Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1033786
Summary: | mock post install fails on armhfp | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Nicolas Chauvet (kwizart) <kwizart> |
Component: | mock | Assignee: | Miroslav Suchý <msuchy> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 20 | CC: | bochecha, dennis, kwizart, mebrown, msuchy, pbrobinson, rdieter, tlestach, williams |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | mock-1.2.0 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-10-12 21:18:19 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 245418 |
Description
Nicolas Chauvet (kwizart)
2013-11-22 22:23:12 UTC
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" armhfp drop the uname -i from the call and it gives us the right info 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 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: https://koji.spacewalkproject.org/koji/taskinfo?taskID=168270 https://koji.spacewalkproject.org/koji/taskinfo?taskID=168268 https://koji.spacewalkproject.org/koji/taskinfo?taskID=168266 Fixed in commit c33350d in msuchy-work branch. Fixed in mock-1.2.0, which just landed in rawhide. |