menu.jpg  ::  Home ::  Computing ::  Downloads ::  Harley Davidson ::  Links ::  Music ::  Nonsense ::  Mail :: 

Nachdem das Release von Woody zum Schluss etwas länger als vorherzusehen war auf sich warten gelassen hat, habe ich hier 'mal die Endphase des Releases anhand von eMails aus "debian-devel-announce" und "debian-announce" dokumentiert.

Und immer im Hinterkopf behalten:

Ein neues Debian Release ist dann fertig, wenn es fertig ist.

6 Apr 2002

Subject: [2002-04-06] Release Status Update
From: Anthony Towns <>
Date: Sat, 6 Apr 2002 22:24:34 +1000
Mail-copies-to: nobody
Organisation: Lacking
User-agent: Mutt/1.3.28i

Hello again,

Over the past few weeks most of the following packages have been removed
from the upcoming release due to bugs and such [0].

    acroread           libqt3-psql             mercury
    antlr              libsnmp-ruby            msyslog
    cgiemail           lire                    orbit-mt
    chdrv              lmbench                 pfaedit
    devel-protocols    logtrend-complexalarm   popularity-contest
    dnrd               logtrend-consolidation  pptp-linux
    efingerd           logtrend-doc            qtella
    eiffelfox          logtrend-ftpagent       radiusd-freeradius
    galeon             logtrend-httpagent      rie
    galeon-beta        logtrend-linuxagent     sather
    garchiver          logtrend-mailbridge     scilab
    gnotepad+-help     logtrend-snmpagent      syslog-common
    honyaku-el         logtrend-storageserver  ttthreeparser
    ilisp              logtrend-visuapache     velocity
    infinity           logtrend-visuengine     werken.xpath
    kernel-patch-mppe  makeme                  xmix
    kvdr               masqmail                xtell
    lclint             mc-foo

These packages will get a brief chance to be reconsidered in the next few
days, but don't bet too heavily on them making it. From this point on,
packages that are still in testing that have serious, grave or critical
bugs that get removed probably won't get any second chances.

In that vein, I'm becoming increasingly confident in woody's release
readiness. So, to go out on a limb:

           Debian 3.0 (codenamed woody) will release on May 1st, 2002.

Actually, as always, it'll release when it's ready: if we find that the
software doesn't meet our expectations on April 30th, you'll find me on
the ground writhing in pain with leaves, bark and wood all over the place[1].

Disclaimers aside, the things we've got left to finish of are these:

        * Boot-floppies need to be built for sparc and alpha

        * The people preparing release notes need to finish them off

        * The people preparing CD images need to make sure they're in
          a state where they can be told "go" and come up with reliable,
          final images for all eleven architectures a few hours later

        * apache needs to have its outstanding packaging bugs fixed
        * gimp1.2 needs to be fixed on alpha, even with the new pdl
        * hppa's db2/loader problem needs to be fixed
        * gs-common's license issues need to be resolved
        * mozilla's -fPIC problem needs to be fixed

        * Uploads need to be done for the following packages whose woody
          versions have security problems:

        * A bunch of archive maintenance tasks need to be finished off
          (giving the packages listed at the start of this mail a second
          chance to get released, some further touchups with the crypto
          in main transition, etc)

All these things will be well and truly finished by the 20th (two weeks
away), and should be finished early next week.

For those of you who're working on packages that are crucial for release
but don't have the testing<->unstable buffer to protect us from bugs
you introduce (in particular CD and boot-floppies people) please be
_incredibly_ conservative in _everything_ you do. If you can't prove
beyond any _possible_ question that what you're doing won't break things
that currently work, _do not change them_. No matter how much better it
might be for how many people.

aj (woody release manager)

[0] Note: this reflects bugs in the Debian packages of this software; they
    may be Debian specific problems, or problems that've been fixed by
    the upstream authors. This caveat was brought to you by the Society
    for the Prevention of Irate Letters from Upstream Maintainers,
    and is being displayed with recycled photons.

[1] I'm going out on a limb, remember.

Anthony Towns <>
Woody Release Manager

30 Apr 2002

Subject: [2002-04-30] Release Status Update
From: Anthony Towns <>
Date: Tue, 30 Apr 2002 19:04:06 +1000
Mail-copies-to: nobody
Organisation: Lacking
User-agent: Mutt/1.3.28i

