Re: Highlights from the latest Copr release
Thanks for fixing it! I tried on irc, but I'm not an irc guy and couldn't make it past "cannot send to nick/channel" ... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release
On Saturday, November 14, 2020 2:36:43 PM CET Michael J Gruber wrote: > Same today: > > ssh: connect to host 3.237.199.13 port 22: Connection timed out > > https://download.copr.fedorainfracloud.org/results/mjg/scribus/fedora-32-x86_64/01768969-scribus156/builder-live.log.gz > > Copr infra networked borked? Meh, no. Sorry for inconvenience. We moved the copr backend to new VM and we kept the old one running because we still want to debug one old problem there. But there was a collision on one builder garbage collecting cron job which I just now stopped. It should be fixed now. Thank you for the report! Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release
Same today: ssh: connect to host 3.237.199.13 port 22: Connection timed out https://download.copr.fedorainfracloud.org/results/mjg/scribus/fedora-32-x86_64/01768969-scribus156/builder-live.log.gz Copr infra networked borked? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release
Builds seem to be failing right in the middle due to "broken ssh connections" again and again now. Maybe builders switching over one by one and taking build down? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release
On Friday, November 13, 2020 6:44:14 PM CET Iñaki Ucar wrote: > On Fri, 13 Nov 2020 at 18:13, Pavel Raiskup wrote: > > > - Can a build depend on more than one build ID? > > > > You should rather think about "batches" in this case, and each batch can > > only depend on one batch. > > > > Corner cases aside => --after-build-id creates a new batch, --with-build-id > > puts > > the build into an existing batch. > > And we can use any build ID in a batch with those flags, right? I.e., > we don't need to keep track of the first one in the batch. Correct. Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release
On Fri, 13 Nov 2020 at 18:13, Pavel Raiskup wrote: > > Thanks for questions! > > On Friday, November 13, 2020 5:50:46 PM CET Iñaki Ucar wrote: > > On Fri, 13 Nov 2020 at 17:26, Pavel Raiskup wrote: > > > > > > Hello! > > > > > > On Nov 13 2020, a new Copr release landed production. The list of user > > > visible > > > changes is in the release notes document: > > > > > > https://docs.pagure.org/copr.copr/release-notes/2020-11-13.html > > > > Many thanks for the build batches feature! I have some questions about > > this. Building on the example in the release notes, > > > > - If a fourth build 101040 depends on 101020 and a fifth one 101050 > > depends on 101030, when do these ones start? As soon as each build, > > individually, finish? Or when the whole batch, 101020 and 101030, > > finishes? > > *20 and *30 re in one batch -- so both *40 and *50 are started at the same > time after the that batch finishes. > > Both *40 and *50 are put into a separate batch, but that is just a detail > in this case. > > The currently processed batch dependency tree can be observed at: > https://copr.fedorainfracloud.org/status/batches/ Nice. :) > > - Then, what happens if 101030 fails? > > The batch is finished as soon as all the builds inside are finished. No > matter if they failed or succeeded... so the other two batches will start > building. > > I know it is not ideal. In the future we could implement something more > clever like "give the maintainer a chance to fix the build, before we > continue...". But it would be way too complicated contribution at the > start (even the actual was). Please fill the RFE if you see a space for > enhancement. I think a flag to automatically cancel dependent builds if something fails in a batch wouldn't be too complicated to implement. Will fill an RFE. > > - Can a build depend on more than one build ID? > > You should rather think about "batches" in this case, and each batch can > only depend on one batch. > > Corner cases aside => --after-build-id creates a new batch, --with-build-id > puts > the build into an existing batch. And we can use any build ID in a batch with those flags, right? I.e., we don't need to keep track of the first one in the batch. > > - Are these flags (after-build, with-build) available for other build > > commands (e.g. buildscm)? > > I believe they are. Nice, thanks! -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release
Thanks for questions! On Friday, November 13, 2020 5:50:46 PM CET Iñaki Ucar wrote: > On Fri, 13 Nov 2020 at 17:26, Pavel Raiskup wrote: > > > > Hello! > > > > On Nov 13 2020, a new Copr release landed production. The list of user > > visible > > changes is in the release notes document: > > > > https://docs.pagure.org/copr.copr/release-notes/2020-11-13.html > > Many thanks for the build batches feature! I have some questions about > this. Building on the example in the release notes, > > - If a fourth build 101040 depends on 101020 and a fifth one 101050 > depends on 101030, when do these ones start? As soon as each build, > individually, finish? Or when the whole batch, 101020 and 101030, > finishes? *20 and *30 re in one batch -- so both *40 and *50 are started at the same time after the that batch finishes. Both *40 and *50 are put into a separate batch, but that is just a detail in this case. The currently processed batch dependency tree can be observed at: https://copr.fedorainfracloud.org/status/batches/ > - Then, what happens if 101030 fails? The batch is finished as soon as all the builds inside are finished. No matter if they failed or succeeded... so the other two batches will start building. I know it is not ideal. In the future we could implement something more clever like "give the maintainer a chance to fix the build, before we continue...". But it would be way too complicated contribution at the start (even the actual was). Please fill the RFE if you see a space for enhancement. > - Can a build depend on more than one build ID? You should rather think about "batches" in this case, and each batch can only depend on one batch. Corner cases aside => --after-build-id creates a new batch, --with-build-id puts the build into an existing batch. > - Are these flags (after-build, with-build) available for other build > commands (e.g. buildscm)? I believe they are. Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release
On Fri, 13 Nov 2020 at 17:50, Iñaki Ucar wrote: > > On Fri, 13 Nov 2020 at 17:26, Pavel Raiskup wrote: > > > > Hello! > > > > On Nov 13 2020, a new Copr release landed production. The list of user > > visible > > changes is in the release notes document: > > > > https://docs.pagure.org/copr.copr/release-notes/2020-11-13.html > > Many thanks for the build batches feature! I have some questions about > this. Building on the example in the release notes, > > - If a fourth build 101040 depends on 101020 and a fifth one 101050 > depends on 101030, when do these ones start? As soon as each build, > individually, finish? Or when the whole batch, 101020 and 101030, > finishes? > > - Then, what happens if 101030 fails? > > - Can a build depend on more than one build ID? > > - Are these flags (after-build, with-build) available for other build > commands (e.g. buildscm)? build-package was a better example for this. -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release
On Fri, 13 Nov 2020 at 17:26, Pavel Raiskup wrote: > > Hello! > > On Nov 13 2020, a new Copr release landed production. The list of user > visible > changes is in the release notes document: > > https://docs.pagure.org/copr.copr/release-notes/2020-11-13.html Many thanks for the build batches feature! I have some questions about this. Building on the example in the release notes, - If a fourth build 101040 depends on 101020 and a fifth one 101050 depends on 101030, when do these ones start? As soon as each build, individually, finish? Or when the whole batch, 101020 and 101030, finishes? - Then, what happens if 101030 fails? - Can a build depend on more than one build ID? - Are these flags (after-build, with-build) available for other build commands (e.g. buildscm)? Thanks, -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Highlights from the latest Copr release
Hello! On Nov 13 2020, a new Copr release landed production. The list of user visible changes is in the release notes document: https://docs.pagure.org/copr.copr/release-notes/2020-11-13.html Happy building! Copr Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release
Unfortunately, Copr still deletes data without warning: https://bugzilla.redhat.com/show_bug.cgi?id=1868367 Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release
On Wed, 12 Aug 2020 at 12:32, Pavel Raiskup wrote:
>
> On Wednesday, August 12, 2020 11:19:00 AM CEST Iñaki Ucar wrote:
> > On Wed, 12 Aug 2020 at 10:29, Pavel Raiskup wrote:
> > > - Copr newly provides a build-time macro %buildtag. Its format is
> > > `.copr` and is useable for auto-incrementing the package's NVR
> > > in subsequent builds. It may be used in spec file like:
> > >
> > > Release: 1%{?dist}%{?buildtag}
> > >
> > > It could be useful as good-enough alternative for the Release
> > > auto-bumping proposal. See the fedora devel discussion [2] for more
> > > info. This is not any kind of encouragement to use it. We added it
> > > there to easy testing your ideas about the automatic filling of the
> > > Release tag.
> >
> > Nice one! I understand that having a mix of builds with and without
> > this tag isn't an issue, right? I.e., would
> > --.copr.fcXX be picked as an update of
> > --.fcXX? Or do we need to rebuild all with the
> > new tag and remove the old ones?
>
> No need to do batch-updates.
>
> $ rpmdev-vercmp 1-1.fc32.copr1234 1-1.fc32
> 1-1.fc32.copr1234 > 1-1.fc32
>
> But note I proposed to use %buildtag after %dist, not vice versa. Moving
> %buildtag before %dist would mean that we loose the benefit of dist
> tag -- when both fcNN and fcNN-1 builds exist in multiple repositories
> (notable example is 'fedora' and 'updates') fcNN is the preferred variant
> for installation.
Oh, yeap, right, I pasted the dist tag in the wrong place.
> > > - All the background jobs have now a lower priority than normal jobs.
> > > Previously, background source builds were still prioritized over normal
> > > builds. This should be the last step towards a fair build scheduler.
> >
> > Change of mind? My understanding from the last time we discussed this
> > was that source builds needed to be prioritized no matter what.
>
> No problems to admit a change of mind ;-) that happens all the time.
:)
> Mainly I was afraid that source background builds will eat too much of the
> frontend storage. But there don't seem to be that huge performance
> problems, and that worry was probably a bit over-pessimistic.
I think both options are fine (background source builds with higher or
lower priority), as I said in prior discussions, provided that
non-background normal builds get prioritized over background normal
builds. :)
--
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release
On Wednesday, August 12, 2020 11:19:00 AM CEST Iñaki Ucar wrote:
> On Wed, 12 Aug 2020 at 10:29, Pavel Raiskup wrote:
> >
> > Hello.
> >
> > On Aug 12 2020, a new Copr release landed production. Here is the list
> > of visible changes:
> >
> > - Project karma implemented; Logged-in users can give
> > thumbs-up/thumbs-down to the existing copr projects. This is just
> > another way to give feedback about a particular Copr project quality.
> > This is merely subjective. We do not give you guidance what "thumbs
> > up/down" means. When it is good for you - for whatever reason - give it
> > thumbs up. It may be just feedback for the maintainer or other users.
> > Or we may automatically select and group high-quality projects in the
> > future - and e.g. revive the idea of the Playground [1]. The options
> > are open. We would like to hear your feedback about this feature!
>
> I suppose that the UI looks for some resemblance to StackOverflow's
> vote counter. SO's counter is more prominent in the first place
> (larger arrows and number), but I don't even think that's a good UI.
> We simply got accustomed to it because we know what it is.
Yes, we looked at several popular sites and the voting UI, and picked one
of the existing variants.
> > - Copr newly provides a build-time macro %buildtag. Its format is
> > `.copr` and is useable for auto-incrementing the package's NVR
> > in subsequent builds. It may be used in spec file like:
> >
> > Release: 1%{?dist}%{?buildtag}
> >
> > It could be useful as good-enough alternative for the Release
> > auto-bumping proposal. See the fedora devel discussion [2] for more
> > info. This is not any kind of encouragement to use it. We added it
> > there to easy testing your ideas about the automatic filling of the
> > Release tag.
>
> Nice one! I understand that having a mix of builds with and without
> this tag isn't an issue, right? I.e., would
> --.copr.fcXX be picked as an update of
> --.fcXX? Or do we need to rebuild all with the
> new tag and remove the old ones?
No need to do batch-updates.
$ rpmdev-vercmp 1-1.fc32.copr1234 1-1.fc32
1-1.fc32.copr1234 > 1-1.fc32
But note I proposed to use %buildtag after %dist, not vice versa. Moving
%buildtag before %dist would mean that we loose the benefit of dist
tag -- when both fcNN and fcNN-1 builds exist in multiple repositories
(notable example is 'fedora' and 'updates') fcNN is the preferred variant
for installation.
> > - All the background jobs have now a lower priority than normal jobs.
> > Previously, background source builds were still prioritized over normal
> > builds. This should be the last step towards a fair build scheduler.
>
> Change of mind? My understanding from the last time we discussed this
> was that source builds needed to be prioritized no matter what.
No problems to admit a change of mind ;-) that happens all the time.
Mainly I was afraid that source background builds will eat too much of the
frontend storage. But there don't seem to be that huge performance
problems, and that worry was probably a bit over-pessimistic.
Also, source builds are not yet visible in statistics, so if there's any
problem with source builds - it isn't anyhow obvious (Dominik is working
on the fix in issue 295).
Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release
On 12. 08. 20 11:19, Iñaki Ucar wrote:
- Copr newly provides a build-time macro %buildtag. Its format is
`.copr` and is useable for auto-incrementing the package's NVR
in subsequent builds. It may be used in spec file like:
Release: 1%{?dist}%{?buildtag}
It could be useful as good-enough alternative for the Release
auto-bumping proposal. See the fedora devel discussion [2] for more
info. This is not any kind of encouragement to use it. We added it
there to easy testing your ideas about the automatic filling of the
Release tag.
Nice one! I understand that having a mix of builds with and without
this tag isn't an issue, right? I.e., would
--.copr.fcXX be picked as an update of
--.fcXX? Or do we need to rebuild all with the
new tag and remove the old ones?
It's actually --.fcXX.copr in the example above. An
that sorts higher.
$ rpmdev-vercmp e:v-r.fc34.copr1234567 e:v-r.fc34
e:v-r.fc34.copr1234567 > e:v-r.fc34
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release
On 12. 08. 20 11:20, Pavel Raiskup wrote:
- Copr newly provides a build-time macro %buildtag. Its format is
`.copr` and is useable for auto-incrementing the package's NVR
in subsequent builds. It may be used in spec file like:
Release: 1%{?dist}%{?buildtag}
It could be useful as good-enough alternative for the Release
auto-bumping proposal. See the fedora devel discussion [2] for more
info. This is not any kind of encouragement to use it. We added it
there to easy testing your ideas about the automatic filling of the
Release tag.
This is really interesting feature for some of the projects.
Can this be used in official Fedora specfiles
It is meant to be no-op as long as build system doesn't define it. So at
least technically there's no problem.
or does it need a guideline?
I don't think it is forbidden by guidelines (we can not use macros for
other distributions, but that is a different topic). Dunno if we need to
have an explicit ACK for this. Ideas?
Most likely we don't. I was just trying to think ahead.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release
On Wednesday, August 12, 2020 10:51:56 AM CEST Miro Hrončok wrote:
> On 12. 08. 20 10:29, Pavel Raiskup wrote:
> > - Project karma implemented; Logged-in users can give
> >thumbs-up/thumbs-down to the existing copr projects. [snip]
> >This is just
>
> Assuming the arrows up and down near the copr name are for karma, I find the
> UI for this is a tad confusing. I've seen it before reading your announcement
> and had no idea what it is.
>
> (This is true especially before refreshing the browser cache, it gets a bit
> better after.)
Bleh, I faced the cache issue as well. Let's take a look if we can do something
about it...
> > - Copr newly provides a build-time macro %buildtag. Its format is
> >`.copr` and is useable for auto-incrementing the package's NVR
> >in subsequent builds. It may be used in spec file like:
> >
> > Release: 1%{?dist}%{?buildtag}
> >
> >It could be useful as good-enough alternative for the Release
> >auto-bumping proposal. See the fedora devel discussion [2] for more
> >info. This is not any kind of encouragement to use it. We added it
> >there to easy testing your ideas about the automatic filling of the
> >Release tag.
>
> This is really interesting feature for some of the projects.
> Can this be used in official Fedora specfiles
It is meant to be no-op as long as build system doesn't define it. So at
least technically there's no problem.
> or does it need a guideline?
I don't think it is forbidden by guidelines (we can not use macros for
other distributions, but that is a different topic). Dunno if we need to
have an explicit ACK for this. Ideas?
Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release
On Wed, 12 Aug 2020 at 10:29, Pavel Raiskup wrote:
>
> Hello.
>
> On Aug 12 2020, a new Copr release landed production. Here is the list
> of visible changes:
>
> - Project karma implemented; Logged-in users can give
> thumbs-up/thumbs-down to the existing copr projects. This is just
> another way to give feedback about a particular Copr project quality.
> This is merely subjective. We do not give you guidance what "thumbs
> up/down" means. When it is good for you - for whatever reason - give it
> thumbs up. It may be just feedback for the maintainer or other users.
> Or we may automatically select and group high-quality projects in the
> future - and e.g. revive the idea of the Playground [1]. The options
> are open. We would like to hear your feedback about this feature!
I suppose that the UI looks for some resemblance to StackOverflow's
vote counter. SO's counter is more prominent in the first place
(larger arrows and number), but I don't even think that's a good UI.
We simply got accustomed to it because we know what it is.
> - Copr newly provides a build-time macro %buildtag. Its format is
> `.copr` and is useable for auto-incrementing the package's NVR
> in subsequent builds. It may be used in spec file like:
>
> Release: 1%{?dist}%{?buildtag}
>
> It could be useful as good-enough alternative for the Release
> auto-bumping proposal. See the fedora devel discussion [2] for more
> info. This is not any kind of encouragement to use it. We added it
> there to easy testing your ideas about the automatic filling of the
> Release tag.
Nice one! I understand that having a mix of builds with and without
this tag isn't an issue, right? I.e., would
--.copr.fcXX be picked as an update of
--.fcXX? Or do we need to rebuild all with the
new tag and remove the old ones?
> - Command-line interface for the project package listing was significantly
> optimized, and should now be faster than the web-UI on large projects
> (issue/757).
Many thanks for this!
> - All the background jobs have now a lower priority than normal jobs.
> Previously, background source builds were still prioritized over normal
> builds. This should be the last step towards a fair build scheduler.
Change of mind? My understanding from the last time we discussed this
was that source builds needed to be prioritized no matter what.
> - Support for a new command 'copr-cli list-builds ' was added.
> It lists each build on a separate line, as a tab-separated list of
> items.
Just great! I'll try this instead of my "download a several-dozen-MB
HTML of builds, parse the table to get a dataframe and then regex the
columns" mad script. :)
--
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release
On 12. 08. 20 10:29, Pavel Raiskup wrote:
Hello.
On Aug 12 2020, a new Copr release landed production. Here is the list
of visible changes:
- Project karma implemented; Logged-in users can give
thumbs-up/thumbs-down to the existing copr projects. This is just
another way to give feedback about a particular Copr project quality.
This is merely subjective. We do not give you guidance what "thumbs
up/down" means. When it is good for you - for whatever reason - give it
thumbs up. It may be just feedback for the maintainer or other users.
Or we may automatically select and group high-quality projects in the
future - and e.g. revive the idea of the Playground [1]. The options
are open. We would like to hear your feedback about this feature!
Assuming the arrows up and down near the copr name are for karma, I find the UI
for this is a tad confusing. I've seen it before reading your announcement and
had no idea what it is.
(This is true especially before refreshing the browser cache, it gets a bit
better after.)
- Copr newly provides a build-time macro %buildtag. Its format is
`.copr` and is useable for auto-incrementing the package's NVR
in subsequent builds. It may be used in spec file like:
Release: 1%{?dist}%{?buildtag}
It could be useful as good-enough alternative for the Release
auto-bumping proposal. See the fedora devel discussion [2] for more
info. This is not any kind of encouragement to use it. We added it
there to easy testing your ideas about the automatic filling of the
Release tag.
This is really interesting feature for some of the projects.
Can this be used in official Fedora specfiles or does it need a guideline?
- Command-line interface for the project package listing was significantly
optimized, and should now be faster than the web-UI on large projects
(issue/757).
Thanks, I'll test it instead of my "parse-HTML-by-regex" mad script :)
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Highlights from the latest Copr release
Hello.
On Aug 12 2020, a new Copr release landed production. Here is the list
of visible changes:
- Project karma implemented; Logged-in users can give
thumbs-up/thumbs-down to the existing copr projects. This is just
another way to give feedback about a particular Copr project quality.
This is merely subjective. We do not give you guidance what "thumbs
up/down" means. When it is good for you - for whatever reason - give it
thumbs up. It may be just feedback for the maintainer or other users.
Or we may automatically select and group high-quality projects in the
future - and e.g. revive the idea of the Playground [1]. The options
are open. We would like to hear your feedback about this feature!
- Copr newly provides a build-time macro %buildtag. Its format is
`.copr` and is useable for auto-incrementing the package's NVR
in subsequent builds. It may be used in spec file like:
Release: 1%{?dist}%{?buildtag}
It could be useful as good-enough alternative for the Release
auto-bumping proposal. See the fedora devel discussion [2] for more
info. This is not any kind of encouragement to use it. We added it
there to easy testing your ideas about the automatic filling of the
Release tag.
- The /status page has a new "Starting" tab [3] which shows all the binary
builds where the worker process is already started, but appropriate
builder VM is not yet assigned to it (issue/1429).
- Group avatars (user-icons assigned to an e-mail) were fixed to
really use the groups' emails, not the administrators' (issue/1419).
- Command-line interface for the project package listing was significantly
optimized, and should now be faster than the web-UI on large projects
(issue/757).
- All the background jobs have now a lower priority than normal jobs.
Previously, background source builds were still prioritized over normal
builds. This should be the last step towards a fair build scheduler.
- Support for a new command 'copr-cli list-builds ' was added.
It lists each build on a separate line, as a tab-separated list of
items.
Related copr client Fedora/EPEL updates:
F32 - https://bodhi.fedoraproject.org/updates/FEDORA-2020-ce81a9539d
F31 - https://bodhi.fedoraproject.org/updates/FEDORA-2020-76bfc383c3
EPEL8 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4c313586d8
EPEL7 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6a77e31d06
EPEL6 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-78e089fe70
Should you have any related issues, please report them to us as usual.
[1] https://fedoraproject.org/wiki/Playground
[2]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/TXLF22CSUVUIQBVHH2NEFF4IOIFHS5WK/
[3] https://copr.fedorainfracloud.org/status/starting/
Happy building!
Copr Team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release 2020-06-10
> - Copr project "runtime" dependencies were implemented. Newly you can > specify set of repositories your project depends on. Such repositories > will be installed together with the copr project repo file (e.g., by > 'dnf copr enable YOU/YOUR_PROEJCT'). Those repositories can be other > project in Copr or some 3rd party repository. This is very similar to > build-time dependencies implemented long time ago. Take a look at > blog post: > > https://fedora-copr.github.io/posts/runtime-dependencies This is fantastic news! In one of my COPR projects the cross-dependency prevented me from being able to host the project properly. - Cancel build feature was fixed, and the "cancel" request should reliably > release all occupied builder machines (allowing them to be re-used, or > terminated). > > Also this. Thank you! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release 2020-06-10
On Tuesday, June 16, 2020 8:48:32 PM CEST Ian McInerney wrote: > ...snip... > > > > - There's now more fair build scheduler. Previously, no matter whether the > > "background" attribute was set or not for the build - once builder was > > allocated for a concrete copr user - copr never terminated the builder > > as long as the user kept filling the build queue with new tasks (and it > > blocked the quota for others). Newly, there's a limit of at most > > eight consecutive builds or 30 minutes for one user (sandbox) on one > > builder and the builder is immediately terminated - which gives a chance > > to assign new builders to others' tasks (which have a higher priority at > > that point). > > > > I am confused by this scheduler part. Does this mean that any build that > takes longer than 30 minutes will be cancelled? What about software > packages that are larger and require more build time? This deserved better spelling => any builder that was assigned to one user for _more than 30 minutes_ is - after the build _is finished_ - terminated. The build timeout is a different configuration option (currently around 24h, and the timeout concept should change soon so it is more flexible, https://pagure.io/copr/copr/issue/1303 ). Pavel > -Ian > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release 2020-06-10
...snip... > > - There's now more fair build scheduler. Previously, no matter whether the > "background" attribute was set or not for the build - once builder was > allocated for a concrete copr user - copr never terminated the builder > as long as the user kept filling the build queue with new tasks (and it > blocked the quota for others). Newly, there's a limit of at most > eight consecutive builds or 30 minutes for one user (sandbox) on one > builder and the builder is immediately terminated - which gives a chance > to assign new builders to others' tasks (which have a higher priority at > that point). > I am confused by this scheduler part. Does this mean that any build that takes longer than 30 minutes will be cancelled? What about software packages that are larger and require more build time? -Ian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release 2020-06-10
On Wednesday, June 10, 2020 10:31:32 PM CEST Iñaki Ucar wrote: > > - Copr-cli supports batch build delete feature: > > > > $ copr-cli delete build_id [build_id ...] > > Hooray! Just delete or delete-build? Yes, typo, I meant "delete-build" command. Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release 2020-06-10
On Wed, 10 Jun 2020 at 21:42, Pavel Raiskup wrote: > > - Copr project "runtime" dependencies were implemented. Great! > - Copr-cli supports batch build delete feature: > > $ copr-cli delete build_id [build_id ...] Hooray! Just delete or delete-build? -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Highlights from the latest Copr release 2020-06-10
Hello! On Jun 10, 2020, a new Copr release landed production. Related client tooling updates are here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-390cce74d6 https://bodhi.fedoraproject.org/updates/FEDORA-2020-f90873700f https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3b8c2778f1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-feca133c66 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8449e5d605 Here is the list of visible changes, and new features: - Increased build task throughput. The VM spawner is more flexible now. First, we don't allocate that many workers if they are not actually needed, but more importantly the upper limit for concurrently running workers has risen to 140 (including all architectures), previously we had ~70. We'll see how things go from the backend perspective, but it is expected that we'll go even higher (waiting for a new HW in the new Fedora lab, cheaper VM instances in the future, etc.). So the numbers will likely change; this is to make clear the current state of things. - Copr project "runtime" dependencies were implemented. Newly you can specify set of repositories your project depends on. Such repositories will be installed together with the copr project repo file (e.g., by 'dnf copr enable YOU/YOUR_PROEJCT'). Those repositories can be other project in Copr or some 3rd party repository. This is very similar to build-time dependencies implemented long time ago. Take a look at blog post: https://fedora-copr.github.io/posts/runtime-dependencies - There's now more fair build scheduler. Previously, no matter whether the "background" attribute was set or not for the build - once builder was allocated for a concrete copr user - copr never terminated the builder as long as the user kept filling the build queue with new tasks (and it blocked the quota for others). Newly, there's a limit of at most eight consecutive builds or 30 minutes for one user (sandbox) on one builder and the builder is immediately terminated - which gives a chance to assign new builders to others' tasks (which have a higher priority at that point). - Copr-cli supports batch build delete feature: $ copr-cli delete build_id [build_id ...] Please use this instead of requesting removal of each build_id separately - it will be much faster because you will save the copr backend useless createrepo_c runs after each request. - We also implemented a priority queue algorithm for Action tasks (non-build tasks, e.g., forking, build/project deleting, etc.). This should solve several issues when the action queue gets temporarily too large to process immediately; namely the delayed "initial createrepo" action problem that previously caused an ugly build failures in freshly created copr projects. - Cancel build feature was fixed, and the "cancel" request should reliably release all occupied builder machines (allowing them to be re-used, or terminated). - Users are not allowed to disable chroot in a project that has some running builds against the disabled chroot. The running builds need to be canceled first. This change as done to avoid inconsistencies between frontend/backend, and wasted builder quota on useless tasks. - More space for /var/cache/mock directory, so repeated builds on the same machine won't face the ENOSPC error on mock caches. Considering that each builder can only do at most eight builds (then terminated), this problem should be finally fixed. Happy building! Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release
Hello Kevin, thank you for your feedback. > This is still inherently flawed and unsafe because you have absolutely no > way of guaranteeing that the notification mail actually reached the > maintainer, only that it has been sent. E-mail is not a certified delivery > mechanism. True, that's why we wanted to have a 180 days preservation period. The email accounts are not Copr-specific either, they are linked with FAS. If somebody's mailbox can't be reached by any Fedora service for half a year, there is something wrong. And I don't think we can do anything about it. Though, we are considering implementing some notification icon directly on the Copr website. Is this something you would like to see? > The whole concept of opt-out deletion is inherently flawed. It is > unacceptable to delete user data without explicit confirmation. I agree, that in the ideal world, it should be that way. But in the meantime, Copr is not a paid service and has limited resources - mainly disk space. Not removing any user data, would mean, that by now it wouldn't be possible to build any package anymore. We would run out of space months ago. We got promised new storage, but in the meantime, we need to remove _outdated_ user data, just to keep the service working. Moreover, once a new fedora is branched from rawhide, we create the chroots with packages, that was build in rawhide chroots. This eats a lot (I can check for the numbers) of space immediately after branching. You can read more about the disk space issues in the original blog post http://frostyx.cz/posts/copr-removing-outdated-chroots We needed to figure out, what data we can remove without affecting the most users. For years, we are removing old build results for packages whose newer (or same) version was successfully built in the project. Complying with "It is unacceptable to delete user data without explicit confirmation", we wouldn't be allowed to do even this. But thanks to this feature, we were able to not run out of storage for many months, maybe even years. But lately, this mechanism wasn't sufficient, so we needed to save disk space somewhere else. Our original idea was to announce beforehand but then remove all the outdated chroots. Then we downgraded the idea a little bit and we came with the concept of notification emails and once an owner doesn't care about the outdated chroots for his project, removing them. If you have any other suggestions how to save storage space, let us know, please. We will look at it. > And of course, the fix comes too late for the repositories that you folks > already irremediably destroyed with your deletion rampage. E.g., the latest > release of Kannolo, Kannolo 27, is now missing one of its default > repositories and I have no way to fix that (and neither do you, for that > matter – the only way the problem could be solved would be to allow building > for Fedora 27 again, then I could simply build the packages again). What happened, was very unfortunate, by any means intentional, and we are very sorry about it. A bug slipped into production and broke the notification command, so any email couldn't be sent. After you reported the issue, we fixed the bug, added several unit tests to cover any possible regressions in the future, and updated the code so a chroot that we haven't sent a notification about, can't be removed. I am aware that it won't un-remove the data, that were already lost, so it is not that comforting for you, but unfortunately, we have no way to restore the data. Temporarily enabling outdated chroots for people who care, to rebuild their data, wouldn't be that easy too. There is no guarantee that end of life mock chroots still work. Jakub On Mon, Feb 10, 2020 at 1:36 PM Kevin Kofler wrote: > > Pavel Raiskup wrote: > > - The EOL chroot policy scripts responsible for notifying users about > > upcoming removals were fixed, users should now always be notified - and > > if for some reason they are not, the EOL chroot will not be removed. > > This is still inherently flawed and unsafe because you have absolutely no > way of guaranteeing that the notification mail actually reached the > maintainer, only that it has been sent. E-mail is not a certified delivery > mechanism. > > The whole concept of opt-out deletion is inherently flawed. It is > unacceptable to delete user data without explicit confirmation. > > And of course, the fix comes too late for the repositories that you folks > already irremediably destroyed with your deletion rampage. E.g., the latest > release of Kannolo, Kannolo 27, is now missing one of its default > repositories and I have no way to fix that (and neither do you, for that > matter – the only way the problem could be solved would be to allow building > for Fedora 27 again, then I could simply build the packages again). > > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an
Re: Highlights from the latest Copr release
Pavel Raiskup wrote: > - The EOL chroot policy scripts responsible for notifying users about > upcoming removals were fixed, users should now always be notified - and > if for some reason they are not, the EOL chroot will not be removed. This is still inherently flawed and unsafe because you have absolutely no way of guaranteeing that the notification mail actually reached the maintainer, only that it has been sent. E-mail is not a certified delivery mechanism. The whole concept of opt-out deletion is inherently flawed. It is unacceptable to delete user data without explicit confirmation. And of course, the fix comes too late for the repositories that you folks already irremediably destroyed with your deletion rampage. E.g., the latest release of Kannolo, Kannolo 27, is now missing one of its default repositories and I have no way to fix that (and neither do you, for that matter – the only way the problem could be solved would be to allow building for Fedora 27 again, then I could simply build the packages again). Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release
On Thursday, February 6, 2020 8:42:56 AM MST Pavel Raiskup wrote: > Hello, > > recently (on Feb 06, 2020) a new Copr release landed production. Here is > the list of visible changes: > > - Users now can build packages against explicitly enabled modules. Go to > `Project -> Settings -> Build Options -> [Edit] button (near _enabled_ > chroot) -> Enable module: textarea`. Note that fedora modular > repositories do not behave entirely good in mock (and copr) so we had to > disable before by default. So to actually bring the modules into copr, > you need to also configure the "external repositories" textarea for the > fedora-modular repo. > > - Module builds were historically done only against Fedora dist-git. Now > the `copr-cli build-module` command was enhanced to accept `--distgit` > option which allows users to specify which dist-git instance to build > the module against. For now we have only the "fedora" distgit > configured. If you have ideas what external dist-git we should add to > our configuration, let us know. > > - The EOL chroot policy scripts responsible for notifying users about > upcoming removals were fixed, users should now always be notified - and > if for some reason they are not, the EOL chroot will not be removed. > > - Several fixes were done in copr-rpmbuild so the builds should be more > reliable, especially when the builder VM is heavily re-used for many > builds. > > - News from yesterday - @msuchy enabled CDN for copr backend repositories. > You, or your users, likely want to re-enable the copr repositories > (dnf copr enable ). > > Happy building! > Pavel It looks like this is mostly module related stuff, which is absolutely useless for most packagers.. I hope it's good for RHEL at least, but it seems to be more of a nightmare there (for sysadmins, rather than packagers). -- John M. Harris, Jr. Splentity ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Highlights from the latest Copr release
Hello, recently (on Feb 06, 2020) a new Copr release landed production. Here is the list of visible changes: - Users now can build packages against explicitly enabled modules. Go to `Project -> Settings -> Build Options -> [Edit] button (near _enabled_ chroot) -> Enable module: textarea`. Note that fedora modular repositories do not behave entirely good in mock (and copr) so we had to disable before by default. So to actually bring the modules into copr, you need to also configure the "external repositories" textarea for the fedora-modular repo. - Module builds were historically done only against Fedora dist-git. Now the `copr-cli build-module` command was enhanced to accept `--distgit` option which allows users to specify which dist-git instance to build the module against. For now we have only the "fedora" distgit configured. If you have ideas what external dist-git we should add to our configuration, let us know. - The EOL chroot policy scripts responsible for notifying users about upcoming removals were fixed, users should now always be notified - and if for some reason they are not, the EOL chroot will not be removed. - Several fixes were done in copr-rpmbuild so the builds should be more reliable, especially when the builder VM is heavily re-used for many builds. - News from yesterday - @msuchy enabled CDN for copr backend repositories. You, or your users, likely want to re-enable the copr repositories (dnf copr enable ). Happy building! Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: Highlights from the latest Copr release
On Fri, Oct 4, 2019 at 3:37 PM Pavel Raiskup wrote: > Hello, > > today (on Oct 4, 2019), new Copr release landed production. > > This was mostly a bugfix release, with some optimization/reliability > patches interesting for copr administrators. But there were few exciting > changes for the end-users: > > Multilib projects > - > > If you go to the project settings, there's a new "multilib" checkbox. > When you (a) enable this feature and (b) you enable chroots that form a > "multilib pair" (for example fedora-rawhide-x86_64 and > fedora-rawhide-i386), the repofile generated for your users will contain > two repos with two baseurls, one for x86_64 and one for i386. So in turn > packages for both architectures will be available. This is also fixed in > `dnf enable copr USER/PROJECT` use-case on affected systems, but you need > to wait for `dnf-plugins-core >= 4.0.10`. > Awesome! Thank you. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Highlights from the latest Copr release
Hello, today (on Oct 4, 2019), new Copr release landed production. This was mostly a bugfix release, with some optimization/reliability patches interesting for copr administrators. But there were few exciting changes for the end-users: Multilib projects - If you go to the project settings, there's a new "multilib" checkbox. When you (a) enable this feature and (b) you enable chroots that form a "multilib pair" (for example fedora-rawhide-x86_64 and fedora-rawhide-i386), the repofile generated for your users will contain two repos with two baseurls, one for x86_64 and one for i386. So in turn packages for both architectures will be available. This is also fixed in `dnf enable copr USER/PROJECT` use-case on affected systems, but you need to wait for `dnf-plugins-core >= 4.0.10`. Better builder-live.log handling For some time, we have been automatically compressing the builder-live.log into builder-live.log.gz. Previously, we kept a "stub" builder-live.log file with info that the file was moved to the compressed variant. Newly the stub file is removed, and we automatically redirect from builder-live.log to builder-live.log.gz if the former doesn't exist (i.e., when the build already finished). Frontend UI correctly references either the log/log.gz variant depending on which state the build is in. We now also provide direct links to live log for particular chroot builds, try to click on the chroot status icon. Parallel handling of backend actions Actions like "delete build", "delete project", "create repo", "fork", etc. requested on frontend are now processed on backend concurrently; the effect is that the action queue is processed much faster and the action-reaction is quicker because even very slow actions do not block other actions. Forking projects is fixed - Previously the forked projects contained an incomplete set of builds; this bug was fixed. Please report any issues to https://pagure.io/copr/copr/issues Happy building! Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Highlights from the latest Copr release
Hello,
recently (on Feb 19) a major Copr update took place. It was announced,
but release notes weren't attached. Because a list of all changes
would be long and boring,
I rather decided to present you some highlights of the release.
- Allow per-package chroot-blacklisting by wildcard patterns
You can configure chroot blacklist in package settings. It is applied when
building a package from default source in web UI, copr-cli or via
webhook. This feature
is useful in cases when you have multiple packages per project and
some of them
are not supposed to build successfully in all enabled chroots. The
configuration
supports patterns - for example, to not build a package on EPEL, set
chroot blacklist to `epel-*`.
- Live SRPM build log for custom method
When building SRPM via custom method, builder log is now live.
- Modularity fixes
For quite some time it is possible to build modules in Copr, but
last few months it was not
possible to properly install them with DNF them on user machines due
to changed
expectations on a repository. This issue is resolved and it is possible to
install modules as expected.
- Project forks page
We have added a small number next to the "Fork this project" button.
It indicates
how many forks the project has. Click on it to see a list of the
forks and their
owners.
- Build into sub-repository within the project
When submitting a build in copr-cli, you can now specify the project in the
following format `owner/project:reponame` which allows you to build into
a specific sub-repository within the project. It works the same way as the
automatized builds from pagure pull requests.
https://pagure.io/copr/copr/blob/copr-cli-1.78-1/f/cli/man/copr-cli.1.asciidoc#_217
- API function to wait until builds finish [BZ#1258970]
https://bugzilla.redhat.com/show_bug.cgi?id=1258970
There is a common use case among users, to submit a build via API
and then wait
until its finished, to do some business logic. Yet, we didn't provide any way
to wait on a build and users had to implement it themselves. Now it
is possible
to use `wait(...)` function for this. For example:
from copr.v3 import Client
client = Client.create_from_config_file()
build1 = client.build_proxy.create_from_file(...)
build2 = client.build_proxy.create_from_scm(...)
finished = wait([build1, build2])
print("Builds have finished {}sucessfully".format(
"" if succeeded(finished) else "un"))
- API errors with correct status codes
The Legacy API used just two status codes, 200 for success and 500 for error.
Because the APIv3 is based on it, this flaw remained to its first
release. Now,
the APIv3 finally returns the correct status codes.
- Speed up several slow frontend pages
Including the homepage which loaded slowly mainly because of the recent
builds box on the right side. The select query for this box was improved
and the time required for its execution halved.
Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
