Files
jasp-desktop-bin/README.md
T
agw d880e6748c Bundle our own R 4.5.3 instead of building against Arch's R
Arch ships R 4.6.1, but JASP pins its R packages against a frozen CRAN
snapshot (2026-03-31 for 0.98.1) that targets R 4.5. Configuring against
Arch's R fails at Rcpp 1.1.1, which cannot compile on R 4.6 since
R_NamespaceRegistry was removed; the Rcpp release that fixes it is newer
than the pinned snapshot, so the lockfile cannot reach it either.

Build R 4.5.3 into /opt/jasp-desktop/R and point R_HOME at it, matching
what upstream CI does. This drops 'r' from depends entirely, so an Arch R
upgrade can no longer break an installed JASP, and the rebuild triggers
become Qt6 and ICU - the libraries actually still linked against.
2026-09-01 21:40:00 +02:00

5.4 KiB
Raw Blame History

jasp-desktop-bin

Automated binary builds of JASP for Arch Linux, published to the AUR as jasp-desktop-bin.

Why this exists

Upstream JASP ships installers for Windows and macOS only — there is no official Linux binary. The official Linux channel is the Flathub build. The existing AUR package jasp-desktop therefore builds everything from source, including buildAllDefaultJaspModules.R, which compiles several hundred R packages. That is the multi-hour build this repo exists to avoid: the compile happens once, here, and users download the result.

The constraint that shapes everything

JASP pins its R package set with renv lockfiles against a frozen CRAN snapshot — for 0.98.1, Modules/Rcpp_RInside.lock points at the Posit snapshot of 2026-03-31. That set targets R 4.5.

Building against Arch's current R (4.6.1) fails immediately: Rcpp 1.1.1 does not compile there, because R_NamespaceRegistry is gone in R 4.6. The Rcpp release that fixes this (1.1.2, 2026-07-05) is newer than the pinned snapshot, so the lockfile cannot resolve it either. This is precisely the "old libraries with issues" problem that makes the source AUR package painful.

So this build compiles and bundles its own R 4.5.3 into /opt/jasp-desktop/R and points R_HOME at it — which is what upstream's own CI does (.github/workflows/ubuntu.yml sets JASP_R_VERSION: 4.5.3 and an explicit R_HOME). Tools/CMake/R.cmake reads R_HOME from the environment on Linux, so this is a supported configuration rather than a hack.

Consequences:

  1. r is not a dependency of the package. An Arch R upgrade cannot break an installed JASP.
  2. What the binary is still linked against is Qt6 and ICU, both of which break ABI across releases. The generated PKGBUILD pins those (qt6-base>=6.11 <6.12, icu>=78 <79), and scripts/check-upstream.py triggers a rebuild when Arch moves either — or when JASP releases.

jags and librdata-git are AUR-only, and JASP needs freexl >= 2.0.99 while Arch ships 2.0.0 — so the build compiles those itself, matching what upstream CI does.

Layout

Path Purpose
build/build-jasp.sh The actual build. Runs in an archlinux:base-devel container, emits the tarball plus build-info.json.
scripts/check-upstream.py Compares upstream JASP / Arch Qt6 / Arch ICU against state.json; decides whether to build.
scripts/gen-pkgbuild.py Fills packaging/PKGBUILD.in from build-info.json; derives pkgrel from what is on the AUR.
scripts/publish-github-release.sh Creates the GitHub release and uploads the tarball.
scripts/push-aur.sh Generates .SRCINFO and pushes to aur.archlinux.org.
scripts/record-state.sh Commits state.json so the next nightly run knows what was built.
packaging/PKGBUILD.in Template for the AUR package.
state.json Last successfully built combination.

Flow

nightly (03:00) ─► check-upstream.py
                     │ new JASP tag, or Arch bumped qt6-base / icu?
                     ▼
                   build-jasp.sh  (Arch container, hours)
                     │  builds R 4.5.3, JASP, then all R modules
                     │  jasp-desktop-<ver>-x86_64.tar.zst + build-info.json
                     ▼
                   GitHub release ──► gen-pkgbuild.py ──► push to AUR
                     │
                     ▼
                   state.json committed back

Required configuration

Set these in the Gitea repo before the first run.

Variables (Settings → Actions → Variables):

Name Example Meaning
GH_OWNER asgerw GitHub account hosting the release repo
GH_REPO jasp-desktop-bin Release repo name
AUR_MAINTAINER Asger Geel Weirsoe <asger@weircon.dk> Written into the PKGBUILD header

Secrets (Settings → Actions → Secrets):

Name Meaning
GH_TOKEN GitHub PAT with contents: write on the release repo
AUR_SSH_PRIVATE_KEY Private SSH key registered with your AUR account. Copy the value already set on agw/pi3-smart-workspace.
STATE_PUSH_TOKEN Gitea token with write access to this repo, for committing state.json. (Gitea reserves the GITEA_ secret prefix.)

The GitHub repo GH_OWNER/GH_REPO must exist and be public — the AUR PKGBUILD downloads the tarball from its releases, so it has to be reachable anonymously.

Runner requirements

The build runs for hours and needs disk. On the Gitea runner host:

  • runner.timeout in /var/lib/gitea-worker/config.yaml must exceed the build time (set to 16h).
  • Gitea's own job timeout ([actions] ENDLESS_TASK_TIMEOUT in app.ini, default 3h) must match, otherwise Gitea kills the job at 3h regardless of the runner.
  • Roughly 40–60 GB of free disk for the build tree, the bundled R and the staged install.

Running it by hand

# Build a specific tag without waiting for the schedule
Actions → Build JASP binary and publish to AUR → Run workflow
         jasp_tag = v0.98.1   force = true

Caveat worth knowing

AUR convention is that a -bin package repackages binaries published by upstream. Here upstream publishes no Linux binary, so this one is built by us. That is unusual, and a maintainer or TU may question it. It is not against the rules, but the package description and this README should stay honest about where the binary comes from.