From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carl Dong Subject: bug#37449: Bug when using non-trivial inferiors/channel setup Date: Wed, 18 Sep 2019 16:08:45 +0000 Message-ID: Reply-To: Carl Dong Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:56069) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iAcVs-0005R1-6h for bug-guix@gnu.org; Wed, 18 Sep 2019 12:09:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iAcVq-0003xw-Dx for bug-guix@gnu.org; Wed, 18 Sep 2019 12:09:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:45930) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iAcVq-0003xr-AO for bug-guix@gnu.org; Wed, 18 Sep 2019 12:09:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iAcVq-0007vr-4S for bug-guix@gnu.org; Wed, 18 Sep 2019 12:09:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: Received: from eggs.gnu.org ([2001:470:142:3::10]:56024) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iAcVk-0005Gi-9a for bug-guix@gnu.org; Wed, 18 Sep 2019 12:08:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iAcVi-0003tS-BH for bug-guix@gnu.org; Wed, 18 Sep 2019 12:08:55 -0400 Received: from mail4.protonmail.ch ([185.70.40.27]:64298) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iAcVh-0003ql-TK for bug-guix@gnu.org; Wed, 18 Sep 2019 12:08:54 -0400 List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: 37449@debbugs.gnu.org Hi all, This is a followup to some discussion between rekado, civodul, and I on IRC= (see end of email for transcript). There is a curious bug that happens when usin= g non-trivial inferiors/channels setup that triggers an error with vague outp= ut, something like: ``` building path(s) `/gnu/store/myrl5p8fy3qhpdv7376sak8wmhdsrl5f-profile' Backtrace: 2 (primitive-load "/home/dongcarl/.config/guix/current/bi= =E2=80=A6") In guix/ui.scm: 1692:12 1 (run-guix-command _ . _) 623:13 0 (_ srfi-34 #) guix/ui.scm:623:13: Throw to key `wrong-type-arg' with args `("condition-ha= s-type?" "Wrong type argument")'. ``` Both rekado and I have ran into this problem. Rekado ran into this problem = when using inferiors with more than one channel, and I ran into this problem whe= n using an inferior with a channel that has a .guix-channel file specifying a 'guix channel. A detail here is that it only triggers, but triggers reliabl= y, for certain packages in our manifests, with is quite odd. I've attached the IRC conversation below for convenience. Cheers, Carl Dong contact@carldong.me "I fight for the users" ``` question about general Guix debugging... I'm building a manifest= , and I see this: https://pastebin.com/JjpEjxaG dongcarl: I=E2=80=99ve bumped into this very same bug just a day a= go It's hard to know where to look... :-/ I=E2=80=99m not sure what=E2=80=99s going on here. rekado: REALLY?! a user at the institute, actually Where did you bump into it? Sounds like it needs to be fixed we=E2=80=99re using inferiors with more than one channel rekado: Right exactly! the user managed to avoid the problem for now by pinning the 'guix= channel to commit 2f43e5db1c36ec93a80ed1e3cbe763a8d64adcb5. this sounds like a meta error, really Hmm... Well let me describe what I have there=E2=80=99s something triggering an error in an expression tha= t is wrapped in =E2=80=9Ccall-with-error-handling=E2=80=9D Perhaps the info will be helpful for debugging but the error is not a condition, so the guard fails or something like that my manifest only has one channel in it, called `'bitcoin-guix`, = and that channel's repo has a `.guix-channel` file that specifies a `'guix`= channel actually, the error says that it got a =E2=80=9Ccondition=E2=80= =9D but wrapped inside an =E2=80=9Cinferior-object=E2=80=9D that=E2=80=99s the problem, I think it should just be a condition. the fact that we=E2=80=99re using an inferior results in a wrapped= value it should be unwrapped before raising the condition. another piece of info, this is only happens for one of the packa= ges in the manifest (I narrowed it down), all others are fine =E2=80=94 dongcarl reading same here it happened for python-scanpy others were ine *fine I=E2=80=99m guessing that this may be related to sexp->object in r= ead-repl-response in guix/inferior.scm rekado: Huh... conditions don=E2=80=99t have a self-quoting sexp representation so they end up being wrapped in inferior-object rekado: Is this easy to fix? I don=E2=80=99t know. rekado: what should I look for in guix/inferior.scm? I can take = a look read-repl-response expects to read either (values =E2=80=A6) or (e= xception =E2=80=A6) from the port I don=E2=80=99t know what a condition value would look like we probably need to a) make sure that conditions are serialized pr= operly and b) handle them in read-repl-response. rekado: Why does this error only happen for _some_ objects and b= ut not all? I don=E2=80=99t know we don=E2=80=99t even see the actual error. I guess (a) needs to be done in guix/repl.scm in send-repl-respons= e the problem seems to be that there we only catch plain exceptions,= but not conditions =E2=80=94 dongcarl needs to read up on exceptions and conditions (error 'foo) is an exception conditions are more complex and are defined in srfi-35 conditions have proper types whereas plain errors really only have= a key and optional arguments errors can be caught with (catch 'the-key =E2=80=A6) or (catch #t = =E2=80=A6) for any error dongcarl: could you paste the error on, say, paste.debian.net? (p= atebin.com cannot be accessed over Tor) civodul: Yes, would love to, one second rekado: Ah the type distinction is good to know debugging exceptions from an inferior is... inconvenient civodul: http://paste.debian.net/hidden/03c69d6b/ civodul: agreed I was actually thinking that perhaps inferiors can be a first-cl= ass `guix` cli construct... Not sure if that's possible As in, run the CLI as if `guix` was at this commit Maybe that's dumb :man-shrugging: gunna be back online in 30 mins if you guys need more logs or wt= v dongcarl: oh, i see actually i don't see that much, mostly ellipses ah the re-throw for SRFI-34/35 is interesting it cannot work we should maybe serialize &store-error conditions over the wire ```