Ken Moffat wrote:
> On my build of approximately 7.3 I got 4 failures in the procps
> tests. Pierre has fixed two of them (slabtop), but now that I've
> finished a minimal desktop I wanted to try to understand the other
> two before I try to prove it can build itself [ _without_ analyzing
> if it is bitwise the same, I've long since abandonned that ].
>
> I can't make head or tail of what is being run. I suspect that my
> absence of static libs in this build might be to blame for these
> errors, but I'll note that this time the slabtop tests were ok
> without the patch. The interesting part of the log is:
>
> Running ./pgrep.test/pgrep.exp ...
> ERROR: tcl error sourcing ./pgrep.test/pgrep.exp.
> ERROR: can't read "tty": no such variable
I've seen this if trying in chroot without /dev mounted. It needs /proc
too.
> while executing
> "spawn $pgrep -t $tty $testproc_comm"
> (file "./pgrep.test/pgrep.exp" line 83)
> invoked from within
> "source ./pgrep.test/pgrep.exp"
> ("uplevel" body line 1)
> invoked from within
> "uplevel #0 source ./pgrep.test/pgrep.exp"
> invoked from within
> "catch "uplevel #0 source $test_file_name""
> Running ./pkill.test/pkill.exp ...
> Running ./pmap.test/pmap.exp ...
> FAIL: pmap extra extended output (footer)
> FAIL: pmap double extra extended output (footer)
>
> The two ERROR messages don't get counted as failures, only the two
> FAIL. Any comments, or should I just quietly ignore this ?
I run tests using jhalfs. I did get:
ERROR: tcl error sourcing ./kill.test/kill.exp.
ERROR: couldn't execute "/sources/procps-ng-3.3.6/kill": no such file or
directory
I expect that though because we are specifically using --disable-kill.
Otherwise I have:
# of expected passes 95
# of untested testcases 20
> I'll also note that the glibc tests seem to have a race in
> something - on my first run, my build failed with Error 2 in the
> posix tests although the only failures I could find were Error 1.
> Sometimes, I really regret using set -e. Gave it what I thought
> might be a fix (|| true), sailed through. Only later did I find
> other tests failing (e.g. ld because of no static libs) and discover
> that my attempted fix was ineffective ( set +e ... set -e works if
> you want to save $? to record it in the logs or stamps ) and
> therefore the second run had not hit the same failure. I guess I'm
> increasingly inclined to disregard the tests - sometimes they show a
> problem, but more often any test failures are inconclusive. <sigh/>
For glibc, the only thing I have is:
$ grep Error 071-glibc
make[3]: [/sources/glibc-build/posix/annexc.out] Error 1 (ignored)
make[3]: *** [/sources/glibc-build/rt/tst-cputimer1.out] Error 1
make[2]: *** [rt/tests] Error 2
make[3]: [/sources/glibc-build/conform/run-conformtest.out] Error 1
(ignored)
make[1]: *** [check] Error 2
I get no FAIL messages at all.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
