Re: Multi-arch netinst getting too big
On Thu, 2010-07-29 at 10:39 +0100, Steve McIntyre wrote: On Wed, Jul 28, 2010 at 08:52:25AM +0100, Ian Campbell wrote: I just checked debian-testing-amd64-i386-powerpc-netinst.iso vs firmware-testing-amd64-i386-powerpc-netinst.iso from http://cdimage.debian.org/cdimage/daily-builds/squeeze_d-i/current/multi-arch/iso-cd/ and they have all the same files on them modulo the additional firmware -- did you already fix the problem? or has time been the best cure? The squeeze image fits for now, but the sid image is the one that doesn't. A size comparison of yesterdays squeeze vs sid images didn't suggest any packages which have suddenly grown or anything. * event-modules-*-di added ~6k per kernel flavour * btrfs-modules-*-di added ~200k per kernel flavour * partman-btrfs udeb added ~9k per arch * dhcp3-client-udeb added ~160k per arch Overall it looks like + ~0.8M for each arch for quite reasonable reasons. The firmware image is currently 648M so it's pretty close to the limit. The sid equivalent would be ~650.5 MB. I can raise the maximum size of the image, but I'm reluctant to do that unless there's no other option. Other than drastic measures like dropping an arch or increasing the image size I don't see anything. Even if I could I have a feeling it would just be putting off the inevitable by a few more weeks. Ian. -- Ian Campbell Current Noise: Ozzy Osbourne - Now You See It (Now You Don't) In 1962, you could buy a pair of SHARKSKIN SLACKS, with a Continental Belt, for $10.99!! -- 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/1280482856.24292.1906.ca...@zakaz.uk.xensource.com
Re: Multi-arch netinst getting too big
On Tue, 2010-07-27 at 11:12 +0100, Steve McIntyre wrote: On Mon, Jul 19, 2010 at 10:49:18AM +0100, Ian Campbell wrote: On Mon, 2010-07-19 at 10:43 +0100, Steve McIntyre wrote: On Wed, Jul 14, 2010 at 07:05:47AM +0100, Ian Campbell wrote: On Wed, 2010-07-14 at 00:32 +0100, Steve McIntyre wrote: On Sun, Jul 11, 2010 at 09:26:38AM +0100, Ian Campbell wrote: After struggling for a bit due to CONF.sh overwriting my settings (I've figured out about DEBIAN_CD_CONF_SOURCED now!) I managed to do a sid m-a netinst build without perl and deps on it and it looks as if everything necessary fits on CD1 now, without excluding the 486 kernel or anything like that. Disk usage is 643M here so pretty close to the edge still. Still not seeing that here yet, but of course it'll take time for the changes to hit testing. That's right, it's 5/10 days old at the moment, I was building a sid iso just to see if it helped. And it looks like things are fixed in testing now. \o/ Awesome, thanks for letting me know! And now things have broken again for the image including firmware. :-( :-( I just checked debian-testing-amd64-i386-powerpc-netinst.iso vs firmware-testing-amd64-i386-powerpc-netinst.iso from http://cdimage.debian.org/cdimage/daily-builds/squeeze_d-i/current/multi-arch/iso-cd/ and they have all the same files on them modulo the additional firmware -- did you already fix the problem? or has time been the best cure? The firmware image is only 5M larger than the non-firmware one so if firmware one breaks the regular one must be pretty close to the precipice too. Another option is to increase the size of the ISO a little, but we're already very close to the limit of what will fit on a 650 MB CD. I've suggested raising the CD size from 650 to 700 MB in the past and people didn't like it, but that was quite a while ago. I can't find any 650MB CD-R blanks available anywhere these days... Google shopping finds them if you explicitly ask for 74mins but if you are just looking for CD-R then it's 80mins across the board. The firmware image is currently 648M so it's pretty close to the limit. Ian. -- Ian Campbell Law of the Jungle: He who hesitates is lunch. signature.asc Description: This is a digitally signed message part
Re: Multi-arch netinst getting too big
On Mon, Jul 19, 2010 at 10:49:18AM +0100, Ian Campbell wrote: On Mon, 2010-07-19 at 10:43 +0100, Steve McIntyre wrote: On Wed, Jul 14, 2010 at 07:05:47AM +0100, Ian Campbell wrote: On Wed, 2010-07-14 at 00:32 +0100, Steve McIntyre wrote: On Sun, Jul 11, 2010 at 09:26:38AM +0100, Ian Campbell wrote: After struggling for a bit due to CONF.sh overwriting my settings (I've figured out about DEBIAN_CD_CONF_SOURCED now!) I managed to do a sid m-a netinst build without perl and deps on it and it looks as if everything necessary fits on CD1 now, without excluding the 486 kernel or anything like that. Disk usage is 643M here so pretty close to the edge still. Still not seeing that here yet, but of course it'll take time for the changes to hit testing. That's right, it's 5/10 days old at the moment, I was building a sid iso just to see if it helped. And it looks like things are fixed in testing now. \o/ Awesome, thanks for letting me know! And now things have broken again for the image including firmware. :-( Another option is to increase the size of the ISO a little, but we're already very close to the limit of what will fit on a 650 MB CD. I've suggested raising the CD size from 650 to 700 MB in the past and people didn't like it, but that was quite a while ago. I can't find any 650MB CD-R blanks available anywhere these days... -- 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/20100727101223.gc17...@einval.com
Re: Multi-arch netinst getting too big
On Wed, Jul 14, 2010 at 07:05:47AM +0100, Ian Campbell wrote: On Wed, 2010-07-14 at 00:32 +0100, Steve McIntyre wrote: On Sun, Jul 11, 2010 at 09:26:38AM +0100, Ian Campbell wrote: After struggling for a bit due to CONF.sh overwriting my settings (I've figured out about DEBIAN_CD_CONF_SOURCED now!) I managed to do a sid m-a netinst build without perl and deps on it and it looks as if everything necessary fits on CD1 now, without excluding the 486 kernel or anything like that. Disk usage is 643M here so pretty close to the edge still. Still not seeing that here yet, but of course it'll take time for the changes to hit testing. That's right, it's 5/10 days old at the moment, I was building a sid iso just to see if it helped. And it looks like things are fixed in testing now. \o/ -- 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/20100719094325.ga11...@einval.com
Re: Multi-arch netinst getting too big
On Mon, 2010-07-19 at 10:43 +0100, Steve McIntyre wrote: On Wed, Jul 14, 2010 at 07:05:47AM +0100, Ian Campbell wrote: On Wed, 2010-07-14 at 00:32 +0100, Steve McIntyre wrote: On Sun, Jul 11, 2010 at 09:26:38AM +0100, Ian Campbell wrote: After struggling for a bit due to CONF.sh overwriting my settings (I've figured out about DEBIAN_CD_CONF_SOURCED now!) I managed to do a sid m-a netinst build without perl and deps on it and it looks as if everything necessary fits on CD1 now, without excluding the 486 kernel or anything like that. Disk usage is 643M here so pretty close to the edge still. Still not seeing that here yet, but of course it'll take time for the changes to hit testing. That's right, it's 5/10 days old at the moment, I was building a sid iso just to see if it helped. And it looks like things are fixed in testing now. \o/ Awesome, thanks for letting me know! -- Ian Campbell Current Noise: Dinosaur Jr. - Start Choppin' Package sold by weight, not volume. -- 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/1279532958.5872.1291.ca...@zakaz.uk.xensource.com
Re: Multi-arch netinst getting too big
On Wed, 2010-07-14 at 00:32 +0100, Steve McIntyre wrote: On Sun, Jul 11, 2010 at 09:26:38AM +0100, Ian Campbell wrote: After struggling for a bit due to CONF.sh overwriting my settings (I've figured out about DEBIAN_CD_CONF_SOURCED now!) I managed to do a sid m-a netinst build without perl and deps on it and it looks as if everything necessary fits on CD1 now, without excluding the 486 kernel or anything like that. Disk usage is 643M here so pretty close to the edge still. Still not seeing that here yet, but of course it'll take time for the changes to hit testing. That's right, it's 5/10 days old at the moment, I was building a sid iso just to see if it helped. Ian. -- Ian Campbell I found out why my car was humming. It had forgotten the words. signature.asc Description: This is a digitally signed message part
Re: Multi-arch netinst getting too big
On Sun, Jul 11, 2010 at 09:26:38AM +0100, Ian Campbell wrote: On Fri, 2010-07-09 at 13:51 +0100, Ian Campbell wrote: On Fri, 2010-07-09 at 12:50 +0100, Steve McIntyre wrote: On Thu, Jul 08, 2010 at 03:35:23PM +0100, Ian Campbell wrote: 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. /me likes the perl team, they're very good. :-) It's even uploaded now! I'm just waiting for the ppc buildd to upload and it to propagate to mirrors and I'll try an ISO build against sid to make sure the perl package goes away. After struggling for a bit due to CONF.sh overwriting my settings (I've figured out about DEBIAN_CD_CONF_SOURCED now!) I managed to do a sid m-a netinst build without perl and deps on it and it looks as if everything necessary fits on CD1 now, without excluding the 486 kernel or anything like that. Disk usage is 643M here so pretty close to the edge still. Still not seeing that here yet, but of course it'll take time for the changes to hit testing. -- Steve McIntyre, Cambridge, UK.st...@einval.com liw everything I know about UK hotels I learned from Fawlty Towers -- 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/20100713233253.gs4...@einval.com
Re: Multi-arch netinst getting too big
On Fri, 2010-07-09 at 13:51 +0100, Ian Campbell wrote: On Fri, 2010-07-09 at 12:50 +0100, Steve McIntyre wrote: On Thu, Jul 08, 2010 at 03:35:23PM +0100, Ian Campbell wrote: 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. /me likes the perl team, they're very good. :-) It's even uploaded now! I'm just waiting for the ppc buildd to upload and it to propagate to mirrors and I'll try an ISO build against sid to make sure the perl package goes away. After struggling for a bit due to CONF.sh overwriting my settings (I've figured out about DEBIAN_CD_CONF_SOURCED now!) I managed to do a sid m-a netinst build without perl and deps on it and it looks as if everything necessary fits on CD1 now, without excluding the 486 kernel or anything like that. Disk usage is 643M here so pretty close to the edge still. Ian. -- Ian Campbell Yes, but every time I try to see things your way, I get a headache. signature.asc Description: This is a digitally signed message part
Re: Multi-arch netinst getting too big
On Wed, Jul 07, 2010 at 09:45:12PM -0700, Chris Reich wrote: This powerpc user would rather not see powerpc dropped from the netinstall disk but accepts that it may be the time to do it in the interests of the much larger number of x86 based hardware in the wild. Yup. There will still be a standalone powerpc netinst, but we may have to drop it from the multi-arch disk. I'm hoping to be able to find savings elsewhere, but it's tight. -- Steve McIntyre, Cambridge, UK.st...@einval.com Because heaters aren't purple! -- Catherine Pitt -- 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/20100709114929.gd3...@einval.com
Re: Multi-arch netinst getting too big
On Thu, Jul 08, 2010 at 03:35:23PM +0100, Ian Campbell wrote: 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. /me likes the perl team, they're very good. :-) 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 ;-) Ah, I see *grin*. I'm looking further now. -- Steve McIntyre, Cambridge, UK.st...@einval.com You can't barbecue lettuce! -- Ellie Crane -- 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/20100709115047.ge3...@einval.com
Re: Multi-arch netinst getting too big
On Fri, 2010-07-09 at 12:50 +0100, Steve McIntyre wrote: On Thu, Jul 08, 2010 at 03:35:23PM +0100, Ian Campbell wrote: 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. /me likes the perl team, they're very good. :-) It's even uploaded now! I'm just waiting for the ppc buildd to upload and it to propagate to mirrors and I'll try an ISO build against sid to make sure the perl package goes away. Ian. -- Ian Campbell Current Noise: Decapitated - Revelation Of Existence (The Trip) NOTICE: anyone seen smoking will be assumed to be on fire and will be summarily put out. -- 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/1278679883.28432.630.ca...@zakaz.uk.xensource.com
Re: Multi-arch netinst getting too big
What I've done for now is drop the -486 kernel flavour from the m-a netinst. From a test build I've just done, everything fits on a single CD again, even with firmware included. If people want to install from a netinst onto a pre-686 machine then they'll need to use the separate i386 netinst instead of the multi-arch version. How does that sound? -- Steve McIntyre, Cambridge, UK.st...@einval.com The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary. -- James D. Nicoll -- 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/20100709132813.gh3...@einval.com
Re: Multi-arch netinst getting too big
On Fri, Jul 09, 2010 at 04:11:06PM +0200, Frans Pop wrote: On Friday 09 July 2010, Steve McIntyre wrote: What I've done for now is drop the -486 kernel flavour from the m-a netinst. From a test build I've just done, everything fits on a single CD again, even with firmware included. If people want to install from a netinst onto a pre-686 machine then they'll need to use the separate i386 netinst instead of the multi-arch version. How does that sound? IMO it's a very bad idea to support a flavor in the installer itself and then fail to install a working kernel for it for the target system and thus create an unbootable system. True. Any better suggestions? -- Steve McIntyre, Cambridge, UK.st...@einval.com Since phone messaging became popular, the young generation has lost the ability to read or write anything that is longer than one hundred and sixty characters. -- Ignatios Souvatzis -- 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/20100709141404.gi3...@einval.com
Re: Multi-arch netinst getting too big
On Friday 09 July 2010, Steve McIntyre wrote: True. Any better suggestions? No. Not without doing substantial work on this, which I've already indicated I'm not going to do this release. -- 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/201007091624.50160.elen...@planet.nl
Re: Multi-arch netinst getting too big
On Fri, 2010-07-09 at 14:28 +0100, Steve McIntyre wrote: What I've done for now is drop the -486 kernel flavour from the m-a netinst. From a test build I've just done, everything fits on a single CD again, even with firmware included. If people want to install from a netinst onto a pre-686 machine then they'll need to use the separate i386 netinst instead of the multi-arch version. How does that sound? In light of Frans' concern perhaps consider dropping 686 instead of 486? I think that will result in 686-bigmem being installed on systems which would have previously got 686 (I can confirm if necessary). This isn't necessarily a bad thing -- it enables NX support for one thing which is generally desirable. FWIW RHEL 6 (the beta at least) ships with only a PAE (aka 686-bigmem) kernel, I guess things are heading that way generally. Ian. -- Ian Campbell I have five dollars for each of you. -- Bernhard Goetz -- 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/1278689669.28432.677.ca...@zakaz.uk.xensource.com
Re: Multi-arch netinst getting too big
On Friday 09 July 2010, Ian Campbell wrote: In light of Frans' concern perhaps consider dropping 686 instead of 486? I think that will result in 686-bigmem being installed on systems which would have previously got 686 (I can confirm if necessary). This isn't necessarily a bad thing -- it enables NX support for one thing which is generally desirable. Last I know is that -bigmem is significantly slower on a lot of hardware than the plain 686 kernel. Also, in most cases the 64-bit -amd64 flavor is a *lot* better choice for most i386 users that have systems that have large memory or want NX support. We've had this discussion before! Multiple times. FWIW RHEL 6 (the beta at least) ships with only a PAE (aka 686-bigmem) kernel, I guess things are heading that way generally. I don't really care that much what RH does TBH. And I don't believe it's true anyway: things are moving towards 64-bit, not 32-bit with NX. Isn't perl going to be dropping from the netinsts now and won't that be sufficient? -- 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/201007091807.16732.elen...@planet.nl
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 i...@hellion.org.uk 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 i...@hellion.org.uk 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
Re: Multi-arch netinst getting too big
On Tue, Jun 29, 2010 at 07:16:59AM +0100, Ian Campbell wrote:
On Mon, 2010-06-28 at 22:43 +0100, Steve McIntyre wrote:
I don't think sym-links are going to work - the filesystem code in
isolinux is very simple (e.g. it only supports basic 8.3 filenames!)
and I doubt it'll work. Hard links *might*, however.
OK, that's a one character change...
The files under install.{486,amd}/xen/ don't need to be readable by
isolinux, only by the xen tools. I've just had a quick look and they
appear to support hardlinks but not symlinks so that's another argument
for hardlinks. If we think isolinux would be a problem then we could
restrict this to files under install.*/xen/.
Ian.
---
Subject: boot-x86: detect duplicates in the extra images used for installation
Several files included under install.{386,amd} are actually identical to
others. Rather than duplicating them attempt to detect this and hardlink
them.
Since images can be downloaded from the web at build time it is not
always possible to detect identical files by looking for the symlinks
created by the debian-installer build. Instead we pass a list of
potential doppelgangers to extra_image each of which is checked for
similarity to the new image.
I added gtk/vmlinuz (which is always the same as plain vmlinuz) which
although not necessary makes it more explicit which kernel goes with the
initrd at very little cost.
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 i...@hellion.org.uk
diff --git a/tools/boot/squeeze/boot-x86 b/tools/boot/squeeze/boot-x86
Cool, applied now.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Every time you use Tcl, God kills a kitten. -- Malcolm Ray
--
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/20100707234952.gf4...@einval.com
Re: Multi-arch netinst getting too big
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. :-) 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? -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed? -- 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/20100708001610.gh4...@einval.com
Re: Multi-arch netinst getting too big
[ Added cc: to debian-powerpc for help... ] On Tue, Jun 29, 2010 at 08:44:15AM +0100, Ian Campbell wrote: On Mon, 2010-06-28 at 22:46 +0100, Steve McIntyre wrote: On Wed, Jun 23, 2010 at 03:45:31PM +0200, Goswin von Brederlow wrote: Steve McIntyre st...@einval.com writes: The netinsts are meant to have the base system, yes. I can't see anything obvious myself that we can drop. Maybe time to give up on powerpc on that image, like we've done on the m-a DVD. Shame, but there's only so much stuff we can accommodate here. Anybody else have an opinion here? Frans/Joey? Just a crcy idea: Could the plain i386 kernel be droped instead? That would loose support for i486 and i586 cpus on the m-a CD. But is that needed there? That's an option, yes. We could strip out the kernels for 686 systems here, but I'd like to keep them on if at all possible to make this image as universally useful as possible. I'd be more convinced to simply drop powerpc instead, like we already did for the multi-arch DVD. Sounds reasonable to me, but then I'm not a powerpc user... Does the CD image need powerpc, powerpc-smp and powerpc64 kernels? Perhaps one of powerpc and powerpc-smp could be dropped (presuming that the smp variant still works on a UP system dropping the UP could well be reasonable). No idea, to be honest. Powerpc folks - thoughts? 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). 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. I don't see doc-linux-text in the log either. (Looking at the log files make_disc_tree.log and sort_deps.i386.log for this info...) -- Steve McIntyre, Cambridge, UK.st...@einval.com Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast. Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html -- 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/20100708000935.gg4...@einval.com
Re: Multi-arch netinst getting too big
Steve McIntyre st...@einval.com writes: I don't think sym-links are going to work - the filesystem code in isolinux is very simple (e.g. it only supports basic 8.3 filenames!) and I doubt it'll work. Hard links *might*, however. Hi, Largely immaterial, just for the sake of correctness: ISOLINUX does support long (level 2) ISO 9660 plain filenames. Indeed no Rock Ridge or Joliet extensions, though, thus no symlinks, as you stated. -- Regards, Feri. -- 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/874ogd7x3r@tac.ki.iif.hu
Re: Multi-arch netinst getting too big
On Tue, Jul 06, 2010 at 11:55:52AM +0200, Ferenc Wagner wrote: Steve McIntyre st...@einval.com writes: I don't think sym-links are going to work - the filesystem code in isolinux is very simple (e.g. it only supports basic 8.3 filenames!) and I doubt it'll work. Hard links *might*, however. Largely immaterial, just for the sake of correctness: ISOLINUX does support long (level 2) ISO 9660 plain filenames. Indeed no Rock Ridge or Joliet extensions, though, thus no symlinks, as you stated. Ah, thanks for clearing that up. I guess we're just using filenames at level 1, plus RR extensions. -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back -- 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/20100706103014.gb9...@einval.com
Re: Multi-arch netinst getting too big
On Mon, 2010-06-28 at 22:43 +0100, Steve McIntyre wrote:
Is this list part of the output somewhere when I do a local build
either
with easy-build.sh or by replicating the invocation from
debian-cd-setup
SVN?
It's an excerpt from make_disc_tree.log, produced when
make_disc_trees.pl is laying out packages into the temporary trees. It
logs into the temporary directory where debian-cd is working.
Thanks.
Subject: boot-x86: detect duplicates in the extra images used for
installation
Several files included under install.{386,amd} are actually identical
to
others. Rather than duplicating them attempt to detect this and
symlink
them.
I don't think sym-links are going to work - the filesystem code in
isolinux is very simple (e.g. it only supports basic 8.3 filenames!)
and I doubt it'll work. Hard links *might*, however.
OK, that's a one character change...
The files under install.{486,amd}/xen/ don't need to be readable by
isolinux, only by the xen tools. I've just had a quick look and they
appear to support hardlinks but not symlinks so that's another argument
for hardlinks. If we think isolinux would be a problem then we could
restrict this to files under install.*/xen/.
Ian.
---
Subject: boot-x86: detect duplicates in the extra images used for installation
Several files included under install.{386,amd} are actually identical to
others. Rather than duplicating them attempt to detect this and hardlink
them.
Since images can be downloaded from the web at build time it is not
always possible to detect identical files by looking for the symlinks
created by the debian-installer build. Instead we pass a list of
potential doppelgangers to extra_image each of which is checked for
similarity to the new image.
I added gtk/vmlinuz (which is always the same as plain vmlinuz) which
although not necessary makes it more explicit which kernel goes with the
initrd at very little cost.
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 i...@hellion.org.uk
diff --git a/tools/boot/squeeze/boot-x86 b/tools/boot/squeeze/boot-x86
index c0a5bdc..2189cbf 100644
--- a/tools/boot/squeeze/boot-x86
+++ b/tools/boot/squeeze/boot-x86
@@ -133,6 +133,8 @@ fi
extra_image () {
image=$1
+ doppelgangers=$2
+
dir=$(dirname $image)
mkdir -p $CDDIR/$INSTALLDIR/$dir
@@ -146,6 +148,15 @@ extra_image () {
wget $DI_WWW_HOME/cdrom/$image -O
$CDDIR/$INSTALLDIR/$image
fi
fi
+
+ for doppelganger in $doppelgangers ; do
+ if [ -f $CDDIR/$INSTALLDIR/$dir/$doppelganger ]
+ cmp -s $CDDIR/$INSTALLDIR/$image
$CDDIR/$INSTALLDIR/$dir/$doppelganger ; then
+ echo $image identical to $doppelganger. Linking
+ ln -nf $doppelganger $CDDIR/$INSTALLDIR/$image
+ break
+ fi
+ done
}
# If multiple desktops are to be supported, set the default one
@@ -231,7 +242,8 @@ if [ $THISTYPE = isolinux ]; then
fi
if [ -e boot$N/isolinux/f3.txt.withgtk ]; then
- extra_image gtk/initrd.gz
+ extra_image gtk/vmlinuz ../vmlinuz
+ extra_image gtk/initrd.gz ../initrd.gz
mv boot$N/isolinux/f3.txt.withgtk boot$N/isolinux/f3.txt
mv boot$N/isolinux/f4.txt.withgtk boot$N/isolinux/f4.txt
if [ -e boot$N/isolinux/isolinux.cfg.withgtk ]; then
@@ -243,8 +255,8 @@ if [ $THISTYPE = isolinux ]; then
rm -f boot$N/isolinux/isolinux.cfg.with*
if variant_enabled xen ; then
- extra_image xen/vmlinuz
- extra_image xen/initrd.gz
+ extra_image xen/vmlinuz ../vmlinuz ../gtk/vmlinuz
+ extra_image xen/initrd.gz ../initrd.gz ../gtk/initrd.gz
extra_image xen/xm-debian.cfg
fi
--
--
Ian Campbell
Generic Fortune.
signature.asc
Description: This is a digitally signed message part
Re: Multi-arch netinst getting too big
On Mon, 2010-06-28 at 22:46 +0100, Steve McIntyre wrote: On Wed, Jun 23, 2010 at 03:45:31PM +0200, Goswin von Brederlow wrote: Steve McIntyre st...@einval.com writes: The netinsts are meant to have the base system, yes. I can't see anything obvious myself that we can drop. Maybe time to give up on powerpc on that image, like we've done on the m-a DVD. Shame, but there's only so much stuff we can accommodate here. Anybody else have an opinion here? Frans/Joey? Just a crcy idea: Could the plain i386 kernel be droped instead? That would loose support for i486 and i586 cpus on the m-a CD. But is that needed there? That's an option, yes. We could strip out the kernels for 686 systems here, but I'd like to keep them on if at all possible to make this image as universally useful as possible. I'd be more convinced to simply drop powerpc instead, like we already did for the multi-arch DVD. Sounds reasonable to me, but then I'm not a powerpc user... Does the CD image need powerpc, powerpc-smp and powerpc64 kernels? Perhaps one of powerpc and powerpc-smp could be dropped (presuming that the smp variant still works on a UP system dropping the UP could well be reasonable). 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/*) I have a feeling I'm misunderstanding the technical definition of base system. I thought it was Priority: important or higher but perl, python and binutils are all Priority: standard. Ian. -- Ian Campbell Your happiness is intertwined with your outlook on life. signature.asc Description: This is a digitally signed message part
Re: Multi-arch netinst getting too big
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? Ian. -- -- Ian Campbell Pull the trigger and you're garbage. -- Lady Blue signature.asc Description: This is a digitally signed message part
Re: Multi-arch netinst getting too big
Ian Campbell i...@hellion.org.uk writes: On Sat, 2010-06-26 at 21:49 +0200, Ferenc Wagner wrote: Ian Campbell i...@hellion.org.uk writes: On Sat, 2010-06-26 at 21:12 +0200, Ferenc Wagner wrote: Ian Campbell i...@hellion.org.uk writes: Another option might be to combine gtk/initrd.gz and xen/initrd.gz so that the overhead is only the kernel udebs and not duplicating all the other stuff. I probably mentioned this already, but you aren't constrained to a single initrd.gz: you can use several ones separated by commas. Where can I use several? In a Xen domain config file or in some bootloader config or something? Is it actually supported of does it just happen to work by some coincidence? Unfortunately not in a Xen domain config, AFAIK. But isolinux supports it, as per syslinux.txt: It supports multiple filenames separated by commas. This is mostly useful for initramfs, which can be composed of multiple separate cpio or cpio.gz archives. OK, Thanks. It's actually an overlay, so it may be possible to work around the Xen limitation by making the Xen initrd the base one and overwriting its arch dependent parts as needed. Although it probably could be made to work I'm not that keen on making the regular case more complicated/strange (even if supported by the bootloader) in order to support Xen and I suspect nobody else is either. I'd prefer to drop GTK from the Xen images. By all means go ahead. The multi-initrd feature would be most useful for reusing the normal initrds (mostly kernel modules) in the graphical installer I guess. But then again that may not be worth it. -- Regards, Feri. -- 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/87k4pjh8wv@tac.ki.iif.hu
Re: Multi-arch netinst getting too big
On Tue, 2010-06-15 at 14:30 +0100, Steve McIntyre wrote:
The following packages are falling off onto a second disk now:
i386:main:linux-image-2.6.32-5-686-bigmem:27213342
i386:main:linux-image-2.6-686-bigmem:3036
i386:main:linux-headers-2.6.32-5-686-bigmem:516338
i386:main:linux-headers-2.6-686-bigmem:2930
Is this list part of the output somewhere when I do a local build either
with easy-build.sh or by replicating the invocation from debian-cd-setup
SVN?
On Fri, 2010-06-25 at 21:51 +0100, Ian Campbell wrote:
One thing to note is that the amd64 xen images should by symlinks to
the regular vmlinuz+gtk/initrd.gz images (since no special kernel is
needed on 64 bit, the intention was to symlink just for consistency in
the path to the kernel for convenience) so there is an immediate 18.3M
saving to be made which I will look into.
This was inconvenienced a little because the images can be fetched from
the web and hence the symlinks aren't directly detectable, but here is
what I arrived at. However even with this a bunch of stuff gets punted
to CD2, in my case it is:
/pool/main/l/linux-2.6/linux-headers-2.6.32-5-686_2.6.32-15_i386.deb
/pool/main/l/linux-2.6/linux-headers-2.6.32-5-686-bigmem_2.6.32-15_i386.deb
/pool/main/l/linux-2.6/linux-image-2.6.32-5-686_2.6.32-15_i386.deb
/pool/main/l/linux-2.6/linux-image-2.6.32-5-686-bigmem_2.6.32-15_i386.deb
/pool/main/l/linux-latest-2.6/linux-headers-2.6-686_2.6.32+27_i386.deb
/pool/main/l/linux-latest-2.6/linux-headers-2.6-686-bigmem_2.6.32+27_i386.deb
/pool/main/l/linux-latest-2.6/linux-image-2.6-686_2.6.32+27_i386.deb
/pool/main/l/linux-latest-2.6/linux-image-2.6-686-bigmem_2.6.32+27_i386.deb
which is less than ideal.
This is with the Xen initrd pared down to the non-GTK version too -- I'm
not sure what else can be done to fit stuff on CD1 now...
Ian.
---
Subject: boot-x86: detect duplicates in the extra images used for installation
Several files included under install.{386,amd} are actually identical to
others. Rather than duplicating them attempt to detect this and symlink
them.
Since images can be downloaded from the web at build time it is not
always possible to detect identical files by looking for the symlinks
created by the debian-installer build. Instead we pass a list of
potential doppelgangers to extra_image each of which is checked for
similarity to the new image.
I added gtk/vmlinuz (which is always the same as plain vmlinuz) which
although not necessary makes it more explicit which kernel goes with the
initrd at very little cost.
(it's not clear if hardlinks or symlinks should be preferred. I chose
symlinks largely arbitrarily but I don't know if this has implications
for compatibility with other, non-symlink supporting, OSes which may
wish to read the CD)
Signed-off-by: Ian Campbell i...@hellion.org.uk
diff --git a/tools/boot/squeeze/boot-x86 b/tools/boot/squeeze/boot-x86
index c0a5bdc..ef8aa5e 100644
--- a/tools/boot/squeeze/boot-x86
+++ b/tools/boot/squeeze/boot-x86
@@ -133,6 +133,8 @@ fi
extra_image () {
image=$1
+ doppelgangers=$2
+
dir=$(dirname $image)
mkdir -p $CDDIR/$INSTALLDIR/$dir
@@ -146,6 +148,15 @@ extra_image () {
wget $DI_WWW_HOME/cdrom/$image -O
$CDDIR/$INSTALLDIR/$image
fi
fi
+
+ for doppelganger in $doppelgangers ; do
+ if [ -f $CDDIR/$INSTALLDIR/$dir/$doppelganger ]
+ cmp -s $CDDIR/$INSTALLDIR/$image
$CDDIR/$INSTALLDIR/$dir/$doppelganger ; then
+ echo $image identical to $doppelganger. Linking
+ ln -nsf $doppelganger $CDDIR/$INSTALLDIR/$image
+ break
+ fi
+ done
}
# If multiple desktops are to be supported, set the default one
@@ -231,7 +242,8 @@ if [ $THISTYPE = isolinux ]; then
fi
if [ -e boot$N/isolinux/f3.txt.withgtk ]; then
- extra_image gtk/initrd.gz
+ extra_image gtk/vmlinuz ../vmlinuz
+ extra_image gtk/initrd.gz ../initrd.gz
mv boot$N/isolinux/f3.txt.withgtk boot$N/isolinux/f3.txt
mv boot$N/isolinux/f4.txt.withgtk boot$N/isolinux/f4.txt
if [ -e boot$N/isolinux/isolinux.cfg.withgtk ]; then
@@ -243,8 +255,8 @@ if [ $THISTYPE = isolinux ]; then
rm -f boot$N/isolinux/isolinux.cfg.with*
if variant_enabled xen ; then
- extra_image xen/vmlinuz
- extra_image xen/initrd.gz
+ extra_image xen/vmlinuz ../vmlinuz ../gtk/vmlinuz
+ extra_image xen/initrd.gz ../initrd.gz ../gtk/initrd.gz
extra_image xen/xm-debian.cfg
fi
--
--
Ian Campbell
A mushroom cloud has no silver lining.
signature.asc
Description: This is a digitally signed message part
Re: Multi-arch netinst getting too big
On Sun, Jun 27, 2010 at 07:39:17AM +0100, Ian Campbell wrote: On Sat, 2010-06-26 at 21:49 +0200, Ferenc Wagner wrote: It's actually an overlay, so it may be possible to work around the Xen limitation by making the Xen initrd the base one and overwriting its arch dependent parts as needed. Although it probably could be made to work I'm not that keen on making the regular case more complicated/strange (even if supported by the bootloader) in order to support Xen and I suspect nobody else is either. I'd prefer to drop GTK from the Xen images. OK, that's something we can do quite easily. -- 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/20100628213546.ge4...@einval.com
Re: Multi-arch netinst getting too big
On Mon, Jun 28, 2010 at 07:38:18PM +0100, Ian Campbell wrote:
On Tue, 2010-06-15 at 14:30 +0100, Steve McIntyre wrote:
The following packages are falling off onto a second disk now:
i386:main:linux-image-2.6.32-5-686-bigmem:27213342
i386:main:linux-image-2.6-686-bigmem:3036
i386:main:linux-headers-2.6.32-5-686-bigmem:516338
i386:main:linux-headers-2.6-686-bigmem:2930
Is this list part of the output somewhere when I do a local build either
with easy-build.sh or by replicating the invocation from debian-cd-setup
SVN?
It's an excerpt from make_disc_tree.log, produced when
make_disc_trees.pl is laying out packages into the temporary trees. It
logs into the temporary directory where debian-cd is working.
On Fri, 2010-06-25 at 21:51 +0100, Ian Campbell wrote:
One thing to note is that the amd64 xen images should by symlinks to
the regular vmlinuz+gtk/initrd.gz images (since no special kernel is
needed on 64 bit, the intention was to symlink just for consistency in
the path to the kernel for convenience) so there is an immediate 18.3M
saving to be made which I will look into.
This was inconvenienced a little because the images can be fetched from
the web and hence the symlinks aren't directly detectable, but here is
what I arrived at. However even with this a bunch of stuff gets punted
to CD2, in my case it is:
/pool/main/l/linux-2.6/linux-headers-2.6.32-5-686_2.6.32-15_i386.deb
/pool/main/l/linux-2.6/linux-headers-2.6.32-5-686-bigmem_2.6.32-15_i386.deb
/pool/main/l/linux-2.6/linux-image-2.6.32-5-686_2.6.32-15_i386.deb
/pool/main/l/linux-2.6/linux-image-2.6.32-5-686-bigmem_2.6.32-15_i386.deb
/pool/main/l/linux-latest-2.6/linux-headers-2.6-686_2.6.32+27_i386.deb
/pool/main/l/linux-latest-2.6/linux-headers-2.6-686-bigmem_2.6.32+27_i386.deb
/pool/main/l/linux-latest-2.6/linux-image-2.6-686_2.6.32+27_i386.deb
/pool/main/l/linux-latest-2.6/linux-image-2.6-686-bigmem_2.6.32+27_i386.deb
which is less than ideal.
This is with the Xen initrd pared down to the non-GTK version too -- I'm
not sure what else can be done to fit stuff on CD1 now...
Hmmm, OK.
Subject: boot-x86: detect duplicates in the extra images used for installation
Several files included under install.{386,amd} are actually identical to
others. Rather than duplicating them attempt to detect this and symlink
them.
I don't think sym-links are going to work - the filesystem code in
isolinux is very simple (e.g. it only supports basic 8.3 filenames!)
and I doubt it'll work. Hard links *might*, however.
Since images can be downloaded from the web at build time it is not
always possible to detect identical files by looking for the symlinks
created by the debian-installer build. Instead we pass a list of
potential doppelgangers to extra_image each of which is checked for
similarity to the new image.
I added gtk/vmlinuz (which is always the same as plain vmlinuz) which
although not necessary makes it more explicit which kernel goes with the
initrd at very little cost.
(it's not clear if hardlinks or symlinks should be preferred. I chose
symlinks largely arbitrarily but I don't know if this has implications
for compatibility with other, non-symlink supporting, OSes which may
wish to read the CD)
:-)
--
Steve McIntyre, Cambridge, UK.st...@einval.com
When C++ is your hammer, everything looks like a thumb. -- Steven M. Haflich
--
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/20100628214357.gf4...@einval.com
Re: Multi-arch netinst getting too big
On Wed, Jun 23, 2010 at 03:45:31PM +0200, Goswin von Brederlow wrote: Steve McIntyre st...@einval.com writes: The netinsts are meant to have the base system, yes. I can't see anything obvious myself that we can drop. Maybe time to give up on powerpc on that image, like we've done on the m-a DVD. Shame, but there's only so much stuff we can accommodate here. Anybody else have an opinion here? Frans/Joey? Just a crcy idea: Could the plain i386 kernel be droped instead? That would loose support for i486 and i586 cpus on the m-a CD. But is that needed there? That's an option, yes. We could strip out the kernels for 686 systems here, but I'd like to keep them on if at all possible to make this image as universally useful as possible. I'd be more convinced to simply drop powerpc instead, like we already did for the multi-arch DVD. -- Steve McIntyre, Cambridge, UK.st...@einval.com The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary. -- James D. Nicoll -- 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/20100628214613.gg4...@einval.com
Re: Multi-arch netinst getting too big
On Sat, 2010-06-26 at 21:49 +0200, Ferenc Wagner wrote: Ian Campbell i...@hellion.org.uk writes: On Sat, 2010-06-26 at 21:12 +0200, Ferenc Wagner wrote: Ian Campbell i...@hellion.org.uk writes: Another option might be to combine gtk/initrd.gz and xen/initrd.gz so that the overhead is only the kernel udebs and not duplicating all the other stuff. I probably mentioned this already, but you aren't constrained to a single initrd.gz: you can use several ones separated by commas. Where can I use several? In a Xen domain config file or in some bootloader config or something? Is it actually supported of does it just happen to work by some coincidence? Unfortunately not in a Xen domain config, AFAIK. But isolinux supports it, as per syslinux.txt: It supports multiple filenames separated by commas. This is mostly useful for initramfs, which can be composed of multiple separate cpio or cpio.gz archives. OK, Thanks. It's actually an overlay, so it may be possible to work around the Xen limitation by making the Xen initrd the base one and overwriting its arch dependent parts as needed. Although it probably could be made to work I'm not that keen on making the regular case more complicated/strange (even if supported by the bootloader) in order to support Xen and I suspect nobody else is either. I'd prefer to drop GTK from the Xen images. Ian. -- -- Ian Campbell BOFH excuse #169: broadcast packets on wrong frequency signature.asc Description: This is a digitally signed message part
Re: Multi-arch netinst getting too big
On Sat, 2010-06-26 at 21:12 +0200, Ferenc Wagner wrote: Ian Campbell i...@hellion.org.uk writes: Another option might be to combine gtk/initrd.gz and xen/initrd.gz so that the overhead is only the kernel udebs and not duplicating all the other stuff. I probably mentioned this already, but you aren't constrained to a single initrd.gz: you can use several ones separated by commas. Where can I use several? In a Xen domain config file or in some bootloader config or something? Is it actually supported of does it just happen to work by some coincidence? Ian. On the other hand I've got no idea how much of the initrd contents is arch independent. And I surely wouldn't miss the graphical part of the Xen installer. -- -- Ian Campbell All other things being equal, a bald man cannot be elected President of the United States. -- Vic Gold signature.asc Description: This is a digitally signed message part
Re: Multi-arch netinst getting too big
Ian Campbell i...@hellion.org.uk writes: Another option might be to combine gtk/initrd.gz and xen/initrd.gz so that the overhead is only the kernel udebs and not duplicating all the other stuff. I probably mentioned this already, but you aren't constrained to a single initrd.gz: you can use several ones separated by commas. On the other hand I've got no idea how much of the initrd contents is arch independent. And I surely wouldn't miss the graphical part of the Xen installer. -- Regards, Feri. -- 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/87vd95d2vi@tac.ki.iif.hu
Re: Multi-arch netinst getting too big
Ian Campbell i...@hellion.org.uk writes: On Sat, 2010-06-26 at 21:12 +0200, Ferenc Wagner wrote: Ian Campbell i...@hellion.org.uk writes: Another option might be to combine gtk/initrd.gz and xen/initrd.gz so that the overhead is only the kernel udebs and not duplicating all the other stuff. I probably mentioned this already, but you aren't constrained to a single initrd.gz: you can use several ones separated by commas. Where can I use several? In a Xen domain config file or in some bootloader config or something? Is it actually supported of does it just happen to work by some coincidence? Unfortunately not in a Xen domain config, AFAIK. But isolinux supports it, as per syslinux.txt: It supports multiple filenames separated by commas. This is mostly useful for initramfs, which can be composed of multiple separate cpio or cpio.gz archives. It's actually an overlay, so it may be possible to work around the Xen limitation by making the Xen initrd the base one and overwriting its arch dependent parts as needed. Hopefully this can be done without wasting much memory, maybe by adding empty files/directories to the overlay initrd. But I don't know a thing about the powerpc bootloader. If that does not support this, the possible gains are somewhat lower. -- Regards, Feri. -- 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/87ocexd15l@tac.ki.iif.hu
Re: Multi-arch netinst getting too big
On Wed, 2010-06-16 at 20:06 +0200, Frans Pop wrote: On Wednesday 16 June 2010, Steve McIntyre wrote: I'm afraid I don't have any good ideas. Is this particular image supposed to contain a complete base system or just enough to fetch the remainder of the base system from the net? The netinsts are meant to have the base system, yes. I can't see anything obvious myself that we can drop. Maybe time to give up on powerpc on that image, like we've done on the m-a DVD. Shame, but there's only so much stuff we can accommodate here. Anybody else have an opinion here? Frans/Joey? The i386 netinst has also grown substantially. The base system probably needs cleaning as part of the final preparations for Squeeze. I suspect ATM 2 versions of Python get installed for example, Doesn't look like there is any python on the multiarch netinst ISO and I can't see any other instances of the general problem. and probably some (old) libs have a too high priority. If that is determined to be the case then what is the response? Is it to file bugs against ftp-master or the individual packages? Someone will have to do a detailed comparison between Lenny and Squeeze images to see where the changes are and whether some cleanup is possible. Possibly some udebs and/or packages can be excluded. The Lenny multi arch netinst amd64+i3486+powerpc was 472M which left around 178M spare so I wonder where that space has gone. I wrote some scripts to analyse what has changed from the package lists. They are attached, although I don't pretend anything in there is the best way to achieve the aim. compare-sizes.sh fetches the necessary indexes and compare-sizes.py ARCH will tabulate the packages in the Lenny list vs those in the daily image with sizes (in bytes, kilobytes then megabytes). Piping to sort -k 4 -g orders by size increase. Overall the i386 packages seem to have increased by 69M, amd64 by 28M and powerpc by 30M for an total increase of 128M (suggesting that ~50M of increase is from non-packaged content) Looking at i386 the clear biggest addition is the 686-bigmem kernels (31M in total include udebs etc) but that was expected, excluding those brings the i386 increase to only 38M which is more in line with the other architectures, but still 10M large for some reason. Each of the existing kernel flavours seems to have gained 4-7M on every arch for a total of 42M extra (not including the 686-bigmem kernel on i386) for i in i386 amd64 powerpc ; do ./compare-sizes.py $i | grep linux-image-KABI; done | sort -k 4 -g linux-image-KABI-powerpc 2.6.26-21/23112884 2.6.32-15/28179348 5066464 49474 linux-image-KABI-powerpc-smp 2.6.26-21/23509576 2.6.32-15/28634896 5125320 50054 linux-image-KABI-powerpc642.6.26-21/23369286 2.6.32-15/29785936 6416650 62666 linux-image-KABI-486 2.6.26-21/20181780 2.6.32-15/26949060 6767280 66086 linux-image-KABI-686 2.6.26-21/20216832 2.6.32-15/27077640 6860808 67006 linux-image-KABI-amd642.6.26-21/20874922 2.6.32-15/28155342 7280420 71096 linux-image-KABI-amd642.6.26-21/20893606 2.6.32-15/28257430 7363824 71917 linux-image-KABI-686-bigmem - 2.6.32-15/27213342 2721334226575 25 Something seems to be pulling in perl now (not just perl-base like in Lenny). Perl is ~4M on each architecture + ~3M of arch:all perl-modules. In addition it appears to pull in libdb4.7 whereas everything else needs libdb4.8 leading to two versions of this library for each arch (not that it is especially large). I can't see anything which depends on perl on the ISO and the perl package is Priority: standard according to the Packages file so I'm not sure how it gets included. There is an additional gtk udeb (libgtk2.0-0-udeb). I'm not sure if this is expected, I'd have thought it might be part of the initrd? That's about it for the 1M gains. Doesn't look to be much to be shaved off to me, except perhaps perl and it's dependencies. I'll take a look at the non-package content of the DVD next since there seems to ~50M accounted there. Is there any indication of by how much we are currently overflowing? Is it simply the total of: i386:main:linux-image-2.6.32-5-686-bigmem:27213342 i386:main:linux-image-2.6-686-bigmem:3036 i386:main:linux-headers-2.6.32-5-686-bigmem:516338 i386:main:linux-headers-2.6-686-bigmem:2930 or does pushing a package to the second disk pull along the dependencies too?
Re: Multi-arch netinst getting too big
On Wed, 2010-06-23 at 15:45 +0200, Goswin von Brederlow wrote: Just a crcy idea: Could the plain i386 kernel be droped instead? That would loose support for i486 and i586 cpus on the m-a CD. But is that needed there? I guess it is a possibility, I suppose new installs on i486 and i586 class machines are likely to be a dying breed and there are other images which contain that kernel for those occasions. (although I guess the same rationale could be applied to having i386 at all when amd64 is on the image too ;-) ) Does anyone else have an opinion? Ian. -- Ian Campbell Current Noise: Reverend Bizarre - The March Of The War Elephants New Year's Eve is the time of year when a man most feels his age, and his wife most often reminds him to act it. -- Webster's Unafraid Dictionary -- 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/1277475563.25867.118.ca...@zakaz.uk.xensource.com
Re: Multi-arch netinst getting too big
On Fri, 2010-06-25 at 15:17 +0100, Ian Campbell wrote: The Lenny multi arch netinst amd64+i3486+powerpc was 472M which left around 178M spare so I wonder where that space has gone. [...] I'll take a look at the non-package content of the DVD next since there seems to ~50M accounted there. So the sid daily build of multi arch netinst amd64+i3486+powerpc is 614M (remember that linux-image-686-bigmem has been bumped) Looking at the space used at the top level: * /pool has gone 385M-494M (+109M, seems in line with analysis in previous mail). * /dists has gone 1.4M-1.5M * /docs has gone 1.5M-1.4M * /install has gone 35M-39M (+4M) * /install.386 has gone 18M-38M (+20M) * /install.amd has gone 19M-40M (+21M) * A few K here and there for /README.*, /syslink, /firmware etc So it looks like other than /pool the big change is to /install*. powerpc64 vmlinux,initrd.gz:8.4M+4.3M=12.7M - 11M+4.1M=15.1M (+2.4M) powerpc64 vmlinuz-chrp.initrd: 6.5M- 6.9M (+0.4M) powerpc vmlinux,initrd.gz:5.2M+4.3M=9.5M - 6.7M+4.0M=10.7M (+1.2M) powerpc vmlinuz-chrp.initrd: 6.1M- 6.3M (+0.2M) 386 vmlinuz,initrd.gz:1.5M+4.3M=5.8M - 2.1M+3.9M=6M (+0.2M) 386 gtk initrd.gz:12M - 15M (+3M) 386 xen vmlinuz,initrd.gz:0M - 2.3M+15M=17.3M (+17.3) amd vmlinuz,initrd.gz:1.7M+4.4M=6.1M - 2.3M+4.0M=6.3M (+0.2M) amd gtk initrd.gz:13M - 16M (+3M) amd xen vmlinuz,initrd.gz:0 - 2.3M+16M=18.3M (+18.3M) So the minor culprits seems to be a smallish increase in the powerpc vmlinux's and (as Frans predicted) an increase in the gtk initrd.gz's However the major culprit certainly seems to be the xen initrd.gz's. One thing to note is that the amd64 xen images should by symlinks to the regular vmlinuz+gtk/initrd.gz images (since no special kernel is needed on 64 bit, the intention was to symlink just for consistency in the path to the kernel for convenience) so there is an immediate 18.3M saving to be made which I will look into. The other obvious thing to consider here would be to switch to a non-GTK initrd for i386/xen which I estimate would save ~10M. It's not clear how useful graphical install is under Xen anyway due to its more server-ish focus. Another option might be to combine gtk/initrd.gz and xen/initrd.gz so that the overhead is only the kernel udebs and not duplicating all the other stuff. This seems likely to be enough to squish everything back onto one CD but doesn't seem like it will buy much headroom after that. It's not that clear to me where there are other savings to be made though. Are both powerpc and powerpc64 used these days? (I honestly have no idea) Ian. -- Ian Campbell You know, of course, that the Tasmanians, who never committed adultery, are now extinct. -- M. Somerset Maugham signature.asc Description: This is a digitally signed message part
Re: Multi-arch netinst getting too big
Steve McIntyre st...@einval.com writes: On Tue, Jun 15, 2010 at 03:06:14PM +0100, Ian Campbell wrote: On Tue, 2010-06-15 at 14:30 +0100, Steve McIntyre wrote: For the last few builds, the i386/amd64/powerpc sid netinst image has become too big to fit on one CD any more. The following packages are falling off onto a second disk now: i386:main:linux-image-2.6.32-5-686-bigmem:27213342 i386:main:linux-image-2.6-686-bigmem:3036 i386:main:linux-headers-2.6.32-5-686-bigmem:516338 i386:main:linux-headers-2.6-686-bigmem:2930 The linux-image ones were added to support installation into a Xen PV domain and were added to this image precisely because it was one of the few images which was considered to have room -- it would be a shame to have to drop them. Hmmm, OK. http://cdimage.debian.org/cdimage/daily-builds/sid_d-i/20100615-5/multi-arch/list-cd/debian-testing-amd64-i386-powerpc-netinst.list.gz in case anybody wants to take a look and suggest things... I'm afraid I don't have any good ideas. Is this particular image supposed to contain a complete base system or just enough to fetch the remainder of the base system from the net? The netinsts are meant to have the base system, yes. I can't see anything obvious myself that we can drop. Maybe time to give up on powerpc on that image, like we've done on the m-a DVD. Shame, but there's only so much stuff we can accommodate here. Anybody else have an opinion here? Frans/Joey? Just a crcy idea: Could the plain i386 kernel be droped instead? That would loose support for i486 and i586 cpus on the m-a CD. But is that needed there? MfG Goswin -- 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/87zkyldfr8@frosties.localdomain
Re: Multi-arch netinst getting too big
On Tue, Jun 15, 2010 at 03:06:14PM +0100, Ian Campbell wrote: On Tue, 2010-06-15 at 14:30 +0100, Steve McIntyre wrote: For the last few builds, the i386/amd64/powerpc sid netinst image has become too big to fit on one CD any more. The following packages are falling off onto a second disk now: i386:main:linux-image-2.6.32-5-686-bigmem:27213342 i386:main:linux-image-2.6-686-bigmem:3036 i386:main:linux-headers-2.6.32-5-686-bigmem:516338 i386:main:linux-headers-2.6-686-bigmem:2930 The linux-image ones were added to support installation into a Xen PV domain and were added to this image precisely because it was one of the few images which was considered to have room -- it would be a shame to have to drop them. Hmmm, OK. http://cdimage.debian.org/cdimage/daily-builds/sid_d-i/20100615-5/multi-arch/list-cd/debian-testing-amd64-i386-powerpc-netinst.list.gz in case anybody wants to take a look and suggest things... I'm afraid I don't have any good ideas. Is this particular image supposed to contain a complete base system or just enough to fetch the remainder of the base system from the net? The netinsts are meant to have the base system, yes. I can't see anything obvious myself that we can drop. Maybe time to give up on powerpc on that image, like we've done on the m-a DVD. Shame, but there's only so much stuff we can accommodate here. Anybody else have an opinion here? Frans/Joey? -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied twisted, Just an earth-bound misfit, I... -- 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/20100616131436.gg30...@einval.com
Re: Multi-arch netinst getting too big
On Wednesday 16 June 2010, Steve McIntyre wrote: I'm afraid I don't have any good ideas. Is this particular image supposed to contain a complete base system or just enough to fetch the remainder of the base system from the net? The netinsts are meant to have the base system, yes. I can't see anything obvious myself that we can drop. Maybe time to give up on powerpc on that image, like we've done on the m-a DVD. Shame, but there's only so much stuff we can accommodate here. Anybody else have an opinion here? Frans/Joey? The i386 netinst has also grown substantially. The base system probably needs cleaning as part of the final preparations for Squeeze. I suspect ATM 2 versions of Python get installed for example, and probably some (old) libs have a too high priority. But partly it's normal growth: the G-I initrds are still larger than for Lenny due to the switch to X.Org. The kernel packages are undoubtedly bigger again and the addition of firmware packages will not have helped either. Someone will have to do a detailed comparison between Lenny and Squeeze images to see where the changes are and whether some cleanup is possible. Possibly some udebs and/or packages can be excluded. All inclusion/exclusion lists should be reviewed in general. Beside the netinsts, all first CD and DVD images will need careful review of contents as well: are desktops installable using first images only (at least for i386 and amd64)? One option may be to drop PDF and text versions of the manual. But space will have to be reserved for the Release Notes. I will not be doing any work on any of this myself this release. Cheers, FJP -- 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/201006162006.24570.elen...@planet.nl
Re: Multi-arch netinst getting too big
On Tue, 2010-06-15 at 14:30 +0100, Steve McIntyre wrote: For the last few builds, the i386/amd64/powerpc sid netinst image has become too big to fit on one CD any more. The following packages are falling off onto a second disk now: i386:main:linux-image-2.6.32-5-686-bigmem:27213342 i386:main:linux-image-2.6-686-bigmem:3036 i386:main:linux-headers-2.6.32-5-686-bigmem:516338 i386:main:linux-headers-2.6-686-bigmem:2930 The linux-image ones were added to support installation into a Xen PV domain and were added to this image precisely because it was one of the few images which was considered to have room -- it would be a shame to have to drop them. http://cdimage.debian.org/cdimage/daily-builds/sid_d-i/20100615-5/multi-arch/list-cd/debian-testing-amd64-i386-powerpc-netinst.list.gz in case anybody wants to take a look and suggest things... I'm afraid I don't have any good ideas. Is this particular image supposed to contain a complete base system or just enough to fetch the remainder of the base system from the net? Ian. -- Ian Campbell Current Noise: Disfear - The Horns * SynrG notes that the number of configuration questions to answer in sendmail is NON-TRIVIAL -- Seen on #Debian -- 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/1276610774.19091.9821.ca...@zakaz.uk.xensource.com
