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

Re: requeue requests for sys/ucontext.h namespace polloution

Note: i'm not trimming the quotes so that people who are not monitoring armel@buildd.debian.org can see the context

Hector Oron wrote:
Hello Peter,

2011/12/26 peter green <plugwash@p10link.net>:
As recently discussed on debian-arm and other mailing lists a namespace
polloution issue that was causing a number of build failures has just been
fixed. The fix was uploaded to debian in libc6-dev 2.13-24. Now that things
are fixed on the libc6-dev side affected package need to be requeued

Thanks for taking care.
Please ensure the build chroots on all the armel and armhf buildds have
libc6-dev 2.13-24 installed* and then perform the following requeues.

Upgrade done.
gb . simulavr_0.1.2.2-6.2 . armel armhf
gb . plan_1.10.1-2 . armhf
gb . node_0.3.2-7.1 . armhf
gb . wordgrinder_0.3.3-1 . armhf
gb . predict_2.2.3-3.1 . armel armhf
gb . ratbox-services_1.2.4-1 . armhf

P.S. For future reference are the armel and armhf buildd maintainers the
same people? (that is should I send requests like this to both addresses or
just one of them?)

Slightly different people, but in future it could change, so I would
say yes, please send email to both.
Note that armhf@buildd.debian.org currently seems to bounce

<armhf@buildd.debian.org>: host
   grieg.debian.org[2001:648:2ffc:deb:214:22ff:fe74:1fa] said: 550 Unrouteable
   address (in reply to RCPT TO command)

Note you can also send this kind of requests to:
My understanding is that list reaches a group with the access to requeue packages
but not nessacerally with the ability to update chroots.
PS.- Regarding your useful notes it might be helpful to send out to
wider audience in the mailing list or create a bug report, if it does
not exist yet.
I have cc'd debian-arm and I repeat the notes below in case any porters are interested.

1: most of the above give backs are armhf only because their armel binaries were built sucessfully before signal.h started including sys/ucontext.h. 2:these are not the only packages that were hit by this issue, some (I don't have a list to hand but I belive it's at least three packages and there are probabbly others i'm not aware of) were fixed on the application side and one package (screader) has other issues that prevents it from building even when this bug is fixed. 3: I discovered that eresi still fails on arm* with a redefinion of struct user_regs and struct user_fpregs (and it has other major build problems too). It appears it includes sys/user.h directly (not via sys/ucontext.h).

I already informed the screader guys (by closing a bug) that with the fixed libc their package failed on armel in the same way it fails everywhere else. I've just posted a note to the eresi FTBFS on armel bug report that their issues with arm architectures are not solved by the libc change but frankly their package seems to be rotting anyway(they have an i386 build failure from september still outstanding!). I do not intend to find and contact developers who have already fixed the issue on the application side firstly because I don't have a list of them (I could figure out a couple from my mail archives but I suspect that many packages have quietly fixed this as soon as they saw the build failures), secondly because it's difficult to tell for sure whether their patches are no-longer required or not other than by removing the patch and doing a test build. Finally I do not know if other distros have shipped affected versions of glibc in their stable releases.

Reply to: