Re: Copr patch syntax compat

Am 22.05.25 um 11:33 schrieb Miro Hrončok: On 21. 05. 25 20:08, Leon Fauster via devel wrote: Hey all, while trying to build some centos-stream packages via git in COPR, recently I get error: %patchN is obsolete, use %patch N (or %patch -P N) aborted builds. I can patch the specs files for al

Re: Copr patch syntax compat

On 21. 05. 25 20:08, Leon Fauster via devel wrote: Hey all, while trying to build some centos-stream packages via git in COPR, recently I get error: %patchN is obsolete, use %patch N (or %patch -P N) aborted builds. I can patch the specs files for all builds but (question) is there a compat s

Re: Copr patch syntax compat

Dne 21. 05. 25 v 8:08 odp. Leon Fauster via devel napsal(a): Hey all, while trying to build some centos-stream packages via git in COPR, recently I get error: %patchN is obsolete, use %patch N (or %patch -P N) aborted builds. I can patch the specs files for all builds but (question) is there a

Re: COPR custom build script failing

On Tue, Mar 04, 2025 at 10:15:56AM +0100, Miroslav Suchý wrote: > Dne 04. 03. 25 v 7:29 dop. Peter Hutterer napsal(a): > > Hi all, > > > > This feels like it should be easy but I can't seem to figure it out. > > Two weeks ago my custom build script started failing: > > https://copr.fedorainfraclou

Re: COPR custom build script failing

Dne 04. 03. 25 v 7:29 dop. Peter Hutterer napsal(a): Hi all, This feels like it should be easy but I can't seem to figure it out. Two weeks ago my custom build script started failing: https://copr.fedorainfracloud.org/coprs/whot/libinput-git/builds/ The failing part is... the mockbuild command?

Re: Copr Modularity, the End of an Era

That's a very good question, Nikita. Depending on modules falls in the same category as module-hotfixes for us. In the case of module-hotfixes, Copr only generates the `module_hotfixes=1` line into the repofile, and in the case of module dependencies, Copr only generates `config_opts['module_setup

Re: Copr Modularity, the End of an Era

On Wed, Oct 23, 2024 at 5:32 PM Jakub Kadlcik wrote: > Hello everybody, > I'd like to announce that all Modularity features in Copr (except for > module hotfixes) are now deprecated, and we have a plan to slowly remove > them from our codebase. > > For more reasoning and the retirement schedule,

Re: Copr builds are stuck at package signing

Dne 06. 12. 23 v 12:52 František Šumšal napsal(a): Hey, Thanks to Packit I noticed that a lot of our jobs are running longer than usual, and a quick glance at the Copr task queue[0] tells me there's something fishy going on. I opened a couple of jobs[1][2][3] and all of ... Looks like the last

Re: Copr drops sqlite databases and AppStream from repo metadata

On 14/03/2023 08:19, Pavel Raiskup wrote: We already have AppStream metadata disabled by default for new projects, but there are many old projects where having this enabled causes problems here and there. So we plan to disable it manually even for old projects: Please keep it enabled for prelo

Re: copr and centos9 ?

To answer the first question about 'domain decomposition'.. I don't think it is something that 'most' or 'many' customers deal with. Fair enough, but for HPC scientific applications it is definitely a go-to functionality. In that case, the usual method is 'build it yourself' or 'work with ot

Re: copr and centos9 ?

On Wed, 21 Dec 2022 at 12:32, Mark Olesen wrote: > Yup, scotch doesn't seem to be in CBR either. > Doesn't even seem to be a metis library anymore either. This all seems > to be a bit odd - how do people manage domain decomposition without > metis, or scotch (and ptscotch)? Or is it expected that

Re: copr and centos9 ?

On Wed, 2022-12-21 at 18:31 +0100, Mark Olesen via devel wrote: > Yup, scotch doesn't seem to be in CBR either. > Doesn't even seem to be a metis library anymore either. This all > seems > to be a bit odd - how do people manage domain decomposition without > metis, or scotch (and ptscotch)? Or is

Re: copr and centos9 ?

Yup, scotch doesn't seem to be in CBR either. Doesn't even seem to be a metis library anymore either. This all seems to be a bit odd - how do people manage domain decomposition without metis, or scotch (and ptscotch)? Or is it expected that we should be rolling this thirdparty software into our

Re: copr and centos9 ?

On Wed, 2022-12-21 at 12:11 -0500, Stephen Smoogen wrote: > > > On Wed, 21 Dec 2022 at 12:03, Sérgio Basto wrote: > > On Wed, 2022-12-21 at 17:58 +0100, Mark Olesen via devel wrote: > > > Checking my copr log, it seems that centos-stream-8 (and epel-8) > > has > > > this: > > > > > > ptscotch-o

Re: copr and centos9 ?

On Wed, 21 Dec 2022 at 12:03, Sérgio Basto wrote: > On Wed, 2022-12-21 at 17:58 +0100, Mark Olesen via devel wrote: > > Checking my copr log, it seems that centos-stream-8 (and epel-8) has > > this: > > > > ptscotch-openmpi-devel x86_64 6.0.5-3.el8 powertools > > scotch-devel x86_

Re: copr and centos9 ?

On Wed, 2022-12-21 at 17:58 +0100, Mark Olesen via devel wrote: > Checking my copr log, it seems that centos-stream-8 (and epel-8) has > this: > > ptscotch-openmpi-devel   x86_64   6.0.5-3.el8 powertools > scotch-devel x86_64   6.0.5-3.el8 powertools > > I was mistaken about it workin

Re: copr and centos9 ?

Checking my copr log, it seems that centos-stream-8 (and epel-8) has this: ptscotch-openmpi-devel x86_64 6.0.5-3.el8 powertools scotch-devel x86_64 6.0.5-3.el8 powertools I was mistaken about it working with epel-9. It also fails to load there. So I guess my question has now e

Re: copr and centos9 ?

On Wed, 21 Dec 2022 at 11:05, Michael J Gruber wrote: > > The devel package are not included in CentOS repositories unless > requested > > Yes, but Mark reports that his package builds "with EPEL, but not with > CentOS". As for as I know, we have the following in copr: > > chroot "epel 9" has bas

Re: copr and centos9 ?

> The devel package are not included in CentOS repositories unless requested Yes, but Mark reports that his package builds "with EPEL, but not with CentOS". As for as I know, we have the following in copr: chroot "epel 9" has base RHEL9 and repos base+AppStream+CRB+Extras+EPEL chroot "centos str

Re: copr and centos9 ?

Dne 21. 12. 22 v 16:14 Mark Olesen via devel napsal(a): I'm using copr for https://copr.fedorainfracloud.org/coprs/openfoam/openfoam/ and now finally also enabled for building on epel9 and centos-stream-9 (both x86_64). With the centos-stream-9 I get these messages: Updating Subscription Manag

Re: COPR Build Failures for fedora-35-i686

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 bui

Re: COPR and rpmautospec

On 18/12/2022 15:14, Michael J Gruber wrote: %autorelease needs the git history, and you are building from dist-git, so that part is fine. COPR has Git history. Example: https://copr-dist-git.fedorainfracloud.org/cgit/xvitaly/matrix/neochat.git/log/ -- Sincerely, Vitaly Zaitsev (vit...@eas

Re: COPR and rpmautospec

* Michael J. Gruber: > I'm afraid you're not holding it right ;) > > %autorelease needs the git history, and you are building from > dist-git, so that part is fine. But you are not using `Release: > %autorelease` but, instead, there are additional tags in there. And - > depending on your view on o

Re: COPR Build Failures for fedora-35-i686

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. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org

Re: COPR Build Failures for fedora-35-i686

* Frank Crawford: > I'm trying to build a package (rdiff-backup) for multiple > architectures and releases of Fedora, and all of them work, except > fedora-35-i686, which comes up with the following complaint: > > This system is not registered with an entitlement server. You can use > subscription

Re: COPR and rpmautospec

I'm afraid you're not holding it right ;) %autorelease needs the git history, and you are building from dist-git, so that part is fine. But you are not using `Release: %autorelease` but, instead, there are additional tags in there. And - depending on your view on old vs. new version names - thi

Re: COPR and rpmautospec

On Sat, Dec 17, 2022, 20:59 Florian Weimer wrote: > It looks like COPR always produces 1 for %autorelease. Is this a known > issue? Is there a way around it? > > Here's a build that shows this: > > < > https://copr.fedorainfracloud.org/coprs/fweimer/modernc-1/build/5152562/> > > Thanks, > Flo

