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
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, 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, 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: > 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. -- 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/201007091611.07527.elen...@planet.nl
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, 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: [PATCH] Do not set VARIANTS in CONF.sh by default
On Fri, Jul 09, 2010 at 08:25:19AM +0100, Ian Campbell wrote: >Specifying VARIANTS in CONF.sh seems to stop command lines such as " >VARIANTS=blah ./build.sh" from working because it overrides the command >line supplied value. Commenting out the variable is consistent with how >other such variables are treated. > >I suspect the only reason VARIANTS=xen has been working in the daily >cronjobs is because the CONF.sh in debian-cd/setup SVN is out of date >WRT that in debian-cd/trunk SVN and so doesn't include the VARIANTS line >at all. > >--- a/CONF.sh >+++ b/CONF.sh >@@ -205,7 +205,7 @@ export DISKTYPE=CD > export TASK_LANGLIST=tasksel_d-i.languages > > # Extra variants to enable. See docs/README.variants for more information. >-export VARIANTS= >+#export VARIANTS= > > # We don't want certain packages to take up space on CD1... > #export EXCLUDE1=exclude Applied, thanks. -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you. -- 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/20100709115449.gf3...@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 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
Mike Genkin has invited you to Boxbe
Hi, Last chance! Just a reminder, Mike would like to share approved contacts with you on Boxbe. Use this link: https://www.boxbe.com/register?tc=3618425543_711415629 This message was sent at the request of genkstar...@yahoo.com. If you want to opt-out of invitations from Boxbe members, use this link: https://www.boxbe.com/unsubscribe?email=debian...@lists.debian.org&tc=3618425543_711415629 Boxbe, Inc. | 2390 Chestnut Street #201 | San Francisco, CA 94123
[PATCH] Do not set VARIANTS in CONF.sh by default
Specifying VARIANTS in CONF.sh seems to stop command lines such as " VARIANTS=blah ./build.sh" from working because it overrides the command line supplied value. Commenting out the variable is consistent with how other such variables are treated. I suspect the only reason VARIANTS=xen has been working in the daily cronjobs is because the CONF.sh in debian-cd/setup SVN is out of date WRT that in debian-cd/trunk SVN and so doesn't include the VARIANTS line at all. --- a/CONF.sh +++ b/CONF.sh @@ -205,7 +205,7 @@ export DISKTYPE=CD export TASK_LANGLIST=tasksel_d-i.languages # Extra variants to enable. See docs/README.variants for more information. -export VARIANTS= +#export VARIANTS= # We don't want certain packages to take up space on CD1... #export EXCLUDE1=exclude -- Ian Campbell Pray to God, but keep rowing to shore. -- Russian Proverb signature.asc Description: This is a digitally signed message part
