Bug 211119 - rpmbuild uses wrong macros file
rpmbuild uses wrong macros file
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: rpm (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Panu Matilainen
:
: 253517 349321 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-17 11:10 EDT by Christopher McCrory
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2007-0620
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 12:28:10 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)

  None (edit)
Description Christopher McCrory 2006-10-17 11:10:55 EDT
Description of problem:
rpmbuild uses wrong macros file

Version-Release number of selected component (if applicable):
rpm-build-4.4.2-31.x86_64.rpm

How reproducible:
always

Steps to Reproduce:
1.  build or rebuild a package.spec or package.src.rpm
2.
3.
  
Actual results:
rpmbuild uses /usr/lib/rpm/macros instead of /usr/lib/rpm/x86_64-linux/macros 

Expected results:
use correct file

Additional info:

work around cp /usr/lib/rpm/x86_64-linux/macros ~/.rpmmacros
Comment 1 Paul Nasrat 2006-10-30 05:22:02 EST
What is the output of

cat /etc/rpm/platform
rpm --showrc | grep macrofiles
Comment 2 Christopher McCrory 2006-10-30 07:29:02 EST
[chrismcc@rhel5-56 ~]$ cat /etc/rpm/platform
ia32e-redhat-linux

[chrismcc@rhel5-56 ~]$ rpm -qf /etc/rpm/platform
file /etc/rpm/platform is not owned by any package

[chrismcc@rhel5-56 ~]$ rpm --showrc | grep macrofiles
macrofiles            :
/usr/lib/rpm/macros:/usr/lib/rpm/ia32e-linux/macros:/etc/rpm/macros.*:/etc/rpm/macros:/etc/rpm/ia32e-linux/macros:~/.rpmmacros

Comment 3 Christopher McCrory 2006-10-30 07:33:17 EST
[chrismcc@rhel5-56 ~]$ uname -a
Linux rhel5-56 2.6.17-1.2519.4.21.el5 #1 SMP Wed Aug 30 18:18:28 EDT 2006 x86_64
x86_64 x86_64 GNU/Linux

[chrismcc@rhel5-56 ~]$ arch
x86_64

[chrismcc@rhel5-56 ~]$ rpm -qa --qf '%{NAME}.%{ARCH}\n' | grep ^rpm
rpm.x86_64
rpm-libs.x86_64
rpm-python.x86_64
rpm-build.x86_64
rpm-devel.x86_64

Comment 5 RHEL Product and Program Management 2007-05-01 13:40:13 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 9 Panu Matilainen 2007-08-20 08:34:11 EDT
*** Bug 253517 has been marked as a duplicate of this bug. ***
Comment 12 Panu Matilainen 2007-10-24 04:15:22 EDT
*** Bug 349321 has been marked as a duplicate of this bug. ***
Comment 14 wdc 2007-10-25 12:47:41 EDT
It is our hope at MIT, that the implementation of the fix will be to modify
/etc/platform to change "ia32e" to "x86_64" rather than to do something kludgy
like creating a symbolic link.
Comment 15 wdc 2007-11-02 15:55:41 EDT
Out of band, someone clarified for me that "ia32e" is the Intel nomenclature
that is actually a synonym for x86_64, so even though it says '32' instead of
'64' that symbol is more right than wrong, and that a correction fixes up the
macros and points at /etc/ instead of /usr/etc
Comment 16 wdc 2007-11-02 16:20:56 EDT
I will note in passing, that it would have been extremely useful if the solution
as it evolved were at least described, and the reasons why its original plan for
incorporation into RHEL in June got pushed off till August.

Because Red Hat chose to just paste in boilerplate prose from pm-rhel, NOBODY
outside a select few knew what was going on.  Every customer with a stake had to
open a case, and involve additional personnel at Red Hat and their own site in a
process of establishing communication to Red Hat to describe what information
was wanted, and then to generate and digest that information.  This is not a
good use of Red Hat resources, and not a good use of customer resources.

I guess if bugzilla is only answered by Red Hat engineering, those engineers are
scarce resources that cannot be spared to provide details on the progress of
every little bug.

Perhaps when a customer calls in for more detailed status, what is learned could
be put into the bugzilla bug by the Red Hat service personnel?

Comment 17 errata-xmlrpc 2007-11-07 12:28:10 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0620.html

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