[EPEL-devel] Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
On 1/31/23 11:03, Maxwell G wrote: 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. Does this capture the general sentiment? - ansible is the static/stable collection of collections paired with the provided ansible-core for the life of the point release - ansible-collection-* packages will be at least the version of the collection in ansible, and optionally higher while giving due diligence to avoiding breaking changes. -- 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 or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fwd: Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
2023-01-31T14:05:11Z David Moreau-Simard : 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 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 wrote: On Mon, 30 Jan 2023 21:13:11 -0700 Orion Poplawski 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 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fwd: Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
2023-01-31T13:02:09Z Sagi Shnaidman : 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 wrote: On Mon, 30 Jan 2023 21:13:11 -0700 Orion Poplawski 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 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
On Tue, Jan 31, 2023 at 06:03:48PM +, Maxwell G wrote: > On Tue Jan 31, 2023 at 15:01 +0200, Sagi Shnaidman wrote: > Hi all, Note that some folks cc'ed are not subscribed to epel-devel, so it probibly rejected their posts. :( > > > 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. Yes, when we first started to package collections we made sure (although I have not checked if anything changed) that the seperately packaged collections would override the bundled ones in the ansible package. So, while the ansible collection of collections and ansible-core are (and should be) closely tied together, the seperately packaged ansible collections should be free to update as long as they continue to work ok with ansible-core thats provided/etc. So, in practice I personally have been thinking of 'ansible' as the stable collection of collections, and the seperately packaged collections as 'next' or 'fast moving' channel. Just my 2cents. kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
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 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Replace versioned MODULE_COMPAT_ requires by generators
On Tue, Jan 31, 2023 at 10:19:09AM +0100, Jitka Plesnikova wrote:
> Hi,
>
> I added the package perl-generators-epel to EPEL 7/8/9. The package is
> adding the behavior provided in perl-generators-1.16.
>
> I created pull requests for epel-rpm-macros to add perl-generators-epel
> to EPEL buildroot.
>
> Pull Request
> EPEL 7: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/61
> EPEL 8: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/60
> EPEL 9: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/59
>
> Could anybody please merge them and build the packages or shall I do it
> myself?
Done. Building now.
Thanks for the pr's
kevin
--
>
> Thanks,
> Jitka
>
> On 12/6/22 04:40, Maxwell G via epel-devel wrote:
> > On Mon Dec 5, 2022 at 21:52 +0100, Jitka Plesnikova wrote:
> > > Could be the following file added to the package epel-rpm-macros (or
> > > anything like this) for EPEL 9?
> > It could, but it might be better to include this in a subpackage of
> > epel-rpm-macros or as a separate perl-generators-epel component. We
> > could pull it in with (package-name-here if perl-generators). This won't
> > work in EPEL 7 which unfortunately doesn't support rich dependencies.
> >
> > > 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?
> > Parametric macro dependency generators are not supported in EPEL 7 and
> > 8's RPM versions. You can still implement this using a "regular"
> > dependency generator. This is also described in the RPM
> > documentation[1]. Instead of specifying %__perlcompat_requires() and
> > writing an RPM macro that accepts a path name as %1, you specify
> > `%__percompat_requires /path/to/executable`. That script receives a
> > newline separated list of paths as stdin and prints the generated
> > dependencies to stdout separated by newlines.
> >
> > So perlcompat.attr could look something like
> >
> > ```
> > %__perlcompat_requires %{_rpmconfigdir}/perlcompat.req %{perl_version}
> >
> > # %%__perlcompat_path can stay the same.
> > ```
> >
> > These are usually stored in %%{_rpmconfigdir}. %%{perl_version} is
> > passed to the script as an argument, because the script of course
> > doesn't have access to the RPM context. This can be any executable
> > written in any language, but it should be straightforward to do this in
> > shell.
> >
> >
> > [1]:
> > https://rpm-software-management.github.io/rpm/manual/dependency_generators.html
> >
> > --
> > Maxwell G (@gotmax23)
> > Pronouns: He/Him/His
> > ___
> > epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> > To unsubscribe send an email to epel-devel-le...@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.org
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
>
> --
> Jitka Plesnikova
> Senior Software Engineer
> Red Hat
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@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.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
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-meet...@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=Open #topic Old Business (if needed) #topic General Issues / Open Floor Source: https://calendar.fedoraproject.org//meeting/9854/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
On Mon, 30 Jan 2023 21:13:11 -0700 Orion Poplawski 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. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL 8: %__python3 == /usr/bin/python3 creates runtime problems with alternatives
On 30. 01. 23 22:29, Miro Hrončok wrote: On 30. 01. 23 21:39, Miro Hrončok wrote: When it does change I plan to rebuild the package in EPEL 8. The following packages FTBFS: kwin It failed because it has an %if-%rhel-defined Patch :( Trying again from a patched spec. Done. Also needs a rebuild. The following packages still build after an hour and I need to remember to check them later: qt-creator Built, needs a rebuild as well. root Still in progress. Done. Also needs a rebuild. All the packages needed a rebuild. All PRs open (and some fo them already merged). A handful of packages uses rpmautospec and Pagure does not allow me to send an empty PR. I've emailed the maintainers. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Replace versioned MODULE_COMPAT_ requires by generators
Hi,
I added the package perl-generators-epel to EPEL 7/8/9. The package is
adding the behavior provided in perl-generators-1.16.
I created pull requests for epel-rpm-macros to add perl-generators-epel
to EPEL buildroot.
Pull Request
EPEL 7: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/61
EPEL 8: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/60
EPEL 9: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/59
Could anybody please merge them and build the packages or shall I do it
myself?
Thanks,
Jitka
On 12/6/22 04:40, Maxwell G via epel-devel wrote:
On Mon Dec 5, 2022 at 21:52 +0100, Jitka Plesnikova wrote:
Could be the following file added to the package epel-rpm-macros (or
anything like this) for EPEL 9?
It could, but it might be better to include this in a subpackage of
epel-rpm-macros or as a separate perl-generators-epel component. We
could pull it in with (package-name-here if perl-generators). This won't
work in EPEL 7 which unfortunately doesn't support rich dependencies.
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?
Parametric macro dependency generators are not supported in EPEL 7 and
8's RPM versions. You can still implement this using a "regular"
dependency generator. This is also described in the RPM
documentation[1]. Instead of specifying %__perlcompat_requires() and
writing an RPM macro that accepts a path name as %1, you specify
`%__percompat_requires /path/to/executable`. That script receives a
newline separated list of paths as stdin and prints the generated
dependencies to stdout separated by newlines.
So perlcompat.attr could look something like
```
%__perlcompat_requires %{_rpmconfigdir}/perlcompat.req %{perl_version}
# %%__perlcompat_path can stay the same.
```
These are usually stored in %%{_rpmconfigdir}. %%{perl_version} is
passed to the script as an argument, because the script of course
doesn't have access to the RPM context. This can be any executable
written in any language, but it should be straightforward to do this in
shell.
[1]:
https://rpm-software-management.github.io/rpm/manual/dependency_generators.html
--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
Jitka Plesnikova
Senior Software Engineer
Red Hat
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