Hello world,

So, it's April 30th (for most of the planet, anyway), which probably means
folks are beginning to get mildly curious about whether woody'll actually
be ready for release tomorrow. The answer is a definite "kind-of". Which
is to say, "no".

On the upside, woody itself is ready to be released. The only outstanding
changes that need to be made are the standard security fixes that need
to be made throughout the lifetime of stable anyway.

Unfortunately, that's exactly where we've dropped the ball: the security
team presently don't have the resources to handle security advisories
for woody [0]. While there has been a plan in place for roughly a year
on how to handle this ("rbuilder", for those playing along at home),
it hasn't been successfully rolled out across more than a handful
of the architectures we wish to support, and it further doesn't seem
like trying to rush it now will be particularly effective. As such,
an alternate arrangement, involving some moderately significant changes
to the existing autobuilder system are being made, which should become
active over the next week or so.

Naturally, we will not be making the woody release until we have a viable
mechanism for making timely security updates.

On the technical side of things, the only other significant problem we're
having is that we have so far been unable to produce fully successful
builds of CD images for alpha and sparc. This is being worked on, but may
mean that sparc and alpha CD images will be unavailable at release time.

The other signficant issue that's come up is a poor sense of timing on
behalf of a fair number of people. To take two fairly straightforward
examples: a few days before the expected release is not the time to file
eighty or ninety release-critical bugs about issues that have been being
tracked outside the BTS in a satisfactory manner for months; similarly,
it's far from ideal to have delayed the fix for the nscd bug (which has
been open for over a month and requires a new upload of the glibc package
to fix) until the very last day before release. These aren't isolated
examples: there's been significant amounts of "QA" work (for example,
checking buildability for binary-all packages; checking for packages that
modify conffiles) that has only been started _after_ the time when it's
reasonable to try doing anything about it, and there've been significant
numbers of uploads rushed in at the last minute for problems that could've
been resolved either by the maintainer or by NMU weeks or months ago.

These are two sides of the same coin, really: fixes need to be done
early rather than late so that they can be tested and, if necessarily,
fixed further, and problems need to be found even earlier so that there's
time to fix the problem right. It might be better late than never, but
really the difference isn't all that noticible. Hopefully people will
be able to use the forthcoming suffering as an incentive to get this
done right next time.

So, the final automatic run of the testing scripts was today, and will
be reflected in the next mirror pulse. From this point, we'll have
manually approved security updates to some packages, and very little
else, until release. Requests from the maintainer to remove packages
that are unreleasable may be considered. Requests from the maintainter
for an update to a package will generally be considered a request to
remove the package.

aj (woody release manager)

[0] Issuing an advisory and fixed .debs for the six architectures that
    released with Debian 2.2 (potato) already takes, essentially, an
    entire night with the current tools; doing likewise for the eleven
    architectures that will release with woody will take more time than
    the security team are able to commit; doing it with woody's eleven
    architectures _and_ potato's six architectures for a few months
    so that people have time to evaluate woody before being forced to
    upgrade to it is completely out of the question.

Anthony Towns <>
Woody Release Manager

30 May 2002

Subject: about the release status
From: Josip Rodin <>
Date: Thu, 30 May 2002 22:02:58 +0200
Sender: Josip Rodin <>
User-agent: Mutt/1.3.28i


This note is primarily meant to alleviate the concerns about woody being
released. Please read on if you care about the release.

To reiterate the main point from the April 30th mail by Anthony Towns,
the release of woody is being held back because there is no systematic
way to build packages in security advisories on all architectures
included in woody.

To elaborate on this, the current situation is that when a security
advisory is to be done for a package that is in woody, the security team
people would need to go running around searching for eleven machines
where they can build the new package. For some architectures, it's not
hard to do this, but for some other, it's much harder to find a suitable
machine. Bear in mind that these are, in fact, _security_-sensitive
packages, so you can't just build them on J. Random Hacker's machine and
distribute them worldwide.

So, the ftpmaster team started doing changes to the buildd system and
the archive maintenance scripts. These changes did get done in the first
week of May as expected, but we haven't released woody yet because the
overall testing and implementation on all buildds is still not
complete. Rest assured that this will get done, as the guys really are
working on it.  Several buildds are already testing the new scheme. It's
merely not certain when this will be finished.

