Each run's output now goes to ~/.local/state/coredesktop/logs/, so what
failed can be read after the terminal is gone. In a terminal, update runs
itself under script(1), so everything it runs still sees a terminal, then
strips color codes and progress redraws from the log; otherwise it uses
tee. install.sh, usually piped into bash, uses tee, and runs configure
straight on the terminal, outside the log. Both name the log when
something fails. 95-cleanup.sh keeps the newest 10 update logs and 3
install logs.
The sudo keepalive loops no longer share the logged output, so their
sleep can't hold the log open after the run ends.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
An interrupted plugin update can leave a plugin's files out of step with
its checkout, and lazy.nvim then refuses to update it, every time. Before
syncing, update now stashes such changes, so they can still be recovered
with git stash pop, and puts the plugin's submodules back.
Flathub retired org.mozilla.Thunderbird in favor of
org.mozilla.thunderbird_esr, so update tried to reinstall the old ID on
every run. Install the new one. flatpak update already moves existing
installs over; a migration carries a skip-packages entry for the old ID
over to the new one.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A sibling's version is its latest git tag (v1.4.0, or v1.4.0+3 for commits
after it), or, without tags, its commit's date and short hash, like
CoreDesktop's own. The version shown as available is that of the newest
commit on the default branch, which is what update installs.
sibling list shows each sibling's version. sibling check fetches every
sibling at once and shows which have a newer version, and sibling update
[name...] updates the named siblings or all of them. 71-siblings.sh now
runs sibling update, so update and version share one way of updating.
version lists the installed siblings with any newer version and, when run
in a terminal, asks for each one whether to update it now. version --check
and the update notification still only look at CoreDesktop.
The sibling skill docs describe how to release a version by tagging it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
makepkg builds pkg-debug alongside an AUR package, and removing the
package leaves it behind: the migration that dropped asdf-vm left
asdf-vm-debug. Found by 30-upgrade-from-baseline at 0c0ddf5, whose
machine kept it where a fresh install has none.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Brings in the shellcheck lint and bats tests. Both sides fixed the same
shellcheck warnings; this keeps the remote's versions of 20-aur.sh,
80-gnome-extensions.sh and .shellcheckrc, which silence false positives
per line rather than for the whole repo.
The Gitea workflow now runs make lint, so it checks the same scripts as
the Makefile, and the README points contributors at make check. The test
helper's REPO, used only by the .bats files, is marked for shellcheck,
and the update test expects the pull to be fast-forward only.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
make lint runs shellcheck on every tracked bash script, make test runs
the bats suite in tests/, and make check runs both. The tests cover the
update orchestrator (hook isolation, failure reporting, pull and
free-space handling) and utils.sh (migrations, package install and
removal, services, initramfs build check), using stub commands so they
never touch the real system.
Fixes from the first lint run: 20-aur.sh stops if a cd fails rather
than building or deleting in the wrong directory, and
80-gnome-extensions.sh refuses to rm -rf with an empty path. The rest
are false positives, silenced in .shellcheckrc or per line.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The gateway reads its sandbox rules and loads new dependencies only when it
starts, and hermes update restarts it only for new code. Restart it at the end
of the sandbox update step instead of before hermes update runs.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
`sibling` asks for a git URL, clones the repo into
~/.local/share/siblings/<name>, runs its install.sh and confirms the
install. `sibling list` and `sibling remove` manage installed siblings.
updates.d/71-siblings.sh pulls every sibling during `update` and runs
its update.sh, reporting failures in the update summary.
Document the sibling contract in skills/sibling-project-format.md and
update the custom-hook guide to match.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
davidandClaude Opus 5.5