Leo Famulari <l...@famulari.name> writes: > On Wed, Feb 05, 2025 at 12:18:41AM +0100, Simon Josefsson via Bug > reports for GNU Guix wrote: >> Looking more carefully at the errors, I notice this part: >> >> actual-err> cpack-cfg> set(DPKG_EXECUTABLE "/usr/bin/dpkg") >> actual-err> cpack-cfg> set(READELF_EXECUTABLE >> "/gnu/store/pqai4n95zn5wdw430gslb00sb967jdg8-binutils-2.41/bin/readelf") >> >> So for some reason building cmake-bootstrap in guix in Debian picks up >> Debian's /usr/bin/dpkg, doesn't it?! >> >> I suppose that Guix's build servers aren't running Debian, so it won't >> find any /usr/bin/dpkg. > > It would be really surprising if '/usr/bin/dpkg' could be found or > accessed from within the package build environment, unless the build > isolation has been disabled. > > Are you able to confirm if that is what's happening?
Hi. What do you mean by disabled isolation? In the initial e-mail I quoted the set of commands used which involved: (guix-daemon --disable-chroot --build-users-group=_guixbuild & Is that what you mean? Is building things without build isolation not supposed to work? Maybe there is now sufficient details to reproduce this: rebuild cmake-bootstrap in a Debian container with Guix installed without build isolation. I'm not sure how to trigger a cmake-bootstrap rebuild though, guix just seems to use the cached result for me. Btw, substitutes were available at some point, so there is now arm64 Guix container images suitable for GitLab pipeline! https://gitlab.com/debdistutils/guix/container/-/pipelines/1682821432 https://gitlab.com/debdistutils/guix/container/-/jobs/9211075760 /Simon
signature.asc
Description: PGP signature
