fix(build): run XKB test compiles chrooted into the image, surface xkbcomp errors #275
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/xkb-smoke-compile-chroot"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Root cause of the stage-5
XKB default keymap does not compilefailure on valhala (reproduced live with stderr visible):The XKB test compile ran the image's xkbcomp binary directly on the host, where the loader resolves shared libraries from the host's
/usr/local/lib. valhala carries no X client libraries, so the binary never started — and>/dev/null 2>&1rewrote the loader error into a bogus "does not compile". The keymap data itself is fine: every include the tests use (xfree86,aliases(qwerty),types/complete,compat/complete,pc/us/si/inet(evdev),geometry pc(pc105)) verified present with properdefaultsections in xkeyboard-config 2.48's pkg from the live catalog.Fix:
chroot "${MOUNT_POINT}" /usr/local/bin/xkbcomp …— image binary + image libraries, and theX11/xkbsymlink resolves natively inside the chroot (no_xkb_rootre-anchoring needed for-R; it stays for the host-side dir checks)./tmp(created + 1777'd earlier in this function) and are removed afterwards.${CACHE_DIR}/xkb-test.logand printed with anxkbcomp:prefix on failure — the next drift shows its real face instead of a generic message./mnttest compile had the identical host-loader trap — switched to the samedoas chroot /mnt …form.This also makes the check verify what it always meant to verify: the image can compile its own keymaps, not the host can run image binaries.
Gates:
./scripts/check-format.shgreen,sh -n build.shclean.🤖 Generated with Claude Code
ee4ce4f3193fc403863ffix(build): run XKB smoke compiles chrooted into the image, surface xkbcomp errorsto fix(build): run XKB test compiles chrooted into the image, surface xkbcomp errors