[OS-BUILD PATCH 0/2] Number patches more nicely

[GitLab Bridge on behalf of omos]

From: omos on gitlab.com

Start numbering at one and use the number in patch filenames for easier
navigation in dist-git and SRPM content.

[OS-BUILD PATCH 1/2] genspec.sh: start patch numbering at 1

[GitLab Bridge on behalf of omos]

From: Ondrej Mosnacek <omosnace(a)redhat.com&gt;

After commit 699de0b4ccfa ("Copy Makefile.rhelver as a source file
rather than a patch"), there is no longer a special Patch1, so the
generated patches can start at 1.

Fixes: 699de0b4ccfa ("Copy Makefile.rhelver as a source file rather than a
patch")
Signed-off-by: Ondrej Mosnacek <omosnace(a)redhat.com&gt;
---
 redhat/genspec.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/redhat/genspec.sh b/redhat/genspec.sh
index b72dffe14729..d75fef669ab7 100755
--- a/redhat/genspec.sh
+++ b/redhat/genspec.sh
@@ -30,7 +30,7 @@ HIDE_REDHAT=1;
 HIDE_UNSUPPORTED_ARCH=1;
 # Set up for broken out patches
 plistf="$SOURCES/Patchlist"
-pnum=2
+pnum=1
 # override LC_TIME to avoid date conflicts when building the srpm
 LC_TIME=
 STAMP=$(echo $MARKER | cut -f 1 -d '-' | sed -e "s/v//");
-- 
GitLab

[OS-BUILD PATCH 2/2] genspec.sh: number patch files properly

[GitLab Bridge on behalf of omos]

From: Ondrej Mosnacek <omosnace(a)redhat.com&gt;

The 'pnum' variable is already there, so why not use it?

Signed-off-by: Ondrej Mosnacek <omosnace(a)redhat.com&gt;
---
 redhat/genspec.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/redhat/genspec.sh b/redhat/genspec.sh
index d75fef669ab7..c211d1aed401 100755
--- a/redhat/genspec.sh
+++ b/redhat/genspec.sh
@@ -256,7 +256,7 @@ if [ "$SINGLE_TARBALL" = 0 ]; then
 		":(exclude,top)Makefile.rhelver" \
 		":(exclude,top)redhat")
 	for c in $COMMITS; do
-		patch=$(git format-patch --zero-commit -1 "$c")
+		patch=$(git format-patch --start-number "$pnum" --zero-commit -1
"$c")
 		echo "$patch" >> $plistf
 		mv $patch $SOURCES/
 		sed -i "s/%%PATCHLIST%%/Patch$pnum: $patch\n%%PATCHLIST%%/" $SPECFILE
-- 
GitLab

[GitLab Bridge on behalf of Justin Forbes]

From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/491#note_37090...

Starting at 2 was intentional because it allows for quick testing of
patch sets heading upstream which may conflict with Red Hat patches.  We
want to see and resolve the conflict in the Red Hat patches, not the
upstream headed patch, so we want upstream applied first.

[GitLab Bridge on behalf of Ondrej Mosnáček]

From: Ondrej Mosnáček on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/491#note_37106...

Hm... any reason why you can't use `Patch0` in such case? Anyway, I can
just drop the first patch if you prefer having `Patch1` free.

But I think there should be an explicit `Patch1:`/`Patch0:` entry with
an empty patch (similar to `linux-kernel-test.patch`) so that the
intention is clear (and so someone else doesn't come and try to "fix" it
again). I can add such change to the MR if it's something you'd be happy
to see.

[GitLab Bridge on behalf of Ondrej Mosnáček]

From: Ondrej Mosnáček on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/491#note_39460...

@jmflinuxtx Ping... So is using `Patch0` OK for you or do you want me to
keep the `Patch1` reserved?

[Justin Forbes]

On Wed, Aug 12, 2020 at 2:26 AM GitLab Bridge on behalf of Ondrej
Mosnáček <jcline(a)redhat.com&gt; wrote:
>  From: Ondrej Mosnáček on gitlab.com
>  https://gitlab.com/cki-project/kernel-ark/-/merge_requests/491#note_39460...
>
>  @jmflinuxtx Ping... So is using `Patch0` OK for you or do you want me to
>  keep the `Patch1` reserved? 

It would be fine, but this patch set has not been merged because the
whole thing is planned to go away very soon. The workflow and patch
breakout is being rewritten to be more simple for contributors to work
with.

Justin

[GitLab Bridge on behalf of Justin Forbes]

From: Justin Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/491#note_43461...

Closing this as the workflow change is live and this patch is no longer
relevant there.