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
Date: Thu, 6 Oct 2022 19:25:11 +
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
___
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
