unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Leo Famulari <leo@famulari.name>
To: Marius Bakke <mbakke@fastmail.com>
Cc: guix-devel <guix-devel@gnu.org>, Alex Kost <alezost@gmail.com>
Subject: Re: [PATCH] gnu: Add dlib.
Date: Wed, 24 Aug 2016 13:26:08 -0400	[thread overview]
Message-ID: <20160824172608.GA24668@jasmine> (raw)
In-Reply-To: <87eg5e4g4r.fsf@ike.i-did-not-set--mail-host-address--so-tickle-me>

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?

[0]
https://hydra.gnu.org/jobset/gnu/core-updates
http://lists.gnu.org/archive/html/guix-devel/2016-08/msg01390.html

> 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.

> 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
> on some higher end hardware, hopefully this week.

It's weird that it rebuilds the application again for the tests. Which
build is actually installed in the case of success? Is it worth an
upstream bug report?

> I've also found that FFTW is no longer used, apparently due to thread
> safety issues. So I'd appreciate if the following patch can be added.
> Apologies for not catching the missing reference earlier, I will be more
> careful in the future (fftw was added in the last minute..).

Can you hold this patch locally in your "dlib fixes" queue? It would
trigger a rebuild of dlib on Hydra, but I don't see the point when we
expect the build to fail near the end anyways.

  reply	other threads:[~2016-08-24 17:26 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-13 17:15 [PATCH] gnu: Add dlib Marius Bakke
2016-08-14 17:25 ` Leo Famulari
2016-08-14 19:52   ` Marius Bakke
2016-08-15  7:43     ` Alex Kost
2016-08-15 11:51       ` Marius Bakke
2016-08-15 20:15         ` Leo Famulari
2016-08-15 20:29           ` Marius Bakke
2016-08-15 22:28             ` Leo Famulari
2016-08-16  0:15               ` Ben Woodcroft
2016-08-16 10:45                 ` Marius Bakke
2016-08-16 20:47                   ` Leo Famulari
2016-08-16 23:31                     ` Ben Woodcroft
2016-08-16 23:45                       ` Leo Famulari
2016-08-17  3:24                         ` Ben Woodcroft
2016-08-17  5:01                           ` Ben Woodcroft
2016-08-17 14:48                           ` Marius Bakke
2016-08-18 20:23                             ` Leo Famulari
2016-08-19 10:52                               ` Marius Bakke
2016-08-21 20:17                                 ` Leo Famulari
2016-08-22  2:30                                   ` Ben Woodcroft
2016-08-22 12:01                                     ` Marius Bakke
2016-08-23 18:33                                       ` Marius Bakke
2016-08-24 10:26                                         ` Marius Bakke
2016-08-24 17:26                                           ` Leo Famulari [this message]
2016-08-24 19:08                                             ` Marius Bakke
2016-08-24 22:51                                               ` Ben Woodcroft
2016-08-30 14:43                                               ` Marius Bakke
2016-08-31 19:09                                                 ` Leo Famulari
2016-09-09 12:15                                                   ` Marius Bakke
2016-09-10 12:32                                                     ` Marius Bakke
2016-09-10 18:16                                                       ` Leo Famulari
2016-09-13  5:14                                                         ` Leo Famulari
2016-09-13  5:14                                                       ` Leo Famulari
2016-08-18 20:18                           ` Leo Famulari

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160824172608.GA24668@jasmine \
    --to=leo@famulari.name \
    --cc=alezost@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=mbakke@fastmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).