gmane.comp.gnu.coreutils.announce

Jim Meyering | 19 Apr 23:20

coreutils-6.11 released

Coreutils version 6.11 has been released.  This is a stable release.

Since 6.10, there have been 200 change sets in coreutils proper and almost
300 in gnulib (most of the files in coreutils/{lib,m4} come from gnulib).

Thanks to everyone who has contributed to this release.
This time, a trio from Stanford, Cristian Cadar, Daniel Dunbar and
Dawson Engler deserve special thanks for discovering an amazing number
of bugs (usually segfault-inducing), one in each of the following tools:
pr, md5sum (also affecting sha*sum), mknod, mkfifo, mkdir, paste and ptx.

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

To summarize the gnulib-related changes, you can run this command
From a git-cloned gnulib directory:
git shortlog 16c6ed60fb53998428f510f649ee6b57fea30f35\
..2e8956774250d3f5636898fea193c5abaf041d08

Here are the compressed sources:
  ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.11.tar.gz     (8.8MB)
  ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.11.tar.lzma   (3.6MB)

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

For more information on LZMA compression, see <http://tukaani.org/lzma/>.

(Continue reading)

headers

Russ Allbery | 20 Apr 03:25

Re: coreutils-6.11 released

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

> Coreutils version 6.11 has been released.  This is a stable release.

[...]

> ** Improvements
>
>   id and groups work around an AFS-related bug whereby those programs
>   would print an invalid group number, when given no user-name argument.

I'm hoping that this doesn't mean that coreutils suppresses display of the
PAG group on a system running AFS, since seeing that group is valuable for
debugging.  It really is a supplemental group of the process, even though
it's created in the kernel rather than initialized from /etc/groups.  For
example:

windlord:~> id
uid=1000(eagle) gid=0(root) groups=0(root),4(adm),24(cdrom),29(audio),44(video),1000(eagle),1103312837
windlord:~> id --version
id (GNU coreutils) 6.10

that final group number is useful information.  It was always one of the
features of GNU id over, for example, the Solaris implementation that it
didn't suppress that group number, and I've used that before in programs.

Copied to the AFS list so that people are aware that a change happened in
this area, in case anyone notices differences after a coreutils upgrade.

--

--

(Continue reading)

headers

Russ Allbery | 20 Apr 20:37

Re: coreutils-6.11 released

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

> You can tell I don't use AFS and didn't do my homework.
> I wish you'd noticed and spoken up a month or so ago.

Unfortunately, I only follow the announcement list.  :/

> Knowing that, I expect to revert that patch -- unless someone
> can come up with a very good argument for the new behavior.
>
> Out of curiosity, how have you used it?

Usually to tell whether two shells are in different PAGs, which is useful
when hunting down problems with AFS PAM modules and the like.  Also to
tell whether a process is in a PAG at all, although with current Linux
kernels the keyring is the canonical place where that's stored.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

headers

Brandon S. Allbery KF8NH | 20 Apr 21:08

Re: Re: coreutils-6.11 released

On Apr 20, 2008, at 14:37 , Russ Allbery wrote:

> Jim Meyering <jim <at> meyering.net> writes:
>> Knowing that, I expect to revert that patch -- unless someone
>> can come up with a very good argument for the new behavior.
>>
>> Out of curiosity, how have you used it?
>
> Usually to tell whether two shells are in different PAGs, which is  
> useful
> when hunting down problems with AFS PAM modules and the like.  Also to
> tell whether a process is in a PAG at all, although with current Linux
> kernels the keyring is the canonical place where that's stored.

Putting on my sysadmin hat, I am somewhat baffled by this  
discussion.  Completely hiding unknown groups?  I would print  
numerically and return a nonzero exit status (the latter possibly  
overrideable for OpenAFS use where they are expected); hiding them  
completely isn't just a way to annoy OpenAFS users, it also hides a  
clue to a system configuration problem (namely, missing groups in the  
group database).

If someone actually needs the hiding behavior, make it an option  
(possibly invokable via an environment variable).

--

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery <at> kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery <at> ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH

(Continue reading)

coreutils-6.11 released

Re: coreutils-6.11 released

Re: coreutils-6.11 released

Re: Re: coreutils-6.11 released

Re: retaining AFS-specific nameless group IDs (PAG) in `id' and `groups'

Re: Re: retaining AFS-specific nameless group IDs (PAG) in `id' and `groups'

Re: Re: retaining AFS-specific nameless group IDs (PAG) in `id' and `groups'

Re: Re: coreutils-6.11 released