We can only ask you to be patient. :-)

If anyone wishes to see the code changes in detail, CVS trees are
available at:    module dak         module wanna-build

The first tree is also available via

You can observe the times between your uploads and when the buildds get
to them via

In the meantime, woody has been frozen. We have accumulated some more RC
bugs, and the software has become that much older. Work continues on the
unstable distribution, which is clear for uploading as always. It will
be possible to propagate the newly fixed packages into woody, too, there
is no need to worry about that. Whether woody will be unfrozen and
test-cycled again, or include the patched packages in a point release,
we are not sure, but the release-critical problems that aren't fixed
will eventually be fixed.

Thank you for your patience.
Josip Rodin <>

8 Jun 2002

Subject: The New Security Build Infrastructure
From: Anthony Towns <>
Date: Sat, 8 Jun 2002 18:26:46 +1000
Mail-copies-to: nobody
Organisation: Lacking
User-agent: Mutt/1.3.28i

Hello world,

So, there's probably a whole bunch of people out there who're interested
in the form new security infrastructure will take. If you're not, feel
free to skip this message.

Historically, which is to say, currently, the archive
has been managed pretty manually: a member of the security team will
patch a program with a security bug and test it; then ssh to machines
of each different architecture in the stable release and build the new
source there; then, once this is done everywhere, prepare an advisory
including the md5sums of all the newly built packages; then move the
packages into the appropriate place on; then run
dpkg-scanpackages and dpkg-scansources; and, finally, sign and send out
the advisory. (The above is the general idea aiui, anyway. I'm sure if
anyone cares the security team can correct the details)

This has a whole bunch of problems: since almost everything's done
by hand, it's easy to forget to do something or to make mistakes,
and this has occasionally resulted in broken security updates or
confusing advisories. Additionally, it takes a lot of time and care,
which can delay updates, and certainly makes the job a lot harder than
it might otherwise be. But the real problem is it doesn't scale well:
the ever growing number of packages alone gives the security team an ever
increasing amount of work to do, with woody having twice the number of
ports as potato we've made every single security update require twice
as much effort from the security team, and that's just too much.

Well, that's the problem statement anyway: managing security updates,
and especially getting them built, needs to be much easier.

So, what's the solution? For a fair while (at least a few months that
I've been aware of), the security team were attempting to get "rbuilder"
[0] installed on machines of each architecture so that they could use
that to build security updates, but for various reasons didn't have much
success. As such, in early to mid April, the buck was passed, although
it wasn't for a couple of weeks after that that we figured out who it
could reasonably be passed to.

The new buildd infrastructure consists of two components that've been
on the agenda for a while now:

 (1) Converting to be run by katie

 (2) Modifiying the central wanna-build infrastructure to do

For the former, the thought is that it's a waste to have all this neat
software for managing Debian archives, and then not use it for our
security archive -- but until now, nothing's been actually done, since
making it happen requires some significant changes to both the security
archive itself (poolising it amongst other things), and to generalise
the katie code itself.

Meanwhile, the latter is a nifty idea that the archive changes for
crypto-in-main have allowed: since packages are checked (for signatures
and such) within about fifteen minutes of them being uploaded, there's
no longer any reason to have the autobuilders wait until the daily
archive run before trying to build them. So it's basically a matter
of setting up the buildds' sources.list to point to a new url [0], and
add newly accepted packages to the wanna-build database, and -- presto
chango! -- packages get automatically built thirty minutes or an hour
or so after they're uploaded! As it happens, there're a bunch of little
complications beyond this, to the point where the current setup is the
third reimplementation of the above basic description in the past month
or so, but you get the idea.

While the above makes for a good answer to the scalability problems
the security team are facing -- the archive code and the autobuilders
already cope with much larger numbers of packages than the security team
produce -- there are a number of additional difficulties in trying to
manage security uploads that have to be taken into account.

The major difference is that security updates frequently shouldn't be
made public as soon as they're ready; in some cases they only need to
wait until they can be tested further or an advisory written, in others
they need to wait for a week or more to avoid publicising the flaw until
all vendors have had a reasonable chance to fix it. This is pretty much
in direct opposition to the way normal uploads work: we want those to
be publically available as soon as possible. And, of course, there's an
additional problem here in that in order to do accepted autobuilding,
packages need to be made available to the autobuilders as early as
possible, which is well before thay should be made available to the
wider public.

