[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#48903: guix substitute: error: TLS error in procedure 'read_from_ses
From: |
Maxim Cournoyer |
Subject: |
bug#48903: guix substitute: error: TLS error in procedure 'read_from_session_record_port': Error decoding the received TLS packet. |
Date: |
Tue, 29 Jun 2021 09:23:18 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Hello Ludovic,
Ludovic Courtès <ludo@gnu.org> writes:
[...]
> As a first step, can you reproduce the bug like this:
>
> while echo substitute
> /gnu/store/44h13hn5zssfppz67vydxcf95qsc8qfw-libreoffice-6.4.7.2 /tmp/t
> | guix substitute --substitute ; do chmod -R +w /tmp/t && rm -rf
> /tmp/t; done
>
> ?
>
> FWIW, I can’t seem to reproduce it with:
>
> $ guix describe
> Generacio 185 Jun 07 2021 15:07:46 (nuna)
> guix e3611cc
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: e3611cc412e7b1c750a56d17fb1b7cde684baa3f
I can't seem to reproduce either. Perhaps the issue only arises when
there are many things happening concurrently. My daemon runs with:
--8<---------------cut here---------------start------------->8---
$ sudo ps -eF | grep guix-daemon
root 25193 216 0 3074 1524 3 Jun28 ? 00:00:00
/gnu/store/vphx2839xv0qj9xwcwrb95592lzrrnx7-guix-1.3.0-3.50dfbbf/bin/guix-daemon
25178 guixbuild --max-silent-time 0 --timeout 0
--log-compression none --discover=no --substitute-urls http://127.0.0.1:8080
https://ci.guix.gnu.org --max-jobs=4--8<---------------cut
here---------------end--------------->8---
I can rather easily (and annoyingly!) trigger the problem (and a few
variations of it, it seems) with something like:
$ packages=$(guix refresh -l protobuf | sed 's/^.*: //')
$ guix build -v3 --keep-going $packages
For example, running the above, I just got:
--8<---------------cut here---------------start------------->8---
guix build: error: corrupt input while restoring archive from #<closed:
file 7fc95acfc2a0>
--8<---------------cut here---------------end--------------->8---
Does the above commands succeed on the first time on your end? If you
have already lots of things cached, you can try for an architecture you
don't often build for by adding the '--system=i686-linux' option; that
should cause a massive amount of downloads, likely to trigger the
problem. Perhaps also try to use --max-jobs=4.
If you have ideas of how to debug this when I hit the issue I'm all ears
:-).
Thank you!
Maxim