[sr #110397] autoconf 2.70: autotest.m4 error

2020-12-08 Thread FX
Follow-up Comment #6, sr #110397 (project autoconf):

Without patch, outside of homebrew, installing automake 1.16.3 with autoconf
2.70 fails:


rmeur /tmp/autoconf-2.70 $ ./configure --prefix=/tmp
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... ./build-aux/install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... x86_64-apple-darwin20.1.0
checking host system type... x86_64-apple-darwin20.1.0
configure: autobuild project... GNU Autoconf
configure: autobuild revision... 2.70
configure: autobuild hostname... rmeur.local
configure: autobuild timestamp... 20201209T072029Z
checking for a shell whose -n mode is known to work... /bin/sh
checking for characters that cannot appear in file names... none
checking whether directories can have trailing spaces... yes
checking for expr... /bin/expr
checking for GNU M4 that supports accurate traces... /usr/bin/m4
checking whether /usr/bin/m4 accepts --gnu... no
configure: WARNING: the version of M4 that was found does not support -g
configure: WARNING: using it with POSIXLY_CORRECT set may cause problems
checking how m4 supports trace files... --error-output
checking for perl... /usr/bin/perl
checking whether /usr/bin/perl Fcntl::flock is implemented... yes
checking for emacs... no
checking for xemacs... no
checking for emacs... no
checking where .elc files should go... ${datadir}/emacs/site-lisp
checking for grep that handles long lines and -e... /usr/local/bin/ggrep
checking for egrep... /usr/local/bin/ggrep -E
checking for a sed that does not truncate output... /usr/bin/sed
checking whether make is case sensitive... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating tests/atlocal
config.status: creating Makefile
config.status: executing tests/atconfig commands
rmeur /tmp/autoconf-2.70 $ make install
/Applications/Xcode.app/Contents/Developer/usr/bin/make  install-am
rm -f bin/autom4te bin/autom4te.tmp
./build-aux/install-sh -c -d bin
srcdir=''; \
  test -f ./bin/autom4te.in || srcdir=./; \
  sed -e 's|@SHELL[@]|/bin/sh|g' -e 's|@PERL[@]|/usr/bin/perl|g' -e
's|@PERL_FLOCK[@]|yes|g' -e 's|@bindir[@]|/tmp/bin|g' -e
's|@pkgdatadir[@]|/tmp/share/autoconf|g' -e 's|@prefix[@]|/tmp|g' -e
's|@autoconf-name[@]|'`echo autoconf | sed 's,x,x,'`'|g' -e
's|@autoheader-name[@]|'`echo autoheader | sed 's,x,x,'`'|g' -e
's|@autom4te-name[@]|'`echo autom4te | sed 's,x,x,'`'|g' -e
's|@M4[@]|/usr/bin/m4|g' -e 's|@M4_DEBUGFILE[@]|--error-output|g' -e
's|@M4_GNU[@]||g' -e 's|@AWK[@]|awk|g' -e 's|@RELEASE_YEAR[@]|2020|g' -e
's|@VERSION[@]|2.70|g' -e 's|@PACKAGE_NAME[@]|GNU Autoconf|g' -e
's|@configure_input[@]|Generated from bin/autom4te.in; do not edit by hand.|g'
${srcdir}bin/autom4te.in >bin/autom4te.tmp
chmod +x bin/autom4te.tmp
chmod a-w bin/autom4te.tmp
mv bin/autom4te.tmp bin/autom4te
rm -f lib/autom4te.cfg lib/autom4te.cfg-t
./build-aux/install-sh -c -d lib
sed -e 's|@SHELL[@]|/bin/sh|g' -e 's|@PERL[@]|/usr/bin/perl|g' -e
's|@PERL_FLOCK[@]|yes|g' -e 's|@bindir[@]|/tmp/bin|g' -e
's|@pkgdatadir[@]|/tmp/share/autoconf|g' -e 's|@prefix[@]|/tmp|g' -e
's|@autoconf-name[@]|'`echo autoconf | sed 's,x,x,'`'|g' -e
's|@autoheader-name[@]|'`echo autoheader | sed 's,x,x,'`'|g' -e
's|@autom4te-name[@]|'`echo autom4te | sed 's,x,x,'`'|g' -e
's|@M4[@]|/usr/bin/m4|g' -e 's|@M4_DEBUGFILE[@]|--error-output|g' -e
's|@M4_GNU[@]||g' -e 's|@AWK[@]|awk|g' -e 's|@RELEASE_YEAR[@]|2020|g' -e
's|@VERSION[@]|2.70|g' -e 's|@PACKAGE_NAME[@]|GNU Autoconf|g' -e
's|@configure_input[@]|Generated from lib/autom4te.cfg.in; do not edit by
hand.|g' ./lib/autom4te.in >lib/autom4te.cfg-t
chmod a-w lib/autom4te.cfg-t
mv -f lib/autom4te.cfg-t lib/autom4te.cfg
./build-aux/install-sh -c -d lib/m4sugar
:;{ \
  echo '# This file is part of -*- Autoconf -*-.' && \
  echo '# Version of Autoconf.' && \
  echo '# Copyright (C) 1999, 2000, 2001, 2002, 2006, 2007, 2009' && \
  echo '# Free Software Foundation, Inc.' && \
  echo  &&\
  echo 'm4_define([m4_PACKAGE_NAME],  [GNU Autoconf])' && \
  echo 'm4_define([m4_PACKAGE_TARNAME],   [autoconf])' && \
  echo 'm4_define([m4_PACKAGE_VERSION],   [2.70])' && \
  echo 'm4_define([m4_PACKAGE_STRING],[GNU Autoconf 2.70])' && \
  echo 'm4_define([m4_PACKAGE_BUGREPORT], [bug-autoconf@gnu.org])' && \
  echo 'm4_define([m4_PACKAGE_URL],  
[https://www.gnu.org/software/autoconf/])' && \
  echo 'm4_define([m4_PACKAGE_YEAR],  [2020])'; \
} > lib/m4sugar/version.m4-t
mv lib/m4sugar/version.m4-t lib/m4sugar/version.m4
autom4te_perllibdir='.'/lib AUTOM4TE_CFG='lib/autom4te.cfg'
bin/autom4te -B ''lib -B '.'/lib  

[sr #110397] autoconf 2.70: autotest.m4 error

2020-12-08 Thread Carlo Cabrera
Follow-up Comment #5, sr #110397 (project autoconf):

Yes, of course. That makes sense. I'll need to look into finding you a machine
for remote shell access. 

However, the build scripts for automake and autoconf are very simple. For
automake, it (essentially) runs these commands in the build directory:

export PERL=/usr/bin/perl
./configure --prefix=$prefix
make install


Similarly, for autoconf:

export PERL=/usr/bin/perl
sed -i 's/libtoolize/glibtoolize/g' bin/autoreconf.in
sed -i 's/libtoolize/glibtoolize/g' man/autoreconf.1

./configure --prefix=$prefix --with-lispdir=$elisp
make install

rm -f info/standards.info


The modification to autoreconf.in is so that autoreconf uses Homebrew's (GNU)
libtool instead of Apple's libtool. Could the patch to autoreconf.{in,1} be
causing problems?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




autoconf-2.70 increases make check failure of automake on Solaris x86/x64

2020-12-08 Thread Kiyoshi KANAZAWA
Hello,
Installed autoconf-2.70, and found it increases make check failure of automake.

$ uname -a
SunOS hidden 5.11 11.3 i86pc i386 i86pc

$ gcc --version
gcc (GCC) 10.2.0


$ autoconf --version
autoconf (GNU Autoconf) 2.70

In automake-1.16.3 directory,
$ ./configure CC=gcc
$ make
$ make check

Following failures are detected.
FAIL: t/deprecated-acinit.sh
FAIL: t/distcheck-missing-m4.sh
FAIL: t/distcheck-outdated-m4.sh
FAIL: t/init.sh
FAIL: t/lex-clean-cxx.sh
FAIL: t/lex-depend-cxx.sh
FAIL: t/libobj-basic.sh
FAIL: t/remake-not-after-make-dist.sh

On the other hand, only 2 failure with autoconf-2.69.
PASS: t/deprecated-acinit.sh
PASS: t/distcheck-missing-m4.sh
PASS: t/distcheck-outdated-m4.sh
PASS: t/init.sh
FAIL: t/lex-clean-cxx.sh
FAIL: t/lex-depend-cxx.sh
PASS: t/libobj-basic.sh
PASS: t/remake-not-after-make-dist.sh


Regards,




[sr #110397] autoconf 2.70: autotest.m4 error

2020-12-08 Thread Zack Weinberg
Follow-up Comment #4, sr #110397 (project autoconf):

The aclocal command is part of automake; you need existing installed copies of
both autoconf and automake to run autoreconf -iv on either autoconf or
automake.  It's kinda the same thing as needing a C compiler already before
you can build gcc.  Normally this is only an issue if you're doing development
on these tools, though, because the tarball releases include pre-generated
copies of all the files that are generated by autoreconf -iv.

Is there a macOS machine that you could give me remote shell access to?  I
don't understand how Homebrew works particularly, but I could at least debug
the upstream build process for autoconf and automake in that environment.  I
can provide you with SSH keys.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[sr #110397] autoconf 2.70: autotest.m4 error

2020-12-08 Thread Carlo Cabrera
Follow-up Comment #3, sr #110397 (project autoconf):

Sorry, I just noticed you mentioning the automake configure script needing to
be regenerated with the new autoconf. That's not done in the CI run, which
just calls the configure script immediately. I just tried to run it locally
instead:


autoreconf: export WARNINGS=
autoreconf: Entering directory '.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
Can't exec "aclocal": No such file or directory at
/usr/local/Cellar/autoconf/2.70/share/autoconf/Autom4te/FileUtils.pm line
274.
autoreconf: error: aclocal failed with exit status: 2


This is the error from running `autoreconf --verbose` in the build directory
for automake. Adding `--install` or `--force` flags don't seem to help, but
I'll admit to having no idea what I'm doing here.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[sr #110397] autoconf 2.70: autotest.m4 error

2020-12-08 Thread anonymous
Follow-up Comment #2, sr #110397 (project autoconf):

Thanks for the quick response. Here are the autoconf and automake logs from
the CI node running macOS 11:
https://www.dropbox.com/s/ts1nx36buk3x7a8/logs.tar.gz?dl=1

The logs look similar on the nodes running 10.14 and 10.15, but let me know if
you'd like to have a look at them anyway.

You can also access the logs through the GitHub CI interface here:

https://github.com/Homebrew/homebrew-core/pull/66511/checks?check_run_id=1520593657

There is a way to access the raw logs and log archives for the whole CI run
through that interface if you need it.

Let me know if you need anything else.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[sr #110397] autoconf 2.70: autotest.m4 error

2020-12-08 Thread Zack Weinberg
Update of sr #110397 (project autoconf):

  Status:None => Need Info  

___

Follow-up Comment #1:

Thanks for the bug report.  It looks like the smoke-test code in your Homebrew
recipe was attempting to run autoconf (the command-line utility) on the file
Autoconf (the package) installs as
$prefix/share/autoconf/autotest/autotest.m4.  This file is not a configure
script, and running autoconf on it is not expected to work.  It looks like you
have already changed your recipe to do a more sensible smoke test.

It should be possible to build autoconf from the release tarball without
running `autoreconf -fiv` first and without having automake installed,
*unless* you patch configure.ac, Makefile.am, any of the files in the m4/ or
build-aux/ subdirectories, or any of the files with a .mk extension.

Could you please provide a link to the complete build log for the failed
attempt to build automake after regenerating its configure script with the new
autoconf?  That might indeed be a bug.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[sr #110397] autoconf 2.70: autotest.m4 error

2020-12-08 Thread anonymous
URL:
  

 Summary: autoconf 2.70: autotest.m4 error
 Project: Autoconf
Submitted by: None
Submitted on: Tue 08 Dec 2020 11:09:23 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: carlo.antonio.cabr...@gmail.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: Mac OS

___

Details:

Attempting to run autoconf 2.70 on the packaged autotest.m4 produces the
following error:

```
==> /usr/local/Cellar/autoconf/2.70/bin/autoconf autotest.m4
unknown channel m4trace: -1- _m4_warn(syntax, AC_INIT was never used, )
m4trace: -1- _m4_warn(syntax, AC_OUTPUT was never used, )
 at /usr/local/Cellar/autoconf/2.70/share/autoconf/Autom4te/Channels.pm line
631.
Autom4te::Channels::msg("m4trace: -1- _m4_warn(syntax, AC_INIT was never
used, )\x{a}m4tra"..., undef, undef, "partial", 0) called at
/usr/local/Cellar/autoconf/2.70/bin/autom4te line 1073
```

A similar error is generated when one attempts to build automake using the
newly built autoconf.

These errors were generated in Homebrew CI runs here:
https://github.com/Homebrew/homebrew-core/pull/66511

I can also reproduce the error quoted above on my local machine. Assistance
would be appreciated.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




Re: autoconf-2.70 released [stable]

2020-12-08 Thread John Calcote
Woohoo!! About time! :)

On Tue, Dec 8, 2020 at 12:14 PM Zack Weinberg  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> We are pleased to announce stable release 2.70 of GNU Autoconf.
>
> This release includes eight years of development work since the
> previous release, 2.69.  Noteworthy changes include support for the
> 2011 revisions of the C and C++ standards, support for reproducible
> builds, improved support for cross-compilation, improved compatibility
> with current compilers and shell utilities, more efficient generated
> shell code, and many bug fixes.  See below for a detailed list of
> changes since the previous version, 2.69, as summarized by the NEWS
> file.
>
> Unfortunately, we were not able to maintain perfect backward
> compatibility with existing Autoconf scripts.  Caution is advised when
> upgrading.  The list of changes, below, includes detailed explanations
> and advice for all of the compatibility problems we know about.
>
> Please report bugs and problems with this release to the Savannah bug
> tracker:
>
>https://savannah.gnu.org/support/?func=additem=autoconf
>
> Please also send general comments and feedback to .
>
> We would like to thank everyone who has contributed patches, reported
> problems, and helped testing Autoconf in the past decade.
>
> - -*-*-*-
>
> Here are the compressed sources:
>   https://ftpmirror.gnu.org/autoconf/autoconf-2.70.tar.gz   (2.0MB)
>   https://ftpmirror.gnu.org/autoconf/autoconf-2.70.tar.xz   (1.3MB)
>
> Here are the GPG detached signatures[*]:
>   https://ftpmirror.gnu.org/autoconf/autoconf-2.70.tar.gz.sig
>   https://ftpmirror.gnu.org/autoconf/autoconf-2.70.tar.xz.sig
>
> Use a mirror for higher download bandwidth:
>   https://www.gnu.org/order/ftp.html
>
> [*] Use a .sig file to verify that the corresponding file (without the
> .sig suffix) is intact.  First, be sure to download both the .sig file
> and the corresponding tarball.  Then, run a command like this:
>
>   gpg --verify autoconf-2.70.tar.gz.sig
>
> If that command fails because you don't have the required public key,
> then run this command to import it:
>
>   gpg --keyserver keys.gnupg.net --recv-keys 91FCC32B6769AA64
>
> and rerun the 'gpg --verify' command.
>
> This release was bootstrapped with the following tools:
>   Automake 1.16.3
>
> - -*-*-*-
>
> * Noteworthy changes in release 2.70 (2020-12-08) [stable]
>
> ** Backward incompatibilities:
>
> *** Warnings about obsolete constructs are now on by default.
>
>   These warnings can be turned off with ‘-Wno-obsolete’.
>
>   Many of these warnings advise maintainers to run autoupdate.
>   Be aware that autoupdate cannot solve all backward compatibility
>   problems, and cannot completely solve all of the problems it does
>   address.  A configure script edited by autoupdate is likely to
>   need further manual fix-ups.
>
> *** Many macros have become pickier about argument quotation.
>
>   If you get a shell syntax error from your generated configure
>   script, or seemingly impossible misbehavior (e.g. entire blocks of
>   the configure script not getting executed), check first that all
>   macro arguments are properly quoted. The “M4 Quotation” section of
>   the manual explains how to quote macro arguments properly.
>
>   It is unfortunately not possible for autoupdate to correct
>   quotation errors.
>
> *** Many macros no longer AC_REQUIRE as many other macros as they used to.
>
>   This can expose several classes of latent bugs.  These are the ones
>   we know about:
>
>- Make sure to explicitly invoke all of the macros that set result
>  variables used later in the configure script, or in generated
>  Makefiles.
>
>- Autoconf macros that use AC_REQUIRE are not safe to use in shell
>  control-flow constructs that appear outside of macros defined by
>  AC_DEFUN.  Use AS_IF, AS_CASE, etc. instead.  (See the
>  “Prerequisite Macros” section of the manual for details.)
>
>  The set of macros that use AC_REQUIRE internally may change from
>  release to release.  The only macros that are guaranteed *not* to
>  use AC_REQUIRE are the macros for acting on the results of a
>  test: AC_DEFINE, AC_SUBST, AC_MSG_*, AC_CACHE_CHECK, etc.
>
>- AC_REQUIRE cannot be applied to macros that need to be used with
>  arguments.  Instead, invoke the macro normally, with its arguments.
>
> *** More macros use config.sub and config.guess internally.
>
>   As a consequence of improved support for cross compilation (see below),
>   more macros now use the auxiliary scripts ‘config.sub’ and
> ‘config.guess’.
>   If you use any of the affected macros, these scripts must be available
>   when your configure script is run, even if you have no intention of
>   ever cross-compiling your program.
>
>   autoreconf will issue an error if any auxiliary scripts are needed but
>   cannot be found.  (It is not currently possible to make autoconf
>   itself issue this error.)
>
>   ‘autoreconf 

[sr #110396] autoconf 2.70 c99 check uses ac_c_conftest_c89_program

2020-12-08 Thread anonymous
URL:
  

 Summary: autoconf 2.70 c99 check uses
ac_c_conftest_c89_program 
 Project: Autoconf
Submitted by: None
Submitted on: Tue 08 Dec 2020 09:12:34 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

There is a typo in lib/autoconf/c.m4 that causes the C99 test to use the C89
test program variable instead.



___

File Attachments:


---
Date: Tue 08 Dec 2020 09:12:34 PM UTC  Name: autoconf-c99.diff  Size: 492B  
By: None
Fix C99 test typo


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[sr #109513] Release Autoconf 2.70

2020-12-08 Thread Zack Weinberg
Update of sr #109513 (project autoconf):

  Status: In Progress => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #4:

Autoconf 2.70 was released today:
https://lists.gnu.org/archive/html/autotools-announce/2020-12/msg1.html

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




autoconf-2.70 released [stable]

2020-12-08 Thread Zack Weinberg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

We are pleased to announce stable release 2.70 of GNU Autoconf.

This release includes eight years of development work since the
previous release, 2.69.  Noteworthy changes include support for the
2011 revisions of the C and C++ standards, support for reproducible
builds, improved support for cross-compilation, improved compatibility
with current compilers and shell utilities, more efficient generated
shell code, and many bug fixes.  See below for a detailed list of
changes since the previous version, 2.69, as summarized by the NEWS
file.

Unfortunately, we were not able to maintain perfect backward
compatibility with existing Autoconf scripts.  Caution is advised when
upgrading.  The list of changes, below, includes detailed explanations
and advice for all of the compatibility problems we know about.

Please report bugs and problems with this release to the Savannah bug
tracker:

   https://savannah.gnu.org/support/?func=additem=autoconf

Please also send general comments and feedback to .

We would like to thank everyone who has contributed patches, reported
problems, and helped testing Autoconf in the past decade.

- -*-*-*-

Here are the compressed sources:
  https://ftpmirror.gnu.org/autoconf/autoconf-2.70.tar.gz   (2.0MB)
  https://ftpmirror.gnu.org/autoconf/autoconf-2.70.tar.xz   (1.3MB)

Here are the GPG detached signatures[*]:
  https://ftpmirror.gnu.org/autoconf/autoconf-2.70.tar.gz.sig
  https://ftpmirror.gnu.org/autoconf/autoconf-2.70.tar.xz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.org/order/ftp.html

[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify autoconf-2.70.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys 91FCC32B6769AA64

and rerun the 'gpg --verify' command.

This release was bootstrapped with the following tools:
  Automake 1.16.3

- -*-*-*-

* Noteworthy changes in release 2.70 (2020-12-08) [stable]

** Backward incompatibilities:

*** Warnings about obsolete constructs are now on by default.

  These warnings can be turned off with ‘-Wno-obsolete’.

  Many of these warnings advise maintainers to run autoupdate.
  Be aware that autoupdate cannot solve all backward compatibility
  problems, and cannot completely solve all of the problems it does
  address.  A configure script edited by autoupdate is likely to
  need further manual fix-ups.

*** Many macros have become pickier about argument quotation.

  If you get a shell syntax error from your generated configure
  script, or seemingly impossible misbehavior (e.g. entire blocks of
  the configure script not getting executed), check first that all
  macro arguments are properly quoted. The “M4 Quotation” section of
  the manual explains how to quote macro arguments properly.

  It is unfortunately not possible for autoupdate to correct
  quotation errors.

*** Many macros no longer AC_REQUIRE as many other macros as they used to.

  This can expose several classes of latent bugs.  These are the ones
  we know about:

   - Make sure to explicitly invoke all of the macros that set result
 variables used later in the configure script, or in generated
 Makefiles.

   - Autoconf macros that use AC_REQUIRE are not safe to use in shell
 control-flow constructs that appear outside of macros defined by
 AC_DEFUN.  Use AS_IF, AS_CASE, etc. instead.  (See the
 “Prerequisite Macros” section of the manual for details.)

 The set of macros that use AC_REQUIRE internally may change from
 release to release.  The only macros that are guaranteed *not* to
 use AC_REQUIRE are the macros for acting on the results of a
 test: AC_DEFINE, AC_SUBST, AC_MSG_*, AC_CACHE_CHECK, etc.

   - AC_REQUIRE cannot be applied to macros that need to be used with
 arguments.  Instead, invoke the macro normally, with its arguments.

*** More macros use config.sub and config.guess internally.

  As a consequence of improved support for cross compilation (see below),
  more macros now use the auxiliary scripts ‘config.sub’ and 
‘config.guess’.
  If you use any of the affected macros, these scripts must be available
  when your configure script is run, even if you have no intention of
  ever cross-compiling your program.

  autoreconf will issue an error if any auxiliary scripts are needed but
  cannot be found.  (It is not currently possible to make autoconf
  itself issue this error.)

  ‘autoreconf --install’ will add ‘config.sub’, ‘config.guess’, and
  ‘install-sh’ to your source tree if they are needed.  If you are
  using Automake, scripts added to your tree by ‘autoreconf --install’
  will automatically be included in the tarball 

Re: autoreconf --install --force broke on files with no timestamps

2020-12-08 Thread Zack Weinberg
On Tue, Dec 8, 2020 at 7:09 AM Pascal Terjan  wrote:
>
> http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commit;h=40fa9edce6ad1a05988e4743a7ca64c3a8b3208d
> broke many things as it is no longer possible to use autoreconf
> --force --install to replace a file with no timestamp.
>
> A lot of install-sh files do not have one.

Fixed in c3afa488831e37137f3319f24456bb2cf7953acf.  Thanks for
catching this, it would have been an embarrassing bug to have in
2.70-final.

zw



autoreconf --install --force broke on files with no timestamps

2020-12-08 Thread Pascal Terjan
http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commit;h=40fa9edce6ad1a05988e4743a7ca64c3a8b3208d
broke many things as it is no longer possible to use autoreconf
--force --install to replace a file with no timestamp.

A lot of install-sh files do not have one.

A few examples:
http://pkgsubmit.mageia.org/autobuild/cauldron/aarch64/core/2020-12-06/rsync-3.2.2-2.mga8.src.rpm/build.0.20201207034825.log
http://pkgsubmit.mageia.org/autobuild/cauldron/aarch64/core/2020-12-06/ruby-2.7.2-33.mga8.src.rpm/build.0.20201208035913.log
http://pkgsubmit.mageia.org/autobuild/cauldron/aarch64/core/2020-12-06/socat-2.0.0-0.b9.9.mga8.src.rpm/build.0.20201207034825.log
http://pkgsubmit.mageia.org/autobuild/cauldron/aarch64/core/2020-12-06/sqlite3-3.34.0-1.mga8.src.rpm/build.0.20201208021354.log