Re: [Qa-tools-sig] Orphaned packages looking for new maintainers
by Frantisek Zatloukal
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 years, 1 month
Temporary outage - 2021-02-20
by Pavel Raiskup
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 years, 3 months
Removing old tar-balls
by Miroslav Suchý
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
2 years, 3 months
Failing ELN jobs due to broken GPG signatures
by Frantisek Sumsal
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/buil...
- https://copr.fedorainfracloud.org/coprs/packit/systemd-systemd-18600/buil...
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 years, 3 months
Fedora 34 build chroots enabled in Copr
by Pavel Raiskup
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
2 years, 3 months
Order of External Repositories matters?
by Miro Hrončok
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 years, 3 months
Copr/mock centos-stream => centos-stream-8 rename?
by Pavel Raiskup
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
2 years, 4 months