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

build: introduce buildinfo files for reproducibility #2121

Closed
wants to merge 1 commit into from

Conversation

aparcar
Copy link
Member

@aparcar aparcar commented Jun 13, 2019

generate feeds.buildinfo and commit.buildinfo in build dir after
containing the feed revisions (via ./scripts/feeds list -sf) as well as
the current revision of buildroot (via ./scripts/getver.sh).

With this information it should be possible to reproduce any build,
especially the release builds.

Usage would be to move feeds.buildinfo to feeds.conf and git checkout the
revision hash of commit.buildinfo.

Content of feeds.buildinfo would look similar to this:

src-git routing https://git.openwrt.org/feed/routing.git^bf475d6
src-git telephony https://git.openwrt.org/feed/telephony.git^470eb8e
...

Content of commit.buildinfo would look similar to this:

commit=r10203+1-c12bd3a21b

Without the exact feed revision it is not possible to determine
installed package versions.

Also rename config.seed to config.buildinfo to follow the recommended
style of https://reproducible-builds.org/docs/recording/

Signed-off-by: Paul Spooren mail@aparcar.org

@aparcar
Copy link
Member Author

aparcar commented Jun 13, 2019

@h01ger @lynxis

Makefile Outdated
@@ -92,6 +92,8 @@ checksum: FORCE
diffconfig: FORCE
mkdir -p $(BIN_DIR)
$(SCRIPT_DIR)/diffconfig.sh > $(BIN_DIR)/config.seed
echo "# buildroot $$(git --git-dir $(TOPDIR)/.git rev-parse HEAD)" > $(BIN_DIR)/feeds.seed
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that this may fail if buildroot does not reside in Git (which is something we do support at least for releases). This can for example happen if you download a release tarball from the Github release page - such a tarball will come without any metadata.

Maybe it would be better to use the output of ./scripts/getver.sh instead which is able to cope with such a situation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From my POV it's not diffconfig target anymore, you're as well adding feeds config and build config which are probably separate things.

So this probably should be something like:

buildconfig: FORCE
    echo "commit=$$(git --git-dir $(TOPDIR)/.git rev-parse HEAD)" > $(BIN_DIR)/build.seed

feedsconfig: FORCE
   $(SCRIPT_DIR)/feeds list -fs >> $(BIN_DIR)/feeds.seed   

prepare: .config $(tools/stamp-compile) $(toolchain/stamp-compile)
	$(_SINGLE)$(SUBMAKE) -r diffconfig feedsconfig buildconfig

so you can then just source build.seed in some script/make target and simply use it, without any additional parsing. And I think, that it's likely, that we (or downstream projects) might need to add also other variables to the build.seed in order to provide enough information for reproducible builds.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Switched to using getver.sh and introduced buildconfig and feedsconfig.

@h01ger
Copy link

h01ger commented Jun 13, 2019 via email

@aparcar aparcar changed the title build: introduce feeds.seed for reproducibility [RFC]build: introduce feeds.seed for reproducibility Jun 13, 2019
@aparcar aparcar force-pushed the feeds-seed branch 3 times, most recently from cb0be9f to 74ee4f6 Compare June 13, 2019 14:47
@aparcar aparcar changed the title [RFC]build: introduce feeds.seed for reproducibility [RFC]build: introduce buildinfo files for reproducibility Jun 13, 2019
@aparcar
Copy link
Member Author

aparcar commented Jun 13, 2019

Talking with @h01ger I decided to rename all files required for reproducibility to +.buildinfo as described here.

config.seed is now config.buildinfo, however that shouldn't bother to much as it's also changed in the make menuconfig.

@h01ger
Copy link

h01ger commented Jun 13, 2019 via email

@dedeckeh dedeckeh added RFC pull request ready for comments build/scripts/tools pull request/issues for build, scripts and tools related changes labels Jun 15, 2019
@aparcar
Copy link
Member Author

aparcar commented Jun 15, 2019

I’d very much see this merged. Once merged I can create a rebuild tool to verify not only release builds but also user builds offered in the OpenWrt forum.

@aparcar aparcar changed the title [RFC]build: introduce buildinfo files for reproducibility build: introduce buildinfo files for reproducibility Jun 19, 2019
@aparcar
Copy link
Member Author

aparcar commented Jun 21, 2019

@lynxis ping 🦆

@aparcar
Copy link
Member Author

aparcar commented Jul 2, 2019

@h01ger could you please check the script I attached? Would be very happy this gets merged

@h01ger
Copy link

h01ger commented Jul 6, 2019 via email

[ -z "$COMMIT" ] && exit 1

[ -d "$REBUILD_DIR/openwrt" ] || \
git clone https://github.com/openwrt/openwrt.git "$REBUILD_DIR/openwrt/" --depth 1
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't the URL come from buildinfo was well instead of hard-coding it here? Then at least you'd know that a certain binary is based on a different tree (there are a lot of forks of OpenWrt, vendor SDKs, ...)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And wouldn't be https://git.openwrt.org/openwrt/openwrt.git better anyway?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dangowrt the rebuild.sh is just a "proof of concept", to be later used in a CI or something. However, it seems like a good idea to store the origin source in buildfiles. What would you suggest?

@aparcar
Copy link
Member Author

aparcar commented Jul 31, 2019

The rebuild.sh is more of a proof of concept but a tool to be really added. As this PR is cherry-picked anyway, only the first commit should be picked. I'd be happy to see some progress here, once done I'd work together with @h01ger to integrate in in their CI.

@h01ger
Copy link

h01ger commented Jul 31, 2019 via email

@aparcar
Copy link
Member Author

aparcar commented Jul 31, 2019

then split this commit in two?

Done

generate feeds.buildinfo and version.buildinfo in build dir after
containing the feed revisions (via ./scripts/feeds list -sf) as well as
the current revision of buildroot (via ./scripts/getver.sh).

With this information it should be possible to reproduce any build,
especially the release builds.

Usage would be to move feeds.buildinfo to feeds.conf and git checkout the
revision hash of version.buildinfo.

Content of feeds.buildinfo would look similar to this:

    src-git routing https://git.openwrt.org/feed/routing.git^bf475d6
    src-git telephony https://git.openwrt.org/feed/telephony.git^470eb8e
    ...

Content of version.buildinfo would look similar to this:

    r10203+1-c12bd3a21b

Without the exact feed revision it is not possible to determine
installed package versions.

Also rename config.seed to config.buildinfo to follow the recommended
style of https://reproducible-builds.org/docs/recording/

Signed-off-by: Paul Spooren <mail@aparcar.org>
@dangowrt
Copy link
Member

Cherry-picked onto master (a while ago).

@dangowrt dangowrt closed this Aug 22, 2019
@aparcar aparcar deleted the feeds-seed branch June 19, 2021 23:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build/scripts/tools pull request/issues for build, scripts and tools related changes RFC pull request ready for comments
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants