| Filename | Latest commit message | Latest commit date |
|---|---|---|
pat-s
36d3bc8604
Some checks failed
ci/crow/cron/process-updates/11 Pipeline was successful
ci/crow/cron/process-updates/17 Pipeline was successful
ci/crow/cron/process-updates/18 Pipeline was successful
ci/crow/cron/process-updates/6 Pipeline was successful
ci/crow/cron/process-updates/12 Pipeline was successful
ci/crow/cron/process-updates/5 Pipeline was successful
ci/crow/manual/build-all-versions-install-deps/2 Pipeline was successful
ci/crow/cron/process-updates/7 Pipeline was successful
ci/crow/cron/process-updates/1 Pipeline was successful
ci/crow/cron/process-updates/2 Pipeline was successful
ci/crow/cron/process-updates/9 Pipeline was successful
ci/crow/cron/process-updates/8 Pipeline was successful
ci/crow/cron/process-updates/3 Pipeline was successful
ci/crow/cron/process-updates/4 Pipeline was successful
ci/crow/manual/build-all-versions/8 Pipeline was canceled
ci/crow/manual/build-all-versions/7 Pipeline was canceled
ci/crow/manual/build-all-versions/6 Pipeline was canceled
ci/crow/manual/build-all-versions/5 Pipeline was canceled
ci/crow/cron/process-updates/10 Pipeline was canceled
## Problem The `fs` 2.1.0 binary links **system libuv** (`readelf -d fs.so` shows `NEEDED libuv.so.1`). fs's `configure` prefers system libuv whenever `pkg-config` resolves it, and our build images ship `libuv-devel` (installed as a pak build-time system requirement), so the resulting binary is dynamically linked against `libuv.so.1`. That binary fails to load on any consumer machine without runtime libuv: ```text unable to load shared object '.../fs/libs/fs.so': libuv.so.1: cannot open shared object file: No such file or directory ``` `install.packages()`/renv do **not** install `SystemRequirements` (only `pak` does, and only inside the build container), so most consumers hit this. Older fs 1.6.x always vendored libuv, so only the 2.x binaries regressed. Reproduced in a clean `reg.devxy.io/r/r-alma:4.5-9`. ## Fix Add `local/patches/fs/force-vendored-libuv.patch`, registered for all platforms. It short-circuits `configure` to `cp -f src/Makevars.vendor src/Makevars; exit 0` before the pkg-config detection, forcing the bundled static libuv build (`tools/libuv-v1.52.0.tar.gz`, built via cmake). An env/pkg-config override (`PKG_CONFIG_LIBDIR`) was tried first but the rebuilt binary still linked `libuv.so.1` (the registry `env` tier does not reach fs's configure step), so a source patch is used instead. ## Verification Built end-to-end inside the real `build-env-redhat:9` image (system libuv present): - patch fires (`Building static libuv (bincraft: forced vendored)`), - cmake compiles the vendored libuv, - resulting `fs.so` has **no `libuv.so.1`** in `NEEDED` (only libR, libstdc++, libm, libgcc_s, libc). `Rscript local/validate-patches.R` passes (2 entries). cmake confirmed present in the build-env images. ## Follow-up (not in this PR) - Rebuild `fs 2.1.0` on every affected platform (rhel8/9/10, ubuntu jammy/noble, alpine 3.22/3.23; amd64 + arm64) and purge the CDN binary paths. - CDN delivery gap: `purge_cdn_cache.sh` only purges `PACKAGES*`, never package binaries, so rebuilt binaries stay masked until their `.tar.gz` path is purged. Reviewed-on: #111 |
||
| .. | ||
| fs | ||
| RcppParallel | ||
| README.md | ||
| registry.json | ||
Patch Registry
This directory contains the curated registry of per-package build-time patches consumed by bincraft's patches argument.
Schema
The registry is defined in registry.json as an array of patch entries. Each entry specifies lightweight build-time overrides (environment variables, configure arguments, Makevars) and optionally a source diff to apply before building.
Field semantics
| Field | Type | Required | Description |
|---|---|---|---|
package |
string | yes | CRAN package name. |
versions |
string | yes | "*" for any, a constraint such as ">=5.1.0", or an exact version "5.1.11-2". Env-tier fixes are typically "*"; source diffs are normally exact or lower-bounded because a diff is pinned to the source it was generated against. |
platforms |
array of strings | yes | Matched against the running build's platform tokens — distro family (alpine, ubuntu, redhat), codename (ubuntu-2604, alpine-324), and arch (amd64, arm64). An entry matches if any listed token matches any build token. ["*"] matches all platforms. |
env |
object | no | Environment variables exported only for this package's isolated build. |
configure_args |
array | no | Arguments passed as --configure-args to the isolated build. |
makevars |
object | no | Key/value pairs written into a package-local Makevars for the isolated build. |
patch |
string or null | no | Path (relative to local/patches/) to a unified diff applied to the unpacked CRAN source before building. |
reason |
string | yes | Human explanation, surfaced in logs and metadata. |
Adding an entry
To add a new patch entry:
-
Add an object to the array in
registry.jsonwith the fields documented above. Start with lightweight overrides (environment variables, configure arguments, Makevars) before resorting to source diffs. -
If a source diff is needed, place it in
local/patches/<package>/<file>.patchand reference its path in thepatchfield. For example, a diff forRcppParallelwould go inlocal/patches/RcppParallel/fix.patchand be referenced as"patch": "RcppParallel/fix.patch". -
The
reasonfield should clearly explain why the patch is needed and what problem it solves.
Validation
The registry is validated and applied by bincraft during the build process. For manual validation, run the validator from the repo root:
Rscript local/validate-patches.R
This validates the schema, referenced patch-file existence, and checks for duplicate entries across platforms and versions.