This is to announce automake-1.18.1, a stable release.
See the NEWS below for a brief summary of changes.
Download here (checksum and signature info below):
https://ftp.gnu.org/gnu/automake/automake-1.18.1.tar.gz (2.3MB)
https://ftp.gnu.org/gnu/automake/automake-1.18.1.tar.xz (1.6MB)
Use
77805.
>
> Making mdate-sh aware of S_D_E caused problems (info files getting
> rebuild) with the RH build, per Frederic's report at
> https://lists.gnu.org/archive/html/automake/2025-06/msg00016.html.
>
> Also, I'd like to hear confirmation from Frederic that my guess is
>
t's a good thing,
Fully agreed with your skepticism :).
Version 1.4.20 of m4 in Debian will not use autoreconf, and I think
it will be reproducible because I've already tested it.
Excellent. I think I'm going to revert the change in mdate-sh and push
out a bug-fix rele
On 6/23/25 16:25, Karl Berry wrote:
jcb> Could the right answer be to limit the effect of
SOURCE_DATE_EPOCH to timestamps that will appear in built files?
I'm afraid I'm not sure what you mean, Jacob.
When writing a timestamp into a file, use the SOURCE_DATE_EPOCH value
instead of a
El 23/6/25 a las 23:25, Karl Berry escribió:
jcb> Could the right answer be to limit the effect of
SOURCE_DATE_EPOCH to timestamps that will appear in built files?
I'm afraid I'm not sure what you mean, Jacob.
At any rate, before flailing around further, I'd like to understand why
the
Frederic's report at
https://lists.gnu.org/archive/html/automake/2025-06/msg00016.html.
Also, I'd like to hear confirmation from Frederic that my guess is
correct, or not, as to why the S_D_E-enabled mdate-sh caused makeinfo
reruns.
In other words, to understand what's really going on :). --thanks, karl.
On 6/22/25 17:12, Karl Berry wrote:
[...]
In other words, you've forced the texi file to be considered to have the
same mtime as the spec file, and that might well be newer than the
previously-generated (years and years ago) info files.
I don't know if that's what's really happening. Can you in
Hi Frederic,
So, I re-built Fedora packages and found that the patch I mentioned above
is actually creating a new dependency on packages that use automake:
It's so frustrating. The original tarball is (presumably) entirely
correct but the playing with pretend mtimes causes time
ve
is actually creating a new dependency on packages that use automake:
/builddir/build/BUILD/libextractor-1.13-build/libextractor-1.13/build-aux/missing:
line 85: makeinfo: command not found
WARNING: 'makeinfo' is missing on your system.
You should only need it if you modi
rlos for the info.)
>
>
Thanks, I'll make a mass rebuild during the weekend to see how it goes
with that.
>
> -
> test: adapt tests for SOURCE_DATE_EPOCH.
>
> From https://lists.gnu.org/archive/html/a
.)
-
test: adapt tests for SOURCE_DATE_EPOCH.
>From https://lists.gnu.org/archive/html/automake/2025-06/msg00016.html.
* t/mdate5.sh: allow years 19xx for old SOURCE_DATE_EPOCH.
* t/txinfo-vtexi3.sh: likewise.
* t/txinfo-vtexi4.sh: if SDE is set, use mdate-sh to parse it into
On 6/19/25 4:25 PM, Karl Berry wrote:
Hi Frederic - it would be better to send failures to bug-automake, so
they get bug numbers. But no big deal.
I'm facing a strange regression between 1.17.92 and 1.18 when
rebuilding Automake:
FAIL: t/txinfo-vtexi4
Are you se
Hi Frederic - it would be better to send failures to bug-automake, so
they get bug numbers. But no big deal.
I'm facing a strange regression between 1.17.92 and 1.18 when
rebuilding Automake:
FAIL: t/txinfo-vtexi4
Are you setting SOURCE_DATE_EPOCH in the failing build and if s
Hello,
I'm facing a strange regression between 1.17.92 and 1.18 when rebuilding
Automake:
FAIL: t/txinfo-vtexi4
=
txinfo-vtexi4: running makeinfo --version
texi2any (GNU texinfo) 7.2
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version
On Wed, Jun 4, 2025 at 3:03 PM Karl Berry wrote:
> I signed it. I'm one of the listed admins of the automake group on
> savannah (https://savannah.gnu.org/projects/automake/), so I don't know
> what you mean by "from the automake group". Jim is still the official
Hi Collin, Hi Karl
Thank you very much for your answers. It was mainly to be sure.
To package the automake we need to provide a keyring file to our build
service, and I miss to fetch the newest automake keyring where your key,
Karl, has been added. Therefore only your public gpg key
Karl Berry writes:
> I signed it. I'm one of the listed admins of the automake group on
> savannah (https://savannah.gnu.org/projects/automake/), so I don't know
> what you mean by "from the automake group". Jim is still the official
> automake maintainer, bu
Hi Valentin,
It seems that the key used to sign the archive is no longer the one
from the automake group.
I signed it. I'm one of the listed admins of the automake group on
savannah (https://savannah.gnu.org/projects/automake/), so I don't know
what you mean by "from the
Hello everyone,
Thanks for the new release of autoconf in 1.18, but It seems that the key
used to sign the archive is no longer the one from the automake group. Is
it intentional ?
Best,
Valentin Lefebvre
Linux Distribution Engineer - packager
Member of System Boot and Init team
SUSE Software
Hello!
Thanks for this release. It seems that the key used to sign the archive is
no longer the one from the automake group. Is it intentional ?
All the best,
Valentin Lefebvre
Linux Distribution Engineer - packager
Member of System Boot and Init team
SUSE Software Solutions Germany GmbH
56100
t seems that the key used to sign the archive is no longer the one from
the automake group. Is it intentional ?
All the best,
Valentin Lefebvre
Linux Distribution Engineer - packager
Member of System Boot and Init team
SUSE Software Solutions Germany GmbH
56100 Lorient, France
On Mon, Jun 2, 2025, at 3:58 PM, Nick Bowler wrote:
> Automake has a script called "bootstrap", the documentation says it is
> used to generate configure (and other files), presumably it was
> actually used for this purpose, and therefore it should be included.
Automake (and Au
> due to makefile build rules. Build rules are a simple technical issue,
> > > which have been solved before, and are even already supported by
> > > Automake.
> >
> > I agree wholeheartedly. The bootstrap script forms part of the
> > corresponding source
6:48:38PM -0500, Bob Friesenhahn wrote:
> > > It seems a shame that a distribution tarball will lack a source file
> > > due to makefile build rules. Build rules are a simple technical issue,
> > > which have been solved before, and are even already supported by
> >
> which have been solved before, and are even already supported by
> > Automake.
>
> I agree wholeheartedly. The bootstrap script forms part of the
> corresponding source code for configure and should definitely be
> included in the distribution.
>
> Automake is distri
due to makefile build rules. Build rules are a simple technical
> >> issue, which have been solved before, and are even already supported
> >> by Automake.
> >
> > I agree wholeheartedly. The bootstrap script forms part of the
> > corresponding source code for conf
ve been solved before, and are even already supported
>> by Automake.
>
> I agree wholeheartedly. The bootstrap script forms part of the
> corresponding source code for configure and should definitely be
> included in the distribution.
I generally agree with this. Everyth
On Sun, Jun 01, 2025 at 06:48:38PM -0500, Bob Friesenhahn wrote:
> It seems a shame that a distribution tarball will lack a source file
> due to makefile build rules. Build rules are a simple technical issue,
> which have been solved before, and are even already supported by
> Automa
It seems a shame that a distribution tarball will lack a source file due to
makefile build rules. Build rules are a simple technical issue, which have
been solved before, and are even already supported by Automake.
A project which requires being tethered to a particular computer server,
which
Hi Gavin,
https://lists.gnu.org/archive/html/bug-texinfo/2022-05/msg0.html
I wrote at the time (in a private email):
> Yes, I am still opposed. I believe it is wrong to include it in the
> distribution as it can delete or overwrite files from the distribution,
> with no w
On Sat, May 31, 2025 at 10:19 PM Karl Berry wrote:
> Or, wait, let's back up. Why is bootstrap in the tarball in the first
> place? Does every package distribute it? No, I see it's not in the GNU
> make or autoconf tarballs. So I guess automake should not include it
> ei
ps> I am not familiar with automake's development model, but in
general for all GNU packages, at least:
It's the same for Automake. (Not that I wrote any of Automake's
bootstrap script -- I don't believe it's changed in many years.)
Cf> running
Paul Smith writes:
> Aha!
>
> I am not familiar with automake's development model, but in general for
> all GNU packages, at least:
>
> The bootstrap script is for users who are checking the code out of a
> source control facility like Git or CVS, and building that way. For
> those people, they
On Sat, 2025-05-31 at 00:13 +0200, Christoph Grüninger via Discussion
list for automake wrote:
> I played around and this is the sequence the package process is
> currently executing:
>
> > tar ..
> > sh bootstrap
> > make
> > make install
>
> The is
Hi Karl,
thank you for the additional information and suggestions.
I played around and this is the sequence the package process is
currently executing:
> tar ..
> sh bootstrap
> make
> make install
The issue vanished after I remove the call to bootstrap. I checked and
it was not changed in t
Hi Christoph,
Note, that the issue arises when `make install` is called.
tar xf automake-1.18.tar.xz && configure --prefix=/tmp/a18 && make install
doesn't run makeinfo for me either. Or make install DESTDIR=/tmp/adest.
I can only surmise that something in your pr
On Thu, 2025-05-29 at 11:02 -0400, Nick Bowler wrote:
> On Thu, May 29, 2025 at 08:59:08AM +0200, Christoph Grüninger via
> Discussion list for automake wrote:
> > Note, that the issue arises when `make install` is called. I
> > attached the output of the call in verbose m
On Thu, May 29, 2025 at 08:59:08AM +0200, Christoph Grüninger via Discussion
list for automake wrote:
> Note, that the issue arises when `make install` is called. I attached the
> output of the call in verbose mode (V=1). I still cannot spot an issue.
Like others, I cannot reproduce any ma
DESTDIR=/home/abuild/rpmbuild/BUILD/automake-1.18-build/BUILDROOT V=1
[ 12s] restore=: && backupdir=".am$$" && \
[ 12s] am__cwd=`pwd` && CDPATH="${ZSH_VERSION+.}:" && cd . && \
[ 12s] rm -rf $backupdir && mkdir $backupdir &&a
Hi all,
Karl Berry writes:
> But when I unpack it and run configure and make, it isn't run.
> $ tar xf automake-1.18.tar.xz
> $ cd automake-1.18
> $ ./configure
> $ make
> ... no use of MAKEINFO ...
Likewise for me, doing 'make V=1 2>&1 | grep makeinfo' returns nothing.
Collin
Hi Christoph,
I wanted to update the openSuse package for Automake to 1.18. But I get
an error that makeinfo is not found. Past releases did no require
makeinfo. Is this an oversight?
Argh. Certainly makeinfo is not supposed to be required.
But when I unpack it and run configure
Hi!
I wanted to update the openSuse package for Automake to 1.18. But I get
an error that makeinfo is not found. Past releases did no require
makeinfo. Is this an oversight?
Kind regards,
Christoph
Build log:
[ 12s] + cd /home/abuild/rpmbuild/BUILD/automake-1.18-build
[ 12s] + /usr
This is to announce automake-1.18, a stable release.
See the NEWS below for a brief summary of changes.
Download here (checksum and signature info below):
https://ftp.gnu.org/gnu/automake/automake-1.18.tar.gz (2.3MB)
https://ftp.gnu.org/gnu/automake/automake-1.18.tar.xz (1.6MB)
Use a
On 16 Apr 2025, at 15:56, Ross Burton wrote:
>
> On 16 Apr 2025, at 15:00, Frederic Berat via Discussion list for automake
> wrote:
>>
>> On Fri, Apr 11, 2025 at 7:09 PM Karl Berry wrote:
>>
>>> This is to announce automake-1.17.92, a alpha release.
>&g
On 16 Apr 2025, at 15:00, Frederic Berat via Discussion list for automake
wrote:
>
> On Fri, Apr 11, 2025 at 7:09 PM Karl Berry wrote:
>
>> This is to announce automake-1.17.92, a alpha release.
>> See the NEWS below for a brief summary of changes.
>>
>> Downloa
On Fri, Apr 11, 2025 at 7:09 PM Karl Berry wrote:
> This is to announce automake-1.17.92, a alpha release.
> See the NEWS below for a brief summary of changes.
>
> Download here:
> https://alpha.gnu.org/gnu/automake/automake-1.17.92.tar.gz
> https://alpha.gnu.org/gnu
This is to announce automake-1.17.92, a alpha release.
See the NEWS below for a brief summary of changes.
Download here:
https://alpha.gnu.org/gnu/automake/automake-1.17.92.tar.gz
https://alpha.gnu.org/gnu/automake/automake-1.17.92.tar.xz
Please report bugs and problems to
(instead of
On Wed, Feb 26, 2025 at 12:53 AM Karl Berry wrote:
> This is to announce automake-1.17.90, a alpha release.
> See the NEWS below for a brief summary of changes.
>
> Download here:
> https://alpha.gnu.org/gnu/automake/automake-1.17.90.tar.gz
> https://alpha.gnu.org/gnu
On 24 Mar 2025, at 15:34, Karl Berry wrote:
>
> Hi Ross - back on this:
>
> | configure:2612: error: possibly undefined macro: AM_RUN_LOG
>
> What version of autoconf are you using? If it's not the original GNU
> Autoconf 2.72, maybe you could try that? That's what I'm using. I'm
> guessing Nick i
rom: Nick Bowler
To: Ross Burton
Cc: Karl Berry , "automake@gnu.org"
Subject: Re: automake-1.17.90 pretest released [alpha]
On Thu, Feb 27, 2025 at 06:23:42PM +, Ross Burton wrote:
..
> >| configure:2612: error: possibly undefined macro: AM_RUN_LOG
..
> A leaner test
On 3 Mar 2025, at 22:28, Karl Berry wrote:
>
>In a clean build with 1.17, autom4te.cache/traces.0 says:
>...
>But in a build with 1.17.90 that has previously been configured with 1.17:
>m4_if([$1], [1.17], [],
>
> Ross, do you have a $HOME/.config.site or other config.site file tha
In a clean build with 1.17, autom4te.cache/traces.0 says:
...
But in a build with 1.17.90 that has previously been configured with 1.17:
m4_if([$1], [1.17], [],
Ross, do you have a $HOME/.config.site or other config.site file that
might somehow be causing the different results? See
ough you get the error
> > pervasively :(. I tried cloning your repo:
[...]
> A leaner test case is icon-naming-utils. If I build that with
> automake 1.17.0, it works. If I build it _from clean_ with 1.17.90,
> it works.
>
> If I build it with 1.17.0 and then autoreconf with 1.17
e old build is not being purged when it should be?
I guess, but I have no idea what's going on with autom4te.
Zack, Paul, anyone?
A leaner test case is icon-naming-utils. If I build that with
automake 1.17.0, it works. If I build it _from clean_ with 1.17.90,
it works.
If
Resending another message from Ross with interesting info,
my reply follows. -k
Date: Thu, 27 Feb 2025 18:30:43 +
From: Ross Burton
To: Karl Berry
Subject: Re: automake-1.17.90 pretest released [alpha]
I need to eat but one quick datapoint from doing a three-way comparison with
meld.
In
Hi Ross,
| configure:2612: error: possibly undefined macro: AM_RUN_LOG
I've been unable to reproduce this, even though you get the error
pervasively :(. I tried cloning your repo:
git clone git://git.yoctoproject.org/matchbox-sato
PATH=/path/to/pretest/bin:$PATH
sh autogen.sh
grep AM_RUN_LO
> On 27 Feb 2025, at 12:53, Ross Burton wrote:
>
> On 26 Feb 2025, at 22:14, Ross Burton wrote:
>>
>> On 25 Feb 2025, at 22:59, Karl Berry wrote:
>>>
>>> This is to announce automake-1.17.90, a alpha release.
>>> See the NEWS below for a brief s
On 26 Feb 2025, at 22:14, Ross Burton wrote:
>
> On 25 Feb 2025, at 22:59, Karl Berry wrote:
>>
>> This is to announce automake-1.17.90, a alpha release.
>> See the NEWS below for a brief summary of changes.
>
> Good news: I found some breakage. Well, goodish.
On 25 Feb 2025, at 22:59, Karl Berry wrote:
>
> This is to announce automake-1.17.90, a alpha release.
> See the NEWS below for a brief summary of changes.
Good news: I found some breakage. Well, goodish.
With a fairly ancient but small configure.ac:
https://git.yoctoproject.org/matc
Is the plan for the next automake release to be automake 1.18?
Yes. Since there are new features. --thanks, karl.
* Karl Berry (k...@freefriends.org) wrote:
> This is to announce automake-1.17.90, a alpha release.
> See the NEWS below for a brief summary of changes.
[snip]
Is the plan for the next automake release to be automake 1.18?
--
Eric Dorland
43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93
This is to announce automake-1.17.90, a alpha release.
See the NEWS below for a brief summary of changes.
Download here:
https://alpha.gnu.org/gnu/automake/automake-1.17.90.tar.gz
https://alpha.gnu.org/gnu/automake/automake-1.17.90.tar.xz
Please report bugs and problems to
(instead of
PERL5OPT= $MAKE check || st=$?
Done, thanks.
Unsetting PERL5OPT before the test runs automake defeats the purpose of
using PERL5OPT here, which is that warnings raised while running
Automake should be fatal.
I know, but it seemed so minor to worry about it for this one test
On 2/6/25 17:42, Karl Berry wrote:
Unsetting it in the shell test driver could work,
Yep. That's what I had in mind, sorry I wasn't clear.
to the line that actually executes the Perl script
The t/parallel-tests-log-compiler-example.sh test (copied below) is
testing Auto
Unsetting it in the shell test driver could work,
Yep. That's what I had in mind, sorry I wasn't clear.
to the line that actually executes the Perl script
The t/parallel-tests-log-compiler-example.sh test (copied below) is
testing Automake tests, so the script is not invoke
On 2/5/25 16:18, Karl Berry wrote:
Hi Jacob,
If a plain "use warnings;" in a script overrides setting
PERL5OPT=-Mwarnings=FATAL,all in the environment,
Fortunately, it was my mistake. I got confused in the testing I was
doing. use warnings; in a script does not override that PERL5OPT
Hi Jacob,
If a plain "use warnings;" in a script overrides setting
PERL5OPT=-Mwarnings=FATAL,all in the environment,
Fortunately, it was my mistake. I got confused in the testing I was
doing. use warnings; in a script does not override that PERL5OPT
setting. I'll fix the intentional w
pt overrides setting
PERL5OPT=-Mwarnings=FATAL,all in the environment, then I was wrong and
using PERL5OPT like that will /not/ make warnings in Automake code
fatal, since every Automake module (should) "use warnings;" and thus end
up overriding them to the default of being non-fatal.
: allow running with fatal warnings given in PERL5OPT.
* HACKING: mention running the test suite with
PERL5OPT=-Mwarnings=FATAL,all in the environment at new Perl (and
Automake releases), to try to keep up with new Perl warnings.
Suggestion from Jacob Bachmeyer,
https://lists.gnu.org/archive/h
aking certain that new Perl warnings are noticed,
simply putting PERL5OPT='-Mwarnings=FATAL,all' in the environment when
running the testsuite should accomplish that. Run the testsuite once
with that and once without and compare the results for each new Perl
release.
Note that no spe
I have to admit I don't much like any method Jacob mentioned, or
anything else I can think of (sed ...) to munge core source files.
I don't know about the past, but I've never knowingly ignored a Perl
warning that's been reported or that I've seen. Going to these lengths
to have fatal warnings in
releases, and spamming end users who probably don't care.
Since that is clearly also causing problems for end users, I suggest we
should find a way to keep the FATAL => 'all' for automake and autoconf
running out of git (and in particular for our own test suites), but
downgrade it
On 1/31/25 11:22, Karl Berry wrote:
Maybe Automake shouldn't use:
use warnings FATAL => 'all';
Changed to just "use warnings;", as Jacob also noted.
I also took the opportunity to systematize on
use 5.006; use strict; use warnings;
all on one line
On Fri, Jan 31, 2025, at 12:22 PM, Karl Berry wrote:
> Maybe Automake shouldn't use:
> use warnings FATAL => 'all';
>
> Changed to just "use warnings;", as Jacob also noted.
>
> I also took the opportunity to systematize on
> use 5.00
Maybe Automake shouldn't use:
use warnings FATAL => 'all';
Changed to just "use warnings;", as Jacob also noted.
I also took the opportunity to systematize on
use 5.006; use strict; use warnings;
all on one line to reduce real estate usage.
Not all f
On 1/30/25 17:52, Karl Berry wrote:
[...]
Maybe Automake shouldn't use:
use warnings FATAL => 'all';
Agreed. I'm working on it. --thanks, karl.
Using "use warnings;" (and "use strict;") is good style in Perl,
however. The best o
it> Here's the thread where I have reported the issue to the perl community
https://github.com/Perl/perl5/issues/22954#issuecomment-2622966302
I hope they don't persist in warning about this common use of the !!
idiom in their next stable release.
Re the notes about the Aut
Igor Todorovski writes:
> This is the relevant code:
>
> return (!!$val == $neg) ? '##%' : '';
I've attached a patch that fixes this by quoting $val and the '!'
operators.
Maybe Automake shouldn't use:
use warnings FATAL => 'al
Thanks, I agree with removing `use warnings FATAL => 'all';` . This will make
it somewhat future proof in case new warnings are introduced in new versions of
Perl.
When is the next release of automake planned for?
Thanks,
Igor
From: Collin Funk
Date: Wednesday, January 29, 202
Here’s the thread where I have reported the issue to the perl community :
https://github.com/Perl/perl5/issues/22954#issuecomment-2622966302
From: Igor Todorovski
Date: Wednesday, January 29, 2025 at 4:48 PM
To: automake@gnu.org
Subject: automake-1.17 fails with latest Perl (5.41.8) - Possible
With the latest version of Perl (Perl 5.41.8), automake 1.17 exits due to an
error:
./bin/automake-1.17 ; echo $?
Possible precedence problem between ! and numeric eq (==) at
./bin/automake-1.17 line 6875.
255
This is the relevant code:
return (!!$val == $neg) ? '##%' : '';
This is to announce GNU Automake 1.17, a stable release.
[Thanks to Karl Berry for doing so much of work, preparing
for this release and even writing most of the following. ]
This release changes AM_PATH_PYTHON to prefer Python 3 to Python 2 (set
PYTHON beforehand to override the searching
On 2024-07-01 10:21, Zack Weinberg wrote:
> # clue Make that gen-foo also updated foo.h whenever foo.c is new
> foo.h: foo.c
> @:
>
> If I had to guess, I would guess that someone thought Make would be
> more likely to skip invoking a shell if the command was actually empty
> rather than "
On Sun, Jun 30, 2024, at 4:28 PM, Karl Berry wrote:
...
> introspection/%.h: introspection/%.c
> $()
...
> As an aside, I'm curious as to why the $() is used. It seems
> a mysterious way to do nothing. Do you know?
I don't know why someone chose to do it this way, but I do know that
GCC's Ma
On Sun, Jun 30, 2024 at 10:28 PM Karl Berry wrote:
> Hi Frederic,
>
> Hello,
> NetworkManager:
> Use of uninitialized value $var in string eq at
> /usr/share/automake-1.16/Automake/Variable.pm line 754, line
> 1169.
>
> From the Makefile.am you sent m
Hi Frederic,
NetworkManager:
Use of uninitialized value $var in string eq at
/usr/share/automake-1.16/Automake/Variable.pm line 754, line 1169.
>From the Makefile.am you sent me separately (attached here for the
record), it seems that is coming from the use of $() in:
introspect
reopen 71487
thanks
Dave Hart writes:
> After installing Libtool to the same prefix as the prerelease Automake, the
> problem disappeared.
I think you might have sent this to the wrong bug report.
Bug#71487 is an Emacs bug, see:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71487
(1) a macro definition of LT_INIT must be available at this time, and
> (2) the LT_INIT macro must actually be expanded directly, and
> (3) tracing must not be disabled.
>
> Normally aclocal will take care of (1). Since this tool is part of
> Automake, this is something you have chan
On 2024-06-29 07:28, Dave Hart wrote:
> I'm seeing a regression building ntpd on FreeBSD 12.1 amd64 with
> Autoconf 2.71 between Automake 1.16.5 and 1.16.92. I haven't filed a
> bug report yet as I'm trying to do my part to characterize it well and
> provide an easy re
l 2.4.6
I saw no interesting differences between various Automake versions after
1.16.5, nor with Autoconf 2.71 vs. 2.72. Let me know if there's more I can
do to home in on the problem.
--
Cheers,
Dave Hart
Hi Dave,
in case it affects a decision to release 1.17
Indeed. Thank you very much for the report (and the followup). The first
question that comes to mind: are you using the same version of libtool
in the various cases? --thanks again, karl.
It seems debbugs.gnu.org is down or running behind, so here's what I've
found. Further testing after I composed the report shows the Automake
1.16i prerelease also suffers the problem.
-- Forwarded message -
From: Dave Hart
Date: Sat, 29 Jun 2024 at 17:18
Subject
I'm seeing a regression building ntpd on FreeBSD 12.1 amd64 with Autoconf
2.71 between Automake 1.16.5 and 1.16.92. I haven't filed a bug report yet
as I'm trying to do my part to characterize it well and provide an easy
reproduction. It may well be a bug in our use of Automake,
I ran a mass rebuild on Fedora for packages that depend on automake with
this version.
Thank you!!
Out of 1330 packages built, I found the following failures.
Could be a lot worse!
NetworkManager
x2gokdrive
xorg-x11-server
Use of uninitialized value $var in string
Hello,
I ran a mass rebuild on Fedora for packages that depend on automake with
this version. Out of 1330 packages built, I found the following failures.
NetworkManager:
Use of uninitialized value $var in string eq at
/usr/share/automake-1.16/Automake/Variable.pm line 754, line 1169.
x2gokdrive
Hi Jim,
> > I created a Gnulib testdir (of all of Gnulib) with automake-1.16.92,
> > and built that on various platforms (from Alpine Linux to MSVC) [1].
> > Everything OK; all tests passed.
> >
> > Obviously this tests only a small part of the Automake functionality
On Fri, Jun 21, 2024, 16:46 Bruno Haible wrote:
> Jim Meyering wrote:
> > We're particularly interested in bugs or regressions in the actual
> > Automake functionality.
>
> I created a Gnulib testdir (of all of Gnulib) with automake-1.16.92,
> and built that on v
Jim Meyering wrote:
> We're particularly interested in bugs or regressions in the actual
> Automake functionality.
I created a Gnulib testdir (of all of Gnulib) with automake-1.16.92,
and built that on various platforms (from Alpine Linux to MSVC) [1].
Everything OK; all tests passed.
[Thanks to Karl Berry for doing so much of work again, preparing
for this release and even writing most of the following. ]
We are pleased to announce the GNU Automake 1.16.92 test release.
This is a release candidate for the upcoming automake-1.17.
It mostly attempts to eliminate a delay in
Why two blank lines, not just one as for the other scripts?
Slip of the editor. Will fix. Thanks for the sharp eyes. -k
1 - 100 of 2056 matches
Mail list logo
