<div dir="ltr">Is using the last commit really that useful?<div><br></div><div>I would like to be able to compare 2 subsequent builds (ideally performed on 2 different hosts with some small modification in metadata layers) and the binaries not affected by those small metadata modifications should be the same - which is not the case if we feed them with the top commit date.</div><div><br></div><div>The real world use-case is that we&#39;re doing daily official builds (which don&#39;t use sstate for some bad reasons) and just comparing files-in-image.txt file from buildhistory shows that almost all binaries are different every day (just their size fluctuating +- 2 bytes from the linker mangling) and when something goes wrong, it&#39;s hard to find &quot;the significant diff&quot; when it&#39;s always all different even when the 2nd build only had very small change in image recipe.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 25, 2017 at 8:14 PM, Juro Bystricky <span dir="ltr">&lt;<a href="mailto:juro.bystricky@intel.com" target="_blank">juro.bystricky@intel.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This patch set contains several patches aimed to achieve reproducible binaries.<br>
Building reproducible binaries may remove certain intentional<br>
randomness intended for increased security. Hence, it is reasonable<br>
to expect there will be cases where this is not desirable.<br>
The user can select his/her preferences via the variable<br>
BUILD_REPRODUCIBLE_BINARIES. The variable defaults to &quot;0&quot; (do not<br>
build reproducible binaries) in order to minimize any potential<br>
regressions. (Once the reproducible binaries code is mature enough,<br>
it can be set to &quot;1&quot;.)<br>
<br>
The patch set is rather simple, targeting the &quot;low hanging fruit&quot;.<br>
For debian packages we get a lot of binary identical packages simply by<br>
exporting SOURCE_DATE_EPOCH.<br>
For rootfs we get much fewer differences by modified prelinking and by<br>
ensuring various timestamps are reproducible.<br>
<br>
<br>
Juro Bystricky (4):<br>
  bitbake.conf: new variable BUILD_REPRODUCIBLE_BINARIES<br>
  base.bbclass: initial support for binary reproducibility<br>
  image-preling.bbclass: support binary reproducibility<br>
  rootfs-postcommands.bbclass: support binary reproducibility<br>
<br>
 meta/classes/base.bbclass                | 82 ++++++++++++++++++++++++++++++<wbr>++<br>
 meta/classes/image-prelink.<wbr>bbclass       |  9 +++-<br>
 meta/classes/rootfs-<wbr>postcommands.bbclass | 18 ++++++-<br>
 meta/conf/bitbake.conf                   |  3 ++<br>
 4 files changed, 109 insertions(+), 3 deletions(-)<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
2.7.4<br>
<br>
--<br>
______________________________<wbr>_________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.<wbr>openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/openembedded-<wbr>core</a><br>
</font></span></blockquote></div><br></div>