Panama

3 Commits

Include renames

Author SHA1 Message Date

Author	SHA1	Message	Date
Gabriel Brown	4910bd659c	Say out loud that the portal backend is crash-looping xdg-desktop-portal-hyprland 1.4.1 segfaults in its own shutdown path: exit() runs the CPortalManager destructor, which tears down wlr-foreign-toplevel handles and xdg-output proxies after the display has gone, and dies in wl_map_insert_at. systemd restarts it, so the desktop keeps working and the only symptom is screen sharing dropping mid-session and the occasional document-portal casualty. Sixty crashes in one day left no trace anywhere a person would look. It took reading coredumpctl to find, and nobody reads coredumpctl on a desktop that appears to be working -- which is exactly the shape of problem the health page exists for. On this machine the new check reported twenty-eight in the last day the moment it was wired up. Reported rather than repaired, and it says so. There is nothing to restart that systemd has not already restarted, and no newer build in the Hyprland COPR to install: the fix is upstream. A button that did nothing would be worse than a sentence that explains. Below five in a day stays green, because an upstream bug that only bites on shutdown will occasionally bite and a health page that is never green teaches people to ignore it.	2026-08-22 07:38:41 -04:00
Gabriel Brown	86825e7327	Judge the document portal by its mount, not by its service No flatpak would launch. Every one of them failed in bwrap with "Can't find source path /run/user/1000/doc/by-app/<id>", because xdg-document-portal's fuse mount was gone -- /run/user/1000/doc was a plain empty directory. That mount is bound into every sandbox bwrap builds, so losing it takes out all 34 flatpaks at once, never a subset. It had been gone for three days. The shipped unit is Type=dbus with Restart=no, so nothing retries it on failure: after it exited 21 it came back only because a flatpak called its bus name two seconds later, and that activation landed on the dying instance's mountpoint and came up with no mount at all. systemctl reports active (running) either way -- the fusermount3 helper is still sitting there as a child, in this case for two and a half days without ever completing the mount. Nothing running notices, which is what makes it so quiet. A sandbox needs the mount only while it is being constructed, so everything already open keeps working and the symptom arrives whenever you next open a flatpak you had not opened yet. Here that was three days later, and it presented as "gearlever is missing" -- an application that was installed, healthy, and entirely innocent. Two changes, because there are two failures: it does not recover, and nothing says so. The drop-in clears the mountpoint before each start, so an activation that follows a crash lands on clean ground. ExecStartPre rather than ExecStopPost precisely because nothing restarts this unit -- the next start is whenever something next wants it, and that is the moment that has to be safe. `-` because a clean start has nothing to unmount and fusermount3 exits 1 saying so. /etc/systemd/user rather than a per-user drop-in so it covers every account, and change-settings reloads the user manager so it applies without a re-login. The check asks the mount table whether $XDG_RUNTIME_DIR/doc is mounted fuse.portal. Deliberately not a service probe, and deliberately not folded into desktop.portals: that one asks about xdg-desktop-portal, a different service which was up and healthy throughout. Service state is exactly the question that lied here, so asking it again in a new place would have been no check at all. Warning carries a restart repair, verified end to end rather than assumed. The mount table is injectable, like every other path this script reads, so the contract covers unmounted, wrong-filesystem-at-the-right-path, and unreadable against written fixtures rather than against whatever /proc happens to say -- coupling the test to this machine's live flatpak state is the same mistake in miniature. Stubbing the check to always return ok fails the contract, which was confirmed rather than hoped. What is not fixed is the crash itself: one occurrence, and restarting the service to get the desktop working destroyed the evidence. The exit was 21, it landed 21 seconds after xdg-desktop-portal restarted, and that is one sample and not a theory. What this buys is that the next one is a two-second blip the doctor names, rather than three silent days. Second time for this bug. `ac231ee` found the same dead mount in August while chasing "can't open Bitwarden", fixed it by hand, and recorded it as "not a config issue, so nothing to commit there". That judgement is why it was paid for twice, and it is the part most worth writing down.	2026-08-21 15:26:20 -04:00
Gabriel Brown	e1faaf7a76	Drop the extension, and give the test suite a front door Phase 6, the last of the fresh-install spec. 159 scripts lose their .sh: 110 contracts, 47 Vicinae commands, 2 compositor contracts. A shebang and the executable bit already select the interpreter. The extension only ever added something that had to stay in sync, and the rename proved the point twice over in the space of an hour. The spec's stated risk was Vicinae's script discovery. One script was renamed and reloaded on its own before the other 46 followed; it came back as scripts:panama.capture and all 47 resolve. What the probe turned up instead is that the extension was never only a filename: Vicinae's command IDs embed it, so every ID changed. Nothing in this repository refers to them, so nothing breaks. The only trace is Vicinae's metadata.json, whose visited map had two Panama entries that are now orphaned -- two commands lost their usage ranking and will earn it back. Worth knowing before anyone renames these again on a machine that has a keybind pointing at one. Rewriting the references by exact filename missed two things it structurally could not see: a name built from a variable, settings-$page.sh, and a glob, -name '.sh'. Both were in the contract that counts the generated commands, which promptly reported 47 expected and 0 found. The mechanical part of a rename is the part that looks finished. The three subcommands. panama doctor fronts a health check that already existed and already ran at the end of every install but could not be reached from a terminal. panama upgrade re-runs the installer from anywhere. panama test runs the suite, which had no entry point at all -- 121 files that were the main safety net in this repository and were invisible in it. Writing that runner found three tests nothing was running. calendar_agenda_bridge_test, home_assistant_bridge_test and kdeconnect_bridge_test are unittest suites without the executable bit, so no contract invoked them and the first draft of the runner skipped them silently. All three pass, and have passed unobserved for weeks. The runner collects _test.py as well now, because a runner with a blind spot is worse than no runner for the same reason a dependency checker with one is: it reports PASS. Six worktrees pruned. Each was re-checked rather than trusted to the spec's list, and two needed it: panama-commands is not on feat/panama-commands but on feat/gnome-tweaks-parity, and fix/panama-displays-review reads [ahead 3] -- ahead of its remote, not of main, with every commit patch-equivalent to landed work. roadmap-completion stays; it has five commits that are genuinely unlanded. The branches are left alone: pruning a worktree costs nothing, deleting a branch is a decision. 121 contracts pass. Claude-Session: https://claude.ai/code/session_01NvgBuSWB5sE43yWmg21ozj	2026-08-20 21:55:55 -04:00

