Embed Notice

@libreleah Agreed that goals might be the same but approaches makes lbmk not fail on t480 because 24.12 not reused for other boards which should reuse 24.12. We're looping here.

Heads community members struggling and now passing more than 30h mentoring them understand lbmk and Heads where if patchset was ok upstream, it would be for Heads/Lbmk to do their own things as they want. Problem is, the patchset is incomplete for coreboot to review.

Anyway, putting the t480 aside, and postponing t480s until coreboot patchset under review is merged on my side, and taking note that a board can only be supported if part of a maintained coreboot fork (that is, that is not causing regressions for other boards depending on the same commit).

Heads port of t480 will stay where it is at https://github.com/linuxboot/heads/pull/1908#issuecomment-2704450527

I have not much more time to invest on this. As I said, I do not sell the t480, collaboration should happen upstream (for the bettering of the whole ecosystem) and debating lbmk/Heads buildsystem differences is out of scope of my message here, with all the others going in multiple directions as well.

If you are to invest into something to revise buildsystem buildstack, I would advise looking into StageX. I invested a lot of time into building a Nix docker image to fix reproducibility issues once and for all since Heads builds a lot of standard linux tools packed into initramfs, but StageX is working on the gnat/ADA boostrapping and once done, they will be feature complete and par with Nix for providing the proper docker image, and more (maybe even use StageX to produce libs and binaries to be packed into initramfs) without needing to build musl-cross-make, nor crossgcc buildstacks eventually; they could be packed into docker image and reproduced as needed)

Last note and repetition for clarity: each board under Heads specify a coreboot version (which corresponds to a fork/release), a linux version and configuration files for both. Then the boards are built by CI, with a dependency chain to reuse not only build stacks, but every build artifacts. This is accomplished because of the way the Make buildsystem does things, so no need for caching under coreboot by itself, all the boards will try to refresh build artifacts ad ski rebuuding them because fresh enough. This permits me to have a qube per project I work on and not waste time rebuilding anything else then initramfs which contains the scripts I work on under Heads, the rest is reused unless changed. And there is helpers in Makefile, and modules/* to clean things up if needed. Building fresh, I understand as a concept. But if reproducibility is guaranteed, is there a need to build fresh and waste CPU and disk space? Different ideologies, both valid. But once one tries to build roms on CI, one has to optimize those things because free tier builds are limiting, and Heads builds a lot of stuff.

LBMK fits LBMK needs. Heads fits Heads needs. Heads would improve by having things cached in a reproducible guaranteed cache system. It won't be Nix because Nix doesn't build things cached with muslc... But StageX does. And StageX was made with the goal of making firmware reproducibility a resolved problem.

Conference on ladt vPub: https://www.youtube.com/watch?v=9-xfccecwpo