On 2016-06-27, Yury V. Zaytsev wrote: > On Mon, 27 Jun 2016, Reiner Herrmann wrote:
Going through some old outstanding reproducible builds related bugs... >> You are right, the mtime of the file is used for the manpage timestamp. >> But there is still a patch modifying the manpage: >> mcedit_full_path.patch. When this patch is upstreamed, the >> SOURCE_DATE_EPOCH patch is not needed, though it would still help when >> the manpages are patched. > > Thank you for the confirmation that my guesses are correct! > > However, I'm hesitant to apply SOURCE_DATE_EPOCH to anything that looks > like a nail. I believe that patching of upstream sources by Debian is such > an oft occurring situation, that I would rather look for at solution at > the packaging level. After all, builds from *upstream* sources are > *already* reproducible, in this case, it's the Debian build procedure that > is injecting randomness here. I am biased, but I do think using SOURCE_DATE_EPOCH could still be a reasonable approach upstream. There are some examples of how to use this in various languages: https://reproducible-builds.org/docs/source-date-epoch/ I did notice some things in the upstream code doc/man/date-of-man-include.am: MAN_DATE_CMD = \ LC_ALL=$(DATE_LANG) @PERL@ -CS -MPOSIX -e '\ @fi=lstat("'$${MAN_FILE}'"); \ print POSIX::strftime("$(DATE_FORMAT)", localtime($$fi[9]));' 2>/dev/null This uses localtime, which could be affected by timezone differences. To my surprise, it doesn't appear to affect the results, as only the patched manpage is affected: https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/mc.html Setting LC_ALL explicitly avoids variations due to the build environment's locale(yay!), although the specified locales are not guaranteed to be available (adding locales-all to build-depends could fix that). Again, surprisingly, this has not appeared to affect the results for the locales tested on tests.reproducible-builds.org, though that may mean the default locale is used even for the translated pages... > For instance, it seems to me that it is only logical to set the mtime of > patched files to the mtime of the last patch that touched them, and this > will make the source mtime dependent builds fully reproducible. The attached alternate implements this for mc by touching the potential files before running configure with a consistent timestamp. According to my local tests, applying this patch should make mc build reproducibly once it lands in testing/bookworm! There are outstanding build path issues tested in unstable and experimental. It doesn't address the larger issue of files modified by debian/patches having the current timestamp, which is a much more complicated intersection of issues. live well, vagrant
From 4e69587954d29ec6bfc7d85b4b618724b16b840e Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian <vagr...@reproducible-builds.org> Date: Thu, 6 Oct 2022 19:25:11 +0000 Subject: [PATCH 5/5] debian/rules: Ensure consistent timestamp on manpages. The upstream build system uses the file modification time of the .in file for the manpage to embed into the generatated manpage, but if debian/patches modify the .in files, the timestamp is updated, resulting in builds performed in different months or years embedding a different date. --- debian/rules | 2 ++ 1 file changed, 2 insertions(+) diff --git a/debian/rules b/debian/rules index c633a73..bf8eb5e 100755 --- a/debian/rules +++ b/debian/rules @@ -25,6 +25,8 @@ override_dh_autoreconf: # AWK="awk" is inheritance of 4.7.* series, see http://bugs.debian.org/499723 # might be still necessary for extfs scripts override_dh_auto_configure: + # Ensure reproducible timestamp on manpages + touch -d@$(SOURCE_DATE_EPOCH) doc/man/*.1.in doc/man/*/*.1.in dh_auto_configure -- AWK="awk" X11_WWW="x-www-browser" \ --libexecdir='/usr/lib' \ --with-x \ -- 2.37.2
signature.asc
Description: PGP signature