Ben Woodcroft <b.woodcr...@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 <l...@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
