Name the end of the pipeline that actually broke

[frangarcj]

Windows failed twice this month at the same line of create-core-package.sh, and both logs said the same thing:

bin/makepkg.conf: Write error: Broken pipe

That is bsdtar, naming whatever file it happened to be reading when its output closed. The file was fine. What broke was the other end — most likely xz, killed for memory during a silent three-minute -9 over the core payload — and a process the kernel kills leaves no message at all, so nothing in the log was ever about it.

Under pipefail the failing status surfaces. The text does not: it belongs to whichever element noticed first, and that is never the one that died.

What changes

Both compression pipelines — the .MTREE one through gzip and the package one through xz — capture PIPESTATUS and hand it to report_pipeline, which names every element that failed and reads a status above 128 as the signal it is.

The status the caller sees is unchanged. report_pipeline returns the last failing one, which is exactly what pipefail would have handed up, so anything reading 137 out of this keeps reading 137. It says more, not something else.

Simulated

An xz on PATH that dies mid-write, against tests/package/test-core-package.sh in ubuntu:24.04:

	output	exit
master	: Write error, plus a job-control dump	137
this branch	packaging vdpm-…pkg.tar.xz: bsdtar exited 1 packaging vdpm-…pkg.tar.xz: xz killed by signal 9	137

The first poison I wrote drained its input before dying, which let bsdtar finish and produced a different signature — worth saying, because the faithful one has to die while bsdtar is still writing, which is what an OOM kill does.

Test

tests/ci/test-pipeline-report.sh drives the function the script defines, extracted with sed the way test-host-runner.sh already does, rather than a copy of it:

• nothing failed → says nothing, succeeds
• the compressor killed for memory → named, with signal 9
• the upstream elements that took the SIGPIPE → reported too, so the consequence is visible alongside the cause
• an ordinary non-zero exit → reported as an exit, not as a signal
• an element past the names given → still reported, by position
• the last failing status → preserved

One thing worth noting

tests/ci/test-empty-array-expansion.sh caught this change before it ran anywhere:

these expansions die on macOS bash 3.2 when the array is empty;
write ${name[@]+"${name[@]}"} instead:

scripts/create-core-package.sh:213:  statuses=("${PIPESTATUS[@]}")

PIPESTATUS is never empty after a pipeline, so this would not have failed in practice — but the rule was made mechanical on purpose after #168, and the guard doing its job on new code is the point of it. Fixed rather than exempted.

All 10 CI tests pass; tests/package/test-bootstrap-archive.sh and the packaging half of test-core-package.sh pass in a Linux container (its pacman step needs a docker this one does not have).

---

AI tools were used in preparing this PR (Claude Opus 5, Anthropic).