From mboxrd@z Thu Jan 1 00:00:00 1970 From: taylanbayirli@gmail.com (Taylan Ulrich =?utf-8?Q?Bay=C4=B1rl=C4=B1?= =?utf-8?Q?=2FKammer?=) Subject: Re: proposal: make build failures explicit results in the store Date: Wed, 25 Nov 2015 09:52:12 +0100 Message-ID: <87610qmpfn.fsf@T420.taylan> References: <56556DFC.3050402@gmx.net> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53204) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1VoH-00048m-04 for guix-devel@gnu.org; Wed, 25 Nov 2015 03:52:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1VoG-0001oh-01 for guix-devel@gnu.org; Wed, 25 Nov 2015 03:52:16 -0500 Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]:35177) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1VoF-0001od-Q4 for guix-devel@gnu.org; Wed, 25 Nov 2015 03:52:15 -0500 Received: by wmuu63 with SMTP id u63so128309170wmu.0 for ; Wed, 25 Nov 2015 00:52:15 -0800 (PST) In-Reply-To: <56556DFC.3050402@gmx.net> (Florian Paul Schmidt's message of "Wed, 25 Nov 2015 09:14:52 +0100") 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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Florian Paul Schmidt Cc: guix-devel@gnu.org Florian Paul Schmidt writes: > Hi, > > currently I'm trying my hands on building _all_ available packages on > the x86_64 platform in a qemu-vm (with the intended aim to later > publish them to maybe take some load off hydra), but I came across an > issue that might have an easy solution but I'm not sure exactly what's > the right way to proceed. > > Basically what I did right now was this: > > for n in `guix package -A | cut -f1`; do guix build --no-substitutes\ > --max-silent-time=10 "$n" || true; done > > Watching it run I noticed something though: Some package, let's call > it "foo1", seemed to have package "bar" as depencency (the concrete > example for bar was Qt5 which is probably why I noticed ;)), but the > bar build failed. So building foo1 failed, too. So far so good, aside > from foo1's and bar's failure everything is fine. > > Now another package, foo2, comes along and it, too, depends on bar. > Since bar failed to build previously guix thinks it's a swell idea to > retry building bar. This, of course, is silly, and in this concrete > example, Qt5, a massive waste of cpu cycles and the only good thing it > does is to bring the universe closer to the heat death. Hi, You can run the Guix daemon with the switch --cache-failures and it will do pretty much exactly what you want. :-) (I'm not sure whether it actually puts the failures into /gnu/store in some format, so "pretty much.") Don't know why this isn't enabled by default. Taylan