Re: a coreutils release is imminent

[Jim Meyering]

Matthew Woehlke <address@hidden> wrote:
...
> 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.

Thanks for checking.

>> 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

In my book, this is an unimportant failure.
First, this is a brand new option.  No existing script uses it.
Second, on most systems it doesn't fail so easily.

> 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:
...
> Here's the verbose output (which I admit I am looking at, and don't
> understand...):
...
> + 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

This looks like a bug on that system.
Touching "a" 3s after "b", then running "ls -t a b",
the result should list the newer-mtime "a" before "b".