[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 ?

 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


Reply to: