Python 2.7 will reach end-of-life in January 2020, over 9 years after it was released. This falls within the Fedora 31 lifetime. Packages that depend on Python 2 are being switched to Python 3 or removed from Fedora: https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal#Information_on_Remaining_Packages Python 2 will be retired in Fedora 32: https://fedoraproject.org/wiki/Changes/RetirePython2 To help planning, we'd like to know the plans for python-ipaddress's future. Specifically: - What is the reason for the Python2 dependency? (Is it software written in Python, or does it just provide Python bindings, or use Python in the build system or test runner?) - What are the upstream/community plans/timelines regarding Python 3? - What is the guidance for porting to Python 3? (Assuming that there is someone who generally knows how to port to Python 3, but doesn't know anything about the particular package, what are the next steps to take?) This bug is filed semi-automatically, and might not have all the context specific to python-ipaddress. If you need anything from us, or something is unclear, please mention it here. Thank you.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
Please answer the above questions. If you don't, the package can be orphaned: https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal#Information_on_Remaining_Packages If you need any information or help, or if you need some more time, please let us know.
Package has been retired: python 3.3+ has a native implementation of this library
Did you coordinate with maintainers of packages that depend on ipaddress?
Dependent packages blew up.
python2-cryptography package blows up. Please reinstate python2-ipaddress until all packages are fixed that require python2-cryptography.
https://pagure.io/releng/issue/8721
I don't think that would be the correct approach ? python2 will not be part of fedora 32, and this build was only done in rawhide. So regardless, python-cryptography using python2 will blow up regardless. It just needs to be fixed? It seems the only packages affected are (based on repoquery on f30) python-cryptography python-policycoreutils python-service-identity python-urllib3 I will have a look at those packages and see if we can fix those if still needed instead of crippling python-ipaddress again
> python2 will not be part of fedora 32 That is not entirely correct. The interpreter stays and packages may request exceptions. Chances are, somebody will request an exception that will include ipaddress. We don't break things on purpose (yet anyway) by removing packages that are depended upon. > I will have a look at those packages and see if we can fix those if still needed instead of crippling python-ipaddress again fix how?
I cannot drop python2-cryptography as long as other packages still depend on it. The dependencies must be addresses leaf first. Bazaar (bzr) is currently blocking Python 2 removal. Either bzr must be dropped or we have to keep Python 2 stuff in F32. # dnf repoquery --whatrequires python2-cryptography python2-paramiko-0:2.6.0-3.fc32.noarch python2-pyOpenSSL-0:19.0.0-3.fc32.noarch python2-requests-kerberos-0:0.12.0-7.fc32.noarch python2-service-identity-0:18.1.0-4.fc32.noarch # dnf repoquery --whatrequires python2-pyOpenSSL certmaster-0:0.28-19.fc31.noarch func-0:0.30-16.fc31.noarch python2-dslib-0:3.1-13.fc31.noarch python2-impacket-0:0.9.19-1.fc31.1.noarch python2-paste-0:3.0.8-3.fc32.noarch python2-service-identity-0:18.1.0-4.fc32.noarch # dnf repoquery --whatrequires python2-paramiko bzr-0:2.7.0-23.fc30.x86_64 # dnf repoquery --recursive --whatrequires python2-cryptography bzr-0:2.7.0-23.fc30.x86_64 bzr-doc-0:2.7.0-23.fc30.noarch certmaster-0:0.28-19.fc31.noarch etckeeper-bzr-0:1.18.8-4.fc32.noarch func-0:0.30-16.fc31.noarch git-remote-bzr-0:0.2-12.fc31.noarch python2-dslib-0:3.1-13.fc31.noarch python2-impacket-0:0.9.19-1.fc31.1.noarch python2-paramiko-0:2.6.0-3.fc32.noarch python2-paste-0:3.0.8-3.fc32.noarch python2-paste-deploy-0:2.0.1-3.fc32.noarch python2-pdc-client-0:1.8.0-14.fc32.noarch python2-plaster-pastedeploy-0:0.7-3.fc32.noarch python2-pyOpenSSL-0:19.0.0-3.fc32.noarch python2-requests-kerberos-0:0.12.0-7.fc32.noarch python2-service-identity-0:18.1.0-4.fc32.noarch python2-wstool-0:0.1.17-13.fc32.noarch python3-rosinstall-0:0.7.8-7.fc32.noarch python3-wstool-0:0.1.17-13.fc32.noarch trac-bazaar-plugin-0:0.4.2-16.fc31.noarch > I will have a look at those packages and see if we can fix those if still needed instead of crippling python-ipaddress again I don't understand this comment. Why are these packages crippling python-ipaddresses? python-ipaddress SRPM only provides python2-ipaddress noarch RPM. In Python 3 the ipaddress module is part of the standard library. Once Python 2 is gone the python-ipaddress package can be retired completely.
python-ipaddress was just retired from rawhide after being orphaned for 6+ weeks.