Same change as Guará: update_apply used to flatly refuse to run for
the GUI binary and point the user to a manual download instead. Since
the desktop app already elevates to root before showing its window,
the process applying the update already has everything it needs — no
second authentication round is required.
- New sabia_core::update::apply_desktop[_with_progress], alongside the
existing CLI-only apply() (left untouched): detects the install kind
at runtime (AppImage via the APPIMAGE env var, same FUSE-mount issue
elevated_exe() already works around and this reuses; Deb otherwise
on Linux; WindowsInstaller on Windows), matches the right release
asset by the GUI bundle naming (_amd64/_aarch64.AppImage,
_amd64/_arm64.deb, _x64-setup.exe), verifies SHA-256 when a sidecar
is published, and installs:
- AppImage: downloads to a temp file in the same directory, renames
over the running file, execs it in place (same PID, already root).
- .deb: runs dpkg -i directly (already root), execs current_exe()
again now that dpkg replaced it on disk.
- Windows: runs the installer silently and detached, exits
immediately to release the file lock. Does not claim to relaunch
the app afterwards — no documented NSIS or Tauri flag does that;
needs a real Windows machine to confirm actual post-install
behavior.
- Engine::update_apply_desktop wires it into the Tauri update_apply
command (now takes AppHandle, emits update-progress events).
- Fixed a real gap: the existing update button handler changed its own
label when an update was available but never actually called apply
— wired it for real, with per-phase progress feedback in the
interface's existing language (download/verify/install/restart).
- scripts/build-gui.sh: generates a checksum file next to every file
in dist-gui/, matching the CLI release archive convention.
- 3 new unit tests: install-kind detection, GUI asset suffix matching
against real release naming, existing CLI-refusal test unchanged.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAyr8d7HuAdUGB6aA5xmDD
Same root cause and fix as Guará: tauri-bundler's prepare_tools runs
'dd ... seek=8 conv=notrunc' on the cached linuxdeploy-x86_64 binary on
the aarch64 Gitea runner. A bash wrapper script there loses its shebang
to the dd and fails with ENOENT; a native ELF launcher survives because
bytes 8-10 of the ELF header are unused EI_PAD padding. Replace the
wrapper with a small ELF launcher compiled with cc, and cache
AppRun-x86_64 explicitly.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAyr8d7HuAdUGB6aA5xmDD
The updater reads the latest release from Gitea. update::apply refuses to
overwrite anything but the CLI. Release workflow builds the Linux CLI;
scripts/build-gui.sh builds the Linux and Windows desktop app. Docs say Linux
and Windows only.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
