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.


Reply via email to