Re: Packages-arch-specific for armhf
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 ?
(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