coreutils-7.4 released [stable]

[Jim Meyering]

This is to announce coreutils-7.4, a "stable" release.
It fixes a 7.3-release-related snafu and a minor, but long-standing bug in date.

For a summary of changes and contributors, see:
  http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=shortlog;h=v7.4
or run this command from a git-cloned coreutils directory:
  git shortlog v7.3..v7.4

To summarize the gnulib-related changes, run these commands from a
git-cloned coreutils directory:
  git checkout v7.4
  git summary v7.3


Distribution note: new suffix, ".xz" replaces ".lzma".
Note the better-compressed tar ball name below has the ".xz" suffix.
XZ Utils (new name for the improved format/tools) is the successor to lzma.
For more info, see http://tukaani.org/xz/

If your distro doesn't yet distribute an "xz" program, request it.
The latest version of GNU tar (1.22) supports it, so you can already
unpack .tar.xz files with a simple "tar xf foo.tar.xz".


Here are the compressed sources:
  ftp://ftp.gnu.org/gnu/coreutils/coreutils-7.4.tar.gz   (9.3MB)
  ftp://ftp.gnu.org/gnu/coreutils/coreutils-7.4.tar.xz   (3.9MB)

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

[*] You can use either of the above signature files to verify that
the corresponding file (without the .sig suffix) is intact.  First,
be sure to download both the .sig file and the corresponding tarball.
Then, run a command like this:

  gpg --verify coreutils-7.4.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys B9AB9A16

and rerun the `gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.63b.42-b26d5
  Automake 1.10c
  Gnulib v0.0-2123-gc90c5cc
  Bison 2.4

NEWS

* Noteworthy changes in release 7.4 (2009-05-07) [stable]

** Bug fixes

  date -d 'next mon', when run on a Monday, now prints the date
  7 days in the future rather than the current day.  Same for any other
  day-of-the-week name, when run on that same day of the week.
  [This bug appears to have been present in "the beginning". ]

  date -d tuesday, when run on a Tuesday -- using date built from the 7.3
  release tarball, not from git -- would print the date 7 days in the future.
  Now, it works properly and prints the current date.  That was due to
  human error (including not-committed changes in a release tarball)
  and the fact that there is no check to detect when the gnulib/ git
  submodule is dirty.

** Build-related

  make check: two tests have been corrected

** Portability

  There have been some ACL-related portability fixes for *BSD,
  inherited from gnulib.

pgpTWPoJYzeH8.pgp
Description: PGP signature