Re: COPR and rpmautospec

On 17/12/2022 20:59, Florian Weimer wrote: It looks like COPR always produces 1 for %autorelease. Is this a known issue? Yes. rpmautospec works correctly only in Fedora Koji. In rpmbuild, mock, COPR, it will always use 1. Is there a way around it? I didn't find it, so I reverted my packa

Re: Copr delete-by-default expiration policy still unacceptable

On Fri, Oct 14, 2022 at 09:24:05AM +0200, Miroslav Suchý wrote: > Dne 13. 10. 22 v 14:41 Kevin Kofler via devel napsal(a): > > At least allow the opt-out per maintainer. > > > > I would suggest to add the permanent opt-out checkbox, mark it "(BETA)", and > > then evaluate how many maintainers actu

Re: Copr delete-by-default expiration policy still unacceptable

Dne 13. 10. 22 v 16:24 Josh Boyer napsal(a): Would you be willing to pay for that feature? BTW I have been seriously probing for some time whether people would be willing to pay for private repositories. And this is my first time mentioning it in public space :) Miroslav

Re: Copr delete-by-default expiration policy still unacceptable

Dne 13. 10. 22 v 17:18 PGNet Dev napsal(a): Another option is to get the containerized COPR efforts polished & available.  Then, any/all could spin them up easily (aka, far easier than now), and deploy locally, &/or make available ... and, charge some reasonable fee for those downloads. https:

Re: Copr delete-by-default expiration policy still unacceptable

Dne 13. 10. 22 v 14:41 Kevin Kofler via devel napsal(a): At least allow the opt-out per maintainer. I would suggest to add the permanent opt-out checkbox, mark it "(BETA)", and then evaluate how many maintainers actually check that checkbox and how much resource usage is actually caused by it. T

Re: Copr delete-by-default expiration policy still unacceptable

Dne 13. 10. 22 v 15:27 Stephen Smoogen napsal(a): The problem is that they HAVE been running out of disk space quite regularly. This is not a new problem as COPR has bounced off of zero storage over time as various 'newer' hardware is moved over for their usage. Currently, the storage they are u

Re: Copr delete-by-default expiration policy still unacceptable

Dne 13. 10. 22 v 17:06 Neal Gompa napsal(a): Considering services like packagecloud.io and others exist and do manage to make money storing repositories and builds, I think it's pretty workable for COPR too. It would require some advertising and such to get it out there, but it'd be workable. W

Re: Copr delete-by-default expiration policy still unacceptable

On Thu, Oct 13, 2022 at 3:56 PM Josh Boyer wrote: > > On Thu, Oct 13, 2022 at 11:04 AM Gary Buhrmaster > wrote: > > > > On Thu, Oct 13, 2022 at 2:25 PM Josh Boyer > > wrote: > > > > > Would you be willing to pay for that feature? > > > > A "freemium" COPR service? > > > > I suspect that that wo

Re: Copr delete-by-default expiration policy still unacceptable

