nextcloud-client and blueman: the two tray apps as modules, each with one start #48

2026-10-05T09:47:54Z

mesh-admin commented

2026-10-05 09:47:54 +00:00

Two new Go bundle modules for the workstations (hq ADR 0208, 0210, 0212, 0182). Both require x11-display, hold no seat, make no contribution and write no file.

nextcloud-client

Owns: the package nextcloud-client (official, extra; installed explicitly on both workstations).
Start: the client's own XDG autostart entry (~/.config/autostart/Nextcloud.desktop), which the client writes while 'Launch on system startup' is ticked; the session runs it through i3's dex --autostart. No xinitrc slot and no node-display-session exec, because either would be a second start. The module can't own the entry either, because the client rewrites it on every start. The packaged user unit stays disabled.
nextcloud.cfg is the operator's: it is found, and the tools only read it. No answer carries the server address, user ids or credentials: they are replaced by , and .
Tools: nextcloud_status (running, accounts by name, folders with their last sync run and errors, recent log warnings), nextcloud_log (client or sync log, bounded, across rotations), nextcloud_restart (in the session, as a transient user unit), nextcloud_check (package, exactly one start, running once, folders).

blueman

Owns: the package blueman (official, extra). It declares nothing of the bluetooth module's (bluez, bluez-utils, bluetooth.service).
Start: the package's /etc/xdg/autostart/blueman.desktop, run by dex. No other start. The static user unit exists only for D-Bus activation, and the tools always ask with --auto-start=no.
Tools: blueman_status (applet and tray processes, plugins loaded and not loaded from the applet over D-Bus, plugin switches from gsettings, Bluetooth on), blueman_restart, blueman_check (package, one start, one applet, bluetooth.service active).
It relies on the bluetooth module for the stack. No dependency mechanism exists between modules that hold no seat, so blueman_check reports a missing stack instead.

Findings (read-only, both workstations)

g14: both apps were started by dex from their entries (session scope; nextcloud --background). There is no i3 exec.
shanks: the running client and applet are children of i3, started by the predecessor's exec lines in the session of 2026-10-04, before the i3 module installed dex. From the next login, dex starts each of them once.
Neither app comes from the AUR. Assigning either module changes nothing on disk.

Also

bluetooth README: its 'leaves as found' note about blueman now points to this module.

Tests: go vet and go test in both modules run against a fake /proc and a fake home, with an injected Runner. They include manifest tests. desktop.go and its test are the same file in both bundles. mctl module check modules/*: 106 manifests ok.

Not merged, built or assigned.

Two new Go bundle modules for the workstations (hq ADR 0208, 0210, 0212, 0182). Both require x11-display, hold no seat, make no contribution and write no file. ## nextcloud-client - Owns: the package `nextcloud-client` (official, extra; installed explicitly on both workstations). - Start: the client's own XDG autostart entry (~/.config/autostart/Nextcloud.desktop), which the client writes while 'Launch on system startup' is ticked; the session runs it through i3's `dex --autostart`. No xinitrc slot and no node-display-session exec, because either would be a second start. The module can't own the entry either, because the client rewrites it on every start. The packaged user unit stays disabled. - nextcloud.cfg is the operator's: it is found, and the tools only read it. No answer carries the server address, user ids or credentials: they are replaced by <server>, <account> and <hidden>. - Tools: nextcloud_status (running, accounts by name, folders with their last sync run and errors, recent log warnings), nextcloud_log (client or sync log, bounded, across rotations), nextcloud_restart (in the session, as a transient user unit), nextcloud_check (package, exactly one start, running once, folders). ## blueman - Owns: the package `blueman` (official, extra). It declares nothing of the bluetooth module's (bluez, bluez-utils, bluetooth.service). - Start: the package's /etc/xdg/autostart/blueman.desktop, run by dex. No other start. The static user unit exists only for D-Bus activation, and the tools always ask with --auto-start=no. - Tools: blueman_status (applet and tray processes, plugins loaded and not loaded from the applet over D-Bus, plugin switches from gsettings, Bluetooth on), blueman_restart, blueman_check (package, one start, one applet, bluetooth.service active). - It relies on the bluetooth module for the stack. No dependency mechanism exists between modules that hold no seat, so blueman_check reports a missing stack instead. ## Findings (read-only, both workstations) - g14: both apps were started by dex from their entries (session scope; nextcloud --background). There is no i3 exec. - shanks: the running client and applet are children of i3, started by the predecessor's exec lines in the session of 2026-10-04, before the i3 module installed dex. From the next login, dex starts each of them once. - Neither app comes from the AUR. Assigning either module changes nothing on disk. ## Also - bluetooth README: its 'leaves as found' note about blueman now points to this module. Tests: go vet and go test in both modules run against a fake /proc and a fake home, with an injected Runner. They include manifest tests. desktop.go and its test are the same file in both bundles. `mctl module check modules/*`: 106 manifests ok. Not merged, built or assigned.

mesh-admin added 1 commit 2026-10-05 09:47:54 +00:00

Add nextcloud-client and blueman: the two tray apps get an owner and tools, each with one start 9582208984

Both are official packages already on both workstations, started once by dex from an XDG
autostart entry (the client's own, the package's). The modules declare the package, add no
second start, own none of the apps' files, and give the mesh status, log, restart and check.

mesh-admin merged commit 170b3296e9 into main

2026-10-05 09:48:44 +00:00

mesh-admin deleted branch feat/nextcloud-client-and-blueman

2026-10-05 09:48:44 +00:00

mesh-admin commented

2026-10-06 23:08:19 +00:00

Delivery novox/mesh-catalog@170b3296e90b — held since 2026-10-06T23:05:28Z

Held for a person: merged without a passing check: only a person decides that it goes on — mesh-delivery.release with why lets it go on.

Delivery plan — builds blueman, bluetooth, nextcloud-client → g14, shanks; no bus step

tier 0: blueman, bluetooth, nextcloud-client
g14: receives blueman, bluetooth, nextcloud-client
shanks: receives blueman, bluetooth, nextcloud-client

Transitions

2026-10-06 23:05 (new) → proposed (announced): novox/mesh-catalog#48 merged; its head was not heard by this owner, so it is made from the forge's word
2026-10-06 23:05 proposed → held (merged-unchecked): merged without a passing check — a verdict known with it is taken first: only a person decides that it goes on

The commit's note under refs/notes/mesh-plan keeps every transition: git log --notes=mesh-plan.

**Delivery** `novox/mesh-catalog@170b3296e90b` — **held** since 2026-10-06T23:05:28Z Held for a person: merged without a passing check: only a person decides that it goes on — `mesh-delivery.release` with why lets it go on. **Delivery plan** — builds blueman, bluetooth, nextcloud-client → g14, shanks; no bus step - tier 0: blueman, bluetooth, nextcloud-client - g14: receives blueman, bluetooth, nextcloud-client - shanks: receives blueman, bluetooth, nextcloud-client **Transitions** - 2026-10-06 23:05 (new) → proposed (announced): novox/mesh-catalog#48 merged; its head was not heard by this owner, so it is made from the forge's word - 2026-10-06 23:05 proposed → held (merged-unchecked): merged without a passing check — a verdict known with it is taken first: only a person decides that it goes on The commit's note under `refs/notes/mesh-plan` keeps every transition: `git log --notes=mesh-plan`.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-catalog#48