fix(build): Ship the MAKEFLAGS helper in the tarball, and refuse a value that is not -jN - #2678
fix(build): Ship the MAKEFLAGS helper in the tarball, and refuse a value that is not -jN#2678krlmlr wants to merge 1 commit into
MAKEFLAGS helper in the tarball, and refuse a value that is not -jN#2678Conversation
…value that is not `-jN`
`configure` filled `MAKEFLAGS` in from `scripts/setup-makeflags.R`,
but `.Rbuildignore` lists `^scripts$`,
so `R CMD build` strips the directory
and no package installed from a tarball could read it.
`Rscript` reports a file it cannot open on *stdout* and exits 2,
so neither the `2>/dev/null` nor the `|| echo ""` kept the message out of the
capture: every such build exported
MAKEFLAGS=Fatal error: cannot open file 'scripts/setup-makeflags.R': No such file or directory
and then compiled serially, with the failure visible only as a puzzling echo.
Move the helper to `tools/`, which `R CMD build` keeps,
and accept its output only when it is the `-jN` it is meant to produce,
so a helper that ever goes missing again leaves `MAKEFLAGS` unset
rather than exporting whatever came back.
r-universe finding, 2026-08-27: `duckdb.dev` failed
`macos-oldrel-x86_64` (duckdb.r-universe.dev, 3786 s) at `main-green`
d794a33 and `macos-release-x86_64` (krlmlr.r-universe.dev, 3812 s) at
`main-fwd-green` f6f4c6b, both with `The action has timed out.` while
still compiling `src/duckdb`, and both preceded by the `MAKEFLAGS=Fatal
error: ...` line above. The serial build is what puts those two targets
over r-universe's one-hour budget; the other 13 targets fit either way.
No other series is affected today, and no target is red for another reason.
Verified: `R CMD build` on this tree ships `tools/setup-makeflags.R`,
and `./configure` inside the extracted tarball sets `MAKEFLAGS=-j2`
where it previously exported the error string.
Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Q9P75FLG4YSwyTn91Vupf7
Date: 2026-08-27 18:04:01 +0000 Implement HTTP cache control (https://redirect.github.com/duckdb/duckdb/pull/24587) R-side fix: Nothing in the tree — a finding with no repair to carry, recorded here because nothing else keeps it. r-universe's `macos-release-x86_64` target failed again on the current green, f6f4c6b (`duckdb.dev` 1.5.5.9013.1315, krlmlr.r-universe.dev): `##[error]The action has timed out.` after 3847 s of a one-hour action budget, with `src/duckdb` still compiling. The cause is not the builder being slow, which is what the previous reading of this red concluded (925408e). It is in the log 500 lines above the timeout: Setting MAKEFLAGS=Fatal error: cannot open file 'scripts/setup-makeflags.R': No such file or directory for parallel compilation `configure` fills `MAKEFLAGS` in from `scripts/setup-makeflags.R`, `.Rbuildignore` lists `^scripts$`, so `R CMD build` strips the directory and no package installed from a tarball can read it. `Rscript` reports the missing file on stdout and exits 2, so the capture keeps the error string and `MAKEFLAGS` is exported as that string rather than as `-jN`. Every source install from the built package therefore compiles serially, and the two slowest targets land on the wrong side of the hour. duckdb#2678 fixes it — the helper moves to `tools/`, which `R CMD build` keeps, and a value that is not `-jN` is refused. It is open against `main`; the series gets it when stage 4 ports it, never before. The margin is thin rather than hard: on this same read `macos-oldrel-x86_64` at `main-green` d794a33, red at 3786 s when the PR was written, came back OK on a rebuild, while this target went from 3812 s to 3847 s. So a green here proves nothing about the next build until the helper ships. The consequence is a stale published binary, not a broken one: `mac-x86_64` still serves 1.5.5.9013.1313, built 2026-08-26. The `rcc` gate is Linux on one R version and never compiles this target, and no `each-rcc` run records the outcome either way.
Date: 2026-08-27 18:04:01 +0000 Implement HTTP cache control (https://redirect.github.com/duckdb/duckdb/pull/24587) R-side fix: Nothing in the tree — a finding with no repair to carry, recorded here because nothing else keeps it. r-universe's `macos-release-x86_64` target failed again on the current green, f6f4c6b (`duckdb.dev` 1.5.5.9013.1315, krlmlr.r-universe.dev): `##[error]The action has timed out.` after 3847 s of a one-hour action budget, with `src/duckdb` still compiling. The cause is not the builder being slow, which is what the previous reading of this red concluded (925408e). It is in the log 500 lines above the timeout: Setting MAKEFLAGS=Fatal error: cannot open file 'scripts/setup-makeflags.R': No such file or directory for parallel compilation `configure` fills `MAKEFLAGS` in from `scripts/setup-makeflags.R`, `.Rbuildignore` lists `^scripts$`, so `R CMD build` strips the directory and no package installed from a tarball can read it. `Rscript` reports the missing file on stdout and exits 2, so the capture keeps the error string and `MAKEFLAGS` is exported as that string rather than as `-jN`. Every source install from the built package therefore compiles serially, and the two slowest targets land on the wrong side of the hour. duckdb#2678 fixes it — the helper moves to `tools/`, which `R CMD build` keeps, and a value that is not `-jN` is refused. It is open against `main`; the series gets it when stage 4 ports it, never before. The margin is thin rather than hard: on this same read `macos-oldrel-x86_64` at `main-green` d794a33, red at 3786 s when the PR was written, came back OK on a rebuild, while this target went from 3812 s to 3847 s. So a green here proves nothing about the next build until the helper ships. The consequence is a stale published binary, not a broken one: `mac-x86_64` still serves 1.5.5.9013.1313, built 2026-08-26. The `rcc` gate is Linux on one R version and never compiles this target, and no `each-rcc` run records the outcome either way.
|
Evidence from the next series-loop firing (2026-08-27, ~20:00 UTC), on the same two greens this PR was written from. Both targets rebuilt since, and the pair separates the cause from the symptom rather cleanly:
So the serial build is not reliably over the hour — it is sitting on the boundary, and which side a build lands on is noise. That makes the red intermittent per target while the cause is constant, and it means a green on either target proves nothing until the helper actually ships in the tarball. It also explains why this went unnoticed for so long: a target that clears the budget by a minute looks exactly like a healthy one. The remaining 13 targets were OK on both universes in this read; no other series is affected. Recorded on the series side too, in the Generated by Claude Code |
Date: 2026-08-28 07:20:12 +0000 Prune numeric comparison for NOTEQUAL / DISTINCT_FROM operation (https://redirect.github.com/duckdb/duckdb/pull/25061) Use clang for most CI jobs (https://redirect.github.com/duckdb/duckdb/pull/25053) R-side fix: Nothing in the tree — a finding with no repair to carry, recorded here because nothing else keeps it. r-universe's `macos-release-x86_64` target failed a third consecutive time, now on 925408e (`duckdb.dev` 1.5.5.9013.1324, krlmlr.r-universe.dev): `##[error]The action has timed out.` after 3842 s of a one-hour action budget. The cause is diagnosed in full on d49ded3, two commits below: `.Rbuildignore` lists `^scripts$`, so `R CMD build` strips the directory and `configure` cannot read `scripts/setup-makeflags.R`, which leaves `MAKEFLAGS` holding an error string rather than `-jN`. Every source install from the built tarball therefore compiles serially. duckdb#2678 moves the helper to `tools/`, which `R CMD build` keeps. What this reading adds is that the margin is no longer thin. Three greens in a row have overrun — 3613 s, 3847 s, 3842 s — so the earlier hope that a rebuild might land on the right side of the hour (925408e) is settled: it does not. The consequence is still a stale published binary rather than a broken one; `mac-x86_64` has not moved past 1.5.5.9013.1313, built 2026-08-26. The `rcc` gate is Linux on one R version and never compiles this target, and no `each-rcc` run records the outcome either way. duckdb#2678 is open against `main`; the series gets it when stage 4 ports it, never before.
|
Evidence from the 2026-08-29 series-loop firing. The red has now moved to the other universe, which is the part that is new.
Both universes install from a tarball and therefore both export the error string as The consequence is still staleness rather than breakage, and it is milder than it was: No Generated by Claude Code |
Date: 2026-09-01 15:30:44 +0000 Validate LIST offsets before use (https://redirect.github.com/duckdb/duckdb/pull/25212) R-side fix: Nothing in the tree — a finding with no repair to carry, recorded here because nothing else keeps it. r-universe's `macos-oldrel-x86_64` target failed on the previous green, 99dad8e (`duckdb.dev` 1.5.99.9003.1382, duckdb.r-universe.dev): `##[error]The action has timed out.` after 3927 s of a one-hour action budget, with `src/duckdb` still compiling. The cause is the one diagnosed on `main-fwd-dev` d49ded3, and the log names it outright this time: Setting MAKEFLAGS=Fatal error: cannot open file 'scripts/setup-makeflags.R': No such file or directory for parallel compilation `configure` fills `MAKEFLAGS` in from `scripts/setup-makeflags.R`, `.Rbuildignore` lists `^scripts$`, so `R CMD build` strips the directory and no package installed from a tarball can read it. The `2>/dev/null` on that call does not help here: this platform's `Rscript` reports the missing file on stdout, so the capture keeps the error string and `MAKEFLAGS` is exported as that string rather than as `-jN`. Every source install from the built tarball therefore compiles serially. duckdb#2678 moves the helper to `tools/`, which `R CMD build` keeps, and refuses a value that is not `-jN`. It is open against `main`; the series gets it when stage 4 ports it, never before. The consequence is a stale published binary, not a broken one: `mac-x86_64` still serves 1.5.99.9003.1360, built earlier the same day. The `rcc` gate is Linux on one R version and never compiles this target, and no `each-rcc` run records the outcome either way.
Date: 2026-09-01 15:30:44 +0000 Validate LIST offsets before use (https://redirect.github.com/duckdb/duckdb/pull/25212) R-side fix: Nothing in the tree — a finding with no repair to carry, recorded here because nothing else keeps it. Two r-universe targets failed on the previous green, 1b37203 (`duckdb.dev` 1.5.5.9013.1395, krlmlr.r-universe.dev): `macos-release-x86_64` at 3804 s and `windows-devel-x86_64` at 3664 s, both `##[error]The action has timed out.` inside a one-hour action budget, both with `src/duckdb` still compiling. The Windows one is new, and it is the same cause as the macOS one (d49ded3, and duckdb#2678): `.Rbuildignore` lists `^scripts$`, so `R CMD build` strips the directory and `configure` / `configure.win` cannot read `scripts/setup-makeflags.R`, which is where `MAKEFLAGS` comes from. What differs is only how the failure shows: this platform's `Rscript` reports the missing file on stderr, which `2>/dev/null` swallows, so `makeflags_value` is empty, no `MAKEFLAGS` line is printed at all, and the build simply compiles serially with nothing in the log to say why — where macOS keeps the error string and prints it. The Windows log shows one `g++` invocation at a time from 17:31 to the timeout at 18:31, which is the same serial build. So the target list this costs is wider than macOS: every platform that installs from the built tarball compiles serially, and the ones near the hour fall off the edge. duckdb#2678 moves the helper to `tools/`, which `R CMD build` keeps, and refuses a value that is not `-jN`; this firing added the Windows evidence to it. It is open against `main`; the series gets it when stage 4 ports it, never before. The consequence is stale published binaries, not broken ones: `mac-x86_64` and `win-x86_64` both still serve 1.5.5.9013.1373, built earlier the same day. The `rcc` gate is Linux on one R version and never compiles either target, and no `each-rcc` run records the outcome either way.
|
Evidence from the 2026-09-01 series-loop firing. What is new here is that the red has reached Windows, and that it wears a different shape there — which is why it has been invisible in every earlier reading.
The Windows log contains no So the affected surface is not "the two slow macOS builders". Every target that installs from the built tarball compiles serially, on every platform; the ones near the hour are simply the ones that fall off the edge, and the rest just pay the time. Consequence is still staleness rather than breakage: Recorded on the series side in the Generated by Claude Code |
|
Calling an R script seems difficult. Can we inline and just use |
…uckdb#2669) R-side fix: Nothing in the tree — two findings with no repair to carry, recorded here because nothing else keeps them. This firing minted no vendor commit (every buffer was at its upstream tip), so they land on the commit the port stage produced. r-universe read `duckdb.dev` 1.5.99.9003.1394 at 4b9d84a (`main-green`), on duckdb.r-universe.dev, and two of the fifteen targets failed. `macos-release-x86_64` timed out after 3949 s: `##[error]The action has timed out.` at 3612903 ms of the one-hour budget, with `src/duckdb` still compiling (<https://duckdb.r-universe.dev/api/actions/logs/101070339127>). This is the cause already recorded on 16fb13c, now on a second target, and the log names it outright again: + makeflags_value='Fatal error: cannot open file '\''scripts/setup-makeflags.R'\'': No such file or directory' + export 'MAKEFLAGS=Fatal error: cannot open file ...' `configure` fills `MAKEFLAGS` in from `scripts/setup-makeflags.R`, `.Rbuildignore` lists `^scripts$`, so `R CMD build` strips the directory and no package installed from a tarball can read it; `MAKEFLAGS` is exported as the error string rather than as `-jN` and every source install from the built tarball compiles serially. duckdb#2678 moves the helper to `tools/`, which `R CMD build` keeps, and refuses a value that is not `-jN`. It has been open against `main` since 2026-08-27, so this is the second firing to pay for it; the series gets it when stage 4 ports it, never before. `windows-devel-arm64` failed after 168 s, and this one is new (<https://duckdb.r-universe.dev/api/actions/logs/101070339182>): ** using staged installation Warning in system2(file.path(R.home("bin"), "Rcmd.exe"), c("config", x), : running command '"C:/R/bin/Rcmd.exe" config CC' had status 4 Error in (function (...) : 'names' and 'val' are of different lengths `R CMD INSTALL` stops before `configure.win` runs — no `Setting MAKEFLAGS=` line appears — so the tree never had a say: R's own toolchain probe on that runner exited 4, and R then called `Sys.setenv()` with an empty value vector. Nothing between 1.5.99.9003.1393 and .1394 touches the R side, `configure*`, or the Makevars: the diff is upstream's ART and table-scan change alone. The same target is OK on every other package in both universes, so it is neither a permanent platform gap nor the standing arm64 extension-download gap (duckdb#2425), which fails an `INSTALL` with HTTP 404 much later in the run. Treated as the runner's, with no repair to carry; a second occurrence is what would make it the tree's. The consequence is a stale published binary, not a broken one: `mac-x86_64` and `win-aarch64` both still serve 1.5.99.9003.1393, built 2026-09-02. The `rcc` gate is Linux on one R version and compiles neither target, and no `each-rcc` run records the outcome either way. Co-authored-by: Claude <noreply@anthropic.com> (cherry picked from commit e287fdf)
|
Evidence from the series-loop firing of 2026-09-04: this bug has now cost a second r-universe target.
The log names the cause outright:
The previous occurrence was on No action taken on the series: the fix reaches every Generated by Claude Code |
|
Evidence from the second series-loop firing of 2026-09-04 (~20:45 UTC). What is new: the bug has left the
The same four lines are at 1074–1080 of that log: Nothing about this is series-specific, which is the point: Consequence is staleness, not breakage: The No Generated by Claude Code |
|
Evidence from the 2026-09-08 series-loop firing. Same cause, back on the
Lines 1068-1077 of that log are the familiar four: Consequence is staleness rather than breakage, as before: Nothing new about the mechanism; what is new is the elapsed time. This PR has been open as a draft since 2026-08-27. The last count recorded here was the sixth consecutive firing, on 2026-09-04, and firings have run daily since. The open review question above — inline No action taken on the series: the fix reaches every Generated by Claude Code |
Date: 2026-09-08 10:53:21 +0000 Track I/O operation counts alongside byte counters (https://redirect.github.com/duckdb/duckdb/pull/25409) R-side fix: Nothing in the tree — one finding with no repair to carry, recorded here because nothing else keeps it. r-universe read `duckdb.dev` 1.5.99.9003.1397 at 1f4b6d7 (`main-green`), on duckdb.r-universe.dev, and one of the fifteen targets failed. `macos-oldrel-x86_64` timed out after 3794 s: `##[error]The action has timed out.` at 3612765 ms of the one-hour budget, with `duckdb/ub_src_parser_peg_transformer.cpp` still compiling (<https://duckdb.r-universe.dev/api/actions/logs/102024688950>). This is the `MAKEFLAGS` cause already recorded on 16fb13c and on 59cb20f, now on its third target, and the log names it outright again: + makeflags_value='Fatal error: cannot open file '\''scripts/setup-makeflags.R'\'': No such file or directory' + export 'MAKEFLAGS=Fatal error: cannot open file ...' `configure` fills `MAKEFLAGS` in from `scripts/setup-makeflags.R`, `.Rbuildignore` lists `^scripts$`, so `R CMD build` strips the directory and no package installed from a tarball can read it; `MAKEFLAGS` is exported as the error string rather than as `-jN` and every source install from the built tarball compiles serially. duckdb#2678 moves the helper to `tools/`, which `R CMD build` keeps, and refuses a value that is not `-jN`. It has been open against `main` since 2026-08-27, so this is the third firing to pay for it; the series gets it when stage 4 ports it, never before. The consequence is a stale published binary, not a broken one: `mac-x86_64` still serves 1.5.99.9003.1396, built 2026-09-07. The `rcc` gate is Linux on one R version and compiles that target on no run, so no `each-rcc` record says anything either way. `windows-devel-arm64`, recorded on 59cb20f as the runner's rather than the tree's, is OK again on this build — one occurrence, not a pattern.
Date: 2026-09-08 10:53:21 +0000 Track I/O operation counts alongside byte counters (https://redirect.github.com/duckdb/duckdb/pull/25409) R-side fix: Nothing in the tree — one finding with no repair to carry, recorded here because nothing else keeps it. r-universe read `duckdb.dev` 1.5.99.9003.1397 at 1f4b6d7 (`main-green`), on duckdb.r-universe.dev, and one of the fifteen targets failed. `macos-oldrel-x86_64` timed out after 3794 s: `##[error]The action has timed out.` at 3612765 ms of the one-hour budget, with `duckdb/ub_src_parser_peg_transformer.cpp` still compiling (<https://duckdb.r-universe.dev/api/actions/logs/102024688950>). Not a new target and not a new cause: this is the `MAKEFLAGS` timeout recorded on 16fb13c for the same target, and on 59cb20f for `macos-release-x86_64`. The log names it outright again: + makeflags_value='Fatal error: cannot open file '\''scripts/setup-makeflags.R'\'': No such file or directory' + export 'MAKEFLAGS=Fatal error: cannot open file ...' `configure` fills `MAKEFLAGS` in from `scripts/setup-makeflags.R`, `.Rbuildignore` lists `^scripts$`, so `R CMD build` strips the directory and no package installed from a tarball can read it; `MAKEFLAGS` is exported as the error string rather than as `-jN` and every source install from the built tarball compiles serially. Which targets fall over is boundary noise; the cause is constant. duckdb#2678 moves the helper to `tools/`, which `R CMD build` keeps, and refuses a value that is not `-jN`. It has been open as a draft since 2026-08-27 and every firing since has paid for it; the series gets it when stage 4 ports it, never before. This exact read was already posted as evidence on that PR by the firing four hours earlier (duckdb#2678, comment of 2026-09-08 11:49 UTC), so this firing added no second comment — only this record, which that firing had no `-dev` commit to write. The consequence is a stale published binary, not a broken one: `mac-x86_64` still serves 1.5.99.9003.1396, built 2026-09-07. The `rcc` gate is Linux on one R version and compiles that target on no run, so no `each-rcc` record says anything either way. `windows-devel-arm64`, recorded on 59cb20f as the runner's rather than the tree's, is OK again on this build — one occurrence, not a pattern.
Date: 2026-09-08 23:12:20 +0000 perf(variant): Optimize shredded vector value retrieval (https://redirect.github.com/duckdb/duckdb/pull/25458) R-side fix: Nothing in the tree — one finding with no repair to carry, recorded here because nothing else keeps it. r-universe read `duckdb.dev` 1.5.5.9013.1412 at db79d51 (`main-fwd-green`), on krlmlr.r-universe.dev, and one of the fifteen targets failed. `macos-oldrel-x86_64` failed after 3749 s: `##[error]The action has timed out.` at the one-hour budget, with the tree still linking `duckdb.dev.so` after an hour of serial compiling (<https://krlmlr.r-universe.dev/api/actions/logs/102360114641>). This is the `MAKEFLAGS` cause already recorded on 16fb13c, 59cb20f and 7121193, now on the forward lineage, and the log names it outright again: + makeflags_value='Fatal error: cannot open file '\''scripts/setup-makeflags.R'\'': No such file or directory' + export 'MAKEFLAGS=Fatal error: cannot open file ...' `configure` fills `MAKEFLAGS` in from `scripts/setup-makeflags.R`, `.Rbuildignore` lists `^scripts$`, so `R CMD build` strips the directory and no package installed from a tarball can read it; `MAKEFLAGS` is exported as the error string rather than as `-jN` and every source install from the built tarball compiles serially. Which target falls over is boundary noise; the cause is constant. The base series is the read that shows it: `main-green` recorded this same failure on its previous build and is all-fifteen-OK on this one, while the forward — same package, same hour budget — now carries it. duckdb#2678 moves the helper to `tools/`, which `R CMD build` keeps, and refuses a value that is not `-jN`. It has been open as a draft since 2026-08-27, thirteen days, and every firing since has paid for it; the series gets it when stage 4 ports it, never before. The consequence is a stale published binary, not a broken one: `mac-x86_64` still serves 1.5.5.9013.1410, built 2026-09-08. The `rcc` gate is Linux on one R version and compiles that target on no run, so no `each-rcc` record says anything either way. The other fourteen targets are OK, `windows-devel-arm64` among them.
Date: 2026-09-09 12:05:11 +0000 Issue https://redirect.github.com/duckdb/duckdb/pull/24830: Volatile Windowing (https://redirect.github.com/duckdb/duckdb/pull/25482) R-side fix: Nothing in the tree — one finding with no repair to carry, recorded here because nothing else keeps it. r-universe read `duckdb.dev` 1.5.99.9003.1400 at b26b7ed (`main-green`), on duckdb.r-universe.dev, and one of the fifteen targets failed. `macos-oldrel-x86_64` failed after 3819 s: `##[error]The action has timed out.` at the one-hour budget, with the vendored tree still compiling one translation unit at a time (<https://duckdb.r-universe.dev/api/actions/logs/102527398737>). This is the `MAKEFLAGS` cause already recorded on 16fb13c and 7121193, on the same target as 7121193 — two consecutive builds now — and the log names it outright again: + makeflags_value='Fatal error: cannot open file '\''scripts/setup-makeflags.R'\'': No such file or directory' + export 'MAKEFLAGS=Fatal error: cannot open file ...' `configure` fills `MAKEFLAGS` in from `scripts/setup-makeflags.R`, `.Rbuildignore` lists `^scripts$`, so `R CMD build` strips the directory and no package installed from a tarball can read it; `MAKEFLAGS` is exported as the error string rather than as `-jN` and every source install from the built tarball compiles serially. duckdb#2678 moves the helper to `tools/`, which `R CMD build` keeps, and refuses a value that is not `-jN`. It has been open as a draft since 2026-08-27, thirteen days, and every firing since has paid for it; the series gets it when stage 4 ports it, never before. This firing paid it twice over: the same cause timed `macos-release-x86_64` out on the forward lineage in the same round, recorded on the `main-fwd-dev` commit for this upstream SHA, so both universes now lose a mac x86_64 target per build. The consequence is a stale published binary, not a broken one: `mac-x86_64` still serves 1.5.99.9003.1399, built 2026-09-08. The `rcc` gate is Linux on one R version and compiles that target on no run, so no `each-rcc` record says anything either way. The other fourteen targets are OK, `windows-devel-arm64` among them.
Date: 2026-09-09 12:05:11 +0000 Issue https://redirect.github.com/duckdb/duckdb/pull/24830: Volatile Windowing (https://redirect.github.com/duckdb/duckdb/pull/25482) R-side fix: Nothing in the tree — one finding with no repair to carry, recorded here because nothing else keeps it. r-universe read `duckdb.dev` 1.5.5.9013.1413 at d6613df (`main-fwd-green`), on krlmlr.r-universe.dev, and one of the fifteen targets failed. `macos-release-x86_64` failed after 3914 s: `##[error]The action has timed out.` at the one-hour budget, with the vendored tree still compiling one translation unit at a time (<https://krlmlr.r-universe.dev/api/actions/logs/102529635583>). This is the `MAKEFLAGS` cause recorded on d6613df itself one build ago, moved from `macos-oldrel-x86_64` to `macos-release-x86_64`: which of the two mac x86_64 targets falls over is boundary noise, the cause is constant, and the log names it outright again: + makeflags_value='Fatal error: cannot open file '\''scripts/setup-makeflags.R'\'': No such file or directory' + export 'MAKEFLAGS=Fatal error: cannot open file ...' `configure` fills `MAKEFLAGS` in from `scripts/setup-makeflags.R`, `.Rbuildignore` lists `^scripts$`, so `R CMD build` strips the directory and no package installed from a tarball can read it; `MAKEFLAGS` is exported as the error string rather than as `-jN` and every source install from the built tarball compiles serially. duckdb#2678 moves the helper to `tools/`, which `R CMD build` keeps, and refuses a value that is not `-jN`. It has been open as a draft since 2026-08-27, thirteen days, and every firing since has paid for it; the series gets it when stage 4 ports it, never before. This is the first round in which both lineages lost a target to it in the same firing: `main-green` timed `macos-oldrel-x86_64` out on duckdb.r-universe.dev at the same time, recorded on the `main-dev` commit for this upstream SHA. The consequence is a stale published binary, not a broken one: `mac-x86_64` still serves 1.5.5.9013.1412, built 2026-09-08. The `rcc` gate is Linux on one R version and compiles that target on no run, so no `each-rcc` record says anything either way. The other fourteen targets are OK.
|
Evidence from the 2026-09-09 series-loop firing: this is the first round in which both lineages lost a target to this cause at the same time, so the cost is now two failed r-universe builds per firing rather than one.
Both logs name the cause outright, the same line this PR fixes: Which of the two mac x86_64 targets falls over is boundary noise — Thirteen days open as a draft; the findings are recorded on 1a6fff2 ( Generated by Claude Code |
|
Evidence from the series-loop firing of 2026-09-09 20:45 UTC: the cost of this staying open has gone up again. This round r-universe lost four mac x86_64 targets across three lineages to this one cause, all timing out at the one-hour action budget with the tree still compiling one translation unit at a time:
The last is the first occurrence on the
Consequence is a stale published binary rather than a broken one — Generated by Claude Code |
Date: 2026-09-09 22:39:43 +0000 Buffer managed indexes 3 - NodePtrHandle + owning PrefixHandle + InsertIntoNode and Prefix::New rewrite (https://redirect.github.com/duckdb/duckdb/pull/23619) R-side fix: Nothing in the tree — one finding with no repair to carry, recorded here because nothing else keeps it. r-universe read `duckdb.dev` 1.5.5.9013.1414 at 418fe1b (`main-fwd-green`), on krlmlr.r-universe.dev, and one of the fifteen targets failed. `macos-release-x86_64` failed after 3830 s: `##[error]The action has timed out.` at 3612749 ms of the one-hour budget, with `src/duckdb` still compiling one translation unit at a time (<https://krlmlr.r-universe.dev/api/actions/logs/102767402040>). This is the `MAKEFLAGS` cause recorded on 78466b6 one firing ago, and the log names it outright again: ++ Rscript scripts/setup-makeflags.R + makeflags_value='Fatal error: cannot open file '\''scripts/setup-makeflags.R'\'': No such file or directory' + export 'MAKEFLAGS=Fatal error: cannot open file ...' `configure` fills `MAKEFLAGS` in from `scripts/setup-makeflags.R`, `.Rbuildignore` lists `^scripts$`, so `R CMD build` strips the directory and no package installed from a tarball can read it; `MAKEFLAGS` is exported as the error string rather than as `-jN` and every source install from the built tarball compiles serially. What is new is that this is the **same** green, the same version and the same target as the previous firing's red (3891 s, log 102612766401): r-universe rebuilt 1.5.5.9013.1414 and it fell off the hour a second time. Every earlier reading of this cause moved between targets or lineages between builds, which is what the boundary-noise reading rests on. Here it did not move, and the two lineages that did get a rebuild went the other way in the same read: `main-green` c08b31a, two mac x86_64 targets red on the previous firing, is all-fifteen-OK on 1.5.99.9003.1401, and `v1.5-variegata-green` 75a1845, red on `macos-release-x86_64` then, is all-fifteen-OK on 1.5.5.9013.35 now. So the boundary is where this target sits, not where it occasionally lands, and this lineage is the one that no longer clears the hour by chance. duckdb#2678 moves the helper to `tools/`, which `R CMD build` keeps, and refuses a value that is not `-jN`. It has been open as a draft since 2026-08-27, fourteen days, and every firing since has paid for it; the series gets it when stage 4 ports it, never before. Its open review question — inline `$(nproc)` rather than an R script, and whether that holds under Rtools — is the only thing between the loop and stopping to pay this. No further comment was added to that PR this firing: nine already carry the same evidence, the most recent of them reporting four targets across three lineages, and one target is not a new case against it. The consequence is a stale published binary, not a broken one: `mac-x86_64` still serves 1.5.5.9013.1412, built 2026-09-08, so publication on this package is now two greens behind. The `rcc` gate is Linux on one R version and compiles that target on no run, so no `each-rcc` record says anything either way. The other fourteen targets are OK.
Date: 2026-09-10 07:31:58 +0000 Merge `cyanoptera` into `main` (https://redirect.github.com/duckdb/duckdb/pull/25542) R-side fix: `patch/0036-Mark-two-assert-only-bindings-used.patch` is retired here: upstream rewrote both call sites it marked, so neither hunk has a target left. The patch answered `-Wunused-variable` on two bindings that only ever appear inside a `D_ASSERT`, which is `((void)0)` under NDEBUG. This merge rewrites `RowGroup::WriteToDisk()`'s range-based loop over `row_groups` into an index loop, so the `row_group` binding the first hunk marked no longer exists, and the assertion reads through the index instead. The second hunk's `child_entries` in `variant_unshredding.cpp` went the same way in an earlier commit and is already absent from the tree. The replay of this buffer commit conflicted on exactly that loop, on this lineage and on `main-dev` alike; the resolution takes upstream's form verbatim, so the tree here is byte-identical to the buffer's at `src/duckdb/src/storage/table/row_group.cpp`. The entry lives on the `-dev` branches only, ported from `main` (duckdb#2617) and never mirrored onto a buffer, so no vendor run could retire it by itself. R-side fix: Nothing in the tree — one finding with no repair to carry, recorded here because nothing else keeps it. r-universe read `duckdb.dev` 1.5.5.9013.1415 at 78466b6 (`main-fwd-green`), on krlmlr.r-universe.dev, and one of the fifteen targets failed. `macos-release-x86_64` failed after 3824 s: `##[error]The action has timed out.` at the one-hour budget, with `clang++` still compiling one translation unit at a time ten seconds before the cut (<https://krlmlr.r-universe.dev/api/actions/logs/102839247756>). This is the `MAKEFLAGS` cause recorded on 78466b6 and on the `main-fwd-dev` commit for `eeb0648e8`, and the log names it outright again: ++ Rscript scripts/setup-makeflags.R + makeflags_value='Fatal error: cannot open file '\''scripts/setup-makeflags.R'\'': No such file or directory' + export 'MAKEFLAGS=Fatal error: cannot open file ...' `configure` fills `MAKEFLAGS` in from `scripts/setup-makeflags.R`, `.Rbuildignore` lists `^scripts$`, so `R CMD build` strips the directory and no package installed from a tarball can read it; `MAKEFLAGS` is exported as the error string rather than as `-jN` and every source install from the built tarball compiles serially. This is the third consecutive build of this lineage to lose the same target: 1.5.5.9013.1413 (log 102529635583), 1.5.5.9013.1414 (log 102767402040), and now 1.5.5.9013.1415 — two different greens and one rebuild of a third. The previous firing read the repeat on one unchanged green as the end of the boundary-noise reading; a third round on a fresh green settles it. The other three lineages r-universe built in the same read were all-fifteen-OK: `main-green` 1a6fff2 at 1.5.99.9003.1402, `v1.5-variegata-fwd-green` ed80191 at 1.5.5.9013.35, and `v1.4-andium-fwd-green` 27c1dc0 at 1.4.5.9000.1. So the hour is only ever missed where this target sits, on this lineage. The consequence is a stale published binary, not a broken one: `mac-x86_64` still serves 1.5.5.9013.1412, built 2026-09-08, so publication on this package is now three greens behind. The two Windows targets read stale at 1.5.5.9013.1414 in the same pass, which is a build that had not finished yet rather than one that failed. The `rcc` gate is Linux on one R version and compiles that target on no run, so no `each-rcc` record says anything either way. The other fourteen targets are OK. duckdb#2678 moves the helper to `tools/`, which `R CMD build` keeps, and refuses a value that is not `-jN`. It has been open as a draft since 2026-08-27, fourteen days, and every firing since has paid for it; the series gets it when stage 4 ports it, never before. No further comment was added to that PR this firing: nine already carry the same evidence, and a third round on the same target is a longer trend rather than a new case against it.
2 participants
configurefillsMAKEFLAGSin fromscripts/setup-makeflags.R, but.Rbuildignorelists^scripts$, soR CMD buildstrips the directory and no package installed from a tarball can read it.Rscriptreports a file it cannot open on stdout and exits 2, so neither the2>/dev/nullnor the|| echo ""keeps the message out of the capture. Every source install from the built package therefore exportsand then compiles serially — the only trace being a puzzling
Setting MAKEFLAGS=Fatal error: ...line in the log.The change
tools/, whichR CMD buildkeeps (verified below), so the same path resolves in the repository and in the tarball.-jNit is meant to produce. A helper that goes missing again leavesMAKEFLAGSunset instead of exporting whatever came back.handbook/build/configuration/records both, since it owns theMAKEFLAGSknob;scripts/README.mdis regenerated and the helper'sdocs-readme.Rgroup entry drops with the file.Where it showed up
Today's series-loop firing read r-universe and found two reds, both
The action has timed out.while still compilingsrc/duckdb, and both preceded by theMAKEFLAGS=Fatal error: ...line:duckdb.dev/macos-oldrel-x86_64, 3786 s, atmain-greend794a33 — https://duckdb.r-universe.dev/api/actions/logs/98339213208duckdb.dev/macos-release-x86_64, 3812 s, atmain-fwd-greenf6f4c6b — https://krlmlr.r-universe.dev/api/actions/logs/98339480947The serial build is what puts those two targets over r-universe's one-hour budget; the other 13 targets fit either way, which is why this stayed invisible until now. No other series is affected today.
Verification
Rscript missing.RprintsFatal error: cannot open file ...on stdout and exits 2, so$(... 2>/dev/null || echo "")captures it.R CMD buildon a minimal package with^scripts$ignored keepstools/and dropsscripts/.R CMD buildon this tree shipstools/setup-makeflags.R, and./configureinside the extracted tarball setsMAKEFLAGS=-j2where it previously exported the error string.-j2and-j16; it rejects-j,-j2x, the fatal-error string, and the empty string.docs-consistencylink integrity and generated-index checks pass.Costs Linux nothing: the gate's builds set
MAKEFLAGSfrom the environment or get the same-j2they got when the helper was readable.Generated by Claude Code