Hi Niels, On Sun, Nov 28, 2021 at 10:38:40AM +0100, Niels Thykier wrote: > To confirm: The root cause here is that dh_strip_nondeterminism uses the > binNMU timestamp which differs between each architecture for timestamps > *inside* the files being modified.
Yes. > Clarification needed: This is about the *mtime* of files. Does this also > cover mtimes inside archives (e.g., .zip/.tar.gz) or is it only about > the mtime of the file on the file system? Thank you for pointing the finger at my imprecision. The issue with backups is about the mtime of files and that's what caused dh_strip_nondeterminism to change. The issue with Multi-Arch: same very much is not about the mtime of files and only about their contents. dh_strip_nondeterminism presently makes the contents of files vary and that's the very issue here. > As in, would it be an option for dh_strip_nondeterminism to use the > changelog date from the original upload inside the files while > debhelper/dpkg used the changelog date from the binNMU load for the > external mtimes for files? I agree. > If we go that route, then the conditional would belong in > dh_strip_nondeterminism to disable itself. Fine with me. I had little success convincing the reproducible folks that this problem needs solving though. > For me, the options are: > > * Provided it solves the issue without regression and is feasible, we > use asymmetric SOURCE_DATE_EPOCH timestamps inside files vs. external > mtimes. I am fine with providing "infrastructure" code for this in > Dh_Lib.pm to support dh_strip_nondeterminism. I actually prefer this one. Thank you for proposing it. > * dh_strip_nondeterminism detects this issue itself and exits (silently > or with a warning). Works for me. > * We phase out dh_strip_nondeterminism in the next compat level. > - In this case, I can be persuaded to do the work around inside > dh logic (but it would not work for "classic" debhelper and maybe > not for overrides of dh_strip_nondeterminism). Can we maybe agree to phase out dh_strip_nondeterminism on the next compat level unless it implements one of the other options? That'd definitely give the reproducible folks sufficient time to fix their tooling and it would solve the Multi-Arch issue in a reasonable amount of time. > Options that I am not interested in: > > * debhelper works around dh_strip_nondeterminism deficiencies. Makes sense. The options that I am not interested in: * Continue breaking Multi-Arch: same on binNMUs. Helmut
