Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pin musl-cross-git to a particular commit for reproducible builds #498

Closed
strugee opened this issue Dec 14, 2018 · 4 comments
Closed

Pin musl-cross-git to a particular commit for reproducible builds #498

strugee opened this issue Dec 14, 2018 · 4 comments

Comments

@strugee
Copy link
Contributor

strugee commented Dec 14, 2018

While patching musl-cross it came to my attention that Heads' build script just clones the latest git commit. This seems like a problem for reproducible builds? Especially since upstream can break our build. In fact I first noticed this because I pushed a commit to my fork (which I patched Heads to pull from) and my Heads build started failing because patching the musl-cross config file failed.

strugee added a commit to strugee/heads that referenced this issue Dec 14, 2018
Fixes upstreams potentially being able to break our builds, and also
makes builds more deterministic which helps with reproducible builds.

Fixes linuxboot#498
@strugee
Copy link
Contributor Author

strugee commented Dec 14, 2018

Note that I just pulled the latest commit from GitHub for all of these, which I assume is the right thing to do?

strugee added a commit to strugee/heads that referenced this issue Feb 11, 2019
Fixes upstreams potentially being able to break our builds, and also
makes builds more deterministic which helps with reproducible builds.

Fixes linuxboot#498
@tlaurion
Copy link
Collaborator

Discussion follows in pull request

@tlaurion
Copy link
Collaborator

tlaurion commented Apr 13, 2019

@strugee : any base Makefile change proposition to pull the code upon detected git changes instead? That would do it IMHO.

Doing so, a CI build would notify CI owner of any conflict that needs to be fixed since the builds would fails in case a patch that cannot be applied (thinking of this for example). Would guarantee that builds come from latest versions available and make them reproducible without having a high maintenance cost, since git dependent modules are stable. The situation would be different for coreboot module switching to git, on which I would agree with you with the necessity of pinning to a specific commit.

Else each build actually has a commit id in the build under /etc/config , and each build CI build log will have /build/$BOARD/hashes.txt file permitting to find reproducibility error source once #457 is merged.

Let me know what you think.

@tlaurion
Copy link
Collaborator

#567 seems to be the solution for this.
@strugee ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants