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