Re: coreutils-6.5 released (stable)

2006-11-21 Thread Andreas Schwab
Paul Eggert <[EMAIL PROTECTED]> writes: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> It'd sure be nice to keep gnulib's instability from affecting >> "stable" coreutils releases. > > What I do for my (less-ambitious-than-coreutils) releases is take a > snapshot of gnulib, and then use "./bootst

Re: coreutils-6.5: yet another C89 problem

2006-11-21 Thread Paul Eggert
Matthew Woehlke <[EMAIL PROTECTED]> writes: > Maybe it would help if someone occasionally did builds with gcc's > strict-c89 mode Even better, if someone would build CVS coreutils once a day with some random non-GCC c89 compiler. Perhaps you could arrange for that? (The usual idea is that the t

Re: coreutils-6.5: yet another C89 problem

2006-11-21 Thread Jim Meyering
Matthew Woehlke <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> Michael Deutschmann <[EMAIL PROTECTED]> wrote: >>> Yet again, a new C89-incompatibility ... [snip] >> As you can see, I am not very motivated to be >> proactive about supporting such ancient compilers. >> Is upgrading not an option

Re: coreutils-6.5 released (stable)

2006-11-21 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 11/21/2006 3:28 AM: >> How about putting that stable snapshot in the repository? > > Yes, whatever we use should be publicly accessible. > I hope a tag or a branch will be enough. Is it worth applying that tag directly to

Re: coreutils-6.5 released (stable)

2006-11-21 Thread Jim Meyering
Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> It'd sure be nice to keep gnulib's instability from affecting >> "stable" coreutils releases. > > What I do for my (less-ambitious-than-coreutils) releases is take a > snapshot of gnulib, and then use "./bootstra

Re: test du/trailing-slash fails for coreutils-6.5 under Solaris 9

2006-11-21 Thread Paul Eggert
Jim Meyering <[EMAIL PROTECTED]> writes: > Think of this bug as incentive for you to upgrade to Solaris 10 :-) :-) , says Sun will stop shipping Solaris 8 on 2007-02-16, and they plan to support Solaris 8 through 2012-03-31.

Re: gettext.m4 bug

2006-11-21 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 11/21/2006 6:53 AM: > > Thanks for reporting this. Your patch works, but I'm applying a different > patch, for maintainability reasons. ... > --- 137,150 > dnl to fall back to GNU NLS library. > >

Re: coreutils-6.4 released (stable)

2006-11-21 Thread Matthew Woehlke
Paul Eggert wrote: Matthew Woehlke writes: Perhaps there's a better way. In I asked Matthew Woehlke why the patch was actually needed -- as it's not 100% clear to me -- and that hasn't been followed up on yet. ...it's need

Re: progreloc.c

2006-11-21 Thread Paul Eggert
Charles Wilson <[EMAIL PROTECTED]> writes: > http://lists.gnu.org/archive/html/bug-gnulib/2006-11/msg00054.html > > Relevant to recent discussion about LGPL modules depending on GPL > ones, this file has no module so was missed during that discussion. > The message above sent last week provides a

Re: coreutils-6.4 released (stable)

2006-11-21 Thread Paul Eggert
Matthew Woehlke <[EMAIL PROTECTED]> writes: >> Perhaps there's a better way. In >> >> I asked Matthew Woehlke why the patch was actually needed -- as it's >> not 100% clear to me -- and that hasn't been followed up on yet. >

Re: coreutils-6.5: yet another C89 problem

2006-11-21 Thread Jim Meyering
Michael Deutschmann <[EMAIL PROTECTED]> wrote: > Yet again, a new C89-incompatibility has appeared in coreutils (6.5) that > is not covered by c99-to-c89.diff. It's different from all I've reported > before. > > The fix is appended. Thanks for the patch. I applied it. As you can see, I am not ve

FYI: "make check" for gnulib/lib

2006-11-21 Thread Jim Meyering
This rule would have helped avoid a problem in idcache.c. I expect to add something similar (though in modules/) that will run check-module once I've found the time to clean up the existing violations. I chose to put it in lib/ only slightly arbitrarily. Eventually we may divide things by function