On Thu, Oct 13, 2022 at 11:04 AM Gary Buhrmaster wrote: > > On Thu, Oct 13, 2022 at 2:25 PM Josh Boyer wrote: > > > Would you be willing to pay for that feature? > > A "freemium" COPR service? > > I suspect that that would be such a > niche service that the cost per user > (to pay for the overhea

Re: Copr delete-by-default expiration policy still unacceptable

Don't get me wrong, the folks who work on Koji and Copr are great, but even they'll admit that they're woefully underfunded. The compose tooling, PDC, etc. are also examples of this problem. Can't agree enough. Hats off to the COPR folks. Without it, even it current state, RH/Fed ecosystem is,

Re: Copr delete-by-default expiration policy still unacceptable

On Thu, Oct 13, 2022 at 11:04 AM Gary Buhrmaster wrote: > > On Thu, Oct 13, 2022 at 2:25 PM Josh Boyer wrote: > > > Would you be willing to pay for that feature? > > A "freemium" COPR service? > > I suspect that that would be such a > niche service that the cost per user > (to pay for the overhea

Re: Copr delete-by-default expiration policy still unacceptable

On Thu, Oct 13, 2022 at 2:25 PM Josh Boyer wrote: > Would you be willing to pay for that feature? A "freemium" COPR service? I suspect that that would be such a niche service that the cost per user (to pay for the overheads to create and maintain it) would not be acceptable to anyone. _

Re: Copr delete-by-default expiration policy still unacceptable

Il 13/10/22 16:48, Kevin Kofler via devel ha scritto: > > What makes Copr so interesting is that it is offered at no cost to all > Fedora contributors. But it has always been treated as an unloved stepchild > by Red Hat and has never received the kind of resources, e.g., OBS has. Is there any chan

Re: Copr delete-by-default expiration policy still unacceptable

On Thu, Oct 13, 2022 at 10:48 AM Kevin Kofler via devel wrote: > > Josh Boyer wrote: > > Would you be willing to pay for that feature? > > Probably not, because at that point, it would probably be cheaper to just > set up a mirror or even a full-fledged build system on a VPS somewhere. Or > even t

Re: Copr delete-by-default expiration policy still unacceptable

On Thu, Oct 13, 2022 at 10:48 AM Kevin Kofler via devel wrote: > > Josh Boyer wrote: > > Would you be willing to pay for that feature? > > Probably not, because at that point, it would probably be cheaper to just > set up a mirror or even a full-fledged build system on a VPS somewhere. Or > even t

Re: Copr delete-by-default expiration policy still unacceptable

Josh Boyer wrote: > Would you be willing to pay for that feature? Probably not, because at that point, it would probably be cheaper to just set up a mirror or even a full-fledged build system on a VPS somewhere. Or even to use OBS, though I do not know what their retention policies for old repo

Re: Copr delete-by-default expiration policy still unacceptable

You do have to admit that this happens only as a result of: - wanting to support EOLed chroots - not wanting to support non EOLed chroots (for those projects) - not receiving notification e-mails - not logging onto the web UI for more than 75 days All of this in combination, and knowingly, as you

Re: Copr delete-by-default expiration policy still unacceptable

On Thu, Oct 13, 2022 at 8:41 AM Kevin Kofler via devel wrote: > > Miroslav Suchý wrote: > > Dne 13. 10. 22 v 6:12 Kevin Kofler via devel napsal(a): > >> I am really angry at Copr's expiration policy once again. It looks like I > >> missed the deadline to renew the expired chroots (I still do not g

Re: Copr delete-by-default expiration policy still unacceptable

On Thu, 13 Oct 2022 at 08:49, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Miroslav Suchý wrote: > > Dne 13. 10. 22 v 6:12 Kevin Kofler via devel napsal(a): > >> I am really angry at Copr's expiration policy once again. It looks like > I > >> missed the deadline to renew the ex

Re: Copr delete-by-default expiration policy still unacceptable

Miroslav Suchý wrote: > Dne 13. 10. 22 v 6:12 Kevin Kofler via devel napsal(a): >> I am really angry at Copr's expiration policy once again. It looks like I >> missed the deadline to renew the expired chroots (I still do not get any >> notification mails, they end up eaten in a spam filter somewher

Re: Copr delete-by-default expiration policy still unacceptable

Dne 13. 10. 22 v 6:12 Kevin Kofler via devel napsal(a): I am really angry at Copr's expiration policy once again. It looks like I missed the deadline to renew the expired chroots (I still do not get any notification mails, they end up eaten in a spam filter somewhere), so once again a lot of data

Re: Copr delete-by-default expiration policy still unacceptable

PS: At the very least, you could add a checkbox to allow a maintainer to opt out permanently of automatic expiration (it would still be possible to manually click on "Expire now"), as opposed to having to click dozens of buttons (an everincreasing number, since there is not even an "Extend all"

Re: Copr login not working

Sorry for the late reply. It's working great again. Thank you for restoring the service and best of luck figuring out the bug you encountered. Chris On Thu., Jun. 2, 2022, 9:45 p.m. Kevin Fenzi, wrote: > On Thu, Jun 02, 2022 at 08:34:51PM -0400, Chris wrote: > > Hi, > > > > Can't seem to log i

Re: Copr login not working

On Thu, Jun 02, 2022 at 08:34:51PM -0400, Chris wrote: > Hi, > > Can't seem to log into COPR; I can log into everything else, but after > providing my correct user/pass combo and logging in, the screen just > returns back as though I never even attempted (the log in). > > I tried resetting my pas

Re: copr expired security certificate?

On Wed, Mar 02, 2022 at 05:06:59PM -0500, Steven A. Falco wrote: > On 3/2/22 04:35 PM, Scott Talbert wrote: > > On Wed, 2 Mar 2022, Steven A. Falco wrote: > > > > > I just tried to connect to copr [1] with firefox, and got a "Did Not > > > Connect: Potential Security Issue" error. > > > > > > An

Re: copr expired security certificate?

On 3/2/22 04:35 PM, Scott Talbert wrote: On Wed, 2 Mar 2022, Steven A. Falco wrote: I just tried to connect to copr [1] with firefox, and got a "Did Not Connect: Potential Security Issue" error. And apparently copr uses HSTS, so I cannot override it.  Is anyone else having the problem? [1]

Re: copr expired security certificate?

On Wed, 2 Mar 2022, Steven A. Falco wrote: I just tried to connect to copr [1] with firefox, and got a "Did Not Connect: Potential Security Issue" error. And apparently copr uses HSTS, so I cannot override it. Is anyone else having the problem? [1] https://copr.fedoraproject.org/coprs/g/ki

Re: copr expired security certificate?

Hi Steve, I get the same error when I use the URL you linked. Typically when I interface with copr, I'm using (maybe wrongly) the 'copr.fedorainfracloud.org' URL instead. To which point I can reach the build you're trying to get to that way. https://copr.fedorainfracloud.org/coprs/g/kicad/kicad

Re: Copr success but no packages?

On 1/4/22 04:28 AM, Vitaly Zaitsev via devel wrote: On 03/01/2022 22:25, Steven A. Falco wrote: The builder-live.log in the F35 dir shows that the rpms were written, but they are missing from the dir. Too aggressive web cache on COPR side. I've seen this issue several times too. Thanks for

Re: Copr success but no packages?

On 03/01/2022 22:25, Steven A. Falco wrote: The builder-live.log in the F35 dir shows that the rpms were written, but they are missing from the dir. Too aggressive web cache on COPR side. I've seen this issue several times too. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) _

Re: Copr success but no packages?

On Tuesday, January 4, 2022 8:51:58 AM CET Miroslav Suchý wrote: > Dne 03. 01. 22 v 22:57 Steven A. Falco napsal(a): > > On 1/3/22 04:38 PM, Elliott Sales de Andrade wrote: > >> Here are direct links to the chroots: > >>> > >>> https://download.copr.fedorainfracloud.org/results/stevenfalco/kicad/fe

Re: Copr success but no packages?

Dne 03. 01. 22 v 22:57 Steven A. Falco napsal(a): On 1/3/22 04:38 PM, Elliott Sales de Andrade wrote: Here are direct links to the chroots: https://download.copr.fedorainfracloud.org/results/stevenfalco/kicad/fedora-34-x86_64/03123050-kicad/ https://download.copr.fedorainfracloud.org/results/

Re: Copr success but no packages?

On 1/3/22 04:38 PM, Elliott Sales de Andrade wrote: On Mon, 3 Jan 2022 at 16:25, Steven A. Falco wrote: I ran the following build on Copr: https://copr.fedorainfracloud.org/coprs/stevenfalco/kicad/build/3123050/ There are three chroots, one for F34, F35, and rawhide (all x86_64). All report

Re: Copr success but no packages?

On Mon, 3 Jan 2022 at 16:25, Steven A. Falco wrote: > > I ran the following build on Copr: > > https://copr.fedorainfracloud.org/coprs/stevenfalco/kicad/build/3123050/ > > There are three chroots, one for F34, F35, and rawhide (all x86_64). > > All report "success", but there are no resulting rpm

Re: Copr success but no packages?

Hi Steve, It looks like you had some (browser?) caching issue, all the rpms in all the chroots are there. Best regards, A. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedor

Re: Copr - look back at 2021

On Monday, January 3, 2022 11:30:42 AM CET Tomas Tomecek wrote: > On Thu, Dec 30, 2021 at 3:35 PM Miroslav Suchý wrote: > > > > >- > > > >Statistics: > >- > > > > Copr run 2,900,000 builds. > > - > > > > People created 15 731 new projects. > > > > > Whaaat! The whole

Re: Copr - look back at 2021

On Thu, Dec 30, 2021 at 3:35 PM Miroslav Suchý wrote: > >- > >Statistics: >- > > Copr run 2,900,000 builds. > - > > People created 15 731 new projects. > > Whaaat! The whole list of things you have achieved is mega impressive but this one totally caught my eye: doing

Re: Copr - look back at 2021

On Thu, Dec 30, 2021 at 03:33:05PM +0100, Miroslav Suchý wrote: > Let me sum up what the Copr team did during 2021: Thanks so much for all your work in the last year! kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists

Re: Copr - look back at 2021

On Thu, Dec 30, 2021 at 03:33:05PM +0100, Miroslav Suchý wrote: > Let me sum up what the Copr team did during 2021: Lots of great stuff, thanks! >We had an initial meeting about rebase-helper automatically opening PR in > src.fedoraproject.org. There is even some >code written

Re: Copr - look back at 2021

On Fri, Dec 31, 2021 at 9:20 AM Benson Muite wrote: > > On 12/30/21 5:33 PM, Miroslav Suchý wrote: > > Let me sum up what the Copr team did during 2021: > > > Awesome work. Looking forward to a great 2022! Let me second that. Thank you all for working on COPR and related projects. I use those ser

Re: Copr - look back at 2021

On 12/30/21 5:33 PM, Miroslav Suchý wrote: Let me sum up what the Copr team did during 2021: Awesome work. Looking forward to a great 2022! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedor

Re: Copr for ppc64le "No space left on device"

On 9/22/21 11:12, Stephen John Smoogen wrote: On Wed, 22 Sept 2021 at 10:20, Steven A. Falco wrote: The KiCAD project builds "nightly" images via copr. Lately, I'm seeing many failures for the ppc64le architecture. In some cases [1] I get "Error: Failed to download metadata for repo 'fedora

Re: Copr for ppc64le "No space left on device"

On Wed, 22 Sept 2021 at 10:20, Steven A. Falco wrote: > > The KiCAD project builds "nightly" images via copr. Lately, I'm seeing many > failures for the ppc64le architecture. In some cases [1] I get "Error: > Failed to download metadata for repo 'fedora'". In other cases [2] I get > "pigz: a

Re: Copr in 2020 and outlook for 2021

On Sat, Feb 13, 2021 at 3:06 PM Ken Dreyer wrote: > > On Mon, Jan 4, 2021 at 9:52 AM Miroslav Suchý wrote: > > * Contribute to fedpkg/koji to have machine-readable output. > > There is a "--json" argument to "koji call", and that produces > machine-readable output for individual Koji RPCs. > > I

Re: Copr in 2020 and outlook for 2021

On Mon, Jan 4, 2021 at 9:52 AM Miroslav Suchý wrote: > * Contribute to fedpkg/koji to have machine-readable output. There is a "--json" argument to "koji call", and that produces machine-readable output for individual Koji RPCs. It would be really nice if rpkg had something similar, or even an

Re: Copr in 2020 and outlook for 2021

On 04. 01. 21 20:53, Miro Hrončok wrote: On 04. 01. 21 20:48, Miroslav Suchý wrote: Dne 04. 01. 21 v 20:14 Miro Hrončok napsal(a): Is there any chance we could vote for GitHub Actions enablement instead of Travis? Currently we run a Fedora Docker image on top of the Ubuntu host, which is less t

Re: Copr in 2020 and outlook for 2021

On 04. 01. 21 20:48, Miroslav Suchý wrote: Dne 04. 01. 21 v 20:14 Miro Hrončok napsal(a): Is there any chance we could vote for GitHub Actions enablement instead of Travis? Currently we run a Fedora Docker image on top of the Ubuntu host, which is less than ideal in some cases (e.g., filesystem

Re: Copr in 2020 and outlook for 2021

Dne 04. 01. 21 v 20:14 Miro Hrončok napsal(a): >> Is there any >> chance we could vote for GitHub Actions enablement instead of Travis? >> Currently we run a Fedora Docker image on top of the Ubuntu host, >> which is less than ideal in some cases (e.g., filesystem package >> upgrades...). > > I wa

Re: Copr in 2020 and outlook for 2021

Dne 04. 01. 21 v 20:36 Dan Čermák napsal(a): > Is it intentional that google asks me to sign in? I don't actually have > a google account. Yes. It is intentional. The motivation is that you can change your vote later. If you do not have google account then just write me an email. I will add it to

Re: Copr in 2020 and outlook for 2021

Hi, Miroslav Suchý writes: > Let me sum up what we - the Copr team - did in 2020: > > * We enabled CDN for repos. https://fedora-copr.github.io/posts/copr-cdn > > * We enabled runtime dependecies on repositories > https://fedora-copr.github.io/posts/runtime-dependencies > > * We migrated all

Re: Copr in 2020 and outlook for 2021

On 04. 01. 21 18:40, Alexander Scheel wrote: * Native support for Fedora in Travis. Travis has made a lot of changes to how OSS projects can use it, and (IMO) burnt a lot of good will in the community. All of our upstream projects ended up moving off it and onto GitHub Actions. Is there any ch

Re: Copr in 2020 and outlook for 2021

Congrats! I can say I've used several of these features and they work well, thanks for your team's work! One query inline... :) On Mon, Jan 4, 2021 at 11:53 AM Miroslav Suchý wrote: > > Let me sum up what we - the Copr team - did in 2020: > > * We enabled CDN for repos. https://fedora-copr.git

Re: [COPR] [armhfp] insufficient space to install deps

On Monday, November 30, 2020 11:00:32 PM CET Petr Stodulka wrote: > Hi guys, > not sure whether I missed something, but I have realized troubles > with building for the armhfp arch. The build process crash on > installation of requirements because of inssuficient space: > > https://download.cop

Re: Copr timeout on large KiCAD package

Dne 30. 11. 20 v 19:29 Rudolf Kastl napsal(a): > copr-cli has a --timeout option (in seconds). had the same issue with llvm. WebUI has the the option as well when you specify new build. > the default timeout from 18000 seconds (5 hours). You can set it to a max of > 20 hours. The default is 180

Re: Copr timeout on large KiCAD package

Thanks for the replies. I'll add the CLI timeout flag to our CI scripts. Steve On 11/30/20 1:29 PM, Rudolf Kastl wrote: copr-cli has a --timeout option (in seconds). had the same issue with llvm. - Rudolf Kastl Am Mo., 30. Nov. 2020 um 19:24 Uhr schrieb Richard Shaw : On Mon, Nov 3

Re: Copr timeout on large KiCAD package

copr-cli has a --timeout option (in seconds). had the same issue with llvm. - Rudolf Kastl Am Mo., 30. Nov. 2020 um 19:24 Uhr schrieb Richard Shaw : > > On Mon, Nov 30, 2020 at 11:42 AM Steven A. Falco > wrote: >> >> KiCAD has a large package containing 3D component models. It takes a long >>

Re: Copr timeout on large KiCAD package

On Mon, Nov 30, 2020 at 11:42 AM Steven A. Falco wrote: > KiCAD has a large package containing 3D component models. It takes a long > time to compress with the new zstd compressor. So long in fact that the > copr build system is throwing a timeout. You can see an example here: > > > https://do

Re: [COPR] Build against libuv and Judy librairies

On Thu, Nov 05, 2020 at 09:29:46AM +0100, Didier Fabert wrote: > Hi, > > I try to make an epel-8 package on COPR, and I get the following errors in > root.log > DEBUG util.py:634: No matching package to install: 'Judy-devel' > DEBUG util.py:634: No matching package to install: 'libuv-devel' > >

Re: Copr package build fails on python-nocaselist package

elist/> Is that the way to do it? > > Also, as far as I'm concerned we do not necessarily need to get the COPR > build to succeed, as long as I can get the package review started by > pointing to a Koji build. Please let me know. > > Andy > > > Begin forwarded message

Re: Copr package build fails on python-nocaselist package

On Friday, 18 September 2020 09:19:48 CEST Andreas R Maier wrote: > Hi, > I am new to building packages, and I'm trying to build a new package > 'python-nocaselist' on Copr, and it fails in the %prep stage when unpacking > the SRPM file because it cannot cd into the directory it assumes got > unpac

Re: copr builds for rawhide 64-bit arches failing

Thanks for the report. On Saturday, February 15, 2020 3:09:49 PM CET Alexander Ploumistos wrote: > DEBUG util.py:596: ERROR: not a btrfs filesystem: /var/lib/mock > DEBUG util.py:596: ERROR: can't access '/var/lib/mock' > DEBUG util.py:744: Child return code was: 1 > DEBUG util.py:1580: Please

Re: copr builds for rawhide 64-bit arches failing

And now I am getting gpg key mismatches. Should I just wait it out and keep resubmitting builds until they succeed? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of

Re: Copr Build System - review of 2019 and vote for features in 2020

On Mon, Feb 10, 2020 at 01:46:14AM -0700, John M. Harris Jr wrote: > So long as people are willing to maintain it, why restrict peoples' ability > to > work on something, especially while users are stuck on that version, or > forced > to move elsewhere if they cannot get a fix and cannot upgra

Re: Copr Build System - review of 2019 and vote for features in 2020

On Thursday, January 30, 2020 6:31:37 PM MST Kevin Fenzi wrote: > On Thu, Jan 23, 2020 at 11:07:21AM -0700, John M. Harris Jr wrote: > > EOL is not, literally, EOL. EOL just means the complete end of support, in > > commercial products. Still doesn't mean systems with that version > > installed > >

Re: Copr Build System - review of 2019 and vote for features in 2020

On Thu, Jan 23, 2020, 9:04 AM Stephen John Smoogen wrote: > On Wed, 22 Jan 2020 at 06:04, Kevin Kofler wrote: > > > > Kevin Kofler wrote: > > > IMHO, this whole "delete by default" concept is inherently flawed and > > > dangerous and cannot be fixed. Notification e-mails can be lost in so > many

Re: Copr Build System - review of 2019 and vote for features in 2020

On Thu, Jan 23, 2020 at 11:07:21AM -0700, John M. Harris Jr wrote: > > EOL is not, literally, EOL. EOL just means the complete end of support, in > commercial products. Still doesn't mean systems with that version installed > cease to exist. In Fedora, it simply means that it gets little attenti

Re: Copr Build System - review of 2019 and vote for features in 2020

On Thursday, January 23, 2020 7:05:14 AM MST Miroslav Suchý wrote: > Dne 22. 01. 20 v 12:03 Kevin Kofler napsal(a): > > > I also do not understand why 6 TB of disk space is such an issue in times > > > > where one single HDD can carry up to 16 TB. > > > Because you need more of them because of

Re: Copr Build System - review of 2019 and vote for features in 2020

On Wed, 22 Jan 2020 at 06:04, Kevin Kofler wrote: > > Kevin Kofler wrote: > > IMHO, this whole "delete by default" concept is inherently flawed and > > dangerous and cannot be fixed. Notification e-mails can be lost in so many > > ways (wrong Fedora notification settings, e-mail provider issues, s

Re: Copr Build System - review of 2019 and vote for features in 2020

Dne 22. 01. 20 v 12:03 Kevin Kofler napsal(a): > I also do not understand why 6 TB of disk space is such an issue in times > where one single HDD can carry up to 16 TB. Because you need more of them because of RAID. And because once you reach the roof - 16 GB atm - the price does not grow linear

Re: Copr Build System - review of 2019 and vote for features in 2020

On Wednesday, January 22, 2020 1:05:45 PM CET Kevin Kofler wrote: > Miro Hrončok wrote: > > Do you realize that copr is a free service (as in free beer in this > > argument)? > > So is Fedora as a whole, yet it does not completely delete EOL releases, > but puts them on archive.fedoraproject.org. >

Re: Copr Build System - review of 2019 and vote for features in 2020

On 2020-01-22 12:03, Kevin Kofler wrote: Kevin Kofler wrote: IMHO, this whole "delete by default" concept is inherently flawed and dangerous and cannot be fixed. Notification e-mails can be lost in so many ways (wrong Fedora notification settings, e-mail provider issues, spam filter false posi

Re: Copr Build System - review of 2019 and vote for features in 2020

On 22. 01. 20 13:05, Kevin Kofler wrote: Miro Hrončok wrote: Do you realize that copr is a free service (as in free beer in this argument)? So is Fedora as a whole, yet it does not completely delete EOL releases, but puts them on archive.fedoraproject.org. Gratuity (the state of being free as

Re: Copr Build System - review of 2019 and vote for features in 2020

Miro Hrončok wrote: > Do you realize that copr is a free service (as in free beer in this > argument)? So is Fedora as a whole, yet it does not completely delete EOL releases, but puts them on archive.fedoraproject.org. Gratuity (the state of being free as in beer) is no excuse for deliberate d

  1   2   3   4   >