Hi, On Wed, 02 Feb 2022 at 18:00, zimoun <zimon.touto...@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
