Description of problem: When installing packages available for both armv7hl (built for VFPv3 D16 FPU) and armv7hnl (built for NEON) on a Tegra 2 system (which only has VFPv3 D16, and no NEON), dnf tries to select armv7hnl variant. After manual installation specifying the correct sub-architecture, dnf distro-sync tries to reinstall armv7hnl variant instead of armv7hf. Version-Release number of selected component (if applicable): [root@localhost ~]# dnf --version 1.1.9 Installed: dnf-0:1.1.9-2.fc24.noarch at 2016-06-14 16:39 Built : Fedora Project at 2016-05-24 15:43 Installed: rpm-0:4.13.0-0.rc1.27.fc24.armv7hl at 2016-06-14 16:38 Built : Fedora Project at 2016-04-25 13:53 How reproducible: Always (at least with ffmpeg-libs from rpmfusion-free) Steps to Reproduce: 1. Run Fedora on a no-NEON ARMv7 system, e.g. NVidia Tegra 2 based (I use Toshiba AC100) 2. Try to install a package which is available for both armv7hl and armv7hnl (e.g. ffmpeg-libs from rpmfusion-free) Actual results: dnf offers armv7hnl variant Expected results: dnf should offer armv7hl variant Additional info: [root@localhost ~]# cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 0 (v7l) BogoMIPS : 2.00 Features : half thumb fastmult vfp edsp thumbee vfpv3 vfpv3d16 tls CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x1 CPU part : 0xc09 CPU revision : 0 processor : 1 model name : ARMv7 Processor rev 0 (v7l) BogoMIPS : 2.00 Features : half thumb fastmult vfp edsp thumbee vfpv3 vfpv3d16 tls CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x1 CPU part : 0xc09 CPU revision : 0 Hardware : NVIDIA Tegra SoC (Flattened Device Tree) Revision : 0000 Serial : 0000000000000000 [root@localhost ~]# rpm --showrc | grep arm build arch : armv7hl compatible build archs: armv7hl armv6hl noarch install arch : armv7hl compatible archs : armv7hl armv6hl noarch optflags : -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -14: __cc armv7hl-redhat-linux-gnueabi-gcc -14: __cpp armv7hl-redhat-linux-gnueabi-gcc -E -14: __cxx armv7hl-redhat-linux-gnueabi-g++ gpg --no-verbose --no-armor -14: __isa_name armv7hl -14: _arch arm -14: _build_arch arm -14: _host armv7hl-redhat-linux-gnueabi -14: _host_alias armv7hl-redhat-linux-gnueabi%{nil} -14: _host_cpu armv7hl -11: _target armv7hl-linux -11= _target_cpu armv7hl -14: arm armv3l armv4b armv4l armv4tl armv5tel armv5tejl armv6l armv6hl armv7l armv7hl armv7hnl -11: optflags -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 [root@localhost ~]# dnf distro-sync Last metadata expiration check: 1:19:23 ago on Thu Aug 18 20:28:08 2016. Dependencies resolved. ============================================================================================================================== Package Arch Version Repository Size ============================================================================================================================== Reinstalling: ffmpeg-libs armv7hnl 3.0.2-4.fc24 rpmfusion-free-updates 5.1 M x264-libs armv7hnl 0.148-7.20160614gita5e06b9.fc24 rpmfusion-free 485 k x265-libs armv7hnl 1.9-1.fc24 rpmfusion-free 301 k Transaction Summary ============================================================================================================================== Total download size: 5.8 M Is this ok [y/N]:
Please run dnf distro-sync with --debugsolver and upload it.
Created attachment 1192907 [details] Results of dnf --debugsolver distro-sync
> system armv7hnl rpm @System that's actually why.
https://github.com/rpm-software-management/hawkey/blob/d61bf52871fcc8e41c92921c8cd92abaa4dfaed5/src/util.c#L116-L154
Is there any way to set that to the correct value? Reading docs on dnf configuration didn't reveal much, so I thought it should get autodetected via /proc/cmdline (which doesn't seem to work here).
Sorry, I meant /proc/cpuinfo above. Looking at the code snippet you've linked above Igor, my machine should be detected as armv7hl as /proc/cpuinfo doesn't include any instances of "neon" (thus ARM_NEON should not be set in flags on line 53). I believe RPM itself also detects the architecture correctly as armv7hl (as evidenced by rpm --showrc in the original post, if I interpret it correctly) - can the problem lie within dnf and/or libsolv specifically?
(In reply to Alexey Charkov from comment #6) > Sorry, I meant /proc/cpuinfo above. Looking at the code snippet you've > linked above Igor, my machine should be detected as armv7hl as /proc/cpuinfo > doesn't include any instances of "neon" (thus ARM_NEON should not be set in > flags on line 53). > > I believe RPM itself also detects the architecture correctly as armv7hl (as > evidenced by rpm --showrc in the original post, if I interpret it correctly) > - can the problem lie within dnf and/or libsolv specifically? can you paste `cat /proc/cpuinfo`? Actually that function defines your arch and passes then to DNF/libsolv.
Igor, that's already pasted in the original bug description above, along with an abstract from rpm --showrc. Please let me know if there's any other info that could help (happy to single-step through the code in gdb or whatever, if helpful - but would appreciate pointers on where to look).
#include <stdlib.h> #include <stdio.h> #include <hawkey/util.h> static inline void cleanup_free (void *p) { void **pp = (void **)p; if (*pp) free (*pp); } int main (void) { __attribute__((__cleanup__(cleanup_free))) char *arch = NULL; if (hy_detect_arch (&arch)) return EXIT_FAILURE; printf ("%s\n", arch); return EXIT_SUCCESS; } # dnf --enablerepo=fedora-debuginfo --enablerepo=updates-debuginfo install hawkey-debuginfo glibc-debuginfo $ gcc -Wall -Wextra -Werror -g `pkg-config --cflags --libs hawkey` arch.c $ gdb ./a.out -ex "b hy_detect_arch" -ex "run" and would be nice if you will examine what's going on there.
Bingo. flags & (ARM_NEON | ARM_VFP3) is true whenever either of ARM_NEON or ARM_VFP3 bits is set (or both). Should instead be as follows: (flags & ARM_NEON) && (flags & ARM_VFP3) What would be the easiest way to test and confirm the fix on a non-devel system? Sorry I'm relatively new to Fedora - coming from Gentoo world where one can't really have a non-devel system :)
(In reply to Alexey Charkov from comment #10) > Bingo. > > flags & (ARM_NEON | ARM_VFP3) is true whenever either of ARM_NEON or > ARM_VFP3 bits is set (or both). Should instead be as follows: > > (flags & ARM_NEON) && (flags & ARM_VFP3) > > What would be the easiest way to test and confirm the fix on a non-devel > system? Sorry I'm relatively new to Fedora - coming from Gentoo world where > one can't really have a non-devel system :) From RPM's code: if (rstreq(un.machine, "armv7l")) { if (rpmat.hwcap & HWCAP_ARM_VFPv3) { if (rpmat.hwcap & HWCAP_ARM_NEON) strcpy(un.machine, "armv7hnl"); else strcpy(un.machine, "armv7hl"); } } There are 2 solutions: * just fix that expression * get arch from RPM 2nd one looks better solution.
hawkey-0.6.3-5.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-8b21e1bd2d
hawkey-0.6.3-5.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-035cf56746
I confirm that with hawkey-0.6.3-5.fc24 from Koji I'm now correctly getting armv7hf variant for the packages in question. Thanks a lot for such a quick turnaround!
hawkey-0.6.3-5.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-035cf56746
hawkey-0.6.3-5.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8b21e1bd2d
hawkey-0.6.3-5.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
hawkey-0.6.3-5.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.