Thanks for testing. But the above does not make sense to me because until ./configure is run there is no ./Makefile and therefore the "make bootstrap" can't work. Also since this is a distribution te
What umask are you using when unpacking, building, and testing? In order to get directory modes 777 I would expect that you have a zero umask set. If you unpack, build and test using 'umask 02' or 'u
I won't disagree that people may like the colors but personally I find them annoying. Mostly this is because wading through the escape sequences in the logs makes it difficult to find failures. I am
when you unpack using `tar xf coreutils-...tar.gz` as root, the directories get 0777 even with umask 0022. unpacking as non-root gives correct behavior of 0755. -mike Attachment: signature.asc Descri
Hi Bob, Or just determine why the test for whether to enable colors isn't working for the buildbot? In build-aux/check.mk, it does this: if test -t 1; then red=... Can you create a stand-alone test t
The 'test -t 1' does not check the value of TERM. It simply assumes a vt220 terminal and assigns escape sequences without regard to terminal type. It really should only do this when there is a compat
Here are the usual tarballs and signatures. 3.5M http://meyering.net/cu/coreutils-6.9-ss.tar.lzma 8.5M http://meyering.net/cu/coreutils-6.9-ss.tar.gz aka 3.5M http://meyering.net/cu/coreutils-6.9-375
Where do you think it is buggy? This is the classical effect of double rounding, and the printf formatting is doing exactly the right thing. Andreas. -- Andreas Schwab, SuSE Labs, address@hidden SuSE
... Hi Pádraig, I think Mike's was on some ppc-based system, but I think the cause was a buggy test, not a buggy printf function. Did you see Andreas' messages in this thread? http://thread.gmane.or
According to Jim Meyering on 11/1/2007 5:21 PM: I haven't had time to fully analyze these failures on cygwin, but here's the list. The bulk of the problems are probably due to file name restrictions,
Actually I did not misread it. I added those tests to test various combinations of _what the user expects_ not what the current implementation happens to be. I.E. `seq 10.8 0.1 10.95`, should always
Here are the tarballs and signatures. (note the name change: the -ss names no longer include any version string) 3.6M http://meyering.net/cu/coreutils-ss.tar.lzma 8.6M http://meyering.net/cu/coreutil
I've just made a new snapshot. This may be the last one before the upcoming beta release, so please give it a good work-out. If there aren't too many problems, I'll release coreutils-6.9.90 this week
Two bug fixes so far: "ls -l" would not output "+" on SELinux hosts unless -Z was also given. "rm" would fail to unlink a non-directory when run in an environment in which the user running rm is capa
I've built a new snapshot: http://meyering.net/cu/coreutils-ss.tar.gz http://meyering.net/cu/coreutils-ss.tar.lzma http://meyering.net/cu/coreutils-ss.tar.gz.sig http://meyering.net/cu/coreutils-ss.t
... ... Thanks for reporting that. Unfortunately, it's hard to reproduce and debug at the same time. And it rarely complains about the same program twice in a row, so I'm confident it's not a problem