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 testing. 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 binaries? > 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 possibility. > 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