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

Re: testing security blockers

On Thu, Aug 11, 2005 at 04:32:57PM -0400, Joey Hess wrote:
> Long time no report, so here I am again with some analysis of what's
> holding 101 security fixes out of testing. The executive summary:
> Unsuprisingly, glibc is causing a lot of blockage right now, but
> suprisingly the other ongoing transitions are not causing many problems.
> ICEs, hppa borkage, s390 needs-requeue, and some mising uploads for arm
> are also common. Several fixes have been blocked for a month or more.

> asterisk
> 	blocked by unixodbc which is blocked by several packages that
> 	are too young to reach testing. Might get unblocked within 4
> 	days.

Eh, no it won't.  The full chain required for a unixodbc update includes both
php4 and php5; see the grep-excuses for those packages for more fun.

> centericq
> 	blocked by glibc which is 5/10 days old and needs to be hinted
> 	as it's frozen due to producing udebs

It's still being sorted out, but it seems likely that glibc is implicated in
the current hppa breakage, so I wouldn't expect this current build to hit

It's also got a problem with not restarting services on upgrade (NSS ABI
incompatibility), and nscd isn't installable on alpha.

> ekg
> 	1/2 days old, missing hppa build, blocked by glibc

So, hppa should be ignored at this point for any RC bugs that could
otherwise be fixed in testing; but the number of bugs in that state is
approximately zero until glibc 2.3.5 reaches testing anyway, and that may or
may not include a fix for hppa as well...

> krb5
> 	28 days old
> 	FTBFS on m68k due to gcc ICE, needs followup

Is this one that we should consider pushing into testing without the m68k

> net-snmp
> 	blocked by perl, which FTBFS on some arches

Also has a fresh RC bug, 322500.  I'm not completely convinced from the
description of the bug that it is an RC ABI change, but it's certainly a

> openmotif
> 	72 days old
> 	Non-free package with old buils on several arches that will not
> 	get rebuilt unless done manually.
> 	Unfortunatly removing these old builds involves removing
> 	dependent packages on those arches, unsure if it's time to think
> 	about doing that yet.

Perhaps a mail to the affected porter lists and the maintainers of the
reverse-deps would be in order first.

So, we're probably going to be sitting here for a while waiting on glibc
yet, and many of these packages have newer versions on all archs in
unstable, which makes them candidates for uploads to t-p-u.  Even hppa
should be fine for t-p-u, though we may have to get things selectively
reenabled on sarti for that.  Is it time to start doing testing NMUs for
some of the packages on this list?

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                  to set it on, and I will move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply to: