bug#20132: bug#20104: [PATCH] gzip: make the GZIP env var obsolescent

On Wednesday, March 18, 2015 2:40:29 PM CEST Jim Meyering wrote: > On Tue, Mar 17, 2015 at 10:38 PM, Paul Eggert wrote: > > I did propose an Automake patch, here: > > > > http://bugs.gnu.org/20132 > > Glanced through, but didn't have time for a thorough review. I don't see issue in that patch; a

bug#20082: new warning from ar on rawhide systems

On Tuesday 02 of June 2015 16:22:50 Pavel Raiskup wrote: > On Saturday 18 of April 2015 11:50:31 Pavel Raiskup wrote: > > On Friday 17 of April 2015 18:07:57 Peter Rosin wrote: > > > On 2015-04-17 17:54, Pavel Raiskup wrote: > > > > I tried to prepare the patch, but t

bug#20082: bug#19967: bug#20082: new warning from ar on rawhide systems

close 19967 2.4.6.9-41812 -- On Thursday 25 of June 2015 16:50:12 Pavel Raiskup wrote: > On Wednesday 17 of June 2015 09:22:31 Pavel Raiskup wrote: > > Not sure whether some review has been done, so pinging once more to get > > some attention. Otherwise I'll probably push th

bug#21001: Testsuite failure with new Perl

([^ \t=:+{}]+)}/ at /usr/bin/automake line 3936. Please consider the attached patch. [1] https://bugzilla.redhat.com/attachment.cgi?id=1046458 Pavel >From 34163794a58b5bd91c5d6bd9adf5437571c7a479 Mon Sep 17 00:00:00 2001 From: Pavel Raiskup Date: Tue, 7 Jul 2015 10:54:24 +0200 Subject: [PATCH] bin

bug#20082: [gnulib PATCH]: new warning from ar on rawhide systems

On Thursday 25 of June 2015 16:50:12 Pavel Raiskup wrote: > To gnulib guys: I haven't done proper analysis yet. Is the > gl_PROG_AR_RANLIB really expected to be called for *each* 'gnulib' > dependant project? If yes, could we possibly at least set the ARFLAGS > defau

bug#20082: bug#19967: bug#20082: new warning from ar on rawhide systems

On Wednesday 17 of June 2015 09:22:31 Pavel Raiskup wrote: > Not sure whether some review has been done, so pinging once more to get > some attention. Otherwise I'll probably push those changes. OK, I updated the patches a bit more and now just holding them in praiskup-ARFLAGS branch

bug#20082: bug#19967: bug#20082: new warning from ar on rawhide systems

On Saturday 18 of April 2015 11:50:31 Pavel Raiskup wrote: > On Friday 17 of April 2015 18:07:57 Peter Rosin wrote: > > On 2015-04-17 17:54, Pavel Raiskup wrote: > > > I tried to prepare the patch, but thats probably wrong. It would be nice > > > if somebody could c

bug#20082: new warning from ar on rawhide systems

On Saturday 18 of April 2015 11:50:31 Pavel Raiskup wrote: > On Friday 17 of April 2015 18:07:57 Peter Rosin wrote: > > On 2015-04-17 17:54, Pavel Raiskup wrote: > > > I tried to prepare the patch, but thats probably wrong. It would be nice > > > if somebody could c

bug#20082: new warning from ar on rawhide systems

On Friday 17 of April 2015 18:07:57 Peter Rosin wrote: > On 2015-04-17 17:54, Pavel Raiskup wrote: > > I tried to prepare the patch, but thats probably wrong. It would be nice > > if somebody could comment, > > Microsofts archiver (lib.exe) uses a syntax like: >

bug#20082: new warning from ar on rawhide systems

[+cc Ralf] On Friday 27 of March 2015 21:43:14 Pavel Raiskup wrote: > On Friday 27 of March 2015 10:51:36 Eric Blake wrote: > > Hmm. How hard is it to change ARFLAGS to 'cr' instead of the default of > > 'cru', so that projects that want to silence the warning n

bug#20082: new warning from ar on rawhide systems

[+cc back libtool bug; as fixing automake does not seem to be enough] On Friday 27 of March 2015 10:51:36 Eric Blake wrote: > On 03/27/2015 09:48 AM, Pavel Raiskup wrote: > > > So probably the worst slowdown would be an 'ar' task to update archive > > consisting of

bug#20077: automake / silent-rules / $(V)

