3:29 a.m.
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<BUILD_ID>` 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 <project>' was added.
It lists each build on a separate line, as a tab-separated list of
<BUILD_ID> <PACKAGE_NAME> <BUILD_STATUS> 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.o...
[3] https://copr.fedorainfracloud.org/status/starting/
Happy building!
Copr Team
3:51 a.m.
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<BUILD_ID>` 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
4:19 a.m.
On Wed, 12 Aug 2020 at 10:29, Pavel Raiskup <praiskup(a)redhat.com> 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<BUILD_ID>` 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
<pkg>-<version>-<release>.copr<id>.fcXX be picked as an update of
<pkg>-<version>-<release>.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
<project>' was added.
It lists each build on a separate line, as a tab-separated list of
<BUILD_ID> <PACKAGE_NAME> <BUILD_STATUS> 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
4:20 a.m.
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<BUILD_ID>` 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
4:34 a.m.
On 12. 08. 20 11:20, Pavel Raiskup wrote:
>> - Copr newly provides a build-time macro %buildtag. Its
format is
>> `.copr<BUILD_ID>` 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
5:12 a.m.
On 12. 08. 20 11:19, Iñaki Ucar wrote:
> - Copr newly provides a build-time macro %buildtag. Its format
is
> `.copr<BUILD_ID>` 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
<pkg>-<version>-<release>.copr<id>.fcXX be picked as an update
of
<pkg>-<version>-<release>.fcXX? Or do we need to rebuild all with the
new tag and remove the old ones?
It's actually <pkg>-<version>-<release>.fcXX.copr<id> 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
5:32 a.m.
On Wednesday, August 12, 2020 11:19:00 AM CEST Iñaki Ucar wrote:
On Wed, 12 Aug 2020 at 10:29, Pavel Raiskup
<praiskup(a)redhat.com> 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<BUILD_ID>` 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
<pkg>-<version>-<release>.copr<id>.fcXX be picked as an update
of
<pkg>-<version>-<release>.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
5:48 a.m.
On Wed, 12 Aug 2020 at 12:32, Pavel Raiskup <praiskup(a)redhat.com> 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 <praiskup(a)redhat.com> wrote:
> > - Copr newly provides a build-time macro %buildtag. Its format is
> > `.copr<BUILD_ID>` 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
> <pkg>-<version>-<release>.copr<id>.fcXX be picked as an
update of
> <pkg>-<version>-<release>.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
7:01 a.m.
Unfortunately, Copr still deletes data without warning:
https://bugzilla.redhat.com/show_bug.cgi?id=1868367
Kevin Kofler
1360
days inactive
1360
days old
8 comments
4 participants
participants (4)
-
Iñaki Ucar -
Kevin Kofler -
Miro Hrončok -
Pavel Raiskup