Re: Bug#983912: grub2: consider renaming signed source packages to grub2-signed-*
On Sun, 20 Nov 2022, Salvatore Bonaccorso wrote: On Wed, Mar 03, 2021 at 10:52:39AM +0100, Ansgar wrote: Source: grub2 Version: 2.04-16 Severity: normal X-Debbugs-Cc: ftpmas...@debian.org, debian-release@lists.debian.org grub2 currently uses grub-efi-signed-* as source package names for the Secure Boot signed packages. While releasing the last security update we found a small issue with these names: dak processes source packages in lexiographic order, so it would process grub-efi-signed-* before grub2 when accepting all packages at once from the "embargoed" policy queue. But the grub-efi-signed-* binary packages have Built-Using: grub2; as grub2 is not accepted from embargoed at this point in time, the /binary/ uploads will be rejected in this case. (This problem exists in principle with all Built-Using relations.) How hard would it be to enhance dak to not require any specific ordering? One way could be to process the same list repeatedly, until no additional packages have been accepted for an entire pass. Regards, Anne Bezemer
Our stable release
Hi all, We haven't had a properly installable stable release for a full month now, #536312. Applies to both CD/DVD and network installs. I don't see much activity to resolve this. Are we so busy with squeeze and sid, that we don't care about lenny any more? Best regards, Anne Bezemer P.S. Just for the record, here is a condensed list of what's broken, based on Otavio's re-generated overrides (#536312 msg#25) --- task.good 2009-07-20 15:09:11.0 +0200 +++ task.now2009-07-29 10:56:03.166433439 +0200 -gksu Taskgnome-desktop +gnome-accessibilityTaskgnome-desktop -gpartedTaskgnome-desktop -gstreamer0.10-ffmpeg Taskgnome-desktop -gthumb Taskgnome-desktop -hal-cups-utils Taskgnome-desktop -hardinfo Taskgnome-desktop -hibernate Tasklaptop -kdeTaskkde-desktop -kde-core Taskkde-desktop -kdeadmin Taskkde-desktop -kdeartwork Taskkde-desktop -kdegraphicsTaskkde-desktop -kdemultimedia Taskkde-desktop -kdenetwork Taskkde-desktop -kdepim Taskkde-desktop +kde-standard Taskkde-desktop<-not in lenny -kdeutils Taskkde-desktop -kpackage Taskkde-desktop -kpowersave Taskkde-desktop -lifereaTaskgnome-desktop -menu-xdg Taskgnome-desktop, kde-desktop +menu-xdg Taskkde-desktop -network-manager-gnome Taskgnome-desktop -nvclockTasklaptop +openoffice.org-help-fi Taskfinnish-desktop <-not in lenny -openoffice.org-kde Taskkde-desktop -pidgin Taskgnome-desktop +pm-utils Taskdesktop, laptop -toshsetTasklaptop -tsclient Taskgnome-desktop -update-notifierTaskgnome-desktop -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [stable, D-I] Kernel selection broken for some architectures
On Thu, 1 Mar 2007, Frans Pop wrote: > Unfortunately we seem to have missed a change that was needed because of > the ABI change in 3.1r3. We have not noticed this until now because the > old kernels were still included in the archive and on CD images. With > 3.1r5 the old images were removed which brought the issue to the surface. > > The result of this is that for some architectures (i386, hppa, ia64, s390) > an incorrect kernel may be selected during base installation. > See also: #412295, #412909. > > The changes should have been made in some default values included in the > rootskel udeb. Updating the rootskel udeb now would mean that we would > need to rebuild D-I images, which is obviously not very desirable. > > Fortunately an alternative solution is possible: correcting the default > after it has been read from the debconf database. > > I have implemented this solution in base-installer (1.13.4sarge2) and > uploaded that new version to stable. As base-installer is not included in > D-I initrds for the affected architectures, this means we "only" need to > include this new version in stable and rebuild CD images. > > I understand that a 3.1r5a was already being considered, so this fix could > be included in that update. One of my customers just asked if there is an ETA for r5a... Best regards, Anne Bezemer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
2.2rev3 CDs (was Re: Stable Release plan)
On Thu, 19 Apr 2001, Raphael Hertzog wrote: > Le Thu, Apr 19, 2001 at 09:16:11AM +0200, Martin Schulze écrivait: > > > Also - is there any chance that .iso images or pseudo image > > > configurations could be ready _before_ the release is announced - eg > > > tonight cdimage.debian.org still has no idea about 2.2r3 - shouldnt .isos > > > be part of the release and the release be conditional upon them being done > > > ?? > > > > Please get in touch with the debian-cd list, they should know about > > cdimage.d.o > > No, no, the problem is with you. You install packages in the archive and 4 > hours later you make the announcement. You need to let one day so that > files propagate to mirrors, send a mail to debian-cd@lists.debian.org > asking us to generate the new ISO with the newly installed files and let > another day so that ISO images have a chance to propagate too. And only > then you should do the announcement. > > That said, people who usually create the debian-cd images ? What are you > doing with 2.2r3 ? Please take care to NOT use the CVS version of > debian-cd to generate the images (since I've introduced the new stuff for > signed Release file and so on and it's not yet ready for prime time) but > rather the last package (or even older ... but not too much). Or you may > use the latest debian-cd if you take care to remove manually the rules > *-secured in the Makefile. Sorry for having been this silent. In the past few days I've spent many hours on getting debian-cd ready for 2.2 rev3 (issues you mentioned, updated/ redesigned README (matching www.d.o but actually better code) and the long-promised "make-a-useful-CD1" project which involved lots of test runs and a new unexclude feature). I'm mostly finished now, a few things still need some tweaking, then I'll leave it to Phil to generate the new .iso's. The unexclude will be used to move any number of kernel sources to CDx, x>=2; the source of only 2.2.19 will be on CD1. However because we currently have 10 (!!) kernel sources in potato, it looks like we're going to have a 4th CD with only 15MB on it. So, unless anyone objects, I think we'd better NOT have the sources of 2.2.10 and possibly 2.2.12 on any CD (which still leaves us 2.2.13, 2.2.15, 2.2.17, 2.2.18pre21, 2.2.18, 2.2.19pre17 and 2.2.19 -- and 2.0.36, 2.0.38 of course). Regards, Anne Bezemer (who still needs to process lots of mails to these and other lists :( )
Re: To Do for 2.2r3
On Mon, 26 Mar 2001, Adam Di Carlo wrote: > Anthony Towns writes: > > > * libc6 -18 for alpha, arm, i386, powerpc (already there for m68k > > and sparc) > > > > * updated kernel / pcmcia stuff? > > > > * updated boot-floppies? > > Joey (Martin Schulz) seems to think the boot-floppies 2.2.21 don't > have the testing to go into 2.2r3. I rather disagree, but it's you > guys' call about that. > > Regarding what is significant which should cause it to go in. I > include a few of the more significant changelog entries: > > - dbootstrap: > when we ask for the Debian CD-ROM, ask specifically for the *first* > CD-ROM; ask fewer questions about archive locations, in fact, no > questions in the cases that some is using a media where things are > where we can find them (closes: Bug#82912) the "load modules from > floppy" step was reworded a bit to make it more clear that this an > extra, non-std thing > > [ bug 82912 was a significant UI error which was fixed -- I don't > know if any of you remember, but you used to be prompted for the > "debian archive location" and the "path within the debian > archive". What I do now is check first for the paths I want to > find, and if I find them, don't prompt (unless we're in verbose > mode). This fixes a *significant* point of confusion for new > users, and eliminates two unnecessary and confusing prompts. Should definately be fixed. And if 2.2.21 isn't well-tested enough, please make an updated 2.2.20 with only this patch applied. Regards, Anne Bezemer
Re: 2.2r3 preparation
#include #include On Mon, 15 Jan 2001, Anthony Towns wrote: > Anyone have any worthwhile opinions on how 2.2r3 and 2.4.0 should get > along? There already seems to be an iptables package and adding a new > devfsd package would have little chance of breaking any existing installs > (assuming they don't install it). modutils is out of date, though. It > might be worth considering making a modutils-2.4 package, which would > work in most cases, and run little risk of breaking anyone's system. > > Of course, there's no way we're going to support 2.4.x in potato much > better than we supported 2.2.x in slink, but including stuff for it > on CDs in extra doesn't strike me as unreasonable. I'm prepared to be > shouted down, of course. The current apt-cdrom will pick up any Packages files on the CD, no matter where they are. So it would be possible to put "incompatible" packages in extras/ (or for-kernel-2.4.x/ or whereever), but then there shouldn't be a Packages file there. That means it'll be quite a hassle to install these things, so I guess it would be wiser to have the stuff available only online and mention the correct sources.list line(s) in the CD's README. Regards, Anne Bezemer
Re: [comments v2] Debian GNU/Linux 2.2r2 Released
On Tue, 5 Dec 2000, Anthony Towns wrote: > On Tue, Dec 05, 2000 at 11:34:05AM +0100, J.A. Bezemer wrote: > > One other note, if you're looking at pandora directly. I've made a Release > file that describes the current release and authenticates the Packages > files and so on, and an accompanying detached signature called Release.gpg. > This more or less matches the format used by Conectiva's patched apt, so > hopefully a future version of apt will be able to use it to authenticate > the release as a whole. > > This probably shouldn't be included on the CDs yet, since it won't match > the Packages files that get used for the CDs; and it probably shouldn't > be relied on too heavily, since they key I used to sign it is really at > about the end of its working life (and it's an RSA key too :). That file is dists/potato/Release, and AFAIK nothing from there is included except Contents-$ARCH.gz. Regards, Anne Bezemer
Re: [comments v2] Debian GNU/Linux 2.2r2 Released
On Tue, 5 Dec 2000, Anthony Towns wrote: > On Mon, Dec 04, 2000 at 09:14:11PM +0100, Nils Lohner wrote: > > [ any more comments? IMO its ready to go out when the release is made. > > --nils ] > > Which should be finished now. If the CD people want to start seeing if > anything's broken, or if not, generating actual cds that's probably not > a bad idea. pool/non-US/main/f/fsh/ is drw-rw-r--. Checked on two separate rsync-mirroring mirrors. Interestingly, http://non-us.debian.org/debian-non-US/pool/non-US/main/f/fsh/ works just fine. Other than that, old packages like fsh_1.0.post.1-2.1.deb and ssh_1.2.3-9.deb are still present alongside the new ones; I suppose they should be removed. Regards, Anne Bezemer
Re: Current 2.2r2 status
On Wed, 22 Nov 2000, lance wrote: [...] >You cant > even download Debian 2.2r0 anymore and you certainly cant make iso images > using the pseudo image kit because the original ftp files were overwritten > by 2.2r1 on the mirrors, without the pseudo image kit having caught up, > there doesnt seem to be a copy of the 2.2r0 tree anywhere to allow the > isos to be made Please carefully read the Kit's README again: "Note that it is not uncommon to get a few warnings, as the FTP server may contain newer files (with other names) than those on the CD image. This is no problem; `rsync' will transfer the missing data directly from the Debian CD mirror." Which means you can still get rev0 images just fine. Regards, Anne Bezemer
2.2 rev 2 imminent?
On 13 Nov 2000, Philip Hands wrote: [...] > I think we're going to skip actually publishing these [=r1 CDs, JAB], > because Wichert doesn't want to produce r1 CDs only to replace them with r2 > CDs within a week, because it will piss the CD vendors off. > > So, I'll not be showing the CDs I produce to the public, or if I do, > I'll put them out of the way, as a test run for r2. > > Opinions? Wichert/AJ: I wouldn't mind getting some official statement on these matters. I think I'm not the only one being a little bit confused ;-) Regards, Anne Bezemer
Release Notes (Re: Stuff to do before release)
On Thu, 10 Aug 2000, Anthony Towns wrote: > > Also, if there are any changes (bug fixes, updated docs, etc) to the > release notes, they'll need to be uploaded by the same time. Josip (who's > been doing this up 'til now) is away, so someone else will have to handle > this. Adam? Anne? I've spent the last ~2 days getting home from my relatively-well-net-connected vacation spot. I didn't have time to examine postings to -doc/-testing and merge them in the release notes (until now I supposed Josip would've been doing that) and I won't have time to do that before your deadline -- which I suppose is in a few hours time. I could possibly give it some attention tomorrow, if you want. Besides, while I can commit changes to the release-notes SGML source in the boot-floppies CVS, I'm not able to produce all formats (txt,html,ps,pdf,...) for all arch'es because I not only lack the experience but also the potato box it "has" to be done on. Basically all "someone" would have to do is pull the entire boot-floppies stuff from (anonymous) CVS and issue the proper make commando(s?) -- but don't ask me which one(s). Anyone from -boot more info on that? Regards, Anne Bezemer
Re: point release versioning
On 3 Aug 2000, Philip Hands wrote: > with a space before the r, to emphasise the point that the revision > number is largely irrelevant to users when it's so easy to use apt-get Yet someone sometime started to call it "point _releases_", see the Subject: line... No wonder there's so much confusion. Regards, Anne Bezemer (who prefers "revision" ;-)
Re: point release versioning
On 3 Aug 2000, Philip Hands wrote: > "J.A. Bezemer" <[EMAIL PROTECTED]> writes: > > > And IMHO 2.2r0 sounds much better than 2.2_r0 - so I'd suggest having a > > DEBVERSION="2.2r0" for the official CDs that will be made in 1.5 weeks or > > so. > > IIRC the right way of writing the full version was supposed to be: > > X.Y rZ > > with a space before the r, to emphasise the point that the revision > number is largely irrelevant to users when it's so easy to use apt-get > to go from one revision to the next. > > Obviously it's a bad idea to have spaces in filenames, hence the > underscore. I tend agree with Anne about dropping the underscore, on > the basis that debian2.2r0 is a valid MSDOS style 8.3 name, whereas > debian2.2_r0 is not. The only place this _may_ occur is the symlink in the FTP archive. But I don't care about that thing, it may be anything the ftpmasters like. I doubt it's ever used. And it's wrong most of the time; it should be 2.2 r0.5 between the first security patch and the release of 2.2 r1... > That said, I still think we should write it as X.Y rZ (or more often > write it without the revision, unless it actually matters) when it's > not part of a filename. That's a very good idea indeed! I've scanned YACS and having a DEBVERSION="2.2 r0" shouldn't cause any problems (except see below...) (To get even less confusion, we could maybe call it "2.2 rev0" or something, but I don't think that's wise at the moment.) > Of course this does break Joey's assumption that we can look for an > underscore to determine the version number when looking for the > dedication, so add-bin-doc will need to look for an ``r'' instead. Oh dear. I see a terrible thing there that I'd classify as a beginners error. There are no quotes. Not around $DEBVERSION, but that was (until now) no big problem. $dir isn't quoted. And $dir can be anything, even "something ; rm -rf ~ ; somethingelse". Can someone PLEASE fix this?! (And scan the scripts for other similar things) Regards, Anne Bezemer
Re: point release versioning
On Wed, 2 Aug 2000, Philip Charles wrote: > Let's make it explicit and call it 2.2r0. The "r" should prevent > confusion with kernels. We know what we mean, but other people could be > confused. I agree with that. AFAIK the CD's volume ID (& .disk/info & README) is the only place this occurs anyway, so this 1) won't break anything, 2) prevents confusion, and 3) doesn't add confusion (which is quite another thing). And IMHO 2.2r0 sounds much better than 2.2_r0 - so I'd suggest having a DEBVERSION="2.2r0" for the official CDs that will be made in 1.5 weeks or so. Regards, Anne Bezemer PS. Oh, the 2.2r0 should probably also go in the "top-level" Changelog, and some symlink on the FTP sites. But I really don't bother about that, since according to those we never released 2.1r4 and 2.1r5 anyway.
Re: Test Cycle Three
On Mon, 24 Jul 2000, Josip Rodin wrote: > On Mon, Jul 24, 2000 at 09:22:13AM +0200, J.A. Bezemer wrote: > > > Second, it means we need a final set of release notes for TC3. These will > > > need to be updated again after TC3 to document any further problems we > > > have, of course, but the TC3 release notes will need to be ready by around > > > 16:00 Monday, GMT. > > > > I already asked this some time ago, but still nothing has happened: > > > > The latest slink/sparc apt and dpkg are supposed to be available in === > > potato/main/upgrade-sparc, as they're needed to upgrade from 2.1rX, X<=3 > > using CDs. They are not there yet. > > Someone needs to provide these, and then a FTP admin needs to install > them... They are already in the archive, in dists/slink/main/binary-sparc/. They simply need to be copied (or hard-linked, if you prefer). > > More info in the sparc release-notes section 3.3. (And AFAIK this is not > > going to change in the final release-notes.) > > What exactly do you mean? If anything should be changed, tell me (and fast!). There it says that you have to install the latest slink versions of apt and dpkg "that are available in the upgrade-sparc/ dir". They'd better be there. The doc is okay, but the FTP site isn't. Regards, Anne Bezemer
Re: Test Cycle Three
On Sat, 22 Jul 2000, Anthony Towns wrote: [...] > Second, it means we need a final set of release notes for TC3. These will > need to be updated again after TC3 to document any further problems we > have, of course, but the TC3 release notes will need to be ready by around > 16:00 Monday, GMT. I already asked this some time ago, but still nothing has happened: The latest slink/sparc apt and dpkg are supposed to be available in potato/main/upgrade-sparc, as they're needed to upgrade from 2.1rX, X<=3 using CDs. They are not there yet. More info in the sparc release-notes section 3.3. (And AFAIK this is not going to change in the final release-notes.) Regards, Anne Bezemer
Re: testcycle 3
On Sat, 15 Jul 2000, Friedemann Schorer wrote: > Hi :-) > I'd like to know if it's predictable how long it will take until I > can get *.list files for the test-cycle-3-images - I have to hurry > a little for I won't have long time left with free and fast access > to the net ... I expect not before, say, wednesday next week, but maybe -release people can be more specific? Regards, Anne Bezemer
Re: Upgrade report: Test Cycle 2
On Thu, 15 Jun 2000, J.A. Bezemer wrote: > On Thu, 15 Jun 2000, Raphael Hertzog wrote: > > > Le Thu, Jun 15, 2000 at 10:42:48AM +0200, Sven Hartrumpf écrivait: > > > I just want to report a successful upgrade > > > from slink to potato-test-cycle-2 (i386) following the instructions > > > in bin1::upgrade/release-notes.en.txt and using bin CDs 1, 2 and 3. > > > > > > Removing egcc ... > > > /var/lib/dpkg/info/egcc.prerm: /usr/sbin/update-alternatives: No such > > > file or directory > > > dpkg: error processing egcc (--remove): > > > subprocess pre-removal script returned error exit status 1 > > [...] > > > The reason for this error was: > > > /usr/sbin/update-alternatives contained > > > #! /usr/local/bin/perl > > > but on my slink system, there was no /usr/local/bin/perl, just > > > /usr/bin/perl. > > > > Did you install the static dpkg stuff ? Where did you get it from ? > > > > We already had such a problem in the first version of static dpkg that we > > provided on Anne's page, but I recompiled it and it should be ok now ... > > unless the bad one has been installed... > > > > Anne, can you check if the good dpkg package has been installed by > > Richard in the upgrade-i386 directory ? > > The dpkg package in upgrade(-i386)/ is okay everywhere I can check, which > includes the Debian FTP archive and the test-cycle-2 Non-US i386 Binary-1 CD. > However, at the moment I can _not_ check the US-exportable CDs. > > The "wrong" version has (AFAIK) never been in the Debian FTP archive; it has > been on my private site only for a few days. > > Sven: Where exactly did you get your CD from? For those listening on the lists (and for the list archives): Sven mailed me personally that: 1) he got the official CDs allright, but 2) he used the "wrong" dpkg version which he had downloaded from my site a "long" time ago. Which means there's nothing to worry about. (Except semi-clueless users, but we're used to that already ;-) Regards, Anne Bezemer
Re: Upgrade report: Test Cycle 2
On Thu, 15 Jun 2000, Raphael Hertzog wrote: > Le Thu, Jun 15, 2000 at 10:42:48AM +0200, Sven Hartrumpf écrivait: > > I just want to report a successful upgrade > > from slink to potato-test-cycle-2 (i386) following the instructions > > in bin1::upgrade/release-notes.en.txt and using bin CDs 1, 2 and 3. > > > > Removing egcc ... > > /var/lib/dpkg/info/egcc.prerm: /usr/sbin/update-alternatives: No such file > > or directory > > dpkg: error processing egcc (--remove): > > subprocess pre-removal script returned error exit status 1 > [...] > > The reason for this error was: > > /usr/sbin/update-alternatives contained > > #! /usr/local/bin/perl > > but on my slink system, there was no /usr/local/bin/perl, just > > /usr/bin/perl. > > Did you install the static dpkg stuff ? Where did you get it from ? > > We already had such a problem in the first version of static dpkg that we > provided on Anne's page, but I recompiled it and it should be ok now ... > unless the bad one has been installed... > > Anne, can you check if the good dpkg package has been installed by > Richard in the upgrade-i386 directory ? The dpkg package in upgrade(-i386)/ is okay everywhere I can check, which includes the Debian FTP archive and the test-cycle-2 Non-US i386 Binary-1 CD. However, at the moment I can _not_ check the US-exportable CDs. The "wrong" version has (AFAIK) never been in the Debian FTP archive; it has been on my private site only for a few days. Sven: Where exactly did you get your CD from? Regards, Anne Bezemer
Test Cycle 2 CD images available
Both non-US and US-exportable CD images of the Second Test Cycle are available. For more details, please refer to http://cdimage.debian.org/potato_pre.html Regards, Anne Bezemer
Re: [URGENT] sparc boot-floppies rebuilt, need install when available
On Fri, 9 Jun 2000, Ben Collins wrote: > Because of a problem with the busybox tar on the boot-floppies, the sparc > base2_2.tgz, when untar'd, was causing / to become mode 644. I have put a > minor fix in boot-floppies CVS to fix this, and am recompiling the sparc > boot-floppies at this very moment. I should have them in incoming within a > few hours. Is this a sparc-specific problem, or are other arch'es also affected? (I mean, the fact that you fixed CVS does suggest so...) Regards, Anne Bezemer
Re: boot-floppies status?
On Thu, 1 Jun 2000, Richard Braakman wrote: > Just to make sure that we're all in sync: I'm currently waiting for 2.2.15 > disk sets to be uploaded for each architecture. I'm under the impression > that these are being built, and that they are necessary to start the > second test phase. Is that correct? > > I have heard that the m68k set will take at least till Sunday, mainly > because of compilation time. > > Will it be possible to use the new kernel 2.2.15-2 (currently in Incoming), > or is it too late for that? Excellent! That's the way to do it ;-) FYI, I won't be doing anything like this for this cycle. That means that "the CD people" will be waiting for your word to start creating the official test-cycle-2 images. It also means that there won't be CD images if we don't hear from you. Just to be 100% clear about the situation ;-) Regards, Anne Bezemer PS. The CD images are created one arch at a time (only source is usually coupled with i386), so it won't be a problem to say "Go create images, except for m68k" or the like. However, if you want to wait till everything is ready, that's obviously okay, too.
Re: Which kernels to keep?
On Fri, 26 May 2000, Richard Braakman wrote: > Can I remove all linux 2.2.13 and 2.2.14 related packages from the > archive prior to the second test cycle? That would zap bug#61544, > for one thing. It might also make potato one CD smaller :-) To make potato 2 CDs instead of the current 3, you'd have to remove ~500 MB ;-) Regards, Anne Bezemer
Upgrade.tar available (was Re: [dark: READ!] CD images)
On Mon, 15 May 2000, Richard Braakman wrote: > On Mon, May 15, 2000 at 04:49:54PM +0200, J.A. Bezemer wrote: > > Okay. Will a developer-signed "fake" .changes file with md5sum of the > > upgrade-all.tar do? Does it have to be placed in Incoming (on ftp-master I > > guess) or can you just fetch it from my website? > > Yes, that will do. I can fetch it, but that may be slow. It's best > if it's already on the machine. Well, it has taken some time because nobody felt like recompiling i386 apt/dpkg, but things are finally ready. The files you can (read "should" ;-) fetch are: http://panic.et.tudelft.nl/~costar/potato/upgrade-all_1.1.tar http://panic.et.tudelft.nl/~costar/potato/upgrade-all_1.1.changes All binaries in the .tar have md5sums that are signed by the Debian developer that compiled them; see the md5sum.* files. This looks a bit kludgy, but it seems the most appropriate solution, given the distributed nature of Debian. The docs have no developer-signed checksum, but you said you could verify those yourself (which is pretty easy in this case). Finally, I've signed the "fake" .changes file myself, because it essentially only covers the documentation. You can find my PGP public key (which is BTW signed by a Debian developer) at http://panic.et.tudelft.nl/~costar/pubkey.pgp I hope this is okay; if not, please tell me! Regards, Anne Bezemer
Re: [dark: READ!] CD images / Re: Formal objection: Changing how the testing of potato works would invalidate the whole test. So please don't change it.
On Mon, 15 May 2000, Richard Braakman wrote: > On Mon, May 15, 2000 at 04:49:54PM +0200, J.A. Bezemer wrote: > > Okay. Will a developer-signed "fake" .changes file with md5sum of the > > upgrade-all.tar do? Does it have to be placed in Incoming (on ftp-master I > > guess) or can you just fetch it from my website? > > Yes, that will do. I can fetch it, but that may be slow. It's best > if it's already on the machine. Okay, I'll see what I can do. I'll tell you when it's done; you can then use `wget' or the like to get it directly to ftp-master, panic.et.tudelft.nl gets >200kByte/s to about anywhere on the world (10Mbit ethernet directly to the TUDelft ATM backbone). > > apt 0.3.19 is something that I don't really know of, but it is supposed to > > fix > > very annoying deadlocks that occur only when installing/upgrading from CDs. > > AFAIK there's nothing on the boot floppies that can be broken by a new apt. > > Boot-floppies contain the apt binary. They will still use the old > binary for the initial install. Installing the new apt means that > the source for the one on the boot-floppies goes missing, and also means > a new round of autocompiling. I see now. That simple little explanations are often very enlightening ;-) > > But if you are not going to install this (Please tell me!) than I can > > arrange > > for a README on the CDs that points out the problem and where a new apt is > > available. > > I am not going to install it for this test cycle. Okay. Now this is doing business! My faith is high and rising again ;-) Regards, Anne Bezemer
Re: [dark: READ!] CD images / Re: Formal objection: Changing how the testing of potato works would invalidate the whole test. So please don't change it.
On Mon, 15 May 2000, Raphael Hertzog wrote: > Le Mon, May 15, 2000 at 01:53:52PM +0200, Richard Braakman écrivait: > > That's a bit of a Catch-22, because everyone else is WAITING for the CD > > images. > > > > > This is my current WaitingFor list: (comments are welcome!) > > > > My first comment is that this is the first I've heard of this list. > > As responsible of the debian-cd package, I hardly see all this is required > for the test cycle even it would be good to have them. Let's face it, > we're late and there are many fixes waiting in Incoming ... let's include > those fixes and start the real testing cycle in one or two days. Update: I've received reports that everything except ARM floppies, apt 0.3.19 and upgrade-stuff is okay at this moment. Maybe you can skip apt for the moment (but then SAY it, so we'll not be waiting for something that won't happen.) > > > - upgrade-alpha install (see #63890) > > > - upgrade-i386 install (see #63890) > > > - upgrade-m68k install (see #63890) > > > - upgrade-sparc install (see #63890) > > > > As you have guessed, a signature from a Debian developer is necessary to > > get something into the archive. The main exception is stuff the archive > > maintainers can review for themselves, such as documentation and small > > scripts. > > Eek... he has taken the time to do this useful work, we certainly should > include it. Can someone download, check & rebuild the packages before > uploading it ? I don't think anyone is prepared to take the trouble. But be my guest. (BTW, I didn't do alpha and m68k myself, so don't blame me for that ;-) > > > - apt 0.3.19install > > ppc > > > - libc6 re-upload & re-install > > sparc > > > - libc6-dev, 2.1.3-10.1 upload & install > > > > Installing these will invalidate the boot-floppies we already have. > > Please get in touch with the boot-floppies team if you think the > > current ones are not useful even for the first test cycle. > > They would differ from those on the boot-floppies but AFAIK it can't > do any harm ... they would just be updated at the initial install. libc6/ppc&sparc is resolved (see above). > > Yes, they are rather late with their boot-floppies. But I see > > 2.2.14 ones for ARM in Incoming now. This is still a problem because > > it's a binary upload and the boot-floppies source is still at 2.2.13. > > There have been a lot of communication problems with the ARM porters; > > I hope they can work out this one. > > Wrt debian-cd, arm will get out with non-bootable CD since ARM don't have > any CD reader ... the install is done over the network. The CD can only be > used to provide the files that would be exported over the local network. Okay. Is the /tools/boot/potato/boot-arm already done? Or do you mean that that's not needed? > > Perhaps we should find someone else to do that, since you're obviously on > > a power trip. I don't see how you got that job without being a Debian > > developer in the first place. > > I feel unconfortable too with the way he reacted, but let's not overreact > too. He has done a great job and he's only bored to see that nobody > is taking care to include the upgrade stuff he prepared ... Actually, I'm rather "angry" because (until just now) I've received NO response whatsoever on any mail directed to ftpmaster. That's obviously not the way things should work. Regards, Anne Bezemer
Re: [dark: READ!] CD images / Re: Formal objection: Changing how the testing of potato works would invalidate the whole test. So please don't change it.
On Mon, 15 May 2000, Richard Braakman wrote: > On Mon, May 15, 2000 at 09:14:54AM +0200, J.A. Bezemer wrote: > > On Sun, 14 May 2000, Josip Rodin wrote: > > > All boot-floppies are ready (except ARM, but that's an opaque thing :), > > > and > > > the CD images have been created. So, we can test potato installation and > > > upgrade with those. > > > > As advertised on cdimage.debian.org, there are (still) _NO_ official CD > > images > > of the first test cycle. > > > > The reason is that we are still WAITING for several things to happen. We are > > not going to release officially broken CDs, because broken CDs can't be > > evaluated. > > That's a bit of a Catch-22, because everyone else is WAITING for the CD > images. > > > This is my current WaitingFor list: (comments are welcome!) > > My first comment is that this is the first I've heard of this list. This list exists as of last saturday for my private reference ;-) > m68k: > > - 2.2.13 floppies install > > I did this just now. Great! > > - upgrade-alpha install (see #63890) > > - upgrade-i386 install (see #63890) > > - upgrade-m68k install (see #63890) > > - upgrade-sparc install (see #63890) > > As you have guessed, a signature from a Debian developer is necessary to > get something into the archive. The main exception is stuff the archive > maintainers can review for themselves, such as documentation and small > scripts. Okay. Will a developer-signed "fake" .changes file with md5sum of the upgrade-all.tar do? Does it have to be placed in Incoming (on ftp-master I guess) or can you just fetch it from my website? (And maybe you could also sign it yourself... ;-) > > (Confirmed 05/13) > > What does this mean? I've been doing some inquiries for CD-readiness (see -$ARCH list archives), and this means that someone on that list confirmed that my WaitingFor entry was correct. > > - apt 0.3.19install > ppc > > - libc6 re-upload & re-install > sparc > > - libc6-dev, 2.1.3-10.1 upload & install > > Installing these will invalidate the boot-floppies we already have. > Please get in touch with the boot-floppies team if you think the > current ones are not useful even for the first test cycle. apt 0.3.19 is something that I don't really know of, but it is supposed to fix very annoying deadlocks that occur only when installing/upgrading from CDs. AFAIK there's nothing on the boot floppies that can be broken by a new apt. But if you are not going to install this (Please tell me!) than I can arrange for a README on the CDs that points out the problem and where a new apt is available. libc6/ppc is broken according to http://www.debian.org/Lists-Archives/debian-release-0005/msg00024.html "This breaks dependencies on almost everything." but I don't know (not Confirmed) if this has been fixed already. libc6-dev/sparc is broken, according to Ben Collins in a private mail. "Actually right now I need to fix up libc6-dev, since it's broken. Once you see libc6-dev 2.1.3-10.1, it's fine :)" > > arm ??? > > - floppies ??? > > ARM will not release with 2.2 as there is no way to install it. > > Maybe 2.2.1 if people are providing boot-stuff. > > Yes, they are rather late with their boot-floppies. But I see > 2.2.14 ones for ARM in Incoming now. This is still a problem because > it's a binary upload and the boot-floppies source is still at 2.2.13. > There have been a lot of communication problems with the ARM porters; > I hope they can work out this one. Okay, this is good. > > We will NOT be releasing official CD images before all this has been > > resolved. > > (And yes, it's me who controls that, since I'm the webmaster of > > cdimage.debian.org.) > > Perhaps we should find someone else to do that, since you're obviously on > a power trip. I don't see how you got that job without being a Debian > developer in the first place. I seem to be having a habit of doing things that no-one else does. This regards the cdimage webpages, which Phil Hands was very happy handing over to me because he just didn't (doesn't) have time for them. Same for upgrade stuff. Same for communication with porters regarding CD-image readiness. > > I'd finally like to see some action from ftpmaster/release manager (i.e. > > dark). He's being _extremely_ communicative to us CD people :-( > > Why, thank you. I should note that I am _not_ ftpmaster, however. I > am a me
[dark: READ!] CD images / Re: Formal objection: Changing how the testing of potato works would invalidate the whole test. So please don't change it.
On Sun, 14 May 2000, Josip Rodin wrote: [...] > > All boot-floppies are ready (except ARM, but that's an opaque thing :), and > the CD images have been created. So, we can test potato installation and > upgrade with those. As advertised on cdimage.debian.org, there are (still) _NO_ official CD images of the first test cycle. The reason is that we are still WAITING for several things to happen. We are not going to release officially broken CDs, because broken CDs can't be evaluated. This is my current WaitingFor list: (comments are welcome!) -- alpha - apt 0.3.19install - upgrade-alpha install (see #63890) (Confirmed 05/13) i386 - apt 0.3.19install - upgrade-i386 install (see #63890) m68k - apt 0.3.19upload & install - 2.2.13 floppies install - upgrade-m68k install (see #63890) (Confirmed 05/14) ppc - apt 0.3.19install - libc6 re-upload & re-install sparc - apt 0.3.19install - libc6-dev, 2.1.3-10.1 upload & install - upgrade-sparc install (see #63890) (Confirmed 05/13) arm ??? - floppies ??? ARM will not release with 2.2 as there is no way to install it. Maybe 2.2.1 if people are providing boot-stuff. -- We will NOT be releasing official CD images before all this has been resolved. (And yes, it's me who controls that, since I'm the webmaster of cdimage.debian.org.) I'd finally like to see some action from ftpmaster/release manager (i.e. dark). He's being _extremely_ communicative to us CD people :-( Regards, Anne Bezemer
Contents for potato/main/upgrade-i386
Hi! This may seem a little weird request, but as I'm not (yet) a Debian developer, I can't do it any other way (or can I?). As posted to -devel, I've been looking into upgrading procedures, with very promising results. Basically, my work is the _only_ way to do upgrades from a CD set (on -cd we've received multiple reports that other ways of upgrading require quite some magic from very experienced users). It's obvious that this must go on the CDs of the first test cycle, since otherwise only new installs can be tested, and not upgrades. My work can't break anything in the archive, since it's not really a part of it. Therefore, speaking for the CD team, I ask you to create a directory debian/dists/potato/main/upgrade-i386 with contents found in http://panic.et.tudelft.nl/~costar/potato/upgrade-i386.tar Please tell me when it's done, or if there are any problems. Porters to other architectures have been informed; when ports become available, I'll put them on my site and send you another request. Regards, Anne Bezemer
Re: http://www.debian.org/Bugs/db/63/63485.html
On Fri, 5 May 2000, David Huggins-Daines wrote:
> "J.A. Bezemer" <[EMAIL PROTECTED]> writes:
>
> > How long will it take to get these things fixed? ("large parts" usually need
> > "much time".) This test cycle will only take about 2/3 weeks(??) so you
> > might
> > not even have things ready by the end of the cycle.
>
> It's already fixed. The reason large parts of the system were broken
> is just because the ld.so cache was broken, and therefore the only
> shared libraries that could be loaded were ones in /lib or /usr/lib
> (unless RPATH was used, which is against policy...)
>
> The fix was a one line source change to ldconfig :-)b
Okay, so only one very-essential package needs to be updated for only one
architecture? Then I see two options:
1. The new package is installed in the archive ASAP. This is fine, since
we're waiting for the new boot-floppies anyway.
2. The new package is made available at some weblocation (FTP/HTTP), and
we'll either put a notice in some README on the CD or somewhere on
the cdimage website.
I prefer 1. It can't break more than what's already broken ;-)
And you can take this as "the official opinion" of the CD team.
Regards,
Anne Bezemer
Re: http://www.debian.org/Bugs/db/63/63485.html
On Fri, 5 May 2000, Richard Braakman wrote:
> On Thu, May 04, 2000 at 04:23:49PM -0400, David Huggins-Daines wrote:
> > Richard, sorry to bother you with this sort of stuff again, but if we
> > could make an exception for this, that would be great.
> >
> > We can't very well test Debian on Alpha if large parts of the system
> > (basically anything X related, since only libraries in /lib and
> > /usr/lib will work) are non-functional.
How long will it take to get these things fixed? ("large parts" usually need
"much time".) This test cycle will only take about 2/3 weeks(??) so you might
not even have things ready by the end of the cycle.
Regards,
Anne Bezemer
Re: [SLINK] Quake2* needs to be pulled
On Wed, 3 May 2000, Adrian Bunk wrote: > Yust to remember there's bug #57301 that the quake2* packages have to be > removed from slink (in 2.1r6). This has been done already (maybe your mirror is out of sync?). Bug should be closed. As a side note, non-free is not officially a part of Debian, so it also isn't "officially released". Bugs against non-free pkgs should therefore not be considered RC. (i.e. we're not going to delay a release because of problems in a package that isn't even going to be officially released.) Regards, Anne Bezemer
Boot floppies okay? (was Re: First Test Cycle starts today)
On Tue, 2 May 2000, Richard Braakman wrote: > The first official Test Cycle has started today. It's not entirely my > doing, but such things gather momentum :-) > > The next few days will be dedicated to getting test-ready boot-floppies > and CD images. I will only make changes to frozen that are necessary > for getting those ready. Are the boot-floppies currently on master (2.2.12-2000-04-26) final for this test cycle, or do we have to wait for a new version? (As soon as someone tells me current floppies are okay, we'll go making CD images.) Regards, Anne Bezemer
2.1r6 & Re: Uploaded imap 4.5-0slink3 (source i386) to master
(Ftpmasters:) How are things with 2.1r6? Can you give any indication when it'll be done? And what about the very new imap (below)? Seems to be available for all arches. Regards, Anne Bezemer On Tue, 25 Apr 2000, Jaldhar H. Vyas wrote: > imap - remote mail folder access server for Pine and others > ipopd - POP2 and POP3 servers from UW > Changes: > imap (4.5-0slink3) stable; urgency=high > . >* SECURITY UPDATE: Backported the fixes from 4.7c that address the buffer > overflow problems mentioned on BugTraq.
Re: Preparing for first test cycle
On Thu, 20 Apr 2000, Ben Collins wrote: > On Fri, Apr 21, 2000 at 08:18:31AM +1000, Herbert Xu wrote: > > On Thu, Apr 20, 2000 at 12:30:27PM -0400, Ben Collins wrote: > > > > > > I think we need to get a kernel-source-2.2.15 package in right now, even > > > if it means that it is actually a 2.2.15-pre19 (the latest pre). This way > > > we can start building images, and have boot-floppies using it. I'm very > > > sure it will release before we do. > > > > > > Herbert, is this possible for you? > > > > OK. It will be called kernel-foo-2.2.14 2.2.15-pre19-1. > > Uggh, can you make it kernel-foo-2.2.15_2.2.15-pre19-1? This way in the Hmmm. And then how to automatically upgrade from 2.2.15-pre19-1 to, say, 2.2.15-2 ? `p' comes _after_ `2', isn't it? Maybe kernel-foo-2.2.15_2.2.14-15pre19-1 would be a better idea? ~ Regards, Anne Bezemer
Re: Please release 2.1r6
On Thu, 20 Apr 2000, Richard Braakman wrote: > On Thu, Apr 20, 2000 at 12:33:33AM +0200, J.A. Bezemer wrote: > > ATTN ftpmasters: > > > > To be perfectly clear: contrary to the Subject: line, 2.1r6 should _not_ be > > released right after the included "wishlist" has been processed. > > > > According to release procedures we're currently trying out, the > > "Debian2.1r6" > > symlink and the entry in the global ChangeLog should be made _only_ when > > you're explicitly asked to do so (i.e. after CD images have been > > successfully > > made, which will take a week or so). > > And have slink change silently and unannounced? I think not. > We don't do that. I think you're misunderstanding me. Of course the global ChangeLog should be updated with information on upgrades of individual packages; the only thing that has to wait a while is the "--- Debian 2.1 r6 is released.\n`date`" line (and the symlink -- the presence of which I can't really understand anyway) The fundamental reason for this is simple: we do not know if everything needed for r6 has been done yet! And we _can't_ know until everything we _do_ know has actually been done. Look at it in another way: what we're basically trying to do is implementing a mini version of your own "release cycles" for the stable branch. Just because `stable' has _shown_ itself to become slightly UNstable with every subrelease, needing patches-to-patch-old-patches in the next subrelease. This always was about 1 or 2 packages. This time, we'll allow them (if any) to be fixed _before_ the actual release is announced, which increases the quality of the end product. There will be _no_ "silent and unannounced" changes; the individual ChangeLog entries will be there for anyone to check, but the official announcements will just appear slightly later. Looking at past events, that shouldn't be any problem: there is (still!) no r5-is-released entry in the global ChangeLog, IIRC there has never been an r3 symlink, and r2 never had an announcement/press release. Even better: this time, the announcements can also mention the availability of CD images -- which hasn't been possible for any earlier release. Which stresses an important point: the Debian distribution isn't anymore only about FTP archives, but CDs are becoming increasingly important. This is taken care for nicely with the potato test cycles, but as soon as `stable' things are concerned CDs seem to be forgotten... Regards, Anne Bezemer
Re: Please release 2.1r6
On Wed, 19 Apr 2000, Vincent Renardias wrote: > hello, > > Here's the list (attached) of the packages that should be added to slink > before to release 2.1r6. ATTN ftpmasters: To be perfectly clear: contrary to the Subject: line, 2.1r6 should _not_ be released right after the included "wishlist" has been processed. According to release procedures we're currently trying out, the "Debian2.1r6" symlink and the entry in the global ChangeLog should be made _only_ when you're explicitly asked to do so (i.e. after CD images have been successfully made, which will take a week or so). And another thing: several packages in the "wishlist" are _not_ in Incoming, but rather in slink-proposed-updates. They need to be moved from there to the main archive. Regards, Anne Bezemer
ftp.debian.org 2.1r5/6 issues: w3-el, security and ChangeLog
Package: ftp.debian.org Version: n/a Severity: critical It has been a _long_ time since 2.1r5 was ""released"" and multiple mails have gone to many addresses. Still issues are not resolved. So I'll try it this way: For the generation of the Official Debian CD images the following things are of CRITICAL IMPORTANCE: 1) Install slink-proposed-updates/w3-el* in the main slink archive 2) Install anything waiting on security.debian.org (latest is mtr_0.28-1, which has not yet been installed, since 9 March!) 3) Make a note in slink/ChangeLog that version 2.1r6 () has been released NOW. And I _mean_ r6, because we can't possibly make r5 images any more due to intermediate security updates etc. If I don't see any action in a reasonable time (a few days!), I will continue sending regular reminder messages. Sorry, I don't like to do things this way either, but all other options have been unsuccessful. Regards, Anne Bezemer (unofficial representative of the debian-cd team)
Re: Debian 2.1r5
On Thu, 23 Mar 2000, Wichert Akkerman wrote: > Previously Jordi wrote: > > I thought 2.1r5 had been released already, but I can't find it on the ftps. > > The changelog does not mention a release neither so I guess it didn't > > happen. > > Will it be released? > > as far as I know it has been released, but nobody has done an > announcement about it. Is there a 2.1r5 symlink? We consider anything to be official ONLY if it is mentioned in the ChangeLog. Everything else has been (very!) unreliable in the past. NOTE: Has the new w3-el-e20 already been installed?? (The "old"==current? version was/is breaking CD creation.) Regards, Anne Bezemer
Re: 2.1r5
On Thu, 16 Mar 2000, Philip Charles wrote: > Still broken!!! What exactly is broken? Regards, Anne Bezemer
RE: 2.1r5 Master file
On Sun, 12 Mar 2000, Philip Charles wrote: [...] > Questions. > What is the status of the present 2.1r5? I asked this before, but didn't get any answer. Release-people or ftpmaster: IF we have 2.1r5 THEN mention it in the ChangeLog ELSE what are we waiting for? > Are official CDs going to be produced? I suppose so. But only AFTER it's mentioned in the ChangeLog. > Is there to be any official announcement? There should be. (Release people: hint hint!) Regards, Anne Bezemer
Re: 2.1r5 Master file
On Tue, 7 Mar 2000, Philip Charles wrote: > I notce that 2.1r5 is out with new boot-disks and there are quite a few The overall ChangeLog does not yet mention that 2.1r5 is released. Release people: does this mean that we DO or DON'T have 2.1r5 at this moment?? And what about the two sets of i386 and three(!) of m68k boot disks? (Obviously only one will end up on the CDs, but which one? I.e. there should be only 1 version on FTP) Regards, Anne Bezemer
Re: Need for Debian 2.1 r5
On Tue, 29 Feb 2000, Gergely Madarasz wrote: > On Mon, 28 Feb 2000, Vincent Renardias wrote: > > > > > On Mon, 28 Feb 2000, Santiago Vila wrote: > > > > > The stable release of Debian which is distributed in CDs does not have a > > > working TeX (!). > > > > > > This is fixed in tetex-bin_0.9.981113-3, uploaded nearly three months ago, > > > but unfortunately this is still in the proposed-updates directory. > > > > > > Are there any plans to release Debian 2.1 r5 sometime soon? > > > > I sent the package list as well as the release notes to > > [EMAIL PROTECTED] about 10 days ago, but nothing seem to have happened > > yet... > > Btw it would be nice to have the latest security fixes included, like > htdig and nmh If they are on the FTP sites by the time r5 is released, they will end up on the CDs, too. Regards, Anne Bezemer
Re: 2.1r5 definitive list...
On Tue, 15 Feb 2000, Vincent Renardias wrote: > unless anyone has objections, my package list for 2.1r5 is definitive... > > pkg list: http://www.debian.org/~vincent/2.1r5.txt There are still a few ($ARCH MISSING) things; if nothing gets done for them, don't forget to change these notes to (no $arch). BTW & IIRC, Phil Hands, who does the CD images, is supposed to be skiing this week. Regards, Anne Bezemer
Re: update on 2.1r5 status...
On Wed, 9 Feb 2000, Roman Hodek wrote: > > > Are there still compiles pending, or can I release 2.1r5 asis? > > Here the m68k answer: Just to be 100% sure: the m68k boot floppies are okay now? Regards, Anne Bezemer
Official CD names?
[Cc:'d debian-release because there might be some people who care about how Debian CDs will end up in the stores ;-] Hi! Joel Goldberger wrote me with some questions, and one of them was how the Official CDs should be named/labeled. Below is what I'm currently doing myself. - Does anyone have a better suggestion? - Should we have "official names"? (i.e. "recommended names" in the CDimages FAQ section) Regards, Anne Bezemer On Wed, 19 Jan 2000, J.A. Bezemer wrote: > About identification: my personal favorite is > >Debian GNU/Linux 2.2 > Official i386 Binary-1 > > If there is enough space, the first line could be > >Debian GNU/Linux 2.2 "Potato" > > And variations of the second line: > > Official alpha Binary-2 > Official m68k Binary-3 > Official sparc Binary-2 > Official ppc Binary-1 > Official Source-1 > > etc.
Re: Updated list of packages of 2.1r5
On Mon, 10 Jan 2000, Wichert Akkerman wrote: > Previously Vincent Renardias wrote: > > [Vincent 1999/12/20] > > package : lprng > > version : 3.5.2-2.1 > > architectures: sparc only > > issue: fix dependency problem preventing the creation of sparc CDs > > Euh, what problem? This seems to be the same version that is also > on security.debian.org and I don't want to have a broken version > there.. IIRC, I did report this dependency problem to either you personally or [EMAIL PROTECTED] (which should have reached you too) only some hours after the security fix was released... Regards, Anne Bezemer
M68K boot floppies / CDs
My customers want m68k r4 CDs and they want them NOW. Please take whatever action is necessary to provide them ASAP. See threads http://www.debian.org/Lists-Archives/debian-68k-9912/msg00056.html and http://www.debian.org/Lists-Archives/debian-68k-9912/msg00087.html Regards (and being a bit annoyed), Anne Bezemer (.nl CD vendor)
Re: list of 2.1r4 changes (was: Re: Last call for updated non-i386 packages.)
On Mon, 13 Dec 1999, Wichert Akkerman wrote: > Anyway, the 2.1r4 release will happen tomorrow (Monday). I have all I didn't see any official announcement. If things are ready, please post to debian-cd (and to Phil Hands <[EMAIL PROTECTED]> personally!) so we know that CDs can be made. Regards, Anne Bezemer
Re: [non-i386 people needed] Proposed packages for 2.1r4
On Thu, 25 Nov 1999, Wichert Akkerman wrote: > Previously Joel Klecker wrote: > > Strongly disagree, 2.2.5 has a lot of bugs, some of them security related. > > The same can be said for 2.2.13 btw. I don't follow kernel development, but 2.2.13 has been out since 20 Oct, and >1 month without update (or errata on www.linux.org.uk) is really long for any stable kernel. So I think "a lot of bugs" in 2.2.13 is a little overstated. Correct me if I'm wrong... Regards, Anne Bezemer
Re: [non-i386 people needed] Proposed packages for 2.1r4
On Thu, 25 Nov 1999, Wichert Akkerman wrote: > Previously J.A. Bezemer wrote: > > I don't follow kernel development, but 2.2.13 has been out since 20 Oct, and > > >1 month without update (or errata on www.linux.org.uk) is really long for > > >any > > stable kernel. So I think "a lot of bugs" in 2.2.13 is a little overstated. > > Correct me if I'm wrong... > > > > There have been frequent updates, look at all the 2.2.14-pre patches. Of course, updates. But are those updates fixing bugs? Critical bugs? Security bugs? Or are they only adding features? IMHO&AFAIK: some, very few, none, and most, respectively. Let me just say: 1) 2.2.13 is definately _much_ better than 2.2.5; 2) if you don't include 2.2.13 "because there are updates" you can't include any kernel at all because updates are almost daily; 3) we're dedicated to providing some quality of service to our users, isn't it? And now we're discussing this: there is 2.0.38 which _does_ fix security bugs in 2.0.36. And yet we're still using 2.0.36 for our "stable" systems..? Regards, Anne Bezemer
Re: [non-i386 people needed] Proposed packages for 2.1r4
On Thu, 25 Nov 1999, Joel Klecker wrote: > At 16:11 + 1999-11-24, Vincent Renardias wrote: > > [*] kernel-source-2.2.5_2.2.5-2_i386.changes > > - needed for SMP machines, fixes lots of bugs, source-only package. > > [OK] > > Strongly disagree, 2.2.5 has a lot of bugs, some of them security related. Hmmm. Is adding _source_ of 2.2.13 (as in potato) a problem? AFAIK, this should work okay with slink, no dependency problems. And, _binary_ of 2.2.13? Regards, Anne Bezemer
Re: Unofficial Y2K update for slink.
On Tue, 23 Nov 1999, Vincent Renardias wrote: > > However, we may try to release a "slink-and-a-half" later featuring a more > extensive update (At least: 2.2 based, XFree 3.3.5, October GNOME) Ehh, could you specify "later" more precisely? Otherwise "later" = "potato"... > 2/ non-i386 people to recompile for m68k, sparc, alpha. Please this time MAKE SURE that ALL packages are okay before officially releasing r4. I hope you remember that there were no 2.1r3 alpha, sparc and m68k CDs due to dependency problems. I don't even know if this is solved already. Regards, Anne Bezemer
2.1.1 and 2.2
How are things with 2.1.1 (="stable update" w/ new X,gnome,...)? Release date? And will potato still freeze on 1 nov? Regards, Anne Bezemer (.nl CD vendor)
Re: version numbering (was Re: Debian 2.1 stable update)
On Sat, 28 Aug 1999, Adam Di Carlo wrote: > Wichert Akkerman <[EMAIL PROTECTED]> writes: > > > Previously Vincent Renardias wrote: > > > 2.1r3 is the next release of slink; > > > > Right. It's the third point-release of slink, and point-release only > > have security-fixes and very important bugfixes. > > > > IMHO the stable update should be 2.2 and then potato can be either 2.3 > > or 3.0, depending on what Richard wants. > > Well, 2.1.1 is another alternative. Personally, I prefer 2.1.1 > (instead of 2.1) since it doesn't fit the bill of a full update like > 2.0 -> 2.1 was. I agree with that (but who am I...) But IF it's going to be 2.2, don't forget that /etc/debian_version in the base-files package has to be updated also. I didn't see that in the "TODO" list, so I thought I'd better mention it ;-) IIRC, 1.3.1 still had 1.3 in /etc/debian_version, so if it's going to be 2.1.1, there seems no need to update base-files. Regards, Anne Bezemer (CD vendor in The Netherlands)
