[EPEL-devel] Re: EPEL 10 status update
On Fri, Sep 6, 2024 at 5:32 PM Andrew Bauer wrote: > > Thanks for the heads up. I received a few epel 10 branch and build requests > this week and took that to mean I should build all my packages for epel 10. Not necessarily, as you can see from the beginning of this thread. I would describe the current state as a "soft launch" period, intended to give packagers more time to get their packages ready. That is resulting in lots of branch and build requests as packagers re-discover their dependency chains and the packages they don't have access to do themselves. It's considerate to other packagers to act fairly quickly on those requests to unblock the packages that depend on them. For packages you haven't gotten requests for, it's perfectly fine to take your time. It may even be wise to do some in some cases if the upstream is releasing a new version soon that wouldn't be allowed as an update in EPEL. > > I got several built, when I started seeing "Could not execute build: Unknown > build target: epel10-candidate"... from your last message, it looks like this > is by design. I apologize for the extra packages that are now in epel 10. > I'll check back here for the green light to proceed again. No need to apologize. The build targets have been restored, so feel free to build away (if you want to). > -- > ___ > 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 -- Carl George -- ___ 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 status update
On Fri, Sep 6, 2024 at 4:11 PM Carl George wrote: > > On Thu, Jul 4, 2024 at 2:45 AM Carl George wrote: > > > > I originally posted this on Fedora Discussion [0], but I'm sharing it > > here as well for awareness. > > > > # Executive summary > > > > EPEL 10 is expected to be launched in Q4 of 2024. You may start > > noticing parts of the infrastructure coming online sooner than that. > > **Please do not start creating EPEL 10 builds until we announce that > > we are ready for packagers to start building.** > > > > # Detailed description > > > > The EPEL Steering Committee has big plans for EPEL 10. These plans > > are covered in detail in the original EPEL 10 proposal [1]. I also > > presented an EPEL 10 overview at the Fedora 40 release party [2]. At > > a high level, we are bringing minor versions to EPEL. I encourage you > > to read the proposal or watch that video for a deeper explanation. > > > > I'm writing this post to share our planned timeline for EPEL 10, and > > to set expectations for the coming months. Early CentOS Stream 10 > > composes are already available [3], but it hasn't been officially > > launched yet because the content set is still in flux. We expect to > > see the official launch announcement for CentOS Stream 10 later this > > year. We intend to align the EPEL 10 launch with that, which will > > give us the following approximate timeline. > > > > - August 2024: EPEL 10 hackfest at Flock [4] (see below for more details) > > - Q4 2024: expected launch of CentOS Stream 10 and EPEL 10 > > - Q2 2025: expected launch of RHEL 10 (three years after RHEL 9) > > > > In the months ahead, you may notice parts of EPEL 10 infrastructure > > coming online, such as build targets in Koji and releases in Bodhi. > > We will need these infrastructure pieces in place to work out all of > > the details of integrating minor versions. We'll send out an > > announcement when EPEL 10 is ready for package maintainers to start > > creating their builds. **Please do not start creating EPEL 10 builds > > until we announce that we are ready for packagers to start building.** > > Any builds created before this announcement may need to be discarded > > and rebuilt. > > > > I will be running an EPEL 10 Hackfest at Flock [4] in August (next > > month). The plan is to work on various infrastructure pieces related > > to EPEL 10. If we happen to have most of these pieces working prior > > to the hackfest, we can pivot our time to adding initial packages to > > EPEL 10. I hope to see you there! > > > > [0] https://discussion.fedoraproject.org/t/epel-10-status-update/124549 > > [1] https://discussion.fedoraproject.org/t/epel-10-proposal/44304 > > [2] https://youtu.be/PxWxK5PgUuE > > [3] > > https://lists.centos.org/hyperkitty/list/de...@lists.centos.org/thread/QCO73CKFMPNMERUWIQ47OVJMMUM7YUXU/ > > [4] https://flocktofedora.org/ > > > > -- > > Carl George > > Quick note for anyone watching this thread, please keep in mind that > some pieces of the infrastructure will continue to be in flux until > the official launch. For example, our plan was to turn on automatic > bodhi updates until the official launch. That worked for a little > while and builds were created and moved to stable, but then that > stopped working once we tried to enable a bodhi compose. We've > implemented a separate compose outside of bodhi, but we need to > temporarily disable new epel10 builds and revert it to finish > processing builds that are still in "pending->testing" and > "pending->stable" states. I'll post here again once the builds can > resume. > > -- > Carl George We were able to get all of the in-between builds processed, and have re-enabled the new compose method. We've also re-enabled the build targets, and verified that a new build got an automatic update that moved to stable automatically, just like rawhide. Builds that are marked stable should be available in the buildroot as soon as the regen-repo task finishes, and then composed nightly. This pipeline should stay the same until the official EPEL 10 launch in Q4. That's when we'll switch to the standard EPEL pipeline, with manually created updates, a default one week testing period, and bodhi composes. Packagers can resume building for epel10 at their leisure. Let us know if anything doesn't seem to be working as expected. -- Carl George -- ___ 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 status update
On Thu, Jul 4, 2024 at 2:45 AM Carl George wrote: > > I originally posted this on Fedora Discussion [0], but I'm sharing it > here as well for awareness. > > # Executive summary > > EPEL 10 is expected to be launched in Q4 of 2024. You may start > noticing parts of the infrastructure coming online sooner than that. > **Please do not start creating EPEL 10 builds until we announce that > we are ready for packagers to start building.** > > # Detailed description > > The EPEL Steering Committee has big plans for EPEL 10. These plans > are covered in detail in the original EPEL 10 proposal [1]. I also > presented an EPEL 10 overview at the Fedora 40 release party [2]. At > a high level, we are bringing minor versions to EPEL. I encourage you > to read the proposal or watch that video for a deeper explanation. > > I'm writing this post to share our planned timeline for EPEL 10, and > to set expectations for the coming months. Early CentOS Stream 10 > composes are already available [3], but it hasn't been officially > launched yet because the content set is still in flux. We expect to > see the official launch announcement for CentOS Stream 10 later this > year. We intend to align the EPEL 10 launch with that, which will > give us the following approximate timeline. > > - August 2024: EPEL 10 hackfest at Flock [4] (see below for more details) > - Q4 2024: expected launch of CentOS Stream 10 and EPEL 10 > - Q2 2025: expected launch of RHEL 10 (three years after RHEL 9) > > In the months ahead, you may notice parts of EPEL 10 infrastructure > coming online, such as build targets in Koji and releases in Bodhi. > We will need these infrastructure pieces in place to work out all of > the details of integrating minor versions. We'll send out an > announcement when EPEL 10 is ready for package maintainers to start > creating their builds. **Please do not start creating EPEL 10 builds > until we announce that we are ready for packagers to start building.** > Any builds created before this announcement may need to be discarded > and rebuilt. > > I will be running an EPEL 10 Hackfest at Flock [4] in August (next > month). The plan is to work on various infrastructure pieces related > to EPEL 10. If we happen to have most of these pieces working prior > to the hackfest, we can pivot our time to adding initial packages to > EPEL 10. I hope to see you there! > > [0] https://discussion.fedoraproject.org/t/epel-10-status-update/124549 > [1] https://discussion.fedoraproject.org/t/epel-10-proposal/44304 > [2] https://youtu.be/PxWxK5PgUuE > [3] > https://lists.centos.org/hyperkitty/list/de...@lists.centos.org/thread/QCO73CKFMPNMERUWIQ47OVJMMUM7YUXU/ > [4] https://flocktofedora.org/ > > -- > Carl George Quick note for anyone watching this thread, please keep in mind that some pieces of the infrastructure will continue to be in flux until the official launch. For example, our plan was to turn on automatic bodhi updates until the official launch. That worked for a little while and builds were created and moved to stable, but then that stopped working once we tried to enable a bodhi compose. We've implemented a separate compose outside of bodhi, but we need to temporarily disable new epel10 builds and revert it to finish processing builds that are still in "pending->testing" and "pending->stable" states. I'll post here again once the builds can resume. -- Carl George -- ___ 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: arch-specific package in CS10 blocking EPEL 10 request
On Wed, Sep 4, 2024 at 8:45 AM Troy Dawson wrote: > > On Wed, Sep 4, 2024 at 3:46 AM Petr Pisar wrote: >> >> V Wed, Sep 04, 2024 at 09:15:23AM +0100, Paul Howarth napsal(a): >> > I got a request to build rgb for EPEL 10 >> > (https://bugzilla.redhat.com/show_bug.cgi?id=2309102), which is not >> > surprising as I did the same for EPEL 9. A local test build of that package >> > failed due to a missing dependency of 'pkgconfig(xorg-macros)', so >> > I requested an EPEL 10 build of xorg-x11-util-macros to resolve that >> > (https://bugzilla.redhat.com/show_bug.cgi?id=2309121). >> > >> > That package request was then declined: >> > >> > fedpkg request-branch epel10 >> > Could not execute request_branch: This package is already an EL >> > package, therefore it cannot be in EPEL. If this is a mistake >> > >> > Looking at the compose metadata, it appears that xorg-x11-util-macros >> > is in CRB, but only for the aarch64 architecture. >> > >> > So, my questions are: >> > 1. Is this intentional (seems unlikely, given that this is fundamental >> > to building just about anything using xorg-x11), and >> >> EPEL can barely answer this. You should open a ticket for CentOS Stream at >> <https://issues.redhat.com/> against "RHEL" project and >> "xorg-x11-util-macros" >> component. > > > Looks like xorg-x11-util-macros on aarch64 was missed back in July when it > was taken out. > I have opened a merge request to get it out of that final arch. > https://gitlab.com/redhat/centos-stream/release-engineering/pungi-centos/-/merge_requests/798 > That will take a week or so to process and be fully out of CentOS Stream 10. > > Troy > > -- > ___ > 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 In an interesting twist, it looks like xorg-x11-util-macros is going to be included in CentOS/RHEL 10 after all. https://bugzilla.redhat.com/show_bug.cgi?id=2309121#c10 https://issues.redhat.com/browse/RHEL-57593 -- Carl George -- ___ 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 status update
On Tue, Sep 3, 2024 at 1:16 PM Leon Fauster via epel-devel wrote: > > Am 03.09.24 um 18:00 schrieb Troy Dawson: > > On Sun, Sep 1, 2024 at 3:03 PM Gary Buhrmaster > > mailto:gary.buhrmas...@gmail.com>> wrote: > > > > On Sat, Aug 10, 2024 at 10:42 PM Carl George > <mailto:c...@redhat.com>> wrote: > > > > > > > > Happy packaging! > > > > > > > I have noted that some dependencies for some > > of my packages are (apparently) no longer > > going to be shipped in EL10 (they were in > > EL9). > > > > Before I request the branches and builds > > in EPEL10, I would like to make sure those > > packages are really removed from EL10, and > > are not some artifact of my misunderstandings. > > > > Is there a list somewhere of packages that > > are known to have been removed from EL10? > > > > > > Three things I do. > > 1 - Go to the CentOS Stream koji instance, look up the package, look at > > the latest el10 build of that package, and see if it's tags have been > > removed, or it has a trashcan tag. > > Examples: > > bash (still there) - > > https://kojihub.stream.centos.org/koji/buildinfo?buildID=62779 > > <https://kojihub.stream.centos.org/koji/buildinfo?buildID=62779> > > java-17-openjdk (removed) - > > https://kojihub.stream.centos.org/koji/buildinfo?buildID=66493 > > <https://kojihub.stream.centos.org/koji/buildinfo?buildID=66493> > > > > 2 - dnf list > > This isn't the best. Sometimes a package is still in the process of > > being removed. Or it's been untagged, but we haven't had a successful > > compose pushed out. > > But, it's still a quick way to check. > > > > 3 - jira search > > The CentOS Stream 10 package removals are public in jira. We have a tag > > for centos-stream-10 package removals. > > This isn't 100% accurate, because sometimes the package has been > > re-added, but that is rare. > > https://issues.redhat.com/browse/CS-2504?jql=labels%20%3D%20rhel-10-beta-package-removal > > > > <https://issues.redhat.com/browse/CS-2504?jql=labels%20%3D%20rhel-10-beta-package-removal> > > > > > I wonder if RHEL10 will have a Workstation flavor? Or if CS10 will be > usable as Workstation OS. When I see all the missing/removed parts. > Can not imagine that EPEL can compensate this all (e.g. is firefox in > the compose?). > > > -- > Leon > > > > > > -- > ___ > 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 Why can't EPEL compensate for this? If RHEL doesn't ship it, then it's probably eligible to be shipped in EPEL. Several desktop apps such as firefox were dropped, but all it takes is someone willing to maintain them in EPEL 10. If there is a package you rely on that was dropped, then become a packager and file a bug asking the Fedora maintainer to add you as a co-maintainer. https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/ https://docs.fedoraproject.org/en-US/epel/epel-package-request/#fedora_packagers -- Carl George -- ___ 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 status update
On Tue, Sep 3, 2024 at 11:01 AM Troy Dawson wrote: > > On Sun, Sep 1, 2024 at 3:03 PM Gary Buhrmaster > wrote: >> >> On Sat, Aug 10, 2024 at 10:42 PM Carl George wrote: >> >> > >> > Happy packaging! >> > >> >> I have noted that some dependencies for some >> of my packages are (apparently) no longer >> going to be shipped in EL10 (they were in >> EL9). >> >> Before I request the branches and builds >> in EPEL10, I would like to make sure those >> packages are really removed from EL10, and >> are not some artifact of my misunderstandings. >> >> Is there a list somewhere of packages that >> are known to have been removed from EL10? > > > Three things I do. > 1 - Go to the CentOS Stream koji instance, look up the package, look at the > latest el10 build of that package, and see if it's tags have been removed, or > it has a trashcan tag. > Examples: > bash (still there) - > https://kojihub.stream.centos.org/koji/buildinfo?buildID=62779 > java-17-openjdk (removed) - > https://kojihub.stream.centos.org/koji/buildinfo?buildID=66493 > > 2 - dnf list > This isn't the best. Sometimes a package is still in the process of being > removed. Or it's been untagged, but we haven't had a successful compose > pushed out. > But, it's still a quick way to check. > > 3 - jira search > The CentOS Stream 10 package removals are public in jira. We have a tag for > centos-stream-10 package removals. > This isn't 100% accurate, because sometimes the package has been re-added, > but that is rare. > https://issues.redhat.com/browse/CS-2504?jql=labels%20%3D%20rhel-10-beta-package-removal > > I hope this helps. > Troy > -- > ___ > 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 One extra note I'll add, you don't have to necessarily check this manually yourself. When you run `fedpkg request-branch epel10`, it will check the CentOS Stream 10 compose metadata, and it will refuse to proceed if the source package you're asking for a branch in is in that metadata. If that check passes, fedpkg creates the SCM request ticket, and the toddler that processes that ticket does the same compose metadata check again before creating the branch. So basically, if your branch request goes through, you're good. -- Carl George -- ___ 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 status update
On Tue, Aug 13, 2024 at 3:15 PM Orion Poplawski wrote: > > On 8/10/24 16:41, Carl George wrote: > > What has not been completed yet: > > > > - publish the epel/10 repo > > Do we have an ETA for an EPEL10 compose (if only in koji)? Thanks! > > -- > Orion Poplawski > he/him/his - surely the least important thing about me > Manager of IT Systems 720-772-5637 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane or...@nwra.com > Boulder, CO 80301 https://www.nwra.com/ > > -- > ___ > 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 The last few days folks have been travelling home from Flock, and today releng was quite busy with F41 branching so I didn't want to bother them. I'm hoping to work with them to get it done later this week or next week. -- Carl George -- ___ 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 status update
On Tue, Aug 13, 2024 at 10:17 AM Gary Buhrmaster wrote: > > On Tue, Aug 13, 2024 at 9:12 AM Stephen Smoogen wrote: > > > This is something I wanted to do in previous EPEL splits, but it has > > usually gotten too many complaints from packagers to consider. Many > > packagers don't want their packages in EPEL at all but will do so if there > > are requests from someone or that there is going to be a branch packager > > for EPEL packages. Many EPEL branch packagers really only want to support > > one release because that is what they are using versus multiple ones. > > There is also the case (I had one), where a package > (in epel8) was later incorporated by RH into EL9, for > which automatic branch requests might have been an > issue (unless the automatic approval processes already > checks for that and rejects the branch request). When you request a branch this is actually verified twice. fedpkg checks the CentOS Stream compose metadata before filing the issue and it should reject the request (not even creating the issue) if the package already exists in that metadata (because that means it's already in RHEL, or on the way to RHEL soon). If somehow the issue gets filed anyways, the SCM toddler does the same check before creating the branch. If we were to automate things further, we'll definitely need to build a similar check into that process. > > > That said, I think it is something to revisit like we did for EL7, EL8 and > > EL9 :). > > Personally, automatic branching would work fine > for me, but often my bigger issue is opening the > bugzilla tickets for the often large dependency > chain for some scripting languages asking for > each package to be actually built, and then > waiting for the packager to have the resources > to build them. If one starts with the premise that > the packagers should control the creation of all > branches then auto-creating all those dependency > branch/build bugzillas (and *their* dependency > branch/build bugzillas, and so on) might be a > better step forward to reduce the process delays. > -- > ___ > 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 -- Carl George -- ___ 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 status update
On Tue, Aug 13, 2024 at 4:12 AM Stephen Smoogen wrote: > > > > On Mon, 12 Aug 2024 at 17:44, Miroslav Suchý wrote: >> >> Dne 11. 08. 24 v 12:41 dop. Carl George napsal(a): >> >> - creating epel10 branches (`fedpkg request-branch epel10`) >> >> Can be the branch automatically created for all packages that has epel9 >> branch? I am not looking forward to request dozens of branches for all my >> packages. >> >> > > This is something I wanted to do in previous EPEL splits, but it has usually > gotten too many complaints from packagers to consider. Many packagers don't > want their packages in EPEL at all but will do so if there are requests from > someone or that there is going to be a branch packager for EPEL packages. > Many EPEL branch packagers really only want to support one release because > that is what they are using versus multiple ones. > > That said, I think it is something to revisit like we did for EL7, EL8 and > EL9 :). > > -- > Stephen Smoogen, Red Hat Automotive > Let us be kind to one another, for most of us are fighting a hard battle. -- > Ian MacClaren > -- > ___ > 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 Beyond just revisiting it, we need someone to step up to figure out the implementation and policy work. There was some discussion in the EPEL Steering Committee meetings about doing it for EPEL 10 based on ELN Extras workloads in Content Resolver, but that idea lost steam around the time the branch requests became automated with a toddler. Now for packages you're the maintainer of, getting the branch is one additional command that results in the branch being ready within minutes. Is it even worth automating this further? For packages you're not a maintainer of, is it even appropriate for us to automate the process and not rely on maintainer opt-in like we do now? -- Carl George -- ___ 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 status update
On Tue, Aug 13, 2024 at 1:47 AM Mattia Verga via epel-devel wrote: > > Jonathan Wright wrote: > > This is (unfortunately) expected. Since epel 10 is currently being treated > > like rawhide where bodhi updates are automatic, it will cite any bugs > > listed in the change log in the bodhi update as well this generating the > > emails. > > You can disable that behavior by adding the release to the exclusion list at > https://pagure.io/fedora-infra/ansible/blob/main/f/roles/bodhi2/base/templates/production.ini.j2#_509 > -- > ___ > 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 Thanks for the tip, I think it's a great idea. https://pagure.io/fedora-infra/ansible/pull-request/2206 We should revert it when we disable automatic updates and enable the testing repo. -- Carl George -- ___ 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 status update
Hey Orion, I planned to send a status update following the hackfest, but I didn't think about the confusion that would be caused for packagers not at the hackfest who were getting branch requests. Sorry about that. I just posted a summary on the discussion thread. I'll include it below as well. --- The EPEL 10 hackfest at Flock took place yesterday. We were able to get enough of the infrastructure working prior to the hackfest to enable packagers in attendance to do a controlled trial run building packages. This also resulted in a few branch request bugzillas for dependencies, which I realize in hindsight was confusing for packagers not at the hackfest. I apologize for not setting that expectation ahead of time. Here is a summary of what is and isn't working at this point. What works: - creating epel10 branches (`fedpkg request-branch epel10`) - pushing commits to epel10 branches - pull requests to epel10 branches - Fedora CI scratch builds for epel10 pull requests - creating epel10.0 builds from epel10 branches (`fedpkg build` from an epel10 branch) - automatic bodhi updates, similar to rawhide What has not been completed yet: - publish the epel/10 repo - mirror the epel/10 repo - create epel-release for epel10 - epel10 configs in mock-core-configs - Fedora CI tasks for epel10 pull requests - enable the testing period in bodhi With no published repo, no mirroring, and no testing period (0 days to stable in bodhi), this is not a good time to start consuming EPEL 10. However, it is a good time for packagers to start building their packages. To be clear, this is the announcement to packagers that they can start building their packages. I'm hoping that in the next week or two we'll be able to get the mock configs done to enable packagers to do local builds, but in the mean time koji scratch builds are a solid alternative. We built about 70 packages during the allotted time of the hackfest, and as I write this we just passed 100 builds. Things seem to be working well. Please let me know if you notice any issues, aside from known items on the "not completed yet" list above. Happy packaging! On Sat, Aug 10, 2024 at 12:29 AM Orion Poplawski wrote: > > On 7/4/24 01:45, Carl George wrote: > > I originally posted this on Fedora Discussion [0], but I'm sharing it > > here as well for awareness. > > > > # Executive summary > > > > EPEL 10 is expected to be launched in Q4 of 2024. You may start > > noticing parts of the infrastructure coming online sooner than that. > > **Please do not start creating EPEL 10 builds until we announce that > > we are ready for packagers to start building.** > > > I'm seeing some builds and bugzilla requests for branching/builds. What > is the current status? > > -- > 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/ > > -- > ___ > 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 -- Carl George -- ___ 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] EPEL 10 status update
I originally posted this on Fedora Discussion [0], but I'm sharing it here as well for awareness. # Executive summary EPEL 10 is expected to be launched in Q4 of 2024. You may start noticing parts of the infrastructure coming online sooner than that. **Please do not start creating EPEL 10 builds until we announce that we are ready for packagers to start building.** # Detailed description The EPEL Steering Committee has big plans for EPEL 10. These plans are covered in detail in the original EPEL 10 proposal [1]. I also presented an EPEL 10 overview at the Fedora 40 release party [2]. At a high level, we are bringing minor versions to EPEL. I encourage you to read the proposal or watch that video for a deeper explanation. I'm writing this post to share our planned timeline for EPEL 10, and to set expectations for the coming months. Early CentOS Stream 10 composes are already available [3], but it hasn't been officially launched yet because the content set is still in flux. We expect to see the official launch announcement for CentOS Stream 10 later this year. We intend to align the EPEL 10 launch with that, which will give us the following approximate timeline. - August 2024: EPEL 10 hackfest at Flock [4] (see below for more details) - Q4 2024: expected launch of CentOS Stream 10 and EPEL 10 - Q2 2025: expected launch of RHEL 10 (three years after RHEL 9) In the months ahead, you may notice parts of EPEL 10 infrastructure coming online, such as build targets in Koji and releases in Bodhi. We will need these infrastructure pieces in place to work out all of the details of integrating minor versions. We'll send out an announcement when EPEL 10 is ready for package maintainers to start creating their builds. **Please do not start creating EPEL 10 builds until we announce that we are ready for packagers to start building.** Any builds created before this announcement may need to be discarded and rebuilt. I will be running an EPEL 10 Hackfest at Flock [4] in August (next month). The plan is to work on various infrastructure pieces related to EPEL 10. If we happen to have most of these pieces working prior to the hackfest, we can pivot our time to adding initial packages to EPEL 10. I hope to see you there! [0] https://discussion.fedoraproject.org/t/epel-10-status-update/124549 [1] https://discussion.fedoraproject.org/t/epel-10-proposal/44304 [2] https://youtu.be/PxWxK5PgUuE [3] https://lists.centos.org/hyperkitty/list/de...@lists.centos.org/thread/QCO73CKFMPNMERUWIQ47OVJMMUM7YUXU/ [4] https://flocktofedora.org/ -- Carl George -- ___ 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: NetworkManager-openvpn
Based on the upstream commit message for the 1.12.0 release, it does seem that the dependency is intentional and correct for the software. https://github.com/NetworkManager/NetworkManager-openvpn/commit/a476b439fc28bdd55a9277113a72040fb94b011b Of course it isn't correct to be released in EPEL 9 if the dependency cannot be met by what is currently available in RHEL 9 (NetworkManager-1.46.0-8.el9_4). CentOS Stream 9 has a new enough version (NetworkManager-1.48.0-1.el9), but it's unlikely for that build to show up in RHEL 9 until 9.5 is released. This update cannot be pushed to stable. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-7748f06d0d On Sun, Jun 30, 2024 at 10:51 AM Leon Fauster via epel-devel wrote: > > epel-testing (epel9) provides a new NetworkManager-openvpn package > that requires NetworkManager >= 1:1.46.2, and that one is currently > not provided by RHEL9. Is this intentional ...? > > -- > Leon > -- > ___ > 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 -- Carl George -- ___ 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: Clamav 1.0.x LTS lands on EPEL 8
This update changes from libclamav.so.9 to libclamav.so.11. It will require rebuilding c-icap-modules and librpminspect. If you release it in the current state you'll break installation of those packages. They should have been rebuilt in a side tag with clamav and released together. This is by definition an incompatible update, yet it doesn't appear to have followed the EPEL Incompatible Upgrades policy. https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ Do not push this update to stable. Simply sending one email to say "hey I did this and I'm gonna push to stable very soon" is not sufficient. Follow the process outlined in the documentation. If you had followed the process in the first place, perhaps you would have received karma on the update thanks to the multiple steps in the process designed to raise awareness of this type of update. On Thu, Jun 27, 2024 at 8:30 AM Sérgio Basto wrote: > > Hi, > I though that I should let you know > > After 4 week in updates-testing > > this update will go to stable very soon and I got none, nienty, zero > feedback, neither good or bad . > > Best regards, > -- > Sérgio M. B. > -- > ___ > 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 -- Carl George -- ___ 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] EPEL 8 Next EOL
Hello, Corresponding to the end of life (EOL) of CentOS Stream 8 [0], EPEL 8 Next is also now EOL. EPEL 8 will continue to be available until the EOL of RHEL 8 on 2029-05-31 [1]. Regards, Carl George on behalf of the EPEL Steering Committee [0] https://lists.centos.org/hyperkitty/list/annou...@lists.centos.org/thread/BQBYHVY55IIJCI2L6JIUQYMJ5BLLJOGE/ [1] https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates -- ___ 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: Contact to Oracle Linux EPEL repo maintainer
For what it's worth, discrepancies between the real EPEL and the repo that Oracle calls EPEL have been a known issue for quite some time. The problem goes beyond just packages with differing versions. There are a significant number of packages that only exist in the real EPEL or only in Oracle's repo. Back in 2021 I updated the default mock configs for oracle+epel to use the real EPEL because of this problem. https://github.com/rpm-software-management/mock/pull/806 In that pull request Avi mentions that the reason for rebuilding EPEL packages is so that an Oracle customer can get all of their packages from Oracle. He said he had no objection to Oracle renaming their repo to something else to avoid this confusion, but this does not appear to have happened yet. Avi, is that something that is still within the realm of possibility? On Fri, May 31, 2024 at 10:37 AM Leon Fauster via epel-devel wrote: > > Am 31.05.24 um 15:30 schrieb Troy Dawson: > > On Fri, May 31, 2024 at 2:48 AM Peter Soppe > <mailto:pe...@soppe.net>> wrote: > > > > Hello EPEL Team, > > > > I am trying to find out how to contact the maintainer of the Oracle > > Linux EPEL repository. > > The only website I found about EPEL and Contact is > > https://fedoraproject.org/wiki/EPEL/FAQ#contact > > <https://fedoraproject.org/wiki/EPEL/FAQ#contact> > > > > My current issue is that I use the Oracle Linux 8 EPEL package > > "cacti" - and there is a security issue that is solved in cacti > > Version 1.2.27 (2024-05-12). > > > > This version is available in the Fedora/RHEL Epel > > https://packages.fedoraproject.org/pkgs/cacti/cacti/ > > <https://packages.fedoraproject.org/pkgs/cacti/cacti/> since > > 2024-05-21 (9 days after release) > > but not in the Oracle Linux EPEL: > > > > https://yum.oracle.com/repo/OracleLinux/OL8/developer/EPEL/x86_64/index.html > > > > <https://yum.oracle.com/repo/OracleLinux/OL8/developer/EPEL/x86_64/index.html> > > Here the latest available Version is 1.2.23 (2023-01-13) which is > > about 19 months old. > > > > I want to know if there are plans to update the cacti version in the > > Oracle EPEL repo and if yes what is the planned timeline to do so. > > > > Best regards, > >Peter Soppe > > > > > > Although the Oracle Linux EPEL repository has the word "EPEL" in it, it > > is a repository supported and maintained by Oracle Linux. Similar to > > the CentOS Extras repo. > > As such, we can only point you back to the distribution and its community. > > > > https://support.oracle.com/ <https://support.oracle.com/> > > > > I did try looking for other information, but everything I found only had > > a heading and to get more information I needed to create an Oracle > > account and log in, which I am not willing to do. > > > > > @Peter why not using the original repo -> EPEL of EPEL :-) > > https://docs.fedoraproject.org/en-US/epel/ > > (do not forget to disable the EPE(O)L repo of Oracle). > > > -- > > Leon > > > -- > ___ > 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 -- Carl George -- ___ 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: Proposed incompatible change: python-botocore + boto3
On Wed, May 1, 2024 at 2:38 PM Major Hayden wrote: > > Hello there, > > We were recently packaging a different package in RHEL 9 (efs-utils) that > lists python-botocore as a dependency. As part of that process, we brought > python-botocore into RHEL 9. Packaging efs-utils in RHEL did not work out in > the end. > > I'm looking to bring python-botocore back to EPEL (from CentOS Stream 9), but > as part of the packaging work, we needed to bump the version to 1.31.62, > which is newer than the existing 1.25.10 version in epel9. > > This also requires moving boto3 and s3transfer to later versions as well. The > boto3 update is another incompatible change but s3transfer should not be > disruptive. > > As discussed in today's meeting on Matrix, it makes more sense to move > botocore forward than to revert to the original version prior to the CentOS > Stream 9 and RHEL work. > > Relevant BZ tickets: > > https://bugzilla.redhat.com/show_bug.cgi?id=2243017 > https://bugzilla.redhat.com/show_bug.cgi?id=2236795 > > Meeting notes: > > > https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-05-01/epel.2024-05-01-18.00.log.html > > Thanks for your time! > > -- > Major Hayden > -- > ___ > 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 We discussed this today at the EPEL Steering Committee meeting. https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-05-15/epel.2024-05-15-18.00.html Committee members voted +6,0,0 to approve this. Please proceed with the rest of the EPEL incompatible update process. -- Carl George -- ___ 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] retiring klee in EPEL 9
I am retiring the klee package in EPEL 9. In accordance with the retirement policy [0], I proposed this retirement two weeks ago on the epel-devel mailing list [1]. This software is not compatible with LLVM 15 or newer [2][3][4]. RHEL 9 regularly updates LLVM, is already defaulting to LLVM 15 in 9.2, and is expected to update to LLVM 16 in 9.3. Since klee cannot be rebuilt to work with the newer LLVM versions, we must retire it. The package was already retired from Fedora earlier this year [5]. The Fedora maintainer also orphaned the package, resulting in there being no maintainers for the EPEL 9 package. I am stepping in to retire the package as a proven packager. [0] https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_no_time_or_desire [1] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/VIP6GZFVNFRC2MZUB6OUEDF2SSW4BBVI/ [2] https://github.com/klee/klee/blob/v3.0/.github/workflows/build.yaml#L39 [3] https://github.com/klee/klee/pull/1648 [4] https://github.com/klee/klee.github.io/pull/347 [5] https://src.fedoraproject.org/rpms/klee/c/35fdedce2021112b996a9d38bf3e93cf5cf236c8 -- Carl George ___ 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: retirement of klee from EPEL 9
Closing the loop here, I've retired klee in EPEL 9. https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/thread/SP2624QZPY33N3NZNX5QLSMO2HZBHNNQ/ On Fri, Sep 29, 2023 at 12:01 PM Kevin Fenzi wrote: > > On Thu, Sep 28, 2023 at 10:37:28PM -0500, Carl George wrote: > > It recently came to my attention that the klee package in EPEL 9 > > needed to be rebuilt against the LLVM 15 library that shipped in RHEL > > 9.2. I filed a bug for this [0], and then noticed it was assigned to > > "Orphan Owner". It looks like the maintainer retired it from Fedora > > [1][2] due the upstream not being compatible with LLVM 15 [3]. I am > > not the maintainer of this package, but I intend to retire this > > package from EPEL 9 to avoid having a package with installation issue > > lingering around. The EPEL retirement policy [4] doesn't cover this > > exact scenario, so I plan to bring it up for discussion at the next > > EPEL Steering Committee meeting. We could delay the retirement for > > one week (the policy for security-related retirements) or two weeks > > (the policy for lack-of-time retirements), but my preference would be > > to retire it ASAP. > > Retiring seems reasonable here. > > kevin > ___ > 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 -- Carl George ___ 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: Are we sticking with exa or moving to eza in EPEL?
On Tue, Oct 10, 2023 at 10:10 PM Ian Laurie wrote: > > I realize exa is still in the EPEL9 repos, was wondering if there is an > intention to move to its replacement eza as was done in F39 and F40? > > Ian > -- > Ian Laurie > FAS: nixuser | IRC: nixuser > TZ: Australia/Sydney > ___ > 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 At a quick glance, I don't see obsoletes, provides, or conflicts in the Fedora spec file, so it wasn't a direct replacement per se. It was rust-exa being retired and rust-eza being added, which didn't happen in the same release. It's up to the relevant package maintainers (Fabio and the Rust SIG) to decide if they want to retire rust-exa from EPEL 9 and/or add rust-eza to EPEL 9. If retirement of rust-exa is the chosen route, an unmaintained upstream can certainly be viewed as the underlying reason why a maintainer would have "no desire" to keep maintaining the package in EPEL. https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_no_time_or_desire Here is a general guide for requesting packages in EPEL (tldr; file a bugzilla). https://docs.fedoraproject.org/en-US/epel/epel-package-request/ -- Carl George ___ 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] retirement of klee from EPEL 9
It recently came to my attention that the klee package in EPEL 9 needed to be rebuilt against the LLVM 15 library that shipped in RHEL 9.2. I filed a bug for this [0], and then noticed it was assigned to "Orphan Owner". It looks like the maintainer retired it from Fedora [1][2] due the upstream not being compatible with LLVM 15 [3]. I am not the maintainer of this package, but I intend to retire this package from EPEL 9 to avoid having a package with installation issue lingering around. The EPEL retirement policy [4] doesn't cover this exact scenario, so I plan to bring it up for discussion at the next EPEL Steering Committee meeting. We could delay the retirement for one week (the policy for security-related retirements) or two weeks (the policy for lack-of-time retirements), but my preference would be to retire it ASAP. [0] https://bugzilla.redhat.com/show_bug.cgi?id=2241277 [1] https://src.fedoraproject.org/rpms/klee/c/35fdedce2021112b996a9d38bf3e93cf5cf236c8?branch=rawhide [2] https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/SSJWCMXP45ERM76XH6MIW6Z76GIC7DFN/ [3] https://github.com/klee/klee/pull/1648 [4] https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/ -- Carl George ___ 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] Revisting conflicts policy for EPEL compat packages
In Fedora, it is allowed for compat packages to conflict with their non-compat equivalents. EPEL policy allows for the same behavior between EPEL packages, but not between EPEL packages and RHEL packages. The current policy includes the phrase "at this time" for that limitation. I believe it is time we revisit that part of the policy. I brought this up at a recent EPEL Steering Committee meeting, and the general consensus was to open a wider discussion about the topic. I've written about this in more detail on the Fedora Discussion site. I'm sending this email for awareness, but please centralize your feedback on the Discussion thread. https://discussion.fedoraproject.org/t/revisting-conflicts-policy-for-epel-compat-packages/90605 -- Carl George ___ 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-ANNOUNCE incompatible update of caddy in EPEL 9
On Thu, Aug 24, 2023 at 1:44 AM Carl George wrote: > > I am performing an incompatible upgrade of the caddy package in EPEL > 9. In accordance with the incompatible upgrade policy [0], I proposed > this upgrade just over a week ago on the epel-devel mailing list [1]. > For reasons detailed in the previous email, it is no longer possible > to update the package at the current version, preventing me from > resolving known CVEs. Today the EPEL Steering Committee voted to > approve this upgrade [2]. > > This upgrade will take the package from version 2.4.6 to 2.6.4. This > includes a few backwards-incompatible changes. I believe these > changes are on the milder side, and most users shouldn't notice a > difference. Here are the most notable removals/changes: > > - Reverse proxy: Incoming X-Forwarded-* headers will no longer be > automatically trusted, to prevent spoofing. > - Logging: Removed the deprecated common_log field from HTTP access > logs, and the single_field encoder. > - Logging: The remote_addr field has been replaced by remote_ip and > remote_port fields in HTTP access logs, which split up the two parts > of the remote address. > - Caddyfile: The reverse_proxy directive's handle_response > subdirective has had its status replacement functionality moved to a > new replace_status subdirective. > > There are also a few additional changes to features labeled as > experimental, and some deprecations (not yet removed). For a full > list, see the upstream release notes [3][4]. > > If you are able, please test and provide karma for the update [5]. > > [0] > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ > [1] > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/CDNDAKTIAQTFTNDHOIHKQJ4B2LAV5ZSS/ > [2] > https://meetbot.fedoraproject.org/fedora-meeting/2023-08-23/epel.2023-08-23-20.00.html > [3] https://github.com/caddyserver/caddy/releases/tag/v2.5.0 > [4] https://github.com/caddyserver/caddy/releases/tag/v2.6.0 > [5] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-8849a14e7f > > -- > Carl George > ___ > epel-announce mailing list -- epel-annou...@lists.fedoraproject.org > To unsubscribe send an email to epel-announce-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-annou...@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue This update has been in the testing repo for the mandatory 1 week period. I am pushing it to stable now. -- Carl George ___ 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] incompatible update of caddy in EPEL 9
I am performing an incompatible upgrade of the caddy package in EPEL 9. In accordance with the incompatible upgrade policy [0], I proposed this upgrade just over a week ago on the epel-devel mailing list [1]. For reasons detailed in the previous email, it is no longer possible to update the package at the current version, preventing me from resolving known CVEs. Today the EPEL Steering Committee voted to approve this upgrade [2]. This upgrade will take the package from version 2.4.6 to 2.6.4. This includes a few backwards-incompatible changes. I believe these changes are on the milder side, and most users shouldn't notice a difference. Here are the most notable removals/changes: - Reverse proxy: Incoming X-Forwarded-* headers will no longer be automatically trusted, to prevent spoofing. - Logging: Removed the deprecated common_log field from HTTP access logs, and the single_field encoder. - Logging: The remote_addr field has been replaced by remote_ip and remote_port fields in HTTP access logs, which split up the two parts of the remote address. - Caddyfile: The reverse_proxy directive's handle_response subdirective has had its status replacement functionality moved to a new replace_status subdirective. There are also a few additional changes to features labeled as experimental, and some deprecations (not yet removed). For a full list, see the upstream release notes [3][4]. If you are able, please test and provide karma for the update [5]. [0] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ [1] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/CDNDAKTIAQTFTNDHOIHKQJ4B2LAV5ZSS/ [2] https://meetbot.fedoraproject.org/fedora-meeting/2023-08-23/epel.2023-08-23-20.00.html [3] https://github.com/caddyserver/caddy/releases/tag/v2.5.0 [4] https://github.com/caddyserver/caddy/releases/tag/v2.6.0 [5] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-8849a14e7f -- Carl George ___ 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] retiring caddy in EPEL 7
I am retiring the caddy package from EPEL 7. In accordance with the retirement policy [0], I proposed this retirement just over a week ago on the epel-devel mailing list [1]. For reasons detailed in the previous email, it is no longer possible to update the package with the same major version, preventing me from resolving known CVEs. Doing an incompatible update to the next major version is not an appealing option with only ten months left until the retirement of EPEL 7 as a whole. Users that wish to keep using caddy on RHEL 7 can use the Copr repo from the upstream project [2][3]. Caddy is also available from EPEL 8 and EPEL 9 for users that are ready to migrate to a newer operating system version. Both of these options will involve the disruptive update from caddy v1 to v2, but users can opt-in to it at their own pace. The upstream project has a migration guide in their documentation to help [4]. [0] https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_security_reasons [1] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/JZRLEWOCX5QX3XZ7INLUZIB7LPAMDUZC/ [2] https://caddyserver.com/docs/install#fedora-redhat-centos [3] https://copr.fedorainfracloud.org/coprs/g/caddy/caddy/ [4] https://caddyserver.com/docs/v2-upgrade -- Carl George ___ 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] incompatible update of caddy in EPEL 9
Per policy [0], this is an announcement that I would like to do an incompatible update of the caddy package in EPEL 9. The version in the EPEL 9 repo is currently 2.4.6. RHEL 8 currently has golang 1.19. Based on my recent investigation of the EPEL 7 package [1], I've discovered just how sensitive caddy is to the version of golang it is built with. Upstream caddy only ever tested version 2.4.6 with golang 1.16 and 1.17 [2]. I did previously build caddy 2.4.6 with golang 1.18, which required swapping out the bundled quic library to work [3]. Thankfully that worked without patching the caddy code, but updating the bundled quic further in order to build with golang 1.19 would require significant patching, which isn't even guaranteed to work. I do not believe that rebuilding caddy at the current version in EPEL 9 is feasible, which prevents even attempting to backport outstanding CVEs. I'm currently tracking two CVEs for the EPEL 9 package that I would like to fix. - CVE-2022-28923 [4][5][6] - CVE-2022-41721 [7][8][9] To resolve these CVEs, and to get compatible with RHEL 9's golang 1.19, I think the best version of caddy to update to is 2.6.4. Updating caddy from 2.4.6 to 2.6.4 includes some backwards-incompatible changes (hence this email). After review, I believe these changes are on the milder side, and most users shouldn't notice a difference. Here are the most notable removals/changes: - Reverse proxy: Incoming X-Forwarded-* headers will no longer be automatically trusted, to prevent spoofing. - Logging: Removed the deprecated common_log field from HTTP access logs, and the single_field encoder. - Logging: The remote_addr field has been replaced by remote_ip and remote_port fields in HTTP access logs, which split up the two parts of the remote address. - Caddyfile: The reverse_proxy directive's handle_response subdirective has had its status replacement functionality moved to a new replace_status subdirective. There are also a few additional changes to features labeled as experimental, and some deprecations (not yet removed). For a full list, see the upstream release notes [10][11]. Finally, I'll note that RHEL 8 has the same version of golang as RHEL 9, so I also targeted caddy 2.6.4 for the initial EPEL 8 package that is on its way to testing [12]. It will be nice to have the same version of caddy in both EPEL 8 and EPEL 9. [0] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ [1] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/JZRLEWOCX5QX3XZ7INLUZIB7LPAMDUZC/ [2] https://github.com/caddyserver/caddy/blob/v2.4.6/.github/workflows/ci.yml#L22 [3] https://src.fedoraproject.org/rpms/caddy/c/8a639d7060ef6ff610880429d161b5f0275deee1?branch=epel9 [4] https://bugzilla.redhat.com/show_bug.cgi?id=2226939 [5] https://access.redhat.com/security/cve/CVE-2022-28923 [6] https://nvd.nist.gov/vuln/detail/CVE-2022-28923 [7] https://bugzilla.redhat.com/show_bug.cgi?id=2232267 [8] https://access.redhat.com/security/cve/CVE-2022-41721 [9] https://nvd.nist.gov/vuln/detail/CVE-2022-41721 [10] https://github.com/caddyserver/caddy/releases/tag/v2.5.0 [11] https://github.com/caddyserver/caddy/releases/tag/v2.6.0 [12] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-0b57e19163 -- Carl George ___ 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] retiring caddy in EPEL 7
Per policy [0], this is an announcement that I intend to retire the caddy package in EPEL 7. This package is in a bit of a weird state. The version in the EPEL 7 repo is currently 1.0.3, which was released upstream on 2019-08-14. Upstream development on v1 stopped with the release of 1.0.5 on 2020-02-28. Recently I updated the package from 1.0.3 to 1.0.5 to bring it as current as possible without breaking changes. At the same time I updated a bundled library to resolve CVE-2022-3064 [1], and also expected that rebuilding it with a newer golang would resolve CVE-2022-41717 [2]. I published this update [3] to the testing repo with the intention of testing it myself, but life got in the way and it was promoted to stable before I had a chance to. I also forgot that while I had enabled the test suite in Fedora, I did not have it enabled in the epel7 branch. Unfortunately, I discovered that the binary in this package would core dump immediately and was completely non-functional. As a quick partial mitigation, I asked RelEng to untag the broken build to revert the repository back to the previous build [4]. After investigating the problem, and consulting with upstream, I believe that it is simply not possible to build a working caddy v1 binary with golang 1.19 (the version currently available EPEL 7). Caddy is rather sensitive to the version of golang that it is built with, both for the minimum version, and as I discovered during this ordeal, the maximum version as well. I considered doing an incompatible update to bring the EPEL 7 package to a version of caddy that works with golang 1.19, but ultimately decided against it. It would be a very disruptive incompatible update because the config file format changed drastically between v1 and v2. With a mere ten months left before EPEL 7's retirement, I do not believe it is worth the effort or disruption to do such an incompatible update. Due to the outstanding CVEs, and the inability to even rebuild the package, I think the best course of action is to just retire it. Per policy, I will take this action in one week. As an alternative, the upstream project maintains a Copr repository [5][6] that provides the latest version, even for RHEL 7. This will still be a disruptive update from caddy v1 to v2, but users can opt-in to it at their own pace if they are unable/unwilling to migrate away from RHEL 7 yet. Caddy is also available in EPEL 9, and will be available in EPEL 8 soon [7], so upgrading to RHEL 8 or 9 is another possible route if users are ready to migrate their OS. [0] https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_security_reasons [1] https://nvd.nist.gov/vuln/detail/CVE-2022-3064 [2] https://nvd.nist.gov/vuln/detail/CVE-2022-41717 [3] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-284c34a6cc [4] https://pagure.io/releng/issue/11606 [5] https://caddyserver.com/docs/install#fedora-redhat-centos [6] https://copr.fedorainfracloud.org/coprs/g/caddy/caddy/ [7] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-0b57e19163 -- Carl George ___ 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: Please branch and build libusbauth-configparser, usbauth and usbauth-notifier in epel9
On Sat, Jul 29, 2023 at 5:15 AM Stefan Koch wrote: > > Hi > > Please branch and build libusbauth-configparser, usbauth and usbauth-notifier > in epel9. > Package are already in epel8. > > There was no response to the following Bugs within 6 months: > > - Please branch and build libusbauth-configparser in epel9 > Package is already in epel8 > https://bugzilla.redhat.com/show_bug.cgi?id=2161706 > > - Please branch and build usbauth epel9 > Package is already in epel8 > https://bugzilla.redhat.com/show_bug.cgi?id=2161707 > > - Please branch and build usbauth-notifier in epel9 > Package is already in epel8 > https://bugzilla.redhat.com/show_bug.cgi?id=2161708 > > Thanks > > Stefan > ___ > 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 Howdy Stefan, You appear to be the sole maintainer of all three of those packages, as well as the most recent committer and assignee for the bugs. Package maintainers can create branches with fedpkg, e.g. `fedpkg request-branch epel9`. https://docs.fedoraproject.org/en-US/epel/fedora-package-in-epel/ -- Carl George ___ 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: Proposed incompatible security update for llhttp in EPEL9
Thanks Ben for following the incompat process and for the detailed email. It makes sense to me, the plan is sound, and I plan to vote yes when we hold the official vote in next week's steering committee meeting. On Wed, Aug 9, 2023 at 1:35 PM Troy Dawson wrote: > > On Tue, Aug 8, 2023 at 4:11 PM Ben Beasley wrote: >> >> This email proposes upgrading the llhttp package in EPEL9 from 6.0.10 to >> 8.1.1, which would break the ABI and bump the SONAME version, under the >> EPEL Incompatible Upgrades Policy[1]. >> >> The llhttp package is a C library (transpiled from TypeScript) that >> provides the low-level HTTP support for NodeJS and for python-aiohttp. >> Currently, only python-aiohttp depends on the llhttp package in EPEL9. >> >> Versions of llhttp prior to 8.1.1 are affected by CVE-2023-30589[2], an >> HTTP request smuggling vulnerability rated 7.7 HIGH in CVSS v3 and rated >> Moderate by Red Hat. The GitHub advisory for llhttp is >> GHSA-cggh-pq45-6h9x[3]; the advisory for python-aiohttp is >> GHSA-45c4-8wx5-qw6w[4]. Upstream for python-aiohttp fixed this by >> updating llhttp (which they bundle, but we unbundle) in release 3.8.5. >> >> I am not comfortable attempting to backport the fix to an older release >> of llhttp. My preferred solution would be to update llhttp to 8.1.1[5] >> and (in the same side tag) update python-aiohttp to 3.8.5[6]. The ABI >> break in llhttp would only affect python-aiohttp; the python-aiohttp >> update itself is compatible (by upstream intent, and verified in >> COPR[7]); and a number of packages that depend on python-aiohttp would >> benefit from the fix. >> >> If this exception request is not approved, my fallback plan is to >> propose rebuilding python-aiohttp in EPEL9 with AIOHTTP_NO_EXTENSIONS=1, >> which would convert it to a pure-Python package. This is a documented >> mitigation, but comes with potentially serious performance regressions, >> again affecting a number of dependent packages. The llhttp package would >> become a leaf package and would remain unpatched. >> >> The same incompatible update was approved by FESCo for Fedora 37[8]. >> >> The purpose of this email is to document and explain the proposed >> update, to begin the minimum one-week discussion period mandated by the >> EPEL Incompatible Upgrades Policy, and to request that the update be >> added to the agenda for an upcoming EPEL meeting. >> >> [1] >> https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades >> >> [2] https://access.redhat.com/security/cve/CVE-2023-30589 >> >> [3] https://github.com/advisories/GHSA-cggh-pq45-6h9x >> >> [4] >> https://github.com/aio-libs/aiohttp/security/advisories/GHSA-45c4-8wx5-qw6w >> >> [5] https://src.fedoraproject.org/rpms/llhttp/pull-request/14 >> >> [6] https://src.fedoraproject.org/rpms/python-aiohttp/pull-request/26 >> >> [7] https://copr.fedorainfracloud.org/coprs/music/aiohttp-epel9/packages/ >> >> [8] https://pagure.io/fesco/issue/3049 > > > Thank you for the nice write-up. > > I have created an EPEL issue. Not really for discussion but more for voting > and make sure this is on the meeting agendas. > https://pagure.io/epel/issue/241 > > Troy > > ___ > 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 -- Carl George ___ 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: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
ption, as well as the original option? > > > > Then for epel7 the rpm's would have the original option turned off, but > > > for > > > > epel8 and 9 the option could be there and update wouldn't be a breaking > > > > update. > > > > > > > > That would allow users that have machines on RHEL 7,8 and 9 to use the > > > same > > > > version and secure options. > > > > Users that only have machines on RHEL 8 and 9, would then have the > > > > option > > > > to move to the more secure option when the time is good for them. > > > > > > > > Troy > > > > > > > > On Fri, May 5, 2023 at 3:30 PM Dave Dykstra via epel-devel < > > > > epel-devel@lists.fedoraproject.org> wrote: > > > > > > > > > The NVD analysis at > > > > > https://nvd.nist.gov/vuln/detail/CVE-2023-30549 > > > > > is now finished and they agreed with the impact score that I gave it. > > > > > They ended up with an even higher rating because they said the attack > > > > > complexity was low. I think the complexity is high, but in either > > > case the > > > > > overall severity is rated High. > > > > > > > > > > Dave > > > > > > > > > > On Thu, May 04, 2023 at 10:17:42AM -0500, Dave Dykstra wrote: > > > > > > DT, > > > > > > > > > > > > I am not all arguing that CVE-2022-1184 impact score was incorrect. > > > I > > > > > can't imagine why you think that. > > > > > > > > > > > > By itself, CVE-2022-1184 is not a privilege escalation, because it > > > can > > > > > normally only be exploited by someone with write access to the > > > filesystem > > > > > boots, that is, root. Only with setuid-root apptainer/singularity > > > does it > > > > > become a privilege escalation. > > > > > > > > > > > > I have said that I think that CVE-2022-1184's "Privileges Required" > > > was > > > > > incorrect. It was you who suggested USB automounts being available to > > > > > users may have been their reason for setting it to "low". If that's > > > what > > > > > they meant, then I think it makes perfect sense that they don't count > > > that > > > > > as a privilege escalation because physical access already gives > > > privilege > > > > > escalation in much easier ways. I said that that's probably why they > > > only > > > > > counted it as denial of service since that was the only thing new. > > > > > > > > > > > > Dave > > > > > > > > > > > > On Thu, May 04, 2023 at 02:14:08PM +0100, David Trudgian wrote: > > > > > > > Dave, > > > > > > > > > > > > > > On Wed, May 3, 2023, at 10:31 PM, Dave Dykstra via epel-devel > > > wrote: > > > > > > > > On Wed, May 03, 2023 at 02:59:42PM -0500, Carl George wrote: > > > > > > > > > On Thu, Apr 27, 2023 at 10:20 AM Dave Dykstra via epel-devel > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Thu, Apr 27, 2023 at 02:11:46AM -0500, Carl George wrote: > > > > > > > > ... > > > > > > > > > > > The Red Hat CVSS score for CVE-2022-1184 has the same > > > > > breakdown as the > > > > > > > > > > > NVD CVSS score. Both rate the "privileges required" > > > property > > > > > as low. > > > > > > > > > > > From what I can tell that property would be rated high if > > > they > > > > > > > > > > > considered root privileges to be required. How does > > > > > apptainer's use > > > > > > > > > > > of setuid change anything here? > > > > > > > > > > > > > > > > > > > > According to the explanation I received from the ext4 kernel > > > > > developer, > > > > > > > > > > Red Hat's CVSS rating was incorrect on that property. > > > Without > > > > > singularity > > > > > > &
[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
On Thu, Apr 27, 2023 at 10:20 AM Dave Dykstra via epel-devel wrote: > > On Thu, Apr 27, 2023 at 02:11:46AM -0500, Carl George wrote: > > On Wed, Apr 26, 2023 at 11:20 AM Dave Dykstra via epel-devel > ... > > > The summary of the CVE is that the way that apptainer & singularity > > > allow mounts of ext3 filesystems in setuid mode raises the severity of > > > many ext4 filesystem CVEs (ext3 filesystems are implemented by the ext4 > > > driver). OS vendors consider those CVEs to be low or moderate priority > > > because they assume that users do not have write access to the > > > underlying bits of the filesystem, but apptainer/singularity setuid mode > > > gives that access to users by default (before this release of apptainer). > > > Since vendors don't see urgency to patch low/moderate CVEs, it can take > > > a very long time for them to patch them and in fact RHEL7 is not patched > > > for one in particular. All this information came from a reliable source, > > > the owner of the ext4 kernel driver. > > > > The Red Hat CVSS score for CVE-2022-1184 has the same breakdown as the > > NVD CVSS score. Both rate the "privileges required" property as low. > > From what I can tell that property would be rated high if they > > considered root privileges to be required. How does apptainer's use > > of setuid change anything here? > > According to the explanation I received from the ext4 kernel developer, > Red Hat's CVSS rating was incorrect on that property. Without singularity > or apptainer it does require high privileges to exploit. Red Hat's CVSS score breakdown for CVE-2022-1184 is: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H You're suggesting that Red Hat's rating should have been higher because they didn't factor in low privileges, but that is objectively false because they did score it with low privileges. If they had scored it for high privileges, that would have dropped the rating down from 5.5 to 4.4. There is no reason to believe that CVE-2022-1184 should have been marked as higher impact than it was, and thus I see no reason to justify the likely duplicate CVE-2023-30549 as high. https://access.redhat.com/security/cve/CVE-2022-1184 https://nvd.nist.gov/vuln/detail/CVE-2022-1184 https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator > > > > I am sorry to see that I have already done one step too many according > > > to the incompatible changes policy, and have made the release available > > > to epel-testing. However, I think it's important to make it available > > > that way for system administrators to install early. The large High > > > Energy Physics community that I represent has security teams that want > > > to be able to notify their site administrators to upgrade to respond to > > > this high severity CVE, and it would be so much better if the > > > announcement they send can say to install from epel-testing rather than > > > having to provide URLs to download from koji. > > > > You can't just ignore the policy because you feel it's important to > > make a particular update available quickly. If you feel the policy > > needs to allow for things to be done in that order, propose a change > > to the policy. > > The policy does already say parenthetically that a short-circuit is > needed for security updates. I will propose a change to make such a > short-circuit. > > > > So, to the EPEL Steering Committee members: must I unpublish this update > > > from testing, or may I leave it there and send an announcement to > > > epel-announce that it is there and pending approval by the committee? > > > The bodhi settings are set so they won't get auto-updated by karma or > > > time. > > > > We discussed this earlier today at the Steering Committee meeting. No > > one seemed to have an issue with allowing these updates to stay in the > > testing repo until we vote on it next week. Next time, follow the > > policy steps correctly. > > Thank you, I will do that. I apologize for starting off on the wrong > foot. I neglected to read the policy again in my focus on getting the > release done. > > Dave > ___ > 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-d
[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
On Thu, Apr 27, 2023 at 9:42 AM Dave Dykstra via epel-devel wrote: > > We believe that it is important to apply this change to all EPEL releases, > for these reasons: > 1. The general vulnerability described in this CVE applies equally to all > currently supported Linux distributions. The Singularity/Apptainer CVE-2023-30549 only applies to apptainer on RHEL 7 because the underlying vulnerability (CVE-2022-1184) has been fixed on RHEL 8 and 9. > community has long been aware that making setuid-root kernel > filesystem mounts available to all users has been a risk, because > https://lwn.net/Articles/652468/ briefly explained that kernel > developers considered that to be a great risk. System admins have > been willing to live with the risk because (a) nobody had identified > an attack, (b) the functionality was so useful, especially the > squashfs mounts, and (c) there wasn't an alternative. With the new > information from the ext4 kernel filesystem owner, we now have more > specifics on how the attack can be done including an example > vulnerability, the ext3 mounts aren't as widely used as squashfs, > and Apptainer has an alternative using unprivileged user namespaces. > 2. RHEL8 & RHEL9 have unprivileged user namespaces enabled by default, > so the functionality will still be available to most of the users. > It does not automatically switch to the alternative, but there's a > clear error message saying that it is disabled by configuration and > suggesting that users add the --userns option (and of course if > apptainer-suid is not installed it uses the user namespace mode > automatically). > 3. It is important to have consistency across platforms, since users and > administrators often use more than one and it would be confusing to > have different behavior on different platforms. Admins can also If consistency across platforms is important, then it seems prudent to avoid this incompatible update across all three platforms, especially this late in the RHEL 7 lifecycle. > install the rpm on RHEL8 & 9 directly from github, and it would not > be good to have different behavior when installed from EPEL. > > Dave > > > On Thu, Apr 27, 2023 at 02:42:13AM -0500, Carl George wrote: > ... > > EPEL 9: > > > > RHEL 9 has the fix for CVE-2022-1184. CVE-2023-30549 requires > > CVE-2022-1184 to be unpatched. Because of this I'm opposed to an > > incompatible update for apptainer in EPEL 9. Apptainer in EPEL 9 > > should be modified to set the "allow setuid-mount extfs" option to yes > > for compatibility, even if that isn't the upstream default. > > > > EPEL 8: > > > > RHEL 8 has the fix for CVE-2022-1184. CVE-2023-30549 requires > > CVE-2022-1184 to be unpatched. Because of this I'm opposed to an > > incompatible update for apptainer in EPEL 8. Apptainer in EPEL 8 > > should be modified to set the "allow setuid-mount extfs" option to yes > > for compatibility, even if that isn't the upstream default. > > > > EPEL 7: > > > > RHEL 7 appears to be vulnerable to CVE-2022-1184. CVE-2023-30549 > > requires CVE-2022-1184 to be unpatched, so unlike EPEL 8 and EPEL 9 it > > actually impacts the EPEL 7 apptainer package. This CVE has not yet > > been rated by NVD. If the NVD assigns a rating of high (matching the > > CNA suggestion) or critical, I would be agreeable to an incompatible > > update of apptainer in EPEL 7. If the NVD assigns a rating of medium > > (matching CVE-2022-1184) or low, I would be opposed to an incompatible > > update of apptainer in EPEL 7. > > > > https://nvd.nist.gov/vuln/detail/CVE-2023-30549 > ___ > 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 -- Carl George ___ 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: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
; Thanks, > >> > > >> > DT > >> > > >> > > >> ___ > >> 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 > > > > > > -- > > Jonathan Wright > > AlmaLinux Foundation > > Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan> > > ___ > > 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 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 Thanks everyone for the detailed information provided so far. We should evaluate each of these updates separately since the conditions surrounding them are not the same across the board. EPEL 9: RHEL 9 has the fix for CVE-2022-1184. CVE-2023-30549 requires CVE-2022-1184 to be unpatched. Because of this I'm opposed to an incompatible update for apptainer in EPEL 9. Apptainer in EPEL 9 should be modified to set the "allow setuid-mount extfs" option to yes for compatibility, even if that isn't the upstream default. EPEL 8: RHEL 8 has the fix for CVE-2022-1184. CVE-2023-30549 requires CVE-2022-1184 to be unpatched. Because of this I'm opposed to an incompatible update for apptainer in EPEL 8. Apptainer in EPEL 8 should be modified to set the "allow setuid-mount extfs" option to yes for compatibility, even if that isn't the upstream default. EPEL 7: RHEL 7 appears to be vulnerable to CVE-2022-1184. CVE-2023-30549 requires CVE-2022-1184 to be unpatched, so unlike EPEL 8 and EPEL 9 it actually impacts the EPEL 7 apptainer package. This CVE has not yet been rated by NVD. If the NVD assigns a rating of high (matching the CNA suggestion) or critical, I would be agreeable to an incompatible update of apptainer in EPEL 7. If the NVD assigns a rating of medium (matching CVE-2022-1184) or low, I would be opposed to an incompatible update of apptainer in EPEL 7. https://nvd.nist.gov/vuln/detail/CVE-2023-30549 -- Carl George ___ 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: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
n/date >> > Wed Apr 26 09:12:37 BST 2023 >> > >> > # Update to the testing package >> > $ sudo dnf update --enablerepo=epel-testing apptainer-suid >> > >> > # After update >> > $ apptainer exec sif-overlay.sif /bin/date >> > FATAL: configuration disallows users from mounting SIF extfs partition >> > in setuid mode, try --userns >> > ``` >> > >> > I understand that the update is related to a security issue that upstream >> > has published: >> > >> > CVE-2023-30549 - >> > https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg >> > >> > However, I don't think this exempts the update from the incompatible >> > upgrades policy? >> > >> > I'd also like to note that CVE-2023-30549 is dependent on and potentially >> > a duplicate of CVE-2022-1184, which has been patched in EL8 and EL9, but >> > admittedly not in EL7. >> > >> > Thanks, >> > >> > DT >> > >> > >> ___ >> 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 > > > > -- > Jonathan Wright > AlmaLinux Foundation > Mattermost: chat > ___ > 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 -- Carl George ___ 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: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
g package > > $ sudo dnf update --enablerepo=epel-testing apptainer-suid > > > > # After update > > $ apptainer exec sif-overlay.sif /bin/date > > FATAL: configuration disallows users from mounting SIF extfs partition in > > setuid mode, try --userns > > ``` > > > > I understand that the update is related to a security issue that upstream > > has published: > > > > CVE-2023-30549 - > > https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg > > > > However, I don't think this exempts the update from the incompatible > > upgrades policy? > > > > I'd also like to note that CVE-2023-30549 is dependent on and potentially a > > duplicate of CVE-2022-1184, which has been patched in EL8 and EL9, but > > admittedly not in EL7. > > > > Thanks, > > > > DT > > > > > _______ > 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 -- Carl George ___ 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?
That sounds great, thanks. On Thu, Mar 30, 2023, 8:28 AM Troy Dawson wrote: > It doesn't look like they've done their merge yet, so I'll see if I can > get your change in. > How does this sound? > > Subject: > Notice: will be automatically retired from EPEL when > RHEL . is released > > Comment: > > This issue is purely informational, you do not need to take any action. > Thank you for your work maintaining in EPEL . Red Hat > considers this package important enough to promote it to official RHEL. It > will be part of RHEL .. Please do not update in > EPEL so the RHEL version can have a higher version and release. > When RHEL . is released, EPEL automation will remove > from EPEL and close this bug. > > > On Tue, Mar 28, 2023 at 9:14 AM Carl George wrote: > >> I'm also late to the party with this feedback, but just in case it's >> not too late to include, can we include something about not updating >> the package further? Beyond just "you do not need to take any >> action", we should advise against making any changes at that point, as >> often the RHEL package will be exactly one release higher than the >> current EPEL package, and updating the EPEL package further (either >> release or version) will screw up the upgrade path. >> >> On Mon, Mar 27, 2023 at 7:22 PM Troy Dawson wrote: >> > >> > On Sat, Mar 25, 2023 at 12:51 PM Miro Hrončok >> wrote: >> >> >> >> On 20. 03. 23 12:20, Neal Gompa wrote: >> >> >> I could think of other reasons as well. E.g. it's not important for >> customers >> >> >> but it's important for Red Hat. Or maybe it is a not-so-important >> dependency of >> >> >> something else. >> >> >> >> >> > Does Red Hat have any other motivation with RHEL other than a >> customer >> >> > needing the functionality? Those other reasons are generally driven >> by >> >> > someone needing it. >> >> >> >> See e.g. https://bugzilla.redhat.com/2175213 >> > >> > >> > I see your point. It sometimes also happens when the EPEL package is a >> dependency of the important package, the customers aren't actually asking >> for the EPEL package. >> > It looks like this change still hasn't been merged in so I'll see if I >> can get a change in. How about this? >> > >> > Subject: >> > Notice: will be automatically retired from EPEL when >> RHEL . is released >> > >> > Comment: >> > >> > This issue is purely informational, you do not need to take any >> action. Thank you for your work maintaining in EPEL . >> Red Hat considers this package important enough to promote it to official >> RHEL. It will be part of RHEL .. When that is released, >> EPEL automation will remove from EPEL and close this bug. >> > >> > _______ >> > 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 >> >> >> >> -- >> Carl George >> ___ >> 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 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 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?
I'm also late to the party with this feedback, but just in case it's not too late to include, can we include something about not updating the package further? Beyond just "you do not need to take any action", we should advise against making any changes at that point, as often the RHEL package will be exactly one release higher than the current EPEL package, and updating the EPEL package further (either release or version) will screw up the upgrade path. On Mon, Mar 27, 2023 at 7:22 PM Troy Dawson wrote: > > On Sat, Mar 25, 2023 at 12:51 PM Miro Hrončok wrote: >> >> On 20. 03. 23 12:20, Neal Gompa wrote: >> >> I could think of other reasons as well. E.g. it's not important for >> >> customers >> >> but it's important for Red Hat. Or maybe it is a not-so-important >> >> dependency of >> >> something else. >> >> >> > Does Red Hat have any other motivation with RHEL other than a customer >> > needing the functionality? Those other reasons are generally driven by >> > someone needing it. >> >> See e.g. https://bugzilla.redhat.com/2175213 > > > I see your point. It sometimes also happens when the EPEL package is a > dependency of the important package, the customers aren't actually asking for > the EPEL package. > It looks like this change still hasn't been merged in so I'll see if I can > get a change in. How about this? > > Subject: > Notice: will be automatically retired from EPEL when RHEL > . is released > > Comment: > > This issue is purely informational, you do not need to take any action. > Thank you for your work maintaining in EPEL . Red Hat > considers this package important enough to promote it to official RHEL. It > will be part of RHEL .. When that is released, EPEL automation > will remove from EPEL and close this bug. > > ___ > 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 -- Carl George ___ 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: Timeframe for EPEL retirement vs RHEL new package releases
On Wed, Mar 8, 2023 at 9:43 AM Troy Dawson wrote: > > > > On Wed, Mar 8, 2023 at 6:31 AM Troy Dawson wrote: >> >> On Tue, Mar 7, 2023 at 7:16 PM Carl George wrote: >>> >>> On Tue, Mar 7, 2023 at 2:18 PM Troy Dawson wrote >>> > >>> > RHEL has been very good (lately) about their NVR's being higher than >>> > EPEL's. >>> > If that is so, the EPEL packages don't take precedence over RHEL's. >>> >>> They may not when you first check. The risk in leaving the branch >>> active is that a maintainer may bump the version and/or release and >>> start overriding the RHEL package at any given time. We don't >>> currently have a mechanism to freeze the distgit branch but leave the >>> package in the repo. Our current calculus is "if the package is in >>> RHEL, it needs to be promptly retired from EPEL". Leaving packages >>> longer means that someone needs to continually check that the >>> duplicating packages haven't started overriding their RHEL equivalent. >> >> >> Before I dig through all my emails, let me ask if you have got any examples >> of EPEL packagers updating a package after RHEL has released it? >> (Within a reasonable time frame, which is to say a month after the release) The most recent example I remember is python-sqlalchemy. It was available in EPEL 9 at version 1.4.37. That same version was added to CentOS Stream 9 in preparation to go into RHEL 9.1. The EPEL maintainer didn't notice the retirement warning bug and continued to update the package to newer versions in EPEL 9. It made it up to version 1.4.44 before it was retired. That last update to 1.4.44 was pushed to stable on 2022-11-23, eight days after the RHEL 9.1 release. Anyone that had it installed previously won't get upgraded to the RHEL 9.1 package which is still at version 1.4.37. Thankfully the RHEL maintainer agreed to rebase it in RHEL 9.2 to eventually resolve the upgrade path. https://bugzilla.redhat.com/show_bug.cgi?id=2098498 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-cee8cb8dc1 https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/KGKSCFABQE6MJ5F4RKR3HUXW73GGTSU6/ https://bugzilla.redhat.com/show_bug.cgi?id=2152649 It's happened before, and I'd like to minimize the window where it can happen again in the future. I understand wanting to be courteous to rebuild users, but we need to find the right balance. > > > I'm sorry, it's sounding like I'm trying to argue with you, and I'm not. > I just have no idea why you feel packagers updating after RHEL has released a > package is a problem. It's not just updating after RHEL, it's updating the package to a higher NVR than what RHEL plans to release, as we saw in the sqlalchemy example. > Back before we started doing this EPEL2RHEL, we did have a problem, and that > was because many packagers had no idea that their package was in RHEL. > Since we started EPEL2RHEL we've had the opposite problem. They get so > excited about not having to maintain the package that they drop it too soon. > If I've missed things, please let me know. Because I feel like I'm not > seeing a problem that you are seeing. > >> >> Beyond the reasoning about timing, here's my other problem. >> In the script I'm writing, I can't check if a package has been released by >> RHEL, I can only check if a package has been released by Alma and/or Rocky. >> It's the same reason that willit is only checking against Alma. >> The whole subscription problem. >> >> Troy >> > ___ > 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 -- Carl George ___ 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: Timeframe for EPEL retirement vs RHEL new package releases
On Tue, Mar 7, 2023 at 2:18 PM Troy Dawson wrote: > > > > On Tue, Mar 7, 2023 at 11:38 AM Carl George wrote: >> >> On Tue, Mar 7, 2023 at 8:52 AM Troy Dawson wrote: >> > >> > On Mon, Mar 6, 2023 at 8:48 PM Carl George wrote: >> >> >> >> On Fri, Mar 3, 2023 at 5:42 AM Daniel P. Berrangé >> >> wrote: >> >> > >> >> > >> >> > There is also the case of the RHEL rebuilds whose users consume EPEL >> >> > packages. Depending how quick they are, the rebuild distros might not >> >> > have their 9.2 rebuild ready for some days/weeks/months after RHEL-9.2 >> >> > is first available. My projects' upstream CI is all based on AlmaLinux >> >> > and I don't want to see it broken again by premature capstone retirement >> >> > from EPEL. >> >> >> >> Historically, when CentOS was a rebuild, many EPEL maintainers would >> >> wait for corresponding CentOS rebuild release before changing their >> >> EPEL packages to work on RHEL. This was true both for soname rebuilds >> >> and retirements. CentOS would usually take about a month to catch up >> >> to RHEL minor versions. The new rebuilds are doing much better in >> >> this area. Alma is routinely getting their minor versions out 1-2 >> >> days after RHEL. The other rebuilds aren't far behind. If we were to >> >> delay package retirements, I don't think it's necessary to delay for >> >> more than a few days. >> > >> > >> > Do you mean "a few days after both Alma and Rocky are up to the latest >> > release." or "a few days after RHEL is released."? >> > >> > If you mean "a few days after RHEL is released." then I have to disagree >> > with you. >> > It does no harm to leave the packages in EPEL for a few weeks/months. >> > It does harm to rip the packages out too early. >> >> I do mean a few days after a RHEL release. Between the distgit >> retirement, compose, and mirror sync delay, the package doesn't become >> unavailable for nearly a business week (~5 days). > > > We already know this isn't true. > We've had packagers accidentally retire packages early and people get hit > literally the next day. Got any examples of this "next day" timing? The problem in the bugzilla linked at the start of this thread was that the retirement took place long before the package was in RHEL. I don't see any mention in the bug of observing the lack of the package on the mirrors, just discussion spurred by the maintainer commenting that he performed the retirement. Anecdotally I recall there being at least several days delay between retirement and the rare complaints about the package not being available in EPEL anymore. If users are consistently seeing the effects of a retirement the next day, then of course waiting a little bit longer could make sense. > > >> >> Users that already >> have the package installed are unaffected. If a user is using a RHEL >> rebuild that hasn't got their release done yet by that point, the only >> effect is that the package is unavailable in the EPEL repo, but it's >> still available for manual download from Koji or the snapshot >> archives. Harm is far too strong a word for this. It's a temporary >> annoyance that can be resolved by several workarounds, including >> switching to a rebuild that gets releases done faster. >> >> It's important that EPEL packages don't take precedence over RHEL >> packages, and you said yourself it's too difficult to continuously >> monitor which packages are a lower NVR than their RHEL equivalent and >> allow them to stay longer. EPEL targets RHEL, and we should minimize >> any delay of correcting issues that violate the core principle of >> EPEL. > > > RHEL has been very good (lately) about their NVR's being higher than EPEL's. > If that is so, the EPEL packages don't take precedence over RHEL's. They may not when you first check. The risk in leaving the branch active is that a maintainer may bump the version and/or release and start overriding the RHEL package at any given time. We don't currently have a mechanism to freeze the distgit branch but leave the package in the repo. Our current calculus is "if the package is in RHEL, it needs to be promptly retired from EPEL". Leaving packages longer means that someone needs to continually check that the duplicating packages haven't started overriding their R
[EPEL-devel] Re: Timeframe for EPEL retirement vs RHEL new package releases
On Tue, Mar 7, 2023 at 8:52 AM Troy Dawson wrote: > > On Mon, Mar 6, 2023 at 8:48 PM Carl George wrote: >> >> On Fri, Mar 3, 2023 at 5:42 AM Daniel P. Berrangé >> wrote: >> > >> > >> > There is also the case of the RHEL rebuilds whose users consume EPEL >> > packages. Depending how quick they are, the rebuild distros might not >> > have their 9.2 rebuild ready for some days/weeks/months after RHEL-9.2 >> > is first available. My projects' upstream CI is all based on AlmaLinux >> > and I don't want to see it broken again by premature capstone retirement >> > from EPEL. >> >> Historically, when CentOS was a rebuild, many EPEL maintainers would >> wait for corresponding CentOS rebuild release before changing their >> EPEL packages to work on RHEL. This was true both for soname rebuilds >> and retirements. CentOS would usually take about a month to catch up >> to RHEL minor versions. The new rebuilds are doing much better in >> this area. Alma is routinely getting their minor versions out 1-2 >> days after RHEL. The other rebuilds aren't far behind. If we were to >> delay package retirements, I don't think it's necessary to delay for >> more than a few days. > > > Do you mean "a few days after both Alma and Rocky are up to the latest > release." or "a few days after RHEL is released."? > > If you mean "a few days after RHEL is released." then I have to disagree with > you. > It does no harm to leave the packages in EPEL for a few weeks/months. > It does harm to rip the packages out too early. I do mean a few days after a RHEL release. Between the distgit retirement, compose, and mirror sync delay, the package doesn't become unavailable for nearly a business week (~5 days). Users that already have the package installed are unaffected. If a user is using a RHEL rebuild that hasn't got their release done yet by that point, the only effect is that the package is unavailable in the EPEL repo, but it's still available for manual download from Koji or the snapshot archives. Harm is far too strong a word for this. It's a temporary annoyance that can be resolved by several workarounds, including switching to a rebuild that gets releases done faster. It's important that EPEL packages don't take precedence over RHEL packages, and you said yourself it's too difficult to continuously monitor which packages are a lower NVR than their RHEL equivalent and allow them to stay longer. EPEL targets RHEL, and we should minimize any delay of correcting issues that violate the core principle of EPEL. This should all be much simpler in EPEL 10. Package retirement will be per-minor-release. We'll be able to actually follow the guidelines in CentOS Stream, retiring the package in that EPEL repo without affecting RHEL users. When a new RHEL minor version happens, they'll switch from an EPEL repo that has the package to an EPEL repo that doesn't have the package (but it will be available in RHEL at that point). Anyone using an older minor version (whether EUS, a manually pinned release, or a RHEL rebuild that is lagging) can explicitly point to the EPEL repo that matches their minor version by passing the `--releasever` flag to dnf with the appropriate value. > > Troy > > ___ > 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 -- Carl George ___ 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: Timeframe for EPEL retirement vs RHEL new package releases
On Fri, Mar 3, 2023 at 11:57 AM Nick Howitt via epel-devel wrote: > > On 03/03/2023 15:33, Daniel P. Berrangé wrote: > > On Fri, Mar 03, 2023 at 06:55:46AM -0800, Troy Dawson wrote: > > We are currently in the middle of changing the workflow of retiring these > packages. We are changing it so that the package maintainer doesn't do the > removing. It will be automated, or semi-automated, so there is a > consistent time when all of them are removed. > > That's a good idea. > > When do you actually remove the packages from the EPEL repository? > It has been agreed that it will be after both Alma and Rocky have their > latest release out. > > Ok, that's good, and should at least avoid breaking my upstream CI > use case since our containers should transparently start receiving > the 9.2 content when Alma releases their rebuilt container iamges. > > But how long after? > Immediately after? a month? 6 months? > > I personally am leaning towards a month after. > Here is my reasoning. > At the time a new RHEL release is released, we take a snapshot of the EPEL > repo and put it in the archives. > So all the packages that were built, and run on RHEL 9.1 are available in > that archive. > > snip > > Anyway, if some users are still doing new installs of RHEL 9.1 (or > compatible) after that month, then they should probably add the epel 9.1 > archive to their yum repositories. > > That's interesting, I didn't know about the y-stream archive > snapshots. > > Is there any mileage in considering a way to make the use of the epel > 9.1 archive automatic so users don't have risk of breakage needing manual > reconfiguration to keep working ? > > eg perhaps have 2 yum repos provided and enabled by epel-release. One > repo URL always the latest release and one repo URL always the current > 9.x release number, with a lower priority number set. The latter repo > initially empty of packages, but at the start of 9.2 it receives the > snapshot of 9.1 content, and so becomes dominent over the former repo > which will henceforth be holding 9.2 content. > > With regards, > Daniel > > Is this one of those cases where it would be better not to use an el9 package > suffix but something alphanumerically lower than el9, then Redhat's packages > would always take priority if they come along? Changing the disttag to sort lower will only have an effect if the RHEL package has the exact same version and release digit as the EPEL package. This almost never happens in practice. The RHEL maintainer is much more likely to select an older version for specific reasons or choose the same version with a higher release to provide a clean upgrade path. > > Nick > ___ > 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 -- Carl George ___ 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: Timeframe for EPEL retirement vs RHEL new package releases
On Fri, Mar 3, 2023 at 9:33 AM Daniel P. Berrangé wrote: > > On Fri, Mar 03, 2023 at 06:55:46AM -0800, Troy Dawson wrote: > > We are currently in the middle of changing the workflow of retiring these > > packages. We are changing it so that the package maintainer doesn't do the > > removing. It will be automated, or semi-automated, so there is a > > consistent time when all of them are removed. > > That's a good idea. > > > When do you actually remove the packages from the EPEL repository? > > It has been agreed that it will be after both Alma and Rocky have their > > latest release out. > > Ok, that's good, and should at least avoid breaking my upstream CI > use case since our containers should transparently start receiving > the 9.2 content when Alma releases their rebuilt container iamges. > > > But how long after? > > Immediately after? a month? 6 months? > > > > I personally am leaning towards a month after. > > Here is my reasoning. > > At the time a new RHEL release is released, we take a snapshot of the EPEL > > repo and put it in the archives. > > So all the packages that were built, and run on RHEL 9.1 are available in > > that archive. > > snip > > > Anyway, if some users are still doing new installs of RHEL 9.1 (or > > compatible) after that month, then they should probably add the epel 9.1 > > archive to their yum repositories. > > That's interesting, I didn't know about the y-stream archive > snapshots. > > Is there any mileage in considering a way to make the use of the epel > 9.1 archive automatic so users don't have risk of breakage needing manual > reconfiguration to keep working ? The current EPEL snapshot archives are flawed. They are done manually when Fedora Releng remembers. It has happened where packages made it into a snapshot labeled "EPEL X.Y" that were actually built against RHEL X.Y+1. We're actually planning a more robust and holistic approach to solving this problem for EPEL 10. The full proposal is over on Fedora Discussion. I cross posted it to this list back in November. Last month the EPEL Steering Committee approved the general direction of the plan (without commiting to exact implementation details). Please check it out and share your thoughts. https://discussion.fedoraproject.org/t/epel-10-proposal/44304 > > eg perhaps have 2 yum repos provided and enabled by epel-release. One > repo URL always the latest release and one repo URL always the current > 9.x release number, with a lower priority number set. The latter repo > initially empty of packages, but at the start of 9.2 it receives the > snapshot of 9.1 content, and so becomes dominent over the former repo > which will henceforth be holding 9.2 content. > > With regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| > ___ > 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 -- Carl George ___ 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: Timeframe for EPEL retirement vs RHEL new package releases
versions that are still maintained. When they refer to Y-stream work, they're talking about work in CentOS Stream in preparation for the next RHEL minor version. > > Solutions to the problems have to take all three of those impediments into > consideration to be done. My attempt with EPEL-playground in 8 broke down on > (2) Fedora packagers not having the capacity to deal with different workflows > and (1) infrastructure limits. EPEL-Next seems to be running into 1, 2 and 3. > > > -- > Stephen Smoogen, Red Hat Automotive > Let us be kind to one another, for most of us are fighting a hard battle. -- > Ian MacClaren > ___ > 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 -- Carl George ___ 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: Timeframe for EPEL retirement vs RHEL new package releases
ot; is not a concrete thing we can target. For every user that delays updating, many more are updating at their first opportunity in order to stay current. > > > > The package added to RHEL should (must) have a newer NEVR than the > existing package in EPEL, so even if we leave it in EPEL, it will > be ignored if the newer version is present in RHEL repos. The current "retire immediately" stance originated at a time when RHEL did less coordination with EPEL, and there was no CentOS Stream to publicly see what was planned for the next minor version. It was common for RHEL to choose an older NVR than what was available in EPEL, or for the EPEL maintainer to continue to do version/release bumps after a version had been selected to bake into the next RHEL minor version. Either way resulted in EPEL having a higher NVR than what ended up in RHEL. This necessitated quick retirement so that users that were on the current RHEL minor versions got the RHEL package, not the EPEL package. EPEL's core principle is to only be extra packages and not disturb or replace RHEL packages. We also are not able to mandate what RHEL ships. If they choose to ship foo 2.5, but EPEL has been shipping foo 3.1, foo still must be retired from EPEL. > > The main important thing I see is that the EPEL branch in dist-git > must be made read-only and/or prevented from submitting new builds, > once the package has been built in CentOS Stream. ie to ensure the > EPEL NEVR doesn't creep back above the pending RHEL package's NEVR. As far as I know we don't currently have a mechanism to do this in the current structure. The only mechanism to prevent changes to the distgit branch and prevent new builds is retirement, which also removes the package from the repo. > > > If that's done it should be fine to leave it in EPEL for a prolonged > period after 9.2 is released, to allow sufficient time for users to > actually switch from deploying 9.1 over to 9.2. > > I guess someone might say that EPEL only targets the very latest > y-stream of RHEL, so continuing to use 9.1 after 9.2 is released > is unsupported ? Even if that is technically the case, I think > in practice users won't take that into account, and thus expect > it to keep working and generally that should be fine. Only if a > EPEL package is rebuilt such that it depends on a newly added > API/ABI is that a problem. Other than nitpicking over the over-loaded term "support", I would say that's accurate. We don't have to theorize about this, as this already happens in practice. Oftentimes EPEL packages install correctly on older minor versions. When they don't, we see users file bugs or ask in communication channels about the error they see. They're informed that EPEL only targets the current minor versions,and then directed towards the koji history, the archive snapshots, or the spec file to build it themselves. It's a thing that happens periodically, and I wouldn't characterize it as overwhelming. Typically the response is "oh yeah I know I need to get updated to the current minor version". > > With regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| > ___ > 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 -- Carl George ___ 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
I would prefer using the incompat process [0] to upgrade epel9's python-tox to version 4, and introducing a python-tox3 compat package. We could use the same naming scheme in Fedora if it makes any sense to keep tox 3 around there for some period of time. [0] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ On Wed, Dec 14, 2022 at 8:45 AM 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? > > -- > 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 -- Carl George ___ 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] retirement of python-pyghmi in EPEL 8
python-pyghmi was added to RHEL 8.5 [0]. Per EPEL policy [1][2], it must be retired from EPEL 8. The version-release of the RHEL 8 package (1.5.29-1.el8) is higher than the last one provided in EPEL 8 (1.5.19-2.el8), so there is a clean upgrade path. The only loss of functionality is that EPEL 8 included the python-pyghmi-doc and python3-pyghmi-tests subpackages, but these were not included in RHEL. Nothing else in EPEL 8 depends on these subpackages. [0] https://access.redhat.com/errata/RHEA-2021:4331 [1] https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy [2] https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_package_in_rhel -- Carl George ___ 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] retirement of python-tornado in EPEL 9
python-tornado has been added to RHEL 9.1 [0]. Per EPEL policy [1][2], it must now be retired from EPEL 9. The version-release of the RHEL 9 package (6.1.0-8.el9) is higher than the last one provided in EPEL 9 (6.1.0-6.el9), so there is a clean upgrade path. The only loss of functionality is that EPEL 9 included the python-tornado-doc subpackage, but this was not included in RHEL. Nothing else in EPEL 9 depends on this subpackage. [0] https://access.redhat.com/errata/RHBA-2022:8193 [1] https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy [2] https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_package_in_rhel -- Carl George ___ 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 2:27 PM Maxwell G via epel-devel wrote: > > 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 is part of Fedora. discussion.fpo is one of the official places to talk about Fedora things [0]. We already have an #epel tag there with multiple posts [1]. The platform (discourse) has some support for email if you prefer that. On the tag page there is a bell icon that lets you subscribe to a tag, which I believe will email you for every topic started in that tag. You can reply to topics by replying to those emails. The regular mailing lists are also a valid place to discuss Fedora things, but in this instance I wanted to use discussion.fpo for two specific reasons: 1) I wanted to use markdown tables, and 2) I wanted to be able to edit the original post to add FAQ items as feedback comes in. [0] https://docs.fedoraproject.org/en-US/project/help/#_fedora_discussion [1] https://discussion.fedoraproject.org/tag/epel -- Carl George ___ 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] EPEL 10 proposal
Now that EPEL 9 is in full swing, I'd like to start planning ahead for what comes next. CentOS Stream 10 is expected to be available in 2024. We should be able to start EPEL 10 around the same time. Until then, we have the opportunity to evaluate what we can improve in EPEL. I am proposing a new workflow and structure for EPEL 10. The high level summary is for EPEL 10 to have unique branches, build targets, and repos for each minor version of RHEL 10, including CentOS Stream 10 as the upcoming minor version. This would be a significant change from how EPEL works today, but I think it would address several pain points for maintainers and users. I am opening this topic for discussion as early as possible before the EPEL 10 launch to gather feedback. Please note that this is currently just a proposal and has yet to be voted on by the EPEL Steering Committee. Please visit this thread on the Fedora Discussion site for the full proposal. https://discussion.fedoraproject.org/t/epel-10-proposal/44304 I would also ask that feedback be provided there instead of as email replies here on the list. -- Carl George ___ 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: How can I add a component for fedora to request a packges?
On Fri, Oct 21, 2022 at 5:26 PM Betty Liu wrote: > > Hi, I want to request a package in EPEL8 and I follow the steps in the > documentation > If isn’t found in Component under "Fedora EPEL" or "Fedora" > Products, it should be added to Fedora first > > The package name is webkit2gtk-4.0 and I saw it in Fedora, but not in the > RedHat Bugzilla. Can anyone teach me how to add the component to fedora? > ___ > 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 The component in bugzilla corresponds to the source package name, not the binary package name. Often times these are the same, but you've run into one of the instances where they are not. One way to check for this is to use the dnf repoquery command, in this case on Fedora since that's where the package is present and query-able. [root@f37-container:~]# dnf repoquery --quiet --info webkit2gtk4.0 | grep --max-count 1 Source Source : webkitgtk-2.38.0-3.fc37.src.rpm Alternatively, you can search for the package name in the Fedora Packages web app. https://packages.fedoraproject.org/search?query=webkit2gtk4.0 This returns one result, which shows webkit2gtk4.0 as a "subpackage" of webkitgtk. That's another way to describe the source/binary relationship. https://packages.fedoraproject.org/pkgs/webkitgtk/webkit2gtk4.0/ Whichever way you discover the source name, use that as the component for your bugzilla request. https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=webkitgtk -- Carl George ___ 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 Modules get the axe on Halloween 2022
e it > worse, that feature is unreliable for modular packages because it does not > transport a stream name. > > -- Petr > _______ > 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 -- Carl George ___ 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: EL selinux policy
On Tue, Sep 13, 2022 at 8:46 PM Mukundan Ragavan wrote: > > > I have a packaging question - > > One of the packages I maintain, nextcloud-client, fails to execute in > EPEL-9. It is being blocked by SELinux policy. > > getsebool selinuxuser_execmod is off in EL9. > > Is it even allowed to change SELinux rule in, for example, %post? > > I suspect the correct way to do this is to file a bug, correct? > > Thanks. > > -- > GPG Key: E5C8BC67 > ___ > 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 I've never seen anything prohibiting it. In the caddy package I set some SELinux booleans, fcontexts, and ports in %post. To avoid hard dependencies on the tools I wrap the commands in an if statement that checks for the relevant binary. https://src.fedoraproject.org/rpms/caddy/blob/rawhide/f/caddy.spec#_232-250 Grepping through other spec files I see a quite a few other examples of setsebool and semanage commands in scriptlets. -- Carl George ___ 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 Mon, Sep 5, 2022 at 2:22 PM Mark E. Fuller wrote: > > Hi all, > > 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? > > Thanks > > -- > Mark E. Fuller, Ph.D. > ful...@fedoraproject.org > ful...@mefuller.dev > @fuller:fedora.im > @fuller:one.ems.host > https://www.stossrohr.net > PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60 > ___ > devel mailing list -- de...@lists.fedoraproject.org > To unsubscribe send an email to 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/de...@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue For naming of the package, please follow the Fedora guidelines for "Multiple packages with the same base name". You'll find many other styles of naming these kind of packages, both in RHEL and EPEL, but please stick with the current Fedora guidelines on this. https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple Also make sure your package name and none of the files in your package conflict with anything shipped in RHEL. This may require manually renaming some files. https://docs.fedoraproject.org/en-US/epel/epel-policy/#package_maintenance_and_update_policy Once you have a working spec file, you can request a dist-git repo with the exception flag because it would fall under the second bullet point for exceptions. https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process If the package is intended to be EPEL-only, make sure to retire the rawhide branch. -- Carl George ___ 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: Request for fence-agents-pve package
Correct, a fence-agents-epel package is probably the best choice here.
Are you interested in creating and maintaining that? It's described
in further detail in the EPEL docs [0], although it's lacking
examples.
[0] https://docs.fedoraproject.org/en-US/epel/epel-policy-missing-sub-packages/
On Tue, Jun 21, 2022 at 9:15 AM Alex Talaran wrote:
>
> Carl,
>
> it looks like this will not be included in centos stream per RH. so
> looks like option 2 or 3 would be next right? to help the greater
> community 3 might be better since other agents are missing too.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2098360
>
> On 2022-06-17 16:28, Carl George wrote:
> > On Fri, Jun 17, 2022 at 8:31 AM Alex Talaran wrote:
> >>
> >> would anyone be willing to package this in epel or help get it in the
> >> existing package please?
> >>
> >> i asked on bugzilla [1] but the current maintainer isnt able to help at
> >> the moment. from what i can tell it might just need uncommented in the
> >> spec file [2]. someone else asked about it [1][3] and the ownership is
> >> being thrown back and forth between epel and rhel.
> >>
> >>
> >> [1]
> >> https://bugzilla.redhat.com/show_bug.cgi?id=2029251
> >>
> >> [2]
> >> https://github.com/ClusterLabs/fence-agents/blob/main/fence-agents.spec.in#L33
> >>
> >> [3]
> >> https://github.com/ClusterLabs/fence-agents/issues/456
> >> ___
> >> 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
> >
> > In Fedora fence-agents-pve is a subpackage of fence-agents.
> > fence-agents is in RHEL, so the Fedora package cannot be branched
> > as-is for EPEL. Some possible alternatives:
> >
> > - Open a CentOS Stream bugzilla and request that fence-agents-pve be
> > added to the fence-agents spec file. If the maintainer agrees, it
> > will show up in the next RHEL minor release ("next" being contingent
> > on timing). This is the ideal solution from a packaging perspective
> > but has a fair chance of being declined if RHEL doesn't want to
> > ship/support that subpackage.
> > - Create a stand-alone fence-agents-pve package, and get it reviewed
> > as an EPEL-only package. That would be allowed in EPEL because
> > neither the srpm or rpm name would conflict with RHEL.
> > - Create a fence-agents-epel package that contains all the subpackages
> > that are disabled in the RHEL spec file. Similar to the previous
> > option, this would be EPEL-only and would be allowed because the srpm
> > and rpm names don't conflict with RHEL.
> > - Rebuild the Fedora spec file with all subpackages somewhere where
> > replacing base packages is allowed, such as a copr or a CentOS SIG.
> >
> ___
> 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
--
Carl George
___
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: Default for 'dnf copr enable'
On Mon, Apr 11, 2022 at 8:38 AM Miroslav Suchý wrote: > > Hi. > I want to get your feedback: > > When you enable Copr repository you can run: >dnf copr enable myname/project epel-9-x86_64 > The last parameter is optional and most people usually runs: >dnf copr enable myname/project > > Dnf-plugins-core tries to guess [3] the correct chroot. On Fedora it is easy. > For Fedora 35 it is fedora-35-$arch. > But for RHEL/Centos/Centos Stream it is a bit tricky. > > E.g. for C9S we now defaults to centos-stream-9-$arch. But this gets some > pushback [1,2]. I want to know if this opinion > is minority or whether majority of people wants this. > I do not think there is an option which is correct. So it is about choosing a > default which is correct for most people. > > Can you please tell me what is good default for you: > > Centos Stream 9: > 1) epel-9-$arch > 2) centos-stream-9-$arch > 3) centos-stream+epel-next-9-$arch > 4) no default, print error and let user explicitly declare the chroot > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2058471 > [2] > https://gitlab.com/redhat/centos-stream/rpms/dnf-plugins-core/-/merge_requests/7 > [3] > https://github.com/rpm-software-management/dnf-plugins-core/blob/master/plugins/copr.py#L472 > > Miroslav > ___ > 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 In most cases, epel-9-$arch will be the correct choice. In the bug [0] it is suggested that when the guess is wrong it's simple to add the chroot as an explicit argument. Instead of making the majority of users do `dnf copr enable epel-9-`, why can't we have a tiny number of users do `dnf copr enable centos-stream-9-` and have the plugin guess the correct thing for the majority of users? [0] https://bugzilla.redhat.com/show_bug.cgi?id=2058471#c1 -- Carl George ___ 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: Request for fence-agents-pve package
On Fri, Jun 17, 2022 at 8:31 AM Alex Talaran wrote:
>
> would anyone be willing to package this in epel or help get it in the
> existing package please?
>
> i asked on bugzilla [1] but the current maintainer isnt able to help at
> the moment. from what i can tell it might just need uncommented in the
> spec file [2]. someone else asked about it [1][3] and the ownership is
> being thrown back and forth between epel and rhel.
>
>
> [1]
> https://bugzilla.redhat.com/show_bug.cgi?id=2029251
>
> [2]
> https://github.com/ClusterLabs/fence-agents/blob/main/fence-agents.spec.in#L33
>
> [3]
> https://github.com/ClusterLabs/fence-agents/issues/456
> ___
> 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
In Fedora fence-agents-pve is a subpackage of fence-agents.
fence-agents is in RHEL, so the Fedora package cannot be branched
as-is for EPEL. Some possible alternatives:
- Open a CentOS Stream bugzilla and request that fence-agents-pve be
added to the fence-agents spec file. If the maintainer agrees, it
will show up in the next RHEL minor release ("next" being contingent
on timing). This is the ideal solution from a packaging perspective
but has a fair chance of being declined if RHEL doesn't want to
ship/support that subpackage.
- Create a stand-alone fence-agents-pve package, and get it reviewed
as an EPEL-only package. That would be allowed in EPEL because
neither the srpm or rpm name would conflict with RHEL.
- Create a fence-agents-epel package that contains all the subpackages
that are disabled in the RHEL spec file. Similar to the previous
option, this would be EPEL-only and would be allowed because the srpm
and rpm names don't conflict with RHEL.
- Rebuild the Fedora spec file with all subpackages somewhere where
replacing base packages is allowed, such as a copr or a CentOS SIG.
--
Carl George
___
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 Fri, Jun 17, 2022 at 8:33 AM Troy Dawson wrote: > > > > On Thu, Jun 16, 2022 at 10:22 PM Carl George wrote: >> >> On Wed, Jun 15, 2022 at 5:12 PM Troy Dawson wrote: >> > >> > I'm totally top-posting, and I apologize for that. >> > >> > For right now, I'm going to put my enable-crb script in epel-release, but >> > not automatically run it in a %post script or anything. >> > The debate about putting it in a post script, or a separate package, can >> > go on independently of the script. >> > >> > This does a few things. >> > - give people a single, easy to remember way to enable crb >> > -- Right now if you install anything but RHEL you might remember "dnf >> > install epel-release" but then you forget what the dnf command is to >> > enable a repo, and you might forget if it's crb or powertools. >> > -- It will make scripting easier because you just have one command that >> > will work across all RHEL compatibles. >> > >> > - gives the script a chance to find all the corner cases >> > -- It's worked on everything I've tried thus far, but I'm sure there are >> > some corner cases or two where the script doesn't work. >> > >> > I was thinking of it being >> > /usr/bin/enable-crb >> > /usr/bin/epel-enable-crb (a link to enable-crb) >> > >> > Thoughts? >> > >> > Troy >> > >> I think it would be nice to be able to both enable and disable from >> the same script. This would come in handy when you are looking for >> things that don't install when crb is disabled. I don't see anything >> else in Fedora or RHEL that ships a command with the name crb, so how >> about that? >> >> crb enable >> crb disable > > > That shouldn't be too hard. I'm going to give it a shot. > If that takes too long, I'll just push what I currently have for now. > > I notice that you said crb-enable, crb-disable. > Do you like having the name first, or the function first? > > enable-crb vs crb-enable ? > > either way I want to have it by itself, as well as starting with epel > > epel-enable-crb vs epel-crb-enable ? > > Troy > > > > ___ > 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 I was specifically suggesting /usr/bin/crb, accepting a single argument of enable or disable. I can't find anything else in Fedora or RHEL using that path. What would be the purpose of prefixing it with "epel-"? It's not "CRB from EPEL", it's a generic script for enabling/disabling the crb repo that just happens to be included in the epel-release package. -- Carl George ___ 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 Wed, Jun 15, 2022 at 5:12 PM Troy Dawson wrote: > > I'm totally top-posting, and I apologize for that. > > For right now, I'm going to put my enable-crb script in epel-release, but not > automatically run it in a %post script or anything. > The debate about putting it in a post script, or a separate package, can go > on independently of the script. > > This does a few things. > - give people a single, easy to remember way to enable crb > -- Right now if you install anything but RHEL you might remember "dnf install > epel-release" but then you forget what the dnf command is to enable a repo, > and you might forget if it's crb or powertools. > -- It will make scripting easier because you just have one command that will > work across all RHEL compatibles. > > - gives the script a chance to find all the corner cases > -- It's worked on everything I've tried thus far, but I'm sure there are some > corner cases or two where the script doesn't work. > > I was thinking of it being > /usr/bin/enable-crb > /usr/bin/epel-enable-crb (a link to enable-crb) > > Thoughts? > > Troy > > https://pagure.io/epel/issue/128 > https://src.fedoraproject.org/rpms/epel-release/pull-request/21 > ___ > 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 I think it would be nice to be able to both enable and disable from the same script. This would come in handy when you are looking for things that don't install when crb is disabled. I don't see anything else in Fedora or RHEL that ships a command with the name crb, so how about that? crb enable crb disable -- Carl George ___ 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 Sat, Jun 4, 2022 at 3:52 PM Troy Dawson wrote: > > When I first created the EPEL issue to auto-enable crb repo[1] I was only > thinking of CAN we do it. I wasn't thinking SHOULD we do it. > We've come to the point that we actually can do it. But before we go down > that road, I wanted to take a step back and ask, should we do it. > > The more I think about it, the more I think we shouldn't auto-enable the crb > repo for epel8 and epel9. Here are my reasons why. > > 1 - The need to auto-enable crb isn't as big as it was before. > At the time that I wrote that issue, I was getting quite alot of bugs / pings > / emails about epel packages not being installable. I think on average > about 2 a month. > With epel being in fedora-docs, and with Carl's re-write of how to enable > epel, that number has dropped significantly. I possibly still average one a > month, but that's an average over a year, with most of them being last year. > In short, I believe the documentation is better, and easier to find, allowing > people to enable crb on their own, without automation. > > 2 - crb isn't an epel repo > We really shouldn't be messing with other repo's that we, epel, don't own. > > 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 could go into more explanation on each of those things, but in the end, > I've talked myself out of wanting to auto-enable crb for epel8 and epel9. > But I also wanted to get others' thoughts before I close the bug and pull > request. > > What do others think? > > Troy > > > [1] - https://pagure.io/epel/issue/128 > ___ > 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 I have sympathy for the issue we are trying to solve, but I do not think it's that big a deal. Enabling crb is a documented part of setting up EPEL. Anyone having issues because crb isn't enabled failed to follow the instructions. Continuing to redirect people to the instructions will eventually result in this being common knowledge, and the instances of having to tell people about it will continue to fall. We can further reduce these instances by requesting EPEL runtime dependencies be "promoted" from crb to baseos or appstream. In the mean time, it's not that much work to copy/paste "the missing dependencies are in crb/powertools, follow the setup instructions again" to the occasional bug report. When we were first setting up the repo definitions for CentOS Stream 9, I suggested the idea of moving the crb repo file to a separate package (centos-release-crb), with enabled=1 but not installed by default. This would allow epel-release to recommmend centos-release-crb. There was push back to this idea because there is a desire for the "enable crb" action in CentOS Stream to look roughly similar to how it works in RHEL (`dnf config-manager --set-enabled crb` and `subscription-manager repos --enable codeready-builder-for-rhel-9-$(arch)-rpms`). Maybe we can revisit this idea for CentOS Stream 10. -- Carl George ___ 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: [HEADS UP] ImageMagick side-tag for epel8
On Wed, Apr 13, 2022 at 5:05 PM Carl George wrote: > > On Fri, Apr 8, 2022 at 5:17 PM Troy Dawson wrote: > > > > > > > > On Fri, Apr 8, 2022 at 3:00 PM Sérgio Basto wrote: > >> > >> On Fri, 2022-04-08 at 13:08 -0700, Troy Dawson wrote: > >> > >> > >> > >> On Fri, Apr 8, 2022 at 12:46 PM Sérgio Basto wrote: > >> > >> On Thu, 2022-03-31 at 11:54 +0100, Sérgio Basto wrote: > >> > > This update changes a library soname, which makes it an > >> > > incompatible > >> > > upgrade. It must follow the EPEL incompatible upgrades policy [0]. > >> > > This email can count as step 1 once you reply with the specific > >> > > CVEs > >> > > this will address. Then it must be open for discussion on list for > >> > > one week (step 2) before being added as an agenda item at next > >> > > week's > >> > > EPEL Steering Committee meeting [1] (step 3). > >> > > > >> > > [0] > >> > > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ > >> > > [1] https://calendar.fedoraproject.org/epel/#m9854 > >> > > >> > OK , thank you > >> > >> > >> Hi, > >> have we any new ? > >> > >> I'd like move on before rhel 8.6 be available . > >> > >> > >> Thank you > >> > >> > >> Hi Sérgio, > >> Could you list the CVE's that this update addresses. > >> If that list is fairly long, at least the important ones > >> > >> > >> > >> we got 82 reported on bugzilla > >> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=ImageMagick&list_id=12543908&product=Fedora%20EPEL&query_format=advanced > > > > > > Youch! > > Next time, lead with that. :) > > I joke, but that's really what we were waiting for. > > It's a Friday afternoon, and I'm pretty certain we won't get enough of the > > committee reading this to give a full vote until next week. > > But, as for me, I give it a +1. > > Troy > > > > > > ___ > > 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 > > This was approved [0] in today's EPEL Steering Committee meeting. > Please continue with the process for incompatible upgrades from step 4 > forward [1]. > > [0] https://meetbot.fedoraproject.org/teams/epel/epel.2022-04-13-20.00.html > [1] > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades > > -- > Carl George Based on repoquery it looks like only three packages need to be rebuilt for this. converseen digikam dvdauthor -- Carl George ___ 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: [HEADS UP] ImageMagick side-tag for epel8
On Fri, Apr 8, 2022 at 5:17 PM Troy Dawson wrote: > > > > On Fri, Apr 8, 2022 at 3:00 PM Sérgio Basto wrote: >> >> On Fri, 2022-04-08 at 13:08 -0700, Troy Dawson wrote: >> >> >> >> On Fri, Apr 8, 2022 at 12:46 PM Sérgio Basto wrote: >> >> On Thu, 2022-03-31 at 11:54 +0100, Sérgio Basto wrote: >> > > This update changes a library soname, which makes it an >> > > incompatible >> > > upgrade. It must follow the EPEL incompatible upgrades policy [0]. >> > > This email can count as step 1 once you reply with the specific >> > > CVEs >> > > this will address. Then it must be open for discussion on list for >> > > one week (step 2) before being added as an agenda item at next >> > > week's >> > > EPEL Steering Committee meeting [1] (step 3). >> > > >> > > [0] >> > > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ >> > > [1] https://calendar.fedoraproject.org/epel/#m9854 >> > >> > OK , thank you >> >> >> Hi, >> have we any new ? >> >> I'd like move on before rhel 8.6 be available . >> >> >> Thank you >> >> >> Hi Sérgio, >> Could you list the CVE's that this update addresses. >> If that list is fairly long, at least the important ones >> >> >> >> we got 82 reported on bugzilla >> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=ImageMagick&list_id=12543908&product=Fedora%20EPEL&query_format=advanced > > > Youch! > Next time, lead with that. :) > I joke, but that's really what we were waiting for. > It's a Friday afternoon, and I'm pretty certain we won't get enough of the > committee reading this to give a full vote until next week. > But, as for me, I give it a +1. > Troy > > > ___ > 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 This was approved [0] in today's EPEL Steering Committee meeting. Please continue with the process for incompatible upgrades from step 4 forward [1]. [0] https://meetbot.fedoraproject.org/teams/epel/epel.2022-04-13-20.00.html [1] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades -- Carl George ___ 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: Dependency issue hwinfo/libx86emu
On Fri, Apr 8, 2022 at 2:23 AM Nick Howitt via epel-devel wrote: > > > > On 08/04/2022 04:38, Carl George wrote: > > On Thu, Apr 7, 2022 at 7:33 PM Gemneye via epel-devel > > wrote: > >> > >>>> > >>>> Error: Package: hwinfo-21.68-1.el7.x86_64 (epel) > >>>> Requires: libx86emu.so.1()(64bit) > >>>> Removing: libx86emu-1.1-2.1.x86_64 > >>>> (@/libx86emu-1.1-2.1.x86_64) > >>>> libx86emu.so.1()(64bit) > >>>> Updated By: libx86emu-3.5-1.el7.x86_64 (epel) > >>>>~libx86emu.so.3()(64bit) > >>>> You could try using --skip-broken to work around the problem > >>>> You could try running: rpm -Va --nofiles --nodigest > >>>> > >>>> Any suggestions and help appreciated. > >>> > >>> Hello > >>> > >>> > >>> You can install hwinfo if you either disable epel-testing or filter > >>> out (yum --exclude) libx86emu-3.5-1.el7. This package was pushed to > >>> epel-testing and indeed, hwinfo which depends on libx86emu would need > >>> a rebuild against it. > >>> > >>> > >>> wolfy > >>> > >> > >> Thank you for the response. > >> > >> It looks like libx86emu-3.5-1.el7.x86_64 is in the main epel repository. > >>Using --disablerepo=epel-testing, nor disabling repo in > >> /etc/yum.repos.d/epel-testing.repo caused the issue to go away. > >> > >> You are correct in that hwinfo can be installed by using > >> --exclude=libx86emu, but is still looks like there is a packing issue?? > >> ___ > >> 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 > > > > This just recently happened in EPEL8 too [0]. I've created a > > corresponding bug for EPEL7 [1]. This incompatible soname bump in > > libx86emu is not allowed by EPEL policy [2]. If an update like this > > must happen for security reasons, it should follow the incompatible > > upgrades policy [3], which includes discussion on this list and > > announcements on epel-announce. Obviously that's not what happened > > here. The quickest fix is to rebuild hwinfo against the new soname. > > I did that for EPEL8 a few days ago, and just submitted the EPEL7 one > > now. Follow along in the bugzilla for future updates. > > > > [0] https://bugzilla.redhat.com/show_bug.cgi?id=2071639 > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2073238 > > [2] https://docs.fedoraproject.org/en-US/epel/epel-policy/ > > [3] > > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ > > > Or, as a short term kludge, can you force the installation of both > packages and then symlink libx86emu.so.1 to so.3? > ___ > 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 That is awful advice. Please don't tell people to do that. When an soname changes the library developer is explicitly stating that the interfaces have changed. You are gambling that the application using the library isn't using any of the changed interfaces. -- Carl George ___ 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: Dependency issue hwinfo/libx86emu
On Thu, Apr 7, 2022 at 7:33 PM Gemneye via epel-devel wrote: > > >> > >> Error: Package: hwinfo-21.68-1.el7.x86_64 (epel) > >>Requires: libx86emu.so.1()(64bit) > >>Removing: libx86emu-1.1-2.1.x86_64 > >> (@/libx86emu-1.1-2.1.x86_64) > >>libx86emu.so.1()(64bit) > >>Updated By: libx86emu-3.5-1.el7.x86_64 (epel) > >> ~libx86emu.so.3()(64bit) > >> You could try using --skip-broken to work around the problem > >> You could try running: rpm -Va --nofiles --nodigest > >> > >> Any suggestions and help appreciated. > > > > Hello > > > > > > You can install hwinfo if you either disable epel-testing or filter > > out (yum --exclude) libx86emu-3.5-1.el7. This package was pushed to > > epel-testing and indeed, hwinfo which depends on libx86emu would need > > a rebuild against it. > > > > > > wolfy > > > > Thank you for the response. > > It looks like libx86emu-3.5-1.el7.x86_64 is in the main epel repository. > Using --disablerepo=epel-testing, nor disabling repo in > /etc/yum.repos.d/epel-testing.repo caused the issue to go away. > > You are correct in that hwinfo can be installed by using > --exclude=libx86emu, but is still looks like there is a packing issue?? > ___ > 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 This just recently happened in EPEL8 too [0]. I've created a corresponding bug for EPEL7 [1]. This incompatible soname bump in libx86emu is not allowed by EPEL policy [2]. If an update like this must happen for security reasons, it should follow the incompatible upgrades policy [3], which includes discussion on this list and announcements on epel-announce. Obviously that's not what happened here. The quickest fix is to rebuild hwinfo against the new soname. I did that for EPEL8 a few days ago, and just submitted the EPEL7 one now. Follow along in the bugzilla for future updates. [0] https://bugzilla.redhat.com/show_bug.cgi?id=2071639 [1] https://bugzilla.redhat.com/show_bug.cgi?id=2073238 [2] https://docs.fedoraproject.org/en-US/epel/epel-policy/ [3] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ -- Carl George ___ 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: [HEADS UP] ImageMagick side-tag for epel8
t; Sérgio M. B. > ___ > devel mailing list -- de...@lists.fedoraproject.org > To unsubscribe send an email to 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/de...@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure This update changes a library soname, which makes it an incompatible upgrade. It must follow the EPEL incompatible upgrades policy [0]. This email can count as step 1 once you reply with the specific CVEs this will address. Then it must be open for discussion on list for one week (step 2) before being added as an agenda item at next week's EPEL Steering Committee meeting [1] (step 3). [0] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ [1] https://calendar.fedoraproject.org/epel/#m9854 -- Carl George ___ 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] slowing down the stalled request process
EPEL has a stalled request policy [0] that allows packagers to get themselves added as collaborators on epel* branches. Prior to this policy being implemented, requests to add Fedora packages to EPEL would often go unanswered for long periods of time. Packagers wanting to help had only one option to force action: Fedora's non-responsive maintainer policy [1]. This was view by many as overkill, as it results in all of the non-responsive maintainer's packages being orphaned or transferred to the requester. The stalled request policy is much friendlier and enables greater collaboration. However, despite the good intentions, I've observed some frustrations among Fedora packagers when collaborators are added via this process. We do not want maintainers to feel rushed or circumvented. That said, I am firmly of the opinion that nobody "owns" Fedora packages, we maintain them. Packagers wanting to take action on EPEL requests should have a way to do that if the existing maintainers have not taken action within a reasonable amount of time. What I would like to discuss is what amount of time is reasonable. The current process allows a collaborator to be added after a two week period. When the stalled policy was implemented I was a fan of this duration, but now I think it is too short. Extending it slightly would be a good compromise to give maintainers a bit more time to respond while still allowing the request to eventually be completed. I have two suggestions for alternative steps for the process. Current process (two bugzilla pings, two weeks total time): - 1st request - one week goes by - 2nd request - one week goes by - releng ticket to be added as a collaborator Proposal A (three bugzilla pings, three weeks total time): - 1st request - one week goes by - 2nd request - one week goes by - 3rd request - one week goes by - releng ticket to be added as a collaborator Proposal B (two bugzilla pings, four weeks total time): - 1st request - two weeks go by - 2nd request - two weeks go by - releng ticket to be added as a collaborator I also think we can improve the process by having the last bugzilla comment include setting the needsinfo flag. Please share your thoughts on these alternative process steps. [0] https://docs.fedoraproject.org/en-US/epel/epel-policy/#stalled_epel_requests [1] https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ -- Carl George ___ 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: Handling packages with missing dependencies provided by HA-RS repos?
On Thu, Mar 24, 2022 at 5:50 PM Kevin Fenzi wrote: > > On Wed, Mar 23, 2022 at 09:18:08PM -0500, Carl George wrote: > > On Wed, Mar 23, 2022 at 2:54 PM Carl George wrote: > > > > > > Typically EPEL inherits policy from Fedora, diverging when necessary. > > > Here is the corresponding section of Fedora policy. > > > > > > "All package dependencies (build-time or runtime, regular, weak or > > > otherwise) MUST ALWAYS be satisfiable within the official Fedora > > > repositories." > > > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_package_dependencies > > > > > > We don't consider HA or RS part of the base RHEL distribution > > > (referred to in policy as the "Target Base"). However, I don't think > > Well, for 8 and 9... for 7 we do. ;) > > > > we should strictly forbid any dependency on HA or RS packages, because > > > that would require unnecessary duplication of HA/RS packages in EPEL > > > (which is allowed, but shouldn't be required IMO). I suggest a > > > compromise that we can make the policy: > > > > > > "All EPEL package dependencies (build-time or runtime) MUST ALWAYS be > > > satisfiable within the Target Base or EPEL itself. Weak package > > > dependencies are allowed on packages from additional RHEL channels > > > that are not part of the Target Base, such as the HighAvailability > > > channel." > > > > > > -- > > > Carl George > > > > We discussed this a bit further at today's EPEL Steering Committee. > > One alternative that was suggested was to just add the HA and RS repos > > to the target base list. The initial impact of that would be that > > several packages already in EPEL8 would become policy violations and > > would have to be retired. > > Yeah, I guess thats pretty anoying in 8 since we didn't start with them. > ;( > > So, if we did allow weak deps to packages in other non our Base repos, > wouldn't that not actually work for the case that started this thread? > > ie, say I have a foo-plugin package and foo is in a different non epel > base rhel channel and I add a Reccomends for it in epel. People who have > the channel enabled would be fine but if someone else installed > foo-plugin it would just... not work. What I suggested as policy would be to allow weak dependencies on non-base channels, not to incorrectly identify all hard dependencies as weak if they're in these channels. If an EPEL package has a hard dependency, that dependency should be in the target base or EPEL itself. If the dependency actually is weak (optional), it would be useful to allow those to be provided by non-target-base channels. The plugin example is a bit of a grey area. If the software is designed as such that no one uses the plugin directly, but rather the plugin extends the functionality of the main software which is used directly, then I think users can figure out they need to install both the main software and the plugin, regardless of the dependency relationship. This will vary case by case, and we could allowed these by Steering Committee exception only. > > Also could we tell if deps changed? Say I have foo-plugin in epel > Reccommending foo, and RHEL drops foo. None of our 'will it install' or > broken deps type checks will know that it is now not working. ;( As far as I know RHEL doesn't really drop packages, they stay on the CDN for the life of distro. Even if they do get dropped, this seems like an edge case we shouldn't really need to worry too much about. If it happens and it results in an EPEL package not working, we'll know it should have been a Requires and not a Recommends all along, which will lead to either the maintainer adding the necessary dependency to EPEL, or retiring the package with the missing dependency. > > If we don't add HA and RS to the base epel repos, I guess we could just > allow people to build those things they need in epel, but then of course > they get to maintain them. ;( This is already allowed, which is why we have EPEL packages that would need to be retired if HA/RS are added to the target base. > > Perhaps instead of a strict rule we could just ask everything that has > this issue to get an exception? As stated above I'd be fine with an exception workflow if a maintainer feels it's justified to intentionally mislabel a hard dependency as weak, but the general case of truly weak (optional) dependencies from non-target-base channels shouldn't need exceptions IMO. > > Not an easy case. > > kevin > ___ > e
[EPEL-devel] Re: Handling packages with missing dependencies provided by HA-RS repos?
On Thu, Mar 24, 2022 at 3:46 AM Felix Schwarz wrote: > > > Am 24.03.22 um 03:18 schrieb Carl George: > > python-boto3-1.6.1-2.el8 > > python-boto3-1.15.15-1.el8 > > > > python-botocore-1.9.1-2.el8 > > python-botocore-1.18.15-1.el8 > > > > python-fasteners-0.14.1-14.el8 > > python-fasteners-0.14.1-20.el8 > > > > python-oauth2client-4.1.2-6.el8 > > python-oauth2client-4.1.3-9.el8 > > > > python-s3transfer-0.1.13-1.el8 > > python-s3transfer-0.3.4-1.el8 > > That might have implications for the "certbot" package - there is at least one > plugin which requires that stack. *If* the RHEL packages have similar versions > and provide Python 3 modules it might not be a problem (we had some bad > experience with Red Hat's RPMs in EPEL 7/Python 2). > > certbot + plugins provide a comprehensive test suite so as a test one could > do a > test build with the HA repos. If the test suites pass everything should be > fine. > > Unfortunately I'm pretty busy atm. > > Felix > Thanks for pointing these out Felix. I found python-certbot-dns-google and python-certbot-dns-route53 that require some of these packages. I did local mock builds using a custom one off config comprised of RHEL8, RHEL8 HA, and EPEL8 with the above packages excluded. The %check sections of both certbot plugins passed (26 and 17 tests respectively). I don't know if that is sufficient to declare that the dependency version downgrade will have no impact on those plugins, but at least the test suites pass. I'm happy to repeat this step with any other EPEL packages people are aware of that require these packages. -- Carl George ___ 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: Handling packages with missing dependencies provided by HA-RS repos?
On Wed, Mar 23, 2022 at 2:54 PM Carl George wrote: > > On Mon, Mar 14, 2022 at 4:23 PM Troy Dawson wrote: > > > > > > > > On Thu, Mar 10, 2022 at 2:17 PM Diego Herrera wrote: > >> > >> I've been checking the packages that won't install on EPEL [1] and found > >> out that drbd-pacemaker cant get installed > >> because of a missing dependency (pacemaker). While researching why, I saw > >> that pacemaker exists on EPEL7 because it's > >> provided by the HighAvailability repo, but by policy [2] that repo is not > >> a base for EPEL8 nor EPEL9. > >> > >> When I asked on how to handle this cases on the steering meeting, some > >> proposed ideas were: > >> > >> * Rebuild the dependencies as -epel > >> * Retire the packages > >> * Bringing back HA & RS repo > >> > >> The only other package that i've found also has this problem is > >> resalloc-aws that depends on awscli. > >> > >> Is there a policy on this cases? Are EPEL packages allowed to require > >> packages outside of the policy approved? > >> I would like more feedback on how to proceed so we can file bugs for this > >> packages correctly. > >> > >> Package: drbd-pacemaker-9.20.2-1.el9 > >> Error: Problem: conflicting requests - nothing provides pacemaker needed > >> by drbd-pacemaker-9.20.2-1.el9.x86_64 > >> > >> Package: resalloc-aws-1.1-1.el9 > >> Error: Problem: conflicting requests - nothing provides awscli needed by > >> resalloc-aws-1.1-1.el9.noarch > >> > >> Package: drbd-pacemaker-9.17.0-1.el8 > >> Error: Problem: conflicting requests - nothing provides pacemaker needed > >> by drbd-pacemaker-9.17.0-1.el8.x86_64 > >> > >> [1] > >> https://tdawson.fedorapeople.org/epel/willit/epel8/status-wont-install.html > >> [2] https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy > > > > > > Someone can tell me I'm wrong, but I believe if something is in HA or RS in > > RHEL8 or 9 it is fair game for EPEL8 or EPEL9. > > Those packages are currently not being excluded when you request a package > > for epel8 or epel9. > > > > So, my opinion, build pacemaker in EPEL. > > > > Troy > > > > ___ > > 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 > > Typically EPEL inherits policy from Fedora, diverging when necessary. > Here is the corresponding section of Fedora policy. > > "All package dependencies (build-time or runtime, regular, weak or > otherwise) MUST ALWAYS be satisfiable within the official Fedora > repositories." > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_package_dependencies > > We don't consider HA or RS part of the base RHEL distribution > (referred to in policy as the "Target Base"). However, I don't think > we should strictly forbid any dependency on HA or RS packages, because > that would require unnecessary duplication of HA/RS packages in EPEL > (which is allowed, but shouldn't be required IMO). I suggest a > compromise that we can make the policy: > > "All EPEL package dependencies (build-time or runtime) MUST ALWAYS be > satisfiable within the Target Base or EPEL itself. Weak package > dependencies are allowed on packages from additional RHEL channels > that are not part of the Target Base, such as the HighAvailability > channel." > > -- > Carl George We discussed this a bit further at today's EPEL Steering Committee. One alternative that was suggested was to just add the HA and RS repos to the target base list. The initial impact of that would be that several packages already in EPEL8 would become policy violations and would have to be retired. HA8 package EPEL8 package awscli-1.14.50-5.el8 awscli-1.18.156-1.el8 google-api-python-client-1.6.5-3.el8 google-api-python-client-1.6.7-10.el8 python-boto3-1.6.1-2.el8 python-boto3-1.15.15-1.el8 python-botocore-1.9.1-2.el8 python-botocore-1.18.15-1.el8 python-fasteners-0.14.1-14.el8 python-fasteners-
[EPEL-devel] Re: Handling packages with missing dependencies provided by HA-RS repos?
On Mon, Mar 14, 2022 at 4:23 PM Troy Dawson wrote: > > > > On Thu, Mar 10, 2022 at 2:17 PM Diego Herrera wrote: >> >> I've been checking the packages that won't install on EPEL [1] and found out >> that drbd-pacemaker cant get installed >> because of a missing dependency (pacemaker). While researching why, I saw >> that pacemaker exists on EPEL7 because it's >> provided by the HighAvailability repo, but by policy [2] that repo is not a >> base for EPEL8 nor EPEL9. >> >> When I asked on how to handle this cases on the steering meeting, some >> proposed ideas were: >> >> * Rebuild the dependencies as -epel >> * Retire the packages >> * Bringing back HA & RS repo >> >> The only other package that i've found also has this problem is resalloc-aws >> that depends on awscli. >> >> Is there a policy on this cases? Are EPEL packages allowed to require >> packages outside of the policy approved? >> I would like more feedback on how to proceed so we can file bugs for this >> packages correctly. >> >> Package: drbd-pacemaker-9.20.2-1.el9 >> Error: Problem: conflicting requests - nothing provides pacemaker needed by >> drbd-pacemaker-9.20.2-1.el9.x86_64 >> >> Package: resalloc-aws-1.1-1.el9 >> Error: Problem: conflicting requests - nothing provides awscli needed by >> resalloc-aws-1.1-1.el9.noarch >> >> Package: drbd-pacemaker-9.17.0-1.el8 >> Error: Problem: conflicting requests - nothing provides pacemaker needed by >> drbd-pacemaker-9.17.0-1.el8.x86_64 >> >> [1] >> https://tdawson.fedorapeople.org/epel/willit/epel8/status-wont-install.html >> [2] https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy > > > Someone can tell me I'm wrong, but I believe if something is in HA or RS in > RHEL8 or 9 it is fair game for EPEL8 or EPEL9. > Those packages are currently not being excluded when you request a package > for epel8 or epel9. > > So, my opinion, build pacemaker in EPEL. > > Troy > > ___ > 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 Typically EPEL inherits policy from Fedora, diverging when necessary. Here is the corresponding section of Fedora policy. "All package dependencies (build-time or runtime, regular, weak or otherwise) MUST ALWAYS be satisfiable within the official Fedora repositories." https://docs.fedoraproject.org/en-US/packaging-guidelines/#_package_dependencies We don't consider HA or RS part of the base RHEL distribution (referred to in policy as the "Target Base"). However, I don't think we should strictly forbid any dependency on HA or RS packages, because that would require unnecessary duplication of HA/RS packages in EPEL (which is allowed, but shouldn't be required IMO). I suggest a compromise that we can make the policy: "All EPEL package dependencies (build-time or runtime) MUST ALWAYS be satisfiable within the Target Base or EPEL itself. Weak package dependencies are allowed on packages from additional RHEL channels that are not part of the Target Base, such as the HighAvailability channel." -- Carl George ___ 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 Office Hours
The EPEL Steering Committee has implementing monthly office hours for the EPEL project. These will be held on the first Wednesday of each month at 1700 UTC. The openSUSE Heroes team has agreed to let us host the meeting on their Jitsi Meet instance. Please join us at https://meet.opensuse.org/epel with all your EPEL questions. https://discussion.fedoraproject.org/t/join-us-for-the-epel-office-hours-every-month/37235 -- Carl George ___ 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: EPEL9 Rollout Proposals
On Thu, Nov 18, 2021 at 1:32 PM Troy Dawson wrote: > > In our last EPEL Steering Committee meeting, Carl brought up a new proposal > for our epel9 / epel9-next rollout. Sometimes IRC isn't the best way to > explain things like that, it got a little confusing. Carl and I had a good > video chat to clean up confusion and talk about some pros and cons of the > various proposals. > Here are the three proposals. > > * PLAN A > Plan A is basically what we've been working towards for the past couple of > months. > - launch epel9-next now-ish (ideally aligned with c9s launch promotion) > - After RHEL9 goes GA > -- perform a mass branch and mass rebuild to populate epel9 > -- launch epel9 after RHEL9 GA is launched. > > ** Plan A Pros: > - epel9-next and epel9 are only set up once, and not changed > - ready to go now > > ** Plan A Cons: > - complexity and added work of mass branch and mass rebuild > - mass rebuild will have a moderate rate of failure due to buildroot > differences (unshipped devel packages) > - epel9 not available at rhel9 ga > - confusing messaging to packagers: > -- target epel9-next for ~6 months > -- after epel9 exists target that instead, only use epel9-next when needed > - confusing messaging to users: > -- use epel9-next now for c9s and rhel9 beta > -- use epel9-next temporarily at rhel9 launch but don’t leave it enabled > -- use epel9 primarily once it exists > > > * PLAN B > - epel9-next stays the way it is currently setup. > - Setup epel9 using RHEL9 Beta for the buildroot. > -- Pull in any errata as it comes. > -- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB > - Launch epel9 and epel9-next together (In 1-2 weeks). > - When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to RHEL9 > GA > > ** Plan B Pros: > - simple messaging to packagers: > -- epel9 is the primary target, use epel9-next only when needed (same as > epel8-next) > - simple messaging to users: > -- use epel9 everywhere (epel-next-release is a recommends on c9s) > - no mass branching > - no mass rebuild > - No confusion from using the full CentOS Stream buildroot > -- epel9 buildroot will only have AppStream, BaseOS and CRB > > ** Plan B Cons: > - potential for large divergence between rhel9 beta and ga > - changing our messaging right before the launch > > > * PLAN C > - epel9-next stays the way it is currently setup. > - setup up epel9 using c9s for the buildroot > -- Use the repos you would for RHEL9: AppStream, BaseOS, CRB > - freeze epel9 buildroot before c9s switches to 9.1 content > - launch epel9 and epel9-next together (1-2 weeks) > - switch epel9 buildroot from frozen c9s to rhel9 ga later > > ** Plan C Pros: > - simple messaging to packagers: > -- epel9 is the primary target, use epel9-next only when needed (same as > epel8-next) > - simple messaging to users: > -- use epel9 everywhere (epel-next-release is a recommends on c9s) > - no mass branching > - no mass rebuild > - No confusion from using the full CentOS Stream buildroot > -- epel9 buildroot will only have AppStream, BaseOS and CRB > > ** Plan C Cons: > - potential infrastructure complexity of freezing the epel9 buildroot > - changing our messaging right before the launch > > > Please let us know what you think. > If we do choose to go with Plan B or C we will need to make the decision > fairly quickly. > > Troy > > ___ > 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 Closing the loop here, at the 2021-11-24 EPEL Steering Committee meeting we voted and selected plan C. https://meetbot.fedoraproject.org/teams/epel/epel.2021-11-24-21.00.html We are in the process of finishing up the EPEL9 implementation and plan to launch EPEL9 and EPEL9 Next together with a formal announcement very soon. Until then you may notice parts of that implementation coming online (repositories, release packages, etc.) but we recommend waiting until the announcement for official instructions. -- Carl George ___ 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: Mock/Copr default epel-8-* configuration to be changed
On Mon, Nov 22, 2021 at 8:37 AM Vitaly Zaitsev via devel
wrote:
>
> On 22/11/2021 15:00, Pavel Raiskup wrote:
> > - builds will require a valid Red Hat subscription (the no-cost variant is
> >OK as well, though [2])
>
> I'm going to retire all my EPEL8 packages as I can't build/test them in
> mock without any subscriptions.
>
> --
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- de...@lists.fedoraproject.org
> To unsubscribe send an email to 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/de...@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
This has always been allowed. EPEL packagers are not required to
maintain their packages for the entire corresponding RHEL lifecycle.
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#_epel
I will point out that it's trivial to avoid dealing with a
subscription by doing koji scratch builds, or by using the existing
oraclelinux-epel-8-x86_64 mock chroot, or by submitting equivalent
{clone}-epel-8-{arch} chroots to mock-core-configs for your preferred
clone. Mass retiring all of your epel8 packages seems like an
overreaction to me, but it is your choice. If you do decide to go
that route I hope you're welcoming to other maintainers that offer to
co-maintainer your packages to be responsible for the epel8 branch
going forward. Ideally you would also send an email to epel-devel
beforehand to avoid a quick retire/unretire churn for the packages
other maintainers are interested in keeping around.
--
Carl George
___
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: Mock/Copr default epel-8-* configuration to be changed
On Mon, Nov 22, 2021 at 8:27 AM Miroslav Suchý wrote: > > Dne 22. 11. 21 v 15:10 Miro Hrončok napsal(a): > > > > However, enough of my personal views. Since we have not used RHEL for > > copr/mock EPEL buidlroots until now, but we used > > a downstream freely-available RHEL-copy (CentOS Linux), could we not > > continue doing so by using e.g. AlmaLinux? > > For day to day work I would suggest to move to centos-stream + epel-next > (hmm, we do not have a config for that). > > But EPEL is built against RHEL (not Alma, not Rocky). So we either use > default config which will differ from Koji or we > have to fiddle with entitlements: > > https://rpm-software-management.github.io/mock/Feature-rhelchroots > > https://developers.redhat.com/blog/2021/02/10/how-to-activate-your-no-cost-red-hat-enterprise-linux-subscription#step_2__download_no_cost_rhel > > Miroslav > ___ > devel mailing list -- de...@lists.fedoraproject.org > To unsubscribe send an email to 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/de...@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure Agreed, for quick local builds it's fine to use epel8-next (c8s) to verify it builds and then submit the koji build to the epel8 (rhel8) target. If the local build works but the koji build doesn't, you likely have a candidate for an official epel8-next koji build. -- Carl George ___ 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: Mock/Copr default epel-8-* configuration to be changed
On Mon, Nov 22, 2021 at 8:11 AM Miro Hrončok wrote: > > On 22. 11. 21 15:00, Pavel Raiskup wrote: > > - builds will require a valid Red Hat subscription (the no-cost variant is > >OK as well, though [2]) > > I cannot help myself but I consider this very unpleasant for EPEL packagers. > > Getting and configuring the subscription was always so unfriendly for me that > I've been using EPEL mocks even for my RHEL work. This basically means using > EPEL mocks will once again be as complicated as using RHEL. > > However, enough of my personal views. Since we have not used RHEL for > copr/mock > EPEL buidlroots until now, but we used a downstream freely-available RHEL-copy > (CentOS Linux), could we not continue doing so by using e.g. AlmaLinux? > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- de...@lists.fedoraproject.org > To unsubscribe send an email to 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/de...@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure I'm not aware of a RHEL clone that offers all the architectures that EPEL does. As far as I can tell, the three most popular (Alma, Rocky, Oracle) only offer x86_64 and aarch64 but are missing ppc64le and s390x. That said CentOS Linux 8 doesn't offer s390x either, so we already have this problem, but switch the EPEL mock chroot to one of those clones would make the situation worse by also dropping ppc64le. -- Carl George ___ 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: EPEL9 Rollout Proposals
On Fri, Nov 19, 2021 at 5:26 PM Miroslav Suchý wrote: > > Dne 20. 11. 21 v 0:04 Troy Dawson napsal(a): > > Do we keep everything in epel9-next until RHEL9 GA and then do a mass > > branch over and mass rebuild? (Plan A) > > And again with 9.1 GA? And again with 9.2 GA? // I do not expect answer, just > pointing that minor releases should be > part of the solution. > > Miroslav > ___ > 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 Historically most EPEL packages don't need to be rebuilt with every minor release, as RHEL libraries don't change often. When they do need to be rebuilt, it's been left up to the individual maintainers to take care of as their time allows. This has mostly worked OK for us. Plan A would be a departure from the norm, where we do a mass rebuild at 9.0 for a "bootstrap" of epel9 content from epel9-next. At the last EPEL Steering Committee meeting we talked about doing mass rebuilds at every future minor release, but more or less agreed that this would be overkill and would result in a drastic increase in disk usage in the infrastructure. Additionally our existing mass rebuild tooling doesn't account for changes that exist in the epel9-next branches that need to be merged to the epel9 branches before building. Plans B and C are more like the status quo, where packagers target epel9, and do individual package rebuilds as needed after a RHEL minor release. -- Carl George ___ 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 9 Next Bodhi updates: Set lower days to stable limit?
On Fri, Nov 19, 2021 at 12:33 PM Kevin Fenzi wrote: > > On Fri, Nov 19, 2021 at 01:22:32PM -0500, Neal Gompa wrote: > > On Fri, Nov 19, 2021 at 1:15 PM Miro Hrončok wrote: > > > > > > On 19. 11. 21 17:54, Troy Dawson wrote: > > > > > > > > > > > > On Fri, Nov 19, 2021 at 8:46 AM Stephen John Smoogen > > > <mailto:smo...@gmail.com>> wrote: > > > > > > > > On Fri, 19 Nov 2021 at 11:42, Miro Hrončok > > > <mailto:mhron...@redhat.com>> wrote: > > > > > > > > > > Hello EPEL people, > > > > > > > > > > what do you think about setting the Bodhi days to stable limit > > > > to 3 days for > > > > > EPEL 9 Next (at least until RHEL 9 GA)? > > > > > > > > > > > > > I think EPEL-9 Next being based off of Stream with its major changes > > > > should have a small stable limit. 3 days sounds about right. > > > > > > > > > > > > +1 > > > > > > There seem to be a consensus, do I file a ticket at infra, or does the > > > EPSCo > > > need to approve it a meeting? > > > > > > > Please file a ticket with infra about it. > > wow... consensus in 1.5 hours. :) > > Perhaps this should be discussed at the next meeting? To allow > interested parties to actually see it and comment? +1 to putting this on the agenda for next week's meeting. > > Anyhow, I'm personally fine with it, but note that 3 days leaves very > little time for testing. One of those days is likely mirror sync/getting > the update, so interested testers would need to update at least every > day to make sure and not miss out. > > kevin > ___ > 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 -- Carl George ___ 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: EPEL9 Rollout Proposals
On Thu, Nov 18, 2021 at 1:32 PM Troy Dawson wrote: > > In our last EPEL Steering Committee meeting, Carl brought up a new proposal > for our epel9 / epel9-next rollout. Sometimes IRC isn't the best way to > explain things like that, it got a little confusing. Carl and I had a good > video chat to clean up confusion and talk about some pros and cons of the > various proposals. > Here are the three proposals. > > * PLAN A > Plan A is basically what we've been working towards for the past couple of > months. > - launch epel9-next now-ish (ideally aligned with c9s launch promotion) > - After RHEL9 goes GA > -- perform a mass branch and mass rebuild to populate epel9 > -- launch epel9 after RHEL9 GA is launched. > > ** Plan A Pros: > - epel9-next and epel9 are only set up once, and not changed > - ready to go now > > ** Plan A Cons: > - complexity and added work of mass branch and mass rebuild > - mass rebuild will have a moderate rate of failure due to buildroot > differences (unshipped devel packages) > - epel9 not available at rhel9 ga > - confusing messaging to packagers: > -- target epel9-next for ~6 months > -- after epel9 exists target that instead, only use epel9-next when needed > - confusing messaging to users: > -- use epel9-next now for c9s and rhel9 beta > -- use epel9-next temporarily at rhel9 launch but don’t leave it enabled > -- use epel9 primarily once it exists > > > * PLAN B > - epel9-next stays the way it is currently setup. > - Setup epel9 using RHEL9 Beta for the buildroot. > -- Pull in any errata as it comes. > -- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB > - Launch epel9 and epel9-next together (In 1-2 weeks). > - When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to RHEL9 > GA > > ** Plan B Pros: > - simple messaging to packagers: > -- epel9 is the primary target, use epel9-next only when needed (same as > epel8-next) > - simple messaging to users: > -- use epel9 everywhere (epel-next-release is a recommends on c9s) > - no mass branching > - no mass rebuild > - No confusion from using the full CentOS Stream buildroot > -- epel9 buildroot will only have AppStream, BaseOS and CRB > > ** Plan B Cons: > - potential for large divergence between rhel9 beta and ga > - changing our messaging right before the launch > > > * PLAN C > - epel9-next stays the way it is currently setup. > - setup up epel9 using c9s for the buildroot > -- Use the repos you would for RHEL9: AppStream, BaseOS, CRB > - freeze epel9 buildroot before c9s switches to 9.1 content > - launch epel9 and epel9-next together (1-2 weeks) > - switch epel9 buildroot from frozen c9s to rhel9 ga later > > ** Plan C Pros: > - simple messaging to packagers: > -- epel9 is the primary target, use epel9-next only when needed (same as > epel8-next) > - simple messaging to users: > -- use epel9 everywhere (epel-next-release is a recommends on c9s) > - no mass branching > - no mass rebuild > - No confusion from using the full CentOS Stream buildroot > -- epel9 buildroot will only have AppStream, BaseOS and CRB > > ** Plan C Cons: > - potential infrastructure complexity of freezing the epel9 buildroot > - changing our messaging right before the launch > > > Please let us know what you think. > If we do choose to go with Plan B or C we will need to make the decision > fairly quickly. > > Troy > > ___ > 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 Thanks everyone for the feedback so far. I would still like to talk with the Fedora Infra folks in a bit more depth about the difficulty level of each plan, but at this point in time I feel like plan C is the best option because of the benefits. - simple instructions to maintainers - simple instructions for users - no need for a mass rebuild, which is a big time saver - ability to have EPEL9 content ready on day 1 of the RHEL9 GA launch I'm stating this as my opinion right now, not as the final decision. I'll defer that to an EPEL Steering Committee vote of course. -- Carl George ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedorapr
[EPEL-devel] Re: EPEL9 Rollout Proposals
art and have them stay the same. > So, I am not against this idea as well. One thing I would like to > mention here is, even if we can setup this way since rhel 9 beta is > out, we cannot do that same thing during rhel10 time as we might setup > epel10-next way in advance before the rhel10 beta. We cannot keep this > plan consistent going further. I don't think we need to worry about making the exact same plan work for EPEL10 yet. Maybe we decide that our EPEL9 plan doesn't work for EPEL10 and we try something else. Maybe we plan from the start to launch EPEL10 after the RHEL10 Beta. I'd like to make the best choice for EPEL9 now, and then build off that when the time comes for EPEL10. > > > > > * PLAN C > > - epel9-next stays the way it is currently setup. > > - setup up epel9 using c9s for the buildroot > > -- Use the repos you would for RHEL9: AppStream, BaseOS, CRB > > - freeze epel9 buildroot before c9s switches to 9.1 content > > - launch epel9 and epel9-next together (1-2 weeks) > > - switch epel9 buildroot from frozen c9s to rhel9 ga later > > > > ** Plan C Pros: > > - simple messaging to packagers: > > -- epel9 is the primary target, use epel9-next only when needed (same as > > epel8-next) > > - simple messaging to users: > > -- use epel9 everywhere (epel-next-release is a recommends on c9s) > > - no mass branching > > - no mass rebuild > > - No confusion from using the full CentOS Stream buildroot > > -- epel9 buildroot will only have AppStream, BaseOS and CRB > > > > ** Plan C Cons: > > - potential infrastructure complexity of freezing the epel9 buildroot > > - changing our messaging right before the launch > > > > I can see how its advantageous, but I dont like this plan, since there > are some uncertainties, we dont really know when c9s will start > pointing to rhel 9.1, we can only guestimate currently. Even if we > know for sure, we have to ask centos stream folks to freeze their work > until we sort out things on our side. And what if the package versions > changed in rhel9 ga, because they found an issue in that build. We will have a really good idea of when c9s is preparing to switch to 9.1 content. And we don't have to ask CentOS Stream to do anything, we just need to stop syncing the mirror directory that corresponds to the EPEL9 koji target's external repo before 9.1 changes show up in c9s. It is extremely unlikely that a package version will change in a way that is significant to EPEL packages (library soname change) in that frozen time period. > > > > > Please let us know what you think. > > If we do choose to go with Plan B or C we will need to make the decision > > fairly quickly. > > I am okay with either plan A or plan B. > > > > > Troy > > > > ___ > > 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 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 -- Carl George ___ 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: EPEL9 Rollout Proposals
ely unlikely that close to the GA release. Security changes don't change the soname, and dynamically linked packages don't need to be rebuilt. Staticly linked packages are another story, but those are fairly rare in EPEL due to the massive dependency burden of golang and rust. > > > - launch epel9 and epel9-next together (1-2 weeks) > > - switch epel9 buildroot from frozen c9s to rhel9 ga later > > > > ** Plan C Pros: > > - simple messaging to packagers: > > -- epel9 is the primary target, use epel9-next only when needed (same as > > epel8-next) > > - simple messaging to users: > > -- use epel9 everywhere (epel-next-release is a recommends on c9s) > > - no mass branching > > - no mass rebuild > > - No confusion from using the full CentOS Stream buildroot > > -- epel9 buildroot will only have AppStream, BaseOS and CRB > > > > ** Plan C Cons: > > - potential infrastructure complexity of freezing the epel9 buildroot > > - changing our messaging right before the launch > > Another con: breaks a foundational promise of EPEL. > "builds against rhel". Now, of course we don't have that said anywhere, > but some people really really like that it's built against RHEL and will > be quite upset when it's built against stream. :( > Not to say we can't do it, but I bet there will be yelling. I see an easy pivot there of "built against RHEL, once it reaches GA release". I think far more people would be happy about having day 1 EPEL9 packages than would be upset about this slight shift. > > We already sync stream, but this will require us to 'freeze' it, which > could be tricky. I'm specifically interested in how difficult this would be from the infra perspective. That is definitely a factor. > > > Please let us know what you think. > > If we do choose to go with Plan B or C we will need to make the decision > > fairly quickly. > > I like A. ;) > > I think B is risky because of the possible changes between beta and ga, > and I think C is breaking the 'we build against rhel' implied promise as > well as leaving a window with no security updates between branching and > GA. > > kevin > ___ > 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 -- Carl George ___ 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-gevent and pytest-cov in el9
On Fri, Sep 24, 2021 at 3:05 PM Josh Boyer wrote: > > On Fri, Sep 24, 2021 at 4:02 PM Neal Gompa wrote: > > > > On Fri, Sep 24, 2021 at 3:59 PM Josh Boyer wrote: > > > > > > On Fri, Sep 24, 2021 at 3:46 PM Ken Dreyer wrote: > > > > > > > > Hi folks, > > > > > > > > The RHEL 9 composes do not have libev-devel and libuv-devel, so we > > > > cannot build python-gevent on EPEL 9 easily. > > > > > > https://odcs.stream.centos.org/production/CentOS-Stream-9-20210924.0/compose/CRB/x86_64/os/Packages/libuv-devel-1.42.0-1.el9.x86_64.rpm > > > > > > You could request libev-devel in the composes. I remain confused why > > > it has to be in the compose though, because libev and it's devel > > > package are accessible in the CentOS Stream 9 buildroots today. > > > > > > > We can't use them in EPEL if they're not in CRB. > > Yes, that's what everyone keeps telling me. I don't understand why. EPEL builds against published RHEL content, not the CentOS Stream buildroot. Having a package available in the CentOS Stream buildroot doesn't make it accessible to EPEL builds. We can't change EPEL to use the CentOS Stream buildroot because that will cause some EPEL packages to not be installable on RHEL. On a related note, EPEL 9 Next _is_ being set up to build against the CentOS Stream 9 buildroot. This works for EPEL Next because it explicitly targets the next minor release of RHEL (i.e. CentOS Stream). This will allow more packages to be built, at the cost of potentially confusing packagers when their package builds successfully for EPEL 9 Next but not for EPEL 9. EPEL 8 Next currently builds against published CentOS Stream 8 content. If things go well with EPEL 9 Next using the CentOS Stream 9 buildroot, EPEL 8 Next may switch to using the CentOS Stream 8 buildroot in the future. > > 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 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: Rebasing nlohmann_json to 3.6.1 in EPEL7
On Mon, Aug 2, 2021 at 8:38 PM Kyle Knoepfel wrote: > > Hi all, > > I am rebasing nlohmann_json from 3.3.1 to 3.6.1 in epel7 to agree with the > version in epel8. This change is necessary for supporting a new epel7 package > jsonnet. > > Bodhi update: > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-b95dc99fad > > Assuming no issues or objections I will push it in to the stable when > possible. > > Thanks, > Kyle > ___ > 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 How compatible is this upgrade? You may need to take additional steps as detailed in the incompatible upgrade policy. https://fedoraproject.org/wiki/EPEL_incompatible_upgrades_policy https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Package_maintenance_and_update_policy -- Carl George ___ 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: and about missing binary packages Re: proposed recommendation - missing devel packages
Yes, this would also apply to that scenario. You can create a
lame-epel package that has a lame subpackage, as long as none of the
files conflict with lame-devel and lame-libs from RHEL8. You would
also want to relax the requirement on lame-libs by removing the
%{release}, so that way you can bump the release on the epel package
and still have the requirement satisfied by the RHEL lame-libs.
-Requires: %{name}-libs = %{version}-%{release}
+Requires: %{name}-libs = %{version}
On Thu, Jul 1, 2021 at 5:31 PM Sérgio Basto wrote:
>
> Hi,
>
> Sorry, this may be a little Off-topic but we notice that lame package
> from RHEL 8 (1) is not shipping lame package with binaries and in this
> case lame-devel is provided along with lame-libs , can we apply the
> same rules ? is completely a different situation ?
>
>
> (1)
> https://git.centos.org/rpms/lame/blob/c8/f/SPECS/lame.spec
>
>
> On Thu, 2021-07-01 at 15:05 -0700, Troy Dawson wrote:
> > I believe this is a recommendation, versus a policy.
> > I wanted to get people's thoughts on it, and if ya'll like it, put it
> > in the documentation.
> >
> > In Red Hat Enterprise Linux (RHEL) 8, Red Hat decided to not ship all
> > packages that are built from RHEL spec files. This will also be true
> > of RHEL 9, and possibly future RHEL releases. These missing packages
> > are usually -devel packages and may impact an EPEL package build.
> > If your EPEL package is impacted by a missing -devel package, do the
> > following.
> >
> > 1 - Request the package be added to RHEL 8 and 9 CRB repository.
> > -- To initiate this process, please file a bug in
> > https://bugzilla.redhat.com and request it be added to RHEL 8 and 9.
> > Report the bug against the "CentOS Stream" version of the "Red Hat
> > Enterprise Linux 8" and/or "Red Hat Enterprise Linux 9" product.
> > -- Be sure to say that it is impacting an EPEL build, and which package
> > it is impacting.
> >
> > 2 - Create an epel package that only has the missing packages.
> > -- Be prepared to maintain this package as long as it is needed.
> > -- It is recommended that you name it -epel
> > -- It is recommended that you add the epel-packaging-sig group as a co-
> > maintainer
> > -- It qualifies for an exception to the review process[1] so you can
> > request the repo with
> > --- fedpkg request-repo --exception -epel
> > -- If you need help building this, ask for help. We have some
> > examples.
> >
> > 3 - When/If the missing package(s) are added to RHEL CRB, retire your -
> > epel package.
> >
> > ---
> > Sorry, this is a little rushed. I wanted to get something out sooner,
> > rather than later.
> >
> > Troy
> >
> > [1] -
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process
> > - Third bullet point
>
> --
> Sérgio M. B.
> ___
> 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
--
Carl George
___
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: proposed recommendation - missing devel packages
This looks great so far to me. Should we also encourage/require modifying the release to have a leading `0.` so that it will upgrade cleanly when/if RHEL adds the relevant subpackage? On Thu, Jul 1, 2021 at 5:30 PM Kevin Fenzi wrote: > > On Thu, Jul 01, 2021 at 03:05:50PM -0700, Troy Dawson wrote: > > I believe this is a recommendation, versus a policy. > > I wanted to get people's thoughts on it, and if ya'll like it, put it in > > the documentation. > > > > In Red Hat Enterprise Linux (RHEL) 8, Red Hat decided to not ship all > > packages that are built from RHEL spec files. This will also be true of > > RHEL 9, and possibly future RHEL releases. These missing packages are > > usually -devel packages and may impact an EPEL package build. > > If your EPEL package is impacted by a missing -devel package, do the > > following. > > > > 1 - Request the package be added to RHEL 8 and 9 CRB repository. > > -- To initiate this process, please file a bug in > > https://bugzilla.redhat.com and request it be added to RHEL 8 and 9. Report > > the bug against the "CentOS Stream" version of the "Red Hat Enterprise > > Linux 8" and/or "Red Hat Enterprise Linux 9" product. > > -- Be sure to say that it is impacting an EPEL build, and which package it > > is impacting. > > > > 2 - Create an epel package that only has the missing packages. > > -- Be prepared to maintain this package as long as it is needed. > > -- It is recommended that you name it -epel > > --- It cannot be named (ie, the same name as the rhel source > package name). > > > -- It is recommended that you add the epel-packaging-sig group as a > > co-maintainer > > -- It qualifies for an exception to the review process[1] so you can > > request the repo with > > --- fedpkg request-repo --exception -epel > > -- If you need help building this, ask for help. We have some examples. > > -- keep it in sync with the RHEL version, upgrade when they do. > > > > > 3 - When/If the missing package(s) are added to RHEL CRB, retire your -epel > > package. > > > > --- > > Sorry, this is a little rushed. I wanted to get something out sooner, > > rather than later. > > Looks great to me aside the nitpicks above. > > kevin > ___ > 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 -- Carl George ___ 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 8 Next is now available
Howdy folks, On behalf of the EPEL Steering Committee, I'm happy to announce the availability of EPEL 8 Next. This is an additional repository that allows package maintainers to build against CentOS Stream 8 instead of RHEL 8. This is sometimes necessary when CentOS Stream contains an upcoming RHEL library rebase, or if an EPEL package has a minimum version build requirement that is already in CentOS Stream but not yet in RHEL. You can read more about it in the wiki [0]. Special thanks goes out to the Fedora Release Engineering team for their help implementing this. [0] https://fedoraproject.org/wiki/EPEL_Next -- Carl George ___ 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: proposal: EPEL 8 Next
Howdy again folks, I know people have been curious about what happened with this proposal. I apologize for the lack of updates in this thread. The proposal was approved by unanimous vote by the EPEL Steering Committee last October [0]. It has been a regular topic at the weekly committee meetings since then, with slow but steady progress. I'm happy to report that we are near completion of the work to launch EPEL Next. Initial documentation is on the wiki [1]. Fedpkg 1.40-6 [2] added support for requesting epel8-next branches, and has been widely available since April. The epel-next-release subpackage is currently available in the testing repo [3]. There is already one package available in the repo (qt5-qtwebkit [4]), which we used to verify the pipeline worked correctly. Let me know if there is anything else you would like to see in the documentation, especially FAQ items [5]. I would also appreciate any testing and karma on the epel-next-release bodhi update [2]. If you have a package that requires an EPEL Next rebuild (mainly qt packages currently), go ahead and try the workflow [6] and report any issues. [0] https://meetbot.fedoraproject.org/teams/epel/epel.2020-10-23-21.01.html [1] https://fedoraproject.org/wiki/EPEL_Next [2] https://src.fedoraproject.org/rpms/fedpkg/c/ee2d8465803e11c236ae764d445b99593d835353?branch=rawhide [3] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-159d68a2ef [4] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2021-c0fcb78eb0 [5] https://fedoraproject.org/wiki/EPEL_Next#FAQ [6] https://fedoraproject.org/wiki/EPEL_Next#Example_Workflow On Tue, Sep 8, 2020 at 11:00 PM Carl George wrote: > > Howdy folks, > > A large part of my day job is working on CentOS Stream. Naturally I would > like it to be successful and have wide adoption. I know that EPEL will play > a big role in this success. EPEL is extremely popular. Many users consider > RHEL and CentOS unusable without it. > > The problem we are facing is that EPEL 8 cannot be 100% compatible with > RHEL/CentOS 8 and CentOS 8 Stream at the same time. It is not uncommon for > RHEL to ship library soname changes in minor releases. In the RHEL 8 cycle, > those changes are showing up in CentOS 8 Stream first. EPEL 8 builds > against the latest RHEL 8 release. This can result in EPEL 8 packages that > are uninstallable on CentOS 8 Stream due to the library differences. One > prominent example we have already seen is llvm-libs, which has increased its > library soname in every RHEL 8 minor release so far. Another increase is > planned for RHEL 8.3, which has already been released in CentOS 8 Stream. > There are likely other incompatibilities that haven't been noticed yet. I > expect this problem to grow worse as RHEL development continues and more > packages are added to EPEL 8. This situation is hurting the adoption of > CentOS Stream. > > To solve this problem, I am proposing that we create a new repository called > EPEL 8 Next. > > - built against CentOS 8 Stream > - opt-in for packagers (must request epel8-next dist-git branch) > - opt-in for users (part of epel-release but disabled by default) > - used *with* epel8, not *instead of* > > This will provide EPEL packagers a place where they can update their > packages when necessary to be compatible with CentOS 8 Stream. These > packages would also be useful for RHEL 8 users during the gap between a RHEL > minor release and the equivalent CentOS 8 Linux rebuild. In theory this > repository should also be directly consumable by RHEL 8 Beta releases. > Similar to RHEL itself, breaking changes could be permitted in epel8-next in > preparation for delivering them to epel8 around the time of the next RHEL > minor release. > > This proposal may sound similar to epel8-playground. However, that was > still built against RHEL 8, so it didn't solve the compatibility issue with > CentOS 8 Stream. This proposal does draw on lessons learned from the > playground experiment. > > - no automatic builds via packages.cfg > - opt-in rather than opt-out > - layering on top of epel8, rather than duplicating content > > I first suggested this idea at the last EPEL Steering Committee meeting, and > we plan to discuss it again during the next one. Please share your thoughts > on this proposal. > > -- > Carl George -- Carl George ___ 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: What about future EPEL for Centos ?
I can confirm, this issue affects very few EPEL packages, less than 1% (excluding packages that don't install on RHEL8 either) [0]. The numbers were very similar when RHEL was 8.3 and CS8 tracked 8.4 content. Most of those got resolved with the RHEL 8.4 release, but in exchange CS8 now has that qt5 rebase which is coming in 8.5. These problems are short lived (~6 months), small in number, and we'll see even fewer of them over time as RHEL maintainers do fewer rebases later in the RHEL lifecycle. We also plan to make epel-next a fairly seamless experience for CS8 users by having epel-release recommend epel-next-release if centos-stream-release is installed [1]. [0] https://twitter.com/carlwgeorge/status/1396960645250158593 [1] https://src.fedoraproject.org/rpms/epel-release/pull-request/13 On Mon, Jun 7, 2021 at 10:53 AM Matthew Miller wrote: > > On Mon, Jun 07, 2021 at 01:51:36PM +, john tatt wrote: > > I mean: will Epel follow Centos Stream and in this case not surely be > > compatible with RHEL 8 ?, or > > Troy answered the overall questions separately, but... in practice, I expect > this to be a very small issue. How often has it been that RHEL minor updates > have required EPEL packages to be rebuilt, or EPEL packages built on the > latest to not install on older point-releases of RHEL? I'm sure it happens > occasionally, but it's not the typical case. > > > -- > Matthew Miller > > Fedora Project Leader > ___ > 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 -- Carl George ___ 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: dpkg Requires po4a >= 0.59 on epel 8 but version available is po4a-0.52-4.el8
PowerTools is the CentOS equivalent of the RHEL CRB repository. EPEL
doesn't have any control over it. You'll have to convince the RHEL
maintainer to rebase that package.
https://bugzilla.redhat.com/enter_bug.cgi?product=Red Hat Enterprise
Linux 8&component=po4a&version=CentOS Stream
On Tue, May 11, 2021 at 6:13 PM Sérgio Basto wrote:
>
> Hi,
> Since this commit [1] I need po4a >= 0.59 to build dpkg , but [2],
> po4a is in powertools repo [3] , can we do something to update it ?
>
> Thank you.
>
>
> [1]
> https://github.com/guillemj/dpkg/commit/a74a91310260efe55cc986506fe208ae2776a45a
>
> [2]
> https://git.centos.org/rpms/po4a/
> import po4a-0.52-4.el8 CentOS Sources committed 2 years ago
>
> [3]
> dnf repoquery po4a --qf "%{repoid} %{sourcerpm}" --quiet
> powertools po4a-0.52-4.el8.src.rpm
>
> --
> Sérgio M. B.
> ___
> 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
--
Carl George
___
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: python39 in EPEL7
I think it's a fine idea, but I don't personally need it and don't have time to help. I think redefining %__python3 to /usr/bin/python3.9 on a per-specfile basis is fine, as long as we leave the default value (/usr/bin/python3.6) from RHEL alone. I'm not a fan of the %__python3_other macros, and would be happy to see them go away when python34 is retired (which can happen independently of python3.9). On Wed, Apr 7, 2021 at 2:36 AM Miro Hrončok wrote: > > On 07. 04. 21 4:50, Carl George wrote: > > What do you mean by support? The only thing EPEL supports (using the > > term loosely) is enabling Fedora packagers to branch and build their > > packages for EPEL. Any maintainer of the Fedora python3.9 package (or > > any related package necessary for bootstrapping) can request an epel7 > > branch and start building. The main thing to be aware of is to comply > > with EPEL policy [0], especially the part about not > > replacing/disturbing the base distribution. RHEL7 includes python3, > > so an epel7 python3.9 build would need to ensure it doesn't conflict > > with any filesystem paths from that package. > > > I believe the confusion is my fault. > > By "support" I've meant: Does EPEL-devel generally agree that adding Python > 3.9 > to EPEL 7 is a good idea, even if we don't phase out Python 3.4 at the same > time? > > E.g. building RPMs for Python 3.9 in EPEL would require redefining %__python3 > (or %__python3_other). > > -- > 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 on the list, report it: > https://pagure.io/fedora-infrastructure -- Carl George ___ 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: python39 in EPEL7
What do you mean by support? The only thing EPEL supports (using the term loosely) is enabling Fedora packagers to branch and build their packages for EPEL. Any maintainer of the Fedora python3.9 package (or any related package necessary for bootstrapping) can request an epel7 branch and start building. The main thing to be aware of is to comply with EPEL policy [0], especially the part about not replacing/disturbing the base distribution. RHEL7 includes python3, so an epel7 python3.9 build would need to ensure it doesn't conflict with any filesystem paths from that package. [0] https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy On Tue, Mar 30, 2021 at 8:38 AM Pim Rupert wrote: > > Hello, > > I am posting to gather if there is enough support to provide python39 in EPEL. > > Currently, EL7 users wanting to run modern python apps under uwsgi can only > use uwsgi-plugin-pyton36@epel. New Django releases are expected to require > 3.8 or higher. There is a rh-python38 SCL, but this version does not have a > compatible uwsgi-plugin. > > From https://bugzilla.redhat.com/show_bug.cgi?id=1781940 I gather that there > is interest in getting python39 in EPEL. I talked to Miro Hrončok, who was > willing to work on packaging, if there would be sufficient support from EPEL. > > Thanks, > > Pim > ___ > 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 -- Carl George ___ 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: EPEL7 python3/python36 standardization
I had originally hoped to limit this guideline change to EPEL7's
python36 packages, not EPEL7's python34 packages or anything about
EPEL8. But I do see the appeal of taking it a step further to lay out
the guidelines for all EPEL python packages. The overall intent is to
have EPEL python package prefixes match the RHEL python stack they are
intended to work with. That means the recommended prefixes for EPEL7
would be python and python3. The recommended prefixes for EPEL8 would
be python2, python3, and python38.
Regarding EPEL7's python34 packages, all the changes discussed here
can take place without modifying the
python%{python3_other_pkgversion}- (python34-)
subpackages. EPEL7's python34 packages should just be retired as that
Python version is EOL upstream, but so far no one (myself included)
has stepped up to drive that effort. I don't know if it's worth the
effort, as surely some will complain about it being removed,
regardless of the upstream status.
I think a tracker bug would only be necessary if we made the prefix
recommendations a MUST. As a SHOULD, it would be fine to let packages
get corrected naturally over time. The important piece would be to
have the guideline in place for package reviews to reference, to
prevent any further packages using non-standard prefixes from being
added.
On Thu, Jan 21, 2021 at 11:28 AM Kevin Fenzi wrote:
>
> On Thu, Jan 21, 2021 at 12:19:39AM -0600, Carl George wrote:
> > Howdy folks,
> >
> > RHEL7 ships Python 3.6 packages using the python3 prefix. Currently
> > EPEL7 contains Python 3.6 packages using both the python3 and python36
> > prefixes. Thanks to the foresight and preparation work of the Red Hat
> > Python Maintenance team, these work interchangeably when using the
> > %python_provide macro. However the situation is still confusing for
> > packagers and users. We never formalized guidelines on which prefix
> > to use. I would like to change that. I propose that we standardize
> > on the python3 prefix to match RHEL7 packages and document in EPEL
> > guidelines that maintainers SHOULD use the python3 prefix.
> >
> > Transitioning packages is straightforward. Packages using a
> > python%{python3_pkgversion}- subpackage can simply rename it to
> > python3-. If the top level package is already python3-,
> > then the subpackage can be converted into the top level package. In
> > both cases, `%python_provide python3-` handles the necessary
> > provides and obsoletes. This work doesn't need to happen all at once,
> > and maintainers can opt in as they have time. We already have a mix
> > of prefixes, this is just about nudging towards python3 as the correct
> > prefix.
> >
> > Please share your feedback, and I'll present this proposal and the
> > feedback to the EPEL Steering Committee.
>
> Seems like anoying churn to change them, but I guess standardizing is
> good. Perhaps we could generate a list of python36 and python34
> subpackages that need changing and make a tracker bug and the
> epel-packagers sig could drive forward filing bugs/pr's/just fixing
> these?
>
> For epel8: I see there's one python38 package in epel8 ( python38-radicale3 )
> do we want to also standardize there also to python3-name? Since there's
> multiple python stacks there we really might have need for being more
> specific there, so that might be fine, but we should probibly note it.
>
> kevin
> ___
> 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
--
Carl George
___
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
[EPEL-devel] Re: EPEL7 python3/python36 standardization
I'm not sure I understand your question. This proposal is about python36 packages, not the existing python34 packages or hypothetical python38 packages. In any case, packages shouldn't be requiring python* directly. They automatically get a requirement on `python(abi) = X.Y` that serves this purpose. On Thu, Jan 21, 2021 at 4:57 AM Andrew C Aitchison wrote: > > > On Thu, 21 Jan 2021, Carl George wrote: > > > RHEL7 ships Python 3.6 packages using the python3 prefix. Currently > > EPEL7 contains Python 3.6 packages using both the python3 and python36 > > prefixes. Thanks to the foresight and preparation work of the Red Hat > > Python Maintenance team, these work interchangeably when using the > > %python_provide macro. However the situation is still confusing for > > packagers and users. We never formalized guidelines on which prefix > > to use. I would like to change that. I propose that we standardize > > on the python3 prefix to match RHEL7 packages and document in EPEL > > guidelines that maintainers SHOULD use the python3 prefix. > > Do we need to be explicit about how we spell any value of these keys > - e.g. should it be >Requires: python >= 38 > or >Requires: python >= 3.8 > ? > > -- > Andrew C. Aitchison Kendal, UK > and...@aitchison.me.uk > ___ > 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 -- Carl George ___ 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
[EPEL-devel] Re: EPEL7 python3/python36 standardization
Agreed. And if a maintainer decides to stick with the python36 name, they MUST provide the equivalent python3 name. I've captured those for what I'll add to the guidelines. On Thu, Jan 21, 2021 at 4:30 AM Miro Hrončok wrote: > > On 21. 01. 21 7:19, Carl George wrote: > > I propose that we standardize > > on the python3 prefix to match RHEL7 packages and document in EPEL > > guidelines that maintainers SHOULD use the python3 prefix. > > I'm fine with that, is we also say they MUST use %python_provide (or that the > packages MUST provide/obsolete python36-...). > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > -- Carl George ___ 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
[EPEL-devel] EPEL7 python3/python36 standardization
Howdy folks,
RHEL7 ships Python 3.6 packages using the python3 prefix. Currently
EPEL7 contains Python 3.6 packages using both the python3 and python36
prefixes. Thanks to the foresight and preparation work of the Red Hat
Python Maintenance team, these work interchangeably when using the
%python_provide macro. However the situation is still confusing for
packagers and users. We never formalized guidelines on which prefix
to use. I would like to change that. I propose that we standardize
on the python3 prefix to match RHEL7 packages and document in EPEL
guidelines that maintainers SHOULD use the python3 prefix.
Transitioning packages is straightforward. Packages using a
python%{python3_pkgversion}- subpackage can simply rename it to
python3-. If the top level package is already python3-,
then the subpackage can be converted into the top level package. In
both cases, `%python_provide python3-` handles the necessary
provides and obsoletes. This work doesn't need to happen all at once,
and maintainers can opt in as they have time. We already have a mix
of prefixes, this is just about nudging towards python3 as the correct
prefix.
Please share your feedback, and I'll present this proposal and the
feedback to the EPEL Steering Committee.
--
Carl George
___
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
[EPEL-devel] Re: proposal: EPEL 8 Next
Thanks for looking over the plan Kevin. 1. I wasn't planning any changes for bugzilla. I think it's appropriate for the bug reports to be filed against the epel8 component. Typically there should be an epel8 branch already when an epel8-next branch is requested. The only exception I can imagine is if a package has a dependency on a package that is in CentOS Stream but isn't in a RHEL GA release yet. Even then, it would only be a temporary situation, because within six months that package would make it into RHEL and then the package should be built in epel8, not epel8-next. Do you think it would be worthwhile for fedscm-admin to enforce a requirement of an epel8 branch before allowing the creation of an epel8-next branch? 2. I'm perfectly fine waiting until after F33 is done. That makes lots of sense. On Sat, Oct 3, 2020 at 12:07 PM Kevin Fenzi wrote: > > On Thu, Oct 01, 2020 at 11:12:28PM -0500, Carl George wrote: > > Here is my rough outline of the steps required to implement this proposal. > > I imagine things would happen roughly in this order, but some things could > > probably take place in parallel. > > > > 1. EPEL Steering Committee approves the proposal > > 2. koji changes: > > - create CentOS Stream 8 external repo > > - create epel8-next build target (inheriting from epel8) > > - dist macro override for that target > > 3. create PDC entries > > 4. update fedscm-admin with branch SLAs > > 5. configure dist-git to allow branch name > > 6. update pungi config > > 7. add epel-next-repo subpackage to epel-release > > 8. add epel8-next release in bodhi > > 9. document in the wiki > > 10. announcement email > > > > Please let me know if I'm missing anything. > > Looks pretty good to me, but two things: > > 1. I assume (but good to ask) that we are not going to change anything > in bugzilla? ie, bug reports should just go against the epel component? > Of course now that playground is 'seperate' and next will also be, would > we ever have cases where we have a component without epel branch, but > with playground and/or next? And what would we do for bugs there? > > 2. We are heading into final freeze for Fedora 33 next tuesday, so not > sure how much will get done until f33 is out the door. Is it ok to do > this after? Some of it could be done with freeze breaks and such, but > might be easier just to do it all at once after f33 freeze is over? > > Thanks much for putting this together! > > kevin > -- > > > > > On Wed, Sep 23, 2020 at 8:43 PM Carl George wrote: > > > > > > I agree, using .el8.next for the dist macro makes the most sense. This > > > will > > > enable maintainers to use a similar workflow to Fedora branches, where > > > older > > > branches can be fast forwarded, and the same commit can be built for > > > different targets but still have different NVRs in Koji. Here is an > > > example > > > workflow for a fictional foo package that already exists in Fedora. > > > > > > - request epel8 branch > > > - merge master branch to epel8 branch > > > - build epel8 branch, resulting in foo-1-1.el8 > > > - realize it won't install on CentOS Stream due to a library difference > > > - request epel8-next branch > > > - merge epel8 branch to epel8-next branch > > > - build epel8-next branch, resulting in foo-1-1.el8.next > > > > > > After the next RHEL 8 minor release (when that library difference affects > > > everyone), the maintainer can increment the release on the epel8 branch > > > and > > > proceed as usual. > > > > > > On Sun, Sep 20, 2020 at 1:31 PM Kevin Fenzi wrote: > > > > > > > > On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote: > > > > > At the EPEL Steering Committee last week, we had an extensive > > > > > discussion of > > > > > this proposal, specifically focused on how to handle the dist macro. > > > > > I > > > > > believe these are the possible choices. > > > > > > > > > > * keep dist the same as epel8 (.el8) > > > > > > > > > > RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using > > > > > .el8 for > > > > > dist. It would make sense to continue using the same dist for EPEL > > > > > Next. > > > > > However, this would put a little more work on packagers. They would > > > > > not be > > > > > able to build the same commit for both EPEL an
[EPEL-devel] Re: proposal: EPEL 8 Next
Here is my rough outline of the steps required to implement this proposal. I imagine things would happen roughly in this order, but some things could probably take place in parallel. 1. EPEL Steering Committee approves the proposal 2. koji changes: - create CentOS Stream 8 external repo - create epel8-next build target (inheriting from epel8) - dist macro override for that target 3. create PDC entries 4. update fedscm-admin with branch SLAs 5. configure dist-git to allow branch name 6. update pungi config 7. add epel-next-repo subpackage to epel-release 8. add epel8-next release in bodhi 9. document in the wiki 10. announcement email Please let me know if I'm missing anything. On Wed, Sep 23, 2020 at 8:43 PM Carl George wrote: > > I agree, using .el8.next for the dist macro makes the most sense. This will > enable maintainers to use a similar workflow to Fedora branches, where older > branches can be fast forwarded, and the same commit can be built for > different targets but still have different NVRs in Koji. Here is an example > workflow for a fictional foo package that already exists in Fedora. > > - request epel8 branch > - merge master branch to epel8 branch > - build epel8 branch, resulting in foo-1-1.el8 > - realize it won't install on CentOS Stream due to a library difference > - request epel8-next branch > - merge epel8 branch to epel8-next branch > - build epel8-next branch, resulting in foo-1-1.el8.next > > After the next RHEL 8 minor release (when that library difference affects > everyone), the maintainer can increment the release on the epel8 branch and > proceed as usual. > > On Sun, Sep 20, 2020 at 1:31 PM Kevin Fenzi wrote: > > > > On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote: > > > At the EPEL Steering Committee last week, we had an extensive discussion > > > of > > > this proposal, specifically focused on how to handle the dist macro. I > > > believe these are the possible choices. > > > > > > * keep dist the same as epel8 (.el8) > > > > > > RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using .el8 > > > for > > > dist. It would make sense to continue using the same dist for EPEL Next. > > > However, this would put a little more work on packagers. They would not > > > be > > > able to build the same commit for both EPEL and EPEL Next because the NVR > > > will conflict in Koji. In simple rebuild situations, this is not a > > > problem > > > because at a minimum the release will be higher. But if a packager wanted > > > to update the package in both EPEL and EPEL Next, they will need to first > > > update and build it in EPEL, then bump the release and build it in EPEL > > > Next. This isn't ideal, but isn't terrible either, and can be partially > > > mitigated by good documentation around EPEL Next workflows. > > > > > > * modify dist to always be higher than epel8 (.el8.next or similar) > > > > > > In EPEL Next we could define dist to a string that RPM evaluates higher > > > than > > > .el8, such as .el8.next. This would allow EPEL and EPEL Next branches to > > > be > > > in sync and the same commit could be built for both targets. The higher > > > dist would ensure the upgrade path works. > > > > I think this makes the most sense and will help packages workflows the > > best. > > > > kevin > > ___ > > 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 > > > > -- > Carl George -- Carl George ___ 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
[EPEL-devel] Re: proposal: EPEL 8 Next
I agree, using .el8.next for the dist macro makes the most sense. This will enable maintainers to use a similar workflow to Fedora branches, where older branches can be fast forwarded, and the same commit can be built for different targets but still have different NVRs in Koji. Here is an example workflow for a fictional foo package that already exists in Fedora. - request epel8 branch - merge master branch to epel8 branch - build epel8 branch, resulting in foo-1-1.el8 - realize it won't install on CentOS Stream due to a library difference - request epel8-next branch - merge epel8 branch to epel8-next branch - build epel8-next branch, resulting in foo-1-1.el8.next After the next RHEL 8 minor release (when that library difference affects everyone), the maintainer can increment the release on the epel8 branch and proceed as usual. On Sun, Sep 20, 2020 at 1:31 PM Kevin Fenzi wrote: > > On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote: > > At the EPEL Steering Committee last week, we had an extensive discussion of > > this proposal, specifically focused on how to handle the dist macro. I > > believe these are the possible choices. > > > > * keep dist the same as epel8 (.el8) > > > > RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using .el8 for > > dist. It would make sense to continue using the same dist for EPEL Next. > > However, this would put a little more work on packagers. They would not be > > able to build the same commit for both EPEL and EPEL Next because the NVR > > will conflict in Koji. In simple rebuild situations, this is not a problem > > because at a minimum the release will be higher. But if a packager wanted > > to update the package in both EPEL and EPEL Next, they will need to first > > update and build it in EPEL, then bump the release and build it in EPEL > > Next. This isn't ideal, but isn't terrible either, and can be partially > > mitigated by good documentation around EPEL Next workflows. > > > > * modify dist to always be higher than epel8 (.el8.next or similar) > > > > In EPEL Next we could define dist to a string that RPM evaluates higher than > > .el8, such as .el8.next. This would allow EPEL and EPEL Next branches to be > > in sync and the same commit could be built for both targets. The higher > > dist would ensure the upgrade path works. > > I think this makes the most sense and will help packages workflows the > best. > > kevin > ___ > 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 -- Carl George ___ 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
[EPEL-devel] Re: proposal: EPEL 8 Next
At the EPEL Steering Committee last week, we had an extensive discussion of this proposal, specifically focused on how to handle the dist macro. I believe these are the possible choices. * keep dist the same as epel8 (.el8) RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using .el8 for dist. It would make sense to continue using the same dist for EPEL Next. However, this would put a little more work on packagers. They would not be able to build the same commit for both EPEL and EPEL Next because the NVR will conflict in Koji. In simple rebuild situations, this is not a problem because at a minimum the release will be higher. But if a packager wanted to update the package in both EPEL and EPEL Next, they will need to first update and build it in EPEL, then bump the release and build it in EPEL Next. This isn't ideal, but isn't terrible either, and can be partially mitigated by good documentation around EPEL Next workflows. * modify dist to always be higher than epel8 (.el8.next or similar) In EPEL Next we could define dist to a string that RPM evaluates higher than .el8, such as .el8.next. This would allow EPEL and EPEL Next branches to be in sync and the same commit could be built for both targets. The higher dist would ensure the upgrade path works. * modify dist to reflect future rhel version (.el8_3) This is similar to the previous choice as far as the upgrade path. It would make things a bit more obvious during the CentOS Linux rebuild gap. For example, a user who upgrades from RHEL 8.2 to 8.3 could grab a .el8_3 build from EPEL Next if the EPEL package hasn't been rebuilt yet. However, the dist could be misleading. Building against CentOS Stream at a given point in time doesn't necessarily give you all the libraries that will be in the next final RHEL minor release. There will be situations early in the cycle where some libraries have changed and others that will haven't yet. Additionally, there will be a short period of time late in the cycle where CentOS Stream will have release+2 content prior to release+1 reaching RHEL GA. Leaving the minor release out of the dist leaves us more wiggle room on user expectations. We need to make a decision on dist before moving further. Here are some other thoughts from the meeting: - epel-next-release as a subpackage of epel-release - automatic nightly compose or bodhi enablement? - start enumerating the steps necessary to move forward (WIP) On Wed, Sep 9, 2020 at 2:55 PM José Abílio Matos wrote: > > On Wednesday, September 9, 2020 5:56:43 PM WEST Patrick Riehecky wrote: > > > From a mulit-language perspective, I prefer not to use '4' in place of > > > the English word 'for'. It makes the translation work a bit wonky. > > > Not only that, do not forget the meaning/association of 4 in different > cultures. :-) > > > -- > > José Abílio > > ___ > 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 -- Carl George ___ 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
[EPEL-devel] Re: proposal: EPEL 8 Next
> So, maintainers would need to be careful to make sure epel8-next or > whatever packages are rpm 'newer' at all times to make this work right? > Or I guess if they were fixing soname issues like above, dnf might be > smart enough to pull in the next version anyhow even if it was lower > than the epel8 one (unless the user used --best). Yes, I believe dnf helps us out here as you described. We could also document that packagers should take care to ensure the upgrade path works from epel8 to epel8-next, similar to Fedora branches. Fedora has the added benefit of the dist macro always ensuring the release field is higher on higher branches, but in our cases it's .el8 for both. Maybe we could consider redefining dist for epel8-next builds to accomplish the same thing, but I'm not sure it's worth the effort. > So, say I have package foo that needs a rebuild to work with stream. > I request a branch, do a build and everything there is happy. > Now, 8.x comes out and the main epel8 one needs a rebuild. I do that and > push it out and everything is happy again... but what about the > epel8-stream/next package? It just sits there older and unused? Yes, but I don't see a problem with this. > I assume this would work like playground/rawhide as far as landing in > the buildroot right after build and going out in the daily compose? > Or would you want to use bodhi updates? My preference would be to use bodhi updates. I think updates getting published without review would degrade the experience for CentOS Stream users. We could do a lower karma/time threashold than regular EPEL if desired. On Wed, Sep 9, 2020 at 11:55 AM Kevin Fenzi wrote: > > On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote: > > Howdy folks, > > > > A large part of my day job is working on CentOS Stream. Naturally I would > > like it to be successful and have wide adoption. I know that EPEL will play > > a big role in this success. EPEL is extremely popular. Many users consider > > RHEL and CentOS unusable without it. > > > > The problem we are facing is that EPEL 8 cannot be 100% compatible with > > RHEL/CentOS 8 and CentOS 8 Stream at the same time. It is not uncommon for > > RHEL to ship library soname changes in minor releases. In the RHEL 8 cycle, > > those changes are showing up in CentOS 8 Stream first. EPEL 8 builds > > against the latest RHEL 8 release. This can result in EPEL 8 packages that > > are uninstallable on CentOS 8 Stream due to the library differences. One > > prominent example we have already seen is llvm-libs, which has increased its > > library soname in every RHEL 8 minor release so far. Another increase is > > planned for RHEL 8.3, which has already been released in CentOS 8 Stream. > > There are likely other incompatibilities that haven't been noticed yet. I > > expect this problem to grow worse as RHEL development continues and more > > packages are added to EPEL 8. This situation is hurting the adoption of > > CentOS Stream. > > > > To solve this problem, I am proposing that we create a new repository called > > EPEL 8 Next. > > > > - built against CentOS 8 Stream > > - opt-in for packagers (must request epel8-next dist-git branch) > > - opt-in for users (part of epel-release but disabled by default) > > I like tdawsons idea down thread that it be a 'epel-release-stream' or > whatever subpackage, so they have to install that and enable it (just > like they would for enabling stream) > > > - used *with* epel8, not *instead of* > > So, maintainers would need to be careful to make sure epel8-next or > whatever packages are rpm 'newer' at all times to make this work right? > Or I guess if they were fixing soname issues like above, dnf might be > smart enough to pull in the next version anyhow even if it was lower > than the epel8 one (unless the user used --best). > > Possibly it would be best to say 'must be newer' and have some kind of > check... ? > > > This will provide EPEL packagers a place where they can update their > > packages when necessary to be compatible with CentOS 8 Stream. These > > packages would also be useful for RHEL 8 users during the gap between a RHEL > > minor release and the equivalent CentOS 8 Linux rebuild. In theory this > > repository should also be directly consumable by RHEL 8 Beta releases. > > Similar to RHEL itself, breaking changes could be permitted in epel8-next in > > preparation for delivering them to epel8 around the time of the next RHEL > > minor release. > > So, say I have package foo that needs a rebuild to work with stream. > I request a branch, do a build and everything
[EPEL-devel] Re: proposal: EPEL 8 Next
> It's too early to do this now, but I think there's a compelling case > to be made for shifting EPEL from Fedora to Stream at some point. One of the biggest benefits to EPEL being in Fedora is the ability to do fast forward merges from Fedora branches to EPEL branches. Unless CentOS Stream and Fedora are on the same dist-git, we would lose that ability, which I am 100% opposed to. > 2EPEL2Streamious This is the only alternative name I'm willing to accept. /s On Wed, Sep 9, 2020 at 11:37 AM Ben Cotton wrote: > > On Wed, Sep 9, 2020 at 10:34 AM Stephen John Smoogen wrote: > > > > I can see two big reasons for not using Stream in the name as the starting > > point of a proposal: > > 1. There is always a complaint that Red Hat related projects jump onto a > > single name to the point of overuse. Atomic, -Shift, -Stack, and a couple > > others have been ones in just recent memory. Participants in the various > > communities feel usually railroaded to use a brand even if they don't think > > it wise. > > I don't think that's as much of an issue here since this would be > specifically targeting CentOS Stream. It's not really a name so much > as a version in string form. > > > 2.EPEL has a hard enough time getting Fedora contributions with various > > community members seeing it as a useless diversion. Putting Stream in the > > title will just add to the 'why isn't EPEL just in CentOS already so I > > don't have to look at those ugly named branches in MY package'. > > > Warning: heresy and rampant speculation ahead! > It's too early to do this now, but I think there's a compelling case > to be made for shifting EPEL from Fedora to Stream at some point. This > would be dependent on getting a solid contributor community > established for Stream, of course. Realistically, I'd say we're a few > years away from making that transition, but I think the Stream > community would be a more natural fit. If CentOS Stream had existed > when EPEL started, I don't think we'd have made EPEL a part of Fedora, > despite the good points Matthew makes below. (In other words, it's not > a foregone conclusion that EPEL should be a part of Stream, and there > are reasons not to do that, but there are also reasons to do that. > That's a problem for Future Us to solve.) > > On Wed, Sep 9, 2020 at 12:28 PM Matthew Miller > wrote: > > > > So, the distinction is: EPEL is in Fedora because it's direct community > > ownership and maintenance. CentOS Stream is explicitly Red Hat controlled > > with a "patches appreciated!" approach. It's valuable to have both, but I > > also like the clarity of the separation. > > > See comments above (just leaving this quote in for reference) > > > This all leads me to think that actually what we want is not "EPEL Stream" > > but "EPEL for Stream". (epel-for-stream? epel-4-stream? epel4s? no not that > > last one for sure.) > > 2EPEL2Streamious. In seriousness, EPEL 8 is Extra Packages for > Enterprise Linux 8, right? So we can go one of two ways: > 1. Loosen the definition of what "Enterprise Linux" means (after all, > it's not EPRHEL...) and go with something like "EPEL 8 Stream" or > "EPEL Stream 8" (I'm inclined toward the latter) > 2. Keep the pattern and call it "EPCS 8" for "Extra Packages for > CentOS Stream 8". That has the benefit of being more clear what we're > targeting at the cost of potential changes in tooling and adding YAA > (yet another acronym) to the mix. (I say "acronym" here because it > would clearly be pronounced as "epics", not the initialism "Eee pee > cee ess") > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > 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 -- Carl George ___ 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
[EPEL-devel] Re: proposal: EPEL 8 Next
> I do not like it being part of epel-release, because it is (possibly) > not compatible with a regular RHEL/CentOS release. My thinking there is that shipping it as a disabled repository in epel-release makes it easier to consume in that gap between a RHEL minor release and the corresponding CentOS Linux rebuild. Imagine the scenario where an issue with an uninstallable package during that gap is solved just by running `dnf --enablerepo epel-next update`. I'm not entirely opposed to doing it as a subpackage, but it does add an extra step in the scenario I'm describing. As far as users enabling it when they shouldn't, we'll never be able to completely idiot proof things. Personally I think disabled by default is a sufficient safety measure here, but I won't lose any sleep if the steering committee insists on it being an optional subpackage. > I believe there is one other thing that was mentioned during the > meeting, and that is the lifetime. > If I remember right, the lifetime of epel8-next would only be until N > months after RHEL9 was released. (1 < N < 12) That would align with CentOS Stream, but we could keep it around for RHEL Betas and the CentOS Linux rebuild gap. Library changes are less common after the next RHEL major version is released, but they still happen. For example, in RHEL 7 ImageMagick had a library soname bump in 7.8, over six years after the initial RHEL 7 release. On Wed, Sep 9, 2020 at 8:31 AM Troy Dawson wrote: > > On Wed, Sep 9, 2020 at 5:51 AM Petr Pisar wrote: > > > > On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote: > > > To solve this problem, I am proposing that we create a new repository > > > called > > > EPEL 8 Next. > > > > > > - built against CentOS 8 Stream > > > - opt-in for packagers (must request epel8-next dist-git branch) > > > - opt-in for users (part of epel-release but disabled by default) > > I do not like it being part of epel-release, because it is (possibly) > not compatible with a regular RHEL/CentOS release. > I don't mind it being a sub-package of epel-release, something like > epel-stream-repo, but not what they get when they do the basic > epel-release install. > Users have to go through extra steps to get and use CentOS Stream, > they can do an extra step to get the EPEL next repo. > > > > - used *with* epel8, not *instead of* > > > > > I agree with all of that. I only don't like the name. Why EPEL 8 Next? If it > > is to be use with Stream, why don't we call it EPEL 8 Stream? I think the > > meaning of the repository would be easier to understand. > > > > Very good question, one I asked in the meeting. > If I got the argument right, then the amount of red-tape / legal work > it would take to call it epel-stream would be much higher than we want > to pay. > Many of us didn't like the name "Stream" to begin with since it is > sooo overloaded. > > But that also is part of the reason I don't want the repo installed by > default. > If your average EPEL user were to see that there was now a repo called > epel-next, they would think it is what we currently call playground. > Where the maintainers put their next versions of things. Those users > (and I'm sure there are many) who want to test, or use the next > version of ... whatever it is ... let's say nedit, would enable > epel-next, and then be disappointed that anything in there won't > install on their system. > > I believe there is one other thing that was mentioned during the > meeting, and that is the lifetime. > If I remember right, the lifetime of epel8-next would only be until N > months after RHEL9 was released. (1 < N < 12) > > Troy > ___ > 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 -- Carl George ___ 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
