Re: Preparing for 6.3 Release
I wrote: BTW, I have no 64-bit PC. This is no longer true. Now I have a system with Intel BLKDG965SSCK motherboard, Intel Core 2 Duo E6420 CPU, and 2 GB or RAM. My first task is to fix the LiveCD so that it works well on this computer (this means updating the kernel). -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Jeremy Huntwork wrote: As far as a native x86_64 build is concerned, I think that would be a good candidate for 7.0. Agreed. Personally, I'd like to see multilib support (since there is only a 32-bit zsnes, and I do use the Flash plugin from time to time in FF also (but note: not enough to get rid of the flashblock extension, of course)). However, I have a feeling that multilib would be harder to support than pure64. And the LiveCD could be useful for that end, as well, since these days it comes with the option to boot a 64-bit kernel. While that is true, and the LiveCD works great to run 64-bit stuff inside a chroot, the CD does not come with a 64-bit userspace. (So you can't run 64-bit binaries outside a chroot.) To build a pure64 system, you'd therefore have to cross-compile, and I'm not sure we want to do that in the book (since it's what CLFS is for). OTOH, adding an entire 64-bit userspace to the livecd probably won't work either. Possibly the only solution would be a separate 64-bit livecd, but that's a bunch more work for the maintainers (and may not even be possible for them to build, I don't know). :-( -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGm1FRS5vET1Wea5wRA6udAJ9RkE5IxHBTQP5Ffpp1Y4G/eYZBawCfS8+Z lgeOMCa2YzrNj85xZA7xLV4= =idhQ -END PGP SIGNATURE- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
Jeremy Huntwork wrote: Hmmm... Looking at the livecd repo, I'm seeing that Alexander has included a 64-bit gcc and binutils. So a step in that direction has already been taken. They are cross-tools, and are installed in /tools (and thus, they don't appear on the real CD). Also, gcc is just bare bones good enough only for the kernel. Maybe patching gcc in Chapter 6 like Debian does (so that gcc is 32-bit by default, but produces 64-bit code with -m64) is a better solution - but I have not tried to build this. BTW, I have no 64-bit PC. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
On 7/14/07, Randy McMurchy [EMAIL PROTECTED] wrote: Dan Nicholson wrote these words on 07/14/07 12:52 CST: It's their stable branch which contains many backported bug fixes and they're not producing any more releases. Is it better to use a known buggy glibc-2.5? If glibc-2.5.1 was imminent, I'd say wait, but recent history would suggest it's not likely. I'm just mentioning it, doesn't really matter to me. However I'm curious about something else. These branch update patches are huge, these are all bug fixes? There's no enhancements in these patches? I'm asking because I don't know the answer, but it would be nice to know. As far as I know, yes. But I'd be implying a lot more knowledge of glibc internals than I have if I tried to claim that. You can see all the changes here: http://sourceware.org/cgi-bin/cvsweb.cgi/libc/ChangeLog?cvsroot=glibconly_with_tag=glibc-2_5-branch This is also what would become glibc-2.5.1 if it's released. http://linuxfromscratch.org/pipermail/lfs-dev/2007-July/059606.html http://www.sourceware.org/ml/libc-alpha/2007-07/msg00045.html -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
Dan Nicholson wrote: I think most of the issues brought up in this thread have been addressed. I'd like to see if glibc-2.5.1 will happen, but we can certainly just use the latest branch_update patch. The LiveCD is still kind of up in the air, but I think most of the big concerns have been addressed, and now Jeremy is back on the prowl helping out. Too many things to respond to in this thread... Since I'm mentioned here, seems a good place to reply. Being a little out of the loop these days, I'm not really in much of a position to speak about what things need to be done to get 6.3 ready. Still, it's my opinion that we should get a release out sooner rather than later. I'll help out wherever there's a need... As far as a native x86_64 build is concerned, I think that would be a good candidate for 7.0. It really shouldn't be that big of a deal to make generic commands that work for both native builds - there would be a handful of commands specific to whichever platform you're building, but most would be the same. And the LiveCD could be useful for that end, as well, since these days it comes with the option to boot a 64-bit kernel. Just making some noise and pitching in my half a cent or so. ;) -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
On 6/8/07, Dan Nicholson [EMAIL PROTECTED] wrote: So, I think it's about time we start pushing out a 6.3 release. What do you guys think? Here are the outstanding issues I can think of. Matthew, ping? Any thoughts on this? I think most of the issues brought up in this thread have been addressed. I'd like to see if glibc-2.5.1 will happen, but we can certainly just use the latest branch_update patch. The LiveCD is still kind of up in the air, but I think most of the big concerns have been addressed, and now Jeremy is back on the prowl helping out. Would it help to have someone else handle the release? I'm pretty tied up until August, but could probably play a bigger role then. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
Dan Nicholson wrote these words on 07/14/07 10:34 CST: I think most of the issues brought up in this thread have been addressed. I'd like to see if glibc-2.5.1 will happen, but we can certainly just use the latest branch_update patch. Just out of curiosity, why are we continually updating the Glibc patch? After this branch_update 3 patch, Glibc probably isn't even close to a stable release any more. Doesn't this sort of go against a long-standing policy? -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 12:08:01 up 2 days, 5:15, 1 user, load average: 0.68, 0.23, 0.07 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
Dan Nicholson wrote these words on 07/14/07 12:52 CST: It's their stable branch which contains many backported bug fixes and they're not producing any more releases. Is it better to use a known buggy glibc-2.5? If glibc-2.5.1 was imminent, I'd say wait, but recent history would suggest it's not likely. I'm just mentioning it, doesn't really matter to me. However I'm curious about something else. These branch update patches are huge, these are all bug fixes? There's no enhancements in these patches? I'm asking because I don't know the answer, but it would be nice to know. -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 13:13:00 up 2 days, 6:20, 1 user, load average: 0.02, 0.03, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
Dan Nicholson wrote: So, what are the major bugs? 1) Unclear status of wireless network support. The CD doesn't contain wpa-supplicant and doesn't have firmware for most wireless network cards (even though we qualify as ISV and thus can redistribute ipw firmware). However, I can't test this because I don't have a wireless card. 2) Incorrect contents of /etc/issue with the toram boot option. The sources are intentionally not copied to RAM (so that one can use toram on a 512M box), but the message still says they are available in /lfs-sources. Since it is easy to add generation of the no-sources ISO, we may want to cover this case, too. 3) Undocumented initramfs boot options. Maybe we should document things like noapic pci=noacpi, too. 4) It is necessary to add back the reiser4 and loop-aes kernel patches once the kernel version in LFS stabilizes. 5) I have updated the packages blindly too frequently. Many of them are simply untested. Someone should go through _all_ of them and attempt to make sure that the basic functionality is there. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
I wrote: 1) Unclear status of wireless network support. The CD doesn't contain wpa-supplicant and doesn't have firmware for most wireless network cards (even though we qualify as ISV and thus can redistribute ipw firmware). However, I can't test this because I don't have a wireless card. 2) Incorrect contents of /etc/issue with the toram boot option. The sources are intentionally not copied to RAM (so that one can use toram on a 512M box), but the message still says they are available in /lfs-sources. Since it is easy to add generation of the no-sources ISO, we may want to cover this case, too. 3) Undocumented initramfs boot options. Maybe we should document things like noapic pci=noacpi, too. 4) It is necessary to add back the reiser4 and loop-aes kernel patches once the kernel version in LFS stabilizes. 5) I have updated the packages blindly too frequently. Many of them are simply untested. Someone should go through _all_ of them and attempt to make sure that the basic functionality is there. 6) In Japanese locales, fontconfig chooses the wrong default font (AR PL New Sung, while it should use Kochi fonts) -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
I want to just say out front what my opinion of the LiveCD is before I respond to individual points. The most important task of the livecd is to provide a host with a known working kernel and toolchain to allow people to build *LFS. Next, it should provide tools that allow the *LFS support channels to be reached. Everything else is a bonus and should not determine whether a livecd release is made. IMO. On 6/11/07, Alexander E. Patrakov [EMAIL PROTECTED] wrote: I wrote: 1) Unclear status of wireless network support. The CD doesn't contain wpa-supplicant and doesn't have firmware for most wireless network cards (even though we qualify as ISV and thus can redistribute ipw firmware). However, I can't test this because I don't have a wireless card. I'd say don't bother. We don't even have a working wireless setup in BLFS. I don't think it's asking people too much to plug in an ethernet cable if they want to use the livecd. This would be a great feature, but it shouldn't stop a release from being made. 2) Incorrect contents of /etc/issue with the toram boot option. The sources are intentionally not copied to RAM (so that one can use toram on a 512M box), but the message still says they are available in /lfs-sources. Since it is easy to add generation of the no-sources ISO, we may want to cover this case, too. If you're using the toram option, you must remount the CD to use the package tarballs in /lfs-sources. I don't know if that's all that's correct. I didn't investigate when I was using toram yesterday. 3) Undocumented initramfs boot options. Maybe we should document things like noapic pci=noacpi, too. That'd be nice. Is it possible to add more documentation pages to isolinux? We could add options2.msg and add F2 options2.msg to isolinux.cfg, right? 4) It is necessary to add back the reiser4 and loop-aes kernel patches once the kernel version in LFS stabilizes. I suppose. I don't consider that high priority at all. If you're depending on functionality that's not in the mainline kernel, then it's a huge bonus if anyone supports you out of the box. 5) I have updated the packages blindly too frequently. Many of them are simply untested. Someone should go through _all_ of them and attempt to make sure that the basic functionality is there. Well, LFS-6.3 will put a test to that. It's not a problem if bugs are found and a -2 release needs to be made. It seemed to work fine for me, although I didn't do too much. Like I said above, the main two tasks for me are the toolchain and the support tools. I hope the toolchain is fine or LFS is in trouble, too. I played with seamonkey and pidgin briefly. My network was setup fine out of the box, and I was able to jump right onto the internet and irc. So, from my end, it was working fine. The only package I saw that I thought was borderline was xf86-video-intel-2.0.0. You and I both read the xorg mailing list and know that it's not stable yet. If you're curious, the G965 is supported just fine in xf86-video-i180-1.7.4. I've been using it for months. It doesn't have all the fancy functionality of intel-2.0.0 (but neither does the livecd since it's using libXrandr-1.1.2), but it's working fine. What was the reason for updating to 2.0.0? 6) In Japanese locales, fontconfig chooses the wrong default font (AR PL New Sung, while it should use Kochi fonts) Is there any way to change this in fonts.conf? It looks like you're adding configuration for firefly, but not for kochi. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
Dan Nicholson wrote: If you're using the toram option, you must remount the CD to use the package tarballs in /lfs-sources. I don't know if that's all that's correct. I didn't investigate when I was using toram yesterday. Now we have an additional variable: the -nosrc CD, which doesn't contain sources, but must contain the same /etc/issue file, because root.ext2 is the same. If we don't find a wording that covers all three cases, I will have to generate /etc/issue during boot. Anyway, the /lfs-sources symlink should be removed during boot if it is dangling, so a script (or part of initramfs /init) is needed anyway. 3) Undocumented initramfs boot options. Maybe we should document things like noapic pci=noacpi, too. That'd be nice. Is it possible to add more documentation pages to isolinux? We could add options2.msg and add F2 options2.msg to isolinux.cfg, right? Yes. The only package I saw that I thought was borderline was xf86-video-intel-2.0.0. You and I both read the xorg mailing list and know that it's not stable yet. If you're curious, the G965 is supported just fine in xf86-video-i180-1.7.4. I've been using it for months. It doesn't have all the fancy functionality of intel-2.0.0 (but neither does the livecd since it's using libXrandr-1.1.2), but it's working fine. What was the reason for updating to 2.0.0? Ability to set modes that the monitor prefers (e.g., native resolution on LCD monitors). According to forums, 915resolution is not too reliable (e.g., Xorg and the monitor disagree upon the synchronization frequencies). However, now I am not sure whether xf86-video-intel-2.0.0 is really better. Anyway, it supports more hardware (new: i965GM, found in laptops). 6) In Japanese locales, fontconfig chooses the wrong default font (AR PL New Sung, while it should use Kochi fonts) Is there any way to change this in fonts.conf? It looks like you're adding configuration for firefly, but not for kochi. Ignore this. It was a panic from my side after seeing non-antialiased fonts, not a real bug. Kochi fonts are known to fontconfig out of the box, but AR PL New Sung isn't. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
On 6/11/07, Alexander E. Patrakov [EMAIL PROTECTED] wrote:
Dan Nicholson wrote:
If you're using the toram option, you must remount the CD to use the
package tarballs in /lfs-sources.
I don't know if that's all that's correct. I didn't investigate when I
was using toram yesterday.
Now we have an additional variable: the -nosrc CD, which doesn't contain
sources, but must contain the same /etc/issue file, because root.ext2 is the
same. If we don't find a wording that covers all three cases, I will have to
generate /etc/issue during boot. Anyway, the /lfs-sources symlink should be
removed during boot if it is dangling, so a script (or part of initramfs
/init) is needed anyway.
I think that generated would be the best since I can't think of any
words that aren't convoluted. What about something like this in
intramfs/init.in (wording to be improved, of course):
toram=0
[EMAIL PROTECTED]@ # This would be 0 or 1 as substituted by the Makefile
...
case ${toram}${nosrc} in
00) cat /.root/etc/issue EOF # or however you would access it
from the initramfs
Find the sources in /lfs-sources
EOF
;;
*1) ;; # No sources, so don't bother saying anything?
10) cat /.root/etc/issue EOF
Since you are using the toram option, you must remount the CD to
find the sources for the LFS packages.
EOF
;;
esac
3) Undocumented initramfs boot options. Maybe we should document things
like
noapic pci=noacpi, too.
That'd be nice. Is it possible to add more documentation pages to
isolinux? We could add options2.msg and add F2 options2.msg to
isolinux.cfg, right?
Yes.
I don't know all the options, but I'll play with this a bit.
The only package I saw that I thought was borderline was
xf86-video-intel-2.0.0. You and I both read the xorg mailing list and
know that it's not stable yet. If you're curious, the G965 is
supported just fine in xf86-video-i180-1.7.4. I've been using it for
months. It doesn't have all the fancy functionality of intel-2.0.0
(but neither does the livecd since it's using libXrandr-1.1.2), but
it's working fine. What was the reason for updating to 2.0.0?
Ability to set modes that the monitor prefers (e.g., native resolution on
LCD monitors). According to forums, 915resolution is not too reliable (e.g.,
Xorg and the monitor disagree upon the synchronization frequencies).
However, now I am not sure whether xf86-video-intel-2.0.0 is really better.
Anyway, it supports more hardware (new: i965GM, found in laptops).
I forgot about the 915resolution package. Things have always just
worked for me. Well, until it breaks something, I say keep it in. I
don't think anyone's going to try any xrandr'ing from a livecd,
anyway.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
On 6/8/07, Alexander E. Patrakov [EMAIL PROTECTED] wrote: Dan Nicholson wrote: Anything else? LiveCD. I simply have no possibility to fix all known bugs, so LFS 6.3 has to be released without the CD and should not mention it at all. OK. I think this should be top priority because we need to figure out a long term solution anyway. I've subscribed to the livecd list. I tried out that snapshot you told me about, r1930. It worked fine on my Lenovo x60 laptop. I haven't tried my G965 system yet, but will today. Looks very nice, Alexander. I tried linux pata. It worked 3/4 times with pata_piix. The one time it failed was just a race to get the device up. You may want to check out the initramfs setup that Fedora is using with David Zeuthen's livecd-tools. The root setup seems to be fairly robust. There's some Fedora specific stuff in there, but the main init script is pretty nice. I haven't checked out your changes for the livecd initramfs setup yet. http://gitweb.freedesktop.org/?p=users/david/livecd-tools.git;a=blob;hb=HEAD;f=creator/mayflower So, what are the major bugs? We can take the conversation to the livecd list if you'd prefer. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
Alexander E. Patrakov wrote: Dan Nicholson wrote: Anything else? LiveCD. I simply have no possibility to fix all known bugs, so LFS 6.3 has to be released without the CD and should not mention it at all. My own issue with the livecd on the inspiron is actually the hardware, not your efforts. The only reliable version is a set of install discs from around the time the inspiron was new hardware, everything else just fails. [ *buntu, slak, gentoo, *noppix, debian, even RH 5 through 9 fail. ] So that is my own issue not a livecd issue. both my other systems I haven't hit any bugs on, with the patch for the sis 900 chipset r1904 disc. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
El Viernes, 8 de Junio de 2007 23:23, Dan Nicholson escribió: So, I think it's about time we start pushing out a 6.3 release. What do you guys think? IMHO, just update to the packages listed now on Trac (except, of course, the toolchain ones), and do package freezing to release 6.3 very soon. Toolchain update, bootloader(s) update, and the other remaining open bugs may meant to start working on 7.x LFS series. * Docbook XML/XSL changes: Manuel, how's that coming along? I haven't really been paying attention to this lately. The DocBook-XSL-1.72.1 release timeframe is a unknow variable. I asked some days ago to Bob Stayton about that without answers for now. Due that 1.72.0 was the first testing release including native support for DB-XML-5.0-rcX, I suposse that he might be waiting the final DB-XML-5.0 release to release the acompaning XSL stable release. If that DB-XSL release is not done at time for LFS-6.3, we must release the book with the current stylesheets or, if really wanted to use the new code, to port the full nex-xml branch, included the docbook-xsl-snapshot files (or even create our own LFS-XSL tarball). -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
Alexander E. Patrakov wrote: LiveCD. I simply have no possibility to fix all known bugs, so LFS 6.3 has to be released without the CD and should not mention it at all. I would see nothing wrong with using a LiveCD with is running an older version of LFS, but simply has the latest 6.3 sources from which to build the real LFS box. While it's nice for the two to be in the same ballpark, there's nothing that says the LiveCD needs to be running 6.3, just that it should be sufficient to build 6.3. Steve -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Preparing for 6.3 Release
So, I think it's about time we start pushing out a 6.3 release. What do you guys think? Here are the outstanding issues I can think of. * Linux-2.6.21: Yesterday I read this blog post from the Fedora kernel maintainer, Dave Jones: http://kernelslacker.livejournal.com/79957.html Doesn't exactly make 2.6.21 sound like the appealing kernel to base our stable release on. I'm not the expert here, but it may be better to wait for 2.6.22. Food for thought, anyway. * Docbook XML/XSL changes: Manuel, how's that coming along? I haven't really been paying attention to this lately. * Udev rules: Alexander has posted in a couple other places that we have broken rules for DVB and floppy device setup. Alexander/Bryan, could you guys look at our ruleset and make sure they do everything we want them to? * Bootscripts: There are a couple changes that I'd like to get in. Nothing critical. I'll have a separate post on that. Anything else? -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Dan Nicholson wrote: * Udev rules: Alexander has posted in a couple other places that we have broken rules for DVB and floppy device setup. Alexander/Bryan, could you guys look at our ruleset and make sure they do everything we want them to? Well, I just yanked the applicable SuSE rules, modified them a bit to fit our group names, and stuffed them into 25-lfs.rules. See r8152. Alexander, I'm assuming that should work better? (We may need to change those rules if we update udev though. -112 is out now.) * Bootscripts: There are a couple changes that I'd like to get in. Nothing critical. I'll have a separate post on that. If that includes your post from here: http://linuxfromscratch.org/pipermail/lfs-dev/2007-April/059308.html on modifying the console logging level, I'm all for it. Or that part of it, at least. :-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGaedXS5vET1Wea5wRA8pEAKCSv96iPRcn3bS/2Mxh0EUDGMfODACghb+l PCODF637QGpLJb8T1N5emaI= =cBp+ -END PGP SIGNATURE- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
Dan Nicholson wrote: Anything else? LiveCD. I simply have no possibility to fix all known bugs, so LFS 6.3 has to be released without the CD and should not mention it at all. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
