Re: new snapshot available: coreutils-8.20.113-1f1f4
On 02/08/2013 02:53 PM, Bernhard Voelker wrote: Shouldn't check-root be limited to SUBDIRS=. in tests/local.mk? check-root: - $(MAKE) check TESTS='$(root_tests)' + $(MAKE) check TESTS='$(root_tests)' SUBDIRS=. Ok to submit this in your name? commit a2702f0f435032a269a3ef1202c3a89b8f2166cc Author: Bernhard Voelker m...@bernhard-voelker.de Date: Mon Feb 11 09:48:31 2013 + maint: avoid running check-root tests in gnulib * tests/local.mk (check-root): Restrict to SUBDIRS=. as traversing into gnulib-tests induces a false failure. diff --git a/tests/local.mk b/tests/local.mk index 83b4ab9..9be1970 100644 --- a/tests/local.mk +++ b/tests/local.mk @@ -137,7 +137,7 @@ all_root_tests =\ ALL_RECURSIVE_TARGETS += check-root .PHONY: check-root check-root: - $(MAKE) check TESTS='$(root_tests)' + $(MAKE) check TESTS='$(root_tests)' SUBDIRS=. # Do not choose a name that is a shell keyword like 'if', or a # commonly-used utility like 'cat' or 'test', as the name of a test.
Re: new snapshot available: coreutils-8.20.113-1f1f4
On 02/11/2013 10:51 AM, Pádraig Brady wrote: On 02/08/2013 02:53 PM, Bernhard Voelker wrote: Shouldn't check-root be limited to SUBDIRS=. in tests/local.mk? check-root: - $(MAKE) check TESTS='$(root_tests)' + $(MAKE) check TESTS='$(root_tests)' SUBDIRS=. Ok to submit this in your name? Yes, of course. Thanks for wrapping it into a proper patch. Have a nice day, Berny
Re: new snapshot available: coreutils-8.20.113-1f1f4
On 02/09/2013 05:52 AM, Pádraig Brady wrote: On 02/08/2013 05:09 PM, Bernhard Voelker wrote: On February 8, 2013 at 5:30 PM Pádraig Brady p...@draigbrady.com wrote: On 02/08/2013 02:53 PM, Bernhard Voelker wrote: On February 7, 2013 at 8:57 PM Pádraig Brady p...@draigbrady.com wrote: * SLES-10.3 (i586): gcc (GCC) 4.1.2 20070115 (SUSE Linux) FAIL: tests/tail-2/inotify-rotate.sh NFS issue during cleanup_ I think I see what's happening. With /bin/sh - bash, bash will create a redundant subshell for the : timeout ... construct. I.E. this prints bash rather than timeout: : timeout 5 sleep 1 readlink /proc/$!/exe So if you had dash installed, this would probably work: make check SHELL=dash TESTS=tests/tail-2/inotify-rotate.sh \ SUBDIRS=. VERBOSE=yes RUN_EXPENSIVE_TESTS=yes There's no dash installed, unfortunately. The reason the subshell causes an issue is that it won't auto send the SIGHUP to timeout when it gets a SIGTERM as it's a non interactive script, and so the timeout processes and thus the tail processes accessing the files hang around until the 40s timeout. In any case the attached should avoid the subshell and hopefully fix the issue. Bingo! Now, the test passes. ;-) Thanks! Have a nice day, Berny
Re: new snapshot available: coreutils-8.20.113-1f1f4
On 02/09/2013 01:16 PM, Bernhard Voelker wrote: Bingo! Now, the test passes. ;-) Thanks! Great, thanks for confirming that. I'll push these 2 test fixups so. thanks, Pádraig.
Re: new snapshot available: coreutils-8.20.113-1f1f4
On February 7, 2013 at 8:57 PM Pádraig Brady p...@draigbrady.com wrote: coreutils snapshot: http://pixelbeat.org/cu/coreutils-8.20.113-1f1f4.tar.xz Hi Padraig, * SLES-10.4 (x86_64): gcc (GCC) 4.1.2 20070115 (SUSE Linux) FAIL: tests/misc/numfmt.pl 1 of 477 tests failed (61 tests were not run) * SLES-10.3 (i586): gcc (GCC) 4.1.2 20070115 (SUSE Linux) FAIL: tests/tail-2/inotify-rotate.sh NFS issue during cleanup_ reproduced: 2x out of 2 tries. FAIL: tests/misc/numfmt.log same as above 2 of 468 tests failed (70 tests were not run) * openSUSE-12.2 (x86_64): gcc (GCC) 4.1.2 20070115 (SUSE Linux) All 501 tests passed (37 tests were not run) BUT 1 gnulib test failed (2x out of 2 times): FAIL: test-utimensat (exit: 134) test-lutimens.h:64: assertion failed * Regarding check-root tests (run on the above openSUSE system): As running them in the gnulib-tests directory doesn't work: make check-TESTS make[6]: Entering directory `/home/berny/test/coreutils-8.20.113-1f1f4/gnulib-tests' make[7]: Entering directory `/home/berny/test/coreutils-8.20.113-1f1f4/gnulib-tests' make[7]: *** No rule to make target `tests/chown/basic.sh.log', needed by `test-suite.log'. make[7]: *** No rule to make target `tests/cp/cp-a-selinux.sh.log', needed by `test-suite.log'. ... Shouldn't check-root be limited to SUBDIRS=. in tests/local.mk? check-root: - $(MAKE) check TESTS='$(root_tests)' + $(MAKE) check TESTS='$(root_tests)' SUBDIRS=. Have a nice day, Berny SLES-10.4.x86_64.tar.xz Description: Binary data SLES-10.3.i586.tar.xz Description: Binary data
Re: new snapshot available: coreutils-8.20.113-1f1f4
Hello Bernhard, Bernhard Voelker wrote, On 02/08/2013 09:53 AM: On February 7, 2013 at 8:57 PM Pádraig Brady p...@draigbrady.com wrote: coreutils snapshot: http://pixelbeat.org/cu/coreutils-8.20.113-1f1f4.tar.xz Hi Padraig, * SLES-10.4 (x86_64): gcc (GCC) 4.1.2 20070115 (SUSE Linux) FAIL: tests/misc/numfmt.pl Regarding the 'numfmt' failures - these are locale-related problems (in both cases). Perhaps I wrote the tests incorrectly. May I ask you to try the followings on those systems, and send the output (or compare with this expected output): # The french locale is used for locale testing - if it doesn't exist, those tests should not run at all. $ locale -a | grep -i fr fr_FR.utf8 # First try without locale (this is test 'lcl-grp-1' which succeeded) $ LC_ALL=C ./src/numfmt --debug --grouping --from=si 7M ./src/numfmt: grouping has no effect in this locale 700 # Try grouping, the expected output should have a space as thousands-separator # this is test lcl-grp-3 which failed, on your system the result was 700 $ LC_ALL=fr_FR.utf8 ./src/numfmt --debug --grouping --from=si 7M 7 000 000 Thanks! -gordon
Re: new snapshot available: coreutils-8.20.113-1f1f4
On February 8, 2013 at 4:13 PM Assaf Gordon assafgor...@gmail.com wrote: Regarding the 'numfmt' failures - these are locale-related problems (in both cases). Perhaps I wrote the tests incorrectly. May I ask you to try the followings on those systems, and send the output (or compare with this expected output): # The french locale is used for locale testing - if it doesn't exist, those tests should not run at all. $ locale -a | grep -i fr fr_FR.utf8 Sure: $ locale -a | grep -i fr br_FR br_FR@euro br_FR.utf8 fr_BE fr_BE@euro fr_BE.utf8 fr_CA fr_CA.utf8 fr_CH fr_CH.utf8 fr_FR fr_FR@euro fr_FR.utf8 fr_LU fr_LU@euro fr_LU.utf8 oc_FR oc_FR.utf8 # First try without locale (this is test 'lcl-grp-1' which succeeded) $ LC_ALL=C ./src/numfmt --debug --grouping --from=si 7M ./src/numfmt: grouping has no effect in this locale 700 LC_ALL=C ./src/numfmt --debug --grouping --from=si 7M ./src/numfmt: grouping has no effect in this locale 700 # Try grouping, the expected output should have a space as thousands-separator # this is test lcl-grp-3 which failed, on your system the result was 700 $ LC_ALL=fr_FR.utf8 ./src/numfmt --debug --grouping --from=si 7M 7 000 000 LC_ALL=fr_FR.utf8 ./src/numfmt --debug --grouping --from=si 7M ./src/numfmt: grouping has no effect in this locale 700 Have a nice day, Berny
Re: new snapshot available: coreutils-8.20.113-1f1f4
On 02/08/2013 03:47 PM, Bernhard Voelker wrote:
On February 8, 2013 at 4:13 PM Assaf Gordon assafgor...@gmail.com wrote:
Regarding the 'numfmt' failures - these are locale-related problems (in both
cases).
Perhaps I wrote the tests incorrectly.
May I ask you to try the followings on those systems, and send the output (or
compare with this expected output):
# The french locale is used for locale testing - if it doesn't exist,
those tests should not run at all.
$ locale -a | grep -i fr
fr_FR.utf8
Sure:
$ locale -a | grep -i fr
br_FR
br_FR@euro
br_FR.utf8
fr_BE
fr_BE@euro
fr_BE.utf8
fr_CA
fr_CA.utf8
fr_CH
fr_CH.utf8
fr_FR
fr_FR@euro
fr_FR.utf8
fr_LU
fr_LU@euro
fr_LU.utf8
oc_FR
oc_FR.utf8
# First try without locale (this is test 'lcl-grp-1' which succeeded)
$ LC_ALL=C ./src/numfmt --debug --grouping --from=si 7M
./src/numfmt: grouping has no effect in this locale
700
LC_ALL=C ./src/numfmt --debug --grouping --from=si 7M
./src/numfmt: grouping has no effect in this locale
700
# Try grouping, the expected output should have a space as
thousands-separator
# this is test lcl-grp-3 which failed, on your system the result was
700
$ LC_ALL=fr_FR.utf8 ./src/numfmt --debug --grouping --from=si 7M
7 000 000
LC_ALL=fr_FR.utf8 ./src/numfmt --debug --grouping --from=si 7M
./src/numfmt: grouping has no effect in this locale
700
Have a nice day,
Berny
OK so we can't assume the locale will behave as we want.
Therefore we can gate the test on the output of the independent
printf like:
diff --git a/tests/misc/numfmt.pl b/tests/misc/numfmt.pl
index c542483..603b60a 100644
--- a/tests/misc/numfmt.pl
+++ b/tests/misc/numfmt.pl
@@ -883,7 +883,19 @@ my @Locale_Tests =
{ENV=LC_ALL=$locale}],
);
-push @Tests, @Locale_Tests if $locale ne C;
+if ($locale ne 'C')
+ {
+# Reset locale to 'C' if LOCALE_FR_UTF8 doesn't output as expected
+# as determined by the separate printf program.
+my $loc_num = `LC_ALL=$locale printf %'d\n 1234`;
+chomp($loc_num);
+if ($loc_num ne '1 234')
+ {
+warn loc_num =$loc_num=\n;
+$locale = 'C';
+ }
+ }
+push @Tests, @Locale_Tests if $locale ne 'C';
## Check all valid/invalid suffixes
foreach my $suf ( 'A' .. 'Z', 'a' .. 'z' ) {
cheers,
Pádraig.
Re: new snapshot available: coreutils-8.20.113-1f1f4
On February 8, 2013 at 4:56 PM Pádraig Brady p...@draigbrady.com wrote: OK so we can't assume the locale will behave as we want. Therefore we can gate the test on the output of the independent printf like: PASS: tests/misc/numfmt.pl ;-) Have a nice day, Berny
Re: new snapshot available: coreutils-8.20.113-1f1f4
On 02/08/2013 02:53 PM, Bernhard Voelker wrote: On February 7, 2013 at 8:57 PM Pádraig Brady p...@draigbrady.com wrote: coreutils snapshot: http://pixelbeat.org/cu/coreutils-8.20.113-1f1f4.tar.xz Hi Padraig, * SLES-10.4 (x86_64): gcc (GCC) 4.1.2 20070115 (SUSE Linux) FAIL: tests/misc/numfmt.pl 1 of 477 tests failed (61 tests were not run) * SLES-10.3 (i586): gcc (GCC) 4.1.2 20070115 (SUSE Linux) FAIL: tests/tail-2/inotify-rotate.sh NFS issue during cleanup_ reproduced: 2x out of 2 tries. If you put a wait before the Exit at the end of that test, does it help. As a less desirable solution we could put require_local_dir_ at the top of this test. FAIL: tests/misc/numfmt.log same as above 2 of 468 tests failed (70 tests were not run) * openSUSE-12.2 (x86_64): gcc (GCC) 4.1.2 20070115 (SUSE Linux) All 501 tests passed (37 tests were not run) BUT 1 gnulib test failed (2x out of 2 times): FAIL: test-utimensat (exit: 134) test-lutimens.h:64: assertion failed On NFS again? http://lists.gnu.org/archive/html/bug-gnulib/2011-10/threads.html#00291 * Regarding check-root tests (run on the above openSUSE system): As running them in the gnulib-tests directory doesn't work: make check-TESTS make[6]: Entering directory `/home/berny/test/coreutils-8.20.113-1f1f4/gnulib-tests' make[7]: Entering directory `/home/berny/test/coreutils-8.20.113-1f1f4/gnulib-tests' make[7]: *** No rule to make target `tests/chown/basic.sh.log', needed by `test-suite.log'. make[7]: *** No rule to make target `tests/cp/cp-a-selinux.sh.log', needed by `test-suite.log'. ... Shouldn't check-root be limited to SUBDIRS=. in tests/local.mk? check-root: - $(MAKE) check TESTS='$(root_tests)' + $(MAKE) check TESTS='$(root_tests)' SUBDIRS=. Probably. thanks, Pádraig.
Re: new snapshot available: coreutils-8.20.113-1f1f4
Thanks for the quick fix. Bernhard Voelker wrote, On 02/08/2013 11:02 AM: On February 8, 2013 at 4:56 PM Pádraig Brady p...@draigbrady.com wrote: OK so we can't assume the locale will behave as we want. Therefore we can gate the test on the output of the independent printf like: PASS: tests/misc/numfmt.pl I don't know if this is a SUSE bug or not. The closest thing I've found is a Debian bug report from 2004: locales: Wrong thousands_sep value in fr_FR locale http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248377 -gordon
Re: new snapshot available: coreutils-8.20.113-1f1f4
On February 8, 2013 at 5:30 PM Pádraig Brady p...@draigbrady.com wrote:
On 02/08/2013 02:53 PM, Bernhard Voelker wrote:
On February 7, 2013 at 8:57 PM Pádraig Brady p...@draigbrady.com wrote:
* SLES-10.3 (i586):
gcc (GCC) 4.1.2 20070115 (SUSE Linux)
FAIL: tests/tail-2/inotify-rotate.sh
NFS issue during cleanup_
reproduced: 2x out of 2 tries.
If you put a wait before the Exit at the end of that test, does it help.
As a less desirable solution we could put require_local_dir_ at the top
of this test.
Unfortunately not:
+ for j in '$(seq 150)'
+ grep ok out
+ return 0
+ found=1
+ kill 27060
+ test 1 = 0
+ wait
+ Exit 0
+ set +e
+ exit 0
+ exit 0
+ remove_tmp_
+ __st=0
+ cleanup_
+ :
+ cd /homes/vb027591/depot/coreutils-8.20.113-1f1f4
+ chmod -R u+rwx
/homes/vb027591/depot/coreutils-8.20.113-1f1f4/gt-inotify-rotate.sh.aQIe
+ rm -rf
/homes/vb027591/depot/coreutils-8.20.113-1f1f4/gt-inotify-rotate.sh.aQIe
rm: cannot remove
'/homes/vb027591/depot/coreutils-8.20.113-1f1f4/gt-inotify-rotate.sh.aQIe/.nfs005d43e60398':
Device or resource busy
rm: cannot remove
'/homes/vb027591/depot/coreutils-8.20.113-1f1f4/gt-inotify-rotate.sh.aQIe/.nfs005d43e7039b':
Device or resource busy
rm: cannot remove
'/homes/vb027591/depot/coreutils-8.20.113-1f1f4/gt-inotify-rotate.sh.aQIe/.nfs005d43e8039e':
Device or resource busy
rm: cannot remove
'/homes/vb027591/depot/coreutils-8.20.113-1f1f4/gt-inotify-rotate.sh.aQIe/.nfs005d43e203a1':
Device or resource busy
+ test 0 = 0
+ __st=1
+ exit 1
I even tried with
+ wait
+ sleep 5
but still Device or resource busy. ;-(
Why do we need this in remove_tmp_ ()?
# If removal fails and exit status was to be 0, then change it to 1.
rm -rf $test_dir_ || { test $__st = 0 __st=1; }
* openSUSE-12.2 (x86_64):
gcc (GCC) 4.1.2 20070115 (SUSE Linux)
All 501 tests passed
(37 tests were not run)
BUT 1 gnulib test failed (2x out of 2 times):
FAIL: test-utimensat (exit: 134)
test-lutimens.h:64: assertion failed
On NFS again?
http://lists.gnu.org/archive/html/bug-gnulib/2011-10/threads.html#00291
No, that's a VirtualBox VM with no NFS mounts running on a Win7 host.
The file system is ext4 on plain /dev/sdb.
Have a nice day,
Berny
Re: new snapshot available: coreutils-8.20.113-1f1f4
On 02/08/2013 05:35 PM, Assaf Gordon wrote: Thanks for the quick fix. Bernhard Voelker wrote, On 02/08/2013 11:02 AM: On February 8, 2013 at 4:56 PM Pádraig Brady p...@draigbrady.com wrote: OK so we can't assume the locale will behave as we want. Therefore we can gate the test on the output of the independent printf like: PASS: tests/misc/numfmt.pl I don't know if this is a SUSE bug or not. The closest thing I've found is a Debian bug report from 2004: locales: Wrong thousands_sep value in fr_FR locale http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248377 -gordon Hmm, these servers aren't updated regularly, so it's possible that such a bug is already fixed for years ... Thanks have a nice day, Berny
Re: new snapshot available: coreutils-8.20.113-1f1f4
On 02/08/2013 05:09 PM, Bernhard Voelker wrote:
On February 8, 2013 at 5:30 PM Pádraig Brady p...@draigbrady.com wrote:
On 02/08/2013 02:53 PM, Bernhard Voelker wrote:
On February 7, 2013 at 8:57 PM Pádraig Brady p...@draigbrady.com wrote:
* SLES-10.3 (i586):
gcc (GCC) 4.1.2 20070115 (SUSE Linux)
FAIL: tests/tail-2/inotify-rotate.sh
NFS issue during cleanup_
reproduced: 2x out of 2 tries.
If you put a wait before the Exit at the end of that test, does it help.
As a less desirable solution we could put require_local_dir_ at the top
of this test.
Unfortunately not:
I think I see what's happening. With /bin/sh - bash,
bash will create a redundant subshell for the : timeout ... construct.
I.E. this prints bash rather than timeout:
: timeout 5 sleep 1 readlink /proc/$!/exe
So if you had dash installed, this would probably work:
make check SHELL=dash TESTS=tests/tail-2/inotify-rotate.sh \
SUBDIRS=. VERBOSE=yes RUN_EXPENSIVE_TESTS=yes
The reason the subshell causes an issue is that it won't
auto send the SIGHUP to timeout when it gets a SIGTERM
as it's a non interactive script, and so the timeout
processes and thus the tail processes accessing the files
hang around until the 40s timeout.
In any case the attached should avoid the subshell
and hopefully fix the issue.
BTW I found a related signal race in bash when looking at this,
where it will ignore the SIGTERM before it execs the background
command, but I'm fairly sure we're not hitting this here
and so will only send details of that to the bash list.
Why do we need this in remove_tmp_ ()?
# If removal fails and exit status was to be 0, then change it to 1.
rm -rf $test_dir_ || { test $__st = 0 __st=1; }
I think that's fine. It's indicating the error which
we would have missed otherwise.
Maybe it should call framework_failure_ or something,
rather than set __st=1, but that's a minor detail.
cheers,
Pádraig.
From 1420fb36651d105c96eee2ace3563a32c1c0a1af Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
Date: Sat, 9 Feb 2013 04:39:40 +
Subject: [PATCH] tests: tail-2/inotify-rotate: fix a false failure on NFS
* tests/tail-2/inotify-rotate.sh: Avoid a subshell with bash,
which in turn causes the `kill` to be ineffective to the tail
processes (as the SIGTERM is sent to the subshell which doesn't
propagate the signal on to its children). On NFS the test
cleanup will then fail as there will be .nfs files maintained
in the directory for the files still opened by the tail processes.
Reported by Bernhard Voelker.
---
tests/tail-2/inotify-rotate.sh |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/tests/tail-2/inotify-rotate.sh b/tests/tail-2/inotify-rotate.sh
index 94c2b7d..4a16202 100755
--- a/tests/tail-2/inotify-rotate.sh
+++ b/tests/tail-2/inotify-rotate.sh
@@ -47,7 +47,8 @@ for i in $(seq 50); do
# Normally less than a second is required here, but with heavy load
# and a lot of disk activity, even 20 seconds is insufficient, which
# leads to this timeout killing tail before the ok is written below.
-:k :x timeout 40 tail -F k out 21
+:k :x || framework_failure_ failed to initialize files
+timeout 40 tail -F k out 21
pid=$!
sleep .1
echo b k;
@@ -65,4 +66,5 @@ for i in $(seq 50); do
test $found = 0 { cat out; fail_ failed to detect echoed 'ok'; }
done
+wait
Exit $fail
--
1.7.7.6
