buildsys November 2021

buildsys@lists.fedoraproject.org

10 participants
7 discussions

automated rpm signing woes
by John Florian 15 Feb '22

15 Feb '22

What is the recommended solution for this these days? What is fedoraproject.org using? I presently have a setup using Sigul on CentOS 7 but that's leading to my current problem of being unable to upgrade anything. I can't find anything workable with CentOS 8, meanwhile my Koji Hub is stuck at 1.21.1 because I'm unaware of any newer builds via epel7. My Koji Builders are now stuck at Fedora 33 because tasks fail if they have a newer version of Koji than the Hub. My attempts at moving Sigul to CentOS 8 Stream have just led to one bug after another using the only build I could find, located at https://kojipkgs.fedoraproject.org/repos-dist/epel$releasever-infra/latest/…. I've fumbled my way through a few fixes and would be happy to contribute when I can or, at least, report bugs. However, whenever I go to https://pagure.io/sigul/, the apparent upstream for the project, I see the last commit as 10 months ago, the last comment on any issue as 7 months ago, no issues closed, no PRs merged. Is it dead?

2 3

Re: [EPEL-devel] Mock/Copr default epel-8-* configuration to be changed
by Stephen John Smoogen 29 Nov '21

29 Nov '21

On Sun, 28 Nov 2021 at 19:32, Nico Kadel-Garcia <nkadel(a)gmail.com> wrote: > > On Sun, Nov 28, 2021 at 7:06 PM Neal Gompa <ngompa13(a)gmail.com> wrote: > > > > On Thu, Nov 25, 2021 at 2:02 PM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote: > > > > > > On Thu, Nov 25, 2021 at 8:26 AM Neal Gompa <ngompa13(a)gmail.com> wrote: > > > > > > > > On Thu, Nov 25, 2021 at 6:19 AM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote: > > > > > > > > > > On Thu, Nov 25, 2021 at 3:05 AM Miroslav Suchý <msuchy(a)redhat.com> 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-kCFdE6VBWPW8o8zjXd2Z0SGy4… > > > > > > > > > > > > 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 them.] I do not have numbers on how often packages churn or which ones churn the most. -- Stephen J Smoogen. Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren

4 4

Re: [EPEL-devel] Mock/Copr default epel-8-* configuration to be changed
by Neal Gompa 28 Nov '21

28 Nov '21

On Thu, Nov 25, 2021 at 2:02 PM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote: > > On Thu, Nov 25, 2021 at 8:26 AM Neal Gompa <ngompa13(a)gmail.com> wrote: > > > > On Thu, Nov 25, 2021 at 6:19 AM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote: > > > > > > On Thu, Nov 25, 2021 at 3:05 AM Miroslav Suchý <msuchy(a)redhat.com> 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-kCFdE6VBWPW8o8zjXd2Z0SGy4… > > > > > > > > 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!

1 0

Re: [EPEL-devel] Mock/Copr default epel-8-* configuration to be changed
by Neal Gompa 25 Nov '21

25 Nov '21

On Thu, Nov 25, 2021 at 6:19 AM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote: > > On Thu, Nov 25, 2021 at 3:05 AM Miroslav Suchý <msuchy(a)redhat.com> 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-kCFdE6VBWPW8o8zjXd2Z0SGy4… > > > > 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!

1 0

Mock: how to get a client cert + key into the chroot?
by patrick+buildsys＠laimbock.com 18 Nov '21

18 Nov '21

Hi, How do I get a client certificate + key into the mock chroot? Mock needs access to a repo which requires the client to send its certificate (nginx with ssl_verify_client on;). If I copy the certificate and key to /etc/pki/tls/{certs,private} in the bootstrap directory then the chroot picks them up and the repo is available. Is there a way to specify the client certificate + key in a config somewhere so they get picked up automatically? Thanks! Best, Patrick

4 11

New website for mock's user documentaion
by Miroslav Suchý 11 Nov '21

11 Nov '21

FYI - I have moved mock's wiki to mock.git/docs directory and it is now visible on: https://rpm-software-management.github.io/mock/ The old wiki has been deleted. The reason for this is that GH's wiki is not indexed by search engines. The edits of the documentation now needs to be done through PR. We welcome such PR and will merge them as soon as possible. Miroslav

2 4

Mock v2.13 release
by Pavel Raiskup 02 Nov '21

02 Nov '21

Hello! I'm glad I can announce that we have a new release of Mock. Two new commandline options were added, and several bugs were fixed. For more info see the upstream release notes: https://rpm-software-management.github.io/mock/Release-Notes-2.13 Note that this release is likely the last v2 release being shipped both in Fedora 33+ and EPEL 7+. We'll keep v2 in bugfix mode for the purpose of EPEL 7 builds, and elsewhere we'll forward with v3. For more info see: https://github.com/rpm-software-management/mock/issues/755 Happy building! Pavel

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

buildsys November 2021