copr-devel December 2022

copr-devel@lists.fedorahosted.org

8 participants
10 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

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

chroot fedora-35-i686 removed
by Miroslav Suchý 21 Dec '22

21 Dec '22

Because of this the chroot fedora-35-i686 is not usefull anymore. I disabled this chroot. Just after the Christmas break we are going to remove all other Fedora 35 chroots. Miroslav -------- Přeposlaná zpráva -------- Předmět: Re: COPR Build Failures for fedora-35-i686 Datum: Mon, 19 Dec 2022 18:32:45 +1100 Od: Frank Crawford <frank(a)crawford.emu.id.au> Adresa pro odpověď: Development discussions related to Fedora <devel(a)lists.fedoraproject.org> Komu: Development discussions related to Fedora <devel(a)lists.fedoraproject.org> Kopie: Vitaly Zaitsev <vitaly(a)easycoding.org> On Sun, 2022-12-18 at 16:07 +0100, Vitaly Zaitsev via devel wrote: > On 18/12/2022 12:20, Frank Crawford wrote: > > Can anyone explain what is going on? > > Fedora no longer has i686 mirrors, so COPR or mock use Koji's > buildroot. It was recently removed due to F35 EOL so you can no longer build F35 > i686 packages. Thank you Vitaly, that is understandable. Regards Frank _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

1 0

Updating openEuler and openSUSE chroots
by Jiri Kyjovsky 14 Dec '22

14 Dec '22

Hello, today we added new chroots for openEuler and openSUSE, namely: - openeuler-22.03-aarch64 - openeuler-22.03-x86_64 - opensuse-leap-15.4-aarch64 - opensuse-leap-15.4-x86_64 and at the same time, we have removed these outdated ones: - opensuse-leap-15.2-aarch64 - opensuse-leap-15.2-x86_64 Jiri

1 0

PPC64LE problems?
by Steven A. Falco 10 Dec '22

10 Dec '22

The nightly Copr builds for KiCad are failing on the ppc64le builders [1]. Is this a known problem? It looks like there has been an issue for the past 3 days or so [2]. Steve [1] https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/5119571/ [2] https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/builds/

2 1

armhfp builds can fail on memory allocation for dnf
by Tomas Tomecek 08 Dec '22

08 Dec '22

This was reported to us recently: https://github.com/packit/packit-service/issues/1798 I wonder, now that Copr is on Github, shall we move the issue to your issue tracker? Logs: https://download.copr.fedorainfracloud.org/results/@meta/drgn/fedora-36-arm… PR: https://github.com/packit/packit-service/issues/1798 Unfortunately, the problem looks consistent: https://download.copr.fedorainfracloud.org/results/@meta/drgn/fedora-36-arm… Tomas

1 0

Copr OpenID login should work now
by Jakub Kadlcik 08 Dec '22

08 Dec '22

Hello, as many of you noticed, we had a problem with login failing with "504 gateway timeout" error for the last couple of days. I am sorry it took that long to fix, it wasn't easy for me to pinpoint what exactly is wrong. Anyway, the login should work now. Please let me know if not. If you are interested, details can be found here https://github.com/fedora-copr/copr/issues/2418#issuecomment-1341394581 Jakub

1 0

Outage: Upgrade of Copr servers - 2022-11-28 12:00 UTC
by Pavel Raiskup 01 Dec '22

01 Dec '22

.... aaand finally this long outage is over. This wasn't ideal, sorry for any inconveniences. There were some PEBKAC problems while migrating the storage to a new F37 instance, some signature problems (a few builds failed because of sign error, please resubmit them) and some failed to import (resubmit as well). Otherwise, we are finally fully on F37 (builders and infrastructure) and everything appears to be working. It was a long day so we'll continue tomorrow with remaining stuff, e.g. sending updated cli packages and providing release notes. Happy building. Copr Team On neděle 27. listopadu 2022 2:15:28 CET Jakub Kadlčík wrote: > > frostyx reported a new issue against the project: `fedora-infrastructure` that you are following: > `` > There will be an outage starting at: > > ``` > $ date --date '2022-11-28 13:30 UTC' > ``` > > The outage will last approximately 3 hours. The copr-backend storage (copr > build results) will stay mostly online during this outage but some downtime is expected. > > Reason for outage: > We're updating copr packages to the new versions which will bring new > features and bugfixes. We are also upgrading our servers to F37. > > Affected Services: > copr-frontend - https://copr.fedorainfracloud.org > copr-backend - https://copr-be.cloud.fedoraproject.org/ > > Contact persons: > @frostyx / @praiskup / @nikromen > > Please join #fedora-admin in irc.libera.chat or add comments to the ticket for > this outage above. > `` > > To reply, visit the link below or just reply to this email > https://pagure.io/fedora-infrastructure/issue/11011 >

2 1

copr.fedorainfracloud.org: Can not create storage directory for uploaded file: [Errno 13] Permission denied: '/var/lib/copr/data/srpm_storage/tmpXXX' -> '/var/lib/copr/data/srpm_storage/tmpYYY/ZZZ
by Ivan Mironov 01 Dec '22

01 Dec '22

Hi! For more than a day I am seeing following when trying to upload SRPM into copr.fedorainfracloud.org: Error 500: Unknown error Can not create storage directory for uploaded file: [Errno 13] Permission denied: '/var/lib/copr/data/srpm_storage/tmpXXX' -> '/var/lib/copr/data/srpm_storage/tmpYYY/ZZZ' This happens with both copr-cli and the web interface. (If this is not the right place o report such problems then please provide a link to the right one.)

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

copr-devel December 2022