Etch r5 (4.0_r5) cds and other media
Hi! Yesterday we built the images for the new release of Etch, they were tested by some of the people on the channels and seem ok, so I have moved all the stuff to the release/4.0_r5 directory on farbror and linked current to it. I know there are other things that must be done now, like building the snapshots, changing things on the web and feeding the lions, I mean the torrents, but most of the people that usually takes care of all this is away right now, so even though I would have preferred to talk to others and coordinate all this (tried irc, mail and phone) I'm making this part available and hope others will do the rest when they can or contact me. I hope quality is good, the only thing we haven't updated are etchnhalf images, this is because, as fjp realised, D-I in testing is broken, so etchnhalf will follow after RC1. I guess that's all for now. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Smart Boot Manager binary in debian-cd
> I think that we should be able to drop sbm without annoying anyone as all > modern machines are able to boot from CD without troubles. Yes, that's true and there are some other reasons to drop it, first would be that sbm is dead upstream (at least there are no new versions since a long time ago and no movement on the lists, also... if somebody wants sbm he can download it from the net and create the floppy himself. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Downloading Debian CD images with BitTorrent
> The requested URL /debian-cd/4.0_r3/amd64/bt-dvd/ was not found on this > server. > Please, restore links. We are in the process of creating the new 4.0r4 images, I suppose that and the lack of space on the machine for holding all the images may be the problem here, I suppose that as soon as we finish with r4 images things should go to normal again and you should have r4 images linked there. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: completing etchnhalf
> > The first part should take the usual couple of days to build and test, > > *although* I'm going to be away and busy for a large chunk of next > > weekend myself. Maybe Manty or somebody else could watch over the > > build...? > Sure, even though I'm not much up to date in current status, but a little > talk on IRC should be enough to get me going. I'm updating my availability with this mail... I'll be a little bit bussy on friday 25th, I suppose that I'll be available from evening CET on friday, I can even maybe do some stuff before evening, provided the neighbours at the place where I'll be still have their wireless open :-) Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: completing etchnhalf
> The first part should take the usual couple of days to build and test, > *although* I'm going to be away and busy for a large chunk of next > weekend myself. Maybe Manty or somebody else could watch over the > build...? Sure, even though I'm not much up to date in current status, but a little talk on IRC should be enough to get me going. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debmirror can't download some boot system's files
> I had used debmirror with that options: > debmirror debian --nosource --host=ftp.fi.debian.org --method=http --progress > --dist=etch --section=main,contrib,non-free,main/debian-installer --arch=i386 > --ignore-release-gpg > What's wrong with that, had I missed some debmirror options? I'd suggest at least --ignore=^dists/.*/main/installer-.*/ or similar Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: r1593 - in trunk: debian tasks tools tools/boot/lenny
> What is discover1 used for? Can discover (v2) be used instead? I don't know, I just copied what we have on arm and exists also on armel, arm has discover1, so added it for armel. Maybe we don't even need any discover thing :-? Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Broken DVD jigdo files
> Does this mean that the official woody r4 CDs contain packages which are no > longer on the mirrors? :- weren't we talking about testing DVDs? I had understood that, and the versioning of the files is exactly the same we have in current testing DVDs. Regards... -- Manty/BestiaTester -> http://manty.net
Re: Broken DVD jigdo files
> Rl_zRMQ5kqAtOVmv202uqg=Debian:pool/main/c/cl-mcclim/cl-mcclim_0.9+cvs.2004.11.30-1_all.deb > 9paFr9vHQqwa3P-60B89ew=Debian:pool/main/c/cl-mcclim/cl-mcclim-examples_0.9+cvs.2004.11.30-1_all.deb > KdxheqrpQymQeY8Rbr1gKw=Debian:pool/main/c/cl-mcclim/cl-mcclim-doc_0.9+cvs.2004.11.30-1_all.deb These files are gone and they are no longer in the mirrors, however jigdo should be able to fetch them out of the snapshot that we have at gluck automatically, yo should see this lines at the end of your .jigdo files: [Servers] Debian=http://gluck.debian.org/cdimage/snapshot/dvd/i386/20050108/Debian/ --try-last I have just rechecked and the files are there: http://gluck.debian.org/cdimage/snapshot/dvd/i386/20050108/Debian/pool/main/c/cl-mcclim/ Jigdo should fetch them from there automatically after not finding them on your mirror. Regards... -- Manty/BestiaTester -> http://manty.net
Re: DVD jidgo broken files...
> As the result, some of the files could not be downloaded, and I could not > really troubleshoot it. As I could see from online separate package > distribution, those are really missing or have been moved/renamed. This was due to a mistake on my side, it has been corrected, you can use the isos you have downloaded to try to fetch the ones we have now online (rc2 ones) or wait till tomorrow when you'll be able to fetch new ones. Try to always use the packages on your old isos to fill the new downloaded ones, that way you'll save everybody's bandwith. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DVD sarge image broken?
Mea culpa. > http://cdimage.debian.org/pub/cdimage-testing/dvd/jigdo-area/i386/ > timestamped 4-Dec-2004. Looks as if there is a mismatch with the current > pool? Yes, this happens always, and there is an snapshot that solves this, when people doesn't find a package in the mirrors, it goes back to the snapshot. We used to keep the snapshot for a week until the next build was built, and then removed the old snapshot and changed it for the new one, the problem was that people could be trying to use the old snapshot when the new one was already in place. So, I did some changes after the rc2 of debian-installer to keep old rc2 jigdos with their snapshots around for some time and also at the same time to have snapshots for the current build and the last one. The thing is that I forgot to change things for the DVDs to match the changes I did for the CDs, so while cds seem to be OK, at least to me, DVDs were still trying to use the snapshot we had built for rc2, which doesn't have some of the files that were supposed to be on the dvds but are no longer in the mirrors. I have replaced the bad jigdos with the rc2 ones and new ones will be generated this weekend (hopefully ok if I have fixed it well). Sorry about the problem, you can either find the packages you are missing at snapshot.debian.net, or try to use the packages you have downloaded and that are now on the iso you were trying to complete to build the rc2 isos, or wait for this weekend's new build. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Sarge Netinst
> But I still have one question; can I install debian sarge netinst with a > wireless networkcard? > The wireless networkcard has the wifi standard. I did that some time ago, it was after the beta1 of d-i was out, during a public talk about Debian where I showed, among other things, how one would be able to install sarge. What I did at that time was to boot from a USB flash memory device and then install over a wireless network card. I remember there were some little problems at that time, but I could install, I suppose things should be better now. The key, though, would be to have a supported wireless card ;-) Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
About the weekly full CD/DVD images delay
The weekly images were not produced this past weekend and were a bit delayed on the weekend before that, this was all due to the release of the release candidate 2 of debian-installer. We wanted the images that were due to be produced in the weekend of the 19th november to include the rc2 of debian-installer, so we had to delay them a bit to get all the rc2 stuff into sarge and then build. As for this past weekend, I decided it was better not to produce new images so that people could get the rc2 ones throughout this weekfrom the torrents or whatever they wanted before they were overriten by the weekend's build. We'll start building new weekly full images of CDs and DVDs this weekend, so the rc2 images will be overriten by the new build, that is for the iso images and the torrents, we have however decided to leave a copy of the rc2 full CDs and DVDs in jigdo format, which should be available at the following urls for CDs and DVDs respectively: http://cdimage.debian.org/pub/cdimage-testing/cd/rc2/ http://cdimage.debian.org/pub/cdimage-testing/dvd/rc2/ I think that's all. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#283137: Problem when booting from second CD
> Proably because there are no udebs at all, let alone kernel udebs, on > the second CD. So I'm reassigning this to debian-cd; if the second full > CD is intended to be bootable, it needs to have the d-i udebs on it. :-??? Does this seem reasonable? I mean, isn't it more reasonable to inform the user of this problem and ask him to change the cd and introduce the one with the udebs on it rather than having the udebs on each bootable cd? Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian GNU/Linux 3.0 updated (r3)
> So why announce it before its released. That the CDs aren't ready yet doesn't mean that the distribution is not ready, CDs are just one of the multible ways on which Debian is distributed, the new Woody release is out, available on the mirrors, CDs will come later, looks quite a simple thing to understand to me :-? Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
DOS compatible again? 8+3 names broken due to mkisofs option
Hi! While trying to make our cds compatible with DOS again we have identified several problems, the last one is that we are generating duplicate 8+3 names, which means that some files on the cds aren't accesible to DOS. The problem with this is that we are using the -l option in our mkisofs command line, this option is descrived in mkisofs like this: -l Allow full 31 character filenames. Normally the ISO9660 file- name will be in an 8.3 format which is compatible with MS-DOS, even though the ISO9660 standard allows filenames of up to 31 characters. If you use this option, the disc may be difficult to use on a MS-DOS system, but this comes in handy on some other systems (such as the Amiga). Use with caution. We are using this option in i386 along with other arches, and not in m68k, which if the man page is right, would be the arch where we should find it handy. I don't know if this flag should be applied to m68k, people knowing this arch please enlighten us on this ;-) But I definitely think it is of no sense on i386, here it doesn't provide anything (we already have long names through joliet) and it breaks compatibility with the old DOS based systems. So, I'm for removing this -l option on i386 as I see all pros and no cons, if somebody doesn't agree with this please tell us. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
About the broken jigdos and gluck's load
Hi! Sorry to everybody for not fixing this sooner, the thing is that lately I've been so busy with other stuff that I didn't find the time to read the list, otherwise I would have realised about this problem and how important it was, Mattias told me something but I was in a hurry so I didn't allow him to explain it all. Anyway, I have updated gluck with a new mkisofs based on jte 1.12 with the patches that were sent to the list, so, next dvd/cd runs should fix the problem with the jte images. Also I have scheduled this weekly build to start today and not on friday to get fixed images as soon as posible. Sorry to all the guys that have been getting the errors in the meanwhile, I apologize for my absence lately. On the other hand, I really think gluck is not the machine we should be using to produce all this, it's always overloaded and seems to struggle when it comes to disk access, something we do a lot when producing our images, even using jte. So, isn't there any other machine in the project that we could use to produce the testing cd/dvd images? Are we really that short on machines? Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Calculation of cd sizes implemented and tested, should I commit?
Hi!
It is two weeks since we started using at gluck the code I made to try to
estimate the sizes of the cd parts that debian-cd was not controling, it
seems to be working ok, so I was wondering if I should commit it :-?
What I did is an script tools/calc which gets info from the last full or
partial cd build, so that it gets the sizes of the boot files and other
stuff on the cds which is not packages and then builds a .calc file
containing this.
So, this is all standard, I mean, if one wants to use tools/calc to update
the .calc files for an arch, he can, if not, he uses the last estimations
stored in .calc files and given that things hadn't changed a lot since they
were estimated, they should still work ok.
The resulting .calc files are like this one (boot-powerpc.calc):
BOOT_SIZE_1=65
BOOT_SIZE_10=2
BOOT_SIZE_11=2
BOOT_SIZE_12=2
BOOT_SIZE_13=2
BOOT_SIZE_14=2
BOOT_SIZE_2=2
BOOT_SIZE_3=2
BOOT_SIZE_4=2
BOOT_SIZE_5=2
BOOT_SIZE_6=2
BOOT_SIZE_7=2
BOOT_SIZE_8=2
BOOT_SIZE_9=2
SIZE_MULT_1=93
The SIZE_MULT stuff is calculated by hand, as there is no way to easily
estimate the filesystem overhead, so far only m68k for all cds and powerpc
for the first cd need this.
I can try to remove the 2 megs of maximum overhead that is being added and
remove a lot of those entries if people finds any problem with this data.
This is the code that generates it:
#!/bin/sh
# Directory of the previous build, this doesn't need to be a full build,
# you can get the needed stuff by running a build.sh with something like:
# IMAGETARGET="ok bootable upgrade bin-infos bin-list"
BDIR="$TDIR/$CODENAME-$ARCH"
#Get info from older build if it exists
if [ -d "$BDIR" ];
then
echo Estimated sizes:
rm -f "boot/sarge/boot-$ARCH.calc"
for i in `du -sm "$BDIR"/CD[0123456789]* |
sed -n 's/^\([0-9]\+\).*CD\([0-9]\+\)/\2=\1/p'`
do
#space used by boot images in megs (this has an error of up to a mega)
if [ -d "$BDIR/boot${i%=*}" ]
then
imgdu=`du -sm "$BDIR/boot${i%=*}" |
sed -n 's/^\([0-9]\+\).*/\1/p'`
else
imgdu=1
fi
#add it all up and write it to the .calc file
echo BOOT_SIZE_${i%=*}=${i#*=}+$imgdu
echo BOOT_SIZE_${i%=*}=$((${i#*=}+$imgdu)) >> "boot/sarge/boot-$ARCH.calc"
case "$ARCH" in
m68k) echo SIZE_MULT_${i%=*}=97 >> "boot/sarge/boot-$ARCH.calc";;
esac
done
fi
case "$ARCH" in
powerpc) echo SIZE_MULT_1=93 >> "boot/sarge/boot-$ARCH.calc";;
esac
Well, comments, new ideas, patches, ... :-?
Should I commit it like that and then let people do changes?
Regards...
--
Manty/BestiaTester -> http://manty.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
we lost all DOS support, do we want it back?
Hi! Today I was trying to install sarge on an old machine, it doesn't boot from cd, so I said I'd use etherboot from a floppy, and when that didn't work even after adding another network card I sai'd, I'd boot from DOS and launch the install from the cd. Well, I have realised that we've lost all DOS compatibility, we don't have the install.bat or boot.bat that we used to have, that could easily be added, but we don't have loadlin.exe on the cd (wasn't there on beta1 cds already), these two problems could be easily solved if one gets loadlin and the .bat file into the DOS floppy he is using, but I think we should put this on our cds, what does people think about this? Currently there is another problem, as cds are no longer usable under DOS, I believe this is a bug caused by the JTE patch to mkisofs, Steve is going to take a look at this when he has some time, in the meanwhile I have changed config so that the images which are not jigdoed (netinst and businesscard) are produced using a non JTE patched version of mkisofs, so they should start working in DOS again, only missing the bat and the loadlin which is people agrees, I would inmediately add. Well, that's all for the DOS support. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
weekly builds are coming back again
Well, yesterday I finished my preliminary tests of the new cd and dvd soft, so today we'll start building weekly ISOs again. The new method uses a new soft, JTE, that should build the jigdos faster than before, but it can also have bugs that the old method didn't, so of you find something weird within the ISOS, just comment it around here. The schedule is setup like it was before, on friday night we'll build the DVDs and on saturday night we'll start creating the CDs. Hope we don't have too many problems. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
New DVD images and status of the weekly builds
Hi! We have produced new images and made them available (after fixing yesterday the problem with the powerpc builds). These images should again fit in all DVDs at least if we didn't break other things, they are the first images built with JTE that we publish, and even though we tested the JTE images internally for the last weeks, there could be errors when downloading or within the images, if so, please report them to the list and we'll try to address them asap. Does this mean that we are ready for building weekly images again? Nope, not yet, we still have size problems, we just have bypassed them for now to build these images, if you want to help with the size problems, have a look at my yesterday's mail with subject: ISO sizes problem (searching for a solution) It is much easier for us to generate DVD isos of a good size (and even in that we have not been much successfull) without solving this problem with the sizes, than to do it with CD isos, that's why we have produced new DVD images and not CDs yet, maybe we start generating new CDs and DVDs again in a weekly basis soon, but I wouldn't know when yet, for now, if you want a recent build please try out the new DVD images and let us know if they work ok. Regards... -- Manty/BestiaTester -> http://manty.net PS: thanks to Richard for replying to all the questions on the list.
ISO sizes problem (searching for a solution)
Hi! As everybody that has created debian cds using debian-cd knows, it is difficult to estimate the image sizes, till now I had been using my own estimations at gluck and it is now when I switched to debian-cd current estimations that DVD and CD sizes have gone wrong. So, I'd like to fix what we currently have in debian-cd, Raphael sugested (if I recall well) that we should change the disks-$ARCH directory size by the size of the installer-$ARCH directory (Raphael, correct me if this was not what you told me), the problem here is that not all the images in the installer dir are used, for ecample: du -s debian/dists/sarge/main/installer-i386/current/images/ 60064 debian/dists/sarge/main/installer-i386/current/images ls debian/dists/sarge/main/installer-i386/current/images/ MANIFEST MD5SUMS cdrom floppy hd-media netboot The thing is that only 20 megs aprox of this dir are used, which corresponds to the cdrom and floppy dirs, but this can change with the arches. The only way I see to estimate images sizes in the cds would be to do the download/cp of the images from the web/mirror into the tmp directory before we calculate the sizes, thus in the build.sh script. I can see, without thinking too much on the problem and not knowing the code well, at least a way to do this: calling the boot scripts with a "predownload" parameter that only does the downloading or cp of all the stuff to a dir into the tmp space, and then when the boot script is called in the usual way by the Makefile, they check that this dir is already created and they don't download the stuff again. This would mean that we need to modify all boot scripts. What we'd get of this, would be the real size of all the extra stuff put on the cds for all the arches in real time, wich is one of the parameters we are looking for. If we take a real example where the space reserved for boot files was 0... CD 1 filled with 652854624 bytes ... (limit was 660602880) this means that it is calculating around 622 megs of packages, and it ended up with an image of 650MB If we analyse the space in the tmp dir for CD1... /CD1$ du -s --apparent-size * 11 README.html 76 README.mirrors.html 38 README.mirrors.txt 6 README.txt 1 debian 1430dists 771 doc 20457 install 115 md5sum.txt 19 pics 640410 pool 986 tools we can see that pool has 626 megs, which is a little bit more than calculated (anybody knows where this 4 megs came from?), and then we see that most of the other space is from the install directory (the space I was trying to estimate coming from the boot images and all that) and then a bit from the doc, tools and dists (packages files), if we stimate by hand the size of these last ones and we calculate the size of the images we can have a good stimation on the size of the files we are putting in, don't you think? For example, here the estimation would say that for doc, packages and other stuff we need 4 megs, then we calculate the size of install, which is 20, and we add that to the 622 that we had already, and we get 646, which is a little bit under the ISO size, but that is a good estimation as we didn't take into account the extras that the filesystem imposes. That is another of the problems we have, estimating the extra space added by the filesystem, for what I know, that can change quite a lot the size of the images on some arches, I know we already have some ways to try to estimate this, but I haven't yet examined this, anybody that knows other arches or the scripts we use for this wants to say something on this? is this really problematic? or to we already have a solution for this? We'll I now have a quite fast raid 0 here at home, so I'll be making some tests, here, but what I don't have is a good bandwith to be able to make tests with all arches and right now I only have a mirror for i386 :-( I accept all kind of help, comments, hints, ... with all this, I don't know the code we use for all this size estimations, so anybody wanting to help is at least as qualified as I aam ;-) Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: size of DVD-image sarge-i386-1.iso is too large?
> i think that the the iso-file sarge-i386-1.iso does not fit on a DVD+RW > (gross capacity 4.700.372.992 bytes). I tried to download it with I have downloaded the image: -rw-r--r-- 1 manty manty 4702103552 Sep 2 00:24 sarge-i386-1.iso and burned it on several dvd media without any problem in sizes, did you test that on a real DVD? Does anybody know what is the real limit in bytes for the size of an image to be written to a normal DVD? Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Single DVD official Sarge images??
> Any plan for single DVD official Sarge images, maybe not now, but at least > when sarge moves to stable? The current archive should fit on either a Yes, we are planning to release with official DVD images to be burned on a single DVD. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ppc and m68k images getting too big
>Hmmm. It looks like the HFS hybrid stuff on ppc/m68k makes the images >too large if I don't tweak the image sizes substantially. On a >DVD-sized image I'm going ~300MB too big, which is a bit of a >problem. Is anybody else seeing this? Manty? Sorry it took me so long to reply, I seem to be lacking the avility to find free time lately. Yes, I'm seing differences in sizes in powerpc and m68k cds, right now my script to build cds at gluck says this: if [ ! "$SIZELIMIT1" ] then case "$ARCH" in i386)export SIZELIMIT1=65000;; ia64)export SIZELIMIT1=65000;; m68k)export SIZELIMIT1=63700;; powerpc) export SIZELIMIT1=57700;; *) export SIZELIMIT1=65700;; esac fi if [ ! "$SIZELIMIT" ] then case "$ARCH" in m68k) export SIZELIMIT=64000;; *)export SIZELIMIT=67000;; esac fi This were just adjustments I did having a look at the resulting sizes of the cds. For what I see m68k is bigger in every cd, but powerpc isn't, the differences in the first cd sizes could be due to the stuff put on the cd by d-i (kernels, images, ...) I think this can be handled using the .calc files in debian-cd, but I have never used that, anybody can enlighten us? Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
revising the first cd contents...
Hi! We have a problem with the first cd as we don't even have any xserver there, so I'm trying to go through that and as I don't have much experience with deiban-cd code myself, I'll try to comment here things that look weird to me or that I think should be changed. The target should be to have really the packages we and our users want on the first cd, for example, Joey Hess wanted the desktop task to be available, but this task depends on both x-window-system-core, kde and gnome. Testing on a newly base installed bachine, tells me that installing desktop task needs to download 353 MB, and we know that our netinst cds (debian installer + base) is already 110 MB in size, adding them would mean 465 megs, leaving almost 200 megs free for other stuff, not bad at all, but are this real numbers for our dear debian-cd? I don't think so. The thing is that on the netinst cds we just have the base stuff, but on full cds we have all the standard system, and also we add recommends and suggests, and also that we have a forcd1 task that adds stuff to cd1 and doesn't add the packages needed for the desktop task. I have done some tests and we can have on our first cd both x-window-system-core, kde-core and gnome-core as well as all the stuff we add in forcd1 task, this is using normal options, adding recommends and suggests. Note that I added -core versions of kde and gnome, and not the full kde and gnome, which wouldn't fit. I don't know however if this would give good contents for this cd. Trying to add full kde and gnome (not the -core stuff) resulted on not fitting on the first cd, not even if I choose just kde or gnome and not both. This is however adding recommends and suggests. I've done some different tests, this are some numbers I got from them: Normal build (with recommends and suggests): Standard system already takes 481498058 bytes on the first CD. Trying to add x-window-system-core... $cd_size = 524856070, $size = 25958248 Trying to add gnome-core... $cd_size = 550814318, $size = 81092036 Trying to add kde-core... $cd_size = 631906354, $size = 10605184 Modified build (without recommends and suggests): Standard system already takes 424595680 bytes on the first CD. Trying to add x-window-system-core... $cd_size = 500982974, $size = 25958248 Trying to add gnome-core... $cd_size = 526941222, $size = 34316326 Trying to add kde-core... $cd_size = 561257548, $size = 44965402 As you can see, removing recommends and suggests get's us 36 megs of space on the first cd. The increment in size on adding kde-core to the modified build with respect to the normal build, is caused because in a normal build gnome's suggests and recommends pull a lot of thing on which kde depends, like qt. Other numbers taken from a freshly installed base from sarge: installing x-window-system-core gnome and kde (task desktop) downloads 353 MB installing x-window-system-core will download 43 MB installing x-window-system-core + gnome will download 197 MB installing x-window-system-core + kde will download 215 MB Well, that is the data I've got, maybe it is not too usefull, I know this, but it is all I could get in this last days (not too much free time lately and less time in the future). I'd like you to express your opinion on how we should build, what we should have on forcd1 task, if we should build with or without recommends and suggests (this doesn't mean that recommended and sugested packages aren't put on the cds, just that we don't try to pull them in with the package that suggests them, so they are added later), ... Now a couple of comments and doubts I have on our builds: First one: When we build rawlist we do: $(Q)if [ -x "/usr/sbin/debootstrap" -a _$(INSTALLER_CD) != _1 ]; then \ /usr/sbin/debootstrap --arch $(ARCH) --print-debs $(CODENAME) \ | tr ' ' '\n' >>$(BDIR)/rawlist; \ fi But then task base-sarge, included from Debian_sarge, is generated using: for arch in alpha arm i386 ia64 m68k powerpc sparc mips mipsel hppa s390 do echo "#ifdef ARCH_$arch" debootstrap --arch $arch --print-debs $CODENAME | tr ' ' '\n' | grep -v "^$" echo "#endif" echo "" done So I'm asking myself if the data which is supposed to be included in base-sarge is not already included in rawlist and even more up to date as it is built on runtime not like base-sarge which dates from debootstrap 0.2.23, if so... why is base-sarge needed at all? Second one: I have one question about this tasks, how is forcd1 generated? Is forcd1 for sarge? for any release? Shouldn't it be different for each release? maybe a name like forcd1-sarge and some purging, additions, reordering, ... here should be in place? Third one: We are building with contrib, like we have done in the past, how about adding contrib just to the last media? after all main has gone in? I think this is not posible with current debian-cd, anybody wanting to make the modifications to allow this? Feel free to sugest and
Re: non-US
> Maybe, yes. Or alternatively just drop the non-US area altogether. > Manty, what do you do at the moment? Right now we are producing cds without non-US and with main and contrib on them. One question I have is why is the contrib included, and if it is included, I think it would be good to have them on the last of the disks, but this is not supported right now in debian-cd, if anybody likes the idea and wants to add this feature to debian-cd I think it would be welcome :-) > Probably, yes. But *which* 700 MB media? I've had problems with > Knoppix not fitting on some of the 700MB media I've bought. Of course, > now creating the jigdo files is so cheap, it's feasible to produce > multiple images/sets in the following priority: I like the idea, there are so many medias now, that just building on the smaller ones for compatibility doesn't sound good. I'm specially looking forward to the double layer dvds, that would mean just one dvd with all our binary packages :-) Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: TRANS.TBL on CDs
> OK. What size difference is there? It won't be huge (a few bytes per > directory), but I'd expect it to be noticeable, especially on the > businesscard image where we're short of space. Well, it is difficult to mesure, I mean, cds change from one day to the next one, The smaller difference I saw was 250K on businesscard and 500K on netinst, what I can say is that all cds built without TBL seem to be a little bit smaller than those built the day before, but again, this could be due to package changes in the cds, so this is not significative at all. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing CD/DVD images "Official"?
> I'm working on getting setup to become yet another Debian-CD vendor, and > am wondering about the proper labeling for the testing CD/DVD images > available from http://cdimage.debian.org/pub/cdimage-testing/ I wouldn't even think in distributing those images, either official or unofficial, they have not been well tested and the few test they have had show that they are badly broken, the testing until now has been done using the small cd images (businesscard and netinst) and not the full sized cd images or dvd images. > Can images formed from the .jigdo files/templates available here be > labeled 'official' (assuming MD5 sums match) ie: > > Debian GNU/Linux > Testing "Sarge" > Official Snapshot > alpha Binary-1 > I'd say that it is better for everyone if they are not yet distributed, but maybe somebody with release powers can tell you something else :-? Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: TRANS.TBL on CDs
> >Agreed. Feel free to commit a fix. > Done. I have applied your changes to gluck before today's build, but I do not see any important changes in sizes :- at least comparing today's build with yesterday's and I have checked them and there is no TRANS.TBL files on them. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian_sarge task missing debian-installer+kernel?
Hi! Joeyh Hess has told me today that he had noticed that some files included in the debian-installer+kernel were not included in some cds (debian-educ) and that after seing this he had found that debian-installer+kernel was not included in the Debian_sarge task. I believe that debian-installer+kernel should be part of Debian_sarge, unless there can be a problem if any package part of debian-installer+kernel is already in Debian_sarge, I have included debian-installer+kernel from Debian_sarge at gluck, for testing purposes, but I'd like to know opinions on this from other people, is this wrong? Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JTE (Jigdo Template Export) v1.0
On Jun 07 2004, Richard Atterer wrote: > Yes, but once you can use the cache, mkisofs needn't even read the file > data anymore. It could just skip over the file, output the filename to the > .jte and leave the rest to jigdo-file. I can imagine that image creation > would be a matter of 30 seconds that way... Wow, this would really speed things up a lot. BTW... now that you are at this, I remember talking to Richard about a warning in the dvd creation logs, because of files over the 4 gigas, and indeed I think that we are having some kind of trouble with jigdo creation on dvds, as the templates for i386 dvds sum around 265 megs where the templates for the cds sum under 15 megs. Richard: I remember that you were about to put out a new version of jigdo that could help in this, how is this going? Well, I'm commenting all these because DVDs are really going to be important for our distro in the near future, whether it is in 4.7 gigs dvd format or even bigger to allow us to distribute sarge on a single double layer media dvd. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: jogdo-files für die Testing-Distribution auf CD
> Ich habe heute versucht, die CD-images für die Testing-Version von > Debian herunterzuladen. Dabei gab jigdo-lite für Windows mir den Fehler, > daß unter Windows keine Image, die größer ist als 2 GB gemacht werden > kann. No german here, but I'd say... it was my fault, and it is solved now, if not, please try to explain in english what the problem is :-) Regards -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: jigdo CD directory contains DVD images
> it seems a mistake was made on the primary mirror for CD jigdo files - the Yes, my fault, should be solved now! Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why is the new jigdo test template soo large?
> Any clue? Maybe you got the dvd template that a bug I made put instead of the cd one. If it was that, it should be solved now, if it isn't please tell us. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cd -- dvd
> I think that in > http://cdimage.debian.org/pub/cdimage-testing/cd/jigdo-area/i386/ isnt CD > but DVD version. This was a mistake I made (cut and paste is not good if you don't change what needs to be changed) but it was autofixed this morning as the weekly build finished. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
mipsel cd images available for testing
Hi! Today we have produced our first set of mipsel cd images of testing, they have not yet been tested, so we need people with cd equiped mipsel machines to test the new images, they are available at the usual place, which for mipsel is: http://cdimage.debian.org/pub/cdimage-testing/sarge_d-i/mipsel/current/ or rsync://cdimage.debian.org/cdimage-testing/sarge_d-i/mipsel/current/ If you can test booting and/or installation with this images, please report back on the lists. Thanks in advance. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing CD/DVD jigdo files
> Hi, I've changed the links. Sorry, somehow I completely missed that that > location has changed. What is the difference to the files on gluck? Judging > from the timestamps, the files on gluck are still updated weekly. The files on gluck and on cdimage.debian.org are the same, they are generated on gluck and then mirrored to cdimage.debian.org, gluck was having too much network load, nobody could work on it as it was overloaded with all the cds, so we have thrown the load on to cdimage.debian.org. And yes, the dvds and full cds are still generated weekly, only the netinst images are generated daily and in four brands per arch ;-) Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing CD/DVD jigdo files
> According to http://www.debian.org/CD/jigdo-cd/, official "testing" > images can be found at: http://gluck.debian.org/cdimage/testing/ I believe that should be changed, the official place for the testing cds is now http://cdimage.debian.org/pub/cdimage-testing/ and you can also get your precious rsync access at rsync://cdimage.debian.org/cdimage-testing/ Any webmaster around that could change the url for the cds? Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6 kernels and CDs
> Anyway, I'm concerned that this will probably not fit on a netinst iso > image. The current netinst iso is 106 mb (that includes the existing > 2.6.5 kernel udebs; it's under 200 mb without them). To add full 2.6 > support, we would need to add a vmlinux file and an initrd for the 2.6 > kernel (3.9 mb), plus the kernel-image.deb (14 mb). That would increase > the netinst iso to 124 mb in size. Just for the readers of the lists that don't hang on irc all the time ;-) Yesterday we solved the space problems on the netinst cds and started making sid_d-i cds (both businesscard and netinst) for i386 that have dual boot, allowing us to boot linux (for kernel 2.4) or linux26 (for kernel 2.6) along with their repective expert options. As soon as the sarge d-i images add support for 2.6, also sarge_d-i cds, the full cd set and the dvds will also have dual boot on their first disc. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Dirty workaround for size reduction in the netinst cds
Hi! There problem in the code that selects the packages to go into the cds when we use either metapackages such as mail-transport-agent, for example, or we give alternatives, this translates into a problem in the size of the netinst cds, I have talked about this with Raphael already. The thing is that I have found a kind of workaround for this problem, the thing is that if we order the list of packages a bit the problem gets solved. We did this by hand with good results, at least goo enough so that we made room in the netinst cds for adding 2.6 kernel to them without going over a size which would break the 128 MB usb images. The problem was how to translate this into debian-cd code, and I did so at gluck by "hinting" the list, I mean that I added a couple of good hints at the beginning of the list so that the problematic dependencies that were throwing a lot of unwanted stuff in the cds get covered with this hints and thus we avoid that extra stuff. I know this is a dirty thing, thats why I have commited the stuff for having the 2.6 in the images but not this part of the code, which only aims size reduction on the netinst cd, and I'm posting it here asking for comments on it and if I should commit it or not. Thanks in advance. Regards... -- Manty/BestiaTester -> http://manty.net --- debian-cd/Makefile 2004-03-25 07:35:36.0 +0100 +++ Makefile2004-04-21 13:09:03.0 +0200 @@ -331,6 +331,8 @@ # Build the raw list (cpp output) with doubles and spaces $(BDIR)/rawlist: +# Hint for saving space on netinst images + /bin/echo -e "mawk\nexim4-daemon-light\nunifont" >>$(BDIR)/rawlist ifdef FORCENONUSONCD1 $(Q)$(apt) cache dumpavail | \ grep-dctrl -FSection -n -sPackage -e '^(non-US|non-us)' - | \ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Should we change the way we boot?
Hi! Some time ago somebody asked on our lists why didn't we made our cds behave like the Windows cd do, in the sense that if you forget the cd in the drive while rebooting the machine, and this one boots from the cd, if the user doesn't touch the keyboard in a certain time, the boot continues from the Hard Disk. I have written an small assembler .cbt program today that if called from syslinux, isolinux, ... boots from the HD, if that fails it tries with the FD, and if that fails outputs a message saying that boot has failed and waits for the user to hit a key and then reboots. The program is quite silly (asembled with nasm takes 140 bytes right now) but can be extended to be more verbose, to check if the read sectors have the 55AA mark, or whatever we wish, in fact, sugestions are welcome (you can find the source code, which is GPL, at manty.net/boothdfd.asm). The idea would be to call this program on syslinux if the timeout of syslinux expires, so that if the user has not touch any key before this timeout, the boot continues from the HD. The problem with this idea is that, to make the program run when syslinux times out, this program must be syslinux default boot, and thus, if you just hit enter or return, you'll end up booting from your HD instead of booting the install, which is what we did up to now, and this can be confusing for the people. We have one thing that can help our users not to be confused because of this change, and it is the new splash screen, being something new, people will look at it and I suppose they'll read what we put under it, so if we put there something like... Press F1 for help, or ENTER to boot from HD or type "go" to install: Or something even more short and clear, it shouldn't be confusing for them. Another way to solve this, would be to change syslinux and isolinux to allow two different defaults, one for the timeout (which in our case would be to boot this program that boots from the HD) and another one for the case on which people just hits enter. There are even more posibilities, maybe modifying syslinux is not needed at all to have a kernel and a .cbt called, maybe somebody with more knowledge on syslinux can solve this with its config, or other ideas come up with a good way around the problem, ... Anyway, I'm not saying that we should change the way we boot, I'm just exposing a posibility we have, that can of course be enhanced with ideas from anybody, and that can be dropped into the basket if people doesn't like it. If somebody wants to test all this, just nasm boothdfd.asm -o boothdfd.cbt and set it as DEFAULT for syslinux, isolinux, pxelinux, ... So, time for ideas, comments, ... Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Syncing my stuff at gluck with cvs, or asking for sugestions.
Hi! I'm trying to sync the stuff we are currently using at gluck for building the testing cds with what we have at cvs, but I have several doubts, so sugestions are welcome. First of all I'd like to say that the stuff we are using at gluck should now be available at http://people.debian.org/~manty/debian-cd/ Also I'd like people to know that before the beta3 of d-i I started to use a new version of isolinux, the one we have at sid and sarge right now, and it seems to be working ok, no problems so far, so I'l be commiting this in my next update. Also there are a lot of boot scripts updates for sarge including new arches being supported and things like that. Now, for the conflictive stuff... It seems that the old ofboot.b for yaboot that you can see at http://cvs.debian.org/debian-cd/data/yaboot/ofboot.b?rev=1.5 is having some kind of troubles with some of the subarches we currently support at sarge, so I've been told to use another one, you can see it at http://people.debian.org/~manty/debian-cd/data/sarge/yaboot/ofboot.b The thing is that I don't know if changing this ofboot.b file would be also good for woody or not, I mean, do I update the old ofboot.b file with this new one? or do I put the new one in the sarge/yaboot dir like I have it now? We have new sparc configs, same files we used to have at data/sparc/ I have placed these files at data/sarge/sparc to avoid breaking woody and other older distros, but I don't know what to do with the old dir, is it ok to leave it like it is now? I'll be looking for your comments on this. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: d-i powerpc for testing CD
> That's good to know. I don't plan to stop building it, but actually the > build system is a laptop that sometimes I bring with me. So my new > question is: could you please tell me when are those images used? I > would like to provide always an updated kernel from SVN. Sorry for the late reply, last week or so, we switched to luther's images, which he is building from newer d-i stuff producing more images, ... so you can stop building yours if you want, at least till luther's autobuilder stops ;-) Thanks for your helping anyway. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: d-i powerpc for testing CD
> Now I would like to knoe if these images are still used for creating > debian-cd or not. If this is the case I would like to accomodate the > upload timeframe and other options. If you look at gluck's file... /org/cdimage.debian.org/setup/debian-cd/tools/boot/sarge/boot-powerpc you can see there... DI_WWW_HOME="http://people.debian.org/~eppesuig/debian-installer/daily-powerpc-build/daily/cdrom"; so... yes, it is being used, and unless you don't want to build them and somebody else does, I'll continue using yours :-) BTW: Thanks for building and for caring about them ;-) Regards... -- Manty/BestiaTester -> http://manty.net
Re: d-i powerpc for testing CD
> Now I would like to knoe if these images are still used for creating > debian-cd or not. If this is the case I would like to accomodate the > upload timeframe and other options. If you look at gluck's file... /org/cdimage.debian.org/setup/debian-cd/tools/boot/sarge/boot-powerpc you can see there... DI_WWW_HOME="http://people.debian.org/~eppesuig/debian-installer/daily-powerpc-build/daily/cdrom"; so... yes, it is being used, and unless you don't want to build them and somebody else does, I'll continue using yours :-) BTW: Thanks for building and for caring about them ;-) Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: official Testing cd images finally available through rsync
> We have already mirrored .jigdo & .template files (no available bandwidth for > the ISO's). The isos really take few few bandwith, I typically get a rsync speedup on them of about 30 to 60 from one day to the next one, and they are only 100 megs in size. You can gather just the daily image and not the others we keep, or gather them all and use the preseeding script I have posted or something similar, so that rsync downloads only a few megs for each image. Unfortunately, presently our mirror is not visible beyond bg ip > space and is not to be reported on this list. > > Will we have the same daily generation for unstable distribution ? I don't think so, the aim of building Testing images is to test the shape of Testing, which changes, but not as much as unstable, I persinally don't see the point in recording something as volatile as unstable on a media like a CD, however if Debian leaders see the need for this, they'll be built. Regards... -- Manty/BestiaTester -> http://manty.net
Re: official Testing cd images finally available through rsync
> We have already mirrored .jigdo & .template files (no available bandwidth for > the ISO's). The isos really take few few bandwith, I typically get a rsync speedup on them of about 30 to 60 from one day to the next one, and they are only 100 megs in size. You can gather just the daily image and not the others we keep, or gather them all and use the preseeding script I have posted or something similar, so that rsync downloads only a few megs for each image. Unfortunately, presently our mirror is not visible beyond bg ip > space and is not to be reported on this list. > > Will we have the same daily generation for unstable distribution ? I don't think so, the aim of building Testing images is to test the shape of Testing, which changes, but not as much as unstable, I persinally don't see the point in recording something as volatile as unstable on a media like a CD, however if Debian leaders see the need for this, they'll be built. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem with sarge-i386-7 jigdo
> When attempting to use jidgo to download sarge-i386-7.jigdo, I get the > following error message for the first 50 files (different file name for > each error, of course) after which jigdo stops. All the other jigdo > downloads work fine (so I'm not doing something wrong) Umm, I have tested right now and I don't get the problem you are getting, this is what happened to me when testing with... http://gluck.debian.org/cdimage/testing/cd/jigdo-area/i386/sarge-i386-7.jigdo: FINISHED --01:16:41-- Downloaded: 3,130,314 bytes in 5 files Found 5 of the 13 files required by the template Copied input files to temporary file `sarge-i386-7.iso.tmp' - repeat command and supply more files to continue - 8 files not found in previous pass, trying alternative download locations: --01:16:44-- http://gluck.debian.org/cdimage/snapshot/cd/i386/Debian/pool/main/m/mini-dinstall/mini-dinstall_0.6.16_all.deb => `sarge-i386-7.iso.tmpdir/gluck.debian.org/cdimage/snapshot/cd/i386/Debian/pool/main/m/mini-dinstall/mini-dinstall_0.6.16_all.deb' Resolving gluck.debian.org... 192.25.206.10 Connecting to gluck.debian.org[192.25.206.10]:80... connected. HTTP request sent, awaiting response... 200 OK Length: 37,092 [application/x-debian-package] 100%[>] 37,09220.49K/s As you can see I don't have all the files, as this image was generated on saturday and the mirror I'm using is up to date, so there are things on the cd that are no longer on the mirror, however, we have an snapshot of the files that can be needed to reconstruct the cd, and as you can see, after finishing with the mirror I use, it tries teh alternative locations, finding the files it needs and finally finishing the cd with success, as you can see here: Successfully created `sarge-i386-7.iso' - Finished! The fact that you got this far is a strong indication that `sarge-i386-7.iso' was generated correctly. I will perform an additional, final check, which you can interrupt safely with Ctrl-C if you do not want to wait. OK: Checksums match, image is good! If you can provide any further info, like the date of the .jigdo and .template files you are using from gluck.debian.org, and the output of jigdo-lite, then we may get to know what is happening to you. Regards... -- Manty/BestiaTester -> http://manty.net
Re: Problem with sarge-i386-7 jigdo
> When attempting to use jidgo to download sarge-i386-7.jigdo, I get the > following error message for the first 50 files (different file name for > each error, of course) after which jigdo stops. All the other jigdo > downloads work fine (so I'm not doing something wrong) Umm, I have tested right now and I don't get the problem you are getting, this is what happened to me when testing with... http://gluck.debian.org/cdimage/testing/cd/jigdo-area/i386/sarge-i386-7.jigdo: FINISHED --01:16:41-- Downloaded: 3,130,314 bytes in 5 files Found 5 of the 13 files required by the template Copied input files to temporary file `sarge-i386-7.iso.tmp' - repeat command and supply more files to continue - 8 files not found in previous pass, trying alternative download locations: --01:16:44-- http://gluck.debian.org/cdimage/snapshot/cd/i386/Debian/pool/main/m/mini-dinstall/mini-dinstall_0.6.16_all.deb => `sarge-i386-7.iso.tmpdir/gluck.debian.org/cdimage/snapshot/cd/i386/Debian/pool/main/m/mini-dinstall/mini-dinstall_0.6.16_all.deb' Resolving gluck.debian.org... 192.25.206.10 Connecting to gluck.debian.org[192.25.206.10]:80... connected. HTTP request sent, awaiting response... 200 OK Length: 37,092 [application/x-debian-package] 100%[>] 37,09220.49K/s As you can see I don't have all the files, as this image was generated on saturday and the mirror I'm using is up to date, so there are things on the cd that are no longer on the mirror, however, we have an snapshot of the files that can be needed to reconstruct the cd, and as you can see, after finishing with the mirror I use, it tries teh alternative locations, finding the files it needs and finally finishing the cd with success, as you can see here: Successfully created `sarge-i386-7.iso' - Finished! The fact that you got this far is a strong indication that `sarge-i386-7.iso' was generated correctly. I will perform an additional, final check, which you can interrupt safely with Ctrl-C if you do not want to wait. OK: Checksums match, image is good! If you can provide any further info, like the date of the .jigdo and .template files you are using from gluck.debian.org, and the output of jigdo-lite, then we may get to know what is happening to you. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: official Testing cd images finally available through rsync
One other thing, it would be good that people mirroring this would report it
to us so that we can have all the mirrors at the web pages and people can
use them.
> One recommendation for people wanting to make mirrors of this to other
> sites, as the daily cds are being built on different directories but the
> ones built one day are similar to those built before or after, it is a good
> idea to populate the directory tree copying the images from the last build
> to the directory where the new images are expected to be created, this will,
> thanks to rsync, save a lot of bandwidth.
I have written this little script to make the preseeding:
#!/bin/sh
DATE=`/bin/date -u +%Y%m%d`
find ~/cdimage-testing/*_d-i -type l -name current -printf "%h/%l\n" |
while read i;do
dir="${i%/*}"
name="${i##*/}"
if [ -d "$dir/$name" -a ! -e "$dir/$DATE" ]
then
cp -a "$dir/$name" "$dir/$DATE"
fi
done
DATE here is supposed to be the name of the directory of the new images at
gluck, the expresion I use at the script is the same used at gluck, but if
the script is executed long time after it is executed at gluck, then the
resulting name will be different.
This is to be used for preseeding of the daily images, which are usually
created at gluck right after the mirror push ends over there, which is
usually before 21h utc, but sometimes it can be a little bit later, it
should never be after 22h utc.
Hope this helps setting up the mirrors.
Regards...
--
Manty/BestiaTester -> http://manty.net
official Testing cd images finally available through rsync
Hi! At last we have the cd images available through rsync. Everything available at http://gluck.debian.org/cdimage/testing is now available via rsync at rsync://cdimage.debian.org/cdimage-testing The size of all this is over the 7 gigs (7747560k) and can grow even more as we add more arches. But you don't need to mirror it all, you can do partial mirrors if this is too much for you, dropping daily builds or full dvds or cds, ... The mirroring over there is not yet automatic, I'll work on that in the next few days. One recommendation for people wanting to make mirrors of this to other sites, as the daily cds are being built on different directories but the ones built one day are similar to those built before or after, it is a good idea to populate the directory tree copying the images from the last build to the directory where the new images are expected to be created, this will, thanks to rsync, save a lot of bandwidth. Hope this helps more and more people test the cds now that we are getting very near to the beta3 of the Debian-installer. If anything is not clear, just ask. Regards... -- Manty/BestiaTester -> http://manty.net
Re: official Testing cd images finally available through rsync
One other thing, it would be good that people mirroring this would report it
to us so that we can have all the mirrors at the web pages and people can
use them.
> One recommendation for people wanting to make mirrors of this to other
> sites, as the daily cds are being built on different directories but the
> ones built one day are similar to those built before or after, it is a good
> idea to populate the directory tree copying the images from the last build
> to the directory where the new images are expected to be created, this will,
> thanks to rsync, save a lot of bandwidth.
I have written this little script to make the preseeding:
#!/bin/sh
DATE=`/bin/date -u +%Y%m%d`
find ~/cdimage-testing/*_d-i -type l -name current -printf "%h/%l\n" |
while read i;do
dir="${i%/*}"
name="${i##*/}"
if [ -d "$dir/$name" -a ! -e "$dir/$DATE" ]
then
cp -a "$dir/$name" "$dir/$DATE"
fi
done
DATE here is supposed to be the name of the directory of the new images at
gluck, the expresion I use at the script is the same used at gluck, but if
the script is executed long time after it is executed at gluck, then the
resulting name will be different.
This is to be used for preseeding of the daily images, which are usually
created at gluck right after the mirror push ends over there, which is
usually before 21h utc, but sometimes it can be a little bit later, it
should never be after 22h utc.
Hope this helps setting up the mirrors.
Regards...
--
Manty/BestiaTester -> http://manty.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
official Testing cd images finally available through rsync
Hi! At last we have the cd images available through rsync. Everything available at http://gluck.debian.org/cdimage/testing is now available via rsync at rsync://cdimage.debian.org/cdimage-testing The size of all this is over the 7 gigs (7747560k) and can grow even more as we add more arches. But you don't need to mirror it all, you can do partial mirrors if this is too much for you, dropping daily builds or full dvds or cds, ... The mirroring over there is not yet automatic, I'll work on that in the next few days. One recommendation for people wanting to make mirrors of this to other sites, as the daily cds are being built on different directories but the ones built one day are similar to those built before or after, it is a good idea to populate the directory tree copying the images from the last build to the directory where the new images are expected to be created, this will, thanks to rsync, save a lot of bandwidth. Hope this helps more and more people test the cds now that we are getting very near to the beta3 of the Debian-installer. If anything is not clear, just ask. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bad sarge template/jigdo file
> ftp://ftp.fsn.hu/pub/CDROM-Images/debian-unofficial/sarge-dvd/jigdo/ Official images can be found at: http://gluck.debian.org/cdimage/testing/dvd/ Regards... -- Manty/BestiaTester -> http://manty.net
Re: Will we have official DVD for Sarge?
> Could you guys tell me for the purpose of the Debian installation > manual, if Debian will officially support Sarge on a DVD (either in > a form of jigdo or a full image)? I think the question here would be what dvd sizes to support, I mean, right now we are building testing images for 4.7Gb DVDs, the ones you can typically burn at home, which means that you would need either two DVDs or a double sided DVD. Is this enough? Regards... -- Manty/BestiaTester -> http://manty.net
Re: testing net install cd image
> Its burned in 4x and works on other machines. What to do? Do you know if this machine works with other cds that boot without floppy emulation? (CD1 for woody does this, Windows 2003 does this, ...) Can you test with woody's first cd and current sarge build as of today? Thanks for testing! -- Manty/BestiaTester -> http://manty.net
Re: gluck/cdimage/snapshot
On Mar 06 2004, Greg Madden wrote: > It seems the the snapshot directory, gluck.debian.org/cdimage/snapshot/, > is out of sync with the jigdo templates, building a DVD, Sarge-1-1386 > (05-Mar-2004) is issing 85 files, Sarge-2-1386 is missing 136 packages. > Using another mirror finishes the build though. I believe you got the image while we were changing, I mean that the new images were built from the 5th to the 6th, so I believe that you where trying to complete the old image when we already had the new one set online. What is weird is that you were trying to complete it against gluck, it should have first looked at the mirror you had specified and to gluck only if it could not find the files in your mirror, and then... if gluck's snapshot didn't have the files and your other mirror didn't have them either, I'm wondering how changing to another mirror got it solved :-? I'm going to have a better snapshot system setup when time permits, so that we can have the two last builds in the snapshot. Regards... -- Manty/BestiaTester -> http://manty.net
Re: bad sarge template/jigdo file
> ftp://ftp.fsn.hu/pub/CDROM-Images/debian-unofficial/sarge-dvd/jigdo/ Official images can be found at: http://gluck.debian.org/cdimage/testing/dvd/ Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Will we have official DVD for Sarge?
> Could you guys tell me for the purpose of the Debian installation > manual, if Debian will officially support Sarge on a DVD (either in > a form of jigdo or a full image)? I think the question here would be what dvd sizes to support, I mean, right now we are building testing images for 4.7Gb DVDs, the ones you can typically burn at home, which means that you would need either two DVDs or a double sided DVD. Is this enough? Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: testing net install cd image
> Its burned in 4x and works on other machines. What to do? Do you know if this machine works with other cds that boot without floppy emulation? (CD1 for woody does this, Windows 2003 does this, ...) Can you test with woody's first cd and current sarge build as of today? Thanks for testing! -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gluck/cdimage/snapshot
On Mar 06 2004, Greg Madden wrote: > It seems the the snapshot directory, gluck.debian.org/cdimage/snapshot/, > is out of sync with the jigdo templates, building a DVD, Sarge-1-1386 > (05-Mar-2004) is issing 85 files, Sarge-2-1386 is missing 136 packages. > Using another mirror finishes the build though. I believe you got the image while we were changing, I mean that the new images were built from the 5th to the 6th, so I believe that you where trying to complete the old image when we already had the new one set online. What is weird is that you were trying to complete it against gluck, it should have first looked at the mirror you had specified and to gluck only if it could not find the files in your mirror, and then... if gluck's snapshot didn't have the files and your other mirror didn't have them either, I'm wondering how changing to another mirror got it solved :-? I'm going to have a better snapshot system setup when time permits, so that we can have the two last builds in the snapshot. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
asking for mirrors of the official testing cd images
Hi! Some people have been asking here if we could set up rsync in gluck so that mirrors of the official cd images could be set up, I have asked for this to debian-admin but there has been no answer till now. So, as I believe that the mirrors would be a good thing, I was wondering who would be insterested in mirroring and if we could setup some kind of push mirror from gluck to these mirrors, so that I could do an rsync upload, when the image creation ends, to the mirrors, or something like that (sugestions are welcome). Hope we can find some solution for this problem, comments and suggestions are welcome. Regards... -- Manty/BestiaTester -> http://manty.net
Re: Debian Sarge/testing cdimages
> about the unofficial CD images from Sarge/testing on > ftp://ftp.fsn.hu/pub/CDROM-Images/debian-unofficial/ I wonder why does people still use the ftp.fsn.hu testing images instead of the official ones, I mean, they were of a big help for people upgrading to testing in the past, but now that we have official images... do they still make sense? I'm saying this because I think that we should focus into testing the official images which tend to have an updated debian-installer and are coordinated with the debian-installer guys, I think having input from unofficial images doesn't help us improve testing, and sometimes it misleads us, as no mention to wether the problematic images are the official or the unofficial ones. > How could I fix this myself and/or could it be fixed in the next version > of the cdimages ? Why don't you get the official images? http://gluck.debian.org/cdimage/testing/ If you don't have clear what images you need, go to http://cdimage.debian.org Hope that helps. Regards... -- Manty/BestiaTester -> http://manty.net
asking for mirrors of the official testing cd images
Hi! Some people have been asking here if we could set up rsync in gluck so that mirrors of the official cd images could be set up, I have asked for this to debian-admin but there has been no answer till now. So, as I believe that the mirrors would be a good thing, I was wondering who would be insterested in mirroring and if we could setup some kind of push mirror from gluck to these mirrors, so that I could do an rsync upload, when the image creation ends, to the mirrors, or something like that (sugestions are welcome). Hope we can find some solution for this problem, comments and suggestions are welcome. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Sarge/testing cdimages
> about the unofficial CD images from Sarge/testing on > ftp://ftp.fsn.hu/pub/CDROM-Images/debian-unofficial/ I wonder why does people still use the ftp.fsn.hu testing images instead of the official ones, I mean, they were of a big help for people upgrading to testing in the past, but now that we have official images... do they still make sense? I'm saying this because I think that we should focus into testing the official images which tend to have an updated debian-installer and are coordinated with the debian-installer guys, I think having input from unofficial images doesn't help us improve testing, and sometimes it misleads us, as no mention to wether the problematic images are the official or the unofficial ones. > How could I fix this myself and/or could it be fixed in the next version > of the cdimages ? Why don't you get the official images? http://gluck.debian.org/cdimage/testing/ If you don't have clear what images you need, go to http://cdimage.debian.org Hope that helps. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
changes to Debian's web page
I didn't know were to send this, so as the changes are related to debian-cd I'm posting it here with the aim that somebody with powers to modify the web can do it. These are changes that I believe should be done because of the changes in the cd image production that we've had lately, there are new images like dvd, and also some paths have changed, I'm noting the web page and then the changes I suggest: http://www.debian.org/distrib/ Maybe a note about the DVD images should be put here. http://www.debian.org/CD/faq/ In "Are DVD images of Debian available?" section: we should modify the paragraph where we state that "only unofficial DVD images for..." to state that there are official DVD images for "testing". In "Where are the CDs for architecture X?" section: I think that the first two paragraphs should be rebuilt into one where we don't mention the stable distro as in the link we are using for the stable distro we also have links for testing, also, I plan to remove cdimage-unofficial.debian.net in the near future, so it is better if we can remove it now. In "The software on the official CDs is outdated - why don't you release a new version?" section: the last paragraph should be rewritten to let people know that there is also official testing cds and dvds, and maybe add a link so that people can find the jigdo images. http://www.debian.org/CD/jigdo-cd/ The link for the cd jigdos should now point to http://gluck.debian.org/cdimage/testing/cd/jigdo-area/ in here: * Official jigdo files for the "testing" distribution on CD (all architectures, regenerated weekly) http://www.debian.org/CD/http-ftp/ We are announcing the unofficial dvd images even though they are only available through jigdo, while the official ones, available the same way at http://gluck.debian.org/cdimage/testing/dvd/ are not announced. More enfasis on the official images, even though the only ones we have available without jigdo are the netinst ones (I think that the netinst images should be announced in this page having a link to the netinst page from this one). I think we should make clear that the unofficial ones are unsupported and that people wanting to test or install testing should use the official version, not the unofficial one. remove: Another group of people in Spain produce their own set of CD images for the "testing" distribution. You should probably only use the images accessible via this site if the fsn.hu images are not suitable for you, for example because you need images for a non-i386 architecture. Well, guess that is all for now. Regards... -- Manty/BestiaTester -> http://manty.net
changes to Debian's web page
I didn't know were to send this, so as the changes are related to debian-cd I'm posting it here with the aim that somebody with powers to modify the web can do it. These are changes that I believe should be done because of the changes in the cd image production that we've had lately, there are new images like dvd, and also some paths have changed, I'm noting the web page and then the changes I suggest: http://www.debian.org/distrib/ Maybe a note about the DVD images should be put here. http://www.debian.org/CD/faq/ In "Are DVD images of Debian available?" section: we should modify the paragraph where we state that "only unofficial DVD images for..." to state that there are official DVD images for "testing". In "Where are the CDs for architecture X?" section: I think that the first two paragraphs should be rebuilt into one where we don't mention the stable distro as in the link we are using for the stable distro we also have links for testing, also, I plan to remove cdimage-unofficial.debian.net in the near future, so it is better if we can remove it now. In "The software on the official CDs is outdated - why don't you release a new version?" section: the last paragraph should be rewritten to let people know that there is also official testing cds and dvds, and maybe add a link so that people can find the jigdo images. http://www.debian.org/CD/jigdo-cd/ The link for the cd jigdos should now point to http://gluck.debian.org/cdimage/testing/cd/jigdo-area/ in here: * Official jigdo files for the "testing" distribution on CD (all architectures, regenerated weekly) http://www.debian.org/CD/http-ftp/ We are announcing the unofficial dvd images even though they are only available through jigdo, while the official ones, available the same way at http://gluck.debian.org/cdimage/testing/dvd/ are not announced. More enfasis on the official images, even though the only ones we have available without jigdo are the netinst ones (I think that the netinst images should be announced in this page having a link to the netinst page from this one). I think we should make clear that the unofficial ones are unsupported and that people wanting to test or install testing should use the official version, not the unofficial one. remove: Another group of people in Spain produce their own set of CD images for the "testing" distribution. You should probably only use the images accessible via this site if the fsn.hu images are not suitable for you, for example because you need images for a non-i386 architecture. Well, guess that is all for now. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
changes to make cds with a special d-i version
Hi!
This are the changes I made at gluck to be able to build cds for a version
of Debian using Debian installer from another version, for example, the
sid_d-i netinst images we are making using Debian installer from sid and
having the packages from sarge.
It is a quick hack I did, so sugestions are welcome, specially on how to
handle the DI_CODENAME thing at the CONF.sh (BTW, CONF.sh on debian dir is
completely out of sync with the other one).
Raphael, if you like this I can commit it, I still have some other misc
stuff around, but that is not related, so I guess I'll commit them later on.
Index: CONF.sh
===
RCS file: /cvs/debian-boot/debian-cd/CONF.sh,v
retrieving revision 1.36
diff -u -r1.36 CONF.sh
--- CONF.sh 18 Dec 2003 10:22:38 - 1.36
+++ CONF.sh 7 Feb 2004 22:44:53 -
@@ -49,6 +49,12 @@
# Building woody cd set ...
export CODENAME=woody
+# By default use Debian installer packages from $CODENAME
+if [ ! "$DI_CODENAME" ]
+then
+ export DI_CODENAME=$CODENAME
+fi
+
# Version number, "2.2 r0", "2.2 r1" etc.
export DEBVERSION="3.0"
Index: tools/add_dirs
===
RCS file: /cvs/debian-boot/debian-cd/tools/add_dirs,v
retrieving revision 1.11
diff -u -r1.11 add_dirs
--- tools/add_dirs 7 Dec 2002 10:33:52 - 1.11
+++ tools/add_dirs 9 Jan 2004 17:45:28 -
@@ -44,7 +44,7 @@
mkdir -p dists/$CODENAME/non-free/binary-$ARCH
mkdir -p dists/$CODENAME/non-free/source
fi
-if [ -e "$MIRROR/dists/$CODENAME/main/debian-installer" ]; then
+if [ -e "$MIRROR/dists/$DI_CODENAME/main/debian-installer" ]; then
mkdir -p dists/$CODENAME/main/debian-installer/binary-$ARCH
fi
Index: tools/apt-selection
===
RCS file: /cvs/debian-boot/debian-cd/tools/apt-selection,v
retrieving revision 1.16
diff -u -r1.16 apt-selection
--- tools/apt-selection 7 Dec 2002 10:22:40 - 1.16
+++ tools/apt-selection 9 Jan 2004 15:56:27 -
@@ -65,12 +65,12 @@
>> $APTTMP/$CODENAME-$ARCH/apt/sources.list
fi
# Debian-installer
- if [ -e "$MIRROR/dists/$CODENAME/main/debian-installer" ]; then
- echo "deb file:$MIRROR $CODENAME main/debian-installer" \
+ if [ -e "$MIRROR/dists/$DI_CODENAME/main/debian-installer" ]; then
+ echo "deb file:$MIRROR $DI_CODENAME main/debian-installer" \
>> $APTTMP/$CODENAME-$ARCH/apt/sources.list
fi
- if [ -n "$LOCAL" -a -e
"${LOCALDEBS:-$MIRROR}/dists/$CODENAME/local/debian-installer" ]; then
- echo "deb file:${LOCALDEBS:-$MIRROR} $CODENAME
local/debian-installer" \
+ if [ -n "$LOCAL" -a -e
"${LOCALDEBS:-$MIRROR}/dists/$DI_CODENAME/local/debian-installer" ]; then
+ echo "deb file:${LOCALDEBS:-$MIRROR} $DI_CODENAME
local/debian-installer" \
>> $APTTMP/$CODENAME-$ARCH/apt/sources.list
fi
fi
Index: tools/generate_di_list
===
RCS file: /cvs/debian-boot/debian-cd/tools/generate_di_list,v
retrieving revision 1.4
diff -u -r1.4 generate_di_list
--- tools/generate_di_list 24 Dec 2003 17:19:14 - 1.4
+++ tools/generate_di_list 25 Jan 2004 13:44:09 -
@@ -1,7 +1,7 @@
#!/usr/bin/perl -w
# Generate a list of packages required for debian-installer
# This script makes use of the following variables that need to be preset:
-# MIRROR, CODENAME, BASEDIR
+# MIRROR, DI_CODENAME, BASEDIR
my @ARCHES=qw{alpha arm hppa hurd-i386 i386 ia64 m68k mips mipsel
powerpc s390 sparc sh};
my $DATE=`date`;
@@ -24,7 +24,7 @@
my @exclude = @common_excludes;
push @exclude, read_exclude("exclude-udebs-$arch")
if -e exclude_path("exclude-udebs-$arch");
- my
$packagefile="$ENV{MIRROR}/dists/$ENV{CODENAME}/main/debian-installer/binary-$arch/Packages";
+ my
$packagefile="$ENV{MIRROR}/dists/$ENV{DI_CODENAME}/main/debian-installer/binary-$arch/Packages";
UDEB: foreach my $udeb (map { chomp; $_ } `grep-dctrl -n -s Package ''
$packagefile`) {
foreach my $pattern (@exclude) {
if ($udeb =~ /^$pattern$/) {
@@ -54,5 +54,5 @@
sub exclude_path {
my $file=shift;
- return "$ENV{BASEDIR}/data/$ENV{CODENAME}/$file";
+ return "$ENV{BASEDIR}/data/$ENV{DI_CODENAME}/$file";
}
Index: tools/scanpackages
===
RCS file: /cvs/debian-boot/debian-cd/tools/scanpackages,v
retrieving revision 1.25
diff -u -r1.25 scanpackages
--- tools/scanpackages 20 Dec 2002 01:46:25 - 1.25
+++ tools/scanpackages 9 Jan 2004 15:56:27 -
@@ -91,8 +91,8 @@
fi
fi
-if [ -e "$MIRROR/dists/$CODENAME/main/debian-installer/binary-$ARCH/Release"
]; then
-cp $MIRROR/dists/$CODENAME/main/debian-installer/binary-$ARCH/Release \
+if [ -e
changes to make cds with a special d-i version
Hi!
This are the changes I made at gluck to be able to build cds for a version
of Debian using Debian installer from another version, for example, the
sid_d-i netinst images we are making using Debian installer from sid and
having the packages from sarge.
It is a quick hack I did, so sugestions are welcome, specially on how to
handle the DI_CODENAME thing at the CONF.sh (BTW, CONF.sh on debian dir is
completely out of sync with the other one).
Raphael, if you like this I can commit it, I still have some other misc
stuff around, but that is not related, so I guess I'll commit them later on.
Index: CONF.sh
===
RCS file: /cvs/debian-boot/debian-cd/CONF.sh,v
retrieving revision 1.36
diff -u -r1.36 CONF.sh
--- CONF.sh 18 Dec 2003 10:22:38 - 1.36
+++ CONF.sh 7 Feb 2004 22:44:53 -
@@ -49,6 +49,12 @@
# Building woody cd set ...
export CODENAME=woody
+# By default use Debian installer packages from $CODENAME
+if [ ! "$DI_CODENAME" ]
+then
+ export DI_CODENAME=$CODENAME
+fi
+
# Version number, "2.2 r0", "2.2 r1" etc.
export DEBVERSION="3.0"
Index: tools/add_dirs
===
RCS file: /cvs/debian-boot/debian-cd/tools/add_dirs,v
retrieving revision 1.11
diff -u -r1.11 add_dirs
--- tools/add_dirs 7 Dec 2002 10:33:52 - 1.11
+++ tools/add_dirs 9 Jan 2004 17:45:28 -
@@ -44,7 +44,7 @@
mkdir -p dists/$CODENAME/non-free/binary-$ARCH
mkdir -p dists/$CODENAME/non-free/source
fi
-if [ -e "$MIRROR/dists/$CODENAME/main/debian-installer" ]; then
+if [ -e "$MIRROR/dists/$DI_CODENAME/main/debian-installer" ]; then
mkdir -p dists/$CODENAME/main/debian-installer/binary-$ARCH
fi
Index: tools/apt-selection
===
RCS file: /cvs/debian-boot/debian-cd/tools/apt-selection,v
retrieving revision 1.16
diff -u -r1.16 apt-selection
--- tools/apt-selection 7 Dec 2002 10:22:40 - 1.16
+++ tools/apt-selection 9 Jan 2004 15:56:27 -
@@ -65,12 +65,12 @@
>> $APTTMP/$CODENAME-$ARCH/apt/sources.list
fi
# Debian-installer
- if [ -e "$MIRROR/dists/$CODENAME/main/debian-installer" ]; then
- echo "deb file:$MIRROR $CODENAME main/debian-installer" \
+ if [ -e "$MIRROR/dists/$DI_CODENAME/main/debian-installer" ]; then
+ echo "deb file:$MIRROR $DI_CODENAME main/debian-installer" \
>> $APTTMP/$CODENAME-$ARCH/apt/sources.list
fi
- if [ -n "$LOCAL" -a -e
"${LOCALDEBS:-$MIRROR}/dists/$CODENAME/local/debian-installer" ]; then
- echo "deb file:${LOCALDEBS:-$MIRROR} $CODENAME local/debian-installer" \
+ if [ -n "$LOCAL" -a -e
"${LOCALDEBS:-$MIRROR}/dists/$DI_CODENAME/local/debian-installer" ]; then
+ echo "deb file:${LOCALDEBS:-$MIRROR} $DI_CODENAME local/debian-installer" \
>> $APTTMP/$CODENAME-$ARCH/apt/sources.list
fi
fi
Index: tools/generate_di_list
===
RCS file: /cvs/debian-boot/debian-cd/tools/generate_di_list,v
retrieving revision 1.4
diff -u -r1.4 generate_di_list
--- tools/generate_di_list 24 Dec 2003 17:19:14 - 1.4
+++ tools/generate_di_list 25 Jan 2004 13:44:09 -
@@ -1,7 +1,7 @@
#!/usr/bin/perl -w
# Generate a list of packages required for debian-installer
# This script makes use of the following variables that need to be preset:
-# MIRROR, CODENAME, BASEDIR
+# MIRROR, DI_CODENAME, BASEDIR
my @ARCHES=qw{alpha arm hppa hurd-i386 i386 ia64 m68k mips mipsel
powerpc s390 sparc sh};
my $DATE=`date`;
@@ -24,7 +24,7 @@
my @exclude = @common_excludes;
push @exclude, read_exclude("exclude-udebs-$arch")
if -e exclude_path("exclude-udebs-$arch");
- my
$packagefile="$ENV{MIRROR}/dists/$ENV{CODENAME}/main/debian-installer/binary-$arch/Packages";
+ my
$packagefile="$ENV{MIRROR}/dists/$ENV{DI_CODENAME}/main/debian-installer/binary-$arch/Packages";
UDEB: foreach my $udeb (map { chomp; $_ } `grep-dctrl -n -s Package ''
$packagefile`) {
foreach my $pattern (@exclude) {
if ($udeb =~ /^$pattern$/) {
@@ -54,5 +54,5 @@
sub exclude_path {
my $file=shift;
- return "$ENV{BASEDIR}/data/$ENV{CODENAME}/$file";
+ return "$ENV{BASEDIR}/data/$ENV{DI_CODENAME}/$file";
}
Index: tools/scanpackages
===
RCS file: /cvs/debian-boot/debian-cd/tools/scanpackages,v
retrieving revision 1.25
diff -u -r1.25 scanpackages
--- tools/scanpackages 20 Dec 2002 01:46:25 - 1.25
+++ tools/scanpackages 9 Jan 2004 15:56:27 -
@@ -91,8 +91,8 @@
fi
fi
-if [ -e "$MIRROR/dists/$CODENAME/main/debian-installer/binary-$ARCH/Release" ]; then
-cp $MIRROR/dists/$CODENAME/main/debian-installer/binary-$ARCH/Release \
+if [ -e "$
Re: Problem in sarge DVD 1
> > Why don't you use the official testing images available at > > http://gluck.debian.org/cdimage/testing/ > Probably because of missing rsync --daemon. What do you need rsync for? sarge-i386-1.jigdo 23-Jan-2004 21:07 195k sarge-i386-2.jigdo 23-Jan-2004 21:07 158k sarge-i386-1.template 23-Jan-2004 19:56 277M sarge-i386-2.template 23-Jan-2004 21:06 10.8M The only file in which rsync would give you some kind of speed up is the template for the first dvd and I really don't think you'll get a lot of speedup. Anyway, I really just produce the images, I cannot say what needs to be in the machine, rsync has been requested several times, maybe we should ask the admins :-? > I also have some problems with ftp.fsh.hu files, some jigdo .templates are > still ~>600MB ... just to mention some of them: Well, I cannot tell you anything about those images. Regards... -- Manty/BestiaTester -> http://manty.net
Re: Problem in sarge DVD 1
> > Why don't you use the official testing images available at > > http://gluck.debian.org/cdimage/testing/ > Probably because of missing rsync --daemon. What do you need rsync for? sarge-i386-1.jigdo 23-Jan-2004 21:07 195k sarge-i386-2.jigdo 23-Jan-2004 21:07 158k sarge-i386-1.template 23-Jan-2004 19:56 277M sarge-i386-2.template 23-Jan-2004 21:06 10.8M The only file in which rsync would give you some kind of speed up is the template for the first dvd and I really don't think you'll get a lot of speedup. Anyway, I really just produce the images, I cannot say what needs to be in the machine, rsync has been requested several times, maybe we should ask the admins :-? > I also have some problems with ftp.fsh.hu files, some jigdo .templates are > still ~>600MB ... just to mention some of them: Well, I cannot tell you anything about those images. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem in sarge DVD 1
> http://ftp.fsn.hu/pub/CDROM-Images/debian-unofficial/sarge-dvd/jigdo/sar > ge-i386-1.template Why don't you use the official testing images available at http://gluck.debian.org/cdimage/testing/ :-? Regards... -- Manty/BestiaTester -> http://manty.net
Re: Status of the cd building (NEW: bootable cd images for hppa)
> Full CD and DVD can be done once a week. That is how we've been doing it all the time, but changes in building (I suppose it was jigdo, but also hard could have helped) have increased the time it takes a lot, so now I think we are only able to build 5 or 6 a day, not all the 11 like we used to do. We'll see what we do when more arches are added. Regards... -- Manty/BestiaTester -> http://manty.net
Re: Problem in sarge DVD 1
> http://ftp.fsn.hu/pub/CDROM-Images/debian-unofficial/sarge-dvd/jigdo/sar > ge-i386-1.template Why don't you use the official testing images available at http://gluck.debian.org/cdimage/testing/ :-? Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of the cd building (NEW: bootable cd images for hppa)
> Full CD and DVD can be done once a week. That is how we've been doing it all the time, but changes in building (I suppose it was jigdo, but also hard could have helped) have increased the time it takes a lot, so now I think we are only able to build 5 or 6 a day, not all the 11 like we used to do. We'll see what we do when more arches are added. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Status of the cd building (NEW: bootable cd images for hppa)
Hi! I'd like to let you know that we now have netinst bootable images for hppa, with that one, we are having 5 arches with bootable cds, that is however only less than half of the arches we have, so we still miss a lot of them. I'd like to thank Thorsten Sauter for his work on hppa (as well as other arches) as he was the one pushing hppa cds forward by making the d-i builds and telling me what to do to make the cds bootable ;-) There are even some problems with two of these 5 arches, namely hppa and alpha, their programs to make the cds bootable (palo and isomarkboot) are failing to work with the DVD ISOs as they are too big, if somebody can help with sorting out these bugs (#228229 and ...) it would be great. Well, aside all that, I'm thinking in how could I reschedule the full cd set and dvd set builds, as now it takes really long to build and I cannot build all cds in the same day like we used to do. So I'm wondering... should I spread the build throughout the week? or would it be better for gluck if I could build the most each day and have the machine building cds all day long during 3 or 4 days? Comments? Regards... -- Manty/BestiaTester -> http://manty.net
Status of the cd building (NEW: bootable cd images for hppa)
Hi! I'd like to let you know that we now have netinst bootable images for hppa, with that one, we are having 5 arches with bootable cds, that is however only less than half of the arches we have, so we still miss a lot of them. I'd like to thank Thorsten Sauter for his work on hppa (as well as other arches) as he was the one pushing hppa cds forward by making the d-i builds and telling me what to do to make the cds bootable ;-) There are even some problems with two of these 5 arches, namely hppa and alpha, their programs to make the cds bootable (palo and isomarkboot) are failing to work with the DVD ISOs as they are too big, if somebody can help with sorting out these bugs (#228229 and ...) it would be great. Well, aside all that, I'm thinking in how could I reschedule the full cd set and dvd set builds, as now it takes really long to build and I cannot build all cds in the same day like we used to do. So I'm wondering... should I spread the build throughout the week? or would it be better for gluck if I could build the most each day and have the machine building cds all day long during 3 or 4 days? Comments? Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Back online again (was: testing netinst isos)
Hi! I'd like to announce that we have http://gluck.debian.org/cdimage/testing back online again, even though we are still producing the cd images, so not all arches are already there. We have a new setup wich comes with even more images, and better daily images handling, all this stuff has been tested at http://people.debian.org/~manty/testing while the official url was offline, so some of you may already know it. The new stuff is: Weekly DVD images, built for 4.7Gigs DVDs Daily builds archived for some days so that we can download older builds New sid_d-i netinst images [1] Daily builds are now produced when the mirror pulse gets to gluck [1] These images right now are just like normal netinst images but are produced using the sid's debian-installer udeb packages, as now we already have testing and unstable packages for debian-installer. We'll continue to add more stuff to our setup in the future, as soon as we complete the images regeneration. Hope you enjoy the new stuff out there! Regards... -- Manty/BestiaTester -> http://manty.net
Back online again (was: testing netinst isos)
Hi! I'd like to announce that we have http://gluck.debian.org/cdimage/testing back online again, even though we are still producing the cd images, so not all arches are already there. We have a new setup wich comes with even more images, and better daily images handling, all this stuff has been tested at http://people.debian.org/~manty/testing while the official url was offline, so some of you may already know it. The new stuff is: Weekly DVD images, built for 4.7Gigs DVDs Daily builds archived for some days so that we can download older builds New sid_d-i netinst images [1] Daily builds are now produced when the mirror pulse gets to gluck [1] These images right now are just like normal netinst images but are produced using the sid's debian-installer udeb packages, as now we already have testing and unstable packages for debian-installer. We'll continue to add more stuff to our setup in the future, as soon as we complete the images regeneration. Hope you enjoy the new stuff out there! Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: restoring /org/cdimage.debian.org on gluck
> Why is it taking so long to reactivate an silly include apache.conf line... Don't ask me, I first contacted debian-admin on the 8th of December of 2003, since then I contacted them another time and Raphael Hertzog has also contacted them, but still nothing has happened. > BTW I was just referring to the timestamps under /org/cdimage.d.o which were > old. /org/cdimage.d.o? where is that? we used to have that dir, but that was moved away as part of the reinstall proccess, now there is the old copy of it, which I cleaned and updated a bit some time ago, but I'm working at $HOME till we have a full setup again. Regards... -- Manty/BestiaTester -> http://manty.net
Re: restoring /org/cdimage.debian.org on gluck
> Why is it taking so long to reactivate an silly include apache.conf line... Don't ask me, I first contacted debian-admin on the 8th of December of 2003, since then I contacted them another time and Raphael Hertzog has also contacted them, but still nothing has happened. > BTW I was just referring to the timestamps under /org/cdimage.d.o which were > old. /org/cdimage.d.o? where is that? we used to have that dir, but that was moved away as part of the reinstall proccess, now there is the old copy of it, which I cleaned and updated a bit some time ago, but I'm working at $HOME till we have a full setup again. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: jigdo problem
> - > The jigdo file refers to files stored on Debian mirrors. Please > choose a Debian mirror as follows: Either enter a complete URL > pointing to a mirror (in the form > `ftp://ftp.debian.org/debian/'), or enter any regular expression > for searching through the list of mirrors: Try a two-letter > country code such as `de', or a country name like `United > States', or a server name like `sunsite'. > Debian mirror: http://ftp2.it.debian.org/debian-non-US This is the normal debian url not the debian-non-US, so it should be: http://ftp2.it.debian.org/debian or http://ftp.it.debian.org/debian > - > The jigdo file also refers to the Non-US section of the Debian > archive. Please repeat the mirror selection for Non-US. Do not > simply copy the URL you entered above; this does not work because > the path on the servers differs! > Debian non-US mirror: http://ftp.it.debian.org/debian and this should be the non-US part, so it should read: http://ftp2.it.debian.org/debian-non-US or: http://ftp.it.debian.org/debian-non-US > Am I doing something wrong ? Yes, seems like you didn't pay too much attention to the messages of jigdo, next time read more carrefully ;-) Regards... -- Manty/BestiaTester -> http://manty.net
Re: restoring /org/cdimage.debian.org on gluck
> Do you guys need any help restoring the CD image building process? Thank you very much, but cd image building is up and running again since quite some time, the only thing that we are missing right now is the setup for apache, we are waiting for the admins to set that up, meanwhile the cds are available at http://people.debian.org/~manty/testing BTW, the setup for cd building now will even be better, offering DVDs along with the full CD sets and the netinst images :-) > It should be pretty straightforward, the CVS is back up, and the rest can > be sorted out almost trivially... They were back online again before the cvs was made available ;-) Thanks for your offer anyway ;-) Regards... -- Manty/BestiaTester -> http://manty.net
Re: jigdo problem
> - > The jigdo file refers to files stored on Debian mirrors. Please > choose a Debian mirror as follows: Either enter a complete URL > pointing to a mirror (in the form > `ftp://ftp.debian.org/debian/'), or enter any regular expression > for searching through the list of mirrors: Try a two-letter > country code such as `de', or a country name like `United > States', or a server name like `sunsite'. > Debian mirror: http://ftp2.it.debian.org/debian-non-US This is the normal debian url not the debian-non-US, so it should be: http://ftp2.it.debian.org/debian or http://ftp.it.debian.org/debian > - > The jigdo file also refers to the Non-US section of the Debian > archive. Please repeat the mirror selection for Non-US. Do not > simply copy the URL you entered above; this does not work because > the path on the servers differs! > Debian non-US mirror: http://ftp.it.debian.org/debian and this should be the non-US part, so it should read: http://ftp2.it.debian.org/debian-non-US or: http://ftp.it.debian.org/debian-non-US > Am I doing something wrong ? Yes, seems like you didn't pay too much attention to the messages of jigdo, next time read more carrefully ;-) Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: restoring /org/cdimage.debian.org on gluck
> Do you guys need any help restoring the CD image building process? Thank you very much, but cd image building is up and running again since quite some time, the only thing that we are missing right now is the setup for apache, we are waiting for the admins to set that up, meanwhile the cds are available at http://people.debian.org/~manty/testing BTW, the setup for cd building now will even be better, offering DVDs along with the full CD sets and the netinst images :-) > It should be pretty straightforward, the CVS is back up, and the rest can > be sorted out almost trivially... They were back online again before the cvs was made available ;-) Thanks for your offer anyway ;-) Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Invalid link on http://www.debian.org/CD/netinst/
> points to http://gluck.debian.org/cdimage/testing/netinst/, but this URL > seems to be invalid, as I got an HTTP 404 - File not found. We are waiting for the admins to setup cdimage back again, it was removed due to the reinstalation of gluck, meanwhile you can access the cd images at http://people.debian.org/~manty/testing Regards... -- Manty/BestiaTester -> http://manty.net
Re: Invalid link on http://www.debian.org/CD/netinst/
> points to http://gluck.debian.org/cdimage/testing/netinst/, but this URL > seems to be invalid, as I got an HTTP 404 - File not found. We are waiting for the admins to setup cdimage back again, it was removed due to the reinstalation of gluck, meanwhile you can access the cd images at http://people.debian.org/~manty/testing Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dead link on HP
> Manty, am I right in assuming that you don't want the links on the web > pages to point to your page on people.d.o? That's ok, the thing we want is the normal pages to be back ASAP, when that will be... I don't know, why I have built that in my home... to test dvd images. For going back into our old build system we need some apache setup and a directory to be moved, also we are still missing powerpc and alpha debian-installer daily images. Thanks for asking! -- Manty/BestiaTester -> http://manty.net
Re: Dead link on HP
> Manty, am I right in assuming that you don't want the links on the web > pages to point to your page on people.d.o? That's ok, the thing we want is the normal pages to be back ASAP, when that will be... I don't know, why I have built that in my home... to test dvd images. For going back into our old build system we need some apache setup and a directory to be moved, also we are still missing powerpc and alpha debian-installer daily images. Thanks for asking! -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of the images for CDs and DVDs
> Maybe we could send out a mail to everyone who filed an install report > of failure, and see if they can reproduce the failure, and also make > sure they didn't produce a CD with a .iso file on it or similar mistake. Sounds like a good idea, but we should have tested cd images before that, if you want I can build ones and test them here on a machine that I know was failing to boot beta-1. Current installer seems to be behaving well, I've been installing several machines from dvd lately without any problem, so maybe when we have /cdimage setup again we can build images and select some to be moved out of the daily directory so that they are our official testing images, or is a beta-2 near? Also, we need a list of the people who reported that kind of bug, I only have: Jeffrey Barish Jan 'Miernik' Macek Barrie James I've been looking at the installation reports and only found those with booting problems, anybody gets any others? Regards... -- Manty/BestiaTester -> http://manty.net
Re: Status of the images for CDs and DVDs
> Maybe we could send out a mail to everyone who filed an install report > of failure, and see if they can reproduce the failure, and also make > sure they didn't produce a CD with a .iso file on it or similar mistake. Sounds like a good idea, but we should have tested cd images before that, if you want I can build ones and test them here on a machine that I know was failing to boot beta-1. Current installer seems to be behaving well, I've been installing several machines from dvd lately without any problem, so maybe when we have /cdimage setup again we can build images and select some to be moved out of the daily directory so that they are our official testing images, or is a beta-2 near? Also, we need a list of the people who reported that kind of bug, I only have: Jeffrey Barish Jan 'Miernik' Macek Barrie James I've been looking at the installation reports and only found those with booting problems, anybody gets any others? Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Jigdo template size problem
> All sarge i386 .template files generated after December 5 are ~600Mb > in size, is this inentional? Where is that? I mean, my templates are around 30 megs, even the DVD ones, which are only a little bit bigger than the cd ones. > Also is it possible to generate template files locally? Sorry, I don't get this, are you building your own images? The template files for jigdo are generated by jigdo-file when we build the cd images, that's the only way I see of generating templates. Regards... -- Manty/BestiaTester -> http://manty.net
Re: Jigdo template size problem
> All sarge i386 .template files generated after December 5 are ~600Mb > in size, is this inentional? Where is that? I mean, my templates are around 30 megs, even the DVD ones, which are only a little bit bigger than the cd ones. > Also is it possible to generate template files locally? Sorry, I don't get this, are you building your own images? The template files for jigdo are generated by jigdo-file when we build the cd images, that's the only way I see of generating templates. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Status of the images for CDs and DVDs
Hi! The recovery of the functionality of our servers is taking long, we still don't have gluck.debian.org/cdimage back, however that doesn't mean we have stopped making images, in fact, we are now able to produce DVD images as well. While we don't recover gluck.debian.org/cdimage you can find the new images at http://people.debian.org/~manty/testing/ currently there are only i386 and ia64 images, but as soon as debian-installer images of alpha, powerpc and others are produced, I'll start building CDs and DVDs for those as well. I have started producing jigdos for DVDs, they are made for the standard 4.7GB DVDs, so you can have sarge binaries in one and a half DVD, or you can record it all in a double sided DVD, if anybody finds other needs, please comment them. The new tree for the images is like this: testing/ netinst/ $ARCH/ daily/ ISOs jigdo-area/ $ARCH/ JIGDOs dvd/ jigdo-area/ $ARCH/ JIGDOs This can of course be changed if anybody sugest a more logical one. I have made and tested the DVDs at Extremadura (home of Linex) during the first Debconf-ES, they worked perfectly, the only problem I found is that the 2.4.22 doesn't mount the DVD-R or DVD-RW disks on some DVD readers (at least some pioneer slot in) when using auto as the filesystem type. This has been corrected on 2.4.23, and can be workarounded by changing the fs type in /etc/fstab from auto to iso9660, or by avoiding this convination of hardware via using DVD+R or DVD+RW, for example. I'd like to comment on the bug we had with the debian-installer beta-1 cds, which weren't bootable on some machines, for what I saw, this was not isolinux fault, the businesscard cds were carrying the same isolinux and had been made using the very same isolinux options and were not failing, farther more, the netinst images made prior or after the beta-1 seem to work again. I'd like to get this tested by some other people than me, by downloading the daily netinst images we are producing now and testing them in one of the machines that didn't want to boot out of the beta-1 cds. I don't know what happened to the beta-1 cds, looking at the images everything seems ok, I tried to contact upstream of mkisofs and isolinux without luck. It seems to me either a bug in the BIOS or in mkisofs, I'll try to make more tests, but it seems quite difficult for me to find the exact problem, if anybody with more experience in bootable cds can help he is welcome to do so. Well, I think that is all for now. Regards... -- Manty/BestiaTester -> http://manty.net
Status of the images for CDs and DVDs
Hi! The recovery of the functionality of our servers is taking long, we still don't have gluck.debian.org/cdimage back, however that doesn't mean we have stopped making images, in fact, we are now able to produce DVD images as well. While we don't recover gluck.debian.org/cdimage you can find the new images at http://people.debian.org/~manty/testing/ currently there are only i386 and ia64 images, but as soon as debian-installer images of alpha, powerpc and others are produced, I'll start building CDs and DVDs for those as well. I have started producing jigdos for DVDs, they are made for the standard 4.7GB DVDs, so you can have sarge binaries in one and a half DVD, or you can record it all in a double sided DVD, if anybody finds other needs, please comment them. The new tree for the images is like this: testing/ netinst/ $ARCH/ daily/ ISOs jigdo-area/ $ARCH/ JIGDOs dvd/ jigdo-area/ $ARCH/ JIGDOs This can of course be changed if anybody sugest a more logical one. I have made and tested the DVDs at Extremadura (home of Linex) during the first Debconf-ES, they worked perfectly, the only problem I found is that the 2.4.22 doesn't mount the DVD-R or DVD-RW disks on some DVD readers (at least some pioneer slot in) when using auto as the filesystem type. This has been corrected on 2.4.23, and can be workarounded by changing the fs type in /etc/fstab from auto to iso9660, or by avoiding this convination of hardware via using DVD+R or DVD+RW, for example. I'd like to comment on the bug we had with the debian-installer beta-1 cds, which weren't bootable on some machines, for what I saw, this was not isolinux fault, the businesscard cds were carrying the same isolinux and had been made using the very same isolinux options and were not failing, farther more, the netinst images made prior or after the beta-1 seem to work again. I'd like to get this tested by some other people than me, by downloading the daily netinst images we are producing now and testing them in one of the machines that didn't want to boot out of the beta-1 cds. I don't know what happened to the beta-1 cds, looking at the images everything seems ok, I tried to contact upstream of mkisofs and isolinux without luck. It seems to me either a bug in the BIOS or in mkisofs, I'll try to make more tests, but it seems quite difficult for me to find the exact problem, if anybody with more experience in bootable cds can help he is welcome to do so. Well, I think that is all for now. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: net inst cd images are gone..
> all the net inst cd images are gone. what gives? If you are talking from gluck, I believe this is good, in fact, the ony cd images that we may want to have restored are beta1 images, and only if we can check the md5sums from good known sources, the rest of the images I can generate them as soon as I can get access to gluck again and check the cd building space. PS: if any of the admins of gluck is reading this, I believe that the hole /org/cdimage.debian.org/www/ could be renamed so that it cannot be accesible till we can make sure that all we are making available is clean. Regards... -- Manty/BestiaTester -> http://manty.net
Re: net inst cd images are gone..
> all the net inst cd images are gone. what gives? If you are talking from gluck, I believe this is good, in fact, the ony cd images that we may want to have restored are beta1 images, and only if we can check the md5sums from good known sources, the rest of the images I can generate them as soon as I can get access to gluck again and check the cd building space. PS: if any of the admins of gluck is reading this, I believe that the hole /org/cdimage.debian.org/www/ could be renamed so that it cannot be accesible till we can make sure that all we are making available is clean. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Usage of isolinux on the beta CDs
> Right, we'll want to add help screens to syslinux for all of our images > in any case. I think I understand now, isolinux uses its own help > screens which it reads from the CD, and these come from debian-cd (for > now..), but we can control the rest of them. That's it. > I don't particularly want to make the decision about which CD has > isolinux on it and which uses the old method. I do want to get the help > texts straightened out and preferably in one place, and I do want to Sounds reasonable, we can get the texts out of a package, for example, one thing that would be good is if we didn't need root for getting those texts, avoid things like loop mounting and so. > have a netinst CD without isolinux on it. Anything you guys decide that > accomplishes that is 100% fine with me, you are the ones who know all > about isolinux. Seems like isolinux has put some bugfixes to avoid problems with broken bioses and they work, at least my scsi bios can boot from sarge's cds but not from woody's first cd. We can build two netinst sets for now if you want, but I'd rather build test images with the last version of isolinux in debug mode before making a decision on all this, anybody objects on building this kind of images and asking the people that wrote the bugs to test them so that we can get feedback on this? Regards... -- Manty/BestiaTester -> http://manty.net
Re: Usage of isolinux on the beta CDs
> Right, we'll want to add help screens to syslinux for all of our images > in any case. I think I understand now, isolinux uses its own help > screens which it reads from the CD, and these come from debian-cd (for > now..), but we can control the rest of them. That's it. > I don't particularly want to make the decision about which CD has > isolinux on it and which uses the old method. I do want to get the help > texts straightened out and preferably in one place, and I do want to Sounds reasonable, we can get the texts out of a package, for example, one thing that would be good is if we didn't need root for getting those texts, avoid things like loop mounting and so. > have a netinst CD without isolinux on it. Anything you guys decide that > accomplishes that is 100% fine with me, you are the ones who know all > about isolinux. Seems like isolinux has put some bugfixes to avoid problems with broken bioses and they work, at least my scsi bios can boot from sarge's cds but not from woody's first cd. We can build two netinst sets for now if you want, but I'd rather build test images with the last version of isolinux in debug mode before making a decision on all this, anybody objects on building this kind of images and asking the people that wrote the bugs to test them so that we can get feedback on this? Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
