GNU bug report logs - #31647
[core-updates] gtkglext fails in a weird way

Previous Next

Full log

Message #23 received at 31647 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 31647 <at> debbugs.gnu.org
Subject: Re: bug#31647: [core-updates] gtkglext fails in a weird way
Date: Thu, 31 May 2018 08:42:56 +0200

Mark H Weaver <mhw <at> netris.org> writes:

> Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> writes:
>
>> Mark H Weaver <mhw <at> netris.org> 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
>> “make” but not those of custom “invoke” 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.
[…]
> 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 “invoke” could be reported
by Guile directly without us catching and reformatting them in
gnu-build.

--
Ricardo

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.