Hi all,
with the "upcoming" ansible-core migration, I wonder if its possible to provide a python-passlib package (or stream) for the python38 environment (ansible-core dependency).
The current status:
# rpm -q python3-passlib --requires |head -1 python(abi) = 3.6
Whats the best approach. Upgrade the ABI compat or provide a module build?
-- Thanks Leon
On Mon, May 16, 2022 at 3:42 PM Leon Fauster via epel-devel epel-devel@lists.fedoraproject.org wrote:
Hi all,
with the "upcoming" ansible-core migration, I wonder if its possible to provide a python-passlib package (or stream) for the python38 environment (ansible-core dependency).
The current status:
# rpm -q python3-passlib --requires |head -1 python(abi) = 3.6
Whats the best approach. Upgrade the ABI compat or provide a module build?
Modular build against the python38 module.
josh
On Tue, 17 May 2022 at 07:02, Josh Boyer jwboyer@redhat.com wrote:
On Mon, May 16, 2022 at 3:42 PM Leon Fauster via epel-devel epel-devel@lists.fedoraproject.org wrote:
Hi all,
with the "upcoming" ansible-core migration, I wonder if its possible to provide a python-passlib package (or stream) for the python38 environment (ansible-core dependency).
The current status:
# rpm -q python3-passlib --requires |head -1 python(abi) = 3.6
Whats the best approach. Upgrade the ABI compat or provide a module
build?
Modular build against the python38 module.
[resend because lists did not like me previously.]
As far as I know, the Fedora/EPEL MBS/Koji can not do this without itself building a python38 module which matches/replaces the RHEL one. MBS can only use modules which it has built itself and does not have a way to understand about 'external' modules. [ All RHEL code is 'external' to both koji and mbs databases so they do not have a way to reference them for a build.]
Because of this, we have to use grobisplitter to put the python38 as a 'regular' rpm (which works because the pythons are parallel installable.).
I think what could be done is a python38-passlib package which was built against the python38 rpms.
josh _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Am 17.05.22 um 14:57 schrieb Stephen Smoogen:
On Tue, 17 May 2022 at 07:02, Josh Boyer <jwboyer@redhat.com mailto:jwboyer@redhat.com> wrote:
On Mon, May 16, 2022 at 3:42 PM Leon Fauster via epel-devel <epel-devel@lists.fedoraproject.org <mailto:epel-devel@lists.fedoraproject.org>> wrote: > > Hi all, > > with the "upcoming" ansible-core migration, I wonder if its possible to > provide a python-passlib package (or stream) for the python38 > environment (ansible-core dependency). > > The current status: > > # rpm -q python3-passlib --requires |head -1 > python(abi) = 3.6 > > Whats the best approach. Upgrade the ABI compat or provide a module build? Modular build against the python38 module.[resend because lists did not like me previously.]
As far as I know, the Fedora/EPEL MBS/Koji can not do this without itself building a python38 module which matches/replaces the RHEL one. MBS can only use modules which it has built itself and does not have a way to understand about 'external' modules. [ All RHEL code is 'external' to both koji and mbs databases so they do not have a way to reference them for a build.]
Because of this, we have to use grobisplitter to put the python38 as a 'regular' rpm (which works because the pythons are parallel installable.).
I think what could be done is a python38-passlib package which was built against the python38 rpms.
Ok, thanks. A quick local test was successful. python38-passlib and python3-passlib are parallel installable.
Following patch
https://paste.centos.org/view/06187bdb
adapts
https://src.fedoraproject.org/rpms/python-passlib/blob/main/f/python-passlib...
to build it locally (for the sake of progress I disabled the tests/nose dep).
Playbooks have access to missing jinja filters now. Great!
I will try to request this via bugzilla/epel or is the maintainer "apevec" maybe here?
-- Thanks Leon
On 17. 05. 22 16:58, Leon Fauster via epel-devel wrote:
Am 17.05.22 um 14:57 schrieb Stephen Smoogen:
On Tue, 17 May 2022 at 07:02, Josh Boyer <jwboyer@redhat.com mailto:jwboyer@redhat.com> wrote:
On Mon, May 16, 2022 at 3:42 PM Leon Fauster via epel-devel <epel-devel@lists.fedoraproject.org mailto:epel-devel@lists.fedoraproject.org> wrote: > > Hi all, > > with the "upcoming" ansible-core migration, I wonder if its possible to > provide a python-passlib package (or stream) for the python38 > environment (ansible-core dependency). > > The current status: > > # rpm -q python3-passlib --requires |head -1 > python(abi) = 3.6 > > Whats the best approach. Upgrade the ABI compat or provide a module build?
Modular build against the python38 module.
[resend because lists did not like me previously.]
As far as I know, the Fedora/EPEL MBS/Koji can not do this without itself building a python38 module which matches/replaces the RHEL one. MBS can only use modules which it has built itself and does not have a way to understand about 'external' modules. [ All RHEL code is 'external' to both koji and mbs databases so they do not have a way to reference them for a build.]
Because of this, we have to use grobisplitter to put the python38 as a 'regular' rpm (which works because the pythons are parallel installable.).
I think what could be done is a python38-passlib package which was built against the python38 rpms.
Ok, thanks. A quick local test was successful. python38-passlib and python3-passlib are parallel installable.
Following patch
Why %{?python_disable_dependency_generator} ?
On Tuesday, May 17, 2022 9:58:33 AM CDT Leon Fauster via epel-devel wrote:
https://paste.centos.org/view/06187bdb
adapts
https://src.fedoraproject.org/rpms/python-passlib/blob/main/f/python-passlib...
to build it locally (for the sake of progress I disabled the tests/nose dep).
Unless you are planning to remove python3-passlib (the python36 version) or make it a modular package, I think it is better to just create a new SRPM named python38-passlib with no subpackages.
Am 17.05.22 um 18:08 schrieb Maxwell G:
On Tuesday, May 17, 2022 9:58:33 AM CDT Leon Fauster via epel-devel wrote:
https://paste.centos.org/view/06187bdb
adapts
https://src.fedoraproject.org/rpms/python-passlib/blob/main/f/python-passlib...
to build it locally (for the sake of progress I disabled the tests/nose dep).
Unless you are planning to remove python3-passlib (the python36 version) or make it a modular package, I think it is better to just create a new SRPM named python38-passlib with no subpackages.
https://bugzilla.redhat.com/show_bug.cgi?id=2087268
PS: Is it only my impression or do others feel also the same. Starting with EL8 the expenses just for the platform (distribution) gets more and more attention in our daily work. Shouldn't it be the other way around?
-- Leon
On Tuesday, May 17, 2022 1:05:20 PM CDT Leon Fauster via epel-devel wrote:
PS: Is it only my impression or do others feel also the same. Starting with EL8 the expenses just for the platform (distribution) gets more and more attention in our daily work. Shouldn't it be the other way around?
Well, in this case, the issue is that ansible-core bumped its minimal Python version requirement for the controller to 3.8. They had no choice but to build it for a non-default Python version.
On 5/17/22 12:05, Leon Fauster via epel-devel wrote:
Am 17.05.22 um 18:08 schrieb Maxwell G:
On Tuesday, May 17, 2022 9:58:33 AM CDT Leon Fauster via epel-devel wrote:
https://paste.centos.org/view/06187bdb
adapts
https://src.fedoraproject.org/rpms/python-passlib/blob/main/f/python-passlib...
to build it locally (for the sake of progress I disabled the tests/nose dep).
Unless you are planning to remove python3-passlib (the python36 version) or make it a modular package, I think it is better to just create a new SRPM named python38-passlib with no subpackages.
I've been coming to the thinking that naming the SRPMS python3X-%{srcname}-epel is a better choice. This makes modifying original Fedora specs simpler. See https://fedoraproject.org/wiki/EPEL/Python3X
PS: Is it only my impression or do others feel also the same. Starting with EL8 the expenses just for the platform (distribution) gets more and more attention in our daily work. Shouldn't it be the other way around?
Yes, I seem to be staring down a huge amount of work to package up python 3.8 deps for EPEL8. I suppose I should just give up and start using pip and virtual envs.
On Monday, May 23, 2022 11:18:38 PM CDT Orion Poplawski wrote:
I've been coming to the thinking that naming the SRPMS python3X-%{srcname}-epel is a better choice. This makes modifying original Fedora specs simpler.
I think that makes sense, especially considering that these packages will not be built for Fedora.
Here is some feedback:
First, aren't we trying to move off the wiki? Wouldn't this be a better candidate for the EPEL docs on docs.fp.o?
separate Python 3 minor versions in EPEL 8 are packaged as separate python3X (currently python38) packages to allow for independent versions for each Python version.
There is also python39.
== Issues ==
- How to handle %{py3_dist} macro?
I believe `%{py3_dist}` works properly if you add `%global python3_pkgversion 3X`.
When I built ansible-5 for Python 3.8, I just ran `:%s python3-/python% {python3_pkgversion}-/` and added `%global python3_pkgversion 38`. `% {python3_pkgversion}` is set to 3 by default. I would recommend doing that in your example instead of hardcoding `python38`.
== Example Spec ==
<pre>
[...]
%global sum An example python module
I don't think there's any point to have a %sum macro when you can use `% {summary}` in subpackage definitions. Admittedly, this is more of a packaging nitpick than a comment related to the issue at hand :D.
%global __python3 /usr/bin/python3.8
I think it's better to add `Requires: python%{python3_pkgversion}-rpm-macros`. To be fair, they both do effectively the same thing: set %__python3 to the correct value. In any case, I submitted https://src.fedoraproject.org/rpms/ epel-rpm-macros/pull-request/44 so neither should be necessary.
%check %{__python3} setup.py test
I was going to suggest using `%pytest`, but then I remembered that https:// pagure.io/releng/issue/10679 is still outstanding :(.
%files -n python38-%{srcname}
[...]
%{python3_sitelib}/*
Globs like this are against the Python Packaging Guidelines.
On 5/24/22 11:53, Maxwell G via epel-devel wrote:
On Monday, May 23, 2022 11:18:38 PM CDT Orion Poplawski wrote:
I've been coming to the thinking that naming the SRPMS python3X-%{srcname}-epel is a better choice. This makes modifying original Fedora specs simpler.
I think that makes sense, especially considering that these packages will not be built for Fedora.
Right - that's the other help hopefully to reduce bugzilla issues filed against the wrong component.
Here is some feedback:
First, aren't we trying to move off the wiki? Wouldn't this be a better candidate for the EPEL docs on docs.fp.o?
Sure, except I know nothing about how docs.fp.o works ;)
separate Python 3 minor versions in EPEL 8 are packaged as separate python3X (currently python38) packages to allow for independent versions for each Python version.
There is also python39.
egads. added.
== Issues ==
- How to handle %{py3_dist} macro?
I believe `%{py3_dist}` works properly if you add `%global python3_pkgversion 3X`.
It looks like it's hard-coded to python3dist, so I think it has to change to %{py38_dist}.
When I built ansible-5 for Python 3.8, I just ran `:%s python3-/python% {python3_pkgversion}-/` and added `%global python3_pkgversion 38`. `% {python3_pkgversion}` is set to 3 by default. I would recommend doing that in your example instead of hardcoding `python38`.
Yeah, I think maybe a sed script is in order.
== Example Spec ==
<pre>
[...]
%global sum An example python module
I don't think there's any point to have a %sum macro when you can use `% {summary}` in subpackage definitions. Admittedly, this is more of a packaging nitpick than a comment related to the issue at hand :D.
%global __python3 /usr/bin/python3.8
I think it's better to add `Requires: python%{python3_pkgversion}-rpm-macros`. To be fair, they both do effectively the same thing: set %__python3 to the correct value. In any case, I submitted https://src.fedoraproject.org/rpms/ epel-rpm-macros/pull-request/44 so neither should be necessary.
%check %{__python3} setup.py test
I was going to suggest using `%pytest`, but then I remembered that https:// pagure.io/releng/issue/10679 is still outstanding :(.
%files -n python38-%{srcname}
[...]
%{python3_sitelib}/*
Globs like this are against the Python Packaging Guidelines.
True. Fixed.
Thanks.
On 25. 05. 22 1:56, Orion Poplawski wrote:
== Issues ==
- How to handle %{py3_dist} macro?
I believe `%{py3_dist}` works properly if you add `%global python3_pkgversion 3X`.
It looks like it's hard-coded to python3dist, so I think it has to change to %{py38_dist}.
That could (should?) be fixed by either redefining the macro in each python3X-rpm-macros or by changing the macro in python-srpm-macros to use %python3_pkgversion value -- that would require some "guess-work" where to put the dot, but I suppose the logic won't be that convoluted:
* 3 -> python3dist * 3X -> python3.Xdist * 3XY -> python3.XYdist * 3.X -> python3.Xdist * 3.Y -> python3.XYdist * anything else -> blow up?
That reminds me https://bugzilla.redhat.com/show_bug.cgi?id=1812665 which was fixed incorrectly in RHEL 7 but a followup was never opened.
On Tuesday, May 24, 2022 6:56:41 PM CDT Orion Poplawski wrote:
Sure, except I know nothing about how docs.fp.o works ;)
The source code for the EPEL docs page is here[1]. Honestly, I'm not super familiar with it either :).
[1]: https://pagure.io/epel/tree/main
It looks like it's hard-coded to python3dist, so I think it has to change to %{py38_dist}.
I looked at the macros file on Fedora and saw that it was dynamic, but I was too lazy to look at an actual EL 8 system and notice it hadn't been backported ;(. I opened https://bugzilla.redhat.com/show_bug.cgi?id=2090007. Let's see what the RHEL Python maintainers have to say... As far as I know, `% {py38_dist}` doesn't exist at all.
On 25. 05. 22 2:52, Maxwell G via epel-devel wrote:
On Tuesday, May 24, 2022 6:56:41 PM CDT Orion Poplawski wrote:
Sure, except I know nothing about how docs.fp.o works ;)
The source code for the EPEL docs page is here[1]. Honestly, I'm not super familiar with it either :).
It looks like it's hard-coded to python3dist, so I think it has to change to %{py38_dist}.
I looked at the macros file on Fedora and saw that it was dynamic, but I was too lazy to look at an actual EL 8 system and notice it hadn't been backported ;(. I opened https://bugzilla.redhat.com/show_bug.cgi?id=2090007. Let's see what the RHEL Python maintainers have to say... As far as I know, `% {py38_dist}` doesn't exist at all.
Just for the record. We can fix %{py3_dist} to include the 3.X part, but it will only work when either %python3_pkgversion is redefined in the specfile or python3X-rpm-macros are installed in the buildSRPM buildroot (and the latter is not happening for Koji builds). I.e. doing just this:
BuildRequires: python38-rpm-macros BuildRequires: %{py3_dist ...}
Will *not* work. That is a limitation we cannot workaround.
On Tuesday, May 24, 2022 12:53:36 PM CDT Maxwell G via epel-devel wrote:
I think it's better to add `Requires: python%{python3_pkgversion}-rpm-macros`. To be fair, they both do effectively the same thing: set %__python3 to the correct value. In any case, I submitted https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/44 so neither should be necessary.
* neither should be necessary once the PR is merged.
I should probably clarify, that PR hasn't been merged yet, so it's still necessary to add `BuildRequires: python%{python3_pkgversion}-rpm-macros`.
Am 24.05.22 um 19:53 schrieb Maxwell G via epel-devel:
On Monday, May 23, 2022 11:18:38 PM CDT Orion Poplawski wrote:
I've been coming to the thinking that naming the SRPMS python3X-%{srcname}-epel is a better choice. This makes modifying original Fedora specs simpler.
I think that makes sense, especially considering that these packages will not be built for Fedora.
Here is some feedback:
First, aren't we trying to move off the wiki? Wouldn't this be a better candidate for the EPEL docs on docs.fp.o?
separate Python 3 minor versions in EPEL 8 are packaged as separate python3X (currently python38) packages to allow for independent versions for each Python version.
There is also python39.
Just a followup:
In CS8/EPELNEXT ansible is on following version now:
# rpm -qa |grep ansible ansible-core-2.13.3-1.el8.x86_64 ansible-6.0.0-1.el8.next.noarch
with following dependency
# rpm -q --requires ansible-core |grep abi python(abi) = 3.9
so the mentioned passlib package needs the corresponding rebuild:
I quick test in COPR shows - while builded against the corresponding python "dnf" module, it necessary don't need to be in a stream/module itself. All variants can be installed side by side:
# rpm -qa |grep passlib python3-passlib-1.7.4-6.el8.noarch python38-passlib-1.7.4-6.el8.noarch python39-passlib-1.7.4-8.el8.noarch
It seems that the fedora maintainer had changed:
https://bugzilla.redhat.com/show_bug.cgi?id=2087268
-- Leon
On Monday, May 16, 2022 2:41:57 PM CDT Leon Fauster via epel-devel wrote:
with the "upcoming" ansible-core migration, I wonder if its possible to provide a python-passlib package (or stream) for the python38 environment (ansible-core dependency).
Yes, it's possible. You can create a separate python38-passlib package that BuildRequires python38-rpm-macros and depends on the python38 versions of its dependencies. You may have to package some of the dependencies for python38 even if they're already there for python36. I don't think it has to be modular.
Perhaps the EPEL SIG can create some policy or provide some docs about this process?
epel-devel@lists.fedoraproject.org
-
Josh Boyer -
Leon Fauster -
Maxwell G -
Miro Hrončok -
Orion Poplawski -
Stephen Smoogen