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.