Ken Moffat wrote: > On Thu, Aug 15, 2013 at 11:06:45AM -0500, Bruce Dubbs wrote: >> I'd like to do a package freeze today in preparation for LFS-7.4. >> >> Right now I'm not sure whether to to generate a rc1 or not. There are >> several tests that fail that we may want to 1) Note, 2) Patch, or 3) >> Ignore. Below is my analysis of the current svn: >> >> Coreutils. 1 failure. tests/df/skip-rootfs.sh >> >> This appears to be for the following reason. We are now running with >> /etc/mtab as a symlink to /proc/mounts and my host has a file system >> mounted that is not accessible in chroot. Probably can be ignored. > > Perhaps a brief note that it might fail ? Did it stop the build > with a bad return code the way that coreutils failures used to ? > 8.21 passed all its tests for me with versions from 5th August and > I'm sure that (at least) /home wasn't directly accessible from chroot.
This is what my log has: + df Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 10190136 1798576 7850888 19% / /dev/sda1 10190136 1798576 7850888 19% /boot devtmpfs 5055808 0 5055808 0% /dev /dev/sdb2 10190136 1798576 7850888 19% / devtmpfs 5055808 0 5055808 0% /dev shm 5056272 0 5056272 0% /run/shm + df -a df: '/mnt/qemu1': No such file or directory + fail=1 + grep '^rootfs' out rootfs 10190136 1798576 7850888 19% / + df + grep '^rootfs' out + df -t rootfs df: no file systems processed + grep '^rootfs' out + df -t rootfs -a + grep '^rootfs' out rootfs 10190136 1798576 7850888 19% / + df -a -x rootfs df: '/mnt/qemu1': No such file or directory + fail=1 + grep '^rootfs' out + Exit 1 The build was fine. There is just one test that indicates FAIL. > >> ---- >> Automake. 1 Failure, currently noted in the book. >> ---- >> Flex. 2 failures. Probably due to bison-3.0. These seem to be test >> failures only and we could add a note to the book > > I've found plenty of results on google for breakage caused by > bison-3.0 dropping things that had been deprecated, so that sounds > a plausible explanation. The phrase "the proof of the pudding is in > the eating" comes to mind - I believe you are planning to test a lot > of BLFS ? If so, a note would be a reasonable initial step. Not sure what kind of note you have in mind. We already have a patch for the two failures, but it no longer works. I'm about to remove the patch and insert: First, skip running two regression tests that are out of date: sed -i -e '/test-bison-yy/d' tests/Makefile.in >> ---- >> Texinfo. 1 Failure. prove.sh >> ./t/Pod-Simple-Texinfo.t (Wstat: 768 Tests: 17 Failed: 3) >> Failed tests: 3, 7, 11 >> Non-zero exit status: 3 >> >> http://old.nabble.com/Self-test-fail%3A-texinfo-5.1-due-to-pod-simple-pm-td35605532.html >> >> The book notes that "Two tests in the test suite fail due to out of date >> perl code." We could just change that to one. > > Sounds good. In my sandbox. >> ---- >> glibc. 4 failures, but three are noted in the book. >> >> The other is test-getaddrinfo4. Looking around, I did find this: >> http://sourceware.org/glibc/wiki/Release/2.18#Testsuite_Failures >> Add another note? > > No opinion, at the moment - I'm still on 2.17. Looking at > http://sourceware.org/bugzilla/buglist.cgi?quicksearch=getaddrinfo > there are 29 bugs open, but 1 appears to be a feature request and 20 > are against 2.17 or earlier (the rest are unspecified). Looking at posix/tst-getaddrinfo4.c, it looks like this will always fail without a network connection. I've added another item in the known failures section. >> ---- >> e2fsprogs. 1 failure. f_extent_oobounds. I found this: >> http://comments.gmane.org/gmane.comp.file-systems.ext4/39357 >> >> Add a sed? > > That reference looks like a reputable fix, so yes. In my sandbox. >> ---- >> bison. 1 failure. >> CXX examples/calc++/examples_calc___calc__-calc++-scanner.o >> g++: error: ./examples/calc++/calc++-scanner.cc: No such file or directory >> g++: fatal error: no input files >> compilation terminated. >> >> This matches what Ken saw a couple of days ago. May be specific to >> building in chroot. >> I'm still working on this one. > I'm still massaging my buildscripts and haven't managed to get > bison > 2.7.1 to build with them. Only a few more functions to > rename as km_, and then I'll have to go back to looking at the diff > of the source. > > That last sentence of yours makes me wonder what might be different > in chroot. Usually that comes down either to mounts, or to runtime > deps. I start to wonder if something needs to be built sooner. But > looking at the full text (wrapped by my mailer) I can't see anything > missing : > > /bin/sh ./build-aux/ylwrap `test -f > 'examples/calc++/calc++-scanner.ll' || echo > './'`examples/calc++/calc++-scanner.ll .c > examples/calc++/calc++-scanner.cc -- : > g++ -I./examples/calc++ -g -O2 -MT > examples/calc++/examples_calc___calc__-calc++-scanner.o -MD -MP -MF > examples/calc++/.deps/examples_calc___calc__-calc++-scanner.Tpo -c > -o examples/calc++/examples_calc___calc__-calc++-scanner.o `test -f > 'examples/calc++/calc++-scanner.cc' || echo > './'`examples/calc++/calc++-scanner.cc > g++: error: ./examples/calc++/calc++-scanner.cc: No such file or > directory > g++: fatal error: no input files > compilation terminated. > > It seems to me that build-aux/ylwrap is failing. That's a script > which creates temporary files and always deletes them on exit. I > don't see anything in it except /bin/sh, sed, and some coreutils > programs. And we've got all of those. That's good info. I'll use that for more investigation. Thanks. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