4910bd659c

Say out loud that the portal backend is crash-looping

xdg-desktop-portal-hyprland 1.4.1 segfaults in its own shutdown path:
exit() runs the CPortalManager destructor, which tears down
wlr-foreign-toplevel handles and xdg-output proxies after the display
has gone, and dies in wl_map_insert_at. systemd restarts it, so the
desktop keeps working and the only symptom is screen sharing dropping
mid-session and the occasional document-portal casualty.

Sixty crashes in one day left no trace anywhere a person would look. It
took reading coredumpctl to find, and nobody reads coredumpctl on a
desktop that appears to be working -- which is exactly the shape of
problem the health page exists for. On this machine the new check
reported twenty-eight in the last day the moment it was wired up.

Reported rather than repaired, and it says so. There is nothing to
restart that systemd has not already restarted, and no newer build in
the Hyprland COPR to install: the fix is upstream. A button that did
nothing would be worse than a sentence that explains.

Below five in a day stays green, because an upstream bug that only
bites on shutdown will occasionally bite and a health page that is
never green teaches people to ignore it.

2026-08-22 07:38:41 -04:00

Gabriel Brown

86825e7327

Judge the document portal by its mount, not by its service

No flatpak would launch. Every one of them failed in bwrap with "Can't find
source path /run/user/1000/doc/by-app/<id>", because xdg-document-portal's fuse
mount was gone -- /run/user/1000/doc was a plain empty directory. That mount is
bound into every sandbox bwrap builds, so losing it takes out all 34 flatpaks at
once, never a subset.

It had been gone for three days. The shipped unit is Type=dbus with Restart=no,
so nothing retries it on failure: after it exited 21 it came back only because a
flatpak called its bus name two seconds later, and that activation landed on the
dying instance's mountpoint and came up with no mount at all. systemctl reports
active (running) either way -- the fusermount3 helper is still sitting there as a
child, in this case for two and a half days without ever completing the mount.

Nothing running notices, which is what makes it so quiet. A sandbox needs the
mount only while it is being constructed, so everything already open keeps
working and the symptom arrives whenever you next open a flatpak you had not
opened yet. Here that was three days later, and it presented as "gearlever is
missing" -- an application that was installed, healthy, and entirely innocent.

