Hi Daniel, Daniel Sahlberg <daniel.l.sahlb...@gmail.com> writes:
> Den mån 3 apr. 2023 kl 17:35 skrev Maxim Cournoyer < > maxim.courno...@gmail.com>: > >> Oh. This suggests your installation does not make use of the available >> binary substitutes that would dramatically speed things up and >> workaround the bug you encountered (which is caused by TLS certificates >> expiring in the OpenSSL test suite, see: >> https://issues.guix.gnu.org/56137). >> > > I used the --no-substitutes argument as suggested. Maybe this is the reason? Ah yes, silly me! It would have been better advice to simply suggest to try to build it without that --no-substitutes argument, apologies! > The substitute servers key should have been authorized at installation >> by the guix-install.sh script, and Guix as of 1.4.0 uses both >> 'https://ci.guix.gnu.org' and 'https://bordeaux.guix.gnu.org' as its >> default substitute providers. >> >> What does 'cat /etc/guix/acl' show? It should have something like, the >> first entry being Bordeaux and the second one for Berlin. >> >> --8<---------------cut here---------------start------------->8--- >> (acl >> (entry > > > [...] > > ) >> ) >> --8<---------------cut here---------------end--------------->8--- >> > > I have the same keys, only in opposite order. Your setup appears to be fine :-). [...] > In the meantime, I manually set the date/time to 2022-01-01 and that seemed > to do the trick. The build completed successfully. > > In the Subversion build/test I see the same errors you have. I then did: > > [[[ > $ guix build --no-substitutes --no-grafts --system=i686-linux --keep-failed > subversion > ... > $ cd /tmp/guix-build-subversion-1.14.2.drv-0/ > $ source environment-variables > $ cd subversion-1.14.2 > $ make check -j4 PARALLEL=4 > ]]] > > This is now a functional environment to do more tests. I've been able to > reproduce the error in this environment. > > If I did the same, without sourcing the environment variables (I had to > make clean; ./config.nice before make), ie using the compiler and libraries > included with the distribution, the tests succeed. Right; you wouldn't be using the i686 libraries/toolchain then though (it'd build for x86_64, which is not known to have the problem). > I'm currently leaning towards something fishy with compiler/libraries used > in guix. I'm trying to figure out exactly how this goes wrong, but threads > programming is far from my comfort zone. In case anyone else would like to > pick up, feel free! I think the problem probably be reproducible from another i686-linux distribution; perhaps it could be tried using Docker for example. -- Thanks, Maxim
