headers
Jim Meyering | 19 Nov 18:06

coreutils-6.5 released (stable)

If you haven't heard about the GNU coreutils, the FAQ is a good
place to start: <http://www.gnu.org/software/coreutils/faq/>.

This is a stable release.

There has been only one significant bug fix since the last release,
but it's an important one, affecting recursive traversals by chmod,
chgrp, chown and du.  See the NEWS below for details.  For older
changes see the distributed NEWS file, or this link:

  <http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=blob;f=NEWS;hb=HEAD>

----------------------------------------------------------------
Here are the compressed sources:
  ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.5.tar.gz   (7.7MB)
  ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.5.tar.bz2   (5.2MB)

Here are the xdelta-style diffs:
  ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.4-6.5.xdelta   (312KB)

Here are the GPG detached signatures[*]:
  ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.5.tar.gz.sig
  ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.5.tar.bz2.sig

Here are the MD5 and SHA1 checksums:

a0811d36a814d8102dbbcd82301274f4  coreutils-6.5.tar.gz
ecf8e9aa5b85dd89a0b18d5fab63de55  coreutils-6.5.tar.bz2
e715ce3d19f431c1426d635784d2f4c3  coreutils-6.4-6.5.xdelta
a199669c764c5a87857c73cc2c0f5f9bc7b72462  coreutils-6.5.tar.gz
(Continue reading)

Permalink | Reply |
Permalink | Reply |
headers
Jim Meyering | 20 Nov 13:59

Re: coreutils-6.5 released (stable)

Andreas Schwab <schwab <at> suse.de> wrote:
> Jim Meyering <jim <at> meyering.net> writes:
>> If you haven't heard about the GNU coreutils, the FAQ is a good
>> place to start: <http://www.gnu.org/software/coreutils/faq/>.
>>
>> This is a stable release.

Well, I'm confident that the coreutils part was stable.
It'd sure be nice to keep gnulib's instability from affecting
"stable" coreutils releases.

> NLS configuration is broken.

Thanks for the quick patch.  I've applied it in gnulib.
For those wondering, this bug caused coreutils' configure-time
test for gettext to fail like this on our favorite systems:

    checking for GNU gettext in libc... no
    checking for iconv... (cached) yes
    checking for GNU gettext in libintl... no
    checking whether to use NLS... no

In config.log, there were new compile errors:

    configure:51552: checking for GNU gettext in libc
    configure:51582: gcc -std=gnu99 -o conftest -g   -Wl,--as-needed conftest.c  >&5
    conftest.c:437: error: expected identifier or '(' before '[' token

Since the offending file comes from gettext via gnulib,
I've cc'd those lists.
(Continue reading)

Permalink | Reply |
headers
Paul Eggert | 20 Nov 19:05
Favicon

Re: coreutils-6.5 released (stable)

Jim Meyering <jim <at> meyering.net> 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 "./bootstrap --gnulib-srcdir=../gnulib-stable".
Crude, but it might be good enough.

_______________________________________________
bug-gnu-utils <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-utils
Permalink | Reply |
headers
Jim Meyering | 21 Nov 11:12

Re: coreutils-6.5 released (stable)

Paul Eggert <eggert <at> CS.UCLA.EDU> wrote:
> Jim Meyering <jim <at> meyering.net> 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 "./bootstrap --gnulib-srcdir=../gnulib-stable".

Thanks.  That sounds good enough for me, too.

_______________________________________________
bug-gnu-utils <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-utils
Permalink | Reply |
headers
Andreas Schwab | 21 Nov 11:24
Favicon
Gravatar

Re: coreutils-6.5 released (stable)

Paul Eggert <eggert <at> CS.UCLA.EDU> writes:

> Jim Meyering <jim <at> meyering.net> 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 "./bootstrap --gnulib-srcdir=../gnulib-stable".
> Crude, but it might be good enough.

How about putting that stable snapshot in the repository?

Andreas.

--

-- 
Andreas Schwab, SuSE Labs, schwab <at> suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

