Repository navigation
build: three fixes to the attach/updiff machinery - #333
Merged
Merged
Conversation
Found while bringing up rpi4_64 in the opencn-ng tree; all three are
generic to this build system, so they come here unchanged.
1. patch_identifier() now normalises a leading "./".
do_updiff matches a staged patch to the series by the path in the patch
header. Staged patches carry git-style "+++ b/<rel>"; patches generated
years ago by a plain `diff` run from the target directory carry
"+++ ./<rel>". The two never compared equal, so every existing patch
looked unmatched and updiff appended a duplicate for every file it saw
-- 25190 patches onto a series of 33, reported as success.
This is not hypothetical here: 3872 patches in this tree still carry the
"./" form. Any updiff on one of those recipes would have done the same.
2. do_updiff refuses a runaway.
do_diffcompose compares the pristine snapshot against IB_TARGET, which
is a working tree the user may have run `make` in, and the artefact
exclusion list is a blacklist. A single `build.sh uboot` was measured
leaving 49 files it does not name. Above IB_UPDIFF_MAX_NEW (20) new
files the task now fails and prints the two commands that fix it,
instead of writing the series.
3. do_check_attach refuses a tree attached by another recipe.
IB_TARGET is a path in the source tree and more than one recipe can
claim it: uboot_2022.04 and uboot_2024.07 both attach to u-boot/,
selected by PREFERRED_VERSION per platform. The attach is stamped per
recipe, so after building platform A and switching to B, B finds its own
stamp from an earlier session, skips the attach, and configures A's
sources.
It failed loudly once (rpi4_64_defconfig missing in a 2024.07 tree) and
silently once: a virt64 image built with U-Boot 2022.04 instead of
2024.07, differing in CONFIG_POSITION_INDEPENDENT, so ATF loaded BL33 at
0x60000000 and jumped into a binary linked for 0x0 -- no output, no
error, a whole secure boot chain to bisect.
do_attach_infrabase now records the owning PF in ${IB_TARGET}.attach.pf
and a nostamp do_check_attach refuses on mismatch. It refuses rather
than re-attaching: that deletes a tree the user may have edited outside
the patch series, which is their call, as with IB_FORCE_ATTACH. A tree
with no marker predates this and is adopted silently.
A parse-time variant that dropped the stale stamp was tried first and
removed: the message printed but bitbake had already settled the
runqueue and built the wrong tree anyway. The check has to be a task.
Verified: all recipes parse, and the guard was exercised both ways in
the originating tree.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
do_patch drives quilt, which leaves its working state in ${S}: patches/
+ patches/series (the stack) and .pc/ (a pristine copy of every file each
patch touches, so `quilt pop` can undo it). do_attach_infrabase copies
${S} wholesale into IB_TARGET, so that staging lands there too, and then
records a sha256 of every file it wrote.
Recording build products in that manifest turns the dirty-guard against
itself: quilt regenerates them on the next do_patch, the checksums no
longer match, and the guard refuses to re-attach a perfectly clean tree.
This tree's u-boot manifest currently carries 55 such entries.
Pruned on write, and also filtered on the check so manifests recorded
before this fix stop blocking. `|| true` because grep exits 1 when it
filters everything away and bitbake runs shell tasks under `set -e`.
Already present in infrabase, pos_sol and opencn-ng; this brings the
tree in line.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
daniel-rossier
force-pushed
the
align/attach-updiff-guards
branch
from
September 15, 2026 16:29
a73375c to
1baa6af
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three fixes to the attach/updiff machinery, found while bringing up rpi4_64 in the opencn-ng tree. All generic to this build system.
1.
patch_identifier()normalises a leading./do_updiffmatches a staged patch to the series by the path in the patch header. Staged patches carry+++ b/<rel>; patches generated years ago by a plaindiffrun from the target directory carry+++ ./<rel>. The two never compared equal, so every existing patch looked unmatched and updiff appended a duplicate for every file it saw — 25190 patches onto a series of 33, reported as success.Not hypothetical here — patches still carrying the
./form: so3 233, micofe 265 (infrabase 3872, pos_sol 247). Anyupdiffon one of those recipes would have done the same.2.
do_updiffrefuses a runawaydo_diffcomposecompares the pristine snapshot againstIB_TARGET, a working tree the user may have runmakein, and the artefact exclusion list is a blacklist. A singlebuild.sh ubootwas measured leaving 49 files it does not name. AboveIB_UPDIFF_MAX_NEW(20) the task now fails with the recovery commands instead of writing the series.3.
do_check_attachrefuses a tree attached by another recipeuboot_2022.04anduboot_2024.07both attach tou-boot/, selected byPREFERRED_VERSIONper platform, and the attach is stamped per recipe. Switching platform makes the second recipe find its own stamp, skip the attach, and configure the first one's sources.Failed loudly once (
rpi4_64_defconfigmissing in a 2024.07 tree) and silently once: a virt64 image built with U-Boot 2022.04 instead of 2024.07. The two differ inCONFIG_POSITION_INDEPENDENT, so ATF loaded BL33 at0x60000000and jumped into a binary linked for0x0— no output, no error, a whole secure boot chain to bisect.do_attach_infrabasenow records the owningPFin${IB_TARGET}.attach.pf; a nostampdo_check_attachrefuses on mismatch rather than re-attaching, since re-attaching deletes a tree the user may have edited outside the patch series (same reasoning asIB_FORCE_ATTACH).A parse-time variant that dropped the stale stamp was tried first and removed: the message printed but bitbake had already settled the runqueue and built the wrong tree anyway. The check has to be a task.
Not included here: the
do_prepare_initrddependency change that went to infrabase and opencn-ng. This tree'susr-linuxbbappend makesdo_deploya build step that bakes the apps intorootfs.cpioand depends on${IB_ROOTFS_METHOD}:do_build— the dependency is correct here and the initrd legitimately carries the apps.Verified: all recipes parse; the guard was exercised both ways in the originating tree.
🤖 Generated with Claude Code