Install menu offers x86_64-only packages on aarch64: every entry fails with target not found in a floating terminal that closes #8645

Summary

Omarchy's install paths name packages that only exist for x86_64, and nothing in
the tree checks the running architecture, so on aarch64 the Install menu offers
entries that can never succeed. Each one fails in a floating terminal that prints
error: target not found: <pkg> and closes, usually faster than it can be read.

System details

• Omarchy 4.0.0.alpha (from /usr/share/omarchy/version)
• Arch Linux ARM, uname -m = aarch64, kernel 7.2.0-2-aarch64-ARCH (not Asahi)
• QEMU/UTM guest on an Apple Silicon host (product_name = QEMU Virtual Machine,
  /proc/device-tree/compatible empty)
• pacman repositories configured: core, extra, alarm, aur

Mechanism

Three pieces combine:

1. bin/omarchy-pkg-add is pacman-only. It runs
   sudo pacman -S --noconfirm --needed "$@" and never touches the AUR
   (bin/omarchy-pkg-aur-add is the separate yay path). Any name that is not in a
   configured sync repository fails outright.
2. bin/omarchy-install-app hides the failure. It wraps omarchy-pkg-add in
   omarchy-launch-floating-terminal-with-presentation, so the pacman error appears
   in a transient floating window and disappears. The same is true of every
   omarchy-launch-floating-terminal-with-presentation omarchy-install-* menu action.
3. Nothing anywhere checks the architecture. In 4.0.0.alpha,
   grep -rIn 'x86_64\|aarch64\|uname -m\|arm64\|HOSTTYPE\|MACHTYPE' bin default install config etc shell
   returns no hits. The omarchy-hw-* predicate family covers CPU vendor, GPU,
   chassis and peripherals, but has no architecture predicate, so no menu entry can
   currently gate on one.

The [omarchy] repository compounds this. default/pacman/pacman-stable.conf points
it at https://pkgs.omarchy.org/stable/$arch, and that tree is x86_64-only:

$ curl -o /dev/null -w '%{http_code}\n' https://pkgs.omarchy.org/stable/x86_64/omarchy.db
200
$ curl -o /dev/null -w '%{http_code}\n' https://pkgs.omarchy.org/stable/aarch64/omarchy.db
404

Most of the AUR-derived apps in the Install menu resolve out of [omarchy] on x86_64
(1password, cursor-bin, dropbox, lmstudio-bin, once-bin,
openai-codex-desktop, spotify, sublime-text-4, symfony-cli,
visual-studio-code-bin, voxtype-bin, … — 202 packages in the x86_64 database), so
on aarch64 they have no source at all through the pacman-only path.

Reachable entries whose package cannot exist on aarch64

Every row below is offered from Menu → Install with no hardware or architecture
gate. Their only disabled predicate is omarchy-pkg-present <pkg>, which is false on
a machine where the package could never have installed — so the entry renders enabled.
arch= values are from the authoritative PKGBUILD at
https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=<pkg>; "not in any repo" was
checked with pacman -Si against core/extra/alarm/aur.

Reachable entries whose package could work on aarch64

These are a milder case of the same mechanism: the upstream PKGBUILD does list
aarch64, but the package lives only in the AUR and in [omarchy], and
omarchy-pkg-add is pacman-only while pkgs.omarchy.org has no aarch64 tree. So they
fail too, even though nothing about them is architecture-bound.

What is not affected

For completeness, I traced every x86-only package name in bin/, install/ and
default/ and confirmed the following are correctly gated behind an omarchy-hw-*
predicate or a hardware-detection guard, so they never run on ARM and are not part
of this report: intel-lpmd, thermald, intel-media-driver, libvpl, vpl-gpu-rt,
libva-intel-driver, intel-ipu7-camera, linux-ptl, linux-ptl-headers,
sof-firmware, asusctl, supergfxctl (when: omarchy-hw-hybrid-gpu),
broadcom-wl, macbook12-spi-driver-dkms, dell-xps-touchpad-haptics,
dell-xps13-sidecar-amps, qmk-hid, tuxedo-drivers-nocompatcheck-dkms,
yt6801-dkms, linux-firmware-marvell, the nvidia.sh kernel/driver set, and the
ollama-cuda / ollama-rocm branches of install.ai.ollama (guarded by
omarchy-cmd-present nvidia-smi / rocminfo).

