[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 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: Updating tox to 4 in EPEL 9
On Wed Dec 14, 2022 at 15:45 +0100, Miro Hrončok wrote: > Hello folks. > > A new major version of tox was released. The bump form version 3 to > version 4 > should be flawless to users but breaks all the plugins that have not > been > updated to the new API yet. > > I would like to avoid the need to maintain tox 3 in EPEL9 for many > years after > upstream abandoned it (they have no intention to do maintenance > releases for > tox 3.x). > > We are currently upgrading to tox 4 in Fedora Rawhide. When the dust > settles > I'd like to have the possibility to update it in EPEL too. > > One way to do it is to package a new tox4 component in EPEL 9 (and make > it > conflict with tox < 4) and keep the old tox around until it breaks (the > breakage might mean it no longer supports a newly added Python version > being > added to RHEL 9). > > Is that a sensible approach for EPEL? > There's no policy against compat packages in EPEL, so I see no problem with adding a tox4 component. We also have the EPEL Package Retirement policy[1] that allows you to retire packages as long as you announce it on the mailing list. BTW, we are currently discussing a slight change to this policy[2]. It'd be a good idea to decide on a retirement date in advanced for tox 3 and announce it on epel-announce. From there, you'd have to decide whether to completely retire the tox component and keep tox4 or to preform an Incompatible Update[3] of the tox package. This would require approval from the EPEL Steering Committee. Perhaps we can retire tox and have tox4 Provide tox but not Obsolete it. This way, existing users' setups won't be updated and potentially broken without explicit action, but new setups won't get unsupported content. You should open a ticket on the pagure.io/epel tracker once you have a concrete proposal. [1]: https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/ [2]: https://pagure.io/epel/pull-request/213 [3]: https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ -- 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
[EPEL-devel] Re: libssh2 epel vs rhel-8-for-x86_64-appstream-rpms
On Tue Dec 13, 2022 at 16:47 +0100, Leon Fauster via epel-devel wrote: Hi Leon, > I noticed that on a RHEL8 workstation the deprecated and removed package > from EL8.0 - libssh2, does not get substituted by the package from epel: > > libssh2-1.8.0-8.module+el8.0.0+4084+cceb9f44.1.x86_64 > vs > libssh2-1.9.0-5.el8.x86_64 > > only possible with > > yum update libssh2 --disablerepo=rhel-8-for-x86_64-appst* > > is this intentional? > > yum distrosync > > tries to install the obsolete version 1.8.0 again. > > How to solve this conflict? Its seems not to be a "module" problem > otherwise it would not install the epel version at all, right? Have you tried adding `module_hotfixes=true` [1] to the EPEL repo configuration file (/etc/yum.repos.d/epel.repo IIRC)? [1]: https://dnf.readthedocs.io/en/latest/modularity.html#hotfix-repositories -- 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
[EPEL-devel] Re: Replace versioned MODULE_COMPAT_ requires by generators
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
[EPEL-devel] Re: Fedora EPEL 9 request Compiz
Hi John, On Sun Nov 27, 2022 at 08:51 +, john tatt via epel-devel wrote: > Hi everyoneI'll like to have Compiz / Emerald available on RHEL/Rocky aso > > is there a chance for this to happen ? > Thank you Please follow the standard EPEL Package Request[1] procedure and let us know if you have any questions. [1]: https://docs.fedoraproject.org/en-US/epel/epel-package-request/ -- Best, 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
[EPEL-devel] Re: EPEL 10 proposal
On Wed Nov 23, 2022 at 00:52 CST, Carl George wrote: > I would also ask that feedback be provided there instead of as email > replies here on the list. I don't think there's been a formal discussion about moving EPEL discussions over to the forums. We already have communication split between the issue tracker and the ML, so I'm -1 to also adding the forums. In general, I find it easier to keep up with and participate in discussions on mailing lists than on forums. However, it seems to me that this is just for this one proposal, so I guess my comment is off topic. -- Best, 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
[EPEL-devel] Re: Should we retire weechat from EPEL 7?
On Thu Oct 6, 2022 at 19:11 +0200, Neal Gompa wrote: > The cmake3 package has all the macros from the mainline cmake package in > Fedora. > > It should be fully compatible, just swap %cmake_* for %cmake3_*. Oops, I responded before I saw this. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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: Should we retire weechat from EPEL 7?
On Thu Oct 6, 2022 at 12:02 CDT, Michel Alexandre Salim wrote: > I'm not sure either Paul or myself really care enough about EL7 to > maintain a divergent spec. The %cmake3* macros work everywhere. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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: Proposal: Dropping modules from EPEL-8. Not adding modules to EPEL-9
On Friday, September 9, 2022 Christopher Engelhard wrote: > I found it useful to ship the nextcloud package as a module, particularly in > EPEL, but if after multiple years there really are only 12 packages in the > repo and even those may or may not work then that is a pretty clear > argument for eating the sunk cost & abandoning the idea. Yes, the nextcloud modular packages that were in EPEL were uninstallable. Also, you could still include multiple versions of Nextcloud in EPEL. You'd just create separate non-modular nextcloud22, nextcloud23, etc. packages that Conflict with each other. -- Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ 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: Proposal: Dropping modules from EPEL-8. Not adding modules to EPEL-9
Sep 7, 2022 9:04:57 AM Petr Pisar : What we could do is write a notice about the end of life into the module summaries and rebuild the modules. That way users running "dnf module list" could see the message. But people upgrading after the module removal wouldn't see anything. We would have keep to modular repository available forever. Probably the idea of the notice is not worth of it. I think it's worth adding notices to the module descriptions. We could also add scriptlets to the old modular packages to print warnings if we really wanted. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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: EPEL: packaging multiple versions and compat packages
On Monday, September 5, 2022 Mark E. Fuller wrote: > Can someone point me to a good resource on how (if permitted) I can make > appropriate compat(?) packages to allow for two major versions of the > same package to be available? > Is this allowed for EPEL? You can package compat packages as long as they don't conflict with anything in RHEL. EPEL packages may conflict with other EPEL packages, however. -- Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ 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: EPEL2RHEL - New Wording? - New Workflow?
On Wednesday, August 31, 2022 Troy Dawson wrote: > 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. I think this whole process should be automated. File bugs that say "Heads up: your package will be automatically retired after the release of RHEL X.X" and provide some explanation. This will have multiple benefits: 1. Saying "you'll have to do something in six months, but it'll be bad if you do it now" is quite difficult to follow. 2. We can send out one announcement to epel-announce about which packages are going to be retired and when that'll happen, instead of retiring packages in a piecemeal manner. 3. The maintainers won't have to remember to do it. 4. If we find out that a package is buildroot only, then we'll close the bug and exclude it from the automatic retiring. -- Best, 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
[EPEL-devel] Re: Fwd: [Fedora-packaging] Need help: Building a package requiring python >= 3.7 on epel8
On Friday, August 26, 2022 Steve Cossette wrote: > Now, I decided to contribute further by building the package for epel8 and > epel9. I have been following the guide on > https://docs.fedoraproject.org/en-US/package-maintainers/Package_Maintenanc > e_Guide/, but did not know that doing so does not guarantee installation > will be successful (specially if some of the packages set as 'Requires' are > not available in the repos oops!) Yes, you need to check that packages are installable. At least, you can run `mock -r chroot_name_here --postinstall --source . --spec lutris.spec` or `fedpkg mockbuild --postinstall` to build the package in a mock chroot and ensures that it's actually installable. > Python38-devel installs fine, but 3 subpackages keep failing, mainly > python3.8(evdev), python3.8(pygobject) and python3.8(distro). Yes, those packages are probably not available for python38. If you want to support lutris on EPEL 8, you'd have to package up the dependencies. However, I'd recommend targeting python39 instead of python38. If you're interested in doing that, I'd be happy to provide some more pointers. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ 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: [Fedora-packaging] Need help: Building a package requiring python >= 3.7 on epel8
Looping in epel-devel -- Forwarded Message -- Subject: [Fedora-packaging] Need help: Building a package requiring python >= 3.7 on epel8 From: Steve Cossette To: packag...@lists.fedoraproject.org Good day to you all! I am still pretty much new at packaging, for fedora or, well, any distro to be frank. I applied to become a co-packager for the lutris package at the beginning of the year and was lucky enough to be co-sponsored and brought on board. Love packaging! Now, I decided to contribute further by building the package for epel8 and epel9. I have been following the guide on https://docs.fedoraproject.org/en-US/package-maintainers/Package_Maintenance_Guide/, but did not know that doing so does not guarantee installation will be successful (specially if some of the packages set as 'Requires' are not available in the repos oops!) So, with Lutris requiring python 3.7 or higher, I decided to go with 3.8. I've set the spec to use python3.8 (By using the "%global __python3 /usr/bin/python3.8" macro) and specified python3.8 packages as much as possible, as the default python for centos stream/epel8 is 3.6. Python38-devel installs fine, but 3 subpackages keep failing, mainly python3.8(evdev), python3.8(pygobject) and python3.8(distro). Distro should work with the python38-pip package (if pkgs.org is to be believed) but the other two seem to be a no-go on epel8. Before we drop that branch, I wanted to post here, to make sure I didn't miss anything. Thanks for your help! ___ packaging mailing list -- packag...@lists.fedoraproject.org To unsubscribe send an email to packaging-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/packag...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue - -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ 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: Adding Package to side-tag
n 22/08/27 04:03PM, Frank Crawford wrote: > While building two related new packages for EPEL9 with a chainbuild, > the second one failed, however, now I am trying to work out how to > specify the completed package in the build for the second package. > > I have tried creating a side-tag and add the completed build to the > side-tag, then building the second package in that side-tag, but it > still claims that it can't find the first package, which it requires to > build. Can you please provide more information? What are the builds/packages? What commands did you run? How did you add the first package to the side tag? Did you wait for the side tag repo to refresh before trying to build the second package? > do I have to wait until the first package gets pushed to the stable > before I can now build the second? No, that is not necessary. There are multiple ways to build against packages that have not yet reached stable. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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: Orphaning EPEL Branches
On Tuesday, August 23, 2022 7:49:15 PM CDT Neal Gompa wrote: > > * The Pagure API does not allow tagging existing issues. I had planned to > > liberally use tags to manage the issues. > > What? You can do this with the "update issue information" API call: > https://pagure.io/api/0/#issues-tab According to the documentation, the only valid inputs to "Update issue information" are "title" and "issue_content". https://pagure.io/pagure/issue/ 4761 was opened for this and never closed. Is there some undocumented parameter? -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ 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: Orphaning EPEL Branches
On Wednesday, August 10, 2022 4:07:29 PM CDT Troy Dawson wrote: > On Sun, Aug 7, 2022 at 12:31 PM Kevin Fenzi wrote: > > On Sat, Aug 06, 2022 at 10:05:40PM +0200, Maxwell G via epel-devel wrote: > > > We could create an issue tracker for this. Packagers would have to > > > submit a ticket requesting to orphan a certain package's EPEL branch(es) > > > and set the EPEL Bugzilla assignee to "orphan" if they're orphaning all > > > active EPEL branches. epel-devel@ could be CC'd on all issues. Then, we > > > could have a provenpackager in the SIG go through and manually retire > > > the packages that haven't been picked up after six weeks. The later will > > > be difficult if we have a large volume, but I don't expect that. We > > > could script this if necessary or just ask the submitter to do it > > > themself. > > > > > > This doesn't allow picking up packages in a self-service manner, but I > > > don't think that's a huge deal for our case. > > After some discussion in our weekly EPEL Steering Committee meeting > Maxwell's idea seems to lead the way. > Maxwell has setup of pagure repo, to track these orphan issues. > A pagure repo gives us the opportunity to have a nice README that people > can see if they are unsure of the process. > A pagure issue also seems more user friendly than a bugzilla. Both for the > person creating the issue, and for others tracking it. > > https://pagure.io/epel/package-orphan-requests So, I've started working on this. So far, I have a structured issue template, and I've started writing a tool to go through the issues and act on them (creating an announcement, etc. While I had originally wanted to use a Pagure issue tracker, I decided to switch to Gitlab half way through. There were three reasons: * The Pagure API does not allow tagging existing issues. I had planned to liberally use tags to manage the issues. * Gitlab already has a nice Python wrapper (python-gitlab), which is much easier to work with. * It's more future proof, as the state of Pagure in Fedora is a bit up in the air. I really appreciate Pagure, and I wanted to make it work, but I'm trying to be pragmatic. Currently, the plan for identity verification is to make sure the sure the user is a member of the Fedora group on Gitlab. For non-matching usernames, I should be able to provide a dedicated field for that and cross reference the custom username with the FAS Gitlab field. Does anybody know if it's possible to limit issue submissions to only Fedora members while keeping the issue tracker public? That would make this easier. I have one question: who should be able to orphan EPEL branches? In Fedora, it's only the main admin. Do we also want to open this up to people with other privileges? Currently, anybody with any type of write permissions on a repository can retire the package. If the actual people who maintain the EPEL branches don't have permissions to orphan EPEL branches, I worry it will make the policy ineffective. > The policy isn't setup yet, but we are moving in the right direction. Indeed :). -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ 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] Orphaning EPEL Branches
Hi EPEL folks, In the past couple EPEL SCo meetings, we have been discussing adding a new package retirement policy for EPEL packages. However, we have not found a satisfactory solution to the scenario where a packager no longer wishes to maintain their package in EPEL, but the package does not have unpatched CVEs, a dead upstream, or other reasons to warrant completely retiring it. In Fedora itself, there is a specific policy/procedure[1] for orphaning packages: > When Fedora maintainers do not want or are not able to maintain a > package any longer, they can orphan or retire the package. > In case the package is still useful for Fedora, it should be orphaned. > Then other maintainers that are interested in maintaining it, can take > ownership of this package. > Orphan packages will be retired if they remain orphaned for six weeks. I omitted the parts that are specific to the Fedora release cycle. Currently, EPEL packages can be retired from any EPEL branch at any time. However, it is currently impossible to independently orphan EPEL branches for the following reasons: 1. EPEL branches can't be orphaned separately. It's only possible to orphan the entire repository, which is not wanted in all cases. 2. Technically, it's possible to set the Bugzilla assignee for EPEL to "orphan" but that doesn't really accomplish anything. Currently with this approach: There is no way for packagers to pick up orphaned EPEL branches in a self-service fashion. There are no notifications when these packages are orphaned, so it's unlikely that anyone will pick them up. We'd also need to figure out how to handle retiring packages from EPEL that remain orphaned there for six weeks. This solution still doesn't solve the situation where e.g. a maintainer no longer wishes to maintain their package in epel7 but wants to maintain it in epel9. What do y'all think about this issue? How do you think we should address it? Keep in mind that orphaning a package basically amounts to delayed retirement, unless someone picks it up. Here are my thoughts: If an entire Fedora package that has (an) EPEL branch(es) is orphaned, the EPEL branch(es) should probably be orphaned at the same time as the rawhide branch. Otherwise, we'd have to treat only orphaning an EPEL branch as a special case: We could create an issue tracker for this. Packagers would have to submit a ticket requesting to orphan a certain package's EPEL branch(es) and set the EPEL Bugzilla assignee to "orphan" if they're orphaning all active EPEL branches. epel-devel@ could be CC'd on all issues. Then, we could have a provenpackager in the SIG go through and manually retire the packages that haven't been picked up after six weeks. The later will be difficult if we have a large volume, but I don't expect that. We could script this if necessary or just ask the submitter to do it themself. This doesn't allow picking up packages in a self-service manner, but I don't think that's a huge deal for our case. [1]: https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/#_orphaning_and_retiring_packages -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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: EPEL 8: All Python 3.8 and 3.9 packages provide python3dist(...)
On 22/07/19 07:00PM, Miro Hrončok wrote: > apparently, all EPEL 8 Python 3.8 and 3.9 packages that should only provide > python3.8dist(...)/python3.9dist(...) also provide python3dist(...). > > That means, any Python 3.6 package that BuildRequires python3dist(...) might > get a Python 3.8/3.9 package instead. > > This has been fixed via > https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/47 (and > accidentally pushed without epel-rpm-macros maintainers ack). > > I propose that we ship the fix and rebuild all affected packages. We discussed this issue in the EPEL SCo meeting, and I volunteered to handle it. I built the fixed epel-rpm-macros and submitted a Bodhi update[0] and a buildroot override. I also rebuilt the affected packages and submitted [1]. I would appreciate testing and karma! [0]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-5e2dae8961 [1]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-781937ed73 Out of all of the packages, only python38-itsdangerous-epel FTBFS, and I filed [2] for that one. [2]: https://bugzilla.redhat.com/show_bug.cgi?id=2109363 -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] EPEL Steering Committee Meeting
Hi everyone, The weekly EPEL Steering Committee meeting is scheduled for today at 20:00 UTC (4:00 p.m. EDT for those in the U.S.). It will take place in #fedora-meeting on Libera.chat and bridged to #meeting:fedoraproject.org on Matrix. Hope to see you all there! -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: EPEL 8: All Python 3.8 and 3.9 packages provide python3dist(...)
On 22/07/19 07:00PM, Miro Hrončok wrote:
> I propose that we ship the fix and rebuild all affected packages.
I agree. This issue has the potential to result in confusing, hard to
debug issues for packagers (mainly) but also users.
> + new packages that have not yet reached the either EPEL 8 repo
I checked Bodhi and there are no python38-* or python39-* packages in
epel8{,-next} pending or in testing.
> + probably the same query in EPEL 8 next, but I miss a repo file for it ATM
sudo dnf repoquery --repo=epel-next{,-testing} --whatprovides
'python3.8dist(*)' --whatprovides 'python3.9dist(*)' --qf='%{source_name}'
--latest-limit 1
ansible
ansible is in both epel8 and epel8-next, as there's a newer version in
epel8-next to correspond to the newer ansible-core in c8s. To whoever
ends up rebuilding the packages: please let me to handle that package. I
have an update for it in testing that needs to be synced with some
upcoming updates in c8s in order to avoid an FTI, and I don't want the
karma to be reset.
I'm already handling the go rebuild, but I wouldn't mind handling this
one as well.
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
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 on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
On Friday, June 17, 2022 9:03:07 AM CDT Patrick Riehecky via epel-devel wrote: > This way any extra ideas for actions can be added easily later on. > Perhaps a "check" or "status" to see if CRB is enabled/disabled/not- > what-the-os-ships. +1. Having some logic to check if CRB is actually enabled would allow us to create a scriptlet for epel-release to print a warning instructing users to run `crb enable` if necessary. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Stalled EPEL package: glances
On Tuesday, June 14, 2022 5:26:11 PM CDT Richard Shaw wrote: > I think the non-response maintainer process should be started. It seems that someone has already done just that: https://pagure.io/fesco/issue/2808 -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Intent to retire containerd in EPEL 7 and co-maintainer request
On Thursday, June 9, 2022 5:55:34 PM CDT Stewart Smith wrote: > Unfortunately I don't think we can [help with EPEL 7] given the > likely packaging differences I'd be surprised if there's major differences, unless AL 2 backports newer go macros. > the containerd version differences containerd in EPEL 7 actually *needs to* be updated to fix the CVEs. That would be one of the first jobs of the theoretical new EPEL 7 maintainer. > that we don't have infinite time and given a choice between EPEL7 work > and jumping into modern Fedora packaging to enhance both Fedora and our > Amazon Linux 2022 efforts, I'd pick the latter. As I said, that would also be appreciated. >> Additionally, I would appreciate co-maintainers to help with the Fedora >> branches of containerd, its unbundled go dependencies, and moby-engine >> (bundled go package). Long term, I'm not sure I'll have the time or the >> interest to maintain these packages. Note that on EPEL 7, containerd >> bundles its dependencies; moby-engine is not packaged there. > > This is 100% somewhere that Amazon Linux can step in and help with. We > have a continued interest in the containerd ecosystem working in Fedora > like distros (namely Amazon Linux), and the bundled/not-bundled split > existing in some working bconds is certainly in our interest (we're > likely to continue to bundle dependencies for the forseeable future). Currently, moby-engine (equivalent to docker-ce) already uses bundled dependencies. containerd on Fedora uses unbundled dependencies, which does create more work, but doing so is recommended by our packaging guidelines where it's feasible. It shouldn't be too difficult/messy to add bundling bconds, as long as we stick to the version of go-rpm-macros in Fedora and EL 9. It starts getting messier (repeated code and lots of conditionals) when you maintain unbundled Fedora and EPEL 7-8 compatibility in the same specfile. On a related note, I recently learned that it's possible to include snippets from other files in specfiles using the %include macro. This way, you can easily create a script to update virtual provides for bundled go packages without having to copy/paste text into the specfile. This also keeps your specfile cleaner. If anyone is interested, feel free to look at moby-engine for an example. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Intent to retire containerd in EPEL 7 and co-maintainer request
Hi everyone, I have been de-facto maintaining containerd in Fedora as a member of the go- sig for a little while now, as the previous maintainer no longer has time to do. In addition to the Fedora branches, this package also exists on EPEL 7. That branch has not been maintained for a while and has unpatched CVEs. I am not interested in maintaining it myself, so unless someone steps up to maintain it and fix the vulnerabilities, I will retire the package from EPEL 7 in a week from today, on June 15th. Additionally, I would appreciate co-maintainers to help with the Fedora branches of containerd, its unbundled go dependencies, and moby-engine (bundled go package). Long term, I'm not sure I'll have the time or the interest to maintain these packages. Note that on EPEL 7, containerd bundles its dependencies; moby-engine is not packaged there. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
On Wednesday, June 8, 2022 2:54:51 PM CDT Michel Alexandre Salim wrote: > without messing with config files (which I > hate, because that means newer crb.repo changes won't be picked up). I thought files marked `%config(noreplace)` don't get updated automatically even if the user didn't modify it all. Am I missing something or are we talking about different things? -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: EPEL8: New Ansible and (native) python modules
Jun 7, 2022 12:09:15 AM Igor Raits : > The new ansible (5.x) is in the EPEL stable which works great until > one tries to use some non-trivial modules which require some Python > modules to be available… At that point you realize that the new > Ansible is built against Python 3.8 (default is 3.6) and we don't have > many python38-* packages (almost none). Take a look at https://bugzilla.redhat.com/show_bug.cgi?id=2093589#c1 . Only libraries required by controller plugins (e.g. python38-jmespath[1] for the json_query filter plugin) need to packaged for python38. Modules are *supposed* to use the system python interpreter (/usr/libexec/platform-python). [1]: https://src.fedoraproject.org/rpms/python38-jmespath/tree/epel8 > The question is: What is the recommendation on how to get those >modules available in EPEL8? Do we want to go with > python3_other_pkgversion (which is not defined now) and build all > packages with python36/python38 both available or is there a plan to > switch default Python in EL8 to 3.8? This was discussed here: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/CECLJH3QPXWNZGNTG3KIQHFZB4WFVOAN/ #S57EJSNCP6YOY7QXGGI4NATDR2FKQZWO -- Maxwell G Pronouns: He/Him/His gotmax@e.email signature.asc Description: This is a digitally signed message part. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
Jun 4, 2022 4:01:42 PM Troy Dawson : > 3 - We are taking the choice away from users > After I stopped and thought about it, there are plenty of scenarios where > people want epel for just one or two packages, which do not require crb. > > 4 - All the many small side cases. > auto-enabling crb will have bugs. RHEL and it's clones are in too many odd > places for us to not hit some odd use cases we didn't expect. We'd have to > keep fixing the scripts. I will just add that both of these issues can be remedied. For my part, I have suggested edits on Troy's epel-release PR[1] to allow an opt-out mechanism and make the script more robust. Users who are knowledgeable enough to check whether the packages they use need CRB should also be able to opt out. I think the real question is whether epel-release should be touching subscriptions/repos it doesn't own in the first place (Troy's question #2). Another option would be to have the %post script only print a warning if CRB/Powertools isn't enabled instead of actually enabling it. This won't help with automated deployments[2], but it should catch some cases. [1]: https://src.fedoraproject.org/rpms/epel-release/pull-request/21 [2]: With my ansible hat on, it also doesn't help that the two most popular epel roles on Ansible Galaxy don't enable CRB/Powertools, but I disgress. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-passlib for python38 module
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
signature.asc
Description: This is a digitally signed message part.
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-passlib for python38 module
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
signature.asc
Description: This is a digitally signed message part.
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: SPDX identifiers in old branches?
On Tuesday, May 24, 2022 7:08:13 PM CDT Gary Buhrmaster wrote: > I don't think that is going to work unless the rpm spec > file support would be backported to previous releases > (without another macro that tries to do some magic). I don't follow. What "rpm spec file support" are you referring to? > And the goal for some of us is to have one spec file > work across all currently supported releases. I agree; divergent dist-git branches are a nuisance. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: SPDX identifiers in old branches?
On Tuesday, May 24, 2022 3:11:39 PM CDT Miroslav Suchý wrote: > We see no reason why not to do that. It should not cause any harm. If **you** know of any reason we should not propose > this, please tell us now. I already brought this up previously, but how will we handle license identifiers such as MIT that are valid in both SPDX and Fedora but have different meanings? We won't know whether it's specifically referring to the MIT/Expat License (SPDX) or a group of MIT-like licenses (Fedora) and we won't be able to tell which specfiles have been converted to use SPDX identifiers and which haven't. From the Change Proposal: > * Convert license string to SPDX formula: > $ license-fedora2spdx 'MIT or GPLv1' > > Warning: more options how to interpret MIT. Possible options: > ['Adobe-Glyph', 'MIT-CMU', 'MIT-CMU', 'HPND', 'HPND', 'no-spdx-yet > (MIT license (also X11))', 'SGI-B-2.0', 'SGI-B-2.0', 'SMLNJ', > 'MIT-enna', 'MIT-feh', 'mpich2'] > > mpich2 or GPL-1.0-only -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-passlib for python38 module
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.
> == 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 ==
>
>
[...]
> %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
signature.asc
Description: This is a digitally signed message part.
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Fwd: Re: retirement of ansible-2.9.x
May 16, 2022 8:32:58 PM Maxwell G : On Tuesday, April 19, 2022 3:14:56 PM CDT Kevin Fenzi wrote: > In epel8 I will be converting the 'ansible' epel8 package into the > upstream ansible-5 meta collections package (which also pulls in > ansible-core). > Hi everyone, I have rebased ansible to ansible 5 in epel8 and submitted a Bodhi update[1]. I would appreciate if you could help test the update and provide feedback. We are also providing a newer version of ansible 5 in epel8-next that depends on the newer version of ansible-core available in CentOS 8 Stream. Here[2] is the Bodhi update for the epel8-next version. [1]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-67f52f0700 [2]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2022-7083a5c511 I also branched ansible for epel9 and epel9-next. Here[3,4] are the Bodhi updates for that. [4]:https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-73e215eb5c [5]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2022-3090b856c2 Remember that ansible 5 is just a bundle of ansible collections that are released together, and it depends on ansible-core (the engine) which provides the core modules, engine, and command line tools. This provides the "batteries-included" approach that users of ansible classic (ansible 2.9.x and below) are used to. If you prefer a more minimalist approach, you can install ansible-core alongside the specific collections you need. You can install collections through EPEL's ansible-collection-* RPM packages or from Ansible Galaxy. If you would like to do this, you can switch to ansible-core with `dnf swap ansible ansible-core`. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-passlib for python38 module
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 signature.asc Description: This is a digitally signed message part. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-passlib for python38 module
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.spec > > 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 signature.asc Description: This is a digitally signed message part. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-passlib for python38 module
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 signature.asc Description: This is a digitally signed message part. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: retirement of ansible-2.9.x
On Tuesday, April 19, 2022 3:14:56 PM CDT wrote: > In epel8 I will be converting the 'ansible' epel8 package into the > upstream ansible-5 meta collections package (which also pulls in > ansible-core). > Hi everyone, I have rebased ansible to ansible 5 in epel8 and submitted a Bodhi update[1]. I would appreciate if you could help test the update and provide feedback. We are also providing a newer version of ansible 5 in epel8-next that depends on the newer version of ansible-core available in CentOS 8 Stream. Here[2] is the Bodhi update for the epel8-next version. [1]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-67f52f0700 [2]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2022-7083a5c511 I also branched ansible for epel9 and epel9-next. Here[3,4] are the Bodhi updates for that. [4]:https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-73e215eb5c [5]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2022-3090b856c2 Remember that ansible 5 is just a bundle of ansible collections that are released together, and it depends on ansible-core (the engine) which provides the core modules, engine, and command line tools. This provides the "batteries-included" approach that users of ansible classic (ansible 2.9.x and below) are used to. If you prefer a more minimalist approach, you can install ansible-core alongside the specific collections you need. You can install collections through EPEL's ansible-collection-* RPM packages or from Ansible Galaxy. If you would like to do this, you can switch to ansible-core with `dnf swap ansible ansible-core`. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
