fdroid: fix the buildserver recipe and add a remote build check - #1
Merged
Conversation
Running the recipe in F-Droid's own buildserver image turned up two things that would have failed fdroiddata's CI after the merge request was open. The sudo block fetched node as a .tar.xz, but the buildserver has no xz binary -- only gzip -- so `tar xf` died before anything was built. Switch to the gzip tarball nodejs.org publishes alongside it. The recipe was also not in fdroid's canonical format. fdroiddata CI runs `fdroid rewritemeta` on every changed file and fails if the file changes, and that rewrite strips YAML comments, so the rationale the comments carried moves to MaintainerNotes where a reviewer will actually see it. Add Game Helper alongside Sports & Health: upstream describes it as "game helper, assistant, companion, score board, timer", which is what this is. FDROID.md documents the one blocker left. React Native forces a Java 17 toolchain on every module and the buildserver ships only JDK 21, with no openjdk-17 available on trixie at all. Three ways out are written up; the choice belongs in the merge request, not here. .github/workflows/fdroid-build.yml runs `fdroid build` in the buildserver image on a runner, so the recipe can be checked remotely. Its provision_jdk17 input installs the same Temurin 17 the release build already uses -- on, it verifies the rest of the recipe end to end; off, it reproduces the blocker exactly. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
React Native forces a Java 17 toolchain on every module and the buildserver ships only JDK 21, with no openjdk-17 available on trixie at all, so the recipe fetches a pinned Temurin 17 the same way it fetches node and names the path in gradleprops. This is the JDK the app is already built with everywhere else: release.yml's build and smoke-test jobs both run setup-java with temurin 17, so the buildserver now matches rather than diverges. That settles the question FDROID.md was holding open, so its section is rewritten around the decision, and the fdroid-build workflow loses the provision_jdk17 toggle that existed to demonstrate the failure. Also bump every action to its current major. GitHub is deprecating Node 20 and was already forcing checkout and setup-node onto Node 24. Note that the publish job only runs on a tag, so action-gh-release is the one bump a workflow_dispatch dry run cannot exercise. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
1 participant
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.
Ran the recipe against F-Droid's own buildserver image (
fdroidserver:buildserver-trixie) rather than trusting it, which turned up two things that would have failed fdroiddata's CI after the merge request was already open.Fixed
xzis not on the buildserver. Thesudo:block fetched node as.tar.xzand rantar xf, which died withtar (child): xz: Cannot exec: No such file or directory. Onlygzipis present — noxz,unxzorbzip2. Switched to the gzip tarball nodejs.org publishes alongside it, checksum fromSHASUMS256.txt.fdroid rewritemetaon every changed file and fails the MR if the file changes. That rewrite strips YAML comments, so the rationale they carried moved intoMaintainerNotes, where a reviewer will actually see it.Game HelperalongsideSports & Health— upstream describes it as "game helper, assistant, companion, score board, timer".Verified:
fdroid lint -fclean,fdroid rewritemetaidempotent,fdroid scannerclean on both the source tree and all three published APKs.Known blocker, documented not worked around
React Native's
JdkConfiguratorUtilsforcesjvmToolchain(17)on every module; the buildserver installs onlydefault-jdk-headless(JDK 21) and Debian trixie has noopenjdk-17package at all. The build fails at:app:compileReleaseJavaWithJavac.Three ways out are written up in
FDROID.md. The choice belongs in the merge request — F-Droid reviewers handle this across every RN app in the repo and will have a preference.Worth noting for that conversation:
release.yml'sbuildandsmoke-testjobs already useactions/setup-javawith Temurin 17, so every published APK is built with exactly that JDK. Pinning it in the recipe only makes the buildserver match.Remote verification
.github/workflows/fdroid-build.ymlrunsfdroid buildin the buildserver image on a runner —workflow_dispatchonly. Itsprovision_jdk17input installs the same Temurin 17: on, it verifies the rest of the recipe end to end; off, it reproduces the blocker exactly, so it can be linked to rather than described.This workflow only becomes dispatchable once it is on
main— that is howworkflow_dispatchworks.🤖 Generated with Claude Code