About the improving of 1st debian CD (there are some 'duplicates',etc.)
Hi again, I got no answer to my suggestions about improving 1st debian CD and desktop task :( Maybe debian-cd maintainer can say if 1st CD would include more packages for beginners: hardware autodetection packages, user-friendly package managers, user-friendly configuration tools, etc. and would desktop task be splited into GNOME desktop and KDE desktop tasks ? I think aptitude and discover must be installed as default in debian woody. I'm attaching my earlier letter (for clarity): -Earlier letter I found some 'duplicates' in the 1st debian CD: emacs20-dl_20.7-14.3_i386.deb - ~10MB emacs20_20.7-13.1_i386.deb - ~9MB emacs21_21.2-1_i386.deb - ~12MB I understand - emacs is a very goot thing, but I think 3 different versions of emacs in the1st CD is a luxury. Maybe only one, newest version, would be enough for the 1st CD? Then ~20 Mb will be freed from 1st CD. I think in the first CD should also be: - some good apt frontends. Now there is only dselect in 1st CD. I think there should be more user-friendly apt frontends: at least one text-mode apt frontend, like aptitude (1MB) and one graphical, like stormpkg (~100 kb), see woody release notes - http://www.debian.org/releases/woody/i386/release-notes/ch-whats-new.en.html#s-newdistro - ... To replace the aging, much-maligned, yet still popular dselect, many apt frontends have been in development during the woody release cycle. Interested users should investigate the aptitude package ... hardware, better autodetection support; - most users need automatic hardware detection system (discover - ~150kb, and maybe kudzu + sndconfig) and user-friendly network configuration tool (etherconf - ~20kb) packages; - User-friendly configuration tools, developed by Progeny: python-configlet (35kb), configlet-frontends (20kb), timezoneconf (30kb), localeconf (20kb); - gnumeric (because KSpread is already in 1st CD, 3MB + some depended packages); - xservers-v3.3.6 (14MB). All these packages (except maybe xservers-v3.3.6) should fit in 1st CD if we remove some 'duplicates' (like 3 versions of emacs) and maybe some not very useful for beginners packages (like erlang_8.0-4_i386.deb - 13MB or libopenh323-dev_1.7.4-6_i386.deb+ libopenh323-dbg_1.7.4-6_i386.deb - 7MB) I think in 1st CD shouldn't be a lot of *-dev or *-dbg (debug version) packages. It would be very nice if small and fast window-manager IceWM would be in 1st CDd too, but it is not a necessity. In my opinion task Desktop Environment should be spitted into 2 tasks: GNOME Desktop Environment and KDE Desktop Environment, because most users use mainly one - GNOME or KDE and just sometimes some programs from other. The installation of Debian will be much more user-friendly and Debian OS will be simpler to use (especially for the beginners), if the packages, mentioned above, are included in the 1st Debian CD. Mantas Kriauciunas [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
One comment: In pre6-pre7-package.diff.txt I see: -Non-US:pool/non-US/main/e/erlang/erlang_8.0-4_i386.deb -Non-US:pool/non-US/main/e/erlang-slang/erlang-slang_1.0-3_i386.deb -Non-US:pool/non-US/main/o/openh323/libopenh323-dbg_1.7.4-6_i386.deb -Non-US:pool/non-US/main/p/python-popy/python1.5-popy_2.0.8-2_i386.deb -Non-US:pool/non-US/main/p/python-popy/python2.2-popy_2.0.8-2_i386.deb which seems to indicate that some of the bigger packages in CD #1 were there just because we wanted to include the whole of non-US in the first CD, not because of their popularity. If we accept that a first non-US CD does not necessarily have to contain the whole of non-US, we could change the way of generating the CDs from Including most of non-US in CD#1, excluding big packages to Including packages from non-US in CD#1 according to their popularity, as we already do for main packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
On Thu, 2002-05-30 at 10:08, Santiago Vila wrote: One comment: In pre6-pre7-package.diff.txt I see: -Non-US:pool/non-US/main/e/erlang/erlang_8.0-4_i386.deb -Non-US:pool/non-US/main/e/erlang-slang/erlang-slang_1.0-3_i386.deb -Non-US:pool/non-US/main/o/openh323/libopenh323-dbg_1.7.4-6_i386.deb -Non-US:pool/non-US/main/p/python-popy/python1.5-popy_2.0.8-2_i386.deb -Non-US:pool/non-US/main/p/python-popy/python2.2-popy_2.0.8-2_i386.deb Doh! I noticed that, but the implications didn't occur to me. which seems to indicate that some of the bigger packages in CD #1 were there just because we wanted to include the whole of non-US in the first CD, not because of their popularity. If we accept that a first non-US CD does not necessarily have to contain the whole of non-US, we could change the way of generating the CDs from Including most of non-US in CD#1, excluding big packages to Including packages from non-US in CD#1 according to their popularity, as we already do for main packages. But then we need a 2_NONUS, or perhaps we just arrange for all packages to be in popularity order, and have as many non-US CDs as it happens to take depending where the packages land. I think that's a big enough change to leave for a later release, unless someone else is confident that they can change this without breaking things. I think my next cut will allow erlang and xspecs back in CD1, to see what that gives us. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
On 30 May 2002, Philip Hands wrote: On Thu, 2002-05-30 at 10:08, Santiago Vila wrote: If we accept that a first non-US CD does not necessarily have to contain the whole of non-US, we could change the way of generating the CDs from Including most of non-US in CD#1, excluding big packages to Including packages from non-US in CD#1 according to their popularity, as we already do for main packages. But then we need a 2_NONUS, or perhaps we just arrange for all packages to be in popularity order, and have as many non-US CDs as it happens to take depending where the packages land. I think that's a big enough change to leave for a later release, unless someone else is confident that they can change this without breaking things. Hmm, considering that woody has already 8 binary CDs (i.e. 7 US CDs and 1 non-US one) a 2nd NONUS CD would not be such a big change. [ Of course, having as many non-US CDs as it happens to take depending where the packages land is out of question. Please do not even consider that... ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First try on Hurd-H4-CD1 jigdo files
On Wed, May 29, 2002 at 01:53:17PM +0200, Patrick Strasser wrote: Richard Atterer wrote: For other files (packages on the CD that become outdated and disappear from the main mirror), one possibility is to set up an md5sum-based fallback directory; for a MD5Sum=http://foo/; entry in the jigdo file, jigdo will first look in the main mirror for a file, then for at That's what Attila does in debain-superseded, AFAIK. Quite big, 9000 packages. In case the size is really a problem, note that you can always refine the script used to generate the debian-superseded contents. Attila just puts *all* outdated files there (because his CDs actually use most files, and because it's easy to code). However, nothing prevents you from writing a script which only puts those files into the superseded dir which are actually referenced by the template file. Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: About the improving of 1st debian CD (there are some 'duplicates',etc.)
Mantas K. wrote: I got no answer to my suggestions about improving 1st debian CD and desktop task :( Here is one (not official, since I am not the debian-cd maintainer). The current CDs are made basically using the data produced by the popularity-contest package. Debian is for everybody, not just for beginners. If package A is more popular than package B, then A is more likely to be included in CD#1, even if it's less user-friendly than B. In my opinion this principle is basically right and should not be changed. I think it's better that we do not try to second-guess our user's needs based on abstract concepts like user-friendliness. We can measure how many people use a package regularly or how many people have it installed, but we can't measure the user-friendliness. Regarding emacsen: emacs20-dl has just been excluded from CD #1. emacs20 and emacs21 are still both very popular. [ BTW: I use emacs20 myself and do not consider it a duplicate of emacs21 ]. You mention also some big packages in non-US. I agree that it would be nice to have them in the second CD, but this would mean a 2nd non-US CD at least. AFAIK, the implications of that have yet to be evaluated. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
Previously Philip Hands wrote: The good news is that TeX is in, the bad news is that packages such as xdm, xfs xterm are out. This seems bad, but I suppose since gdm kdm are on there, and one can survive without xfs, and gnome-terminal is in, we could actually live without those, but will the resulting lack of x-window-system cause a problem with the tasks? Breaking X is imho a much worse than getting TeX on CD1. gnome-terminal is definitely not a replacement for xterm. Wichert. -- _ [EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
On Thu, 30 May 2002, Wichert Akkerman wrote: Previously Philip Hands wrote: The good news is that TeX is in, the bad news is that packages such as xdm, xfs xterm are out. This seems bad, but I suppose since gdm kdm are on there, and one can survive without xfs, and gnome-terminal is in, we could actually live without those, but will the resulting lack of x-window-system cause a problem with the tasks? Breaking X is imho a much worse than getting TeX on CD1. gnome-terminal is definitely not a replacement for xterm. Well, I refuse to think that we have to choose between X and TeX... What I don't understand is the reason xterm, used regularly by 445 people in the pop-con goes to second CD when you move xspecs (used regularly by 0 people) to the second CD. BTW: Please note that the x-window-system meta-package is not the one normal people would install: This metapackage provides substantially all the components of the X Window System as developed by the XFree86 Project, as well as a set of historically popular accessory programs. The development and debugging libraries are not provided by this metapackage. This package depends on xspecs so it's certainly not for normal users. Normal users would use x-window-system-core plus some x-window-manager plus some x-terminal-emulator instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CD release announcement
Hello, this is my first attempt at a note to mail to all CD mirror admins. Doubtlessly it is inaccurate in some places - please correct any mistakes. Is there any important issue which I missed, and which the mirror maintainers should know about? Where will the official 3.0r0 jigdo files be placed? I think it would be wise *not* to use cdimage/jigdo-area for that, because - ATM jigdo-mirror will attempt to re-generate any non-existent images every time it is run. IOW, if mirror admins mirror jigdo-area/ and then let jigdo-mirror loose on it, the script will work several minutes on each pre-release image, only to realize that it is unable to re-create it. - When 3.0r0 is out and Phil starts making 3.0r1 pre-releases, all mirrors will pick those up, attempt to create them, maybe overflow their disks etc... not desirable! Another related question: At the moment, jigdo-mirror does not allow you to filter which images it should create and which not. People using it will only be able to mirror all 88 images, there's no way to prevent it from creating e.g. binary-3 to binary-7, or the non-us CDs. Should I modify it to allow such filtering? -- Release of CD images for the Debian Linux 3.0r0 release (woody) ~ This mail was sent to you because your address is stored in our database of Debian CD mirror servers and your server is listed on http://www.debian.org/CD/http-ftp/. Note that if you reply to this mail, your answer will by default be sent to [EMAIL PROTECTED], a public mailing list. [Reply-To will be set up accordingly.] Within the next weeks, Debian 3.0 woody will be released and new CD images will be made available. Here is some information about the release of the new CD images. Size requirements ~ [Please correct numbers - they may be completely wrong!] The images of the current stable distribution (potato) need 13 GB of disc space for 22 CD images. In contrast to this, the full set of woody CDs needs about 53 GB for 88 CD images! [The 88 is 8*10 + 8 source.] This increase is due to the larger number of CDs (8, used to be 3) per architecture, and the larger number of architectures (10, used to be 6). Because we expect that most mirror admins do not want to dedicate so much space to CD images, by default not all CD images will be made available, only a subset which will take about 21 GB for 34 CD images. (We omit CDs 3-8 for the 9 non-Intel architectures.) Required setup changes on your mirror ~ You do not need to change anything about your current mirror setup if you want to distribute the default set of 34 CD images - the old debcdmirror scheme as well as rsync or FTP/HTTP mirroring will continue to work. [Is this correct? Will PIK-style .list files be generated? Will the rsync/http/ftp paths stay the same?] However, consider changing the mirror setup as described below if one of the following applies: - You want to update your mirror quickly after the release. In our experience, the master site will be under extremely heavy load immediately after the release, possibly even to the point of not being reachable. - You already have a local regular Debian FTP mirror. In this case, the mirroring can be made much more efficient now. - You want to offer the full set of 88 CD images. New way of mirroring: jigdo-mirror ~~ jigdo is a new way of generating Debian CD images. A local (=same machine) Debian FTP mirror is required for this. Additionally, if the mirror does not run Linux on Intel, you'll have to compile jigdo yourself - you need a recent C++ compiler (e.g. GCC 2.95) for this. The jigdo-mirror script to automate mirroring of Debian's CD images is new and needs more testing - if you can, please try it out now on the 3.0 pre-release images and report any success/failure to us! jigdo-mirror takes packages from the mirror as well as special files with .jigdo and .template extensions, and assembles the CD images from all this information. This makes it similar to how debcdmirror works, with the important difference that jigdo does not rely on rsync to produce the final image. A jigdo-based mirror requires - setting up a normal Debian FTP mirror http://www.debian.org/mirror/ - setting up HTTP mirroring of the .jigdo/.template files - setting up a cronjob which runs jigdo-mirror at regular intervals - configuring jigdo-mirror. This should be easy, it hardly needs more information than the paths to the .jigdo/.template files and your Debian FTP mirror. Links ~ Debian on CD: http://www.debian.org/CD/ Retrieving Debian CDs with jigdo: http://www.debian.org/CD/jigdo-cd/ rsync path for stable CD images: rsync://cdimage.debian.org/debian-cd/ (Try not to mirror directly from the master site if possible.) HTTP access is
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
On Thu, 30 May 2002, Santiago Vila wrote: On Thu, 30 May 2002, Wichert Akkerman wrote: Previously Philip Hands wrote: The good news is that TeX is in, the bad news is that packages such as xdm, xfs xterm are out. This seems bad, but I suppose since gdm kdm are on there, and one can survive without xfs, and gnome-terminal is in, we could actually live without those, but will the resulting lack of x-window-system cause a problem with the tasks? Breaking X is imho a much worse than getting TeX on CD1. gnome-terminal is definitely not a replacement for xterm. Well, I refuse to think that we have to choose between X and TeX... What I don't understand is the reason xterm, used regularly by 445 people in the pop-con goes to second CD when you move xspecs (used regularly by 0 people) to the second CD. BTW: Please note that the x-window-system meta-package is not the one normal people would install: This metapackage provides substantially all the components of the X Window System as developed by the XFree86 Project, as well as a set of historically popular accessory programs. The development and debugging libraries are not provided by this metapackage. This package depends on xspecs so it's certainly not for normal users. We are operating with two sets of constraints. The task system. x-window-system is part of task basic-desktop, so to remove it means that this task is incomplete and probably broken unless the first two CDs are used. If a package is to be moved off the first CD then ../indices/override.woody.extra.main.gz needs to be checked to see if it is part of a task. If it is, then moving it will probably break the task. The release. We were told in no uncertain terms that we were not to mess with task system. We need to do the best we can within these limitations. The alternative is to tell people that they need the first two CDs minimum. woody+1 for the solution? Phil. -- Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand +64 3 488 2818Fax +64 3 488 2875Mobile 025 267 9420 [EMAIL PROTECTED] - preferred. [EMAIL PROTECTED] I sell GNU/Linux GNU/Hurd CDs. See http://www.copyleft.co.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
On Thu, 2002-05-30 at 10:50, Santiago Vila wrote: On 30 May 2002, Philip Hands wrote: On Thu, 2002-05-30 at 10:08, Santiago Vila wrote: If we accept that a first non-US CD does not necessarily have to contain the whole of non-US, we could change the way of generating the CDs from Including most of non-US in CD#1, excluding big packages to Including packages from non-US in CD#1 according to their popularity, as we already do for main packages. But then we need a 2_NONUS, or perhaps we just arrange for all packages to be in popularity order, and have as many non-US CDs as it happens to take depending where the packages land. I think that's a big enough change to leave for a later release, unless someone else is confident that they can change this without breaking things. Hmm, considering that woody has already 8 binary CDs (i.e. 7 US CDs and 1 non-US one) a 2nd NONUS CD would not be such a big change. Steve noticed that several of the packages that claim to be non-US are actually now in main, but are also still in the non-US archive, which is what the fundamental problem is. Erlang is one of these, and once it's sorted out we'll have a bit more room on CD1, so there's no need for CD2_NONUS as it turns out. I'll report these as bugs against non-us, and possibly do something nasty to my mirror to sort it out in the meantime. A quick comparison of the .deb's in both non-US and main, gives this list of suspects: http://www.hands.com/~phil/woody-cd/non-non-US.txt This list may include packages that are in non-US main for reasons based on differences between package versions, but it should contain all the problem packages, that are really in main, but still lingering in non-US as well. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: CD release announcement
On Thu, 30 May 2002, Richard Atterer wrote: Another related question: At the moment, jigdo-mirror does not allow you to filter which images it should create and which not. People using it will only be able to mirror all 88 images, there's no way to prevent it from creating e.g. binary-3 to binary-7, or the non-us CDs. Should I modify it to allow such filtering? Most definitely yes. Many site only mirror i386. The images of the current stable distribution (potato) need 13 GB of disc space for 22 CD images. In contrast to this, the full set of woody CDs needs about 53 GB for 88 CD images! [The 88 is 8*10 + 8 source.] Because we expect that most mirror admins do not want to dedicate so much space to CD images, by default not all CD images will be made available, only a subset which will take about 21 GB for 34 CD images. (We omit CDs 3-8 for the 9 non-Intel architectures.) Let people choose. Filtering. Unless Phil Hands wants to limit the number. [Is this correct? Will PIK-style .list files be generated? Will the rsync/http/ftp paths stay the same?] I hope so, particulaly rsync. There will be dud jigdo images. PIK and debian-cd can be used to produce starting images for use with rsync. Phil. -- Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand +64 3 488 2818Fax +64 3 488 2875Mobile 025 267 9420 [EMAIL PROTECTED] - preferred. [EMAIL PROTECTED] I sell GNU/Linux GNU/Hurd CDs. See http://www.copyleft.co.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CD release announcement
On Thu, 2002-05-30 at 13:16, Richard Atterer wrote: Where will the official 3.0r0 jigdo files be placed? I think it would be wise *not* to use cdimage/jigdo-area for that, because does this work if you point it at: http://cdimage.debian.org/jigdo-area/current/ ? If so, there's no problem (as long as I remember to update the symlink :-) Another related question: At the moment, jigdo-mirror does not allow you to filter which images it should create and which not. People using it will only be able to mirror all 88 images, there's no way to prevent it from creating e.g. binary-3 to binary-7, or the non-us CDs. Should I modify it to allow such filtering? Well, US sites need to be able to exclude the non-US images at the very least, but I don't suppose there are many of the potential users of this that actually want to carry all the images, so it would be good to be able to exclude various combinations of image. The other thing that is likely to happen (I should be able to sort it out soon) is that cdimage will actually be a CNAME for raff.d.o and non-us.cdimage.debian.org will point at open. raff is in the USA, so cannot carry the non-US CDs. It can however carry the non-US jigdo images, since they have no non-US data other than the package names and checksums in them. This may make the explanation a bit more complicated. Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
On Wed, 30 May 2001, Philip Charles wrote: This package depends on xspecs so it's certainly not for normal users. We are operating with two sets of constraints. The task system. x-window-system is part of task basic-desktop, so to remove it means that this task is incomplete and probably broken unless the first two CDs are used. If a package is to be moved off the first CD then ../indices/override.woody.extra.main.gz needs to be checked to see if it is part of a task. If it is, then moving it will probably break the task. The release. We were told in no uncertain terms that we were not to mess with task system. More than being a part of, x-window-system is the *only* package in the basic-desktop task. I think there is something fundamentally wrong in this task if it's called basic and, at the same time, it includes xspecs. There is also a `desktop' task containing x-window-system-core, which is the good one. I think the basic-desktop task should not exist, or it should not contain x-window-system, or we should not force it to be in the first CD. I would like to hear some comments about this from whoever created this weird basic-desktop task. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
Perhaps this is a simple typo/mistake and it should be x-window-system-core, not x-window-system, the single package in the basic-desktop task? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
On Thu, 2002-05-30 at 12:30, Wichert Akkerman wrote: Previously Philip Hands wrote: The good news is that TeX is in, the bad news is that packages such as xdm, xfs xterm are out. This seems bad, but I suppose since gdm kdm are on there, and one can survive without xfs, and gnome-terminal is in, we could actually live without those, but will the resulting lack of x-window-system cause a problem with the tasks? Breaking X is imho a much worse than getting TeX on CD1. gnome-terminal is definitely not a replacement for xterm. OK, the latest cut is much better: http://www.hands.com/~phil/woody-cd/pre6-pre8-package.diff.txt Note' this is the diff against the With X, but missing TeX pre6, so the fact that there is no mention of things like xdm means they're still on CD#1 Things to note: erlang is still in, on the strength of its (spurious) listing as a non-US package, so once non-US is cleaned up, we'll have a load more space on CD#1. The three Non-US packages at the end of this, that have gone to CD#7, are also now in the main US archive, so are not in fact contaminating CD7 with non-US stuff. Having exchanged the kernel images for the kernel source, we should probably make sure that all the patches required to make the images we've removed also be included on CD#1 --- any suggestions on how to maintain a definitive list? The jigdos that go with this are starting to appear here: http://cdimage.debian.org/jigdo-area/3.0-pre8/ Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Custom cd's
Hello, I was wondering if anyone know of any methods where I could customize a debian cd set with just the packages I want and scaled down so it would fit on a mini and/or business card/credit card cd. To give you some idea the size requirments Full cd = 650 megs Mini cd = 180 megs biz card cd = 51 megs Credit card cd = 52 megs Note these are the capacity of the blanks that I use and the size/shape does vary on the latter 2. Ed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
On Thu, May 30, 2002 at 01:57:38PM +0100, Philip Hands wrote: Hmm, considering that woody has already 8 binary CDs (i.e. 7 US CDs and 1 non-US one) a 2nd NONUS CD would not be such a big change. Steve noticed that several of the packages that claim to be non-US are actually now in main, but are also still in the non-US archive, which is what the fundamental problem is. Erlang is one of these, and once it's sorted out we'll have a bit more room on CD1, so there's no need for CD2_NONUS as it turns out. I've already replied to Phil's bug about this, but this doesn't actually work out: erlang's in non-US in testing and unstable, and won't be moving for woody. There's a bunch of stuff for which new versions have been uploaded to main for unstable, but most of those that haven't already made it to woody, won't. I'll probably be updating woody some more tomorrow wrt openh323 stuff moving (which is probably big, but no promises as to whether it'll actually go into main for woody or not), and various other things, if you want to wait 'til then to see what happens. But most of that list isn't going to be changed. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif msg03904/pgp0.pgp Description: PGP signature
Re: CD release announcement
On Thu 30 May, Richard Atterer wrote: Another related question: At the moment, jigdo-mirror does not allow you to filter which images it should create and which not. Should I modify it to allow such filtering? yes. It's pretty close to being essential I think. Because we expect that most mirror admins do not want to dedicate so much space to CD images, by default not all CD images will be made available, only a subset which will take about 21 GB for 34 CD images. (We omit CDs 3-8 for the 9 non-Intel architectures.) I'm not sure this is the right approach. Most people are interested in a particular arch either entirely or not at all, so I'd expect them to want all 8 arch-whatever CDs, rather than just the first two of a load of arches. (e.g. I want all 8 arm CDs and all 8 source but nothing else (well probably all i386 actually). I suppose the 'get the first 2 CDs then use apt' makes a lot of sense, but it's just as true for i386 as the other arches. All in all I think we need user-level filtering, on arch, non-US and CD number (with an easy '1st 2' and 'others' split making sense for CD numbers). Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
CD image
Hi, I had download the CD image of Debian OS. I searched at the package.debian-cd web site, and downloaded some .deb files. I still could not find the necessary information of howto burn the CD as bootable disk with images. Please let me know where I can find such information. Thanks, Wu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
On Thu, 30 May 2002, Santiago Vila wrote: On Wed, 30 May 2001, Philip Charles wrote: The release. We were told in no uncertain terms that we were not to mess with task system. More than being a part of, x-window-system is the *only* package in the basic-desktop task. I think there is something fundamentally wrong in this task if it's called basic and, at the same time, it includes xspecs. There is also a `desktop' task containing x-window-system-core, which is the good one. I think the basic-desktop task should not exist, or it should not contain x-window-system, or we should not force it to be in the first CD. I would like to hear some comments about this from whoever created this weird basic-desktop task. If you look at i18n you will see worse problems. But we are stuck with what is there as far as woody is concerned. We can only do what we can given the restrictions imposed by a (hopefully) imminent release. We have made quite a lot of progess, at least a stand-alone first CD does work, but it is far from perfect. I cannot say that I am happy with the situation. Bitching about this situation has a theraputic value, but it is not going to change anything. Phil. -- Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand +64 3 488 2818Fax +64 3 488 2875Mobile 025 267 9420 [EMAIL PROTECTED] - preferred. [EMAIL PROTECTED] I sell GNU/Linux GNU/Hurd CDs. See http://www.copyleft.co.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
Santiago Vila wrote: More than being a part of, x-window-system is the *only* package in the basic-desktop task. I think there is something fundamentally wrong in this task if it's called basic and, at the same time, it includes xspecs. There is also a `desktop' task containing x-window-system-core, which is the good one. I think the basic-desktop task should not exist, or it should not contain x-window-system, or we should not force it to be in the first CD. I would like to hear some comments about this from whoever created this weird basic-desktop task. Well, take a look at tasksel's changelog: * Make the basic-desktop task incude all of x-window-system (so it gets a WM and xterm and so on), while the desktop task uses just x-window-system-core (because it already has a WM and so on from gnome and kde). Closes: #129217 I did the best I could within the constraints of the freeze and the available X metapackages. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CD image
On Thu, 30 May 2002, Wu, Ying-Wah CECOM RDEC I2WD wrote: I had download the CD image of Debian OS. I searched at the package.debian-cd web site, and downloaded some .deb files. I still could not find the necessary information of howto burn the CD as bootable disk with images. Please let me know where I can find such information. Hi, Check out this link: http://www.debian.org/CD/faq/#record-unix (or #record-windows or #record-mac) I think this is what you're looking for. Hope that helps. Cheers, Till -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Custom cd's
On Thu, May 30, 2002 at 11:20:21AM -0400, Ed Street wrote: I was wondering if anyone know of any methods where I could customize a debian cd set with just the packages I want and scaled down so it would fit on a mini and/or business card/credit card cd. To give you some idea the size requirments Hi Ed- if you use the debian-cd scripts to build CDs, you basically just give it a list of packages at one stage during the process and specify a size limit for the ISO. Full cd = 650 megs Mini cd = 180 megs biz card cd = 51 megs Credit card cd = 52 megs The woody-mini-i386-1.raw file I make with a cut-down packages list is 161Mb. I'm not sure what you'd do to get it down to 50. Go axe-happy on the package list though I guess :} SRH -- Steve Haslam http://www.arise.demon.co.uk/ [EMAIL PROTECTED] Debian GNU/Linux Maintainer [EMAIL PROTECTED] but I won't admit to needing you I'll never say that's true, not to you [sister machine gun] msg03910/pgp0.pgp Description: PGP signature
Re: Custom cd's
Is this the method people are using the build the minimal netinst type cd's aswell? It seems like overkill to have a full debian mirror to build a 50-70 meg image. -stephen On Thu, 30 May 2002, Steve Haslam wrote: SH On Thu, May 30, 2002 at 11:20:21AM -0400, Ed Street wrote: SH I was wondering if anyone know of any methods where I could customize a SH debian cd set with just the packages I want and scaled down so it would SH fit on a mini and/or business card/credit card cd. To give you some SH idea the size requirments SH SH Hi Ed- if you use the debian-cd scripts to build CDs, you basically just SH give it a list of packages at one stage during the process and specify a SH size limit for the ISO. SH SH Full cd = 650 megs SH Mini cd = 180 megs SH biz card cd = 51 megs SH Credit card cd = 52 megs SH SH The woody-mini-i386-1.raw file I make with a cut-down packages list is SH 161Mb. I'm not sure what you'd do to get it down to 50. Go axe-happy on the SH package list though I guess :} SH SH SRH SH -- Stephen Mulcahy, Software Engineer, AO - Multivendor Systems Engineering, HP Services, Hewlett-Packard Company, Ballybrit Business Park, Galway, Ireland tel: +353-91-754584 / mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Custom cd's
On Thu, May 30, 2002 at 07:19:31PM +0100, Stephen Mulcahy wrote: Is this the method people are using the build the minimal netinst type cd's aswell? It seems like overkill to have a full debian mirror to build a 50-70 meg image. It's what I'm using, but yes it's overkill. Especially since it has to cope with installing different kernels on different CD's etc.. which is just irrelevant for building small images. But I don't know any alternatives atm. SRH -- Steve Haslam http://www.arise.demon.co.uk/ [EMAIL PROTECTED] Debian GNU/Linux Maintainer [EMAIL PROTECTED] but I won't admit to needing you I'll never say that's true, not to you [sister machine gun] msg03912/pgp0.pgp Description: PGP signature
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
On Thu, 30 May 2002, Joey Hess wrote: Santiago Vila wrote: I would like to hear some comments about this from whoever created this weird basic-desktop task. Well, take a look at tasksel's changelog: * Make the basic-desktop task incude all of x-window-system (so it gets a WM and xterm and so on), while the desktop task uses just x-window-system-core (because it already has a WM and so on from gnome and kde). Closes: #129217 I did the best I could within the constraints of the freeze and the available X metapackages. What's wrong with basic-desktop being x-window-system-core plus a WM plus xterm? As I said, x-window-system contains things which are far away from being basic. If we force it to be on CD #1, lots of very popular packages will end up being in CD #2. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
CD sizes, Packages and Sources
Hello, this is my first message to this list after lurking since long. I have a partial mirror for woody/binary-i386 based on debmirror and the actual CVS version of debian-cd. Every so often I build inofficial woody CDs from my local mirror which I put onto CD-RWs. This works great except for two things: I always end up in getting 8 CDs instead of 7 as with jigdo: 660996096 May 30 19:10 woody-i386-1.raw 661159936 May 30 19:11 woody-i386-2.raw 668467200 May 30 19:13 woody-i386-3.raw 654671872 May 30 19:15 woody-i386-4.raw 659292160 May 30 19:17 woody-i386-5.raw 654049280 May 30 19:20 woody-i386-6.raw 661487616 May 30 19:21 woody-i386-7.raw 172818432 May 30 19:22 woody-i386-8.raw The way I use debian-cd (according to the documentation) is: source CONF.sh make distclean make mirrorcheck make status make list TASK=tasks/Debian_woody COMPLETE=1 SIZELIMIT1=55500 make bootable make packages make md5list make images make imagesums Should I use a different value for SIZELIMIT1, or skip it at all? Except for the pathes my CONF.sh only differs from the original in export NONFREE=1 export SECURED=1 being set. From above commands 'make md5list' produces the following errors: cp: cannot stat `.../main/binary-i386/Packages': No such file or directory cp: cannot stat `.../main/source/Sources': No such file or directory cp: cannot stat `.../contrib/binary-i386/Packages': No such file or directory cp: cannot stat `.../contrib/source/Sources': No such file or directory cp: cannot stat `.../non-free/binary-i386/Packages': No such file or directory cp: cannot stat `.../non-free/source/Sources': No such file or directory The corresponding compressed file Packages.gz and Sources.gz exist in the same directories. Do they need to be extraced beforehand? I'm aware that there are more important problems than mine while woody is about to be released. However, if someone could give me a hint I would greatly appreciate that. Thank you all for the excellent work! Achim Löbbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CD image
On Thu, May 30, 2002 at 12:52:47PM -0400, Wu, Ying-Wah CECOM RDEC I2WD wrote: I had download the CD image of Debian OS. I searched at the package.debian-cd web site, and downloaded some .deb files. I still could not find the necessary information of howto burn the CD as bootable disk with images. Please let me know where I can find such information. Have you had a look at http://www.debian.org/CD/? It describes various ways of getting .iso images for Debian Linux. Instructions for making a CD-R from the .iso file can be found under http://www.debian.org/CD/faq/#record-windows. Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CD release announcement
OK, I'll implement the filtering. The part about not providing rsyncable CDs 3-7 for non-i386 was the last word from Phil H. about this, but that was before the decision to move almost everything to raff. So... will we be offering rsync access to all 88 images? In that case, a warning to the mirror admins about the size is definitely necessary. :) If this means that already existent mirror setups are going to fetch 53GB of data by default, there should also be instructions on how to limit the CDs by filename. With rsync, e.g. --include '*i386*' --exclude '*-[3-9].*' might be handy. BTW, are my size estimates correct? On Thu, May 30, 2002 at 02:35:58PM +0100, Philip Hands wrote: does this work if you point it at: http://cdimage.debian.org/jigdo-area/current/ ? If so, there's no problem (as long as I remember to update the symlink :-) Ah, sure, that should work just fine! Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Custom cd's
On Thu, 30 May 2002, Steve Haslam wrote: SH On Thu, May 30, 2002 at 07:19:31PM +0100, Stephen Mulcahy wrote: SH Is this the method people are using the build the minimal netinst type SH cd's aswell? It seems like overkill to have a full debian mirror to SH build a 50-70 meg image. SH SH It's what I'm using, but yes it's overkill. Especially since it has to cope SH with installing different kernels on different CD's etc.. which is just SH irrelevant for building small images. But I don't know any alternatives atm. Would the author(s) of debian-cd care to provide an outline of the major steps that debian-cd performs in constructing an image - it would help others wanting to put together similar tools for such tasks (I know, I know, documentation is evil .. but it can be useful ;) I'm thinking of something that explains things to the level of making a bootable image, copying in packages, creating a rescue disk image, etc. (excuse me if this is gibberish, I'm not very familiar with the process currently but would like an alternative to mounting existing netinst images with a loopback device and inserting items into them). Thanks, -stephen -- Stephen Mulcahy, Software Engineer, AO - Multivendor Systems Engineering, HP Services, Hewlett-Packard Company, Ballybrit Business Park, Galway, Ireland tel: +353-91-754584 / mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
Philip == Philip Hands [EMAIL PROTECTED] writes: Philip Looking at the sizes of the packages on CD#1_NONUS from pre6 Philip I see that stating with the largest we have (after getting Philip rid of the kernel images): Philip 128882447 emacs21_21.2-1_i386.deb Philip 105322127 emacs20-dl_20.7-14.3_i386.deb We definitely doi not need emacs 20 dynamically loaded versions on CD1 -- this is a far smaller constituency. Indeed, emacs21 ought to be the default FSF emacs now -- development, and even bug fixes have stopped on emacs20, and emacs21 seems to be stable. It is not as if emacs20 is being removed from the set, just moved further back. manoj -- Just don't make the '9' format pack/unpack numbers... :-) Larry Wall in [EMAIL PROTECTED] Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
On Thu, May 30, 2002 at 01:24:28PM -0400, Joey Hess wrote: Santiago Vila wrote: I would like to hear some comments about this from whoever created this weird basic-desktop task. Well, take a look at tasksel's changelog: * Make the basic-desktop task incude all of x-window-system (so it gets a WM and xterm and so on), while the desktop task uses just x-window-system-core (because it already has a WM and so on from gnome and kde). Closes: #129217 I did the best I could within the constraints of the freeze and the available X metapackages. Maybe it would shut Santiago up if you just made basic-desktop task depend on everything depended upon by x-window-system, instead of x-window-system itself. -- G. Branden Robinson| Why do we have to hide from the Debian GNU/Linux | police, Daddy? [EMAIL PROTECTED] | Because we use vi, son. They use http://people.debian.org/~branden/ | emacs. msg03919/pgp0.pgp Description: PGP signature
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
On Thu, 30 May 2002, Branden Robinson wrote: On Thu, May 30, 2002 at 01:24:28PM -0400, Joey Hess wrote: Well, take a look at tasksel's changelog: * Make the basic-desktop task incude all of x-window-system (so it gets a WM and xterm and so on), while the desktop task uses just x-window-system-core (because it already has a WM and so on from gnome and kde). Closes: #129217 I did the best I could within the constraints of the freeze and the available X metapackages. Maybe it would shut Santiago up if you just made basic-desktop task depend on everything depended upon by x-window-system, instead of x-window-system itself. I was going to propose something similar, but excluding not-so-popular packages from the dependency chain, since this is a basic desktop. x-window-system depends on the following packages, sorted by regular usage: xterm404 246 111 1 xfs 2759649 0 xdm 838820 0 twm 49 23051 0 xnest 29 21266 0 xvfb 26 17153 0 xprt 16 19854 1 proxymngr 14 10737 0 lbxproxy 149741 0 xfwp 99327 0 x-window-system-core 0 0 0 135 xspecs 0 0 0 195 For a basic-desktop task, xterm, xfs, xdm and twm would probably suffice (plus x-window-system-core, which adds the remaining bits). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CD sizes, Packages and Sources
On Thu, May 30, 2002 at 06:57:22PM +, Achim L?bbert wrote: this is my first message to this list after lurking since long. I have a partial mirror for woody/binary-i386 based on debmirror and the actual CVS version of debian-cd. Every so often I build inofficial woody CDs from my local mirror which I put onto CD-RWs. This works great except for two things: I always end up in getting 8 CDs instead of 7 as with jigdo: 660996096 May 30 19:10 woody-i386-1.raw 661159936 May 30 19:11 woody-i386-2.raw 668467200 May 30 19:13 woody-i386-3.raw 654671872 May 30 19:15 woody-i386-4.raw 659292160 May 30 19:17 woody-i386-5.raw 654049280 May 30 19:20 woody-i386-6.raw 661487616 May 30 19:21 woody-i386-7.raw 172818432 May 30 19:22 woody-i386-8.raw The way I use debian-cd (according to the documentation) is: source CONF.sh make distclean make mirrorcheck make status make list TASK=tasks/Debian_woody COMPLETE=1 SIZELIMIT1=55500 make bootable make packages make md5list make images make imagesums Should I use a different value for SIZELIMIT1, or skip it at all? Except for the pathes my CONF.sh only differs from the original in export NONFREE=1 This is what's giving you the 8th CD. Turn off non-free if you want to fit into 7 CDs. From above commands 'make md5list' produces the following errors: cp: cannot stat `.../main/binary-i386/Packages': No such file or directory cp: cannot stat `.../main/source/Sources': No such file or directory cp: cannot stat `.../contrib/binary-i386/Packages': No such file or directory cp: cannot stat `.../contrib/source/Sources': No such file or directory cp: cannot stat `.../non-free/binary-i386/Packages': No such file or directory cp: cannot stat `.../non-free/source/Sources': No such file or directory The corresponding compressed file Packages.gz and Sources.gz exist in the same directories. Do they need to be extraced beforehand? Sorry, I'm not sure what's happening here. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] It's actually quite entertaining to watch ag129 prop his foot up on the desk so he can get a better aim. [ seen in ucam.chat ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Where to send installation reports?
Hello, I'm a fairly experienced Debian i386 user who just got himself an Apple iBook. I know next to zilch about the Mac, and have had a number of false starts at installing Debian on the thing. I have some feedback for The Powers That Be about my installation experience, and I'm also keeping some notes on http://tinyplanet.ca/pubs/debian/ibook/ , and it will eventually get added as an appendix to my Painless Debian GNU/Linux docco at http://tinyplanet.ca/pubs/debian/ . So far I have had no success in getting Debian to coexist with the MacOS. No, I am not asking for help, because I want to see how far I can get using only the published documentation. My question is: is debian-cd the appropriate place to discuss this? Or should I use debian-powerpc, or debian-boot, or...? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
On Thu, 30 May 2002, Santiago Vila wrote: What's wrong with basic-desktop being x-window-system-core plus a WM plus xterm? As I said, x-window-system contains things which are far away from being basic. If we force it to be on CD #1, lots of very popular packages will end up being in CD #2. The freeze? -- Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand +64 3 488 2818Fax +64 3 488 2875Mobile 025 267 9420 [EMAIL PROTECTED] - preferred. [EMAIL PROTECTED] I sell GNU/Linux GNU/Hurd CDs. See http://www.copyleft.co.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
woody-src-?.jigdo template url incorrect,
The jigdo image at http://cdimage.debian.org/jigdo-area/3.0-pre8/jigdo/source/wwody-src-6.jigdo has the following section [Image] Filename=debian-30p8-source-6.iso Template=http://cdimage.debian.org/jigdo-area/3.0-pre8/jigdo/src/woody-sr c-6.template ShortInfo='Debian GNU/Linux 3.0 p8 Woody - Pre-release Source-6 CD' Info='Generated on Thu, 30 May 2002 15:08:00 +0100' NOTE: the path is different, the .jigdo file mentions .../src/... path, in reality it is .../source/ I think its the same thing with other images, jigdo works if the templates are downloaded to the local dir by hand. Also, woody-src-6 failed to verify through jigdo-lite, but its md5sum match the value in the MD5SUM file Appart from these minor bugs i like jigdo-lite. Thanks Glenn msg03924/pgp0.pgp Description: PGP signature
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
On Fri, 31 May 2002, Philip Charles wrote: On Thu, 30 May 2002, Santiago Vila wrote: What's wrong with basic-desktop being x-window-system-core plus a WM plus xterm? As I said, x-window-system contains things which are far away from being basic. If we force it to be on CD #1, lots of very popular packages will end up being in CD #2. The freeze? If we can't fix usability bugs during the freeze, we might better unfreeze woody for a while, fix the basic-desktop task, and freeze woody again... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First try on Hurd-H4-CD1 jigdo files
Philip Charles wrote: Good luck, let us know how you get on. We need to speed up the transfer of the iso's from Dunedin to Budapest. If you have a local debian tree, that should be no problem at all. It works already when you have just the files that are mirrored in the same relative position local as on the mirrors, so you don't even need a whole mirror. And I don't think anyone would like to have a Debian mirror just for fun. This files would be taken out of the image and fetched from the mirrors when rebuilding the system. That would be the straigth forward approach. Could you start thinking of how we could use a loop mounted iso image to speed things up. I tried to filter the files list from the image and the list of my local copy of alpha, but it showed that I realy need to know exactly which files can't be fetched from a mirror and which can. I can make jigdo-file take the alpha files instead of the loop-mounted files, but I did not find a usable way of excluding the non-fetchable files. I tried a ls-LR file froma a mirror, but I need the path to the files too, and I don't see a reasonable short way of getting this out of the ls-LR. If someone could provide me a 'find -type f' result of a Debian mirror and the hurd directory of alpha, that would bring me a big step further. Then I could match that list with a list of files in the image, leaving out files that can't be fetched to remain in the template. Finally I'd present jigdo-file the alpha file list before the matched image file list, so that the alpha files are stamped out too. To sum up, first we need a list of files that can be found on mirrors with their corresponding location, what I'm trying to do ATM. And second the files itself for the checksums, which we get from the mounted image. I now work with a local copy of alpha, just to be able to separate the server locations in the jigdo file, but this should not be needed with a file listing from alpha and some file list manipulation. In my theory this would result in the perfect hurd-H4-CD1 jigdo files. (But as a wise man said: I practice the difference between theory and practice is mach bigger than in theory ;-) By the while, H4 seem not to be the best place/time for trying jigdo. Patrick ps: Can anyone give my a size of a Debian mirror? Just to know what we try to avoid. -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser pstrasser at bigfoot dot de Student of Telematik, Techn. University Graz, Austria -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First try on Hurd-H4-CD1 jigdo files
Richard Atterer wrote: On Wed, May 29, 2002 at 01:53:17PM +0200, Patrick Strasser wrote: In case the size is really a problem, note that you can always refine the script used to generate the debian-superseded contents. Attila just puts *all* outdated files there (because his CDs actually use most files, and because it's easy to code). However, nothing prevents you from writing a script which only puts those files into the superseded dir which are actually referenced by the template file. That would be needed anyway. Can anyone give me data on package change to estimate the size of such a directory or a hint to where I can find this? How much packages change during a normal month? How much can we expect from H4 to J1 to change? Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser pstrasser at bigfoot dot de Student of Telematik, Techn. University Graz, Austria -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
On Fri, 31 May 2002, Santiago Vila wrote: If we can't fix usability bugs during the freeze, we might better unfreeze woody for a while, fix the basic-desktop task, and freeze woody again... Let's get woody out of the door fast. Tomorrow preferably, if not, the day after. We can reccommend that people use the first two CDs. This is the case with Red Hat, not that this is an example I would like to follow long term. Woody+1 Phil. -- Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand +64 3 488 2818Fax +64 3 488 2875Mobile 025 267 9420 [EMAIL PROTECTED] - preferred. [EMAIL PROTECTED] I sell GNU/Linux GNU/Hurd CDs. See http://www.copyleft.co.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First try on Hurd-H4-CD1 jigdo files
On Fri, 31 May 2002, Patrick Strasser wrote: Cut To sum up, first we need a list of files that can be found on mirrors with their corresponding location, what I'm trying to do ATM. And second the files itself for the checksums, which we get from the mounted image. I now work with a local copy of alpha, just to be able to separate the server locations in the jigdo file, but this should not be needed with a file listing from alpha and some file list manipulation. In my theory this would result in the perfect hurd-H4-CD1 jigdo files. (But as a wise man said: I practice the difference between theory and practice is mach bigger than in theory ;-) I realy don't like this complexity. I can add quite a few more complications, e.g. unique Hurd boot-floppies which only exist on the master CD images. These would always have to be fetched from somewhere. I suspect that a hacked PIK might be the easiest way to go. This would probably give us about 80% complete images which could be rsync'ed. Phil. -- Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand +64 3 488 2818Fax +64 3 488 2875Mobile 025 267 9420 [EMAIL PROTECTED] - preferred. [EMAIL PROTECTED] I sell GNU/Linux GNU/Hurd CDs. See http://www.copyleft.co.nz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What kernel stuff on CD1? Was Still no TeX in CD#1
On Thu, 2002-05-30 at 16:18, Anthony Towns wrote: I've already replied to Phil's bug about this, but this doesn't actually work out: erlang's in non-US in testing and unstable, and won't be moving for woody. There's a bunch of stuff for which new versions have been uploaded to main for unstable, but most of those that haven't already made it to woody, won't. I'll probably be updating woody some more tomorrow wrt openh323 stuff moving (which is probably big, but no promises as to whether it'll actually go into main for woody or not), and various other things, if you want to wait 'til then to see what happens. But most of that list isn't going to be changed. Yeah, sorry about that bug report, sloppy analysis on my part, combined with Steve and I jumping to a few conclusions which are looking to be wrong. I failed to spot that libopenh323-dbg was a non-US package when I excluded it from CD#1 --- I think that's where the problem came from, I'm just doing another run to see what we get without that exclusion. Hmm, still getting a 7_NONUS CD for some reason. Oh well. That'll give me something to do over the weekend. :-/ Cheers, Phil. -- Say no to software patents! http://petition.eurolinux.org/ |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND signature.asc Description: This is a digitally signed message part
Re: CD release announcement
On 30 May 2002, Philip Hands wrote: On Thu, 2002-05-30 at 13:16, Richard Atterer wrote: Where will the official 3.0r0 jigdo files be placed? I think it would be wise *not* to use cdimage/jigdo-area for that, because does this work if you point it at: http://cdimage.debian.org/jigdo-area/current/ ? If so, there's no problem (as long as I remember to update the symlink :-) Just a small mention, I mirror jigdo-area daily now (excluding snapshot) on http://ftp.se.debian.org/mirror/debian-cd/jigdo-area/ - after the release I'll make the symlink (taking out mirror/ in that url) and stuff work so there isn't both a debian-iso and debian-cd with slightly different things (debian-iso is a pure mirror of the potato release images) Right now I made the decision that it is better to leave debian-iso as the mirror it is. The other thing that is likely to happen (I should be able to sort it out soon) is that cdimage will actually be a CNAME for raff.d.o and non-us.cdimage.debian.org will point at open. Where will the jigdo files turn up? open is a bit closer, but I get good rates to raff too. Just wondering if I should have that cron job that mirrors jigdo-area point at cdimage or open. I'll probably do alot of manual work at release time anyway, but it would be good to know where stuff will turn up. /Mattias Wadenstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: woody-src-?.jigdo template url incorrect,
On Fri, 31 May 2002 09:08:30 +1000 Glenn McGrath [EMAIL PROTECTED] wrote: The jigdo image at http://cdimage.debian.org/jigdo-area/3.0-pre8/jigdo/source/wwody-src-6.jigdo Same problem in 3.0-pre9 Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
