DO NOT MERGE: skeleton docker support

[aesrentai]

Essentially a tech demo that does absolutely nothing but throw the current build process, cross compilers and all, into a docker image. It doesn't pin dependencies or use snapshots of the debian repos, but this isn't supposed to be merged anyways. I'll see if I can replace parts of the build system, notably the cross compiler, with prebuilt binaries (verifying the hash ofc).

There's an issue where all files created by this docker image are owned by root, but I was too lazy to fix that. Just make sure to chown -R the relevant directories.

Usage:
To build the docker container: cd reproducible-builds && docker build -t heads .
To compile heads, from the root directory: docker run --rm -v $(pwd):/project -w /project heads make BOARD=whatever

Also, is there a reason install/bin and install/sbin contain a bunch of files not needed for the build process such as gpg and kexec? They're clearly not the binaries going into the initrd since the hashes don't match but there's no reason for the build process to need gpg.

[tlaurion]

Also, is there a reason install/bin and install/sbin contain a bunch of files not needed for the build process such as gpg and kexec?

Not sure I understand the question here unless a part of Makefiles logic was misinterpreted.
When building modules, install dir is the destination specified and passed to modules for make install, so everything modules (bin and libs) are copied there at install (not really useful but for dynamic linking, since depedencies build libraries first which modules binaries depend on are linked to libraries there).

You have to refer to global Makefile to understand the logic of what is actually compiled, "installed" and actually, what is packed into initrd.

You can see calls to the strip musl-cross binaries from global Makefile, where modules output (in build/subdir are the origin of what is stripped and packed into initrd, not from install dir) This is the "magic" that happens behind the scene to guarantee that what is packed under initrd is reduced to its smallest stripped footprint prior of being XZ compressed.

Stripping of binaries prior of initrd packing happens here under master currently:
https://github.com/osresearch/heads/blob/bf415a8d693699ba3048c78b65455634ff8b7c9b/Makefile#L404-L420

They're clearly not the binaries going into the initrd since the hashes don't match but there's no reason for the build process to need gpg.

Short version: modules compilation install dir is install where binaries and libraries origin are specified under output statements of modules. That output of modules is being stripped prior of being packed into initrd, which is why you will see discrepancies between hashes of what is under install dir and what is under hashes (which matches what is seen from under Heads perspective).

Yet again, gpg being installed through apt is an old age artifact of the time where Heads was using generic-init without gpg-gui.sh/oem-factory-reset scripts, and where instructions were telling how to generate and inject public key into rom prior of flashing.

Consequently, qemu, gpg and some other tools are part of the toolstack to be installed on OS, simply to facilitate non-duplication of documentation for end-users/developers and CIs. That might need some cleanly after the buildstack problem is resolved.

@aesrentai makes sense?