Re: Multi-arch netinst getting too big
On Thu, 2010-07-08 at 01:16 +0100, Steve McIntyre wrote: > On Tue, Jun 29, 2010 at 08:49:36AM +0100, Ian Campbell wrote: > >On Mon, 2010-06-28 at 22:46 +0100, Steve McIntyre wrote: > >> the multi-arch DVD. > > > >Another random thought, would we be better off enabling the xen variant > >on the m-a DVD rather than CD? > > Adding this stuff onto the DVD sounds like a plan, whether we remove > it from the netinst or not. I hadn't noticed it wasn't there yet, in > fact. :-) I think this is sufficient to enable it: diff --git a/cronjob.weekly b/cronjob.weekly index 127cfad..16980d0 100755 --- a/cronjob.weekly +++ b/cronjob.weekly @@ -228,6 +228,7 @@ if lockfile -r0 $TOPDIR/.debian-cd.lock ; then INSTALLER_CD=6 TASK=Debian-all \ KERNEL_PARAMS='desktop=all' \ MAXCDS=1 MAXISOS=ALL MAXJIGDOS=ALL \ +VARIANTS=xen \ ./testingcds "i386 amd64 source" # We don't do multi in parallel, only one build type # to do! > But I don't know what xen folks are typically going to be > looking for - something small like the netinst, or something more > complete like the DVD? When I initially implemented support for d-i under Xen I had hoped that fully network based install (i.e. not ISO) would be sufficient. This actually works quite nicely under Xen since you don't need PXE and stuff TFTP etc, you just wget the kernel and initrd in domain 0 and boot with them. However there were people (possibly just a vocal minority) who wanted to install from ISO, possibly because the Xen hosts were firewalled or something. I always considered that for these use cases any ISO which could boot and do the basic install thing, with the usual option to add other ISO images or use a network mirror to get further packages would be sufficient. From that point of view smaller images would be better but since you only need to download once for each set of hosts I don't think a DVD sized image would be a particular issue and is certainly better than nothing. Ian. -- Ian Campbell Current Noise: Pendulum - Slam Look before you leap. -- Samuel Butler -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1278577039.28432.357.ca...@zakaz.uk.xensource.com
Re: Multi-arch netinst getting too big
(dropped powerpc for this subthread) On Thu, 2010-07-08 at 01:09 +0100, Steve McIntyre wrote: > > >Do you have any idea where perl (not perl-base) comes from? python > > (not python-minimal) doesn't seem to be in the base system but is on > > the CD as well. Similarly nothing seems to pull in binutils or > > doc-linux-text deliberately. (I'm picking on these packages because > > they are the largest components under pool/main/*) > > Hmmm. At the very least, debconf needs perl-base. linux-base then > pulls in the main perl package later (via libapt-pkg-perl). I think you mean via libuuid-perl? Looking at adding libuuid-perl to satisfy dep libuuid-perl Dep: ( OR perl-base ) libuuid-perl Dep: perl libuuid-perl Dep: libc6 libuuid-perl Dep: libuuid1 linux-base Dep: ( OR debconf cdebconf cdebconf-udeb debconf ) linux-base Dep: ( OR util-linux udev ) linux-image-2.6.32-5-486 Dep: ( OR initramfs-tools dracut initramfs-tools ) linux-image-2.6.32-5-486 Dep: ( OR debconf cdebconf cdebconf-udeb debconf ) Looking at adding libapt-pkg-perl to satisfy dep libapt-pkg-perl Dep: perl-base libapt-pkg-perl Dep: ( OR perl-base ) libapt-pkg-perl Dep: ( OR apt ) libapt-pkg-perl Dep: libc6 libapt-pkg-perl Dep: libgcc1 libapt-pkg-perl Dep: libstdc++6 I don't think libuuid-perl really needs perl and I have filed #588427 to that effect. > As for > python, I'm not seeing that on the current m-a netinst CD. We then > have linux-headers-$foo -> gcc-4.3 -> binutils. Ah, I didn't think to check transitive dependencies. I was wondering why linux-headers were on the CD in the first place and find that tools/generate_di+k_list says: /* Note that we do not have to include every optimised kernel flavor for * i386, but this does control what kernels are available on the netinst CD. * Kernel headers are included as third party modules are commonly * used on this architecture. */ so it's only for amd64 and i386 but it is on all ISO images. Could we consider making this only for certain image types? It would save 10M. > I don't see doc-linux-text in the log either. There was a popcon update in debian-cd SVN recently -- does that effect this sort of thing? All I see in my logs are + Trying to add doc-linux-text... @dep before checklist = doc-linux-text @dep after checklist = doc-linux-text $output_size = 49686668, $size = 7814144 Also my mirror was only updated at the end of June so I guess something there may have changed? It 7.5M but I guess maybe this was selected from popcon to fill the slack left by things which were bumped? > (Looking at the log files make_disc_tree.log and sort_deps.i386.log > for this info...) Thanks for the pointer. Ian. -- Ian Campbell Current Noise: Pendulum - Plastic World (feat. Fats & TC) Man is the only animal that can remain on friendly terms with the victims he intends to eat until he eats them. -- Samuel Butler (1835-1902) -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1278579638.28432.409.ca...@zakaz.uk.xensource.com
Re: Multi-arch netinst getting too big
On Thu, 2010-07-08 at 12:45 +0100, Steve McIntyre wrote: > On Thu, Jul 08, 2010 at 12:49:52AM +0100, Steve McIntyre wrote: > >On Tue, Jun 29, 2010 at 07:16:59AM +0100, Ian Campbell wrote: > >> > >>Hardlinks are used in preference to symlinks since these are expected to > >>work better with isolinux and the Xen tools. > >> > >>Signed-off-by: Ian Campbell > >> > >>diff --git a/tools/boot/squeeze/boot-x86 b/tools/boot/squeeze/boot-x86 > > > >Cool, applied now. > > And now fixed slightly so it works. :-) Oops, sorry. Looks like I made the naive change from symlinks to hardlinks without properly testing. Ian. -- Ian Campbell Current Noise: Dinosaur Jr. - Blowing It Cleanliness becomes more important when godliness is unlikely. -- P. J. O'Rourke -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1278591299.28432.583.ca...@zakaz.uk.xensource.com
Re: Multi-arch netinst getting too big
On Thu, 2010-07-08 at 15:23 +0100, Steve McIntyre wrote: > On Thu, Jul 08, 2010 at 10:00:38AM +0100, Ian Campbell wrote: > >I don't think libuuid-perl really needs perl and I have filed #588427 to > >that effect. > > Cool. It's tagged as pending already in the perl team's VCS, very fast turnaround. > >I was wondering why linux-headers were on the CD in the first place and > >find that tools/generate_di+k_list says: > >/* Note that we do not have to include every optimised kernel flavor > > for > > * i386, but this does control what kernels are available on the > > netinst CD. > > * Kernel headers are included as third party modules are commonly > > * used on this architecture. > > */ > >so it's only for amd64 and i386 but it is on all ISO images. Could we > >consider making this only for certain image types? It would save 10M. > > Yes we could, but I don't see it as such an issue elsewhere. It's the > m-a netinst CD I'm really trying to cut down as a priority. By "only for certain image types" I guess I really meant "not for the m-a netinst CD" ;-) Ian. -- Ian Campbell Current Noise: Karma to Burn - Five When you dig another out of trouble, you've got a place to bury your own. -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1278599723.28432.591.ca...@zakaz.uk.xensource.com
Re: Multi-arch netinst getting too big
On Thu, Jul 08, 2010 at 12:49:52AM +0100, Steve McIntyre wrote: >On Tue, Jun 29, 2010 at 07:16:59AM +0100, Ian Campbell wrote: >> >>Hardlinks are used in preference to symlinks since these are expected to >>work better with isolinux and the Xen tools. >> >>Signed-off-by: Ian Campbell >> >>diff --git a/tools/boot/squeeze/boot-x86 b/tools/boot/squeeze/boot-x86 > >Cool, applied now. And now fixed slightly so it works. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100708114511.gb6...@einval.com
Re: Multi-arch netinst getting too big
On Thu, Jul 08, 2010 at 09:17:19AM +0100, Ian Campbell wrote: >On Thu, 2010-07-08 at 01:16 +0100, Steve McIntyre wrote: >> On Tue, Jun 29, 2010 at 08:49:36AM +0100, Ian Campbell wrote: >> >On Mon, 2010-06-28 at 22:46 +0100, Steve McIntyre wrote: >> >> the multi-arch DVD. >> > >> >Another random thought, would we be better off enabling the xen variant >> >on the m-a DVD rather than CD? >> >> Adding this stuff onto the DVD sounds like a plan, whether we remove >> it from the netinst or not. I hadn't noticed it wasn't there yet, in >> fact. :-) > >I think this is sufficient to enable it: > >diff --git a/cronjob.weekly b/cronjob.weekly >index 127cfad..16980d0 100755 >--- a/cronjob.weekly >+++ b/cronjob.weekly >@@ -228,6 +228,7 @@ if lockfile -r0 $TOPDIR/.debian-cd.lock ; then > INSTALLER_CD=6 TASK=Debian-all \ > KERNEL_PARAMS='desktop=all' \ > MAXCDS=1 MAXISOS=ALL MAXJIGDOS=ALL \ >+VARIANTS=xen \ > ./testingcds "i386 amd64 source" > # We don't do multi in parallel, only one build type > # to do! Yup, I've just turned that on now. >> But I don't know what xen folks are typically going to be >> looking for - something small like the netinst, or something more >> complete like the DVD? > >When I initially implemented support for d-i under Xen I had hoped that >fully network based install (i.e. not ISO) would be sufficient. This >actually works quite nicely under Xen since you don't need PXE and stuff >TFTP etc, you just wget the kernel and initrd in domain 0 and boot with >them. Cool. >However there were people (possibly just a vocal minority) who wanted to >install from ISO, possibly because the Xen hosts were firewalled or >something. > >I always considered that for these use cases any ISO which could boot >and do the basic install thing, with the usual option to add other ISO >images or use a network mirror to get further packages would be >sufficient. From that point of view smaller images would be better but >since you only need to download once for each set of hosts I don't think >a DVD sized image would be a particular issue and is certainly better >than nothing. Right. Well, let's see if we can get both the CD and the DVD working for you. I can understand people wanting the smaller image too if we can manage it... -- Steve McIntyre, Cambridge, UK.st...@einval.com "It's actually quite entertaining to watch ag129 prop his foot up on the desk so he can get a better aim." [ seen in ucam.chat ] -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100708142614.gh6...@einval.com
Re: Multi-arch netinst getting too big
On Thu, Jul 08, 2010 at 10:00:38AM +0100, Ian Campbell wrote: >(dropped powerpc for this subthread) > >On Thu, 2010-07-08 at 01:09 +0100, Steve McIntyre wrote: >> >> >Do you have any idea where perl (not perl-base) comes from? python >> > (not python-minimal) doesn't seem to be in the base system but is on >> > the CD as well. Similarly nothing seems to pull in binutils or >> > doc-linux-text deliberately. (I'm picking on these packages because >> > they are the largest components under pool/main/*) >> >> Hmmm. At the very least, debconf needs perl-base. linux-base then >> pulls in the main perl package later (via libapt-pkg-perl). > >I think you mean via libuuid-perl? Ah, yes. > Looking at adding libuuid-perl to satisfy dep >libuuid-perl Dep: ( OR perl-base ) >libuuid-perl Dep: perl >libuuid-perl Dep: libc6 >libuuid-perl Dep: libuuid1 >linux-base Dep: ( OR debconf cdebconf cdebconf-udeb debconf ) >linux-base Dep: ( OR util-linux udev ) >linux-image-2.6.32-5-486 Dep: ( OR initramfs-tools dracut initramfs-tools ) >linux-image-2.6.32-5-486 Dep: ( OR debconf cdebconf cdebconf-udeb debconf ) > Looking at adding libapt-pkg-perl to satisfy dep >libapt-pkg-perl Dep: perl-base >libapt-pkg-perl Dep: ( OR perl-base ) >libapt-pkg-perl Dep: ( OR apt ) >libapt-pkg-perl Dep: libc6 >libapt-pkg-perl Dep: libgcc1 >libapt-pkg-perl Dep: libstdc++6 > >I don't think libuuid-perl really needs perl and I have filed #588427 to >that effect. Cool. >> As for >> python, I'm not seeing that on the current m-a netinst CD. We then >> have linux-headers-$foo -> gcc-4.3 -> binutils. > >Ah, I didn't think to check transitive dependencies. > >I was wondering why linux-headers were on the CD in the first place and >find that tools/generate_di+k_list says: >/* Note that we do not have to include every optimised kernel flavor > for > * i386, but this does control what kernels are available on the > netinst CD. > * Kernel headers are included as third party modules are commonly > * used on this architecture. > */ >so it's only for amd64 and i386 but it is on all ISO images. Could we >consider making this only for certain image types? It would save 10M. Yes we could, but I don't see it as such an issue elsewhere. It's the m-a netinst CD I'm really trying to cut down as a priority. >> I don't see doc-linux-text in the log either. > >There was a popcon update in debian-cd SVN recently -- does that effect >this sort of thing? It shouldn't affect netinsts, no - the popcon numbers only affect ordering of packages that come after the tasks. >All I see in my logs are >+ Trying to add doc-linux-text... > @dep before checklist = doc-linux-text > @dep after checklist = doc-linux-text > $output_size = 49686668, $size = 7814144 > >Also my mirror was only updated at the end of June so I guess something >there may have changed? Could be, or task changes. -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100708142353.gg6...@einval.com
