<div dir="ltr"><div>Thank you everyone for the positive feedback!</div><div><br></div><div>Yes, you can now find the source code repository for Dettrace under:<a href="https://github.com/dettrace/dettrace" target="_blank"> https://github.com/dettrace/dettrace<br></a></div><div>(I have submitted several pull requests to polish some details and update the README so check those out as well).</div><div><br></div><div>> However, it's clear that some builds may be difficult to make reproducible through other techniques; using DetTrace to resolve many of the remaining ones. Does that sound like a reasonable way to use DetTrace?</div><div>Yes that is one of the intended uses for Dettrace. Dettrace aims for 100% determinism guarantee which is overkill in many cases, as Dettrace is extremely paranoid of sources of nondeterminism. For example, we handle process and (somewhat) thread scheduling, even though these are unlikely to be sources of irreproducibility. An ideal system, would disallow us to selectively turn off some of the determinism enforcement Dettrace does.</div><div>Handling Java or other managed languages fails due to our imperfect or nonexistent treatment of timers, proper thread sequentialization, and interprocess signals. I believe turning this off would still provide reproducibility 99% of the time while still supporting Java and others.</div><div><br></div><div>> I would like to see a day where language package managers will flag as "dangerous" any packages that cannot be reproducibly built</div><div>I'm quite a fan of Rust and its package manager: Cargo. I would love to see such a system integrated into Cargo one day.<br></div><div><br></div><div>> It seems to me that this could also be used to run minification & generate language-level packages - correct?</div><div>I'm afraid I'm not familiar with minification here as it relates to language-level packages and reproducibility?</div><div><br></div><div>> If the "starting date" is arbitrary (like Jan 1, 1970) that would look odd. But if the "starting date" were forcibly set to a human-reasonable value (like the date-time of the last commit, or of the latest source file), then it might be easier to accept the results. Has that been considered?</div><div>Currently the date is arbitrarily set to a default, and as you pointed out "ticks" up on every system call to give the illusion of increasing time. A command line option in Dettrace does allow setting a user defined date:</div><div> --epoch arg Set system epoch (start) time. Accepts<br> `yyyy-mm-dd,HH:MM:SS` (utc). The default is `1993-08-08,22:00:00`.<br> Also accepts a `now` value which permits<br> nondeterministically setting the initial system time to the host<br> time. <br></div><div><br></div><div>> like the date-time of the last commit, or of the latest source file</div><div><br></div><div>I had not considered these personally but both would make a lot of sense and are probably better choices than the default constant we picked, thanks!</div><div><br></div><div>> <code>SOURCE_DATE_EPOCH</code></div><div><code><font face="arial,sans-serif"><span style="font-family:arial,sans-serif">Admittedly, I wasn't aware of <code><span style="font-family:arial,sans-serif">SOURCE_DATE_EPOCH, this too makes a good target for the starting date. At the same time, Dettrace was designed to make arbitrary computation deterministic. So while the implementation works especially well for Debian packages, the methods are Distro and package manager agnostic. We could take advantage of distro/package-manager specific features like </span><code><span style="font-family:arial,sans-serif">SOURCE_DATE_EPOCH for an easier user experience.<br></span></code></code></span></font></code></div><div><code><font face="arial,sans-serif"><span style="font-family:arial,sans-serif"><code><code><span style="font-family:arial,sans-serif"><br></span></code></code></span></font></code></div><div><code><font face="arial,sans-serif"><span style="font-family:arial,sans-serif"><code><code><span style="font-family:arial,sans-serif">Omar<br></span></code></code></span></font></code></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 5, 2020 at 8:57 PM Chris Lamb <<a href="mailto:lamby@debian.org">lamby@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Vagrant,<br>
<br>
> > This was curious to me too — to wit, the paper describes that the Debian<br>
> > «wheezy» distribution was being built so it was interesting to me that<br>
> > the first timestamp in the debian/changelog was not chosen, á la<br>
> > SOURCE_DATE_EPOCH.<br>
> <br>
> If I recall correctly, wheezy was chosen precisely because it had *less*<br>
> reproducibility fixes ... so that they could more easily tell how much<br>
> dettrace solved...<br>
<br>
Apologies if my previous email was in any way ambiguously phrased as it<br>
appears you have accidentally misparsed it.<br>
<br>
My query was not regarding why an *older* Debian distribution was<br>
chosen (you are correct in your analysis) but rather that given that<br>
*any* Debian release was chosen, the canonical timestamp was not taken<br>
from debian/changelog.<br>
<br>
<br>
Regards,<br>
<br>
-- <br>
,''`.<br>
: :' : Chris Lamb<br>
`. `'` <a href="mailto:lamby@debian.org" target="_blank">lamby@debian.org</a> 🍥 <a href="http://chris-lamb.co.uk" rel="noreferrer" target="_blank">chris-lamb.co.uk</a><br>
`-<br>
</blockquote></div>