Tools respecting SOURCE_DATE_EPOCH (was Re: Reproducible XFS Filesystems Builds for VMs)

[Vagrant Cascadian]

On 2025-04-12, Simon Josefsson via rb-general wrote:
> Luca DiMaio via rb-general <rb-general at lists.reproducible-builds.org>
> writes:
>
>> - For FAT32 partitions: `mkfs.vfat --invarian -i $EFI_UUID` with
>> `$SOURCE_DATE_EPOCH` and populating via mtools
>> - For EXT4 partitions: `mkfs.ext4 -E hash_seed=$EXT4_HASH_SEED -U
>> $ROOTFS_UUID` with `$SOURCE_DATE_EPOCH` plus the `-d
>> /path/to/rootfs.tar.gz` to populate it
>
> Wow that great work!

Agreed!


> Out of curiosity, do mkfs.ext4 and mkfs.vfat upstream natively react on
> the SOURCE_DATE_EPOCH environment variable?

I believe so, yay!


> I think generally it is unfortunate if upstream tools start to respect
> build-specific environment variable.  Tools should support mechanisms
> for reproducibility.  But I find reacting to build environment variables
> problematic.

Well, that is the intended purpose of SOURCE_DATE_EPOCH, so I will have
to disagree a bit...


> Should upstream tools start to listen on Gentoo's
> NO_NETWORK build environment variable too?  Should ping stop sending
> packets when that environment variable is set?

Maybe? That sure sounds useful!


> There are many other build environment variables that are problematic
> to use in native code.

Well, we tried to specify SOURCE_DATE_EPOCH in a way that would not be
too problematic ... and it is not an environment variable that should be
set except in a build environment in which you want it to be
respected...


> FWIW, I ran into a similar problem with 'help2man' which behave
> different depending on SOURCE_DATE_EPOCH setting and there is no way
> except to use datefudge/faketime to make help2man use another time than
> current time. Or to perform post-processing of the output files.  Or
> give up and hard-code SOURCE_DATE_EPOCH when calling help2man (which is
> what I settled with), but that invalidates the callers ability to pass
> in another SOURCE_DATE_EPOCH value and this nests badly.

I am not seeing an actual problem here... so perhaps I am missing
something. Why do you need multiple different SOURCE_DATE_EPOCH values
as part of a single build process? If you have multiple build processes,
why are they getting ... an undesired SOURCE_DATE_EPOCH value?


In my opinion, help2man is a build tool, and if it embeds any sort of
date, respecting SOURCE_DATE_EPOCH is the correct thing to do. At least,
that is the intention of how SOURCE_DATE_EPOCH is supposed to work...


> Help2man could have accepted the time to use as a parameter on the
> command-line instead.

That it lacks a commandline option is fine, as the whole point of
SOURCE_DATE_EPOCH is to avoid having to patch every single call on all
source code available to call tool specific arguments to pass the
timestamp. It is intentionally an environment variable that should be
supported widely, by many tools, withoput any special calling syntax.

That said, maybe if help2man (or other build tools) does support a
commandline argument, I can see an argument that it should respect the
commandline over the SOURCE_DATE_EPOCH environment variable. But that
should not be in lieu of SOURCE_DATE_EPOCH, but in addition to it.


I will admit there are some projects which abuse SOURCE_DATE_EPOCH in a
couple ways...

One case, which is technically outside of the letter of the
SOURCE_DATE_EPOCH specification, but perhaps following the spirit of it
(at least from a reproducible builds perspective), is to avoid embedding
timestamps when SOURCE_DATE_EPOCH is specified.

Another is treating SOURCE_DATE_EPOCH as a "please build reproducibly"
flag and using non-timestamp settings that make the build deterministic
(e.g. normalizing other things such as username or setting a random
value seed based on presence of SOURCE_DATE_EPOCH). Feels a little
wrong, but a lesser wrong, at least with my Reproducible Builds
biases. :)


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/20250412/5494c7a6/attachment.sig>