GENERIC_X64 / VM (QEMU+VirtualBox) build for local QA — clean up & land x64-build-fix

[maxengel]

Goal

A GENERIC_X64 build that boots in a VM (QEMU + VirtualBox) so contributors can QA
features (e.g. the native EmulationStation work, #15, and cloud-sync) in a VM instead of
flashing to a device. A true x86_64 hardware build is a nice-to-have, not the priority.

Status — most of the work already exists (but is stale)

On origin/x64-build-fix:

• Boots GENERIC_X64 on QEMU and VirtualBox (commit ce40175c96 "first booting build…"),
  plus installer support (dbacdefbb2), DMI/quirks, systemd/mesa/llvm/qt6/dbus fixes, and
  QEMU/VirtualBox test scripts.
• Planning lives in plans/x64_build_target/ (x64_build_target_plan.md + _checklist.md).

Staleness / footprint:

• Branch tip 2025-10-22; merge-base with upstream/next is 2025-08-18.
• upstream/next is ~2,465 commits ahead of that merge-base.
• ~108 substantive files changed (the rest is qemu-*.log, test_*.sh, CLAUDE.md,
  and old shared-copilot-knowledge churn — all noise to drop).

Proposed approach

Re-derive (don't straight-rebase) onto a fresh feature/generic-x64 off current next:

1. Validate the existing branch still builds + boots in QEMU as a baseline (Docker:
   make docker-GENERIC_X64).
2. Port the ~108 substantive changes group-by-group (device options, scripts/mkimage/
   image/build_distro, package.mk fixes), dropping logs/test-script noise.
3. Add a short contributor doc: "build + boot ROCKNIX in QEMU/VirtualBox for QA".
4. Validate other arches (aarch64) still build (no regressions), then open an upstream PR.

Host is build-ready (Docker 29.6.1, ~800 GB free).

Open question

When to do this — it's a multi-hour-build, multi-day spike. Likely best timed as the
QA-enabling precursor to the ES native work (#15). Tracking here; timing TBD.

[maxengel]

Spike progress — re-derivation is working

Branch: origin/feature/generic-x64 (5 clean commits, re-derived onto current next).
Build reaches ~355–430 / 655 packages (varies by parallel ordering); foundation validated
through the x86_64 kernel.

Reactive fixes so far (all in-pattern, not the stale branch's hacks):

1. Restore intel-ucode package (x86_64 linux unpack dep, removed upstream with old x86 device).
2. Seed 15 GENERIC_X64 emulator/app configs from SM8250 (+retroarch x86) — placeholders.
3. gst-plugins-base: fix a real upstream graphene AVX header bug (only fires with __AVX__).
4. rocknix:target: add GENERIC_X64 bootloader/update.sh (syslinux/UEFI).

Current wall — graphics/compute toolchain (llvm ↔ spirv)

llvm:host builds SPIRV-LLVM-Translator (pulled in because GENERIC_X64 is the first ROCKNIX
device to use the iris driver). Translator 20.1.5 references opcodes
(OpSubgroup2DBlockLoadINTEL) missing from next's spirv-headers — a latent version mismatch
no current device exercises. The old branch bypassed llvm by symlinking the container's system
llvm-15, which doesn't apply to current llvm-20.1.8.

Options: (A) align the spirv-headers/tools/translator versions for llvm-20 (keeps full
GL+compute); (B) disable OpenCL/clover (llvm-spirv) for GENERIC_X64 to reach a booting image
faster (keeps OpenGL via iris; drop compute for now); (C) pause. Each needs a few more long
build iterations (llvm/mesa are ~30+ min each).