X-Loop: help-debbugs@HIDDEN Subject: bug#31647: [core-updates] gtkglext fails in a weird way Resent-From: Ricardo Wurmus <ricardo.wurmus@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-guix@HIDDEN Resent-Date: Tue, 29 May 2018 18:22:02 +0000 Resent-Message-ID: <handler.31647.B.152761806821685 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: report 31647 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: 31647 <at> debbugs.gnu.org X-Debbugs-Original-To: <bug-guix@HIDDEN> Received: via spool by submit <at> debbugs.gnu.org id=B.152761806821685 (code B ref -1); Tue, 29 May 2018 18:22:02 +0000 Received: (at submit) by debbugs.gnu.org; 29 May 2018 18:21:08 +0000 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> 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-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
Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) Content-Type: text/plain; charset=utf-8 X-Loop: help-debbugs@HIDDEN From: help-debbugs@HIDDEN (GNU bug Tracking System) To: Ricardo Wurmus <ricardo.wurmus@HIDDEN> Subject: bug#31647: Acknowledgement ([core-updates] gtkglext fails in a weird way) Message-ID: <handler.31647.B.152761806821685.ack <at> debbugs.gnu.org> References: <87d0xeqq6l.fsf@HIDDEN> X-Gnu-PR-Message: ack 31647 X-Gnu-PR-Package: guix Reply-To: 31647 <at> debbugs.gnu.org Date: Tue, 29 May 2018 18:22:02 +0000 Thank you for filing a new bug report with debbugs.gnu.org. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): bug-guix@HIDDEN If you wish to submit further information on this problem, please send it to 31647 <at> debbugs.gnu.org. Please do not send mail to help-debbugs@HIDDEN unless you wish to report a problem with the Bug-tracking system. --=20 31647: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D31647 GNU Bug Tracking System Contact help-debbugs@HIDDEN with problems
X-Loop: help-debbugs@HIDDEN Subject: bug#31647: [core-updates] gtkglext fails in a weird way Resent-From: Ricardo Wurmus <ricardo.wurmus@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-guix@HIDDEN Resent-Date: Tue, 29 May 2018 20:32:02 +0000 Resent-Message-ID: <handler.31647.B31647.1527625886943 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 31647 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: <31647 <at> debbugs.gnu.org> Received: via spool by 31647-submit <at> debbugs.gnu.org id=B31647.1527625886943 (code B ref 31647); Tue, 29 May 2018 20:32:02 +0000 Received: (at 31647) by debbugs.gnu.org; 29 May 2018 20:31:26 +0000 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> 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-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
X-Loop: help-debbugs@HIDDEN Subject: bug#31647: [core-updates] gtkglext fails in a weird way Resent-From: Mark H Weaver <mhw@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-guix@HIDDEN Resent-Date: Wed, 30 May 2018 03:58:02 +0000 Resent-Message-ID: <handler.31647.B31647.152765266832558 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 31647 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Ricardo Wurmus <ricardo.wurmus@HIDDEN> Cc: 31647 <at> debbugs.gnu.org Received: via spool by 31647-submit <at> debbugs.gnu.org id=B31647.152765266832558 (code B ref 31647); Wed, 30 May 2018 03:58:02 +0000 Received: (at 31647) by debbugs.gnu.org; 30 May 2018 03:57:48 +0000 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> 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-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
X-Loop: help-debbugs@HIDDEN Subject: bug#31647: [core-updates] gtkglext fails in a weird way Resent-From: Ricardo Wurmus <ricardo.wurmus@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-guix@HIDDEN Resent-Date: Wed, 30 May 2018 06:51:01 +0000 Resent-Message-ID: <handler.31647.B31647.152766305417147 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 31647 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Mark H Weaver <mhw@HIDDEN> Cc: 31647 <at> debbugs.gnu.org Received: via spool by 31647-submit <at> debbugs.gnu.org id=B31647.152766305417147 (code B ref 31647); Wed, 30 May 2018 06:51:01 +0000 Received: (at 31647) by debbugs.gnu.org; 30 May 2018 06:50:54 +0000 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> 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-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
X-Loop: help-debbugs@HIDDEN Subject: bug#31647: [core-updates] gtkglext fails in a weird way Resent-From: Mark H Weaver <mhw@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-guix@HIDDEN Resent-Date: Wed, 30 May 2018 08:30:02 +0000 Resent-Message-ID: <handler.31647.B31647.152766896025804 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 31647 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Ricardo Wurmus <ricardo.wurmus@HIDDEN> Cc: 31647 <at> debbugs.gnu.org Received: via spool by 31647-submit <at> debbugs.gnu.org id=B31647.152766896025804 (code B ref 31647); Wed, 30 May 2018 08:30:02 +0000 Received: (at 31647) by debbugs.gnu.org; 30 May 2018 08:29:20 +0000 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> 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-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
X-Loop: help-debbugs@HIDDEN Subject: bug#31647: [core-updates] gtkglext fails in a weird way Resent-From: Mark H Weaver <mhw@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-guix@HIDDEN Resent-Date: Wed, 30 May 2018 08:45:02 +0000 Resent-Message-ID: <handler.31647.B31647.152766988127156 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 31647 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Ricardo Wurmus <ricardo.wurmus@HIDDEN> Cc: 31647 <at> debbugs.gnu.org Received: via spool by 31647-submit <at> debbugs.gnu.org id=B31647.152766988127156 (code B ref 31647); Wed, 30 May 2018 08:45:02 +0000 Received: (at 31647) by debbugs.gnu.org; 30 May 2018 08:44:41 +0000 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> 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-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
X-Loop: help-debbugs@HIDDEN Subject: bug#31647: [core-updates] gtkglext fails in a weird way Resent-From: Ricardo Wurmus <ricardo.wurmus@HIDDEN> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-guix@HIDDEN Resent-Date: Thu, 31 May 2018 06:44:01 +0000 Resent-Message-ID: <handler.31647.B31647.15277489976060 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 31647 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Mark H Weaver <mhw@HIDDEN> Cc: 31647 <at> debbugs.gnu.org Received: via spool by 31647-submit <at> debbugs.gnu.org id=B31647.15277489976060 (code B ref 31647); Thu, 31 May 2018 06:44:01 +0000 Received: (at 31647) by debbugs.gnu.org; 31 May 2018 06:43:17 +0000 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> 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-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
X-Loop: help-debbugs@HIDDEN Subject: bug#31647: [core-updates] gtkglext fails in a weird way Resent-From: ludo@HIDDEN (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> Resent-CC: bug-guix@HIDDEN Resent-Date: Sun, 03 Jun 2018 20:38:01 +0000 Resent-Message-ID: <handler.31647.B31647.152805825712664 <at> debbugs.gnu.org> Resent-Sender: help-debbugs@HIDDEN X-GNU-PR-Message: followup 31647 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Ricardo Wurmus <ricardo.wurmus@HIDDEN> Cc: Mark H Weaver <mhw@HIDDEN>, 31647 <at> debbugs.gnu.org Received: via spool by 31647-submit <at> debbugs.gnu.org id=B31647.152805825712664 (code B ref 31647); Sun, 03 Jun 2018 20:38:01 +0000 Received: (at 31647) by debbugs.gnu.org; 3 Jun 2018 20:37:37 +0000 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?=) 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-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.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.