bug#23768: [PATCH] tests: adjust to ignore gzip 1.8+ warnings

This fixes a test failure when testing with gzip 1.8. * t/distcheck-no-prefix-or-srcdir-override.sh: Instead of testing for an empty 'stderr' file, check for a zero-line file once gzip warnings have been removed. --- t/distcheck-no-prefix-or-srcdir-override.sh | 6 +- 1 file changed, 5

bug#22372: [PATCH] automake.in: fix deprecated regex syntax

Enrico Jorns skribis: > Running automake with perl >= 5.22.0 produces the warning > > Unescaped left brace in regex is deprecated, passed through in regex; > marked by <-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at > >

bug#16291: Use of /bin/rm

Stefano Lattarini stefano.lattar...@gmail.com skribis: On 12/29/2013 10:49 PM, Ludovic Courtès wrote: [...] However, in general, I think packages should not rely on hardcoded file names, and instead use AC_PATH_PROG or similar mechanisms to get the right file name. Not in this case

bug#16291: Use of /bin/rm

Stefano Lattarini stefano.lattar...@gmail.com skribis: On 12/30/2013 04:44 PM, Ludovic Courtès wrote: Stefano Lattarini stefano.lattar...@gmail.com skribis: On 12/29/2013 10:49 PM, Ludovic Courtès wrote: [...] However, in general, I think packages should not rely on hardcoded file

bug#16291: Use of /bin/rm

Hello! While upgrading the GNU system to Automake 1.14.1, I noticed that a few tests emit warnings like this: --8---cut here---start-8--- SKIP: t/spy-rm.tap 1 # SKIP /bin/rm not found PASS: t/spy-rm.tap 2 - rm -f SKIP: t/spy-rm.tap 3 # SKIP /bin/rm not found

bug#10447: ‘parallel-test3.test’ doesn’t terminate on x86_64-unknown-freebsd8.2

Hi Stefano, Stefano Lattarini stefano.lattar...@gmail.com skribis: On 01/07/2012 10:52 PM, Ludovic Courtès wrote: Hi, Hi Ludo, thanks for the report. ‘parallel-test3.test’ doesn’t terminate on x86_64-unknown-freebsd8.2. For some reason, the ‘make -j1 check’ stopped after ‘foo4.test

bug#10447: ‘parallel-test3.test’ doesn’t terminate on x86_64-unknown-freebsd8.2

Hi, ‘parallel-test3.test’ doesn’t terminate on x86_64-unknown-freebsd8.2. For some reason, the ‘make -j1 check’ stopped after ‘foo4.test’, and thus the test sits forever waiting for ‘serial/test-suite.log’ to appear. Sorry I can’t provide more details. Does it ring a bell? Thanks, Ludo’.

bug#10448: dist-xz and dist-gzip cannot be combined?

Hi, The ‘master’ branch of Automake fails to produce both a tar.gz and tar.xz tarball. The former is empty, apparently because the source tree gets removed after the tar.xz is created: --8---cut here---start-8--- tardir=automake-1.11a ${TAR-tar} chof -

bug#9026: Supporting $ACLOCAL_PATH?

Hello, On an FHS-style system, all macros are picked up from /usr/share/aclocal. Conversely, on a Stow/Nix-style installation, macros are to be found in /foo/automake/share/aclocal, /bar/guile/share/aclocal, /baz/pkg-config/share/aclocal, etc. It seems to me that the latter calls for user

bug#7995: Guile support in Automake

Hi Ralf, Andy already answered most of your questions, I think. Ralf Wildenhues ralf.wildenh...@gmx.de writes: - The current tests assume _GUILE sources are distributed by default; OTOH, _LISP are not. Rationale for this semantic difference? In a typical project, 90% of the .scm files are

bug#7995: [PATCH 1/4] Documentation for Guile support.

Hi Ralf, Ralf Wildenhues ralf.wildenh...@gmx.de writes: +@example +guile_GUILE = compiled-and-installed.scm +nodist_guile_GUILE = not-distributed.scm +guile_DATA = not-compiled.scm +noinst_GUILE = compiled-but-not-installed.scm +dist_noinst_DATA = just-distributed-blob.scm + +# object

Re: Intermittent test failures

Hello Ralf, Ralf Wildenhues ralf.wildenh...@gmx.de writes: In addition to the previously posted patch, I'm thus applyin the one below, and merging both into master. master should be regression-free now, the testsuite should hopefully pass consistently. I'm interested in any remaining

Re: Intermittent test failures

