On Wed, Aug 01, 2007 at 02:53:59PM -0700, Dan Nicholson wrote: > On 7/30/07, Ken Moffat <[EMAIL PROTECTED]> wrote: > > > > To expand on what I posted earlier about test failures: > > > > Tar is repeatedly failing '26: incremental' for me, looks like a > > regression. But nobody else has commented. > > This time I got all passes for tar. Go figure. Yeah, I think it often works. Greg pointed to failures in another test on the tar list, but I haven't seen that in my own results. > > > The bash failure I reported was a fubar in my script (trying to > > chown the test log so it was writable by the appropriate user, but > > before it was created ;). But, my second run did seem to have one > > failure - 'run-test' shows > > > > 152c152 > > < 1 > > --- > > > 0 > > 158c158 > > < 1 > > --- > > > 0 > > I got those failures on a single run (using jhalfs). I'm not sure > what's causing the errors, but what's failing is `test -r /dev/fd/0' > and `test -r /dev/stdin' (look at tests/test.right for the output that > it's diffing to above). > > So, I suspect this has something to do with the su to the nobody user > and how su handles these devices. But the last time I thought about > this it hurt my head. It may have something even more to do with how > our scripts are handling the user switching. >
Hmm, it might indeed. I can't begin to get my head around the detail of *most* packages' testsuites. What I haven't done is actually confirm if the test finished with a good or bad status - will try to remember to check that tomorrow, and then see what happens if I try to su-tools and that test. > > The perl failure didn't happen on the second run, I guess it's just > > another unreliable test. > > What was the exact perl failure? (edited to suppress dots and path) ext/IO/t/io_sock Died at io_sock.t line 37, <GEN5> line 2. FAILED--expected 26 tests, saw 11. Somebody dug into _a_ perl failure recently and pointed out that the text had a description saying it sometimes fails. I'm not sufficiently motivated to search for the posting ;) > > > And the vim test failure is totally impenetrable. > > One of the vim tests hung on me, and trying to decipher the output > only resulted in garbage in the terminal. I think I might just stop > running this thing. > If my scripts had the ability to control tests on a per-package basis, I think I'd not run them for lots of the packages - I generally keep running tests because they usually look ok, but when a failure can be tracked down, more often than not it seems to be a problem in the testsuite. With vim, mine always writes to a log so the terminal itself isn't trashed. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
