Debian and SOURCE_DATE_EPOCH=0

[Vagrant Cascadian]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20260220/19fbdbcf/attachment.sig>