So! How does it all work? Here's the general idea:

 a) Someone finds a security problem.

 b) Someone fixes the problem, and makes an upload to's incoming. That is to say, a package is
    uploaded to:

    Its changelog needs to point it at "stable-security" or
    "testing-security" in place of the usual "unstable". It should be
    signed in the usual manner. It should, obviously, be tested fairly
    thoroughly. Anyone can do this, but presumably it'll usually be a
    member of the security team. If you're _not_ a member of the security
    team, you should definitely contact them before doing this. Further,
    while anyone can upload files here, only the security team can see
    what people have uploaded.

 c) The upload gets checked and processed by "jennifer" and moved into
    queue/accepted, and the buildds are notified. Files in here can
    be accessed by the security team and (somewhat indirectly) by the

 d) Security-enabled buildds pick up the source package (prioritized over
    normal builds), build it, and send the logs to the security team.

 e) The security team reply to the logs, and the newly built packages
    are uploaded to queue/unchecked, where they're processed by jennifer,
    and moved into queue/accepted.

 f) When the security team are happy with the source package (ie, that
    it's been correctly built for all applicable architectures and that
    it fixes the security hole and doesn't introduce new problems of its
    own) they run a script (viz, "amber") which: 
        * installs the package into the security archive
        * updates the Packages, Sources and Release files in the usual way
        * sets up a template advisory that the security team can finish off
        * (optionally) forwards the packages to the appropriate 
          proposed-updates so that it can be included in the real archive ASAP

And that's pretty much it.

All of the above has been implemented and tested in one way or another,
although some of this hasn't been in entirely realistic conditions yet.
It does, though, seem pretty safe to say that any further changes that'll
be needed will be small bugfixes rather than redesigns or rewrites. katie
for has been setup on [1] and
basically works, and the buildd changes are being live tested on the
alpha, i386, powerpc and sparc autobuilders.

Credit for the katie implementation work go to James Troup, for the
buildd changes, Ryan Murray, and for all the -devel and other flamewars,
yours truly. ;)

What you can expect next is for the security infrastructure to move
over to satie permanently and into the hands of the security team, and
an update on all the other things that affect woody which have come up
over the past month and a bit.

It's possible that some of these changes will let us handle security
updates in better ways in future (I'm hopeful it'll let us does security
updates for testing in a more timely manner, eg), but that probably
won't become clear until the security team's had more of a chance to
get comfortable with it all.

aj (woody release manager)

[0], as it happens. These are IP/password
    restricted and shouldn't be used except by autobuilders. If you want to
    poke around just for curiousity's sake, auric:/org/
    is one place to start.

[1] Also accessible via a reference to this project's codename, "security
    by obscurity", as

Anthony Towns <>

11 Jun 2002

