diff options
Diffstat (limited to 'todo.org')
| -rw-r--r-- | todo.org | 82 |
1 files changed, 36 insertions, 46 deletions
@@ -223,8 +223,8 @@ 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> +** 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 @@ -248,6 +248,13 @@ 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] @@ -495,8 +502,8 @@ 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> +** 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 @@ -504,7 +511,7 @@ DEADLINE: <2026-08-15 Sat> 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]] +[[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 @@ -526,6 +533,17 @@ 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] @@ -791,9 +809,9 @@ 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:working/velox-reinstall/2026-08-14-emacsd-velox-reinstall-gaps-1.org][gaps 1-4]], -[[file:working/velox-reinstall/2026-08-14-emacsd-velox-reinstall-gaps-2.org][gap 5]] and -[[file:working/velox-reinstall/2026-08-14-emacsd-velox-reinstall-gaps-3.org][the two email-side gaps]] (the Bridge cert and the Bridge password). +[[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: @@ -864,7 +882,7 @@ 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]] +[[file:working/emacs-wttrin-rescue/wttrin-bf0457f.bundle][working/emacs-wttrin-rescue/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. @@ -874,11 +892,11 @@ 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 +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, and it also -pins the working directory open — the reinstall task cannot file its artifacts -away while this bundle is still load-bearing. +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. ** TODO [#B] archsetup doesn't clone rulesets :bug:velox: DEADLINE: <2026-08-15 Sat> :PROPERTIES: @@ -2375,38 +2393,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. @@ -3659,7 +3649,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 |