Received: (at 31647) by debbugs.gnu.org; 3 Jun 2018 20:37:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jun 03 16:37:37 2018 Received: from localhost ([127.0.0.1]:60595 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1fPZku-0003IA-2N for submit <at> debbugs.gnu.org; Sun, 03 Jun 2018 16:37:37 -0400 Received: from eggs.gnu.org ([208.118.235.92]:55423) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <ludo@HIDDEN>) id 1fPZks-0003Hw-7y for 31647 <at> debbugs.gnu.org; Sun, 03 Jun 2018 16:37:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <ludo@HIDDEN>) id 1fPZkl-0001Ik-TO for 31647 <at> debbugs.gnu.org; Sun, 03 Jun 2018 16:37:28 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35572) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <ludo@HIDDEN>) id 1fPZkl-0001IR-Pd; Sun, 03 Jun 2018 16:37:27 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=53094 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <ludo@HIDDEN>) id 1fPZkl-00045i-CL; Sun, 03 Jun 2018 16:37:27 -0400 From: ludo@HIDDEN (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: Ricardo Wurmus <ricardo.wurmus@HIDDEN> Subject: Re: bug#31647: [core-updates] gtkglext fails in a weird way References: <87d0xeqq6l.fsf@HIDDEN> <87a7siqk5m.fsf@HIDDEN> <8736y9dcev.fsf@HIDDEN> <874lipr612.fsf@HIDDEN> <87y3g1a6pf.fsf@HIDDEN> <87h8mopbpr.fsf@HIDDEN> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 15 Prairial an 226 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Sun, 03 Jun 2018 22:37:23 +0200 In-Reply-To: <87h8mopbpr.fsf@HIDDEN> (Ricardo Wurmus's message of "Thu, 31 May 2018 08:42:56 +0200") Message-ID: <877enf61z0.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 31647 Cc: Mark H Weaver <mhw@HIDDEN>, 31647 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -6.0 (------) Hello, Ricardo Wurmus <ricardo.wurmus@HIDDEN> skribis: > Mark H Weaver <mhw@HIDDEN> writes: > >> Ricardo Wurmus <ricardo.wurmus@HIDDEN> writes: >> >>> Mark H Weaver <mhw@HIDDEN> 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.
bug-guix@HIDDEN:bug#31647; Package guix.
Full text available.Received: (at 31647) by debbugs.gnu.org; 31 May 2018 06:43:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 31 02:43:17 2018 Received: from localhost ([127.0.0.1]:55526 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1fOHIq-0001Zg-Pr for submit <at> debbugs.gnu.org; Thu, 31 May 2018 02:43:17 -0400 Received: from pegasus.bbbm.mdc-berlin.de ([141.80.25.20]:43270) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <Ricardo.Wurmus@HIDDEN>) id 1fOHIo-0001ZY-S8 for 31647 <at> debbugs.gnu.org; Thu, 31 May 2018 02:43:15 -0400 Received: from localhost (localhost [127.0.0.1]) by pegasus.bbbm.mdc-berlin.de (Postfix) with ESMTP id A406E8EB89B; Thu, 31 May 2018 08:43:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mdc-berlin.de; h= content-transfer-encoding:content-type:content-type:mime-version :message-id:date:date:in-reply-to:subject:subject:from:from :user-agent:references:received:received:received:received; s= mdc; t=1527748988; x=1529563389; bh=bH08p3GpWvvxXNEQTnZqWNAd5b7F Emozx7W0HN3hRCY=; b=tLfbbnc3prZ1GmGVPjU5/axbagBQ4GdL3hTuO6ShF1XJ e37KKbO7t7dFRIxWjOs846wPruRk6iE/ihsxd79OypAhmQtbPRL7XDIq+qFcx4KQ TW6Am/JoSnPvDS3uKn/tp68xfsxXBV01icR5wF1rmK4x3KAfKPT+B/5UCfRlcvc= X-Virus-Scanned: amavisd-new at mdc-berlin.de Received: from pegasus.bbbm.mdc-berlin.de ([127.0.0.1]) by localhost (pegasus.bbbm.mdc-berlin.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUIbfbxtfCPK; Thu, 31 May 2018 08:43:08 +0200 (CEST) Received: from HTCAONE.mdc-berlin.net (puck.citx.mdc-berlin.de [141.80.36.101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pegasus.bbbm.mdc-berlin.de (Postfix) with ESMTPS; Thu, 31 May 2018 08:43:08 +0200 (CEST) Received: from SW-IT-P-CAS4.mdc-berlin.net (141.80.113.59) by HTCAONE.mdc-berlin.net (141.80.180.120) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 31 May 2018 08:43:07 +0200 Received: from localhost (141.80.113.51) by SW-IT-P-CAS4.mdc-berlin.net (141.80.113.59) with Microsoft SMTP Server id 14.3.399.0; Thu, 31 May 2018 08:43:07 +0200 References: <87d0xeqq6l.fsf@HIDDEN> <87a7siqk5m.fsf@HIDDEN> <8736y9dcev.fsf@HIDDEN> <874lipr612.fsf@HIDDEN> <87y3g1a6pf.fsf@HIDDEN> User-agent: mu4e 1.0; emacs 26.1 From: Ricardo Wurmus <ricardo.wurmus@HIDDEN> To: Mark H Weaver <mhw@HIDDEN> Subject: Re: bug#31647: [core-updates] gtkglext fails in a weird way In-Reply-To: <87y3g1a6pf.fsf@HIDDEN> X-URL: https://elephly.net X-PGP-Key: https://elephly.net/rekado.pubkey X-PGP-Fingerprint: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC Date: Thu, 31 May 2018 08:42:56 +0200 Message-ID: <87h8mopbpr.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [141.80.113.51] X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.2.1013-23878.005 X-TM-AS-Result: No-11.365600-8.000000-10 X-TMASE-MatchedRID: fE0JoqABJp173HU3OUveQfHkpkyUphL9MhomkrNJ+uxnnK6mXN72mwMP pF205xvm7ib3HB3rhCpcNgYs8tfTm3xynZpunVHF2OSj4qJA9QYpWss5kPUFdOzKYenbqbY4JML Bwm0wof35Swo+HknGyeMFrXb7veAOF6sM4RCEo4yZroPNdqiG85l/lu28zzkBfeB8ZkBTx8ubJx j/y/77pC87ZJz7QD0NkI3RJlIxYEMTQUygzaW7drMjW/sniEQK5TbwqVVpF+O9gXm7Obz+TGUoD 5JLGXzAHc16TDTHn4LgEe/gTiF1icOQecnAhEpbEPf7TDUOGooBmf/gD11vZBahL68yPcDbOaHc QalrcFDcnCVQ360bPJnmteZltT2l/AWa8di4kIDNRsyOiZyYygwi9wxRt+9OmyiLZetSf8my5/t FZu9S3Ku6xVHLhqfxwrbXMGDYqV8PXZPurZ0hS+TsTv0rmaFsArs67qINTy6Nhn+FXvB0BTrqab kBtCVA X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--11.365600-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.2.1013-23878.005 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 31647 Cc: 31647 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -6.0 (------) Mark H Weaver <mhw@HIDDEN> writes: > Ricardo Wurmus <ricardo.wurmus@HIDDEN> writes: > >> Mark H Weaver <mhw@HIDDEN> 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
bug-guix@HIDDEN:bug#31647; Package guix.
Full text available.
Received: (at 31647) by debbugs.gnu.org; 30 May 2018 08:44:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 30 04:44:41 2018
Received: from localhost ([127.0.0.1]:54648 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1fNwin-00073w-Gv
for submit <at> debbugs.gnu.org; Wed, 30 May 2018 04:44:41 -0400
Received: from world.peace.net ([64.112.178.59]:49196)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <mhw@HIDDEN>) id 1fNwil-00073i-9s
for 31647 <at> debbugs.gnu.org; Wed, 30 May 2018 04:44:40 -0400
Received: from mhw by world.peace.net with esmtpsa
(TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
(envelope-from <mhw@HIDDEN>)
id 1fNwif-0001yc-Ml; Wed, 30 May 2018 04:44:33 -0400
From: Mark H Weaver <mhw@HIDDEN>
To: Ricardo Wurmus <ricardo.wurmus@HIDDEN>
Subject: Re: bug#31647: [core-updates] gtkglext fails in a weird way
References: <87d0xeqq6l.fsf@HIDDEN> <87a7siqk5m.fsf@HIDDEN>
<8736y9dcev.fsf@HIDDEN> <874lipr612.fsf@HIDDEN>
<87y3g1a6pf.fsf@HIDDEN>
Date: Wed, 30 May 2018 04:43:19 -0400
In-Reply-To: <87y3g1a6pf.fsf@HIDDEN> (Mark H. Weaver's message of "Wed, 30
May 2018 04:27:56 -0400")
Message-ID: <87po1da5zs.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 31647
Cc: 31647 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
I wrote:
> However, I would prefer to catch *only* invoke errors, and to let most
> exception types go unhandled by gnu-build.
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.
What do you think?
Mark
bug-guix@HIDDEN:bug#31647; Package guix.
Full text available.
Received: (at 31647) by debbugs.gnu.org; 30 May 2018 08:29:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 30 04:29:20 2018
Received: from localhost ([127.0.0.1]:54643 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1fNwTw-0006i8-4w
for submit <at> debbugs.gnu.org; Wed, 30 May 2018 04:29:20 -0400
Received: from world.peace.net ([64.112.178.59]:49012)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <mhw@HIDDEN>) id 1fNwTu-0006hu-4j
for 31647 <at> debbugs.gnu.org; Wed, 30 May 2018 04:29:18 -0400
Received: from mhw by world.peace.net with esmtpsa
(TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
(envelope-from <mhw@HIDDEN>)
id 1fNwTn-0001sM-St; Wed, 30 May 2018 04:29:11 -0400
From: Mark H Weaver <mhw@HIDDEN>
To: Ricardo Wurmus <ricardo.wurmus@HIDDEN>
Subject: Re: bug#31647: [core-updates] gtkglext fails in a weird way
References: <87d0xeqq6l.fsf@HIDDEN> <87a7siqk5m.fsf@HIDDEN>
<8736y9dcev.fsf@HIDDEN> <874lipr612.fsf@HIDDEN>
Date: Wed, 30 May 2018 04:27:56 -0400
In-Reply-To: <874lipr612.fsf@HIDDEN> (Ricardo Wurmus's message of "Wed,
30 May 2018 08:50:33 +0200")
Message-ID: <87y3g1a6pf.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 31647
Cc: 31647 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Ricardo Wurmus <ricardo.wurmus@HIDDEN> writes:
> Mark H Weaver <mhw@HIDDEN> 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 e=
xpressions 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
bug-guix@HIDDEN:bug#31647; Package guix.
Full text available.
Received: (at 31647) by debbugs.gnu.org; 30 May 2018 06:50:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 30 02:50:54 2018
Received: from localhost ([127.0.0.1]:54584 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1fNuwg-0004SV-Dm
for submit <at> debbugs.gnu.org; Wed, 30 May 2018 02:50:54 -0400
Received: from sinope02.bbbm.mdc-berlin.de ([141.80.25.24]:56630)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <Ricardo.Wurmus@HIDDEN>) id 1fNuwd-0004SL-6e
for 31647 <at> debbugs.gnu.org; Wed, 30 May 2018 02:50:52 -0400
Received: from localhost (localhost [127.0.0.1])
by sinope02.bbbm.mdc-berlin.de (Postfix) with ESMTP id 18F4E115C952;
Wed, 30 May 2018 08:50:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mdc-berlin.de; h=
content-transfer-encoding:content-type:content-type:mime-version
:message-id:date:date:in-reply-to:subject:subject:from:from
:user-agent:references:received:received:received:received; s=
mdc; t=1527663044; x=1529477445; bh=uxi4cbfF8E+tv4rug2QWnKolgNYz
H4CBmUc45tIwvg8=; b=Wpp/RJLEYZ38nvAAJ9mwKUSZirMpMmqBo9SA55Yq0eF1
RrBY0TuqVDdk5UgIfApEGPbQDJBbMVAABGJBmL/XzC4/Zpg7h6R8QjNw2jxoOQd1
8xtGPqIdcJMO4WQJ7ajmU6aaournfNXKEBejMJYIpKZSVd8bL/suqO+hHN4GS3Y=
X-Virus-Scanned: amavisd-new at mdc-berlin.de
Received: from sinope02.bbbm.mdc-berlin.de ([127.0.0.1])
by localhost (sinope02.bbbm.mdc-berlin.de [127.0.0.1]) (amavisd-new,
port 10024)
with ESMTP id J_rOC3dqK3OE; Wed, 30 May 2018 08:50:44 +0200 (CEST)
Received: from HTCATWO.mdc-berlin.net (puck.citx.mdc-berlin.de [141.80.36.101])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by sinope02.bbbm.mdc-berlin.de (Postfix) with ESMTPS;
Wed, 30 May 2018 08:50:44 +0200 (CEST)
Received: from SW-IT-P-CAS3.mdc-berlin.net (141.80.113.58) by
HTCATWO.mdc-berlin.net (141.80.180.190) with Microsoft SMTP Server (TLS) id
14.3.399.0; Wed, 30 May 2018 08:50:44 +0200
Received: from localhost (141.80.113.51) by SW-IT-P-CAS3.mdc-berlin.net
(141.80.113.58) with Microsoft SMTP Server id 14.3.399.0; Wed, 30 May 2018
08:50:43 +0200
References: <87d0xeqq6l.fsf@HIDDEN> <87a7siqk5m.fsf@HIDDEN>
<8736y9dcev.fsf@HIDDEN>
User-agent: mu4e 1.0; emacs 25.3.1
From: Ricardo Wurmus <ricardo.wurmus@HIDDEN>
To: Mark H Weaver <mhw@HIDDEN>
Subject: Re: bug#31647: [core-updates] gtkglext fails in a weird way
In-Reply-To: <8736y9dcev.fsf@HIDDEN>
X-URL: https://elephly.net
X-PGP-Key: https://elephly.net/rekado.pubkey
X-PGP-Fingerprint: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
Date: Wed, 30 May 2018 08:50:33 +0200
Message-ID: <874lipr612.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [141.80.113.51]
X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.2.1013-23876.005
X-TM-AS-Result: No-7.474800-8.000000-10
X-TMASE-MatchedRID: byfwvk+IcRl73HU3OUveQfHkpkyUphL9GNMTWh+TA9u7vsaNORPCIDfy
D4B1B1XwcNEx2k3DBRpz4VEcXJKv3+IPatyEA1M94k7Mg7Jxs09KJXxORkqw+ZeZYtcskV9PkvU
orCVhLfXJb6Xyw3o7GGOOh8THk2SQc33gkrfTLYhkvXN3b8W46O9KnaK64e2ip+cg3PT8JVwldx
6oW+9DA7BWZd3L4yheMAE1DSB/Dz8B/868Hoi7s7Sw7varainhkKAa/khZ3iRcKZwALwMGs7Pci
xxZ/aRbWq8NaROlrVmZI8OviNkMUagKXL9wpp4vAoNa2r+Edw10bXWCb2qGLv0TP/kikeqnsJC4
m2jcjnyFVWnKWyGFg5nG04QlGSAedrkSn8I/xo7bZBKWXQaqDX0tCKdnhB581B0Hk1Q1KyLUZxE
AlFPo8/cUt5lc1lLgKIzdZS3ou0URQwEc2J+vPGDknYXc0XzvOHVNsSXyBUpUdnHs75jQhYtQZf
Q6yV/OWHWn6cEwhPU5bULHLoUfo0gucaUbPHBHhgO4KqirjdORfnv0/NGS1II7sdThXqCLHiSER
gyVTNPJh4tPdu4niQ==
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
X-TMASE-Result: 10--7.474800-8.000000
X-TMASE-Version: SMEX-12.5.0.1300-8.2.1013-23876.005
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 31647
Cc: 31647 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Mark H Weaver <mhw@HIDDEN> writes:
> Ricardo Wurmus <ricardo.wurmus@HIDDEN> writes:
>
>>> on “core-updates” the “gtkglext” package fails with an odd error
>>> message: […]
>>
>> It seems that this is not limited to “gtkglext”. This behaviour seems
>> to affect any package using “invoke” where the invoked command fails.
>>
>> Should the build system catch the exception and make sure that it gets
>> to print “build phase `foo' failed”?
>
> In my opinion, it's not important for that message to be printed. What
> is being printed now is far more informative, and sometimes that extra
> information is quite useful.
[…]
> Also, even if we catch the exception and do a nice job printing it, we'd
> likely lose the backtrace to the original error, which in some cases
> might be quite useful.
Since the build system itself uses invoke to run “make” any error
encountered during the build phase looks something like this:
--8<---------------cut here---------------start------------->8---
Backtrace:
4 (primitive-load "/gnu/store/vrv8gx4s940z0vaaq9a40jsq9xf…")
In ice-9/eval.scm:
191:35 3 (_ _)
In srfi/srfi-1.scm:
640:9 2 (for-each #<procedure a4bbc0 at /gnu/store/qzsljkcllc0…> …)
In /gnu/store/qzsljkcllc01dmdq9z0yrqri3ajam3vp-module-import/guix/build/gnu-build-system.scm:
799:31 1 (_ _)
In /gnu/store/qzsljkcllc01dmdq9z0yrqri3ajam3vp-module-import/guix/build/utils.scm:
616:6 0 (invoke _ . _)
/gnu/store/qzsljkcllc01dmdq9z0yrqri3ajam3vp-module-import/guix/build/utils.scm:616:6: In procedure invoke:
Throw to key `srfi-34' with args `(#<condition &invoke-error [program: "make" arguments: ("-j" "4") exit-status: 2 term-signal: #f stop-signal: #f] 9a61c0>)'.
builder for `/gnu/store/2yn2kz4vdfxrrm8lcxfkfbx2548rrmd6-powertabeditor-2.0.0-alpha10.drv' failed with exit code 1
--8<---------------cut here---------------end--------------->8---
It doesn’t seem like this information is actually useful. I see here
that make failed, which is obvious because we are in the build phase. I
don’t see why it failed. I could do without the information that the
“gnu-build-system” uses invoke internally, because “invoke” is not at
fault here.
Previously, we had the phase return #f, which allowed us to cleanly
exit, inform the observant user about the phase that failed (this is
useful because the name of the phase may have long scrolled out of the
buffer), and exit. The backtrace for invoke does not seem to add
anything of importance and it obscures the actual error.
> 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?
What do others think?
--
Ricardo
bug-guix@HIDDEN:bug#31647; Package guix.
Full text available.
Received: (at 31647) by debbugs.gnu.org; 30 May 2018 03:57:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 29 23:57:48 2018
Received: from localhost ([127.0.0.1]:54540 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1fNsF9-0008T4-PP
for submit <at> debbugs.gnu.org; Tue, 29 May 2018 23:57:47 -0400
Received: from world.peace.net ([64.112.178.59]:47992)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <mhw@HIDDEN>) id 1fNsF7-0008So-Ea
for 31647 <at> debbugs.gnu.org; Tue, 29 May 2018 23:57:46 -0400
Received: from mhw by world.peace.net with esmtpsa
(TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
(envelope-from <mhw@HIDDEN>)
id 1fNsF1-0000FI-9N; Tue, 29 May 2018 23:57:39 -0400
From: Mark H Weaver <mhw@HIDDEN>
To: Ricardo Wurmus <ricardo.wurmus@HIDDEN>
Subject: Re: bug#31647: [core-updates] gtkglext fails in a weird way
References: <87d0xeqq6l.fsf@HIDDEN> <87a7siqk5m.fsf@HIDDEN>
Date: Tue, 29 May 2018 23:56:24 -0400
In-Reply-To: <87a7siqk5m.fsf@HIDDEN> (Ricardo Wurmus's message of "Tue,
29 May 2018 22:30:45 +0200")
Message-ID: <8736y9dcev.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 31647
Cc: 31647 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Ricardo Wurmus <ricardo.wurmus@HIDDEN> writes:
>> on =E2=80=9Ccore-updates=E2=80=9D the =E2=80=9Cgtkglext=E2=80=9D package=
fails with an odd error
>> message: [=E2=80=A6]
>
> It seems that this is not limited to =E2=80=9Cgtkglext=E2=80=9D. This be=
haviour seems
> to affect any package using =E2=80=9Cinvoke=E2=80=9D where the invoked co=
mmand fails.
>
> Should the build system catch the exception and make sure that it gets
> to print =E2=80=9Cbuild phase `foo' failed=E2=80=9D?
In my opinion, it's not important for that message to be printed. What
is being printed now is far more informative, and sometimes that extra
information is quite useful.
If we caught exceptions, we'd need to ensure that all of the relevant
information about the exception is printed. The code to catch and print
those exceptions would need to be in (guix build ...), and it could
never be updated without forcing a full rebuild.
'call-with-error-handling' in (guix ui) might be suitable, but it would
need to be duplicated.
Also, even if we catch the exception and do a nice job printing it, we'd
likely lose the backtrace to the original error, which in some cases
might be quite useful.
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 :)
What do you think?
Mark
bug-guix@HIDDEN:bug#31647; Package guix.
Full text available.Received: (at 31647) by debbugs.gnu.org; 29 May 2018 20:31:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 29 16:31:26 2018 Received: from localhost ([127.0.0.1]:54359 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1fNlHC-0000F9-LM for submit <at> debbugs.gnu.org; Tue, 29 May 2018 16:31:26 -0400 Received: from sinope02.bbbm.mdc-berlin.de ([141.80.25.24]:53044) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <Ricardo.Wurmus@HIDDEN>) id 1fNlHB-0000F1-6R for 31647 <at> debbugs.gnu.org; Tue, 29 May 2018 16:31:25 -0400 Received: from localhost (localhost [127.0.0.1]) by sinope02.bbbm.mdc-berlin.de (Postfix) with ESMTP id 08FF4115C2D6 for <31647 <at> debbugs.gnu.org>; Tue, 29 May 2018 22:31:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mdc-berlin.de; h= content-transfer-encoding:content-type:content-type:mime-version :message-id:date:date:in-reply-to:subject:subject:from:from :user-agent:references:received:received:received:received; s= mdc; t=1527625878; x=1529440279; bh=wAR9cKDhncYcWMiBv7YQRZ5uPSDU ktYhIdQ6+UhK3kk=; b=X7LrMn3AxFeSe1BewBDUBdlWo71BovTIJLbdpF4UrCCq o1UTdcRNQ+REUqiVwQchBpzEhYE0mcN4rAy14ULTTk44bvF1M1Ctjjwf6GfnuuW1 Y0/e92aGXQ/bp6gCH4JmZOAx9qGCEblIsrpBj+FweWLO1p/6Tnwmpp3xhJLXEUg= X-Virus-Scanned: amavisd-new at mdc-berlin.de Received: from sinope02.bbbm.mdc-berlin.de ([127.0.0.1]) by localhost (sinope02.bbbm.mdc-berlin.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bt_35VweynDL for <31647 <at> debbugs.gnu.org>; Tue, 29 May 2018 22:31:18 +0200 (CEST) Received: from HTCAONE.mdc-berlin.net (puck.citx.mdc-berlin.de [141.80.36.101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sinope02.bbbm.mdc-berlin.de (Postfix) with ESMTPS for <31647 <at> debbugs.gnu.org>; Tue, 29 May 2018 22:31:18 +0200 (CEST) Received: from SW-IT-P-CAS2.mdc-berlin.net (141.80.113.54) by HTCAONE.mdc-berlin.net (141.80.180.120) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 29 May 2018 22:30:57 +0200 Received: from localhost (141.80.113.51) by SW-IT-P-CAS2.mdc-berlin.net (141.80.113.54) with Microsoft SMTP Server id 14.3.399.0; Tue, 29 May 2018 22:30:57 +0200 References: <87d0xeqq6l.fsf@HIDDEN> User-agent: mu4e 1.0; emacs 25.3.1 From: Ricardo Wurmus <ricardo.wurmus@HIDDEN> To: <31647 <at> debbugs.gnu.org> Subject: Re: [core-updates] gtkglext fails in a weird way In-Reply-To: <87d0xeqq6l.fsf@HIDDEN> X-URL: https://elephly.net X-PGP-Key: https://elephly.net/rekado.pubkey X-PGP-Fingerprint: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC Date: Tue, 29 May 2018 22:30:45 +0200 Message-ID: <87a7siqk5m.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [141.80.113.51] X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.2.1013-23876.002 X-TM-AS-Result: No-0.628200-8.000000-10 X-TMASE-MatchedRID: ZrceL/U8jXQ4HKI/yaqRmwbts0Qkqy42D0SPCEki8WJb6PBUqmq+UvRP dGKxu2/jKK1L8iJUWSFory5Ze4fh3b9ZdlL8eona0C1sQRfQzEHEQdG7H66TyB5vYIBVaAnASdT eOYSfN4fqlvIK0gZcaGusFskjEQcEQ0aLDBvB9plkmR0GwK9Pp+wCEOjcG8WnpU4leMtnPpEUAF YQ7mEflSyoQoKnvVpi X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--0.628200-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.2.1013-23876.002 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 31647 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > on “core-updates” the “gtkglext” package fails with an odd error > message: […] It seems that this is not limited to “gtkglext”. This behaviour seems to affect any package using “invoke” where the invoked command fails. Should the build system catch the exception and make sure that it gets to print “build phase `foo' failed”? -- Ricardo
bug-guix@HIDDEN:bug#31647; Package guix.
Full text available.
Received: (at submit) by debbugs.gnu.org; 29 May 2018 18:21:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 29 14:21:08 2018
Received: from localhost ([127.0.0.1]:54306 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1fNjF6-0005dh-7T
for submit <at> debbugs.gnu.org; Tue, 29 May 2018 14:21:08 -0400
Received: from eggs.gnu.org ([208.118.235.92]:55060)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <Ricardo.Wurmus@HIDDEN>) id 1fNjF3-0005cq-QQ
for submit <at> debbugs.gnu.org; Tue, 29 May 2018 14:21:07 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <Ricardo.Wurmus@HIDDEN>) id 1fNjEx-0004O2-P3
for submit <at> debbugs.gnu.org; Tue, 29 May 2018 14:21:00 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level:
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_DKIM_INVALID
autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:41545)
by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
(Exim 4.71) (envelope-from <Ricardo.Wurmus@HIDDEN>)
id 1fNjEx-0004Ny-ME
for submit <at> debbugs.gnu.org; Tue, 29 May 2018 14:20:59 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:46020)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <Ricardo.Wurmus@HIDDEN>) id 1fNjEw-0001S7-Eo
for bug-guix@HIDDEN; Tue, 29 May 2018 14:20:59 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <Ricardo.Wurmus@HIDDEN>) id 1fNjEr-0004Le-GM
for bug-guix@HIDDEN; Tue, 29 May 2018 14:20:58 -0400
Received: from pegasus.bbbm.mdc-berlin.de ([141.80.25.20]:53688)
by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
(Exim 4.71) (envelope-from <Ricardo.Wurmus@HIDDEN>)
id 1fNjEr-0004K5-57
for bug-guix@HIDDEN; Tue, 29 May 2018 14:20:53 -0400
Received: from localhost (localhost [127.0.0.1])
by pegasus.bbbm.mdc-berlin.de (Postfix) with ESMTP id 85F6D8E7265
for <bug-guix@HIDDEN>; Tue, 29 May 2018 20:20:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mdc-berlin.de; h=
content-transfer-encoding:content-type:content-type:mime-version
:message-id:date:date:subject:subject:from:from:user-agent
:received:received:received:received; s=mdc; t=1527618045; x=
1529432446; bh=P2lQeh2jgrWEfHioQwMAkr0Rd0z1hcOuwTeOYTdMXz0=; b=O
luSoX6wTJd6KkQYvwG9QZ5bC6Sv+XnUq1VFEiY8ppkBvfIVINv6Zo8wGaYd9dSHM
926t+SMk0FWnda/80/ha9sJXxStxrAcvDDChFVRPDQJkma4QfwS6e6lsZdBbj8Qs
N7TIYb1vCTQP33N18iHXHlDuLTIN8EMHkiAzsU3WAM=
X-Virus-Scanned: amavisd-new at mdc-berlin.de
Received: from pegasus.bbbm.mdc-berlin.de ([127.0.0.1])
by localhost (pegasus.bbbm.mdc-berlin.de [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id SAo2k3fvhQvG for <bug-guix@HIDDEN>;
Tue, 29 May 2018 20:20:45 +0200 (CEST)
Received: from HTCAONE.mdc-berlin.net (puck.citx.mdc-berlin.de [141.80.36.101])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by pegasus.bbbm.mdc-berlin.de (Postfix) with ESMTPS
for <bug-guix@HIDDEN>; Tue, 29 May 2018 20:20:45 +0200 (CEST)
Received: from SW-IT-P-CAS4.mdc-berlin.net (141.80.113.59) by
HTCAONE.mdc-berlin.net (141.80.180.120) with Microsoft SMTP Server (TLS) id
14.3.399.0; Tue, 29 May 2018 20:20:44 +0200
Received: from localhost (141.80.113.51) by SW-IT-P-CAS4.mdc-berlin.net
(141.80.113.59) with Microsoft SMTP Server id 14.3.399.0; Tue, 29 May 2018
20:20:44 +0200
User-agent: mu4e 1.0; emacs 25.3.1
From: Ricardo Wurmus <ricardo.wurmus@HIDDEN>
To: <bug-guix@HIDDEN>
Subject: [core-updates] gtkglext fails in a weird way
X-URL: https://elephly.net
X-PGP-Key: https://elephly.net/rekado.pubkey
X-PGP-Fingerprint: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
Date: Tue, 29 May 2018 20:20:34 +0200
Message-ID: <87d0xeqq6l.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: [141.80.113.51]
X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.2.1013-23876.001
X-TM-AS-Result: No-3.058600-8.000000-10
X-TMASE-MatchedRID: T6t2NwDDz3ZeUK17YvKvWU+4wmL9kCTxyeUl7aCTy8gE2aoKQOZTG9Eg
pvxS4CfK61QlpXSTkDezWMr8hvbhX6jC6/MNUxOoaK+MsTwM+1l9LQinZ4QefNZE3xJMmmXc+gt
Hj7OwNO34ZhR52Rc1alaWLsS+fp7nVCM6vXT5Bx+ubRLGI7iP0/DHEXVoh3n9QlBGiC6ssMPFc9
h7EOPxnsCzWdXN/Yf7z68JaB74KrNlM3PKijh4kchl8PYpW67XQHxnuDsoKcvQXizQ6BX8slCXD
fOQBoNTNMuAlzaYkJ4=
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
X-TMASE-Result: 10-3.058600-8.000000
X-TMASE-Version: SMEX-12.5.0.1300-8.2.1013-23876.001
Content-Transfer-Encoding: quoted-printable
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
[fuzzy]
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.0 (------)
Hi,
on =E2=80=9Ccore-updates=E2=80=9D the =E2=80=9Cgtkglext=E2=80=9D package =
fails with an odd error
message:
--8<---------------cut here---------------start------------->8-
make[4]: Leaving directory '/tmp/guix-build-gtkglext-1.2.0.drv-0/gtkglext=
-1.2.0/gdk'
make[3]: *** [Makefile:558: all-recursive] Error 1
make[3]: Leaving directory '/tmp/guix-build-gtkglext-1.2.0.drv-0/gtkglext=
-1.2.0/gdk'
make[2]: *** [Makefile:428: all] Error 2
make[2]: Leaving directory '/tmp/guix-build-gtkglext-1.2.0.drv-0/gtkglext=
-1.2.0/gdk'
make[1]: *** [Makefile:363: all-recursive] Error 1
make[1]: Leaving directory '/tmp/guix-build-gtkglext-1.2.0.drv-0/gtkglext=
-1.2.0'
make: *** [Makefile:279: all] Error 2
Backtrace:
4 (primitive-load "/gnu/store/spxlr67fxvsjyz489wwds5saa6p=E2=80=
=A6")
In ice-9/eval.scm:
191:35 3 (_ _)
In srfi/srfi-1.scm:
640:9 2 (for-each #<procedure 95ddc0 at /gnu/store/f95ghy8mx00=E2=80=
=A6> =E2=80=A6)
In /gnu/store/f95ghy8mx00fc22nrvswvnpqlfdkf2nk-module-import/guix/build/g=
nu-build-system.scm:
799:31 1 (_ _)
In /gnu/store/f95ghy8mx00fc22nrvswvnpqlfdkf2nk-module-import/guix/build/u=
tils.scm:
616:6 0 (invoke _ . _)
/gnu/store/f95ghy8mx00fc22nrvswvnpqlfdkf2nk-module-import/guix/build/util=
s.scm:616:6: In procedure invoke:
Throw to key `srfi-34' with args `(#<condition &invoke-error [program: "m=
ake" arguments: ("-j" "4") exit-status: 2 term-signal: #f stop-signal: #f=
] 9f5f80>)'.
builder for `/gnu/store/0ykv7qamqrk130j5wcg7hvs07gidhvkc-gtkglext-1.2.0.d=
rv' failed with exit code 1
--8<---------------cut here---------------end--------------->8---
Note that it does not print that the build phase failed.
--
Ricardo
Ricardo Wurmus <ricardo.wurmus@HIDDEN>:bug-guix@HIDDEN.
Full text available.bug-guix@HIDDEN:bug#31647; Package guix.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.