bug#12041: Issues running the testsuite as root

On 07/24/2012 03:59 PM, Dennis Clarke wrote: > > However, for just right now, how would I run just that one test? > In this case: make check TESTS=t/primary-prefix-couples-force-valid Regards, Stefano

bug#12041: Issues running the testsuite as root

On 07/24/2012 03:33 PM, Dennis Clarke wrote: > >> These are known testsuite issues (not real bugs in automake), and have >> already been solved in the development version of Automake. So we don't >> need to worry about them. > > Okay .. this is a good thing. I guess we can expect a release on that

bug#12041: Issues running the testsuite as root (was: Re: bug#12041: GNU Automake 1.12.2 - FAIL 4 tests on SunOS5.10_sparcv9_64-bit)

severity 12041 minor retitle 12041 Issues running the testsuite as root thanks Hi Dennis, thanks for the report. On 07/24/2012 02:25 PM, Dennis Clarke wrote: > > > n.b.: see attached self-check-exit.log.gz > and GNU_Automake_1.12.2_SunOS5.10_sparcv9_64-bit.test.log.gz > and GNU_Aut

bug#11924: t/aclocal7.sh fails after updating from 1.12.1 to 1.12.2

Hi Peter. On 07/23/2012 09:01 PM, Peter Simons wrote: > Hi Stefano, > > > For future reference: the complete log (usually quite verbose, in the > > case of Automake tests) is automatically saved in the 't/aclocal7.log' > > file by the Automake test harness. > > on NixOS, those tests are usual

bug#11532: automake-1.12.0b self test failures: t/remake8b & t/remake9c

On 07/23/2012 05:26 PM, Simon Josefsson wrote: > Stefano Lattarini writes: > >> severity 11532 minor >> tags 11532 + moreinfo >> thanks >> >> Reference: >> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11532> >> >> On 05/21/2012 02:24

bug#7824: Automatic chaining of make suffix rules

On 07/23/2012 02:49 PM, Юрий Пухальский wrote: > > [SNIP] > >>> >>> Alas! My thing must be highly portable. I'm not sure who's guilty in >>> this case, maybe HP, >>> >> Well, their make is busted in another, more relevant way: >> >>

bug#9933: ylwrap bug

tags 9933 + moreinfo thanks Hi Bruce, sorry for the delay. On 11/01/2011 05:56 PM, Bruce Korb wrote: > On 11/01/11 09:22, Stefano Lattarini wrote: >>> AM_LFLAGS = @LEX_FL@ --header-file=$(LEX_HEADER) -DYY_NO_INPUT=1 >>> So ylwrap fires off the flex program and it run

bug#11909: automake 1.12.2 fails t/self-check-explicit-skips.sh on Mac OS X 10.7.4

tags 11909 + patch close 11909 thanks On 07/14/2012 01:38 PM, Stefano Lattarini wrote: > > On 07/11/2012 02:37 PM, Max Horn wrote: >> >> turns out there is one more test failure on Mac OS X 10.7.4, >> in t/self-check-explicit-skips.sh. >> > I can reproduce

bug#11532: automake-1.12.0b self test failures: t/remake8b & t/remake9c

severity 11532 minor tags 11532 + moreinfo thanks Reference: On 05/21/2012 02:24 PM, Simon Josefsson wrote: > Hi! I got two failures on my Ubuntu 12.04 LTS system, > see output below. > > FAIL: t/remake8b > FAIL: t/remake9c > Hi Simon, sorry

bug#11401: moreinfo

severity 11401 minor tags 11401 + moreinfo thanks I'm tagging this bug with "more info required", because we're still waiting to see how things will evolve on the Libtool side. Regards, Stefano

bug#7670: won't fix