Subject: [2002-06-11] Release Status Update
From: Anthony Towns <>
Date: Tue, 11 Jun 2002 01:14:44 +1000
Mail-copies-to: nobody
Organisation: Lacking
User-agent: Mutt/1.3.28i

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)
                kernel-image-2.2.20-udma100-ext3-i386 [zlib bug]
                mmix-src [broken, 145534]
                wmspaceweather [147284]

        * binary-only updates to packages on particular architectures to bring
          them in sync:

        * updated packages (source and binaries across all applicable
                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.


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 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:


          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.

aj (woody release manager)

Anthony Towns <>

19 Jul 2002

From: Martin Schulze <>
Subject: Debian GNU/Linux 3.0 released
Date: Fri, 19 Jul 2002 23:59:59 +0200
To: Debian Announcements <>
User-Agent: Mutt/1.4i

The Debian Project                      
Debian GNU/Linux 3.0 released                 
July 19th, 2002       

The Debian Project is pleased to announce the release of Debian GNU/Linux
version 3.0.  Debian GNU/Linux is a free operating system, which now
supports a total of eleven processor architectures, includes KDE and GNOME
desktop environments, features cryptographic software, is compatible
with the FHS v2.2 and supports software developed for the LSB.

With the addition of the IA-64 (ia64), HP PA-RISC (hppa), MIPS (mips,
mipsel), and S/390 (s390) architectures, Debian GNU/Linux now supports a
total of eleven architectures.  It now runs on computers ranging from
palmtops to supercomputers, and nearly everything in between, including the
latest generation of 64 bit machines.

This is the first version of Debian that features cryptographic software
integrated into the main distribution.  OpenSSH and GNU Privacy Guard are
included in the default installation, and strong encryption is now present
in web browsers and web servers, databases, and so forth.  Further
integration of cryptographic software is planned for future releases.

For the first time, Debian comes with the K Desktop Environment 2.2 (KDE).
The GNOME desktop environment is upgraded to version 1.4, and X itself is
upgraded to the much improved XFree86 4.1.  With the addition of several
full-featured free graphical web browsers in the form of Mozilla, Galeon,
and Konqueror, Debian's desktop offerings have radically improved.

This version of Debian supports the 2.2 and 2.4 releases of the Linux
kernel.  Along with better support for a greater variety of new hardware
(such as USB) and significant improvements in usability and stability, the
2.4 kernel provides support for the ext3 and reiserfs journaling filesystems.

Debian GNU/Linux 3.0 features a more streamlined and polished installation,
which is translated into numerous languages.  The task system has been
revamped and made more flexible.  The debconf tool makes configuration of
the system easier and more user friendly.  Debian GNU/Linux can be installed
from CD, or from the network and a few floppies.  It can be downloaded now,
and will soon be available on CD-ROM from numerous vendors

Upgrades to Debian GNU/Linux 3.0 from earlier releases are automatically
handled by the apt package management tool.  As always, Debian GNU/Linux
systems can be upgraded painlessly, in place, without any forced downtime.
For detailed instructions about installing and upgrading Debian GNU/Linux,
please see the release notes

This is the first release of Debian that is compatible with version 2.2 of
the Filesystem Hierarchy Standard (FHS).  Debian GNU/Linux now also supports
software developed for the Linux Standard Base (LSB), though it is not yet
LSB certified.

Current Debian users may be interested to know that this release of Debian
supports build dependencies, to aid in building packages from source, and  
apt pinning, to ease partial upgrades to our testing or unstable branch.
This release of Debian features aptitude as an alternative for the
venerable dselect program, which will make it easier to select packages.
About four thousand new software packages were added to the distribution in
Debian GNU/Linux 3.0.

About Debian

Debian GNU/Linux is a free operating system, developed by nearly a thousand
volunteers from all over the world who collaborate via the Internet.
Debian's dedication to Free Software, its non-profit nature, and its open
development model make it unique among GNU/Linux distributions.

The Debian project's key strengths are its volunteer base, its dedication
to the Debian Social Contract, and its commitment to provide the best   
operating system possible.  Debian 3.0 is another important step in that  

Contact Information

For further information, please visit the Debian web pages at
<> or send mail to <>.

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

20 Jul 2002

Subject: [2002-07-20] Release Status Update
From: Anthony Towns <>
Date: Sat, 20 Jul 2002 08:09:16 +1000
Mail-copies-to: nobody
Organisation: Lacking
Sender: Anthony Towns <>
User-agent: Mutt/1.3.28i

Hello world,

First, the big news: it's my mum's birthday today. Happy birthday mum!

Second, for those who haven't already noticed:

  ajt@auric:/org/$ ls -l testing stable Debian3.0r0 
  lrwxrwxrwx    1 troup    debadmin        5 Jul 19 14:41 Debian3.0r0 -> woody
  lrwxrwxrwx    1 troup    debadmin        5 Jul 19 14:40 stable -> woody
  lrwxrwxrwx    1 troup    debadmin        5 Jul 19 14:43 testing -> sarge

Third, for those of you who aren't used to leaping to conclusions based
on the output of a couple of obscurely named commands, this means the
new testing distribution is codenamed "sarge" [0], and that "woody" is
released -- the Debian GNU/Linux stable distribution is now at version
3.0. This revision began development when the "potato" entered it's
code freeze, around two and a half years ago. It includes KDE, a new
version of Gnome, Mozilla 1.0, and lots of other stuff that's already
been covered in the real announcement and the release notes. If you've
missed the real announcement, it's at:

Fourth, we've got a new tool for generating CDs, called "jigdo". It lets
you download most of the CD from your local Debian mirror -- which is
likely to be faster or cheaper or both. See
for some details. Note that regular .iso images won't be made available
for a couple of days, so if you want to be a really early adopter Jigdo
is the only way to go. To find your local mirror, look at 

Note that by the time you read this, some mirrors won't have updated
yet.  If you feel the need to update immediately enough to edit your
/etc/apt/sources.list to point at an updated mirror, I'd *strongly*
encourage you to include woody from your closest mirror as the first
line in your sources.list. If you do that, any debs that're up to date
on the local mirror will be fetched from there which will also be faster
and cheaper for everyone concerned.

Fifth, it seems to be the season for security updates. So make sure you've
        deb stable/updates main
or similar in your sources.list.

So, that just leaves all the gossip! Sweet.

(If you're a suit with a business imperative to obtain reassurance in
regard to the enterprise suitability of Debian -- don't read on :)

The traditional round of thanks, then. Over two or so years of trying to
get woody released, there's a fair number of people who've done useful
things: heck, that much time is enough for people to discover Debian, join
it, do a bunch of useful things, get bored with it, and quit. I'm going
to be lame and not even try to cover most people. You can get some vague
idea of who the people who've gotten Debian from 2.2 to 3.0 by looking at

but it's only a vague idea at best. These releases don't happen without
all the folks who work on our 9000 or so packages, our porters, our CD
developers, our QA team, our security team, our installer developers, our
bug reporters, etc, etc. And all that excludes the other two ends that
make Debian what it is: all the people upstream who develop software we
package, and all the people who actually use it. Apparently there are
one or two people in both groups.

But you can't have a round of thanks by saying "there are too many people
to thank", coz that's just lame. So I'm going to restrict my focus to
the release task itself, and thus I get to mainly thank James Troup and
Ryan Murray. Without James' efforts over the past two years, the archive
software wouldn't be anywhere near capable of managing all the packages we
have (around 10000 all up, multiplied by 13 architectures (11 released,
one unreleased and source)) nor the complexities of the way we've tried
to handle this release (aka "testing"). Without Ryan's efforts we were
struggling to keep our packages remotely consistent across a handful
of architectures, with them, we're keeping almost a dozen highly varied
architectures almost perfectly synced with twice as many packages.

Normally I'd expect to be running through a list of people like the
port maintainers or the boot-floppy hackers or the CD people here,
but in a shocking turn of events, they all pretty much took care of
themselves. People like Adam Di Carlo and Philip Hands can get a token
mention anyway, though. Check the changelogs for the full details. Thanks,

Thanks also to Jonathan Oxer, who fell for my blatant attempt at extortion
in my previous update [1]: he's now the official organiser of the Debian
mini-conference at 2003 in Perth. So, if you're into
Debian enough to be reading this mail, and you're planning on being in
the Southern Hemisphere next January, you know what you should do.

There's actually been some criticism of my use of the woody release
to blackmail someone into hosting the mini-conf -- a number of people
have indicated that I should've demanded money too. Well, fortunately
there's still time to remedy such problems. And there'd better be, because
there's a much more serious issue that's come to light: a certain past
policy has almost certainly unfairly biassed some of the more accurate
IT polling organisations [2] against the new release.

As such, you should feel free to send a buck or two to "The Release
Manager's Beer Fund" via PayPal to [3]. Your
return on investment is guaranteed!

So, that about does it. Last time around I had a couple of bits about
what went wrong with the release just gone, and some of the things that
we'll be working on for the next one, but they're complicated enough to
warrant a separate email sometime in the next week or so.

Hrm. So, what else could cause some more chaos?

I know!

IRC PARTY IN #debian ON NOW!!!!!

Have fun. :)


[0] sarge is named after the green toy soldier, continuing the theme of
    using codenames based on characters in the animated movie _Toy Story_.



[3] PayPal's at I've no idea how it works. Or if it works.

    If you're overly excited by all this "release" stuff, and feel an
    urge to send even *more* than pocket change, look at:

    instead. That'll ensure your money is properly accounted for and
    isn't randomly wasted.

Anthony Towns
Debian Release Mananger

Valid XHTML 1.0

Zurück zur Main-Site
Created with GNU-Emacs on Mon Jun 10 01:10:36 CEST 2002

Valid CSS