<html><head></head><body><div>On Mon, 2015-11-02 at 10:45 +0100, Paul Gevers wrote:</div><blockquote type="cite"><pre>Hi all,
You may have noticed that in the last couple of upload of our packages,
I have been working on getting our tools to build reproducible¹.
</pre></blockquote><div>That is a great news. Reproducible builds is a so nice feature and we need to collaborate to that goal.</div><div>I assume FPC core team, copied here, may be interested in this topic and could give advices on that especially on the PPU date discussed topic below.</div><blockquote type="cite"><pre>
I have nearly nailed all the issues that I think should be fixed within
our own tools (e.g. Latex introducing timestamps should be fixed in
Latex). However, for the last one I need your help and/or advice.
</pre></blockquote><div>This will get fixed sooner or later as all packages will need to honor this goal, isn't it?</div><blockquote type="cite"><pre>
Yesterday, I created the wiki page² about reproducible issues with ppu
files. The issue is that fpc stores the date of the source file of a ppu
into the ppu file. Looking at it, however, I am unsure if this timestamp
is actually really used. You don't need the source to use the ppu,
rigth? Does anybody know this? Abou? Otherwise, if somebody (Michalis
maybe) could test if updating the timestamp of the source of an ppu
(e.g. by using touch) after the ppu is build but before it is used
causes any issues?
</pre></blockquote><div>In the old days where the computers where too slow, Borland introduced the time stamp as a way to avoid recompiling. This was a feature borrowed from make utility that was considered too complex for common programmers (and is actually if you look in industrial world).</div><div><br></div><div>Later, FPC introduced SHA computation as a more accurate way to check for modification, especially for the case where only implementation is changed but not the interface. This avoids recompiling all units depending on the changed one as only the link needs to be done again.</div><div><br></div><div>Now, is that date still used or not, I don't know. That is why I copy here the FPC core team, in case someone can comment on that.</div><blockquote type="cite"><pre>
If the date in the ppu is not critical, I am going to propose a patch to
upstream to honor the environment variable SOURCE_DATE_EPOCH³. I will
include an improved patch for the documentation issues then as well, so
that we don't need to carry Debian specific patches for long.
</pre></blockquote><div>That sound to me the right way, but would prefer hear a comment from FPC core team to avoid divergence in the future.</div><blockquote type="cite"><pre>
Thanks for your help.
Paul
P.s. I am working on getting ppudump functionality into diffoscope, the
tool used by the reproducibility project to view differences.
</pre></blockquote><div>I was not aware of such tool, will have a look at it.</div><blockquote type="cite"><pre>
¹
<a href="https://reproducible.debian.net/unstable/index_dd-list.html#pkg-pascal-devel@lists.alioth.debian.org">https://reproducible.debian.net/unstable/index_dd-list.html#pkg-pascal-devel@lists.alioth.debian.org</a>
² <a href="https://wiki.debian.org/ReproducibleBuilds/TimestampsInPPUGeneratedByFPC">https://wiki.debian.org/ReproducibleBuilds/TimestampsInPPUGeneratedByFPC</a>
³ <a href="https://reproducible-builds.org/specs/source-date-epoch/">https://reproducible-builds.org/specs/source-date-epoch/</a>
</pre><pre><br></pre></blockquote><div>-- </div><div class="-x-evo-signature-wrapper"><span><pre>Cheers,
Abou Al Montacir</pre></span></div></body></html>