Re-apply hardware pacman repos after a refresh restore

[hudsonwa]

Fixes #9853

What broke

omarchy refresh pacman overwrites /etc/pacman.conf with the channel template and never re-applies hardware-specific repository additions. On Apple T2 Macs that silently drops the [arch-mact2] stanza, so linux-t2 (the running kernel), t2fanrd, apple-t2-audio-config and apple-bcm-firmware lose their update source with no visible symptom.

The install path does this correctly: install/post-install/pacman.sh sources install/hardware/pacman.sh, which appends the T2 stanza and is idempotent (it guards on grep -q '^\[arch-mact2\]'). That same file states the intent in its own comment: the extension "must survive the final pacman.conf restore". The refresh path never copies it.

Fix

After the template restore, source $OMARCHY_PATH/install/hardware/pacman.sh the same way the install path does:

if [[ -f $OMARCHY_PATH/install/hardware/pacman.sh ]]; then
  sudo bash -c "source '$OMARCHY_PATH/install/hardware/pacman.sh'"
fi

Notes on why this shape:

• The issue's suggested source "$OMARCHY_INSTALL/hardware/pacman.sh" cannot work in bin/omarchy-refresh-pacman: $OMARCHY_INSTALL is not defined at runtime (only omarchy-apply-hardware/omarchy-apply-system set it). At runtime the tree lives at $OMARCHY_PATH/install/ (docs/file-layout.md maps install/** to /usr/share/omarchy/install/).
• The file appends to /etc/pacman.conf, so it must run as root; the copy steps just above already use sudo, so the script runs as the user and elevates.
• Placed before the pre-refresh-pacman user hook, matching the issue's ordering, so user hooks see the final repo set.
• The [[ -f ]] guard keeps the refresh a no-op on anything where the install tree is absent, and if install/hardware/pacman.sh is ever removed the refresh simply skips it.

Security context

install/hardware/pacman.sh is also in the sights of open security PRs #8709 (arms verification on the T2 stanza) and #9461 (draft: remove the unsigned source). This PR deliberately does not take a side: it sources whatever the packaged file contains at runtime, so if #8709 lands the refresh re-applies the armed stanza, and if a removal lands the -f guard no-ops. Only the "refresh drops hardware repos" bug is fixed here.

Tests

New test/shell.d/refresh-pacman-test.sh runs the command against a sandboxed /etc/pacman.conf (absolute paths rewritten) with stubbed lspci/sudo/pacman/omarchy-hook:

• T2 (lspci shows 106b:1801): [arch-mact2] with the mirror server is present after the refresh, the user hook still runs, and pacman -Syyuu still runs.
• Second run: the stanza is not duplicated.
• Non-T2: nothing is added.

All four assertions pass here, and the test fails against the pre-fix command (RED → GREEN). Honest host note: this is an Apple Silicon macOS machine with no bash 4+ and no Wayland, so the repo's full ./test/shell cannot complete here (${var,,}-style and compositor tests are environment-bound); the new test is bash-3.2 compatible and was run directly, and it never touches the real /etc/pacman.conf. Real-T2 end-to-end validation (an actual omarchy refresh pacman on a T2 Mac) remains for someone with that hardware.

One scope note: a migration that repairs already-upgraded machines was intentionally left out — I did not want to guess at maintainer preferences on machine-wide repairs, and the refresh fix covers every future refresh. Happy to add one if you want it.

[omarchybot]

Reviewed by Claude Opus 5 in Claude Code, with a second opinion from Codex (gpt-5.6-sol) at xhigh reasoning. Everything executable ran on a disposable Omarchy 4.0.0 VM, never against this machine's own /etc/pacman.conf.

The fix is correct and I pushed nothing. The two properties worth checking hardest both hold.

Idempotence. The append cannot duplicate the stanza, because the template cp on line 19 lands first and install/hardware/pacman.sh guards on grep -q '^\[arch-mact2\]' against the file it has just rewritten. Verified end to end on the worker with a stubbed lspci reporting 106b:1801 and a stubbed pacman: five consecutive omarchy-refresh-pacman stable runs against the VM's real /etc/pacman.conf leave exactly one [arch-mact2]. This matters more than it looks — a duplicate does not fail the parse, pacman prints error: could not register 'arch-mact2' database (database already registered) and quietly uses the first, which is how a later ordering change becomes ineffective with no symptom. It does not happen here.

