GNU bug report logs - #10898
test-suite output of automake-1.11.3 - it requested I send it to you!

Previous Next

Full log

Message #8 received at 10898 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Lou Picciano <Lou <at> Picciano.org>
Cc: 10898 <at> debbugs.gnu.org, Bayard Bell <buffer.g.overflow <at> gmail.com>
Subject: Re: bug#10898: test-suite output of automake-1.11.3 - it requested
	I send it to you!
Date: Mon, 27 Feb 2012 20:42:33 +0100

Hi Lou, thanks for the report.

On 02/27/2012 05:53 PM, Lou Picciano wrote:
> Building - and testing - significantly more completely now...
> 
> Build is on OpenIndiana 151a2 (illumos/née OpenSolaris) - and, yes; will certainly keep an eye out for the upcoming ßeta.
> 
> Regards, Lou Picciano
> 
> =====================================
> 5 of 787 tests failed
> (151 tests were not run)
> See tests/test-suite.log
> Please report to bug-automake <at> gnu.org
> =====================================
> 

> FAIL: ansi2knr-deprecation.test (exit: 1)
> =========================================
>
> [SNIP]
>
OK, this is almost surely a spurious failure due to a testsuite weakness
(we were forgetting to clobber a possibly out-of-date autom4te cache);
absolutely nothing to worry about ...  And moreover, the 'ansi2knr' support
is strongly deprecated in automake 1.11.2 already, and will be removed
altogether in automake 1.12.  You can safely ignore this error.

> FAIL: automake.test (exit: 1)
> =============================
>
> [SNIP]
>
> + test 1 = 1
> + grep 'input file.*--voo' stderr
> automake: no Automake input file found for `--voo'
> + AUTOMAKE_fails ''
> + AUTOMAKE_run 1
> + expected_exitcode=1
> + shift
> + exitcode=0
> + automake-1.11 --foreign -Werror -Wall
> + 1> stdout 2> stderr
> + exitcode=1
> + cat stderr
> + 1>& 2
> configure.in: no proper invocation of AM_INIT_AUTOMAKE was found.
> configure.in: You should verify that configure.in invokes AM_INIT_AUTOMAKE,
> configure.in: that aclocal.m4 is present in the top-level directory,
> configure.in: and that aclocal.m4 was recently regenerated (using aclocal).
> automake: no `Makefile.am' found for any configure output
> + cat stdout
> + test 1 = 1
> + grep 'empty argument' stderr
> + exit_status=1
>
Ah, likely the famous ksh bug with "$@" and empty arguments:

 <http://lists.gnu.org/archive/html/automake-patches/2009-12/msg00037.html>

Can you verify that your shell suffers of the problem described there?  If
yes, a patch to fix this issue should be trivial.

> FAIL: instfail.test (exit: 1)
> =============================
>
> [SNIP]
>
> WARNING: Warnings can be ignored. :-)
> if test "emacs" != no; then \
>   set x; \
>   list='lisp1.el lisp2.el lisp3.el lispn1.el lispn2.el lispn3.el'; for p in $list; do \
>     if test -f "$p"; then d=; else d="./"; fi; \
>     set x "$@" "$d$p"; shift; \
>   done; \
>   shift; \
>   EMACS="emacs" /bin/sh ./elisp-comp "$@" || exit 1; \
> else : ; fi
> /usr/bin/emacs: no emacs binaries available. Install software package
> SUNWgnu-emacs-gtk, SUNWgnu-emacs-x, or SUNWgnu-emacs-nox
> *** Error code 1
> make: Fatal error: Command failed for target `elc-stamp'
> + exit_status=1
> instfail: exit 1
>
Spurious error due to a broken emacs installation, not automake's fault.

> FAIL: instspc.test (exit: 1)
> ============================
>
> [SNIP]
>
> + mkdir sub1 ./a:
> + cd a:
> .../instspc.test[137]: cd: a:: [No such file or directory]
> + exit_status=1
>
I remember seeing a similar problem when testing with ksh on Solaris; this is a
spurious failure due to a ksh bug, nothing to worry about.  Moreover, the
instspc.test has been extensively rewritten in master, and made more resilient
to this kind of shell bugs (if you think this failure is weird, you should see
the one on MSYS ;-).  In case you re-encounter this failure with automake from
master, feel free to open a new report.

> FAIL: subpkg4.test (exit: 1)
> ============================
>
> + make distdir
> ...
> find "../subpkg4-1.0/subpkg" -type d ! -perm -755 \
>	-exec chmod u+rwx,go+rx {} \; -o \
>  ! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
>  ! -type d ! -perm -400 -exec chmod a+r {} \; -o \
> ...
>
> find: bad option -links
> find: [-E] [-H | -L] path-list predicate-list
>
Oops, your find (1) doesn't support the '-links' option, which is mandated by
POSIX: <http://pubs.opengroup.org/onlinepubs/009604599/utilities/find.html>.
Also, both Solaris 10 /usr/xpg4/bin/find and /usr/bin/find support it (I've
just checked).
Can you try to re-run this test with a more capable 'find' program early
in path, like GNU find?  Does the test fails in this case as well?

Thanks,
  Stefano

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.