Helmut Grohne: > Package: debhelper > Version: 13.5.2 > Severity: important > X-Debbugs-Cc: debian-cr...@lists.debian.org, > rb-gene...@lists.reproducible-builds.org > > Hi, > > [...] > > The situation is that when performing a binNMU, the changelogs are > created with differing timestamps. [...] As a consequence, the > SOURCE_DATE_EPOCH differs. When dh_strip_nondeterminism fixes up files, > it actually makes them differ from one another in a coinstallationset of > Multi-Arch: same packages. Files that were previously reproducible are > made unreproducible by dh_strip_nondeterminism.
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. > The behaviour used to be > different and the most recent non-binNMU date was considered, but that > happend to break backup software as it could no longer detect > modifications from a non-binNMU to binNMU upgrade. That is how we ended > up with current situation. > 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? 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? > [...] > > In order for a package to actually hit the bug, two conditions must be > met simultaneously: > * Some binary package must be marked Multi-Arch: same. > * The build must be a binNMU. > > [...] > > Given that there is no progress for prolonged time, we have a choice: > Either we produce reproducible packages that happen to not be > installable or we produce installable packages that happen to not be > reproducible. The trade-off appears obvious to me. Keep in mind that > dh_strip_nondeterminism was enabled on the provision of not breaking > stuff. Now it does break stuff. > I always saw dh_strip_nondeterminism was a *temporary* solution to kick-start the reproducibility process. As such I hoped we would eventually phase it out. > As such, I propose that debhelper automatically disables > dh_strip_nondeterminism if and only if both relevant conditions are met. > What do you think about this? > If we go that route, then the conditional would belong in dh_strip_nondeterminism to disable itself. > I think the reproducible builds folks favour a solution that involves > sourcefull uploads replacing binNMUs. The proposed workaround does not > interfere with the reproducible proposal in any way. > > Do you need a patch? > > Helmut > 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. * dh_strip_nondeterminism detects this issue itself and exits (silently or with a warning). * 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). Options that I am not interested in: * debhelper works around dh_strip_nondeterminism deficiencies. Thanks, ~Niels