Bug 437608 - When prelink is installed, rpm builds are garbage
When prelink is installed, rpm builds are garbage
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
14
All Linux
low Severity low
: ---
: ---
Assigned To: Martin Stransky
Fedora Extras Quality Assurance
: Triaged
: 457209 538347 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-15 01:25 EDT by Christopher Aillon
Modified: 2013-01-09 23:36 EST (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-01-06 07:53:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Command history demonstrating issue (1.33 KB, text/plain)
2009-03-07 16:57 EST, Mike A. Harris
no flags Details
Fix unprelinking the stub as soon as possible. (337 bytes, patch)
2010-04-06 05:36 EDT, Jan Kratochvil
no flags Details | Diff
patch to firefox.spec (1.86 KB, patch)
2010-12-21 06:23 EST, Martin Stransky
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 158266 None None None Never

  None (edit)
Description Christopher Aillon 2008-03-15 01:25:30 EDT
Just spent some time with nirik trying to track this down....


With prelink installed, doing e.g. make local on firefox/devel yields:

prelink:
/var/tmp/firefox-3.0-0.40.cvs20080312.fc9-root-kevin/usr/lib64/firefox-3.0b5pre/firefox:
Section .gnu.version created after prelinking"

during the build process, and on trying to install the generated rpm, yields:

error: unpacking of archive failed on file
/usr/lib64/firefox-3.0b5pre/firefox;47db5609: cpio: MD5 sum mismatch

Uninstalling prelink fixes the problem.  This is true for rpmbuild -ba
foo.src.rpm as well.
Comment 1 Bug Zapper 2008-05-14 02:05:01 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Jan Horak 2008-11-12 05:00:59 EST
*** Bug 457209 has been marked as a duplicate of this bug. ***
Comment 3 Jack Perdue 2009-02-13 17:27:17 EST
Also on Fedora 10.

firefox-3.0.6-1.fc10
prelink-0.4.0-3.i386

Might be related to bug #158266.  Using the workaround there (using "/bin/cat preload library" in /etc/rpm/macros.prelink) didn't seem to help.  Removing the prelink RPM or removing /etc/rpm/macros.prelink does.
Comment 4 Mike A. Harris 2009-03-07 16:54:17 EST
This problem just hit me in CentOS 5.2 while trying to rebuild the stock firefox-3.0.6 package updated to 3.0.7.  My build succeeded, but would not install.  'nirik' in IRC told me to try removing the prelink rpm and rebuilding firefox again, which worked successfully for me.  Attaching a log of the errors et al.
Comment 5 Mike A. Harris 2009-03-07 16:57:21 EST
Created attachment 334426 [details]
Command history demonstrating issue
Comment 6 Trevor Cordes 2009-04-01 16:54:35 EDT
"Me too".  The workaround of uninstalling prelink first works fine.  I think rpmbuild is taking the md5 first, then applying prelink after, thereby screwing up the md5 in the final rpm.  Just a guess.
Comment 7 Mike A. Harris 2009-04-03 06:10:32 EDT
Doesn't appear to be a Fedora specific issue, but does not seem to occur with other packages.  Appears rather to be firefox package specific, or at least I have not been able to reproduce this with any other package yet.
Comment 8 Hans Lellelid 2009-04-20 13:18:55 EDT
Note that this happened to be me with a completely unrelated, proprietary/internal package.  Just wanted to register that this is not a Firefox-specific issue. (Uninstalling prelink fixes the issue for me too.)
Comment 9 Trevor Cordes 2009-04-22 03:30:19 EDT
Note: don't freak out if you run a rpm -Va check after uninstalling prelink!  I did that and thought I had rootkits out the wazzooo, but reinstalling prelink fixed rpm -Va.  I don't even want to think about how they compensate for that in rpm -V.
Comment 10 Bug Zapper 2009-06-09 19:46:37 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 Kevin Fenzi 2009-06-09 23:33:28 EDT
per at least comment #3, this happens on f10 at least.
Comment 12 Nathan G. Grennan 2009-06-20 16:27:01 EDT
I am seeing this on Fedora 11 while trying to build Firefox 3.5rc2.
Comment 13 Nathan G. Grennan 2009-06-20 17:08:43 EDT
 I found a workaround that doesn't involve fussing with the prelink package. I put the line below at the end of the %install section. It seems to have done the trick. I am not 100% sure, because oddly I started having this problem out of the blue. I built the package a few times without a problem, changed the spec in a minor way, and then started having this problem. I also tried changing it back, and the problem continued.

prelink -u $RPM_BUILD_ROOT/%{mozappdir}/firefox


 I also get the impression that the problem is related to that fact that the firefox binary is in a library folder. Where as in most packages it would be in /usr/bin. So maybe prelink makes an assumption, and firefox does things less than ideally. Other packages would probably put firefox in a libexec directory.
Comment 14 Nathan G. Grennan 2009-06-20 21:25:05 EDT
  The prelink solution doesn't work on Fedora 10. I am wondering if ccache is at play here.

+ prelink -u /home/builder/rpmbuild/BUILDROOT/firefox-3.5-0.18.rc2.fc10.x86_64//usr/lib64/firefox-3.5/firefox
prelink: /home/builder/rpmbuild/BUILDROOT/firefox-3.5-0.18.rc2.fc10.x86_64//usr/lib64/firefox-3.5/firefox does not have .gnu.prelink_undo section
Comment 15 Bug Zapper 2009-11-18 07:27:04 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Martin Stransky 2009-11-18 08:53:44 EST
reproducible on f11 too
Comment 17 Panu Matilainen 2009-11-26 04:53:48 EST
*** Bug 538347 has been marked as a duplicate of this bug. ***
Comment 18 Daniel Duggan 2010-01-16 20:47:13 EST
This very same thing happen when rebuilding firefox-3.6.1-0.9.b5.fc13.x86_64 on
F12  2.6.31.9-174.fc12.x86_64
RPM version 4.7.2
prelink 1.0
ccache version 2.4
Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz

Had rebuilt the same a rpm a number of times, then it suddenly started generating
the following message
Section .gnu.version created after prelinking"
and upon an attempted installation with yum localinstall
cpio: MD5 sum mismatch

I added (as previously suggested) at the end of the %install section
prelink -u $RPM_BUILD_ROOT/%{mozappdir}/firefox
and the error was no longer present.
Comment 19 Jan Kratochvil 2010-04-06 05:35:00 EDT
So this is a bug in Firefox.
/usr/lib64/xulrunner-1.9.1/xulrunner-stub is a system binary so it gets naturally prelinked.  You have to unprelink it when used for new rpm build.

Other possibility would be to reassign this Bug to "xulrunner" and create:
/etc/prelink.conf.d/xulrunner.conf:
-b /usr/lib64/xulrunner-1.9.1/xulrunner-stub
(not tested)
Comment 20 Jan Kratochvil 2010-04-06 05:36:35 EDT
Created attachment 404666 [details]
Fix unprelinking the stub as soon as possible.
Comment 21 Jakub Jelinek 2010-04-06 05:45:26 EDT
It is very questionable that binaries from the system are just copied into a newly created rpm, they should be either built from the sources, or symlinked, or copied in rpm scriptlets.  Copying a system binary means you aren't shipping sources for what you include in the binary rpm.
Comment 22 Matěj Cepl 2010-04-30 10:19:15 EDT
Just switching this to the latest distro, because it is live and kicking everywhere.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 23 Bug Zapper 2010-07-30 06:31:41 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 24 Hicham HAOUARI 2010-10-06 11:40:58 EDT
Having this problem as well when trying to package instantbird ( mozilla based IM ).

adding : %define __prelink_undo_cmd %{nil}

to the spec fixes the issue for me ( thanks to rdieter for the suggestion )
Comment 25 Martin Stransky 2010-12-14 10:50:42 EST
__prelink_undo_cmd sounds promising.
Comment 26 Martin Stransky 2010-12-17 11:15:17 EST
Hm, it looks all ways has their drawbacks. __prelink_undo_cmd causes that rpm -V fails which is unacceptable, to call prelink during package build fails when the package is rebuilt by non-root user.
Comment 27 Martin Stransky 2010-12-21 06:23:08 EST
Created attachment 469957 [details]
patch to firefox.spec
Comment 28 Martin Stransky 2011-01-06 07:53:52 EST
fixed in rawhide, firefox-4.0-0.10b8.fc15
Comment 29 Hicham HAOUARI 2011-01-06 08:06:05 EST
I think a new guideline for packaging xulrunner apps should be created with this workaround in it.
Comment 30 Hicham HAOUARI 2011-01-07 11:45:53 EST
@Martin :

This change would result in treating all xulrunner apps like firefox addons. If firefox is stuck, you should kill xulrunner, instead of killing just the stub in the ff libdir. Is that really an intentional behavior ?
Comment 31 Hicham HAOUARI 2011-01-07 12:00:51 EST
@Martin :

The changes you have done resulted in firefox being noarch too.
Comment 32 Hicham HAOUARI 2011-01-07 12:11:59 EST
I would rather go with solution 3 of comment 21, since the stub isn't meant to be part of the package.
Comment 33 Martin Stransky 2011-01-10 03:34:10 EST
What do you mean with "treating all xulrunner apps like firefox addons" and which application will do so?

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