Skip to content

spruce: build an arm64 bundle for 64-bit devices - #149

Open
misantronic wants to merge 5 commits into
mainfrom
spruce-arm64-bundle
Open

misantronic wants to merge 5 commits into
mainfrom
spruce-arm64-bundle

Conversation

@misantronic

@misantronic misantronic commented Sep 9, 2026

Copy link
Copy Markdown
Owner

The spruce package only built for armv7, which covers the Miyoo Mini and A30. spruce also runs on aarch64 hardware (Brick, BrickPro, SmartPro, SmartProS, Flip, Pixel2, Zero28, Anbernic), where the armv7 bundle cannot start at all. This adds a second target.

Building

./linux/spruce/fetch_runtime_arm64.sh      # once
./linux/spruce/build_bundle.sh arm64

build_bundle.sh now takes an architecture argument and defaults to armv7, so the existing invocation is unchanged.

armv7 arm64
Runtime CPython 3.9 (Onion's cache) CPython 3.11 (fetch_runtime_arm64.sh)
pygame + SDL2 Onion vendor stack muOS vendor stack (cp311 manylinux)
rchash target arm-linux-gnueabihf.2.17 aarch64-linux-gnu.2.17

Nothing new is introduced: the arm64 target borrows from muOS the way the armv7 target borrows from Onion.

Supporting changes

common.sh had python3.9 hardcoded in the certifi lookup. It now resolves the runtime's own lib/python3.*/site-packages, so both runtimes work from one script.

launch.sh no longer execs the menu. If the menu fails, it runs an SDL probe that tries kmsdrm, fbcon, directfb, x11, wayland, offscreen and dummy in turn, and records which drivers the device offers to data/menu-sdl.log. On untested hardware that is the difference between a usable bug report and a black screen.

resolve_python_bin now records why each runtime candidate was rejected. Two bugs used to destroy that: probe stderr was redirected with 2> into the log it shared, so the last (successful) probe truncated it, and the system-Python branch cleared RUNTIME_FAILURE_REASON on success. A wrong or unusable bundled runtime therefore fell through to spruce's own python3, which has no vendored pygame, and the only symptom was a ModuleNotFoundError far from the cause. data/runtime-detect.log is now append-only and names the device, its uname -m, and each candidate's outcome; run_menu_sdl logs sys.executable so a fallback is visible on the first line.

Docs list which devices each build covers, since users know they own a Miyoo Flip rather than that a Flip is aarch64.

Status

The proxy half is confirmed working on a TrimUI Brick by a tester: caching while online, autostart, and the achievement popup on offline launch. The menu does not come up there. spruce drives its own Brick UI through PySDL2 against spruce/brick/sdl2, so the generic manylinux SDL2 in this bundle is untried on that panel; the probe added here is what will tell us which driver to target.

A second tester on a Miyoo Flip reports the app falling back to spruce's system Python with both the armv7 and the arm64 build. Both being rejected rules out a plain architecture mismatch and points at the install rather than the binaries, but the old logging could not say which. That is what the runtime-detect logging above is for, and the diagnosis is still open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant