In line with the Mass Python 2 Package Removal [0], all (sub)packages of resultsdb_conventions were marked for removal: * python2-resultsdb_conventions * python2-resultsdb_conventions-fedora According to our query, those packages only provide a Python 2 importable module. If this is not true, please tell us why, so we can fix our query. Please retire your package in Rawhide (Fedora 30). If there is no objection in a week, we will retire the package for you. We hope this doesn't come to you as a surprise. If you want to know our motivation for this, please read the change document [0]. [0] https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal
No, I will not do this, at least not yet. I certainly will not retire the package. It builds only for Python 2 at present as the whole chain of things that uses it runs on Python 2, because it was all built around fedmsg, which for years did not work properly under Python 3. Now it apparently does, but I have not yet had time to look at what is needed to move all the bits in infra over to running on Python 3 instead of Python 2. It's probably not something I can just flip a single switch on, various things are going to need to be co-ordinated. There is a whole chain of events co-ordinated by fedmsg consumers that needs to be sorted out.
According to our query, those packages only provide a Python 2 importable module not needed by anything else. Help us understand why is this package needed and what pattern we need to recognize as "important" here. As an example we filter out packages that install to /usr/lib/python2.7/site-packages/libtaskotron/ext/ as we realize those are needed for various taskotron extensions.
More explicitly, how exactly do we find the "whole chain of things that uses it"?
It would be a bit difficult to tell as none of the consumers are packaged :/ It makes little sense to package them as they have virtually no utility outside of Fedora infra, and I often need to make changes. The major consumers are: https://pagure.io/fedora-qa/fedora_openqa https://pagure.io/fedora-qa/autocloudreporter these are the things that forward results from openQA and Autocloud to ResultsDB. This is all done using fedmsg consumers that run on a box in Fedora infra (openqa01.qa specifically). If I can figure out what I actually need to do to switch that box over to using Python 3 fedmsg services instead of Python 2, and ensure all the necessary consumers and all their deps are installed in Python 3 versions not Python 2 versions, we can drop all the Python 2 subpackages and stuff (there are several others in this chain, e.g. fedfind and python-wikitcms). But only once that's figured out. I mean, technically I could change the packages in Rawhide before figuring all that out, but honestly I'd be more comfortable getting all the bits actually running on Python 3 *where we use them for important functions*, then retiring the subpackages after that.
Note this conversation: <adamw> so <adamw> serious question <adamw> is there some sort of co-ordinated plan for switching from python2 to python3 for fedmsg stuff in infra? <adamw> because alll of the fedmsg-y stuff i maintain on the openqa boxes is still running on py2 afaik <adamw> i do not know if there's some sort of standard process for switching over to python3 fedmsg <nirik> you should just be able to do that anytime I think... <puiterwijk> adamw: fedmsg has py3 support. <puiterwijk> That should just work <adamw> well yes <adamw> but it's the...implementation <adamw> didn't i see that there are alternative versions of all the services with different names? <adamw> so plain old 'fedmsg.service' or whatever is py2, then there's 'fedmsg3.service' or something that's py3 <puiterwijk> Oh, that could be <adamw> so since the fedmsg stuff for infra is standardized in the playbook, i don't know what i'm supposed to do if anything to get those plays to use the py3 versions, or whatever <puiterwijk> Ahhhh. That's what you mean, I see. <puiterwijk> So... I don't know that any of the playbooks and roles are in that way ready to deal with py3 services yet, I guess... <puiterwijk> So... You can be the person to implement that? :D * puiterwijk runs So, there's quite a lot of fedmsg stuff running in Fedora infra, and at least if that conversation is accurate, *all* of it is currently running on Python 2.
> It would be a bit difficult to tell as none of the consumers are packaged :/ > It makes little sense to package them as they have virtually no utility > outside of Fedora infra, and I often need to make changes. > > The major consumers are: > > https://pagure.io/fedora-qa/fedora_openqa > https://pagure.io/fedora-qa/autocloudreporter So if I take this as a source of override, everything will be fine? https://pagure.io/fedora-qa/fedora_openqa/blob/master/f/setup.py#_55 https://pagure.io/fedora-qa/autocloudreporter/blob/master/f/install.requires How often does it change? I.e. is it OK if I copy it or should I try fetching it? > So, there's quite a lot of fedmsg stuff running in Fedora infra, and at > least if that conversation is accurate, *all* of it is currently running on > Python 2. This is sadly not surprising to me at all.
"So if I take this as a source of override, everything will be fine?" It should mostly cover things, I think, yeah.
https://github.com/fedora-python/portingdb/pull/442
I'm closing this one, the packages are now whitelisted. See https://pagure.io/fedora-infrastructure/issue/7235 for a followup.