The firmware builds against sysdrv/source/buildroot/buildroot-2025.02.8 in the
vendor SDK. That tree is not in the vendor checkout -- the SDK ships 2023.02.6 --
it was not in this manifest, and nothing anywhere recorded its origin. A clean
rebuild on another machine silently fell back to the vendor's older buildroot
and produced a different userspace, which is flare-edge#135.
fetch-buildroot-tarball.sh follows fetch-kernel-tarball.sh exactly: pinned URL,
pinned sha256, fails closed on a missing pin. Buildroot signs releases with GPG
rather than publishing a .sha256, so the pin was computed from the tarball and
is what the script verifies against.
The manifest now says out loud that two of the inputs are tarballs rather than
git trees, so "which buildroot" has an answer in the same place as "which LVGL".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T2D2KtdgwbhbF6Mo64eUrn
LVGL and the vendor RV1106 SDK are what this platform is built against, and
nothing in this repo said WHICH ones. The two live outside every worktree as
shared checkouts, so "the version we build against" was whatever happened to be
on the machine.
They are pinned here now, by exact commit, with one script that obtains and
verifies them. Not copied: between them they are ~21 GB, the vendor SDK bakes
absolute paths into its host tools so it has to sit at one stable path anyway,
and a 21 GB git repo would be unusable while still not making anything
reproducible. What makes a build reproducible is knowing exactly which tree was
used, which is a commit id -- the same reasoning build/fetch-kernel-tarball.sh
already applies to the kernel, where a sha256 pin stands in for vendoring the
tarball.
Two behaviours worth stating, because both were wrong in the first draft:
- A checkout is detected by `.git` EXISTING, not by it being a directory. LVGL
is checked out as a worktree here, where `.git` is a file.
- Local modifications are reported and are NOT a failure. The vendor SDK is
supposed to carry them -- tools/build-firmware.sh applies our sdk-patches
series into that tree on every build -- so a pristine checkout is the
unusual state. Only a MISSING or DRIFTED tree fails.
Nothing is ever reset automatically: a tree off its pin is reported, because a
local change to a vendor tree is usually someone mid-debug, not something to
throw away on their behalf.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T2D2KtdgwbhbF6Mo64eUrn
