bug#74847: change default tar format from v7 to ustar

On 2/24/25 14:41, Karl Berry wrote: Did any change to pax formats ever come to pass? None that would affect this issue with Solaris etc.

bug#67891: automake-1.16i doesn't build on Solaris 10 sparc

On 2023-12-19 14:54, Karl Berry wrote: Hi Paul, help2man: can't get `--help' info from bin/automake Try `--no-discard-stderr' if option outputs to stderr So, the obvious question is, why can't help2man run bin/automake? Clearly it works on other systems, and it doesn't seem like this

bug#67891: automake-1.16i doesn't build on Solaris 10 sparc

Here are the symptoms. But now that I look into it, I see the automake-1.16 build fails with the same symptoms. So I assume this is low priority. GEN doc/automake-1.16.1 help2man: can't get `--help' info from bin/automake Try `--no-discard-stderr' if option outputs to stderr *** Error co

bug#62896: [Configure] Bug with check for PERL when path has spaces (i.e. Windows)

portable. I installed the attached into Automake. The original bug was fixed before I got to this, so I'm boldly closing the bug report.From 668e8a20e3561063ee7478e91c9f81bb40cfed7a Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 2 Dec 2023 21:50:45 -0800 Subject: [PATCH] Simplify rece

bug#50469: [bison-3.8] bug or side effect to flex & automake

On 9/11/21 4:03 AM, Kiyoshi KANAZAWA wrote: Failures of flex's make check also disappeared with bison-3.8.1. Thanks for testing, and thanks Akim for writing the patch. I installed it on the automake master branch on Savannah.

bug#50469: [bison-3.8] bug or side effect to flex & automake

On 9/8/21 2:18 PM, Karl Berry wrote: Just an idea that I don't expect you to adopt, but just to mention -- you could only institute the breaking change if POSIXLY_CORRECT. That's why POSIXLY_CORRECT exists. -k I like this idea. It insulates us against POSIX decisions and/or indecisions in thi

bug#50469: [bison-3.8] bug or side effect to flex & automake

On 9/7/21 10:31 PM, Akim Demaille wrote: However, I don't see a published version of the POSIX Yacc "specs" that includes these changes. The next POSIX revision is targeted for 2022, according to . I suppose there is still opportunity t

bug#42051: Automake Bug

Although it's hard to tell from the symptoms, my guess is that it's some sort of issue with autom4te calling the wrong version of M4 (or maybe of Perl), or M4 not being installed in the right place in your VM, or something like that. Can you specify which version of RHEL you're using, and give

bug#29376: automake gnits version check vs. gnulib's git-version-gen?

On 11/20/2017 11:44 PM, Bernhard Voelker wrote: So my question: aren't 3-level version strings allowed by the gnits check in combination with gnulib's git-version-gen script?  Do we have to change the strictness from gnits to gnu? I would think so, unless someone takes the time to change Auto

bug#20314: [PATCH] Make output of mdate-sh deterministic

se TZ='UTC0' instead of TZ='UTC'. Thanks. For reference, here's the POSIX spec for TZ: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03 and look for "TZ". From 5b240b3b36766045a47a6ad89ae5f4550e81d534 Mon Sep 17 00:00:00 2001 From

bug#21219: automake: m4/python.m4: support python3.4 and python3.5

On 04/22/2016 06:46 AM, Thomas Klausner wrote: Thanks. I don't see the commit onhttp://git.savannah.gnu.org/cgit/automake.git yet though? http://git.savannah.gnu.org/cgit/automake.git/log/?h=micro We can also close my bug report 21219 (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21219).

bug#20132: [PROPOSED PATCH] autoconf: port better to future gzip

Eric Blake wrote: Is the title intentional? No, it's a typo, sorry: the title should have said "automake:", not "autoconf:".

bug#20132: [PROPOSED PATCH] autoconf: port better to future gzip

* lib/am/distdir.am (dist-gzip, dist-shar, distcheck): Port better to future versions of gzip, which are planned to deprecate the GZIP environment variable. --- lib/am/distdir.am | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/lib/am/distdir.am b/lib/am/dist

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

Dimitrios Apostolou wrote: $ touch blah $ ln -s blah link_to_blah $ cp --dereference link_to_blah blah2 The result is that "blah" and "blah2" have different inode! Of course, and that's what one would expect, cp makes copies by default, and the copies have a different inode from the original.

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

