[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: a coreutils release is imminent
From: |
Matthew Woehlke |
Subject: |
Re: a coreutils release is imminent |
Date: |
Wed, 21 Mar 2007 17:00:28 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.4.0 |
Jim Meyering wrote:
Matthew Woehlke 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.
Hey, I plan on installing this sucker! I want it to work... :-D
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.
Ok, as long as it's known to be broken.
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".
Um. I added 'ls -t --full-time $d/a $d/b ; date' to the test, and got this:
-rw-r--r-- 1 install sqe 0 2007-03-21 13:42:31.590078000 -0800 ./b
-rw-r--r-- 1 install sqe 0 2007-03-21 13:21:20.009964000 -0800 ./a
...yike! Hmm... ok, *now* I see the problem. It turns out this box's
clock is WAAAAY off (about 21 minutes). So I guess this can be ignored.
However... what is different about OSF (versus, say, x86/Solaris) that
it sets the time stamp on a file on an NFS volume to the *local host's*
clock, rather than the NFS server's clock? On an x86/Solaris box (that
happens to be about six minutes fast), 'touch a' (coreutils 6.6) and '>
a' result in the same (correct (the NFS server is correct), but not
matching the local host's clock) time stamp.
--
Matthew
Congratulations! You've won a free trip to the future! All you have to
do to claim your prize is wait five minutes...
- a coreutils release is imminent, Jim Meyering, 2007/03/20
- Re: a coreutils release is imminent, Matthew Woehlke, 2007/03/20
- Re: a coreutils release is imminent, Bob Proulx, 2007/03/21
- Re: a coreutils release is imminent, Jim Meyering, 2007/03/21
- Re: a coreutils release is imminent, Matthew Woehlke, 2007/03/21
- Re: a coreutils release is imminent, Matthew Woehlke, 2007/03/21
- Re: a coreutils release is imminent, Jim Meyering, 2007/03/21
- Re: a coreutils release is imminent,
Matthew Woehlke <=
- Re: a coreutils release is imminent, Andreas Schwab, 2007/03/21
- Re: a coreutils release is imminent, Matthew Woehlke, 2007/03/21
- Re: a coreutils release is imminent, Jim Meyering, 2007/03/21
- Re: a coreutils release is imminent, Matthew Woehlke, 2007/03/21
- Re: a coreutils release is imminent, Paul Eggert, 2007/03/21
- Re: a coreutils release is imminent, Paul Eggert, 2007/03/21
Re: a coreutils release is imminent, Paul Eggert, 2007/03/21
Re: a coreutils release is imminent, Jim Meyering, 2007/03/21
Re: a coreutils release is imminent, Eric Blake, 2007/03/21