Re: a coreutils release is imminent

[Matthew Woehlke]

Matthew Woehlke wrote:
> Jim Meyering wrote:
> > Matthew Woehlke wrote:
> > > sort-compress still fails with a low process limit (e.g. my OSF
> > > system)... I thought this was fixed? It also failed on ia64/hpux.
> > >
> > > There is (still) a really annoying problem with the perl detection that
> > > leads to "can't find strict.pm" problems; maybe we could check that perl
> >
> > This is the first I've heard of such a problem.
> > What version of Perl is installed there?
> > I may simply raise the required version number to one for which
> > "use strict;" works.  In the mean time, you can work around that
> > by manually removing the "use strict" lines.
>
> That's what I was thinking. Hmm, 'perl --version' hangs waiting for 
> input, and 'perl -V' is a usage error. So... how do I *tell* what 
> version? (Clearly I'm not a perl expert :-).)
>
> Hmm, ok, I see this in the error:
> /freeware/lib/perl5/alpha-dec_osf/5.00401
> ...so maybe it is 5.00401?
>
> [snip] methinks my perl is b0rk.

Ok, I finally bit the bullet and figured out how to build perl. (Talk 
about ugly build systems... I feel unclean.) It croaked once on tty-eof 
but skipped it after I nuked the dir and started clean from the tarball, 
so that was probably because I installed a working perl after running 
configure.

> Anyway, sort-compress is still "broken". Wasn't there talk of limiting 
> the number of forks based on getrlimit?

It passed on another re-run, then failed again... which as I recall is 
expected; the failure is intermittent because it depends on *which* fork 
fails. (There were still plenty of /fork/ failures* on the "successful" 
run, just not a "critical" one.)

So I guess sort-compress is the only remaining severe failure, failing 
on OSF (due to the extremely low 64-process-limit) and at least once on 
ia64/HPUX. Unfortunately this test seems to fail irregularly.

However, I am seeing one more failure on OSF: touch/empty-file. Both the 
local clock and the NFS clock incorrectly report PST, but otherwise 
appear to be in sync:

$ touch fubar ; ls --full-time fubar ; date ; rm -f fubar
-rw-r--r-- 1 user group 0 2007-03-21 12:22:59.009964000 -0800 fubar
Wed Mar 21 12:22:59 PST 2007

Increasing SLEEP_SECONDS as suggested didn't help (although I only tried 
5, not 3602...).

Here's the verbose output (which I admit I am looking at, and don't 
understand...):

+ DEFAULT_SLEEP_SECONDS=2
+ SLEEP_SECONDS=3
+ fail=0
+ : .
+ framework_failure=0
+ rm -rf ./a ./b ./c
+ 1> ./a
+ test -f ./a
+ 1> ./b
+ test -f ./b
+ 1> ./c
+ test -f ./c
+ test 0 = 1
+ echo sleeping for 3 seconds...
sleeping for 3 seconds...
+ sleep 3
+ touch ./a
+ ls -t ./a ./b
+ set x ./b ./a
+ test x ./b ./a = x ./a ./b
+ fail=1
+ echo sleeping for 3 seconds...
sleeping for 3 seconds...
+ sleep 3
+ touch ./b
+ ls -t ./a ./b
+ set x ./b ./a
+ test x ./b ./a = x ./b ./a
+ touch -
+ 1< ./c 2> /dev/null
+ rm -rf ./a ./b ./c
+ test 1 != 0
+ cat
+ 1>& 2 0<<

--
Matthew
Congratulations! You've won a free trip to the future! All you have to 
do to claim your prize is wait five minutes...