<div dir="ltr">Okay I added text that I believe handles your suggestions.  I also just pasted some text from the .buildinfo documentation into the part of the paper where we will eventually talk about what is and is not a good way to think about non-determinism.  <div><br></div><div>We'll need to reformat it later, but it seems to make the most sense there with the paper's current organization.</div><div><br></div><div>Justin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 15, 2017 at 4:21 PM, Justin Cappos <span dir="ltr"><<a href="mailto:jcappos@nyu.edu" target="_blank">jcappos@nyu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, May 15, 2017 at 11:40 AM, Ximin Luo <span dir="ltr"><<a href="mailto:infinity0@debian.org" target="_blank">infinity0@debian.org</a>></span> wrote:<br></span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Justin, could you add me to the repo? My github username is infinity0.<br>
<br>
As a note for others, on Debian you need to install the "texlive-science" package for "make" to work.<br>
<br>
I'm not sure about this part:<br>
<br>
> [..] We propose a more precise goal, specifi-<br>
> cally dictating *where* reproducible build bugs should be fixed<br>
> rather than just focusing on the goal of making builds re-<br>
> producible. [..]<br>
<br>
This is nice as an ideal goal, but I didn't think we're ready for it yet. I don't see this expanded in the rest of the paper though. Did you have some more concrete ideas towards it?<br></blockquote><div><br></div></span><div>I don't really have concrete ideas, but the paper really needs to be about *something*.  I thought that it was interesting to claim it is bad to either change the build environment (i.e., running in a VM / container) or doing some post processing steps.  We could argue for changing the source code of the build systems, which seems the much harder way to solve the problem.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regarding SOURCE_DATE_EPOCH, it should be noted that it's somewhat of a "compromise" solution. The general motivation is described here:<br>
<br>
<a href="https://wiki.debian.org/ReproducibleBuilds/StandardEnvironmentVariables" rel="noreferrer" target="_blank">https://wiki.debian.org/Reprod<wbr>ucibleBuilds/StandardEnvironme<wbr>ntVariables</a><br>
<br>
You should probably also mention buildinfo files, and how they differ from things like Dockerfiles which I briefly touched upon in the other thread, "Regarding Zero Install manifests". The general motivation is described here:<br>
<br>
<a href="https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles" rel="noreferrer" target="_blank">https://wiki.debian.org/Reprod<wbr>ucibleBuilds/BuildinfoFiles</a><br>
<br>
and in slightly-more precise theoretical terms here:<br>
<br>
<a href="https://anonscm.debian.org/cgit/reproducible/buildinfo-spec.git/tree/notes/buildinfo.rst" rel="noreferrer" target="_blank">https://anonscm.debian.org/cgi<wbr>t/reproducible/buildinfo-spec.<wbr>git/tree/notes/buildinfo.rst</a><br>
<br></blockquote><div> </div></span><div>These sound like great things to add / correct.  Do you want to take a stab at the text?  I could do so also, but it will be a few days...</div><div><br></div><div>(If you do edit, feel free to just push your changes to master when you are done.)</div><div><br></div><div>Thanks,</div><div>Justin</div></div></div></div>
</blockquote></div><br></div>