buildsys

buildsys@lists.fedoraproject.org

1413 discussions

OUTAGE: Fedora Copr enlarging the backend infra VM
by Pavel Raiskup 17 Oct '22

17 Oct '22

We plan to power-cycle one virtual machine in our infrastructure and boost the computational power there. In thurn the build results (RPMs/metadata) are going to be offline for a short period of time (up to 10 minutes). More info on #fedora-buildsys irc channel (libera chat). Links: https://pagure.io/fedora-infrastructure/issue/10943 https://status.fedoraproject.org/ Pavel

1 0

Mock v3.2 released
by Pavel Raiskup 14 Oct '22

14 Oct '22

Hello maintainers! I'm glad I can announce that we have a new release of Mock v3.2. The -–list-chroots option is now faster, directories in /var/cached and /var/lib dropped SGID bit, rpmbuild --noclean (cleanup_on_success=False) is not used while building for EL6 chroots. See full release notes: https://rpm-software-management.github.io/mock/Release-Notes-3.2 The updated packages are in Bodhi: [Fedora 37]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-3b6ee0825e [Fedora 36]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-9f6d199630 [Fedora 35]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-c4316e5c3f [EPEL 9]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-73bd121c67 [EPEL 8]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-4e4f7442dc Happy building! Pavel

1 0

Mock v3.1 release, mock-core-configs v37.5
by Pavel Raiskup 23 Jul '22

23 Jul '22

Hello maintainers! I'm glad I can announce that we have a new release of Mock v3.1. This is a small release with several minor fixes. Most of the work has been done in mock-core-configs package (mock configuration). See full release notes: https://rpm-software-management.github.io/mock/Release-Notes-3.1 The updated packages are in Bodhi: [Fedora 36]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-438ee58218 [Fedora 35]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-ec98b247c8 [EPEL 9]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-893a307ae7 [EPEL 8]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-4e4f7442dc [EPEL 7]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-3fcd2b8a9a Happy building! Pavel

1 0

Mock v3.0 release, mock-core-configs v37.3
by Pavel Raiskup 08 Apr '22

08 Apr '22

Hello maintainers! I'm glad I can announce that we have a new release of Mock v3.0. Even though we bumped the major version here, this is just a normal update that brings a few new features and shouldn't bring any troubles or backward incompatibilities. The reason we bumped the version this way is that we feature-freezed the Mock v2.X, which stays in "bug-fix" mode and is going to be updated until the EPEL 7 EOL (actually, Mock v2.17 was released in parallel with Mock v3.0, but only for EL7). From the new things, - there's a nice new option `--list-chroots`, - we better copy the CA certificates from host to the build chroot, - there's a first "library like" function simple_load_config() which was needed by the Fedora Review tool (thanks to Neal we also ship an updated fedora-review tool in the same Bodhi updates below!). - there's a disabled SECCOMP for Podman commands (with a new opt-in config if someone wants to have it enabled). We also shipped a new version of mock-core-configs v37.3 which works-around issues with improperly signed Fedora ELN packages and provides the epel-9-* configs to fix 'fedpkg mockbuild' (these are just symlinks to C9S+EPEL — once the RHEL 9 is GA, we'll use the same approach as we use for epel-8* configs). [Release notes]: https://rpm-software-management.github.io/mock/Release-Notes-3.0 [Fedora 36]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-7a34e4d255 [Fedora 35]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-d60cc8b586 [Fedora 34]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-1e8c2e2791 [EPEL 9]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-df59848ff7 [EPEL 8]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-e86ba06e24 [EPEL 7]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-2eb57408f3 Happy building! Pavel

1 0

Fedora Copr - highlights from the 2022-04-05 release
by Pavel Raiskup 05 Apr '22

05 Apr '22

Hello. We are pleased to announce that we deployed a new Fedora Copr release. This time we added GSSAPI/Kerberos authentication support, we optimized the backend side for the large task queues we face last months, and fixed several bugs. More info: https://docs.pagure.org/copr.copr/release-notes/2022-04-05.html Happy building! Copr Team