_______________________________________________
bug-gnu-utils <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-utils
Permalink | Reply |
headers
Jim Meyering | 21 Nov 11:28

Re: coreutils-6.5 released (stable)

Andreas Schwab <schwab <at> suse.de> wrote:
> Paul Eggert <eggert <at> CS.UCLA.EDU> writes:
>> Jim Meyering <jim <at> meyering.net> 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 "./bootstrap --gnulib-srcdir=../gnulib-stable".
>> Crude, but it might be good enough.
>
> 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.

_______________________________________________
bug-gnu-utils <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-utils
Permalink | Reply |
headers
Eric Blake | 21 Nov 14:42

Re: coreutils-6.5 released (stable)


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 gnulib?  If so, I would also
like to reuse the m4-1_4_8 tag in gnulib to match what I just released in M4.

--
Life is short - so eat dessert first!

Eric Blake             ebb9 <at> byu.net
Permalink | Reply |
headers
Jim Meyering | 21 Nov 14:56

Re: coreutils-6.5 released (stable)

Eric Blake <ebb9 <at> byu.net> wrote:
> 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 gnulib?  If so, I would also
> like to reuse the m4-1_4_8 tag in gnulib to match what I just released in M4.

That's what I meant.
However, tags in CVS are relatively expensive, since
they affect every single affected ,v file.  And if every project
that uses gnulib starts applying its own release tags, ...

Contrast that with modern distributed version control systems (git,
mercurial) where tags are very cheap both in time-to-apply and in
repository space.

I'm tempted to set up a gnulib mirror (to git), and then
to use tags in the git repository.  Just being able to compute
diffs without network latency would be very welcome.

I did hesitate before asking this, but... :-)
Would anyone be averse to switching gnulib development from CVS to git?
I switched coreutils a month ago and am very happy with the result.

For now, I think it's enough to specify a gnulib snapshot
via date/time that can then be used to checkout the precise
sources used to bootstrap.
(Continue reading)

Permalink | Reply |
headers
Simon Josefsson | 21 Nov 15:06
Favicon
Gravatar

Re: coreutils-6.5 released (stable)

Jim Meyering <jim <at> meyering.net> writes:

> I did hesitate before asking this, but... :-)
> Would anyone be averse to switching gnulib development from CVS to git?
> I switched coreutils a month ago and am very happy with the result.

I've been hesitating to change from cvs in my projects because there
seem to be too many options available, and it isn't clear exactly what
the con/pro's are for each alternative.  Frankly, I hadn't even heard
about git until a few weeks ago, although I'm familiar with svn and
arch (of which I strongly prefer svn).  Has anyone made a comparison?

I'm particularly interested in emacs support, external tools support
(e.g., cvs2cl to produce changelogs, viewcvs.cgi for web browsing,
statcvs e.g. <http://josefsson.org/gnutls/statcvs/>), authentication
options (anonymous, ssh, etc), portability (Windows?).  Support at
Savannah may be a factor too.

/Simon
Permalink | Reply |
headers
Jim Meyering | 21 Nov 15:33

switching gnulib from CVS to a dVCS

Simon Josefsson <simon <at> josefsson.org> wrote:
> Jim Meyering <jim <at> meyering.net> writes:
>
>> I did hesitate before asking this, but... :-)
>> Would anyone be averse to switching gnulib development from CVS to git?
>> I switched coreutils a month ago and am very happy with the result.
>
> I've been hesitating to change from cvs in my projects because there
> seem to be too many options available, and it isn't clear exactly what
> the con/pro's are for each alternative.  Frankly, I hadn't even heard
> about git until a few weeks ago, although I'm familiar with svn and
> arch (of which I strongly prefer svn).  Has anyone made a comparison?

