push-aur.sh: mktemp -d creates the work directory as 0700 root, so the
builder user could not enter it to run makepkg ('cd: Permission denied'),
and the git steps afterwards would refuse a tree owned by another user. Give
builder the whole tree for makepkg and hand it back to root before git.
record-state.sh: 'git diff --quiet' ignores untracked files, so the first
state.json was reported as unchanged and never committed, which would have
rebuilt and republished every night. Stage it before comparing.
Both were found by the first publishing run; push-aur.sh was then tested end
to end in a clean Arch container with a dummy key.
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 first full build succeeded and produced a package that would not have
worked. Three separate causes, all silent:
- R was configured --with-blas --with-lapack, so it linked Arch's external
BLAS and never built libRblas.so/libRlapack.so. The JASP module bundles
expect those inside R_HOME, the way a conventional R and the Flatpak ship
them. Now --without-blas, with a hard check after install.
- buildModuleBundlesLocally.R installs jaspModuleTools via install_github,
which failed on anonymous GitHub rate limits. No bundles were produced at
all. GITHUB_PAT is now required rather than merely recommended.
- buildAllDefaultJaspModules.R calls the bundle builder through system2(),
which ignores exit status, so all of the above exited 0. Added explicit
guards: jaspModuleTools must exist, Modules/local must be non-empty, and
the staged tree must contain the bundles and all three R libraries.
Staging was also wrong: it copied ModuleBundleBuildDir/Modules, which is
cloned module *sources* with zero compiled objects, while dropping
LibraryR entirely - 267MB of R packages built against the bundled R.
Cloning a package that does not exist on the AUR yet gives an empty repo
whose initial branch follows the runner's init.defaultBranch, which is not
guaranteed to be master. Verified against the real AUR remote: auth works,
the empty clone yields a .git, and 'git diff --staged --quiet' correctly
reports changes there - so the first publish commits instead of exiting
early with 'nothing to push'.
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.
Checked what the AUR actually requires rather than relying on my earlier
assumption. The submission guidelines say only that packages using prebuilt
deliverables must carry the -bin suffix; nothing requires the binary to come
from upstream, so -bin is correct and sufficient here.
There is no formal 'unofficial binary' flag, so disclose it where users look:
an explicit PROVENANCE block in the PKGBUILD comment header naming the tag,
commit, build recipe and release URL, plus '(prebuilt binary)' in pkgdesc.
Corrects the README, which overstated the risk of a maintainer objecting.
Bundling R alone was not enough: R links libicuuc, and Arch moves ICU
regularly. The obvious fix - pinning 'icu>=78 <79' in depends - is worse
than the disease on a rolling distro, because pacman would then refuse to
upgrade ICU while JASP is installed, blocking the user's whole system
upgrade until a rebuild lands.
So bundle-libs.sh copies every non-system shared library into
/opt/jasp-desktop/lib and rewrites rpaths, by denylist rather than
allowlist. depends now carries no version constraints at all.
Qt6 stays system-provided on purpose - Qt is binary compatible across Qt 6
minors, and bundling QtWebEngine would add ~500 MB. That also means the
only rebuild triggers left are a new JASP release and a Qt major bump;
rebuilding for anything else would cost users a 1.7 GB re-download.
Also fixes check-upstream.py querying only repo=Extra, which silently
returned nothing for icu (it lives in core).
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