|
:: Home :: Computing :: Downloads :: Scooter :: 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.
To: debian-devel-announce@lists.debian.org
Subject: [2002-04-06] Release Status Update
From: Anthony Towns <aj@azure.humbug.org.au>
Date: Sat, 6 Apr 2002 22:24:34 +1000
Mail-copies-to: nobody
Mail-followup-to: debian-devel-announce@lists.debian.org
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:
exim-tls
icecast-server
libax25
lockvc
nscd
phpgroupware
xfree86
* 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.
Cheers,
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 <ajt@debian.org>
Woody Release Manager
To: debian-devel-announce@lists.debian.org
Subject: [2002-04-30] Release Status Update
From: Anthony Towns <aj@azure.humbug.org.au>
Date: Tue, 30 Apr 2002 19:04:06 +1000
Mail-copies-to: nobody
Mail-followup-to: debian-devel-announce@lists.debian.org
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.
Cheers,
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 <ajt@debian.org>
Woody Release Manager
To: debian-devel-announce@lists.debian.org Subject: about the release status From: Josip Rodin <joy@debian.org> Date: Thu, 30 May 2002 22:02:58 +0200 Mail-followup-to: debian-devel@lists.debian.org Sender: Josip Rodin <joy@gkvk.hr> User-agent: Mutt/1.3.28i Hi, 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: :pserver:anonymous@cvs.debian.org:/cvs/dak module dak :pserver:anon@cvs.linux-m68k.org:/CVS module wanna-build The first tree is also available via http://cvs.debian.org/dak/?cvsroot=dak You can observe the times between your uploads and when the buildds get to them via http://buildd.debian.org/ 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 <joy@debian.org>
To: debian-devel-announce@lists.debian.org
Subject: The New Security Build Infrastructure
From: Anthony Towns <aj@azure.humbug.org.au>
Date: Sat, 8 Jun 2002 18:26:46 +1000
Mail-copies-to: nobody
Mail-followup-to: debian-devel-announce@lists.debian.org
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 security.debian.org 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 security.debian.org; 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 security.debian.org to be run by katie
(2) Modifiying the central wanna-build infrastructure to do
"Accepted-Autobuilding"
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
security.debian.org's incoming. That is to say, a package is
uploaded to:
security.debian.org:/org/security.debian.org/queue/unchecked
(aka ftp://security.debian.org/pub/SecurityUploadQueue)
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
buildds.
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 security.debian.org has been setup on satie.debian.org [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.
Cheers,
aj (woody release manager)
[0] http://incoming.debian.org/buildd/, 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/incoming.debian.org/
is one place to start.
[1] Also accessible via a reference to this project's codename, "security
by obscurity", as obscurity.debian.org.
--
Anthony Towns <ajt@debian.org>
To: debian-devel-announce@lists.debian.org
Subject: [2002-06-11] Release Status Update
From: Anthony Towns <aj@azure.humbug.org.au>
Date: Tue, 11 Jun 2002 01:14:44 +1000
Mail-copies-to: nobody
Mail-followup-to: debian-devel-announce@lists.debian.org
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)
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>
From: Martin Schulze <joey@infodrom.org> Subject: Debian GNU/Linux 3.0 released Date: Fri, 19 Jul 2002 23:59:59 +0200 To: Debian Announcements <debian-announce@lists.debian.org> User-Agent: Mutt/1.4i ------------------------------------------------------------------------ The Debian Project http://www.debian.org/ Debian GNU/Linux 3.0 released press@debian.org July 19th, 2002 http://www.debian.org/News/2002/20020719 ------------------------------------------------------------------------ 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 <http://www.debian.org/CD/>. 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 <http://www.debian.org/releases/woody/releasenotes>. 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 direction. Contact Information ------------------- For further information, please visit the Debian web pages at <http://www.debian.org/> or send mail to <press@debian.org>. -- To UNSUBSCRIBE, email to debian-announce-request@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
To: debian-devel-announce@lists.debian.org
Subject: [2002-07-20] Release Status Update
From: Anthony Towns <ajt@debian.org>
Date: Sat, 20 Jul 2002 08:09:16 +1000
Mail-copies-to: nobody
Mail-followup-to: debian-devel-announce@lists.debian.org
Organisation: Lacking
Sender: Anthony Towns <aj@azure.humbug.org.au>
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/ftp.debian.org/ftp/dists$ 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:
http://www.debian.org/News/2002/20020719
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 http://cdimage.debian.org/
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
http://ftp.debian.org/README.mirrors.html
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
got
deb http://security.debian.org/ 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
http://www.debian.org/intro/organization
http://www.debian.org/devel/people
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,
y'all.
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 linux.conf.au 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 ajt-woody-rocks@debian.org [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 irc.openprojects.net NOW!!!!!
Have fun. :)
Cheers,
aj
[0] sarge is named after the green toy soldier, continuing the theme of
using codenames based on characters in the animated movie _Toy Story_.
[1] http://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200207/msg00005.html
[2] http://srom.zgp.org/
[3] PayPal's at www.paypal.com. 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:
http://www.spi-inc.org/donations
instead. That'll ensure your money is properly accounted for and
isn't randomly wasted.
--
Anthony Towns
Debian Release Mananger
|
|
Zurück zur Main-Site |
|