On Wednesday 11 of March 2015 02:06:40 Mirko Vogt wrote: > I just stumbled across an issue where a project fails to compile using > automake and silent-rules with $V being set to sth. else other than '1' > or '0'. > > This is because of the following resulting Makefile code when using > silent rul

bug#20082: new warning from ar on rawhide systems

On Wednesday 11 of March 2015 10:07:33 Eric Blake wrote: > When compiling libvirt (and probably other packages) on Fedora rawhide > systems, I'm seeing a new warning message on every link line. > > # rpm -q libtool gcc binutils > libtool-2.4.6-1.fc23.x86_64 > gcc-5.0.0-0.16.fc23.x86_64 > binutils-2

bug#19539: [1.15] AC_CONFIG_AUX_DIR should be called early

[+cc autoconf as this should be done in cooperation] On Thursday 08 of January 2015 16:43:02 Pavel Raiskup wrote: > Hi, automake-1.15 behaves differently when AC_CONFIG_AUX_DIR is specified > after AC_USE_SYSTEM_EXTENSIONS (example attached which worked with > automake-1.14.1): > >

bug#19616: [Bug-tar] dist tarball contains hardlinks

On Monday 26 of January 2015 12:12:09 Dimitrios Apostolou wrote: > On Fri, 23 Jan 2015, Pavel Raiskup wrote: > > > On Friday 23 of January 2015 15:45:57 Dimitrios Apostolou wrote: > >> Thank you Joerg. If so then it is an issue that must be fixed in > >> automak

bug#19616: [Bug-tar] dist tarball contains hardlinks

On Friday 23 of January 2015 15:45:57 Dimitrios Apostolou wrote: > Thank you Joerg. If so then it is an issue that must be fixed in > automake, which is the reason I cross-posted to both projects, because I > am not sure which one should be changed! What solution you exactly propose? Note that 'h

bug#19616: [Bug-tar] dist tarball contains hardlinks

On Friday 16 of January 2015 16:43:20 Dimitrios Apostolou wrote: > (Cross posting to both bug-automake and bug-tar as I can see both projects > being affected.) > (Please keep me CC'd as I'm not subscribed.) > > Hello, > > this bug report is because of the following messages when extracting a > sou

bug#17690: [GNU Automake 1.9] testsuite: 7 failed

On Wednesday 04 of June 2014 13:04:23 Engelbrecht, Per wrote: > Making check in . > make[1]: Entering directory `/var/tmp/automake_autoconf_libtool/automake-1.9' > make[1]: Nothing to be done for `check-am'. > make[1]: Leaving directory `/var/tmp/automake_autoconf_libtool/automake-1.9' > [...] Hi,

bug#14891: [PATCH] automake: account for perl hash order randomization (was: Re: bug#14891: GNU Automake 1.14 FAIL: 5)

> These are not Solaris issues AFAIK, but are due to an incompatible > change in perl 5.18. The patch below should take care of it. > Can you confirm it works? FWIW, it fixed the testsuite problem for me (after change to perl 5.18). I also don't see any problem in your patch. Pavel

bug#13588: Pax hangs in case big UID

Hi! > I have re-introduced the line removed by mistake. It seems to be completely OK now, thanks a LOT for your patience. I don't see any problems and also all test passes for me. Have a nice day, Pavel

bug#13588: Pax hangs in case big UID

Stefano, this patch is quite hard to follow because of the new indentation. But both checks are saying PASS for me now. I have found one possible problem (missing one line): > -done > -am__tar="$_am_tar --format=m4_if([$1], [pax], [posix], [$1]) -chf - > "'"$$tardir"' > -am__tar_="$

bug#13588: Pax hangs in case big UID

> Actually, I prefer to keep the checks distinct, and output the problematic > UID/GID as well (makes debugging easier). So I'd rather drop the squash-in > patch you proposed. No problem :). > > I'm also quite afraid of testsuite performance of testsuite - this > > check costs more than 6 second

bug#13588: Pax hangs in case big UID

ESULT([no]) > + _am_tools=none > +fi], Here ^^ it would be possible to de-duplicate (just one message to standard output and little simpler code). But it is just a matter of taste. To make it easier, follows the patch, do not assign me as a co-author. I'm also quite afraid

bug#13588: Pax hangs in case big UID

