copr-devel December 2021

copr-devel@lists.fedorahosted.org

2 participants
6 discussions

Oracle Linux chroots (temporarily) available in Fedora Copr
by Pavel Raiskup 17 Jul '23

17 Jul '23

Hello, just a quick note - we enabled Oracle Linux chroots in Fedora Copr today, this is temporarily needed by OAMG/LEAPP team for their CI/CD system. Feel free to test those chroots, but please don't heavily depend on them as we don't know when we'll again drop them (preferably use epel/centos-stream chroots instead, they should provide similar build results). Pavel

2 2

Excluding older builds of packages from Fedora when testing new ones in Copr
by Miro Hrončok 24 May '23

24 May '23

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 7

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

28 Jan '22

Hello, 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

2 6

Updated mock-core-configs v36.4 deployed to Fedora Copr
by Pavel Raiskup 21 Dec '21

21 Dec '21

Hello maintainers, just heads-up (on breakage today, I hope). To bring several config fixes (especially for the broken centos-stream chroots), the mock-core-configs was updated today. This though also gave us an opportunity to add EPEL 9 configs. Feel free to experiment with them. Note though Enterprise Linux 9 is not yet available - so the EPEL 9 chroots are currently built against CentOS Stream 9 + EPEL 9 (similarly to what is done officially in Koji ATM). This update also means that 'epel-8' configs disappeared from the package [1]. To avoid build failures - for now - we provide a compat symlink from 'epel-8' config to 'centos+epel-8' in Copr. This basically means EPEL 8 configs haven't been changed at all, for now. Some time early in 2022 we will try to re-configure EPEL 8 chroots against RHEL 8 (subscribed content) + EPEL 8. That's because CentOS 8 goes EOL, [2]. [1] Mock release notes: https://rpm-software-management.github.io/mock/Release-Notes-2.16 [2] RHEL+EPEL Fedora devel discussion: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… Pavel

1 1

No more builds for Fedora 33, EOL
by Pavel Raiskup 14 Dec '21

14 Dec '21

Hello maintainers! Fedora 33 has been EOL for two weeks already: https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html So I disabled the Fedora 33 chroots now, which started the standard build removal policy, for more info take a look at docs: https://docs.pagure.org/copr.copr/copr_outdated_chroots_removal_policy.html Pavel

1 0

fedora-eln-ppc64le added
by Pavel Raiskup 03 Dec '21

03 Dec '21

Hello, just a quick update, I was asked why ELN ppc64le isn't available in Copr - the reason probably was that at the time we were adding other fedora-eln chroots we didn't have ppc64le builders in hands... And when we re-enabled ppc64le builders, we forgot about adding ELN chroot. So I created that chroot a few minutes back. Pavel

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

copr-devel December 2021