Hello world, You should probably read all of this message, or at least skim the first sentence of each paragraph to make sure you don't miss anything. Oh, and if it's not the 11th yet where you are, obviously you shouldn't read this message. So, presumably everyone who's reading this has already seen the previous message, which indicated the security infrastructure work we were waiting on is getting close to done. For those of you who hadn't, consider yourself updated. First, I should emphasise that security stuff is *not* yet finished. That most of the remaining work should be bug fixes and a matter of installing previously tested software on different machines doesn't mean there's no work left to be done. We're not going to be releasing in the next few hours. We're also not entirely done developing woody. In the previous update, I indicated that I thought woody was ready to be released. We're now in the fairly fortunate position of being able to review any problems that have come up with woody in the month after I made that statement and see how accurate, or not, it was. So, the easiest first step in such a review is to see what changes have actually been made to woody since May 1. They are: * a new boot-floppies upload (3.0.23-2002-05-21), particularly for sparc (which couldn't produce bootable CDs with previous b-f builds), and ia64 (which needed a new kernel version) * removed packages: (mostly stuff that was requested to be removed from unstable that isn't depended on by anything in woody) atm chess kernel-image-2.2.20-udma100-ext3-i386 [zlib bug] kernel-source-2.4.12 kernel-source-2.4.13 libpgsql libticables2 libticalcs2 linkchecker-ssl mkinitrd-cd mmix-src [broken, 145534] modules-scyld-source-0.0 tom wmspaceweather [147284] xshogi * binary-only updates to packages on particular architectures to bring them in sync: cl-imho/ia64 clanbomber/mipsel clanlib0/mips,mipsel dossizola/arm effectv/ia64 eglade/hppa electricsheep/m68k fakeroot/mipsel flightgear/mips,mipsel ginac/m68k kernel-patch-2.4.17-mips/mips,mipsel libqt3-psql/arm lsh-utils/ia64 lvm-common/arm,hppa,ia64,m68k,mips,s390 mm/hppa mpqc/m68k mrproject/arm muse/arm,hppa netsaint-plugins/arm netsaint-plugins/arm openafs-krb5/ia64 palo/arm r-base/mips raidtools/mips scribe/m68k star/alpha * updated packages (source and binaries across all applicable architectures): abiword [various minor bugs, update to be > version 1.00] apache [security issues] arch [security issues] base-config [looping problem] bind9 [9.2.1-1 CERT] brltty [broken init script] cweb [145534] dhcp3 [security, 3.0.1rc9-1 CERT CA-2002-12] dns-browse [security, 147654] dpkg [enable force-overwrite by default] ecartis [security, argv buffer overflow, bugtraq, 147064] eterm [security, 0.9.2-0pre2002042903 bug# 141374] ethereal [security, 0.9.4-1 ethereal advisory enpa-sa-00004] evolution [security, 1.0.3-3 bug# 145903] gaim [security, 0.57 buffer overflow in TOC protocol plugin] gal [needed by evolution] gdk-pixbuf [needed by gaim and evolution] glibc [nscd security issue] libnss-lwres [crypto-in-main] lukemftp [security, 1.5-7 bug# 146148] lvm10 [new lvm systems] lvm10 [twice! "downgrade" from 1.1 to 1.0] mnogosearch [security, 3.1.19-3 bug# 146720] mutt [crypto-in-main, 145770] orbit [needed by abiword] psycopg [crypto-in-main] qpopper [security, 4.0.4-2 bug# 144974] rblcheck [145769] snoopy [147169] squirrelmail [security, 1:1.2.6-1 bug# 144496] trafstats [security, 0.4.19-4 bug# 145361] webmin [security, 0.94-5 buffer overflow 147599] A few of these are real problems: the problem with the sparc boot-floppies and dpkg are relatively serious issues for release and weren't discovered, let alone fixed, until after May. Likewise, the lvm and base-config problems aren't really things we would have liked to have had to deal with after commiting to a release. There're also a handful of belated crypto-in-main related changes, that should've (and in most cases could've) been accepted into woody before May 1. Of the remainder, there are four or five packages that've been updated or removed at the request of the maintainer that we could've lived with pretty easily as they were, and a whole host of security updates, that we generally have to live with maintaining post release anyway. As far as this goes, it seems fairly reasonable so far. Woody is certainly a long way off perfect, but it seems to be standing up fairly well, after a month's scrutiny. So. From this point on, security updates should be done entirely through the security team. They (via the new security software) will make uploads both to security.debian.org and to the appropriate proposed-updates directory. If you have a security problem in your package, make sure they're informed about it. They'll give you any further instructions about exactly what they'd like you to do from there. Security updates processed before release will be included in the release. Otherwise, over the next week or so, I'd like to encourage people to do their own poking around at woody to see if my opinion strikes you as accurate. Are there any major issues that desperately need to be addressed before we release? If you find some, you should do the following: * Discuss it with some other developers to make sure you're not freaking out over nothing. We've got 15,000 open bugs that'll all make some of our users (or some of us) miserable one way or another, and we simply can't do anything about the vast majority of them for woody. Is the problem you found particularly special, or is it just something we need to fix before th enext release? * Make sure it's fixable. If there's no bug report filed, file one, and include a full explanation. If there's no patch in the bug report, work out what the problem is and fix it. If it hasn't been fixed in unstable yet, contact the maintainer and make sure it is fixed in unstable. Do an NMU if the maintainer's not able to fix it. * Send an email to me pointing to the bug report and making sure it's clear why this problem needs to be fixed in woody. There's a special email address for this, viz: ajt-woody-sucks@debian.org which should get you a much better response than such mails to me have been getting over the past month. Be clear, and concise, but include all the details. You may wish to begin your emails "Woody sucks because...". Once you've done that, you should get a reply indicating whether it really is worth fixing, or not. * If it is worth fixing, you'll then need to prepare a "backport" to testing. This means preparing a new version of the package with a different version number (it needs to be a lower version number than the package in unstable to ensure upgrades behave sensibly) and uploading it to "testing" instead of "unstable" (or "frozen" or "woody-proposed-updates"). Presuming we're stay in good shape for a week or so, and can solve any problems that're found, we'll be looking to release shortly after that. In the meantime, since we have woody-proposed-updates operational, and won't be accepting further promotion of packages from unstable to testing, there's no need to be particularly wary about uploading new stuff to unstable. So, have at it. Cheers, aj (woody release manager) -- Anthony Towns <ajt@debian.org>
Attachment:
pgppGx0XrghVn.pgp
Description: PGP signature