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.
OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
