Merge branch 'fix-pr13588-pax-hangs' into branch-1.13.2
authorStefano Lattarini <stefano.lattarini@gmail.com>
Tue, 30 Apr 2013 12:48:45 +0000 (14:48 +0200)
committerStefano Lattarini <stefano.lattarini@gmail.com>
Tue, 30 Apr 2013 12:48:45 +0000 (14:48 +0200)
* fix-pr13588-pax-hangs:
  tar: format 'ustar' cannot support UID/GID longer than 21 bits

1  2 
NEWS
THANKS
t/list-of-tests.mk

diff --combined NEWS
--- 1/NEWS
--- 2/NEWS
+++ b/NEWS
@@@ -1,59 -1,22 +1,59 @@@
 -New in 1.13.2:
 +* WARNING: New versioning scheme for Automake.
 +
 +  - Starting with this version onward, Automake will use an update and
 +    more rational versioning scheme, one that will allow users to know
 +    which kind of changes can be expected from a new version, based on
 +    its version number.
 +
 +    + Micro versions (e.g., 1.13.3, 2.0.1, 3.2.8) will introduce only
 +      documentation updates and bug and regression fixes; they will
 +      not introduce new features, nor any backward-incompatibility (any
 +      such incompatibility would be considered a bug, to be fixed with
 +      a further  micro release).
 +
 +    + Minor versions (e.g., 1.14, 2.1) can introduce new backward
 +      compatible features; the only backward-incompatibilities allowed
 +      in such a release are new *non-fatal* deprecations and warnings,
 +      and possibly fixes for old or non-trivial bugs (or even inefficient
 +      behaviours) that could unfortunately have been seen, and used, by
 +      some developers as "corner case features".  This kind of fixes
 +      should hopefully be quite rare.
 +
 +    + Major versions (now expected to be released every 18 or 24 months,
 +      and not more often) can introduce new big features (possibly with
 +      rough edges and not-fully-stabilized APIs), removal of deprecated
 +      features, backward-incompatible changes of behaviour, and possibly
 +      major refactorings (that, while ideally transparent to the user,
 +      could introduce new bugs).  Incompatibilities should however not
 +      be introduced gratuitously and abruptly; a proper deprecation path
 +      should be duly implemented in the preceding minor releases.
 +
 +  - According to this new scheme, the next major version of Automake
 +    (the one that has until now been labelled as '1.14') will actually
 +    become "Automake 2.0".  Automake 1.14 will be the next minor version,
 +    which will introduce new features and deprecation, but no backward
 +    incompatibility.
 +
 +  - See discussion about automake bug#13578 for more details and
 +    background: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578>
  
  * WARNING: Future backward-incompatibilities!
  
 -  - Automake 1.14 will require Autoconf 2.70 or later (which is still
 +  - Automake 2.0 will require Autoconf 2.70 or later (which is still
      unreleased at the moment of writing, but is planned to be released
 -    before Automake 1.14 is).
 +    before Automake 2.0 is).
  
 -  - Automake 1.14 will drop support for the long-deprecated 'configure.in'
 +  - Automake 2.0 will drop support for the long-deprecated 'configure.in'
      name for the Autoconf input file.  You are advised to start using the
      recommended name 'configure.ac' instead, ASAP.
  
    - The ACLOCAL_AMFLAGS special make variable will be fully deprecated
 -    in Automake 1.14 (where it will raise warnings in the "obsolete"
 +    in Automake 2.0 (where it will raise warnings in the "obsolete"
      category).  You are advised to start relying on the new Automake
      support for AC_CONFIG_MACRO_DIRS instead (which was introduced in
      Automake 1.13).
  
 -  - Automake 1.14 will remove support for automatic dependency tracking
 +  - Automake 2.0 will remove support for automatic dependency tracking
      with the SGI C/C++ compilers on IRIX.  The SGI depmode has been
      reported broken "in the wild" already, and we don't think investing
      time in debugging and fixing is worthwhile, especially considering
      modern Windows versions will continue to be fully supported.
  
    - Automake-provided scripts and makefile recipes might (finally!)
 -    start assuming a POSIX shell in Automake 1.14.
 +    start assuming a POSIX shell in Automake 2.0.
  
 -  - Starting from Automake 1.14, third-party m4 files located in the
 +  - Starting from Automake 2.0, third-party m4 files located in the
      system-wide aclocal directory, as well as in any directory listed
      in the ACLOCAL_PATH environment variable, will take precedence
      over "built-in" Automake macros.  For example (assuming Automake
      is installed in the /usr/local hierarchy), a definition of the
      AM_PROG_VALAC macro found in '/usr/local/share/aclocal/my-vala.m4'
      should take precedence over the same-named automake-provided macro
 -    (defined in '/usr/local/share/aclocal-1.14/vala.m4').
 +    (defined in '/usr/local/share/aclocal-2.0/vala.m4').
 +
 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 +
 +New in 1.13.2:
  
  * Obsolescent features:
  
  
  * Bugs fixed:
  
+   - When the 'ustar' option is used, the generated configure script no
+     longer risks hanging during the tests for the availability of the
+     'pax' utility, even if the user running configure has a UID or GID
+     that requires more than 21 bits to be represented.
+     See automake bug#8343 and bug#13588.
    - The obsolete macros AM_CONFIG_HEADER or AM_PROG_CC_STDC work once
      again, as they did in Automake 1.12.x (albeit printing runtime
      warnings in the 'obsolete' category).  Removing them has turned
      Automake 1.13, has turned out to be a similarly very bad idea,
      for exactly the same reason.
  
 +  - aclocal will no longer error out if the first local m4 directory
 +    (as specified by the '-I' option or the 'AC_CONFIG_MACRO_DIRS' or
 +    'AC_CONFIG_MACRO_DIR' macros) doesn't exist; it will merely report
 +    a warning in the 'unsupported' category.  This is done to support
 +    some pre-existing real-world usages.  See automake bug#13514.
 +
 +  - aclocal will no longer consider directories for extra m4 files more
 +    than once, even if they are specified multiple times.  This ensures
 +    packages that specify both
 +
 +        AC_CONFIG_MACRO_DIR([m4])       in configure.ac
 +        ACLOCAL_AMFLAGS = -I m4         in Makefile.am
 +
 +    will work correctly, even when the 'm4' directory contains no
 +    package-specific files, but is used only to install third-party
 +    m4 files (as can happen with e.g., "libtoolize --install").
 +    See automake bug#13514.
 +
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
  New in 1.13.1:
diff --combined THANKS
--- 1/THANKS
--- 2/THANKS
+++ b/THANKS
@@@ -48,7 -48,6 +48,7 @@@ Bob Friesenhahn                 bfriese
  Bob Proulx                      rwp@hprwp.fc.hp.com
  Bob Rossi                       bob@brasko.net
  Bobby Jack                      bobbykjack@yahoo.co.uk
 +Boris Kolpackov                 boris@codesynthesis.com
  Braden N. McDaniel              braden@endoframe.com
  Brandon Black                   blblack@gmail.com
  Brendan O'Dea                   bod@debian.org
@@@ -128,7 -127,6 +128,7 @@@ Ganesan Rajagopal               rganesa
  Garrett D'Amore                 garrett@qualcomm.com
  Garth Corral                    garthc@inktomi.com
  Gary V Vaughan                  gvaughan@oranda.demon.co.uk
 +Gavin Smith                     gavinsmith0123@gmail.com
  Geoffrey Keating                geoffk@apple.com
  Glenn Amerine                   glenn@pie.mhsc.org
  Gord Matzigkeit                 gord@gnu.ai.mit.edu
@@@ -226,6 -224,7 +226,7 @@@ Luo Yi                          luoyi.l
  Maciej Stachowiak               mstachow@mit.edu
  Maciej W. Rozycki               macro@ds2.pg.gda.pl
  Manu Rouat                      emmanuel.rouat@wanadoo.fr
+ Marc Herbert                    marc.herbert@intel.com
  Marcus Brinkmann                Marcus.Brinkmann@ruhr-uni-bochum.de
  Marcus G. Daniels               mgd@ute.santafe.edu
  Marius Vollmer                  mvo@zagadka.ping.de
@@@ -299,7 -298,6 +300,7 @@@ Paul Jarc                       prj@po.
  Paul Lunau                      temp@lunau.me.uk
  Paul Martinolich                martinol@datasync.com
  Paul Thomas                     PTHOMAS@novell.com
 +Pavel Raiskup                   praiskup@redhat.com
  Pavel Roskin                    pavel_roskin@geocities.com
  Pavel Sanda                     ps@twin.jikos.cz
  Per Bothner                     bothner@cygnus.com
@@@ -314,6 -312,7 +315,7 @@@ Peter Muir                      iyhi@ya
  Peter O'Gorman                  peter@pogma.com
  Peter Rosin                     peda@lysator.liu.se
  Peter Seiderer                  seiderer123@ciselant.de
+ Petr Hracek                     phracek@redhat.com
  Petter Reinholdtsen             pere@hungry.com
  Petteri Räty                    betelgeuse@gentoo.org
  Phil Edwards                    phil@jaj.com
@@@ -394,6 -393,7 +396,7 @@@ Tim Rice                        tim@mul
  Tim Van Holder                  tim.van.holder@pandora.be
  Toshio Kuratomi                 toshio@tiki-lounge.com
  Tom Epperly                     tepperly@llnl.gov
+ Tom Rini                        tom_rini@mentor.com
  Ulrich Drepper                  drepper@gnu.ai.mit.edu
  Ulrich Eckhardt                 eckhardt@satorlaser.com
  Václav Haisman                  V.Haisman@sh.cvut.cz
diff --combined t/list-of-tests.mk
@@@ -664,9 -664,8 +664,9 @@@ t/makej.sh 
  t/makej2.sh \
  t/maken.sh \
  t/maken3.sh \
 -t/make-dryrun.tap \
  t/makevars.sh \
 +t/make-dryrun.tap \
 +t/make-is-gnu.sh \
  t/man.sh \
  t/man2.sh \
  t/man3.sh \
@@@ -1152,6 -1151,7 +1152,7 @@@ t/tags-pr12372.sh 
  t/tar.sh \
  t/tar2.sh \
  t/tar3.sh \
+ t/tar-ustar-id-too-high.sh \
  t/tar-override.sh \
  t/target-cflags.sh \
  t/targetclash.sh \