Add omarchy-quake (Quake 1: vkQuake, Omarchy panel, Tailscale deathmatch)

[ryrobes]

Adds omarchy-quake: Quake 1 for Omarchy — vkQuake 1.35 (Vulkan, SDL3, native Wayland, Hyprland friendly) wrapped in an omarchy-quake launcher, a Quickshell panel plugin, and Hyprland window rules. First launch downloads the official shareware (~18MB); existing Steam/GOG PAKs and the 2021 re-release are auto-discovered. Deathmatch over Tailscale or LAN: hosting copies a one-line join command for the other machine.

Build notes:

• Two pinned GitHub tarballs (launcher tree + vkQuake 1.35.0), no git clone during build.
• Four small engine patches (NVIDIA Wayland quit crash, rcon fixes for the panel's map switching) applied with patch(1) and sentinel-checked.
• package() writes nothing to $HOME. The shell plugin ships as files under /usr/share/omarchy-quake/plugin/; the basecamp/omarchy install stub (companion PR) copies and enables it after pacman.
• MIT (launcher/plugin) + GPLv2 (vkQuake), both in /usr/share/licenses/omarchy-quake/.
• x86_64 only for now; software rendering falls back to lavapipe via vulkan-swrast (optdepend).

Tested: makepkg from these exact sources, then pacman -U + plugin enable + play (single player and Tailscale deathmatch between two machines) on stock Omarchy 4. Fine to leave off the fast ring until it has soaked on edge.

Companion PR (menu stub + on-demand installer): omacom/omarchy#7570

preview-gh.mp4

[greptile-apps]

Greptile Summary

Adds a locally maintained package for vkQuake with Omarchy desktop integration.

• Defines pinned launcher and vkQuake source archives with SHA-256 checksums.
• Builds and installs the engine through the launcher project's scripts.
• Registers the package as a local catalog entry.

Confidence Score: 4/5

The PR should not merge until the package stops advertising the unsupported aarch64 build target.

The current recipe still includes aarch64 in its architecture array despite the stated x86_64-only support scope, so repository automation can select an unsupported target.

Files Needing Attention: pkgbuilds/omarchy-quake/PKGBUILD

Important Files Changed

Filename	Overview
pkgbuilds/omarchy-quake/PKGBUILD	Adds the complete build and packaging recipe; its architecture declaration remains inconsistent with the package's stated support scope.
pkgbuilds/omarchy-quake/.omarchy/package.json	Registers omarchy-quake as a locally maintained catalog package.

_{Reviews (2): Last reviewed commit: "Declare opusfile so the Opus codec is bu..." | Re-trigger Greptile}

[greptile-apps]

Align the advertised architectures

The arch array schedules this package for the repository's aarch64 build target, while the submitted support scope says it is x86_64-only. Advertising only the architecture actually supported avoids publishing an unverified ARM package.

Suggested change

	arch=('x86_64' 'aarch64')
	arch=('x86_64')

[omarchybot]

Re-reviewed at c73234f (1.6.3 + aarch64). Two of the findings from the last pass are resolved, one I fixed and pushed — your branch is now at 66c59ac.

The unverified shareware download is fixed, and I checked it against the real mirrors rather than reading the code. 1.6.3 adds QO_SHAREWARE_SHA256 and rejects any candidate that does not match, falling through to the next mirror. On a disposable VM I fetched quake106.zip from the QO_SHAREWARE_URLS list, including the raw.githubusercontent.com one on a moving main branch: they serve byte-identical 9,094,045-byte archives hashing to exactly the pinned value, so the mirror that worried me most is now bounded by the pin rather than trusted. I then ran the real qo_fetch_shareware end to end in a clean container with only the declared dependencies (bsdtar, no 7zip): it downloads, verifies, unpacks RESOURCE.1, and installs pak0.pak plus the 10,036-byte SLICNSE.TXT, exit 0. The new mandatory license file does not break first run.

One limit worth knowing: the pin protects the download, not a directory that already looks installed. qo_fetch_shareware returns early when pak0.pak and a non-empty SLICNSE.TXT are both already present, so a managed shareware directory that arrived some other way is never hashed.

opusfile was still undeclared, and I pushed the one-line fix (66c59ac). I built the package in a clean archlinux:base-devel container to check this from the artifact rather than from the recipe: makepkg -s installed every declared dependency and meson still reported Run-time dependency opusfile found: NO, and the packaged engine linked libmpg123, libFLAC and libvorbisfile with no Opus at all. vkQuake compiles snd_opus.c only when both opus and opusfile are found, and use_codec_opus defaults to auto, so the codec was dropped silently and the opus entry in depends bought nothing. With opusfile declared, the same clean build links libopusfile.so.0. Both source checksums validated (Passed) on every build, so the 1.6.3 tarball hash is correct.

package() still inherits the builder's environment. I demonstrated it rather than inferring it: INSTALL_USER_INTEGRATION=1 makepkg -R -f wrote about twenty files into the builder's real $HOME during package() — ~/.config/omarchy/plugins/quake.omarchy/, ~/.config/hypr/apps/quake-omarchy.lua, ~/.local/share/quake-omarchy/ — and QO_ENGINE=/tmp/fake-engine makepkg -R -f packaged that shell script as /usr/lib/omarchy-quake/vkquake. It stays low severity because the repository's own build path cannot reach it: bin/build forwards only ARCH, MIRROR and PACKAGES into the build container and the image adds only LANG and PATH, so even the credentials the release unit sources never become makepkg's environment. Adding INSTALL_USER_INTEGRATION=0 QO_ENGINE= to the install.sh line closes both — I confirmed that it does, and left it to you rather than pushing it, since it is hardening on a path only a manual builder reaches.

New, low: a shareware install made by a pre-1.6.3 build has no SLICNSE.TXT, and qo_ensure_data now sends it through a fresh download before it can be played. Offline that is a hard qo_die even though the working PAK is still sitting there, and on edition=auto a user who also owns the 2021 re-release does not fall back to it, because qo_pick_basedir prefers managed shareware over re-release. Small population, since this package has not shipped.

aarch64 is declared but, as far as anything here shows, never built. I could not settle it: the worker is x86_64 and emulated ARM compilation of vkQuake was not worth the hour. Nothing architecture-specific turned up — vkQuake 1.35's x86 library paths are confined to Windows branches, mathlib.h carries NEON paths, and build-engine.sh is plain meson/ninja — so it will probably build, but "probably" is doing the work. Note that bin/build --arch aarch64 already sets up QEMU and builds ARM today; that does not wait on #171, which adds native runners rather than the capability. If an ARM build does fail, build/build.sh collects it and exits non-zero for the whole batch. If you have run one, saying so here would close this.

Separately, the PR body still says "x86_64 only for now", which is what led the greptile comment to read the arch array as the mistake. That has it backwards — the newest commit deliberately enabled aarch64, so the body is the stale part — but updating the body would stop the next reader tripping over it.

Two items for the maintainer rather than for you, unchanged from the last pass and both product decisions rather than defects: while hosting, the engine on UDP 26000 and beacon.py serve on 0.0.0.0:26001 listen on all interfaces rather than only the tailnet, and the beacon answers any PING with the machine's hostname, IP, join command, map and mode; and 0002-register-rcon-password.patch enables vkQuake's rcon path so the panel can switch maps, with the generated password passed as a command-line argument and therefore readable in /proc/<pid>/cmdline by any local user.

Reviewed by Opus 5 in Claude Code and by Codex at xhigh reasoning. Codex read the same head and agreed on the opusfile mechanism, on the low rating for the environment inheritance, and that the greptile comment's reasoning is stale — though it was pointed at each of those by my prompt, and its independence is not guaranteed, since it runs as the same user and can read this session's own files. Three things it contributed that I had not reasoned about: that ARM is buildable today rather than only after #171, the qo_pick_basedir ordering that makes the offline case worse, and the early-return path that bypasses hash verification.