Description of problem: The kernel team uses rpmdev-bumpspec quite a bit to increment the release number for kernel builds. In F19 (and prior releases), this works fine by bumping the %{base_release} variable we have. In F20, it bumps both base_release and adds a .1 to the end of %{pkg_release} in the actual Release field. Version-Release number of selected component (if applicable): rpmdevtools-8.4-2.fc20.noarch How reproducible: Always Steps to Reproduce: 1. checkout a fedora kernel repo 2. run 'rpmdev-bumpspec -c "whatever" kernel.spec 3. look at the git diff Actual results: both base_release and Release: %{pkg_release} are bumped. Expected results: Just base_release should be incremented. Additional info: On F19: [jwboyer@zod kernel]$ pwd /home/jwboyer/kernel [jwboyer@zod kernel]$ rpm -q rpmdevtools rpmdevtools-8.3-3.fc19.noarch [jwboyer@zod kernel]$ git show | head -1 commit a752808ab499a0552df7ef7246538da7be2e736c [jwboyer@zod kernel]$ rpmdev-bumpspec -c "whatever" kernel.spec [jwboyer@zod kernel]$ git diff diff --git a/kernel.spec b/kernel.spec index 70ffe5d..e7a12d3 100644 --- a/kernel.spec +++ b/kernel.spec @@ -62,7 +62,7 @@ Summary: The Linux kernel # For non-released -rc kernels, this will be appended after the rcX and # gitX tags, so a 3 here would become part of release "0.rcX.gitX.3" # -%global baserelease 1 +%global baserelease 2 %global fedora_build %{baserelease} # base_sublevel is the kernel version we're starting with and patching @@ -2209,6 +2209,9 @@ fi # ||----w | # || || %changelog +* Sun Dec 15 2013 Josh Boyer <jwboyer> - 3.13.0-0.rc3.git5.2 +- whatever + * Sat Dec 14 2013 Josh Boyer <jwboyer> - 3.13.0-0.rc3.git5.1 - Linux v3.13-rc3-362-gb2077eb [jwboyer@zod kernel]$ On F20: [jwboyer@vader kernel]$ pwd /home/jwboyer/kernel [jwboyer@vader kernel]$ rpm -q rpmdevtools rpmdevtools-8.4-2.fc20.noarch [jwboyer@vader kernel]$ git show | head -1 commit a752808ab499a0552df7ef7246538da7be2e736c [jwboyer@vader kernel]$ rpmdev-bumpspec -c "whatever" kernel.spec [jwboyer@vader kernel]$ git diff diff --git a/kernel.spec b/kernel.spec index 70ffe5d..fa2c810 100644 --- a/kernel.spec +++ b/kernel.spec @@ -62,7 +62,7 @@ Summary: The Linux kernel # For non-released -rc kernels, this will be appended after the rcX and # gitX tags, so a 3 here would become part of release "0.rcX.gitX.3" # -%global baserelease 1 +%global baserelease 2 %global fedora_build %{baserelease} # base_sublevel is the kernel version we're starting with and patching @@ -473,7 +473,7 @@ Group: System Environment/Kernel License: GPLv2 and Redistributable, no modification permitted URL: http://www.kernel.org/ Version: %{rpmversion} -Release: %{pkg_release} +Release: %{pkg_release}.1 # DO NOT CHANGE THE 'ExclusiveArch' LINE TO TEMPORARILY EXCLUDE AN ARCHITECTURE # SET %%nobuildarches (ABOVE) INSTEAD ExclusiveArch: noarch %{all_x86} x86_64 ppc ppc64 ppc64p7 s390 s390x %{arm} aar @@ -2209,6 +2209,9 @@ fi # ||----w | # || || %changelog +* Sun Dec 15 2013 Josh Boyer <jwboyer> - 3.13.0-0.rc3.git5.2.1 +- whatever + * Sat Dec 14 2013 Josh Boyer <jwboyer> - 3.13.0-0.rc3.git5.1 - Linux v3.13-rc3-362-gb2077eb [jwboyer@vader kernel]$ Notice the extra .1 after Release: %{pkg_release} in the F20 steps.
Sigh. In the instances where I said "base_release" above I clearly meant baserelease. Sorry for any confusion.
This is a side effect of bug 789330, and unfortunately the kernel's usage of macros for the release tag outsmarts bumpspec even with the latest improvements to it. I'm not sure what to do about this, it starts to get quite hairy. One option (which I'm not particularly fond of) would be to add a command line option that would restrict bumping to the very first tag/macro found and leave it at that. Michael, thoughts?
I can see how it would get complicated rather fast. If there isn't something that can be done to make the code work for all cases, I thought of two other possible solutions over the weekend. 1) Add a "-d, --define" option that takes a specific %global/%define variable to bump. E.g. we could invoke it with: rpmdev-bumpspec -d baserelease -c "whatever" 2) Add a "-n, --nobump" option (or another script called rpmdev-changelog") that lets you add something to %changelog and doesn't bump anything and leaves the version info off the date line as well since it would be inaccurate. The option/script names are just suggestions.
Extra options aren't worth a penny here, since the script would _not_ do the right thing by default, if run for mass-rebuilds _without_ enabling extra options. And enabling an extra option would break other spec files during mass-rebuilds. On one side there are spec files, which build multiple subpackages with individual Release tags including macro-usage. On the other side are spec files, which enter macro hell for a single Release tag. In the kernel.spec, %baserelease is used to define %fedora_build, which in turn is used to define %pkg_release, which then becomes the value of the Release tag. To handle such a special spec, the bump script would need to become much smarter and attempt at expanding each and every macro in a spec file to determine the values of all Release tags for any subpackage. [...] What's left? A white-list perhaps? To enable a "bump only once" mode for the "kernel" package?
(In reply to Michael Schwendt from comment #4) > Extra options aren't worth a penny here, since the script would _not_ do the > right thing by default, if run for mass-rebuilds _without_ enabling extra > options. And enabling an extra option would break other spec files during > mass-rebuilds. That's true in the general sense. Except it would be useful for what we're actually using it for, and I've already asked that the kernel be exempt from mass rebuilds anyway. I wonder if anything else is broken by the recent change. Probably hard to determine programatically, given someone would have to manually verify every spec even if we scripted a "bump and diff" run against the whole pkg repo. > On one side there are spec files, which build multiple subpackages with > individual Release tags including macro-usage. On the other side are spec > files, which enter macro hell for a single Release tag. > > In the kernel.spec, %baserelease is used to define %fedora_build, which in > turn is used to define %pkg_release, which then becomes the value of the > Release tag. > > To handle such a special spec, the bump script would need to become much > smarter and attempt at expanding each and every macro in a spec file to > determine the values of all Release tags for any subpackage. > > [...] > > What's left? A white-list perhaps? To enable a "bump only once" mode for the > "kernel" package? That's fine too I suppose. I do think having an 'rpmdev-changelog' script would be useful for just adding a comment to the changelog. It could be a separate script, not an option, and we can change our usage to it fairly easily.
> I wonder if anything else is broken by the recent change. Maybe. See bug 789330 comment 24. The problem here simply is that prior to the change, the script didn't bump special multi-%package spec files that used an own Release tag for each subpackage (as complained about in bug 789330). Not bumping subpackages is a bug. Bumping least-significant (trailing .1) is a minor problem only, IMO. Especially for Rawhide where package maintainers may fix %release with the next commit again. > someone would have to manually verify every spec even > if we scripted a "bump and diff" run against the whole pkg repo. That's what I've done for the early Fedora Extras mass-rebuilds (where sopwith/notting's bump script was not capable enough), but I don't remember whether we've had any package with multiple Release tags for subpackages. That's a rare corner-case.
Bug 1047531 comment 7 for a bit of new background. My current solution handles kernel.spec as well as the multi-subpackage packages I've found in F20. $ /tmp/rpmdev-bumpspec kernel.spec -V kernel.spec -1 +2 $ /tmp/rpmdev-bumpspec kernel.spec -V kernel.spec -2 +3 $ /tmp/rpmdev-bumpspec kernel.spec -V kernel.spec -3 +4
rpmdevtools-8.5-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/rpmdevtools-8.5-1.fc21
Package rpmdevtools-8.5-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing rpmdevtools-8.5-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-13380/rpmdevtools-8.5-1.fc21 then log in and leave karma (feedback).
rpmdevtools-8.5-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.