Bug 508211 - mock fail to build i386 package on x86_64 platform
mock fail to build i386 package on x86_64 platform
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
12
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Panu Matilainen
Fedora Extras Quality Assurance
ActualBug
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-26 03:33 EDT by CHIKAMA Masaki
Modified: 2013-01-10 00:16 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-05 01:47:29 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)
root.log (20.80 KB, text/plain)
2009-06-26 03:33 EDT, CHIKAMA Masaki
no flags Details
Patch to possibly resolve pam/coreutils issue in Mock (2.40 KB, patch)
2009-07-11 16:24 EDT, BJ Dierkes
no flags Details | Diff

  None (edit)
Description CHIKAMA Masaki 2009-06-26 03:33:20 EDT
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:
Comment 1 BJ Dierkes 2009-07-11 16:22:07 EDT
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.
Comment 2 BJ Dierkes 2009-07-11 16:24:03 EDT
Created attachment 351358 [details]
Patch to possibly resolve pam/coreutils issue in Mock
Comment 3 BJ Dierkes 2009-07-11 17:37:05 EDT
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.
Comment 4 CHIKAMA Masaki 2009-07-13 21:46:46 EDT
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.
Comment 5 Noa Resare 2009-09-05 06:32:00 EDT
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?
Comment 6 Noa Resare 2009-09-05 11:50:57 EDT
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.
Comment 7 Noa Resare 2009-09-08 05:44:30 EDT
Some further investigation indicates that this is a problem in rpm. Bug 521769 has more details.
Comment 8 Noa Resare 2009-09-09 14:32:49 EDT
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 :)
Comment 9 Clark Williams 2010-09-11 11:20:41 EDT
So do we need to change the component here to rpm (it doesnt' seem like a mock bug)?
Comment 10 Clark Williams 2010-10-14 23:30:11 EDT
changing to rpm
Comment 11 Bug Zapper 2010-11-04 06:57:55 EDT
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
Comment 12 Bug Zapper 2010-12-05 01:47:29 EST
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.

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