copr-devel July 2021

copr-devel@lists.fedorahosted.org

7 participants
5 discussions

CentOS Sream 9 pre-release chroots added to Fedora Copr
by Pavel Raiskup 26 Jul '21

26 Jul '21

Hi all, just for the info, we enabled the `centos-stream-9-x86_64` and `centos-stream-9-aarch64` chroots in Fedora Copr. Note that we build directly from composes [1] without mirrors (some failures can expected), and that the packages are not GPG-signed. You have been warned :-) The ppc64le doesn't seem to build on Power8 hardware we have [2], and s390x has some troubles with qemu emulation [3]. So those architectures are at least for now disabled. [1] https://github.com/rpm-software-management/mock/pull/751 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1985364 [3] Fatal glibc error: CPU lacks VXE support (z14 or later required), https://download.copr-dev.fedorainfracloud.org/results/praiskup/ping/centos… Happy building! Pavel

4 6

Can't login to copr
by harbottle 23 Jul '21

23 Jul '21

I get redirected to Fedora accounts (id.fedoraproject.org), enter my username (harbottle) and password and click "Log in", then....nothing. I can login directly to my Fedora account at [accounts.fedoraproject.org](https://accounts.fedoraproject.org/) just fine. I have tried changing my password. Please help!

2 1

Architecture "ppc64le" again in Fedora Copr
by Pavel Raiskup 14 Jul '21

14 Jul '21

Hi all, I'm glad I can announce that we have again (native) support for ppc64le builds in Fedora Copr. Currently we have two Power8 boxes (in RDU): https://pagure.io/fedora-infrastructure/issue/9059 The ppc64le chroots were re-enabled, feel free to use them. I noticed several build failures caused by missing repodata in ppc64le chroots, please re-generate the repodata manually if you happen to see those problems. Happy building! Pavel

1 0

Excluding older builds of packages from Fedora when testing new ones in Copr
by Miro Hrončok 13 Jul '21

13 Jul '21

Hello Copr users and developers. When we update packages in Fedora, we regularly use Copr to test the impact of the upgrade. For me, the procedure usually goes like this: 1) create a new copr with Fedora rawhide x86_64 chroot (and added Koji repo) $ copr create $COPR --repo='http://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/' --chroot fedora-rawhide-x86_64 --delete-after-days 30 2) define and build the updated package in the copr $ copr add-package-distgit $COPR --name $PKG --webhook-rebuild on --commit $BRANCH --namespace forks/$(whoami) $ copr build-package $COPR --name $PKG 3) get the list of dependent packages $ repoquery -q --repo=rawhide{,-source} [--whatrequires $spkg for each subpackage] --recursive | grep src$ | pkgname 4) define and build the depended packages in the copr $ parallel copr add-package-distgit $COPR --webhook-rebuild on --commit rawhide --name -- $(repoquery from above ...) $ parallel copr build-package $COPR --nowait --background --name -- $(repoquery from above ...) 5) analyze build failures, do a "control" rebuild in another copr if needed However, this procedure has a flaw. Let's say I'm working on upgrading python-click from 7.x to 8.x. And let's say a package (even transitively) BuildRequires: python3dist(click) < 8 The way that dnf dependency resolution works, that package will be built with Rawhide's python3-click 7.x and it will be marked as successful. However, I'd like to see a failure here to be notified that such package cannot be build and will be negatively impacted by the update. Is there a way to solve this? I have couple ideas, but none of them is fully working: A) Compose my own repo with the updated package and Rawhide content without it, use that repo in the copr. Pros: - this is similar to what will happen in Koji once the package is updated Cons: - this requires tooling that I don't think exists - this requires a place to put that repo to - the repo creation could take a lot of time and would need to be repeated on-demand each time rawhide changes - Copr's Fedora chroots always include Fedora repos (maybe I can use custom-1-x86_64 chroot?) B) Create a Fedora side tag, explicitly block the package from it, use that side tag's Koji repo. Pros: - same as (A) Cons: - I don't think on-demand side tags allow users to block packages - Copr's Fedora chroots always include Fedora repos (same as (A)) - this wastes Koji's resources a bit - requires waiting for the initial Koji regen-repo C) Block (exclude) python3-click < 8 from the chroot. Pros: - no custom repos required - no resources overhead - no time overhead Cons: - There is no way exclude packages in chroot settings. Mock settings possibly allow me to do this in config_opts['dnf.conf']. - The exclude could obfuscate root.log resolution problems logs. - Packager needs to figure out what exactly to exclude (possibly need to exclude all subpackage's NEVRAs from rawhide compose (and Koji buildroot if they differ)) Is there another way? If not, I think (C) is easiest to actually implement, if the chroot settings page in copr gains an "excludes" option. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

3 6

Outage: Upgrade of Copr servers - 2021-06-16 6:00 UTC
by Pavel Raiskup 08 Jul '21

08 Jul '21

There will be an outage starting at: $ date --date '2021-06-16 6:00 UTC' The outage will last approximately 2 hours. The copr-backend storage (copr build results) will stay online during this outage. Reason for outage: We're updating copr packages to the new versions which will bring new features and bugfixes. Affected Services: copr-frontend - https://copr.fedorainfracloud.org copr-backend - https://copr-be.cloud.fedoraproject.org/ Contact persons: @praiskup / @frostyx Ticket: https://pagure.io/fedora-infrastructure/issue/10034 In case of any questions, please join the #fedora-buildsys channel on libera.chat or add comments to the ticket above.

1 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

copr-devel July 2021