An annoying and non-obvious rpmbuild “feature enhancement”

Specifically, under certain circumstances, it can dump debuginfo files into /usr/lib/debug and /usr/src/debug under your buildroot, neglect to build the corresponding -debuginfo package, and then have the gall to complain about the unpackaged files it dumped there.

I have a confession to make: I’m anal-retentive enough about the systems I administer where I need to build RPM packages for everything so they can be easily updated, but I’m lazy enough where I usually just grab source RPMs out of the most recent Fedora repositories and modify the specfiles until they work on CentOS 5. This can lead to some interesting issues, because RPM and rpmbuild are not quite the same in CentOS as they are in Fedora. Sometimes you’re never quite sure if something is a bugfix or a feature enhancement, and this was one of those lovely times.

This week, I got a request from a user to build a more recent version of gnuplot than the 4.0 version that ships with CentOS 5. Simple enough, right? I took the F13 SRPM, bumped the underlying source tarball to 4.4.1, made a couple of config fixes for the distro change and version bump, and then fired up Mock to build it for CentOS. It would build successfully, and the RPM packaging would bomb out with errors like the following in Mock’s build.log:


RPM build errors:
    Installed (but unpackaged) file(s) found:
   /usr/lib/debug/usr/bin/gnuplot-minimal.debug
   /usr/lib/debug/usr/bin/gnuplot-wx.debug
   /usr/lib/debug/usr/libexec/gnuplot/4.4/gnuplot_x11.debug
   /usr/src/debug/gnuplot-4.4.1/src/alloc.c
   /usr/src/debug/gnuplot-4.4.1/src/axis.c
   /usr/src/debug/gnuplot-4.4.1/src/axis.h
...

It took me two to three days of looking at this issue off and on to determine that the problem was related to a single innocuous line buried deep inside the package spec:

BuildArch: noarch

Interestingly, this was on a subpackage, which apparently is enough to trip up rpmbuild for all packages listed in the spec.

After removing that line, the -debuginfo was generated fine.

In short: on older rpmbuild versions, don’t build arch-specific binary packages that have noarch subpackages. This does work fine on newer rpmbuild versions.

Hope this helps somebody, somewhere.

16 Comments

  1. Oh man, If not You and google I would wonder for 2or3 days as well. After adding new “noarch” subpackage I could not get the rpm build. Really annoying. Thanx!

  2. Thanks for the post on this.. I ran into this building an SRPM from RHEL 6 on CentOS 5.

    Laced throughout the spec are lines like this.
    %if 0%{?fedora} >= 10 || 0%{?rhel} >= 6
    BuildArch: noarch
    %endif

    which works, except they forgot to wrap one of them :)

  3. Thanks Jeff! That saved my day:

    %package selinux
    Summary:   SElinux support for Xymon
    Group:     Applications/File
    Requires:  %name = %version-%release
    Requires(post): policycoreutils
    Requires(postun): policycoreutils
    %if 0%{?fedora} >= 10 || 0%{?rhel} >= 6 || 0%{?centos} >= 6
    BuildArch: noarch
    %endif
    
    
      
    
  4. You sir are a hero. Many thanks for this

  5. Dang, dude. Awesome find. Having the exact same problem with bind srpm.

  6. Holy freakin’ hell. Thank you for posting this.

  7. Just got bitten by this myself. Yay Google! For comparison, I wrote a blog post about 6 years ago about some obscure Python building detail on obsolete distros, and I still get people thanking me for it :-)

    So … thank you!

  8. Yet another guy who was came up against this problem while backporting packages to EL5 and was beating my head against the wall trying to find the cause. Thanks for sharing!

  9. I am typically to blogging and i actually admire your content. The article has actually peaks my interest. I am going to bookmark your web site and keep checking for brand new information.

  10. Thanks for sharing, helped me as well.

  11. Vyacheslav Yurkov

    20 December, 2012 at 4:10 AM

    Thanks mate!
    You just saved my day!

  12. Sonuva… yes, this happened to me converting an rcov Ruby gem using gem2rpm. In that case, it recognizes that the gem itself is not ‘noarch’, but it left a BuildArch declaration in the _doc subpackage_. Great find!

  13. May your children receive many blessings!

  14. Tks! I got this problem packaging a new app to an old OpenSUSE version. It was driving me crazy!

  15. I really like your writing style, excellent info, thank you for putting up dagaefbbgdke

  16. Thank you, sir. What a dumb thing to leave undocumented!

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2014 @jgoldschrafe

Theme by Anders NorenUp ↑