The checks that exist actually run

[sepehr-safari]

Six things, all the same shape: a guard that was written and then did not fire.

The GTK check never ran on Debian

It was wrapped in command -v ldconfig, and Debian keeps ldconfig in /usr/sbin, which it does not put on a normal user's PATH. So on one of the three distributions this project names as supported, the check that stops you downloading an app your machine cannot run silently did not happen.

Reproduced in a clean debian:13 container before the fix:

ldconfig NOT visible -> the GTK preflight is skipped
==> SHA-256 verified. ==> Installed Plaza v0.18.2. ==> Starting it...
plaza: error while loading shared libraries: libgtk-4.so.1

and after it, on the same image:

error: GTK 4 is missing. Install it first: apt install libgtk-4-1, dnf install gtk4, or pacman -S gtk4.
### installed? NO

It looks for ldconfig by absolute path now, searches the library directories if there is none at all, and reports "cannot tell" rather than guessing, so an unusual layout is a warning and not a refused install.

Worth saying plainly: a real Debian 13 desktop always has GTK 4 (task-gnome-desktop, task-xfce-desktop and task-kde-desktop all pull in libgtk-4-1), so almost nobody was hitting this. It is a safety net that was not there, not a broken distro.

The rest

The floor is checked before GTK presence. An Ubuntu 22.04 machine has GTK 4.6, so a presence check passes there and tells the reader nothing, while the floor is the actual reason their machine cannot run this.

The SHA-256 check installed anyway when the digest could not be fetched. A verification step that any bad minute switches off is not one. It also requires both digests to be non-empty before comparing, because two empty strings compare equal and the check then reports success over nothing at all. I hit exactly that in my own verification script this week, which is why it is guarded here.

A first start that fails now says so. The app was launched with its output thrown away, so a window that died on a missing library was indistinguishable from one that opened behind something.

A second Notary on one key said nothing at all. The daemon takes an exclusive lock on the key file and answers the second process 409 with another Notary already has this key open. The window discarded that and re-synced, landing back on the unlock screen with no error: the right passphrase, the spinner stops, nothing happens, forever. Two ordinary paths reach it, installing Plaza and then Notary, and re-running the installer while Notary is open. A daemon test pins the wording the window matches on, because the two binaries cannot import each other. Probed: changing that wording fails the test by name.

Two message buffers were too small for their messages. setExitNote formats with catch return, so a note one byte too long was not truncated, it was dropped, leaving a dead window with nothing where the explanation goes.

"This Mac holds the only copy" beside the backup button now says "this computer". v0.10.7's notes claimed that sweep covered everywhere it appeared; it had missed the one sentence telling a Linux reader why losing this machine loses their identity.

A failed signer no longer says "check SIGNER_BIN", a developer override documented only in gui/README.md that nobody who used the installer has ever set.

tar failures, unknown arguments and --help now produce messages and the right exit codes. The EXIT trap was returning the status of its own failed test, so --help exited 1.

Two empty files named no-such-key.ncryptsec are deleted. A test opens that path expecting it to be absent and was reading the working directory, so the file it is named for existed. It uses its own temp directory now.

67 tests to 68. Notary is 0.10.10.