Re: [FEATURE_REQUEST] support openssl checksum format too

[Guenter Knauf]

Hi Jim,
was still something wrong with my last patch?

Günter.

Re: [PATCH] ls: don't use an undefined struct stat after failed stat/lstat

[Paul Eggert]

Pádraig Brady  writes:

> -human_readable (ST_NBLOCKS (f->stat), buf, human_output_opts,
> -ST_NBLOCKSIZE, output_block_size));
> +! f->stat_ok ? "?"
> +: human_readable (ST_NBLOCKS (f->stat), buf, human_output_opts,
> +  ST_NBLOCKSIZE, output_block_size));

Just as a style thing, it's better to parenthesize expressions that
cross line boundaries, e.g.:

(! f->stat_ok ? "?"
 : human_readable (ST_NBLOCKS (f->stat), buf, human_output_opts,
  ST_NBLOCKSIZE, output_block_size))

Re: please verify

[Pádraig Brady]

Philip Rowlands wrote:
> On Mon, 5 Oct 2009, Chandan Kumar wrote:
> 
>> I am getting some faults while doing CAL command,
> 
> cal is not part of GNU coreutils.
> 
>> i.e. i am getting some leap years in case of non-leap years i.e. the
>> years like 1000,500,1500,1700 etc
> 
> 1700 is a leap year, and leap years predating 1582 (the adoption of the
> Gregorian Calendar) depend which calendar you're talking about.

The Gregorian calendar was adopted at various times.
`cal` assumes the British empire (including eastern US), so 1752:
http://en.wikipedia.org/wiki/Gregorian_calendar
Thus 1700 is a leap year as it uses the old Julian rule of divisible by 4

cheers,
Pádraig.

[PATCH] maint: make release-making instructions more generic

[Jim Meyering]

FYI,

>From d183a15cbb26691e0a05bab06ab700ec46fcfba4 Mon Sep 17 00:00:00 2001
From: Jim Meyering 
Date: Tue, 6 Oct 2009 16:49:36 +0200
Subject: [PATCH] maint: make release-making instructions more generic

* README-release: Make instructions more generic.
---
 README-release |   33 +
 1 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/README-release b/README-release
index d20a911..4bf4815 100644
--- a/README-release
+++ b/README-release
@@ -7,18 +7,18 @@ Here are most of the steps we (maintainers) follow when 
making a release.
 * Run ./configure && make maintainer-clean

 * Ensure that the desired versions of autoconf, automake, bison, etc.
-  are in your PATH.  See HACKING for the complete list.
+  are in your PATH.  See the buildreq list in bootstrap.conf for
+  the complete list.

 * Ensure that you're on "master" with no uncommitted diffs.
   This should produce no output: git checkout master; git diff

-* Make sure your local gnulib directory is up to date.
-
 * Run bootstrap: ./bootstrap

 FIXME: enable excluded programs like arch? to get their manual pages?

 * Pre-release testing:
+  Ensure that make check syntax-check succeeds.
   On at least one SELinux-enabled (enforcing) and one non-SELinux system,
 run all tests, both root-only and regular.
   Run *all* non-root tests, including expensive and very expensive ones i.e.,
@@ -32,16 +32,17 @@ FIXME: enable excluded programs like arch? to get their 
manual pages?
 * Manually set the date, version number, and [stable/alpha/beta] on
   line 3 of NEWS, then do e.g.,:

-v=7.3
+v=8.0
+pkg=$(sed -n 's/^PACKAGE = \(.*\)/\1/p' Makefile)
 git commit -F <(printf 'version '$v'\n\n* NEWS: Record release date.\n') -a
-git tag -s -m "coreutils $v" v$v HEAD
+git tag -s -m "$pkg $v" v$v HEAD

 * Run the following to create release tarballs.  Your choice selects the
   corresponding upload-to destination in the emitted gnupload command.
   The different destinations are specified in cfg.mk.  See the definitions
