Is 6.3 ready for release?
I put out a 6.3-rc1 a week ago and there really has been very little feedback. Is it ready for final release? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Is 6.3 ready for release?
El Lunes, 30 de Julio de 2007 20:02, Bruce Dubbs escribió: I put out a 6.3-rc1 a week ago and there really has been very little feedback. Is it ready for final release? I think so, but fixing before the missing consolelog bootscript description in chapter07/bootscripts.xml. I have done a lot of builds this days with no issues. If some bug is found later we always could do a 6.3.1 release. Plus, I would start today with the preparative to can merge the x86_64 branch into trunk. -- 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: Is 6.3 ready for release?
On 7/30/07, Bruce Dubbs [EMAIL PROTECTED] wrote: I put out a 6.3-rc1 a week ago and there really has been very little feedback. Is it ready for final release? We need to decide what to do about usb_device devices with linux-2.6.22. http://linuxfromscratch.org/pipermail/lfs-dev/2007-July/059794.html Manuel also asked me to document the consolelog bootscript I added to Ch.7. Oops, it looks like I never spun a new tarball for lfs-bootscripts, so no one has tested the changes I've made recently unless they manually synced. There are two changes in the udev-config rules (in addition to the first item above which hasn't been addressed) that aren't in the current tarball. Let me spin new tarballs for lfs-bootscripts and udev-config. I'll make an announcement on lfs-dev and ask people to test them out. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Is 6.3 ready for release?
On Mon, Jul 30, 2007 at 08:03:43PM +0200, M.Canales.es wrote:
If some bug is found later we always could do a 6.3.1 release.
Plus, I would start today with the preparative to can merge the x86_64 branch
into trunk.
I've been thinking about this some more recently. I really think it's
not worth the time and effort (at least not now) to add the extra
complexity to the XML/XSL to render two separate books for x86 LFS and
x86_64 LFS. The command changes are so minimal that in the end, there
would be very few differences at all. Just for the sake of review and to
show how I would resolve the differences in one book, here's what we
would need to change:
1) After the installation of binutils-pass1, run:
ln -sv lib /tools/lib64
This, being just a symlink has absolutely no effect on x86. We can
put a note that it can be skipped for 32-bit x86, but it hurts nothing.
2) All builds of GCC get the switch '--disable-multilib'. Again,
harmless for x86. Again, we can put a note that it could be left out, if
desired, for x86.
3) Section 5.7, 'Adjusting the Toolchain'. Here's where it gets a little
fun. But still, easily adapted to fit both situations. Somewhere, at the
beginning of the book, we set a LINKER (or some such) variable,
depending on arch. Easily scripted via `uname -m` for the sake of
accuracy. We also take into account that gcc will make use of the /lib64
directory internally, so we account for that, too, in our adjusting
command. Like so:
gcc -dumpspecs | sed s@/lib[64]*/$LINKER@/tools@g \ (etc.)
4) In gcc pass 2, currently there's a sed command that deletes the
multilib spec in gcc/config/i386/t-linux64. I don't think this would
have any effect on x86, but I haven't tested. Also, there have been some
inconsistencies between what I have found wrt the purpose of this
removal and what Greg has found over at DIY. I want to do more testing.
In any case, it is one command and it doesn't seem likely to me to
affect a non-multlib, non-64 bit arch.
5) Creating Directories. Again, adding the {/usr,}/lib64 symlinks. Same
comments as in item 1.
6) Bootloader. This one is probably the biggest. Legacy grub is probably
still preferable for x86. I see 3 options here:
a. Convert to lilo for both (dependency on bin86 which requires a
patch for x86_64)
b. Convert to grub2 for both (untested by me, but I believe it works
for both. Joe Ciccone has more info.)
c. Tell users to install grub via their host system. (Most have it
these days. Wouldn't work for the 64-bit only LiveCD as of now.)
7) Last one. We would need to alter the output of the sanity tests to
accomodate both instances. Or, at least, add more descriptive notes
showing *what* exactly we are looking for and what the differences would
be with a different target triplet and dynamic linker. To me, this would
be a good thing anyway as it makes the instructions that much more
educational and less robotic.
I'll follow the decision of the community on this one, but to me, it
would be a simple thing to merge both possibilities into one set of
instructions. I believe making the LFS book just a little more
architecture agnostic does more to help teach concepts.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Is 6.3 ready for release?
El Lunes, 30 de Julio de 2007 21:26, Jeremy Huntwork escribió: I've been thinking about this some more recently. I really think it's not worth the time and effort (at least not now) to add the extra complexity to the XML/XSL to render two separate books for x86 LFS and x86_64 LFS. The command changes are so minimal that in the end, there would be very few differences at all. Just for the sake of review and to show how I would resolve the differences in one book, here's what we would need to change: Yes, the differences between a x86 build and a pure 64 libs x86_64 build are minimal. The question is, we will add only pure 64 libs x86_64? or is that a mean of POC before adding also instructions to build multilib x86_64 systems? IMHO, multilib build instructions will be very intrussive due that several packages need be builded two times. If we want to add it, we will need to render sepparate books to not mess the reader with a lot of if . Thus I think that if multilib support will be added, is best to have ready the profiling and rendering framework now that the changes are minimal, to let editors familiarice with the new XML tagging. 6) Bootloader. This one is probably the biggest. Legacy grub is probably still preferable for x86. I see 3 options here: a. Convert to lilo for both (dependency on bin86 which requires a patch for x86_64) b. Convert to grub2 for both (untested by me, but I believe it works for both. Joe Ciccone has more info.) c. Tell users to install grub via their host system. (Most have it these days. Wouldn't work for the 64-bit only LiveCD as of now.) d. Move bootloader compilation to Chapter 8 Making the LFS System Bootable discussing available alternatives (Grub, Grub2, LiLo, the host bootloader, a boot CD, etc...) -- 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: Is 6.3 ready for release?
On Mon, Jul 30, 2007 at 10:08:53PM +0200, M.Canales.es wrote: IMHO, multilib build instructions will be very intrussive due that several packages need be builded two times. If we want to add it, we will need to render sepparate books to not mess the reader with a lot of if . I prefer to stay away from multilib. At least for the time being. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Is 6.3 ready for release?
On Mon, Jul 30, 2007 at 01:02:29PM -0500, Bruce Dubbs wrote: I put out a 6.3-rc1 a week ago and there really has been very little feedback. Is it ready for final release? -- Bruce Wow, a whole week. Maybe, hardly anybody has tried it because this is the holiday season in the Northern hemisphere. To expand on what I posted earlier about test failures: Tar is repeatedly failing '26: incremental' for me, looks like a regression. But nobody else has commented. The bash failure I reported was a fubar in my script (trying to chown the test log so it was writable by the appropriate user, but before it was created ;). But, my second run did seem to have one failure - 'run-test' shows 152c152 1 --- 0 158c158 1 --- 0 - as to what that means, your guess is as good as mine. The perl failure didn't happen on the second run, I guess it's just another unreliable test. And the vim test failure is totally impenetrable. In general, the more I run test suites, the less confidence I have in them. Sure, sometimes they point to problems (e.g. when our build order in clfs was wrong and the findutils tests crapped out), but a lot of the time I wonder why we bother. And moving on to farce test results (how repeatable is it?) - apart from cc1 and cc1plus I also had a failure in libc-2.5.so (not yet investigated) and in private mail from archaic I know he saw a failure in nscd (I've got his files for this, but haven't investigated it yet). He also noted in that mail that coreutils seems to be using a pre-created info file in his second and third builds - (I've only run two, and misread the diff : coreutils.info was created by makeinfo version 4.9 in the first build, and 4.8 in the second). But, we don't expect user to build it twice, so I'm not too worried about that, I just add it to my coreutils Makefile is a POS thoughts :-) Nobody else has reported any difference in libc-2.5.so so that is probably a local fubar or a shortcoming in my farce regexps. OTOH, nobody has yet reported on their successes or failures in using it to build BLFS, whether for a server or for a desktop. I was hoping to spend time looking at farce before I ran a third build without tests, and later a by-the-book build with only toolchain tests, but if you want to get it released I'll happily drop those. I won't be able to finish a desktop for some time. Which only leaves space/SBU measurements. Because my build hasn't been by-the-book, and has run tests whenever possible, I'll only comment on those I know look wrong (chapter 6 only) 1. Kernel headers. The time is still minimal, but I think these take 304MB, not 286MB (that should apply to chapter 5 too) - that's because the instructions were altered to install to a subdirectory in the source and then copy them, which is much nicer/safer but guaranteed to take more space. 2. The coreutils time (1.0 SBU) is presumably without tests, but mine only took 1.0 SBU with the tests. 3. If the SBU for autoconf without tests is correct, the tests take about 4 SBU, not 3 (don't you just love newer toolchains?). 4. Similarly, automake is in excess of 13 SBU with tests, not 10. 5. My bzip2 install took 6.4 MiB not 5.3, I attribute this to the docs which seem to be non-optional according to how the book is written. 6. Findutils supposedly takes 13.6 MiB - I assume that is without the tests: with the tests mine took a little more time but only 12.6 MiB. 7. Gzip for me takes 3.3 MiB not 2.2 MiB. 8. Inetutils for me takes 0.3 SBU (not 0.2) and 12.1 MiB (not 8.9). 9. Iproute2 for me takes 0.1 SBU (not 0.2) and 5.0 MiB (not 4.8). Actually, that might be getting a bit close to splitting hairs. 10. The lfs-bootscripts use 0.6 MiB for me, not 0.4 MiB. Now, time for me to ask a question: Is it worthwhile that we continue to record SBUs and space ? Everybody knows that many packages take longer to build and use more space whenever the toolchain is upgraded. Is it really worthwhile to be so exact about the time and space. Certainly, space should be constant across an architecture (well, i686 anyway) for a given toolchain, but the timings depend greatly on amount of memory (do you hit swap?), memory speed (try using a via processor), and disk speed. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LFS-Bootscripts 20070730
I rolled a new snapshot that has a few changes since the last 20070420 tarball. Please test it out so we can get any fixes in to 6.3. They should be entirely backwards compatible with existing scripts. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Tar tests (was Re: Is 6.3 ready for release?)
On 7/30/07, Greg Schafer [EMAIL PROTECTED] wrote: Ken Moffat wrote: Tar is repeatedly failing '26: incremental' for me, looks like a regression. But nobody else has commented. I see this intermittently. I also see 29 failing intermittently too which I reported upstream to no response: Yeah, I've been seeing incremental as well as sorted failing on and off over the past couple releases (I think sorted might be fixed now). http://lists.gnu.org/archive/html/bug-tar/2007-07/msg00032.html In fact, the upstream list has various reports of both 26 and 29 failing. Because they appear to be intermittent failures, I believe they are probably timing related. It's possible these tests are missing sleep statements in key areas (there are many sleep statements within the tar testsuite). Seems pretty likely. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Tar tests (was Re: Is 6.3 ready for release?)
On Tue, Jul 31, 2007 at 08:07:47AM +1000, Greg Schafer wrote: Ken Moffat wrote: Tar is repeatedly failing '26: incremental' for me, looks like a regression. But nobody else has commented. I see this intermittently. I also see 29 failing intermittently too which I reported upstream to no response: http://lists.gnu.org/archive/html/bug-tar/2007-07/msg00032.html In fact, the upstream list has various reports of both 26 and 29 failing. Because they appear to be intermittent failures, I believe they are probably timing related. It's possible these tests are missing sleep statements in key areas (there are many sleep statements within the tar testsuite). Regards Greg Thanks, Greg. One less thing to worry about for a release. Maybe I was just lucky when running tests before 6.3 and on other architectures (actually, the one I definitely remember passing was on ppc - that box is so slow it probably doesn't need any added 'sleep'). ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Is 6.3 ready for release?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Jeremy Huntwork wrote: 3) Section 5.7, 'Adjusting the Toolchain'. Here's where it gets a little fun. But still, easily adapted to fit both situations. Somewhere, at the beginning of the book, we set a LINKER (or some such) variable, depending on arch. Easily scripted via `uname -m` for the sake of accuracy. We also take into account that gcc will make use of the /lib64 directory internally, so we account for that, too, in our adjusting command. Like so: gcc -dumpspecs | sed s@/lib[64]*/$LINKER@/tools@g \ (etc.) Just a suggestion: that sed regexp will match more strings than we intend (but not in this context). This would work fine too, and would be more restrictive: gcc -dumpspecs | sed s@/lib\(64\)\?/$LINKER@/tools@g \ (etc.) Not that I think it really matters -- what we have will work OK. It's just that people may inadvertently start to think that square brackets tell sed to group things together, when they really delimit character classes. Unfortunately the make a group out of 64, and accept zero or one of them version is several characters longer due to the backslashes. That can be shortened a bit with sed's -r option: gcc -dumpspecs | sed -r s@/lib(64)?/$LINKER@/tools@g \ (etc.) but then you're typing in a new -r option, so it's pretty much no different in terms of amount of typing. ;-) (It may also require GNU sed, I'm not sure.) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGrm56S5vET1Wea5wRAyMoAKCwViWZgKqPjB5fnUHXKjkM49cNSwCfUQ5V /dR3X6zRrtrrl1Pic+uuSV4= =xYZ6 -END PGP SIGNATURE- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
