From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: bug#31647: [core-updates] gtkglext fails in a weird way Date: Wed, 30 May 2018 04:27:56 -0400 Message-ID: <87y3g1a6pf.fsf@netris.org> References: <87d0xeqq6l.fsf@elephly.net> <87a7siqk5m.fsf@mdc-berlin.de> <8736y9dcev.fsf@netris.org> <874lipr612.fsf@mdc-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54681) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fNwUg-000090-2w for bug-guix@gnu.org; Wed, 30 May 2018 04:30:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fNwUc-0008MF-VT for bug-guix@gnu.org; Wed, 30 May 2018 04:30:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:46746) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fNwUc-0008MB-RW for bug-guix@gnu.org; Wed, 30 May 2018 04:30:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fNwUc-0006jV-FE for bug-guix@gnu.org; Wed, 30 May 2018 04:30:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <874lipr612.fsf@mdc-berlin.de> (Ricardo Wurmus's message of "Wed, 30 May 2018 08:50:33 +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: 31647@debbugs.gnu.org Ricardo Wurmus writes: > Mark H Weaver writes: > >> 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 > =E2=80=9Cmake=E2=80=9D but not those of custom =E2=80=9Cinvoke=E2=80=9D e= xpressions in custom build > phases where the error message could be useful? I appreciate your perspective on this, and you've made some good points. How about this idea: in core-updates-next, we could add code to 'gnu-build' in (guix build gnu-build-system) which catches &invoke-error exceptions thrown by the phase procedures. This is a very common case, and I agree with you that a backtrace is rarely (if ever) useful for that particular exception type. The program name and arguments included in the condition object should be enough information. We could use a copy of the code from (guix ui) to print the invoke errors nicely: ((invoke-error? c) (leave (G_ "program exited\ ~@[ with non-zero exit status ~a~]\ ~@[ terminated by signal ~a~]\ ~@[ stopped by signal ~a~]: ~s~%") (invoke-error-exit-status c) (invoke-error-term-signal c) (invoke-error-stop-signal c) (cons (invoke-error-program c) (invoke-error-arguments c)))) However, I would prefer to catch *only* invoke errors, and to let most exception types go unhandled by gnu-build. If you can think of another exception type that should be handled more gracefully, please let me know. What do you think? Mark