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.
thanks
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
Requeued.
thanks
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:
<mailto:debian-wb-team@lists.debian.org>
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.
Cheers,
Reply to: