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: Thu, 31 May 2018 08:42:56 +0200 Message-ID: <87h8mopbpr.fsf@mdc-berlin.de> References: <87d0xeqq6l.fsf@elephly.net> <87a7siqk5m.fsf@mdc-berlin.de> <8736y9dcev.fsf@netris.org> <874lipr612.fsf@mdc-berlin.de> <87y3g1a6pf.fsf@netris.org> 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]:52880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fOHJf-0005Iv-5q for bug-guix@gnu.org; Thu, 31 May 2018 02:44:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fOHJa-0007Mi-7E for bug-guix@gnu.org; Thu, 31 May 2018 02:44:07 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:47629) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fOHJa-0007MO-0E for bug-guix@gnu.org; Thu, 31 May 2018 02:44:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fOHJZ-0001aj-Py for bug-guix@gnu.org; Thu, 31 May 2018 02:44:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87y3g1a6pf.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: > >> 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 could = be reported by Guile directly without us catching and reformatting them in gnu-build. -- Ricardo