Description of problem:
uname -i is used on postin snippet to set the runtime default config file.
But the command output armv7l on armhfp and so the default symlink is not set.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. yum re-install mock shows on armhfp machine
warning: %post(mock-1.1.35-1.fc20.noarch) scriptlet failed, exit status 254
Non-fatal POSTIN scriptlet failure in rpm package mock-1.1.35-1.fc20.noarch
$ uname -a :
Linux localhost 3.11.6-301.fc20.armv7hl #1 SMP Mon Oct 21 23:13:51 UTC 2013 armv7l armv7l armv7l GNU/Linux
I don't know how to detect between arm/armhfp and armv6hl (for the pidora).
Do we need a symlink from the armhfp config to an armv7l config?
Denis might know better the details on this.
Hopefully there is a solution that would still work when using third part architecture (such as armv6hl if the related cfg files are provided).
(In reply to Clark Williams from comment #1)
> Do we need a symlink from the armhfp config to an armv7l config?
How do you deal with all the other ARM architectures? Having a quick look at the %post script I don't see where it's archful but presumably from the comment above it's trying to link the default config to the native arch.
The issue we have is that there's armv4t, armv5tel (and other v5 variants), armv6l armv6hl (in other v6 variants), armv7l etc etc and even aarach64 HW will happily run an ARMv7 userspace. The supported armv7hl is generally what we'd see but it's not to say it's the only option.
The armhfp isn't actually an architecture designator so shouldn't really ever be used in this context.
To the end, how to fix this bug ?
Do we need some mapping to circumvent this issue ? (armv7l -> armhfp) how about aarch64 ?
gcc -dumpmachine is probably an accurate way to discover the host userspace, but this will trigger a dependency on gcc which isn't needed yet. Anything better from the current set of mock dependencies ?
replace the call to uname -i with
python -c "import rpmUtils.arch; baseArch = rpmUtils.arch.getBaseArch(\"$(uname -i)\"); print baseArch"
the issue you have is that uname -i may not match the yum base arch as you want the yum basearch the best way to get it is to ask yum.
(In reply to Dennis Gilmore from comment #5)
> replace the call to uname -i with
> python -c "import rpmUtils.arch; baseArch =
> rpmUtils.arch.getBaseArch(\"$(uname -i)\"); print baseArch"
it's output arm on armv7hl, so I don't know how it would solve the problem, unless it means moving back the mock config files from *armhfp.cfg to *arm.cfg namespace which would clash with previous arm softfp. (that been said, thoses arches are currently unsupported in recent fedora).
One last question, how to predict the kernel RPM package target_cpu on arm from userspace ? As that's armv7hl but uname reports armv7l.
[dennis@wandboard01 ~]$ uname -a
Linux wandboard01.ausil.us 3.15.0-0.rc5.git2.9.fc21.armv7hl #1 SMP Thu May 15 19:48:16 UTC 2014 armv7l armv7l armv7l GNU/Linux
[dennis@wandboard01 ~]$ python -c "import rpmUtils.arch; baseArch = rpmUtils.arch.getBaseArch(); print baseArch"
drop the uname -i from the call and it gives us the right info
This also fails on the Spacewalk koji:
For sure, the arm-specific issue described here should be fixed, but even once that's done, I don't think the %post scriptlet should exit with a non-zero return code.
How about this instead:
-[ -e /etc/mock/$cfg ] || exit -2
-ln -s -f $cfg /etc/mock/default.cfg
+cfg=fedora-$ver-$(python -c "import rpmUtils.arch; baseArch = rpmUtils.arch.getBaseArch(\"$(uname -i)\"); print baseArch").cfg
+[ -e /etc/mock/$cfg ] && ln -s -f $cfg /etc/mock/default.cfg
Another possibility is to create the symlink and include in packaging at build time, instead of %post. Then inconsistencies would be caught at build-time instead of during the install.
This means making the package that owns the symlink be arch'd though (mock is currently noarch).
Could we somehow prioritize the BZ?
This issue causes Spacewalk fc19 and fc20 builds to fail:
Fixed in commit c33350d in msuchy-work branch.
Fixed in mock-1.2.0, which just landed in rawhide.