From: Jarod Wilson jarod@redhat.com
redhat: indicate HEAD state in tarball/rpm name
For the non-Fedora (RHEL) case, we are looking to move to a setup where we include Merge Requests as soon as they are ready, and thus the head of main may not always be a tagged build. This gives some indication to someone basing a build on main that they're basing their work on the tree at a state between tagged builds.
If HEAD is a tagged build, as usual, you should see: linux-4.18.0-374.el8.tar.xz kernel-4.18.0-374.el8.src.rpm
If HEAD has additional commits, with this change, you should see: linux-4.18.0-374.p1.g797fdad2a6e5.el8.tar.xz kernel-4.18.0-374.p1.g797fdad2a6e5.el8.src.rpm
The .pX field is "X patches since tag" and the .gSHA field is the HEAD sha of the branch after adding your local changes.
This is directly related to: https://gitlab.com/redhat/rhel/src/kernel/rhel-8/-/merge_requests/2405
Signed-off-by: Jarod Wilson jarod@redhat.com
diff --git a/redhat/Makefile b/redhat/Makefile index blahblah..blahblah 100644 --- a/redhat/Makefile +++ b/redhat/Makefile @@ -189,6 +189,14 @@ ifeq ($(VERSION_ON_UPSTREAM),1) endif else SNAPSHOT:=0 + EXACT_TAG:=$(shell $(GIT) describe --exact-match 2>/dev/null) + ifeq ($(EXACT_TAG),) + _TAG:=$(shell $(GIT) describe 2>/dev/null) + ifneq ($(_TAG),) + RHEL_EXTRAVERSION:=$(shell echo $(_TAG) | awk -F- '{ printf(".p%d.%s", $$(NF-1),$$(NF)) }') + BUILD:=$(BUILD)$(RHEL_EXTRAVERSION) + endif + endif endif
KVERSION:=$(RPMKVERSION).$(RPMKPATCHLEVEL).$(RPMKSUBLEVEL)
-- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1735
From: Prarit Bhargava on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1735#note_9012243...
The problem IIUC (@jmflinuxtx can confirm) is that this leads to multiple sources tarballs being uploaded into koji.
From: Justin M. Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1735#note_9012669...
Correct, I would rather make the BUILD go away even for the KABI tarballs, so for instance kernel-kabi-dw-5.17.1-300.tar.bz2 becomes kernel-kabi- dw-5.17.1.tar.bz2 as there is no need to have 3 copies of the same tarball in lookaside just because they are named differently. It also makes it more difficult for the users working in dist-git to do a quick one off build with a bumped pkgrelease. There are other places I need to clean up in the spec to make that happen, but in the meantime let's not add more. Perhaps we could make this a feature based on a flag in Makefile.variables? That way I could turn it off for Fedora. We do set VERSION_ON_UPSTREAM:=0 for stable fedora releases, while it is 1 for os-build, so that can't be the only key.
From: Jarod Wilson on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1735#note_9015404...
Hm. I forgot you're doing both a Fedora and a RHEL-ish pass on things here every build. This is primarily meant for later use by RHEL, when the only builds the maintainer does are tagged ones. What if this were gated on $(DISTRO) not being fedora or centos, does that help at all?
From: Prarit Bhargava on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1735#note_9015445...
"Perhaps we could make this a feature based on a flag in Makefile.variables? That way I could turn it off for Fedora."
We could but does the $(PKGRELEASE) string really add any value for the tarballs? IOW I'm wondering if something as simple as
https://gitlab.com/prarit/kernel- ark/-/commit/eacde0c5acfa4665f4ef749b2b96ee614d6633f1
would work?
From: Prarit Bhargava on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1735#note_9015491...
Oops. Sorry @jwilsonrh. We definitely could gate on $(DISTRO), but I'm curious if the $(PKGRELEASE) tag has any value at all for a tarball?
kernel@lists.fedoraproject.org
-
Jarod Wilson (via Email Bridge) -
Justin M. Forbes (via Email Bridge)
-
Prarit Bhargava (via Email Bridge)