[EPEL-devel] Re: Mock/Copr default epel-8-* configuration to be changed
On Mon, Nov 29, 2021 at 09:11:48AM -0500, Neal Gompa wrote: > On Mon, Nov 29, 2021 at 9:04 AM Matthew Miller > wrote: > > > > On Mon, Nov 29, 2021 at 07:00:30AM -0500, Neal Gompa wrote: > > > If Fedora and EPEL were to have older versions, we'd have to have a > > > dedicated CDN endpoint for them, because mirrors would seriously have > > > trouble taking it. > > > > How often would such packages be used? If we had a non-default repo > > available but not enabled by default, it could be optional to mirror and > > probably still be okay. So, we actually do have this for fedora updates today. We had to set it up to solve an issue with the updates flow and CoreOS. See the fedora-updates-archive subpackage of fedora-repos. This is hosted on amazon S3, behind cloudfront. > I suspect it would be fairly heavily used. There are significant > benefits to having those: > > * DeltaRPM would be considerably more useful In order to have deltarpms the packages would have to be available at compose time and in the same repo. > * "dnf history undo" would actually work > > We could make it non-default and tell people that rollbacks require an > --enablerepo= option, though. This would work for Fedora now with the archive repo above. I suppose we could look at setting up a similar setup with epel. kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam 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 29, 2021 at 9:04 AM Matthew Miller wrote: > > On Mon, Nov 29, 2021 at 07:00:30AM -0500, Neal Gompa wrote: > > If Fedora and EPEL were to have older versions, we'd have to have a > > dedicated CDN endpoint for them, because mirrors would seriously have > > trouble taking it. > > How often would such packages be used? If we had a non-default repo > available but not enabled by default, it could be optional to mirror and > probably still be okay. > I suspect it would be fairly heavily used. There are significant benefits to having those: * DeltaRPM would be considerably more useful * "dnf history undo" would actually work We could make it non-default and tell people that rollbacks require an --enablerepo= option, though. Having its own mirror module would also give mirrors the ability to opt in, and I wouldn't be surprised if a good chunk of them do. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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 29, 2021 at 07:00:30AM -0500, Neal Gompa wrote: > If Fedora and EPEL were to have older versions, we'd have to have a > dedicated CDN endpoint for them, because mirrors would seriously have > trouble taking it. How often would such packages be used? If we had a non-default repo available but not enabled by default, it could be optional to mirror and probably still be okay. -- 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
[EPEL-devel] Re: Mock/Copr default epel-8-* configuration to be changed
On Mon, Nov 29, 2021 at 6:42 AM Stephen John Smoogen wrote: > > On Sun, 28 Nov 2021 at 19:32, Nico Kadel-Garcia wrote: > > > > On Sun, Nov 28, 2021 at 7:06 PM Neal Gompa wrote: > > > > > > On Thu, Nov 25, 2021 at 2:02 PM Nico Kadel-Garcia > > > wrote: > > > > > > > > On Thu, Nov 25, 2021 at 8:26 AM Neal Gompa wrote: > > > > > > > > > > On Thu, Nov 25, 2021 at 6:19 AM Nico Kadel-Garcia > > > > > wrote: > > > > > > > > > > > > On Thu, Nov 25, 2021 at 3:05 AM Miroslav Suchý > > > > > > wrote: > > > > > > > > > > > > > > Dne 22. 11. 21 v 15:00 Pavel Raiskup napsal(a): > > > > > > > > Hello Fedora EPEL maintainers! > > > > > > > > > > > > > > > > First I don't feel comfortable announcing this, I'm not happy > > > > > > > > about the > > > > > > > > situation and so I don't want to be the lightning rod :-). But > > > > > > > > I believe > > > > > > > > that we can come to acceptable Copr/Mock solution and this > > > > > > > > needs to be > > > > > > > > discussed... so here we are. > > > > > > > > > > > > > > > > By the end of the year 2021 we have to fix our default EPEL 8 > > > > > > > > Mock > > > > > > > > configuration (mock-core-configs.rpm, /etc/mock/epel-8-*.cfg) > > > > > > > > as CentOS 8 > > > > > > > > goes EOL by then. > > > > > > > > > > > > > > > > > > > > > I wrote down the possible options and their pros and cons and I > > > > > > > done my best to catch all the feedback here. > > > > > > > > > > > > > > https://docs.google.com/document/d/1wF7-7_y6Ac_oB-kCFdE6VBWPW8o8zjXd2Z0SGy4VxUA/edit?usp=sharing > > > > > > > > > > > > > > Miroslav > > > > > > > > > > > > That seems to be a succinct listing. I think you left out my > > > > > > suggestion.of "support people re-inventing point releases for > > > > > > CentOS", > > > > > > which is what major CentOS users will do using internal mirrors. due > > > > > > to concern about unexpected and unwelcome updates of CentOS Stream, > > > > > > while they assess whether AlmaLinux or Rocky are reliable and stable > > > > > > enough to use. It's not an uncommon behavior for EPEL itself, partly > > > > > > because of EPEL's bad habit of deleting RPMs without warning and > > > > > > stripping out all previous releases. That's caused me problems with > > > > > > chromium and firefox when updates were incompatible with > > > > > > contemporary > > > > > > regression testing systems. > > > > > > > > > > > > > > > > It's not a "bad habit", it happens because when packages are retired, > > > > > keeping the packages there does a disservice to the community by > > > > > effectively forcing a maintenance burden when there's no maintainer. > > > > > As for stripping out previous releases, that's just how Pungi and > > > > > Bodhi do update composes at the moment. Someday that'll be fixed, but > > > > > then we'd have to come up with a policy on how many because there are > > > > > storage concerns for mirrors if we kept everything published forever. > > > > > > > > It causes problems and confusion for people who need to lock down > > > > evisting versions for deployment. And it happens for packages that are > > > > not retired, but merely updated. I was bitten by it myself with > > > > chromium updates last year. It forces users of EPEL to maintain > > > > internal repos, or out of band access to previously accessible RPMs. > > > > It's destabilizing and breaks the use of bills-of-material based > > > > deployments with complete lists of all desired RPMs. > > > > > > > > Storage and bandwidth concerns are legitimate concerns, as is > > > > potentially continuing to publish older releases with known > > > > vulnerabilities or bugs. But neither Fedora nor RHEL simply discard > > > > previously published versions this way, they aggregate new releases. I > > > > consider this a longstanding bug for EPEL, and one of the reasons I > > > > set up internal mirrors in large deployments. > > > > > > > > > > This is not true. Fedora and EPEL share the same system, and have the > > > same issues. The only difference is that the release repo is frozen in > > > Fedora, so only the updates repo is affected this way. So there's at > > > most two versions of a package at any time. > > > > You're correct. With the current setup, it's also relatively simple to > > revert to the "frozen" release, which handles most of the regression > > situations. And Fedora releases are nowhere near so long-lived as RHEL > > and EPEL, so it tends to be less of a long-lived problem. > > > > > RHEL *does* maintain multiple old versions, but their system is > > > completely different and supports that capability. > > > > What would it take to get Fedora, or at least EPEL, to preserve old > > releases in the default published repos? I appreciate that it would > > require thought and expand them noticeably, especially for bulky and > > frequently updating components like chromium. I admit to not having > > numbers on how much churn happens there: does anyone have numbers? > > In order to
[EPEL-devel] Re: Mock/Copr default epel-8-* configuration to be changed
On Sun, 28 Nov 2021 at 19:32, Nico Kadel-Garcia wrote: > > On Sun, Nov 28, 2021 at 7:06 PM Neal Gompa wrote: > > > > On Thu, Nov 25, 2021 at 2:02 PM Nico Kadel-Garcia wrote: > > > > > > On Thu, Nov 25, 2021 at 8:26 AM Neal Gompa wrote: > > > > > > > > On Thu, Nov 25, 2021 at 6:19 AM Nico Kadel-Garcia > > > > wrote: > > > > > > > > > > On Thu, Nov 25, 2021 at 3:05 AM Miroslav Suchý > > > > > wrote: > > > > > > > > > > > > Dne 22. 11. 21 v 15:00 Pavel Raiskup napsal(a): > > > > > > > Hello Fedora EPEL maintainers! > > > > > > > > > > > > > > First I don't feel comfortable announcing this, I'm not happy > > > > > > > about the > > > > > > > situation and so I don't want to be the lightning rod :-). But I > > > > > > > believe > > > > > > > that we can come to acceptable Copr/Mock solution and this needs > > > > > > > to be > > > > > > > discussed... so here we are. > > > > > > > > > > > > > > By the end of the year 2021 we have to fix our default EPEL 8 Mock > > > > > > > configuration (mock-core-configs.rpm, /etc/mock/epel-8-*.cfg) as > > > > > > > CentOS 8 > > > > > > > goes EOL by then. > > > > > > > > > > > > > > > > > > I wrote down the possible options and their pros and cons and I > > > > > > done my best to catch all the feedback here. > > > > > > > > > > > > https://docs.google.com/document/d/1wF7-7_y6Ac_oB-kCFdE6VBWPW8o8zjXd2Z0SGy4VxUA/edit?usp=sharing > > > > > > > > > > > > Miroslav > > > > > > > > > > That seems to be a succinct listing. I think you left out my > > > > > suggestion.of "support people re-inventing point releases for CentOS", > > > > > which is what major CentOS users will do using internal mirrors. due > > > > > to concern about unexpected and unwelcome updates of CentOS Stream, > > > > > while they assess whether AlmaLinux or Rocky are reliable and stable > > > > > enough to use. It's not an uncommon behavior for EPEL itself, partly > > > > > because of EPEL's bad habit of deleting RPMs without warning and > > > > > stripping out all previous releases. That's caused me problems with > > > > > chromium and firefox when updates were incompatible with contemporary > > > > > regression testing systems. > > > > > > > > > > > > > It's not a "bad habit", it happens because when packages are retired, > > > > keeping the packages there does a disservice to the community by > > > > effectively forcing a maintenance burden when there's no maintainer. > > > > As for stripping out previous releases, that's just how Pungi and > > > > Bodhi do update composes at the moment. Someday that'll be fixed, but > > > > then we'd have to come up with a policy on how many because there are > > > > storage concerns for mirrors if we kept everything published forever. > > > > > > It causes problems and confusion for people who need to lock down > > > evisting versions for deployment. And it happens for packages that are > > > not retired, but merely updated. I was bitten by it myself with > > > chromium updates last year. It forces users of EPEL to maintain > > > internal repos, or out of band access to previously accessible RPMs. > > > It's destabilizing and breaks the use of bills-of-material based > > > deployments with complete lists of all desired RPMs. > > > > > > Storage and bandwidth concerns are legitimate concerns, as is > > > potentially continuing to publish older releases with known > > > vulnerabilities or bugs. But neither Fedora nor RHEL simply discard > > > previously published versions this way, they aggregate new releases. I > > > consider this a longstanding bug for EPEL, and one of the reasons I > > > set up internal mirrors in large deployments. > > > > > > > This is not true. Fedora and EPEL share the same system, and have the > > same issues. The only difference is that the release repo is frozen in > > Fedora, so only the updates repo is affected this way. So there's at > > most two versions of a package at any time. > > You're correct. With the current setup, it's also relatively simple to > revert to the "frozen" release, which handles most of the regression > situations. And Fedora releases are nowhere near so long-lived as RHEL > and EPEL, so it tends to be less of a long-lived problem. > > > RHEL *does* maintain multiple old versions, but their system is > > completely different and supports that capability. > > What would it take to get Fedora, or at least EPEL, to preserve old > releases in the default published repos? I appreciate that it would > require thought and expand them noticeably, especially for bulky and > frequently updating components like chromium. I admit to not having > numbers on how much churn happens there: does anyone have numbers? In order to keep older package releases, it would require changes to the compose tool pungi. It would also have to make it so it worked for EPEL versus Fedora. [Fedora Linux releases have grown to the point that many mirrors can barely carry the OS as is.. adding in older packages is out of the question for
[EPEL-devel] Re: Mock/Copr default epel-8-* configuration to be changed
On Thu, Nov 25, 2021 at 2:02 PM Nico Kadel-Garcia wrote: > > On Thu, Nov 25, 2021 at 8:26 AM Neal Gompa wrote: > > > > On Thu, Nov 25, 2021 at 6:19 AM Nico Kadel-Garcia wrote: > > > > > > On Thu, Nov 25, 2021 at 3:05 AM Miroslav Suchý wrote: > > > > > > > > Dne 22. 11. 21 v 15:00 Pavel Raiskup napsal(a): > > > > > Hello Fedora EPEL maintainers! > > > > > > > > > > First I don't feel comfortable announcing this, I'm not happy about > > > > > the > > > > > situation and so I don't want to be the lightning rod :-). But I > > > > > believe > > > > > that we can come to acceptable Copr/Mock solution and this needs to be > > > > > discussed... so here we are. > > > > > > > > > > By the end of the year 2021 we have to fix our default EPEL 8 Mock > > > > > configuration (mock-core-configs.rpm, /etc/mock/epel-8-*.cfg) as > > > > > CentOS 8 > > > > > goes EOL by then. > > > > > > > > > > > > I wrote down the possible options and their pros and cons and I done my > > > > best to catch all the feedback here. > > > > > > > > https://docs.google.com/document/d/1wF7-7_y6Ac_oB-kCFdE6VBWPW8o8zjXd2Z0SGy4VxUA/edit?usp=sharing > > > > > > > > Miroslav > > > > > > That seems to be a succinct listing. I think you left out my > > > suggestion.of "support people re-inventing point releases for CentOS", > > > which is what major CentOS users will do using internal mirrors. due > > > to concern about unexpected and unwelcome updates of CentOS Stream, > > > while they assess whether AlmaLinux or Rocky are reliable and stable > > > enough to use. It's not an uncommon behavior for EPEL itself, partly > > > because of EPEL's bad habit of deleting RPMs without warning and > > > stripping out all previous releases. That's caused me problems with > > > chromium and firefox when updates were incompatible with contemporary > > > regression testing systems. > > > > > > > It's not a "bad habit", it happens because when packages are retired, > > keeping the packages there does a disservice to the community by > > effectively forcing a maintenance burden when there's no maintainer. > > As for stripping out previous releases, that's just how Pungi and > > Bodhi do update composes at the moment. Someday that'll be fixed, but > > then we'd have to come up with a policy on how many because there are > > storage concerns for mirrors if we kept everything published forever. > > It causes problems and confusion for people who need to lock down > evisting versions for deployment. And it happens for packages that are > not retired, but merely updated. I was bitten by it myself with > chromium updates last year. It forces users of EPEL to maintain > internal repos, or out of band access to previously accessible RPMs. > It's destabilizing and breaks the use of bills-of-material based > deployments with complete lists of all desired RPMs. > > Storage and bandwidth concerns are legitimate concerns, as is > potentially continuing to publish older releases with known > vulnerabilities or bugs. But neither Fedora nor RHEL simply discard > previously published versions this way, they aggregate new releases. I > consider this a longstanding bug for EPEL, and one of the reasons I > set up internal mirrors in large deployments. > This is not true. Fedora and EPEL share the same system, and have the same issues. The only difference is that the release repo is frozen in Fedora, so only the updates repo is affected this way. So there's at most two versions of a package at any time. RHEL *does* maintain multiple old versions, but their system is completely different and supports that capability. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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 Thu, Nov 25, 2021 at 05:20:00PM +0100, Leon Fauster wrote: > >I mean, seriously, RH should make this easy for Fedora packagers. > > +1 > and COPR and mock packagers in general. Yes, but _I_ only have one lever. :) -- 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
[EPEL-devel] Re: Mock/Copr default epel-8-* configuration to be changed
On Mon, Nov 22, 2021 at 03:10:58PM +0100, Miro Hrončok 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. I'm not opposed to working with our friends over at Alma on this, but I think we _also_ should fix this. Would it help if we made it easy to add a RHEL developer entitlement (the 16 no-cost RHEL license thing) to a Fedora Account (perhaps with a check-box agreement in the account system, like the FPCA), and made it trivial in mock use that? I mean, seriously, RH should make this easy for Fedora packagers. -- 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
[EPEL-devel] Re: Mock/Copr default epel-8-* configuration to be changed
On Thu, Nov 25, 2021 at 6:19 AM Nico Kadel-Garcia wrote: > > On Thu, Nov 25, 2021 at 3:05 AM Miroslav Suchý wrote: > > > > Dne 22. 11. 21 v 15:00 Pavel Raiskup napsal(a): > > > Hello Fedora EPEL maintainers! > > > > > > First I don't feel comfortable announcing this, I'm not happy about the > > > situation and so I don't want to be the lightning rod :-). But I believe > > > that we can come to acceptable Copr/Mock solution and this needs to be > > > discussed... so here we are. > > > > > > By the end of the year 2021 we have to fix our default EPEL 8 Mock > > > configuration (mock-core-configs.rpm, /etc/mock/epel-8-*.cfg) as CentOS 8 > > > goes EOL by then. > > > > > > I wrote down the possible options and their pros and cons and I done my > > best to catch all the feedback here. > > > > https://docs.google.com/document/d/1wF7-7_y6Ac_oB-kCFdE6VBWPW8o8zjXd2Z0SGy4VxUA/edit?usp=sharing > > > > Miroslav > > That seems to be a succinct listing. I think you left out my > suggestion.of "support people re-inventing point releases for CentOS", > which is what major CentOS users will do using internal mirrors. due > to concern about unexpected and unwelcome updates of CentOS Stream, > while they assess whether AlmaLinux or Rocky are reliable and stable > enough to use. It's not an uncommon behavior for EPEL itself, partly > because of EPEL's bad habit of deleting RPMs without warning and > stripping out all previous releases. That's caused me problems with > chromium and firefox when updates were incompatible with contemporary > regression testing systems. > It's not a "bad habit", it happens because when packages are retired, keeping the packages there does a disservice to the community by effectively forcing a maintenance burden when there's no maintainer. As for stripping out previous releases, that's just how Pungi and Bodhi do update composes at the moment. Someday that'll be fixed, but then we'd have to come up with a policy on how many because there are storage concerns for mirrors if we kept everything published forever. > The difficulty with switching mock to AlmaLinux or Rocky is that there > is likely to be significant phase lag with new point releases by Red > Hat, and that it will inflict quite a bandwidth burden for all the > "mock" setups in the field. Can they scale up to handle that? Insofar as "phase lag with new point releases", AlmaLinux made their release 48 hours after Red Hat did with RHEL. So, frankly, I'm not worried there with AlmaLinux. For bandwidth burdens, mirror networks are designed to alleviate that burden and both have those in place. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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
Dne 22. 11. 21 v 15:00 Pavel Raiskup napsal(a): Hello Fedora EPEL maintainers! First I don't feel comfortable announcing this, I'm not happy about the situation and so I don't want to be the lightning rod :-). But I believe that we can come to acceptable Copr/Mock solution and this needs to be discussed... so here we are. By the end of the year 2021 we have to fix our default EPEL 8 Mock configuration (mock-core-configs.rpm, /etc/mock/epel-8-*.cfg) as CentOS 8 goes EOL by then. I wrote down the possible options and their pros and cons and I done my best to catch all the feedback here. https://docs.google.com/document/d/1wF7-7_y6Ac_oB-kCFdE6VBWPW8o8zjXd2Z0SGy4VxUA/edit?usp=sharing 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
[EPEL-devel] Re: Mock/Copr default epel-8-* configuration to be changed
Dne 22. 11. 21 v 17:57 Nico Kadel-Garcia napsal(a): Which is precisely why pointing it to the 'stream' release seems the only workable solution. That is EPEL-next https://fedoraproject.org/wiki/EPEL_Next#Introduction 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
[EPEL-devel] Re: Mock/Copr default epel-8-* configuration to be changed
On Mon, Nov 22, 2021 at 11:55 AM Carl George wrote: > > 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. > I've been informed that AlmaLinux is working on ppc64le support, and it's supposed to be released "soon". Perhaps Jack can provide an update here? -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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, 22 Nov 2021 at 10:15, Neal Gompa wrote:
>
> On Mon, Nov 22, 2021 at 10:12 AM Carl George wrote:
> >
> > 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
> > 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.
> >
>
> Note that I've submitted a PR to switch from CentOS Linux to
> AlmaLinux[1] for similar reasons (my workflow would be totally broken
> if I had to deal with the foibles of subscription-manager for building
> packages).
>
> [1]: https://github.com/rpm-software-management/mock/pull/803
>
I would personally like to go this route (Alma+EPEL) myself. Yes I
work for Red Hat and even if I didn't I could get the copies of the
code via the Red Hat Developers program.. but dealing with a
subscription manager while trying to build on Fedora 3X etc has not
been reliable for me. [And saying that I could use a dedicated RHEL8
virtual machine is only going to work for EL8. You would need to have
fedpkg and similar tools in EPEL-9 for the tools to work in EL9.]
--
Stephen J Smoogen.
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 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 10:12 AM Carl George wrote:
>
> 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.
>
Note that I've submitted a PR to switch from CentOS Linux to
AlmaLinux[1] for similar reasons (my workflow would be totally broken
if I had to deal with the foibles of subscription-manager for building
packages).
[1]: https://github.com/rpm-software-management/mock/pull/803
--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Mock/Copr default epel-8-* configuration to be changed
On 22. 11. 21 15:25, Miroslav Suchý wrote: But EPEL is built against RHEL (not Alma, not Rocky). True. As well as it is true today that it is not built against CentOS Linux (and yet we do that in mock). -- 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
[EPEL-devel] Re: Mock/Copr default epel-8-* configuration to be changed
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 ___ 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