1 0

--pm-cmd / --dnf-cmd - ? mock
by lejeczek 04 Mar '22

04 Mar '22

Hi guys. What options such as '--dnf-cmd' do, can you tell? Man page is pretty confusing - well to me it is - in that respect. I thought that was for 'args', parameters in other words which are available to the 'dnf' command itself but that does _not_ seem to be the case. At the same time - I hit something which might be common I'd imagine: ... - cannot install the best update candidate for package mpfr-3.1.6-1.el8.x86_64 - cannot install both mpfr-4.1.0-8.el8.x86_64 and mpfr-3.1.6-1.el8.x86_64 - cannot install both mpfr-3.1.6-1.el8.x86_64 and mpfr-4.1.0-8.el8.x86_64 (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) ... If '--dnf-cmd' is not for those things then how to rectify such a problem? many thanks, L.

2 2

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

Mock v2.16 release, mock-core-configs v36.4
by Pavel Raiskup 11 Feb '22

11 Feb '22

Hello! I'm glad I can announce that we have a new release of Mock. See the full release notes [1]. The major change that happened is the removal of 'epel-8' config files, as a follow-up for [2] discussion (and of course on *devel lists, big thanks to everyone for the discussion). Note that this is is the last v2 release being shipped to all supported Fedora/EPEL versions. From now on, we'll move to v3 with development (in 'main' branch) and EPEL 7 stays on v2 (in 'mock-2' branch, bugfix only). [1] https://rpm-software-management.github.io/mock/Release-Notes-2.16 [2] https://pagure.io/epel/issue/133 [Fedora 35]: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a7d4aaa6fe [Fedora 34]: https://bodhi.fedoraproject.org/updates/FEDORA-2021-0947974f0a [EPEL 8]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-2d0f959e00 [EPEL 7]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-82ccb8f2b7 Happy building! Pavel

1 2

Re: rpkg-util v3 change, moving copr builders to F35
by Pavel Raiskup 28 Jan '22

28 Jan '22

Hello maintainers, seems like we are finally able to migrate to Fedora 35. If all the necessary test pass, we should be OK to migrate tomorrow, 2022-01-25. This also means that we'll finally run against rpkg-util v3+ == no way back to auto_pack feature. Pavel On Friday, December 17, 2021 12:32:37 PM CET Pavel Raiskup wrote: > Hello all, > > just a quick update on this topic. This took a bit more time than I > originally expected, but I was able to test that configuration. > > Please expect that step 2 happens on Monday, 2021-12-20 (I don't want to > break things just when weekend starts). > > For more info see the previous email, and we should be able to help you > next week with the migration on #fedora-buildsys, when needed. > > Also, the step 3 will be delayed at least by 20 days, so you still have the > 1-month transition period. > > Sorry for inconvenience, > Pavel > > On Friday, November 19, 2021 9:44:51 AM CET Pavel Raiskup wrote: > > we are currently preparing Copr build system for migration to Fedora 35, > > including the builder workers. > > > > There's though, at least from the builder perspective, a major `rpkg-util` > > behavior change [1] (removal of `auto_pack` feature) that many of the Copr > > projects rely on. This is a bit unexpected as `auto_pack = True` has been > > the default in Copr for a long time, and the rpkg-util upstream intentions > > behind the feature were generally misunderstood (even in Copr team). > > > > That being said, some of the currently working builds on F34 would fail > > after the migration to F35. > > > > In order to make the migration a bit less dramatic, we plan to migrate in > > the following steps: > > > > 1. Document the feature drop and possible fixes/workarounds see [1], and > > properly announce the change in advance (here we are _now_). > > > > 2. Change the default, and turn off the `auto_pack` feature for > > relatively short period of time on the current F34 builders > > (ie autopack=False). This will happen soon in December 2021. > > The change will naturally trigger the build failures, but a bit > > earlier so users will be informed sooner ... with a _temporary_ > > work-around in hand => everyone can provide the file > > <git-root>/rpkg.conf upstream, and opt-in the old behavior with with > > content like: > > > > [rpkg] > > # temporary work-around for rpkg-util v2, auto_pack is going to be > > # removed soon! See: > > # https://docs.pagure.org/copr.copr/rpkg_util_2_vs_3.html#rpkg-util-v3 > > auto_pack = True > > > > 3. Migrate to Fedora 35, early in January 2022. This will make the > > `auto_pack = True` work-around non-working, and users will have to > > adapt, again, see [1]. > > > > Of course, anyone is encouraged to migrate to the new syntax **right now**, > > sooner the better. If done correctly, package can be built both with rpkg-util > > v2 and v3 [2]. > > > > Sorry for inconvenience! Any comment, idea or help is welcome! > > > > [1] https://docs.pagure.org/copr.copr/rpkg_util_2_vs_3.html#rpkg-util-v3 > > [2] https://pagure.io/copr/copr-hello/c/739ff9910ee8a9c76d7e97de2f6176106dc19a0… > > > > Pavel > > > > > >

