Sphinx: localisation changes / reproducibility

[Holger Levsen]

On Wed, Apr 26, 2023 at 12:40:09PM -0700, Vagrant Cascadian wrote:
> Yes, ideally SOURCE_DATE_EPOCH does not matter. It is a workaround to
> embed a (hopefully meaningful) timestamp, when from a reproducible
> builds perspective, ideally there would be no timestamp at all in the
> resulting artifacts. 

I'm not sure I agree SOURCE_DATE_EPOCH is a workaround. Because, as you 
explain from a reproducible builds perspective no timestamps are ideal
(and as such I can see why you call it a workaround) but I don't think the
reproducible builds perspective is the only relevant perspective in
the world of software development nor usage. And as SOURCE_DATE_EPOCH,
or in other words, the release date of the software in question, is
meaningful to us humans, I also think having an automatic
way of retrieving the release date of a given software, which is
SOURCE_DATE_EPOCH, is more than a workaround.

differently said: I agree that removing timestamps is more often than
not the right thing to do. When this cannot be done or when this can
only be done badly (eg by setting filesystem times to 1970-01-01)
timestamps are best replaced by SOURCE_DATE_EPOCH.


-- 
cheers,
	Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

“It's easy to be a naive idealist. It's easy to be a cynical realist. It's
 quite another thing to have no illusions and still hold the inner flame.”
 (Marie-Louise von Franz)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20230427/2e8aa185/attachment.sig>