On Sat, Sep 10, 2016 at 01:32:22PM +0100, Marius Bakke wrote:
> + (add-after 'disable-asserts 'disable-failing-tests
> + (lambda _
> + ;; One test times out on MIPS, so we need to disable it.
> + ;; The rest is known to fail on non-x86_64 platforms in the
On Sat, Sep 10, 2016 at 02:16:09PM -0400, Leo Famulari wrote:
> On Sat, Sep 10, 2016 at 01:32:22PM +0100, Marius Bakke wrote:
> > Marius Bakke writes:
> >
> > > Leo Famulari writes:
> > >
> > >> Changing the subject, you could disable the tests per-architecture. Look
> > >> for uses of current-t
On Sat, Sep 10, 2016 at 01:32:22PM +0100, Marius Bakke wrote:
> Marius Bakke writes:
>
> > Leo Famulari writes:
> >
> >> Changing the subject, you could disable the tests per-architecture. Look
> >> for uses of current-target-system and current-system for usage examples.
> >> But this is not abs
Marius Bakke writes:
> Leo Famulari writes:
>
>> Changing the subject, you could disable the tests per-architecture. Look
>> for uses of current-target-system and current-system for usage examples.
>> But this is not absolutely required, IMO.
>
> This latest patch series now disables tests on a
Leo Famulari writes:
> Changing the subject, you could disable the tests per-architecture. Look
> for uses of current-target-system and current-system for usage examples.
> But this is not absolutely required, IMO.
This latest patch series now disables tests on a per-arch basis.
There may be ot
On Tue, Aug 30, 2016 at 03:43:05PM +0100, Marius Bakke wrote:
> 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
Marius Bakke writes:
> Leo Famulari 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
On 24 August 2016 3:08:58 PM GMT-04:00, Marius Bakke
wrote:
>
>>> Adding "#:parallel-build? #f" had no effect on tests, indeed the
>check
>>> phase does not seem to use the previously built dlib; it builds it
>again
>>> without parallel-build. I will try reproducing the
>non-reproducibility
>>
Leo Famulari 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 LA
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 shoul
Marius Bakke writes:
>> 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.
>>
>
> 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, b
Ben Woodcroft 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 writes:
>>>
I pushed the patch as 5f0ff6a9e. Hopefully dlib is still useful without
lapack. We should really figure out what the issue is and
On 21/08/16 16:17, Leo Famulari wrote:
On Fri, Aug 19, 2016 at 11:52:37AM +0100, Marius Bakke wrote:
Leo Famulari 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 buil
On Fri, Aug 19, 2016 at 11:52:37AM +0100, Marius Bakke wrote:
> Leo Famulari 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 t
Leo Famulari 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 thing
On Wed, Aug 17, 2016 at 03:48:24PM +0100, Marius Bakke wrote:
> I've attached a patch with a #t in the disable-asserts phase, and also
> deleting the 6MB static library.
>
> Since `guix build --rounds=2` passes, is there any reason to delay this
> patch? I've built this on GuixSD and a foreign dis
On Wed, Aug 17, 2016 at 01:24:46PM +1000, Ben Woodcroft wrote:
> On 17/08/16 09:45, Leo Famulari wrote:
> > How did it appear non-deterministic to you?
> Just based on guix build --check:
>
> guix build: error: build failed: derivation
> `/gnu/store/sxybcxw64q1ajzq6dysal75ffgq6238i-dlib-19.1.drv'
Ben Woodcroft writes:
> On 17/08/16 09:45, Leo Famulari wrote:
>> On Wed, Aug 17, 2016 at 09:31:11AM +1000, Ben Woodcroft wrote:
>>>
>>> On 17/08/16 06:47, Leo Famulari wrote:
On Tue, Aug 16, 2016 at 11:45:16AM +0100, Marius Bakke wrote:
> I initially made this package on a foreign distr
On 17/08/16 13:24, Ben Woodcroft wrote:
On 17/08/16 09:45, Leo Famulari wrote:
On Wed, Aug 17, 2016 at 09:31:11AM +1000, Ben Woodcroft wrote:
On 17/08/16 06:47, Leo Famulari wrote:
On Tue, Aug 16, 2016 at 11:45:16AM +0100, Marius Bakke wrote:
I initially made this package on a foreign di
On 17/08/16 09:45, Leo Famulari wrote:
On Wed, Aug 17, 2016 at 09:31:11AM +1000, Ben Woodcroft wrote:
On 17/08/16 06:47, Leo Famulari wrote:
On Tue, Aug 16, 2016 at 11:45:16AM +0100, Marius Bakke wrote:
I initially made this package on a foreign distro without "lapack" in
inputs and have ve
On Wed, Aug 17, 2016 at 09:31:11AM +1000, Ben Woodcroft wrote:
>
>
> On 17/08/16 06:47, Leo Famulari wrote:
> > On Tue, Aug 16, 2016 at 11:45:16AM +0100, Marius Bakke wrote:
> > > I initially made this package on a foreign distro without "lapack" in
> > > inputs and have verified that dropping LA
On 17/08/16 06:47, Leo Famulari wrote:
On Tue, Aug 16, 2016 at 11:45:16AM +0100, Marius Bakke wrote:
I initially made this package on a foreign distro without "lapack" in
inputs and have verified that dropping LAPACK makes the tests pass.
I also found some other optional dependencies after di
On Tue, Aug 16, 2016 at 11:45:16AM +0100, Marius Bakke wrote:
> I initially made this package on a foreign distro without "lapack" in
> inputs and have verified that dropping LAPACK makes the tests pass.
>
> I also found some other optional dependencies after digging around the
> source, as well a
Ben Woodcroft writes:
> On 16/08/16 08:28, Leo Famulari wrote:
>> On Mon, Aug 15, 2016 at 09:29:11PM +0100, Marius Bakke wrote:
>>> Leo Famulari writes:
Running test_empirical_kernel_map / phase `check' failed after 2043.7
seconds
>>> Strange, I've built this dozens of times now with
On 16/08/16 08:28, Leo Famulari wrote:
On Mon, Aug 15, 2016 at 09:29:11PM +0100, Marius Bakke wrote:
Leo Famulari writes:
Running test_empirical_kernel_map / phase `check' failed after 2043.7 seconds
Strange, I've built this dozens of times now with no test failures
(GuixSD on amd64). Are you
On Mon, Aug 15, 2016 at 09:29:11PM +0100, Marius Bakke wrote:
> Leo Famulari writes:
> > Running test_empirical_kernel_map / phase `check' failed after 2043.7
> > seconds
>
> Strange, I've built this dozens of times now with no test failures
> (GuixSD on amd64). Are you memory constrained by an
Leo Famulari writes:
> On Mon, Aug 15, 2016 at 12:51:15PM +0100, Marius Bakke wrote:
>> Date: Sat, 13 Aug 2016 11:26:10 +0100
>> Subject: [PATCH] gnu: Add dlib.
>>
>> * gnu/packages/machine-learning.scm (dlib): New variable.
>
> Thanks for the updated patch.
>
> Does it build for you? On my x86_
On Mon, Aug 15, 2016 at 12:51:15PM +0100, Marius Bakke wrote:
> Date: Sat, 13 Aug 2016 11:26:10 +0100
> Subject: [PATCH] gnu: Add dlib.
>
> * gnu/packages/machine-learning.scm (dlib): New variable.
Thanks for the updated patch.
Does it build for you? On my x86_64 machine, it fails consistently.
>> +(build-system cmake-build-system)
>> +(arguments
>> + `(#:phases
>> + (let ((test-dir (string-append "../dlib-" ,version
>> "/dlib/test/build")))
>
> I think it's better to move this 'let' inside the phase: ...
>
>> + (modify-phases %standard-phases
>> + (r
Marius Bakke (2016-08-14 22:52 +0300) wrote:
Hello and welcome!
> From 5e30eff1cf24b236a78cc5abed870992e84f443f Mon Sep 17 00:00:00 2001
> From: Marius Bakke
> Date: Sat, 13 Aug 2016 11:26:10 +0100
> Subject: [PATCH] gnu: Add dlib.
[...]
> +(define-public dlib
> + (package
> +(name "dlib")
Leo Famulari writes:
>> +(version "19.0")
>
> The released 19.1 yesterday. Will you send an updated patch using the
> latest version?
Wow, fresh out of the oven :)
>
>> +(arguments
>> + `(#:phases
>> + (let ((test-dir (string-append "../dlib-" ,version
>> "/dlib/test/build"))
On Sat, Aug 13, 2016 at 06:15:59PM +0100, Marius Bakke wrote:
> * gnu/packages/machine-learning.scm (dlib): New variable.
Thanks!
> +(version "19.0")
The released 19.1 yesterday. Will you send an updated patch using the
latest version?
> +(arguments
> + `(#:phases
> + (let ((t
33 matches
Mail list logo
