bug#21336: [PATCH] configure: handle KCC on case-insensitive filesystems

On Thu, Dec 9, 2021 at 10:56 PM Mike Frysinger wrote: > This fixes https://debbugs.gnu.org/21336. On macOS 10.10, there seems Note that I still see kcc on 12.0.1 > to be a kerberos tool installed as "kcc" which breaks the check. > > Also resync with latest autoconf which searches for clang++ to

bug#14196: Problem with invoking "missing" in directory with "(" in name (Automake 1.11.6, Autoconf 2.68

On Fri, Sep 4, 2020 at 4:38 PM Zack Weinberg wrote: > OK, after a quick investigation, the failure happens at configure time > but the problem code belongs to automake. Specifically, > AM_MISSING_HAS_RUN. I think the tidiest fix is to quote the value of > $am_aux_dir/missing unconditionally: > >

bug#11745: the new test-suite summary is confusing

On Mon, Jun 1, 2020 at 6:46 PM Karl Berry wrote: > Hi Alexandre and all - regarding > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=11745 (12 years ago, oh well). > > I upgraded to Automake 1.12.1 to discover the each of these test-suite > [directories] now displays a huge summary like: >

bug#8289: distcheck and make dvi

On Sun, May 17, 2020 at 9:44 AM Karl Berry wrote: > I've attempted to construct a patch [attached] following my own > suggestion :), to create a new variable to allow overriding the "make > dvi" which is done as part of distcheck with another target. I named the > variable AM_DISTCHECK_DVI_TARGET

bug#39078: Path.pm change -> deltree.pl -> t/uninstall-fail failure

On Sun, Jan 12, 2020 at 6:41 PM Karl Berry wrote: > > Regarding the new failure of Path.pm:rmtree to do removals, here is the > change I had in mind to use chmod and rm instead. The previously-"ERROR" > tests (uninstall-fail and instspc) work for me with this change. > > Before I bother spending t

bug#38139: Fwd: Likely bug: generating tags with Emacs Lisp sources present

On Mon, Nov 11, 2019 at 6:55 PM Luca Saiu wrote: > > On 2019-11-10 at 14:24 +0100, Luca Saiu wrote: > > > using lisp_DATA rather than lisp_LISP prevents the misbehavior. > > But, incidentally, using lisp_DATA also prevents tag generation from the > Emacs Lisp sources. Thanks to both of you. Karl

bug#34201: [PATCH] automake: do not require @setfilename in Texinfo files

On Sat, Sep 14, 2019 at 5:35 AM Gavin Smith wrote: > On Mon, Sep 2, 2019 at 6:28 PM Jim Meyering wrote: > > > > Gavin Smith proposed a patch for this back in http://bugs.gnu.org/34201 > > Another reference to the problem: http://bugs.gnu.org/36921 > > > > In the

bug#36921: [PATCH] automake: do not require @setfilename in Texinfo files

Gavin Smith proposed a patch for this back in http://bugs.gnu.org/34201 Another reference to the problem: http://bugs.gnu.org/36921 In the attached (in Gavin's name), I've added a NEWS entry and adjusted the ChangeLog entry. Will push in a day or so if no comment. automake-relax-setfilename.diff

bug#23661: [PATCH] compile: remove .Tpo file upon failure

On Mon, May 30, 2016 at 9:08 PM, Jim Meyering wrote: > I was annoyed not to be able to use automake's latest-from-master > while preparing for a diffutils release: "make distcheck" would fail > with a single left-over .Tpo file under gnulib-tests. > > Here is the pat

bug#23661: [PATCH] compile: remove .Tpo file upon failure

ter in a day or two. From c6dff7e2cac2e8dc5407c77998ef0ac2ba538891 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Mon, 30 May 2016 17:07:52 -0700 Subject: [PATCH] compile: remove .Tpo file upon failure When generating a .deps/base.Po file, we first write to a temporary .Tpo file, so the final

bug#23491: [Automake] Proposed upgrade of the home page

On Mon, May 9, 2016 at 1:34 AM, Thérèse Godefroy wrote: > Hello, > > I am a member of the gnu.org French translation team [0], and also try > to update obsolete features in web pages to make future style > improvement easier. automake.html [1] has the old kind of translation > list at the bottom o

bug#17076: [PATCH] tests: depcomp2: avoid spurious failure on OS/X

I happened to notice a test failure on OS/X 10.8.5, and it was trivial to fix. I'll push this to master in a week unless I hear otherwise. From 5ac6a241b117f372808b9d2a6ac78ca9af42dfaf Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Thu, 20 Mar 2014 13:44:48 -0700 Subject: [PATCH]

