Sphinx: localisation changes / reproducibility

[James Addison]

On Fri, 14 Apr 2023 at 19:51, Holger Levsen <holger at layer-acht.org> wrote:
>
> Dear James,
>
> many thanks also from me for your work on this and sharing your findings here.
>
> I'm another happy sphinx user affected by those problems. :)

Thanks, Holger - I think I made a bit of a (verbose) mess of this
particular bugfix attempt, but it's a learning experience I suppose :)

> somewhat related:
>
> i'm wondering whether distro-info should respect SOURCE_DATE_EPOCH:
> src:developers-reference builds different content based on the build
> date, due to using distro-info and distro-info knows that in 398 days
>  trixie will be released :)))
> see  https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/arm64/diffoscope-results/developers-reference.html

Although it's probably an alternative understanding of the goal, I
(possibly mis)interpret the end result of reproducible builds as:
reliable and complete support for time-traveling software users.

So: it's a slow, rainy Tuesday in early Y2045, and there's a report
that someone's saved game file from Y2019 doesn't load correctly.

Well, we could start by retrieving the sources and building the game
as it existed back in Y2019 - does it load in that version?

In practice, built software could depend on the software and tools
installed locally (in a true-ish sense of location), not only time --
but by using time as a universal and ordered clothesrack (?) onto
which software can be unambiguously placed (and then non-destructively
and freely copied-from), we can all achieve matching software costumes
if and when we want to.

To return more directly to your question, though: the release date
information seems to be in distro-info-data, and I guess that that
itself is also updated over time.  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".  In practice some variance of "s" is allowed for the
build dependencies, in the absence of output-affecting bugs/changes
relevant to the build.

If something is producing different results across builds that share
the same fixed "s" and "t" (and I think that the RB dashboard
indicates that that is happening for developers-reference?), then
either something isn't respecting SOURCE_DATE_EPOCH, or something else
in the build environment is affecting the build output.

Long story short: that's probably not very helpful -- I have retrieved
a few of the sources, but I don't know where the problem is yet.  I'll
take more of a look soon.

(also: although it's not DFSG-compatible, a game that springs to mind
in my case, albeit Y2009 or so probably, would be the original Knights
of The Old Republic game.  not so much a load-game problem, more of a
logic error in the game data that meant that I was stuck on some
planet without being able to achieve the assigned objectives.  I would
_probably_ still remember enough of the details to figure out
replication details for that bug, given a refresher on some of the
levels and objectives involved.  that'll have to be a very rainy day)

Cheers,
James