[lfs-dev] Bad md5 hash for lfs-bootscripts-20130805.tar.bz2
>From the md5sum file with today's rc1 stuff... 110c873942f2c0d2d678e25a7594decb lfs-bootscripts-20130805.tar.bz2 My result... md5sum lfs-bootscripts-20130805.tar.bz2 70af42e8209cc933f22e44ea7b79b7c1 lfs-bootscripts-20130805.tar.bz2 Arthur -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Bad md5 hash for lfs-bootscripts-20130805.tar.bz2
Bruce Dubbs gmail.com> writes: > > Arthur Radley wrote: > >>From the md5sum file with today's rc1 stuff... > > > > 110c873942f2c0d2d678e25a7594decb lfs-bootscripts-20130805.tar.bz2 > > > > My result... > > > > md5sum lfs-bootscripts-20130805.tar.bz2 > > 70af42e8209cc933f22e44ea7b79b7c1 lfs-bootscripts-20130805.tar.bz2 > > Try downloading again. They only differ in timestamps, but I put the > correct version in place. > >-- Bruce > All is good now with the rc1 md5sum file. Thanks. I went ahead with the build anyway firstly because I won't need that tarball until later tonight, and secondly because I figured whatever was the matter it wouldn't be a big deal. Thanks Arthur -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Some minor text tidying for v7.4-rc1
A few things the book says are installed by some of the packages, but I cannot find them installed on my system (or I found information about these no longer being installed)... GLIBC... pt_chown (already mentioned in a recent blfs-dev thread) GCC... gccbug (no information, but I can't find this) UTIL-LINUX... tunelp (deprecated & removed 2012-12-19, http://git.kernel.org/cgit/utils/util-linux/util-linux.git/log/?qt=grep&q=tunelp) x86_64 (no information, but I can't find a script or binary named this) AUTOMAKE... elisp-comp (deleted 2012-08-05 according to the Changelog) symlink-tree (??? Was sync'd from GCC SVN repo but not since 2012-01-21 according to the Changelog. Anyway, I don't have it.) KMOD... kmod-nolib (no information, but I can't find this) LFS-BOOTSCRIPTS... mountkernfs (renamed to mountvirtfs in 2011) static (renamed to ipv4-static in 2004) Arthur -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Some minor text tidying for v7.4-rc1
Ragnar Thomsen gmail.com> writes: > > On Monday 19 August 2013 15:20:10 Arthur Radley wrote: > > A few things the book says are installed by some of the packages, but I > > cannot find them installed on my system (or I found information about these > > no longer being installed)... > > GCC... > > > > gccbug (no information, but I can't find this) > > I would also like to direct your attention to a mail I sent to lfs-dev back in > June: > > http://comments.gmane.org/gmane.linux.lfs.devel/14130 > > concerning the list of installed files for GCC not being up-to-date. Maybe this > can get corrected for LFS 7.4. > > Sincerely, > Ragnar Speaking of libraries... FWIW (maybe nothing), I forgot to mention originally that I also searched my 7.4-rc1 system for every library file mentioned in the book and found them all (including the four referenced above by Ragnar). I didn't try to discover installed libraries not mentioned in the book. Anyway, maybe it's worth reporting that the libraries that are listed in the book are accurate. Arthur P.S.: I also had no issues with any of the steps in the rc1 book. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Some LFS v7.5-rc1 feedback
Everything went smoothly. I only wanted to mention one new thing that
happened and one old thing.
The new thing: In section 6.17. GCC-4.8.2 when verifying that the new linker
is being used with the correct search paths, the result had some extra lines
for /lib32 which I haven't seen before and which are not in the book's
example...
bash-4.2# grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
SEARCH_DIR("/usr/i686-pc-linux-gnu/lib32")
SEARCH_DIR("/usr/local/lib32")
SEARCH_DIR("/lib32")
SEARCH_DIR("/usr/lib32")
SEARCH_DIR("/usr/i686-pc-linux-gnu/lib")
SEARCH_DIR("/usr/local/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("/usr/lib");
And the old thing: Again this time I had that single unexpected test failure
for GCC regarding asan_test.C which your test logs don't have. I reported
that also for LFS v7.4, but I went on to build my usual BLFS system and used
it since then with no problems. The asan_test.C failure is apparently a
recent known issue even though the LFS build-logs still don't show it
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55577)...
=== g++ Summary ===
# of expected passes53365
# of unexpected failures1
# of expected failures 290
# of unsupported tests 647
/sources/gcc-build/gcc/testsuite/g++/../../xg++ version 4.8.2 (GCC)
Anyway, all this is just FYI. Thanks again for all your effort to make this
terrific OS available to us, the 1% of the 1%.
Arthur
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Some LFS v7.5-rc1 feedback
Pierre Labastie neuf.fr> writes: > > But I am worried about this new output for 32 bit build. Doesn't it mean > we should have a symlink lib32->lib, as we have lib64->lib for 64 bit? > How many packages do rely on having libs in lib32 rather than lib? > > Pierre > No lib32 folder was ever created anywhere in the 7.5-rc1 system being built when that GCC check result was observed. Arthur -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] LFS 7.5-rc1 6.2.3. Mounting Virtual Kernel File Systems
LFS 7.5-rc1 6.2.3. Mounting Virtual Kernel File Systems Re: mkdir -pv $LFS/$(readlink $LFS/dev/shm) If the host's /dev/shm is a symbolic link to /run/shm, then "readlink $LFS/dev/shm" will output "/run/shm". mkdir apparently ignores the extra forward slash and creates the directory, but the verbose output of mkdir will be "/mnt/lfs//run/shm" which looks wrong to anyone reading the verbose output (me). It's trivial. Anyway. P.S.: All the other instances of readlink in the book produce "../" and don't do this. Arthur -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
