diff options
| -rw-r--r-- | archive/task-archive.org | 38 | ||||
| -rw-r--r-- | todo.org | 273 |
2 files changed, 154 insertions, 157 deletions
diff --git a/archive/task-archive.org b/archive/task-archive.org index 3811cc6..4f2fdaa 100644 --- a/archive/task-archive.org +++ b/archive/task-archive.org @@ -2930,3 +2930,41 @@ CLOSED: [2026-08-08 Sat] Killed at the 2026-08-08 task review: an undated annual intention that never fired — pain points get surfaced organically as they bite. Once-yearly systematic inventory of known deficiencies and friction points in current toolset +** DONE [#B] Podman API socket and camera-passthrough udev rule :feature:solo: +CLOSED: [2026-08-09 Sun] +:PROPERTIES: +:CREATED: [2026-08-07 Fri] +:LAST_REVIEWED: 2026-08-07 +:END: +Shipped 2026-08-09: the installer enables the rootless podman socket at +install time (enable_user_service grew a wants-target arg so socket units +land in sockets.target.wants) and ships +=72-usb-passthrough-cameras.rules= — numbered below 73 per the winvm +rule-ordering correction, GROUP/MODE as the verified grant, uaccess tag kept. +Applied live on ratio (socket enabled+active, 99- file retired, udev +reloaded); velox apply rides the velox-return riders on the sleep/suspend +task. The uaccess-alone hypothesis stays untested until a camera is attached. +From winvm 2026-08-07 (ratio). Two one-time machine-level setups, both live on +ratio and absent on velox; full evidence and rationale in +[[file:docs/design/2026-08-07-podman-socket-and-camera-udev.md]]. + +- Enable the rootless podman socket at install time + (=systemctl --user enable --now podman.socket=). Socket-activated, zero idle + cost; every podman GUI/API client needs it, and its absence fails silently + (Pods opens to an empty window). The installer already carries the + "=systemctl --user enable= fails during install" workaround pattern + (=archsetup:1270=, =:2722=) — use it. +- Ship a udev rule granting GROUP="video", MODE="0660" on the OBSBOT + (3564:ff02) and BRIO (046d:085e) USB nodes so =usbredirect= can claim them + for VM passthrough. CORRECTED (winvm, 2026-08-08): the original "uaccess + can't ACL raw USB nodes" claim was wrong — the mechanism is rule ordering. + The ACL is applied by =73-seat-late.rules=, so a =99-= rule adds the tag + after that already ran; distro rules that add the tag all sort at or below + 70. [@70] So number our file below 73 (e.g. =72-usb-passthrough-cameras.rules=), + keep the verified GROUP/MODE grant, and keep the tag — correctly ordered it + may make uaccess work on its own (untested hypothesis; a tighter grant if + it holds, needs the camera plugged in to verify). Reconcile ratio's + existing =99-= file (winvm installed it) when the installer version lands. + +Scope: installer step + rule file + tests per existing shapes, and apply both +live to velox over tailscale (daily-driver sync — neither exists there today). @@ -223,38 +223,6 @@ to read file" on stderr and nothing on stdout; piped into =grep -c=, that empty stdout reads as 0 and looks like a missing module. The gate has to run as root and check the exit status, not just the count. -** DONE [#A] Lock-screen clock stale after a real sleep :bug:hyprland:dotfiles:velox: -CLOSED: [2026-09-13 Sun] SCHEDULED: <2026-08-25 Tue> -:PROPERTIES: -:CREATED: [2026-08-25 Tue] -:LAST_REVIEWED: 2026-08-25 -:END: -After waking velox from a real sleep, the hyprlock clock shows a stale time -(Craig confirmed 2026-08-24: the wake-from-sleep case, not an idle-locked -screen). Three isolated tests on 2026-08-24 failed to reproduce it — hyprlock -0.9.6 repainted within a second of a display power-cycle, a three-minute -SIGSTOP, and both together with the screenshot background — so it needs a real -suspend on the real hardware. - -Grading: Minor severity (cosmetic-to-confusing, the screen still unlocks) × -most users frequently (every wake) = P3 = [#C] by the matrix; held at [#A] at -Craig's direction on 2026-08-25 so it gets run while velox is the daily driver -on the road. Revisit the letter once the manual check has an answer. - -Not :solo: — the distinguishing observation is Craig's. The check lives under -Manual testing and validation: "Lock screen after a real sleep: is the clock -frozen, or is all of hyprlock frozen?". Its three outcomes each name a -different fix: stale-then-corrects → repaint interval; frozen with live input -→ clock rendering; frozen with dead input → hyprlock hung, a crash/hang -recovery bug the =screen-lock= watchdog doesn't cover. - -*** 2026-09-13 Sun @ 07:57:04 -0500 Closed: fixed, per Craig -Craig confirmed on 2026-09-13 Sun that the stale clock after a real sleep is fixed on -velox. I could not identify the commit from here (nothing in the dotfiles -or archsetup log since 2026-08-24 names hyprlock, the lock clock, sleep or -resume), so this closes on his report rather than a cited change; the -manual-testing check for it is retired with it. - ** TODO [#C] post-rebuild-check: probe that Emacs frames come up Wayland-native :feature:emacs:velox:solo:quick: :PROPERTIES: :CREATED: [2026-08-25 Tue] @@ -502,48 +470,6 @@ Alternatives if it drags on: change Signal's tray setting so it keeps a window (=~/.config/Signal/ephemeral.json= =system-tray-setting=), or run a waybar carrying the #5240 fallback. -** DONE [#A] Velox reinstall — DR test of archangel + archsetup :velox:chore: -CLOSED: [2026-09-13 Sun] DEADLINE: <2026-08-15 Sat> -:PROPERTIES: -:CREATED: [2026-08-13 Thu] -:LAST_REVIEWED: 2026-08-13 -:END: -Mainboard swapped Intel→AMD (Ryzen AI 9 HX 370); new NVRAM has no boot entry. -Decision: full reinstall via archangel+archsetup, run deliberately as a -disaster-recovery drill before the Sunday flight. Runbook (live checklist): -[[file:docs/2026-08-13-velox-reinstall-runbook.org][docs/2026-08-13-velox-reinstall-runbook.org]] -Done 2026-08-13: ISO rebuilt (archangel-2026-08-13, archsetup baked with AMD -microcode detection, velox profiles at /root/, .ai/inbox excluded — build.sh -edits pending commit in archangel), contents verified, dotfiles swept clean of -Intel assumptions. -Finding folded in: velox's truenas backups silently stopped ~Jul 6 (newest is -DAILY.0 Jul 6; wolf.conf.gpg from Jul 29 is in NO backup). Salvage pass in the -runbook is therefore REQUIRED before partitioning, and the fresh install must -fix + verify the backup timer (runbook Phase 5). - -*** 2026-09-13 Sun @ 07:16:27 -0500 Applied the two live convergence steps on velox -Ratio got both by hand on 2026-09-12 while velox was off the tailnet; velox -came back on 2026-09-13 and got them over ssh: =systemctl disable --now -wsdd.service= (no Samba host to advertise; 43acf51 stops the installer -enabling it) and =systemctl mask passim.service= (the unit is static, so the -09-12 disable was a no-op; 38b1758 masks it in the installer, but -supplemental_software is a completed step there and doesn't re-run). -Verified after: wsdd inactive/disabled, passim inactive/masked, zero -listeners on 5357 and 27500. Same pass fast-forwarded velox's dotfiles to -f56fd1a and archsetup to dc00a62, and confirmed the headless Proton Bridge -service is still disabled there. - -*** 2026-09-13 Sun @ 07:56:37 -0500 Closed the drill and filed its working-dir artifacts -The reinstall itself finished on 2026-08-14; every finding it surfaced is -its own task, and the live convergence steps landed on 2026-09-13, so nothing -was left in this task but the record. Filed per the working-files -convention: the runbook to docs/2026-08-13-velox-reinstall-runbook.org (with -an Outcome section, since the checklist was never ticked during the run), -the boot-entry reference to docs/2026-08-15-velox-uefi-boot-entry-reference.org, -the three gap reports to docs/design/2026-08-14-velox-reinstall-gaps-1 to 3, -and the wttrin bundle to working/emacs-wttrin-rescue/ under the task that -owns it. working/velox-reinstall/ is gone and every inbound link repointed. - ** TODO [#B] Truenas session-host VM for long-running agent sessions :feature:tooling: :PROPERTIES: :CREATED: [2026-08-13 Thu] @@ -873,51 +799,6 @@ matches "the store is the source of truth" — a channel with exactly one plausible reading should not be a dead end. Grading: Minor severity (one fallback still puts a wallpaper up) x some users sometimes = P3 = [#C]. -** DONE [#B] Land the rescued emacs-wttrin commit :chore:velox: -CLOSED: [2026-09-13 Sun] -:PROPERTIES: -:CREATED: [2026-08-14 Fri] -:LAST_REVIEWED: 2026-08-17 -:END: -bf0457f "feat: add wttrin-hide-follow-line to hide the wttr.in follow line" -(2026-06-24) was the only genuinely unpushed commit anywhere on the old -velox — 3 files, 103 insertions, with a test file. Rescued as a verified -git bundle before the disk was wiped (wttrin-bf0457f.bundle, deleted on -2026-09-13 once the commit was on the remote): -To land it: clone emacs-wttrin, =git fetch <bundle> --branches=, review the -commit, then push to git@cjennings.net:emacs-wttrin.git. Delete the bundle -once it's on the remote. - -*** 2026-08-17 Mon @ 19:57:42 -0700 Re-checked: still unlanded, and the bundle is still the only copy -Cloned the remote bare and asked it for the object directly: =git cat-file -t -bf0457f= returns "Not a valid object name", so the commit has never reached -=git@cjennings.net:emacs-wttrin.git=. Remote =main= is =ee8fdeb=. - -That makes =working/emacs-wttrin-rescue/wttrin-bf0457f.bundle= (moved there 2026-09-13 when the reinstall task filed its artifacts) the sole surviving -copy of 103 insertions across three files, on one laptop that is travelling. -Worth doing sooner than its =[#B]= suggests for that reason alone. It also -pinned the reinstall working directory open until 2026-09-13, when the bundle -moved into its own working dir here and the reinstall task closed. - -*** 2026-09-13 Sun @ 09:47:20 -0500 Landed on emacs-wttrin release/0.4.0 and deleted the bundle -Cherry-picked unchanged onto release/0.4.0 (which already contains main; the -remote's default branch is still main, so main doesn't carry it yet) as -cb70193, patch-id identical to bf0457f. Review turned up two -defects the rescued commit carried, both fixed test-first and pushed with it: -f9449f6 makes the existing-F check case-sensitive (case-fold-search defaults -to t, so a lowercase f read as F), and 9c8d23e keys the cache on the effective -display options (toggling the setting kept serving a cached buffer with the -Follow line, against the 944a52f rule). Pushed 37e1c94..9c8d23e; full suite -green at 73 files. - -Two things checked before landing: an old emacs-wttrin note that F broke ANSI -colour is stale (wttr.in sends identical colour codes with and without F), and -the suite's smoke failure was only missing Emacs 31.1 eask deps. The bundle's -main and release/0.4.0 heads are on the remote as-is, and its only other commit -(bf0457f) is there as the patch-identical cb70193, so the bundle and its -working dir are deleted. -emacs-wttrin has a handoff note in its inbox covering all of it. - ** TODO [#B] archsetup doesn't clone rulesets :bug:velox: DEADLINE: <2026-08-15 Sat> :PROPERTIES: @@ -3723,44 +3604,6 @@ the stage defaults; render to a non-stowed path and have hypridle read that; or keep it tracked but commit a machine-neutral render. The first looks right — the store already holds the real source of truth, and the rendered file is a build artifact. -** DONE [#B] Podman API socket and camera-passthrough udev rule :feature:solo: -CLOSED: [2026-08-09 Sun] -:PROPERTIES: -:CREATED: [2026-08-07 Fri] -:LAST_REVIEWED: 2026-08-07 -:END: -Shipped 2026-08-09: the installer enables the rootless podman socket at -install time (enable_user_service grew a wants-target arg so socket units -land in sockets.target.wants) and ships -=72-usb-passthrough-cameras.rules= — numbered below 73 per the winvm -rule-ordering correction, GROUP/MODE as the verified grant, uaccess tag kept. -Applied live on ratio (socket enabled+active, 99- file retired, udev -reloaded); velox apply rides the velox-return riders on the sleep/suspend -task. The uaccess-alone hypothesis stays untested until a camera is attached. -From winvm 2026-08-07 (ratio). Two one-time machine-level setups, both live on -ratio and absent on velox; full evidence and rationale in -[[file:docs/design/2026-08-07-podman-socket-and-camera-udev.md]]. - -- Enable the rootless podman socket at install time - (=systemctl --user enable --now podman.socket=). Socket-activated, zero idle - cost; every podman GUI/API client needs it, and its absence fails silently - (Pods opens to an empty window). The installer already carries the - "=systemctl --user enable= fails during install" workaround pattern - (=archsetup:1270=, =:2722=) — use it. -- Ship a udev rule granting GROUP="video", MODE="0660" on the OBSBOT - (3564:ff02) and BRIO (046d:085e) USB nodes so =usbredirect= can claim them - for VM passthrough. CORRECTED (winvm, 2026-08-08): the original "uaccess - can't ACL raw USB nodes" claim was wrong — the mechanism is rule ordering. - The ACL is applied by =73-seat-late.rules=, so a =99-= rule adds the tag - after that already ran; distro rules that add the tag all sort at or below - 70. [@70] So number our file below 73 (e.g. =72-usb-passthrough-cameras.rules=), - keep the verified GROUP/MODE grant, and keep the tag — correctly ordered it - may make uaccess work on its own (untested hypothesis; a tighter grant if - it holds, needs the camera plugged in to verify). Reconcile ratio's - existing =99-= file (winvm installed it) when the installer version lands. - -Scope: installer step + rule file + tests per existing shapes, and apply both -live to velox over tailscale (daily-driver sync — neither exists there today). ** CANCELLED [#B] agent-text relay reports success for a message that went nowhere :bug: CLOSED: [2026-08-19 Wed] :PROPERTIES: @@ -4412,3 +4255,119 @@ OS-side knob exists. One keystroke: Fn+Esc toggles Fn Lock; Craig confirmed F1-F12 now send F-keys by default. The EC holds the state across reboots; it reverts only if the EC loses power (battery disconnect or mainboard reset), which is likely why it flipped around the August reinstall. +** DONE [#A] Lock-screen clock stale after a real sleep :bug:hyprland:dotfiles:velox: +CLOSED: [2026-09-13 Sun] SCHEDULED: <2026-08-25 Tue> +:PROPERTIES: +:CREATED: [2026-08-25 Tue] +:LAST_REVIEWED: 2026-08-25 +:END: +After waking velox from a real sleep, the hyprlock clock shows a stale time +(Craig confirmed 2026-08-24: the wake-from-sleep case, not an idle-locked +screen). Three isolated tests on 2026-08-24 failed to reproduce it — hyprlock +0.9.6 repainted within a second of a display power-cycle, a three-minute +SIGSTOP, and both together with the screenshot background — so it needs a real +suspend on the real hardware. + +Grading: Minor severity (cosmetic-to-confusing, the screen still unlocks) × +most users frequently (every wake) = P3 = [#C] by the matrix; held at [#A] at +Craig's direction on 2026-08-25 so it gets run while velox is the daily driver +on the road. Revisit the letter once the manual check has an answer. + +Not :solo: — the distinguishing observation is Craig's. The check lives under +Manual testing and validation: "Lock screen after a real sleep: is the clock +frozen, or is all of hyprlock frozen?". Its three outcomes each name a +different fix: stale-then-corrects → repaint interval; frozen with live input +→ clock rendering; frozen with dead input → hyprlock hung, a crash/hang +recovery bug the =screen-lock= watchdog doesn't cover. + +*** 2026-09-13 Sun @ 07:57:04 -0500 Closed: fixed, per Craig +Craig confirmed on 2026-09-13 Sun that the stale clock after a real sleep is fixed on +velox. I could not identify the commit from here (nothing in the dotfiles +or archsetup log since 2026-08-24 names hyprlock, the lock clock, sleep or +resume), so this closes on his report rather than a cited change; the +manual-testing check for it is retired with it. +** DONE [#A] Velox reinstall — DR test of archangel + archsetup :velox:chore: +CLOSED: [2026-09-13 Sun] DEADLINE: <2026-08-15 Sat> +:PROPERTIES: +:CREATED: [2026-08-13 Thu] +:LAST_REVIEWED: 2026-08-13 +:END: +Mainboard swapped Intel→AMD (Ryzen AI 9 HX 370); new NVRAM has no boot entry. +Decision: full reinstall via archangel+archsetup, run deliberately as a +disaster-recovery drill before the Sunday flight. Runbook (live checklist): +[[file:docs/2026-08-13-velox-reinstall-runbook.org][docs/2026-08-13-velox-reinstall-runbook.org]] +Done 2026-08-13: ISO rebuilt (archangel-2026-08-13, archsetup baked with AMD +microcode detection, velox profiles at /root/, .ai/inbox excluded — build.sh +edits pending commit in archangel), contents verified, dotfiles swept clean of +Intel assumptions. +Finding folded in: velox's truenas backups silently stopped ~Jul 6 (newest is +DAILY.0 Jul 6; wolf.conf.gpg from Jul 29 is in NO backup). Salvage pass in the +runbook is therefore REQUIRED before partitioning, and the fresh install must +fix + verify the backup timer (runbook Phase 5). + +*** 2026-09-13 Sun @ 07:16:27 -0500 Applied the two live convergence steps on velox +Ratio got both by hand on 2026-09-12 while velox was off the tailnet; velox +came back on 2026-09-13 and got them over ssh: =systemctl disable --now +wsdd.service= (no Samba host to advertise; 43acf51 stops the installer +enabling it) and =systemctl mask passim.service= (the unit is static, so the +09-12 disable was a no-op; 38b1758 masks it in the installer, but +supplemental_software is a completed step there and doesn't re-run). +Verified after: wsdd inactive/disabled, passim inactive/masked, zero +listeners on 5357 and 27500. Same pass fast-forwarded velox's dotfiles to +f56fd1a and archsetup to dc00a62, and confirmed the headless Proton Bridge +service is still disabled there. + +*** 2026-09-13 Sun @ 07:56:37 -0500 Closed the drill and filed its working-dir artifacts +The reinstall itself finished on 2026-08-14; every finding it surfaced is +its own task, and the live convergence steps landed on 2026-09-13, so nothing +was left in this task but the record. Filed per the working-files +convention: the runbook to docs/2026-08-13-velox-reinstall-runbook.org (with +an Outcome section, since the checklist was never ticked during the run), +the boot-entry reference to docs/2026-08-15-velox-uefi-boot-entry-reference.org, +the three gap reports to docs/design/2026-08-14-velox-reinstall-gaps-1 to 3, +and the wttrin bundle to working/emacs-wttrin-rescue/ under the task that +owns it. working/velox-reinstall/ is gone and every inbound link repointed. +** DONE [#B] Land the rescued emacs-wttrin commit :chore:velox: +CLOSED: [2026-09-13 Sun] +:PROPERTIES: +:CREATED: [2026-08-14 Fri] +:LAST_REVIEWED: 2026-08-17 +:END: +bf0457f "feat: add wttrin-hide-follow-line to hide the wttr.in follow line" +(2026-06-24) was the only genuinely unpushed commit anywhere on the old +velox — 3 files, 103 insertions, with a test file. Rescued as a verified +git bundle before the disk was wiped (wttrin-bf0457f.bundle, deleted on +2026-09-13 once the commit was on the remote): +To land it: clone emacs-wttrin, =git fetch <bundle> --branches=, review the +commit, then push to git@cjennings.net:emacs-wttrin.git. Delete the bundle +once it's on the remote. + +*** 2026-08-17 Mon @ 19:57:42 -0700 Re-checked: still unlanded, and the bundle is still the only copy +Cloned the remote bare and asked it for the object directly: =git cat-file -t +bf0457f= returns "Not a valid object name", so the commit has never reached +=git@cjennings.net:emacs-wttrin.git=. Remote =main= is =ee8fdeb=. + +That makes =working/emacs-wttrin-rescue/wttrin-bf0457f.bundle= (moved there 2026-09-13 when the reinstall task filed its artifacts) the sole surviving +copy of 103 insertions across three files, on one laptop that is travelling. +Worth doing sooner than its =[#B]= suggests for that reason alone. It also +pinned the reinstall working directory open until 2026-09-13, when the bundle +moved into its own working dir here and the reinstall task closed. + +*** 2026-09-13 Sun @ 09:47:20 -0500 Landed on emacs-wttrin release/0.4.0 and deleted the bundle +Cherry-picked unchanged onto release/0.4.0 (which already contains main; the +remote's default branch is still main, so main doesn't carry it yet) as +cb70193, patch-id identical to bf0457f. Review turned up two +defects the rescued commit carried, both fixed test-first and pushed with it: +f9449f6 makes the existing-F check case-sensitive (case-fold-search defaults +to t, so a lowercase f read as F), and 9c8d23e keys the cache on the effective +display options (toggling the setting kept serving a cached buffer with the +Follow line, against the 944a52f rule). Pushed 37e1c94..9c8d23e; full suite +green at 73 files. + +Two things checked before landing: an old emacs-wttrin note that F broke ANSI +colour is stale (wttr.in sends identical colour codes with and without F), and +the suite's smoke failure was only missing Emacs 31.1 eask deps. The bundle's +main and release/0.4.0 heads are on the remote as-is, and its only other commit +(bf0457f) is there as the patch-identical cb70193, so the bundle and its +working dir are deleted. +emacs-wttrin has a handoff note in its inbox covering all of it. |