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

Re: [buildd-tools-devel] Bug#580136: schroot personality build fails on armel

Could the Debian ARM list/porters possibly comment upon this
bug?  Please could you keep buildd-tools-devel and the bug
in the CC on any reply.  Thanks.

It's not clear to me why this bug has suddenly appeared, and
only on armel.  There seem to be a few possibilities:

1) schroot is using personality(2) incorrectly, but this is
   only causing breakage on armel because only armel sets
   some of the high bits outside the range of PER_MASK
2) there's an armel-specific bug in the glibc personality
   wrapper and/or headers
3) there's an armel-specific bug in the kernel and/or its

Presumably any armel-specific bug would be a failure to
mask out the high bits with PER_MASK when passing back
the return value of personality(2) to userspace.  This is
assuming that the user is not required to mask it out by
hand, but if this is required, it's not a documented part
of the interface.

Many thanks,

On Mon, May 03, 2010 at 10:20:02PM +0100, Roger Leigh wrote:
> On 03/05/2010 21:01, Riku Voipio wrote:
>> Package: schroot
>> Severity: serious
>> Version: 1.4.2-1
>> schroot FTBFS's on armel due to:
>> 1) test: test_personality::test_construction (F) line: 51 ../../../test/sbuild-personality.cc
>> assertion failed
>> - Expression: p1.get_name() == "linux" || p1.get_name() == "linux_32bit" || p1.get_name() == "linux32"
>> A quick test on few machines seems to say that:
>> personality(0xffffffff) returns 0xC00000 on armel.
> Looking at the linux include/linux/personality.h, maybe we need to use  
> PER_MASK to mask out the high bits.  0xC00000 would imply
> where 0xC00000 & PER_MASK = PER_LINUX
> However, the documentation does not mention the need for masking, and  
> the personality macro in the header implies that the high bits are not  
> part of the visible personality interface since since they are masked 
> out.
> Is it possible the glibc headers and/or syscall wrapper are buggy here,  
> or the armel-specific kernel code?  Alternatively, is armel the only  
> system to set some of the high bits and this is the first time we've  
> tripped up on this?
> I'll check the glibc header next.  Some input from a kernel person would  
> help here, given the rather sparse documentation!

  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Attachment: signature.asc
Description: Digital signature

Reply to: