7.10 test issues in jhalfs
pierre.labastie at neuf.fr
Tue Sep 6 12:50:22 PDT 2016
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:
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.
More information about the alfs-discuss