On Fri, 14 Apr 2023 at 19:51, Holger Levsen <hol...@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