copr-devel February 2021

copr-devel@lists.fedorahosted.org

9 participants
8 discussions

Re: [Qa-tools-sig] Orphaned packages looking for new maintainers
by Frantisek Zatloukal 28 Apr '21

28 Apr '21

On Mon, Feb 8, 2021 at 4:57 PM Miro Hrončok <mhroncok(a)redhat.com> wrote: > python-flask-openid orphan, pjp, sundaram 0 weeks > ago > Taken. We still need that for blockerbugs, sigh. It's dead upstream, replaced by oidc. I'll try to poke others depending on this (eg. copr) once we finish migration and retire it once completed. -- Best regards / S pozdravem, František Zatloukal Quality Engineer Red Hat

2 1

Temporary outage - 2021-02-20
by Pavel Raiskup 21 Feb '21

21 Feb '21

We observe problems on copr-keygen machine (the one that signs RPMs). I'm going to pause the queue processing for a while, and increase the power of copr-keygen. Sorry for temporary (20m) inconvenience. Pavel

2 2

Removing old tar-balls
by Miroslav Suchý 17 Feb '21

17 Feb '21

We are running low on copr-dist-git storage. I run `remove_unused_sources`, which removes all tar-balls from lookaside-cache but the latest ones referenced in `sources` (in any branch). The script is running now. And is going to run for several hours. The consequence is that hitting "resubmit" button for some olders builds may fail. In this case, please resubmit the whole src.rpm again. -- Miroslav Suchy, RHCA Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys

1 0

Failing ELN jobs due to broken GPG signatures
by Frantisek Sumsal 15 Feb '21

15 Feb '21

Hello, I noticed that for the past couple of days all our builds in fedora-eln-* chroots have been failing due to GPG-related issues: warning: /var/lib/mock/fedora-eln-x86_64-bootstrap-1613383811.551938/root/var/cache/dnf/eln-78c0f68aeb10b59c/packages/alternatives-1.15-2.eln109.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 45719a39: NOKEY Fedora - ELN - Developmental packages for the n 1.6 MB/s | 1.6 kB 00:00 GPG key at file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary (0x9867C58F) is already installed The GPG keys listed for the "Fedora - ELN - Developmental packages for the next Enterprise Linux release" repository are already installed but they are not correct for this package. Check that the correct key URLs are configured for this repository.. Failing package is: alternatives-1.15-2.eln109.x86_64 GPG Keys are configured as: file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary Public key for audit-libs-3.0-2.eln109.x86_64.rpm is not installed. Failing package is: audit-libs-3.0-2.eln109.x86_64 GPG Keys are configured as: file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary ... See: - https://copr.fedorainfracloud.org/coprs/packit/systemd-systemd-18596/build/… - https://copr.fedorainfracloud.org/coprs/packit/systemd-systemd-18600/build/… According to https://pagure.io/releng/issue/10007 this should already be fixed, but the reality begs to differ. Is there anything else I need to do on our side or there's still some underlying unresolved issue? Thanks! Cheers, Frantisek

2 1

Fedora 34 build chroots enabled in Copr
by Pavel Raiskup 15 Feb '21

15 Feb '21

We branched Fedora 34 chroots from Rawhide chroots on Friday (for those projects where this feature is enabled), and the new Fedora 34 chroots are now available. I am afraid that we did not get the right timing (copr branching done too late after Fedora branching), and that some Fedora 34 chroots may again contain some F35 builds. Sorry about that, this is going to be baken into our mock configs documentation so it shouldn't happen next time. If you happen to have f35 builds in your 34 buildroot - please rebuild the package with bumped NVR, or resubmit the build and drop the old one. Happy building! Pavel

1 0

Order of External Repositories matters?
by Miro Hrončok 12 Feb '21

12 Feb '21

