Loïc Minier <l...@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 -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwirgzqi....@lebrac.rtp-net.org
