dotfiles/dot_config/waybar/executable_pacdiff-status.sh, branch masterMy linux config and rc fileshttps://git.sommerfeld.dev/dotfiles/atom/dot_config/waybar/executable_pacdiff-status.sh?h=master2026-05-13T12:43:36Zfix(sudoers-rs,waybar): pass DIFFPROG (and friends) through sudo-rs2026-05-13T12:43:36Zsommerfeldsommerfeld@sommerfeld.dev2026-05-13T12:43:36Zurn:sha1:767a54e48163ea0db701c926e6bf69f2237fce33
The previous fix sidestepped sudo-rs's env scrubbing by setting
DIFFPROG inside a nested root shell. That works but it's the wrong
shape — every command that wants to honour a user UX env var would
have to do the same dance. Configure the policy once instead.
etc/sudoers-rs:
Defaults env_keep += "DIFFPROG"
Defaults env_keep += "EDITOR VISUAL SUDO_EDITOR GIT_EDITOR"
Defaults env_keep += "PAGER MANPAGER GIT_PAGER SYSTEMD_PAGER"
Defaults env_keep += "LESS LESSOPEN SYSTEMD_LESS"
env_keep is the unconditional pass-through list, so no '-E' is needed
on the call site — `DIFFPROG='nvim -d' sudo pacdiff` Just Works, same
as it does for `EDITOR=nvim sudo systemctl edit foo`,
`PAGER=less sudo journalctl …`, etc. None of these vars influence
privilege boundaries; they only configure user-facing program
behaviour, so widening env_keep to cover them carries no security
trade-off worth accounting for. The existing per-visudo env_keep
lines are kept for documentation value (they're now subsumed by the
global rule but make the intent explicit at the visudo call sites).
The waybar pacdiff click handler reverts to the canonical form
`DIFFPROG='nvim -d' sudo pacdiff`, matching the recipe pacman.git
ships in /usr/share/doc/pacman/.
Will take effect after the next `chezmoi apply` redeploys
/etc/sudoers-rs (the run_onchange_after_deploy-etc.sh.tmpl script
re-installs it with mode 0440 whenever its hash changes).
fix(waybar): pacdiff click — set DIFFPROG inside the root shell2026-05-13T12:43:36Zsommerfeldsommerfeld@sommerfeld.dev2026-05-13T12:43:36Zurn:sha1:1238e4dfc33bc4347564350bbfadac50aa8da0cd
sudo-rs scrubs the env by default, so neither `DIFFPROG=… sudo pacdiff`
nor `sudo DIFFPROG=… pacdiff` reaches pacdiff with the variable set.
Sidestep the env-policy question entirely by running
sudo sh -c 'DIFFPROG="nvim -d" pacdiff'
so the assignment happens inside the privileged shell, after the
env-scrubbing boundary. No sudoers-rs change required, and the same
form works identically under stock sudo if the user ever switches
back.
feat(waybar): pacdiff + failed-units reminders2026-05-13T12:43:35Zsommerfeldsommerfeld@sommerfeld.dev2026-05-13T12:43:35Zurn:sha1:aba0bd84ac3b92d45f55b03692814e496358fe25
Two live waybar modules — no timer/state-file pipeline because the
inputs are cheap to compute on every poll:
custom/pacdiff (interval 300s)
Counts unresolved .pacnew / .pacsave files via `pacdiff -o` (output
mode — lists only, takes no action). Hidden at zero. Yellow 'pacdiff
N' otherwise. Mako fires once on the 0→N transition, so you get
exactly one nudge per upgrade wave, not a sustained re-nag for files
you've decided to defer. Click runs `sudo DIFFPROG='nvim -d' pacdiff`
in a floating ghostty.
custom/failed-units (interval 30s)
Sums `systemctl --failed` (system) and `systemctl --user --failed`
counts. Hidden at zero. Red 'failed N' otherwise. Mako fires only on
upward transition (count went up since last poll), so already-known
failures don't keep paging you while you investigate. Click prints
both `systemctl --failed` outputs in a floating ghostty.
Both modules use the same $XDG_RUNTIME_DIR/waybar-X-prev pattern as the
update reminder for state, which makes 'reboot resets the nag' the
default behaviour — exactly the right semantics for both: a fresh boot
deserves a fresh look at pending pacdiffs and any failed units.