-  of gnu_ftp_host-{alpha,beta,major}.
+  of gnu_ftp_host-{alpha,beta,stable}.

-# "TYPE" must be major, beta or alpha
+# "TYPE" must be stable, beta or alpha
 make TYPE

 * Test the tarball.  copy it to a few odd-ball systems and ensure that
@@ -59,12 +60,15 @@ Once all the builds and tests have passed,
   that they're all valid.

 * Push the new tag:
-  git push origin tag v
+
+v=$(cat .prev-version)
+git push origin tag v$v

 * Send the gpg-signed announcement mail, e.g.,
+
 To: info-...@gnu.org, coreutils-annou...@gnu.org
 Cc: coordina...@translationproject.org, bug-coreutils@gnu.org
-Subject: coreutils-7.1 released [stable]
+Subject: coreutils-8.0 released [beta]

 * Approve the announcement here:
   http://lists.gnu.org/mailman/admindb/coreutils-announce
@@ -73,10 +77,13 @@ Once all the builds and tests have passed,
   From here:
 https://savannah.gnu.org/projects/coreutils/
   click on the "submit news", then write something like the following:
+  (If there is no such button, then enable "News" for the project via
+   the Main -> "Select Features" menu item, or via this link:
+   https://savannah.gnu.org/project/admin/editgroupfeatures.php?group=gzip)

-Subject: coreutils-7.2 released [stable]
+Subject: coreutils-0.0 released [beta]
 The announcement is here:
-  http://article.gmane.org/gmane.comp.gnu.core-utils.announce/49
+  http://article.gmane.org/gmane.comp.gnu.core-utils.announce/54

   Then go here to approve it:
 https://savannah.gnu.org/news/approve.php?group=coreutils
@@ -85,4 +92,6 @@ Once all the builds and tests have passed,

 http://www.gnu.org/software/coreutils/manual/

-  by running the gnu-web-doc-update script.
+  by running this:
+
+build-aux/gnu-web-doc-update
--
1.6.5.rc2.204.g8ea19

Re: please verify

[Pádraig Brady]

Chandan Kumar wrote:
> I am getting some faults while doing CAL command,
> i.e. i am getting some leap years in case of non-leap years i.e. the years 
> like 1000,500,1500,1700 etc

You got the wrong list but I work on the util-linux-ng
cal utility so you lucked out :)

Before the gregorian reformation in 1752 any year divisible
by 4 is considered a leap year.

cheers,
Pádraig.

Re: please verify

[Philip Rowlands]

On Mon, 5 Oct 2009, Chandan Kumar wrote:


I am getting some faults while doing CAL command,


cal is not part of GNU coreutils.

i.e. i am getting some leap years in case of non-leap years i.e. the 
years like 1000,500,1500,1700 etc


1700 is a leap year, and leap years predating 1582 (the adoption of the 
Gregorian Calendar) depend which calendar you're talking about.



Cheers,
Phil

Re: please verify

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Chandan Kumar on 10/5/2009 11:07 PM:
> I am getting some faults while doing CAL command,

Thanks for the report.  However, you have reached the GNU coreutils list,
and we are not responsible for the cal command.  You will need to report
this to the correct package.

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrLQ/wACgkQ84KuGfSFAYAhdgCcClQzLUhG9/IQX3/qKC2VOKVn
kfsAniafbiNrsCmlpTlRtkKpsWpHg7+q
=zYIs
-END PGP SIGNATURE-

coreutils-8.0 released [beta]

[Jim Meyering]

