copr-devel February 2023

copr-devel@lists.fedorahosted.org

6 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

(no subject)
by Gezim Blliku 22 Feb '23

22 Feb '23

Hi , i am trying to build packages for fedora copr using custom build method and also i connected with webhooks to my github repo for every push event.My problem is every time i push a commit to a certain branch it will generate builds for every branch .I see that github don't support webhooks for invidual branch ,i am guessing there is a way to come around this in the script .

3 2

Re: [Copr] upcoming deletion of outdated chroots in your projects
by Isaac Lightburn 22 Feb '23

22 Feb '23

I constantly get g/w timeout trying to go there & login, so ? "The gateway did not receive a timely response from the upstream server or application" Any help greatly appreciated, Thanks On Wed, Nov 30, 2022 at 10:10 PM <root(a)copr-fe.aws.fedoraproject.org> wrote: > You have been notified because you are an admin of projects, that have > some builds in outdated chroots > > According to the 'Copr outdated chroots removal policy' > https://docs.pagure.org/copr.copr/copr_outdated_chroots_removal_policy.html > data are going to be preserved 180 days after the chroot is EOL and then > automatically deleted, unless you decide to prolong the expiration period. > > Please, visit the projects settings if you want to extend the time. > > Project: openkj/OpenKJ > Chroot: fedora-34-x86_64 > Remaining: 19 days > https://copr.fedorainfracloud.org/coprs/openkj/OpenKJ/repositories/ > > Project: openkj/OpenKJ > Chroot: fedora-34-i386 > Remaining: 19 days > https://copr.fedorainfracloud.org/coprs/openkj/OpenKJ/repositories/ > > Project: openkj/OpenKJ-beta > Chroot: fedora-34-x86_64 > Remaining: 19 days > https://copr.fedorainfracloud.org/coprs/openkj/OpenKJ-beta/repositories/ > > Project: openkj/OpenKJ-beta > Chroot: fedora-34-i386 > Remaining: 19 days > https://copr.fedorainfracloud.org/coprs/openkj/OpenKJ-beta/repositories/ > > Project: openkj/OpenKJ-unstable > Chroot: fedora-34-x86_64 > Remaining: 19 days > > https://copr.fedorainfracloud.org/coprs/openkj/OpenKJ-unstable/repositories/ > > Project: openkj/OpenKJ-unstable > Chroot: fedora-34-aarch64 > Remaining: 19 days > > https://copr.fedorainfracloud.org/coprs/openkj/OpenKJ-unstable/repositories/ > > Project: openkj/OpenKJ-unstable > Chroot: fedora-34-i386 > Remaining: 19 days > > https://copr.fedorainfracloud.org/coprs/openkj/OpenKJ-unstable/repositories/ > > Project: openkj/OpenKJ-unstable > Chroot: fedora-34-armhfp > Remaining: 19 days > > https://copr.fedorainfracloud.org/coprs/openkj/OpenKJ-unstable/repositories/ > >

2 1

Re: Fedora Linux 38 branched
by Iñaki Ucar 14 Feb '23

14 Feb '23

On Fri, 10 Feb 2023 at 09:44, Jakub Kadlcik <jkadlcik(a)redhat.com> wrote: > > Hello Tomas, > thank you for the announcement. > > We also branched Fedora 38 in Copr so that everybody can submit builds > for it by now. Also, all projects with the "Follow Fedora branching" > option configured in their project settings have F38 chroots > automatically enabled and they contain the last build results from > Fedora Rawhide before the branch. Is this still ongoing? I don't see F38 in my projects. -- Iñaki Úcar

3 4

Copr backend unplanned outage
by Pavel Raiskup 08 Feb '23

08 Feb '23

Hello all, our RAID storage got stuck this night (CET). Likely some deadlock caused by high I/O - caused by the periodic "RAID check" process together with the Fedora Rawhide => F38 branching task that has been done yesterday. But the actual cause is unknown (if this looks familiar to you, let us know). We ended up with about 400 processes hanged, waiting for disk (kill -9 has no effect). This is the second time this happened on F37 but "echo idle > /sys/block/md127/md/sync_action" did not help now (nor 'frozen'), only hard reboot using the AWS console helped eventually. We were more than 7 hours offline (the team was sleeping): https://pagure.io/fedora-infrastructure/issue/11120 Sorry for the inconvenience, and thank you for all the reports! Pavel

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

copr-devel February 2023