Bug#1101741: isync: please make the build reproducible
so did anyone try my proposal? the diff has been lying on my disk for long enough, so i committed it today and will push it in a while unless somebody objects. fwiw, i noticed that the tarball failed to ship version.sh. i'm going to fix that now, so VERSION will now track debian's commits if the build is done directly from your git tree. i consider this a good thing, esp. in the context of the patch here. make sure to check whether VERSION looks sane, though. From 3038221c7a556257e69a628f1287dbebc80634aa Mon Sep 17 00:00:00 2001 From: Oswald Buddenhagen Date: Tue, 5 Aug 2025 10:55:29 +0200 Subject: [PATCH] change reference file for man page date stamps using configure's timestamp makes builds non-reproducible if the build process includes rebuilding configure, which is the case for downstreams like debian. i considered using the NEWS file, as it's now updated with every release. however, that would be unsuitable for git builds. so instead use VERSION's timestamp, which the build system tries to keep constant unless something actually changes. it's also a semantically obvious choice. debian may still want to use a different reference, specifically debian/changelog. however, in principle that should be unnecessary, as they _should_ update VERSION to reflect any local modifications. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 8c46b8b..1cff65a 100644 --- a/configure.ac +++ b/configure.ac @@ -251,7 +251,7 @@ if test "x$have_macos_keychain" != xno; then AC_SUBST(KEYCHAIN_LIBS, ["-Wl,-framework,Security,-framework,CoreFoundation"]) fi -RELEASE_DATE=`date -r $0 +%F` +RELEASE_DATE=`date -r VERSION +%F` AC_SUBST(RELEASE_DATE) AC_CONFIG_FILES([Makefile src/Makefile src/mbsync.1 src/mdconvert.1 isync.spec]) -- 2.49.0.416.g2f302f2ef0.dirty
Bug#1101741: isync: please make the build reproducible
De : Oswald Buddenhagen À : Chris Lamb Cc : [email protected] Date : 31 mars 2025 14:03:11 Objet : Bug#1101741: isync: please make the build reproducible > On Mon, Mar 31, 2025 at 12:04:37PM +0100, Chris Lamb wrote: >> we (RB) have found that using reference filestamps like >> this to seed dates tends to be both unpredictable and opaque. >> > yes, when you don't really understand the build system and basically > hope for the best, then that's what you get. > >> Hence the suggestion to use SOURCE_DATE_EPOCH, >> > which would technically solve the wrong problem, as isync doesn't embed > build-related timestamps, unless manipulated unexpectedly. > > i don't want to rely on an external mechanism for something that should > be perfectly fixable internally. > >> which would not require a Debian-specific change (eg. your "date -r >> debian/changelog…"), and could therefore be upstreamed. >> > which is why i'm asking to evaluate using VERSION. > >> (Either way, the current call is missing the --utc/-u flag.) >> > i guess. > then i only need to remember to actually use an utc timestamp if i > actually release close to midnight ... This interaction is a bit tense for no good reason. Oswald, you might have your reasons for the current code, but I don't think anything Chris wrote warrants rude replies on his potential non-understanding of the build system. Maybe we can try to find a way forward that would suit you and avoid rebuilt antifacts to differ ? RB ils willingly rebuilding with a VM forward in time to make sure that builds are consistent within time. This is valuable to us. Bests, -- Pierre-Elliott Bécue
Bug#1101741: isync: please make the build reproducible
Oswald Buddenhagen wrote: > yes, when you don't really understand the build system and basically > hope for the best, then that's what you get. I don't know why you keep suggesting that I don't understand the build system or why this bug exists... >>(Either way, the current call is missing the --utc/-u flag.) >> > i guess. > then i only need to remember to actually use an utc timestamp if i > actually release close to midnight ... Notwithstanding that this isn't a particularly sociable way of interacting with the rest of Debian, I don't think this approach can ensure reproducible binNMUs. Anyway, good luck with the package. -- ,''`. : :' : Chris Lamb `. `'` [email protected] 🍥 chris-lamb.co.uk `-
Bug#1101741: isync: please make the build reproducible
On Mon, Mar 31, 2025 at 12:04:37PM +0100, Chris Lamb wrote: we (RB) have found that using reference filestamps like this to seed dates tends to be both unpredictable and opaque. yes, when you don't really understand the build system and basically hope for the best, then that's what you get. Hence the suggestion to use SOURCE_DATE_EPOCH, which would technically solve the wrong problem, as isync doesn't embed build-related timestamps, unless manipulated unexpectedly. i don't want to rely on an external mechanism for something that should be perfectly fixable internally. which would not require a Debian-specific change (eg. your "date -r debian/changelog…"), and could therefore be upstreamed. which is why i'm asking to evaluate using VERSION. (Either way, the current call is missing the --utc/-u flag.) i guess. then i only need to remember to actually use an utc timestamp if i actually release close to midnight ...
Bug#1101741: isync: please make the build reproducible
Oswald Buddenhagen wrote:
> On Mon, Mar 31, 2025 at 11:17:15AM +0100, Chris Lamb wrote:
>>+-RELEASE_DATE=`date -r $0 +%F`
>>++RELEASE_DATE=m4_esyscmd([date --utc --date="@${SOURCE_DATE_EPOCH:-$(date
>>+%s)}" +%Y-%m-%d])
>>
> did you even try to understand what the upstream code does, and why it
> fails here?
Oh sure. But we (RB) have found that using reference filestamps like
this to seed dates tends to be both unpredictable and opaque. Hence
the suggestion to use SOURCE_DATE_EPOCH, which would not require a
Debian-specific change (eg. your "date -r debian/changelog…"), and
could therefore be upstreamed.
(Either way, the current call is missing the --utc/-u flag.)
Best wishes,
--
,''`.
: :' : Chris Lamb
`. `'` [email protected] 🍥 chris-lamb.co.uk
`-
Bug#1101741: isync: please make the build reproducible
On Mon, Mar 31, 2025 at 11:17:15AM +0100, Chris Lamb wrote:
+-RELEASE_DATE=`date -r $0 +%F`
++RELEASE_DATE=m4_esyscmd([date --utc --date="@${SOURCE_DATE_EPOCH:-$(date
+%s)}" +%Y-%m-%d])
did you even try to understand what the upstream code does, and why it
fails here?
the problem is that debian re-generates configure each time, thus
falsifying the release timestamp.
it should use a different reference, probably debian/changelog.
upstream, i might switch to NEWS, given commit ea22b09ac in master.
that would be a bit uglier for git builds, though.
VERSION would be better in this regard. would this be compatible with
the debian build process?
Bug#1101741: isync: please make the build reproducible
Source: isync Version: 1.5.1-1 Severity: wishlist Tags: patch User: [email protected] Usertags: timestamps X-Debbugs-Cc: [email protected] Hi, Whilst working on the Reproducible Builds effort [0], we noticed that isync could not be built reproducibly. This is because the manual pages included the current date: ├── ./usr/share/man/man1/mbsync.1.gz │ │ @@ -1,14 +1,14 @@ │ │ .\" mbsync - mailbox synchronizer │ │ . │ │ -.TH mbsync 1 2025-03-13 "isync 1.5.1" "User Commands" │ │ +.TH mbsync 1 2026-04-15 "isync 1.5.1" "User Commands" │ │ . │ │ .SH NAME Patch attached that sources this value from SOURCE_DATE_EPOCH. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` [email protected] / chris-lamb.co.uk `- --- a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0 +0100 --- b/debian/patches/reproducible-build.patch 2025-03-31 11:14:22.256947078 +0100 @@ -0,0 +1,15 @@ +Description: Make the build reproducible +Author: Chris Lamb +Last-Update: 2025-03-31 + +--- isync-1.5.1.orig/configure.ac isync-1.5.1/configure.ac +@@ -251,7 +251,7 @@ if test "x$have_macos_keychain" != xno; + AC_SUBST(KEYCHAIN_LIBS, ["-Wl,-framework,Security,-framework,CoreFoundation"]) + fi + +-RELEASE_DATE=`date -r $0 +%F` ++RELEASE_DATE=m4_esyscmd([date --utc --date="@${SOURCE_DATE_EPOCH:-$(date +%s)}" +%Y-%m-%d]) + AC_SUBST(RELEASE_DATE) + + AC_CONFIG_FILES([Makefile src/Makefile src/mbsync.1 src/mdconvert.1 isync.spec]) --- a/debian/patches/series 1970-01-01 01:00:00.0 +0100 --- b/debian/patches/series 2025-03-31 11:14:19.800927193 +0100 @@ -0,0 +1 @@ +reproducible-build.patch