1 2

Re: Mock v2.16 release, mock-core-configs v36.4
by Neal Gompa 06 Jan '22

06 Jan '22

On Thu, Jan 6, 2022 at 12:01 PM David Cantrell <dcantrell(a)redhat.com> wrote: > > On Wed, Dec 22, 2021 at 05:26:26PM +0100, Pavel Raiskup wrote: > >On Wednesday, December 22, 2021 4:22:29 PM CET Neal Gompa wrote: > >> On Wed, Dec 22, 2021 at 10:14 AM Pavel Raiskup <praiskup(a)redhat.com> wrote: > >> > > >> > On Wednesday, December 22, 2021 9:36:01 AM CET Pavel Raiskup wrote: > >> > > On Tuesday, December 21, 2021 5:49:34 PM CET Maxwell G wrote: > >> > > > On Tuesday, December 21, 2021 8:22:55 AM CST Miro Hrončok wrote: > >> > > > > On 19. 12. 21 22:39, Pavel Raiskup wrote: > >> > > > > > On Sunday, December 19, 2021 10:22:57 PM CET Pavel Raiskup wrote: > >> > > > > >> So it seems that fedpkg doesn't (yet) know there's ~/.config/mock* at all. > >> > > > > > > >> > > > > > Proposed fix: https://pagure.io/rpkg/pull-request/595 > >> > > > > > >> > > > > It seems that this would only fix the issue if the symbolic link has already > > > been created. But before that, `fedpkg --release epel8 mockbuild` would still > >> > > > > fail, wouldn't it? Can we fix that as well, even if it's fixed in some > >> > > > > documentation only? > >> > > > > >> > > > Yes, I think `fedpkg --release epel8 mockbuild` should print the same error > >> > > > message mock does when no default has been set, instead of defaulting to a > >> > > > non-functional koji config. > >> > > > >> > > Fedpkg _automatically_ downloads the relevant Koji config ('koji > >> > > mock-config' variant, which is broken for normal users) when mock doesn't > >> > > ship the appropriate config file (it doesn't by default). > >> > > > >> > > @onosek, would it be too bad if we made the Koji config download feature > >> > > opt-in in fedpkg? Something like 'fedpkg mockbuild --use-koji-mock-config'? > >> > > - when used, all local mock configuration is ignored > >> > > - when not used, 'mock -r epel-8-x86_64' even if the config doesn't exist, > >> > > which would automatically trigger the new Mock error message > >> > > >> > I'm trying to propose this: > >> > https://pagure.io/rpkg/pull-request/597 > >> > > >> > $ fedpkg mockbuild > >> > Not downloading already downloaded pspg-5.5.2.tar.gz > >> > > >> > setting SOURCE_DATE_EPOCH=1639353600 > >> > Wrote: /tmp/pspg/pspg-5.5.2-1.el8.src.rpm > >> > ERROR: Could not find required config file: /etc/mock/epel-8-x86_64.cfg > >> > ERROR: There are those alternatives: > >> > ERROR: > >> > ERROR: [1] alma+epel-8-x86_64 > >> > ERROR: Use instead: mock -r alma+epel-8-x86_64 --resultdir /tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm > >> > ERROR: Builds against AlmaLinux 8 repositories, together with the official EPEL repositories. > >> > ERROR: Project page: https://almalinux.org/ > >> > ERROR: Enable permanently by: > >> > ERROR: $ ln -s /etc/mock/alma+epel-8-x86_64.cfg /home/praiskup/.config/mock/epel-8-x86_64.cfg > >> > ERROR: > >> > ERROR: [2] centos+epel-8-x86_64 > >> > ERROR: Use instead: mock -r centos+epel-8-x86_64 --resultdir /tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm > >> > ERROR: Builds against CentOS Linux 8 repositories, together with the official EPEL repositories. > >> > ERROR: This will reach end-of-life in January 2021. > >> > ERROR: Enable permanently by: > >> > ERROR: $ ln -s /etc/mock/centos+epel-8-x86_64.cfg /home/praiskup/.config/mock/epel-8-x86_64.cfg > >> > ERROR: > >> > ERROR: [3] rhel+epel-8-x86_64 > >> > ERROR: Use instead: mock -r rhel+epel-8-x86_64 --resultdir /tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm > >> > ERROR: Builds against Red Hat Enterprise Linux 8 repositories, together with the official EPEL repositories. > >> > ERROR: This mimics what is done in the official EPEL build system, but you need a Red Hat subscription: > >> > ERROR: https://rpm-software-management.github.io/mock/Feature-rhelchroots > >> > ERROR: Enable permanently by: > >> > ERROR: $ ln -s /etc/mock/rhel+epel-8-x86_64.cfg /home/praiskup/.config/mock/epel-8-x86_64.cfg > >> > ERROR: > >> > ERROR: [4] rocky+epel-8-x86_64 > >> > ERROR: Use instead: mock -r rocky+epel-8-x86_64 --resultdir /tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm > >> > ERROR: Builds against Rocky Linux 8 repositories, together with the official EPEL repositories. > >> > ERROR: Project page: https://rockylinux.org/ > >> > ERROR: Enable permanently by: > >> > ERROR: $ ln -s /etc/mock/rocky+epel-8-x86_64.cfg /home/praiskup/.config/mock/epel-8-x86_64.cfg > >> > Could not execute mockbuild: Failed to execute command. > >> > > >> > >> This is why I suggested that fedpkg needed the alias system instead of > >> mock in the EPEL discussion. fedpkg already has a config file format > >> for setting keys and values, so fedpkg should be extended to allow > >> people to set the distro prefix to search for with epel targets (e.g. > >> alma, rhel, centos-stream, etc.). Mock is basically the "dumb builder" > >> whereas fedpkg is the high-level packager Swiss Army Knife tool to get > >> stuff done. > > > >Well, my opinion is quite the opposite: IMO it would be better if > >fedpkg/pyrpkg know *nothing* about mock configuration (location, etc.). > > > >The fact that this logic is implemented in fedpkg/pyrpkg/rhpkg/etc. makes > >this fix complicated. And searching for the available Mock configs will become > >super complicated once we move the configs from /etc/mock to /usr/share). > > I agree here. fedpkg/pyrpkg should be disconnected from mock as much as > possible. This may not be achievable overnight, but it's something that I > think is worth pursuing. It should be easy to adapt fedpkg to build backends > other than mock and likewise it should be easy to change mock out for > something else if we ever deem that necessary. > > >Also note that I for one have never used 'fedpkg mockbuild' for real. I use > >plain mock. That said, I find the error message quite appropriate in Mock, > >too. > > Me either. I run mock by itself before ultimately submitting builds using > fedpkg. > I always use "fedpkg mockbuild" because it takes care of things like fetching sources and configuring a local resultdir and such. It's nice sugar on top of Mock itself. -- 真実はいつも一つ！/ Always, there's only one truth!

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

buildsys