v6.2.5: make the release tree buildable from a fresh clone again - #315
Merged
Conversation
The v6.2.4 release left SO3_KERNEL_VERSION_FALLBACK at 6.2.3 — the value version.h itself asks to keep in sync with the release tag. Harmless on a git checkout (so3version.sh derives the real version from the tag), but a build from a tree without git metadata (tarball, bitbake workdir copy) banners the previous release. (cherry picked from commit 19228ca)
The tree-wide e-mail alignment (#309) ran over a working tree that carried the lvgl build outputs and committed 37 of them: lib/lv_conf.h, the lib/slv/ sources, the quilt staging directory usr/patches/ and the materialized src/{fillfb,lvgl_*}.c. All of these are created by the lvgl patch set at build time, so on a fresh clone do_patch now finds its own outputs already present and dies on the very first patch ('would create lib/lv_conf.h, which already exists') — the Build workflow has been red since that merge, on every branch. Remove them and gitignore the whole family so they cannot be committed again. Note the v6.2.4 tag carries the broken state: a fresh clone of the tag needs these paths cleaned before usr-so3 builds. (cherry picked from commit bf85716)
Both workflows only triggered on main, yet tags are cut on release/vX.Y — the very commits a release points at were the only ones never built. Add release/** to the push and pull_request triggers so a patch release is validated before it is tagged, and document the pre-tag check in release_process.rst (the Docs workflow already runs on every ref). (cherry picked from commit ee3469c)
Keep SO3_KERNEL_VERSION_FALLBACK in sync with the tag being cut, as version.h asks: a build from a tree without git metadata (tarball, bitbake workdir copy) banners this constant.
musl.libc.org is a single host with no mirror rotation. When it goes down - timeouts, then 'Unable to establish SSL connection', observed today on both CI platforms and from outside CI - musl-cross-make cannot fetch musl-1.2.5.tar.gz and the toolchain build dies after two minutes, on every branch, with no way to retry around it. Point MUSL_SITE at the MacPorts distfiles mirror, which carries the exact upstream tarball; the sha1 check musl-cross-make runs on every download is what keeps this honest (the mirrored tarball matches hashes/musl-1.2.5.tar.gz.sha1). Same treatment GNU_SITE already received for the same class of failure.
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.
Patch release on the 6.2 line, cut on
release/v6.2perrelease_process.rst. It fixes the release plumbing itself — thev6.2.4tree cannot be built from a fresh clone at all.usr/lib/lv_conf.h,usr/lib/slv/, the quilt staging dirusr/patches/, the generatedusr/src/{fillfb,lvgl_*}.c). On a fresh clone the lvgl patch set then finds its own outputs already in place anddo_patchdies on the very first patch. Local incremental trees never saw it — only fresh clones and the CI, red since 17 July.release/vX.Y, yet the workflows only ran onmain: the very commits a release points at were the only ones never built. This PR is the first release commit set actually validated by CI before tagging.SO3_KERNEL_VERSION_FALLBACKis what a gitless build (tarball, bitbake workdir copy) banners;v6.2.4shipped it still reading6.2.3.The dbuild build container (#312) deliberately stays on
main: it is a feature, not a patch-release fix.Tag
v6.2.5follows once this is green and merged.