svn is not a distributed version control system (dVCS).  For that reason,
it wasn't even in the running for me.  As for why I chose git over hg
(I'd narrowed the choice to those two pretty early on), here's something
I wrote a few days ago:

    http://article.gmane.org/gmane.linux.redhat.fedora.maintainers/3380

In fact, that whole thread (long) makes good reading if you're reasonably
familiar with both git and hg.  Beware though, there are some
statements that make git look bad, but when we pushed for details,
none were forthcoming.

> I'm particularly interested in emacs support, external tools support
> (e.g., cvs2cl to produce changelogs, viewcvs.cgi for web browsing,
> statcvs e.g. <http://josefsson.org/gnutls/statcvs/>), authentication
> options (anonymous, ssh, etc), portability (Windows?).
(Continue reading)

Permalink | Reply |
headers
Eric Blake | 27 Nov 13:11

Re: switching gnulib from CVS to a dVCS


According to Jim Meyering on 11/21/2006 7:33 AM:
>>> Would anyone be averse to switching gnulib development from CVS to git?
>>> I switched coreutils a month ago and am very happy with the result.

Based on this thread, I took a leap and ported git/cogito to cygwin, so
that they are now available from a standard cygwin installation, and am
considering using git on more projects myself.  I think moving gnulib to
git would be reasonable; I particularly liked the concept of being able to
diff history without a network connection, and of branches being O(1)
instead of O(n).

--
Life is short - so eat dessert first!

Eric Blake             ebb9 <at> byu.net
Permalink | Reply |
headers
James Youngman | 1 Dec 18:59
Gravatar

Re: switching gnulib from CVS to a dVCS

On 11/27/06, Eric Blake <ebb9 <at> byu.net> wrote:
> Based on this thread, I took a leap and ported git/cogito to cygwin, so
> that they are now available from a standard cygwin installation, and am
> considering using git on more projects myself.  I think moving gnulib to
> git would be reasonable; I particularly liked the concept of being able to
> diff history without a network connection, and of branches being O(1)
> instead of O(n).

I would vote for this too, despite the fact that I've never used git
before.  The rationale is that I would be able to tag which version of
Gnulib got released in which version of findutils, which at the moment
I can only do by examining the files in the findutils-x.yy.zz.tar.gz
release file.

(That is, there should be no need to have commit access to the root
Gnulib repository in order to simply track which version of the
software I used)

James.
Permalink | Reply |
headers
Bruno Haible | 21 Nov 16:41

Re: version control system

Jim Meyering wrote:
> Would anyone be averse to switching gnulib development from CVS to git?
> I switched coreutils a month ago and am very happy with the result.

Do you have a comparison of git with mercurial, monotone, bzr?

What kind of support does savannah offer? The most interesting support
features IMO would be:
  - automatic daily backup,
  - web interface similar to viewcvs.

Bruno
Permalink | Reply |
headers
Jim Meyering | 22 Nov 09:28

Re: version control system

Bruno Haible <bruno <at> clisp.org> wrote:
> Jim Meyering wrote:
>> Would anyone be averse to switching gnulib development from CVS to git?
>> I switched coreutils a month ago and am very happy with the result.
>
> Do you have a comparison of git with mercurial, monotone, bzr?

There are *lots* of git vs. mercurial comments on the
fedora-maintainers thread I referred you to.

Here's a well-written piece from someone else who's switched to git:

  http://keithp.com/blog/Repository_Formats_Matter.html

As for monotone and bzr, here's a dated (~6mo-1yr-old) comparison
of decentralized VCS:

  http://zooko.com/revision_control_quick_ref.html

I searched a little, e.g.,
  http://www.google.com/search?&q=%22distributed+version+control%22+comparison
but didn't find anything compelling.
Even a survey that's just 6 months old is seriously out of date.
That was evident in the fedora-maintainers discussion.

> What kind of support does savannah offer? The most interesting support
> features IMO would be:
>   - automatic daily backup,

Not relevant.
(Continue reading)

Permalink | Reply |
headers
Jim Meyering | 22 Nov 09:41

Re: version control system

Jim Meyering <jim <at> meyering.net> wrote:
> Bruno Haible <bruno <at> clisp.org> wrote:
>> Jim Meyering wrote:
>>> Would anyone be averse to switching gnulib development from CVS to git?
>>> I switched coreutils a month ago and am very happy with the result.
>>
>> Do you have a comparison of git with mercurial, monotone, bzr?

Here's a comparison of mercurial and bzr, from May 2006,
so it's five months old and probably significantly out of date by now:

  http://lists.freestandards.org/pipermail/lsb-futures/2006-May/002080.html

Here's a final link with comparisons that look accurate.
See the "Comparison of CVS, GIT, Subversion, and SVK" table
at the bottom of the page:

  http://wiki.winehq.org/HackingTips
Permalink | Reply |
headers
Bruno Haible | 22 Nov 19:39

Re: version control system

> > Do you have a comparison of git with mercurial, monotone, bzr?

Reading the wikipedia articles on each of them
   http://en.wikipedia.org/wiki/Git_(software)
   http://en.wikipedia.org/wiki/Mercurial_(software)
   http://en.wikipedia.org/wiki/Monotone_(software)
   http://en.wikipedia.org/wiki/Bazaar_(vcs)

it convinced me of two major advantages of git:
  - speed,
  - community support: 3 web interfaces, several GUIs.

> Here's a well-written piece from someone else who's switched to git:
> 
>   http://keithp.com/blog/Repository_Formats_Matter.html

... which adds a third major advantage:
  - robustness of the repository structure.

> >   - automatic daily backup,
> 
> Not relevant.
> With git or hg, anyone who pulls gets the entire repository.

Hmm, but if the central repository got lost, and was restored through - say -
my copy, everyone would see my temporary branches, and see the patches in the
order in which I pulled them and merged them with my patches, which is not
the original order. No?

Bruno
(Continue reading)

Permalink | Reply |
headers
Jim Meyering | 22 Nov 21:47

Re: version control system

Bruno Haible <bruno <at> clisp.org> wrote:
...
>> >   - automatic daily backup,
>>
>> Not relevant.
>> With git or hg, anyone who pulls gets the entire repository.
>
> Hmm, but if the central repository got lost, and was restored through - say -
> my copy, everyone would see my temporary branches,

No problem.
Just make a copy (clone your repo) and remove your temporary
branches in the copy before publishing it.

> and see the patches in the
> order in which I pulled them and merged them with my patches, which is not
> the original order. No?

No.  Deltas in a git repository can't get "out of order".
Permalink | Reply |
headers
Bruno Haible | 21 Nov 14:53

Re: gettext.m4 bug (was: coreutils-6.5 released (stable))

Andreas Schwab <schwab <at> suse.de> wrote:
> > NLS configuration is broken.

Thanks for reporting this. Your patch works, but I'm applying a different
patch, for maintainability reasons.

> Well, I'm confident that the coreutils part was stable.
> It'd sure be nice to keep gnulib's instability from affecting
> "stable" coreutils releases.

Gnulib's instability was not the culprit this time; gnulib contains
the gettext.m4 from the newest supposedly stable gettext release. It's
a plain gettext.m4 bug that crept in although I tested it in gettext
on several platforms and in GNU hello.

You can sidestep gnulib instability during the latest days of testing of a
release by using a gnulib snapshot of a fixed day, when you start testing
your release, and not update this cvs checkout until you're done with the
release. It's rare that a blatant bug stays in gnulib for more than a week;
this way you protect yourself against short-lived bugs.

2006-11-20  Bruno Haible  <bruno <at> clisp.org>

	* gettext.m4 (AM_GNU_GETTEXT): Revert 2005-07-28 patch: Use
	changequote instead of pairs of brackets.
	Reported by Andreas Schwab <schwab <at> suse.de>.

diff -r -c3 --exclude='*.po*' --exclude='*.info*' --exclude='*_*.html' --exclude='*.*.html'
--exclude='*.[13]' --exclude='*.1.in' --exclude=Makefile.in --exclude=aclocal.m4
--exclude=configure --exclude=config.h.in --exclude=version.texi --exclude=stamp-vti
(Continue reading)

Permalink | Reply |
headers
Eric Blake | 21 Nov 15:08

Re: gettext.m4 bug


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.
>   
>           if test $gt_api_version -ge 3; then
> !           gt_revision_test_code='
>   #ifndef __GNU_GETTEXT_SUPPORTED_REVISION
>   #define __GNU_GETTEXT_SUPPORTED_REVISION(major) ((major) == 0 ? 0 : -1)
>   #endif
> + changequote(,)dnl
>   typedef int array [2 * (__GNU_GETTEXT_SUPPORTED_REVISION(0) >= 1) - 1];
> ! changequote([,])dnl
> ! '

The autoconf manual recommends against changequote when possible, because
of a tendency to misuse it (such as forgetting to restore the quotes),
although it looks like you managed to get it right here.  Furthermore, you
used a raw m4 macro changequote; inside of autoconf, you should instead be
using the m4sugar wrapper m4_changequote (as it is, how does this even
work?  m4sugar intentionally disables raw m4 macro names so that they will
not be inadvertently expanded).

One other thought - would it be worth making this code rely on
AC_COMPUTE_INT, rather than open-coding your own checker based on typedef
array size, to take advantage of the portability tricks that autoconf has
(Continue reading)

Permalink | Reply |
headers
Ralf Wildenhues | 21 Nov 19:57

Re: gettext.m4 bug

Hello Eric,

* Eric Blake wrote on Tue, Nov 21, 2006 at 03:08:57PM CET:
>Furthermore, you used a raw m4 macro changequote; inside of autoconf,
>you should instead be using the m4sugar wrapper m4_changequote (as it
>is, how does this even work?  m4sugar intentionally disables raw m4
>macro names so that they will not be inadvertently expanded).

m4sugar initialization happens at AC_INIT time.  Anything that is read
before it will not see its limitations.  The contents of aclocal.m4 for
example.

Yes, this sucks.  Yes, if Autoconf changes to to m4sugar renaming before
anything else, a lot of software will break.  I still think it should be
changed eventually.

Cheers,
Ralf

_______________________________________________
bug-gnu-utils <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-utils
Permalink | Reply |
headers
Bruno Haible | 21 Nov 15:49

Re: gettext.m4 bug

Eric Blake wrote:
> > 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.
> >
> >           if test $gt_api_version -ge 3; then
> > !           gt_revision_test_code='
> >   #ifndef __GNU_GETTEXT_SUPPORTED_REVISION
> >   #define __GNU_GETTEXT_SUPPORTED_REVISION(major) ((major) == 0 ? 0 : -1)
> >   #endif
> > + changequote(,)dnl
> >   typedef int array [2 * (__GNU_GETTEXT_SUPPORTED_REVISION(0) >= 1) - 1];
> > ! changequote([,])dnl
> > ! '
> 
> The autoconf manual recommends against changequote when possible

Yes, and it is because of this recommendation that I was convinced to use
brackets instead of changequote in this place on 2005-07-28. And the result
was that, only two releases later, I got a quoting bug in gettext.m4 -
something which I otherwise haven't had in 5 years.

So, at least for me, changequote is more maintainable than brackets.
The third solution, the quadrigraphs, are not my choice either because
make it hard to copy&paste snippets from .m4 files to .c files or vice
versa.

> Furthermore, you
(Continue reading)

Permalink | Reply |
headers
Bruno Haible | 27 Nov 20:45

Re: gettext.m4 bug (was: coreutils-6.5 released (stable))

FYI: This bug is now fixed not only in gnulib, but also in gettext-0.16.1.

> 2006-11-20  Bruno Haible  <bruno <at> clisp.org>
> 
> 	* gettext.m4 (AM_GNU_GETTEXT): Revert 2005-07-28 patch: Use
> 	changequote instead of pairs of brackets.
> 	Reported by Andreas Schwab <schwab <at> suse.de>.

_______________________________________________
bug-gnu-utils <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-utils
Permalink | Reply |

Gmane