[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: Thoughts: epel-release auto-enable crb repo
On Tue, Jun 14, 2022 at 2:20 PM Josh Boyer wrote: > > Not fully sure I understand the results, but this looks promising. To clarify, the FINAL_EPEL.json files contain CRB packages as the keys and their arrays are packages from EPEL that depend on them. For for example: "poppler-qt5.x86_64": [ "kf5-kfilemetadata-0:5.90.0-1.el9.x86_64", "kile-0:2.9.93-7.el9.x86_64", "okular-part-0:21.04.2-2.el9.x86_64", "qpdfview-qt5-0:0.4.18-9.el9.x86_64" ], "poppler-qt5.x86_64" is the CRB package, and the contents are the EPEL packages that will either require/recommend/etc it at their install time. At least I'm pretty sure that's what "--whatdepends" means. -- Mike Rochefort ___ 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 Tue, Jun 14, 2022 at 2:20 PM Josh Boyer wrote: > > One thing I caught on initial glance, I think it's getting confused on > multilib. > > That seems to be highlighting that lutris.x86_64 depends on gvfs.i686. > I don't think that's actually the case, because gvfs.x86_64 is shipped > in AppStream and should satisfy the dependency for lutris.x86_64 in > EPEL. The multilib aspect is definitely the biggest quirk and I don't know the best approach besides just outright removing i686 CRB packages from the results. -- Mike Rochefort, RHCE Solution Architect Red Hat NA Commercial US Northeast - Boston On Tue, Jun 14, 2022 at 2:20 PM Josh Boyer wrote: > > On Tue, Jun 14, 2022 at 2:15 PM Mike Rochefort wrote: > > > > On Mon, Jun 13, 2022 at 4:18 PM Chris Adams wrote: > > > > > > Once upon a time, Josh Boyer said: > > > > If the dependency is only needed at build time, which is what CRB > > > > content is intended for > > > > > > If that's the intent, then it's not implemented correctly. For example, > > > there are well over 100 perl modules in CRB 9. They may only be used > > > _by Red Hat_ in building, but they are not exclusively build-time > > > packages by a long shot. > > > > If it helps, I've updated my CRB scanner and the results (hopefully > > it's accurate) for seeing what EPEL packages depend on CRB packages > > (via "dnf rq --whatdepends ") for both EL8 and EL9. These > > were run against RHEL 8 and 9 repositories with EPEL (so no EPEL > > Next). I don't believe it'll catch everything (such as things in > > epel-modular), but it could be a decent starting point for review. > > Would also be useful to know if this methodology is flawed and > > inaccurate. > > > > https://gitlab.com/omenos/crb-depends > > Not fully sure I understand the results, but this looks promising. > Thanks for providing it! > > One thing I caught on initial glance, I think it's getting confused on > multilib. For example, from: > https://gitlab.com/omenos/crb-depends/-/blob/main/el9/FINAL_EPEL.json > >"gvfs.i686": [ > "lutris-0:0.5.10.1-1.el9.x86_64" > ], > > That seems to be highlighting that lutris.x86_64 depends on gvfs.i686. > I don't think that's actually the case, because gvfs.x86_64 is shipped > in AppStream and should satisfy the dependency for lutris.x86_64 in > EPEL. > > josh > ___ > 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 -- Mike Rochefort, RHCE Solution Architect Red Hat NA Commercial US Northeast - Boston ___ 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 Tue, Jun 14, 2022 at 2:15 PM Mike Rochefort wrote: > > On Mon, Jun 13, 2022 at 4:18 PM Chris Adams wrote: > > > > Once upon a time, Josh Boyer said: > > > If the dependency is only needed at build time, which is what CRB > > > content is intended for > > > > If that's the intent, then it's not implemented correctly. For example, > > there are well over 100 perl modules in CRB 9. They may only be used > > _by Red Hat_ in building, but they are not exclusively build-time > > packages by a long shot. > > If it helps, I've updated my CRB scanner and the results (hopefully > it's accurate) for seeing what EPEL packages depend on CRB packages > (via "dnf rq --whatdepends ") for both EL8 and EL9. These > were run against RHEL 8 and 9 repositories with EPEL (so no EPEL > Next). I don't believe it'll catch everything (such as things in > epel-modular), but it could be a decent starting point for review. > Would also be useful to know if this methodology is flawed and > inaccurate. > > https://gitlab.com/omenos/crb-depends Not fully sure I understand the results, but this looks promising. Thanks for providing it! One thing I caught on initial glance, I think it's getting confused on multilib. For example, from: https://gitlab.com/omenos/crb-depends/-/blob/main/el9/FINAL_EPEL.json "gvfs.i686": [ "lutris-0:0.5.10.1-1.el9.x86_64" ], That seems to be highlighting that lutris.x86_64 depends on gvfs.i686. I don't think that's actually the case, because gvfs.x86_64 is shipped in AppStream and should satisfy the dependency for lutris.x86_64 in EPEL. josh ___ 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 Mon, Jun 13, 2022 at 4:18 PM Chris Adams wrote: > > Once upon a time, Josh Boyer said: > > If the dependency is only needed at build time, which is what CRB > > content is intended for > > If that's the intent, then it's not implemented correctly. For example, > there are well over 100 perl modules in CRB 9. They may only be used > _by Red Hat_ in building, but they are not exclusively build-time > packages by a long shot. If it helps, I've updated my CRB scanner and the results (hopefully it's accurate) for seeing what EPEL packages depend on CRB packages (via "dnf rq --whatdepends ") for both EL8 and EL9. These were run against RHEL 8 and 9 repositories with EPEL (so no EPEL Next). I don't believe it'll catch everything (such as things in epel-modular), but it could be a decent starting point for review. Would also be useful to know if this methodology is flawed and inaccurate. https://gitlab.com/omenos/crb-depends -- Mike Rochefort ___ 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] Stalled EPEL package: glances
Greetings, Are there any packagers who would like to package and maintain glances on EPEL9? https://bugzilla.redhat.com/show_bug.cgi?id=2088525 Alternatively, I am interested in doing so myself but will require some guidance. My only experience packaging RPMs is a relatively small one on COPR: https://copr.fedorainfracloud.org/coprs/blainester/tomb/ Thanks, Blaine ___ 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
