On Mon, Oct 17, 2011, Arnaud Patard wrote: > 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 ?
You're correct (I'm not sure I have all the use cases for listing architectures in control versus listing packages in P-a-s) > > * 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 ? I'd expect so, but I didn't try; I don't see what floating-pointish bits there would be in kexec, and the syscalls aren't impacted by this ABI change. Let's find out! :-) > > * 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). Makes sense, and an option I've left to the maintainer; that said I think the P-a-s entry should be removed in any case. > > * 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 ? Yup, I've done so when I thought the logs were relevant, but the rtai is 100% sure due to my hardware and the slicer one is a 404 when downloading a build-dep which seems like a debian-ports screwage that I poked Konstantinos about. > > * 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 ? Indeed, there's currently no mean to select between the two ABIs, and only ARMv4 code is generated using either VFP or no VFP and using EABI calling conventions or old ABI -- depending on which features were present on the buildd. I guess tcc should be fixed to allow selecting the ABI at runtime; I've filed a bug against tcc to track this (bug id pending) > > * 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. Makes sense to me -- Loïc Minier -- 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/20111017204324.gb22...@bee.dooz.org
