Matthew Woehlke <[EMAIL PROTECTED]> 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". _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