Ordering. The stanza lands at EOF, after [omarchy]; on the edge template that is after the commented-out [*-debug] block, and it still parses and registers there. Open PR #7583 ("Order the Omarchy repository above Arch's") touches only default/pacman/pacman-*.conf and its own migration, so there is no textual conflict with this PR and no ordering interaction either way: [arch-mact2] stays last, and its packages (linux-t2, t2fanrd, apple-t2-audio-config, apple-bcm-firmware) have no Arch counterpart that could shadow them. Non-T2 was checked with the real lspci on non-Apple hardware: nothing is appended.

Tests, all on the worker: ./test/cli green. ./test/shell green on 225 of 227 files; the two failures are ascii-test.sh (a figlet column-width assertion) and branding-about-animation-test.sh, both environment-bound and reading nothing this PR touches. Your test/shell.d/refresh-pacman-test.sh is not vacuous — with the eight added lines removed from bin/omarchy-refresh-pacman it fails at the first assertion, and passes with them.

Two things for the maintainer rather than defects in the diff:

1. omarchy update never runs this command, so already-stripped machines stay stripped. The only callers of omarchy-refresh-pacman are bin/omarchy-channel-set:86 and bin/omarchy-reinstall-pkgs:11; bin/omarchy-update goes omarchy-update-system-pkgs → omarchy-migrate and never touches it. You said this in the PR body and leaving the repair migration to the maintainer is the right call, especially with #8709 and #9461 both arguing about whether that repository should exist at all. It does mean the Fixes #9853 keyword will auto-close an issue whose reporter's machine is still orphaned until they type omarchy refresh pacman by hand.

2. A non-zero exit from the sourced script is swallowed. omarchy-refresh-pacman has no set -e and line 27's status is unchecked, so if the re-apply ever fails the refresh prints nothing, returns 0, and runs pacman -Syyuu with the repository absent — the exact silent failure #9853 is about. It cannot happen against today's install/hardware/pacman.sh, which is why I did not push a change. It can happen the moment #8709 lands: that PR gives the file an exit 1 when the pinned t2linux key cannot be imported from keyserver.ubuntu.com, and its elif ! grep -q '^\[arch-mact2\]' branch is the one this call site always takes, since the cp just removed the stanza. Reproduced on the worker with a stand-in script that exits 1 — refresh exited 0, [arch-mact2] absent, pacman -Syyuu ran anyway. If #8709 lands, line 27 wants a || echo at minimum; and #8709's side should know that this call site would put a keyserver fetch in every refresh on a T2 Mac.

One more, confirmed on the worker: a user who applied the workaround #9853 suggests — a pre-refresh-pacman.d hook that re-adds the stanza — ends up with two copies once this lands, because the hook runs after the new append. Nothing this PR can fix, but a release-note line would save those users a puzzling pacman error.

On the second opinion: most of what Codex returned was in answer to questions I put to it, so read it as agreement rather than independent discovery, and its independence is not currently guaranteed in this setup. What it added on its own: that a checkout path containing an apostrophe would break the bash -c string on line 27 (true, and not worth a commit — omarchy-refresh-pacman has no NOPASSWD sudoers entry, so no privilege boundary is crossed), and a concurrency variant of the duplicate finding, which I rejected: two simultaneous omarchy refresh pacman runs is not a real scenario.

Nothing pushed to your branch. Waiting on the maintainer for the repair-migration question and for how this sequences against #8709 and #9461.

[hudsonwa]

Thanks for the worker verification, it is exactly the scrutiny this needed. I took the exit-status point further: since the whole bug class here is silent failure, a failed re-apply now aborts the refresh before the upgrade instead of only echoing. The command has no set -e, so the step is checked explicitly; test/shell.d/refresh-pacman-test.sh gained a failing-hardware-script case that fails on the unchecked version and passes now. The repair-migration question I am leaving to the maintainer as agreed: a migration that re-adds the unsigned stanza would collide with #8709 and #9461, so I did not touch it. The pre-refresh-pacman double-append note is worth a release line.