Author	SHA1	Message	Date
pat-s	930a4acd12	fix(ci): install the R packages pipelines use instead of relying on the image ... bincraft v5.5.1 dropped lubridate, dplyr, purrr, data.table and others from its imports, so the pipelines' own calls now depend on whatever the build-env image's site library or the shared R_LIBS_USER cache happens to hold. The arm64 redhat:9 image has no progressr under R 4.4.3, which fails every process-cran-updates-redhat-9-arm64 run since v5.5.1. - Install progressr and lubridate for process-updates, which call them inline. - Install purrr for packages-to-build.R and data.table for the weekly audit. - Drop the unused dplyr and progressr library() calls from packages-to-build.R. - Install RPostgres in every pipeline that talks to the metadata DB, since bincraft silently skips the DB (and the per-minor index aborts) without it. - Reinstall bincraft in the prune re-index step, whose /tmp library does not survive from the prune step.	2026-10-20 08:46:00 +00:00
pat-s	416a2d64d9	chore(alpine): drop the deprecated Alpine 3.22 slot (#213) ... ## Why Alpine 3.22 is deprecated and should be dropped. It was never a published slot to begin with. `local.rpkgs_slots` in `cdn.tf` enumerates eight distros and alpine322 is not one of them, so `UNION_SLOTS` never gated per-minor rewriting for it. The website's `DistroId` union lists the same eight. Every request to the slot therefore fell through to the flat index, which holds R 4.5 builds. ## Evidence The fleet-wide routing verification (pipeline 12591, `verify_routing=all`) measured this end to end. Across all 16 published slots, both architectures, three R minors and both contractual URL forms: **1056 of 1056 install-and-load checks passed.** Every failure in the run was alpine322, identical on amd64 and arm64: ``` amd64/alpine322 R 4.4 via arch|generic|flat: 8 of 11 amd64/alpine322 R 4.6 via arch|generic|flat: 10 of 11 arm64/alpine322 R 4.4 via arch|generic|flat: 8 of 11 arm64/alpine322 R 4.6 via arch|generic|flat: 10 of 11 ``` The tell is that all three forms agree. On a routed slot `arch` and `generic` diverge from `flat`, because that divergence *is* the routing. On alpine322 there is nothing to diverge from. R 4.5 clients were 11 of 11 on every form, because flat happens to be what they need. The data itself is not broken, only unreachable. `alpine322/contrib/4.4/data.table_1.18.6.1.tar.gz` is genuinely `Built: R 4.4.3` and the 4.6 object is `Built: R 4.6.0`. Correct objects, correct per-minor indexes, never served. ## What changed - alpine-322 matrix rows and dropdown options removed from the 12 pipelines that carried them, so `=all` no longer fans out to a slot nobody can reach. - `3.22` removed from the `OS_VERSION` dropdowns in `build-all-versions.yaml` and `repair-built-stamp.yaml`; the latter's default moves to `3.23`. - Stale `3.22` examples updated in `local/packages-to-build.R`. `crow lint .crow/` reports all 18 configs valid. ## Also done outside this diff The six alpine-322 cron jobs are deleted from the Crow server, since a cron whose matrix row is gone keeps firing against nothing: ``` 5 process-cran-updates-alpine-322-amd64 0 5/8 * * * 6 process-cran-updates-alpine-322-arm64 30 5/8 * * * 68 weekly-audit-missing-alpine-322-amd64 20 0 * * 0 69 weekly-audit-missing-alpine-322-arm64 30 0 * * 0 82 weekly-rebuild-missing-alpine-322-amd64 0 4 * * 0 83 weekly-rebuild-missing-alpine-322-arm64 10 4 * * 0 ``` They are listed here so they can be recreated if this is ever reversed. ## Not done The published objects and indexes under `amd64/alpine322` and `arm64/alpine322` are left in the bucket. Deleting them is a separate decision, and nothing routes to them in the meantime. Reviewed-on: #213	2026-09-11 07:27:03 +00:00
pat-s	cceda03935	fix(ci): do not gate the targeted repair on the source classifier (#205) ... ## Why The repair workflow ran `build-one.R --sensitive-only`. That flag skips any version the **source** classifier does not call r-minor-sensitive — and it misses `Rcpp`. So the repair skipped `Rcpp` on every slot, leaving its 4.5-built flat binary as the only copy: ``` flat 200 built under R 4.5.3 4.4/ 404 4.5/ 404 4.6/ 404 ``` Every R 4.4 client on those slots then failed at `dyn.load()`. A real install check across 8 slots x 3 minors x 3 repository forms found **44 such failures**, `Rcpp`, `Matrix` and `RJSONIO` among them. ## What changed Drops `--sensitive-only`. Since bincraft v5.3.0 the destination is decided by the built binary's symbols in `upload_single_binary()`, so building unconditionally is safe and correct: a package that needs a per-minor slot lands there, one that does not lands in the flat slot. Skipping before the build is exactly what removed that decision from the path. `crow lint` passes. ## Companion bincraft #129 is the other half: the index build could not compensate either, because it only considered dropping records whose *package* was flagged risky, and `Rcpp` is not — even though the backfill had recorded that object as unable to load under 4.4. Reviewed-on: #205	2026-09-07 06:20:04 +00:00
pat-s	26406a3e86	feat(ci): add a targeted per-R-minor rebuild workflow (#198) ... ## Why A user hit this on amd64/resolute under R 4.6.1: ``` base64enc.so: undefined symbol: SETLENGTH ``` R 4.6 no longer exports `SETLENGTH`: ``` R 4.4: missing -> R_ClosureEnv R_ClosureFormals R_MakeMissingBinding R_PromiseEnv R_PromiseValue R_mkClosure R 4.5: missing -> R_MakeMissingBinding R_PromiseEnv R_PromiseValue R 4.6: missing -> R_PromiseEnv R_PromiseValue SETLENGTH ``` `base64enc` calls `SETLENGTH` (`base64.c:206`, `253`), its flat binary was built under R 4.4.3, and it has no per-minor copy at all, so the union index hands that binary to a 4.6 client. The safety net missed it because the risky set is defined circularly: ```r risky_packages_across_minors <- function(...) { # a package is "risky" iff it already has a tarball in some per-minor slot ``` A package counts as ABI-risky only if it has *already* been built per-minor. `base64enc` never was, and having no new CRAN version it never enters the build list to be classified. So the per-minor protection only covers packages that passed through the pipeline after the scheme existed. ## Scope Scanning all 4,585 compiled binaries in amd64/resolute's flat index for symbols R 4.6 does not export found 10 referencing `SETLENGTH`. Most already have per-minor builds and are served correctly. Two do not: ``` base64enc_0.1-6 flat=200 4.4=404 4.5=404 4.6=404 lobstr_1.2.1 flat=200 4.4=404 4.5=200 4.6=404 ``` (`iotools` lacks a 4.5 copy but 4.5 still exports `SETLENGTH`, so it does not break.) ## What this adds Rebuilding one package into one minor was only possible with `just rebuild` from a workstation holding the S3 and Postgres credentials. This adds the CI path: ```sh crow pipeline create devxy/build-cran-binaries \ --var rebuild_abi_gap=ubuntu-2604-amd64 \ --var ABI_PACKAGES="base64enc@0.1-6 lobstr@1.2.1" \ --var ABI_R_MINOR=4.6 ``` - reuses `reindex.yaml`'s slot matrix verbatim, so the slot-to-image mapping cannot drift - runs `build-one.R --sensitive-only`, which reclassifies each version and skips anything not ABI-risky rather than writing it to the wrong slot - mounts no shared cache volume, so it cannot disturb the build pipeline's per-agent caches - attempts every package, then exits non-zero if any failed `crow lint` passes. ## Not in this PR This is the remediation path, not the fix. The circular `risky_packages_across_minors()` definition is still in place, so new instances of this class can still appear. That is the follow-up. Reviewed-on: #198	2026-09-04 10:24:47 +00:00