[OS-BUILD PATCH] Makefile.common: Do not pre-maturely bump version number during merge window

[GitLab Bridge on behalf of dzickusrh]

From: Don Zickus <dzickus(a)redhat.com&gt;

I am not sure why the version number is bumped for rc0, but it causes
the rpm to build with the wrong version number.  This puts the kernel
modules in the wrong directory and the booted kernel can't find them.

For example, currently the 5.8-rc1 merge window has 5.7.0 in the top
level Makefile.  But the kernel.spec puts the modules in 5.8.0-0.rc0
directory which doesn't match.

I believe this was for legacy reasons, but forgot why.  Not sure why we
are suddently seeing this after a year.  This might be the first time
we tried building a kernel before -rc1 is officially out.

Signed-off-by: Don Zickus <dzickus(a)redhat.com&gt;
---
 redhat/Makefile.common | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/redhat/Makefile.common b/redhat/Makefile.common
index d980847aacc7..ff5e0853fc40 100644
--- a/redhat/Makefile.common
+++ b/redhat/Makefile.common
@@ -53,15 +53,6 @@ endif
 ifeq ($(SNAPSHOT),1)
   # The base for generating tags is the snapshot commit
   MARKER:=$(shell echo $(TAG) | cut -d "g" -f 2)
-  # The merge window is weird because the actual versioning hasn't
-  # been updated but we still need something that works for
-  # packaging. Fix this by bumping the patch level and marking
-  # this as rc0
-  ifeq ($(RPMKEXTRAVERSION),)
-    KEXTRAVERSION:=.rc0
-    PREBUILD:=0$(KEXTRAVERSION).
-    RPMKPATCHLEVEL:=$(shell expr $(RPMKPATCHLEVEL) + 1)
-  endif
   # Follow the packaging guidelines to include the date + git snapshot
   PREBUILD:=$(PREBUILD)$(shell date +%Y%m%d)git$(MARKER).
   UPSTREAM_TARBALL_NAME:=$(shell date +%Y%m%d)git$(MARKER)
-- 
2.27.0

[Jiri Benc]

On Tue, 09 Jun 2020 20:13:39 -0000, GitLab Bridge on behalf of dzickusrh wrote:
>  For example, currently the 5.8-rc1 merge window has 5.7.0 in the top
>  level Makefile.  But the kernel.spec puts the modules in 5.8.0-0.rc0
>  directory which doesn't match. 
What is the rpm version of the kernel after this patch?

The kernel is not actually 5.7, it is a later one. 5.8-rc0 seems
appropriate, though obviously does not match the in-kernel version and
has the problems you mention. However, naming the kernel "5.7" seems
misleading.

Could we perhaps append something to the kernel version to indicate
it's not a 5.7 kernel anymore? Even something like "5.7.0-5.8.0.rc0"
would work, IMHO. Just be sure that this is understood as a newer
version than 5.7.0 by rpm.

Thanks,

 Jiri

[Jan Stancek]

----- Original Message -----
>  On Tue, 09 Jun 2020 20:13:39 -0000, GitLab Bridge on behalf of
> dzickusrh
>  wrote:
>  > For example, currently the 5.8-rc1 merge window has 5.7.0 in the top
>  > level Makefile.  But the kernel.spec puts the modules in 5.8.0-0.rc0
>  > directory which doesn't match.
>  
>  What is the rpm version of the kernel after this patch?
>  
>  The kernel is not actually 5.7, it is a later one. 5.8-rc0 seems
>  appropriate, though obviously does not match the in-kernel version and
>  has the problems you mention. However, naming the kernel "5.7" seems
>  misleading.
>  
>  Could we perhaps append something to the kernel version to indicate
>  it's not a 5.7 kernel anymore? Even something like "5.7.0-5.8.0.rc0"
>  would work, IMHO. Just be sure that this is understood as a newer
>  version than 5.7.0 by rpm. 
+1, Since it's daily snapshot, how about git sha, so it's possible
to tell 2 snapshots apart?

@@ -58,12 +58,11 @@ ifeq ($(SNAPSHOT),1)
   # packaging. Fix this by bumping the patch level and marking
   # this as rc0
   ifeq ($(RPMKEXTRAVERSION),)
-    KEXTRAVERSION:=.rc0
+    KEXTRAVERSION:=.git$(MARKER)
     PREBUILD:=0$(KEXTRAVERSION).
