JASP 0.98.8 requires the Qt NetworkAuth component, so the build installs
qt6-networkauth and the package depends on it at runtime. Without it CMake
stopped at configure and the run failed every evening.
The scheduled run now starts at 22:00 Danish time instead of 18:00, so the
hours-long build no longer competes with evening use of the runner host.
Claude-Session: https://claude.ai/code/session_01JmhJG6JnhXfzNiKv8f2vHu
The tarball host lists each package's PKGBUILD beside its tarballs, but the
JASP one was only ever placed there by hand and went stale as soon as CI
published a new build. Upload the same PKGBUILD the AUR job gets, once the
tarball's public URL has been verified, via a dotfile and a rename so the
host's index never sees a partial file. Not fatal to the AUR release.
Claude-Session: https://claude.ai/code/session_01GGe7kUhooMFuzY6GaDb2w9
Run logs of a public repository are public, and Gitea prints variables in
them in clear text; only secrets are masked. They are now set only on the
publish step, the one step that needs them.
Claude-Session: https://claude.ai/code/session_01GGe7kUhooMFuzY6GaDb2w9
The README, the publish script and the workflow named the tarball host, its
address and filesystem paths on the web host and the runner. Hosts and paths
now come only from repository variables, and the workflow shares the work
tree and the build cache through the named Docker volumes jasp-build and
jasp-cache instead of host paths. (The runner does not expand ${{ vars }} in
container.volumes, so a variable could not have replaced the host path there.)
Also drop the unused scripts/gen-tarball-index.py, and give each module build
its own process under a time limit: a module once spun for eight hours in
jaspModuleTools' bundling step and stalled the whole build.
Claude-Session: https://claude.ai/code/session_01GGe7kUhooMFuzY6GaDb2w9
The AUR push is made under the maintainer's name and should land in the
evening rather than during working hours. At 16:00 UTC a two-hour build
publishes around 19:00-20:30 local time.
Claude-Session: https://claude.ai/code/session_01GGe7kUhooMFuzY6GaDb2w9
Every build started from an empty container and recompiled R, JASP and 1000+
R packages, which is days of CPU on the runner. Now:
- /srv/jasp-cache on the host holds ccache and the renv package cache, linked
into the paths jaspModuleTools::compile() hard-codes.
- RENV_PATHS_PREFIX is fixed: renv otherwise keys the cache on the archlinux
image's build date, so any newer image started cold.
- Cached packages with unresolved sonames after an Arch update are purged, so
only those are rebuilt.
- R packages compile without -g (the Stan/Eigen ones spend real time and GBs of
memory on debug info), and retry passes skip modules that already built.
Claude-Session: https://claude.ai/code/session_01GGe7kUhooMFuzY6GaDb2w9
docker run -v ${WORK_DIR}:/work reaches the runner host's docker daemon, so it
mounts the host's /srv/jasp-build, not the job container's. The job prepared
its scripts in a private copy that never reached the build, which has been
running a stale build-jasp.sh left on the host since 2 September (22 modules,
no remotes pre-seed) and failing every night on "The package remotes is
required". The publish steps had the same blind spot for out/.
Claude-Session: https://claude.ai/code/session_01GGe7kUhooMFuzY6GaDb2w9
Serve from /srv/tarballz on CT148 via a 'location /tarballz/' alias, NOT
from under /var/www/asger: the asger-web deploy swaps that whole directory
atomically, so tarballs kept inside it would be deleted on the next site
deploy. CT148's rootfs was 3G with 2.7G free - one tarball would have
filled it - so it is grown to 15G; speedy's thin pool has room even though
vgs reports the VG nearly full.
Publishing uploads to a .part name and renames on arrival so a download can
never see a truncated file, verifies sha256 on the host, then fetches the
public URL and checks it against the sha256 baked into the PKGBUILD. Both
checks run before the AUR push, so the package cannot go out pointing at a
missing file. Old tarballs are pruned to the newest three.
GH_TOKEN is kept but demoted to an optional GITHUB_PAT for R module
downloads; it no longer has anything to do with publishing.
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.
Reuse the established conventions rather than inventing new ones: the
AUR_SSH_PRIVATE_KEY secret name, pushing from an archlinux:base-devel
job container instead of docker-in-docker, and the existing git identity.
The AUR job only needs the PKGBUILD, so the 1.5 GB tarball never crosses
a job boundary - it goes straight to GitHub Releases from the build job.
Also correct the Gitea job-timeout setting name to ENDLESS_TASK_TIMEOUT.
Upstream JASP ships no Linux binary, so the existing AUR package builds
everything from source including several hundred R packages. This builds
that once in CI and publishes the result as jasp-desktop-bin.
JASP links against the system R and Qt6 rather than bundling them, so a
rebuild is triggered by an Arch r/qt6-base bump as well as by a new JASP
release, and the generated PKGBUILD pins depends to the versions actually
built against.
agw