Bug 1461288 - ppc64le architecture called powerpc64le
ppc64le architecture called powerpc64le
Status: NEW
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
27
Unspecified Unspecified
high Severity low
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-14 03:01 EDT by Igor Gnatenko
Modified: 2017-08-15 04:22 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
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 Igor Gnatenko 2017-06-14 03:01:40 EDT
This breaks rust builds, because architecture is named ppc64le and we have it in ExclusiveArch. So changing name (it's like this on copr.fedorainfracloud.org) breaks our builds.
Comment 1 clime 2017-06-14 03:06:34 EDT
Filled https://pagure.io/fedora-infrastructure/issue/6111.
Comment 2 Igor Gnatenko 2017-06-14 03:45:19 EDT
That sounds like a bug in autoconf (or we need special patch for Fedora)....

config.status which is generated using autoconf contains:
...
S["target_alias"]=""
S["host_alias"]="ppc64le-redhat-linux-gnu"
S["build_alias"]="ppc64le-redhat-linux-gnu"
...
host_alias='ppc64le-redhat-linux-gnu'
host='powerpc64le-redhat-linux-gnu'
host_os='linux'
build_alias='ppc64le-redhat-linux-gnu'
build='powerpc64le-redhat-linux-gnu'
build_os='linux-gnu'
...
S["host_os"]="linux"
S["host_vendor"]="redhat"
S["host_cpu"]="powerpc64le"
S["host"]="powerpc64le-redhat-linux-gnu"
S["build_os"]="linux-gnu"
S["build_vendor"]="redhat"
S["build_cpu"]="powerpc64le"
S["build"]="powerpc64le-redhat-linux-gnu"


So either RPM should somehow replace powerpc with ppc or autoconf should put ppc64le instead... I think autoconf does its job right, but RPM should do replacement.
Comment 3 Pavel Raiskup 2017-06-14 05:46:56 EDT
I fail to understand what's the problem.  Is this because fedora rawhide has
outdated config.guess in redhat-rpm-config?
Comment 4 Igor Gnatenko 2017-06-14 05:50:41 EDT
(In reply to Pavel Raiskup from comment #3)
> I fail to understand what's the problem.  Is this because fedora rawhide has
> outdated config.guess in redhat-rpm-config?

Problem is that rpm on ppc64le thinks that _host_cpu is powerpc64le rather than ppc64le and when you have ExclusiveArch: ppc64, COPR fails to build package because architecture is not included.

I'm not sure why it is happening, just noted that macros is generated out of config.status and that one has powerpc64le rather than ppc64le.
Comment 5 Pavel Raiskup 2017-06-14 07:14:14 EDT
Btw. the _host_cpu is baked into rpm during build of rpm, and that info is
taken from config.status, which comes from 'gnuconfig' upstream.
I checked some quite old fc22 build of rpm and the %_host_cpu was also set
to powerpc64le.

The %_target_cpu is however by default set in mock configuration, from
config['target_arch'] by default.
Comment 6 Pavel Raiskup 2017-06-14 07:15:03 EDT
I meant s/config.status/config.guess/ of course.
Comment 7 Jan Kratochvil 2017-06-14 08:04:54 EDT
autoconf is calling it all powerpc*-* so that ppc64* is done by rpm.
So I believe it is up to rpm to fix that.
Comment 8 Pavel Raiskup 2017-06-14 09:24:10 EDT
Hms, rather than doing some substitutions on rpm side I guess we should invent
something like %power64le macro to respect gnuconfig opinion about the naming;
if that was the issue in the end.

Anyways, after discussing this with Igor, turns out this is related to
bootstrapping chroot (new feature of mock), where Igor has overwriten rpm
package.  So sounds like NOTABUG at this point.

By default, mock respects the 'target_arch' config option, so that the rpmbuild
is run like 'rpmbuild --target ppc64le' which in the end overrides the default
%_target_cpu macro contents (rpm compares ExclusiveArch contents against
%_target_cpu).
Comment 9 Jan Kurik 2017-08-15 04:22:23 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

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