<feed xmlns='http://www.w3.org/2005/Atom'>
<title>archsetup/working, branch claude/hungry-franklin-09fffc</title>
<subtitle>Builds a full dev workstation from a bare Arch Linux install.
</subtitle>
<id>https://git.cjennings.net/archsetup/atom?h=claude%2Fhungry-franklin-09fffc</id>
<link rel='self' href='https://git.cjennings.net/archsetup/atom?h=claude%2Fhungry-franklin-09fffc'/>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/archsetup/'/>
<updated>2026-10-17T12:07:25+00:00</updated>
<entry>
<title>feat(keyring): ship a patched gnome-keyring and install it from the repo</title>
<updated>2026-10-17T12:07:25+00:00</updated>
<author>
<name>Craig Jennings</name>
<email>c@cjennings.net</email>
</author>
<published>2026-10-17T12:07:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/archsetup/commit/?id=cd6e11b46ecf2b56bf63d6c11886dccc70875e10'/>
<id>urn:sha1:cd6e11b46ecf2b56bf63d6c11886dccc70875e10</id>
<content type='text'>
gnome-keyring 48 through 51.1 aborts when a client's first OpenSession is dispatched before the daemon has created its per-client record. Each abort drops the unlocked state and the next request pops the password dialog. On ratio that happened about three times a day from 2026-10-11, when the ChatGPT desktop app's codex app-server started bursting keyring reads. The same-day glib and keyring upgrades were a coincidence, since 50.0 reproduces it too. Upstream's fix (merge request !112) has sat unmerged since August.

packages/gnome-keyring is Arch's recipe for 1:51.1-1 built from GNOME's tarball plus one patch. It registers the client at the point of use and returns a real D-Bus error instead of completing OpenSession with a NULL body. It resolves a collection alias only after the caller's session exists. It also locks the alias table so the worker-thread filter can't read an entry the main thread is freeing, a pre-existing defect that AddressSanitizer confirmed. I chose pkgrel 1.1 so stock sorts below the rebuild and any future Arch or upstream fix replaces it on a normal upgrade. Nothing pins the package.

install_gnome_keyring_fix replaces the plain stock install, which pacman's --needed would otherwise use to downgrade the rebuild on every re-run. It installs stock only when no gnome-keyring is present, compares versions with vercmp, then stages the recipe into the source dir and builds it with makepkg as the user. The rebuild is a no-op, anything newer skips with a visible note, and a failed build leaves stock in place. I also corrected the keyring-dir comment: the default alias only picks the collection and doesn't unlock anything under autologin.

working/keyring-crash holds the probe, the guest fixture and runners, and the deployment script with backup and rollback. status.org there records the cause and results. Stock aborts on the probe's first batch. The patched daemon, its sanitizer build and the installed package pass every mode, and the upstream suite scores the same for both.
</content>
</entry>
<entry>
<title>chore: stage the meeting transcription service for an install home</title>
<updated>2026-09-25T17:05:42+00:00</updated>
<author>
<name>Craig Jennings</name>
<email>c@cjennings.net</email>
</author>
<published>2026-09-25T17:05:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/archsetup/commit/?id=767b84e2675e7074408a81257a5ec6d0dd410c4d'/>
<id>urn:sha1:767b84e2675e7074408a81257a5ec6d0dd410c4d</id>
<content type='text'>
This is a self-hosted transcription service: whisper.cpp for the words, pyannote for the speaker labels. It has been running on ratio since 2026-09-17, with velox as the offline fallback. A systemd path unit watches a filesystem queue and starts a oneshot worker per job. There is no network listener. ssh is the transport, systemd is the daemon, and the filesystem is the queue.

It lands in working/ rather than its final home because two decisions come first. I haven't picked where the code lives in this repo. The Hugging Face token the diarization model needs on its first download also has to be handled, since anyone can read this repo.

Neither blocks the service, which already runs. Both block the install path this repo owes it.

