nfeske
commented
1 year ago I'm afraid, this risk generally exists for ported software that relies on code generated at build time. As long as not all code-generating tools are covered by Genode's tool chain, the risk of host tools producing different output depending on the host OS will prevail.
Possible solutions would be adding those tools to Genode's tool chain (which would not be natural because genuine Genode components do in fact not need them), or hosting offline-generated output of these tools by ourselves (obfuscating the connection between upstream source and Genode's version, inflating our repository with generated data, complicating future updates of 3rd-part software).
Personally, I find these directions more troublesome than the current situation. Therefore, I think is not worth chasing reproducible hashes between vastly different host-OS versions and would like close this issue.
Note that for reproducing a concrete version of Sculpt OS from source, this problem does not exist because all sources are obtained (as a stable snapshot) from depot.genode.org via the depot/download tool. So the prepare_ports tool is not part of the picture.
chelmuth
Discovered in the dde_linux/wifi port (fixed easily in 515a44da7ab570688403e18291d81fa42545a543) dynamic generation of files on port prepration breaks the reproducibility of depot-archive hashes at least with tools like bison and flex which generate different output files in varying versions (e.g., including the tool version in the generated files). As a result the port is still usable directly from a build directory but depot archives generated from this port produce different hashes/versions. We will experience this in the near future when upgrading from Ubuntu 16.04 to 18.04 or any recent alternative.
A first grep uncovered mesa and qt5 as flex/bison users. Note, we fixed a similar issue in libc with aec4f0db2ddcb89e7f7cdb62bdfed747500c6f2e.