diff options
Diffstat (limited to 'todo.org')
| -rw-r--r-- | todo.org | 309 |
1 files changed, 171 insertions, 138 deletions
@@ -46,6 +46,34 @@ below): input-side-spec.org (DRAFT, four decisions open). * Archsetup Open Work +** TODO [#B] Visual separator between adjacent waybar modules :feature:waybar:dotfiles:quick: +:PROPERTIES: +:CREATED: [2026-09-13 Sun] +:LAST_REVIEWED: 2026-09-13 +:END: +Captured by Craig 2026-07-20 and routed here from the roam inbox, then lost +in the processed pile: the wind (weather) value runs straight into the date +with no visual stop, so the wind figure reads as the start of the date. Add +a light separator or spacing between adjacent modules so each one's edge is +unmistakable. Check the current bar first (the mic/PTT merge and the weather +chip grouping landed after the capture), then decide the form: a thin rule, +a dot glyph, or just margin. That choice is mine, so not solo; the CSS itself +is a quick change in the dotfiles waybar stylesheet. + +** TODO [#C] Saving and restoring a window configuration :feature:hyprland:research: +:PROPERTIES: +:CREATED: [2026-09-13 Sun] +:LAST_REVIEWED: 2026-09-13 +:END: +Research idea captured by Craig 2026-07-24 (the one item of that batch that +never got filed): when I want a specific window orientation, I indicate it +and the window-plus-app configuration reappears. What would we need to know +or store to make that happen? Is there another desktop or OS that does it, +what information do they keep, and what are their rules? Explore how far +Hyprland can get, document thoroughly, and review the findings with me before +building anything. The deliverable is a research note under docs/design, so +this is not solo. + ** TODO [#C] maint backup_freshness probe blind to backup_run remedy runs :bug:maint:dotfiles:solo: :PROPERTIES: :CREATED: [2026-09-12 Sat] @@ -195,31 +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. -** TODO [#A] Lock-screen clock stale after a real sleep :bug:hyprland:dotfiles:velox: -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. - ** TODO [#C] post-rebuild-check: probe that Emacs frames come up Wayland-native :feature:emacs:velox:solo:quick: :PROPERTIES: :CREATED: [2026-08-25 Tue] @@ -467,24 +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. -** DOING [#A] Velox reinstall — DR test of archangel + archsetup :velox:chore: -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:working/velox-reinstall/velox-reinstall-runbook.org][working/velox-reinstall/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). ** TODO [#B] Truenas session-host VM for long-running agent sessions :feature:tooling: :PROPERTIES: :CREATED: [2026-08-13 Thu] @@ -747,6 +732,14 @@ So the checklist wants two columns, not one. Graded [#A] because item 5 is live right now and silently disables paging, and because the flight is Sunday. + +*** 2026-09-13 Sun @ 07:14:54 -0500 Moved the three gap reports into the reinstall working dir +The 2026-08-14 reports that define the five gaps moved out of inbox/ into +[[file:docs/design/2026-08-14-velox-reinstall-gaps-1.org][gaps 1-4]], +[[file:docs/design/2026-08-14-velox-reinstall-gaps-2.org][gap 5]] and +[[file:docs/design/2026-08-14-velox-reinstall-gaps-3.org][the two email-side gaps]] (the Bridge cert and the Bridge password). +They file with the rest of the reinstall artifacts when that task closes. + ** TODO [#B] Restoring a git repo from backup can resurrect a dangerous diff :bug: :PROPERTIES: :CREATED: [2026-08-14 Fri] @@ -806,30 +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]. -** TODO [#B] Land the rescued emacs-wttrin commit :chore:velox: -: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: -[[file:working/velox-reinstall/wttrin-bf0457f.bundle][working/velox-reinstall/wttrin-bf0457f.bundle]] -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/velox-reinstall/wttrin-bf0457f.bundle= 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, and it also -pins the working directory open — the reinstall task cannot file its artifacts -away while this bundle is still load-bearing. ** TODO [#B] archsetup doesn't clone rulesets :bug:velox: DEADLINE: <2026-08-15 Sat> :PROPERTIES: @@ -1280,6 +1249,12 @@ split zroot/var/log and zroot/var/lib/pacman out as configure_zfs_snapshots assumes, or change the config to match the layout velox actually has. That is a call I have not made, so the task stays [#B] and not solo. +*** 2026-09-13 Sun @ 07:14:54 -0500 Filed the original boot-failure handoff under docs/design +The 2026-07-15 diagnosis and recovery plan that opened this task sat in +inbox/ as a processed file; it now lives at +[[file:docs/design/2026-07-15-velox-boot-failure-handoff.org][docs/design/2026-07-15-velox-boot-failure-handoff.org]] +so the timeline survives the inbox sweep. + ** TODO [#C] Assess a Hyprland left-drag window gesture :feature:hyprland: :PROPERTIES: :LAST_REVIEWED: 2026-08-26 @@ -1615,6 +1590,14 @@ Restyle the audio panel's GTK CSS onto =tokens-waybar.css= + the banked composit After ~5 hand ports, weigh widget-level codegen with evidence (mechanical duplication vs judgment per port). Recorded as a dated decision in the spec; go spawns its own spec. *** TODO Flip the spec to IMPLEMENTED When the phases above close: status heading keyword → =IMPLEMENTED=, dated history line with the reason, Metadata =Status= mirror. Three lines, one file. + +*** 2026-09-13 Sun @ 07:21:18 -0500 Filed the two Maeda applets into the clock display references +The Line (C2, 1997) and Cosmos (C1, 1995) standalone applets sent from the +website project on 2026-07-30 sat in inbox/ as processed files; they and +their notes now live beside the other references as +=2026-07-30-maeda-{line,cosmos}-standalone.html= and =-notes.org=. +Reference only, regenerate rather than edit. + ** TODO [#B] Net doctor expansion v1 — VM live verification :feature:dotfiles:network:solo: :PROPERTIES: :SPEC_ID: ce29b103-ed9d-4f56-bf8c-9ed8fe680ff3 @@ -2312,38 +2295,10 @@ fi Expected: "stays gone". If it regenerates, Hyprland is still resolving its config to the .conf path and the port is not actually live — stop and investigate. -*** Lock screen after a real sleep: is the clock frozen, or is all of hyprlock frozen? -What we're verifying: which of two very different faults produces the stale -lock-screen clock Craig sees after waking the machine. Three isolated tests on -2026-08-24 all failed to reproduce it — hyprlock v0.9.6 repainted correctly -within one second of a display power-cycle, of a three-minute SIGSTOP, and of -both together with the =path = screenshot= background. So the cause needs a real -suspend on real AMD hardware, which only Craig can run. - -The distinguishing question is whether *anything* on the lock screen is alive. -A frozen clock with live input is a rendering bug in the clock. A frozen clock -with dead input means hyprlock is hung and the compositor is simply holding its -last pre-suspend frame — a different bug, in the crash/hang recovery layer. - -Run this the next time the machine has actually slept (30 min idle, or a lid -close), not on a screen you just locked by hand. - -- Wake the machine and do NOT type your password yet. -- Read the clock. Note the time it shows and the real time. -- Type one character into the password field. -Expected (record which): either the dots appear normally — input is alive, only -the clock is stale — or nothing appears at all, in which case hyprlock is hung. -- Keep watching for a full 90 seconds without touching anything else. -Expected (record which): the clock corrects itself to the current time within a -minute, or it never changes at all. -- Note whether the blurred background looks like your desktop or like a - previous lock screen (a lock screen photographed behind a lock screen means a - second hyprlock was started on top of the first). - -Expected: enough to pick one of three — stale-then-corrects (a repaint-interval -fix), frozen-with-live-input (a rendering fix), or frozen-with-dead-input -(hyprlock hung; the =screen-lock= watchdog only catches a hyprlock that -*exits*, and its own header says it is blind to one that hangs). +*** 2026-09-13 Sun @ 07:57:32 -0500 Retired the lock-screen clock check: fixed, per Craig +Craig reported on 2026-09-13 Sun that the stale clock after a real sleep no longer +happens on velox, so the three-outcome check never needed running. The +parent bug task is closed with the same note. *** Lock keybind has no crash or hang recovery What we're verifying: that a hand-lock is as recoverable as an idle lock. @@ -3596,7 +3551,7 @@ than it looked when it was filed sight-unseen; still worth doing (unlisted fixes happen, and ACPI tables change), just no longer the front-runner. Deliberately deferred past the flight — a cleared NVRAM is the failure that started this whole rebuild. Boot-entry recovery reference captured at -[[file:working/velox-reinstall/velox-uefi-boot-entry-reference.org][working/velox-reinstall/velox-uefi-boot-entry-reference.org]]. +[[file:docs/2026-08-15-velox-uefi-boot-entry-reference.org][docs/2026-08-15-velox-uefi-boot-entry-reference.org]]. Order of attack on return, cheapest first: reseat the touchpad's *own* press connector at the mainboard (free, untried) → BIOS 04.02 → fit the replacement @@ -3649,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: @@ -4338,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. |