12:52 p.m.
Hello Fedorans and especially Pythonistas.
I'd like to retire python2-setuptools from Fedora 35+.
It contains utilities to execute code downloaded from the internet and it has
not been updated for 2 years. It has a potential of a security hole, although I
am not currently aware of any.
Unfortunately, 6 packages still (Build)Require python2-setuptools in Fedora 35:
https://fedora.portingdb.xyz/pkg/python2-setuptools/
I've split them into 3 categories:
1) Trac plugins: trac-(customfieldadmin|monotone|watchlist)-plugin
Note: trac-monotone-plugin is the only package that Requires python2-setuptools
in Fedora 35 on runtime.
Trac has been already updated to Python 3 in Fedora 34+
The plugins don't (and cannot) work with Python 2 when Trac runs on Python 3.
Bugzillas exists for years:
https://bugzilla.redhat.com/show_bug.cgi?id=1739034
https://bugzilla.redhat.com/show_bug.cgi?id=1739024
https://bugzilla.redhat.com/show_bug.cgi?id=1739042
They were updated this February to point out the uselessness of the packages,
but nothign happened. I have a clear conscience if the packages stop building
(and installing in case of trac-monotone-plugin).
2) Packages that BuildRequire python2-setuptools but don't use it: NFStest
Pull request exists to remove the unused dependency:
https://src.fedoraproject.org/rpms/NFStest/pull-request/2
3) Packages that BuildRequire python2-setuptools but don't have to:
python2-cairo, python-psutil
The two packages use this concept in setup.py:
try:
from setuptools import setup
except ImportError:
from distutils.core import setup
technically, they don't need setuptools to build, the dependency is optional.
Unfortunately they used setuptools to build in the past and if we remove it,
the will change the .egg-info metadata directory to a file. Hence they will hit
a well known limitation in RPM:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Repla...
To compensate a rather ugly scriptlet is needed. The changes were proposed:
https://src.fedoraproject.org/rpms/python-psutil/pull-request/10
https://src.fedoraproject.org/rpms/python2-cairo/pull-request/1
However, I'd rather maintain the 2 scriptlets than python2-setuptools.
Please let me know if you see a problem.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2:23 p.m.
On Wed, Jun 23, 2021 at 1:53 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
Hello Fedorans and especially Pythonistas.
I'd like to retire python2-setuptools from Fedora 35+.
It contains utilities to execute code downloaded from the internet and it has
not been updated for 2 years. It has a potential of a security hole, although I
am not currently aware of any.
If utilities are going to be effectively backported to RHEL 7, it's
useful to have at least the hooks to support python2 until a stack of
critical utilities finally get updated to python3. This includes tools
maintained by Red Hat directly, such as ansible, which still uses
python2 for no reason I can ascertain. But they sell it as part of
their Ansible Tower commercial subscription, so I don't expect it to
to ever be updated for RHEL 7.
Fedora should not be limited by specific version compatibility with
RHEL, but let's be careful when we potentially disable compatibility
with EPEL backports.
Nico Kadel-Garcia
3:34 p.m.
On 23. 06. 21 21:23, Nico Kadel-Garcia wrote:
On Wed, Jun 23, 2021 at 1:53 PM Miro Hrončok
<mhroncok(a)redhat.com> wrote:
>
> Hello Fedorans and especially Pythonistas.
>
> I'd like to retire python2-setuptools from Fedora 35+.
>
> It contains utilities to execute code downloaded from the internet and it has
> not been updated for 2 years. It has a potential of a security hole, although I
> am not currently aware of any.
If utilities are going to be effectively backported to RHEL 7, it's
useful to have at least the hooks to support python2 until a stack of
critical utilities finally get updated to python3. This includes tools
maintained by Red Hat directly, such as ansible, which still uses
python2 for no reason I can ascertain. But they sell it as part of
their Ansible Tower commercial subscription, so I don't expect it to
to ever be updated for RHEL 7.
Fedora should not be limited by specific version compatibility with
RHEL, but let's be careful when we potentially disable compatibility
with EPEL backports.
I am afraid I don't follow. How does removal of python2-setuptools relate to
ansible in RHEL7 or EPEL backports?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
7:52 p.m.
On Wed, Jun 23, 2021 at 4:35 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 23. 06. 21 21:23, Nico Kadel-Garcia wrote:
> On Wed, Jun 23, 2021 at 1:53 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>>
>> Hello Fedorans and especially Pythonistas.
>>
>> I'd like to retire python2-setuptools from Fedora 35+.
>>
>> It contains utilities to execute code downloaded from the internet and it has
>> not been updated for 2 years. It has a potential of a security hole, although I
>> am not currently aware of any.
>
> If utilities are going to be effectively backported to RHEL 7, it's
> useful to have at least the hooks to support python2 until a stack of
> critical utilities finally get updated to python3. This includes tools
> maintained by Red Hat directly, such as ansible, which still uses
> python2 for no reason I can ascertain. But they sell it as part of
> their Ansible Tower commercial subscription, so I don't expect it to
> to ever be updated for RHEL 7.
>
> Fedora should not be limited by specific version compatibility with
> RHEL, but let's be careful when we potentially disable compatibility
> with EPEL backports.
I am afraid I don't follow. How does removal of python2-setuptools relate to
ansible in RHEL7 or EPEL backports?
It doesn't directly. My concern is that as these are withdrawn,
packages which currently include "with_python2" setups in their spec
files will be unable to even test the options, and they'll be stripped
out as a matter of course since it will no longer be possible to even
test compilation under Fedora 35. Has "with_python2" been entirely
discarded for Fedora 35 spec files?
I see that the ansible SRPM in rawhide has already discarded any
support for python2, so that cannot be easily backported to RHEL 7
with continuing use of python2. Our friends doing EPEL support will
have to either do considerable work to continue python2 support, say
with "pyp2rpm", or cooperate with the switch to python3.
7:55 p.m.
On Wed, Jun 23, 2021 at 8:53 PM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
On Wed, Jun 23, 2021 at 4:35 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>
> On 23. 06. 21 21:23, Nico Kadel-Garcia wrote:
> > On Wed, Jun 23, 2021 at 1:53 PM Miro Hrončok <mhroncok(a)redhat.com>
wrote:
> >>
> >> Hello Fedorans and especially Pythonistas.
> >>
> >> I'd like to retire python2-setuptools from Fedora 35+.
> >>
> >> It contains utilities to execute code downloaded from the internet and it
has
> >> not been updated for 2 years. It has a potential of a security hole,
although I
> >> am not currently aware of any.
> >
> > If utilities are going to be effectively backported to RHEL 7, it's
> > useful to have at least the hooks to support python2 until a stack of
> > critical utilities finally get updated to python3. This includes tools
> > maintained by Red Hat directly, such as ansible, which still uses
> > python2 for no reason I can ascertain. But they sell it as part of
> > their Ansible Tower commercial subscription, so I don't expect it to
> > to ever be updated for RHEL 7.
> >
> > Fedora should not be limited by specific version compatibility with
> > RHEL, but let's be careful when we potentially disable compatibility
> > with EPEL backports.
>
> I am afraid I don't follow. How does removal of python2-setuptools relate to
> ansible in RHEL7 or EPEL backports?
It doesn't directly. My concern is that as these are withdrawn,
packages which currently include "with_python2" setups in their spec
files will be unable to even test the options, and they'll be stripped
out as a matter of course since it will no longer be possible to even
test compilation under Fedora 35. Has "with_python2" been entirely
discarded for Fedora 35 spec files?
I see that the ansible SRPM in rawhide has already discarded any
support for python2, so that cannot be easily backported to RHEL 7
with continuing use of python2. Our friends doing EPEL support will
have to either do considerable work to continue python2 support, say
with "pyp2rpm", or cooperate with the switch to python3.
EPEL already advises people to use Python 3 whenever possible for EL7.
For EL8, Python 2 is strongly discouraged. And EL9 isn't even going to
ship Python 2.
At this point, breaking Python 2 in Fedora is really not that big of a deal.
--
真実はいつも一つ！/ Always, there's only one truth!
11:08 p.m.
On Wed, Jun 23, 2021 at 8:56 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
EPEL already advises people to use Python 3 whenever possible for
EL7.
For EL8, Python 2 is strongly discouraged. And EL9 isn't even going to
ship Python 2.
Sadly, their migrations to python3 are not complete and will probably
never approach completion. Between RHEL 8 and EPEL 7, there are
approximately 1300 python2 packages and approximately 500 python3
packages. Resolving the dependency conflicts between packages named
"python3-" and packages named "python36-" complicate backporting: I
took a shot at backporting the current python3 based ansible from
Fedora 34 to RHEL 7 today, and it became very awkward, very quickly.
(pytest dependencies were not my friend.)
At this point, breaking Python 2 in Fedora is really not that big of
a deal.
It's not a *big* deal. I suggest that it comes at a cost for EPEL
backports, especially for RHEL 7.
11:52 p.m.
On Wed, Jun 23, 2021 at 08:52:02PM -0400, Nico Kadel-Garcia wrote:
...snip...
I see that the ansible SRPM in rawhide has already discarded any
support for python2, so that cannot be easily backported to RHEL 7
with continuing use of python2. Our friends doing EPEL support will
have to either do considerable work to continue python2 support, say
with "pyp2rpm", or cooperate with the switch to python3.
The epel7 ansible (classic/2.9) builds both python2 and python2
versions, you can use whatever one you prefer. The epel7 branch has just
diverged from rawhide. It's also as up to date as rawhide is version
wise.
I guess I don't understand what your concern is here... if we required
rawhide to build for all targets, why do we have branches at all?
To me it's a balancing act... some level of conditional is worth it to
allow rawhide's spec to work on other branches, but when it reaches a
level where it's confusing, it's better to break the relationship and
let branches diverge to handle their branch/target only.
kevin
1:13 a.m.
On Thu, Jun 24, 2021 at 12:52 AM Kevin Fenzi <kevin(a)scrye.com> wrote:
On Wed, Jun 23, 2021 at 08:52:02PM -0400, Nico Kadel-Garcia wrote:
...snip...
>
> I see that the ansible SRPM in rawhide has already discarded any
> support for python2, so that cannot be easily backported to RHEL 7
> with continuing use of python2. Our friends doing EPEL support will
> have to either do considerable work to continue python2 support, say
> with "pyp2rpm", or cooperate with the switch to python3.
The epel7 ansible (classic/2.9) builds both python2 and python2
versions, you can use whatever one you prefer. The epel7 branch has just
diverged from rawhide. It's also as up to date as rawhide is version
wise.
Exactly. It's had to be diverged. And they're not identical versions,
epel7 has 2.9.21, and Fedora 34 has 2.9.23.
I guess I don't understand what your concern is here... if we
required
rawhide to build for all targets, why do we have branches at all?
I'm suggesting that we avoid making things more difficult if we don't need to.
To me it's a balancing act... some level of conditional is worth
it to
allow rawhide's spec to work on other branches, but when it reaches a
level where it's confusing, it's better to break the relationship and
let branches diverge to handle their branch/target only.
Sure. I'm suggesting that there is a risk and difficulty to abandoning
python2-setuptools.
10:09 a.m.
On Thu, Jun 24, 2021 at 02:13:03AM -0400, Nico Kadel-Garcia wrote:
On Thu, Jun 24, 2021 at 12:52 AM Kevin Fenzi <kevin(a)scrye.com>
wrote:
>
> On Wed, Jun 23, 2021 at 08:52:02PM -0400, Nico Kadel-Garcia wrote:
> ...snip...
> >
> > I see that the ansible SRPM in rawhide has already discarded any
> > support for python2, so that cannot be easily backported to RHEL 7
> > with continuing use of python2. Our friends doing EPEL support will
> > have to either do considerable work to continue python2 support, say
> > with "pyp2rpm", or cooperate with the switch to python3.
>
> The epel7 ansible (classic/2.9) builds both python2 and python2
> versions, you can use whatever one you prefer. The epel7 branch has just
> diverged from rawhide. It's also as up to date as rawhide is version
> wise.
Exactly. It's had to be diverged. And they're not identical versions,
epel7 has 2.9.21, and Fedora 34 has 2.9.23.
Both git branches should have the same version? Where do you see 2.9.21?
> I guess I don't understand what your concern is here... if
we required
> rawhide to build for all targets, why do we have branches at all?
I'm suggesting that we avoid making things more difficult if we don't need to.
But we did need to. One spec file that works for epel7/epel8/fedora when
we were switching fedora to python3 and some versions had python2 and
some python3 and some both and some couldn't build docs due to some
package versions and some had to exclude some tests due to some versions
became too complex. It was much easier and clearer to diverge branches
and only have the needed items for each branch.
> To me it's a balancing act... some level of conditional is
worth it to
> allow rawhide's spec to work on other branches, but when it reaches a
> level where it's confusing, it's better to break the relationship and
> let branches diverge to handle their branch/target only.
Sure. I'm suggesting that there is a risk and difficulty to abandoning
python2-setuptools.
I'm still not sure I follow why you think so. If epel branches still
use/need it, maintainers can either add conditionals and share a spec
file or diverge branches if they need to. Either way, the issue is
solved?
kevin
11:37 a.m.
On 23. 06. 21 19:52, Miro Hrončok wrote:
To compensate a rather ugly scriptlet is needed. The changes were
proposed:
https://src.fedoraproject.org/rpms/python-psutil/pull-request/10
https://src.fedoraproject.org/rpms/python2-cairo/pull-request/1
The pull requests were adapted to include a less ugly workaround. The egg-info
directory is artificially re-created during build.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
12:10 p.m.
On 24. 06. 21 18:37, Miro Hrončok wrote:
On 23. 06. 21 19:52, Miro Hrončok wrote:
> To compensate a rather ugly scriptlet is needed. The changes were proposed:
>
> https://src.fedoraproject.org/rpms/python-psutil/pull-request/10
> https://src.fedoraproject.org/rpms/python2-cairo/pull-request/1
The pull requests were adapted to include a less ugly workaround. The egg-info
directory is artificially re-created during build.
The pull requests were merged and python2-setuptools was retired.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1025
days inactive
1031
days old
10 comments
4 participants
participants (4)
-
Kevin Fenzi -
Miro Hrončok -
Neal Gompa -
Nico Kadel-Garcia