From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Famulari Subject: Re: [PATCH] gnu: Add dlib. Date: Sun, 21 Aug 2016 16:17:57 -0400 Message-ID: <20160821201757.GA21038@jasmine> References: <20160815222840.GA10735@jasmine> <4752bc68-5466-6c26-a7b4-e53aec400ff5@uq.edu.au> <8760r10z7n.fsf@ike.i-did-not-set--mail-host-address--so-tickle-me> <20160816204736.GA25753@jasmine> <993034f9-ceae-525f-01b9-0b8af7a5aafe@uq.edu.au> <20160816234507.GA24224@jasmine> <87h9ajzc1z.fsf@ike.i-did-not-set--mail-host-address--so-tickle-me> <20160818202353.GB2393@jasmine> <8737m1yqru.fsf@ike.i-did-not-set--mail-host-address--so-tickle-me> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52391) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bbZC7-0006K2-DV for guix-devel@gnu.org; Sun, 21 Aug 2016 16:18:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bbZC3-00076N-Ap for guix-devel@gnu.org; Sun, 21 Aug 2016 16:18:11 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:33262) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bbZC2-00075V-45 for guix-devel@gnu.org; Sun, 21 Aug 2016 16:18:07 -0400 Content-Disposition: inline In-Reply-To: <8737m1yqru.fsf@ike.i-did-not-set--mail-host-address--so-tickle-me> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Marius Bakke Cc: guix-devel , Alex Kost 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 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.