bug#9721: 1 of 404 tests failed (ls/slink-acl)
tag 9721 fixed thanks On 10/10/2011 03:10 PM, Stefano Lattarini wrote: Thanks for the testing and report. I believe that test problem was fixed by this patch posted 2 days ago and pushed to the public repository just one minute ago: http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=11cb50ee6d20966abe I can confirm that, updating to latest master, the testsuite failure I've reported disappears. In which case, I'm closing out this bug. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
bug#9721: 1 of 404 tests failed (ls/slink-acl)
On Monday 10 October 2011, Jim Meyering wrote: > Stefano Lattarini wrote: > > The test failed on my Debian desktop system. > > > > Attached are the log of the failed test, and the (compressed) config.log > > generated by configure. Let me know if you need more information. > > > > Regards, > > Stefano > > > > FAIL: ls/slink-acl (exit: 99) > > = > ... > > + require_setfacl_ > > + setfacl -m user::rwx . > > + touch k > > + setfacl -m m::r k > > setfacl: k: Operation not supported > > + framework_failure_ > > + warn_ 'slink-acl: set-up failure: ' > > + case $IFS in > > + printf '%s\n' 'slink-acl: set-up failure: ' > > slink-acl: set-up failure: > > + test 9 = 2 > > Thanks for the testing and report. > I believe that test problem was fixed by this patch posted 2 days ago > and pushed to the public repository just one minute ago: > > http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=11cb50ee6d20966abe > I can confirm that, updating to latest master, the testsuite failure I've reported disappears. Thanks, Stefano
bug#9721: 1 of 404 tests failed (ls/slink-acl)
Stefano Lattarini wrote: > The test failed on my Debian desktop system. > > Attached are the log of the failed test, and the (compressed) config.log > generated by configure. Let me know if you need more information. > > Regards, > Stefano > > FAIL: ls/slink-acl (exit: 99) > = ... > + require_setfacl_ > + setfacl -m user::rwx . > + touch k > + setfacl -m m::r k > setfacl: k: Operation not supported > + framework_failure_ > + warn_ 'slink-acl: set-up failure: ' > + case $IFS in > + printf '%s\n' 'slink-acl: set-up failure: ' > slink-acl: set-up failure: > + test 9 = 2 Thanks for the testing and report. I believe that test problem was fixed by this patch posted 2 days ago and pushed to the public repository just one minute ago: http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=11cb50ee6d20966abe
bug#9715: Error while compiling coreutils-8.12
Thanks for the bug report. >From the 'configure' file you sent, it appears that you're using a modified version of coreutils, along with some other files (e.g., ) that aren't part of the coreutils distribution. The "configure" file is generated automatically, so if it's not working for you, we need to fix the source code for "configure" rather than patching it by hand. The source code can be found in "configure.in" as well as in the m4/*.m4 files. Also, if any other source code is needed to build coreutils, we'd need that. I expect that this would include (which declares alloca and floss_getmntent) and perhaps the code for floss_getmntent. It puzzles me that any of these changes are needed, as I thought that coreutils already ran on Tandem. Perhaps Tandem has changed? or it's an issue of which compiler or library is being used? One other thing: it's better to use the latest version of coreutils (currently this is 8.13). Sometimes this fixes your problem without any further effort on your part; and even when it doesn't, any patches are easier to merge in.
bug#9719: i found a bug
On 10/10/2011 11:20 AM, Eric Blake wrote: tag 9719 notabug thanks On 10/10/2011 10:55 AM, Ovear wrote: [root@x3430-20836 ~]# echo " aa bb cc dd ee "| tr -s [:blank:] a bb cc dd ee Thanks for the report. However, this is not a bug in tr, but a bug in your usage of the shell. I suspect that you have a file in the current directory that is named with a single character, such that the shell glob [:blank:] is expanding to the name of that file. In fact, I will go so far as to state that the file in question is named 'a', given that you squeezed the 'a's in your output. To prove my point, compare the output of these commands in the same directory as where you filed your bug report: $ echo [:blank:] $ echo "[:blank:]" -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
bug#9719: i found a bug
tag 9719 notabug thanks On 10/10/2011 10:55 AM, Ovear wrote: [root@x3430-20836 ~]# echo " aa bb cc dd ee "| tr -s [:blank:] a bb cc dd ee Thanks for the report. However, this is not a bug in tr, but a bug in your usage of the shell. I suspect that you have a file in the current directory that is named with a single character, such that the shell glob [:blank:] is expanding to the name of that file. [root@x3430-20836 ~]# echo " aa bb cc dd ee "| tr -s " " aa bb cc dd ee [root@x3430-20836 ~]# i can not use like "[:blank:]" Yes you can, if you quote it so the shell can't treat it as a glob: # echo " aa bb cc > dd ee "| tr -s "[:blank:]" aa bb cc dd ee -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
bug#9719: i found a bug
[root@x3430-20836 ~]# echo " aa bb cc dd ee "| tr -s [:blank:] a bb cc dd ee [root@x3430-20836 ~]# echo " aa bb cc dd ee "| tr -s " " aa bb cc dd ee [root@x3430-20836 ~]# i can not use like "[:blank:]"
bug#9718: bugs in `date` command?
The term "third wednesday" seems to be evaluating incorrectly. glaive 12:24:56 [~]% date Mon Oct 10 12:24:59 EDT 2011 glaive 12:24:59 [~]% date -d "first wednesday" Wed Oct 12 00:00:00 EDT 2011 glaive 12:25:09 [~]% date -d "second wednesday" Wed Oct 12 00:00:01 EDT 2011 glaive 12:25:16 [~]% date -d "third wednesday" Wed Oct 26 00:00:00 EDT 2011 glaive 12:25:21 [~]% date -d "fourth wednesday" Wed Nov 2 00:00:00 EDT 2011 glaive 12:25:27 [~]% date -d "fifth wednesday" Wed Nov 9 00:00:00 EST 2011 glaive 12:25:34 [~]% date -d "next wednesday" Wed Oct 12 00:00:00 EDT 2011 glaive 12:25:41 [~]% date -d "last wednesday" Wed Oct 5 00:00:00 EDT 2011 glaive 12:25:46 [~]% date -d "this wednesday" Wed Oct 12 00:00:00 EDT 2011 glaive 12:33:39 [~]% date -d "third wednesday this month" Wed Oct 26 00:00:00 EDT 2011 glaive 12:34:11 [~]% date -d "3 wednesday" Wed Oct 26 00:00:00 EDT 2011 glaive 12:34:13 [~]% date -d "2 wednesday" Wed Oct 19 00:00:00 EDT 2011 glaive 12:34:28 [~]% date -d "1 wednesday" Wed Oct 12 00:00:00 EDT 2011 glaive 12:34:39 [~]% date -d "4 wednesday" Wed Nov 2 00:00:00 EDT 2011
bug#9714: [PATCH] maint: remove vestigial de-ANSI-fication support
Stefano Lattarini wrote: > The support for automatic de-ANSI-fication has been deprecated in > automake 1.11.2, and will be removed altogether in automake 1.12. > Also, coreutils does not use the `ansi2knr' option since at least > 2003-03-14 (commit b9fa45f2b01d0e395b7ddd845ebabb9528cf3f12 "remove > ansi2knr junk", and a few preceding commits). > > * /m4/jm-macros.m4 (gl_CHECK_ALL_TYPES): Don't require > `AM_C_PROTOTYPES' anymore. This is required to avoid a (mostly > spurious) warning from automake. > --- > m4/jm-macros.m4 |5 - > 1 files changed, 0 insertions(+), 5 deletions(-) > > diff --git a/m4/jm-macros.m4 b/m4/jm-macros.m4 > index 58b000d..40ff3e1 100644 > --- a/m4/jm-macros.m4 > +++ b/m4/jm-macros.m4 > @@ -193,11 +193,6 @@ AC_DEFUN([gl_CHECK_ALL_HEADERS], > # This macro must be invoked before any tests that run the compiler. > AC_DEFUN([gl_CHECK_ALL_TYPES], > [ > - dnl This test must precede tests of compiler characteristics like > - dnl that for the inline keyword, since it may change the degree to > - dnl which the compiler supports such features. > - AC_REQUIRE([AM_C_PROTOTYPES]) Thanks. I did that a week or so ago: http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=88873501cff9ed9
bug#9714: [PATCH] maint: remove vestigial de-ANSI-fication support
The support for automatic de-ANSI-fication has been deprecated in automake 1.11.2, and will be removed altogether in automake 1.12. Also, coreutils does not use the `ansi2knr' option since at least 2003-03-14 (commit b9fa45f2b01d0e395b7ddd845ebabb9528cf3f12 "remove ansi2knr junk", and a few preceding commits). * /m4/jm-macros.m4 (gl_CHECK_ALL_TYPES): Don't require `AM_C_PROTOTYPES' anymore. This is required to avoid a (mostly spurious) warning from automake. --- m4/jm-macros.m4 |5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/m4/jm-macros.m4 b/m4/jm-macros.m4 index 58b000d..40ff3e1 100644 --- a/m4/jm-macros.m4 +++ b/m4/jm-macros.m4 @@ -193,11 +193,6 @@ AC_DEFUN([gl_CHECK_ALL_HEADERS], # This macro must be invoked before any tests that run the compiler. AC_DEFUN([gl_CHECK_ALL_TYPES], [ - dnl This test must precede tests of compiler characteristics like - dnl that for the inline keyword, since it may change the degree to - dnl which the compiler supports such features. - AC_REQUIRE([AM_C_PROTOTYPES]) - dnl Checks for typedefs, structures, and compiler characteristics. AC_REQUIRE([gl_BIGENDIAN]) AC_REQUIRE([AC_C_VOLATILE]) -- 1.7.2.3
