spruce: build an arm64 bundle for 64-bit devices - #149
Open
misantronic wants to merge 5 commits into
Open
misantronic wants to merge 5 commits into
misantronic wants to merge 5 commits into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
build_bundle.shnow takes an architecture argument and defaults toarmv7, so the existing invocation is unchanged.fetch_runtime_arm64.sh)arm-linux-gnueabihf.2.17aarch64-linux-gnu.2.17Nothing new is introduced: the arm64 target borrows from muOS the way the armv7 target borrows from Onion.
Supporting changes
common.shhadpython3.9hardcoded in the certifi lookup. It now resolves the runtime's ownlib/python3.*/site-packages, so both runtimes work from one script.launch.shno longerexecs the menu. If the menu fails, it runs an SDL probe that trieskmsdrm,fbcon,directfb,x11,wayland,offscreenanddummyin turn, and records which drivers the device offers todata/menu-sdl.log. On untested hardware that is the difference between a usable bug report and a black screen.resolve_python_binnow records why each runtime candidate was rejected. Two bugs used to destroy that: probe stderr was redirected with2>into the log it shared, so the last (successful) probe truncated it, and the system-Python branch clearedRUNTIME_FAILURE_REASONon success. A wrong or unusable bundled runtime therefore fell through to spruce's ownpython3, which has no vendored pygame, and the only symptom was aModuleNotFoundErrorfar from the cause.data/runtime-detect.logis now append-only and names the device, itsuname -m, and each candidate's outcome;run_menu_sdllogssys.executableso 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.