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

Previous Next

Full log

View this message in rfc822 format

From: Mark H Weaver <mhw <at> netris.org>
To: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de>
Cc: 31647 <at> debbugs.gnu.org
Subject: bug#31647: [core-updates] gtkglext fails in a weird way
Date: Wed, 30 May 2018 04:27:56 -0400

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

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

Previous Next

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