It's not 100% reproducible actually, though once it starts happening it continues to, no matter how many times the file is replaced and removed. What seems to be happening is that the IN_ATTRIB event
We plan to release coreutils-8.24 in about a week, so any testing you can do on various different systems between now and then would be most welcome. Unfortunately shared testing resources have becom
Thanks for all that work. I've attached two tiny patches: Attachment: 0001-maint-factor.c-touch-up-preceding-change.patch Description: Binary data Attachment: 0002-maint-stdbuf.c-avoid-the-OS-X-puten
Hello Pádraig, You can download the coreutils snapshot in xz format (5.4 MB) from: http://pixelbeat.org/cu/coreutils-ss.tar.xz Few failures on OpenSolaris, attached logs from 5.10 and 5.11, i386 and
Hello Pádraig, Few test fail on FreeBSD 10.1, log attached. Many of them seem to be related to 'cp' and preserving permissions, e.g.: FAIL: tests/cp/backup-dir == cp: preserving permissions for 'y/x
HelloPádraig, Regarding the failing 'numfmt': Sadly numfmt fails on all of them, with something like this: $ ./src/numfmt --to=si 4000 0K <...> Which hints the problem is in numfmt.c:797, perhaps th
Is the extra 1 really required? The trailing one was there to cater for the putchar(). Cool. I see setenv() is also used in split. We probably should add an explicit depends in bootstrap.conf rather
I've got reports of that on all FreeBSDs from current trunk to 8.4. I'd need such a system to dig into it. Other notes I made from someone else's test-suite.log on FreeBSD: tests/misc/factor-parallel
Wow, good catch! I'm amazed it passes tests. I guess the overlap of the zeros in small int prec and the zeros in the reduced long double val cancel out :/ I'll apply in your name. thanks! Pádraig.
In a sense, it's not required... in that it doesn't really make a difference if we're off-by-1-byte-per-line when deciding whether to flush. I thought the trailing "+ 1" was for the fputs-added newli
Note in tests/init.sh we make an attempt to find a usable shell. The order is '/bin/sh bash dash zsh pdksh' Though I see no explicit test for "local" in that code. I wonder should we add this to the
The new tests/misc/factor-parallel.sh in this area was failing on FreeBSD (derived) systems where PIPE_BUF = 512 is significant. The attached patch rewrites this code and implements the line bufferin
We plan to release coreutils-8.23 next week, so any testing you can do on various different systems between now and Thursday would be most welcome. -- You can download the coreutils snapshot in xz fo
[umm - was the Reply-to of address@hidden intentional? I'm assuming you wanted replies just to the coreutils list] On 32-bit cygwin, a default ./configure didn't even get to 'make check' due to this
That was set by the gnu mailing as I didn't set a specific reply-to and was sending to multiple lists. Hmm, I'm guessing the make level failure is related to EXEEXT. Notice how bin_PROGRAMS is adjust
Possible; I'll give it a shot. At this point, it requires a full autoreconf, so I spent some time getting coreutils.git up and running rather than just building from the snapshot. Now I'm seeing this
Oops, s/faile/fail/ (not sure how I messed up the copy/paste). Other warnings, once I turned -Werror off: == Related to the first, not sure why the analysis is different on cygwin than it is for Linu
Hello Eric, Pádraig, <...> Ouch. isdigit() is fairly safe (because POSIX limits it to returning true for exactly 10 bytes that can't become negative when promoted to int), but isblank((int)char) is