Sphinx: localisation changes / reproducibility

James Addison jay at jp-hosting.net
Mon Apr 17 23:08:32 UTC 2023

On Sun, 16 Apr 2023 at 00:25, John Gilmore <gnu at toad.com> wrote:
> James Addison via rb-general <rb-general at lists.reproducible-builds.org> wrote:
> >                              In general, we should be able to
> > pick two times, "s" and "t", s <= t, where "s" is the
> > source-package-retrieval time, and "t" is the build-time, and using
> > those, any two people should be able to create exactly the same
> > (bit-for-bit) documentation.  I think that SOURCE_DATE_EPOCH generally
> > refers to "t".
> I think that SOURCE_DATE_EPOCH generally refers to the check-IN time of
> each of the source package(s) being rebuilt.  You can retrieve the
> packages anytime later than that, and you can do the build at any time
> later, and SOURCE_DATE_EPOCH should not change (and the built binaries
> and docs should also not change).

When the goal is to build the software as it was available to the
author at the time of code commit/check-in - and I think that that is
a valid use case - then that makes sense.

(this ignores a subtlety in the hypothetical case where multiple
independent software authors could be tasked with writing to a
specification but without access to each others' source dependencies
-- in that case there is no notion of the "software as it was
available to [each] author".  using FOSS licensing and publication
solves most of that problem, excepting situations where individual
authors are out-of-contact during software development)

Inverting the question somewhat: if a single source-base is rebuilt
using two different SOURCE_DATE_EPOCH values (let's say, 1970-01-01
and 2023-04-18), then what are expected/valid differences in the
resulting output?

More information about the rb-general mailing list