EPEL2RHEL - New Wording? - New Workflow?
by Troy Dawson
Hi All,
EPEL2RHEL is part of the RHEL 8 and 9 new package workflow. When a RHEL
maintainer wants to add a package to RHEL 8 or 9 they start a "new package
workflow". There are several automations that happen when they start that
workflow. One of them is checking if the package is already in epel. If
it is, it creates a bugzilla against that package, and links that bug
against the EPEL2RHEL tracker. [1]
Remember, this check currently happens at the beginning of the new package
workflow. Before a package has been branched, built, or put into testing
repos.
Thus far, there are three problems.
1 - The wording can be confusing:
Subject: Remove <package> from epel9
Comment: This package is being added to RHEL 9.1 at the next minor release.
Please remove it from epel after the next RHEL minor release.
The subject sounds like it should be removed right now. Only if the
maintainer reads the comments do they see it should be removed after the
next release.
What is further confusing is if the package is coming out for a release
that has already happened. We just had one that said it was being added to
RHEL 8.6. The instructions clearly state that it should be removed after
RHEL 8.6 is released, and so it was removed.
2 - What about BuildRoot only packages.
If a RHEL package is a BuildRoot only package, they are fine being in
epel. But at the time the new package is requested, the scripts have no
way of knowing where the binary packages will end up.
Thus, it is possible that a package creates an EPEL2RHEL bug, that package
ends up being in RHEL BuildRoot only, and the epel maintainer removed the
package anyway.
3 - Race conditions
We already saw in RHEL 8.6 that race conditions exist. There were two
packages that were requested in epel and RHEL on the same week. Both
checked, didn't see anything, and then went along their proper path. Only
to find out that when RHEL 8.6 was released, we had duplicate packages in
epel8.
** Solution(s)
A - At the very least, we need to change the wording of the bugs. I am
proposing the following
Subject: Remove <package> from epel9 when rhel 9.1 is released
Comment: This package is being added to RHEL 9.1 at the next minor
release. After the next RHEL minor release, please verify this package was
released in RHEL, and if so remove it from epel9.
B - If possible, move the EPEL2RHEL check to later in the development
cycle. I would like it to be in the step where the packages get added to
BaseOS, AppStream, or CRB. That way we would know it isn't going to be a
BuildRoot only package, and it would reduce the time the bugs sit waiting.
I don't know if this is possible, but I'm going to ask.
C - ?? What if we only created the bugs on the tracker itself, and not the
individual packages ??
Would that be a good thing? Or would it irritate the maintainers?
Troy
[1] - https://bugzilla.redhat.com/show_bug.cgi?id=1998160
1 year
EPEL 8: %__python3 == /usr/bin/python3 creates runtime problems with alternatives
by Miro Hrončok
Hello EPEL folks,
In EL 8, it is possible to change the "meaning" of /usr/bin/python3 because it
is managed by alternatives:
$ ls -l /usr/bin/python3
lrwxrwxrwx. ... /usr/bin/python3 -> /etc/alternatives/python3
And since %__python3 on EPEL 8 is set to /usr/bin/python3 by epel-rpm-macros:
$ rpm --eval '%__python3'
/usr/bin/python3
When packages have %py3_shebang_fix on EPEL 8:
%py3_shebang_fix %{buildroot}%{_bindir}/*
The shebengs have #!/usr/bin/python3 in them.
(This is done by %__brp_mangle_shebangs automatically, so even packages without
%py3_shebang_fix might be affected.)
But when the package has importable modules in %{python3_sitelib} or
%{python3_sitearch} or simply depends on other Python 3.6 modules, and the user
uses alternatives to change /usr/bin/python3 to e.g. python3.9, the script no
longer works.
I suppose the default value of %__python3 needs to be /usr/bin/python3.6 to
prevent this way of shooting the users to their legs.
(I apologize for letting the alternatives happen, but that ship has sailed a
long time ago. Fortunately, EL 9 no longer have this.)
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 1 month
python3-qt5-webkit for EPEL 8
by Orion Poplawski
The python-qt5 package in RHEL 8 does not ship the webkit package. I'm
assuming that this is unlikely to be changed since qt5-qtwebkit isn't in
RHEL but is in EPEL.
I think I'm close to producing a python-qt5-epel package here [1] that
produces python3-qt5-webkit and would love to hear from people more
familiar with the package if this seems like it's reasonable/workable.
I think we're depending on the fact that the RHEL python3-qt5-devel
package does ship the WebKit sip files and that these would match up
with what this package ships.
It also just seems like webengine isn't in there, or I'm missing what's
needed to build it. I also don't need it for my purposes.
[1] - https://copr.fedorainfracloud.org/coprs/orion/python-qt5-epel/
--
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/
1 year, 2 months
Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
by Maxwell G
On Tue Jan 31, 2023 at 15:01 +0200, Sagi Shnaidman wrote:
Hi all,
> Hi, Orion
> Thanks for raising this question.
Indeed!
> I wonder if it's possible to continue to update collections to the
> newest versions anyway. If someone wants to use the collection version
> provided in "big ansible", they would use ansible 6.3.0 with all
> included. If they want a newer collection, they can install a separate
> newest RPM.
I agree. I think we should update collections to the next major version
(if it exists) after each RHEL minor release and then keep them updated
with point releases in between. We update the ansible bundle to the next
major version that corresponds to RHEL's ansible-core version at each
RHEL minor release, so it makes to do the same with the standalone
collection packages. Collection versions that are EOL upstream won't be
tested with newer ansible-core versions.
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/They
1 year, 2 months
Fwd: Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
by Maxwell G
2023-01-31T14:05:11Z David Moreau-Simard <moi(a)dmsimard.com>:
Hi,
Answer in-line but I also want to extend an invititation to everyone here
to join #ansible-packaging on libera.chat (or #packaging:ansible.com on
Matrix) which is a low signal-to-noise ratio channel to talk about
Ansible packaging things such as this one :)
------- Original Message -------
On Tuesday, January 31st, 2023 at 8:01 AM, Sagi Shnaidman
<sshnaidm(a)redhat.com> wrote:
> Hi, Orion
> Thanks for raising this question.
>
> I use both ways - either ansible distro with all-inclusive, or ansible
> (distro or "core") with specific collection installed separately when I
> need a newer version of collection, for example. I wonder if it's
> possible to continue to update collections to the newest versions
> anyway. If someone wants to use the collection version provided in "big
> ansible", they would use ansible 6.3.0 with all included. If they want
> a newer collection, they can install a separate newest RPM.
>
> But not sure if dependencies can be a problem here, like which
> collection version depends on other collection versions (for example
> ansible.utils, which is part of multiple collection dependencies).
We took this use case into account when we refacoted the Fedora ansible
package to match the "post ansible 2.9 era", see:
* https://fedoraproject.org/wiki/Changes/Ansible5
*
https://src.fedoraproject.org/rpms/ansible/blob/rawhide/f/ansible.spec#_207
TL;DR:
* The ansible package installs collections to the python site-lib
* The ansible collections packages should (generally?) install to
/usr/share
* Installing manually from galaxy installs to ~/.ansible
The order of precedence makes it so galaxy-installed collections will
have priority over those installed by the collection packages which have
precedence over those installed by the ansible package.
There may be edge cases where mismatched dependencies could lead to
issues but I'm not sure we can do much about that.
> Let me know what you think.
>
> Thanks
>
> On Tue, Jan 31, 2023 at 2:14 PM Paul Howarth <paul(a)city-fan.org> wrote:
>> On Mon, 30 Jan 2023 21:13:11 -0700
>> Orion Poplawski <orion(a)nwra.com> wrote:
>>
>>> So, I'm wondering if we should have some kind of (at least
>>> semi-)coordinated plan for updating ansible collections in EPEL?
>>>
>>> My initial thought is we would sort of piggy back on to what the
>>> "ansible" community collection bundles on top of the ansible-core
>>> package provided by RedHat. So, currently in EL8.7 we have:
>>>
>>> ansible-core-2.13.3
>>>
>>> and EPEL ships:
>>>
>>> ansible-6.3.0 - which corresponds to the ansible community package
>>> that ships with ansible-2.13.3.
>>>
>>> Then we would endeavor to ship the individual package collection
>>> versions that are contained in that package, .e.g: (taken from the
>>> MANIFEST.json files):
>>>
>>> ansible.posix 1.4.0
>>> ansible.utils 2.6.1
>>> chocolatey.chocolatey 1.3.0
>>> community.docker 2.7.1
>>> community.general 5.5.0
>>> community.libvirt 1.2.0
>>> community.mysql 3.4.0
>>> community.rabbitmq 1.2.2
>>> containers.podman 1.9.4
>>> netbox.netbox 3.7.1
>>
>> Sounds like a reasonable plan to me.
>>
>>> For reference, currently in epel we have:
>> ...
>>> ansible-collection-community-libvirt.noarch 1.1.0-3.el8
>>> epel
>>
>> I updated ansible-collection-community-libvirt to 1.2.0:
>> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-98b1fc46a5
>>
>>> I don't really have a particular agenda here, just trying to solicit
>>> people's thoughts. Personally I like minimal installs so I have been
>>> only using ansible-core + collections on the systems I maintain and
>>> would like to continue to see them be usable together.
>>
>> I too just use ansible-core + collections on the systems I maintain.
>>
>> Regards, Paul.
>>
>
>
> --
> Best regards
> Sagi Shnaidman
1 year, 2 months
Fwd: Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
by Maxwell G
2023-01-31T13:02:09Z Sagi Shnaidman <sshnaidm(a)redhat.com>:
Hi, Orion
Thanks for raising this question.
I use both ways - either ansible distro with all-inclusive, or ansible
(distro or "core") with specific collection installed separately when I
need a newer version of collection, for example. I wonder if it's
possible to continue to update collections to the newest versions anyway.
If someone wants to use the collection version provided in "big ansible",
they would use ansible 6.3.0 with all included. If they want a newer
collection, they can install a separate newest RPM.
But not sure if dependencies can be a problem here, like which collection
version depends on other collection versions (for example ansible.utils,
which is part of multiple collection dependencies).
Let me know what you think.
Thanks
On Tue, Jan 31, 2023 at 2:14 PM Paul Howarth <paul(a)city-fan.org> wrote:
> On Mon, 30 Jan 2023 21:13:11 -0700
> Orion Poplawski <orion(a)nwra.com> wrote:
>
>> So, I'm wondering if we should have some kind of (at least
>> semi-)coordinated plan for updating ansible collections in EPEL?
>>
>> My initial thought is we would sort of piggy back on to what the
>> "ansible" community collection bundles on top of the ansible-core
>> package provided by RedHat. So, currently in EL8.7 we have:
>>
>> ansible-core-2.13.3
>>
>> and EPEL ships:
>>
>> ansible-6.3.0 - which corresponds to the ansible community package
>> that ships with ansible-2.13.3.
>>
>> Then we would endeavor to ship the individual package collection
>> versions that are contained in that package, .e.g: (taken from the
>> MANIFEST.json files):
>>
>> ansible.posix 1.4.0
>> ansible.utils 2.6.1
>> chocolatey.chocolatey 1.3.0
>> community.docker 2.7.1
>> community.general 5.5.0
>> community.libvirt 1.2.0
>> community.mysql 3.4.0
>> community.rabbitmq 1.2.2
>> containers.podman 1.9.4
>> netbox.netbox 3.7.1
>
> Sounds like a reasonable plan to me.
>
>> For reference, currently in epel we have:
> ...
>> ansible-collection-community-libvirt.noarch 1.1.0-3.el8
>> epel
>
> I updated ansible-collection-community-libvirt to 1.2.0:
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-98b1fc46a5
>
>> I don't really have a particular agenda here, just trying to solicit
>> people's thoughts. Personally I like minimal installs so I have been
>> only using ansible-core + collections on the systems I maintain and
>> would like to continue to see them be usable together.
>
> I too just use ansible-core + collections on the systems I maintain.
>
> Regards, Paul.
>
--
Best regards
Sagi Shnaidman
1 year, 2 months
Replace versioned MODULE_COMPAT_ requires by generators
by Jitka Plesnikova
Hi,
I am preparing replacement of versioned MODULE_COMPAT_ requires by
dependency generators.
More details about the change can be found in mail thread [1].
The dependency generator, which I have prepared for Fedora, does not
work for EPEL.
I would like to help maintainers who prefer one version of the spec file
for all releases,
if it is possible.
Could be the following file added to the package epel-rpm-macros (or
anything like this) for EPEL 9?
$ cat perlcompat.attr
%__perlcompat_requires() %{lua:
local path = rpm.expand('%1')
local perl_ver = rpm.expand('%{perl_version}')
if path:match('.+%.so$') and perl_ver ~= "" then
print('perl(:MODULE_COMPAT_' .. perl_ver .. ')')
else
print('perl-libs')
end
}
%__perlcompat_path
^(%{perl_vendorarch}|%{perl_vendorlib}|%{perl_privlib}|%{perl_archlib})/.+
But I don't know how to do it for EPEL 7/8, because the above file
doesn't work.
It ends with error [2]:
error: Couldn't exec perl-libs: No such file or directory
Do you have any idea if there is any other way how to provide
maintainers this functionality for EPEL 7/8?
Thanks for any advice,
Jitka
[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
[2]
https://download.copr.fedorainfracloud.org/results/jplesnik/perl-epel/cen...
--
Jitka Plesnikova
Senior Software Engineer
Red Hat
1 year, 2 months
A coordinated plan for ansible-collection updates in EPEL?
by Orion Poplawski
So, I'm wondering if we should have some kind of (at least
semi-)coordinated plan for updating ansible collections in EPEL?
My initial thought is we would sort of piggy back on to what the
"ansible" community collection bundles on top of the ansible-core
package provided by RedHat. So, currently in EL8.7 we have:
ansible-core-2.13.3
and EPEL ships:
ansible-6.3.0 - which corresponds to the ansible community package that
ships with ansible-2.13.3.
Then we would endeavor to ship the individual package collection
versions that are contained in that package, .e.g: (taken from the
MANIFEST.json files):
ansible.posix 1.4.0
ansible.utils 2.6.1
chocolatey.chocolatey 1.3.0
community.docker 2.7.1
community.general 5.5.0
community.libvirt 1.2.0
community.mysql 3.4.0
community.rabbitmq 1.2.2
containers.podman 1.9.4
netbox.netbox 3.7.1
For reference, currently in epel we have:
ansible-collection-ansible-posix.noarch 1.4.0-1.el8 epel
ansible-collection-ansible-utils.noarch 2.6.1-1.el8 epel
ansible-collection-chocolatey-chocolatey.noarch 1.4.0-1.el8 epel
ansible-collection-community-docker.noarch 2.6.0-1.el8 epel
ansible-collection-community-general.noarch 3.8.9-1.el8 epel
ansible-collection-community-libvirt.noarch 1.1.0-3.el8 epel
ansible-collection-community-mysql.noarch 3.5.1-1.el8 epel
ansible-collection-community-rabbitmq.noarch 1.2.3-1.el8 epel
ansible-collection-containers-podman.noarch 1.10.1-1.el8 epel
ansible-collection-netbox-netbox.noarch 3.7.1-1.el8 epel
However, it's hard for me to resist the allure of the shiny and new, so
I've updated chocolatey. Similarly some others have been updated to
later versions.
The other interesting case here is community.general - ansible has it at
5.5.0, but it looks like Maxwell G has taken the generally preferred
course for EPEL of sticking with the stable release track of 3.X.
Although I suspect very few collections maintain multiple release tracks
(no idea).
I don't really have a particular agenda here, just trying to solicit
people's thoughts. Personally I like minimal installs so I have been
only using ansible-core + collections on the systems I maintain and
would like to continue to see them be usable together.
--
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/
1 year, 2 months