The accompanying note lists what each machine needs. The torch venv is 1.3 GB and the whisper model is a separate download, so the note describes both rather than carrying them here.
</content>
</entry>
<entry>
<title>chore(tasks): close the rescued emacs-wttrin commit</title>
<updated>2026-09-13T14:55:55+00:00</updated>
<author>
<name>Craig Jennings</name>
<email>c@cjennings.net</email>
</author>
<published>2026-09-13T14:55:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/archsetup/commit/?id=0c28aa32f6bc97228ce722e7f6e18c90e2dc23b7'/>
<id>urn:sha1:0c28aa32f6bc97228ce722e7f6e18c90e2dc23b7</id>
<content type='text'>
The commit that existed only on velox's old disk is now on emacs-wttrin's release/0.4.0, with fixes for the two bugs it carried. The bundle's other heads were already on the remote, and the landed patch matches the rescued one. I deleted the bundle and its working dir.
</content>
</entry>
<entry>
<title>chore(tasks): close the velox reinstall drill and the lock-clock bug</title>
<updated>2026-09-13T14:23:39+00:00</updated>
<author>
<name>Craig Jennings</name>
<email>c@cjennings.net</email>
</author>
<published>2026-09-13T14:23:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/archsetup/commit/?id=0e85fe37d4680492a6455672835cdd65901ad22c'/>
<id>urn:sha1:0e85fe37d4680492a6455672835cdd65901ad22c</id>
<content type='text'>
The reinstall drill finished on 2026-08-14 and every finding it surfaced already has its own task, so what remained was the record. I filed its working-dir artifacts into permanent homes. The runbook went to docs/ with an Outcome section, since the checklist was never ticked as it ran. The UEFI boot-entry reference went to docs/ too. The three reinstall-gap reports went to docs/design/. The rescued wttrin bundle moved into its own working dir under the task that owns it. Every inbound link is repointed and working/velox-reinstall/ is gone.

The lock-screen clock bug is closed because it no longer happens on velox. I couldn't identify the commit that fixed it from the dotfiles or archsetup logs, and the note says so. Its manual-testing check retires with it.
</content>
</entry>
<entry>
<title>chore: file the legacy inbox references and two unfiled captures</title>
<updated>2026-09-13T12:22:10+00:00</updated>
<author>
<name>Craig Jennings</name>
<email>c@cjennings.net</email>
</author>
<published>2026-09-13T12:22:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/archsetup/commit/?id=00c9eb4a4c7c79161dd04219dd6ad97f050f8bdf'/>
<id>urn:sha1:00c9eb4a4c7c79161dd04219dd6ad97f050f8bdf</id>
<content type='text'>
The inbox held 64 processed-but-kept handoffs from July and August. The inbox discipline no longer allows that state: a file is a task, reference content in a tracked home, or gone. I read each one. Fifty-six were acknowledgments, FYIs, lint pipeline files or requests whose work had already landed. Those are deleted.

Eight carried content worth keeping. The 2026-07-15 velox boot-failure diagnosis moves to docs/design, linked from the retrospective task. The three 2026-08-14 reinstall-gap reports move into the velox reinstall working dir, linked from the post-rebuild task. The two Maeda applets and their notes join the clock display references.

