Bug#999665: dh_strip_nondeterminism breaks Multi-Arch: same in binNMUs

Mattia Rizzolo mattia at debian.org
Wed Dec 1 11:39:34 UTC 2021


On Sun, Nov 28, 2021 at 10:38:40AM +0100, Niels Thykier wrote:
> 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 suppose this could be fine indeed.  It feels a bit overengineered but
should be fine perhaps.

>  * 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.

To be honest, this to me feels the best approach now.
I actually didn't think of this hybrid solution in the past months when
I was chatting with Helumt et al. on the topic.  Thank you for proposing
it!

Though, tbh, I also just realized that StripNondeterminism only ever
handles file content, the stuff dealing with file metadata in the "bare"
directories is within debhelper itself.  So uh, I suppose most of my
concern are gone now.


Niels: how do you suspect such "infrastructure" to look like?  Right now
dh_strip_nondeterminism is using get_source_date_epoch() from Dh_Lib.pm
to get the timestamp to use for everything.  If you can provide a
similar function returning a similar value but coming from the last
non-binary-only changelog entry, I suppose we could just switchin
dh_strip_nondeterminism to use that.

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
More about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20211201/3eb3a0b6/attachment.sig>


More information about the rb-general mailing list