On Fri, 14 Jun 2013 16:34:27 +1000 Paul Whittaker <whitpa@velocitynet.com.au> wrote: > FYI, I have encountered a few ARM EABI (i.e. ARMEL) binaries in packages > supposedly with architecture "armhf" in the > http://www.emdebian.org/grip/ repo. For example: Both armhf and armel are EABI (as opposed to old ABI which was ARMv4, StrongARM for iPaq's et al.) > I encountered several of these in a row when installing extra stuff on a > wheezy-grip ARMHF box, and thought at first that I must be doing There is a wheezy point release this weekend, as it happens, so there is a window to fix these, however, my initial tests do not support your analysis. The 'file' utility does not discriminate between armel and armhf binaries (and therefore neither does lintian, yet). readelf does but readelf does not agree with your analysis: I unpacked deb-gview_0.2.10_armel.deb and deb-gview_0.2.10_armhf.deb $ readelf -A armel/usr/bin/deb-gview | grep Tag_CPU Tag_CPU_name: "4T" Tag_CPU_arch: v4T $ readelf -A armhf/usr/bin/deb-gview | grep Tag_CPU Tag_CPU_name: "7-A" Tag_CPU_arch: v7 Both recent builds in unstable. The equivalent packages from Grip: deb-gview_0.2.10em1_armel.deb and deb-gview_0.2.10em1_armhf.deb $ readelf -A grip-el/usr/bin/deb-gview |grep Tag_CPU Tag_CPU_name: "4T" Tag_CPU_arch: v4T $ readelf -A grip-hf/usr/bin/deb-gview |grep Tag_CPU Tag_CPU_name: "7-A" Tag_CPU_arch: v7 I then unpacked the fbset packages you described: fbset_2.1-25em1_armhf.deb $ readelf -A 25/bin/fbset |grep Tag_CPU Tag_CPU_name: "7-A" Tag_CPU_arch: v7 fbset_2.1-27em1_armhf.deb $ readelf -A 27/bin/fbset |grep Tag_CPU Tag_CPU_name: "7-A" Tag_CPU_arch: v7 There is room for more investigation here, but my initial checks do not support your conclusions. > something wrong. However, I was able to extract the debs on an ARMEL > platform and run select binaries from their contents, and they will > definitely not run under ARMHF, which is pretty conclusive. I've had to > install non-gripped versions from standard ARMHF Wheezy as a workaround. > Looks like someone used the wrong cross-compiler prefix when building > these, or something. Can we get them fixed please? Emdebian Grip packages are not cross-compiled - the compiled binaries come unchanged from Debian. It is possible that individual packages have been retained from the time when armhf was only available via ports - that should have been fixed when the packages became available from official mirrors but I might have missed some. However, I *must* have 100% reliable data before I can go hacking stuff into the stable release. It's not sufficient just to say "it didn't work on this box", I need to have a programmatic method of checking individual packages in the archive and if the output of readelf does not support detecting your problem without false positives and without false negatives, then more work needs to be done to isolate the precise issue. Rather than checking the CPU, we could also check something related to floating point: $ readelf -A grip-hf/usr/bin/deb-gview |grep Tag_FP_arch Tag_FP_arch: VFPv3-D16 $ readelf -A 25/bin/fbset |grep Tag_FP_arch Tag_FP_arch: VFPv3-D16 $ readelf -A 27/bin/fbset |grep Tag_FP_arch Tag_FP_arch: VFPv3-D16 $ readelf -A grip-el/usr/bin/deb-gview |grep Tag_FP_arch i.e. fbset_25 and fbset_27 are both declaring FP support when genuine armel binaries do not. That would indicate to me that fbset from 2.1-25em1_armhf.deb IS armhf, as is fbset from 2.1-27em1_armhf. i.e. the binaries appear correct when compared against known armel & armhf binaries. One aim with this would be to file a wishlist bug against lintian to ensure that it can use readelf reliably to determine that the correct architecture is being packaged. It already has this test (I provided the patch explicitly for Emdebian cross-building support) but it can be enhanced to use another check as well as 'file' for exactly these situations where file is insufficient. As far as cross-compilation is concerned, lintian *will* catch any cross-build failure because the 'file' output will be x86_64 or i386 *not* one of the ARM architectures. This is known to work and is still seen frequently when the build system fails to pick up the cross-compiler. It's easy to detect because any cross-compilation for Emdebian happens on i386 or amd64 (for Emdebian toolchains, exclusively amd64). I recommend that you undertake more investigation - I have no evidence of a problem at the moment and I won't be changing any of the packages until I can reliably determine the files affected. Checksums: $ sha256sum fbset_2.1-25em1_armhf.deb d596c0ac1f505c45fb1491953155c115601e4a08d7dfcd2080474ddafe0adf70 fbset_2.1-25em1_armhf.deb $ sha256sum fbset_2.1-27em1_armhf.deb 5051d76a3043bdd3d2e42f97def13f256152dcce3e7aeaa0669ef175f5f9c5ef fbset_2.1-27em1_armhf.deb $ sha256sum 25/bin/fbset 65de96b9de7ddd5a9ba9a4a1bfce71d94727ddcdc453dddb5bf443f4ae435227 25/bin/fbset $ sha256sum 27/bin/fbset 111ec5928a521ac5c24fbf3d38d768fc3a088acfea4cdb38862c0be1e51d84ff 27/bin/fbset $ sha256sum deb-gview_0.2.10_armel.deb 009a779859d0b01887a30b7ea9cea4a7415a42d2a6063115cab59a2adea729e8 deb-gview_0.2.10_armel.deb $ sha256sum deb-gview_0.2.10em1_armel.deb b2406ea4f52ab92013247ef8667bb87cbcb74f9010e894d4e0bf1f97ba69b032 deb-gview_0.2.10em1_armel.deb $ sha256sum deb-gview_0.2.10em1_armhf.deb ce08cc91580b953580523a587556283bf07afa68d3b95ea922e6d3fa090c93c5 deb-gview_0.2.10em1_armhf.deb $ sha256sum deb-gview_0.2.10_armhf.deb 5ae88b416fd6562759b5222dc9f26382426832bc1f84829e83f69a4139d82169 deb-gview_0.2.10_armhf.deb -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpHBy8I5Nf5D.pgp
Description: PGP signature