Two bugs hit on rye:
1. neovim tarball URL hardcoded to nvim-linux64.tar.gz (x86_64 only).
On aarch64 boxes (rye is arm64), curl would 404 the tarball, the
unpack would create a binary that won't run, or apt's bundled
neovim might not even be installed.
2. The 'apt's neovim is too old' branch only ran if apt had
successfully installed an old neovim. If apt didn't install
neovim at all (or installed a recent enough version), the
tarball fallback never triggered. On rye, the script reached
the final 'nvim --version' verification line and crashed with
'command not found'.
Fix:
- Detect arch via uname -m, map to correct tarball name
(x86_64 -> nvim-linux64.tar.gz, aarch64 -> nvim-linux-arm64.tar.gz)
- If command -v nvim returns false at all, skip the version check
entirely and go straight to the GitHub tarball
- If apt's neovim IS recent enough (>= 0.9), keep it and skip the
tarball
- Final 'nvim --version' verification preceded by a PATH-ensure
for /usr/local/bin in case the freshly-installed tarball binary
isn't yet on PATH for this script's environment
Verified template renders cleanly on arch.
Script claimed to be arch-only in its comment but had no actual guard.
The body always ran, so on debian it tried pacman-key (which doesn't
exist), failed with 'command not found', and aborted the whole bootstrap
chain (run_once_20 and run_onchange_30 never executed).
Fixes:
1. Wrap entire body in {{ if eq .os_family "arch" }} ... {{ end }} so
the script is a no-op on debian (logs a skip message instead of dying)
2. Prepend sudo to pacman-key, pacman -U, pacman -Syu, pacman -S, and
grep /etc/pacman.conf — same user-vs-root pattern that bit run_once_00
chezmoi runs scripts as the invoking user, not root. run_once_00 was
calling apt-get/pacman directly, which fails on debian with
'Permission denied' on /var/lib/apt/lists/lock and on arch with
similar pacman lock errors. Same pattern was already correct in
run_once_20. Mirror that here.
This is the bug that blocked rye on the second attempt.
chezmoi runs run_once_* scripts as the invoking user (uid != 0).
The earlier check [[ $(id -u) -ne 0 ]] && die ... killed the script
immediately when invoked via 'chezmoi apply' or 'chezmoi init --apply'
from a normal user session.
The scripts use sudo internally for package operations (pacman/apt),
so elevation happens correctly. The id -u check was wrong: it belongs
in a script that's *meant* to be invoked as root directly, not in a
chezmoi-managed script.
debian-stable's /etc/os-release has no ID_LIKE field. Template crashed
with 'map has no entry for key idLike' when chezmoi init ran on rye.
Two fixes:
1. hasKey() guard around .chezmoi.osRelease.idLike so missing key
doesn't error out
2. Flip contains() arg order: sprig's signature is contains(substr, str),
not contains(str, substr). Was checking backwards.
Tested against:
- miche (ID=debian-derivative with ID_LIKE=arch) -> os_family=arch
- empty ID_LIKE fallback (debian-stable) -> falls through to .id=debian
-> os_family=debian
Anonymous read is enabled on the forge, so a freshly-installed box can
clone + init without needing SSH keys pre-configured. SSH stays as the
push URL on the main workstation.
- Arch: paru -S maplemono-nf-cn (AUR package, installed via Chaotic-AUR)
- Debian: download MapleMono-NF.zip from subframe7536/Maple-font v7.9
release, extract to ~/.local/share/fonts, run fc-cache
- Idempotent: skips if fc-list already shows Maple Mono NF
- Pinned to v7.9 (20.6MB); bump MAPLE_FONT_VERSION when upgrading
Also documented in README that the default Maple Mono NF in nvim
init.lua will Just Work on every box thanks to the bootstrap.
