This just happened to me on core-updates, on my YeeLoong:
--8<---------------cut here---------------start------------->8---
mhw:~/guix-core-updates$ ./pre-inst-env guix build -S expect lua zip pth bazaar
ocaml
substitute-binary: Backtrace:
substitute-binary: In ice-9/boot-9.scm:
substitute-binary: 157: 0 [catch #t #<catch-closure 107fb4f0> ...]
substitute-binary:
substitute-binary: ice-9/boot-9.scm:157:17: In procedure catch:
substitute-binary: ice-9/boot-9.scm:157:17: In procedure system-async-mark:
thread has already exited
C-c C-c
--8<---------------cut here---------------end--------------->8---
No doubt, the "system-async-mark: thread has already exited" is a
problem, but that's not what bothers me.
What disturbs me the most is that 'substitute-binary' is being called at
all. I'm 100% certain that I passed '--no-substitutes' to guix-daemon.
I use a script to start guix-daemon with the options I prefer, to avoid
mistakes. I also just checked with 'ps', and indeed '--no-substitutes'
is there on the command line.
It's very important to me to trust that guix-daemon will not accept
binaries from the internet, even if there's a man-in-the-middle that
pretends to be hydra.gnu.org with mips64el binaries for me.
I'm surprised and concerned that we seem to be having so much trouble
making '--no-substitutes' work reliably. How hard can it be?
Until we get this straightened out, what's the most reliable way for me
to hack the code to ensure that substitutes cannot work, ever?
Mark