-    RPMKPATCHLEVEL:=$(shell expr $(RPMKPATCHLEVEL) + 1)
   endif
   # Follow the packaging guidelines to include the date + git snapshot
-  PREBUILD:=$(PREBUILD)$(shell date +%Y%m%d)git$(MARKER).
+  PREBUILD:=$(PREBUILD)$(shell date +%Y%m%d).
   UPSTREAM_TARBALL_NAME:=$(shell date +%Y%m%d)git$(MARKER)
 endif

[Justin Forbes]

On Wed, Jun 10, 2020 at 6:59 AM Jan Stancek <jstancek(a)redhat.com&gt; wrote:
>  ----- Original Message -----
>  > On Tue, 09 Jun 2020 20:13:39 -0000, GitLab Bridge on behalf of dzickusrh
>  > wrote:
>  > > For example, currently the 5.8-rc1 merge window has 5.7.0 in the top
>  > > level Makefile.  But the kernel.spec puts the modules in 5.8.0-0.rc0
>  > > directory which doesn't match.
>  >
>  > What is the rpm version of the kernel after this patch?
>  >
>  > The kernel is not actually 5.7, it is a later one. 5.8-rc0 seems
>  > appropriate, though obviously does not match the in-kernel version and
>  > has the problems you mention. However, naming the kernel "5.7" seems
>  > misleading.
>  >
>  > Could we perhaps append something to the kernel version to indicate
>  > it's not a 5.7 kernel anymore? Even something like "5.7.0-5.8.0.rc0"
>  > would work, IMHO. Just be sure that this is understood as a newer
>  > version than 5.7.0 by rpm.
>  
The place to put something like this would be in EXTRAVERSION which we
already truncate because it exceeds the character limit. But it has
the date and the gitrev.  It can't be that confusing, Linus doesn't
bump PATCHLEVEL until rc1, it has always been that way. Merge window
kernels for 5.7 were 5.6 still.

>  +1, Since it's daily snapshot, how about git sha, so it's
> possible
>  to tell 2 snapshots apart?
>  
It has one, just not in this particular section. EXTRAVERSION has the
gitrev and the date.
kernel-5.7.0-0.rc0.20200608gitaf7b4801030c.1

> @@ -58,12 +58,11 @@ ifeq ($(SNAPSHOT),1)
>    # packaging. Fix this by bumping the patch level and marking
>    # this as rc0
>    ifeq ($(RPMKEXTRAVERSION),)
> -    KEXTRAVERSION:=.rc0
> +    KEXTRAVERSION:=.git$(MARKER)
>      PREBUILD:=0$(KEXTRAVERSION).
> -    RPMKPATCHLEVEL:=$(shell expr $(RPMKPATCHLEVEL) + 1)
>    endif
>    # Follow the packaging guidelines to include the date + git snapshot
> -  PREBUILD:=$(PREBUILD)$(shell date +%Y%m%d)git$(MARKER).
> +  PREBUILD:=$(PREBUILD)$(shell date +%Y%m%d).
>    UPSTREAM_TARBALL_NAME:=$(shell date +%Y%m%d)git$(MARKER)
>  endif
> _______________________________________________
> kernel mailing list -- kernel(a)lists.fedoraproject.org
> To unsubscribe send an email to kernel-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/[e-mail]

[Ondrej Mosnacek]

