Re: Testsuite failures on HP-UX 11.23 (was: Re: testsuite results from master)
Reference: http://lists.gnu.org/archive/html/automake-patches/2010-11/msg00162.html [For the sake of the reading this message in real-time: this reply has been sent pratically without changes also to the related thread Testsuite failures on IRIX 6.5] FAIL: distlinksbrk.test (exit: 1) = /tmp/am/build-hppa2.0w-hp-hpux11.23/tests:/tmp/local/hppa2.0w-hp-hpux11.23/bin :/tmp/bin:/opt/aCC/bin:/opt/ansic/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/X11 :/usr/ccs/bin:/usr/contrib/bin/X11:/usr/vue/bin:/opt/imake/bin + pwd /tmp/am/build-hppa2.0w-hp-hpux11.23/tests/distlinksbrk.dir + set -e + lnk_base=BrknSymlnk + lnk1=BrknSymlnk__001 + lnk2=BrknSymlnk__002 + lnka=BrknSymlnk__aaa + lnkb=BrknSymlnk__bbb + ln -s nonesuch BrknSymlnk__001 + pwd + ln -s /tmp/am/build-hppa2.0w-hp-hpux11.23/tests/distlinksbrk.dir/nonesuch BrknSymlnk__002 + ln -s BrknSymlnk__001 BrknSymlnk__aaa + ln -s BrknSymlnk__aaa BrknSymlnk__bbb + test ! -r BrknSymlnk__001 + test ! -r BrknSymlnk__002 + test ! -r BrknSymlnk__aaa + test ! -r BrknSymlnk__bbb + test -h BrknSymlnk__001 + test -h BrknSymlnk__002 + test -h BrknSymlnk__aaa + test -h BrknSymlnk__bbb + cat + 1 configure.in 0 /var/tmp/sh13163.8 + cat + 1 Makefile.am 0 EXTRA_DIST = BrknSymlnk__001 BrknSymlnk__002 BrknSymlnk__aaa BrknSymlnk__bbb + ls -l total 18 lrwxrwxr-x 1 rwild rwild8 Nov 12 20:16 BrknSymlnk__001 - nonesuch lrwxrwxr-x 1 rwild rwild 74 Nov 12 20:16 BrknSymlnk__002 - /tmp/am/build-hppa2.0w-hp-hpux11.23/tests/distlinksbrk.dir/nonesuch lrwxrwxr-x 1 rwild rwild 15 Nov 12 20:16 BrknSymlnk__aaa - BrknSymlnk__001 lrwxrwxr-x 1 rwild rwild 15 Nov 12 20:16 BrknSymlnk__bbb - BrknSymlnk__aaa -rw-rw-r-- 1 rwild rwild 77 Nov 12 20:16 Makefile.am -rw-rw-r-- 1 rwild rwild 86 Nov 12 20:16 configure.in -rwxr-xr-x 1 rwild rwild20001 Nov 12 20:16 depcomp -rwxr-xr-x 1 rwild rwild13781 Nov 12 20:16 install-sh -rwxr-xr-x 1 rwild rwild11419 Nov 12 20:16 missing + aclocal-1.11a -Werror + autoconf + automake-1.11a --foreign -Werror -Wall + ./configure checking for a BSD-compatible install... ./install-sh -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile + make distdir No suffix list. ?!? What is this? Make: Don't know how to make BrknSymlnk__001. Stop. + make -k distdir + 1 out 2 1 + : + cat out No suffix list. Make: Don't know how to make BrknSymlnk__001. Stop. Just an error message instead of four? Might this be a make -k bug? I've now installed a patch for this; see git commit v1.11-135-g2f8861f distlinksbrk.test: Work around botched 'make -k', and the message on automake-patches: http://lists.gnu.org/archive/html/automake-patches/2010-12/msg00121.html I'm not sure if that really solves the problem above, though. If anyone can do proper testing, please let me know what the results are. Regards, Stefano
Re: Testsuite failures on IRIX 6.5 (was: testsuite results from master)
Reference: http://lists.gnu.org/archive/html/automake-patches/2010-11/msg00166.html [For the sake of the reading this message in real-time: this reply has been sent pratically without changes also to the related thread Testsuite failures on HP-UX 11.23] FAIL: distlinksbrk.test (exit: 1) = /tmp/am/build-mips-sgi-irix6.5/tests:/tmp/local/mips-sgi-irix6.5/bi n:/tmp/bin:/bin:/usr/bin:/sbin:/usr/sbin:/etc:/usr/etc:/usr/bin/X11 :/usr/bsd + pwd /tmp/am/build-mips-sgi-irix6.5/tests/distlinksbrk.dir + set -e + lnk_base=BrknSymlnk + lnk1=BrknSymlnk__001 + lnk2=BrknSymlnk__002 + lnka=BrknSymlnk__aaa + lnkb=BrknSymlnk__bbb + ln -s nonesuch BrknSymlnk__001 + pwd + ln -s /tmp/am/build-mips-sgi-irix6.5/tests/distlinksbrk.dir/nonesuch BrknSymlnk__002 + ln -s BrknSymlnk__001 BrknSymlnk__aaa + ln -s BrknSymlnk__aaa BrknSymlnk__bbb + test ! -r BrknSymlnk__001 + test ! -r BrknSymlnk__002 + test ! -r BrknSymlnk__aaa + test ! -r BrknSymlnk__bbb + test -h BrknSymlnk__001 + test -h BrknSymlnk__002 + test -h BrknSymlnk__aaa + test -h BrknSymlnk__bbb + cat + 1 configure.in 0 /tmp/sh791237.2 + cat + 1 Makefile.am 0 EXTRA_DIST = BrknSymlnk__001 BrknSymlnk__002 BrknSymlnk__aaa BrknSymlnk__bbb + ls -l total 92 lrwxrwxr-x1 rwildrwild 8 Nov 12 20:31 BrknSymlnk__001 - nonesuch lrwxrwxr-x1 rwildrwild 69 Nov 12 20:31 BrknSymlnk__002 - /tmp/am/build-mips-sgi-irix6.5/tests/distlinksbrk.dir/nonesuch lrwxrwxr-x1 rwildrwild 15 Nov 12 20:31 BrknSymlnk__aaa - BrknSymlnk__001 lrwxrwxr-x1 rwildrwild 15 Nov 12 20:31 BrknSymlnk__bbb - BrknSymlnk__aaa -rw-rw-r--1 rwildrwild 77 Nov 12 20:31 Makefile.am -rw-rw-r--1 rwildrwild 86 Nov 12 20:31 configure.in -rwxr-xr-x1 rwildrwild 20001 Nov 12 20:31 depcomp -rwxr-xr-x1 rwildrwild 13781 Nov 12 20:31 install-sh -rwxr-xr-x1 rwildrwild 11419 Nov 12 20:31 missing + aclocal-1.11a -Werror + autoconf + automake-1.11a --foreign -Werror -Wall + ./configure checking for a BSD-compatible install... ./install-sh -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile + make distdir UX:make: ERROR: don't know how to make BrknSymlnk__001 (bu42). + make -k distdir + 1 out 2 1 + : + cat out UX:make: ERROR: don't know how to make BrknSymlnk__001 (bu42). Just an error message instead of four? Might this be a make -k bug? If yes, how does the attached test script fare? I've now installed a patch for this; see git commit v1.11-135-g2f8861f distlinksbrk.test: Work around botched 'make -k', and the message on automake-patches: http://lists.gnu.org/archive/html/automake-patches/2010-12/msg00121.html I'm not sure if that really solves the problem above, though. If anyone can do proper testing, please let me know what the results are. Regards, Stefano
Re: Testsuite failures on IRIX 6.5 (was: testsuite results from master)
Ping on this? Reference: http://lists.gnu.org/archive/html/automake-patches/2010-11/msg00211.html Regards, Stefano
Re: Testsuite failures on Solaris 2.10 on SPARC (was: testsuite results from master)
On Tue, Nov 16, 2010 at 20:45 UTC, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Stefano Lattarini wrote on Sun, Nov 14, 2010 at 11:05:55PM CET: http://autobuild.josefsson.org/automake/log-201011141903417895000.txt checking build system type... sparc-sun-solaris2.10 All the testsuite failures seem spurious, and due to the following rm error (in the distclean target, if I'm not mistaken): rm: Unable to remove directory ...: File exists What's going on here? Maybe NFS issues (wild guess)? Yes, these are NFS-related. E.g., acloca13.test has leftover files .nfs6E44 and .nfs7E44 in tests/acloca13.dir/acloca13-1.0 which correspond to install-sh and configure (or configure.lineno). This test fails reproducibly. I cannot remove the files after the tests have ended. So I suspect that these are file system issues that I don't have under control. The NTP reference implementation make distcheck reliably fails similarly on OpenSolaris in a NFS-mounted directory: SunOS psp-os1 5.11 snv_111b i86pc i386 i86pc Solaris I dug into it, because that machine is over twice as fast building NTP as the other options, so I really wanted to make our distcheck work. I gave up because the code was out of my control without complaining further, but I'd still like to get around it. The Sun NFS client intentionally defers deleting files, renaming them to .nfs for some period of time that is not brief enough for make distcheck to succeed. If you delete a .nfs1234, don't be suprised to see it silently renamed to .nfs5678 :) It would be lovely from my perspective if Automake-generated distcheck would ignore .nfs specifically and trust they will indeed be rm'd eventually. Cheers, Dave Hart
Re: Testsuite failures on IRIX 6.5 (was: testsuite results from master)
In the meantime, I've prepared a patch to fix the VPATH-related
spurious failures in parallel-tests8.test and suffix13.test.
Ralf, does it work for you?
Regards,
Stefano
From 87e825fb00f90939b58cc9dd4eddc4a2cb9d5d0a Mon Sep 17 00:00:00 2001
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Tue, 16 Nov 2010 22:28:26 +0100
Subject: [PATCH] Fix two spurious testsuite failures on IRIX 6.5.
* tests/suffix13.test: (Makefile.am): Account for VPATH issues on
weaker make implementations (e.g. IRIX 6.5).
* tests/parallel-tests8.test: Likewise, plus a required related
change.
Reported by Ralf Wildenhues. The bugs have been there from the
first versions of the affected test scripts.
---
ChangeLog |8
tests/parallel-tests8.test |5 +++--
tests/suffix13.test|3 ++-
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index b69d4e5..6a9f1ba 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,13 @@
2010-11-16 Stefano Lattarini stefano.lattar...@gmail.com
+ Fix two spurious testsuite failures on IRIX 6.5.
+ * tests/suffix13.test: (Makefile.am): Account for VPATH issues on
+ weaker make implementations (e.g. IRIX 6.5).
+ * tests/parallel-tests8.test: Likewise, plus a required related
+ change.
+ Reported by Ralf Wildenhues. The bugs have been there from the
+ first versions of the affected test scripts.
+
Fix regression in colon{5,6}.test (failures on AIX 5.3).
* tests/colon5.test: Also substitute `...@shell@' with `$SHELL' when
post-processing the generated Makefile.in, to work around a bug
diff --git a/tests/parallel-tests8.test b/tests/parallel-tests8.test
index 784e07f..43e67df 100755
--- a/tests/parallel-tests8.test
+++ b/tests/parallel-tests8.test
@@ -38,7 +38,8 @@ TESTS = foo.test
## the next line will cause automake to error out:
TESTS += $(srcdir)/bar.test $(top_srcdir)/baz.test
.in.test:
- cp $ $@
+## Account for VPATH issues on weaker make implementations (e.g. IRIX 6.5)
+ cp `test -f $ || echo $(srcdir)/`$ $@
chmod +x $@
check_SCRIPTS = $(TESTS)
EXTRA_DIST = foo.in foo.test
@@ -57,7 +58,7 @@ AUTOMAKE_fails -a
grep '(srcdir.*bar' stderr
grep 'top_srcdir.*baz' stderr
-sed '/srcdir/d' Makefile.am t
+sed '/^TESTS +=.*srcdir/d' Makefile.am t
mv -f t Makefile.am
$AUTOMAKE -a
diff --git a/tests/suffix13.test b/tests/suffix13.test
index 2b39460..aa5a3ed 100755
--- a/tests/suffix13.test
+++ b/tests/suffix13.test
@@ -38,7 +38,8 @@ AUTOMAKE_OPTIONS = subdir-objects
SUFFIXES = .baz .c
.baz.c:
case $@ in sub/*) $(MKDIR_P) sub;; *) :;; esac
- cp $ $@
+## Account for VPATH issues on weaker make implementations (e.g. IRIX 6.5)
+ cp `test -f $ || echo $(srcdir)/`$ $@
DISTCLEANFILES = sub/bar.c
--
1.7.1
testsuite results from master
Hello Stefano, I think it is time to reevaluate some of the work that has been done in the last few weeks. I'd like to ask you to postpone pushes of pending stuff that has a clock ticking, and look at the lots of new failures that a testsuite run shows on a few hosts; you can find them in some minutes on http://autobuild.josefsson.org/automake/. I might be responsible for some of the failures too, but I think it's fair to guess that your patches are responsible for at least some of these. ;-) Thanks, Ralf
Re: testsuite results from master
On Sunday 14 November 2010, Ralf Wildenhues wrote: Hello Stefano, I think it is time to reevaluate some of the work that has been done in the last few weeks. I'd like to ask you to postpone pushes of pending stuff that has a clock ticking, and look at the lots of new failures that a testsuite run shows on a few hosts; you can find them in some minutes on http://autobuild.josefsson.org/automake/. Log: http://autobuild.josefsson.org/automake/log-201011141903417895000.txt Minimal system info: configure: autobuild project... GNU Automake configure: autobuild revision... v1.11-225-gcdd3cf3 configure: autobuild hostname... hikaru configure: autobuild mode... default configure: autobuild timestamp... 20111412T185841Z checking build system type... sparc-sun-solaris2.10 -*-*-*- All the testsuite failures seem spurious, and due to the following rm error (in the distclean target, if I'm not mistaken): rm: Unable to remove directory ...: File exists What's going on here? Maybe NFS issues (wild guess)? http://www.unix.com/unix-dummies-questions-answers/72080-rm-unable-remove-directory-mnt-users-test-logs-file-exists.html Or something relate to FS logging or FS corruption (wilder guess)? http://www.webservertalk.com/archive101-2004-1-65261.html -*-*-*- I can say I test automake on a Solaris 10 system quite often, and the testsuite is behaving quite well there (apart from some pre-existing, mostly spurious failures). Regards, Stefano
Testsuite failures on AIX 5.3 (was: testsuite results from master)
On Sunday 14 November 2010, Ralf Wildenhues wrote: Hello Stefano, I think it is time to reevaluate some of the work that has been done in the last few weeks. I'd like to ask you to postpone pushes of pending stuff that has a clock ticking, and look at the lots of new failures that a testsuite run shows on a few hosts; you can find them in some minutes on http://autobuild.josefsson.org/automake/. Log: http://autobuild.josefsson.org/automake/log-20101114190221478.txt Minimal system information: configure: autobuild project... GNU Automake configure: autobuild revision... v1.11-225-gcdd3cf3 configure: autobuild hostname... yawara configure: autobuild mode... default configure: autobuild timestamp... 20111412T185841Z running CONFIG_SHELL=/bin/sh /bin/sh ../automake/configure -C --prefix=/tmp/local/powerpc-ibm-aix5.3.0.0 checking build system type... powerpc-ibm-aix5.3.0.0 -*-*-*- FAIL: ansi.test (exit: 2) = /tmp/am/build-powerpc-ibm-aix5.3.0.0/tests:/tmp/local/powerpc-ibm-aix5.3.0.0/bin:/tmp/bin :/usr/vac/bin:/usr/vacpp/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/X11:/etc:/usr/etc + pwd /tmp/am/build-powerpc-ibm-aix5.3.0.0/tests/ansi.dir + set -e + cat + 1 Makefile.am 0 /tmp/sh663580.2 + cat + 1 configure.in 0 /tmp/sh663580.4 + : + 1 ansi2knr.c + : + 1 ansi2knr.1 + aclocal-1.11a -Werror + automake-1.11a --foreign -Werror -Wall + /bin/grep -F -v @SET_MAKE@ Makefile.in + 1 Makefile.sed + make -f Makefile.sed SHELL=/bin/sh test1 echo ' @top_srcdir@/configure.in @top_srcdir@/aclocal.m4 @srcdir@/Makefile.am \ @srcdir@/Makefile.in @top_srcdir@/configure ansi2knr.1 ansi2knr.c \ depcomp install-sh missing' | grep ' ansi2knr\.c ' @SHELL@: not found make: 1254-004 The error code from the last command is 1. Stop. + exit_status=2 IMHO this is a spurious failure due to the old hackish check: $FGREP -v @SET_MAKE@ Makefile.in Makefile.sed $MAKE -f Makefile.sed SHELL=$SHELL test1 retained from older versions of ansi.test; since this check is superseded by the later ones: $AUTOCONF ./configure $MAKE test1 my suggested fix is to just drop the hackish check. -*-*-*- FAIL: colon5.test (exit: 2) FAIL: colon6.test (exit: 2) These tests fail for the same resons of ansi.test; I suggest to drop the older hackish checks and do more proper checks with autoconf, ./configure and make. BTW, there is a pending patch of mine aimed at making the `colon*.test' tests more semantic; see: http://lists.gnu.org/archive/html/automake-patches/2010-09/msg00110.html -*-*-*- FAIL: fn99.test (exit: 2) FAIL: fn99subdir.test (exit: 2) I'm pretty sure these tests haven't been affected by my (or yours) latest patches: the failure is pre-existent IMO. Also, the tests fails due to a segmentation fault in the (make-spawned) shell, so the failures are better investigated by someone having direct access to the system in question. -*-*-*- Regards, Stefano
Testsuite failures on Solaris 2.10 on SPARC (was: testsuite results from master)
[Reposting with a better subject. Sorry for the noise.] On Sunday 14 November 2010, Ralf Wildenhues wrote: Hello Stefano, I think it is time to reevaluate some of the work that has been done in the last few weeks. I'd like to ask you to postpone pushes of pending stuff that has a clock ticking, and look at the lots of new failures that a testsuite run shows on a few hosts; you can find them in some minutes on http://autobuild.josefsson.org/automake/. Log: http://autobuild.josefsson.org/automake/log-201011141903417895000.txt Minimal system info: configure: autobuild project... GNU Automake configure: autobuild revision... v1.11-225-gcdd3cf3 configure: autobuild hostname... hikaru configure: autobuild mode... default configure: autobuild timestamp... 20111412T185841Z checking build system type... sparc-sun-solaris2.10 -*-*-*- All the testsuite failures seem spurious, and due to the following rm error (in the distclean target, if I'm not mistaken): rm: Unable to remove directory ...: File exists What's going on here? Maybe NFS issues (wild guess)? http://www.unix.com/unix-dummies-questions-answers/72080-rm-unable-remove-directory-mnt-users-test-logs-file-exists.html Or something relate to FS logging or FS corruption (wilder guess)? http://www.webservertalk.com/archive101-2004-1-65261.html -*-*-*- I can say I test automake on a Solaris 10 system (i86pc) quite often, and the testsuite is behaving quite well there (apart from some pre-existing, mostly spurious failures). Regards, Stefano
Re: testsuite results from master
Please disregard; answer to the message Testsuite failures on Solaris 2.10 on SPARC instead. Sorry for the noise, Stefano
Re: testsuite results from master
On Sunday 14 November 2010, Ralf Wildenhues wrote: Hello Stefano, I think it is time to reevaluate some of the work that has been done in the last few weeks. Do you mean go and fix the newly introduced regressions before doing other testsuite work, or reconsider the advisability of doing testsuite work in master and/or to have a 72-hours gracetime? If you mean the former, then I agree. I'd like to ask you to postpone pushes of pending stuff that has a clock ticking, There's just two of those, so it's not a problem. and look at the lots of new failures Which of those failures are really new? Some of them involve test scripts and automake features unmodified by quite a long time. that a testsuite run shows on a few hosts; you can find them in some minutes on http://autobuild.josefsson.org/automake/. That's useful. Thanks. I might be responsible for some of the failures too, but I think it's fair to guess that your patches are responsible for at least some of these. ;-) See my other answers to this thread for more information and questions. Regards, Stefano
Testsuite failures on HP-UX 11.23 (was: Re: testsuite results from master)
On Sunday 14 November 2010, Ralf Wildenhues wrote: Hello Stefano, I think it is time to reevaluate some of the work that has been done in the last few weeks. I'd like to ask you to postpone pushes of pending stuff that has a clock ticking, and look at the lots of new failures that a testsuite run shows on a few hosts; you can find them in some minutes on http://autobuild.josefsson.org/automake/. Log: http://autobuild.josefsson.org/automake/log-201011141903352512000.txt Minimal system information: configure: autobuild project... GNU Automake configure: autobuild revision... v1.11-225-gcdd3cf3 configure: autobuild hostname... ichigo configure: autobuild mode... default configure: autobuild timestamp... 20111412T185841Z CONFIG_SHELL=/bin/sh /bin/sh ../automake/configure checking build system type... hppa2.0w-hp-hpux11.23 -*-*-*- FAIL: instspc-space-build.test (exit: 1) FAIL: instspc-space-install.test (exit: 1) FAIL: instspc-tab-build.test (exit: 1) FAIL: instspc-tab-install.test (exit: 1) Hmpf. Not very nice. Apparently, the whitespaces got eaten somehow in the make rules: ../install-sh -c -d '/tmp/am/build-hppa2.0w-hp-hpux11.23/tests/instspc-space-build.dir/sub1/ -prefix/foo/sub' OK, space is there ... ../install-sh -c -m 644 ../sub/nobase.h '/tmp/am/build-hppa2.0w-hp-hpux11.23/tests/instspc-space-build.dir/sub1/ -prefix/foo/sub' ... and here ... test -f '/tmp/am/build-hppa2.0w-hp-hpux11.23/tests/instspc-space-build.dir/sub1/-prefix/foo/sub/nobase.h' ... but not here! *** Error exit code 1 And failure ensues. My knee-jerk guess is that the (leading?) whitespaces got stripped from the variable `file' even if it's defined from the command line: DESTDIR=$dest file=$instspc_test_string $MAKE -e test-install-sep Is this guess correct? Is this a known limitation/bug of HP-UX make? Is it worth working around? (e.g. by adding some more sanity checks and skipping the test if they fail) FAIL: instspc-formfeed-build.test (exit: 1) FAIL: instspc-formfeed-install.test (exit: 1) FAIL: instspc-carriageret-build.test (exit: 1) FAIL: instspc-carriageret-install.test (exit: 1) On the other hand, I wouldn't care about these failures. Getting to the point: how was the older `instspc.test' behaving on this system? Without knowing that, it's hard to tell if we've introduced a regression, or are just hitting known bugs/limits of HP-UX. -*-*-*- FAIL: parallel-tests.test (exit: 1) Not caused by recent testsuite work (and I can't easily guess why it's failing). FAIL: spy.test (exit: 1) This is not really a test on automake/aclocal, but a spy test on the make implementation available, to see if double-colon rules work for it. The heading comments read: # Check whether double colon rules work. The Unix V7 make manual # mentions double-colon rules, but POSIX does not. They seem to be # supported by all Make implementation as we can tell. This test case # is a spy: we want to detect if there exist implementations where # these do not work. We might use these rules to simplify the rebuild # rules (instead of the $? hack). But currently automake doesn't use double-colon rules in the generated makefiles, so no big deal IMHO. -*-*-*- FAIL: distlinksbrk.test (exit: 1) = /tmp/am/build-hppa2.0w-hp-hpux11.23/tests:/tmp/local/hppa2.0w-hp-hpux11.23/bin :/tmp/bin:/opt/aCC/bin:/opt/ansic/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/bin/X11 :/usr/ccs/bin:/usr/contrib/bin/X11:/usr/vue/bin:/opt/imake/bin + pwd /tmp/am/build-hppa2.0w-hp-hpux11.23/tests/distlinksbrk.dir + set -e + lnk_base=BrknSymlnk + lnk1=BrknSymlnk__001 + lnk2=BrknSymlnk__002 + lnka=BrknSymlnk__aaa + lnkb=BrknSymlnk__bbb + ln -s nonesuch BrknSymlnk__001 + pwd + ln -s /tmp/am/build-hppa2.0w-hp-hpux11.23/tests/distlinksbrk.dir/nonesuch BrknSymlnk__002 + ln -s BrknSymlnk__001 BrknSymlnk__aaa + ln -s BrknSymlnk__aaa BrknSymlnk__bbb + test ! -r BrknSymlnk__001 + test ! -r BrknSymlnk__002 + test ! -r BrknSymlnk__aaa + test ! -r BrknSymlnk__bbb + test -h BrknSymlnk__001 + test -h BrknSymlnk__002 + test -h BrknSymlnk__aaa + test -h BrknSymlnk__bbb + cat + 1 configure.in 0 /var/tmp/sh13163.8 + cat + 1 Makefile.am 0 EXTRA_DIST = BrknSymlnk__001 BrknSymlnk__002 BrknSymlnk__aaa BrknSymlnk__bbb + ls -l total 18 lrwxrwxr-x 1 rwild rwild8 Nov 12 20:16 BrknSymlnk__001 - nonesuch lrwxrwxr-x 1 rwild rwild 74 Nov 12 20:16 BrknSymlnk__002 - /tmp/am/build-hppa2.0w-hp-hpux11.23/tests/distlinksbrk.dir/nonesuch lrwxrwxr-x 1 rwild rwild 15 Nov 12 20:16 BrknSymlnk__aaa - BrknSymlnk__001 lrwxrwxr-x 1 rwild rwild 15 Nov 12 20:16 BrknSymlnk__bbb - BrknSymlnk__aaa -rw-rw-r-- 1 rwild rwild 77 Nov 12 20:16 Makefile.am -rw-rw-r-- 1 rwild rwild 86 Nov 12 20:16 configure.in -rwxr-xr-x 1 rwild rwild20001 Nov 12 20:16 depcomp -rwxr-xr-x 1
Testsuite results on FreeBSD 6.4 on i386 (was: testsuite results from master)
On Sunday 14 November 2010, Ralf Wildenhues wrote: Hello Stefano, I think it is time to reevaluate some of the work that has been done in the last few weeks. I'd like to ask you to postpone pushes of pending stuff that has a clock ticking, and look at the lots of new failures that a testsuite run shows on a few hosts; you can find them in some minutes on http://autobuild.josefsson.org/automake/. Log: http://autobuild.josefsson.org/automake/log-201011141903469617000.txt Minimal system information: configure: autobuild project... GNU Automake configure: autobuild revision... v1.11-225-gcdd3cf3 configure: autobuild hostname... thor configure: autobuild mode... default configure: autobuild timestamp... 20111412T185841Z CONFIG_SHELL=/usr/local/bin/bash /usr/local/bin/bash ../automake/configure checking build system type... i386-unknown-freebsd6.4 -*-*-*- Well, it seems the testsuite is passing here... No FAIL'd test that I can see! Am I missing something? Regards, Stefano
Testsuite failures on IRIX 6.5 (was: testsuite results from master)
On Sunday 14 November 2010, Ralf Wildenhues wrote: Hello Stefano, I think it is time to reevaluate some of the work that has been done in the last few weeks. I'd like to ask you to postpone pushes of pending stuff that has a clock ticking, and look at the lots of new failures that a testsuite run shows on a few hosts; you can find them in some minutes on http://autobuild.josefsson.org/automake/. Log: http://autobuild.josefsson.org/automake/log-20101114190370844.txt Minimal system information: configure: autobuild project... GNU Automake configure: autobuild revision... v1.11-225-gcdd3cf3 configure: autobuild hostname... puar configure: autobuild mode... default configure: autobuild timestamp... 20111412T185841Z running CONFIG_SHELL=/bin/sh /bin/sh ../automake/configure PERL=/opt/fsw/perl586/bin/perl checking build system type... mips-sgi-irix6.5 -*-*-*- I see many failures similar to this one (taken from backcompat6.log): config.status: executing depfiles commands make all-am source='quux.c' object='quux.o' libtool=no \ DEPDIR=.deps depmode=sgi /bin/sh ../depcomp \ cc -DHAVE_CONFIG_H -I. -I.. -g -c quux.c cc ERROR: file does not exist: quux.c It should be `../quux.c' here, since it is a VPATH build. Is this a bug in automake or in VPATH support of IRIX make? Should the makefile fragment: source='$' object='$@' libtool=no \ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) \ $(COMPILE) -c $ be rewritten as follows? source='$' object='$@' libtool=no \ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) \ $(COMPILE) -c `test -f $ || echo $(srcdir)`/$ -*-*-*- FAIL: instspc-*-build.test FAIL: instspc-*-install.test Sample: + make source='source.c' object='source.o' libtool=no \ DEPDIR=.deps depmode=sgi /bin/sh ../depcomp \ cc -DPACKAGE_NAME=\instspc-bang-build\ -DPACKAGE_TARNAME=\instspc-bang-build\ \ -DPACKAGE_VERSION=\1.0\ -DPACKAGE_STRING=\instspc-bang-build\ 1.0\ \ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DPACKAGE=\instspc-bang-build\ \ -DVERSION=\1.0\ -I. -I.. -g -c source.c cc ERROR: file does not exist: source.c *** Error code 2 (bu21) So this failures are not due to the recent instspc*.test refactoring, but to the same VPATH issue described above. -*-*-*- FAIL: distlinksbrk.test (exit: 1) = /tmp/am/build-mips-sgi-irix6.5/tests:/tmp/local/mips-sgi-irix6.5/bi n:/tmp/bin:/bin:/usr/bin:/sbin:/usr/sbin:/etc:/usr/etc:/usr/bin/X11 :/usr/bsd + pwd /tmp/am/build-mips-sgi-irix6.5/tests/distlinksbrk.dir + set -e + lnk_base=BrknSymlnk + lnk1=BrknSymlnk__001 + lnk2=BrknSymlnk__002 + lnka=BrknSymlnk__aaa + lnkb=BrknSymlnk__bbb + ln -s nonesuch BrknSymlnk__001 + pwd + ln -s /tmp/am/build-mips-sgi-irix6.5/tests/distlinksbrk.dir/nonesuch BrknSymlnk__002 + ln -s BrknSymlnk__001 BrknSymlnk__aaa + ln -s BrknSymlnk__aaa BrknSymlnk__bbb + test ! -r BrknSymlnk__001 + test ! -r BrknSymlnk__002 + test ! -r BrknSymlnk__aaa + test ! -r BrknSymlnk__bbb + test -h BrknSymlnk__001 + test -h BrknSymlnk__002 + test -h BrknSymlnk__aaa + test -h BrknSymlnk__bbb + cat + 1 configure.in 0 /tmp/sh791237.2 + cat + 1 Makefile.am 0 EXTRA_DIST = BrknSymlnk__001 BrknSymlnk__002 BrknSymlnk__aaa BrknSymlnk__bbb + ls -l total 92 lrwxrwxr-x1 rwildrwild 8 Nov 12 20:31 BrknSymlnk__001 - nonesuch lrwxrwxr-x1 rwildrwild 69 Nov 12 20:31 BrknSymlnk__002 - /tmp/am/build-mips-sgi-irix6.5/tests/distlinksbrk.dir/nonesuch lrwxrwxr-x1 rwildrwild 15 Nov 12 20:31 BrknSymlnk__aaa - BrknSymlnk__001 lrwxrwxr-x1 rwildrwild 15 Nov 12 20:31 BrknSymlnk__bbb - BrknSymlnk__aaa -rw-rw-r--1 rwildrwild 77 Nov 12 20:31 Makefile.am -rw-rw-r--1 rwildrwild 86 Nov 12 20:31 configure.in -rwxr-xr-x1 rwildrwild 20001 Nov 12 20:31 depcomp -rwxr-xr-x1 rwildrwild 13781 Nov 12 20:31 install-sh -rwxr-xr-x1 rwildrwild 11419 Nov 12 20:31 missing + aclocal-1.11a -Werror + autoconf + automake-1.11a --foreign -Werror -Wall + ./configure checking for a BSD-compatible install... ./install-sh -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile + make distdir UX:make: ERROR: don't know how to make BrknSymlnk__001 (bu42). + make -k distdir + 1 out 2 1 + : + cat out UX:make: ERROR: don't know how to make BrknSymlnk__001 (bu42). Just an error message instead of four? Might this be a make -k bug? If yes, how does the attached test script fare? + /bin/grep -F BrknSymlnk__001 out UX:make: ERROR: don't know how to
Re: testsuite results from master
* Stefano Lattarini wrote on Mon, Nov 15, 2010 at 12:19:00AM CET: On Sunday 14 November 2010, Ralf Wildenhues wrote: I think it is time to reevaluate some of the work that has been done in the last few weeks. Do you mean go and fix the newly introduced regressions before doing other testsuite work, or reconsider the advisability of doing testsuite work in master and/or to have a 72-hours gracetime? If you mean the former, then I agree. Yes, I mean the former. and look at the lots of new failures Which of those failures are really new? Some of them involve test scripts and automake features unmodified by quite a long time. I might be responsible for some of the failures too, but I think it's fair to guess that your patches are responsible for at least some of these. ;-) See my other answers to this thread for more information and questions. I will try to address your questions when I have time (i.e., tonight at the earliest), but it would really help if you had access yourself. Thanks, Ralf
