1:56 a.m.
Hello everybody,
I would like to gather different use cases for the 'fedpkg
scratch-build' command.
Currently, this is exactly the same as 'fedpkg build --scratch', meaning
that is performs a scratch build of the pushed head of the current
branch. At least in my workflow, I only do scratch builds before
pushing, to ensure that what I am about to push builds correctly in
Koji. Because if this, I never use the default form. Instead, I always
specify 'fedpkg scratch-build --srpm', so that the srpm to build from is
locally generated from the local working directory.
What I would like to do is to submit a pull request to either fedpkg or
rpkg, making that the default. It is a single line code change, not
counting changes to documentation and code comments.
Doing a scratch build from the pushed contents would still be possible
by either a) using 'fedpkg build --scratch' or b) checking out the
remote head and then issuing 'fedpkg scratch-build'.
Above change seems like a clear improvement to me, making the most used
option the default. But I have noticed that workflows differ wildly
between packagers, so before submitting any code for review, I would
like to hear if somebody regularly uses the default form 'fedpkg
scratch-build' and thinks it currently does the right thing.
This issue came up when we were updating Package Maintainer Docs about
Koji [1].
[1]:
https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/101#co...
2:08 a.m.
Otto Liljalaakso <otto.liljalaakso(a)iki.fi> writes:
Hello everybody,
I would like to gather different use cases for the 'fedpkg
scratch-build' command.
Currently, this is exactly the same as 'fedpkg build --scratch', meaning
that is performs a scratch build of the pushed head of the current
branch. At least in my workflow, I only do scratch builds before
pushing, to ensure that what I am about to push builds correctly in
Koji. Because if this, I never use the default form. Instead, I always
specify 'fedpkg scratch-build --srpm', so that the srpm to build from is
locally generated from the local working directory.
What I would like to do is to submit a pull request to either fedpkg or
rpkg, making that the default. It is a single line code change, not
counting changes to documentation and code comments.
Doing a scratch build from the pushed contents would still be possible
by either a) using 'fedpkg build --scratch' or b) checking out the
remote head and then issuing 'fedpkg scratch-build'.
Above change seems like a clear improvement to me, making the most used
option the default. But I have noticed that workflows differ wildly
between packagers, so before submitting any code for review, I would
like to hear if somebody regularly uses the default form 'fedpkg
scratch-build' and thinks it currently does the right thing.
I pretty much use fedpkg scratch-build only with the --srpm option in
the same way that you do. Thus I very welcome this change and thank you
for submitting this pull request!
Cheers,
Dan
3:37 a.m.
On 16-01-2023 08:56, Otto Liljalaakso wrote:
Above change seems like a clear improvement to me, making the most
used
option the default. But I have noticed that workflows differ wildly
between packagers, so before submitting any code for review, I would
like to hear if somebody regularly uses the default form 'fedpkg
scratch-build' and thinks it currently does the right thing.
+1 for the PR.
So far I haven't used the scratch-build command. I always use build,
since I need to supply extra options anyway to start a scratch build
from local HEAD. This change would make me use the scratch-build command
instead.
-- Sandro
7:57 a.m.
On Mon, Jan 16, 2023 at 3:38 AM Sandro <lists(a)penguinpee.nl> wrote:
On 16-01-2023 08:56, Otto Liljalaakso wrote:
> Above change seems like a clear improvement to me, making the most used
> option the default. But I have noticed that workflows differ wildly
> between packagers, so before submitting any code for review, I would
> like to hear if somebody regularly uses the default form 'fedpkg
> scratch-build' and thinks it currently does the right thing.
+1 for the PR.
So far I haven't used the scratch-build command. I always use build,
since I need to supply extra options anyway to start a scratch build
from local HEAD. This change would make me use the scratch-build command
instead.
Since `fedpkg scratch-build` bombs out with an error if you've made local
changes I propose a slight modification:
If no changes are made then it does a normal scratch build for the "does
this still build / not build" 1% use case
If there are local changes it automatically uploads an SRPM for the 99% use
case.
If you end up in a weird state, i.e. made changes but for some reason want
to do a "normal" scratch build you have a few different ways to accomplish
that.
Thanks,
Richard
8:05 a.m.
On 16. 01. 23 14:57, Richard Shaw wrote:
Since `fedpkg scratch-build` bombs out with an error if you've made local
changes I propose a slight modification:
If no changes are made then it does a normal scratch build for the "does this
still build / not build" 1% use case
If there are local changes it automatically uploads an SRPM for the 99% use case.
I love this.
$ fedpkg scratchbuild / $ fedpkg build --scratch
Uncommitted changes found, uploading SRPM...
If you end up in a weird state, i.e. made changes but for some reason
want to
do a "normal" scratch build you have a few different ways to accomplish that.
That was already impossible:
$ fedpkg --release rawhide scratch-build
Could not execute scratch_build: .../python3.9 has uncommitted changes. Use
git status to see details
Try option --srpm to make scratch build from local changes.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
8:07 a.m.
On Mon, Jan 16, 2023 at 8:06 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 16. 01. 23 14:57, Richard Shaw wrote:
>
> Since `fedpkg scratch-build` bombs out with an error if you've made
local
> changes I propose a slight modification:
>
> If no changes are made then it does a normal scratch build for the "does
this
> still build / not build" 1% use case
>
> If there are local changes it automatically uploads an SRPM for the 99%
use case.
I love this.
$ fedpkg scratchbuild / $ fedpkg build --scratch
Uncommitted changes found, uploading SRPM...
> If you end up in a weird state, i.e. made changes but for some reason
want to
> do a "normal" scratch build you have a few different ways to accomplish
that.
That was already impossible:
$ fedpkg --release rawhide scratch-build
Could not execute scratch_build: .../python3.9 has uncommitted changes.
Use
git status to see details
Try option --srpm to make scratch build from local changes.
Someone mentioned it's possible to specify a specific commit to build from?
I don't know I haven't tried. The other option which is what I would use
would to use `git stash` / scratch build / `git stash apply`.
Thanks,
Richard
3:31 p.m.
Miro Hrončok kirjoitti 16.1.2023 klo 16.05:
On 16. 01. 23 14:57, Richard Shaw wrote:
>
> Since `fedpkg scratch-build` bombs out with an error if you've made
> local changes I propose a slight modification:
>
> If no changes are made then it does a normal scratch build for the
> "does this still build / not build" 1% use case
>
> If there are local changes it automatically uploads an SRPM for the
> 99% use case.
I love this.
$ fedpkg scratchbuild / $ fedpkg build --scratch
Uncommitted changes found, uploading SRPM...
I like this modified proposal, too. It achieves what I wanted to do, and
(unlike my original idea) does not break the "1% case" for 'fedpkg
scratch-build'. I will try to create a pull request for this. More than
a single line needs to change, but it should not be too difficult.
12:58 p.m.
Otto Liljalaakso kirjoitti 16.1.2023 klo 23.31:
Miro Hrončok kirjoitti 16.1.2023 klo 16.05:
> On 16. 01. 23 14:57, Richard Shaw wrote:
>>
>> Since `fedpkg scratch-build` bombs out with an error if you've made
>> local changes I propose a slight modification:
>>
>> If no changes are made then it does a normal scratch build for the
>> "does this still build / not build" 1% use case
>>
>> If there are local changes it automatically uploads an SRPM for the
>> 99% use case.
>
> I love this.
>
> $ fedpkg scratchbuild / $ fedpkg build --scratch
> Uncommitted changes found, uploading SRPM...
I like this modified proposal, too. It achieves what I wanted to do, and
(unlike my original idea) does not break the "1% case" for 'fedpkg
scratch-build'. I will try to create a pull request for this. More than
a single line needs to change, but it should not be too difficult.
Pull request that implements what is discussed above:
https://pagure.io/rpkg/pull-request/653
4:09 a.m.
At least in my workflow, I only do scratch builds before pushing,
to ensure that what I am about to push builds correctly in Koji.
Same here. Some of
my packages are prone to break and in need
of patching on non-x86_64, so that's my main use case as well.
Never used "fedpkg scratch-build" since I didn't even know it
existed, but yes, having it be equivalent to "fedpkg srpm &&
koji build --scratch ..." would make sense to me.
A.FI.
4:52 a.m.
On Mon, Jan 16, 2023 at 09:56:31AM +0200, Otto Liljalaakso wrote:
Hello everybody,
I would like to gather different use cases for the 'fedpkg scratch-build'
command.
Currently, this is exactly the same as 'fedpkg build --scratch', meaning
that is performs a scratch build of the pushed head of the current branch.
At least in my workflow, I only do scratch builds before pushing, to ensure
that what I am about to push builds correctly in Koji. Because if this, I
never use the default form. Instead, I always specify 'fedpkg scratch-build
--srpm', so that the srpm to build from is locally generated from the local
working directory.
What I would like to do is to submit a pull request to either fedpkg or
rpkg, making that the default. It is a single line code change, not counting
changes to documentation and code comments.
Doing a scratch build from the pushed contents would still be possible by
either a) using 'fedpkg build --scratch' or b) checking out the remote head
and then issuing 'fedpkg scratch-build'.
Above change seems like a clear improvement to me, making the most used
option the default. But I have noticed that workflows differ wildly between
packagers, so before submitting any code for review, I would like to hear if
somebody regularly uses the default form 'fedpkg scratch-build' and thinks
it currently does the right thing.
Yep, testing non-pushed content is the primary reason for doing a
scratch-build. So 95% of the time I'll use "fedpkg scratch-build --srpm"
on non-pushed content. Very occassionally I'll do a scratch build
with pushed content, if testing compat with the latest build root
contents.
Probably 70% of the time I would often also add "--arch x86_64" to
avoid burning CPU time across all the Fedora arch builders for a plain
smoketest. Sometimes might pick a different arch if chasing a particular
arch problem.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
5:08 a.m.
For me it is:
99% "I want to check if local changes build" - fedpkg scratch-build --srpm
1% "Something changed in Rawhide and I want to see if X still builds" -
fedpkg scratch-build
I didn't know "fedpkg build" has a scratch option, TIL.
Cheers,
Chris
On Mon, 16 Jan 2023 at 10:52, Daniel P. Berrangé <berrange(a)redhat.com>
wrote:
On Mon, Jan 16, 2023 at 09:56:31AM +0200, Otto Liljalaakso wrote:
> Hello everybody,
>
> I would like to gather different use cases for the 'fedpkg scratch-build'
> command.
>
> Currently, this is exactly the same as 'fedpkg build --scratch', meaning
> that is performs a scratch build of the pushed head of the current
branch.
> At least in my workflow, I only do scratch builds before pushing, to
ensure
> that what I am about to push builds correctly in Koji. Because if this, I
> never use the default form. Instead, I always specify 'fedpkg
scratch-build
> --srpm', so that the srpm to build from is locally generated from the
local
> working directory.
>
> What I would like to do is to submit a pull request to either fedpkg or
> rpkg, making that the default. It is a single line code change, not
counting
> changes to documentation and code comments.
>
> Doing a scratch build from the pushed contents would still be possible by
> either a) using 'fedpkg build --scratch' or b) checking out the remote
head
> and then issuing 'fedpkg scratch-build'.
>
> Above change seems like a clear improvement to me, making the most used
> option the default. But I have noticed that workflows differ wildly
between
> packagers, so before submitting any code for review, I would like to
hear if
> somebody regularly uses the default form 'fedpkg scratch-build' and
thinks
> it currently does the right thing.
Yep, testing non-pushed content is the primary reason for doing a
scratch-build. So 95% of the time I'll use "fedpkg scratch-build --srpm"
on non-pushed content. Very occassionally I'll do a scratch build
with pushed content, if testing compat with the latest build root
contents.
Probably 70% of the time I would often also add "--arch x86_64" to
avoid burning CPU time across all the Fedora arch builders for a plain
smoketest. Sometimes might pick a different arch if chasing a particular
arch problem.
With regards,
Daniel
--
|: https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-
https://fstop138.berrange.com :|
|: https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
6:46 a.m.
Yes, testing local changes with `srpm` is the main use case. I would even say that using
`scratch-build` without `--srpm` is a typical mistake for new packagers - thinking they
test before they push, when in effect they don't.
Testing (scratch-building) the pushed head makes sense when there are/were koschei
warnings, or updates to related packages and you want to know whwther your package still
builds (would build) as is, say before a mass rebuild.
And as you point out, checking out the pushed head gives you almost that at the expense of
an srpm rebuild, which is not exactly the same as scratch-building the "original
srpm".
`--srpm` is named misleadingly, by the way, because it names the "transport of the
source" when indeed it implies a potentially different source version. That's
another reasons why removing it (the name) and making it the mode of operation for
`scratch-build` makes sense:
- `scratch-build` is about doing things from (your) scratch. That involves an srpm for
technical reasons.
- `build` is about building something pushed, and `--scratch` only changes where it is
build.
Now I'm wondering: Does `fedpkg build --srpm` imply `--scratch`? I would hope so, and
I'm really wondering whether any srpm-mode should belong to that command at all.
It's much clearer if `build` deals with sources "in the buildsystem" only,
and {copr,scratch,local,mock}-build with the local sources. (Yes, `local` and `mockbuild`
could have helpful aliases, too.)
3:23 p.m.
Michael J Gruber kirjoitti 16.1.2023 klo 14.46:
`--srpm` is named misleadingly, by the way, because it names the "transport of the
source" when indeed it implies a potentially different source version. That's
another reasons why removing it (the name) and making it the mode of operation for
`scratch-build` makes sense:
- `scratch-build` is about doing things from (your) scratch. That involves an srpm for
technical reasons.
- `build` is about building something pushed, and `--scratch` only changes where it is
build.
Actually, --srpm is named like that because you can also do 'fedpkg
scratch-build --srpm path/to/my/src.rpm', which does what you would
expect. Generating the srpm from the local working directory is just the
default when no path is given.
Now I'm wondering: Does `fedpkg build --srpm` imply `--scratch`?
I would hope so, and I'm really wondering whether any srpm-mode should belong to that
command at all. It's much clearer if `build` deals with sources "in the
buildsystem" only, and {copr,scratch,local,mock}-build with the local sources. (Yes,
`local` and `mockbuild` could have helpful aliases, too.)
I tried it. 'fedpkg build --srpm' is not a scratch build. However, Koji
does not accept such build requests: "ActionNotAllowed: policy violation
(build_from_srpm)".
7:25 a.m.
On Mon, Jan 16, 2023 at 09:56:31AM +0200, Otto Liljalaakso wrote:
Hello everybody,
I would like to gather different use cases for the 'fedpkg
scratch-build' command.
Currently, this is exactly the same as 'fedpkg build --scratch',
meaning that is performs a scratch build of the pushed head of the
current branch. At least in my workflow, I only do scratch builds
before pushing, to ensure that what I am about to push builds
correctly in Koji. Because if this, I never use the default form.
Instead, I always specify 'fedpkg scratch-build --srpm', so that the
srpm to build from is locally generated from the local working
directory.
What I would like to do is to submit a pull request to either fedpkg
or rpkg, making that the default. It is a single line code change,
not counting changes to documentation and code comments.
Doing a scratch build from the pushed contents would still be
possible by either a) using 'fedpkg build --scratch' or b) checking
out the remote head and then issuing 'fedpkg scratch-build'.
Above change seems like a clear improvement to me, making the most
used option the default. But I have noticed that workflows differ
wildly between packagers, so before submitting any code for review,
I would like to hear if somebody regularly uses the default form
'fedpkg scratch-build' and thinks it currently does the right thing.
This issue came up when we were updating Package Maintainer Docs
about Koji [1].
[1]:
https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/101#co...
I always use the --srpm option. I wasn't really aware that there was
another possibility, and it doesn't seem very useful.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
8:50 a.m.
I don't oppose to change of the defaults.
However, I am also using `fedpkg scratch-build --srpm some.rpm`. So how
would the proposed change influence this command?
Vít
Dne 16. 01. 23 v 8:56 Otto Liljalaakso napsal(a):
Hello everybody,
I would like to gather different use cases for the 'fedpkg
scratch-build' command.
Currently, this is exactly the same as 'fedpkg build --scratch',
meaning that is performs a scratch build of the pushed head of the
current branch. At least in my workflow, I only do scratch builds
before pushing, to ensure that what I am about to push builds
correctly in Koji. Because if this, I never use the default form.
Instead, I always specify 'fedpkg scratch-build --srpm', so that the
srpm to build from is locally generated from the local working directory.
What I would like to do is to submit a pull request to either fedpkg
or rpkg, making that the default. It is a single line code change, not
counting changes to documentation and code comments.
Doing a scratch build from the pushed contents would still be possible
by either a) using 'fedpkg build --scratch' or b) checking out the
remote head and then issuing 'fedpkg scratch-build'.
Above change seems like a clear improvement to me, making the most
used option the default. But I have noticed that workflows differ
wildly between packagers, so before submitting any code for review, I
would like to hear if somebody regularly uses the default form 'fedpkg
scratch-build' and thinks it currently does the right thing.
This issue came up when we were updating Package Maintainer Docs about
Koji [1].
[1]:
https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/101#co...
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
5:34 a.m.
Dne 16. 01. 23 v 21:59 Otto Liljalaakso napsal(a):
Vít Ondruch kirjoitti 16.1.2023 klo 16.50:
> I don't oppose to change of the defaults.
>
> However, I am also using `fedpkg scratch-build --srpm some.rpm`. So
> how would the proposed change influence this command?
I do not intend to change that behavior in any way.
But you proposed to basically drop the `--srpm` option. So maybe this
should work: `fedpkg scratch-build some.rpm` instead. Not sure. I have
not thought about this into details especially in relation to plain
`fedpkg build`.
Vít
2:25 p.m.
Vít Ondruch kirjoitti 17.1.2023 klo 13.34:
Dne 16. 01. 23 v 21:59 Otto Liljalaakso napsal(a):
> Vít Ondruch kirjoitti 16.1.2023 klo 16.50:
>> I don't oppose to change of the defaults.
>>
>> However, I am also using `fedpkg scratch-build --srpm some.rpm`. So
>> how would the proposed change influence this command?
>
> I do not intend to change that behavior in any way.
But you proposed to basically drop the `--srpm` option. So maybe this
should work: `fedpkg scratch-build some.rpm` instead. Not sure. I have
not thought about this into details especially in relation to plain
`fedpkg build`.
My original idea was to make --srpm the default, i.e. 'fedpkg
scratch-build' would be the same as 'fedpkg scratch-build --srpm'. No
change to 'fedpkg scratch-build --srpm <path>', or to 'fedpkg
scratch-build --srpm-mock' (with or without path). The lost feature
would have been what 'fedpkg scratch-build' currently does: build the
srpm in Koji, then do a scratch build from it.
Anyhow, Richard has a better proposal in another subthread, which I
intend to follow: All existing behaviour is kept, but if there are local
changes, 'fedpkg scratch-build' does what 'fedpkg scratch-build --srpm'
does — currently an error is printed in this situation.
462
days inactive
467
days old
17 comments
11 participants
participants (11)
-
Artur Frenszek-Iwicki -
Chris Kelley -
Dan Čermák -
Daniel P. Berrangé -
Michael J Gruber -
Miro Hrončok -
Otto Liljalaakso -
Richard Shaw -
Richard W.M. Jones -
Sandro -
Vít Ondruch