bug#50264: ca-certificate-bundle fails to build

[Lars-Dominik Braun <lars@6xq.net>]

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