Two changes, because there are two failures: it does not recover, and nothing
says so.

The drop-in clears the mountpoint before each start, so an activation that
follows a crash lands on clean ground. ExecStartPre rather than ExecStopPost
precisely because nothing restarts this unit -- the next start is whenever
something next wants it, and that is the moment that has to be safe. `-` because
a clean start has nothing to unmount and fusermount3 exits 1 saying so.
/etc/systemd/user rather than a per-user drop-in so it covers every account, and
change-settings reloads the user manager so it applies without a re-login.

The check asks the mount table whether $XDG_RUNTIME_DIR/doc is mounted
fuse.portal. Deliberately not a service probe, and deliberately not folded into
desktop.portals: that one asks about xdg-desktop-portal, a different service
which was up and healthy throughout. Service state is exactly the question that
lied here, so asking it again in a new place would have been no check at all.
Warning carries a restart repair, verified end to end rather than assumed.

The mount table is injectable, like every other path this script reads, so the
contract covers unmounted, wrong-filesystem-at-the-right-path, and unreadable
against written fixtures rather than against whatever /proc happens to say --
coupling the test to this machine's live flatpak state is the same mistake in
miniature. Stubbing the check to always return ok fails the contract, which was
confirmed rather than hoped.

What is not fixed is the crash itself: one occurrence, and restarting the
service to get the desktop working destroyed the evidence. The exit was 21, it
landed 21 seconds after xdg-desktop-portal restarted, and that is one sample and
not a theory. What this buys is that the next one is a two-second blip the
doctor names, rather than three silent days.

Second time for this bug. ac231ee found the same dead mount in August while
chasing "can't open Bitwarden", fixed it by hand, and recorded it as "not a
config issue, so nothing to commit there". That judgement is why it was paid for
twice, and it is the part most worth writing down.

2026-08-21 15:26:20 -04:00

Gabriel Brown

e1faaf7a76

Drop the extension, and give the test suite a front door

Phase 6, the last of the fresh-install spec.

159 scripts lose their .sh: 110 contracts, 47 Vicinae commands, 2 compositor
contracts. A shebang and the executable bit already select the interpreter. The
extension only ever added something that had to stay in sync, and the rename
proved the point twice over in the space of an hour.

The spec's stated risk was Vicinae's script discovery. One script was renamed and
reloaded on its own before the other 46 followed; it came back as
scripts:panama.capture and all 47 resolve. What the probe turned up instead is
that the extension was never only a filename: Vicinae's command IDs embed it, so
every ID changed. Nothing in this repository refers to them, so nothing breaks.
The only trace is Vicinae's metadata.json, whose visited map had two Panama
entries that are now orphaned -- two commands lost their usage ranking and will
earn it back. Worth knowing before anyone renames these again on a machine that
has a keybind pointing at one.

Rewriting the references by exact filename missed two things it structurally
could not see: a name built from a variable, settings-$page.sh, and a glob,
-name '*.sh'. Both were in the contract that counts the generated commands, which
promptly reported 47 expected and 0 found. The mechanical part of a rename is the
part that looks finished.

The three subcommands. panama doctor fronts a health check that already existed
and already ran at the end of every install but could not be reached from a
terminal. panama upgrade re-runs the installer from anywhere. panama test runs
the suite, which had no entry point at all -- 121 files that were the main safety
net in this repository and were invisible in it.

Writing that runner found three tests nothing was running.
calendar_agenda_bridge_test, home_assistant_bridge_test and kdeconnect_bridge_test
are unittest suites without the executable bit, so no contract invoked them and
the first draft of the runner skipped them silently. All three pass, and have
passed unobserved for weeks. The runner collects *_test.py as well now, because a
runner with a blind spot is worse than no runner for the same reason a dependency
checker with one is: it reports PASS.

Six worktrees pruned. Each was re-checked rather than trusted to the spec's list,
and two needed it: panama-commands is not on feat/panama-commands but on
feat/gnome-tweaks-parity, and fix/panama-displays-review reads [ahead 3] -- ahead
of its remote, not of main, with every commit patch-equivalent to landed work.
roadmap-completion stays; it has five commits that are genuinely unlanded. The
branches are left alone: pruning a worktree costs nothing, deleting a branch is a
decision.

121 contracts pass.

Claude-Session: https://claude.ai/code/session_01NvgBuSWB5sE43yWmg21ozj

2026-08-20 21:55:55 -04:00