Subject: Re: bug#5999: new snapshot available: coreutils-8.4.100-81926

From: Jim Meyering <[email-masked]>
Date: Fri, 23 Apr 2010 09:15:33 +0200

Gilles Espinasse wrote:
...
> I forgot to report the spurious configure test
> util-linux-ng
> [     2.17.2 ] [         0 ] [ DONE ]
> e2fsprogs
> [    1.41.11 ] [         0 ] [ DONE ]
> coreutils
> [ 8.4..81926 ]*** %n in writable segment detected ***

I'm pretty sure that output comes from the C library writing to /dev/tty
during a "run test".

> To hide that, we use
>  gl_cv_func_printf_directive_n=no ./configure
>
> We use gl_cv_func_printf_directive_n=no in gzip and m4 too where the same
> problem happen.

Priming the cache with a value saying "the %n directive is mishandled"
does indeed skip the test and avoid the warning-to-tty, but it may make
the resulting tools unnecessarily avoid using your C library's functions.
Why did you choose "no" rather than "yes"?  At least on glibc-based
systems, %n does work the way it's supposed to.

>> > There is a few SKIP that I am not sure of the real cause
>> > ./misc/pwd-unreadable-parent: skipping test: can't use buggy system
> getcwd
> ...
>>
>> > (FS is ext3)
>> > ./du/slink: skipping test: `.' is on an XFS file system
>> > SKIP: du/slink
>>
>> This test would generate spurious failures when using an XFS file
>> system.  Here's the code:
>>
>>   if df --type=xfs . >/dev/null 2>&1; then
>>     # At least on Irix-6.5.19, when using an xfs file system,
>>     # each created symlink (name lengths up to 255) would have a size of
> `0'.
>>     skip_test_ "\`.' is on an XFS file system"
>>   fi
>
> Should not "\`.' is not an XFS file system" be reported?

The above runs "df --type=xfs .".
If that fails (as it should on an ext3 FS), the "if"-block
should not be run.  Here's what I get:

    $ df --type=xfs .
    df: no file systems processed
    [Exit 1]

>> > ./mv/i-3: skipping test: /dev/stdin is not readable
>> > SKIP: mv/i-3
>>
>> Normally, the special file, /dev/stdin is readable.
>> Without that, we must skip this test.
>>
> I suspect it is skipped for a bad reason
> [chroot-i486] root:/$  ls -l /dev/stdin
> lrwxrwxrwx 1 root root 4 Apr 22 17:51 /dev/stdin -> fd/0
> [chroot-i486] root:/$ test -r /dev/stdin || echo not readable
>
> I will try to look at that.

What does ls -L /dev/stdin print?
Or ls -l /dev/fd/0 ?