I also deliberately left the gaming entries (install.gaming.steam,
.lutris, .heroic) out of the tables. They are ungated and they do fail
(steam is multilib-only, wine-staging is arch=('x86_64' 'i686'),
heroic-games-launcher-bin is arch=('x86_64')), but the whole stack is x86-bound by
nature and arguably belongs to a different discussion.

One adjacent case I could not classify cleanly and am flagging as unverified:
install.gaming.xbox-controllers runs omarchy-pkg-add linux-headers xpadneo-dkms.
xpadneo-dkms is arch=(any), but linux-headers does not exist under that name on
ALARM (linux-aarch64-headers) or Asahi (linux-asahi-headers). That is a kernel
package-naming assumption rather than an architecture one, and several
hardware-gated scripts share it.

How this differs from the existing reports

• Dictation installer offers x86-only voxtype-bin on Apple Silicon, making Voxtype uninstallable #8530 and PR Offer a source-build fallback when Voxtype's binary needs AVX2 #8316 address the Voxtype install path specifically, and Offer a source-build fallback when Voxtype's binary needs AVX2 #8316
  is the right shape for it — a source-build fallback gated on the new
  omarchy-hw-x86-64-v3 predicate. But that fix is local to
  bin/omarchy-voxtype-install; the same class of failure remains in every other
  ungated Install entry above.
• Dictation installer offers AVX2-only Voxtype on CPUs without AVX2 #7883 and PR Skip Claude and Pi on CPUs without SSE4.2/POPCNT #8149 cover the related AVX2/SSE4.2 baseline problem within
  x86_64.
• PR Guard three x86-only assumptions so Omarchy can install on aarch64 #8039 covers the aarch64 install-time path (mkinitcpio thunderbolt,
  [multilib] in pacman.conf, mise-work) and notes the pkgs.omarchy.org aarch64
  gap as out of scope. This issue is about the post-install, user-facing menu.
• ERROR: 1password-beta is not available for 'aarch64' arch #87 (closed) and om-arm-archy ? #803 (closed) are much older and predate the current menu.

I did not find an open report covering the general case.

Suggested direction

Offered as options, not a prescription:

1. A preflight in omarchy-pkg-add. Before shelling out to pacman, check that each
   name resolves for the running architecture and, when it does not, fail with a
   message that says so — instead of letting error: target not found scroll past in a
   window that closes. This would cover every call site at once, including the ones
   reached from scripts rather than the menu.
2. disabled predicates on the menu entries whose package cannot exist on the
   running architecture, so the entry is greyed out rather than offered. PR Offer a source-build fallback when Voxtype's binary needs AVX2 #8316's
   bin/omarchy-hw-x86-64-v3 already returns false for any non-x86_64 machine
   ([[ $machine == "x86_64" ]] || exit 1 before the flag checks), so it could serve as
   that gate directly, or a narrower omarchy-hw-x86-64 predicate could be split out of
   it.
3. Publishing an aarch64 tree on pkgs.omarchy.org would independently fix the
   second table, since those packages already build for ARM.

(1) and (2) are complementary: (2) keeps the dead entries out of the user's way, (1)
catches the script-level call sites and gives a readable error when a package is missing
for any other reason.

Happy to open a PR for whichever of these you'd prefer — the omarchy-hw-x86-64
predicate plus disabled gates is the smallest change, and the omarchy-pkg-add
preflight is the one that covers the most ground.