Hi, thanks a lot for working on this! I would like to point some notes, sorry for doing it so late.. > diff --git a/m4/tar.m4 b/m4/tar.m4 > index ec8c83e..61c1206 100644 > --- a/m4/tar.m4 > +++ b/m4/tar.m4 > @@ -81,7 +81,31 @@ do >AM_RUN_LOG([tardir=conftest.dir && eval $am__tar_ >conftest.ta

bug#13514: [PATCH v3 1/2] aclocal: just warn if the primary local m4 dir doesn't exist (don't error)

ened with '('. > [..] > diff --git a/THANKS b/THANKS > index 66498d4..5c014bf 100644 > --- a/THANKS > +++ b/THANKS > @@ -297,6 +297,7 @@ Paul Jarc p...@po.cwru.edu > Paul Lunau t...@lunau.me.uk > Paul Martinolich

bug#13514: [PATCH v2 0/0] AC_CONFIG_MACRO_DIR && non-existent directory

Hi, thanks for your comments! Here is second iteration of my proposal. [PATCH 1/2] aclocal: just warn if the primary local m4 dir doesn't aclocal.in | 10 ++ t/aclocal-macrodir.tap | 22 +- [PATCH 2/2] aclocal: fix for more-than-once specified directories

bug#13514: [PATCH 2/2] aclocal: fix for more-than-once specified directories

Related to automake bug#13514. Do not explore these directories multiple times in 'aclocal'. This causes problems on older packages that specify configure.ac: AC_CONFIG_MACRO_DIRS([m4]) Makefile.am: ACLOCAL_AMFLAGS = -I m4 when the m4 directory does not exist. See:

bug#13514: [PATCH 1/2] aclocal: just warn if the primary local m4 dir doesn't exist (no error)

Related to automake bug#13514. Every bootstrapping process which does not need to have the local macro directory existing in version control system (because it does not have any user-defined macros) would fail during 'autoreconf -vfi' phase if the AC_CONFIG_MACRO_DIRS([m4]) is specified (to force

bug#13514: unintentional regression with AC_CONFIG_MACRO_DIR in 1.13.1

On Fri, 2013-02-08 at 13:56 +0100, Pavel Raiskup wrote: > Hi Stefano, > > > >> [ ... ] > > > > > > Ping. Are you considering my opinions OK? > > > > > Basically yes; and a patch would obviously be welcome, if you want > > to speed u

bug#13514: unintentional regression with AC_CONFIG_MACRO_DIR in 1.13.1

ning is the best and safest approach for now. > Improvements or re-tightening can be done later, if needed. Done. The purpose of patch 0002-* should be obvious from its description. Patches are generated against 1.13.2 branch. Pavel >From ac4e636a2c726437659c57634fb29b38932b412d Mon Sep 17 0

bug#13514: unintentional regression with AC_CONFIG_MACRO_DIR in 1.13.1

> [ ... ] Ping. Are you considering my opinions OK? Quickly again (let's say that AC_CONFIG_MACRO_DIR([m4]) is specified): a) Warn because 'aclocal -I m4' wants to search 'm4' dir which does not exist. Ignoring this completely is imo idea; b) Don't fail in that because it breaks autore

bug#13514: unintentional regression with AC_CONFIG_MACRO_DIR in 1.13.1

> .. because this tool specifies where libtool should put .m4 files ... This is bad statement — autoreconf does not specify this. But its configure.ac does and autoreconf knows better than any tool (imo) how to solve this. Pavel

bug#13514: unintentional regression with AC_CONFIG_MACRO_DIR in 1.13.1

>>> [..skip..] >>> Maybe the current error should be demoted to a warning, to allow us to >>> be more forward-compatible with such possible future scenarios? >> >> I vote for this approach. >> >I'm starting to be convinced myself that it is the best one. > > But then again, mulling over the issue a

bug#13514: unintentional regression with AC_CONFIG_MACRO_DIR in 1.13.1

> [..skip..] > Maybe the current error should be demoted to a warning, to allow us to > be more forward-compatible with such possible future scenarios? I vote for this approach. It was also proposed some time ago (it is transitively hyper-linked from here already): http://lists.gnu.org/archive

bug#12627: The file lib/COPYING does not match current automake license status

Hello, the commit fcf2f56062e384455ec8b1aed943af33f20c27c7 reverted GPLv3+ -> GPLv2+ license but lib/COPYING stays GPLv3+. Pavel

bug#12522: Problem with automake tests for vala

Hi, because valac's developers dropped POSIX profile: commit ca020bf04a09fe16e5583eea5a3a341e7796bff5 .. there is a problem with automake testsuite in: $ grep -r '\-\-profile=posix' . ./vala-libs.sh:libmu_a_VALAFLAGS = --profile=posix --vapidir=$(srcdir) ./vala-mix.sh:AM_VALAFLAGS =