--autounmask-write=y writes the unmask file but emerge still
aborts because CONFIG_PROTECT marks the file as needing manual
review. --autounmask-continue=y is the right flag — it writes the
unmask AND continues the merge without aborting.
Discovered via the 'Autounmask changes successfully written.' message
followed by an immediate abort. The error message about
'autounmask-write' was actually about re-running with that flag,
not about what happened.
Applied to all three emerge invocations (main + GURU + sway).
Discovered via man: --autounmask=y alone only DISPLAYS the needed
keyword changes and aborts. The actual write to /etc/portage/...
files requires --autounmask-write=y (or --autounmask-continue=y
which also auto-continues after writing). Without --autounmask-write,
every lazygit (and any other ~amd64-only GURU package) install
fails with:
The following keyword changes are necessary to proceed:
=dev-vcs/lazygit-0.62.2 ~amd64
Use --autounmask-write to write changes to config files
Added to all three emerge invocations:
- run_once_20-install-user-packages-gentoo.sh.tmpl: main loop
- run_once_20-install-user-packages-gentoo.sh.tmpl: GURU loop
- run_once_40-install-sway-gentoo.sh.tmpl
The GURU emerge in run_once_20-install-user-packages-gentoo.sh.tmpl
was missing --autounmask=y (only had --autounmask-license=y). Same
fix as the main pkg loop: GURU packages like dev-vcs/lazygit are
~amd64-only and need the keyword unmask to be auto-written.
Symptom: 'The following keyword changes are necessary to proceed:
=dev-vcs/lazygit-0.62.2 ~amd64' even though --autounmask=y was
already on the main pkg loop. Fix: add the same flag to the GURU loop.
lazygit and most GURU packages are ~amd64 only. Without --autounmask=y,
emerge fails with: =dev-vcs/lazygit-0.62.2 ~amd64 required.
Applied to run_once_20-install-user-packages-gentoo.sh.tmpl and
run_once_40-install-sway-gentoo.sh.tmpl.
Some packages on tadbit have binaries installed OUTSIDE portage
(bat was installed by cargo earlier; eza/fd from a previous run
that the script didn't track). qlist -I correctly reports them as
not-in-portage, but command -v <bin> finds them on PATH.
Without this guard, every apply would re-emerge these packages,
causing spurious failures (e.g. 'there are no ebuilds to satisfy
app-text/bat' even though /usr/bin/bat works fine).
The detection now does:
1. If qlist reports the package is in portage: skip
2. If the binary is on PATH: log + skip
3. Otherwise: add to MISSING_PKGS
Same fix applied to the GURU_MISSING detection.
The previous missing-detect used 'command -v <basename>' which
fails for packages that don't ship a binary of the same name
(zsh-completions installs /usr/share/zsh files, not
/usr/bin/zsh-completions). After the previous run installed these
packages, the next apply falsely reported them as missing and
tried to re-install them.
Switch to qlist -I which correctly reports whether a package is
in the installed-db. qlist is from app-portage/gentoolkit which
is already installed on gentoo. Fall back to equery, then to
the basename check, in case qlist is missing.
Two corrections to the GURU package list:
1. lazygit: was 'app-misc/lazygit' but GURU has it at 'dev-vcs/lazygit'.
emerge failed with 'no ebuilds to satisfy' on app-misc/lazygit.
2. topgrade: not in any gentoo overlay. It's installed via cargo
(handled by run_onchange_30-ensure-cargo.sh which has 'cargo
install topgrade --locked' as the debian branch — same applies
on gentoo). Removing it from the GURU emerge list avoids the
same 'no ebuilds' error.
On Gentoo, fd-find / fd is in sys-apps/fd (similar to eza being in
sys-apps/eza). Both are modern rust-based CLI tools in the sys-apps
category. The template used 'app-misc/fd' which doesn't exist on
gentoo's main tree; emerge failed with 'no ebuilds to satisfy'.
eza lives in sys-apps/ on Gentoo, not app-misc/. The previous
template used 'app-misc/eza' which made emerge fail with:
!!! Error: 'app-misc/eza' not found
Also updated the USE flag block (sys-apps/eza git instead of
app-misc/eza git) so the file written to /etc/portage/package.use
is correct.
Three issues caught during tadbit onboarding:
1. run_once_00-install-bootstrap-tools.sh.tmpl (gentoo branch):
'gnupg' is ambiguous (app-crypt/gnupg vs app-vim/gnupg). Use full
category/package names: app-crypt/gnupg, app-crypt/age, etc.
The previous 'for p in age curl ...' loop fed short names to
emerge which printed '!!! The short ebuild name gnupg is
ambiguous' and exited 1.
2. run_once_20-install-user-packages-gentoo.sh.tmpl:
sys-devel/base-devel doesn't exist on Gentoo (it's an Arch/Fedora
concept; Gentoo's toolchain is the @system set which is always
installed). Removed base-devel from the package list.
3. Universal scripts (run_once_20 + run_once_40) were running on
gentoo and hitting either 'die unsupported os_family' (universal
20) or 'WARNING sway packages not configured for gentoo' (universal
40). Added early-return: 'if os_family == gentoo, exit 0' at the
top of each universal script so the gentoo-specific scripts
handle the box. (Same pattern the chaotic-aur script already had.)
4. run_once_10-add-gentoo-overlays.sh.tmpl:
The cached ~/.cache/eselect-repo/repositories.xml was corrupt on
tadbit (lxml.etree.XMLSyntaxError on every 'eselect repository
list' call). Added a sanity check: parse the XML with
xml.etree.ElementTree, delete if invalid, re-fetch.
After these fixes, the bootstrap on tadbit is expected to run cleanly
with --keep-going (the four failures above all become no-ops).
Tadbit (tadbit-gentoo, x86_64, gcc 15.2.1, TKG kernel) joins the
homelab as the 7th machine — the first gentoo box. Adds Gentoo
support to the bootstrap alongside arch and debian.
New scripts:
- run_once_10-add-gentoo-overlays.sh.tmpl: enables GURU overlay
via 'eselect repository enable guru' + 'emaint sync -r guru'.
Idempotent — skips if GURU is already at /var/db/repos/guru.
GURU is required because eza, lazygit, topgrade, and most modern
CLI tools only live in GURU (not main).
- run_once_20-install-user-packages-gentoo.sh.tmpl: emerge-based
user package set. Writes USE flags to package.use/ BEFORE
emerging so foot/wofi/waybar get the right features. Detects
missing packages via 'command -v <basename>'. Falls back to
the official curl installer for bun (no gentoo package).
- run_once_40-install-sway-gentoo.sh.tmpl: sway stack via emerge
with USE flags for X+wayland+tray+upower+wireplumber.
Updated scripts:
- .chezmoi.yaml.tmpl: os_family detection now also matches 'gentoo'.
Critical fix: Gentoo's /etc/os-release uses single-quoted values
('gentoo' not 'gentoo' or "gentoo"), and chezmoi's parser doesn't
strip them. Without trimAll "'", .chezmoi.osRelease.id returns
the literal string 'gentoo' with quotes, and the eq test fails.
Symptom: os_family silently becomes 'unknown'.
- run_once_00-install-bootstrap-tools.sh.tmpl: added gentoo branch
that uses emerge --sync + emerge (skipping if tree is < 1 day old).
- run_onchange_30-ensure-cargo.sh.tmpl: added gentoo branch for
bat (already installed by emerge, just verify), topgrade (GURU),
cargo-update (dev-util/cargo-update in main).
README: documented Gentoo-specific quirks (USE flags, GURU,
single-quote parsing, no binary packages).
