Re: new snapshot available: coreutils-8.25.120-ca99c

[Pádraig Brady]

On 27/11/16 04:22, Assaf Gordon wrote:
> Hello Pádraig and all,
> 
>> On Nov 24, 2016, at 11:51, Pádraig Brady <address@hidden> wrote:
>>  https://pixelbeat.org/cu/coreutils-ss.tar.xz
> 
> Few more tests results. Some are already known, but I'm mentioning them for 
> completeness.
> 
> No test failures on x86-64 with:
>    Ubuntu 14.04, 15.04, 16.04
>    CentOS 6.5, 7.0
>    Debian 7.6, 8.1
>    Fedora 24, 23, 22
>    OpenSUSE 42.1, 13.2
>    OpenBSD 6.0, 5.9, 5.8
>    FreeBSD 10.3 (note that 11 does fail, below)
>    Trisquel 6.0.1, 7.0 (ubuntu derivative)
>    Darwin 14.5.0,  15.6.0
> and on:
>    Fedora 20 (ppc64)
>    Ubuntu 14.04 (aarch64)
>    Fedora 21 (ppc64le)
>    Ubuntu 15.04 (i686)

Getting there ...

> Some failures:
> 
> AIX-7: build failure, previously discussed here:
>   http://lists.gnu.org/archive/html/bug-coreutils/2016-01/msg00040.html
> 
> 
> FreeBSD 11p1: 1 test fail.
> Log attached.
> 
>    FAIL: tests/misc/head-write-error
>    =================================
>    + diff -u exp err
>    --- exp    2016-11-25 22:08:55.826372000 +0000
>    +++ err    2016-11-25 22:08:55.842703000 +0000
>    @@ -1 +1 @@
>    -head: error writing 'standard output'
>    +head: 'standard input': cannot seek to offset 65535
>    + fail=1

Hmm, that implies that st->st_size > ST_BLKSIZE(*st)
for pipes on FreeBSD 11. Maybe we should explicitly
disallow st_size==0 for the seekable case?
More generally should we fall back to the nonseekable
path if the seek fails.

Also the sed adjustment to the error doesn't seem to be working?
I.E. I'm surprised to see the ": cannot seek..." portion of the message.

I'll see can I test on a VM...

> NetBSD 7.0.1:
> Same errors as in mentioned here:
>   http://lists.gnu.org/archive/html/coreutils/2016-11/msg00056.html
> Log attached.
> (Something might be strange, as you've already fixed these and they don't 
> fail on FreeBSD.)

Yes the failure is now different and looks to be due
to the shell always returning 127 from `wait $pid`.
I see there's a similar bug in older ksh at least.

thanks!
Pádraig