ready for a new coreutils bug-fix release

[Jim Meyering]

I'm ready for a bug-fix release.

I'd like to include Paul's patch to better guard uses of stat.st_size.

I know Paul mentioned some in-progress speed-up patches for sort,
but anything that changes sort.c enough to evoke a significant speed-up
is unlikely to qualify as simple and clearly "safe".

Does anyone have pending problems/patches we should consider?

Here are the NEWS items since 8.16:

    ** Bug fixes

      id and groups, when invoked with no user name argument, would print
      the default group ID listed in the password database, and sometimes
      that ID would be neither real nor effective.  For example, when run
      set-GID, or in a session for which the default group has just been
      changed, the new group ID would be listed, even though it is not
      yet effective. [bug introduced in coreutils-8.1]

      cp S D is no longer subject to a race: if an existing D were removed
      between the initial stat and subsequent open-without-O_CREATE, cp would
      fail with a confusing diagnostic saying that the destination, D, was not
      found.  Now, in this unusual case, it retries the open (but with 
O_CREATE),
      and hence usually succeeds.  With NFS attribute caching, the condition
      was particularly easy to trigger, since there, the removal of D could
      precede the initial stat.  [This bug was present in "the beginning".]

    ** New features

      fmt now accepts the --goal=WIDTH (-g) option.

    ** Changes in behavior

      cp,mv,install,cat,split: now read and write a minimum of 64KiB at a time.
      This was previously 32KiB and increasing to 64KiB was seen to increase
      throughput by about 10% when reading cached files on 64 bit GNU/Linux.

      cp --attributes-only no longer truncates any existing destination file,
      allowing for more general copying of attributes from one file to another.