Reproducible XFS Filesystems Builds for VMs

Jelle van der Waa jelle at vdwaa.nl
Sat Apr 12 12:28:24 UTC 2025


On 4/12/25 12:06, 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!
> 
> Out of curiosity, do mkfs.ext4 and mkfs.vfat upstream natively react on
> the SOURCE_DATE_EPOCH environment variable?

Yes, and so does mtools. [1]
> 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.  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?  There are many other
> build environment variables that are problematic to use in native code.

Well NO_NETWORK isn't really a respected standard. But funnily enough 
NO_COLOR sort of is. [2]

But I am not going to fall into the trap of discussion if this is wanted 
or not :)

[1] 
https://github.com/tytso/e2fsprogs/blob/ff64357f839071968a727f8b5a08b0ddaedc5bbb/doc/RelNotes/v1.47.1.txt#L144
[2] https://no-color.org/


More information about the rb-general mailing list