Acknowledgement sent
to "Toorn, H.W.P. van den (Henk)" <H.W.P.vandenToorn@uu.nl>:
New bug report received and forwarded. Copy sent to bug-guix@gnu.org.
(Thu, 01 Sep 2022 15:35:02 GMT) (full text, mbox, link).
severity 57527 important
merge 47764 57527
thanks
For now, you can try working-around by retrying "guix pull".
On 01-09-2022 17:00, Toorn, H.W.P. van den (Henk) via Bug reports for
GNU Guix wrote:
> 1417:15 4 (_ #<store-connection 256.99 7f46930e6e60>
> ("/gnu/store/4khcb3b0iqfimjgg6yqnlpf9pkim7s4v-curl-7.84.?" ?) ?)
> 1417:15 3 (loop #f)
> 711:11 2 (process-stderr #<store-connection 256.99 7f46930e6e60> _)
> In ./guix/serialization.scm:
> 102:11 1 (read-int #<input-output: file 10>)
> 80:6 0 (get-bytevector-n* #<input-output: file 10> 8)
Procedure at 80:6:
> (define (get-bytevector-n* port count)
> (let ((bv (get-bytevector-n port count)))
> (when (or (eof-object? bv)
> (< (bytevector-length bv) count))
> (raise (condition (&nar-error
> (file (currently-restored-file))
> (port port)))))
> bv))
An alternative hypotheses:
* build-aux/build-self.scm lets the port be a duplicate of standard
input. But maybe some other code for whatever reason accidentally
reads from there as well? Or: maybe the script is started without
stdout, so when it is duplicated, it becomes stdout, and future code
writes to stdout (i.e., the store port), causing interference?
Potential solution: Open /dev/null on top of stdin, check that the
store port is >2.
Greetings,
Maxime.
severity 57527 important
merge 47764 57527
severity 53802 important
merge 47764 53802
severity 56466 important
merge 47764 56466
thanks
Found a few apparent duplicates (they are all about a &nar-error,
read-int and process-stderror).
On second thought, I don't think the patch I referred to #56466 will
help here, though it could hardly harm here.
For now, you can try working-around by retrying "guix pull".
There are two hypotheses on the cause in
* https://issues.guix.gnu.org/57527#1
* and https://issues.guix.gnu.org/47764
The second seems most plausible to me, and the first seems the simplest
to test (and even if it's not the cause, it would still add some
robustness).
Greetings,
Maxime.
Severity set to 'important' from 'normal'
Request was from Maxime Devos <maximedevos@telenet.be>
to control@debbugs.gnu.org.
(Thu, 01 Sep 2022 17:08:02 GMT) (full text, mbox, link).
Merged 477644778257527.
Request was from Maxime Devos <maximedevos@telenet.be>
to control@debbugs.gnu.org.
(Thu, 01 Sep 2022 17:08:02 GMT) (full text, mbox, link).
Merged 47764477825380257527.
Request was from Maxime Devos <maximedevos@telenet.be>
to control@debbugs.gnu.org.
(Thu, 01 Sep 2022 17:08:03 GMT) (full text, mbox, link).
Information forwarded
to bug-guix@gnu.org: bug#57527; Package guix.
(Thu, 01 Sep 2022 17:39:01 GMT) (full text, mbox, link).
To: Maxime Devos <maximedevos@telenet.be>, "Toorn, H.W.P. van den (Henk)"
<H.W.P.vandenToorn@uu.nl>, 57527@debbugs.gnu.org
Subject: Re: bug#57527: compute-guix-derivation has an error
Date: Thu, 01 Sep 2022 19:38:18 +0200
Hi,
> For now, you can try working-around by retrying "guix pull".
Henk, could you retry
guix pull --commit=89d427e4be35fe79c23e2785a55c19df781fb77e
? BTW, it works for me with:
guix time-machine --commit=fc94e93c4b60addfda3c1eddfb85907e9459a8af \
-- time-machine --commit=89d427e4be35fe79c23e2785a55c19df781fb77e \
-- help
and I guess the error is transient because network.
What is the version of the daemon you are running?
Cheers,
simon
Debbugs is free software and licensed under the terms of the
GNU Public License version 2. The current version can be
obtained from https://bugs.debian.org/debbugs-source/.