Re: Packages-arch-specific for armhf
Loïc Minier <lool@dooz.org> writes:
> Hi there
Hi,
>
> Until recent times, Debian/Ubuntu would list packages which shouldn't
> be built on this or that architecture in a file called
> Packages-arch-specific; the mirrored history of this file can be
> browsed at:
> http://anonscm.debian.org/gitweb/?p=mirror/packages-arch-specific.git
> Riku Voipio explained to me that nowadays it's less relevant as Debian
> buildds check debian/control in source packages directly
> ("Auto-not-for-us"), but it's still useful for some packages and for
> Ubuntu.
iirc, w-b is still using p-a-s but for sure, it would be better to
handle it on package debian/control side imho.
btw, I thought that p-a-s was also used to prevent a package to be built
on some arch, even if it was building on it (for instance, builds fine
but has not chance to work). Is it wrong ?
>
> I had a quick look over the entries in this file looking for packages
> where armhf should be listed along armel. Here are my notes.
>
> * debian-edu-artwork-usplash: not in Debian and usplash was removed
> from Debian/Ubuntu as well; filed a bug requesting removal of this
> entry; Debian #645629
> * gnome-ppp: listed as requiring getcontext() which isn't implemented
> on ARM and wont be, but it doesn't actually need getcontext in the
> latest sources; filed a bug requesting removal of this entry;
> Debian #645631
> * kexec-tools: built fine on armhf; filed bug against package to add
> armhf to control -- Debian #645652 -- and against P-a-s to remove the
> entry
Does it work on armhf ?
> * lcd4linux: built on all Debian architectures already and built fine
> on armhf as well; filed a bug requesting removal of this entry
> Debian #645647
> * linux-kernel-di-armel-2.6, linux-modules-di-armel-2.6: these are
> specific to d-i; there's a linux-kernel-di-armhf-2.6 in debian-ports,
> but not linux-modules-di-armhf-2.6 yet; the -armhf- packages
> probably don't need to be added to P-a-s as the packages limit the
> supported architectures via control already
iirc, doesn't exist anymore.
> * linux-wlan-ng: built fine on armhf; filed bug to update P-a-s entry
fwiw, I think that the wlan-ng driver from drivers/staging is built only
on x86.
> * nictools-pci: built fine on armhf; filed bug against package to add
> armhf to control -- Debian #645654 -- and against P-a-s to remove the
> entry
> * nikwi: built fine on armhf; filed bug against package to add
> armhf to control -- Debian #645664 -- and against P-a-s to remove the
> entry
> * gpart: would probably work on armel as the reason that it's listed in
> P-a-s is because it requires little-endian, but seems like an
> obsolete piece of software without any form of upstream; skipped
> * ocamlgsl: fails to build on armhf; filed tracking bug Debian #645669;
> TODO: needs porting
> * qcontrol: none of the devices that this package currently support
> would be able to run armhf; that said, it is meant to be updated to
> support more devices in the future and would build fine on armhf
> except for Debian #643604, so filed a bug to add support for armhf --
> Debian #645670 -- and another bug to remove the P-a-s entry
what about adding armhf only when qcontrol has a chance to work on
armhf ? (say, when a nas from qnap with armhf capable SoC will exist).
> * qcam: built fine on armhf; not clear how useful that would be, but
> it's built on armel; filed bug to update the P-a-s entry
> * rtai: failed to build in a weird way; TODO: reproduce on another host
> * slicer: TODO: I wasn't able to complete the build yet; need to retry
Have you put your build logs for both, in case someone with proper
knowledge notice something wrong in them ?
> * splay: built fine on armhf and seems useful there too; filed bug to
> update the P-a-s entry
> * tcc: experimental version built fine; filed bug to add armhf to
> Architecture list -- Debian #645673 -- and another one to update
> P-a-s entry
won't it produce armel binaries instead of armhf ?
> * valgrind: built on armhf already; also, Auto-not-for-us is preferable
> over P-a-s; filed bug to request removal of this entry;
> Debian #645639
iiuc, valgrind supports armv7 but not armhf ?
> * wvstreams: P-a-s says it requires getcontext and indeed the source
> code calls it; it has a serious bug open since February and is likely
> pending removal due to the move to KDE4 libraries, doesn't seem worth
> fixing/porting; Konstantinos says this builds fine on armhf;
> TODO: file bugs to update control / P-a-s?
getcontext() call will build but the application will fail at
runtime with a message on stderr saying that getcontext() is not
implemented, so should be better to avoid building it.
Arnaud
Reply to: