Debian Weekly News - email
- Debian 2.2 (a.k.a. 'potato') [not yet released]
October GNOME is already included.
Just make sure you select the 'GNOME Workstation' profile when installing.
- Debian 2.1 (a.k.a. 'slink')
- make sure 'apt' is installed on your system.
If it isn't, install it.
(you can download it from http://ftp.debian.org/debian/dists/stable/main/binary-i386/admin/apt_0.3.10slink11.deb).
- add the line
deb http://www.debian.org/~vincent/ slink-update main
To do so, type (as root):
echo "deb http://www.debian.org/~vincent/ slink-update main">> /etc/apt/sources.list
- download and install the packages:
Using apt; type (as root):
apt-get install task-gnome-apps
You can also use dselect's apt method; just update sources.list and then do an update in dselect (and manually select which packages you want).
You may also want to browse the complete package list
and choose to install extra packages individually by typing (as root):
apt-get install package-name (ie: apt-get install gnumeric)
This repository will be updated from time to time to include the eventually needed bug fixes.
So even after the update, you're encouraged to keep the resource line in your sources.list file,
and to type apt-get dist-upgrade from time to time.
- make sure 'apt' is installed on your system.
- Debian versions before 2.1 are not supported.
If you want October GNOME on your Debian 1.3 or Debian 2.0,
you'll have to recompile them from source (either using the
upstream tarballs, or from the Debian source packages).
To: email@example.com Subject: Adam Di Carlo's Rationale (was Re: FREEZE RESCHEDULED) References: <19991107131936.A1352@xs4all.nl> <firstname.lastname@example.org> <382594DC.1CAD2BE3@by.net> <19991107183854.B281@paradigm.rfc822.org> <38267D5C.C3FA293A@by.net> From: Adam Di Carlo <email@example.com> Date: 08 Nov 1999 21:26:14 -0500 Included is a justification for the delay in freeze that I sent to the slashdot forum. This is the first time I ever posted there, but I'm worried about becoming the most hated person in Debian. Anyhow, I'm posting it here in case people wanna read it. Let me just preface this by saying that I agree with those who say that a 2 month delayed freeze with a 1 month cycle (if we can achieve that) is going to be better than a 3 month freeze. For the developers here, I hope that you hold back uploading very unstable packages until after the potato release. -- .....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/> Anyone who's been watching Debian for more than 1 year knows that freeze time is a huge strain on the project. The release manager, Richard Braakman, has stated his wish that the complete duration of the freeze should be no greater than 3 or four weeks. My discussion with him regarding the preparedness of the boot-floppies, in particular, is just to make sure he has all the information he needs to make this wish into a reality. The whole point is to go *into* the freeze with a feature-complete and beta-ready installation system; with that in place, a 4 week freeze is plausible. Without it, it's not. For those who remember the slink freeze, that was about a 16 week cycle (it froze in mid-Nov, release in mid-March), and was quite stressful to all. Our goals is that freeze is predicated on a pretty stable set of packages, which makes our own ability to test installation from scratch and slink to potato upgrading in a more sane fashion. [FYI, my current estimate is that we will have a feature complete boot-floppies by Dec 1. I can state with some conviction that by 1 Jan 2000 we'll have what I'd call a "release quality" boot-floppies (i.e., has undergone much testing; may still have documentation to be done).] Let me just cover a few other points, quickly. * The main reason why I want more time for boot-floppies features to go in is that I feel these features are very important. Let me mention them briefly: a new task/profile selection mechanism, with the means to continue to use these mechanisms even after installation; use of apt in almost all cases [for package acquisition; yes, I know there are cases with SOCKS proxies and other obscure situations where this might not be a reality]; an apt configurator, with the capability to autosense official cdroms in expected locations; ability to install base2_2.tgz via http and maybe ftp; bootp/dhcp network data population when available; X package installation hand-holder, able to autosense your correct X server package. I feel these advances are important. Even with the delay, I hope we have time to implement them. * Those who say we'll never freeze are just talking crazy. We have a lot of desire to update and obsolete the slink distribution. * Regarding Linux 2.4, no, we do not plan release cycles around Linux release cycles, which should be clear to anyone. For better or worse. Assuming Linux 2.4 is stable (2.2 wasn't that great w.r.t. stability when it came out, IMHO) and comes out in the next couple of weeks, I wouldn't rule out 2.4 for sure. Right now, we're planning on using 2.2.13 (although that can very for our 5 different architectures). * We do realize that the current release engineering mechanisms are showing the strain of how large the project has grown. There are two approaches to this problem: (a) do more "point releases" of the stable system, which simply requires a larger team than we currently have worrying about stable even after it's released; (b) radically reengineer release management, where the most likely candidate for this is the "package pool" proposal -- I don't have the URL offhand. * Even with all that being said, I'd like to reiterate that, AFAIK, Debian is the only distribution with a proven and robust way to upgrade your distribution (whether it's for new releases, picking packages out of unstable, or whatever). * While we're in the "excuses" department, I don't think there are many out there that realize how much effort it is to coordinate Debian in general (or boot-floppies, for that matter). This work goes on behind the scenes, and some of you interpret the slow-moving nature of these issues as indifference. I can assure you we are not indifferent, especially to the criticisms regaring frequency of release and the quality of the boot-floppies.
Date: Tue, 9 Nov 1999 07:23:23 +1100 From: Chris Leishman <firstname.lastname@example.org> To: email@example.com Subject: Partial freeze? Ok, Here is another thought (probably one that has come up before - gotta love going around in circles. Let me know if I am). The problem at the moment is that no-one wants to freeze, because we don't know how long we will be frozen for - and in that time things get stale and old. And why don't we know how long we will be frozen for? Because some "critical to release" packages (like boot-floppies) are not stable and we don't know how long they will take to become so. However - IMHO if we don't freeze, then we are in the same position as unstable always is - at any point there can be an update that will cause a different "critical to release" package to fail. Who knows - in a month when we have boot-floppies working, some other new or updated package might (or new policy) might still prevent us from freezing for the same reasons.. Bit of a catch 22 really. If we freeze, then things can stabilise, but they might also get stale. If we don't, then things won't get stale, but they may not stabilise quickly. How about this then: We identify those packages which are considered "critical to release". This would include packages like boot-floppies and policy. Then we declare a _freeze on those packages_. The same freeze rules apply - only bug fixes to these packages allowed. However, new uploads can continue while this stuff stabilises - as long as they don't cause problems with the "critical to release" packages. If they do, then the freeze rules apply to that upload (no new code). Eventually we freeze the whole distribution for a very short time to clean release critical bugs in non-core packages. We should take a fairly hard line on these, and basically say that if there was a version without _new code_ that didn't exhibit the problem, we backdate to it rather than bugfix. Ok..conclusions from this idea... This _may_ lengthen the freeze time, since we are effectively doing 2 freezes. But the second phase (the phase that can introduce stagnation) will be much shorter than it is in our current situation. Another conclusion may be that this just sounds like common sence, and there is no need to make it official...but I've always found these things work much better when they are enforced. The last remaining question is how workable this concept is.... Best regards, Chris (wish me well for my macroeconomics exam in...oh...1 1/2 hours :) -- ---------------------------------------------------------------------- Linux, because I'd like to *get there* today ---------------------------------------------------------------------- Reply with subject 'request key' for GPG public key. KeyID 0xB4E24219
To: firstname.lastname@example.org Cc: email@example.com Reply-To: firstname.lastname@example.org Subject: New members of the archive maintenance team From: James Troup <email@example.com> Date: 09 Nov 1999 00:41:51 +0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [ Please don't reply to debian-devel-announce ] Hi, I'd like to publicly welcome Gergely Madarasz and Antti-Juhani Kaijanaho who are joining Guy, Richard and I as members of the archive maintenance team. Even though we originally only asked for one person to help, we decided to take on two new members due to the number of NEW packages being uploaded every day. Thank you to everyone else who kindly volunteered their help. - -- James -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.4 and Gnu Privacy Guard <http://www.gnupg.org/> iD8DBQE4J22rgD/uEicUG7ARAlWcAKCSLTKJG76UArnF7ZN9TeQonVGinACg3XPM A9RkFdHOQK7Kluwp9KEwi0A= =C8iF -----END PGP SIGNATURE-----
To receive this newsletter weekly in your mailbox, subscribe to the debian-news mailing list.
Back issues of this newsletter are available.
This issue of Debian Weekly News was edited by Joey Hess.