Re: [PATCH] gnu: Add dlib.

[Marius Bakke <mbakke@fastmail.com>]

Ben Woodcroft <b.woodcroft@uq.edu.au> writes:

> On 21/08/16 16:17, Leo Famulari wrote:
>> On Fri, Aug 19, 2016 at 11:52:37AM +0100, Marius Bakke wrote:
>>> Leo Famulari <leo@famulari.name> writes:
>>>
>>>> I pushed the patch as 5f0ff6a9e. Hopefully dlib is still useful without
>>>> lapack. We should really figure out what the issue is and fix it :)
>>> I noticed this fails to build on Hydra. What's worse is that the i686,
>>> x86_64 and armhf targets fails at completely different things. armhf and
>>> i686 exits cleanly after failing 2 and 5 tests respectively, while the
>>> x86_64 target seems to get the segfault we saw with lapack in inputs.
>>>
>>> What should we do? I'd prefer to keep the package so it can easily be
>>> tested on various architectures, but can understand if it is reverted.
>>> Perhaps we can disable substitutes or tests, to stop bothering Hydra?
>>>
>>> I'll try reproducing it this weekend on various qemu configurations.
>> Let us know about the results of your tests. Then we can decide what to
>> do.
> Can this be fixed simply by using #parallel-build #f ? Doing so makes it 
> reproducible for me so arguably we should be doing that anyway, even if 
> it takes longer to build.

Any chance you can diff the outputs? If there is a race condition or
similar it may indeed fix some problems, but it would be nice to notify
upstream about it.

I opened an issue on their bug tracker, and the suggestion was to
disable BLAS: https://github.com/davisking/dlib/issues/197

Without OpenBLAS dlib will use an internal BLAS implementation. I'm
fairly certain that will at least fix the crash on x86_64, which was
a segfault in libopenblasp-r0.2.15.so when we had LAPACK in inputs, but
seems to consistently trigger on Hydra regardless.

I got busy this weekend, but will try to reproduce the i686 errors this
week; and also check if the newer openblas in core-updates solves the
x86_64 segfault.

Stay tuned...

-marius