[Pkg-javascript-devel] Bug#900237: libuv1: FTBFS on hppa: not ok 46 - fs_copyfile

[John David Anglin]

On 2018-06-03 10:09 AM, Helge Deller wrote:
> On 02.06.2018 17:01, John David Anglin wrote:
>> On 2018-06-02 4:35 AM, Dominique Dumont wrote:
>>> On Sun, 27 May 2018 17:35:40 -0400 John David Anglin<dave.anglin at bell.net>  wrote:
>>>> The value of r in the failing assertion is -233.  If the value is a standard
>>>> errno, it is ENOBUFS.
> No.
> The value of r in the failing assertion is -223, which is -EOPNOTSUPP.
>
> # r is -223    UV_ENOTSUP=-252 and EOPNOTSUPP=-223
You are correct.  I think I'm getting dyslexic.
>
>> The test used to pass with 1.18.0, so the problem appears to be a regression in libuv1.  I would
>> guess that the failure was introduced by the following change:
>> https://github.com/libuv/libuv/commit/3ae88200d6f52ea7b3d8ff9b8164adde65f6c43a
>>
>> The failure line corresponds to this addition.
>>
>> The change mentions that an error will be returned if the platform doesn't support copy-on-write.
>> I tend to think there's an issue with the error codes either in the kernel or libuv1.  I doubt we are
>> actually running out of memory.
> The problem is, that on parisc ENOTSUP and EOPNOTSUPP have different values, which breaks the checks.
> Other arches, e.g. x86-64 seem to have the same value for both, so there the check doesn't break.
>
> test-fs-copyfile.c checks for UV_ENOTSUP (which is ENOTSUP), while in src/unix/fs.c is checked against "errno != EOPNOTSUPP".
> This needs to be fixed in libuv1.
> The attached patch is just a workaround.
According to this manpage, the kernel returns EOPNOTSUPP, not ENOTSUP:
http://man7.org/linux/man-pages/man2/ioctl_ficlonerange.2.html

So, the test is wrong to check UV_ENOTSUP (ENOTSUP).

Thanks,
Dave

-- 
John David Anglin  dave.anglin at bell.net