Dimitrios Apostolou wrote: But when the tarball is extracted, two files with same inode are created, which is kind of unexpected behaviour - at least for me Other utilities have similar behavior (e.g., ls, cp, du), in that they pretend the symlink isn't there and behave as if the pointed-to in

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

Dimitrios Apostolou wrote: Why is such behaviour desirable? It's more logical, since it causes tar to behave as if the symlink were not there, and the pointed-to file was there instead. Using -hard-dereference bloats the tar image, but if that's a price you're willing to pay then you have a

bug#18301: texi-vers.am: Problem with parallel builds due to vti.tmp

Thanks, I installed the attached patch, which has the more-usual approach of a uniquely-named temporary. From 28b4fdb0ea4c540f1b7bcb90675e365e3aa11beb Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 23 Aug 2014 07:55:28 -0700 Subject: [PATCH] build: fix race in parallel builds Reported by

bug#16337: [PATCH] doc: fix encoding error with UTF-8 characters

Stefano Lattarini wrote: please push (to the 'micro' branch) and close this bug report once you're done Thanks, done.

bug#16337: [PATCH] doc: fix encoding error with UTF-8 characters

* doc/automake.texi: Specify @documentencoding and @documentlanguage, to prevent encoding errors for parts of this input file that are UTF-8. This also causes the .info output to use curly quotes, which is easier to read though it does assume UTF-8 support. --- doc/automake.texi | 2 ++ 1 file c

bug#13378: Cleaning up AC_PROG_CC_C_O semantics

On 01/16/13 04:46, Stefano Lattarini wrote: > Makes sense. Should I try to implement something along these lines (might > take a few days), or are you planning to do that yourself (in which case > I'll avoid the duplicated efforts)? I wasn't planning on doing that, so please go ahead.

bug#13378: Cleaning up AC_PROG_CC_C_O semantics

On 01/14/2013 11:56 AM, Stefano Lattarini wrote: > 1. It checks that *both* 'cc' and '$CC' (which might easily be 'gcc' > or 'clang') supports "-c -o" together. Why? If the user has a > broken base vendor compiler, but has installed a better one (say > GCC), why should he still b

bug#13378: Cleaning up AC_PROG_CC_C_O semantics

On 01/14/13 02:24, Stefano Lattarini wrote: > Autoconfers, WDYT? I think I'm lost. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378 is a long thread.

bug#12578: depcomp typo "informations"

On 10/14/2012 02:49 AM, Stefano Lattarini wrote: > However, for the future, might I ask you to provide complete patches, even > for trivial fixlets like this one? That would make the workflow easier for > me. Sure. Even less work for you (and for me) would be if I simply applied the patches.

bug#12578: depcomp typo "informations"

There is no word "informations" in English. I found this typo while spell-checking Emacs, and want to fix the bug upstream, in Automake. diff --git a/lib/depcomp b/lib/depcomp index 0544c68..ee84bf2 100755 --- a/lib/depcomp +++ b/lib/depcomp @@ -108,7 +108,7 @@ if test "$depmode" = msvc7msys; then

bug#10925: Perl version problem in autoconf-2.68b

On 03/02/2012 07:08 AM, Eric Blake wrote: > Paul, would it be okay if for autoconf we > borrow the same configure check as automake is using, and globally bump > the requirement to be consistent across the autotools? Sure. If I understand things correctly, that means 'configure' will complain tha

bug#10443: [PATCH] Quote 'like this', not `like this'.

On 01/08/12 02:08, Stefano Lattarini wrote: > you have forgotten to add the detailed "* file (func): changes" entries > in the git commit message. Sorry, I misunderstood to be proposing the entire commit message, not a subset of it. > I perso

bug#10443: [PATCH] Quote 'like this', not `like this'.

On 01/06/12 02:00, Stefano Lattarini wrote: > please send patches that don't fix any existing bug to the automake-patches Sorry, I'll try to remember that. > assuming you have already re-run the whole testsuite > with your changes applied, which you have, right?) Yes, I have now, on a Fedora 15

bug#10443: [PATCH] Quote 'like this', not `like this'.

accordingly, and Gnulib imports some files directly from Automake master, so here is a proposed patch to Automake master so that these files use the straight-up style. This patch affects only commentary and quoting in diagnostics. >From f78c4d9a1fc2705badae4ce4ebf46d5d1c8209e0 Mon Sep 17 00:

