[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: weird OpenBLAS time-machine
From: |
zimoun |
Subject: |
Re: weird OpenBLAS time-machine |
Date: |
Thu, 03 Feb 2022 03:19:08 +0100 |
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