Red Hat Bugzilla – Bug 508211
mock fail to build i386 package on x86_64 platform
Last modified: 2013-01-10 00:16:25 EST
Created attachment 349513 [details] root.log Description of problem: The mock fail to build i386 packages on x86_64 platform with this error. /var/tmp/rpm-tmp.96898: line 6: cat: command not found /var/tmp/rpm-tmp.96898: line 7: rm: command not found /var/tmp/rpm-tmp.96898: line 22: install: command not found /var/tmp/rpm-tmp.96898: line 25: install: command not found error: %post(pam-0.99.6.2-4.el5.i386) scriptlet failed, exit status 127 But kojibuilders on fedoraproject.org can build successfully. http://koji.fedoraproject.org/koji/buildinfo?buildID=111692 Is is rpm/yum problem that are installed in between kojibuilders and others ? Version-Release number of selected component (if applicable): mock-0.9.14-1.el5 How reproducible: 100% Steps to Reproduce: 1. mock -r epel-5-i386 amarok-1.4.10-5.20090624svn.el5.src.rpm 2. 3. Actual results: see attached log file. Expected results: http://kojipkgs.fedoraproject.org/packages/amarok/1.4.10/5.20090624svn.el5/data/logs/i386/root.log Additional info:
Verified to fail 100% exactly as described above. The commands 'cat', 'rm', and 'install' are all provided by the coreutils package. Just looking at the data, it would appear that pam is at fault... and I had assumed that pam had a regular 'Requires: coreutils' rather than Prereq: coreutils. However, looking at the spec for version pam-0.99.6.2-4.el5.i386 it is infact Prereq: coreutils. Looking at it further, in a Mock environment it looks like this might be more of a $PATH/environment thing. The commands in pam's %post are _not_ being called with absolute path, therefore if the commands didn't exist in $PATH before coreutils was installed (during the same yum process) then calling 'rm', 'cat', 'install' would fail unless called via absolute path '/bin/rm', '/bin/cat', '/usr/bin/install'... So either mock can be hacked up to install coreutils first (which is a prereq for a lot if not almost all packages) or this bug can become a pam bug and not mock. The problem I see however is that coreutils also Requires: pam. So on that note, it might also be a Yum ordering issue (coreutils in fact not being installed before pam tries to call it's commands in %post). I don't have an EL5 i386 box available to rebuild the pam packages at the moment, but once I do I'll try my theory out.
Created attachment 351358 [details] Patch to possibly resolve pam/coreutils issue in Mock
I've tested the suggested changes as applied by the attached patch [using absolute paths], and am able to build i386 packages on a x86_64 host without receiving the PAM errors as outlined above. I suggest making this a pam/rhel5 bug and poking redhat... maybe not too late to get into EL5.4. p.s. I tried to use the patch I attached... and it failed for some reason... therefore you will likely just need to apply the changes rather than using the patch.
Thank you for comment and patch. But, how about simply adding Requires(post): mktemp, sed, coreutils, /sbin/ldconfig to pam.spec ? Fedora has changed it long time ago. http://cvs.fedoraproject.org/viewvc/rpms/pam/devel/pam.spec?r1=1.139&r2=1.140 I found that this bug also happens on i386 platform. Now I can build only x86_64 package on x86_64 platform.
Chikama, pam in EL5 already requires coreutils, that's why it works when using absolute paths. I think that using absolute paths in the pam spec is a band aid solution that should not be implemented. From a conceptual standpoint pam does the right thing and requires the package providing the things needed. Instead I think we should look at what actually happens to the PATH and possibly look into fixing this in yum/rpm-space. Inside the install transaction, when coreutils gets installed, it's binaries placed in standard directories should be available to subsequent %post scripts without absolute path. What part of the mock execution chain should be responsible for making that happening? Why does this function differently when building for i386 on x86_64 than with the x86_64 target?
I have managed to reproduce this issue with only yum. It seems to be a dependency resolution order issue triggered by the specific state of the centos5 i386 base + updates trees at this point in time. The yum issue is described in Bug 521414 and I think it would be correct to mark this issue as a duplicate of that one.
Some further investigation indicates that this is a problem in rpm. Bug 521769 has more details.
I have now written a one line patch to rpm in Bug 521769 that I think is the correct solution. With a patched version of rpm I have successfully built a bunch of i386 packages on my x86_64 centos 5 box. Feel free to test it, on your own risk :)
So do we need to change the component here to rpm (it doesnt' seem like a mock bug)?
changing to rpm
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12'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 12 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
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.