Dealing with version.texi and mdate-sh

Ximin Luo infinity0 at debian.org
Mon Jul 10 10:00:00 UTC 2017


Eric Dorland:
> Hi folks,
> 
> I was trying to fix some unreproduciblity issues with automake and the
> problem of version.texi came to my attention and I haven't seen it
> come up before, but let me know if I just couldn't find it.
> 
> According to
> https://www.gnu.org/software/automake/manual/html_node/Texinfo.html,
> if your .texi includes version.texi it will generate version.texi
> based on the output of mdate-sh on the .texi file (aka whatever the
> modification date of the file is). Obviously that's bad for build
> reproducibility. 
> 
> My thinking on how to fix this would be to add a flag to mdate-sh to
> use SOURCE_DATE_EPOCH if it's available and make automake use that
> flag when generating version.texi. Is there a better approach? Should
> the unpacked source package just have all of the files modification
> dates set to SOURCE_DATE_EPOCH?
> 

Hi Eric, it's better to just directly use SOURCE_DATE_EPOCH if it's available without requiring an extra command-line flag, so package maintainers don't have to add these extra flags anywhere.

With an unpacked source package, what we generally do is reset file modtimes only if they are newer than SOURCE_DATE_EPOCH, otherwise keep them as-is. We've been calling this "clamping". If you're creating tar files you can use the --clamp-mtime option rather than touching the files diretcly.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git



More information about the Reproducible-builds mailing list