I ran coreutils make check tests 60 times (on Fedora 17, x86_64),
recording the results of each run like this:
for i in $(seq 100); do make -j25 check -C tests VERBOSE=yes \
RUN_EXPENSIVE_TESTS=no makerr-$i t=.||t=X; printf $t; done
They all passed, but I decided to compare a few, in
Stefano Lattarini wrote:
On 07/06/2012 12:10 AM, Diego Elio Pettenò wrote:
Il 05/07/2012 11:26, Stefano Lattarini ha scritto:
How so? Removal of $(mkdir_p) is only planned for Automake 1.13, that is
still unreleased.
Ehm Stefano, that's definitely not the case, I've been hitting that
issue
Stefano Lattarini wrote:
On 07/09/2012 09:22 AM, Jim Meyering wrote:
Hi Stefano,
I see that @mkdir_p@ is used in gettext's Makefile.in.in template:
# We use $(mkdir_p).
# In automake = 1.9.x, $(mkdir_p) is defined either as mkdir -p -- or as
# $(mkinstalldirs) or as $(install_sh) -d
Stefano Lattarini wrote:
On 07/09/2012 11:45 AM, Stefano Lattarini wrote:
On 07/09/2012 11:17 AM, Jim Meyering wrote:
- - The long-obsolete (since automake 1.10) @mkdir_p@ configure-time
-substitution and AM_PROG_MKDIR m4 macro will be removed in Automake
-1.13. The $(mkdir_p
a
locally exploitable race condition for those who run make distcheck with
a non-restrictive umask (e.g., 022) in a directory that is accessible by
others. A successful exploit would result in arbitrary code execution
with the privileges of the user running make distcheck -- game over.
Jim Meyering
Stefano Lattarini wrote:
On 07/06/2012 12:10 AM, Diego Elio Pettenò wrote:
Il 05/07/2012 11:26, Stefano Lattarini ha scritto:
How so? Removal of $(mkdir_p) is only planned for Automake 1.13, that is
still unreleased.
Ehm Stefano, that's definitely not the case, I've been hitting that
issue
Stefano Lattarini wrote:
On 07/09/2012 09:22 AM, Jim Meyering wrote:
Hi Stefano,
I see that @mkdir_p@ is used in gettext's Makefile.in.in template:
# We use $(mkdir_p).
# In automake = 1.9.x, $(mkdir_p) is defined either as mkdir -p -- or as
# $(mkinstalldirs) or as $(install_sh) -d
Stefano Lattarini wrote:
On 07/09/2012 11:45 AM, Stefano Lattarini wrote:
On 07/09/2012 11:17 AM, Jim Meyering wrote:
- - The long-obsolete (since automake 1.10) @mkdir_p@ configure-time
-substitution and AM_PROG_MKDIR m4 macro will be removed in Automake
-1.13. The $(mkdir_p
/ sub-directory. Obviously, we cannot
use the doc/ prefix in that case.
With this patch, automake (master) still passes make check.
From ae5038bb59ff9bf40567945683ce89aa680c2ad4 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sat, 30 Jun 2012 13:47:41 +0200
Subject: [PATCH
Stefano Lattarini wrote:
On 06/30/2012 01:53 PM, Jim Meyering wrote:
Hi Stefano,
Hi Jim, thanks for the report and patch.
I found that the following patch is required at least
for vc-dwim, where without it, make distcheck would
fail due to the presence of vc-dwim.t2d/ and all of the
files
Jim Meyering wrote:
Stefano Lattarini wrote:
Hi Jim.
On 06/10/2012 10:08 PM, Jim Meyering wrote:
I stumbled across one of these, so fixed all of them and added a new
syntax-check rule in gnulib's maint.mk to discourage recurrence:
http://thread.gmane.org/gmane.comp.lib.gnulib.bugs
I stumbled across one of these, so fixed all of them and added a new
syntax-check rule in gnulib's maint.mk to discourage recurrence:
http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/30912
From fa0cd34b38729a59a40fa946fc621df3ef0924cd Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer
Stefano Lattarini wrote:
Hi Jim.
On 06/10/2012 10:08 PM, Jim Meyering wrote:
I stumbled across one of these, so fixed all of them and added a new
syntax-check rule in gnulib's maint.mk to discourage recurrence:
http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/30912
From
Stefano Lattarini wrote:
The use of configure.in as Autoconf input has been deprecated for a
very long time in the Autoconf documentation, and the next version of
Autoconf (2.70) will start warning about it ar runtime as well (see
commit 'v2.69-4-g560f16b' or 2012-05-23, general: deprecate
Eric Blake wrote:
...
If anything, this issue shows that the Automake::XFile module (and
other similar modules as well) should live in their own git
repository, which both Autoconf and Automake should use as a
submodule -- and which (for $DEITY's sake!), should be unit-tested.
Any volunteer?
Stefano Lattarini wrote:
On 04/15/2012 09:15 PM, Stefano Lattarini wrote:
On 04/15/2012 08:48 PM, Jim Meyering wrote:
I have not tested it.
AFAIK, I don't have convenient access to such an old version of Perl.
Do you?
Yes; so I will test the patch, but not right now. I'll get back to you
Brendan O'Dea wrote:
On 15 April 2012 03:34, Jim Meyering j...@meyering.net wrote:
I would be happy to use the latest help2man, and at first thought
that's what we'd do, but it seems to require perl 5.008, which is
slightly newer than the current automake prereq of 5.006
[...]
PS
Stefano Lattarini wrote:
Hi Jim, thanks for the patch.
On 04/15/2012 06:48 PM, Jim Meyering wrote:
Thanks, Brendan. That was just what I needed.
Using the newer help2man induces these small improvements:
(patch below)
Here's the patch to make automake use that newer help2man:
From
: Jim Meyering meyer...@redhat.com
Date: Fri, 13 Apr 2012 17:58:04 +0200
Subject: [PATCH] build: use slightly older help2man, for improved portability
* doc/help2man: Downgrade to help2man-1.36.4, so that it does
not require Locale/gettext.pm, which is not available on a
default Fedora 16
Stefano Lattarini wrote:
On 04/11/2012 09:27 PM, Jim Meyering wrote:
Surprised by parallel build failures,
Oops *blush* I must admit that, while I usually run the testsuite with
a high degree of parallelism, I also usually run the build proper with
a simple make all, because that is so fast
Stefano Lattarini wrote:
On 04/12/2012 10:24 AM, Jim Meyering wrote:
Stefano Lattarini wrote:
On 04/11/2012 09:27 PM, Jim Meyering wrote:
Surprised by parallel build failures,
Oops *blush* I must admit that, while I usually run the testsuite with
a high degree of parallelism, I also
change (the one you posted below). WDYT?
Sure.
...
ACK with the nit above addressed.
-*-*-*-
From cc0d0cdb3e8ea2ececc4732d03e05ec4482af74d Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Thu, 12 Apr 2012 15:07:19 +0200
Subject: [PATCH 2/2] build: generate doc/*.1
Surprised by parallel build failures, I tracked them down:
From 3fcf1fe611140eb6677d5893719bec1d96f106db Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Wed, 11 Apr 2012 21:25:48 +0200
Subject: [PATCH] avoid parallel build failures
A parallel build would fail when two
Stefano Lattarini wrote:
On 04/05/2012 08:41 PM, Stefano Lattarini wrote:
Thanks to you for being flexible and patient. I've committed the patch
now. Soon more to follow, to remove the last make recursion (the one for
the testsuite).
Sigh, this is harder than I thought. For the moment,
Stefano Lattarini wrote:
Recursive make-based build systems tend to be slower, more fragile
and less faithful than flat ones. See Peter Miller's article
Recursive Make Considered Harmful for more a more in-depth
discussion:
http://miller.emu.id.au/pmiller/books/rmch/
While in the case
Stefano Lattarini wrote:
On 04/05/2012 03:55 PM, Jim Meyering wrote:
I am glad to see that you too are taking an interest in non-recursive make.
I've always liked how bison switched to non-recursive make, and recently
converted cppi to do the same (the final hold-out there is po/, since its
Stefano Lattarini wrote:
On 04/05/2012 06:10 PM, Jim Meyering wrote:
[SNIP reasonable observations]
Yes, but I haven't given up.
What about this: I conclude the transition to a non-recursive build
system by creating a top-level monolithic Makefile.am, then we do whatever
refactoring
Stefano Lattarini wrote:
* HACKING (Working with git) Generated files like 'configure',
'Makefile.in' and 'aclocal.m4' are not committed anymore in our
git repository by some months. Remove obsoleted advices that
Hi Stefano,
Sorry I didn't see this sooner:
s/advices/advice/
(you may want to
Stefano Lattarini wrote:
...
WDYT? If you agree, I can apply the change below to HACKING, and
implement the new branching policy starting from the Automke 1.12
release.
I agree.
IMHO, you won't go wrong following git.git's example.
diff --git a/HACKING b/HACKING
...
+* The Automake git
Stefano Lattarini wrote:
On 02/26/2012 10:02 AM, Stefano Lattarini wrote:
- many other projects (linux, git itself) seems to use them, and I
believe there's a reason for this (even if I've failed to find it
so far);
Here it is -- point 12 at:
39c13b5bc88dc2a3e28301e1d1a089bd13089c48 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sat, 25 Feb 2012 12:37:25 +0100
Subject: [PATCH] tests: avoid spurious failure when gcj is not installed
* tests/defs-static.in (GNU_GCJ, GNU_GCJFLAGS): Define.
* tests/Makefile.am (do_subust
-describe-SHA1.jpg ]
From 9888205813e24281527448d408b2e4e5075e2026 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sat, 25 Feb 2012 12:37:25 +0100
Subject: [PATCH] tests: avoid spurious failure when gcj is not installed
* tests/defs-static.in (GNU_GCJ, GNU_GCJFLAGS): Define
Stefano Lattarini wrote:
One ludicrously minor nit: we should put references to bug reports,
names of people to thanks, or old commits that introduced a regression
*before* the list of touched files, and always separated by a leading
and a trailing blank line; like this:
Adjusted and pushed.
Stefano Lattarini wrote:
On 02/25/2012 08:38 PM, Stefano Lattarini wrote:
But I should definitely improve HACKING and have it document the
standards and best practice for commit logs (since the GCS are sadly
weak and out-of-date in this regard).
And here is my attempt. WDYT? I will push
Stefano Lattarini wrote:
...
I propose to push the result of doing this:
$ git ci -m 'maint: run make update-copyright' -a
[maint aafc6b5] maint: run make update-copyright
1041 files changed, 1041 insertions(+), 1266 deletions(-)
Hmm... It now occurs to me that, if we apply such a
: Jim Meyering meyer...@redhat.com
Date: Sun, 12 Feb 2012 16:01:54 +0100
Subject: [PATCH] tests: avoid spurious new makefile-deps failure
* tests/makefile-deps.test: Tighten regexp to avoid matching
this new line of every Makefile.in: :) ;; \
---
tests/makefile-deps.test |4 ++--
1
. But that might mean moving them from gnulib proper to
a submodule of gnulib. I don't want to go there right now ;-)
From fd93630e5c6aa9a9775ae945787b9903bab2f6c6 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sun, 12 Feb 2012 16:57:42 +0100
Subject: [PATCH] maint: add a rule to use
Peter Rosin wrote:
This thread has stalled. To sum things up and get things going again,
the following is what I'd like to do. First commit the three patches
(that are replies to this message) on the msvc branch. Then merge msvc
into master and into branch-1.11.
2/3 and 3/3 are already
Stefano Lattarini wrote:
On 02/02/2012 11:41 PM, Peter Rosin wrote:
Stefano Lattarini skrev 2012-02-02 22:45:
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10434
OK, the attached patch fixes the two spurious failures of GCC forced into
Tru64 mode. About time I'd say.
But I'm
Stefano Lattarini wrote:
Hi Jim, thanks for the feedback.
On 02/06/2012 03:27 PM, Jim Meyering wrote:
Stefano Lattarini wrote:
[SNIP]
This seemed a good approach when this test was first introduced, as
it apparently increased coverage for the less used and less tested
dependency
Stefano Lattarini wrote:
On 02/03/2012 03:51 PM, Peter Rosin wrote:
Maybe depmod.tap should be replaced/rewritten with compilers that
simulate the different depmods? I could tinker with that a bit...
Yeah, I had thought about the possibility of such an approach, but was
reluctant to
Eric Blake wrote:
On 02/03/2012 11:29 AM, Peter Rosin wrote:
Jim Meyering skrev 2012-02-03 19:05:
Stefano Lattarini wrote:
On 02/03/2012 03:51 PM, Peter Rosin wrote:
Wait, there's a (trivial) conflict. But if I resolve that and go
on with the merge anyway we will end up with two different
In cppi (http://git.savannah.gnu.org/cgit/cppi.git), I am now using non-
recursive make via subdir-objects, modeled after the way bison does it.
I see that make clean is inefficient: one rm -f per .o file:
rm -fr *.o
rm -f *.o
rm -f lib/calloc.o
rm -f lib/close-stream.o
rm -f
Stefano Lattarini wrote:
On 02/02/2012 03:24 PM, Stefano Lattarini wrote:
On 02/02/2012 02:57 PM, Stefano Lattarini wrote:
The attached patch should take care of three of the remaining five
failures still present on latest Fedora (see automake bug#10418).
I will push to master shortly if
Stefano Lattarini wrote:
Hi Jim, thanks for the quick review.
...
+$@ = ;
+eval { open3(*STDIN, *STDOUT, *STDERR, am--no-such-command) };
+$@ =~ m/\bopen3:.*am--no-such-command/
+ or die Bad \$@ value: \$@\\n;
+ '; then
+: # OK. IPC::Open3 should be good enough.
+
Stefano Lattarini wrote:
I will push this series to master in a couple of days if there is
no objection.
Stefano Lattarini (4):
maintcheck: refactor rules checking '*.am' files
build: require GNU make to run the maintainer checks
maintcheck: take advantage of some GNU make features
Stefano Lattarini wrote:
Hi Jim, thanks for the report.
On 01/21/2012 10:17 PM, Jim Meyering wrote:
On master a few days ago I noticed new test failures on a
Fedora 16 system, due to the unprotected use of compress.
In tests/dist-formats.tap, I read this:
# Assume gzip(1) and compress
Stefano Lattarini wrote:
On 01/21/2012 10:17 PM, Jim Meyering wrote:
FAIL: vala-mix
And the attached patch (applied to maint) should take care of this
failure.
Thanks.
This reduces by one more my FAIL counter.
Subject: [PATCH] vala tests: add missing 'valac' requirement, and other
Stefano Lattarini wrote:
On 01/21/2012 10:17 PM, Jim Meyering wrote:
FAIL: vala-mix
And the attached patch (applied to maint) should take care of this
failure.
Thanks.
This reduces by one more my FAIL counter.
Subject: [PATCH] vala tests: add missing 'valac' requirement, and other
Stefano Lattarini wrote:
On 01/01/2012 04:35 PM, Jim Meyering wrote:
FAIL: parallel-tests-interrupt
==
I suspect a testsuite weakness here. Jim, could you please try out the
attached patch to see if it solves the issue?
Thanks. With that, all 16 parts
Stefano Lattarini wrote:
On 12/26/2011 11:26 PM, Jim Meyering wrote:
FAIL: tap-no-spurious-w
This is due to a backward-incompatible change in the newer TAP::Harness
releases. The attached patch (thoroughly commented) fixes this, and also
makes the behaviour of our awk TAP driver consistent
, perl, or even the C library (especially on 64
+# bit machines). Suggested by Jim Meyering in automake bug#10374.
(ulimit -v 1; sh -c :) skip_ no adequate 'ulimit' builtin found
-(ulimit -v 2; sh -c :) || skip_ no adequate 'ulimit' builtin found
-ulimit -v 2
-
-for i in 01 02 03 04
Stefano Lattarini wrote:
Hello automakers.
A look at:
http://git.savannah.gnu.org/cgit/automake.git/refs/heads
shows that it's probably time to tie up some loose ends there, by removing
redundant branches, and turning old and unactive ones into tags.
Here is my proposals:
* I
Stefano Lattarini wrote:
* README: Now that the automake testsuite uses the parallel-tests
driver, there is no need for the user to capture the stdout of
make check to determine which tests have failed: a detailed log
is automatically saved into the `tests/test-suite.log' file.
---
Stefano Lattarini wrote:
Hi Jim.
On Sunday 11 December 2011, Jim Meyering wrote:
Stefano Lattarini wrote:
Pushed to maint now (so that I will be able to take advantage
of it in the Automake 1.11.2 release process); attached is the
definitive patch.
...
diff --git a/HACKING b/HACKING
.
Suggestion from Jim Meyering.
Sorry for the noise,
Stefano
Stefano Lattarini wrote:
There are few problems with it though, that I've fixed.
More details below.
Hi Stefano,
Thanks for the thorough review and for correcting my errors.
On Friday 09 December 2011, Jim Meyering wrote:
Today I noticed that automake-generated Makefile's dist-xz rule
used
Stefano Lattarini wrote:
On Friday 09 December 2011, Stefano Lattarini wrote:
On Friday 09 December 2011, Jim Meyering wrote:
That looks like a fine solution, though I haven't tried it yet.
I did for a few simple cases (on Linux), it seems to work fine. Before
committing I'll try
Stefano Lattarini wrote:
On Saturday 10 December 2011, Jim Meyering wrote:
I have not taken the time to write a commit hook to warn me when
a git log fails to match the corresponding ChangeLog delta.
It doesn't seem worthwhile.
Absolutely agreed; especially because, as long as the ChangeLog
tarball; so don't
+ run make distcheck here on his behalf; instead ...
+ * HACKING (Release procedure): ... state here that make check
+ and make distcheck should be run before calling make git-dist.
+
2011-12-09 Jim Meyering meyer...@redhat.com
Stefano Lattarini
).
+ * HACKING (Release procedure): Don't tell to update README-alpha.
s/tell/say/
2011-12-09 Jim Meyering meyer...@redhat.com
Stefano Lattarini stefano.lattar...@gmail.com
diff --git a/HACKING b/HACKING
index 873243c..2268102 100644
--- a/HACKING
+++ b/HACKING
@@ -188,7
Stefano Lattarini wrote:
* NEWS: Remove some duplicated entries, and reorder some others,
and rename a subsection. This blunders are probably due to a
botched merge.
---
ChangeLog |7 +++
NEWS | 29 +
2 files changed, 16 insertions(+), 20
Stefano Lattarini wrote:
On Saturday 10 December 2011, Jim Meyering wrote:
Stefano Lattarini wrote:
* Makefile.am (git-dist): The developer might have already tested
might Hah.
The developers shall test extensively before finally creating
the release tarball would sound better? :-)
I
Stefano Lattarini wrote:
Pushed to maint now (so that I will be able to take advantage
of it in the Automake 1.11.2 release process); attached is the
definitive patch.
...
diff --git a/HACKING b/HACKING
index b6f214f..755bffd 100644
--- a/HACKING
+++ b/HACKING
@@ -203,7 +203,7 @@
*
Ralf Corsepius wrote:
On 12/09/2011 10:17 AM, Stefano Lattarini wrote:
Another patch to be applied after the 1.11.2 release.
While conceptually very simple, this patch is quite large in size,
since the diffs contain all the text of the removed configure and
Makefile.in files; so I've
Ralf Corsepius wrote:
On 12/09/2011 02:21 PM, Jim Meyering wrote:
Hi Ralf, It sounds like you're confusing with build-from-release-tarball.
No, I am not.
Then you must be looking at different projects than I am.
There are hundreds of GNU projects that have stopped
version-controlling generated
Stefano Lattarini wrote:
Hi Jim.
On Friday 09 December 2011, Jim Meyering wrote:
On 12/09/2011 10:17 AM, Stefano Lattarini wrote:
Another patch to be applied after the 1.11.2 release.
While conceptually very simple, this patch is quite large in size,
since the diffs contain all
Stefano Lattarini wrote:
I went for a middle-ground solution (sorta), by having the differences
generated on-the-fly. This entails a decise slowdown, which is
however absolutely bearable even on my slow desktop. See the attached
patch.
The code is a little more complicated than I'd like,
for very large tarballs, it defaults to -e (equivalent to -6e).
This limits the default memory requirements imposed on decompressors,
yet still gives very good compression ratios.
From 786d9b3e4ff4831dfea00b1010d24d23b399316e Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sat
Stefano Lattarini wrote:
...
And all of that is duplicated in the ChangeLog file diffs below.
Are you interested in generating ChangeLog from git logs?
Absolutely, but that's for a later change. Also, before going down that
Glad to hear it.
road, I'd like to have a vim syntax file able to
Stefano Lattarini wrote:
References:
http://lists.gnu.org/archive/html/automake/2011-10/msg6.html
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10026
At this point I think we are ready to release a beta version of 1.11.2,
and then ask for help on platform-testers to smoke out some more
Stefano Lattarini wrote:
References:
http://lists.gnu.org/archive/html/automake/2011-10/msg6.html
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10026
At this point I think we are ready to release a beta version of 1.11.2,
and then ask for help on platform-testers to smoke out some more
Stefano Lattarini wrote:
On Sunday 06 November 2011, Jim Meyering wrote:
I install my own versions of m4, autoconf, automake, libtool, etc.,
using --prefix=/p, and I put /p/bin earlier in PATH than /usr/bin, etc.
Because of that, I've always had to initialize
/p/share/aclocal/dirlist
was on the same line
as the option name. ]
From f2be2788fc3ee1710cf9a6f21ddc6ba33be29b90 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Fri, 4 Nov 2011 10:48:31 +0100
Subject: [PATCH] tests: avoid false positive due to change in --help
formatting
* tests/maintmode-configure
Stefano Lattarini wrote:
Hi Jim, sorry for the delay.
No problem, of course.
On Thursday 20 October 2011, Jim Meyering wrote:
...
Here you go, this is with the very latest autoconf early in my path,
but that seems not to matter. These are all due to lack of yylex.
Of yywrap, actually
+ exit_status=1
+ set +e
...
I haven't delved into it to see how this test could be succeeding for
anyone else, so the patch may well be wrong.
From 367df29afd3c875da003fb1cd927e3b2f8ae2197 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Thu, 20 Oct 2011 17:57:55 +0200
Subject
Stefano Lattarini wrote:
On Thursday 20 October 2011, Jim Meyering wrote:
Without the patch below, I would consistently see this failure:
FAIL: aclocal-print-acdir.test (exit: 1)
+ set -e
...
++ aclocal-1.11a -Werror --print-ac
Stefano Lattarini wrote:
Hello automakers.
I think it's about time to release automake 1.11.2 -- the `maint'
branch contains various bug fixes w.r.t. the 1.11.1 release (some
of them quite important), and offers some new small features and
various warnings/deprecations that should prepare
Stefano Lattarini wrote:
Hello automakers.
I think it's about time to release automake 1.11.2 -- the `maint'
branch contains various bug fixes w.r.t. the 1.11.1 release (some
of them quite important), and offers some new small features and
various warnings/deprecations that should prepare
Stefano Lattarini wrote:
Hi Jim, thanks for the report.
Hi Stefano,
Thanks for the quick response.
I built the latest and ran make check TESTSUITEFLAGS=-j20 on Fedora 15.
Note that the `TESTSUITEFLAGS' variable has no effect on Automake-generated
testsuite harness. What you probably
Stefano Lattarini wrote:
On Tuesday 21 June 2011, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Mon, Jun 20, 2011 at 11:12:23PM CEST:
Maybe we should also say that using TESTS_ENVIRONMENT to define a custom
test runner is now not only strongly deprecated (as it already was I hope),
Stefano Lattarini wrote:
...
I've seen a few projects that require their automake-managed tests
be run sequentially. I suspect that some maintainers will not be eager
to adapt their tests to run in parallel solely to accommodate a newer
version of automake. If you have only a dozen or so
Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Mon, Jun 20, 2011 at 10:22:28AM CEST:
[Adding bug-grep, dropping bug-coreutils and automake-patches]
re-adding the latter.
I've noticed that grep uses a definition of TESTS_ENVIRONMENT very similar
to that of coreutils (the one we've just
Here's a small fix for master:
From 5115c011c2f6689508020612ecee97775da7687f Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sun, 19 Jun 2011 12:29:18 +0200
Subject: [PATCH] doc: replace obsolete @vindex entry with a useful one
* doc/automake.texi (Program Sources): Do
Thank you!
That patch looks fine modulo two typos.
I'm folding in these corrections and have adjusted the
grammar in the commit log (included below).
diff --git a/tests/shell-or-perl b/tests/shell-or-perl
index ff92009..08604eb 100644
--- a/tests/shell-or-perl
+++ b/tests/shell-or-perl
@@ -1,7
Stefano Lattarini wrote:
On Thursday 05 May 2011, Jim Meyering wrote:
Green, Paul wrote:
Gentle Coreutils Developers,
[HUGE CUT]
To the automake folks, is there any reason not to do that?
Hi Jim. I'm in a middle of something else right now, so I'm
probably not going to look
Green, Paul wrote:
Gentle Coreutils Developers,
I am writing to notify you of an issue that I stumbled across while
building coreutils-8.12 on the Stratus OpenVOS platform.
Hi Paul,
Thanks for the detailed report.
I'm Cc'ing the automake list, since that's
the source of the compile script.
Is there any reason not to make the compile script
accommodate (in a race-free manner) situations like
the one described in http://debbugs.gnu.org/8616 ?
() and
of more informative skip messages; this patches will be applied to a new
temporary public branch testsuite-work, meant to be finally merged into
master (once it's stabilized).
From 2c8b68396a48f70de2856f0747968225f4906abf Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date
Stefano Lattarini wrote:
...
FAIL: self-check-dir.test (exit: 1)
===
...
FAIL: self-check-me.test (exit: 1)
==
...
These failures are due to a known incompatibity in how Zsh handles $0.
Anyway, currenty the automake testsuite
Hi Stefano,
Thanks for the speedy reply.
Stefano Lattarini wrote:
...
The patch is fine IMHO, I'll apply it in your name ASAP (adding a
reference to this bug report). Thanks.
Thanks.
...
FAIL: self-check-cleanup.test (exit: 1)
===
... [CUT] ...
+ ls
Stefano Lattarini wrote:
On Saturday 16 April 2011, Jim Meyering wrote:
Stefano Lattarini wrote:
...
FAIL: self-check-dir.test (exit: 1)
===
...
FAIL: self-check-me.test (exit: 1)
==
...
These failures are due
Ralf Wildenhues wrote:
...
Why not document framework_failure_?
For tests that use the `parallel-tests' Automake option, set the shell
variable `parallel_tests' to yes before including ./defs. Also,
use for them a name that ends in `-p.test' and does not clash with any
---
Hi guys,
It looks like I never sent this patch:
From 2a898e3a7bc80dac3506f8ef325a95ef375971ef Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Thu, 14 Oct 2010 16:39:22 +0200
Subject: [PATCH] tests: fix comment typo
* tests/substref.test: Fix grammar in a comment
Ralf Wildenhues wrote:
...
Jim, gnulib/tests/init.sh is GPLv3+ right now. We would like to use
code added/modified in commit v0.0-3988-g0ae8d63. Do you mind if we
copy that into Automake's testsuite setup, currently GPLv2+? AFAICS
you're the sole author of that and prior changes around
a summary and log that
also mention dist-bzip2:
From 3b9a100b24b734cfd4cf934740c2694a0fc263c9 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sat, 2 Oct 2010 22:30:02 +0200
Subject: [PATCH] dist-xz, dist-bzip2: don't hard-code -9: honor envvar settings
* lib/am/distdir.am (dist-xz
d2c29e15a77ab2a073cf64919ab320bfec001833 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sat, 2 Oct 2010 22:30:02 +0200
Subject: [PATCH] dist-xz: don't hard-code -9: honor setting of XZ_OPT
* lib/am/distdir.am (dist-xz): Do not hard-code xz's -9: that
made it impossible to override
Stefano Lattarini wrote:
While I don't feel qualified to discuss the merits of the matter here,
I have a couple of nits below...
Hi Stefano,
Thanks for the review!
On Monday 04 October 2010, Jim Meyering wrote:
...
Makefile.in |6 --
NEWS |5
Stefano Lattarini wrote:
...
BZIP2 environment variable
+For example, @samp{make dist-bzip2 XZ_OPT=-7}.
Ditto.
Thank you. Fixed.
Hmm... thinking better, since we are dealing with environment
variables here, shouldn't the correct idiom be:
$ BZIP2=-7 make dist-bzip2
instead? Or
* lib/am/distdir.am (dist-xz): Do not hard-code xz's -9: that
made it impossible to override. Instead, use its XZ_OPT envvar,
defaulting to -9 if not defined. Thus no change in behavior
when XZ_OPT is not set, and now, this rule honors the setting
of that envvar when it is set. Suggested by
101 - 200 of 298 matches
Mail list logo
