From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#31647: [core-updates] gtkglext fails in a weird way Date: Sun, 03 Jun 2018 22:37:23 +0200 Message-ID: <877enf61z0.fsf@gnu.org> References: <87d0xeqq6l.fsf@elephly.net> <87a7siqk5m.fsf@mdc-berlin.de> <8736y9dcev.fsf@netris.org> <874lipr612.fsf@mdc-berlin.de> <87y3g1a6pf.fsf@netris.org> <87h8mopbpr.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]:46468) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fPZlL-0006wk-Hl for bug-guix@gnu.org; Sun, 03 Jun 2018 16:38:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fPZlK-0001MV-8c for bug-guix@gnu.org; Sun, 03 Jun 2018 16:38:03 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:52698) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fPZlK-0001MP-4q for bug-guix@gnu.org; Sun, 03 Jun 2018 16:38:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fPZlJ-0003Is-Sr for bug-guix@gnu.org; Sun, 03 Jun 2018 16:38:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87h8mopbpr.fsf@mdc-berlin.de> (Ricardo Wurmus's message of "Thu, 31 May 2018 08:42:56 +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 Hello, Ricardo Wurmus skribis: > Mark H Weaver writes: > >> 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= expressions 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)))) > > This sounds good to me. > >> 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. > [=E2=80=A6] >> On second thought, I don't have a good justification for this. What I >> really care about is that all exceptions except for specific case(s) >> like invoke-error should generate a full backtrace to the original >> source of the exception, along with all information present in the >> condition object or exception. I see no reason not to let Guile's >> generic exception reporting code handle these unusual cases, but if it's >> important to you we could do the same thing from gnu-build, I suppose. > > I agree. I only really care about the invoke errors, because they are > to be expected when there is anything at all wrong with the build. > > Any exception other than those triggered by =E2=80=9Cinvoke=E2=80=9D coul= d be reported > by Guile directly without us catching and reformatting them in > gnu-build. I agree, we should do this in =E2=80=98core-updates-next=E2=80=99. Ludo=E2=80=99.