Re: weird OpenBLAS time-machine

[zimoun <zimon.toutoune@gmail.com>]

Hi,

On Wed, 02 Feb 2022 at 18:00, zimoun <zimon.toutoune@gmail.com> wrote:

> --8<---------------cut here---------------start------------->8---

[...]

> $ guix time-machine --commit=4b1538e6ef -- show openblas | recsel -P version
> 0.3.9
> --8<---------------cut here---------------end--------------->8---

The issue is because concurrency.  If two time-machines are run
concurrently, they both update ~/.cache/guix/checkouts/ and the end
result is hard to predict.

Well, I probably ran inside one terminal “guix time-machine
--commit=XXXX -- help” where XXXX a commit with openblas@0.3.9; and in
the same time inside another terminal, “guix time-machine
--commit=4b1538e6ef -- help”.  Depending on “the same time”, the state
of the checkout
~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq
used by the time-machine at 4b1538e6ef was the state for the commit
XXXX.

Then, all is messed!

Somehow, IIUC the code behind, what is missing is a lock when updating
the cached checkout to prevent concurrent unrelated updates.


For sure, on 3 independent other machines, and after GC the initial
machine, I get the same error for this commit 4b1538e6ef:

--8<---------------cut here---------------start------------->8---
(repl-version 0 1 1)
Generating package cache for '/gnu/store/9zq283291ak72xrvlhax89gyl578kbbg-profile'...
(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (rust-1.52)) (value #f))
--8<---------------cut here---------------end--------------->8---


Sorry for the noise.

Cheers,
simon