Bug 1033786 - mock post install fails on armhfp
Summary: mock post install fails on armhfp
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Suchý
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
 
Reported: 2013-11-22 22:23 UTC by Nicolas Chauvet (kwizart)
Modified: 2014-10-12 21:18 UTC (History)
9 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2014-10-12 21:18:19 UTC


Attachments (Terms of Use)

Description Nicolas Chauvet (kwizart) 2013-11-22 22:23:12 UTC
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):
mock-1.1.35-1.fc20.noarch

How reproducible:
always

Steps to Reproduce:
1. yum re-install mock shows on armhfp machine
2.
3.

Actual results:
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

Expected results:
Clean update

Additional info:
$ 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).

Comment 1 Clark Williams 2014-01-04 16:36:48 UTC
Do we need a symlink from the armhfp config to an armv7l config?

Comment 2 Nicolas Chauvet (kwizart) 2014-01-06 09:34:13 UTC
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).

Comment 3 Peter Robinson 2014-03-10 13:22:43 UTC
(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.

Comment 4 Nicolas Chauvet (kwizart) 2014-06-02 21:16:49 UTC
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 ?

Comment 5 Dennis Gilmore 2014-06-02 22:05:05 UTC
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.

Comment 6 Nicolas Chauvet (kwizart) 2014-06-02 22:39:18 UTC
(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.

Comment 7 Dennis Gilmore 2014-06-03 02:00:33 UTC
[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"
armhfp

Comment 8 Dennis Gilmore 2014-06-03 02:01:33 UTC
drop the uname -i from the call and it gives us the right info

Comment 9 Mathieu Bridon 2014-08-25 14:59:00 UTC
This also fails on the Spacewalk koji:
http://koji.spacewalkproject.org/koji/getfile?taskID=168111&name=root.log

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:

-cfg=fedora-$ver-$(uname -i).cfg
-[ -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

Comment 10 Rex Dieter 2014-08-25 15:45:37 UTC
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).

Comment 11 Tomas Lestach 2014-08-26 14:28:21 UTC
Could we somehow prioritize the BZ?
This issue causes Spacewalk fc19 and fc20 builds to fail:
https://koji.spacewalkproject.org/koji/taskinfo?taskID=168270
https://koji.spacewalkproject.org/koji/taskinfo?taskID=168268
https://koji.spacewalkproject.org/koji/taskinfo?taskID=168266

Comment 12 Miroslav Suchý 2014-09-04 09:08:03 UTC
Fixed in commit c33350d in msuchy-work branch.

Comment 13 Miroslav Suchý 2014-10-12 21:18:19 UTC
Fixed in mock-1.2.0, which just landed in rawhide.


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