bug#6327: sort fails on some UTF-8 input
River Tarnell wrote: I'm using coreutils 8.5 on Solaris 10. GNU 'sort' fails to sort some input, while Solaris 'sort' handles it correctly: willow% /opt/ts/gnu/bin/sort sort_test.txt /opt/ts/gnu/bin/sort: string comparison failed: Illegal byte sequence /opt/ts/gnu/bin/sort: Set LC_ALL='C' to work around the problem. /opt/ts/gnu/bin/sort: The strings compared were `\360\222\203\276\360\222\205\226' and `\360\222\200\255\360\222\213\253\360\222\213\253\360\222\200\255'. willow% /usr/bin/sort sort_test.txt ⅖ ⋫⋫ willow% I've attached the example file sort_test.txt. Thanks for the report. Since this appears not to be due to any problem with GNU sort per se, but rather with solaris' strcoll implementation, I'm closing this coreutils issue and Cc'ing bug-gnulib, in case someone there wants to pursue the strcoll-replacement approach.
bug#6683: mktemp foo.XXXXXXXXXXX is not sufficiently random
On 08/07/2011 10:04 AM, Jim Meyering wrote: Yes, please do. OK, thanks, I installed the one-line change as change to the diff. This is the first time I've updated a diff file in a while (ever?), so I hope I did it right. I'm marking the bug done. From 8e2767a3f0c279d355f067e53be2c63173959eb1 Mon Sep 17 00:00:00 2001 From: Paul Eggert egg...@cs.ucla.edu Date: Mon, 8 Aug 2011 00:29:46 -0700 Subject: [PATCH] mktemp: stir in enough entropy (Bug#6683) * gl/lib/tempname.c.diff (gen_tempname_len): Use x_suffix_len bytes' worth of entropy, not 8 bytes. --- gl/lib/tempname.c.diff |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/gl/lib/tempname.c.diff b/gl/lib/tempname.c.diff index fcacf53..3e30c97 100644 --- a/gl/lib/tempname.c.diff +++ b/gl/lib/tempname.c.diff @@ -100,7 +100,7 @@ index 2da5afe..562955a 100644 - } -#endif - value += random_time_bits ^ __getpid (); -+ rand_src = randint_all_new (NULL, 8); ++ rand_src = randint_all_new (NULL, x_suffix_len); + if (! rand_src) +return -1; -- 1.7.4.4
bug#9237: [PATCH] tests: get rid of obsolete 'error_' shell function
On Monday 08 August 2011, Jim Meyering wrote: Stefano Lattarini wrote: Date: Thu, 4 Aug 2011 20:48:06 +0200 Subject: [PATCH] tests: complete the renaming framework_failure - framework_failure_ * tests/init.cfg (framework_failure): Remove, `framework_failure_' from init.sh should be used instead in the tests. Remove leading obsolete FIXME comment. (is_local_dir_, require_strace_, require_membership_in_two_groups_, require_sparse_support_, skip_if_mcstransd_is_running_, mkfifo_or_skip_) Use `framework_failure_', not `framework_failure'. * Many test scripts: Likewise. Thanks. I've confirmed that the modified command below does the same job and requires less manual editing. I've modified your commit log to include the command and to fix typos, so include the new version below. Thanks! And BTW, allow me to apologize for the embarassing number of typos in both the patch and my previous mail. Also, I have queued this additional change set: From 601c4d9209e506b92ebfbc9d0fec0f679f5fe5d3 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Mon, 8 Aug 2011 08:54:52 +0200 Subject: [PATCH 2/2] maint: prevent accidental future use of the old shell function name This is especially important for an error-handling shell function like this that is actually called only rarely. [SNIP] Good addition. Should have thought about it myself ... Regards, Stefano
bug#9140: [PATCH 2/3] large-inode: New module
On 07/22/2011 04:10 PM, Paul Eggert wrote: On 07/22/11 10:45, Pádraig Brady wrote: If it works it would be better in AC_SYS_LARGEFILE (as well) I think. OK, thanks, I pushed this into gnulib. Assuming it works (and I don't see why it'd hurt) I'll push it into autoconf. Ouch. This commit broke libvirt 0.9.4, because it unintentionally broke large-file support altogether. It will probably break any other packages that have picked up the latest gnulib in the last few days. Pádraig Brady suggested this in http://debbugs.gnu.org/9140#20. * MODULES.html.sh: Add largefile, remove large-inode. * modules/largefile, m4/largefile.m4: New files. * modules/large-inode, m4/large-inode.m4: Remove. - -configure.ac-early: -AC_REQUIRE([gl_SYS_LARGE_INODE]) - -configure.ac: - + +configure.ac: +AC_REQUIRE([AC_SYS_LARGEFILE]) + +configure.ac: + The first configure.ac should have been configure.ac-early; as a result of the duplicate listing, gnulib-tool completely omits AC_SYS_LARGEFILE from any configure.ac that was using the broken largefile module. Test by looking at './configure --help | grep large' pre- and post-patch. I'm pushing this: diff --git i/ChangeLog w/ChangeLog index 72e7611..3fd0c47 100644 --- i/ChangeLog +++ w/ChangeLog @@ -1,3 +1,8 @@ +2011-08-08 Eric Blake ebl...@redhat.com + + largefile: fix typo that regressed large file support + * modules/largefile (configure.ac-early): Fix section name. + 2011-08-06 Karl Berry k...@gnu.org * MODULES.html.sh (func_all_files): _Noreturn is no longer diff --git i/modules/largefile w/modules/largefile index d4a2e4b..ca10d48 100644 --- i/modules/largefile +++ w/modules/largefile @@ -6,7 +6,7 @@ m4/largefile.m4 Depends-on: -configure.ac: +configure.ac-early: AC_REQUIRE([AC_SYS_LARGEFILE]) configure.ac: -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
bug#9262: test.c runs afoul of GCC 4.6.1 bug if --enable-gcc-warnings
I'm running into a problem with GCC 4.6.1 x86-64 when compiling coreutils (latest git version), configured with --enable-gcc-warnings. A bogus warning is generated, causing make to fail. The warning is function might be candidate for attribute 'pure' if it is known to return normally [-Wsuggest-attribute=pure], and it points to the advance function in test.c. The warning is also generated for lbracket.c, which includes test.c. This is due to a GCC bug that has just been confirmed; see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50021. For now I'm leaving this alone, but I thought I'd give others a heads-up. The coreutils code is pretty crufty but on the other hand I dislike modifying code just to work around bugs in static checkers.
bug#9263: mv overwrite message when owner different
This message, mv: try to overwrite `/cf/updates/F.cpio.gz', overriding mode 0644 (rw-r--r--)? y does not make it clear that the file owner is different. mv (GNU coreutils) 8.5
bug#9140: [PATCH 2/3] large-inode: New module
Eric Blake wrote: It will probably break any other packages that have picked up the latest gnulib in the last few days. Indeed. It broke libiconv-1.14. But fortunately it's not a regression. Large file support in the 'iconv' program would have been an undocumented improvement. Now it's delayed to libiconv-1.15... Thanks for having discovered and fixed this, Eric!! Bruno -- In memoriam Edward Pimental http://en.wikipedia.org/wiki/Edward_Pimental
bug#9262: test.c runs afoul of GCC 4.6.1 bug if --enable-gcc-warnings
Paul Eggert wrote: I'm running into a problem with GCC 4.6.1 x86-64 when compiling coreutils (latest git version), configured with --enable-gcc-warnings. A bogus warning is generated, causing make to fail. The warning is function might be candidate for attribute 'pure' if it is known to return normally [-Wsuggest-attribute=pure], and it points to the advance function in test.c. The warning is also generated for lbracket.c, which includes test.c. This is due to a GCC bug that has just been confirmed; see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50021. For now I'm leaving this alone, but I thought I'd give others a heads-up. The coreutils code is pretty crufty but on the other hand I dislike modifying code just to work around bugs in static checkers. Thanks for the heads up. This came up in July: http://thread.gmane.org/gmane.comp.gnu.coreutils.general/1399 This is why I now build with gcc-4.7.x. With it, I no longer get that invalid warning. Ideally, configure would check for the buggy compiler and disable the offending option when found. If you're not going to work on that, what do you think about sending a message to cont...@debbugs.gnu.org with this in the body? tags 9262 + notabug close 9262 Since this isn't a bug in coreutils, and I'm trying to close issues we're not likely to work on.