bug#10436: bug#10427: bug#10436: New testsuite driver and extra trailing backslash in recipes

I pushed the following doc fix into Autoconf, so that these two portability issues are documented there. It turns out that the second issue is actually due to an old Bash bug -- it's not Solaris-specific. >From b1f0e147aa7aa259dea2c34c5a0ac7965d6efd7e Mon Sep 17 00:00:00 2001 From: Pau

bug#10437: parallel-tests: `recheck' recipe can cause sed to be invoked with too long input lines

On 01/05/12 06:07, Stefano Lattarini wrote: > Which "sort of thing" exactly? I could find only one place which suffers > of the problem you've pointed out, i.e., the `recheck recheck-html' rules > in lib/am/check.am. Am I missing something? Sorry, that appears to have been a miscount on my part:

bug#7893: HP-UX make causes autoconf timestamp issues

That issue is now documented in the INSTALL file, as well as in the Autoconf manual. Here's the relevant commit: http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=2d082fa1ca25a16b60fb874e80f51ee79408e1f4

bug#10237: AM_SILENT_RULES does not work with NonStop make

On 12/26/11 13:35, Stefano Lattarini wrote: > testing on non-Linux systems (*BSD and Solaris at least, hopefully also > Cygwin or MinGW). I tested it on Solaris 8 and that test worked fine. I used Autoconf 2.63, GNU m4 1.4.13, and the system-supplied 'make'. Some of the other tests failed, e.g.,

bug#10237: bug#9928: bug#10237: AM_SILENT_RULES does not work with NonStop make

On 12/26/11 09:42, Stefano Lattarini wrote: > And here is the follow-up tweaking for the test cases I had > promised. I will push in a couple of days if there is no objection. Thanks, that looks good to me; please push it as soon as you like.

bug#10237: bug#9928: bug#10237: AM_SILENT_RULES does not work with NonStop make

