Bug 437608 - When prelink is installed, rpm builds are garbage
Summary: When prelink is installed, rpm builds are garbage
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: 14
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 457209 538347 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-03-15 05:25 UTC by Christopher Aillon
Modified: 2018-04-11 15:07 UTC (History)
21 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-01-06 12:53:52 UTC


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


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 158266 None CLOSED rpm verify with --nomd5 gives bogus size errors on prelinked files 2019-09-27 18:15:12 UTC

Description Christopher Aillon 2008-03-15 05:25:30 UTC
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 06:05:01 UTC
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 10:00:59 UTC
*** Bug 457209 has been marked as a duplicate of this bug. ***

Comment 3 Jack Perdue 2009-02-13 22:27:17 UTC
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 21:54:17 UTC
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 21:57:21 UTC
Created attachment 334426 [details]
Command history demonstrating issue

Comment 6 Trevor Cordes 2009-04-01 20:54:35 UTC
"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 10:10:32 UTC
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 17:18:55 UTC
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 07:30:19 UTC
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 23:46:37 UTC
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-10 03:33:28 UTC
per at least comment #3, this happens on f10 at least.

Comment 12 Nathan G. Grennan 2009-06-20 20:27:01 UTC
I am seeing this on Fedora 11 while trying to build Firefox 3.5rc2.

Comment 13 Nathan G. Grennan 2009-06-20 21:08:43 UTC
 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-21 01:25:05 UTC
  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 12:27:04 UTC
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 13:53:44 UTC
reproducible on f11 too

Comment 17 Panu Matilainen 2009-11-26 09:53:48 UTC
*** Bug 538347 has been marked as a duplicate of this bug. ***

Comment 18 Daniel Duggan 2010-01-17 01:47:13 UTC
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 09:35:00 UTC
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 09:36:35 UTC
Created attachment 404666 [details]
Fix unprelinking the stub as soon as possible.

Comment 21 Jakub Jelinek 2010-04-06 09:45:26 UTC
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 14:19:15 UTC
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 10:31:41 UTC
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 15:40:58 UTC
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 15:50:42 UTC
__prelink_undo_cmd sounds promising.

Comment 26 Martin Stransky 2010-12-17 16:15:17 UTC
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 11:23:08 UTC
Created attachment 469957 [details]
patch to firefox.spec

Comment 28 Martin Stransky 2011-01-06 12:53:52 UTC
fixed in rawhide, firefox-4.0-0.10b8.fc15

Comment 29 Hicham HAOUARI 2011-01-06 13:06:05 UTC
I think a new guideline for packaging xulrunner apps should be created with this workaround in it.

Comment 30 Hicham HAOUARI 2011-01-07 16:45:53 UTC
@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 17:00:51 UTC
@Martin :

The changes you have done resulted in firefox being noarch too.

Comment 32 Hicham HAOUARI 2011-01-07 17:11:59 UTC
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 08:34:10 UTC
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.