Re: [PATCH] gnu: Add dlib.

[Marius Bakke]

Marius Bakke <address@hidden> writes:

> Leo Famulari <address@hidden> writes:
>
>> On Wed, Aug 24, 2016 at 11:26:28AM +0100, Marius Bakke wrote:
>>> There are a couple of things going on in this thread:
>>> 
>>> 1. Segfault on x86_64. This seems to have been resolved simply by
>>> updating OpenBLAS. At least, I'm no longer able to reproduce it even
>>> with LAPACK in inputs. So, that should fix the Hydra x86_64 build.
>>> Can the OpenBLAS update be cherry-picked to master?
>>
>> I'd say it depends on whether the OpenBLAS users are building
>> successfully on core-updates, but unfortunately core-updates is
>> currently failing early in the bootstrap process [0]. Can you take a
>> look at `guix refresh -l dlib` and pick some important looking
>> applications to test with the updated OpenBLAS?
>
> I'm currently building the following openblas dependents: `libreoffice
> bamm python-biom-format clipper shogun armadillo julia` and will try to
> test BLAS functionality in some of them.

Shogun failed to build in this run. I don't have time to investigate
further, so picking the OpenBLAS update is not very appealing.

Instead I opted to disable the test that fails with lapack (and without,
on Hydra), since it's one specific openblas operation that is not unique
to dlib. I think it's an acceptable tradeoff, to give users the full
dlib functionality, and have the segfault "sort itself" when
core-updates lands in master.

>>> 2. i686 test failures. Updating OpenBLAS fixed 1/5 errors. The remaining
>>> four are reproducible on 32-bit Ubuntu, so they do not seem Guix
>>> related. Upstream has been notified.
>>> 
>>> 3. ARM failures. I don't have ARM hardware to test on, but I'm guessing
>>> it's similar to i686 (i.e. not directly Guix related).
>>
>> Maybe dlib is 64-bit only? If that's the case, we can disable it on
>> those architectures.
>
> According to the developer[0], these targets should be supported.
>
> 0: https://github.com/davisking/dlib/issues/197
>
> We could disable tests (at least the failing ones) on these platforms
> until this issue is resolved. The mips64el target on Hydra times out
> after 3600 seconds on one of the tests, but seems fine up to that point.
> Some of these tests are fairly CPU heavy, so the timeout may be too low.

Below is a patch which disables these tests (and the above segfault) for
19.1, rather than backporting the patches from dlib master branch.

One note about the patch: I could not figure out how to pass the list of
tests as arguments to `substitute*`, so currently it calls `substitute*`
for each of them. Any tips to prevent this?

It also no longer builds the main application twice for tests.

0001-gnu-dlib-Remove-unused-fftw-from-inputs.patch
Description: Text Data

0002-gnu-dlib-Disable-failing-tests.patch
Description: Text Data