Re: make -q and maintainer-makefile issues?

On 08/11/2011 06:49 PM, Eric Blake wrote: > I'm not sure if we should revert this part of your change. Unfortunately if that part is reverted, then coreutils would lose all gnulib fixes in the gettext area, due to the funny way that 'bootstrap' invokes autopoint. This includes not only the fix fo

Re: make -q and maintainer-makefile issues?

On 08/11/2011 07:45 PM, Paul Eggert wrote: On 08/11/2011 11:28 AM, Paul Eggert wrote: I'll look at coreutils shortly. ... and I discovered that coreutils was still using gettext 0.17 (!) To some degree, that was intentional. At least cygwin still ships with only gettext 0.17, because all v

Re: make -q and maintainer-makefile issues?

On 08/11/2011 11:28 AM, Paul Eggert wrote: > I'll look at coreutils shortly. ... and I discovered that coreutils was still using gettext 0.17 (!) via autopoint, so it didn't pick up the gnulib patch (and it was missing several other gnulib fixes since 0.17). I installed the following into coreuti

Re: Bug in base64, new module base32

Gijs van Tulder writes: > Bruno Haible wrote: >>> + * See also RFC 3548. >> >> Would is not be better to refer to RFC 4648 >> ? It obsoletes the older RFC >> 3548. > > Yes, that would be better. (This is one of the things I

Re: Bug in base64, new module base32

Bruno Haible wrote: >> + * See also RFC 3548. > > Would is not be better to refer to RFC 4648 > ? It obsoletes the older RFC > 3548. Yes, that would be better. (This is one of the things I copied from the base64 module.)

Re: make -q and maintainer-makefile issues?

On 08/11/2011 11:46 AM, Eric Blake wrote: > I think we need a better solution that involves a stamp file Yes, that could also be done, and please feel free to do that. I've been moving away from stamp files like that lately, though, as these days they seem to be more trouble than they're worth, a

Re: make -q and maintainer-makefile issues?

On 08/11/2011 12:28 PM, Paul Eggert wrote: * modules/configmake (configmake.h): Update configmake.h's time stamp even if the file does not change. Otherwise, 'make -q' fails. Problem reported by Simon Josefsson in . Ouch. Th

[PATCH] * build-aux/bootstrap (slurp): Remove obsolescent gettext.m4 patch.

--- ChangeLog |2 ++ build-aux/bootstrap | 17 ++--- 2 files changed, 4 insertions(+), 15 deletions(-) diff --git a/ChangeLog b/ChangeLog index 3a798cf..ea534b9 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,7 @@ 2011-08-11 Paul Eggert + * build-aux/boot

Re: make -q and maintainer-makefile issues?

On 08/10/2011 02:36 PM, Simon Josefsson wrote: > A user reported that 'make -q' didn't work: > > http://permalink.gmane.org/gmane.comp.gnu.libidn.general/329 > > and I cannot seem to debug this properly. I used "make -d" with coreutils, and found a couple of problems in both gnulib and coreutils

[PATCH] git-version-gen: correct the advice in a comment

FYI, >From 17857d41b41e7b22ba58e4e0d98693ee14f022d4 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Thu, 11 Aug 2011 14:16:35 +0200 Subject: [PATCH] git-version-gen: correct the advice in a comment * build-aux/git-version-gen: Correct comment. Don't recommend to list .tarball-version in .gitig

Re: libidn 1.22: sed commands on Solaris 11 too long

Hi Simon, Mark, > > The problem I'm seeing on my "SunOS lap 5.11 snv_134 i86pc i386 i86pc" > > machine is the sed commands used in the Makefile.in are too long and > > the sed is freezing up. This was already reported in May 2011, and Paul's analysis [1] was that it's a "fairly serious kernel bug

Re: libidn 1.22: sed commands on Solaris 11 too long

Thanks for the report Mark. The problem is in gnulib, so I'm cc'ing the bug-gnulib list for assistance. It seems SunOS 5.11 /bin/sed cannot handle the gnulib sed -e construct to create replacement header files. I recall some discussion about too many -e parameters for some sed, but I'm not sure