bug#12320: bison 2.6.2 contains stale info files

Akim Demaille wrote: ... > So, Karl, Jim, and others, would you accept that gendocs.sh > stopped generating a compressed tarball of split info files, > but would rather ship a compressed --no-split file? Sounds fine to me, but gendocs.sh is Karl's baby ;-)

bug#11235: automake build fails: "Can't locate Locale/gettext.pm"

Stefano Lattarini wrote: ... > Could you please reference the bug number here as well? As in: > > Subject: [PATCH] build: use slightly older help2man, for improved > portability > > Fixes automake bug#11235 > > * doc/help2man: Downgrade to help2man-1.36.4, so that it does > not require Lo

bug#11235: automake build fails: "Can't locate Locale/gettext.pm"

d-require) that module. I've Cc'd the help2man bug-reporting list. >From e93e39c1e07597f8644e9539f8c5daaa47c054e3 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 13 Apr 2012 17:58:04 +0200 Subject: [PATCH] build: use slightly older help2man, for improved portability * doc/help

bug#11153: change automake branching policy: dispensing with the 'branch-X.Y' branches in the future

Stefano Lattarini wrote: ... > WDYT? If you agree, I can apply the change below to HACKING, and > implement the new branching policy starting from the Automke 1.12 > release. I agree. IMHO, you won't go wrong following git.git's example. > diff --git a/HACKING b/HACKING ... > +* The Automake git

bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake

Stefano Lattarini wrote: > Hi Jim, thanks for the feedback. > > On 02/06/2012 03:27 PM, Jim Meyering wrote: >> Stefano Lattarini wrote: >> >> [SNIP] > > >>> This seemed a good approach when this test was first introduced, as >>> it apparently i

bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake

Stefano Lattarini wrote: > On 02/02/2012 11:41 PM, Peter Rosin wrote: >> Stefano Lattarini skrev 2012-02-02 22:45: >>> Reference: >>> >>> >>> OK, the attached patch fixes the two spurious failures of GCC forced into >>> Tru64 mode. About time

bug#10418: [PATCH] {master} tap/perl: handle missing or non-executable scripts better

