2:41 p.m.
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
6:02 a.m.
On Mon, May 16, 2022 at 3:42 PM Leon Fauster via epel-devel
<epel-devel(a)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
7:57 a.m.
On Tue, 17 May 2022 at 07:02, Josh Boyer <jwboyer(a)redhat.com> wrote:
On Mon, May 16, 2022 at 3:42 PM Leon Fauster via epel-devel
<epel-devel(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)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.fedoraproj...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
9:41 a.m.
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?
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
9:58 a.m.
Am 17.05.22 um 14:57 schrieb Stephen Smoogen:
On Tue, 17 May 2022 at 07:02, Josh Boyer <jwboyer(a)redhat.com
<mailto:jwboyer@redhat.com>> wrote:
On Mon, May 16, 2022 at 3:42 PM Leon Fauster via epel-devel
<epel-devel(a)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-pass...
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
10:27 a.m.
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(a)redhat.com
> <mailto:jwboyer@redhat.com>> wrote:
>
> On Mon, May 16, 2022 at 3:42 PM Leon Fauster via epel-devel
> <epel-devel(a)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
Why %{?python_disable_dependency_generator} ?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
11:08 a.m.
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-pass...
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.
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
1:05 p.m.
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-pass...
>
> 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
4:51 p.m.
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.
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
11:18 p.m.
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-pass...
>>
>>
>> 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
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.
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
12:53 p.m.
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.
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
6:56 p.m.
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.
> See https://fedoraproject.org/wiki/EPEL/Python3X
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.
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
7:29 p.m.
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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
7:52 p.m.
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.
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
2:41 p.m.
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 :).
[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.
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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
7:51 p.m.
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`.
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
1:56 p.m.
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.
> See https://fedoraproject.org/wiki/EPEL/Python3X
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
583
days inactive
704
days old
epel-devel@lists.fedoraproject.org
16 comments
6 participants
participants (6)
-
Josh Boyer -
Leon Fauster -
Maxwell G -
Miro Hrončok -
Orion Poplawski -
Stephen Smoogen