On 06/09/2016 19:14, Bruce Dubbs wrote: > Last night I did a jhalfs run of LFS to get timing data fo 7.10 (and to check > gcc failures (they were OK)). > > What I got was a hang in coreutils. The specific test was > tests/misc/seq-precision.sh where it does: > > seq 999999 inf | head -n2 > out || fail=1 > seq 1 .1 inf | head -n2 > out || fail=1 > seq inf inf | head -n2 | uniq > out || fail=1 > > If you run these from the command line, there is no problem. Something > happens when running jhalfs that seems to be intercepting the sigpipe signal > when head exits and seg runs forever making the script hang. > > Running the build/test from the command line seems OK. > > When running jhalfs, I'd suggest editing lfs-commands/chapter06/116-coreutils > and adding > > rm tests/misc/seq-precision.sh > > I've not tested this. What I did was a 'ps -ef |grep nobody' and saw the seq > command running. I killed that and then did it twice more for the other two > calls and then the test completed. > > --- > > In a second minor issue, when running jhalfs the tar extraction of packages > writes a sequence like: > > Building target 133-man-db > tar: write error > > The actual extraction seems to be OK. It does not happen on every file but > does for most. > > Upon reflection it may be due to my disk setup. My drive is an SSD and I have > noatime as a part of the mount options. That may be the reason for the > message. However I don't get that message from the command line when working > from the SSD drive. > > -- Bruce >
I've just rebuilt 7.10-rc1 on real hardware, and have none of those issues. For the coreutils test: PASS: tests/misc/seq-precision.sh The SBU is rather long (13.8), but binutils was run at -j5, while coreutils is run at -j1, so I do not think the test hanged for me. What I know is that some test results are different in coreutils depending whether the terminal is an X terminal or a linux console (the test ssty-pairs.sh for example, does not pass on linux console). I have built in an X terminal (LXTerminal). Thinking about it, we do intercept some signals in jhalfs, that might be the reason. I am almost sure I have seen something similar to what you report in the past. But now, what I usually do is to first configure jhalfs whithout ticking "Run the Makefile", then manually type: make -C /mnt/lfs/jhalfs. This way, no signals are intercepted... Maybe it'd be better to remove the capability to automatically run the Makefile, and just have an informational message "Configuration is now finished. Type "make -C /mnt/lfs/jhalfs" to begin the build". For the second issue, I am almost sure I do not see that, but since this part is not logged, I cannot be totally affirmative. I have seen that on old debian (6 maybe) versions, though. Regards Pierre -- http://lists.linuxfromscratch.org/listinfo/alfs-discuss FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