Hi Ralf! Ralf Wildenhues ralf.wildenh...@gmx.de writes: * Ralf Wildenhues wrote on Sat, Jul 31, 2010 at 02:11:59PM CEST: * Ludovic Courtès wrote on Tue, Jul 27, 2010 at 11:08:39AM CEST: FYI the Automake test suite currently fails on Hydra. The build at http://hydra.nixos.org/build/502179

Re: mtime of installed files

Hello! Ralf Wildenhues ralf.wildenh...@gmx.de writes: Now I need to ask in more detail: do you actually need newer or just not older? Because if the latter, then you could just let the rule to install $(nodist_foobar_DATA) depend on the rule to install $(dist_foobar_SOURCES), the latter of

Re: mtime of installed files

Hi Ralf, Ralf Wildenhues ralf.wildenh...@gmx.de writes: * Ludovic Courtès wrote on Tue, Jul 20, 2010 at 06:28:46PM CEST: Background: Guile 1.9/2.0 has an auto-compilation feature whereby if a source file has no corresponding object file in the search path, or if the object file is older than

mtime of installed files

Hello, Background: Guile 1.9/2.0 has an auto-compilation feature whereby if a source file has no corresponding object file in the search path, or if the object file is older than the source file, then the source file is automatically recompiled and stored in ~/.cache/guile/ccache. Packages that

[PATCH] Fix sloppy tests for silent rules

Hello, I noticed on NixOS GNU/Linux that silent*.test would randomly fail (see http://hydra.nixos.org/build/477516.) The reason is that these tests would fail if “mv” is found in the standard output of ‘make’, but the random build directory names used by Nix could very well contain this string.

Re: [PATCH] Fix sloppy tests for silent rules

Oops, here’s the right patch: Make these tests more robust. Previously, they would fail if the name of the build directory contains `mv', which can very well happen with Nix. --- automake-1.11.1/tests/silent.test 2009-12-08 19:02:32.0 +0100 +++ automake-1.11.1/tests/silent.test

Re: [PATCH] Fix sloppy tests for silent rules

Hi, Stefano Lattarini stefano.lattar...@gmail.com writes: At Monday 05 July 2010, Ludovic Courtès wrote: I noticed on NixOS GNU/Linux that silent*.test would randomly fail (see http://hydra.nixos.org/build/477516.) The reason is that these tests would fail if “mv” is found in the standard

Directory names should use $(PACKAGE_TARNAME), not $(PACKAGE)

Hello, I recently changed Guile so that PACKAGE is “GNU Guile” (instead of “guile”), while PACKAGE_TARNAME remains “guile”. In doing so, I noticed that: 1. $(distdir) is $(PACKAGE)-$(VERSION), but it should really be $(PACKAGE_TARNAME)-$(VERSION). 2. $(pkglibdir), $(pkgdatadir), etc.,

Re: preserving timestamps on installation

Hi Andy, Andy Wingo wi...@pobox.com writes: Where automake comes in is that installing a file touches its mtime, always, not preserving the mtime of the file being installed. Could it be solved with an `install-hook' target that would touch all the installed `.go' files? Thanks, Ludo'.

Re: Cross-directory support

Hi, Roumen Petrov bugtr...@roumenpetrov.info writes: Ludovic Courtès wrote: Questions: 1. Is it possible to avoid repeating `src/' in the second case? 2. Can we somehow arrange the second case so that `libfoo' is built in `$top_builddir/src' (as in the first case) rather than

Re: Failure of `make.test'

Hi, Stepan Kasal [EMAIL PROTECTED] writes: In short, I'd recommend that NixOS reconsider the patch. I actually reached the same conclusion and posted that suggestion to the Nix mailing list: http://thread.gmane.org/gmane.linux.distributions.nixos/662 We'll see what happens... Thanks,

Failure of `make.test'

Hi, This is with Automake 1.10.1 on GNU/Linux (NixOS), with Autoconf 2.62:

Re: Failure of `make.test'

Hi, Stepan Kasal [EMAIL PROTECTED] writes: to reproduce what the test does, try the following: Unfortunately, I can't run it with the in-tree Automake, because `autoreconf' won't find $prefix/share/aclocal-1.10, for instance. How can I make it use the in-tree files? Attached below please

Re: Failure of `make.test'

Hi, Stepan Kasal [EMAIL PROTECTED] writes: It means that make -w behaves strange on your platform. (Try replacing make -w with make at the top of the script; then the answer will be GNU, right?) You should report it to the vendor of your platform (NixOS). Yes, actually I had forgotten

Re: Failure of `make.test'

Hi, Ralf Wildenhues [EMAIL PROTECTED] writes: You could also write a patch letting automake/m4/make.m4 drop that extra output. Or at least show us what it is. The extra output [*] is (1) one line per goal sent to stderr, and (2) an additional \e[p sequence to stdout when `-w' is used: $