coreutils-7.4 released [stable]

--=-=-=

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.

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iQIcBAEBAgAGBQJKAxi4AAoJENd//eG5q5oWFTkP/3wjFGUsCF+cIFq1/LCTRe51
8Txqi4BQodiz6GoB7dIXk9Q0OFBmtuQTpUg1IvU0pZOcz6qhUn0biAvmtsLKs1RY
fzHD9ihExFZx4YaTS79KvfM4E0gD7LDCVER8geeXPJZD0491OBolDmWLwcHGM0Ho
bzvD7lcjKRWfwDQLvgUWTEEAydQZMNSlabl0oI4fm6UnsOTtk8ppGsGephA0SnUW
lY8XkGK399brtDKxOjp0/CHTihYyGbhAn/3Iyr+9VQHXUNv3oDAZVoCEuY2rt0xy
FsT3FBZuLscUlbCCqJICzCiwiSLlAkeNWbtvWRoqxjeNG5UoiXU8xQwycv5Zg5Nn
ZNsH3oesl+Z6ri1gr/DghZv9dhFvwyEwzZXvB8VkQ7I+DQx2xbOjKv37MRMri4a7
Ch2TM/c6M9oIJQQYH1J0fyZHbB+JLIW4Pi7BuJmlYndPsMzghimFgdhCoY9Ctf8y
lz+UbQlZ+2+gjLVZcoPasZ8vMRv38KVvHaBC7xrxxYaozndzgZY+Xpavra1xwTUj
qWtAdJ3S995Fefm7mzKG4plZgKJMklDpJMlN3+8Yiwreh7it9STGuuJkcDB1yZDX
7D7x7X0EBg7rSpJJo39DpfkfnJWUrY3eTA+RkvmFFHMKuzRLjBt7F3+ZOfCJNpnI
vnSoeipPOh/EuHtg+hSB
=XO1c
-----END PGP SIGNATURE-----
--=-=-=--