I've been surprised by a behavior of External Repositories. I've done two builds of python-six in this copr: https://copr.fedorainfracloud.org/coprs/churchyard/tmp/ First with: External Repositories: copr://@python/python3.10 http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/ And the second with: External Repositories: http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/ copr://@python/python3.10 The results suprised me. The first build installs python 3.9 from koji in the bootstrap chroot and successfully bootstraps only with packages from koji. Then it creates the default chroot with packages mostly from koji but python-srpm-macros from @python/python3.10 (higher version). The installation of buildrequires fails with: Error: Problem 1: package python3-pip-21.0-1.fc34.noarch requires python(abi) = 3.9, but none of the providers can be installed - package python3-devel-3.10.0~a5-1.fc34.x86_64 conflicts with python3 < 3.10.0~a5-1.fc34 provided by python3-3.9.1-5.fc34.x86_64 - package python3-devel-3.10.0~a5-1.fc34.x86_64 conflicts with python3 < 3.10.0~a5-1.fc34 provided by python3-3.9.1-5.fc34.i686 - cannot install the best candidate for the job Problem 2: python3-3.9.1-5.fc34.i686 has inferior architecture - package python3-wheel-1:0.36.2-2.fc34.noarch requires python(abi) = 3.9, but none of the providers can be installed - cannot install both python3-3.10.0~a5-1.fc34.x86_64 and python3-3.9.1-5.fc34.x86_64 - cannot install both python3-3.9.1-5.fc34.x86_64 and python3-3.10.0~a5-1.fc34.x86_64 - package python3-tkinter-3.10.0~a5-1.fc34.x86_64 requires python3 = 3.10.0~a5-1.fc34, but none of the providers can be installed - cannot install the best candidate for the job The second build installs python 3.10 from @python/python3.10 in the bootstrap chroot and successfully bootstraps with packages from koji + Python packages from @python/python3.10. Then it creates the default chroot with packages from koji + Python packages from @python/python3.10. Then it successfully installs Python 3.10 with other buildrequires. Does the order of external repos defines their priority/cost? Is that a feature or a bug? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 2

Copr/mock centos-stream => centos-stream-8 rename?
by Pavel Raiskup 08 Feb '21

08 Feb '21

The configuration for CentOS Stream 8 was renamed in mock-core-configs so it makes more sense now (currently the updated package is getting to updates-testing), and we'll have to adjust Fedora Copr to comply with that layout. The idea now is to try script the movement on backend (built results), and create compat symlink 'centos-stream-x86_64 => centos-stream-8-x86_64'. This way new build results will be put into the new location, and old clients will be able to access old/new results. Does this make sense, or is there a better idea? From the UI/API perspective, I believe we'll be able to migrate the existing chroot transparently without disabling old one and creating a new one. If this doesn't happen to be possible (new chroot will be needed) I'll reply here to warn you that the centos-stream buildroot needs to be re-enabled. In any case, note that the `--chroot centos-stream-x86_64` option will stop working very soon, and you should start using `--chroot centos-stream-8-x86_64`. Pavel

1 0

Please raise build time limit for Chromium again
by 藍挺瑋 08 Feb '21

08 Feb '21

Since ld.gold segfault on Fedora 33 and rawhide when it uses more than one thread [1], I switched my Chromium builds to use ld.bfd a few months ago. The change increased the build time, but at least the build didn't fail in 1 hour due to ld.gold segfault. It seems that Chromium 87 increases the build time further with its Ozone platform. Now it is very hard to get successful builds of Chromium 87 on Copr. After submitting Chromium 87.0.4280.66 builds for more than 10 times, I still couldn't get successful builds for all chroots. Even if there were successful builds in some chroots, the build time was pretty close to the limit. For example, this build [2] took 29h 50m for Fedora 33, and this build [3] took 29h 52m for Fedora rawhide. Is it possible to raise the limit again? Given that Chromium keeps increasing the build time for the past 2 years, I think we should raise the limit to 48 hours this time. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1873848 [2] https://copr.fedorainfracloud.org/coprs/lantw44/chromium/build/1782394/ [3] https://copr.fedorainfracloud.org/coprs/lantw44/chromium/build/1794997/

7 11

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

copr-devel February 2021