bug#14477: [PATCH] tests: numfmt: use the printf program, not the shell builtin
* tests/misc/numfmt.pl: Here. This avoids a spurious failure when
/bin/sh is dash (as can happen on Debian systems).
---
tests/misc/numfmt.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/misc/numfmt.pl b/tests/misc/numfmt.pl
index 61917fb..553f68b 100644
--- a/tests/misc/numfmt.pl
+++ b/tests/misc/numfmt.pl
@@ -887,7 +887,7 @@ if ($locale ne 'C')
{
# Reset locale to 'C' if LOCALE_FR_UTF8 doesn't output as expected
# as determined by the separate printf program.
-open(LOC_NUM, LC_ALL=$locale printf \%'d\ 1234|)
+open(LOC_NUM, env LC_ALL=$locale printf \%'d\ 1234|)
or die Can't fork command: $!;
my $loc_num = LOC_NUM;
close(LOC_NUM) || die Failed to read grouped number from printf;
--
1.8.3.rc3.8.g5e49f30
bug#14253: Testsuite failure in gnulib-tests: test programs cannot be built
On 04/25/2013 07:29 AM, Paul Eggert wrote: On 04/24/2013 02:08 AM, Pádraig Brady wrote: Bernhard noticed this also: http://lists.gnu.org/archive/html/coreutils/2013-03/msg00065.html Thanks, here's a proposed patch. I'll CC: this to Bruno since he's gettext's maintainer. From 319571c0a0ad96d60f00470ef5d0ac8cc83c194b Mon Sep 17 00:00:00 2001 From: Paul Eggert egg...@cs.ucla.edu Date: Wed, 24 Apr 2013 22:26:31 -0700 Subject: [PATCH] gettext: now your responsibility to add s/now/now it's/ ? -$(top_builddir)/intl I guess you meant '-I$(top_builddir)/intl' here. [SNIP] Regards, Stefano
bug#14253: Testsuite failure in gnulib-tests: test programs cannot be built
It happens when building from a bootstrapped git checkout, with the latest master v8.21-40-g090294b). This is the exact error: $ (cd gnulib-tests make check) ... make[3]: Entering directory `/storage/home/stefano/src/gnu/coreutils/gnulib-tests' CC localename.o cc1: error: ../intl: No such file or directory [-Werror] cc1: all warnings being treated as errors make[3]: *** [localename.o] Error 1 Some details that might be helpful: $ (cd gnulib-tests make check V=1) ... make[3]: Entering directory `/storage/home/stefano/src/gnu/coreutils/gnulib-tests' depbase=`echo localename.o | sed 's|[^/]*$|.deps/|;s|\.o$||'`;\ gcc -std=gnu99 -I. -I../lib -DIN_COREUTILS_GNULIB_TESTS=1 \ -I. -I. -I.. -I./.. -I../lib -I./../lib -I../intl \ -W \ -Wabi \ -Waddress \ -Wall \ -Warray-bounds \ -Wattributes \ -Wbad-function-cast \ -Wbuiltin-macro-redefined \ -Wcast-align \ -Wchar-subscripts \ -Wclobbered \ -Wcomment \ -Wcomments \ -Wcoverage-mismatch \ -Wcpp \ -Wdeprecated \ -Wdeprecated-declarations \ -Wdisabled-optimization \ -Wdiv-by-zero \ -Wempty-body \ -Wendif-labels \ -Wenum-compare \ -Wextra \ -Wformat-contains-nul \ -Wformat-extra-args \ -Wformat-security \ -Wformat-y2k \ -Wformat-zero-length \ -Wformat=2 \ -Wfree-nonheap-object \ -Wignored-qualifiers \ -Wimplicit \ -Wimplicit-function-declaration \ -Wimplicit-int \ -Winit-self \ -Wint-to-pointer-cast \ -Winvalid-memory-model \ -Winvalid-pch \ -Wjump-misses-init \ -Wmain \ -Wmaybe-uninitialized \ -Wmissing-braces \ -Wmissing-declarations \ -Wmissing-field-initializers \ -Wmissing-include-dirs \ -Wmissing-noreturn \ -Wmissing-parameter-type \ -Wmudflap \ -Wmultichar \ -Wnarrowing \ -Wnonnull \ -Wnormalized=nfc \ -Wold-style-declaration \ -Woverflow \ -Woverlength-strings \ -Woverride-init \ -Wpacked \ -Wpacked-bitfield-compat \ -Wparentheses \ -Wpointer-arith \ -Wpointer-sign \ -Wpointer-to-int-cast \ -Wpragmas \ -Wreturn-type \ -Wsequence-point \ -Wshadow \ -Wstrict-aliasing \ -Wsuggest-attribute=noreturn \ -Wswitch \ -Wsync-nand \ -Wtrampolines \ -Wtrigraphs \ -Wtype-limits \ -Wunknown-pragmas \ -Wunused \ -Wunused-but-set-parameter \ -Wunused-but-set-variable \ -Wunused-function \ -Wunused-label \ -Wunused-local-typedefs \ -Wunused-parameter \ -Wunused-result \ -Wunused-value \ -Wunused-variable \ -Wvariadic-macros \ -Wvector-operation-performance \ -Wvolatile-register-var \ -Wwrite-strings \ -Wno-sign-compare \ -Wno-unused-parameter \ -Wsuggest-attribute=noreturn \ -Wno-format-nonliteral \ -Wno-logical-op -fdiagnostics-show-option -funit-at-a-time \ -Werror -g -O2 -MT localename.o -MD -MP -MF $depbase.Tpo -c -o localename.o localename.c \ mv -f $depbase.Tpo $depbase.Po cc1: error: ../intl: No such file or directory [-Werror] cc1: all warnings being treated as errors make[3]: *** [localename.o] Error 1 make[3]: Leaving directory `/storage/home/stefano/src/gnu/coreutils/gnulib-tests' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/storage/home/stefano/src/gnu/coreutils/gnulib-tests' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/storage/home/stefano/src/gnu/coreutils/gnulib-tests' make: *** [check] Error 2 $ gcc --version gcc (Debian 4.7.2-5) 4.7.2 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Let me know if you need more information, Stefano
bug#13525: 8.20 - [seq 1 3 1] treated as [seq 1 3]
On 01/22/2013 12:23 PM, Pádraig Brady wrote: On 01/22/2013 10:43 AM, Marcel Böhme wrote: Dear all, There is another bug that sneaked into the speed patch of seq on 13.09.12: 560 if (all_digits_p (argv[optind]) 561(n_args == 1 || all_digits_p (argv[optind + 1])) 562(n_args 3 || STREQ (1, argv[optind + 2])) 563!equal_width !format_str strlen (separator) == 1) That should probably be: 560 if (all_digits_p (argv[optind]) 561(n_args == 1 || all_digits_p (argv[optind + 1])) 562(n_args 3 || STREQ (1, argv[optind + 1])) 563!equal_width !format_str strlen (separator) == 1) Sigh we really messed up seq in that release :( The attached should fix it: One minor typo in commit message: [SNIP] * tests/misc/seq.pl: Add a test foro this case. s/foro/for/ Regards, Stefano
bug#13210: [PATCH] maint: cygwin build broken
On 12/18/2012 12:20 AM, Pádraig Brady wrote: On 12/17/2012 11:50 AM, Z. Majeed wrote: Building latest git source in a non-src directory on cygwin win7 with gcc 4.5.3 is broken - a patch follows - doc/local.mk: doc subdir is not created in build dir - I made it a prereq of doc/constants.texi That seems a little hacky, for what seems like an automake bug. Maybe this one is the culprit? http://git.sv.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.11-328-ge87c030 Nope, that change had been later reverted, before any stable release: http://git.sv.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.11-512-g40c3432 I use automake-1.11.6 and the coreutils configured min version is 1.11.2. Specifically I'm not impacted as I have this in Makefile: $(srcdir)/doc/version.texi: $(srcdir)/doc/stamp-vti $(srcdir)/doc/stamp-vti: doc/coreutils.texi $(top_srcdir)/configure test -f doc/$(am__dirstamp) || $(MAKE) $(AM_MAKEFLAGS) doc/$(am__dirstamp) ... This rules is there also for makefiles generated by Automake 1.12.x. And the issue here is really not Automake's fault; the problem really likes in the coreutil's build system, since the declaration: doc/constants.texi: $(top_srcdir)/src/tail.c $(top_srcdir)/src/shred.c is hand-written in 'doc/local.mk', and is not provided by Automake. So what suggested by the OP is not a workaround, but a fix -- and it seems a correct fix to me (albeit a little abusing of Automake's internal). BTW, Steffano, how can I see what release the above commit is included in? No one :-) Only minor versions seem to be tagged? How so? I see: http://git.savannah.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.12 I dislike dependency creep so am open to a workaround as long as we know what's going on. See above. HTH, Stefano
bug#13185: Test case 'misc/timeout-group' failed
On 12/18/2012 01:48 AM, Pádraig Brady wrote: So the skip was on purpose and to avoid signal propagation issues seen on some older systems: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=v8.14-30-g6603e37 This initial failure is worrying, though may be a false positive due to your shell or something. What versions of dash, bash, kernel do you have there? $ bash --version GNU bash, version 4.2.36(2)-release (i686-pc-linux-gnu) $ dpkg -l dash | sed -n '$p' ii dash 0.5.7-3 i386 POSIX-compliant shell $ uname -rsv Linux 2.6.30-2-686 #1 SMP Sat Sep 26 01:16:22 UTC 2009 I can't reproduce at all here with any shell, though you might have older versions. What is your system /bin/sh, dash or bash? Bash. But the affected coreutils testsuite run was done with a more bleeding-edge version of bash, explicitly selected as SHELL (and CONFIG_SHELL). Note you can force a particular SHELL as follows, and it would be interesting to see if the issue affected all shells. The fact is that I haven't been able to reproduce the issue after the first failure. So it won't be easy to ensure whether it has been fixed... make check TESTS='tests/misc/timeout-group.sh' SUBDIRS=. VERBOSE=yes SHELL=bash Hopefully we can come up with a skip for this case too. thanks, Pádraig. Regards, Stefano
bug#13210: [PATCH] maint: cygwin build broken
On 12/18/2012 11:20 AM, Pádraig Brady wrote: [SNIP] Anyway an explicit `make doc/constants.texi` fails on my system too (with a non-src build), and so can fail in a larger build due to ordering of rules. Since we're manually writing the doc/constants.texi rule anyway, I prefer to just add in the MKDIR_P which is the technique we use elsewhere in coreutils. Yeah, but is a simpler and safer idiom. Only minor versions seem to be tagged? How so? I see: http://git.savannah.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.12 I was looking for a tag at each release. 1.11.6 etc. http://git.savannah.gnu.org/cgit/automake.git/tag/?id=v1.11.6 http://git.savannah.gnu.org/cgit/automake.git/tag/?id=v1.11.5 http://git.savannah.gnu.org/cgit/automake.git/tag/?id=v1.11.4 etc ;-) They weren't done for the 1.11 series but they are in place since 1.12, for example: http://git.savannah.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.12.5 There's probably little need to retag older releases, so it's fine going forward. [SNIP] It's good to know we could rely on am__dirstamp in future if needed. Actually, that is an automake internal (as hinted by the 'am__' prefix), and should not be relied upon if at all possible (like it was in this case). Best regards, and HTH, Stefano
bug#13185: Test case 'misc/timeout-group' failed
On 12/18/2012 02:18 PM, Pádraig Brady wrote: I noticed a possible race in the test script. So I'll apply this soon. thanks, Pádraig. commit 09f72d285514a91495960ea3b0570251eed415b0 Author: Pádraig Brady p...@draigbrady.com Date: Tue Dec 18 13:06:15 2012 + tests: avoid a race in timeout-group.sh * tests/misc/timeout-group.sh: The kernel might possibly delay signal propagation to timeout.cmd long enough, that it exits normally without running the signal handler (as sleep will be in the same process group and so get the signal too). So avoid this by explicitly checking that the signal handler is called, which should always happen under normal circumstances. Reported by Stefano Lattarini on linux-2.6.30-2-686 and bash-4.2.36. diff --git a/tests/misc/timeout-group.sh b/tests/misc/timeout-group.sh index 4cefc33..7117abb 100755 --- a/tests/misc/timeout-group.sh +++ b/tests/misc/timeout-group.sh @@ -34,7 +34,11 @@ cat timeout.cmd \EOF #!/bin/sh trap 'touch int.received; exit' INT touch timeout.running -sleep $1 +count=$1 +until test -e int.received || test $count = 0; do + sleep 1 + count=$(expr $count - 1) +done EOF chmod a+x timeout.cmd Seems sensible to me. Let's hope it works; I'll re-open this report if I ever stumble into this problem again. Thanks, Stefano
bug#13185: Test case 'misc/timeout-group' failed
On 12/14/2012 06:28 PM, Stefano Lattarini wrote:
While running the coreutils testsuite on my oldish Debian desktop with
a somewhat heavy load and several bleeding-edge tools in PATH, I've
encountered this failure in the 'tests/misc/timeout-group.sh' test.
[SNIP]
I've re-run the test few times with the system no longer loaded, and
it passed. I he re-run it one more time with the system under some
load again, and this time the test was skipped!
timeout-group.sh: skipped test: timeout returned 142. SIGALRM not handled?
SKIP: tests/misc/timeout-group.sh
The detailed log of the skip is here below.
HTH,
Stefano
-*-*-
++ initial_cwd_=/devel/bleeding/src/coreutils
++ fail=0
+++ testdir_prefix_
+++ printf gt
++ pfx_=gt
+++ mktempd_ /devel/bleeding/src/coreutils gt-timeout-group.sh.
+++ case $# in
+++ destdir_=/devel/bleeding/src/coreutils
+++ template_=gt-timeout-group.sh.
+++ MAX_TRIES_=4
+++ case $destdir_ in
+++ case $template_ in
unset TMPDIR
+++ d=/devel/bleeding/src/coreutils/gt-timeout-group.sh.6KTf
+++ case $d in
+++ test -d /devel/bleeding/src/coreutils/gt-timeout-group.sh.6KTf
ls -dgo /devel/bleeding/src/coreutils/gt-timeout-group.sh.6KTf
tr S -
+++ perms='drwx-- 2 4096 Dec 14 18:30
/devel/bleeding/src/coreutils/gt-timeout-group.sh.6KTf'
+++ case $perms in
+++ test 0 = 0
+++ echo /devel/bleeding/src/coreutils/gt-timeout-group.sh.6KTf
+++ return
++ test_dir_=/devel/bleeding/src/coreutils/gt-timeout-group.sh.6KTf
++ cd /devel/bleeding/src/coreutils/gt-timeout-group.sh.6KTf
++ gl_init_sh_nl_='
'
++ IFS='
'
++ for sig_ in 1 2 3 13 15
+++ expr 1 + 128
++ eval 'trap '\''Exit 129'\'' 1'
+++ trap 'Exit 129' 1
++ for sig_ in 1 2 3 13 15
+++ expr 2 + 128
++ eval 'trap '\''Exit 130'\'' 2'
+++ trap 'Exit 130' 2
++ for sig_ in 1 2 3 13 15
+++ expr 3 + 128
++ eval 'trap '\''Exit 131'\'' 3'
+++ trap 'Exit 131' 3
++ for sig_ in 1 2 3 13 15
+++ expr 13 + 128
++ eval 'trap '\''Exit 141'\'' 13'
+++ trap 'Exit 141' 13
++ for sig_ in 1 2 3 13 15
+++ expr 15 + 128
++ eval 'trap '\''Exit 143'\'' 15'
+++ trap 'Exit 143' 15
++ trap remove_tmp_ 0
+ path_prepend_ ./src
+ test 1 '!=' 0
+ path_dir_=./src
+ case $path_dir_ in
+ abs_path_dir_=/devel/bleeding/src/coreutils/./src
+ case $abs_path_dir_ in
+
PATH=/devel/bleeding/src/coreutils/./src:/devel/bleeding/src/coreutils/src:/usr/local/bleeding/bin:/usr/local/bleeding/sbin:/home/stefano/bin/local:/home/stefano/bin:/usr/local/bin:/opt/bin:/usr/lib/jvm/java-6-sun-1.6.0.26/bin:/usr/games:/usr/bin:/usr/sbin:/bin:/sbin
+ create_exe_shims_ /devel/bleeding/src/coreutils/./src
+ case $EXEEXT in
+ return 0
+ shift
+ test 0 '!=' 0
+ export PATH
+ print_ver_ timeout
+ test yes = yes
+ local i
+ for i in '$*'
+ env timeout --version
timeout (GNU coreutils) 8.20.63-4f62d
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Padraig Brady.
+ setsid true
+ cat
+ chmod a+x timeout.cmd
+ cat
+ chmod a+x group.sh
+ setsid ./group.sh
+ retry_delay_ check_timeout_cmd_running .1 6
+ local test_func=check_timeout_cmd_running
+ local init_delay=.1
+ local max_n_tries=6
+ local attempt=1
+ local num_sleeps=1
+ local time_fail
+ test 1 -le 6
++ gawk -v n=1 -v s=.1 'BEGIN { print s * n }'
+ local delay=0.1
+ check_timeout_cmd_running 0.1
+ local delay=0.1
+ test -e timeout.running
+ sleep 0.1
+ return 1
+ time_fail=1
++ expr 1 + 1
+ attempt=2
++ expr 1 '*' 2
+ num_sleeps=2
+ test 2 -le 6
++ gawk -v n=2 -v s=.1 'BEGIN { print s * n }'
+ local delay=0.2
+ check_timeout_cmd_running 0.2
+ local delay=0.2
+ test -e timeout.running
+ time_fail=0
+ break
+ test 0 = 0
+ env kill -INT -- -3744
+ wait
+ test -e int.received
+ rm -f int.received timeout.running
++ date +%s
+ start=1355506235
+ pid=3779
+ retry_delay_ check_timeout_cmd_running .1 6
+ local test_func=check_timeout_cmd_running
+ local init_delay=.1
+ local max_n_tries=6
+ local attempt=1
+ local num_sleeps=1
+ local time_fail
+ test 1 -le 6
++ gawk -v n=1 -v s=.1 'BEGIN { print s * n }'
+ timeout -sALRM 30 timeout -sINT 25 ./timeout.cmd 20
+ local delay=0.1
+ check_timeout_cmd_running 0.1
+ local delay=0.1
+ test -e timeout.running
+ time_fail=0
+ break
+ test 0 = 0
+ kill -ALRM 3779
+ wait 3779
+ ret=142
+ test 142 -eq 124
+ skip_ 'timeout returned 142. SIGALRM not handled?'
+ warn_ 'timeout-group.sh: skipped test: timeout returned 142. SIGALRM not
handled?'
+ case $IFS in
+ printf '%s\n' 'timeout-group.sh: skipped test: timeout returned 142. SIGALRM
not handled?'
timeout-group.sh: skipped test: timeout returned 142. SIGALRM not handled?
+ test 9 = 2
+ printf '%s\n' 'timeout-group.sh: skipped test: timeout returned 142. SIGALRM
not handled?'
+ sed 1q
+ Exit 77
+ set +e
+ exit 77
+ exit 77
+ remove_tmp_
+ __st=77
+ cleanup_
+ :
+ cd /devel/bleeding/src/coreutils
+ chmod -R u+rwx /devel
bug#12899: Build failure from latest master
On 11/16/2012 02:44 AM, Jim Meyering wrote: Stefano Lattarini wrote: Hi Paul, thanks for the quick feedback. On 11/15/2012 10:03 PM, Paul Eggert wrote: Thanks, wouldn't the following be a bit cleaner, since MAINTAINERCLEANFILES contains BUILT_SOURCES? Possibly yes, but since this behaviour is not documented in the Automake manual, I'd marginally (60-40) prefer not rely on it. Not a big deal in any case, so feel free to mend my patch if you like, with my ACK. I too prefer to use BUILT_SOURCES, and using it here is consistent with the numerous other uses in that file. Which behavior is not documented? The fact that $(BUILT_SOURCES) is automatically cleaned by the Automake-generated 'maintainer-clean rule'. The MAINTAINERCLEANFILES-containing-BUILT_SOURCES is done via this in src/local.mk: MAINTAINERCLEANFILES += $(BUILT_SOURCES) Ah, I didn't noticed that. That I agree with Paul. Could you (Paul or Jim) tweak my patch accordingly, before pushing it? Or should I send a re-roll? Thanks, Stefano
bug#12899: Build failure from latest master
In a freshly-cloned repository on Debian with GNU make 3.82 and gcc 4.7.2.: $ ./bootstrap ./configure ... [all is ok] $ make all ... CC src/echo.o CCLD src/echo CC src/env.o CCLD src/env CC src/expand.o CCLD src/expand CC src/expr.o CCLD src/expr CC src/factor.o src/factor.c:650:20: fatal error: primes.h: No such file or directory compilation terminated. make[2]: *** [src/factor.o] Error 1 Am I the only one encountering such failures? If yes, I'll provide more information about my environment in order to help debugging this. Regards, Stefano
bug#12899: Build failure from latest master
On 11/15/2012 07:24 PM, Stefano Lattarini wrote: In a freshly-cloned repository on Debian with GNU make 3.82 and gcc 4.7.2.: $ ./bootstrap ./configure ... [all is ok] $ make all ... CC src/echo.o CCLD src/echo CC src/env.o CCLD src/env CC src/expand.o CCLD src/expand CC src/expr.o CCLD src/expr CC src/factor.o src/factor.c:650:20: fatal error: primes.h: No such file or directory compilation terminated. make[2]: *** [src/factor.o] Error 1 The patch below seems to solve the issue. Just let me run a complete bootstrap to ensure this is the case ... 8 8 8 8 8 8 8 8 8 From 0d1064cf32327fc0f2c422306d35eceb6334336d Mon Sep 17 00:00:00 2001 Message-Id: 0d1064cf32327fc0f2c422306d35eceb6334336d.1353004592.git.stefano.lattar...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Thu, 15 Nov 2012 19:36:21 +0100 Subject: [PATCH] build: fix build failures from pristine checkout Fixed coreutils bug#12899. * src/local.mk (BUILT_SOURCES): Add '$(top_srcdir)/src/primes.h'. --- src/local.mk | 1 + 1 file changed, 1 insertion(+) diff --git a/src/local.mk b/src/local.mk index 02a9bf5..337d005 100644 --- a/src/local.mk +++ b/src/local.mk @@ -386,6 +386,7 @@ src/dircolors.h: src/dcgen src/dircolors.hin # insist that maintainers must build on hosts that support the widest # known ints (currently 128-bit). MAINTAINERCLEANFILES += $(top_srcdir)/src/primes.h +BUILT_SOURCES += $(top_srcdir)/src/primes.h $(top_srcdir)/src/primes.h: $(MAKE) src/make-prime-list $(AM_V_GEN)rm -f $@ $@-t -- 1.8.0.150.gb0b00a3
bug#12899: Build failure from latest master
On 11/15/2012 07:36 PM, Stefano Lattarini wrote: The patch below seems to solve the issue. Just let me run a complete bootstrap to ensure this is the case ... Yep, it works. But I don't have pushing rights, so someone will have to apply it for me. Regards, Stefano
bug#12899: Build failure from latest master
Hi Paul, thanks for the quick feedback. On 11/15/2012 10:03 PM, Paul Eggert wrote: Thanks, wouldn't the following be a bit cleaner, since MAINTAINERCLEANFILES contains BUILT_SOURCES? Possibly yes, but since this behaviour is not documented in the Automake manual, I'd marginally (60-40) prefer not rely on it. Not a big deal in any case, so feel free to mend my patch if you like, with my ACK. Thanks, Stefano
bug#12820: gnulib testsuite failure in latest master
On 11/08/2012 08:44 AM, Paul Eggert wrote: Ouch, I read your strace output incorrectly: it was napping for 20 ms, not 2 s. Still, there should be no need to nap for that long; 1 ms should suffice on your platform. I installed the following patch to cause the test to take shorter naps. This might affect your original problem, and might not (hey! it's a timing problem) but at least it should make the test run faster. I'll re-run the affected test case as soon as coreutils updates its version of gnulib then, and see what happens. Thanks, Stefano
bug#12820: gnulib testsuite failure in latest master
tags 12820 + moreinfo
severity 12820 minor
thanks
Hi Paul.
On 11/07/2012 04:46 PM, Paul Eggert wrote:
Can you please run strace ./test-utimens and
let us know the system calls that the failing test
executes?
Sure, here it is:
-*-*-
execve(./test-utimens, [./test-utimens], [/* 89 vars */]) = 0
brk(0) = 0x981c000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb803b000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=197544, ...}) = 0
mmap2(NULL, 197544, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb800a000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/i386-linux-gnu/i686/cmov/librt.so.1, O_RDONLY) = 3
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\30\0\0004\0\0\0..., 512)
= 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=30684, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb8009000
mmap2(NULL, 33360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb800
mmap2(0xb8007000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0xb8007000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/i386-linux-gnu/i686/cmov/libc.so.6, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240o\1\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1413288, ...}) = 0
mmap2(NULL, 1427832, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7ea3000
mprotect(0xb7ff9000, 4096, PROT_NONE) = 0
mmap2(0xb7ffa000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x156) = 0xb7ffa000
mmap2(0xb7ffd000, 10616, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7ffd000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/i386-linux-gnu/i686/cmov/libpthread.so.0, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220L\0\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=117009, ...}) = 0
mmap2(NULL, 98816, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7e8a000
mmap2(0xb7e9f000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14) = 0xb7e9f000
mmap2(0xb7ea1000, 4608, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7ea1000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7e89000
set_thread_area({entry_number:-1 - 6, base_addr:0xb7e898d0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
mprotect(0xb7e9f000, 4096, PROT_READ) = 0
mprotect(0xb7ffa000, 8192, PROT_READ) = 0
mprotect(0xb8007000, 4096, PROT_READ) = 0
mprotect(0xb8059000, 4096, PROT_READ) = 0
munmap(0xb800a000, 197544) = 0
set_tid_address(0xb7e89938) = 6810
set_robust_list(0xb7e89940, 0xc)= 0
futex(0xbfa0d810, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL,
bfa0d820) = -1 EAGAIN (Resource temporarily unavailable)
rt_sigaction(SIGRTMIN, {0xb7e8e6e0, [], SA_SIGINFO}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0xb7e8eb70, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
uname({sys=Linux, node=bigio, ...}) = 0
rt_sigaction(SIGINT, {SIG_IGN, [], 0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], 0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD,
parent_tidptr=0xbfa0d7e4) = 6811
waitpid(6811, [{WIFEXITED(s) WEXITSTATUS(s) == 0}], 0) = 6811
rt_sigaction(SIGINT, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, [], 0}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
open(test-utimens.tfile, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0600) = 3
close(3)= 0
stat64(test-utimens.tfile, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
open(test-utimens.ttmp, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0600) = 3
close(3)= 0
stat64(test-utimens.ttmp, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
unlink(test-utimens.ttmp) = 0
nanosleep({0, 2000}, NULL) = 0
open(test-utimens.ttmp, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0600) = 3
close(3)= 0
stat64(test-utimens.ttmp, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
unlink(test-utimens.ttmp) = 0
nanosleep({2, 0}, NULL) =
bug#12820: gnulib testsuite failure in latest master
On 11/07/2012 06:06 PM, Stefano Lattarini wrote: Let's see if I can reproduce the failure with: $ i=0; while strace -o ut ./test-utimens; do echo RUN $((++i)); done ... Well, I still haven't reproduced it after 47 runs. Nor after 150 runs. I'll stop trying to reproduce it for the moment; I'll get back to this thread if the issue crops up again, or if someone has suggestions about how to (try to) reproduce it. Regards, Stefano
bug#12820: gnulib testsuite failure in latest master
On 11/07/2012 07:28 PM, Paul Eggert wrote:
On 11/07/2012 09:06 AM, Stefano Lattarini wrote:
stat64(test-utimens.ttmp, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
unlink(test-utimens.ttmp) = 0
nanosleep({0, 2000}, NULL) = 0
open(test-utimens.ttmp, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0600) = 3
close(3)= 0
stat64(test-utimens.ttmp, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
unlink(test-utimens.ttmp) = 0
nanosleep({2, 0}, NULL) = 0
Well, there's something funny going on there, as this indicates that
your files' time stamps have only 1-second or even 2-second
resolution. Were you running in a FAT file system or something like
that?
Nope, ext3:
$ pwd
/devel/bleeding/src/coreutils/gnulib-tests
$ df -T .
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/hdb4 ext3 23293824 13885728 9408096 60% /devel
Exact kernel version:
$ uname -r
2.6.30-2-686
(and not custom compiled, but installed from Debian package).
That might explain the problem. If you were running in an
ordinary file system like ext4, the above is a bug and should get
tracked down and fixed.
HTH,
Stefano
bug#12715: [PATCH] build: do not require help2man at build-from-tarball time
On 10/25/2012 04:25 PM, Bernhard Voelker wrote: On 10/25/2012 04:08 PM, Jim Meyering wrote: Bernhard Voelker wrote: Isn't it Due to lack on the build system, ...? I.e. coreutils could be built on system A lacking perl, and then be installed on system B which has perl. The above text would be misleading in this case. Good point. I've merged this in: diff --git a/man/dummy-man b/man/dummy-man index 633a5ba..3069376 100755 --- a/man/dummy-man +++ b/man/dummy-man @@ -56,8 +56,8 @@ cat $output END $progname $bs- a $source program .SH DESCRIPTION .B OOOPS! -Due to lack of perl on your system, the $source build system -failed to create the manual page for +Due to the lack of perl on the build system, we were +unable to create a proper manual page for .B $progname. For concise option descriptions, run .IP Looks good, thanks. Fine by me as well. Thanks, Stefano
bug#12715: coreutils-8.20: bad dependency information with man page generation
Hi Pádraig, Mike. On 10/24/2012 01:48 AM, Pádraig Brady wrote: On 10/23/2012 11:27 PM, Mike Frysinger wrote: if i look at vanilla coreutils-8.20, i see: Makefile.in:man/uname.1: src/uname.c which seems to have originated from man/local.mk, but munged: man/uname.1: src/uname this causes parallel build problems because man/uname.1 generation can get scheduled before src/uname has been linked. easy way to reproduce: ./configure touch src/uname.c make -j ... GENman/uname.1 CC src/hostname.o CC src/uptime.o CC src/kill.o CC src/groups.o GENlib/charset.alias GENlib/ref-add.sed GENlib/ref-del.sed CC lib/set-mode-acl.o CC lib/copy-acl.o CC lib/file-has-acl.o CC lib/allocator.o help2man: can't get '--help' info from man/uname.td/uname CC lib/areadlink.o make[2]: *** [man/uname.1] Error 127 make[2]: *** Waiting for unfinished jobs CC lib/areadlink-with-size.o -mike Ouch. There was a recent commit related to that exact issue which should have fixed this? http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=11d6386 The Makefile.in in my local git repo is correct, i.e. man/uname.1: src/uname whereas in the dist tarball it's man/uname.1: src/uname.c I might get time to investigate some time tomorrow. This issue has already cropped up before, and I think I have managed to diagnose it. See: http://lists.gnu.org/archive/html/coreutils/2012-09/msg00110.html There is also a patch available, but it doesn't seem to have encountered much acceptance unfortunately: http://lists.gnu.org/archive/html/coreutils/2012-09/msg00132.html Regards, Stefano
bug#12715: coreutils-8.20: bad dependency information with man page generation
On 10/24/2012 10:25 AM, Andreas Schwab wrote: Stefano Lattarini stefano.lattar...@gmail.com writes: There is also a patch available, but it doesn't seem to have encountered much acceptance unfortunately: http://lists.gnu.org/archive/html/coreutils/2012-09/msg00132.html The easiest way to solve that is to use order-only dependencies. Which we unfortunately can't do, because they are a GNU make only feature. Regards, Stefano
bug#12715: [PATCH] build: do not require help2man at build-from-tarball time
On 10/24/2012 11:31 AM, Stefano Lattarini wrote: On 10/24/2012 10:54 AM, Jim Meyering wrote: Pádraig Brady wrote: `echo warning; touch $manpage`. Sounds good. I.e., it sounds like we want Stefano's patch, after all. As you recall, a nice side effect is that we will no longer distribute the generated man/*.1 files. Stefano, would you care to rebase your patch? Will do soon. Just give me some time to also re-test it ... Done. The patch is inlined below. Regards, Stefano 88888888888 From 6f35e53d98e6dc0c7843b9e434addf81d901aefa Mon Sep 17 00:00:00 2001 Message-Id: 6f35e53d98e6dc0c7843b9e434addf81d901aefa.1351075054.git.stefano.lattar...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Tue, 11 Sep 2012 20:54:30 +0200 Subject: [PATCH] build: graceful degradation in man pages generation if perl is lacking Fixes coreutils bug#12715. Since commit v8.19-118-g57da212, our 'dist-hook' rule tweaks the distributed Makefile.in so that each man page 'man/foo.1' depends on the corresponding source 'man/foo.c' rather than the corresponding program 'man/foo'. That is done to accommodate inferior systems that, lacking perl, cannot run 'help2man' to regenerate the manpage after its corresponding program has been built. This seems a right and proper graceful degradation, in that the man pages dependencies are still 100% correct in a git checkout, while being laxer but more portable in a distribution tarball. Alas, that is not the case in practice, as it turns out the tweaked Makefile makes the building of man pages unreliable and potentially incorrect! In fact, assume that instead of the correct a dependency: man/ls.1: src/ls we have the laxer one: man/ls.1: src/ls.c and think of what happens if a user modifies, say, 'src/ls.c', and then runs make -j4 to rebuild everything. The make process will see that it has to rebuild the man page 'man/ls.1' (because its prerequisite 'src/ls.c' has changed), but won't see that it has to rebuild 'src/ls' *before* re-running 'help2man' to generate that man page; so, if 'man/ls.1' is rebuilt before 'src/ls' (which can happen with concurrent make), our user will get either a build error (if 'src/ls' did non exist) or, worse, a man page with an up-to-date timestamp but an out-of-date content. And what's even worse in all of this is that this problem will be present also for users who have perl installed: this is not a graceful degradation at all! In our situation, the best and simplest way to implement a graceful degradation it to keep the correct dependencies for man pages (that is, man/ls.1: src/ls), and if perl is not present, just generate dummy man pages reporting that built-time issue and redirecting the user back to either the info documentation or the '--help' output. As a consequence of this change, we also stop distributing man pages, since they would be anyway unconditionally rebuilt * Makefile.am (do-not-require-help2man): Remove. (dist-hook): Don't depend on it. * man/local.mk: Remove an obsolete comment. (EXTRA_DIST): Stop distributing generated man pages. ($(EXTRA_MANS)): This no longer needs to depend on $(all_programs). (MAINTAINERCLEANFILES): $(ALL_MANS) should not be listed here ... (CLEANFILES): ... but here. (.x.1): Instead of warning if perl is missing, but then trying to run 'help2man' unconditionally, simply run ... (run_help2man): ... the command referenced by this new variable, that expands to a proper invocation of 'help2man' if perl is present, and to an invocation of a shell script generating a dummy manpage if it's not. (EXTRA_DIST): Distribute that shell script. * man/dummy-man: Be that shell script --- Makefile.am | 20 + man/dummy-man | 72 +++ man/local.mk | 25 +++-- 3 files changed, 86 insertions(+), 31 deletions(-) create mode 100755 man/dummy-man diff --git a/Makefile.am b/Makefile.am index 0232090..5eaa45b 100644 --- a/Makefile.am +++ b/Makefile.am @@ -93,29 +93,11 @@ BUILT_SOURCES = .version .version: $(AM_V_GEN)echo $(VERSION) $@-t mv $@-t $@ -# In general, we run help2man to build a man page from the binary's --help -# output, but when building from a just-unpacked distribution tarball, we -# must not do that, since help2man uses perl. We don't want to depend on -# perl in that case. In general, the .1 file does indeed depend on the -# binary. I.e., for cat, we have this Makefile dependency: -# man/cat.1: src/cat -# That means that once we build src/cat, we would trigger the .x.1 -# rule which runs help2man. The trick is simply to change the RHS to -# src/cat.c in the $(distdir) that we're about to tar and compress. -# Also handle the three exceptions corresponding to the three binaries -# for which there is no like-named .c file: dir, vdir, ginstall. -.PHONY: do-not-require-help2man -do-not-require-help2man: - perl -pi -e
bug#12715: [PATCH] build: do not require help2man at build-from-tarball time
On 10/24/2012 12:38 PM, Stefano Lattarini wrote: On 10/24/2012 11:31 AM, Stefano Lattarini wrote: On 10/24/2012 10:54 AM, Jim Meyering wrote: Pádraig Brady wrote: `echo warning; touch $manpage`. Sounds good. I.e., it sounds like we want Stefano's patch, after all. As you recall, a nice side effect is that we will no longer distribute the generated man/*.1 files. Stefano, would you care to rebase your patch? Will do soon. Just give me some time to also re-test it ... Done. The patch is inlined below. Yikes, some blunders slipped in. We need at least the following diffs squashed in: -*-*-*- diff --git a/man/dummy-man b/man/dummy-man index cba661c..2e32320 100755 --- a/man/dummy-man +++ b/man/dummy-man @@ -1,5 +1,5 @@ #!/bin/sh -# Poor place holder for help2man invocation on systems lacking perl; +# Poor placeholder for help2man invocation on systems lacking perl; # it generates a dummy manpage stating that as proper manpage could # not be generated, and redirecting the user back to either the info # documentation or the '--help' output. @@ -21,7 +21,7 @@ output= source=GNU coreutils while test $# -gt 0; do case $1 in -# Help2man options we recognize handle. +# Help2man options we recognize and handle. --output=*) output=`expr x$1 : x'--output=\(.*\)'`;; --output) shift; output=$1;; --source=*) source=`expr x$1 : x'--source=\(.*\)'`;; @@ -40,7 +40,7 @@ done test $# -gt 0 || fatal_ missing argument test $# -le 1 || fatal_ too many non-option arguments -baseout=`basename $output` +baseout=`basename_ $output` sed 's/^/WARNING: /' 2 END Cannot create proper man page '$baseout' since perl is missing or inadequate on this system. Will create a stub man page instead. -*-*-*- Here is the updated patch. Sorry for the noise, Stefano 88888888888 From f61dcb763975c1aab299fa9678ea180d70db6acf Mon Sep 17 00:00:00 2001 Message-Id: f61dcb763975c1aab299fa9678ea180d70db6acf.1351075572.git.stefano.lattar...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Tue, 11 Sep 2012 20:54:30 +0200 Subject: [PATCH] build: graceful degradation in man pages generation if perl is lacking Fixes coreutils bug#12715. Since commit v8.19-118-g57da212, our 'dist-hook' rule tweaks the distributed Makefile.in so that each man page 'man/foo.1' depends on the corresponding source 'man/foo.c' rather than the corresponding program 'man/foo'. That is done to accommodate inferior systems that, lacking perl, cannot run 'help2man' to regenerate the manpage after its corresponding program has been built. This seems a right and proper graceful degradation, in that the man pages dependencies are still 100% correct in a git checkout, while being laxer but more portable in a distribution tarball. Alas, that is not the case in practice, as it turns out the tweaked Makefile makes the building of man pages unreliable and potentially incorrect! In fact, assume that instead of the correct a dependency: man/ls.1: src/ls we have the laxer one: man/ls.1: src/ls.c and think of what happens if a user modifies, say, 'src/ls.c', and then runs make -j4 to rebuild everything. The make process will see that it has to rebuild the man page 'man/ls.1' (because its prerequisite 'src/ls.c' has changed), but won't see that it has to rebuild 'src/ls' *before* re-running 'help2man' to generate that man page; so, if 'man/ls.1' is rebuilt before 'src/ls' (which can happen with concurrent make), our user will get either a build error (if 'src/ls' did non exist) or, worse, a man page with an up-to-date timestamp but an out-of-date content. And what's even worse in all of this is that this problem will be present also for users who have perl installed: this is not a graceful degradation at all! In our situation, the best and simplest way to implement a graceful degradation it to keep the correct dependencies for man pages (that is, man/ls.1: src/ls), and if perl is not present, just generate dummy man pages reporting that built-time issue and redirecting the user back to either the info documentation or the '--help' output. As a consequence of this change, we also stop distributing man pages, since they would be anyway unconditionally rebuilt * Makefile.am (do-not-require-help2man): Remove. (dist-hook): Don't depend on it. * man/local.mk: Remove an obsolete comment. (EXTRA_DIST): Stop distributing generated man pages. ($(EXTRA_MANS)): This no longer needs to depend on $(all_programs). (MAINTAINERCLEANFILES): $(ALL_MANS) should not be listed here ... (CLEANFILES): ... but here. (.x.1): Instead of warning if perl is missing, but then trying to run 'help2man' unconditionally, simply run ... (run_help2man): ... the command referenced by this new variable, that expands to a proper invocation of 'help2man' if perl is present, and to an invocation of a shell script generating a dummy manpage if it's not. (EXTRA_DIST): Distribute
bug#12303: [MICROBUG]: gnulib doesn't add lib/spawn.h to .gitignore?
Severity: minor OK, this is a minor annoyance rather than a real bug, but I guess reporting it won't hurt. In GNU coreutils, the gnulib-provided 'bootstrap' script fails to add the generated file 'lib/spawn.h' to the .gitignore in 'lib/': $ ./bootstrap ./configure make ... [all is OK] $ git status ... # Untracked files: # (use git add file... to include in what will be committed) # # lib/spawn.h nothing added to commit but untracked files present (use git add to track) $ grep spawn lib/.gitignore /spawn-pipe.c /spawn-pipe.h /spawn.in.h /spawn_faction_addclose.c /spawn_faction_adddup2.c /spawn_faction_addopen.c /spawn_faction_destroy.c /spawn_faction_init.c /spawn_int.h /spawnattr_destroy.c /spawnattr_init.c /spawnattr_setflags.c /spawnattr_setsigmask.c /spawni.c /spawnp.c /w32spawn.h Since I don't know where the problem might lie (coreutils or gnulib?), and since I have no time to investigate at the moment, I'm reporting the issue to both lists. Regards, Stefano
bug#12225: One test failed on Solaris 10
$ make -j16 check ... FAIL: df/no-mtab-status And the same failure (and only that) takes place if the Sun C compiler is used (version Sun C 5.9 SunOS_i386 Patch 124868-15 2010/08/11). Regards, Stefano
bug#10305: coreutils-8.14, rm -r fails with EBADF
On 07/20/2012 04:42 PM, Joachim Schmitz wrote: First I'd need to get git ported to NonStop, this is on my todolist already. Appare4ny git install needs Python AFAIK, only some non-fundamental programs and features in the Git toolbox need python. Most of git is perfectly usable without python. I don't know more details right away, and have little time to dig them up, sorry. You might try to ask on the Git list for help and guidance, it's usually very responsive and helpful. HTH, Stefano
bug#10305: coreutils-8.14, rm -r fails with EBADF
On 07/20/2012 05:19 PM, Joachim Schmitz wrote: I've been told that git needs python, and in a newer version, for getting it installed. That is false; quoting the comments in the git Makefile: Define NO_PYTHON if you do not want Python scripts or libraries at all. Haven't verified that yet and as having newer version of Python is a good idea anyway, I started looking into that first. Unfortunately there are only 24 hours to a day ;-) Bye, Jojo HTH, Stefano
bug#11933: ambiguous stty --help text
On 07/13/2012 04:22 PM, Michael Stummvoll wrote: Hi, Thanks for pushing this to bug-coreutils. I never thought about this for myself. + [-]parodd set odd parity (or even parity with '-')\n\ another (and maybe clearer) way could be: parodd set odd parity -parodd set even parity but I am not sure, cause it breaks with the notation of all the other options. What about the following? [-]parodd set parity (even parity with '-', odd parity otherwise) Regards, Stefano
bug#11828: [PATCH] doc: fix errors and warnings with Texinfo 5
Or rather, with the development version 4.13.90, which will eventually
become Texinfo 5.0.
Fixes coreutils bug#11828.
* doc/coreutils.texi: Use '@item' instead of '@itemx' in several places,
as Texinfo 5 refuses to process an '@itemx' that is not preceded by an
'@item'. Ensure that node extended names in menus and sectioning are
consistent, and that ordering and presence of nodes in menus and in the
actual text are consistent as well.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
doc/coreutils.texi | 110 ++---
1 file changed, 55 insertions(+), 55 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 751a920..516ec73 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -40,8 +40,8 @@
* cat: (coreutils)cat invocation. Concatenate and write files.
* chcon: (coreutils)chcon invocation. Change SELinux CTX of files.
* chgrp: (coreutils)chgrp invocation. Change file groups.
-* chmod: (coreutils)chmod invocation. Change file permissions.
-* chown: (coreutils)chown invocation. Change file owners/groups.
+* chmod: (coreutils)chmod invocation. Change access permissions.
+* chown: (coreutils)chown invocation. Change file owners and groups.
* chroot: (coreutils)chroot invocation. Specify the root directory.
* cksum: (coreutils)cksum invocation. Print POSIX CRC checksum.
* comm: (coreutils)comm invocation. Compare sorted files by line.
@@ -591,7 +591,7 @@ with embedded newlines.
@end macro
@macro optSi
-@itemx --si
+@item --si
@opindex --si
@cindex SI output
Append an SI-style abbreviation to each size, such as @samp{M} for
@@ -615,7 +615,7 @@ Use the @option{--si} option if you prefer powers of 1000.
@end macro
@macro optStripTrailingSlashes
-@itemx @w{@kbd{--strip-trailing-slashes}}
+@item @w{@kbd{--strip-trailing-slashes}}
@opindex --strip-trailing-slashes
@cindex stripping trailing slashes
Remove any trailing slashes from each @var{source} argument.
@@ -2204,7 +2204,7 @@ between sentences to two spaces.
Fill output lines up to @var{width} characters (default 75 or @var{goal}
plus 10, if @var{goal} is provided).
-@itemx -g @var{goal}
+@item -g @var{goal}
@itemx --goal=@var{goal}
@opindex -g
@opindex --goal
@@ -2702,7 +2702,7 @@ However, if @var{k} starts with a @samp{-},
print all but the last @var{k} bytes of each file.
@multiplierSuffixes{k}
-@itemx -n @var{k}
+@item -n @var{k}
@itemx --lines=@var{k}
@opindex -n
@opindex --lines
@@ -2852,7 +2852,7 @@ This option is the same as @option{--follow=name
--retry}. That is, tail
will attempt to reopen a file when it is removed. Should this fail, tail
will keep trying until it becomes accessible again.
-@itemx --retry
+@item --retry
@opindex --retry
This option is useful mainly when following by name (i.e., with
@option{--follow=name}).
@@ -2860,7 +2860,7 @@ Without this option, when tail encounters a file that
doesn't
exist or is otherwise inaccessible, it reports that fact and
never checks it again.
-@itemx --sleep-interval=@var{number}
+@item --sleep-interval=@var{number}
@opindex --sleep-interval
Change the number of seconds to wait between iterations (the default is 1.0).
During one iteration, every specified file is checked to see if it has
@@ -2873,7 +2873,7 @@ is usually ignored. However, if you also specify
@option{--pid=@var{p}},
@command{tail} checks whether process @var{p} is alive at least
every @var{number} seconds.
-@itemx --pid=@var{pid}
+@item --pid=@var{pid}
@opindex --pid
When following by name or by descriptor, you may specify the process ID,
@var{pid}, of the sole writer of all @var{file} arguments. Then, shortly
@@ -2896,7 +2896,7 @@ terminate until long after the real writer has terminated.
Note that @option{--pid} cannot be supported on some systems; @command{tail}
will print a warning if this is the case.
-@itemx --max-unchanged-stats=@var{n}
+@item --max-unchanged-stats=@var{n}
@opindex --max-unchanged-stats
When tailing a file by name, if there have been @var{n} (default
n=@value{DEFAULT_MAX_N_UNCHANGED_STATS_BETWEEN_OPENS}) consecutive
@@ -2909,7 +2909,7 @@ and when it prints the lines that have accumulated in the
new log file.
This option is meaningful only when polling (i.e., without inotify)
and when following by name.
-@itemx -n @var{k}
+@item -n @var{k}
@itemx --lines=@var{k}
@opindex -n
@opindex --lines
@@ -3034,7 +3034,7 @@ possible without exceeding @var{size} bytes. Individual
lines longer than
@var{size} bytes are broken into multiple files.
@var{size} has the same format as for the @option{--bytes} option.
-@itemx --filter=@var{command}
+@item --filter=@var{command}
@opindex --filter
With this option, rather than simply writing to each output file,
write through a pipe to the specified shell @var{command} for each output file.
@@ -3108,7 +3108,7
bug#11828: Problems building the coreutils info documentation with the development version of makeinfo
Below is the produced diagnostic. Regards, Stefano -*-*-*- coreutils.texi:2207: @itemx must follow @item coreutils.texi:2705: @itemx must follow @item coreutils.texi:2855: @itemx must follow @item coreutils.texi:2863: @itemx must follow @item coreutils.texi:2876: @itemx must follow @item coreutils.texi:2899: @itemx must follow @item coreutils.texi:2912: @itemx must follow @item coreutils.texi:3037: @itemx must follow @item coreutils.texi:3111: @itemx must follow @item coreutils.texi:3133: @itemx must follow @item coreutils.texi:3506: @itemx must follow @item (possibly involving @filesZeroFromOption) coreutils.texi:3687: @itemx must follow @item coreutils.texi:3696: @itemx must follow @item coreutils.texi:3729: @itemx must follow @item coreutils.texi:4132: @itemx must follow @item (possibly involving @filesZeroFromOption) coreutils.texi:6502: @itemx must follow @item coreutils.texi:6871: @itemx must follow @item (possibly involving @optSi) coreutils.texi:7655: @itemx must follow @item coreutils.texi:7785: warning: @itemx should not begin @table coreutils.texi:7787: @itemx must follow @item coreutils.texi:7793: @itemx must follow @item coreutils.texi:7799: @itemx must follow @item coreutils.texi:7823: @itemx must follow @item coreutils.texi:7825: @itemx must follow @item coreutils.texi:7830: @itemx must follow @item coreutils.texi:7846: @itemx must follow @item coreutils.texi:7851: @itemx must follow @item coreutils.texi:7966: @itemx must follow @item (possibly involving @optStripTrailingSlashes) coreutils.texi:8609: @itemx must follow @item coreutils.texi:8759: @itemx must follow @item (possibly involving @optStripTrailingSlashes) coreutils.texi:8830: @itemx must follow @item coreutils.texi:8849: @itemx must follow @item coreutils.texi:8868: @itemx must follow @item coreutils.texi:8876: @itemx must follow @item coreutils.texi:9988: @itemx must follow @item coreutils.texi:10042: @itemx must follow @item coreutils.texi:10049: @itemx must follow @item coreutils.texi:10169: @itemx must follow @item coreutils.texi:10176: @itemx must follow @item coreutils.texi:10291: @itemx must follow @item coreutils.texi:10298: @itemx must follow @item coreutils.texi:10597: @itemx must follow @item coreutils.texi:10671: @itemx must follow @item (possibly involving @optSi) coreutils.texi:10789: @itemx must follow @item coreutils.texi:10841: @itemx must follow @item (possibly involving @filesZeroFromOption) coreutils.texi:10899: @itemx must follow @item (possibly involving @optSi) coreutils.texi:10918: @itemx must follow @item coreutils.texi:10924: @itemx must follow @item coreutils.texi:10934: @itemx must follow @item coreutils.texi:11077: @itemx must follow @item coreutils.texi:12921: @itemx must follow @item coreutils.texi:12928: @itemx must follow @item coreutils.texi:14062: @itemx must follow @item coreutils.texi:14101: @itemx must follow @item coreutils.texi:15307: warning: @itemx should not begin @table coreutils.texi:15314: @itemx must follow @item coreutils.texi:15817: warning: @itemx should not begin @table coreutils.texi:9888: warning: Node next `chown invocation' in menu `touch invocation' and in sectioning `chgrp invocation' differ coreutils.texi:9888: warning: Node `chmod invocation' is prev for `chown invocation' in menu but not in sectioning coreutils.texi:10106: warning: Node `chown invocation' is prev for `chgrp invocation' in sectioning but not in menu coreutils.texi:10229: warning: Node next `chmod invocation' in menu `chown invocation' and in sectioning `touch invocation' differ coreutils.texi:10329: warning: Node prev `touch invocation' in menu `chown invocation' and in sectioning `chmod invocation' differ Makefile:1705: recipe for target 'coreutils.info' failed make[1]: *** [coreutils.info] Error 1 make[1]: Leaving directory '/devel/bleeding/src/coreutils/doc' Makefile:1752: recipe for target 'info-recursive' failed make: *** [info-recursive] Error 1
bug#11829: Build failure with --enable-gcc-warnings
Trying to build the latest coreutils from master: $ make all ... CC stty.o stty.c: In function 'main': stty.c:740:8: error: variable 'speed_was_set' set but not used [-Werror=unused-but-set-variable] cc1: all warnings being treated as errors make[3]: *** [stty.o] Error 1 $ uname -rmos Linux 3.3.1-3.fc16.ppc64 ppc64 GNU/Linux $ gcc --version gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2) Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Let me know if you need more information. Regards, Stefano
bug#11828: Problems building the coreutils info documentation with the development version of makeinfo
On 07/01/2012 12:29 AM, Karl Berry wrote: Hi Stefano, coreutils.texi:2207: @itemx must follow @item I imagine the diagnostic is correct. Sorry if I hasn't been clear, but I meant the CC: to 'texinfo-devel' just as an FYI to you, not a bug report (otherwise I'd have written to bug-texinfo ;-). I thought you might be interested in seeing how your improved diagnostic behaves in the wild. @itemx must follow @item. Otherwise the TeX output is wrong. Previous makeinfo unfortunately did not warn about this. The solution is to fix the manual :). coreutils.texi:9888: warning: Node next `chown invocation' in menu `touch invocation' and in sectioning `chgrp invocation' differ Would have to see the source. Looks like the menus list the nodes in a different order than they actually appear, and/or the master menu (can't remember if coreutils.texi has one) differs from the real menu. k P.S. I took bug-coreutils out of cc simply because I didn't want to deal with opening a bug report (doesn't it require the bug number somewhere to append)? I don't think so; the debbugs software should be smart enough to realize that you're answering to a massage that has already opened a bug report, and it should thus avoid to open a new bug report. I might be wrong on this, though, and I don't feel inclined to experiment right now. Please forward so it does the right thing, if you like. Done. Regards, Stefano
bug#11294: [RFC] build: support and require Automake-NG
On 04/21/2012 11:48 AM, Stefano Lattarini wrote:
* configure.ac (AM_INIT_AUTOMAKE): Add the 'ng' option, to ensure that
mainstream Automake is not used by mistake when bootstrapping. Also,
bump the required Automake version from '1.11.1' to '1.11e', which is
the latest (and still development-only) version of Automake-NG at the
moment of writing.
* bootstrap (check_versions): Hacked to handle automake and aclocal
from Automake-NG specially. This change should be backported to Gnulib
proper in a later step.
* bootstrap.conf ($buildreq): Require automake-ng and aclocal-ng
version = 0.5; don't require mainstream automake anymore.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
I'd like this to be applied to an experimental branch in the coreutils
repository, which will be used to test and experiment with Automake-NG
in a real-world, important, medium-complexity package like GNU coreutils
is.
I hope you'll agree this is a sensible move, which could bring advantages
and improvements to both coreutils and Automake-NG.
I've updated the patch to take into account:
- the recent bump in the Automake-NG version (1.11e = 1.12a);
- the bump in the minimal Autoconf version required by Automake-NG
(2.62 = 2.65);
- the support for Automake-NG recently added to the Gnulib-provided
bootstrap script
- the removal of the m4 macro 'AM_PROG_MKDIR_P' from the master
branch of the Automake repository (and thus from Automake-NG,
where 'master' is regularly merged).
So, OK to apply this patch to a new branch in the coreutils official
repository? Or it's better if I clone the coreutils repo on GitHub
and work there, to have more freedom while experimenting?
Regards,
Stefano
From c71f1ea695ba9ee3ecc6bbaa8136a9dbf6b18df9 Mon Sep 17 00:00:00 2001
Message-Id: c71f1ea695ba9ee3ecc6bbaa8136a9dbf6b18df9.1336489368.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Fri, 20 Apr 2012 13:28:28 +0200
Subject: [PATCH] build: support and require Automake-NG
* configure.ac (AC_PREREQ): Require Autoconf version = 2.65,
since that is the minimal version supported by Automake-NG.
(AM_INIT_AUTOMAKE): Add the 'ng' option, to ensure that mainstream
Automake is not used by mistake when bootstrapping. Also, bump the
required Automake version from '1.11.1' to '1.12a', which is the
latest (and still development-only) version of Automake-NG at the
moment of writing.
* bootstrap: Updated from latest Gnulib. In particular ...
(check_versions): ... this now handles the automake and aclocal
from Automake-NG.
* bootstrap.conf ($buildreq): Require 'automake-ng' and
'aclocal-ng'; don't require mainstream 'automake' anymore.
Bump required 'autoconf' version to 2.65.
* m4/mkdirp-compat.m4: New file, contain a definition of the macro
'AM_PROG_MKDIR_P' (simply as an alias to the Autoconf-provided
macro 'AC_PROG_MKDIR_P'), that is used by the Gettext-provided
macro 'AM_PO_SUBDIRS', but which has been removed in Automake-NG
(as well as in the master branch of mainline Automake).
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
bootstrap | 44
bootstrap.conf |5 +++--
configure.ac|4 ++--
m4/mkdirp-compat.m4 | 24
4 files changed, 69 insertions(+), 8 deletions(-)
create mode 100644 m4/mkdirp-compat.m4
diff --git a/bootstrap b/bootstrap
index c8ee3cc..c496d29 100755
--- a/bootstrap
+++ b/bootstrap
@@ -1,6 +1,6 @@
#! /bin/sh
# Print a version string.
-scriptversion=2012-02-11.09; # UTC
+scriptversion=2012-04-26.13; # UTC
# Bootstrap this package from checked-out sources.
@@ -36,6 +36,10 @@ nl='
LC_ALL=C
export LC_ALL
+# Ensure that CDPATH is not set. Otherwise, the output from cd
+# would cause trouble in at least one use below.
+(unset CDPATH) /dev/null 21 unset CDPATH
+
local_gl_dir=gl
me=$0
@@ -423,12 +427,28 @@ check_versions() {
$use_git || continue
fi
# Honor $APP variables ($TAR, $AUTOCONF, etc.)
-appvar=`echo $app | tr '[a-z]-' '[A-Z]_'`
+appvar=`echo $app | LC_ALL=C tr '[a-z]-' '[A-Z]_'`
test $appvar = TAR appvar=AMTAR
case $appvar in
GZIP) ;; # Do not use $GZIP: it contains gzip options.
*) eval app=\${$appvar-$app} ;;
esac
+
+# Handle the still-experimental Automake-NG programs specially.
+# They remain named as the mainstream Automake programs (automake,
+# and aclocal) to avoid gratuitous incompatibilities with
+# pre-existing usages (by, say, autoreconf, or custom autogen.sh
+# scripts), but correctly identify themselves (as being part of
+# GNU automake-ng) when asked their version.
+case $app in
+ automake-ng|aclocal-ng)
+app=`echo $app | sed 's/-ng$//'`
+($app --version | grep '(GNU automake-ng)') /dev/null 21 || {
+ echo $me: Error: '$app' not found or not from Automake-NG 2
bug#11294: [RFC] build: support and require Automake-NG
Hi Jim, thanks for the feedback. On 05/08/2012 09:57 PM, Jim Meyering wrote: Stefano Lattarini wrote: So, OK to apply this patch to a new branch in the coreutils official repository? Or it's better if I clone the coreutils repo on GitHub and work there, to have more freedom while experimenting? Hi Stefano, The git commit hooks that we use (e.g., to prohibit pushing merge commits) Ugh, why do you do that? might well slow you down: I presume they'd have to be adjusted to permit merge commits or non-ff messiness) on that new branch. As you suggest, using another repository may be better. OK. Here it is: http://github.com/slattarini/coreutils-am-ng If you can confirm that works correctly for you, feel free to close this bug report. Thanks, Stefano
bug#11294: [RFC] build: support and require Automake-NG
* configure.ac (AM_INIT_AUTOMAKE): Add the 'ng' option, to ensure that
mainstream Automake is not used by mistake when bootstrapping. Also,
bump the required Automake version from '1.11.1' to '1.11e', which is
the latest (and still development-only) version of Automake-NG at the
moment of writing.
* bootstrap (check_versions): Hacked to handle automake and aclocal
from Automake-NG specially. This change should be backported to Gnulib
proper in a later step.
* bootstrap.conf ($buildreq): Require automake-ng and aclocal-ng
version = 0.5; don't require mainstream automake anymore.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
I'd like this to be applied to an experimental branch in the coreutils
repository, which will be used to test and experiment with Automake-NG
in a real-world, important, medium-complexity package like GNU coreutils
is.
I hope you'll agree this is a sensible move, which could bring advantages
and improvements to both coreutils and Automake-NG.
Regards,
Stefano
bootstrap | 19 +++
bootstrap.conf |3 ++-
configure.ac |2 +-
3 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/bootstrap b/bootstrap
index c8ee3cc..cc058bd 100755
--- a/bootstrap
+++ b/bootstrap
@@ -429,6 +429,25 @@ check_versions() {
GZIP) ;; # Do not use $GZIP: it contains gzip options.
*) eval app=\${$appvar-$app} ;;
esac
+
+# Special handling for Automake-NG programs. They are still named as
+# the mainstream Automake programs (automake, aclocal) to avoid
+# gratuitous incompatibilities with pre-existing usages (by, say,
+# autoreconf, or custom autogen.sh scripts), but correctly identify
+# themselves (as being part of GNU automake-ng) when asked their
+# version.
+case $app in
+automake-ng|aclocal-ng)
+ app=`echo $app | sed 's/-ng$//'`
+ if ($app --version | grep '(GNU automake-ng)') /dev/null 21; then
+:
+ else
+echo $me: Error: '$app' not found or not from Automake-NG 2
+ret=1
+continue
+ fi ;;
+esac
+
if [ $req_ver = - ]; then
# Merely require app to exist; not all prereq apps are well-behaved
# so we have to rely on $? rather than get_version.
diff --git a/bootstrap.conf b/bootstrap.conf
index bb414ef..a2432aa 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -307,8 +307,9 @@ gnulib_tool_option_extras=--tests-base=gnulib-tests
--with-tests --symlink\
# Build prerequisites
buildreq=\
+automake-ng -
+aclocal-ng -
autoconf 2.62
-automake 1.11.1
autopoint -
bison -
gettext0.17
diff --git a/configure.ac b/configure.ac
index 5a4860e..dab8b07 100644
--- a/configure.ac
+++ b/configure.ac
@@ -32,7 +32,7 @@ AC_CONFIG_SRCDIR([src/ls.c])
AC_CONFIG_AUX_DIR([build-aux])
AC_CONFIG_HEADERS([lib/config.h:lib/config.hin])
-AM_INIT_AUTOMAKE([1.11.1 no-dist-gzip dist-xz color-tests parallel-tests])
+AM_INIT_AUTOMAKE([1.11e ng no-dist-gzip dist-xz color-tests parallel-tests])
AM_SILENT_RULES([yes]) # make --enable-silent-rules the default.
dnl POSIXCHECK is worthwhile for maintainers, but adds several seconds
--
1.7.9.5
bug#11289: [PATCH] maint: fix bootstrap-time requirement on autoconf version
* bootstrap.conf ($buildreq): Require autoconf 2.64, not 2.62. This is consistent with what is required by AC_PREREQ in configure.ac. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- bootstrap.conf |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bootstrap.conf b/bootstrap.conf index bb414ef..41b9cc2 100644 --- a/bootstrap.conf +++ b/bootstrap.conf @@ -307,7 +307,7 @@ gnulib_tool_option_extras=--tests-base=gnulib-tests --with-tests --symlink\ # Build prerequisites buildreq=\ -autoconf 2.62 +autoconf 2.64 automake 1.11.1 autopoint - bison - -- 1.7.9.5
bug#10819: [BUG][RM]
Hi Eric. On 02/16/2012 04:28 PM, Eric Blake wrote: You can always use 'rm -rf dummy $file_list' without having to check for whether $file_list is empty, but yes, that is the primary reasoning why -f with no options behaves differently than any other case with no options. FYI: I just opened a POSIX bug report, asking that this usage be codified (since everyone that I tested already does it): http://austingroupbugs.net/view.php?id=542 Still, I vaguely recall that there are some 'rm' implementations out there which fails upon rm -f (with no arguments); and that's why automake uses the ugly idiom: test -z $(VAR) || rm -f $(VAR) in a lot of recipes. Now, I can't tell off-hand which systems those were, nor if they actually exist (and in fact I'd *love* to be proven wrong here, so that we could simplify a bunch of automake recipes); but a more extensive probing is needed in this matter I guess. And if you are right (as I hope), then this 'rm' feature could be documented in the Autoconf manual. Regards, Stefano
bug#10819: POSIX will say running rm -f with no argument is OK
Severity: wishlist [CC:ing bug-automake, so that we won't forget about this issue] Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10819#40 POSIX will say in a future version that running rm -f with no argument is OK; we might simplify several automake-generated cleaning rules accordingly, to get rid of the awful idiom: test -z $(VAR) || rm -f $(VAR) On 02/16/2012 08:15 PM, Philip Rowlands wrote: On 16/02/2012 18:58, Eric Blake wrote: so that we could simplify a bunch of automake recipes); but a more extensive probing is needed in this matter I guess. And if you are right (as I hope), then this 'rm' feature could be documented in the Autoconf manual. Yep, I think that's appropriate, as it is unlikely that we will come up with any counterexamples any time soon. As the now-POSIX-infringing behaviour is simple to detect, couldn't automake detect it early and die with a helpful message, or is that contrary to its philosophy? Well, that might be an overkill, since it appears that all the non-museum implementations of 'rm' have the behaviour we want. But I agree that, in case we ever stumble upon a system violating this new expectation, adding proper configure-time probing and warning might be helpful (and might convince the users of such an inferior system to start using GNU coreutils). Regards, Stefano
bug#10427: bug#10436: New testsuite driver and extra trailing backslash in recipes
On 01/05/2012 02:08 PM, Stefano Lattarini wrote: On 01/05/2012 01:47 PM, Stefano Lattarini wrote: [adding bug-automake in CC:] Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=104367#8 And here is the definitive version of the patch that I'll push by this evening (to master) if there is no objection. Pushed now. Regards, Stefano
bug#10427: New testsuite driver and extra trailing backslash in recipes (was: Re: bug#10427: coreutils-8.14.116-1e18d: testsuite failures on NetBSD 5.1)
[adding bug-automake in CC:] Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10427#8 Hi Paul, thanks for the report and diagnosis. On 01/05/2012 10:00 AM, Paul Eggert wrote: I'm sending this to bug-automake because I think it's an automake issue. However, the problem causes the latest coreutils snapshot to fail to build, so I'm CC'ing to bug-coreutils. On 01/03/2012 06:10 PM, Jim Meyering wrote: FYI, here's a snapshot of what will soon be coreutils-8.15, expected on Thursday or Friday. coreutils snapshot: http://meyering.net/cu/coreutils-ss.tar.xz 5.2 MB http://meyering.net/cu/coreutils-ss.tar.xz.sig http://meyering.net/cu/coreutils-8.14.116-1e18d.tar.xz This snapshot doesn't build on Solaris 8 (sparc) with native tools, for a couple of reasons. I don't expect Solaris 8 is an active porting target any more, but these problems could well happen on active targets. I agree that this issues might prove a liability on some modern systems too, and that we should fix them. (BTW, if you feel like running the whole automake testsuite on Solaris 8 to find more similar issues, I wouldn't object ;-) First, there's code like this in tests/Makefile.in: $(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS) $(LOG_DRIVER_FLAGS) -- $(LOG_COMPILE) $$tst \ $(AM_TESTS_FD_REDIRECT) This code is generated by Automake. Here, AM_TESTS_FD_REDIRECT is empty. Solaris 8 'make' executes the above as follows: bash -c '[expansion of previous line] \' and Bash complains about a syntax error with the trailing backslash. I can reproduce this with bash 2.05b on Debian. Attached is a fix for this bug, with a testcase. The test is quite elaborate and somewhat hacky, but I'd rather keep it anyway, since I'm planning to refactor it into an external helper script that will be used to guard against other unwanted trailing `\' in *all* the make recipes run in the automake testsuite (that's for a follow-up patch obviously). How about changing Automake to generate something like this instead, with no backslash-newline? $(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS) $(LOG_DRIVER_FLAGS) -- $(LOG_COMPILE) $$tst $(AM_TESTS_FD_REDIRECT) This should avoid the problem. I ended up breaking the line in a safer place instead. It is enough to fix the bug. Regards, Stefano From 7902852607b596d1a341501d1823da826fb4b4ed Mon Sep 17 00:00:00 2001 Message-Id: 7902852607b596d1a341501d1823da826fb4b4ed.1325767602.git.stefano.lattar...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Thu, 5 Jan 2012 13:41:13 +0100 Subject: [PATCH] parallel-tests: avoid trailing backslashes in make recipes The new testsuite-harness could generate recipes with a trailing backslash character (possibly followed by blank characters only), in the very common case where the user hadn't defined the special $(AM_TESTS_FD_REDIRECT) variable. This caused spurious syntax errors with at least older bash versions (e.g., bash 2.05b), and could be potentially unportable to other weaker shells. See automake bug#xxx: xxx and coreutils bug#10427: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10427#8 * lib/am/check2.am: Rework line breaks so that no backslash can be at the end of a line. * tests/parallel-tests-trailing-bslash.test: New test. * tests/list-of-tests.mk: Add it. --- lib/am/check2.am | 10 +- tests/list-of-tests.mk|1 + tests/parallel-tests-trailing-bslash.test | 115 + 3 files changed, 121 insertions(+), 5 deletions(-) create mode 100755 tests/parallel-tests-trailing-bslash.test diff --git a/lib/am/check2.am b/lib/am/check2.am index ad0a4aa..9a0fe9d 100644 --- a/lib/am/check2.am +++ b/lib/am/check2.am @@ -1,5 +1,5 @@ ## automake - create Makefile.in from Makefile.am -## Copyright (C) 2008, 2009, 2011 Free Software Foundation, Inc. +## Copyright (C) 2008, 2009, 2011, 2012 Free Software Foundation, Inc. ## This program is free software; you can redistribute it and/or modify ## it under the terms of the GNU General Public License as published by @@ -19,8 +19,8 @@ ?!GENERIC?%OBJ%: %SOURCE% @p='%SOURCE%'; $(am__check_pre) %DRIVER% --test-name $$f \ --log-file '%BASE%.log' --trs-file '%BASE%.trs' \ - $(am__common_driver_flags) %DRIVER_FLAGS% -- %COMPILE% $$tst \ - $(AM_TESTS_FD_REDIRECT) + $(am__common_driver_flags) %DRIVER_FLAGS% -- %COMPILE% \ + $$tst $(AM_TESTS_FD_REDIRECT) ## If no programs are built in this package, then this rule is removed ## at automake time. Otherwise, %am__EXEEXT% expands to a configure time @@ -30,6 +30,6 @@ if %am__EXEEXT% ?GENERIC?%EXT%$(EXEEXT).log: @p='%SOURCE%'; $(am__check_pre) %DRIVER% --test-name $$f \ --log-file '%BASE%.log' --trs-file '%BASE%.trs' \ - $(am__common_driver_flags) %DRIVER_FLAGS% -- %COMPILE% $$tst \ - $(AM_TESTS_FD_REDIRECT) + $(am__common_driver_flags) %DRIVER_FLAGS% -- %COMPILE% \ + $$tst $(AM_TESTS_FD_REDIRECT
bug#10427: parallel-tests: `recheck' recipe can cause sed to be invoked with too long input lines (was: Re: bug#10427: coreutils-8.14.116-1e18d: testsuite failures on NetBSD 5.1)
[adding bug-automake in CC:] Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10427#8 Hi Paul, thanks for the report and diagnosis. On 01/05/2012 10:00 AM, Paul Eggert wrote: The latest coreutils snapshot fail to build On 01/03/2012 06:10 PM, Jim Meyering wrote: FYI, here's a snapshot of what will soon be coreutils-8.15, expected on Thursday or Friday. coreutils snapshot: http://meyering.net/cu/coreutils-ss.tar.xz 5.2 MB http://meyering.net/cu/coreutils-ss.tar.xz.sig http://meyering.net/cu/coreutils-8.14.116-1e18d.tar.xz This snapshot doesn't build on Solaris 8 (sparc) with native tools, for a couple of reasons. I don't expect Solaris 8 is an active porting target any more, but these problems could well happen on active targets. I agree. Second, there's code like this in tests/Makefile.in: @list='$(TEST_LOGS)'; \ list=`for i in $$list; do \ test .log = $$i || echo $$i; \ done | tr '\012\015' ' '`; \ list=`echo $$list | sed 's/ *$$//'`; \ This generates a long line and sends it to 'sed', which complains Output line too long. and outputs nothing. And if I'm not mistaken, sed is allowed such a behaviour by POSIX, so this is a portability problem in automake. This code is also generated by Automake. How about changing Automake to generate something like this instead? @test_logs='$(TEST_LOGS)'; \ list=; \ for i in $$test_logs; do \ test .log = $$i || list=$$list $$i; \ done; \ This avoids the business with echo and tr and ` sed and avoids the sed limitation with long lines. Good idea. I will followed your idea (with some tweaks). Patch coming up soon. Automake does this latter sort of thing in about 4 places, Which sort of thing exactly? I could find only one place which suffers of the problem you've pointed out, i.e., the `recheck recheck-html' rules in lib/am/check.am. Am I missing something? and I figure it's done that way for a reason, but I don't know what the reason is. The comments in lib/am/check.am should be explicative enough. if not, that's a (minor) bug, so feel free to report it! Thanks, Stefano
bug#10427: bug#10437: parallel-tests: `recheck' recipe can cause sed to be invoked with too long input lines
Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10437 On 01/05/2012 03:07 PM, Stefano Lattarini wrote: Patch coming up soon. And here it is. I will push by this evening if there is no objection. Regards, Stefano From e3b0e12400f5fa4220fc0aa79dd0989e56def9c6 Mon Sep 17 00:00:00 2001 Message-Id: e3b0e12400f5fa4220fc0aa79dd0989e56def9c6.1325772813.git.stefano.lattar...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Thu, 5 Jan 2012 15:13:30 +0100 Subject: [PATCH] parallel-tests: avoid issue with overly long lines in sed input See automake bug#10437: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10437 and coreutils bug#10427: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10427#8 * lib/am/check.am (recheck, recheck-html): In order to strip trailing whitespace from the definition of the `$list' variable, we used to invoke sed in a way that could cause it to get passed overly long input lines, causing spurious failures. So rework the logic of the recipe to avoid any sed invocation, relying on simpler shell idioms instead. (check-TESTS): Reorganize the recipe to be more similar to the one of `recheck', for consistency and simplicity. * NEWS: Update. Report and analysis by Paul Eggert. --- NEWS|4 lib/am/check.am | 38 +- 2 files changed, 25 insertions(+), 17 deletions(-) diff --git a/NEWS b/NEWS index 2e572e4..7e52d83 100644 --- a/NEWS +++ b/NEWS @@ -89,6 +89,10 @@ Bugs fixed in 1.11.0a: * Bugs introduced by 1.11: + - The parallel-tests harness doesn't trip anymore on sed implementations +with stricter limits on the length of input lines (problem seen at +least on Solaris 8). + - The `parallel-tests' test driver works around a GNU make 3.80 bug with trailing white space in the test list (`TESTS = foo $(EMPTY)'), and does not report spurious successes when used with concurrent FreeBSD diff --git a/lib/am/check.am b/lib/am/check.am index 3d0188d..29faa38 100644 --- a/lib/am/check.am +++ b/lib/am/check.am @@ -245,15 +245,16 @@ check-TESTS: ## OTOH, this means that, in the rule for `$(TEST_SUITE_LOG)', we ## cannot use `$?' to compute the set of lazily rerun tests, lest ## we rely on .PHONY to work portably. -## + @test -z $(TEST_SUITE_LOG) || rm -f $(TEST_SUITE_LOG) + @list='' list2='$(TEST_LOGS)'; for f in $$list2; do \ ## Trailing whitespace in `TESTS = foo.test $(empty)' causes GNU make ## 3.80 to erroneously expand $(TESTS_LOGS) to `foo.log .log'. ## Work around this bug. - @test -z $(TEST_SUITE_LOG) || rm -f $(TEST_SUITE_LOG) - @list='$(TEST_LOGS)'; \ - list=`for f in $$list; do \ - test .log = $$f || echo $$f; \ - done | tr '\012\015' ' '`; \ + test .log = $$f continue; \ +## Be careful to avoid extra whitespace in the definition of $list. See +## comments in `recheck' below for why this might be useful. + if test -z $$list; then list=$$f; else list=$$list $$f; fi; \ + done; \ $(MAKE) $(AM_MAKEFLAGS) $(TEST_SUITE_LOG) TEST_LOGS=$$list AM_RECURSIVE_TARGETS += check @@ -298,17 +299,20 @@ AM_RECURSIVE_TARGETS += check-html ## Rerun all FAILed or XPASSed tests. recheck recheck-html: - @target=`echo $@ | sed 's,^re,,'`;\ - list='$(TEST_LOGS)'; \ - list=`for f in $$list; do \ - test -f $$f || continue;\ - if test -r $$f read line $$f; then \ - case $$line in FAIL*|XPASS*) echo $$f;; esac; \ - else echo $$f; fi; \ - done | tr '\012\015' ' '`;\ -## This apparently useless munging helps to avoid a nasty bug (a -## segmentation fault!) on Solaris XPG4 make. - list=`echo $$list | sed 's/ *$$//'`;\ + @target=`echo $@ | sed 's,^re,,'`; \ + list='' list2='$(TEST_LOGS)'; for f in $$list2; do \ + test -f $$f || continue; \ + if test -r $$f read line $$f; then \ + case $$line in FAIL*|XPASS*) : ;; *) continue;; esac; \ + fi; \ +## Be careful to avoid extra whitespace in the definition of $list, since +## its value will be passed to the recursive make invocation below through +## the TEST_LOGS macro, and leading/trailing white space in a make macro +## definition can be problematic. In this particular case, trailing white +## space was known to cause a segmentation fault on Solaris 10 XPG4 make: +## http://lists.gnu.org/archive/html/bug-automake/2010-08/msg4.html + if test -z $$list; then list=$$f; else list=$$list $$f; fi; \ + done; \ $(MAKE) $(AM_MAKEFLAGS) $$target AM_MAKEFLAGS='$(AM_MAKEFLAGS) TEST_LOGS='$$list'' .PHONY: recheck recheck-html -- 1.7.7.3
bug#10427: bug#10437: parallel-tests: `recheck' recipe can cause sed to be invoked with too long input lines
On 01/05/2012 07:06 PM, Paul Eggert wrote: On 01/05/12 06:07, Stefano Lattarini wrote: Which sort of thing exactly? I could find only one place which suffers of the problem you've pointed out, i.e., the `recheck recheck-html' rules in lib/am/check.am. Am I missing something? Sorry, that appears to have been a miscount on my part: I was counting some files that Automake generates for itself while building. In Automake source there are only two instances, which your patch caught: the 'recheck recheck-html' rule and the 'check-TESTS' rule (the latter is what actually triggered the problem with coreutils). Wait, the `check-TESTS' rules didn't use any sed invocation, so it wouldn't make sense for it to trip for a sed failure ... What am I missing? Thanks, Stefano
bug#10427: bug#10437: parallel-tests: `recheck' recipe can cause sed to be invoked with too long input lines
On 01/05/2012 07:24 PM, Stefano Lattarini wrote: On 01/05/2012 07:06 PM, Paul Eggert wrote: On 01/05/12 06:07, Stefano Lattarini wrote: Which sort of thing exactly? I could find only one place which suffers of the problem you've pointed out, i.e., the `recheck recheck-html' rules in lib/am/check.am. Am I missing something? Sorry, that appears to have been a miscount on my part: I was counting some files that Automake generates for itself while building. In Automake source there are only two instances, which your patch caught: the 'recheck recheck-html' rule and the 'check-TESTS' rule (the latter is what actually triggered the problem with coreutils). Wait, the `check-TESTS' rules didn't use any sed invocation, so it wouldn't make sense for it to trip for a sed failure ... What am I missing? I will answer myself: I was missing the fact that such a sed invocation had been added to check-TESTS, *but in master only*. Anyway, the maint - master merge will take care of everything. Thanks, and sorry for the noise, Stefano
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
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#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#8887: Automake patches for custom test drivers' support break coreutils testsuite
On Saturday 18 June 2011, Jim Meyering wrote:
Stefano Lattarini wrote:
[Adding bug-coreutils]
Reference:
http://lists.gnu.org/archive/html/automake-patches/2011-06/msg00093.html
On Friday 17 June 2011, Ralf Wildenhues wrote:
I generally like the direction this is taking. The point of best
separation between which code goes into Makefile.in and which into
the driver scripts can be fine-tuned when we have more than one such
script.
Actually, yes, before deciding on this for real I really do want to see
a nontrivial other driver script. There is no point in hardcoding
too much in several driver scripts if it all needs to be the same
anyway.
Please measure the time overhead your changes introduce into the current
code, for a trivial testsuite (say, 50 tests running 'true'), and a
nontrivial one like Automake's and one with faster tests.
I've tried the coreutils testsuite and ... Ouch! That gets broken
by my patches :-(
Thank you for trying with coreutils before committing them.
Note that they'll be commmited to a dedicated branch before being merged
into master, so even if you're using the developement version of automake
with coreutils you should be safe even in case of other breakage (that
is, until the merge to master takes place).
That's due to the overly complex TESTS_ENVIRONMENT employed by
conreutils' tests/Makefile.am:
TESTS_ENVIRONMENT = \
. $(srcdir)/lang-default; \
tmp__=$${TMPDIR-/tmp};\
test -d $$tmp__ test -w $$tmp__ || tmp__=.;\
. $(srcdir)/envvar-check; \
TMPDIR=$$tmp__; export TMPDIR;\
shell_or_perl_() {\
if grep '^\#!/usr/bin/perl' $$1 /dev/null; then \
if $(PERL) -e 'use warnings' /dev/null 21; then \
grep '^\#!/usr/bin/perl -T' $$1 /dev/null T_=T || T_=; \
$(PERL) -w$$T_ -I$(srcdir) -MCoreutils -MCuSkip \
-MCuTmpdir qw($$f) -- $$1;\
else \
echo 12 $$tst: configure did not find a usable version of Perl,
\
...
In order to work with the upcoming new Automake testsuite harness, coreutils
have two possibilities:
1. move the `shell_or_perl_' subroutine's functionality into a real acript,
and define the LOG_COMPILER to point to it; or
2. add a `.pl' extension to the perl test scripts, and define
PL_LOG_COMPILER
appropriately (might be a little tricky, considering the hops that the
`shell_or_perl_' subroutine goes through in order to get the flags and
imports right).
1) sounds preferable.
But it has a serious drawback: the redirection `92' placed at the end
of TESTS_ENVIRONMENT will be rendered useless by the final exec done
in the new `shell_or_perl' script (at least for with shells using the
`cloexec' flag on fds 2); this will bring back the problems fixed by
commit `v8.12-82-g6b68745' :-(
So I now think we should go with solution (2).
I should have have an FSF copyright assignement in place for coreutils too,
Confirmed.
so I can volounteer to write a fix for this situation, if no one wants to
beat me.
I won't say no ;-)
Thanks for volunteering.
Regards,
Stefano
bug#8888: [PATCH] maint: fix typos in comment in configure.ac
A tiny silly cosmetic patch. I post it here because I couldn't find a coreutils-patches list; I hope it's ok, and if not, sorry in advance. Regards, Stefano From cfa243dbd91058969499194ae3fcea4453ab9664 Mon Sep 17 00:00:00 2001 Message-Id: cfa243dbd91058969499194ae3fcea4453ab9664.1308395039.git.stefano.lattar...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Sat, 18 Jun 2011 13:03:54 +0200 Subject: [PATCH] maint: fix typos in comment in configure.ac * configure.ac ($MAN): Fix typos in explicative comments. --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 2e45f84..b6a1007 100644 --- a/configure.ac +++ b/configure.ac @@ -419,7 +419,7 @@ esac MAN=`echo $optional_bin_progs |sed 's/ /.1 /g;s/ $//'|tr -d '\\015\\012'` -# Change ginstall.1 to install.h in $MAN. +# Change ginstall.1 to install.1 in $MAN. MAN=`for m in $MAN; do test $m = ginstall.1 m=install.1; echo $m; done \ | tr '\015\012' ' '; echo` -- 1.7.2.3
bug#8892: distcheck failure from master
Running make distcheck from the latest git version of autoconf, I get this error: ... [LOTS OF OUTPUT SNIPPED] redundant_const 0.12 redundant_const require_config_h 0.07 require_config_h require_config_h_first 1.02 require_config_h_first require_stdio_safer 0.11 require_stdio_safer require_test_exit_idiom 0.01 require_test_exit_idiom root_tests 0.10 root_tests space_before_open_paren 2.93 space_before_open_paren space_tab 0.10 space_tab strftime_check --- sc_strftime_check-src 2011-06-18 19:08:06.0 +0200 +++ sc_strftime_check-info 2011-06-18 19:08:10.0 +0200 @@ -1,42 +1 @@ -% -A -B -C -D -F -G -H -I -M N -P -R -S -T -U -V -W -X -Y -Z -a -b -c -d -e -g -h -j -k -l -m -n -p -r -s -t -u -w -x -y -z cfg.mk:202: recipe for target `sc_strftime_check' failed make[3]: *** [sc_strftime_check] Error 1 make[3]: Leaving directory `/devel/bleeding/src/coreutils' dist-check.mk:148: recipe for target `my-distcheck' failed make[2]: *** [my-distcheck] Error 2 make[2]: Leaving directory `/devel/bleeding/src/coreutils' Makefile:1909: recipe for target `distcheck-hook' failed make[1]: *** [distcheck-hook] Error 2 make[1]: Leaving directory `/devel/bleeding/src/coreutils' Makefile:1691: recipe for target `distcheck' failed make: *** [distcheck] Error 1 Regards, Stefano
bug#8893: [PATCH 1/2] tests: make test runner a script, not a shell function (was: Automake patches for custom test drivers' support break coreutils testsuite)
On Saturday 18 June 2011, Jim Meyering wrote:
Stefano Lattarini wrote:
...
In order to work with the upcoming new Automake testsuite harness,
coreutils
have two possibilities:
1. move the `shell_or_perl_' subroutine's functionality into a real
acript,
and define the LOG_COMPILER to point to it; or
2. add a `.pl' extension to the perl test scripts, and define
PL_LOG_COMPILER
appropriately (might be a little tricky, considering the hops that
the
`shell_or_perl_' subroutine goes through in order to get the flags
and
imports right).
1) sounds preferable.
But it has a serious drawback: the redirection `92' placed at the end
of TESTS_ENVIRONMENT will be rendered useless by the final exec done
in the new `shell_or_perl' script (at least for with shells using the
`cloexec' flag on fds 2); this will bring back the problems fixed by
commit `v8.12-82-g6b68745' :-(
Well, no, that's not true; the problematic shells only set the 'close-on-exec'
flag on the file descriptors they themselves create, not on the ones they
inherit
from their parents:
$ ksh -c 'exec 91; sh -c echo foo 9'
sh: 9: Bad file descriptor
$ ksh -c 'sh -c echo foo 9' 91
foo
$ (exec 91; ksh -c 'sh -c echo foo 9')
foo
I should have tested better before reporting an imaginary problem.
So I now think we should go with solution (2).
Ok.
I've gone with the less invasive solution (1) instead. See the attached
patch. I will soon post a follow up that tries to compensate for the
extra forks I've introduced here by removing a couple of grep calls from
the `shell-or-perl' script (this is for Cygwin, I know that the overhead
on Unix is utterly irrelevant).
Regards,
Stefano
From e4dd05df8ea1f0fc99649627f895a76ec776279a Mon Sep 17 00:00:00 2001
Message-Id: e4dd05df8ea1f0fc99649627f895a76ec776279a.1308418725.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Sat, 18 Jun 2011 10:26:15 +0200
Subject: [PATCH 1/2] tests: make test runner a script, not a shell function
This changes implements a more correct and idiomatic use of the
features of the Automake-provided 'parallel-tests' harness.
Moreover, this change is required in order for the testsuite to
continue to work with the new testsuite harness that is planned
to be introduced in Automake 1.12 (which, as of the writing date,
is still under development and in alpha state).
* tests/shell-or-perl: New auxiliary script.
* tests/Makefile.am (EXTRA_DIST): Distribute it.
* tests/check.mk (TESTS_ENVIRONMENT): Remove definition of the
`shell_or_perl_' shell function, whose code has been moved in
the new script above (with few improvements and extensions). Do
not use it to run the test scripts.
(LOG_COMPILER): New, properly invoking `shell-or-perl'.
---
tests/Makefile.am |1 +
tests/check.mk | 27 +---
tests/shell-or-perl | 111 +++
3 files changed, 123 insertions(+), 16 deletions(-)
create mode 100644 tests/shell-or-perl
diff --git a/tests/Makefile.am b/tests/Makefile.am
index a324dc1..f8fbd38 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -20,6 +20,7 @@ EXTRA_DIST = \
other-fs-tmpdir \
require-perl \
sample-test \
+ shell-or-perl \
$(pr_data)
root_tests = \
diff --git a/tests/check.mk b/tests/check.mk
index 9db96af..d45c288 100644
--- a/tests/check.mk
+++ b/tests/check.mk
@@ -48,6 +48,16 @@ check-am: .built-programs
MAKEFLAGS= $(MAKE) -s built_programs.list) \
$@-t mv $@-t $@
+## `$f' is set by the Automake-generated test harness to the path of the
+## current test script stripped of VPATH components, and is used by the
+## shell-or-perl script to determine the name of the temporary files to be
+## used. Note that $f is a shell variable, not a make macro, so the use of
+## `$$f' below is correct, and not a typo.
+LOG_COMPILER = \
+ $(SHELL) $(srcdir)/shell-or-perl \
+ --test-name $$f --srcdir '$(srcdir)' \
+ --shell '$(SHELL)' --perl '$(PERL)' --
+
# Note that the first lines are statements. They ensure that environment
# variables that can perturb tests are unset or set to expected values.
# The rest are envvar settings that propagate build-related Makefile
@@ -58,21 +68,6 @@ TESTS_ENVIRONMENT =\
test -d $$tmp__ test -w $$tmp__ || tmp__=.; \
. $(srcdir)/envvar-check; \
TMPDIR=$$tmp__; export TMPDIR; \
- shell_or_perl_() {\
-if grep '^\#!/usr/bin/perl' $$1 /dev/null; then \
- if $(PERL) -e 'use warnings' /dev/null 21; then \
- grep '^\#!/usr/bin/perl -T' $$1 /dev/null T_=T || T_=; \
-$(PERL) -w$$T_ -I$(srcdir) -MCoreutils -MCuSkip \
- -MCuTmpdir qw($$f) -- $$1; \
- else \
- echo 12 $$tst: configure did not find a usable version of Perl, \
- so skipping this test; \
- (exit 77);\
- fi; \
-else \
- $(SHELL) $$1;\
-fi
bug#8893: [PATCH 1/2] tests: make test runner a script, not a shell function (was: Automake patches for custom test drivers' support break coreutils testsuite)
On Saturday 18 June 2011, Stefano Lattarini wrote:
On Saturday 18 June 2011, Jim Meyering wrote:
Stefano Lattarini wrote:
...
In order to work with the upcoming new Automake testsuite harness,
coreutils
have two possibilities:
1. move the `shell_or_perl_' subroutine's functionality into a real
acript,
and define the LOG_COMPILER to point to it; or
2. add a `.pl' extension to the perl test scripts, and define
PL_LOG_COMPILER
appropriately (might be a little tricky, considering the hops that
the
`shell_or_perl_' subroutine goes through in order to get the flags
and
imports right).
1) sounds preferable.
But it has a serious drawback: the redirection `92' placed at the end
of TESTS_ENVIRONMENT will be rendered useless by the final exec done
in the new `shell_or_perl' script (at least for with shells using the
`cloexec' flag on fds 2); this will bring back the problems fixed by
commit `v8.12-82-g6b68745' :-(
Well, no, that's not true; the problematic shells only set the
'close-on-exec'
flag on the file descriptors they themselves create, not on the ones they
inherit
from their parents:
$ ksh -c 'exec 91; sh -c echo foo 9'
sh: 9: Bad file descriptor
$ ksh -c 'sh -c echo foo 9' 91
foo
$ (exec 91; ksh -c 'sh -c echo foo 9')
foo
I should have tested better before reporting an imaginary problem.
So I now think we should go with solution (2).
Ok.
I've gone with the less invasive solution (1) instead. See the attached
patch. I will soon post a follow up that tries to compensate for the
extra forks I've introduced here by removing a couple of grep calls from
the `shell-or-perl' script
Here it is.
Regards,
Stefano
From bb3cbef9eece619dd694a60e5a738e71e939f9aa Mon Sep 17 00:00:00 2001
Message-Id: bb3cbef9eece619dd694a60e5a738e71e939f9aa.1308420965.git.stefano.lattar...@gmail.com
In-Reply-To: e4dd05df8ea1f0fc99649627f895a76ec776279a.1308420965.git.stefano.lattar...@gmail.com
References: e4dd05df8ea1f0fc99649627f895a76ec776279a.1308420965.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Sat, 18 Jun 2011 17:57:53 +0200
Subject: [PATCH 2/2] tests: avoid extra forks in the testsuite
* tests/shell-or-perl: Prefer the `read' builtin over `grep' to
look at the shebang line of test scripts. Since `read' is a
special builtin, it might abort the whole program upon failures,
so add extra sanity checks, verifying that the test script exists
and is readable, before trying to read from it.
---
tests/shell-or-perl | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/tests/shell-or-perl b/tests/shell-or-perl
index ff92009..8c92f87 100644
--- a/tests/shell-or-perl
+++ b/tests/shell-or-perl
@@ -84,12 +84,19 @@ test -z $test_name test_name=$test_script
# Run the test script #
# - #
-if grep '^#!/usr/bin/perl' $test_script /dev/null; then
+test -f $test_script test -r $test_script \
+ || error_ test script '$test_script' does not exist, or isn't readable
+
+read shebang_line $test_script \
+ || error_ cannot read from the test script '$test_script'
+
+case $shebang_line in
+'#!/usr/bin/perl'*)
# The test is a perl script.
if $cu_PERL -e 'use warnings' /dev/null 21; then
# Perl is available, see if we must run the test with taint
# mode on or not.
-grep '^#!/usr/bin/perl -T' $test_script /dev/null T_=T || T_=
+case $shebang_line in *\ -T*) T_=T;; *) T_=;; esac
# Now run it.
exec $cu_PERL -w$T_ -I$srcdir -MCoreutils -MCuSkip \
-MCuTmpdir qw($test_name) \
@@ -99,10 +106,11 @@ if grep '^#!/usr/bin/perl' $test_script /dev/null; then
echo $test_name: skip: no usable version of Perl found
exit 77
fi
-else
+ ;;
+*)
# Assume the test is a shell script.
exec $cu_SHELL $test_script ${1+$@}
-fi
+esac
# - #
# Not reached #
--
1.7.2.3
bug#8886: duplicate names in THANKS?
OK, this is just a silly cosmetic issue, but maybe you'd like to know about it anyway: $ make THANKS GENTHANKS ./thanks-gen: THANKS.in: duplicate name: Karl Berry ./thanks-gen: THANKS.in: duplicate name: Karl Heuer ./thanks-gen: THANKS.in: duplicate name: Stéphane Raimbault $ grep 'Karl Berry' THANKS Karl Berry k...@freefriends.org Karl Berry k...@gnu.org Regards, Stefano
bug#8887: Automake patches for custom test drivers' support break coreutils testsuite (was: Re: [PATCH v4 1/3] parallel-tests: add auxiliary script 'pt-driver', refactor)
[Adding bug-coreutils]
Reference:
http://lists.gnu.org/archive/html/automake-patches/2011-06/msg00093.html
On Friday 17 June 2011, Ralf Wildenhues wrote:
I generally like the direction this is taking. The point of best
separation between which code goes into Makefile.in and which into
the driver scripts can be fine-tuned when we have more than one such
script.
Actually, yes, before deciding on this for real I really do want to see
a nontrivial other driver script. There is no point in hardcoding
too much in several driver scripts if it all needs to be the same
anyway.
Please measure the time overhead your changes introduce into the current
code, for a trivial testsuite (say, 50 tests running 'true'), and a
nontrivial one like Automake's and one with faster tests.
I've tried the coreutils testsuite and ... Ouch! That gets broken
by my patches :-(
That's due to the overly complex TESTS_ENVIRONMENT employed by
conreutils' tests/Makefile.am:
TESTS_ENVIRONMENT = \
. $(srcdir)/lang-default; \
tmp__=$${TMPDIR-/tmp};\
test -d $$tmp__ test -w $$tmp__ || tmp__=.;\
. $(srcdir)/envvar-check; \
TMPDIR=$$tmp__; export TMPDIR;\
shell_or_perl_() {\
if grep '^\#!/usr/bin/perl' $$1 /dev/null; then \
if $(PERL) -e 'use warnings' /dev/null 21; then \
grep '^\#!/usr/bin/perl -T' $$1 /dev/null T_=T || T_=; \
$(PERL) -w$$T_ -I$(srcdir) -MCoreutils -MCuSkip \
-MCuTmpdir qw($$f) -- $$1;\
else \
echo 12 $$tst: configure did not find a usable version of Perl, \
so skipping this test; \
(exit 77); \
fi; \
else\
$(SHELL) $$1; \
fi; \
};\
export\
VERSION='$(VERSION)' \
LOCALE_FR='$(LOCALE_FR)' \
LOCALE_FR_UTF8='$(LOCALE_FR_UTF8)'\
abs_top_builddir='$(abs_top_builddir)'\
abs_top_srcdir='$(abs_top_srcdir)'\
abs_srcdir='$(abs_srcdir)'\
built_programs=`cat .built-programs`\
host_os=$(host_os)\
host_triplet='$(host_triplet)'\
srcdir='$(srcdir)'\
top_srcdir='$(top_srcdir)'\
CONFIG_HEADER='$(abs_top_builddir)/$(CONFIG_INCLUDE)' \
CU_TEST_NAME=`basename '$(abs_srcdir)'`,`echo $$tst|sed 's,^\./,,;s,/,-,g'` \
CC='$(CC)'\
AWK='$(AWK)' \
EGREP='$(EGREP)' \
EXEEXT='$(EXEEXT)'\
MAKE=$(MAKE) \
PACKAGE_BUGREPORT='$(PACKAGE_BUGREPORT)' \
PACKAGE_VERSION=$(PACKAGE_VERSION)\
PERL='$(PERL)'\
PREFERABLY_POSIX_SHELL='$(PREFERABLY_POSIX_SHELL)' \
REPLACE_GETCWD=$(REPLACE_GETCWD) \
; test -d /usr/xpg4/bin PATH='/usr/xpg4/bin$(PATH_SEPARATOR)'$$PATH; \
PATH='$(abs_top_builddir)/src$(PATH_SEPARATOR)'$$PATH \
; shell_or_perl_ 92
In order to work with the upcoming new Automake testsuite harness, coreutils
have two possibilities:
1. move the `shell_or_perl_' subroutine's functionality into a real acript,
and define the LOG_COMPILER to point to it; or
2. add a `.pl' extension to the perl test scripts, and define PL_LOG_COMPILER
appropriately (might be a little tricky, considering the hops that the
`shell_or_perl_' subroutine goes through in order to get the flags and
imports right).
I should have have an FSF copyright assignement in place for coreutils too,
so I can volounteer to write a fix for this situation, if no one wants to
beat me.
Regards,
Stefano
bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed
Notice: this is a JFTR answer; for the final solution of the issue, see
the better working solution at:
http://lists.gnu.org/archive/html/bug-coreutils/2011-06/msg00080.html
http://lists.gnu.org/archive/html/bug-autoconf/2011-06/msg00016.html
On Tuesday 14 June 2011, Eric Blake wrote:
On 06/13/2011 04:24 PM, Stefano Lattarini wrote:
On Monday 13 June 2011, Eric Blake wrote:
Not possible to portably sniff out closed fds; quoting the autoconf manual:
Don't rely on duplicating a closed file descriptor to cause an
error. With Solaris @command{/bin/sh}, when the redirection fails, the
output goes to the original file descriptor.
Do the shells with the close-on-exec issue also suffer of the issue with
closed fds you've reported? If not, the following could be enough to
solve our situation without having to change automake:
Where are you proposing this hack? In init.sh (after fd 9 has already
been closed if the calling shell used exec instead of some other form of
redirection)? That is, why are we trying to fix init.sh to deal with a
closed fd after the fact, when it seems like the better approach is to
guarantee that fd is never closed on exec in the first place? Which
necessarily implies altering the caller.
if (exec 3-; exec 43) /dev/null 21; then
# Cannot determine whether a file descriptor is closed, fall back
# to inferior hack.
if test 2 -ne $stderr_fileno_ test ! -t $stderr_fileno_; then
eval exec $stderr_fileno_2 # Or is `stderr_fileno_=2' enough?
fi
Or is the whole point of this hack to init.sh to avoid the spurious
warning about EBADF and to instead redirect errors to the
(possibly-altered-by-make) fd 2 when fd 9 was lost, so that at least the
warning messages appear in the logs even though we lost the chance to
display them on the tty?
Yes, this was the idea. But it is moot now that we have a better solution
to be used in TESTS_ENVRIRONMENT.
At any rate, in answer to your question:
Solaris /bin/sh (the shell where failed redirections are silently
ignored) does this:
$ /bin/sh -c '(exec 3-; exec 43) /dev/null 21; echo $?'
0
$ cat k
#!/bin/sh
e=9; warn_ () { echo $@ 1$e; }; warn_ x
$ /bin/sh k
x
$ /bin/sh k /dev/null
$ /bin/sh k 92
x
$ /bin/sh k 92 /dev/null
x
That is, if fd 9 is closed, then 1$e (aka 9) is a no-op on that
shell, and output goes to the original fd 1; but if fd 9 is open, then
output goes to fd 9.
Whereas ksh and HP-UX sh are both vocal on failed redirections, for
reliable detection:
$ ksh -c '(exec 3-; exec 43) /dev/null 21; echo $?'
1
$ ksh k
k[2]: 9: cannot open [Bad file number]
$ ksh k /dev/null
k[2]: 9: cannot open [Bad file number]
$ ksh k 92
x
$ ksh k 92 /dev/null
x
This would have been a problem :-/
Luckily, no more need to worry about it now :-)
Regards,
Stefano
bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed
[adding automake-patches on CC:] Reference to original thread(s), mostly duplicated: http://lists.gnu.org/archive/html/bug-coreutils/2011-06/msg00051.html http://lists.gnu.org/archive/html/bug-autoconf/2011-06/msg2.html Reference to last relevant message there: http://lists.gnu.org/archive/html/bug-autoconf/2011-06/msg00018.html http://lists.gnu.org/archive/html/bug-coreutils/2011-06/msg00082.html On Tuesday 14 June 2011, Eric Blake wrote: On 06/13/2011 04:29 PM, Stefano Lattarini wrote: If this work, then using a bare `2' *at the end of TESTS_ENVIRONMENT* and You meant a bare `92', Yes, sorry. but yes that does seem to be workable for what we want! *without a following semicolon* might give a portable workaround, as if I'm not mistaken POSIX mandates that redirections can be specified anywere on the command line, and are to be evaluated from left to right. Yes, all shells support these as equivalent: 92 sh k sh k 92 UPDATE: Yes, it seems to work. I'll add a testcase to the 'maint' branch in case you and Jim decide to go with this solution (and you can confirm that it really works). Cool! Definitely worth documenting in the automake manual, as owner of TESTS_ENVIRONMENT and as a client of init.sh functionality, as well as your proposed automake testcase addition to ensure we don't break it. I'll then push the attached patch to automake master soonish (by tomorrow or so) if there is no objection by then. Regards, Stefano From 9f80020a24110e599b7dbdc5699dc8dbf5af0bd2 Mon Sep 17 00:00:00 2001 Message-Id: 9f80020a24110e599b7dbdc5699dc8dbf5af0bd2.1308037344.git.stefano.lattar...@gmail.com From: Stefano Lattarini stefano.lattar...@gmail.com Date: Tue, 14 Jun 2011 09:41:14 +0200 Subject: [PATCH] tests: check portable fd redirection in TESTS_ENVIRONMENT * tests/tests-environment-fd-redirect.test: New test. * tests/Makefile.am (TESTS): Update. Motivated by coreutils bug#8846: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8846 See also following CC:ed thread on bug-autoconf list: http://lists.gnu.org/archive/html/bug-autoconf/2011-06/msg2.html --- ChangeLog| 10 tests/Makefile.am|1 + tests/Makefile.in|1 + tests/tests-environment-fd-redirect.test | 75 ++ 4 files changed, 87 insertions(+), 0 deletions(-) create mode 100755 tests/tests-environment-fd-redirect.test diff --git a/ChangeLog b/ChangeLog index aad41c7..e482cbd 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,13 @@ +2011-06-14 Stefano Lattarini stefano.lattar...@gmail.com + + tests: check portable fd redirection in TESTS_ENVIRONMENT + * tests/tests-environment-fd-redirect.test: New test. + * tests/Makefile.am (TESTS): Update. + Motivated by coreutils bug#8846: + http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8846 + See also following CC:ed thread on bug-autoconf list: + http://lists.gnu.org/archive/html/bug-autoconf/2011-06/msg2.html + 2011-06-08 Stefano Lattarini stefano.lattar...@gmail.com test defs: new function 'fatal_', for hard errors diff --git a/tests/Makefile.am b/tests/Makefile.am index e68f6d7..c0f39ce 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -949,6 +949,7 @@ tar2.test \ tar3.test \ target-cflags.test \ targetclash.test \ +tests-environment-fd-redirect.test \ txinfo.test \ txinfo2.test \ txinfo3.test \ diff --git a/tests/Makefile.in b/tests/Makefile.in index 7e5fd09..4c223fc 100644 --- a/tests/Makefile.in +++ b/tests/Makefile.in @@ -1216,6 +1216,7 @@ tar2.test \ tar3.test \ target-cflags.test \ targetclash.test \ +tests-environment-fd-redirect.test \ txinfo.test \ txinfo2.test \ txinfo3.test \ diff --git a/tests/tests-environment-fd-redirect.test b/tests/tests-environment-fd-redirect.test new file mode 100755 index 000..2a0afa9 --- /dev/null +++ b/tests/tests-environment-fd-redirect.test @@ -0,0 +1,75 @@ +#! /bin/sh +# Copyright (C) 2011 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2, or (at your option) +# any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see http://www.gnu.org/licenses/. + +# Test for a behaviour of `TESTS_ENVIRONMENT' and `AM_TESTS_ENVIRONMENT' +# w.r.t. file descriptor redirections which, although undocumented, +# is nonetheless required by Gnulib's 'tests/init.sh' and by coreutils' +# testsuite. +# The checked behaviour is that we can portably do file descriptor +# redirections
bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed
On Tuesday 14 June 2011, Jim Meyering wrote:
Here's what I expect to do for coreutils,
along with an advice-update for gnulib's init.sh:
Thanks, I'll apply something similar to automake `tests/defs' soonish.
I have a doubt below, tough (see near the end).
From e948173c1c461aac9f1c490061b257f55e42608d Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Tue, 14 Jun 2011 09:59:14 +0200
Subject: [PATCH] tests: accommodate HP-UX and Solaris shells
Running make check normally prints a diagnostic to the outermost
stderr (usually a tty) to explain why a test is skipped. It did this
by redirecting FD 9 to stderr (via exec 92) before invoking the
shell script. Shell scripts write skip-explanation to FD 9 via
init.sh's skip_ function. However, with Solaris 10's ksh and HP-UX,
the effects of exec 92 are canceled upon fork-and-exec,
BTW, this is true also for the default ksh on Debian GNU/Linux (but
note that this is just a trivia fact, since on GNU/Linux basically
everybody uses either bash or dash as the non-interactive shell of
choice).
so we would get a Bad file number diagnostic and no skip explanation
on those systems.
* tests/check.mk (TESTS_ENVIRONMENT): Redirect more portably, via
$(SHELL) $$1 92, rather than the prior
exec 92; $(SHELL) ...
Actually, we use shell_or_perl_ 92, to make this effective
also for the perl-based tests.
* tests/init.sh (stderr_fileno_): Update the advice in comments.
See http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/22488
for lots of discussion. Stefano Lattarini suggested the solution
of putting 92 after the command. Reported by Bruno Haible.
---
tests/check.mk |3 +--
tests/init.sh |4 ++--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/tests/check.mk b/tests/check.mk
index db7f067..9db96af 100644
--- a/tests/check.mk
+++ b/tests/check.mk
@@ -58,7 +58,6 @@ TESTS_ENVIRONMENT = \
test -d $$tmp__ test -w $$tmp__ || tmp__=.; \
. $(srcdir)/envvar-check; \
TMPDIR=$$tmp__; export TMPDIR; \
- exec 92; \
shell_or_perl_() { \
if grep '^\#!/usr/bin/perl' $$1 /dev/null; then
\
if $(PERL) -e 'use warnings' /dev/null 21; then\
@@ -100,6 +99,6 @@ TESTS_ENVIRONMENT =\
REPLACE_GETCWD=$(REPLACE_GETCWD) \
; test -d /usr/xpg4/bin PATH='/usr/xpg4/bin$(PATH_SEPARATOR)'$$PATH; \
PATH='$(abs_top_builddir)/src$(PATH_SEPARATOR)'$$PATH \
- ; shell_or_perl_
+ ; shell_or_perl_ 92
VERBOSE = yes
diff --git a/tests/init.sh b/tests/init.sh
index 60d1bc1..a769d8b 100644
--- a/tests/init.sh
+++ b/tests/init.sh
@@ -68,8 +68,8 @@ Exit () { set +e; (exit $1); exit $1; }
# Print warnings (e.g., about skipped and failed tests) to this file number.
# Override by defining to say, 9, in init.cfg, and putting say,
-# export ...ENVVAR_SETTINGS...; exec 92; $(SHELL) in the definition
-# of TESTS_ENVIRONMENT in your tests/Makefile.am file.
+# export ...ENVVAR_SETTINGS...; $(SHELL) $$1 92
What is this `$$1' here for?
+# in the definition of TESTS_ENVIRONMENT in your tests/Makefile.am file.
# This is useful when using automake's parallel tests mode, to print
# the reason for skip/failure to console, rather than to the .log files.
: ${stderr_fileno_=2}
--
1.7.6.rc0.293.g40857
Regards,
Stefano
bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed
Hello Jim.
Just a minor nit, since your fix will have to be ported to automake's
`tests/defs' too ...
On Monday 13 June 2011, Jim Meyering wrote:
Bruno Haible wrote:
On HP-UX 11.31, built with cc, coreutils-8.12 gives 3 test suite failures:
FAIL: misc/printf-surprise (exit: 1)
FAIL: dd/nocache (exit: 1)
FAIL: du/inaccessible-cwd (exit: 1)
Find attached the log file.
...
FAIL: misc/printf-surprise (exit: 1)
./init.sh: line 77: 1: Bad file number
printf (GNU coreutils) 8.12
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
...
Hi Bruno
Thank you for the testing and report.
That bad file number error comes from this code in init.sh:
: ${stderr_fileno_=2}
warn_ () { echo $@ 1$stderr_fileno_; }
Because of that, the log contains less information than usual.
If you can easily apply this patch and rerun the failing tests,
I'd appreciate it. It should avoid the error and let us see
more details about what is failing.
From 25e7bded3f2abff58540b0fcead2ba110d344bb0 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Mon, 13 Jun 2011 12:07:14 +0200
Subject: [PATCH] init.sh: accommodate shells for which 1$stderr_fileno_
fails
* tests/init.sh (warn_): Use eval to work around a bug in some shells,
like those of Solaris 10 and HP-UX 11.11.
---
tests/init.sh |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tests/init.sh b/tests/init.sh
index 14f2e26..7a701f6 100644
--- a/tests/init.sh
+++ b/tests/init.sh
@@ -74,7 +74,7 @@ Exit () { set +e; (exit $1); exit $1; }
# the reason for skip/failure to console, rather than to the .log files.
: ${stderr_fileno_=2}
-warn_ () { echo $@ 1$stderr_fileno_; }
+warn_ () { eval 'echo '$@' 1'$stderr_fileno_; }
Wouldn't it be simpler, and potentially more correct, to use simply:
warn_ () { eval 'echo $@ 1'$stderr_fileno_; }
With your new implementation, I see this on Debian with bash and dash:
$ stderr_fileno_=2; warn_ () { eval 'echo '$@' 1'$stderr_fileno_; }
$ $ warn_ '$HOME'
/home/stefano
which is not intended behaviour IMHO.
fail_ () { warn_ $ME_: failed test: $@; Exit 1; }
skip_ () { warn_ $ME_: skipped test: $@; Exit 77; }
framework_failure_ () { warn_ $ME_: set-up failure: $@; Exit 99; }
--
1.7.6.rc0.293.g40857
Regards,
Stefano
bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed
On Monday 13 June 2011, Jim Meyering wrote:
Stefano Lattarini wrote:
Hello Jim.
...
Wouldn't it be simpler, and potentially more correct, to use simply:
warn_ () { eval 'echo $@ 1'$stderr_fileno_; }
With your new implementation, I see this on Debian with bash and dash:
$ stderr_fileno_=2; warn_ () { eval 'echo '$@' 1'$stderr_fileno_; }
$ $ warn_ '$HOME'
/home/stefano
which is not intended behaviour IMHO.
Thanks again. Here's what I've just pushed.
I'll do the same for gnulib shortly.
From 6fb9aeedd1b858a61d5cbf7f15782adf29ff733a Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Mon, 13 Jun 2011 12:07:14 +0200
Subject: [PATCH] init.sh: accommodate shells for which 1$stderr_fileno_
fails
* tests/init.sh (warn_): Use eval to work around a bug in some shells,
like those of Solaris 10 and HP-UX 11.11.
Improved by Stefano Lattarini.
---
tests/init.sh |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tests/init.sh b/tests/init.sh
index 14f2e26..25850af 100644
--- a/tests/init.sh
+++ b/tests/init.sh
@@ -74,7 +74,7 @@ Exit () { set +e; (exit $1); exit $1; }
# the reason for skip/failure to console, rather than to the .log files.
: ${stderr_fileno_=2}
-warn_ () { echo $@ 1$stderr_fileno_; }
+warn_ () { eval 'echo $@ 1'$stderr_fileno_; }
fail_ () { warn_ $ME_: failed test: $@; Exit 1; }
skip_ () { warn_ $ME_: skipped test: $@; Exit 77; }
framework_failure_ () { warn_ $ME_: set-up failure: $@; Exit 99; }
--
1.7.6.rc0.293.g40857
Thanks. I'll port this to automake tests/defs soonish; I assume you are
ok to be credited as lead author in ChangeLog and git commit, right?
Regards,
Stefano
bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed
Hi Jim. Probably you're totally going to hate me today, but ...
On Monday 13 June 2011, Jim Meyering wrote:
From d987cf87de5e7e597e295914c536bd332c24cc63 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Mon, 13 Jun 2011 18:54:53 +0200
Subject: [PATCH] init.sh: redirect FD 9 to stderr again, for Solaris 10 and
HP-UX
* tests/init.sh (setup_): When $stderr_fileno_ is not 2, redirect it.
Prior to this change, we would redirect before the shell fork-and-exec
performed via automake's TESTS_ENVIRONMENT, but that redirection was
ineffective on Solaris 10 and HP-UX 11.31, due to the fact that those
systems set the CLOEXEC bit on FDs larger than 2. Thus our redirection
of FD 9 would not survive the fork-and-exec of running each test script.
---
tests/init.sh |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/tests/init.sh b/tests/init.sh
index 60d1bc1..d101643 100644
--- a/tests/init.sh
+++ b/tests/init.sh
@@ -317,6 +317,11 @@ path_prepend_ ()
setup_ ()
{
+ # If we're redirecting a file descriptor larger than 2, say via automake's
+ # TESTS_ENVIRONMENT, that redirected FD is closed-on-exec on some systems
+ # (at least Solaris 10 and HP-UX 11.x), so redirect it here again.
+ test $stderr_fileno_ = 2 || eval exec $stderr_fileno_2
+
... isn't this equivalent to just using 2 unconditionally in 'warn_()'?
IMHO, the right fix is to to modify the code in TESTS_ENVIRONMENT to avoid the
definition of $stderr_fileno_ the shell performs closed-on-exec; e.g.,
TESTS_ENVIRONMENT = ...; \
if test x`(exec 91 sh -c 'echo foo 9' /dev/null 21)` = x'foo';
then
stderr_fileno_=9; export stderr_fileno_;
else
unset stderr_fileno_ || :
fi
If we know that bash and zsh are well behaved, we can even avoid a couple of
forks (Cygwin users won't hate us too much then):
TESTS_ENVIRONMENT = ...; \
if test -n $${ZSH_VERSION}$${BASH_VERSION} || \
test x`(exec 91 sh -c 'echo foo 9' /dev/null 21)` = x'foo'
then
stderr_fileno_=9; export stderr_fileno_;
else
unset stderr_fileno_ || :
fi
A better fix would be to do the redirect $stderr_fileno_2 in tess/init.sh
iff $stderr_fileno_ is closed, but how can that be portably determined
without printing trash on the user screen (and for *each* test)?
if test $VERBOSE = yes; then
# Test whether set -x may cause the selected shell to corrupt an
# application's stderr. Many do, including zsh-4.3.10 and the /bin/sh
--
1.7.6.rc0.293.g40857
Regards,
Stefano
bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed
On Monday 13 June 2011, Stefano Lattarini wrote:
Hi Jim. Probably you're totally going to hate me today, but ...
On Monday 13 June 2011, Jim Meyering wrote:
From d987cf87de5e7e597e295914c536bd332c24cc63 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Mon, 13 Jun 2011 18:54:53 +0200
Subject: [PATCH] init.sh: redirect FD 9 to stderr again, for Solaris 10 and
HP-UX
* tests/init.sh (setup_): When $stderr_fileno_ is not 2, redirect it.
Prior to this change, we would redirect before the shell fork-and-exec
performed via automake's TESTS_ENVIRONMENT, but that redirection was
ineffective on Solaris 10 and HP-UX 11.31, due to the fact that those
systems set the CLOEXEC bit on FDs larger than 2. Thus our redirection
of FD 9 would not survive the fork-and-exec of running each test script.
---
tests/init.sh |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/tests/init.sh b/tests/init.sh
index 60d1bc1..d101643 100644
--- a/tests/init.sh
+++ b/tests/init.sh
@@ -317,6 +317,11 @@ path_prepend_ ()
setup_ ()
{
+ # If we're redirecting a file descriptor larger than 2, say via
automake's
+ # TESTS_ENVIRONMENT, that redirected FD is closed-on-exec on some systems
+ # (at least Solaris 10 and HP-UX 11.x), so redirect it here again.
+ test $stderr_fileno_ = 2 || eval exec $stderr_fileno_2
+
... isn't this equivalent to just using 2 unconditionally in 'warn_()'?
IMHO, the right fix is to to modify the code in TESTS_ENVIRONMENT to avoid the
definition of $stderr_fileno_ the shell performs closed-on-exec; e.g.,
TESTS_ENVIRONMENT = ...; \
if test x`(exec 91 sh -c 'echo foo 9' /dev/null 21)` =
x'foo'; then
stderr_fileno_=9; export stderr_fileno_;
else
unset stderr_fileno_ || :
fi
If we know that bash and zsh are well behaved, we can even avoid a couple of
forks (Cygwin users won't hate us too much then):
TESTS_ENVIRONMENT = ...; \
if test -n $${ZSH_VERSION}$${BASH_VERSION} || \
test x`(exec 91 sh -c 'echo foo 9' /dev/null 21)` = x'foo'
then
stderr_fileno_=9; export stderr_fileno_;
else
unset stderr_fileno_ || :
fi
A better fix would be to do the redirect $stderr_fileno_2 in tess/init.sh
iff $stderr_fileno_ is closed, but how can that be portably determined
without printing trash on the user screen (and for *each* test)?
But this last observaton makes me think. The only purpose of $stderr_fileno_
is to allow the test to print diagnostic on the user's tty, instead of burying
it in the test logs; at this point, we might do the redirection only if the
fd 2 is a tty, so that we will know that, in `tests/init.sh', either:
[1] $stderr_fileno_ refers to a tty, even after the automake parallel-tests
driver has made its own redirections; or:
[2] $stderr_fileno_ is simply the file descriptor 2, which is expected to be
open for writing in any remotely sane setup.
Then we can test, from within tests/init.sh, whether $stderr_fileno_ has been
closed or not by doing:
test 2 -eq $stderr_fileno_ || test -t $stderr_fileno_
and if this is not the case, we eval exec $stderr_fileno_ 2 and live
happily. All without extra forks or overly complex `TESTS_ENVIRONMENT'
definitions.
WDYT?
Regards,
Stefano
bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed
On Monday 13 June 2011, Stefano Lattarini wrote:
On Monday 13 June 2011, Stefano Lattarini wrote:
Hi Jim. Probably you're totally going to hate me today, but ...
On Monday 13 June 2011, Jim Meyering wrote:
From d987cf87de5e7e597e295914c536bd332c24cc63 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Mon, 13 Jun 2011 18:54:53 +0200
Subject: [PATCH] init.sh: redirect FD 9 to stderr again, for Solaris 10
and HP-UX
* tests/init.sh (setup_): When $stderr_fileno_ is not 2, redirect it.
Prior to this change, we would redirect before the shell fork-and-exec
performed via automake's TESTS_ENVIRONMENT, but that redirection was
ineffective on Solaris 10 and HP-UX 11.31, due to the fact that those
systems set the CLOEXEC bit on FDs larger than 2. Thus our redirection
of FD 9 would not survive the fork-and-exec of running each test script.
---
tests/init.sh |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/tests/init.sh b/tests/init.sh
index 60d1bc1..d101643 100644
--- a/tests/init.sh
+++ b/tests/init.sh
@@ -317,6 +317,11 @@ path_prepend_ ()
setup_ ()
{
+ # If we're redirecting a file descriptor larger than 2, say via
automake's
+ # TESTS_ENVIRONMENT, that redirected FD is closed-on-exec on some
systems
+ # (at least Solaris 10 and HP-UX 11.x), so redirect it here again.
+ test $stderr_fileno_ = 2 || eval exec $stderr_fileno_2
+
... isn't this equivalent to just using 2 unconditionally in 'warn_()'?
IMHO, the right fix is to to modify the code in TESTS_ENVIRONMENT to avoid
the
definition of $stderr_fileno_ the shell performs closed-on-exec; e.g.,
TESTS_ENVIRONMENT = ...; \
if test x`(exec 91 sh -c 'echo foo 9' /dev/null 21)` =
x'foo'; then
stderr_fileno_=9; export stderr_fileno_;
else
unset stderr_fileno_ || :
fi
If we know that bash and zsh are well behaved, we can even avoid a couple of
forks (Cygwin users won't hate us too much then):
TESTS_ENVIRONMENT = ...; \
if test -n $${ZSH_VERSION}$${BASH_VERSION} || \
test x`(exec 91 sh -c 'echo foo 9' /dev/null 21)` =
x'foo'
then
stderr_fileno_=9; export stderr_fileno_;
else
unset stderr_fileno_ || :
fi
A better fix would be to do the redirect $stderr_fileno_2 in tests/init.sh
iff $stderr_fileno_ is closed, but how can that be portably determined
without printing trash on the user screen (and for *each* test)?
But this last observaton makes me think. The only purpose of $stderr_fileno_
is to allow the test to print diagnostic on the user's tty, instead of burying
it in the test logs; at this point, we might do the redirection only if the
fd 2 is a tty, so that we will know that, in `tests/init.sh', either:
[1] $stderr_fileno_ refers to a tty, even after the automake parallel-tests
driver has made its own redirections; or:
[2] $stderr_fileno_ is simply the file descriptor 2, which is expected to be
open for writing in any remotely sane setup.
Then we can test, from within tests/init.sh, whether $stderr_fileno_ has been
closed or not by doing:
test 2 -eq $stderr_fileno_ || test -t $stderr_fileno_
and if this is not the case, we eval exec $stderr_fileno_ 2 and live
happily. All without extra forks or overly complex `TESTS_ENVIRONMENT'
definitions.
Only that BSD make and Solaris dmake, when running in concurrent mode,
redirect stdout/stderr to temporary files or to named or anonymous pipes
(for output serialization); so that my proposed idiom wouldn't work with
them. Sigh.
Regards,
Stefano
bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed
On Monday 13 June 2011, Eric Blake wrote:
Not possible to portably sniff out closed fds; quoting the autoconf manual:
Don't rely on duplicating a closed file descriptor to cause an
error. With Solaris @command{/bin/sh}, when the redirection fails, the
output goes to the original file descriptor.
Do the shells with the close-on-exec issue also suffer of the issue with
closed fds you've reported? If not, the following could be enough to
solve our situation without having to change automake:
if (exec 3-; exec 43) /dev/null 21; then
# Cannot determine whether a file descriptor is closed, fall back
# to inferior hack.
if test 2 -ne $stderr_fileno_ test ! -t $stderr_fileno_; then
eval exec $stderr_fileno_2 # Or is `stderr_fileno_=2' enough?
fi
else
if (exec 39) /dev/null 21; then
:
else
eval exec $stderr_fileno_2 # Or is `stderr_fileno_=2' enough?
fi
fi
Regards,
Stefano
bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed
On Tuesday 14 June 2011, Eric Blake wrote:
On 06/13/2011 03:39 PM, Stefano Lattarini wrote:
[3] The $(SHELL), which here we assume is ksh with close-on-exec, does a
fork+exec to execute the test script; thus, when that script begins
its execution, it has the fd 9 closed (d'oh!, but expected now);
Oddly enough, it looks like it is _only_ 'exec 92' that suffers from
close-on-exec semantics; using '(blah) 92' leaves fd 9 inheritable.
So maybe the real fix is to do the redirection to a subshell or grouping
{} rather than via exec, at which point even ksh and HP-UX sh will allow
the original stderr to be inherited as fd 9 to the child script process:
$ printf '#!/bin/sh\nexec 9\n' k
$ sh k
k[2]: 9: Generated or received a file descriptor number that is not valid.
$ sh k 92
$ sh -c 'exec 92; /bin/sh k'
k[2]: 9: Generated or received a file descriptor number that is not valid.
$ sh -c 'sh k 92'
If this work, then using a bare `2' *at the end of TESTS_ENVIRONMENT* and
*without a following semicolon* might give a portable workaround, as if I'm
not mistaken POSIX mandates that redirections can be specified anywere on
the command line, and are to be evaluated from left to right.
UPDATE: Yes, it seems to work. I'll add a testcase to the 'maint' branch in
case you and Jim decide to go with this solution (and you can confirm that it
really works).
$ sh -c '(sh k) 92'
$ sh -c '{ sh k;} 92'
$
but I don't know if that will require some changes in automake's
parallel-test driver setup code.
And Autoconf should probably document that the close-on-exec semantics
of some shells applies only to the exec builtin, since they do not
happen to other redirections.
Regards,
Stefano
bug#8728: test 'stat-free-color' failed (latest git version v8.12-42-g7d44751)
The log of the failed test is attached. I've not looked into it in any way. Let me know if you need more information. Regards, Stefano FAIL: ls/stat-free-color (exit: 1) == ++ initial_cwd_=/home/stefano/src/coreutils/_build_bleeding/tests ++ fail=0 +++ testdir_prefix_ +++ printf gt ++ pfx_=gt +++ mktempd_ /home/stefano/src/coreutils/_build_bleeding/tests gt-stat-free-color. +++ case $# in +++ destdir_=/home/stefano/src/coreutils/_build_bleeding/tests +++ template_=gt-stat-free-color. +++ MAX_TRIES_=4 +++ case $destdir_ in +++ case $template_ in unset TMPDIR mktemp -d -t -p /home/stefano/src/coreutils/_build_bleeding/tests gt-stat-free-color. +++ d=/home/stefano/src/coreutils/_build_bleeding/tests/gt-stat-free-color.r7or +++ case $d in +++ test -d /home/stefano/src/coreutils/_build_bleeding/tests/gt-stat-free-color.r7or ls -dgo /home/stefano/src/coreutils/_build_bleeding/tests/gt-stat-free-color.r7or tr S - +++ perms='drwx-- 2 4096 May 24 21:58 /home/stefano/src/coreutils/_build_bleeding/tests/gt-stat-free-color.r7or' +++ case $perms in +++ test 0 = 0 +++ echo /home/stefano/src/coreutils/_build_bleeding/tests/gt-stat-free-color.r7or +++ return ++ test_dir_=/home/stefano/src/coreutils/_build_bleeding/tests/gt-stat-free-color.r7or ++ cd /home/stefano/src/coreutils/_build_bleeding/tests/gt-stat-free-color.r7or ++ gl_init_sh_nl_=' ' ++ IFS=' ' ++ for sig_ in 1 2 3 13 15 +++ expr 1 + 128 ++ eval 'trap '\''Exit 129'\'' 1' +++ trap 'Exit 129' 1 ++ for sig_ in 1 2 3 13 15 +++ expr 2 + 128 ++ eval 'trap '\''Exit 130'\'' 2' +++ trap 'Exit 130' 2 ++ for sig_ in 1 2 3 13 15 +++ expr 3 + 128 ++ eval 'trap '\''Exit 131'\'' 3' +++ trap 'Exit 131' 3 ++ for sig_ in 1 2 3 13 15 +++ expr 13 + 128 ++ eval 'trap '\''Exit 141'\'' 13' +++ trap 'Exit 141' 13 ++ for sig_ in 1 2 3 13 15 +++ expr 15 + 128 ++ eval 'trap '\''Exit 143'\'' 15' +++ trap 'Exit 143' 15 ++ trap remove_tmp_ 0 + path_prepend_ ../src + test 1 '!=' 0 + path_dir_=../src + case $path_dir_ in ++ cd /home/stefano/src/coreutils/_build_bleeding/tests/../src ++ echo /home/stefano/src/coreutils/_build_bleeding/src + abs_path_dir_=/home/stefano/src/coreutils/_build_bleeding/src + case $abs_path_dir_ in + PATH=/home/stefano/src/coreutils/_build_bleeding/src:/home/stefano/src/coreutils/_build_bleeding/src:/home/stefano/go/bin:/home/stefano/bin/linux:/home/stefano/bin:/usr/local/bin:/opt/bin:/usr/lib/jvm/java-6-sun-1.6.0.20/bin:/usr/games:/usr/bin:/usr/sbin:/bin:/sbin + create_exe_shims_ /home/stefano/src/coreutils/_build_bleeding/src + case $EXEEXT in + return 0 + shift + test 0 '!=' 0 + export PATH + print_ver_ ls + test yes = yes + local i + for i in '$*' + env ls --version ls (GNU coreutils) 8.12.42-7d447 Packaged by Bleeding Edge Support (v8.12-42-g7d44751) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Richard M. Stallman and David MacKenzie. + require_strace_ stat + test 1 = 1 + strace -V + strace -qe stat echo + require_dirent_d_type_ + python + python /home/stefano/src/coreutils/_build_bleeding/../tests/d_type-check + ln -s nowhere dangle + cat ++ dircolors -b color-without-stat + eval 'LS_COLORS='\''rs=0:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=00:su=00:sg=00:ca=00:tw=00:ow=00:st=00:ex=00:mh=00:'\'';' export LS_COLORS ++ LS_COLORS='rs=0:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=00:su=00:sg=00:ca=00:tw=00:ow=00:st=00:ex=00:mh=00:' ++ export LS_COLORS + strace -o log -e stat,lstat ls --color=always . color-without-stat [0m[01;36mdangle[0m log ++ wc -l + n_lines=0 + test 0 = 1 + fail=1 + Exit 1 + set +e + exit 1 + exit 1 + remove_tmp_ + __st=1 + cleanup_ + : + cd /home/stefano/src/coreutils/_build_bleeding/tests + chmod -R u+rwx /home/stefano/src/coreutils/_build_bleeding/tests/gt-stat-free-color.r7or + rm -rf /home/stefano/src/coreutils/_build_bleeding/tests/gt-stat-free-color.r7or + exit 1
bug#8728: test 'stat-free-color' failed (latest git version v8.12-42-g7d44751)
On Tuesday 24 May 2011, Jim Meyering wrote:
Stefano Lattarini wrote:
The log of the failed test is attached. I've not looked into it in any way.
Let me know if you need more information.
Regards,
Stefano
FAIL: ls/stat-free-color (exit: 1)
==
...
+ strace -o log -e stat,lstat ls --color=always .
color-without-stat
...
++ wc -l
+ n_lines=0
+ test 0 = 1
+ fail=1
Hi Stefano,
Thanks for the report.
It would help to know why strace reported no matches.
Maybe it's due to alternate names like stat64?
If you apply the following patch and rerun that test,
it should provide that information:
make check -C tests TESTS=ls/stat-free-color VERBOSE=yes
The patch does not help to get more information IMHO, because the failure
is caused precisely by the fact that `log' is empty (as can be inferred by
the fact that n_lines=`wc -l log` resulted in $n_lines being 0).
If my guess is correct, then adding ,stat64,lstat64
to the strace command may be the solution:
strace -o log -e stat,lstat,stat64,lstat64 ls --color=always . || fail=1
Yes, this does indeed fix the failure.
From 06a94be331d7e31048f2bb4e659130159cd454f0 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Tue, 24 May 2011 23:06:31 +0200
Subject: [PATCH] tests: stat-free-color: write more into the log upon failure
* tests/ls/stat-free-color: Print syscall log upon error,
to aid diagnosis.
---
tests/ls/stat-free-color |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tests/ls/stat-free-color b/tests/ls/stat-free-color
index d11c6f4..f14beb9 100755
--- a/tests/ls/stat-free-color
+++ b/tests/ls/stat-free-color
@@ -49,6 +49,6 @@ eval $(dircolors -b color-without-stat)
strace -o log -e stat,lstat ls --color=always . || fail=1
n_lines=$(wc -l log)
-test $n_lines = 1 || fail=1
+test $n_lines = 1 || { fail=1; cat log; }
Exit $fail
--
1.7.5.2.585.gfbd48
Thanks,
Stefano
bug#6405: cp from -MM to -M
At Friday 11 June 2010, Peng Yu wrote: I'm trying to cp -MM to -M. But so far I don't have a way to do it. Would you please let me know what is the correct way to cp from -MM to -M? $ cp -r -- -MM/ -- -M The first `--' stops option processing, and so the second `--' is interpreted like a file path, not like an option. cp: target `-M' is not a directory $ ll -go total 0 drwx-- 2 64 2010-06-11 14:35 -MM Simply use: $ cp -r -- -MM/ -M or: $ cp -r ./-MM/ ./-M Stefano
bug#5926: feature request: mv -p to create missing target dir
Just a few obsevations on side issues...
Bob Proulx writes:
Rodolfo Borges wrote:
cat EOF ~/.bashrc
function mv() {
local target=${!#}
local dir
if [[ $target =~ '/$' ]]; then
dir=$target
else
dir=$(dirname $target)
fi
test -d $dir || mkdir -vp $dir
$(which mv) $@
}
EOF
Very good! I see that you have a solution to your problem.
As a side comment I don't see the point of:
$(which mv) $@
I think that's needed because otherwise the shell function would end
up calling itself recursively, since it's named `mv' too.
The 'which' command is another one of those simple but not very
portable commands that does different things on different systems.
Since Rodolfo is assuming bash as his shell, he could have used:
$(type -P mv) $@
instead, which is more portable because it just uses bash builtins.
In the simple case of reporting where the command is found on PATH
the use here is redundant since the command would otherwise simply
be found on PATH.
mv $@
No, this would call the `mv' function, since shell functions take
precedence over external commands in bash.
Regards,
Stefano
bug#5926: feature request: mv -p to create missing target dir
At Monday 26 April 2010, Jim Meyering j...@meyering.net wrote: Using env is the most portable, at the expense of a fork (compared to bash's command): env mv $@ Generally, this is true. But Rodolfo was assuming bash as his shell anyway, and in this case the use of well-estabilished bash builtins/constructs (like command, which was there since at least bash 2.0) can IMHO help to increase portability. In fact, this way one doesn't have to remember the limits/idiosyncracies of many different shells and system utilities (and different versions thereof), but only those of one shell, i.e. bash (and I think that anyone who's read the section Portable Shell Programming in the autoconf manual could be easily convinced that this is a great advantage). Regards, Stefano
bug#5926: feature request: mv -p to create missing target dir
At Monday 26 April 2010, Andreas Schwab sch...@linux-m68k.org wrote: I think that's needed because otherwise the shell function would end up calling itself recursively, since it's named `mv' too. You use command mv for that. Good point, I forgot about that. And it works for shell builtins too. Using command mv seems indeed the optimal choice. Regards, Stefano