Stefano Lattarini wrote: > On 02/02/2012 03:24 PM, Stefano Lattarini wrote: >> On 02/02/2012 02:57 PM, Stefano Lattarini wrote: >>> The attached patch should take care of three of the remaining five >>> failures still present on latest Fedora (see automake bug#10418). >>> I will push to master shor

bug#10697: subdir-objects "make clean" invokes one rm for each .o file

In cppi (http://git.savannah.gnu.org/cgit/cppi.git), I am now using non- recursive make via subdir-objects, modeled after the way bison does it. I see that "make clean" is inefficient: one "rm -f" per .o file: rm -fr *.o rm -f *.o rm -f lib/calloc.o rm -f lib/close-stream.o rm -f lib/clo

bug#10575: "compress" not found: causes many test failures

Stefano Lattarini wrote: > On 01/21/2012 10:17 PM, Jim Meyering wrote: >> >> FAIL: vala-mix >> > And the attached patch (applied to maint) should take care of this > failure. Thanks. This reduces by one more my "FAIL" counter. > Subject: [PATCH] val

bug#10575: "compress" not found: causes many test failures

Stefano Lattarini wrote: > Hi Jim, thanks for the report. > > On 01/21/2012 10:17 PM, Jim Meyering wrote: >> On master a few days ago I noticed new test failures on a >> Fedora 16 system, due to the unprotected use of compress. >> >> In tests/dist-formats.tap, I r

bug#10434: FAIL: depmod.tap 50 - tru64 [long VPATH] make & remake

Stefano Lattarini wrote: ... > Unfortunately, I don't have access to a Tru64 system, so I can't do the > testing > myself. Nor do I.

bug#10431: a .trs file left behind for each test

Stefano Lattarini wrote: ... >> [using latest automake from git.master] >> For example, in grep and coreutils, after I run "make check", I find >> that every test has a corresponding .trs file alongside the usual .log file. >> > Yep, that's by design; the new automake-generated testsuite harness ne

bug#10431: a .trs file left behind for each test

Hi Stefano, [using latest automake from git.master] For example, in grep and coreutils, after I run "make check", I find that every test has a corresponding .trs file alongside the usual .log file. Those are indeed removed via "make clean", but shouldn't they be removed also upon normal completio

bug#10418: 10 test failures on Fedora 16

Stefano Lattarini wrote: > On 01/01/2012 04:35 PM, Jim Meyering wrote: >> >> FAIL: parallel-tests-interrupt >> == >> > I suspect a testsuite weakness here. Jim, could you please try out the > attached patch to see if it solves the i

bug#10374: 3 test failures on fedora 16

Stefano Lattarini wrote: > On 12/26/2011 11:26 PM, Jim Meyering wrote: >> FAIL: tap-no-spurious-w >> > This is due to a backward-incompatible change in the newer TAP::Harness > releases. The attached patch (thoroughly commented) fixes this, and also > makes the behavio

bug#10374: 3 test failures on fedora 16

gives tools and libraries # plenty of room to grow. > +# "bloating" of automake, perl, or even the C library (especially on 64 > +# bit machines). Suggested by Jim Meyering in automake bug#10374. > (ulimit -v 1; sh -c ":") && skip_ "no adequate 'u

bug#10374: 3 test failures on fedora 16

Stefano Lattarini wrote: > On 12/26/2011 11:26 PM, Jim Meyering wrote: >> FAIL: cond29 >> ... >> + aclocal-1.11a -Werror >> /usr/bin/perl: error while loading shared libraries: >> libc.so.6: failed to map segment from shared object: >> Ca

bug#9807: custom libtool installation and automake testsuite failures

Stefano Lattarini wrote: > On Sunday 06 November 2011, Jim Meyering wrote: >> I install my own versions of m4, autoconf, automake, libtool, etc., >> using --prefix=/p, and I put /p/bin earlier in PATH than /usr/bin, etc. >> >> Because of that, I've always had t

bug#9807: custom libtool installation and automake testsuite failures

Stefano Lattarini wrote: ... > Just to verify this hunch of mine is correct, can you tell me how > you've configured automake, where you have installed your private > libtool version, and post the logs of the failing test(s)? > >> Should I expect those tests to pass in this case? >> > For the momen

bug#9238: help help2man to find iwhd

Pete Zaitcev wrote: > I have a problem that I'm failing to solve. > > If "make distcheck" is ran on a freshly-cloned iwhd repo, just after the > configuring it, the following happens: ... > > But the above causes this to happen: > > $ sh autogen.sh > $ ./configure > $ make distcheck >

bug#9147: 6 test failures on Fedora 15 with latest from git

Stefano Lattarini wrote: > Hi Jim, thanks for the report. Hi Stefano, Thanks for the quick response. >> I built the latest and ran "make check TESTSUITEFLAGS=-j20" on Fedora 15. >> > Note that the `TESTSUITEFLAGS' variable has no effect on Automake-generated > testsuite harness. What you probab

bug#9147: 6 test failures on Fedora 15 with latest from git

Hi, I built the latest and ran "make check TESTSUITEFLAGS=-j20" on Fedora 15. There were 6 failures. I barely have time to send this, so haven't tried to analyze the failures. == GNU Automake 1.11a: tests/test-suite.log ===

bug#8896: [PATCH] doc: replace obsolete @vindex entry with a useful one

Here's a small fix for master: >From 5115c011c2f6689508020612ecee97775da7687f Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sun, 19 Jun 2011 12:29:18 +0200 Subject: [PATCH] doc: replace obsolete @vindex entry with a useful one * doc/automake.texi (Program Sources): Do not index

bug#8526: [GNU Bison 2.4.588-2f658] testsuite: 74 75 76 77 78 79 80 81 82 141 149 185 186 188 189 190 191 195 247 250 287 289 291 293 295 296 297 298 299 300 301 302 304 305 306 307 310 311 failed

Ralf Wildenhues wrote: > * Jim Meyering wrote on Wed, Apr 20, 2011 at 02:43:46PM CEST: >> [TL;DR using automake.git, bison.git fails "make distcheck"s non-srcdir >> build] > >> >> /bin/sh ../build-aux/ylwrap ../src/scan-skel.l lex.yy.c src/scan-skel.c &g

bug#8526: [GNU Bison 2.4.588-2f658] testsuite: 74 75 76 77 78 79 80 81 82 141 149 185 186 188 189 190 191 195 247 250 287 289 291 293 295 296 297 298 299 300 301 302 304 305 306 307 310 311 failed

[TL;DR using automake.git, bison.git fails "make distcheck"s non-srcdir build] Joel E. Denny wrote: > On Mon, 18 Apr 2011, Jim Meyering wrote: > >> FYI, now, using the latest sources from git, >> when I bootstrap, run ./configure --enable-gcc-warnings >> and the

bug#8508: 8 test failures on Fedora 15

Stefano Lattarini wrote: > On Saturday 16 April 2011, Jim Meyering wrote: >> Stefano Lattarini wrote: >> ... >> >> FAIL: self-check-dir.test (exit: 1) >> >> === >>

bug#8508: 8 test failures on Fedora 15

Hi Stefano, Thanks for the speedy reply. Stefano Lattarini wrote: ... > The patch is fine IMHO, I'll apply it in your name ASAP (adding a > reference to this bug report). Thanks. Thanks. ... >> FAIL: self-check-cleanup.test (exit: 1) >> === >> >> ... [CUT] .

bug#8508: 8 test failures on Fedora 15

Stefano Lattarini wrote: ... >> FAIL: self-check-dir.test (exit: 1) >> === ... >> FAIL: self-check-me.test (exit: 1) >> == ... > These failures are due to a known incompatibity in how Zsh handles $0. > Anyway, currenty the automake te

bug#8508: 8 test failures on Fedora 15

864b6a20606c75faa127b670cb Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sat, 16 Apr 2011 11:55:46 +0200 Subject: [PATCH] depcomp: correct invalid sed invocation * lib/depcomp: Insert missing -e before '/:$/d'. Otherwise, that use of sed would treat '/:$/d' as a file name.

Re: [PATCH] doc: fix typo: s/AM_V_AT/AM_V_at/

Ralf Wildenhues wrote: > * Jim Meyering wrote on Thu, Apr 01, 2010 at 10:06:03AM CEST: >> I noticed my recent doc changes caused slightly-too-verbose >> build output. This fixes it: >> >> Cc'ing bug-automake, in case Ralf thinks it makes sense to let >> the

[PATCH] doc: fix typo: s/AM_V_AT/AM_V_at/

I noticed my recent doc changes caused slightly-too-verbose build output. This fixes it: Cc'ing bug-automake, in case Ralf thinks it makes sense to let the consistently capitalized name be used some day. >From d2480e520cda846b8adaa9f064e34a050e238875 Mon Sep 17 00:00:00 2001 From: Jim

all tests pass on Rawhide, Fedora 10, Debian unstable, and more

Hello, Ralf, Are you ready to release 1.11? ;-) Using the latest from git/master (v1.10b-55-g27f63d4), "make check" passed on each of the following systems: Fedora rawhide Fedora 10 Debian unstable Red Hat Enterprise Linux Server 5.3 Ubuntu 9.04 on ubuntu, all libtool-related tests we

Re: test fails when no C++ compiler is available

Jim Meyering wrote: > Hi Ralf, Whoops. This is for autoconf, but for automake. > I've just built automake-from-git on a newly-installed system > that lacked a C++ compiler. It failed like this: > > 220: Multiple languages FAILED (compile.at:24

test fails when no C++ compiler is available

Hi Ralf, I've just built automake-from-git on a newly-installed system that lacked a C++ compiler. It failed like this: 220: Multiple languages FAILED (compile.at:249) ... 220. compile.at:204: 220. Multiple languages (compile.at:204): FAILED (compile.at:249) tes

Re: coreutils' parallel make distcheck now fails

Ralf Wildenhues wrote: > * Jim Meyering wrote on Fri, Apr 10, 2009 at 02:51:08PM CEST: >> > 2009-04-10 Ralf Wildenhues >> > >> >Fix parallel distcheck failure. >> >* maint.mk (ALL_RECURSIVE_TARGETS): Add patch-check, >> >check-AUTHORS

Re: coreutils' parallel make distcheck now fails

Ralf Wildenhues wrote: > * Jim Meyering wrote on Fri, Apr 10, 2009 at 02:07:53PM CEST: >> On a quad-core system, building "make -j7 distcheck" >> fails consistently like this: (note the parallel builds of rmdir.o) >> >> CC nohup.o >> CC read

Re: coreutils' parallel make distcheck now fails

Jim Meyering wrote: > On a quad-core system, building "make -j7 distcheck" > fails consistently like this: (note the parallel builds of rmdir.o) Oh! I left out an important detail. This is using automake built from up-to-the-minute "next".

coreutils' parallel make distcheck now fails

On a quad-core system, building "make -j7 distcheck" fails consistently like this: (note the parallel builds of rmdir.o) CC nohup.o CC readlink.o CC rm.o CC rmdir.o make[3]: Entering directory `/c/coreutils/src' CC readlink.o CC stat.o AR libver.a

Re: parallel make and the maintainer GNUmakefile

Ralf Wildenhues wrote: > Hello Jim, all, ... > 2) disable parallel builds if more than one target is listed on the > command line, and at least one of them invokes a recursive target. > This is the gist of the issue, and the patch only avoids this issue > while practically enabling parallelism thro

Re: new coreutils snapshot available

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * Jim Meyering wrote on Thu, Mar 20, 2008 at 06:49:35PM CET: >> -dist_man_MANS = $(MAN) >> +# We must include at least one literal name here, so that >> +# automake-1.10.1 emits the required install-man* rules. >> +di

Re: new coreutils snapshot available

"Dmitry V. Levin" <[EMAIL PROTECTED]> wrote: > On Wed, Mar 19, 2008 at 11:41:14PM +0100, Jim Meyering wrote: >> "Dmitry V. Levin" <[EMAIL PROTECTED]> wrote: >> > On Fri, Mar 07, 2008 at 03:27:19PM +0100, Jim Meyering wrote: >> >&

Re: new coreutils snapshot available

"Dmitry V. Levin" <[EMAIL PROTECTED]> wrote: > On Fri, Mar 07, 2008 at 03:27:19PM +0100, Jim Meyering wrote: >> There have been over 50 change-sets since the last one, so... > > Something odd happened with generated man/Makefile.in file, > it is no longer g

Re: Problems building coreutils HEAD against gnulib HEAD

Eric Blake <[EMAIL PROTECTED]> wrote: > According to Andreas Schwab on 2/19/2008 2:32 PM: > |> Under the influence of -L, does -xtype l work like -lname '*' in > |> detecting just the broken symlinks? > | > | You don't use -L of course (it isn't supported by find 4.1 anyway). > | Note that with -L

