From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: bug#35529: libdrm fails to build on armhf-linux Date: Sun, 05 May 2019 18:41:01 -0400 Message-ID: <87imuosew7.fsf@netris.org> References: <87d0l1n97o.fsf@netris.org> <87k1f8gl7k.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([209.51.188.92]:42494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNPqZ-0004BP-8T for bug-guix@gnu.org; Sun, 05 May 2019 18:43:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hNPqX-0007Od-RY for bug-guix@gnu.org; Sun, 05 May 2019 18:43:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:41605) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hNPqX-0007OX-NX for bug-guix@gnu.org; Sun, 05 May 2019 18:43:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hNPqX-0000Dh-KD for bug-guix@gnu.org; Sun, 05 May 2019 18:43:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87k1f8gl7k.fsf@elephly.net> (Ricardo Wurmus's message of "Fri, 03 May 2019 07:29:03 +0200") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ricardo Wurmus Cc: 35529@debbugs.gnu.org Hi Ricardo, Ricardo Wurmus writes: > Mark H Weaver writes: > >> Hydra failed two consecutive attempts to build libdrm on armhf-linux: >> >> https://hydra.gnu.org/build/3481547#tabs-summary >> >> Both build attempts were made on hydra-slave2, which is a Wandboard Quad >> based on the Freescale i.MX6 SOC. > > This has built fine on berlin. We have a completed build for > /gnu/store/3c28p8b07709isd9jlcnnnyrpgz4ndz8-libdrm-2.4.97. What kind of hardware was it built on? Note that the failure on Hydra was due to a timeout in the test suite: https://hydra.gnu.org/build/3481547/nixlog/6/tail-reload All of the other tests completed within a few seconds, but the timeout tripped after 1200 seconds. So, I'm not sure if it's simply that the build hardware is too slow. It might have actually gotten stuck. Perhaps the test uses /dev/random (as opposed to /dev/urandom) and there's not enough entropy available on the build machine. Thanks, Mark