Two captures had never landed anywhere: the waybar module separator I captured on 2026-07-20 ([#B]) and the window-configuration research idea from 2026-07-24 ([#C]). Both are filed. The velox reinstall task records the two live steps (wsdd off, passim masked) applied over ssh once velox came back, and the health-check log now says velox is masked.
</content>
</entry>
<entry>
<title>docs(health-check): record the velox 2026-09-12 findings</title>
<updated>2026-09-13T12:02:39+00:00</updated>
<author>
<name>Craig Jennings</name>
<email>c@cjennings.net</email>
</author>
<published>2026-09-13T12:02:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/archsetup/commit/?id=28d576db056d35033061a2db41b7a7ac5ac6a64e'/>
<id>urn:sha1:28d576db056d35033061a2db41b7a7ac5ac6a64e</id>
<content type='text'>
These come from velox's 2026-09-12 health check. The Framework 04.02 BIOS update re-enabled Secure Boot, which rejects the unsigned ZFSBootMenu loader and reads as "no bootable device" while the boot entries are intact. I added a pre-firmware-update checklist to Phase 3 and a check-Secure-Boot-first section to the velox boot-entry reference.

Four Known Issues entries cover the Secure Boot flip, fwupdmgr activating passim, the topgrade containers step failing on local images and the harmless mkinitcpio firmware warnings. Phase 3 also notes why lsinitcpio needs sudo: the images are 0600, so an unprivileged run errors on stderr with an empty stdout, and a piped count reads 0.
</content>
</entry>
<entry>
<title>chore: stage the Hyprland Lua port with its redeploy kit</title>
<updated>2026-08-24T20:27:57+00:00</updated>
<author>
<name>Craig Jennings</name>
<email>c@cjennings.net</email>
</author>
<published>2026-08-24T20:27:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/archsetup/commit/?id=7d20bc89cd2ea92877558b18b4e0ccac6fa17113'/>
<id>urn:sha1:7d20bc89cd2ea92877558b18b4e0ccac6fa17113</id>
<content type='text'>
Hyprland 0.57 drops the .conf format. The port is built and measured identical to the current config in a nested compositor — 38 settings, 103 binds, the host-override chain — but it is not deployed. I put it live this afternoon and took it back out the same hour, because it had not been run on real hardware and the machine has to stay usable until it has.

working/hyprland-lua-port/ carries what the switch needs, including the two reader changes as replayable patches. Those matter more than the config itself: four things read hyprland.conf as a source of truth, and dotfiles-validate globs hypr/*.conf, so with the .conf gone it finds nothing and reports a clean tree.

Two facts not worth re-deriving: with both files present 0.56.2 loads the .lua, so keeping the .conf beside it buys no rollback; and a running compositor rewrites a stub config within a second of the file vanishing, which is what fights a restow.

Also archives finished tasks and folds in several sessions of task-review edits.
</content>
</entry>
<entry>
<title>fix(velox): trace the dead touchpad to its own connector, and repair two lost todo headings</title>
<updated>2026-08-20T16:46:19+00:00</updated>
<author>
<name>Craig Jennings</name>
<email>c@cjennings.net</email>
</author>
<published>2026-08-20T16:46:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/archsetup/commit/?id=fb13378559cdc6a9ef3b23883bcbda2937dc1195'/>
<id>urn:sha1:fb13378559cdc6a9ef3b23883bcbda2937dc1195</id>
<content type='text'>
The touchpad fault was an interrupt line that never fired: the device
enumerated, hid-multitouch bound, and the handler sat correctly on amd_gpio
pin 8, but the count stayed at zero across all 24 CPUs under active use and
the i2c-HID reset timed out at every boot. A live USB reproduced it exactly,
which ruled out software. The fix was the touchpad's own connector — the
input-cover ribbon I reseated first fixed the phantom power button and left
this untouched, and the 4-pin connector beside the silkscreen is GND and VCC
only, so it could never have carried i2c. Both faults from the mainboard swap
are now closed.

Two task headings had been overwritten by inserts at the top of Open Work, and
I recovered both verbatim from the commits that introduced them. One displaced
task had ridden an archived parent into Resolved, so an open bug had been
sitting outside Open Work for weeks.

Filed the install placeholder passwords still live on this laptop as an [#A],
graded on severity alone rather than the frequency matrix: full-disk encryption
protected by a dictionary word does no work at all on a machine that travels.

Corrected the ARCHSETUP_DIR line in the reinstall runbook. It carried a tilde on
the right-hand side of an assignment, which zsh does not expand, so following it
would have produced an ISO with the installer silently absent.
</content>
</entry>
<entry>
<title>chore: rebuild velox and file what the reinstall exposed</title>
<updated>2026-08-14T15:03:26+00:00</updated>
<author>
<name>Craig Jennings</name>
<email>c@cjennings.net</email>
</author>
<published>2026-08-14T15:03:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/archsetup/commit/?id=e8004e3a7416c57661d43e8bfaefb7c77255129e'/>
<id>urn:sha1:e8004e3a7416c57661d43e8bfaefb7c77255129e</id>
<content type='text'>
The mainboard swap left no boot entry, so I reinstalled from the archangel ISO rather than repairing a ZFS-root machine a stock USB can't read. Ran it as a disaster-recovery drill: microcode, keys, repos, and data are back, and hibernate now works end to end on a 100G encrypted swap.

The tasks are most of what this bought. Reseating the input-cover ribbon is [#A] for today, because four phantom power-button presses and the dead touchpad are one loose connector, and the last one cut power below systemd. The rescued emacs-wttrin bundle rides along until it lands on its remote; the runbook stays until velox is settled.
</content>
</entry>
<entry>
<title>chore(todo): velox reinstall runbook and the tasks it surfaced</title>
<updated>2026-08-14T03:35:41+00:00</updated>
<author>
<name>Craig Jennings</name>
<email>c@cjennings.net</email>
</author>
<published>2026-08-14T03:35:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/archsetup/commit/?id=2e78f55638ee80da6ce4998d37996bea73076efa'/>
<id>urn:sha1:2e78f55638ee80da6ce4998d37996bea73076efa</id>
<content type='text'>
The runbook drove today's rebuild: preflight, a required salvage pass, the install, and post-install verification. It stays as the working record until velox is settled.

Filed from the rebuild: reseating the input-cover ribbon, which is [#A] for tomorrow because phantom power-button presses have killed the machine four times and the last one cut power below systemd, where no setting can catch it. The rest are hibernate in the settings dial, a truenas VM for long-running sessions, the keyboard-backlight binding, and the screen-lock suite that fails 21 of 23 on ratio.
</content>
</entry>
</feed>
