why Debian sarge won't release today

A clone of the "BattleIsle 2/3" game called asc crashes on the alpha architecture. Unlike all the other other games in Debian that fail in some way on some obscure architecture (like my package of kobodeluxe), this asc crash is some some reason considered release critical and reason to delay the release, or remove the game entirely.

Some templating engine called cheetah that I've certianly never heard of before turns out to have a boneheaded security hole. There's some holdup getting the fix into sarge that I don't understand.

A second templating engine that I've never heard over either, called clearsilver (also written in python like cheetah, because TMTOWTDI, or something), fails to build from source in sarge because someone tried to write their own patch management system instead of using something standard and screwed up. A fix will reach sarge tomorrow. Hurrah.

gcompris, an "Educational games for small children," is missing a dependency on something obvious. It's taken since 19 May to get the fix for this from unstable into testing for reasons that are too boring to mention.

Ximain connector doesn't work with Microsoft Exchange 2003. I cry a single tear.

A fun new security hole was recently found in gdb, the kernel, and lots of other stuff that lets malformed ELF executables crash these programs. Of course if we'd released sarge the day before, we'd be issuing DSAs instead of waiting and hey, sarge would be released!

Simularly, security holes in a breakout clone, the GNU TLS library, X, and openmotif. All of them have patches, none of the patches have been uploaded yet.

gdm fails to work in an obscure setup on some large network. But works for everyone else on the planet.

Yet another UI library, GLUI, has a seriously messed up debian control file, due to some kind of control.in craziness and mismanagement. It's both been fixed and is planned to be removed, but neither has hit sarge yet.

Our initrd-tools package was updated quite a lot at the last minute; one of those changes intended to make it work better on ultra-obscure powerpc subarchitectures which only kids at Easter Seals have heard about, like the pegasos, but instead planted a mine that will blow up in our faces if the package is ever actually built on the powerpc architecture. DamnIfIKnow why we had to do this before sarge released.

A bunch of bugs were filed on old kernel patches that don't apply to current kernels in sarge. Likely most of these will be removed, OTOH, why worry about this now and not sometime in the past 6 months that we've been using the same old kernels in sarge? Well, because we seeme to be near to release and someone's pet peeve popped up.

Various other kernel security holes and hangs that are for some reason listed as worth delaying the release over, even though dozens of others are not. Hey, you want another kernel hang bug, I can certianly find hardware that will oblige.

hppa64. sun4m. 80386. These cutting-edge, mission-critical computer subarchitectures all have upgrade issues and it's imperative we delay the sarge release until we either make it really easy for all 1.5 users of each to upgrade, or until cosmic rays destroy all remaining instances of these machines.

samba's smbclient is high quality software that cannot cope with directories containing 27 or more entries.

logrotate fails if /tmp is mounted with the useless noexec flag.

Something called The WBXML Library crashes on (unspecified) input XML.

A circuit simulator called oregano uses the still highly in flux cario library and so has stopped working.

tex runs out of "capacity" on someone's system.

People are utter idiots when it comes to software licenses.

slapd sucks asteroids through soda straws.

syslogd is subject to a race with new kernels and glibc, which makes it hang. Which loses, badly. Thank you 2.6, thank you NPTL. Thank goodness for smarter heads than mine.