Re: Highlights from the latest Copr release
On 11/13/20 5:25 PM, 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 Happy building! Indeed it is happy. I've just finally got to trying out the batch thing. $ copr build-package --nowait @python/python3.10 --name python-pytest-relaxed --after-build-id 1776391 Build was added to python3.10. Created builds: 1776396 $ copr build-package --nowait @python/python3.10 --name python-invoke --after-build-id 1776396 Build was added to python3.10. Created builds: 1776397 $ copr build-package --nowait @python/python3.10 --name python-paramiko --after-build-id 1776397 Build was added to python3.10. Created builds: 1776398 $ copr build-package --nowait @python/python3.10 --name ansible --after-build-id 1776398 Build was added to python3.10. Created builds: 1776399 This is awesome! One small suggestion: The pending builds are not visibly marked as waiting for another build (or at least I have not find the information in the web UI). That might be confusing for others when multiple people work on one copr project. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.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 ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.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 ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Highlights from the latest Copr release
On 11/13/20 6:32 PM, Pavel Raiskup wrote: On Friday, November 13, 2020 6:30:48 PM CET Miro Hrončok wrote: On 11/13/20 6:24 PM, Pavel Raiskup wrote: $ copr edit-package-distgit --name ... Indeed, thanks. I needed: https://bodhi.fedoraproject.org/updates/FEDORA-2020-b9d29463b5 Does the Auto-rebuild option of such packages still include src.fp.o pull requests? Yes, it should. Awesome. Thanks, Pavel! -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Highlights from the latest Copr release
On Friday, November 13, 2020 6:30:48 PM CET Miro Hrončok wrote: > On 11/13/20 6:24 PM, Pavel Raiskup wrote: > > $ copr edit-package-distgit --name ... > > Indeed, thanks. I needed: > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-b9d29463b5 > > Does the Auto-rebuild option of such packages still include src.fp.o pull > requests? Yes, it should. Pavel ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Highlights from the latest Copr release
On 11/13/20 6:24 PM, Pavel Raiskup wrote:
On Friday, November 13, 2020 6:06:49 PM CET Miro Hrončok wrote:
On 11/13/20 5:25 PM, 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
Dist-Git packages \o/
Is there a way to edit the packages to use this via CLI?
E.g. when we added packages like this:
copr add-package-scm --clone-url https://src.fedoraproject.org/rpms/${pkg}.git
--name $pkg --webhook-rebuild on --commit master ${copr}
How can I run copr edit-package-... or some other command to convert such
packages to fedora dist-git packages?
The 'edit-package-*' pattern should just work:
$ copr edit-package-distgit --name ...
Indeed, thanks. I needed:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-b9d29463b5
Does the Auto-rebuild option of such packages still include src.fp.o pull
requests?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Highlights from the latest Copr release
On Friday, November 13, 2020 6:06:49 PM CET Miro Hrončok wrote:
> On 11/13/20 5:25 PM, 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
>
> Dist-Git packages \o/
>
> Is there a way to edit the packages to use this via CLI?
>
> E.g. when we added packages like this:
>
> copr add-package-scm --clone-url
> https://src.fedoraproject.org/rpms/${pkg}.git
> --name $pkg --webhook-rebuild on --commit master ${copr}
>
> How can I run copr edit-package-... or some other command to convert such
> packages to fedora dist-git packages?
The 'edit-package-*' pattern should just work:
$ copr edit-package-distgit --name ...
Pavel
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.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 ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Highlights from the latest Copr release
On 11/13/20 5:25 PM, 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
Dist-Git packages \o/
Is there a way to edit the packages to use this via CLI?
E.g. when we added packages like this:
copr add-package-scm --clone-url https://src.fedoraproject.org/rpms/${pkg}.git
--name $pkg --webhook-rebuild on --commit master ${copr}
How can I run copr edit-package-... or some other command to convert such
packages to fedora dist-git packages?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.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 ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.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 ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Highlights from the latest Copr release
> 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!
For anyone interested, I wrote a blog post about this feature
http://frostyx.cz/posts/upvoting-projects-in-copr
Jakub
On Wed, Aug 12, 2020 at 3:38 PM Pavel Raiskup wrote:
>
> On Wednesday, August 12, 2020 2:29:25 PM CEST Vít Ondruch wrote:
> > Dne 12. 08. 20 v 10:29 Pavel Raiskup napsal(a):
> > > - 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}
> >
> > Not bad, but I think we don't want to promote new (and more over Copr
> > specific) macro in Fedora. IHO, it would be much better if Copr modified
> > the %{dist} macro appending the %{buildtag}.
>
> It's good idea, but not as trivial as the additional tag. You need knobs
> turning this on/off, etc. Patches towards this are welcome I think, but
> it will not be cheap (and it will collide with e.g. %forgemeta and
> others).
>
> This isn't really a promoting of something, but mostly R && RFC. As a
> potential _compromise_ solving the auto-bumping problem cheaply. Yeah, on
> one-hand it is awesome to see how much energy our community has to to
> solve the problem, but OTOH it really hurts, ... that many man-hours on
> such trivial thing ...
>
> > lso, %{buildtag} is such generic name which on one hand does not say
> > anything about its purposed
>
> Do you have ideas how to change this?
>
> > while there is chance it might collide with something.
>
> Yes. Unlikely, but yes. Ideas how to prevent this?
>
> > So why you have not chosen %{buildid} or even %{coprbuildid}.
>
> Because we didn't want to create copr-only solution. It's R, but if
> successful, we can just use the tag as is elsewhere..
>
> Pavel
>
>
> ___
> copr-devel mailing list -- copr-devel@lists.fedorahosted.org
> To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Highlights from the latest Copr release
On Wednesday, August 12, 2020 2:29:25 PM CEST Vít Ondruch wrote:
> Dne 12. 08. 20 v 10:29 Pavel Raiskup napsal(a):
> > - 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}
>
> Not bad, but I think we don't want to promote new (and more over Copr
> specific) macro in Fedora. IHO, it would be much better if Copr modified
> the %{dist} macro appending the %{buildtag}.
It's good idea, but not as trivial as the additional tag. You need knobs
turning this on/off, etc. Patches towards this are welcome I think, but
it will not be cheap (and it will collide with e.g. %forgemeta and
others).
This isn't really a promoting of something, but mostly R && RFC. As a
potential _compromise_ solving the auto-bumping problem cheaply. Yeah, on
one-hand it is awesome to see how much energy our community has to to
solve the problem, but OTOH it really hurts, ... that many man-hours on
such trivial thing ...
> lso, %{buildtag} is such generic name which on one hand does not say
> anything about its purposed
Do you have ideas how to change this?
> while there is chance it might collide with something.
Yes. Unlikely, but yes. Ideas how to prevent this?
> So why you have not chosen %{buildid} or even %{coprbuildid}.
Because we didn't want to create copr-only solution. It's R, but if
successful, we can just use the tag as is elsewhere..
Pavel
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.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
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.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
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.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
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.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
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.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
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.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
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.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
___
copr-devel mailing list -- copr-devel@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.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 > ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.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 ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.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 ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Highlights from the latest Copr release 2020-06-10
On 10. 06. 20 21:41, Pavel Raiskup wrote: Hello! On Jun 10, 2020, a new Copr release landed production. Thank You! 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. Happy to see this in action. - 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 sounds really interesting and helpful. Thanks. - 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've been personalyl affected by the old behavior, happy to see this. - 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. Yet again, \o/ - Cancel build feature was fixed, and the "cancel" request should reliably release all occupied builder machines (allowing them to be re-used, or terminated). Awesome as well. Thanks for this release. I've also seen some UX changes wehn viewing builds, the builder-live.log.gz is now 1 click closer. This seems slow, but in bulk, is really awesome. Keep up the good work. I am so glad we have such innovations! -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.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 ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
Re: Highlights from the latest Copr release
On 20. 01. 20 10:15, Tomas Hrnciar wrote: Hello, recently (on Jan 16, 2020) a new Copr release landed production. Here is the list of visible changes: - We contributed to createrepo_c to speed up Copr for building large projects. Building large projects should be significantly faster. Thanks for this. It indeed feels faster! -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.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. ___ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.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.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
