Quiet the DMS doctor warnings on the niri-dms editions #72

Merged

TheDarkWizard merged 2 commits from dms-doctor-fixes into main

2026-07-17 07:01:12 +00:00

TheDarkWizard commented

2026-07-17 06:42:26 +00:00

Owner

Booted the niri-dms live ISO and DMS's System Check showed three warnings. Two of them were real wiring gaps in the image:

dms.service Disabled: we spawned the shell from the generated niri config, so the packaged user unit sat disabled and the shell ran outside it. The niri-dms recipes now enable dms.service globally (it binds to the graphical-session.target that niri-session brings up) and the generated config no longer spawns dms run, so it can't start twice. Niri only, on purpose: Hyprland has no systemd session, and an enabled-but-never-started unit would make the doctor report an error instead of today's warning.

Terminal: None found: worse than cosmetic. DMS launches terminal commands as $TERMINAL -e sh -c ... and falls back to xterm when TERMINAL is unset, so the launcher's terminal apps and the updater's run-in-terminal feature were dead on an image that only ships ptyxis (no -e support, only -x and --). Added a monolith-terminal shim that translates the -e convention into ptyxis' -- form, and TERMINAL=monolith-terminal in /etc/environment so pam_env reaches both the niri systemd session and Hyprland's exec-once session. The doctor line itself stays (it greps for ghostty/kitty/alacritty/foot/wezterm binaries) and is accepted as cosmetic now that the features work.

The third warning, Operating System "(not supported by dms setup)", only gates danklinux's package installer, which has no job on an immutable image. dms matches os-release ID against an exact list with no ID_LIKE fallback, and ID=monolith stays (the anaconda profile keys off it), so this one is accepted as-is.

Tested the config generation script against upstream niri 26.04's default-config.kdl for both NIRI_SHELL values; the fail-loud anchor greps still pass and the dms variant keeps the Spotlight/lock binds while losing the spawn line.

Booted the niri-dms live ISO and DMS's System Check showed three warnings. Two of them were real wiring gaps in the image: **dms.service Disabled**: we spawned the shell from the generated niri config, so the packaged user unit sat disabled and the shell ran outside it. The niri-dms recipes now enable dms.service globally (it binds to the graphical-session.target that niri-session brings up) and the generated config no longer spawns dms run, so it can't start twice. Niri only, on purpose: Hyprland has no systemd session, and an enabled-but-never-started unit would make the doctor report an error instead of today's warning. **Terminal: None found**: worse than cosmetic. DMS launches terminal commands as `$TERMINAL -e sh -c ...` and falls back to xterm when TERMINAL is unset, so the launcher's terminal apps and the updater's run-in-terminal feature were dead on an image that only ships ptyxis (no -e support, only -x and `--`). Added a monolith-terminal shim that translates the -e convention into ptyxis' `--` form, and TERMINAL=monolith-terminal in /etc/environment so pam_env reaches both the niri systemd session and Hyprland's exec-once session. The doctor line itself stays (it greps for ghostty/kitty/alacritty/foot/wezterm binaries) and is accepted as cosmetic now that the features work. The third warning, Operating System "(not supported by dms setup)", only gates danklinux's package installer, which has no job on an immutable image. dms matches os-release ID against an exact list with no ID_LIKE fallback, and ID=monolith stays (the anaconda profile keys off it), so this one is accepted as-is. Tested the config generation script against upstream niri 26.04's default-config.kdl for both NIRI_SHELL values; the fail-loud anchor greps still pass and the dms variant keeps the Spotlight/lock binds while losing the spawn line.

TheDarkWizard added 2 commits

2026-07-17 06:42:26 +00:00

Start DMS from its systemd user unit on the niri editions f543498a3f

dms doctor flags dms.service as Disabled when the shell is spawned from
the niri config instead of running inside the unit. Enable the packaged
unit globally (it binds to the graphical-session.target niri-session
brings up) and drop the spawn-at-startup from the generated config so it
doesn't start twice. Niri only: Hyprland has no systemd session, so an
enabled but never-started unit would turn the doctor warning into an
error there.

Give DMS a working $TERMINAL by wrapping ptyxis

PR Rebase Hint / Post rebase command (pull_request) Successful in 4s

Details

bluebuild / Check if a rebuild is needed (pull_request) Successful in 4s

Details

bluebuild / Release (pull_request) Has been cancelled

Details

bluebuild / Generate Release (pull_request) Has been cancelled

Details

9bc8e6c15f

DMS runs terminal commands as "$TERMINAL -e sh -c ..." and falls back
to xterm when TERMINAL is unset, so the launcher's terminal apps and the
updater's run-in-terminal were dead on an image that only ships ptyxis
(which has no -e). Add a small shim that translates -e into ptyxis' --
form and point TERMINAL at it through /etc/environment, which reaches
both the niri systemd session and Hyprland's plain exec session.

The doctor's "Terminal: None found" line still shows since it greps
for ghostty/kitty/alacritty/foot/wezterm binaries; cosmetic now that the
features work.

TheDarkWizard merged commit 89de960b51 into main

2026-07-17 07:01:12 +00:00

TheDarkWizard referenced this pull request from a commit

2026-07-17 07:01:13 +00:00

Merge pull request 'Quiet the DMS doctor warnings on the niri-dms editions' (#72) from dms-doctor-fixes into main