Hi Ludo, thanks for looking into this!
> Is this the backtrace found in the build log (under /var/log/guix/drvs)? Yes, it is printed on stdout, as well as part of the build log. > I tried and failed to reproduce it like this: > > --8<---------------cut here---------------start------------->8--- > $ guix environment --ad-hoc nss-certs -n > La jena derivo estus konstruata: > /gnu/store/i5s8jqzl52j38qmwqghjyp0v8p7dnlgd-profile.drv > > $ guix gc -R /gnu/store/i5s8jqzl52j38qmwqghjyp0v8p7dnlgd-profile.drv |grep > certificate > /gnu/store/n63a6h3dfhwnaas9pg35zk78qjhxbas9-cmake-curl-certificates.patch > /gnu/store/c8czsp9prfd73wvnyh595h0riqcllfqp-ca-certificate-bundle-builder > /gnu/store/wdnm4j88pxxkg0m72b58db24fghjizmz-ca-certificate-bundle.drv > $ guix build --rounds=10 > /gnu/store/wdnm4j88pxxkg0m72b58db24fghjizmz-ca-certificate-bundle.drv > … > --8<---------------cut here---------------end--------------->8--- > > Could you find a way to reproduce the issue? Alright, let’s see. The command I have been using is guix pack -L . -C 'zstd' -f docker -S /bin=bin python-jupyterlab bash coreutils findutils with . being a checkout of guix-science (same applies to `guix time-machine` though). The first time it’ll fail, but the second time it succeeds. Running `guix gc` makes it fail again the first time. The docker-pack.tar.zst.drv used for the first build is different from the second one (different hash prefix). For me it’s /gnu/store/r096cm3np7hbdn853ih35h1a5l39in4s-python-jupyterlab-bash-coreutils-docker-pack.tar.zst.drv the first time and /gnu/store/dywspxjshfjhc07i17hkcyrlq8kn7m07-python-jupyterlab-bash-coreutils-docker-pack.tar.zst.drv the second time. YMMV. Looking at ca-certificate-bundle.drv, the first one lacks any form of glibc-utf8-locales as an input (neither in the .drv, nor via `guix gc --references <.drv> | grep glibc-`), so it’s clear it must fail. I’m not quite sure why though, since the actual builder still has a reference to the locales and sets LOCPATH. So I’m a little puzzled. > --8<---------------cut here---------------start------------->8--- > $ guix build glibc-utf8-locales > /gnu/store/rgydar9dfvflqqz2irgh7njj34amaxc6-glibc-utf8-locales-2.31 > $ guix hash -r $(guix build glibc-utf8-locales) > 012a1vcvmhbrqr5kjbmf7qlgpbw2zv36rgj7rxh400dh8wlj97pi > $ wget -qO - https://ci.guix.gnu.org/rgydar9dfvflqqz2irgh7njj34amaxc6.narinfo > |grep NarHash > NarHash: sha256:012a1vcvmhbrqr5kjbmf7qlgpbw2zv36rgj7rxh400dh8wlj97pi > --8<---------------cut here---------------end--------------->8--- Exactly the same for me, so we have the same data at least. `guix gc` with the repair,contents options also does not show any corrupted items. I’m thus assuming my store is intact. Any ideas? Thanks, Lars