On 12/23/11 00:50, Stefano Lattarini wrote: > could you apply the patch *not to maint nor to master*, but to a *new* > branch (say `silent-fixes' or `silent-portability') based off of maint, > and push that new branch to the public automake repo? OK, done, as 'silent-fixes', with your recent nit-f

bug#9928: bug#10237: AM_SILENT_RULES does not work with NonStop make

naming convention better. >From 939ba315f5e3e5caea0513af20724c35ead86956 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 22 Dec 2011 13:48:54 -0800 Subject: [PATCH] silent-rules: fallback for makes without nested vars This fixes two problems reported for Automake (Bug#9928, Bug#10237)

bug#9928: bug#10237: AM_SILENT_RULES does not work with NonStop make

review. >From 07edd4aa81af2a8fb982427705a2009c2b7eb0bf Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 20 Dec 2011 17:29:06 -0800 Subject: [PATCH] automake: silent-rules no longer requires nested vars This fixes two problems reported for Automake (Bug#9928, Bug#10237) and is in response

bug#10237: AM_SILENT_RULES does not work with NonStop make

On 12/06/11 11:02, Stefano Lattarini wrote: > If you are interested in accomodating this fringe situation, I will > then accept a patch on the lines Paul has proposed (with a mandatory > testcase, otherwise it would be far too easy to regress in such a > almost-never-excercised corner case). OK, a

bug#10237: AM_SILENT_RULES does not work with NonStop make

On 12/06/11 15:16, Daniel Richard G. wrote: > (Paul: Does $({}) work on NonStop?) I don't know, sorry. I wanted a solution that worked on any POSIX platform -- POSIX 2008 says that $(aaa${bbb}) is just as unspecified as $(aaa$(bbb)) is, and I wanted to play it safe. Part of this is my experience

bug#10237: AM_SILENT_RULES does not work with NonStop make

On 12/06/11 10:19, Stefano Lattarini wrote: > which will also very likely be in the next POSIX standard, if I'm not > mistaken) Do you have a reference for that? That would allay some of my concerns in this area, moving forward. > I'm extremely reluctant to add yet more complexity to automake I

bug#10237: bug#10234: Coreutils incompatibility with POSIX make

On 12/06/11 09:36, Jim Meyering wrote: > I am very reluctant to > sacrifice the above default solely to accommodate that system. Yes, the "make" chatter is annoying, but on the other hand being portable is pretty important too. It's not just NonStop; NextStep 'make' has a similar problem, and I w

bug#10237: AM_SILENT_RULES does not work with NonStop make

If AM_SILENT_RULES is used, Automake generates Makefile.in files with lines like this: AM_V_CC = $(am__v_CC_$(V)) am__v_CC_ = $(am__v_CC_$(AM_DEFAULT_VERBOSITY)) and these are copied into Makefile unchanged. Unfortunately, as the Automake documentation notes, these lines do not conform to th

bug#10210: [PATCH] lib/depcomp: spelling fix in usage message

Found while spell-checking Emacs. Here's a proposed patch. There are similar misspellings in the ChangeLogs but that's less important. depcomp: spelling fix * lib/depcomp (-h): Fix misspelling in usage diagnostic. diff --git a/lib/depcomp b/lib/depcomp index 9825d56..b97ed64 100755 --- a/lib/depc

bug#10083: Acknowledgement ([PATCH] * lib/install-sh: Spelling fix in comment.)

I pushed this as trivial (thanks to Jim), and am closing it.

bug#10083: [PATCH] * lib/install-sh: Spelling fix in comment.

geLog @@ -1,3 +1,7 @@ +2011-11-19 Paul Eggert + + * lib/install-sh: Spelling fix in comment. + 2011-11-10 Stefano Lattarini tests: avoid a spurious failure of 'ltinit.test' MinGW diff --git a/lib/install-sh b/lib/install-sh index a9244eb..64c4b3e 100755 --- a/lib/insta

bug#8881: config.h double inclusion

On 06/16/11 10:36, Alfred M. Szmidt wrote: > I'm thinking that maybe should be generated with a double > inclusion guard But the general rule is that must always be included first, no? So there shouldn't ever be a possibility of including it twice. It might be better to have config.h do somethi

bug#8493: autoconf fails if env var U set

On 04/13/2011 11:02 AM, Tom Lane wrote: > If the intended use is only for ansi2knr, I'd even argue that it > should be off by default ... how many people care about ansi2knr > anymore? Nobody. It would be fine to remove the ansi2knr stuff from Autoconf.

Re: automatic update Makefile.am -> Makefile.in -> Makefile no longer working

Ralf Wildenhues <[EMAIL PROTECTED]> writes: > I think this should be applied to HEAD and branch-1-10. > Would you like me to do it? Yes, please. And thanks for your review; your points all look right to me. > So this is yet another reason to keep Autoconf version incompatibilities > as few as p

Re: automatic update Makefile.am -> Makefile.in -> Makefile no longer working

Bruno Haible <[EMAIL PROTECTED]> writes: > Are we now supposed to edit Makefile.in by hand each time we modify > Makefile.am? I hope not. How about the following (untested) Automake patch? 2007-06-20 Paul Eggert <[EMAIL PROTECTED]> * aclocal.in (write_aclocal): W

Re: 1.10a instspc.test failure

Ralf Wildenhues <[EMAIL PROTECTED]> writes: > 2007-01-17 Ralf Wildenhues <[EMAIL PROTECTED]> > > * doc/autoconf.texi (Setting Output Variables): Mention that > all non-NUL characters are ok in substituted values. > * lib/autoconf/status.m4 (_AC_SED_CMD_LIMIT): Fix comment typo.

Re: 1.10a instspc.test failure

Ralf Wildenhues <[EMAIL PROTECTED]> writes: > -is called. The value can contain newlines. > +is called. The value can contain all ASCII characters except for > +the @code{NUL} character and carriage return; newline is ok to use. If we can assume POSIX conformance with a reasonable C locale, the

Re: ftp.gnu.org no longer working with old method?

Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: > A new version of gnupload is in Automake's CVS (and attached). Thanks, but it's not in Automake's CVS yet. Did you have second thoughts? I did not install it into gnulib, since I wanted to double-check first.

Re: Use current directory for POSIX mkdir test in install-sh

"Alex Unleashed" <[EMAIL PROTECTED]> writes: > the fact of the attempt is what > really matters, I'm afraid I'll have to disagree on this one, as a matter of philosophy. Autoconf regularly tries stuff to see whether it works. It's not at all unreasonable for Autoconf to try programs that have me

Re: Use current directory for POSIX mkdir test in install-sh

either _succeeds_ (which is what should matter here). So it sounds like your sandbox tests should be adjusted, one way or another, since they're not consistent. 2006-10-09 Paul Eggert <[EMAIL PROTECTED]> * doc/autoconf.texi (Limitations of Usual Tools): Describe

Re: getdate.lo is linked twice to libgnu.la

Simon Josefsson <[EMAIL PROTECTED]> writes: > 2006-09-13 Simon Josefsson <[EMAIL PROTECTED]> > > * getdate.m4: Don't AC_LIBOBJ([getdate]), automake takes care of > that internally, suggested by Ralf Wildenhues > <[EMAIL PROTECTED]>. Thanks, I installed that.

Re: compilation flags per object file

al/lib" business in all 'make' output, not just for files that don't need LIBDIR. How about the following patch to gnulib instead? It's short and sweet, doesn't require any changes to Automake, and should be easier to maintain. And it simplifies the 'make' outp

suggest making de-ANSI-fication obsolete; also, "an hello" -> "a hello"

on. Here's a proposed patch. 2006-08-21 Paul Eggert <[EMAIL PROTECTED]> * NEWS: "an hello" -> "a hello". * NEWS: Mark de-ANSI-fication as being obsolete. * doc/automake.texi: Likewise. diff -pru automake-1.9b/NEWS automake-1.9b

Re: make install using "-j"

t;> + posix_mkdir=: > > still falsely thinks the HP-UX mkdir is Posix conforming. Thanks for catching that. I suppose we'll have to make a test directory in /tmp after all, to catch these bugs. Here's a revised proposed patch which addresses this issue, along with o

Re: make install using "-j"

"David Everly" <[EMAIL PROTECTED]> writes: > I've also opened a bug on mkdir -p against ia64-hp-hpux11.23, and I > want to confirm this bug (I'm not an expert on posix, especially > relating to umask and mkdir). I'm sure HP will thank you for your efforts > Here are the three tests, includin

Re: make install using "-j"

== RCS file: /cvs/automake/automake/ChangeLog,v retrieving revision 1.2901 diff -p -u -r1.2901 ChangeLog --- ChangeLog 7 Jun 2006 06:01:22 - 1.2901 +++ ChangeLog 22 Jun 2006 21:08:06 - @@ -1,3 +1,20 @@ +2006-06-22 Paul Eggert <[EMAIL PROTEC

Re: 10 failures in recent automake checkout testsuite under Solaris 9

Ralf Wildenhues <[EMAIL PROTECTED]> writes: > and all in all I'm really not sure whether we shouldn't just convince > users to fix the file permissions of install-sh instead. I agree. Let's just do that. It's much simpler. > +so your package should contain @file{install-sh} as described under

workaround for problem with VPATH-based builds on Solaris

ds to variables other than TESTS. Perhaps Automake should follow Autoconf's lead, and start recommending VPATH builds only for GNU make? If so, I could prepare a patch to the Automake documentation along these lines. Jim, should I also install this patch on the 5.9x branch of coreutils? 2006-

Re: A release with LIBOBJDIR?

Ralf Wildenhues <[EMAIL PROTECTED]> writes: > * NEWS, doc/autoconf.texi (AC_LIBOBJ vs LIBOBJS): Mark > `LIBOBJDIR' as experimental. That change looks good to me; thanks.

Re: A release with LIBOBJDIR?

Stepan Kasal <[EMAIL PROTECTED]> writes: > That is why I'd like to ask you to consider marking the feature > as experimental, and adding a warning that it may disappear in > future releases. That sounds fine to me, but we need a real patch.

Re: Bug in latest install-sh

Stepan Kasal <[EMAIL PROTECTED]> writes: >> Both do, but trap '' 0 seems to be the most portable. > > And it is also the clener one. > Proposed patch attached. Thanks. I installed that (replacing "trap - 0" with "trap '' 0" in install-sh) into Automake's main line. Perhaps it should be put into

Re: [gettext] update .cvsignore files

Re <http://lists.gnu.org/archive/html/bug-gnu-utils/2005-07/msg00087.html> Bruno Haible <[EMAIL PROTECTED]> writes: >> libtool >> -stamp-h >> +stamp-h* >> alloca.h > > I thought that Paul Eggert had submitted, years ago, a patch through which > o

Re: missing --docdir parsing code

Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: > Looks OK? Yes; please install. Thanks.

Re: automake not working inspite of AC_CONFIG_FILES([Makefile])

Hema K <[EMAIL PROTECTED]> writes: > configure.in:16: warning: AC_RUN_IFELSE was called before AC_GNU_SOURCE Try calling AC_GNU_SOURCE before line 16.