On Wed, Jun 10, 2020 at 2:16 PM Justin Forbes <jmforbes(a)linuxtx.org&gt; wrote:
>  On Wed, Jun 10, 2020 at 6:59 AM Jan Stancek
> <jstancek(a)redhat.com&gt; wrote:
>  >
>  >
>  > ----- Original Message -----
>  > > On Tue, 09 Jun 2020 20:13:39 -0000, GitLab Bridge on behalf of dzickusrh
>  > > wrote:
>  > > > For example, currently the 5.8-rc1 merge window has 5.7.0 in the top
>  > > > level Makefile.  But the kernel.spec puts the modules in 5.8.0-0.rc0
>  > > > directory which doesn't match.
>  > >
>  > > What is the rpm version of the kernel after this patch?
>  > >
>  > > The kernel is not actually 5.7, it is a later one. 5.8-rc0 seems
>  > > appropriate, though obviously does not match the in-kernel version and
>  > > has the problems you mention. However, naming the kernel "5.7" seems
>  > > misleading.
>  > >
>  > > Could we perhaps append something to the kernel version to indicate
>  > > it's not a 5.7 kernel anymore? Even something like
> "5.7.0-5.8.0.rc0"
>  > > would work, IMHO. Just be sure that this is understood as a newer
>  > > version than 5.7.0 by rpm.
>  >
>
>  The place to put something like this would be in EXTRAVERSION which we
>  already truncate because it exceeds the character limit. But it has
>  the date and the gitrev.  It can't be that confusing, Linus doesn't
>  bump PATCHLEVEL until rc1, it has always been that way. Merge window
>  kernels for 5.7 were 5.6 still.
>
>  > +1, Since it's daily snapshot, how about git sha, so it's possible
>  > to tell 2 snapshots apart?
>  >
>
>  It has one, just not in this particular section. EXTRAVERSION has the
>  gitrev and the date.
>  kernel-5.7.0-0.rc0.20200608gitaf7b4801030c.1 
But this is < kernel-5.7.0-1, which is older than this snapshot. Maybe
we could at least change the first number in PREBUILD from 0 to 900 or
something to make the version higher than any v5.7 based kernel build?

-- 
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.

[Justin Forbes]

On Wed, Jun 10, 2020 at 7:45 AM Ondrej Mosnacek <omosnace(a)redhat.com&gt; wrote:
>  On Wed, Jun 10, 2020 at 2:16 PM Justin Forbes <jmforbes(a)linuxtx.org&gt; wrote:
>  > On Wed, Jun 10, 2020 at 6:59 AM Jan Stancek <jstancek(a)redhat.com&gt; wrote:
>  > >
>  > >
>  > > ----- Original Message -----
>  > > > On Tue, 09 Jun 2020 20:13:39 -0000, GitLab Bridge on behalf of dzickusrh
>  > > > wrote:
>  > > > > For example, currently the 5.8-rc1 merge window has 5.7.0 in the top
>  > > > > level Makefile.  But the kernel.spec puts the modules in 5.8.0-0.rc0
>  > > > > directory which doesn't match.
>  > > >
>  > > > What is the rpm version of the kernel after this patch?
>  > > >
>  > > > The kernel is not actually 5.7, it is a later one. 5.8-rc0 seems
>  > > > appropriate, though obviously does not match the in-kernel version and
>  > > > has the problems you mention. However, naming the kernel "5.7"
> seems
>  > > > misleading.
>  > > >
>  > > > Could we perhaps append something to the kernel version to indicate
>  > > > it's not a 5.7 kernel anymore? Even something like
> "5.7.0-5.8.0.rc0"
>  > > > would work, IMHO. Just be sure that this is understood as a newer
>  > > > version than 5.7.0 by rpm.
>  > >
>  >
>  > The place to put something like this would be in EXTRAVERSION which we
>  > already truncate because it exceeds the character limit. But it has
>  > the date and the gitrev.  It can't be that confusing, Linus doesn't
>  > bump PATCHLEVEL until rc1, it has always been that way. Merge window
>  > kernels for 5.7 were 5.6 still.
>  >
>  > > +1, Since it's daily snapshot, how about git sha, so it's possible
>  > > to tell 2 snapshots apart?
>  > >
>  >
>  > It has one, just not in this particular section. EXTRAVERSION has the
>  > gitrev and the date.
>  > kernel-5.7.0-0.rc0.20200608gitaf7b4801030c.1
>
>  But this is < kernel-5.7.0-1, which is older than this snapshot. Maybe
>  we could at least change the first number in PREBUILD from 0 to 900 or
>  something to make the version higher than any v5.7 based kernel build?
>  
Oh, actually, you are correct. So comments in the changelog for old
kernels were based on the upstream version, but what we really had in
rawhide to take care of this was in the spec:

   # if pre-rc1 devel kernel, must fix up PATCHLEVEL for our versioning scheme
    %if !0%{?rcrev}
    %if 0%{?gitrev}
    perl -p -i -e 's/^PATCHLEVEL.*/PATCHLEVEL = %{upstream_sublevel}/' Makefile
    %endif
    %endif

Which will have to be fixed up a bit differently in the ark spec, but
we can do something similar.

Justin

[GitLab Bridge on behalf of Don Zickus]

From: Don Zickus on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/442#note_35893...

I will close this and in preference to Justin's change.

Cheers,
Don