tags 7824 + wontfix tags 7670 + wontfix close 7824 close 7670 thanks These bugs would IMHO be too expensive to fix, and anyway fixing them would only bring a very marginal gain (as the issues only affects few vendor makes, and only appears in unusual -- albeit admittedly fully legitimate -- setups

bug#11855: [PATCH 1/2] check: support colorized testsuite output by default

void spurious colorization of the output due to the use of the 'expect' program. * t/color-tests-opt.sh: New test, check that the 'color-tests' option is still recognized as a no-op. * t/list-of-tests.mk: Add the new test. Signed-off-by: Stefano La

bug#11855: [PATCH 2/2] tests: better name for a couple of tests

* t/color.sh: Rename ... * t/color-tests.sh: ... like this. * t/color2.sh: Rename ... * t/color-tests2.sh: ... like this. * t/list-of-tests.mk: Adjust. Signed-off-by: Stefano Lattarini --- t/{color.sh => color-tests.sh} |0 t/{color2.sh => color-tests2.sh} |0 t/list-of-te

bug#11855: [PATCH 0/2] Enable colorized testsuite output by default

Reference: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11855> The actual implementation is done by the first patch. The second on is just a minor testsuite cleanup "while we are at it". I intend to push this series by tomorrow. Regards, Stefano Stefano Lattarini (2):

bug#12009: Autoconf testsuite failure (likely spurious) with the development version of Automake

AUtoconf test 035 "autom4te preselections" is failing when run with developement versions of aclocal and automake installed in $PATH: -*-*-*- # -*- compilation -*- 35. tools.at:1162: testing autom4te preselections ... ./tools.at:1168: automake --version || exit 77 stde

bug#7648: ylwrap appears not to support bison's lalr1.cc skeleton

On 07/14/2012 11:34 AM, Stefano Lattarini wrote: > Reference: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7648> > > The bug has finally been fixed by Akim Demaille (kudos to him); the fix > will appear in the next maintenance version of Automake (1.12.3). > > S

bug#11932: Remove "#serial" lines from Automake-provided *.m4 files

tags 11932 + patch close 11932 On 07/13/2012 03:19 PM, Stefano Lattarini wrote: > Severity: minor > > The "# serial" lines are only considered by aclocal for the system-wide > third-party '.m4' files, not for the Automake-provided ones (and even in > that case

bug#11909: automake 1.12.2 fails t/self-check-explicit-skips.sh on Mac OS X 10.7.4

tags 11909 + patch thanks On 07/14/2012 01:38 PM, Stefano Lattarini wrote: > severity 11909 minor > thanks > > On 07/11/2012 02:37 PM, Max Horn wrote: >> Hi there, >> > Hi Max, sorry for the delay. > >> turns out there is one more test failure on Mac OS X

bug#11909: automake 1.12.2 fails t/self-check-explicit-skips.sh on Mac OS X 10.7.4

severity 11909 minor thanks On 07/11/2012 02:37 PM, Max Horn wrote: > Hi there, > Hi Max, sorry for the delay. > turns out there is one more test failure on Mac OS X 10.7.4, > in t/self-check-explicit-skips.sh. > I can reproduce the issue with bash 3.2 on Debian. > Looking at the code, I don't u

bug#11942: Oops, spurious report, ignore (was: Re: bug#11942: ylwrap appears not to support bison's lalr1.cc skeleton)

retitle 11942 Oops, spurious report, ignore tags 11942 notabug close 11942 thanks While replying to an old bug report, I've opened a new one by mistake. I'm closing it now. Sorry for the noise, Stefano

bug#11942: ylwrap appears not to support bison's lalr1.cc skeleton

Reference: The bug has finally been fixed by Akim Demaille (kudos to him); the fix will appear in the next maintenance version of Automake (1.12.3). See the thread: and

bug#11803: close bug report

severity 11803 minor close 11803 thanks Oops, I forgot to close this bug when we fixed it. Closing it now. Stefano

bug#11932: Remove "#serial" lines from Automake-provided *.m4 files

Severity: minor The "# serial" lines are only considered by aclocal for the system-wide third-party '.m4' files, not for the Automake-provided ones (and even in that case, they are considered only when the '--install' aclocal option is used). So they serve no real purpose in the Automake '.m4' fi

bug#11898: [PATCH] tests: verify the shell test scripts are syntactically valid

tags 11898 + patch close 11898 thanks On 07/11/2012 11:30 AM, Stefano Lattarini wrote: > [PATCH] tests: verify the shell test scripts are syntactically valid > > This measure of extra safety is mostly motivated by the fact that some > shells (at least some versions of Bash in the

bug#10766: bug#11893: Regression in automake 1.12.1 on Mac OS X

On 07/12/2012 09:36 PM, Eric Blake wrote: > On 07/12/2012 12:42 PM, Stefano Lattarini wrote: > >> >> In the light of our discussion, attached is the patch I'd finally like >> to push. WDYT? > > Looks fine to me (although I have not actually tested it). > Pushed now. Thanks, Stefano

bug#8880: depcomp for Portland Group Compilers: get rid of file locking hack?

l builds. Use a locking strategy to avoid stomping on # the same $tmpdepfile. In particular, I propose the attached patch. Can you give it a try to check whether it works? Thanks, Stefano >From d847fe2011811a1f924ac4bb0502d4802ab94c5e Mon Sep 17 00:00:00 2001 Message-Id: From: Stefano Lattarini

bug#8880: [PATCH] add pgcc support to depcomp

171549080a91514374cff7341d9c08e.1342121162.git.stefano.lattar...@gmail.com> From: Dave Goodell Date: Thu, 12 Jul 2012 21:25:46 +0200 Subject: [PATCH] depcomp: initial support for Portland Group Compilers * lib/depcomp: Here. See automake bug#8880. Co-authored-by: Jeff A. Daily Acked-

bug#8880: [FYI] {depcomp-pgcc} depcomp: style changes to Portland Group Compilers support

nd send them to standard error rather than to standard output. Signed-off-by: Stefano Lattarini --- lib/depcomp | 37 ++--- 1 file changed, 18 insertions(+), 19 deletions(-) diff --git a/lib/depcomp b/lib/depcomp index 8619fcb..0544c68 100755 --- a/lib/depcomp ++

bug#10766: bug#11893: Regression in automake 1.12.1 on Mac OS X

On 07/12/2012 07:06 PM, Eric Blake wrote: > On 07/12/2012 10:23 AM, Stefano Lattarini wrote: > >>> Other than that, the only supported method in existing POSIX for >>> checking for equal files is by parsing 'ls -i' output; but I don't know >>> if &#

bug#11924: t/aclocal7.sh fails after updating from 1.12.1 to 1.12.2

forcemerge 11924 11896 close 11924 thanks On 07/12/2012 10:15 AM, Peter Simons wrote: > Hi, > Hi Peter, thanks for the report. > we have recently updated from Automake 1.12.1 to 1.12.2 in the NixOS Linux > distribution. That change caused a unit test failure in t/aclocal7.sh. The > complete buil

bug#10766: bug#11893: Regression in automake 1.12.1 on Mac OS X

Hi Eric. On 07/12/2012 05:48 PM, Eric Blake wrote: > On 07/12/2012 08:37 AM, Stefano Lattarini wrote: > >>>> Agreed (albeit it does its dirty work for now). Any suggestion on >>>> how to make it more reliable? >>> >>> Is test /usr/bin/CC -ef /u

bug#10766: bug#11893: Regression in automake 1.12.1 on Mac OS X

On 07/12/2012 04:00 PM, Peter Rosin wrote: > > Stefano Lattarini wrote: >> >> Since that requirement is only needed for bootstrapping, I could send >> you a (patched) tarball to test (so that you'll only require an >> autoconf >= 2.62). Would that be m

bug#10766: bug#11893: Regression in automake 1.12.1 on Mac OS X

Hi Peter. On 07/11/2012 11:21 PM, Peter Rosin wrote: > On 2012-07-11 14:44, Stefano Lattarini wrote: >> On 07/09/2012 07:04 PM, Max Horn wrote: >> >>> I am currently looking into packaging automake 1.12.1 for >>> Fink <http://www.finkproject.org/> on Mac

bug#11893: Regression in automake 1.12.1 on Mac OS X

more testsuite coverage "in the wild". # Note that we don't look for the MSVC C/C++ compiler here. This is # deliberate; for more discussion and rationale, see: # <http://lists.gnu.org/archive/html/automake-patches/2012-01/msg00130.html> Thanks, Stefano >From 66bcbd11febd14e5653482b57e33f

bug#11898: [PATCH] tests: verify the shell test scripts are syntactically valid

checks verifying that a script exits with non-zero status upon encountering a syntax error; as explained above, we can't depend on that. Signed-off-by: Stefano Lattarini --- I plan to push this by this evening or tomorrow. Regards, Stefano Makefile.am |

bug#11898: automake 1.12.2: self-check-exit.tap fails on Mac OS X 10.7.4

Max, could you keep the mailing list in the loop in your future replies, so that they will be registered in the bug tracker? Thanks. For this time, I'm quoting the relevant part of your reply, so no need to re-send. On 07/10/2012 05:44 PM, Max Horn wrote: > > On 10.07.2012, at 16:

bug#11898: automake 1.12.2: self-check-exit.tap fails on Mac OS X 10.7.4

severity 11898 minor thanks On 07/10/2012 04:26 PM, Max Horn wrote: > Hi there, > > there is another test failure I am experiencing on Mac OS X 10.7.4, > but this time I have no idea what's wrong (in particular, no idea > if this is a problem with my particular system; with OS X or with > automak

bug#11897: automake 1.12.2 test failure on Mac OS X 10.7

On 07/10/2012 04:30 PM, Max Horn wrote: > > On 10.07.2012, at 16:06, Stefano Lattarini wrote: > >> On 07/10/2012 03:56 PM, Max Horn wrote: >>> >>> This fixes most of the errors, except for >>> >>> PASS: t/suffix8.tap 10 >>> ERROR

bug#11897: automake 1.12.2 test failure on Mac OS X 10.7

6710143cfc4ac Mon Sep 17 00:00:00 2001 Message-Id: <65e7ac8c3556d1895ee597811856710143cfc4ac.1341929183.git.stefano.lattar...@gmail.com> From: Stefano Lattarini Date: Tue, 10 Jul 2012 15:29:57 +0200 Subject: [PATCH] tests: avoid spurious TAP errors on Mac OS X 10.7 Fixes automake bug#1897. Report

bug#11897: automake 1.12.2 test failure on Mac OS X 10.7

th our test results. > Perhaps you would like to workaround it by making the test a bit > more strict about how it detects a completed test step? > This is not possible; the '*.tap' tests in the Automake testsuite use the TAP protocol, and that mandates which output lines must be int

bug#11896: aclocal7.sh test fails sometimes with automake-1.12.2

ll older than the existing aclocal.m4, so we must sleep to ensure somedefs.m4 has an older timestamp than the aclocal.m4 the next aclocal call will generate. Copyright-paperwork-exempt: yes Signed-off-by: Stefano Lattarini --- t/aclocal7.sh |5 + 1 file changed, 5 insertions(+) diff --g

bug#11833: Testsuite summary for GNU Automake 1.12.1 # FAIL: 2

tags 11833 + moreinfo severity 11833 minor thanks Hi Dennis, sorry for the delay. On 07/01/2012 08:33 PM, Dennis Clarke wrote: > > on debian 6.0.5 amd64 : > > . > . > . > PASS: t/self-check-cleanup.tap 5 - post-cleanup removed null-perms testdir > PASS: t/self-check-cleanup.tap 6 - pre-cleanu

bug#11806: (setq load-path ..) of elisp-comp

On 07/06/2012 10:34 AM, Stefano Lattarini wrote: > > Thanks. I'll push the patch by this evening or afternoon if nobody > else speaks out. > Pushed now. I'm thus closing this bug report. Regards, Stefano

bug#11806: (setq load-path ..) of elisp-comp

On 07/06/2012 02:42 AM, Jack Kelly wrote: > On Fri, Jul 6, 2012 at 7:57 AM, Stefano Lattarini > wrote: >> Usually I'd agree, and in fact I had done as you're suggesting in a >> previous attempt; but that caused the test 'lisp3.sh' to fail :-/ >> With

bug#11806: (setq load-path ..) of elisp-comp

Hi Jack, thanks for the feedback. On 07/05/2012 11:33 PM, Jack Kelly wrote: > On Fri, Jul 6, 2012 at 3:56 AM, Stefano Lattarini > wrote: >> On 07/01/2012 01:03 AM, Jack Kelly wrote: >> Thanks. I've condensed a patch from you explanation (see attachment). >> I will

bug#11806: (setq load-path ..) of elisp-comp

ay out. > -- Jack Thanks, Stefano >From 5c94d97d90aa5b731a11c538f8b835e57bf39fee Mon Sep 17 00:00:00 2001 Message-Id: <5c94d97d90aa5b731a11c538f8b835e57bf39fee.1341510886.git.stefano.lattar...@gmail.com> From: Jack Kelly Date: Thu, 5 Jul 2012 18:50:37 +0200 Subject: [PATCH] lisp:

bug#11814: The test logs lost their title

> Le 29 juin 2012 à 19:01, Stefano Lattarini a écrit : > >> Hi Akim. > > Hi! > >> On 06/29/2012 09:17 AM, Akim Demaille wrote: >>> It seems that in recent changes, the test logs have lost >>> their title, which included the exit status. Now, read

bug#11863: Building test plugins

tags 11863 - moreinfo thanks On 07/05/2012 08:19 AM, Gary V. Vaughan wrote: > Hi Reuben, > > On 5 Jul 2012, at 05:39, Reuben Thomas wrote: >> On 4 July 2012 23:35, Stefano Lattarini wrote: >>> tags 11863 + moreinfo >>> thanks >>> >>> On 07/0

bug#11863: Building test plugins

tags 11863 + moreinfo thanks On 07/04/2012 10:43 PM, Reuben Thomas wrote: > I have a library that I want to build just for tests. Hence, I add it > to check_LTLIBRARIES. It's a plugin, so I want the .so (or .dll or > whatever) to be built, but it isn't! > It isn't built when you run "make check"?

bug#11855: Enabling the 'color-tests' option by default

Severity: wishlist Hello automakers. Anyone has an idea about why the 'color-tests' option should be not enabled by default (apart from the obvious historical reasons, that is)? Even when this option is on, the developer is free to disable testsuite coloring on a per-makefile basis (by adding "A

bug#11287: Various issues with the test suite framework

Reference: To sum up the actions related to this bug report: On 04/20/2012 01:13 PM, Akim Demaille wrote: > Hi! > > I have seen that check-html will be removed, or rather moved > into the contrib part, but there are a few issues: > > - the target is not declared r

bug#11287: [PATCH] contrib: simple improvements to check-html

the one in 'contrib/t/parallel-tests-html.sh'. Prefer 'mv -f' over bare 'mv'. Do not break the recipe in Signed-off-by: Stefano Lattarini --- contrib/check-html.am | 20 +--- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/contrib

bug#11287: [FYI] {master} contrib: check-html: pass flags to rst2html invocations

Related to automake bug#11287. * contrib/t/check-html.am (.log.html): Here, passing $(AM_RST2HTMLFLAGS) and $(RST2HTMLFLAGS) (in that order). Signed-off-by: Stefano Lattarini --- contrib/check-html.am |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/contrib/check

bug#11287: [FYI] {master} coverage: check-html can be used recursively

Addresses the main part of Automake bug#11287. * contrib/t/parallel-tests-html-recursive.sh: New test. * contrib/t/local.am: Add it. Signed-off-by: Stefano Lattarini --- contrib/t/local.am |1 + contrib/t/parallel-tests-html-recursive.sh | 163

bug#11791: [PATCH] {maint} parallel-tests: reimplement fix for bug#11791

On 07/01/2012 01:29 PM, Stefano Lattarini wrote: > * lib/am/check.am: Here. The new implementation is shorter, slightly > more efficient (requiring less forks), less brittle in the face of > signals or unexpected interruptions in the make process, and should > also be easier to merg

bug#11791: [PATCH] {maint} parallel-tests: reimplement fix for bug#11791

culties in merging our previous version of the fix in the 'ng/master' codebase, Automake-NG still lacks a fix for bug#11791). Signed-off-by: Stefano Lattarini --- I plan to push this by this evening. Regards, Stefano lib/am/check.am | 38 +++---

bug#11791: recheck and compilation error

Reference: <http://debbugs.gnu.org/11791> On 06/27/2012 03:08 PM, Stefano Lattarini wrote: > > I agree. The attached patch should solve the issue. It's more ugly > than I'd like, but this bug is annoying enough to make such ugliness > acceptable. I will push (to m

bug#11814: The test logs lost their title

tags notabug 11814 thanks Hi Akim. On 06/29/2012 09:17 AM, Akim Demaille wrote: > It seems that in recent changes, the test logs have lost > their title, which included the exit status. Now, reading > a log, one can no longer know how the test exited. > All of this is intended, because we now re

bug#11806: (setq load-path ..) of elisp-comp

Hi Makoto. Thanks for the report and the patch. On 06/28/2012 06:47 AM, Makoto Fujiwara wrote: > We have following line in automake-1.12.1/lib/elisp-comp. > > 73 mkdir $tempdir > 74 cp "$@" $tempdir > 75 > 76 ( > 77cd $tempdir > 78echo "(setq load-path (cons

bug#11803: missing:138 has trailing whitespace

tags 11803 notabug close 11803 thanks Hi Karl. On 06/28/2012 12:06 AM, Karl Berry wrote: > I saw there has been some discussion on bug-gnulib about removing > "missing" and some of the other "internal" autotools helper scripts from > gnulib. That makes sense, but I didn't see a final conclusion

bug#11793: [PATCH] docs: document AM_MISSING_PROG

AM_MISSING_PROG. I'm thus closing this bug report. Thanks, Stefano >From 78900b933039b7001443be126b63862430ec2648 Mon Sep 17 00:00:00 2001 Message-Id: <78900b933039b7001443be126b63862430ec2648.1340873870.git.stefano.lattar...@gmail.com> From: Stefano Lattarini Date: Thu, 28 Jun 2012 10:55:13 +0200 Subj

bug#11793: AM_MISSING_PROG undocumented

On 06/28/2012 12:01 AM, Eric Blake wrote: > On 06/26/2012 04:56 PM, Stefano Lattarini wrote: > >>>> AM_MISSING_PROG has been around for a while (git log says it was >>>> introduced in 1997, although the current two-argument version appears to >>>> dat

bug#11791: recheck and compilation error

to maint) in a couple of days if there are no objections. > Please find a script attached illustrating the behavior. > > This is with automake 1.12. > > Cheers, > Peter > Thanks, Stefano >From 2a3e45d6f3083c5152d94156f8b4e21366090c0f Mon Sep 17 00:00:00 2001 Message-Id:

bug#11793: AM_MISSING_PROG undocumented

On 06/26/2012 09:07 PM, Eric Blake wrote: > [adding bug-autoconf, for an autoconf documentation issue] > > On 06/26/2012 11:46 AM, Eric Blake wrote: >> [adding bug-automake, to turn into a formal bug] >> >> On 06/26/2012 11:39 AM, Eric Blake wrote: >> >>> And while looking into how M4 differs from

bug#11793: AM_MISSING_PROG undocumented

tags 11793 + wishlist thanks > On 06/26/2012 11:39 AM, Eric Blake wrote: > >> And while looking into how M4 differs from coreutils, I noticed that >> coreutils uses this via a .m4 file included into its configure.ac: >> >> AM_MISSING_PROG(HELP2MAN, help2man) >> >> which is roughly supposed to se

bug#11419: [PATCH] yacc, lex: new 'no-ylwrap' option to prevent use of the 'ylwrap' script

Hi Eric. On 06/26/2012 06:27 PM, Akim Demaille wrote: > > Le 26 juin 2012 à 18:18, Eric Blake a écrit : > >> Just from reading this summary, the idea of improving AC_PROG_LEX and >> AC_PROG_YACC to be more useful makes sense, especially if it would make >> automake easier to maintain. What sort

bug#11419: [PATCH] yacc, lex: new 'no-ylwrap' option to prevent use of the 'ylwrap' script

On 06/26/2012 04:34 PM, Akim Demaille wrote: > Hi Stefano, > > Thanks for this! > > Le 25 juin 2012 à 16:01, Stefano Lattarini a écrit : > >> When used with good yacc and lex implementations, like Flex and GNU Bison, >> the 'ylwarp' > >

bug#11419: [PATCH] yacc, lex: new 'no-ylwrap' option to prevent use of the 'ylwrap' script

ltiple.sh: New test, checks that if we get ylwrap out of the way, we can build a program using several lexers at once. * t/list-of-tests.mk (handwritten_TESTS): Add it. * t/yacc-bison-skeleton.sh: Use the 'no-ylwrap' option. This allow the test to pass, at last! * t/yacc-bison-skeleto

bug#11371: [Patch] fix silent-rules option

On 04/28/2012 09:24 PM, Stefano Lattarini wrote: > tags 11371 wontfix > thanks > No more activity on this bug report for a couple of months, thus I'm closing it. Regards, Stefano

bug#7434: When an incorrect option is used before --help/--version, automake behaviour is inconsistent with that of other GNU programs.

On 01/25/2011 06:36 PM, Stefano Lattarini wrote: > > Since it seems to me that we "agreed to differ" on this issue, I'm > tagging the report as "wontfix". > Actually, all of this discussion has basically become quite moot after we have decided to share the

bug#11146: texinfo: could automake start using the '--tidy' option in its dvi and pdf rules?

On 04/04/2012 11:45 AM, Stefano Lattarini wrote: > >> I'll thus apply to two attached patches to master in a couple of days >> if there is no objection. >> > Pushed now. > And the proposal for using '--tidy' in Automake 1.13 has been (basically) im

bug#8031: feature request: slow "make clean"

forcemerge 10697 8031 close 8031 thanks On 02/13/2011 08:52 PM, Ralf Hemmecke wrote: > This is a copy of > http://lists.gnu.org/archive/html/automake/2011-02/msg00017.html > It's not really a bug, but rather a feature request. > > Ralf > > Original Message > Subject: slow "make

bug#7689: wontfix

tags 7689 wontfix close 7689 thanks I'm closing this bug report. Packages that are not interested in being portable to non-GNU makes are now advised to use the Automake-NG fork instead: Regards, Stefano

bug#11419: ylwrap does not rename y.tab.h in y.tab.c

Reference: On 06/25/2012 10:25 AM, Akim Demaille wrote: > > Le 20 juin 2012 à 07:26, Akim Demaille a écrit : > >> >> Le 15 juin 2012 à 13:34, Akim Demaille a écrit : >> >>> I installed it, and some more tests, in maint, as follo

bug#11762: AM_PATH_PYTHON regression in automake 1.11.3

tags 11762 notabug close 11762 thanks On 06/22/2012 03:28 AM, Robert Collins wrote: > AM_PATH_PYTHON used to generate install logic like: > if test -z "$(DESTDIR)"; then \ > PYTHON=$(PYTHON) $(py_compile) --basedir "$(demodir)" $$dlist; \ > else \ >PYTHON=$(PYTHON) $(py_compile) --destd

bug#8665: [PATCH 0/3] Determine whether silent rules are active from inside a make recipe

On 06/11/2012 04:52 PM, Stefano Lattarini wrote: > [Resurrecting an old thread] > > Reference: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8665> > > Hi Jack, automakers, sorry for the shameful delay. > > This patch series (for maint) should take care of the &q

bug#10697: subdir-objects "make clean" invokes one rm for each .o file

On 06/10/2012 02:17 PM, Stefano Lattarini wrote: > Reference: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10697> > > See the attached patch; I will push it by tomorrow if there is no objection > (and if anyone would like to give it a try on a real project, that would be

bug#8665: [PATCH 0/3] Determine whether silent rules are active from inside a make recipe

the make recipes to determine whether make is being run in verbose mode (as with "make V=1") or quiet mode (as with "make V=0"). I will push by tomorrow if there is no objection. Regards, Stefano Stefano Lattarini (3): refactor: &define_verbose_var: accept a third op

bug#8665: [PATCH 1/3] refactor: &define_verbose_var: accept a third optional argument

This is only required by future changes. * automake.in (define_verbose_var): Accept a third optional argument, specifying the value to assign to the given make variable when silent rules are disabled. Signed-off-by: Stefano Lattarini --- automake.in | 25 - 1 file

bug#8665: [PATCH 2/3] refactor: silent rules handling (a little)

* automake.in (handle_languages): Move definition of $(AM_V_GEN) variable ... (define_verbose_tagvar): ... and of '$(AM_V_at)' variable ... (handle_silent): ... in this new subroutine. (generate_makefile): Call it. Signed-off-by: Stefano Lattarini --- automake.in | 14 ++--

bug#8665: [PATCH 3/3] silent: new $(AM_V_P) variable, tell if we're running in silent mode

didn't actually deal with user extension of silent rules ... * t/silent-obsolescent-warns.sh: ... into this test (bound to be removed once 'maint' is merged into the 'master' branch). * t/list-of-tests.mk: Add the new test. Signed-off-by: Stefano Lattarini --- NEWS

bug#10697: subdir-objects "make clean" invokes one rm for each .o file

ciated). Regards, Stefano >From 06dfdbe38e78c5eedb03f688f0264ec0097a4e21 Mon Sep 17 00:00:00 2001 Message-Id: <06dfdbe38e78c5eedb03f688f0264ec0097a4e21.1339330238.git.stefano.lattar...@gmail.com> From: Stefano Lattarini Date: Sun, 10 Jun 2012 13:38:58 +0200 Subject: [PATCH] subdir-objec

bug#11524: [platform-testers] Automake 1.12.0b test release

tags 11524 + moreinfo thanks Hi Dagobert. On 05/20/2012 11:57 AM, Dagobert Michelsen wrote: > Hi Stefano, > > Am 19.05.2012 um 16:17 schrieb Stefano Lattarini: >> The beta release "1.12.0b" of GNU Automake is now available at >> <ftp://alpha.gnu.org/gnu/automak

bug#11512: Testsuite summary for GNU Automake 1.12

On 05/29/2012 05:34 PM, Guido Trentalancia wrote: > > The attached 0001-perf-beginning-of-a-performance-testsuite.patch patch looks > conceptually fine to me. > I've pushed the patch, and I'm thus closing this bug report. Thanks, Stefano

bug#11512: Testsuite summary for GNU Automake 1.12

tags 11512 + patch tags 11512 - moreinfo thanks On 05/29/2012 10:01 AM, Stefano Lattarini wrote: > > Maybe the best fix is to remove the 'ulimit' usages, and > make this tests (and the few other ones oriented at checking Automake > performances) only run if the user/develo

bug#11512: Testsuite summary for GNU Automake 1.12

On 05/29/2012 12:35 AM, Guido Trentalancia wrote: > > [SNIP] > > The above mentioned perl test failures were due to a broken perl > installation. After re-installing perl, they complete successfully, > so please ignore the above. > OK. > The only test which fails is t/cond29.sh. > >>> FAIL: t/co

bug#11543: 3 test failures with automake-1.12.0 and perl-5.16.0

On 05/28/2012 11:20 PM, Matt Burgess wrote: > On Mon, 2012-05-28 at 13:47 +0200, Stefano Lattarini wrote: > >> Does the attached patch fixes your issue? > > Thanks, Stefano. That's fixed it. > Thanks for confirming. I've applied that patch, after squashing in

bug#11543: 3 test failures with automake-1.12.0 and perl-5.16.0

> Thanks, > > Matt. > Does the attached patch fixes your issue? Thanks, Stefano >From 72ed7e00f847ce1ab3c8d460a5a4dcc06a3c560a Mon Sep 17 00:00:00 2001 Message-Id: <72ed7e00f847ce1ab3c8d460a5a4dcc06a3c560a.1338205618.git.stefano.lattar...@gmail.com> From: Stefano Latta

bug#11512: Testsuite summary for GNU Automake 1.12

tags 11512 moreinfo severity 11512 minor thanks Hi Guido, thanks for the report, and sorry for the delay. On 05/18/2012 08:40 PM, Guido Trentalancia wrote: > > Testsuite summary for GNU Automake 1.12 > ==

bug#11422: automake 1.12 info doc installation problem

On 05/13/2012 07:21 PM, Roumen Petrov wrote: > Hi Stefano , > > What is final solution to use texinfo pages for GNU autotools > (autoconf,automake,libtool) ? > For what concerns the automake issue: I haven't looked into it yet, and likely I won't anytime soon; it is very very low priority for me.

bug#11452: self test failure: t/parallel-tests-fork-bomb

On 05/12/2012 08:44 AM, Stefano Lattarini wrote: > tags 11452 + patch > severity 11452 minor > thanks > > Hi Simon, thanks for the report. > > On 05/11/2012 10:45 AM, Simon Josefsson wrote: >> I got two self-test failures with automake 1.12 on Ubuntu 12.04 LTS. >

bug#11452: self test failure: t/parallel-tests-fork-bomb

the problem for you? Regards, Stefano >From 3f685ea79f9e42b4cd9351948889a9f9707803f9 Mon Sep 17 00:00:00 2001 Message-Id: <3f685ea79f9e42b4cd9351948889a9f9707803f9.1336804959.git.stefano.lattar...@gmail.com> From: Stefano Lattarini Date: Sat, 12 May 2012 08:42:37 +0200 Subject: [PATCH] tests: fix spur

bug#11401: automake-1.12 (incorrectly?) complains about missing AM_PROG_AR

On 05/04/2012 09:19 PM, Mike Frysinger wrote: > On Friday 04 May 2012 03:20:10 Peter Rosin wrote: >> On 2012-05-04 07:25, Mike Frysinger wrote: >>> >>> $ cat configure.ac >>> AC_PREREQ([2.63]) >>> AC_INIT([foo], [0]) >>> AM_INIT_AUTOMAKE([1.11 -Wall foreign]) >>> AC_PROG_CC >>> LT_INIT >>> AC_OUTPU

bug#11419: Get rid of ylwrap, and simplify yacc/lex rules

On 05/08/2012 12:48 PM, Akim Demaille wrote: > > On second thought, this is unfair to ylwrap. The issue is > rather that bison issues synclines which are relative the > cwd instead of relative to the path of the output file. > > [SNIP] > Well, good for us then :-) >> Or maybe we could get rid o

bug#11422: automake 1.12 info doc installation problem

severity 11422 minor tags 11422 + moreinfo thanks On 05/06/2012 06:13 PM, Bruno Haible wrote: > Hi, > Hi Bruno, sorry for the delay. > I have installed automake-1.12 a couple of days ago. In particular > the info format documentation was installed as well: > > [SNIP] > > The 'info' program finds

bug#11419: Get rid of ylwrap, and simplify yacc/lex rules (was: Re: FYI: maint: fix the generation of the synclines for bison's parser)

Severity: wishlist [Adding bug-automake in CC:] Hi Akim. On 05/06/2012 11:20 AM, Akim Demaille wrote: > This is taken from master. I work with a VPATH build, and the > generated synclines are very wrong. Probably something that > ylwrap should handle better btw. > Or maybe we could get rid of

bug#11413: Racy failure in test case 'tap-more.sh'

tags 11413 + patch close 11413 thanks On 05/05/2012 05:51 PM, Stefano Lattarini wrote: > Severity: minor > > I'm sporadically seeing the failure below in the test 'tap-more.sh'. > > Anyone has an insight about what's going on? > Such an insight is

bug#11413: Racy failure in test case 'tap-more.sh'

Severity: minor I'm sporadically seeing the failure below in the test 'tap-more.sh'. Anyone has an insight about what's going on? Regards, Stefano -*-*-*- tap-more: exec /bin/sh t/tap-more.sh Running from installcheck: no Using TAP: no PATH = [SNIP] ++ pwd /devel/stefano/src/am/branches/trun

bug#11034: [PATCH 0/2] cygnus: deprecate and remove

tags 11034 + patch close 11034 thanks On 04/30/2012 06:45 PM, Stefano Lattarini wrote: > > Stefano Lattarini (2): > cygnus: warn when it's used (flagged as 'obsolete' now) > cygnus: remove support for Cygnus-style trees > > The first patch deprecates suppo

bug#11377: configure.am - fails to remove configure before attempting replacement

tags 11377 + moreinfo severity 11377 minor thanks Hi Ronald, sorry for the delay. On 04/28/2012 10:55 PM, Ronald F. Guilmette wrote: > Under certain very reasonable scenarios, the configure file contained within > some source tree may perhaps be marked as read-only. > Before continuing, may I ask

<    1   2   3   4   5   6   7   8   9   10   >