epel-devel January 2023

epel-devel@lists.fedoraproject.org

16 participants
102 discussions

EPEL2RHEL - New Wording? - New Workflow?
by Troy Dawson 04 Apr '23

04 Apr '23

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

12 35

Re: Backported som rpm from fedora to epel
by Troy Dawson 22 Mar '23

22 Mar '23

lsyncd and autossh - already in epel9 geoip - https://bugzilla.redhat.com/show_bug.cgi?id=2066787 "Please do NOT branch GeoIP for EPEL 9, because MaxMind, the GeoIP upstream, has clearly declared the end of life for GeoIP" webalizer - nobody has asked for it. And maybe someone needs to port webalizer to use libmaxminddb On Fri, Sep 9, 2022 at 6:29 AM Serge Sterck via epel-devel < epel-devel(a)lists.fedoraproject.org> wrote: > I have backported from fedora to almalinux 9/centos 9/rocky 9 some rpms > > > lsyncd > autossh > geoip needed for webalizer > webalier > > > i provide the binary and the source rpm at this url > > > alma9-rpm > <https://tenfmsb-my.sharepoint.com/:f:/g/personal/serge_sterck_fmsb_be/EgNXH…> >

2 3

EPEL 8: %__python3 == /usr/bin/python3 creates runtime problems with alternatives
by Miro Hrončok 23 Feb '23

23 Feb '23

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

2 9

python3-qt5-webkit for EPEL 8
by Orion Poplawski 06 Feb '23

06 Feb '23

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/

3 2

Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
by Maxwell G 02 Feb '23

02 Feb '23

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

3 3

[Fedocal] Reminder meeting : EPEL Steering Committee
by tdawson＠redhat.com 01 Feb '23

01 Feb '23

Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2023-02-01 from 16:00:00 to 17:00:00 US/Eastern At fedora-meeting(a)irc.libera.chat The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #topic aloha #topic EPEL Issues https://pagure.io/epel/issues * https://pagure.io/epel/issues?tags=meeting&status=Open #topic Old Business (if needed) #topic General Issues / Open Floor Source: https://calendar.fedoraproject.org//meeting/9854/

2 1

Fwd: Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
by Maxwell G 31 Jan '23

31 Jan '23

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 0

Fwd: Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
by Maxwell G 31 Jan '23

31 Jan '23

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 0

Replace versioned MODULE_COMPAT_ requires by generators
by Jitka Plesnikova 31 Jan '23

31 Jan '23

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.org… [2] https://download.copr.fedorainfracloud.org/results/jplesnik/perl-epel/cento… -- Jitka Plesnikova Senior Software Engineer Red Hat

4 6

A coordinated plan for ansible-collection updates in EPEL?
by Orion Poplawski 31 Jan '23

31 Jan '23

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/

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

epel-devel January 2023