From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: bug#31647: [core-updates] gtkglext fails in a weird way Date: Wed, 30 May 2018 08:50:33 +0200 Message-ID: <874lipr612.fsf@mdc-berlin.de> References: <87d0xeqq6l.fsf@elephly.net> <87a7siqk5m.fsf@mdc-berlin.de> <8736y9dcev.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36587) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fNuws-00006W-Js for bug-guix@gnu.org; Wed, 30 May 2018 02:51:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fNuwo-0006GE-Lm for bug-guix@gnu.org; Wed, 30 May 2018 02:51:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:46687) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fNuwo-0006Fw-AS for bug-guix@gnu.org; Wed, 30 May 2018 02:51:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fNuwn-0004Sr-TW for bug-guix@gnu.org; Wed, 30 May 2018 02:51:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <8736y9dcev.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: Mark H Weaver Cc: 31647@debbugs.gnu.org Mark H Weaver writes: > Ricardo Wurmus writes: > >>> on “core-updates” the “gtkglext” package fails with an odd error >>> message: […] >> >> It seems that this is not limited to “gtkglext”. This behaviour seems >> to affect any package using “invoke” where the invoked command fails. >> >> Should the build system catch the exception and make sure that it gets >> to print “build phase `foo' failed”? > > In my opinion, it's not important for that message to be printed. What > is being printed now is far more informative, and sometimes that extra > information is quite useful. […] > Also, even if we catch the exception and do a nice job printing it, we'd > likely lose the backtrace to the original error, which in some cases > might be quite useful. Since the build system itself uses invoke to run “make” any error encountered during the build phase looks something like this: --8<---------------cut here---------------start------------->8--- Backtrace: 4 (primitive-load "/gnu/store/vrv8gx4s940z0vaaq9a40jsq9xf…") In ice-9/eval.scm: 191:35 3 (_ _) In srfi/srfi-1.scm: 640:9 2 (for-each # …) In /gnu/store/qzsljkcllc01dmdq9z0yrqri3ajam3vp-module-import/guix/build/gnu-build-system.scm: 799:31 1 (_ _) In /gnu/store/qzsljkcllc01dmdq9z0yrqri3ajam3vp-module-import/guix/build/utils.scm: 616:6 0 (invoke _ . _) /gnu/store/qzsljkcllc01dmdq9z0yrqri3ajam3vp-module-import/guix/build/utils.scm:616:6: In procedure invoke: Throw to key `srfi-34' with args `(#)'. builder for `/gnu/store/2yn2kz4vdfxrrm8lcxfkfbx2548rrmd6-powertabeditor-2.0.0-alpha10.drv' failed with exit code 1 --8<---------------cut here---------------end--------------->8--- It doesn’t seem like this information is actually useful. I see here that make failed, which is obvious because we are in the build phase. I don’t see why it failed. I could do without the information that the “gnu-build-system” uses invoke internally, because “invoke” is not at fault here. Previously, we had the phase return #f, which allowed us to cleanly exit, inform the observant user about the phase that failed (this is useful because the name of the phase may have long scrolled out of the buffer), and exit. The backtrace for invoke does not seem to add anything of importance and it obscures the actual error. > In summary, although the new messages don't look as nice in common > cases, I think it's more important to ensure that we have the > information we need to debug the occasional non-obvious problem. So, I > think we should leave it alone :) I think we should strive to make the common case look good. Can we achieve this without making the exceptional case harder to debug? Can we caught the exception triggered by standard build phase invocations of “make” but not those of custom “invoke” expressions in custom build phases where the error message could be useful? What do others think? -- Ricardo