Bug 968015 - Macro "modsign_install_post" is broken in specfile
Macro "modsign_install_post" is broken in specfile
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All All
unspecified Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-05-28 15:14 EDT by Matthias Hensler
Modified: 2013-10-08 13:15 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-10-08 13:15:17 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Use integer comparison instead of string comparison (1.37 KB, patch)
2013-05-28 15:14 EDT, Matthias Hensler
no flags Details | Diff

  None (edit)
Description Matthias Hensler 2013-05-28 15:14:30 EDT
Created attachment 754054 [details]
Use integer comparison instead of string comparison

Description of problem:
When building the kernel from source the modsign_install_post macro does not honour buildflags correctly and therefore fails.

Version-Release number of selected component (if applicable):
3.9.4-300.fc19, but I guess all F19-versions are affected.

How reproducible:
Every time, if the package is build without debug (other buildflags might also fail).

Steps to Reproduce:
1. Install kernel.src.rpm from koji
2. Build with "rpmbuild -ba --without debug kernel.spec"
3. Build will fail

Actual results:

Build fails with:
+ /usr/lib/rpm/redhat/brp-java-repack-jars
+ '[' 1 == 1 ']'
+ '[' 0 '!=' 0 ']'
+ '[' '     0 ' '!=' 0 ']'
+ mv signing_key.priv.sign.debug signing_key.priv
mv: cannot stat 'signing_key.priv.sign.debug': No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.mCLy7C (%install)

Expected results:
Build should not fail :)

Additional info:
The root cause is how the "with_debug" variable is defined (applies for others variables as well) and how it is used in modsign_install_post.

The define for "with_debug" is the following:
%define with_debug     %{?_without_debug:     0} %{?!_without_debug:     1}

The if-construct in modsign_install_post looks like this:
if [ "%{with_debug}" != "0" ]; then

So, if "--without debug" is specified on the commandline, the "with_debug"-variable actually has the value "    0" (note the four trailing spaces upfront). Actually that is no problem, as long as the usual "%if %{with_debug}" syntax is used (actually in the build process no debugbuild takes places, and so the needed signing-keys will not be created for debug), however in modsign_install_post a strict string comparison is used, and actually "    0" is different from "0" there.

If I see correctly we can be sure, that all five used variables ("signmodules", "with_pae", "with_debug", "with_pae_debug" and "with_up") are always properly initialized (either with "0", "1", "     0" or "     1", but never empty). In that case the attached patch will solve the issue by switching from string-comparison to integer-comparison.

Another, more robust solution could be a construct like this:

  if [ "$((%{with_debug}+0))" -ne "0" ]; then

That would even take care of uninitialized variable, but looks a bit ugly. So I guess it would be enough to apply to solution from attached patch.
Comment 1 Josh Boyer 2013-05-28 15:42:54 EDT
This should be fixed in rawhide with fedora commits:

commit 63cb38bed692a52a79e33f41bfe42c277e578712
Author: Kyle McMartin <kyle@mcmartin.ca>
Date:   Thu Mar 28 15:01:42 2013 -0400

    simplify the signing stuff now that sign-file takes pub/priv key args
    also fix %{with_*} tests (which jan stancek sent for rhel, thanks!)


commit f9a5fa4aa62ad3f14839621e8f593e189681d6e0
Author: Kyle McMartin <kyle@mcmartin.ca>
Date:   Mon Apr 8 10:31:23 2013 -0400

    wat (!= -ne)
Comment 2 Josh Boyer 2013-09-18 16:46:07 EDT
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

Note You need to log in before you can comment on or make changes to this bug.