On 2026-02-15, John Gilmore wrote: > "David A. Wheeler via rb-general" wrote: >> I personally prefer a "meaningful" datetime stamp, since that provides >> additional information. But that's a preference about maximally providing >> info; clearly choosing "1" can also provide reproducibility >> >> Can these trade-offs be documented somewhere on the r-b website >> with SOURCE_DATE_EPOCH? Basically: >> >> * Many prefer setting SOURCE_DATE_EPOCH, MTIME, and --mtime to a >> "meaningful" value like `git show HEAD --format=%ct --no-patch` >> as this provides additional information.
See 1st paragraph on: https://reproducible-builds.org/docs/source-date-epoch/ Much further down on the page, the "Setting the variable" section includes an example for git, as well as elaborate Debian-specific information... maybe we should at least bump git up before the Debian examples, as the most generalized example. :) Maybe also put "Setting the variable" before the "Reading the variable" section. Or at least referring to "Setting the variable" in the 1st paragraph. > There is a step beyond bit-for-bit reproducibility that I think it would > be wise for us to enable. > > That is the ability to patch something or a few things (e.g. close major > security bugs), rebuild the world, and then be able to see with "diff > -r" just the small set of changes that those bug-fixes made in the > generated binaries and files. Without an ocean of chaff from shifting > timestamps in unrelated files. Well, this would ideally be accomplished better without SOURCE_DATE_EPOCH, and I *swear* our documentation for SOURCE_DATE_EPOCH even used to include something about preferably not including timestamps at all, but cannot find it anymore. Maybe some git arcchaeology is in order... In my opinion, SOURCE_DATE_EPOCH should really be a timestamp of last resort, the preferred thing is to not include build timestamps at all! > Using `git show HEAD` to create the timestamp means that you can't patch > a bug, rebuild, and see what changed -- because every timestamp embedded > in the generated files will change. (This is the same problem that > reproducible-builds are trying to solve for the case when NO patch has > been applied. Can we simultaneously solve it for when there ARE > patches?) I think your example here is a perfect case for how to use reproducible builds and SOURCE_DATE_EPOCH: In your scenario, you might set SOURCE_DATE_EPOCH to the value of the earlier commit you are testing against, rather than the current commit, to be able to test for differences without all that pesky timestamp noise. The specification allows for this sort of thing: https://reproducible-builds.org/specs/source-date-epoch/ The value MUST be reproducible (deterministic) across different executions of the build, depending only on the source code. It SHOULD be set to the last modification time of the source, incorporating any packaging-specific modifications. I think that SHOULD allowance includes the workflow you were describing... although if you want the timestamp values to be deterministic across your builds, obviously you MUST use the same value for both (or Nth) builds. This might get tricky for processes that might set SOURCE_DATE_EPOCH during the build itself... I had the impression that at least some of the tooling only sets SOURCE_DATE_EPOCH if unset... but that does not seem to be represented in the spec or documentation at a quick glance... live well, vagrant
signature.asc
Description: PGP signature
