FYI, I've just updated copyright messages for the new year:
https://git.savannah.gnu.org/cgit/automake.git/commit/?id=6c8ff6a8f3c80f86e703a3fc2a0ffb81e87f0957
On Tue, Jan 18, 2022 at 8:14 AM Mike Frysinger wrote:
> currently the automake website only hosts one manual version -- the latest.
> when working with older code bases, especially when trying to update them
> to newer versions, it can be helpful to have the older manual available to
> quickly
On Fri, Apr 8, 2022 at 6:30 AM Bob Friesenhahn
wrote:
> Today I saw an announcement for a new version of gzip. It provided
> lots of data for how to verify the downloaded tarballs. I recently
> saw a very similar announcement for a new version of libtool. I am not
> sure where the template of
On Mon, May 23, 2022 at 1:48 PM Karl Berry wrote:
>
> I was going to bisect but if it doesn't fail for me in the first place...
> :(
>
> Thanks. Indeed, reconfiguring etc. got rid of those errors.
>
> Now a bunch (12) of the Python tests are failing for me, presumably
> because of previous
GS_N
I've just pushed the attached fix.
Introduced in v1.16.5-46-g38da1d906 and v1.16.5-45-g3099097d7
so this doesn't need a NEWS update.
Mike, can you add an automake test that would have caught this?
>From 208f103f2607eaed95aa0d227c5627b4363ffb7b Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date
On Tue, May 3, 2022 at 2:57 PM Karl Berry wrote:
>
> I see no reason why mv would be so crucial.
>
> Hmm, I guess you're right. Thanks for the analysis.
>
> The purpose of the stamp files is to avoid partial files being written
> (and screwing up future makes), but if the file is zero bytes,
On Tue, May 3, 2022 at 3:55 PM Nick Bowler wrote:
>
> On 2022-05-02, Karl Berry wrote:
> > - @echo '# dummy' >$@-t && $(am__mv) $@-t $@
> > + @: >>$@
> >
> > 1) does it actually speed anything up?
>
> The answer seems to be a resounding "yes". I tried one of my packages
> on an old slow
On Thu, Oct 6, 2022 at 1:28 PM Karl Berry wrote:
>
> No errors on RHEL7+autoconf2.71
>
> Puzzling. Can you easily try RHEL8 or one of its derivatives?
> It surprises me that that is the culprit, but it seems possible.
>
> I'm using autoconf-2.71, make-4.3, etc., compiled from source, but am
>
or this whole subsecond-mtime problem. With this set
to "sleep 1",
Do not use "sleep x" in the above tests. Use "$sleep" instead.
make: *** [maintainer/syntax-checks.mk:443: sc_tests_plain_sleep] Error 1
So I adjusted via the second attached change.
Now, I think it will succe
Some automake-generated code malfunctions when using the combination of
the subdir-objects option and non-literal _SOURCES. You can demonstrate
by changing automake's tests/pr224.test, replacing this line:
bar_SOURCES = foo/main.c
with these apparently equivalent ones:
f = foo
[EMAIL PROTECTED] (Karl Berry) wrote:
Could we have a new option in automake for making lzma-compressed
tarballs, a la bzip2? The package to use is lzma-utils, from
http://tukaani.org/lzma/. Generally, it compresses better and
uncompresses faster than bzip.
Not just better. Significantly
Eric Blake [EMAIL PROTECTED] wrote:
[adding bug-automake]
According to Jim Meyering on 2/19/2008 4:33 AM:
| But I am, having seen it myself. It happens when you have a stale symlink
| from an older copy of gnulib, but which now points nowhere because the
| file was renamed in gnulib
Eric Blake [EMAIL PROTECTED] wrote:
According to Andreas Schwab on 2/19/2008 2:32 PM:
| Under the influence of -L, does -xtype l work like -lname '*' in
| detecting just the broken symlinks?
|
| You don't use -L of course (it isn't supported by find 4.1 anyway).
| Note that with -L you
Dmitry V. Levin [EMAIL PROTECTED] wrote:
On Fri, Mar 07, 2008 at 03:27:19PM +0100, Jim Meyering wrote:
There have been over 50 change-sets since the last one, so...
Something odd happened with generated man/Makefile.in file,
it is no longer going to build and install manpages because all
Ralf Wildenhues [EMAIL PROTECTED] wrote:
* Jim Meyering wrote on Thu, Mar 20, 2008 at 06:49:35PM CET:
-dist_man_MANS = $(MAN)
+# We must include at least one literal name here, so that
+# automake-1.10.1 emits the required install-man* rules.
+dist_man_MANS = rm.1 $(MAN)
You can instead
On a quad-core system, building make -j7 distcheck
fails consistently like this: (note the parallel builds of rmdir.o)
CC nohup.o
CC readlink.o
CC rm.o
CC rmdir.o
make[3]: Entering directory `/c/coreutils/src'
CC readlink.o
CC stat.o
AR libver.a
Jim Meyering wrote:
On a quad-core system, building make -j7 distcheck
fails consistently like this: (note the parallel builds of rmdir.o)
Oh! I left out an important detail.
This is using automake built from up-to-the-minute next.
Ralf Wildenhues wrote:
* Jim Meyering wrote on Fri, Apr 10, 2009 at 02:07:53PM CEST:
On a quad-core system, building make -j7 distcheck
fails consistently like this: (note the parallel builds of rmdir.o)
CC nohup.o
CC readlink.o
CC rm.o
CC rmdir.o
make[3
Ralf Wildenhues wrote:
* Jim Meyering wrote on Fri, Apr 10, 2009 at 02:51:08PM CEST:
2009-04-10 Ralf Wildenhues ralf.wildenh...@gmx.de
Fix parallel distcheck failure.
* maint.mk (ALL_RECURSIVE_TARGETS): Add patch-check,
check-AUTHORS, maintainer-distcheck, vc-dist, taint
Hi Ralf,
I've just built automake-from-git on a newly-installed system
that lacked a C++ compiler. It failed like this:
220: Multiple languages FAILED (compile.at:249)
...
220. compile.at:204: 220. Multiple languages (compile.at:204): FAILED
(compile.at:249)
Jim Meyering wrote:
Hi Ralf,
Whoops.
This is for autoconf, but for automake.
I've just built automake-from-git on a newly-installed system
that lacked a C++ compiler. It failed like this:
220: Multiple languages FAILED (compile.at:249)
...
220. compile.at
Hello, Ralf,
Are you ready to release 1.11? ;-)
Using the latest from git/master (v1.10b-55-g27f63d4),
make check passed on each of the following systems:
Fedora rawhide
Fedora 10
Debian unstable
Red Hat Enterprise Linux Server 5.3
Ubuntu 9.04
on ubuntu, all libtool-related tests
I noticed my recent doc changes caused slightly-too-verbose
build output. This fixes it:
Cc'ing bug-automake, in case Ralf thinks it makes sense to let
the consistently capitalized name be used some day.
From d2480e520cda846b8adaa9f064e34a050e238875 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Ralf Wildenhues wrote:
* Jim Meyering wrote on Thu, Apr 01, 2010 at 10:06:03AM CEST:
I noticed my recent doc changes caused slightly-too-verbose
build output. This fixes it:
Cc'ing bug-automake, in case Ralf thinks it makes sense to let
the consistently capitalized name be used some day
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
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
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 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
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:
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:
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
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:
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
: 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
Akim Demaille wrote:
...
So, Karl, Jim, and others, would you accept that gendocs.sh
stopped generating a compressed tarball of split info files,
but would rather ship a compressed --no-split file?
Sounds fine to me, but gendocs.sh is Karl's baby ;-)
-cvs repository there.
Lvm2 and device-mapper were the first test subjects there:
http://sources.redhat.com/git/gitweb.cgi
]
2007-10-07 Jim Meyering [EMAIL PROTECTED]
Add lzma compression support.
* NEWS: Mention it.
* automake.in (handle_dist): Recognize dist-lzma
on the to-do list.
* Jim Meyering wrote on Sun, Oct 07, 2007 at 11:44:55AM CEST:
[BTW, if there's interest (ha!) I will set up a read-only git mirror
on sourceware.org of the primary automake-cvs repository there.
Lvm2 and device-mapper were the first test subjects there:
http
Ralf Wildenhues [EMAIL PROTECTED] wrote:
FWIW2, we could use subdirectories named after the test name rather than
using the PID. However, I've found myself running the same test in
parallel sometimes:
make check TESTS=foo.test # Stop with C^Z, then run same command again
and it causes
Ralf Wildenhues [EMAIL PROTECTED] wrote:
Hello Jim,
Somehow this got turned off again for Automake, as Benoit noted.
Any chance you could look into it?
It looks like it's going to the right place:
GIT_DIR=/vservers/cvs/srv/git/automake.git git config -l|grep glis
[EMAIL PROTECTED]
Are
Akim Demaille [EMAIL PROTECTED] wrote:
The problem is now that I don't seem to have write permissions
on Automake [3]. Could someone add me please? Thanks in advance.
Hi Akim,
I've just added you.
-
commit 6130d102ef0c70a60c231bceefc5a40a8908ade0
Author: Jim Meyering [EMAIL PROTECTED]
Date: Tue Dec 18 17:49:49 2007 +0100
* lib/gnupload (GPG): Don't use an absolute path.
This reverts part of the 2004-01-28 change
Ralf Wildenhues [EMAIL PROTECTED] wrote:
You just barely beat me! :-)
Hi Ralf (and welcome back ;-),
...
A NEWS entry and a couple of tests would be great, but fixing the above
is needed, too, as well as the nits below. Note that I'm quite OK with
reworking this patch myself, if you don't
From: Jim Meyering [EMAIL PROTECTED]
Date: Mon, 26 May 2008 16:51:38 +0200
Subject: [PATCH] eliminate some installation overhead
* lib/am/mans.am (install-man%SECTION%) [!%?NOTRANS_MANS%]:
When possible, install all man pages with a single invocation
of $(INSTALL_DATA).
---
lib/am/mans.am | 19
Ralf Wildenhues [EMAIL PROTECTED] wrote:
* Ralf Wildenhues wrote on Sun, Sep 14, 2008 at 03:23:45PM CEST:
Sigh, this was overly optimistic. With libtool libraries, the
eventual need to relink at install time requires that the ordering
is exactly the same as given in the Makefile.am lines.
Ralf Wildenhues [EMAIL PROTECTED] wrote:
Hello everyone,
These four patches implement parallel execution of TESTS in Automake,
adapted from the check.mk file Akim Demaille posted earlier. I would
be delighted about review, comments, bug reports, any feedback. There
are a couple of
[EMAIL PROTECTED] (Karl Berry) wrote:
It is not exactly simple to figure out how to delete (archive) files
from ftp.gnu.org and alpha.gnu.org with the ftp directives, and anyway
constructing the directive files and uploading them by hand is always a
pain.
This patch adds a --delete option so
Ralf Wildenhues [EMAIL PROTECTED] wrote:
thanks for the patch!
* Jim Meyering wrote on Wed, Nov 12, 2008 at 10:33:19PM CET:
lzma-utils is morphing into xz, and will yield a beta (aka stable API)
release of the xz package in the not too distant future.
What do you think of adding support
Ralf Wildenhues [EMAIL PROTECTED] wrote:
...
Anyway, thanks for the patch. Committed to master with only minor
modifications. It would be nice if you could test the new test to
ensure that it passes with 'xz' installed (I haven't done that on my
system yet, let's see if Debian uploads a
Ralf Wildenhues [EMAIL PROTECTED] wrote:
Hello Jim,
* Jim Meyering wrote on Tue, Nov 25, 2008 at 10:59:36AM CET:
I think it's a fine idea to disallow bogus (and potentially dangerous)
absolute names in automake's sanity.m4, but the existing code is not
sufficient.
Agreed.
To demonstrate
Ralf Wildenhues wrote:
For this patch, I'm unsure if we should even add it at all.
It adds an automake option to enable silent build rules.
Here's why I wrote it in the first place: if you are a distribution
and want to change all your packages to build silently, you may not
want to change
Hi Ralf,
I am using your new --silent-rules option (from the je-silent branch)
in coreutils, albeit only privately for now.
I would like to make it permanent/public, and noticed that
this is not yet on next. Do you need more testimonials?
Anything I can do to help?
Thanks for yet another useful
From 15b94859da3b658182e4a334f85fbf8e0ddb6ce2 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Wed, 18 Mar 2009 10:09:23 +0100
Subject: [PATCH] Fix a documentation typo.
* doc/automake.texi (Headers): Clarify the note telling when it's
better not to use noinst_HEADERS
Just noticed this in a diagnostic...
From 99d6d57d4dadeeafd8fef8f774d26c6e65886d89 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Tue, 31 Mar 2009 08:30:23 +0200
Subject: [PATCH] use more common spelling in diagnostic: s/canonic/canonical/
* automake.in (check_typos): s
Jim Meyering meyer...@redhat.com
+
+ manual: fix a trivial grammar error.
+ * doc/automake.texi (Invoking aclocal): Fix grammar.
+
2009-06-07 Ralf Wildenhues ralf.wildenh...@gmx.de
AM_PROG_GCJ: use AC_CHECK_TOOLS for gcj, for cross compilation.
diff --git a/doc/automake.texi b
d658959e28eaa19e1ae8e6f68ad1a39ec049af51 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Thu, 30 Jul 2009 15:55:04 +0200
Subject: [PATCH] AM_SANITY_CHECK: avoid a 1-second sleep, if possible
* m4/sanity.m4 (AM_SANITY_CHECK): Use stat to compare timestamps.
Perform the 1-second sleep only if necessary
Ralf Wildenhues wrote:
* Jim Meyering wrote on Thu, Jul 30, 2009 at 04:20:52PM CEST:
I noticed (by inspection, since I was looking at AM_SANITY_CHECK)
the unconditional 1-second sleep in coreutils' configure script,
and realized that it'd be easy to avoid it on modern systems:
either because
Ralf Wildenhues wrote:
Hello Jim,
* Jim Meyering wrote on Fri, Aug 14, 2009 at 09:33:11AM CEST:
Ralf Wildenhues wrote:
* Jim Meyering wrote on Thu, Jul 30, 2009 at 04:20:52PM CEST:
I deliberately chose not to use ls, because parsing
its output is not worth the trouble.
Could
Ralf Wildenhues wrote:
...
I've committed the patch now, to be merged in branch-1.11 and master,
with the only additional change to avoid a second sleep in the error
path.
Cheers, and thanks again, (and sorry for the multi-second delay ;-)
;-)
Thanks!
Stefano Lattarini wrote:
...
Hmm, I'm a bit leery of making things read-only, but making sure
the files contain a generated by ... line near the top seems a
good idea.
In truth, I don't find that much useful in order to prevent
unintentional editing: I have ended up too many times modifying
ffcd00af02f97d8990ee0f45ab82706803f10578 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Fri, 30 Oct 2009 12:02:22 +0100
Subject: [PATCH] Don't let an envvar setting of $fail cause build failure.
Without this change, in a project using an automake-generated
Makefile, make fail
Hi Ralf,
Running the latest automake with perl-5.11.2,
I saw a warning about a useless /d modifier.
This fixes it:
From 95a4deafaa2ca0c2a609b53eddb74a104f74da22 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sat, 28 Nov 2009 21:11:58 +0100
Subject: [PATCH] avoid a warning
project) will result in all directories being world-writable.
From 2d12a10952025e47c0487572c494ece9d6bd3a36 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sat, 28 Nov 2009 21:05:33 +0100
Subject: [PATCH] do not put world-writable directories in distribution tarballs
* lib/am
* 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
Ralf Wildenhues wrote:
* Jim Meyering wrote on Sun, Oct 03, 2010 at 12:35:57PM CEST:
* 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
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
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
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
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
---
() 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
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
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
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
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
+ 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:
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
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:
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
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:
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
101 - 200 of 298 matches
Mail list logo
