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

Previous Next

Full log

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de>
Cc: Mark H Weaver <mhw <at> netris.org>, 31647 <at> debbugs.gnu.org
Subject: Re: bug#31647: [core-updates] gtkglext fails in a weird way
Date: Sun, 03 Jun 2018 22:37:23 +0200

Hello,

Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> skribis:

> 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.

I agree, we should do this in ‘core-updates-next’.

Ludo’.

Previous Next

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