This is to announce coreutils-8.0.
We're calling this a beta release partly because rm has been
rewritten (now it uses gnulib's fts for its hierarchy traversal),
and partly because there have been so many changes in the
gnulib infrastructure involving file-system primitives.

Thanks to everyone who has been helping, especially Eric Blake,
Pádraig Brady and Ondřej Vašík.


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

To summarize the gnulib-related changes, run these commands
From a git-cloned coreutils directory:
  git checkout v8.0
  git submodule summary v7.6

Here are the compressed sources:
  ftp://alpha.gnu.org/gnu/coreutils/coreutils-8.0.tar.gz   (9.8MB)
  ftp://alpha.gnu.org/gnu/coreutils/coreutils-8.0.tar.xz   (4.1MB)

Here are the GPG detached signatures[*]:
  ftp://alpha.gnu.org/gnu/coreutils/coreutils-8.0.tar.gz.sig
  ftp://alpha.gnu.org/gnu/coreutils/coreutils-8.0.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-8.0.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.64.57-af6c
  Automake 1.11a
  Gnulib v0.0-2697-g6f6420c
  Bison 2.4.1.146-17a40

NEWS

* Noteworthy changes in release 8.0 (2009-10-06) [beta]

** Bug fixes

  cp --preserve=xattr and --archive now preserve extended attributes even
  when the source file doesn't have write access.
  [bug introduced in coreutils-7.1]

  touch -t [[CC]YY]MMDDhhmm[.ss] now accepts a timestamp string ending in .60,
  to accommodate leap seconds.
  [the bug dates back to the initial implementation]

  ls --color now reverts to the color of a base file type consistently
  when the color of a more specific type is disabled.
  [bug introduced in coreutils-5.90]

  ls -LR exits with status 2, not 0, when it encounters a cycle

  ls -is is now consistent with ls -lis in ignoring values returned
  from a failed stat/lstat.  For example ls -Lis now prints "?", not "0",
  for the inode number and allocated size of a dereferenced dangling symlink.

  tail --follow --pid now avoids a race condition where data written
  just before the process dies might not have been output by tail.
  Also, tail no longer delays at all when the specified pid is not live.
  [The race was introduced in coreutils-7.5,
   and the unnecessary delay was present since textutils-1.22o]

** Portability

  On Solaris 9, many commands would mistakenly treat file/ the same as
  file.  Now, even on such a system, path resolution obeys the POSIX
  rules that a trailing slash ensures that the preceeding name is a
  directory or a symlink to a directory.

** Changes in behavior

  id no longer prints SELinux " context=..." when the POSIXLY_CORRECT
  environment variable is set.

  readlink -f now ignores a trailing slash when deciding if the
  last component (possibly via a dangling symlink) can be created,
  since mkdir will succeed in that case.

** New features

  ln now accepts the options --logical (-L) and --physical (-P),
  added by POSIX 2008.  The default behavior is -P on systems like
  GNU/Linux where link(2) creates hard links to symlinks, and -L on
  BSD systems where link(2) follows symlinks.

  stat: without -f, a command-line argument of "-" now means standard input.
  With --file-system (-f), an argument of "-" is now rejected.
  If you really must operate on a file named "-", specify it as
  "./-" or use "--" to separate options from arguments.

** Improvements

  rm: rewrite to use gnulib's fts
  This makes rm -rf significantly faster (400-500%) in some pathological
  cases, and slightly slower (20%) in at least one pathological case.

  rm -r deletes deep hierarchies more efficiently.  Before, execution time
  was quadratic in the depth of the hierarchy, now it is merely linear.
  However, this improvement is not as pronounced as might be expected for
  very deep trees, because prior to this change, for any relative name
  length longer than 8KiB, rm -r would sacrifice official conformance to
  avoid the disproportionate quadratic performance penalty.  Leading to
  another improvement:

  rm -r is now slightly more standards-conformant when operating on
  write-protected files with relative names longer than 8KiB.


pgpAmXfGej7rq.pgp
Description: PGP signature

please verify

[Chandan Kumar]

I am getting some faults while doing CAL command,
i.e. i am getting some leap years in case of non-leap years i.e. the years like 
1000,500,1500,1700 etc
 
 


  From cricket scores to your friends. Try the Yahoo! India Homepage! 
http://in.yahoo.com/trynew

Re: new snapshot available: coreutils-7.6.63-addb6

[Simon Josefsson]

Pádraig Brady  writes:

> Jim Meyering wrote:
>> Pádraig Brady wrote:
>> 
>>> Jim Meyering wrote:
 Eric Blake wrote:
> According to Pádraig Brady on 10/5/2009 3:53 PM:
> This is a new test, but FC5 is s old,
> that I'm not sure it's worth worrying about.
 March 2006?
>>> The failure is probably a function of the kernel.
>>> Which is it?
>> In summary this is what fails:
>>
>> $ touch a
>> $ ln -s a symlink
>> $ ln -L symlink hardlink
>> ln: creating hard link `hardlink' => `symlink': Invalid argument
>>
>> `man linkat` says that AT_SYMLINK_FOLLOW is only supported since 2.6.18
>> and my FC5 system is 2.6.17
> This should fix it.  I don't have access to FC5, but I tested the new code
> path by priming the cache (gl_cv_func_linkat_follow=runtime ./configure)
> along with a temporary setting of have_follow_really=-1 in linkat.c.  I
> also verified that the replacement is not picked up on cygwin 1.7, where
> AT_SYMLINK_FOLLOW was implemented at the same time as linkat.
>
> The patch copies from areadlink.c, as well as link_follow earlier in
> linkat.c, to create two new fd-relative helpers.  For now, I didn't see
> any reason to expose them, but areadlinkat may someday be worth making
> into a full-blown module.
 Wow, that was quick.  Thanks.
 I should have read this first.

 I was just reviewing the changes in gnulib and
 see a few that should be included in the imminent coreutils
 beta release, so will probably take this one, too.
>>> Needs a couple of tweaks..
>>>
>>> This needs to be added to linkat.c
>>> (seems like it should be refactored somewhere?)
>>>
>>> #ifndef SIZE_MAX
>>> # define SIZE_MAX ((size_t) -1)
>>> #endif
>>> #ifndef SSIZE_MAX
>>> # define SSIZE_MAX ((ssize_t) (SIZE_MAX / 2))
>>> #endif
>> 
>> This should do it:
>> 
>>>From 6f6420cc9705dcfa545a28c674fddf5703e72c86 Mon Sep 17 00:00:00 2001
>> From: Jim Meyering 
>> Date: Tue, 6 Oct 2009 11:11:39 +0200
>> Subject: [PATCH] linkat: avoid compilation failure
>> 
>> * lib/linkat.c: Include  for use of SIZE_MAX.
>
> That works thanks.
>
> I suppose these should include stdint.h also?
>
> areadlink.c:# define SIZE_MAX ((size_t) -1)
> areadlink-with-size.c:# define SIZE_MAX ((size_t) -1)
> backupfile.c:# define SIZE_MAX ((size_t) -1)
> fnmatch.c:# define SIZE_MAX ((size_t) -1)
> quotearg.c:# define SIZE_MAX ((size_t) -1)
> striconv.c:# define SIZE_MAX ((size_t) -1)

Note that stdint.h may not be sufficient to get SIZE_MAX, quoting
size_max.h:

/* Get SIZE_MAX declaration on systems like Solaris 7/8/9.  */
# include 
/* Get SIZE_MAX declaration on systems like glibc 2.  */
# if HAVE_STDINT_H
#  include 
# endif
/* On systems where these include files don't define it, SIZE_MAX is defined
   in config.h.  */

However given that SIZE_MAX should be in stdint.h according to POSIX,
maybe it makes more sense to make sure gnulib's stdint.h replacement is
enabled when SIZE_MAX is not provided by the system's stdint.h?  And
then deprecate size_max.h in favor of stdint.

> While these already include stdint.h so should probably not redefine
>
> fts.c:# define SIZE_MAX ((size_t) -1)
> getdelim.c:# define SSIZE_MAX ((ssize_t) (SIZE_MAX / 2))
> getndelim2.c:# define SSIZE_MAX ((ssize_t) (SIZE_MAX / 2))

SSIZE_MAX should be provided by limit.h, see:

http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html

The stdint.h documentation doesn't mention SSIZE_MAX:

http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html

/Simon

Re: new snapshot available: coreutils-7.6.63-addb6

[Pádraig Brady]

Paolo Bonzini wrote:
> On 10/06/2009 11:05 AM, Pádraig Brady wrote:
>> Also a minor nit in s/Linux/Gnu\/Linux/
> 
> Definitely not when it's talking explicitly of a kernel version?

Right, it could be "GNU/Linux" or "Linux kernels? (.*)?"

cheers,
Pádraig.

Re: new snapshot available: coreutils-7.6.63-addb6

[Pádraig Brady]

Jim Meyering wrote:
> Pádraig Brady wrote:
> 
>> Jim Meyering wrote:
>>> Eric Blake wrote:
 According to Pádraig Brady on 10/5/2009 3:53 PM:
 This is a new test, but FC5 is s old,
 that I'm not sure it's worth worrying about.
>>> March 2006?
>> The failure is probably a function of the kernel.
>> Which is it?
> In summary this is what fails:
>
> $ touch a
> $ ln -s a symlink
> $ ln -L symlink hardlink
> ln: creating hard link `hardlink' => `symlink': Invalid argument
>
> `man linkat` says that AT_SYMLINK_FOLLOW is only supported since 2.6.18
> and my FC5 system is 2.6.17
 This should fix it.  I don't have access to FC5, but I tested the new code
 path by priming the cache (gl_cv_func_linkat_follow=runtime ./configure)
 along with a temporary setting of have_follow_really=-1 in linkat.c.  I
 also verified that the replacement is not picked up on cygwin 1.7, where
 AT_SYMLINK_FOLLOW was implemented at the same time as linkat.

 The patch copies from areadlink.c, as well as link_follow earlier in
 linkat.c, to create two new fd-relative helpers.  For now, I didn't see
 any reason to expose them, but areadlinkat may someday be worth making
 into a full-blown module.
>>> Wow, that was quick.  Thanks.
>>> I should have read this first.
>>>
>>> I was just reviewing the changes in gnulib and
>>> see a few that should be included in the imminent coreutils
>>> beta release, so will probably take this one, too.
>> Needs a couple of tweaks..
>>
>> This needs to be added to linkat.c
>> (seems like it should be refactored somewhere?)
>>
>> #ifndef SIZE_MAX
>> # define SIZE_MAX ((size_t) -1)
>> #endif
>> #ifndef SSIZE_MAX
>> # define SSIZE_MAX ((ssize_t) (SIZE_MAX / 2))
>> #endif
> 
> This should do it:
> 
>>From 6f6420cc9705dcfa545a28c674fddf5703e72c86 Mon Sep 17 00:00:00 2001
> From: Jim Meyering 
> Date: Tue, 6 Oct 2009 11:11:39 +0200
> Subject: [PATCH] linkat: avoid compilation failure
> 
> * lib/linkat.c: Include  for use of SIZE_MAX.

That works thanks.

I suppose these should include stdint.h also?

areadlink.c:# define SIZE_MAX ((size_t) -1)
areadlink-with-size.c:# define SIZE_MAX ((size_t) -1)
backupfile.c:# define SIZE_MAX ((size_t) -1)
fnmatch.c:# define SIZE_MAX ((size_t) -1)
quotearg.c:# define SIZE_MAX ((size_t) -1)
striconv.c:# define SIZE_MAX ((size_t) -1)

While these already include stdint.h so should probably not redefine

fts.c:# define SIZE_MAX ((size_t) -1)
getdelim.c:# define SSIZE_MAX ((ssize_t) (SIZE_MAX / 2))
getndelim2.c:# define SSIZE_MAX ((ssize_t) (SIZE_MAX / 2))

cheers,
Pádraig.

Re: new snapshot available: coreutils-7.6.63-addb6

[Paolo Bonzini]

On 10/06/2009 11:05 AM, Pádraig Brady wrote:

Also a minor nit in s/Linux/Gnu\/Linux/


Definitely not when it's talking explicitly of a kernel version?

Paolo

Re: new snapshot available: coreutils-7.6.63-addb6

[Jim Meyering]

Pádraig Brady wrote:

> Jim Meyering wrote:
>> Eric Blake wrote:
>>> According to Pádraig Brady on 10/5/2009 3:53 PM:
>>> This is a new test, but FC5 is s old,
>>> that I'm not sure it's worth worrying about.
>> March 2006?
> The failure is probably a function of the kernel.
> Which is it?
 In summary this is what fails:

 $ touch a
 $ ln -s a symlink
 $ ln -L symlink hardlink
 ln: creating hard link `hardlink' => `symlink': Invalid argument

 `man linkat` says that AT_SYMLINK_FOLLOW is only supported since 2.6.18
 and my FC5 system is 2.6.17
>>> This should fix it.  I don't have access to FC5, but I tested the new code
>>> path by priming the cache (gl_cv_func_linkat_follow=runtime ./configure)
>>> along with a temporary setting of have_follow_really=-1 in linkat.c.  I
>>> also verified that the replacement is not picked up on cygwin 1.7, where
>>> AT_SYMLINK_FOLLOW was implemented at the same time as linkat.
>>>
>>> The patch copies from areadlink.c, as well as link_follow earlier in
>>> linkat.c, to create two new fd-relative helpers.  For now, I didn't see
>>> any reason to expose them, but areadlinkat may someday be worth making
>>> into a full-blown module.
>>
>> Wow, that was quick.  Thanks.
>> I should have read this first.
>>
>> I was just reviewing the changes in gnulib and
>> see a few that should be included in the imminent coreutils
>> beta release, so will probably take this one, too.
>
> Needs a couple of tweaks..
>
> This needs to be added to linkat.c
> (seems like it should be refactored somewhere?)
>
> #ifndef SIZE_MAX
> # define SIZE_MAX ((size_t) -1)
> #endif
> #ifndef SSIZE_MAX
> # define SSIZE_MAX ((ssize_t) (SIZE_MAX / 2))
> #endif

This should do it:

>From 6f6420cc9705dcfa545a28c674fddf5703e72c86 Mon Sep 17 00:00:00 2001
From: Jim Meyering 
Date: Tue, 6 Oct 2009 11:11:39 +0200
Subject: [PATCH] linkat: avoid compilation failure

* lib/linkat.c: Include  for use of SIZE_MAX.
---
 ChangeLog|5 +
 lib/linkat.c |1 +
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 0362497..c942631 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2009-10-06  Jim Meyering  
+
+   linkat: avoid compilation failure
+   * lib/linkat.c: Include  for use of SIZE_MAX.
+
 2009-10-05  Eric Blake  

linkat: support Linux 2.6.17
diff --git a/lib/linkat.c b/lib/linkat.c
index f785d09..e0dd8f2 100644
--- a/lib/linkat.c
+++ b/lib/linkat.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
--
1.6.5.rc2.204.g8ea19

Re: new snapshot available: coreutils-7.6.63-addb6

[Pádraig Brady]

Jim Meyering wrote:
> Eric Blake wrote:
>> According to Pádraig Brady on 10/5/2009 3:53 PM:
>> This is a new test, but FC5 is s old,
>> that I'm not sure it's worth worrying about.
> March 2006?
 The failure is probably a function of the kernel.
 Which is it?
>>> In summary this is what fails:
>>>
>>> $ touch a
>>> $ ln -s a symlink
>>> $ ln -L symlink hardlink
>>> ln: creating hard link `hardlink' => `symlink': Invalid argument
>>>
>>> `man linkat` says that AT_SYMLINK_FOLLOW is only supported since 2.6.18
>>> and my FC5 system is 2.6.17
>> This should fix it.  I don't have access to FC5, but I tested the new code
>> path by priming the cache (gl_cv_func_linkat_follow=runtime ./configure)
>> along with a temporary setting of have_follow_really=-1 in linkat.c.  I
>> also verified that the replacement is not picked up on cygwin 1.7, where
>> AT_SYMLINK_FOLLOW was implemented at the same time as linkat.
>>
>> The patch copies from areadlink.c, as well as link_follow earlier in
>> linkat.c, to create two new fd-relative helpers.  For now, I didn't see
>> any reason to expose them, but areadlinkat may someday be worth making
>> into a full-blown module.
> 
> Wow, that was quick.  Thanks.
> I should have read this first.
> 
> I was just reviewing the changes in gnulib and
> see a few that should be included in the imminent coreutils
> beta release, so will probably take this one, too.

Needs a couple of tweaks..

This needs to be added to linkat.c
(seems like it should be refactored somewhere?)

#ifndef SIZE_MAX
# define SIZE_MAX ((size_t) -1)
#endif
#ifndef SSIZE_MAX
# define SSIZE_MAX ((ssize_t) (SIZE_MAX / 2))
#endif

Also a minor nit in s/Linux/Gnu\/Linux/

After that the test passes.

cheers,
Pádraig.

Re: new snapshot available: coreutils-7.6.63-addb6

[Jim Meyering]

Eric Blake wrote:
> According to Pádraig Brady on 10/5/2009 3:53 PM:
> This is a new test, but FC5 is s old,
> that I'm not sure it's worth worrying about.
 March 2006?
>>> The failure is probably a function of the kernel.
>>> Which is it?
>>
>> In summary this is what fails:
>>
>> $ touch a
>> $ ln -s a symlink
>> $ ln -L symlink hardlink
>> ln: creating hard link `hardlink' => `symlink': Invalid argument
>>
>> `man linkat` says that AT_SYMLINK_FOLLOW is only supported since 2.6.18
>> and my FC5 system is 2.6.17
>
> This should fix it.  I don't have access to FC5, but I tested the new code
> path by priming the cache (gl_cv_func_linkat_follow=runtime ./configure)
> along with a temporary setting of have_follow_really=-1 in linkat.c.  I
> also verified that the replacement is not picked up on cygwin 1.7, where
> AT_SYMLINK_FOLLOW was implemented at the same time as linkat.
>
> The patch copies from areadlink.c, as well as link_follow earlier in
> linkat.c, to create two new fd-relative helpers.  For now, I didn't see
> any reason to expose them, but areadlinkat may someday be worth making
> into a full-blown module.

Wow, that was quick.  Thanks.
I should have read this first.

I was just reviewing the changes in gnulib and
see a few that should be included in the imminent coreutils
beta release, so will probably take this one, too.

Re: new snapshot available: coreutils-7.6.63-addb6

[Jim Meyering]

Eric Blake wrote:
> Pádraig Brady  draigBrady.com> writes:
>
>> ln: creating hard link `hardlink' => `symlink': Invalid argument
>>
>> `man linkat` says that AT_SYMLINK_FOLLOW is only supported since 2.6.18
>> and my FC5 system is 2.6.17
>
> Bingo.  For FC5, I need to implement rpl_linkat in gnulib, which mimics the
> link_follow fallback used on systems that lack linkat altogether, if linkat
> (,AT_SYMLINK_FOLLOW) fails with EINVAL.  And probably enable rpl_linkat
> unconditionally at configure time for Linux, for the benefit of people that
> compiled against newer headers but run against an older kernel; the 
> replacement
> code would need a static variable that learns whether we expect success or
> failure, similar to how we've wrapped O_CLOEXEC support in recent modules when
> compiling against newer headers and older kernel.
>
> Jim, do you want to wait for me to get that done in gnulib, or do we just 
> state
> that since 8.0 will be beta that it is a known bug which will be fixed for 
> 8.1?

I'm ready to release today, and that failure is far enough out on
the fringe that I have no qualms.

This makes two known bugs.  The fix for the other will be
always-required l?getfilecon wrappers to avoid segfaulting
on old-kernel-munged disks and/or old versions of libselinux.

Re: [PATCH]: chcon: no longer abort on SELinux disabled kernel

[Jim Meyering]

Jim Meyering wrote:
> Stephen Smalley wrote:
> ...
>> Must have previously booted an ancient kernel with SELinux permissive
>> and no policy loaded.  Kernel was fixed by the commit below in 2006.
>> I'd recommend that he run the following to clean up the droppings in his
>> filesystem:
>> find / \( -fstype ext2 -o -fstype ext3 -o -fstype ext4 \) -exec setfattr -x 
>> security.selinux {} \;
>>
>> commit 8aad38752e81d1d4de67e3d8e2524618ce7c9276
>> Author: Stephen Smalley 
>> Date:   Wed Mar 22 00:09:13 2006 -0800
>>
>> [PATCH] selinux: Disable automatic labeling of new inodes when no policy 
>> is loaded
>
> Thanks for the quick explanation!

I've revised the commit not to say anything in NEWS
and to expand the log message.  While the exit-early
change doesn't solve the problem in all cases, it is useful
and does make chcon consistent with runcon in that respect.

>From 3a97d664b9f639fddb5a245775f47d27bfbb56c9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ond=C5=99ej=20Va=C5=A1=C3=ADk?= 
Date: Mon, 5 Oct 2009 09:20:48 +0200
Subject: [PATCH] chcon: exit immediately if SELinux is disabled

This change happens to avoid an abort in chcon when SELinux is
disabled while operating on a file with an "unlabeled" context from
back in 2006.  However, that same abort can still be triggered by the
same file when running chcon with SELinux enabled.  This bug in chcon
will be fixed in a subsequent commit via a getfilecon wrapper.  See
http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/18378/focus=18384
for how to correct your disk attributes to avoid triggering this bug.
* src/chcon.c (main): Exit immediately if SELinux is disabled.
Reported in http://bugzilla.redhat.com/527142 by Yanko Kaneti.
* src/runcon.c (main): Do not hardcode program name in error message.
* THANKS: Update.
---
 THANKS   |1 +
 src/chcon.c  |4 
 src/runcon.c |2 +-
 3 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/THANKS b/THANKS
index e0e14e5..65ac1bb 100644
--- a/THANKS
+++ b/THANKS
@@ -612,6 +612,7 @@ Wis Macomsonwis.macom...@intel.com
 Wojciech Purczynski cl...@isec.pl
 Wolfram Kleff   kl...@cs.uni-bonn.de
 Won-kyu Parkwkp...@chem.skku.ac.kr
+Yanko Kanetiyan...@declera.com
 Yann Dirson dir...@debian.org
 Zvi Har'El  r...@math.technion.ac.il

diff --git a/src/chcon.c b/src/chcon.c
index fbfdb4d..c0da694 100644
--- a/src/chcon.c
+++ b/src/chcon.c
@@ -519,6 +519,10 @@ main (int argc, char **argv)
   usage (EXIT_FAILURE);
 }

+  if (is_selinux_enabled () != 1)
+error (EXIT_FAILURE, 0,
+   _("%s may be used only on a SELinux kernel"), program_name);
+
   if (reference_file)
 {
   if (getfilecon (reference_file, &ref_context) < 0)
diff --git a/src/runcon.c b/src/runcon.c
index e0019da..f87eada 100644
--- a/src/runcon.c
+++ b/src/runcon.c
@@ -195,7 +195,7 @@ main (int argc, char **argv)

   if (is_selinux_enabled () != 1)
 error (EXIT_FAILURE, 0,
-   _("runcon may be used only on a SELinux kernel"));
+   _("%s may be used only on a SELinux kernel"), program_name);

   if (context)
 {
--
1.6.5.rc2.204.g8ea19