Matthias Klose <[EMAIL PROTECTED]> writes: > Goswin Brederlow writes: > > Package: gcc-3.0 > > Version: 1:3.0.3-1 > > Severity: normal > > > > The package doesn't pass its selftests and _should_fail_ to build. > > It should fail when the first make fails and not continue with other > > selftest, otherwise errors get overlocked. > > huh? then we'll never have a build which succeeds ...
Some test are expected to fail, thats fine. I hope the expected failures don't make the make return with an error too. But an unexpected failure suggests a new error. That should fail and stop the build. > > The timeout might be the reason why it fails to build on m68k, > > something just takes too long during build. > > the timeout is a buildd problem, not a gcc problem. The timeout on m68k might take longer than 150 minutes from the last line it outputs. Then the buildd assumes its in a loop and kills it. Maybe a little more verbose output would solve the problem or help pinpoint the exact testcase that makes it fail. > > === libjava Summary === > > > > # of expected passes 1674 > > # of unexpected failures 1 > > # of unexpected successes 10 > > # of expected failures 14 > > # of untested testcases 17 > > make[5]: *** [check-DEJAGNU] Error 1 > > make[5]: Leaving directory > > `/tmp/gcc-3.0-3.0.3ds3/build/i386-linux/libjava/testsuite' > > make[4]: *** [check-am] Error 2 > > make[4]: Target `check' not remade because of errors. > > make[4]: Leaving directory > > `/tmp/gcc-3.0-3.0.3ds3/build/i386-linux/libjava/testsuite' > > ====================================================================== > > you deleted the interesting part. where/why doesn't it continue? It does. I think the next one was the gcc tests. That shouldn't be caried out since the libjava tests failed (unexpectedly). MfG Goswin