Re: Problems building coreutils HEAD against gnulib HEAD

Eric Blake <[EMAIL PROTECTED]> wrote: > [adding bug-automake] > > According to Jim Meyering on 2/19/2008 4:33 AM: > |> But I am, having seen it myself. It happens when you have a stale symlink > |> from an older copy of gnulib, but which now points nowhere because t

Re: not hardwiring gpg

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Jim, Karl, > > * Jim Meyering wrote on Tue, Dec 18, 2007 at 03:36:27PM CET: >> [EMAIL PROTECTED] (Karl Berry) wrote: >> > Will you accept this change from Jim Meyering to gnupload? >> > (Until now we have c

Re: not hardwiring gpg

[EMAIL PROTECTED] (Karl Berry) wrote: > Will you accept this change from Jim Meyering to gnupload? > (Until now we have copied the gnulib gnupload from automake.) Thanks for forwarding that, Karl. I didn't know gnulib's gnupload file came from elsewhere. FYI, rationale + ChangeLo

Re: support for lzma in automake?

[EMAIL PROTECTED] (Karl Berry) wrote: > Could we have a new option in automake for making lzma-compressed > tarballs, a la bzip2? The package to use is lzma-utils, from > http://tukaani.org/lzma/. Generally, it compresses better and > uncompresses faster than bzip. Not just "better". Significan

Re: subdir-objects fails with non-literal _SOURCES

Hi Ralf! Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * Jim Meyering wrote on Tue, Apr 17, 2007 at 09:16:59PM CEST: >> Ralf Wildenhues <[EMAIL PROTECTED]> wrote: >> ... >> > The strongest argument against invoking `make' at the end of configure >> &

Re: subdir-objects fails with non-literal _SOURCES

Ralf Wildenhues <[EMAIL PROTECTED]> wrote: ... > The strongest argument against invoking `make' at the end of configure > is one of debugging: if your makefile contains a syntax error -- and for > newbies it frequently will -- then configure won't finish successfully. Hi Ralf, If you're tempted,

subdir-objects fails with non-literal _SOURCES

Some automake-generated code malfunctions when using the combination of the subdir-objects option and non-literal _SOURCES. You can demonstrate by changing automake's tests/pr224.test, replacing this line: bar_SOURCES = foo/main.c with these apparently equivalent ones: f = foo bar_S

fix coreutils' "make distcheck": remove AC_CONFIG_LIBOBJ_DIR(lib)

10-07 Jim Meyering <[EMAIL PROTECTED]> * jm-macros.m4 (gl_MACROS): Remove use of AC_CONFIG_LIBOBJ_DIR(lib). It is no longer needed, and was causing dependencies to appear in lib/lib/.deps, which provoked a "make distcheck" failure.