From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: bug#36754: New linux-libre failed to build on armhf on Berlin Date: Mon, 22 Jul 2019 13:13:11 -0400 Message-ID: <87zhl656xk.fsf@netris.org> References: <87o91n3ps0.fsf@netris.org> <87o91n3ps0.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:48188) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hpbtv-0001Ek-A8 for bug-guix@gnu.org; Mon, 22 Jul 2019 13:15:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hpbtu-0004hz-5Y for bug-guix@gnu.org; Mon, 22 Jul 2019 13:15:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:52979) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hpbtu-0004hv-1o for bug-guix@gnu.org; Mon, 22 Jul 2019 13:15:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hpbtt-0004C4-Pc for bug-guix@gnu.org; Mon, 22 Jul 2019 13:15:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87o91n3ps0.fsf@netris.org> 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: 36754@debbugs.gnu.org Hi Ricardo, Interesting. I distinctly remember that there was no log file when I looked last time. Hmm. Anyway, it seems that now, all of the failed builds have either build logs available or else information about which dependency failed. I don't remember seeing any of this last time, but I'm glad to see it now. A pattern has now emerged, but I don't know what it means. All of the armhf kernel builds failed except for linux-libre-arm-veyron-5.2.2, which succeeded: https://ci.guix.gnu.org/build/1488502/details (arm-veyron-5.2.2) Apart from this anomalous success, all of the armhf 5.2.2 and 4.19.60 have a truncated log file: https://ci.guix.gnu.org/build/1488517/details (5.2.2) https://ci.guix.gnu.org/build/1488503/details (4.19.60) https://ci.guix.gnu.org/build/1488513/details (arm-generic-5.2.2) https://ci.guix.gnu.org/build/1488519/details (arm-generic-4.19.60) https://ci.guix.gnu.org/build/1488504/details (arm-omap2plus-5.2.2) https://ci.guix.gnu.org/build/1488501/details (arm-omap2plus-4.19.60) This pattern seems too regular to be a coincidence. Can we find out which build machines were used for these builds? All of the 4.14.134 builds failed in the deblobbing step, due to timeout (1 hour of silence) while packing the linux-libre tarball: https://ci.guix.gnu.org/build/1488514/details (4.14.134) https://ci.guix.gnu.org/build/1488515/details (arm-generic-4.14.134) https://ci.guix.gnu.org/build/1488512/details (arm-omap2plus-4.14.134) I'm not sure how to deal with this. This is a computed origin, not a normal package, and so I don't see a way to configure a longer timeout. Perhaps I should make the tarball packing and unpacking operations verbose, to work around the issue. Of course that's our usual practice, but I find it suboptimal because any warnings will be buried in a mountain of uninteresting output. Thoughts? Anyway, thanks for looking into it. Mark