Right, but we pass an int to these macros, so could they be doing anything but referencing the relevant bits? BTW in case WEXITSTATUS isn't always one wider than WTERMSIG, it would be more general to
the interesting content is in its own wiki on the same site, same restrictions: http://posix.rhansen.org:9001/p/bug947 My apologies for not mentioning the first time: username 'posix', password '2115
Patch is attached, fixing/simplifying the test, and adding lots of info about exit status limits. thanks again, Pádraig. Attachment: kill-large-signals.patch Description: Text Data
s/ulimit_supported/ulimit_supported_/ typo fixed in that Yes it does. In fact 1.576MB over the base determined value was needed. I've bumped the value to $base+4000 While testing on FreeBSD 10 I also
It wasn't stored in the hash actually, because on BTRFS the link count for a dir is always 1 (so there is no limit on the number of subdirs). The attached patch always hashes specified source dirs. c
This is triggered by /home being a BTRFS subvolume. Avoidance patch attached. Patch attached. cheers, Pádraig Attachment: df-mount-list-on-fail.patch Description: Text Data Attachment: df-symlink-su
We plan to release coreutils-8.25 early next week, so any testing you can do on various different systems between now and then would be most welcome. -- You can download the coreutils snapshot in xz
Hello Pádraig and all, With this new version (8.24.161), only 3 lesser issues remain. The other issues I mentioned with 8.24.150 are resolved. 1. Compiling with Tiny-C Compiler (due to tcc bug). 2.
Grr. Does increasing the adjustment value above 4000 help? I'd need access to that particular system to debug. I suppose we could s/framework_failure_/ret=$?/ here and rely on the subsequent skip_ No
Nearly there. I plan to release tomorrow. I've just committed a further two test fixes: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.24-162-gcc05c3c http://git.sv.gnu.org/gitweb/?p
2. On FreeBSD-9.3,amd64, "tests/misc/head-c" fails with: == + head --bytes=-9223372036854775807 head: memory exhausted == Grr. Does increasing the adjustment value above 4000 help? 5100 and above pa
Sorry for the last-minute post, but found 4 failures that might relate to GPFS file-system ( https://en.wikipedia.org/wiki/IBM_General_Parallel_File_System ). The system is CentOS 7 kernel 3.10.0-229
General problem with tail really on any remote file system. tail: 'a' has been replaced with a remote file. giving up on this name We should probably disable inotify if there are no files opened, as
-2016-01-18 12:21:28.294123000 -0500 +2016-01-18 12:21:28.296528000 -0500 cp -Pp didn't seem to preserve the timestamp on GPFS. I'd need access to the system to see why. I'd test with touch -d '...'
On 01/18/2016 03:31 PM, Assaf Gordon wrote: On 01/18/2016 02:27 PM, Pádraig Brady wrote: On 18/01/16 18:18, Assaf Gordon wrote: FAIL: tests/cp/preserve-slink-time -2016-01-18 12:21:28.294123000 -050
On 01/18/2016 03:38 PM, Assaf Gordon wrote: On 01/18/2016 03:31 PM, Assaf Gordon wrote: On 01/18/2016 02:27 PM, Pádraig Brady wrote: On 18/01/16 18:18, Assaf Gordon wrote: FAIL: tests/cp/preserve-sl
On 01/19/2016 11:03 AM, Pádraig Brady wrote: On 18/01/16 19:27, Pádraig Brady wrote: On 18/01/16 18:18, Assaf Gordon wrote: Sorry for the last-minute post, but found 4 failures that might relate to