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

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Helmut Grohne <helmut@subdivi.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: dh_strip_nondeterminism breaks Multi-Arch: same in binNMUs

Date: Sun, 14 Nov 2021 14:23:36 +0100

Package: debhelper
Version: 13.5.2
Severity: important
X-Debbugs-Cc: debian-cross@lists.debian.org, rb-general@lists.reproducible-builds.org

Hi,

dh_strip_nondeterminism was automatically enabled on the provision that
it wouldn't break stuff. To a large extend, that's the case.
Unfortunately, there is a corner case where it does get things wrong and
we cannot make progress as the requirements appear to conflict with one
another. The issue is reported as #950806.

The situation is that when performing a binNMU, the changelogs are
created with differing timestamps. (That's a technical limitation of our
archive implementation. In theory, binNMUs could use equal timestamps
and sbuid already has --binNMU-timestamp.) 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. 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.

So we're actually talking about a relatively small set of affected
packages. Unfortunately, libruby2.N is among them and that has a
relatively high impact. But the issue does not stop there. We've had
other high profile cases in the past. They tend to pop up at unfortunate
times.

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.

We can estimate this set using grep-dctrl:

grep-dctrl '(' -r -F Version '.*+b[0-9]\+$' ')' --and '(' -F Multi-Arch -X same ')' -s Package -n $PKGFILE

For unstable, that's about 2100 binary packages built from 900 source
packages at present.

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.

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?

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

Message #10 received at 999665@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: Helmut Grohne <helmut@subdivi.de>, 999665@bugs.debian.org

Cc: debian-cross@lists.debian.org, rb-general@lists.reproducible-builds.org

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

Date: Sun, 28 Nov 2021 10:38:40 +0100

Helmut Grohne:
> Package: debhelper
> Version: 13.5.2
> Severity: important
> X-Debbugs-Cc: debian-cross@lists.debian.org, rb-general@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

Message #15 received at 999665@bugs.debian.org (full text, mbox, reply):

From: Helmut Grohne <helmut@subdivi.de>

To: Niels Thykier <niels@thykier.net>

Cc: 999665@bugs.debian.org, debian-cross@lists.debian.org, rb-general@lists.reproducible-builds.org

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

Date: Sun, 28 Nov 2021 11:57:40 +0100

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

Message #20 received at 999665@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: "Niels Thykier" <niels@thykier.net>, rb-general <rb-general@lists.reproducible-builds.org>, "Helmut Grohne" <helmut@subdivi.de>, 999665@bugs.debian.org

Cc: debian-cross@lists.debian.org

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

Date: Wed, 01 Dec 2021 01:13:03 -0000

Hi all,

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

Just as a bit of throat-clearing, if you've not heard anything from
the Reproducible Builds folks (or at least from me…) then the
underlying reason is more that I am just not well-versed enough with
the binNMU and builddd apparatus to have an informed opinion on this
fairly technical and quite wide-reaching topic.

In other words, it's not a lack of interest or an uncaring disregard
for other parts of Debian (!), something that other mails in this
  thread might have accidentally implied.

I'd be more than happy to change dh_strip_nondeterminism now to fix
this longstanding issue for all of us, although with the proviso that
the solution we want to get behind can be outlined in brief; and we
seem to be close to there.

> [Option:]
>  * We phase out dh_strip_nondeterminism in the next compat level.

Not the ideal place for this info but unfortunately I don't think the
rest of the archive is in a place to drop strip-nondeterminism on the
next compat level. From memory, this is chiefly due to some key
toolchain packages, where the required changes are not forthcoming,
changes are blocking on upstream, patches have not been applied in
Debian, or the discussion has stalled for various reasons.

I do very much share your desire to phase out this tool completely and
I even introduced a deprecation roadmap for every change that
strip-nondeterminism makes for this very reason. But we're just not
there... yet.

> [Option:]
> * debhelper works around dh_strip_nondeterminism deficiencies.

Just to be explicit, I totally agree with this.


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org 🍥 chris-lamb.co.uk
       `-

Message #25 received at 999665@bugs.debian.org (full text, mbox, reply):

From: Helmut Grohne <helmut@subdivi.de>

To: Chris Lamb <lamby@debian.org>

Cc: Niels Thykier <niels@thykier.net>, rb-general <rb-general@lists.reproducible-builds.org>, 999665@bugs.debian.org, debian-cross@lists.debian.org

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

Date: Wed, 1 Dec 2021 11:44:50 +0100

[Message part 1 (text/plain, inline)]

Control: tags -1 + patch

Hi Chris,

On Wed, Dec 01, 2021 at 01:13:03AM -0000, Chris Lamb wrote:
> In other words, it's not a lack of interest or an uncaring disregard
> for other parts of Debian (!), something that other mails in this
>   thread might have accidentally implied.

I did not mean to imply intent. The fact is that this issue is causing
significant pain for a significant amount of time and the reproducible
builds folks have generally not reacted to it in any helpful way. I also
note that your reply is fully consistent with this observation: You
acknowledge the problem and double down on keeping the broken status
quo.

> I'd be more than happy to change dh_strip_nondeterminism now to fix
> this longstanding issue for all of us, although with the proviso that
> the solution we want to get behind can be outlined in brief; and we
> seem to be close to there.

You seem to be referring to Niels' approach here. I think he already put
it quite precise. Is there anything you find missing? Moving ahead with
that would be my preference.

> > [Option:]
> >  * We phase out dh_strip_nondeterminism in the next compat level.
> 
> Not the ideal place for this info but unfortunately I don't think the
> rest of the archive is in a place to drop strip-nondeterminism on the
> next compat level. From memory, this is chiefly due to some key
> toolchain packages, where the required changes are not forthcoming,
> changes are blocking on upstream, patches have not been applied in
> Debian, or the discussion has stalled for various reasons.

As much as I see the other side of the picture and as much as I value
the achievements of reproducible builds, I come to the conclusion that
it is irrelevant. dh_strip_nondeterminism was accepted on the grounds of
not breaking stuff. Those grounds no longer exist. So the question
whether it still is needed, is secondary. The question of whether it
still is affordable already has an answer: no.

The more I deal with this issue, the more I am convinced that
dh_strip_nondeterminism should be removed from debhelper as soon as
possible. It wasn't added in a compat level. It doesn't need a compat
level to be dropped.

I think we can afford about a month for finding a better solution.
Failing that, we should move forward with the one we have.

Helmut

[debhelper_13.5.2+nmu1.debdiff (text/plain, attachment)]

Message #30 received at 999665@bugs.debian.org (full text, mbox, reply):

From: Mattia Rizzolo <mattia@debian.org>

To: Niels Thykier <niels@thykier.net>, 999665@bugs.debian.org

Cc: Helmut Grohne <helmut@subdivi.de>, debian-cross@lists.debian.org, rb-general@lists.reproducible-builds.org

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

Date: Wed, 1 Dec 2021 12:39:34 +0100

[Message part 1 (text/plain, inline)]

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  `-

[signature.asc (application/pgp-signature, inline)]

Message #35 received at 999665@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: 999665@bugs.debian.org, debian-cross@lists.debian.org, rb-general@lists.reproducible-builds.org

Cc: Helmut Grohne <helmut@subdivi.de>

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

Date: Wed, 1 Dec 2021 22:07:50 +0100

Mattia Rizzolo:
> [...]
> 
> 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.
> 

Hi,

I think it would something like this from the debhelper side:

  https://salsa.debian.org/debian/debhelper/-/merge_requests/58

Would that work for you? :)

Thanks,
~Niels

Message #40 received at 999665@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: "Niels Thykier" <niels@thykier.net>, rb-general <rb-general@lists.reproducible-builds.org>, 999665@bugs.debian.org, debian-cross@lists.debian.org

Cc: "Helmut Grohne" <helmut@subdivi.de>

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

Date: Mon, 06 Dec 2021 14:19:26 -0800

Hi Niels,

> I think it would something like this from the debhelper side:
>
>   https://salsa.debian.org/debian/debhelper/-/merge_requests/58
>
> Would that work for you? :)

Indeed it would. Would strip-nondeterminism then simply Depend on the
version of debhelper this change gets released in? Or rather: should
we do something more involved than that?


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org 🍥 chris-lamb.co.uk
       `-

Message #45 received at 999665@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: Chris Lamb <lamby@debian.org>, 999665@bugs.debian.org, rb-general <rb-general@lists.reproducible-builds.org>, debian-cross@lists.debian.org

Cc: Helmut Grohne <helmut@subdivi.de>

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

Date: Tue, 7 Dec 2021 21:20:09 +0100

Chris Lamb:
> Hi Niels,
> 
>> I think it would something like this from the debhelper side:
>>
>>   https://salsa.debian.org/debian/debhelper/-/merge_requests/58
>>
>> Would that work for you? :)
> 
> Indeed it would. Would strip-nondeterminism then simply Depend on the
> version of debhelper this change gets released in? Or rather: should
> we do something more involved than that?
> 
> 
> Regards,
> 

Hi,

You can either depend on it or do a runtime check for the new function
to see if the feature is available - whatever floats your boat. :)

When you concluded the feature is available, you would then call
get_non_binnmu_date_epoch instead of get_source_date_epoch to obtain the
value for SOURCE_DATE_EPOCH.  You may want to do a
`$ENV{SOURCE_DATE_EPOCH} = get_non_binnmu_date_epoch()` depending on
whether you call third-party tools that use the variable.

Thanks,
~Niels

Message #48 received at 999665@bugs.debian.org (full text, mbox, reply):

From: Mattia Rizzolo <mattia@debian.org>

To: Niels Thykier <niels@thykier.net>, 999665@bugs.debian.org

Cc: Chris Lamb <lamby@debian.org>, rb-general <rb-general@lists.reproducible-builds.org>, debian-cross@lists.debian.org, Helmut Grohne <helmut@subdivi.de>

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

Date: Sat, 11 Dec 2021 15:46:23 +0100

[Message part 1 (text/plain, inline)]

So, I did some tests here.

Helmut, look below:

On Tue, Dec 07, 2021 at 09:20:09PM +0100, Niels Thykier wrote:
> You can either depend on it or do a runtime check for the new function
> to see if the feature is available - whatever floats your boat. :)

I went this way indeed:

--- strip-nondeterminism.orig/bin/dh_strip_nondeterminism
+++ strip-nondeterminism/bin/dh_strip_nondeterminism
@@ -91,7 +91,13 @@
        find(\&testfile,$tmp);
        next unless @nondeterministic_files;
 
-       $File::StripNondeterminism::canonical_time = get_source_date_epoch();
+       if (eval "get_non_binnmu_date_epoch()") {
+               $File::StripNondeterminism::canonical_time
+                 = get_non_binnmu_date_epoch();
+               $ENV{SOURCE_DATE_EPOCH} = get_non_binnmu_date_epoch()
+       } else {
+               $File::StripNondeterminism::canonical_time = get_source_date_epoch();
+       }
 
        verbose_print("Using $File::StripNondeterminism::canonical_time as canonical time");
 


And then I built and then binNMUed p11-kit/0.24.0-2 - which was one of
those packages affected by this "bug".

I confirm that for all 2 builds, strip-nondeterminism used 1630835345 as
timestamp, so the patch works.

However, in that particular package, there is still this change:

│ │ │ ├── ./usr/share/man/man1/trust.1.gz
│ │ │ │ ├── trust.1
│ │ │ │ │ @@ -1,12 +1,12 @@
│ │ │ │ │  '\" t
│ │ │ │ │  .\"     Title: trust
│ │ │ │ │  .\"    Author: Stef Walter <stef@thewalter.net>
│ │ │ │ │  .\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
│ │ │ │ │ -.\"      Date: 09/05/2021
│ │ │ │ │ +.\"      Date: 12/11/2021
│ │ │ │ │  .\"    Manual: User Commands
│ │ │ │ │  .\"    Source: p11-kit
│ │ │ │ │  .\"  Language: English
│ │ │ │ │  .\"
│ │ │ │ │  .TH "TRUST" "1" "" "p11-kit" "User Commands"
│ │ │ │ │  .\" -----------------------------------------------------------------
│ │ │ │ │  .\" * Define some portability stuff
│ │ │ ├── ./usr/share/man/man5/pkcs11.conf.5.gz
│ │ │ │ ├── pkcs11.conf.5
│ │ │ │ │ @@ -1,12 +1,12 @@
│ │ │ │ │  '\" t
│ │ │ │ │  .\"     Title: pkcs11.conf
│ │ │ │ │  .\"    Author: Stef Walter <stef@thewalter.net>
│ │ │ │ │  .\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
│ │ │ │ │ -.\"      Date: 09/05/2021
│ │ │ │ │ +.\"      Date: 12/11/2021
│ │ │ │ │  .\"    Manual: System Files
│ │ │ │ │  .\"    Source: p11-kit
│ │ │ │ │  .\"  Language: English
│ │ │ │ │  .\"
│ │ │ │ │  .TH "PKCS11\&.CONF" "5" "" "p11-kit" "System Files"
│ │ │ │ │  .\" -----------------------------------------------------------------
│ │ │ │ │  .\" * Define some portability stuff
│ │ │ ├── ./usr/share/man/man8/p11-kit.8.gz
│ │ │ │ ├── p11-kit.8
│ │ │ │ │ @@ -1,12 +1,12 @@
│ │ │ │ │  '\" t
│ │ │ │ │  .\"     Title: p11-kit
│ │ │ │ │  .\"    Author: Stef Walter <stef@thewalter.net>
│ │ │ │ │  .\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
│ │ │ │ │ -.\"      Date: 09/05/2021
│ │ │ │ │ +.\"      Date: 12/11/2021
│ │ │ │ │  .\"    Manual: System Commands
│ │ │ │ │  .\"    Source: p11-kit
│ │ │ │ │  .\"  Language: English
│ │ │ │ │  .\"
│ │ │ │ │  .TH "P11\-KIT" "8" "" "p11-kit" "System Commands"
│ │ │ │ │  .\" -----------------------------------------------------------------
│ │ │ │ │  .\" * Define some portability stuff


Now, this is in the binary package p11-kit, which is not m-a:same, so it
doesn't matter, but I guess this is some kind of "proof" that
strip-nondeterminism is not really "at fault" for things, IMHO.

That said, I do suppose we can go ahead with this change, since it has
the possibility of greatly lowering the chances of conflicts.  Indeed,
the .png that caused troubles in #995162 has the same content, however
different filesystem metadata (which is exactly what we wanted to
achieve.)

I committed my change to git, feel free to adjust if my non-existent
perl knowledge made things worse!
https://salsa.debian.org/reproducible-builds/strip-nondeterminism/-/commit/96fcd0f6391a8d05a30af2fb9b77f530b9f88adb

-- 
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  `-

[signature.asc (application/pgp-signature, inline)]

Message #51 received at 999665-submitter@bugs.debian.org (full text, mbox, reply):

From: Mattia Rizzolo <mattia@debian.org>

To: 999665-submitter@bugs.debian.org

Subject: Bug#999665 marked as pending in strip-nondeterminism

Date: Sat, 11 Dec 2021 14:45:42 +0000

Control: tag -1 pending

Hello,

Bug #999665 in strip-nondeterminism reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/reproducible-builds/strip-nondeterminism/-/commit/96fcd0f6391a8d05a30af2fb9b77f530b9f88adb

------------------------------------------------------------------------
dh_strip_nondeterminism: use get_non_binnmu_date_epoch() when available.

Closes: #999665
Signed-off-by: Mattia Rizzolo <mattia@debian.org>
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/999665

Message #58 received at 999665-close@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 999665-close@bugs.debian.org

Subject: Bug#999665: fixed in strip-nondeterminism 1.13.0-1

Date: Mon, 20 Dec 2021 17:49:35 +0000

Source: strip-nondeterminism
Source-Version: 1.13.0-1
Done: Holger Levsen <holger@debian.org>

We believe that the bug you reported is fixed in the latest version of
strip-nondeterminism, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 999665@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Holger Levsen <holger@debian.org> (supplier of updated strip-nondeterminism package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Mon, 20 Dec 2021 18:12:02 +0100
Source: strip-nondeterminism
Architecture: source
Version: 1.13.0-1
Distribution: unstable
Urgency: medium
Maintainer: Reproducible builds folks <reproducible-builds@lists.alioth.debian.org>
Changed-By: Holger Levsen <holger@debian.org>
Closes: 999665
Changes:
 strip-nondeterminism (1.13.0-1) unstable; urgency=medium
 .
   [ Mattia Rizzolo ]
   * dh_strip_nondeterminism: use get_non_binnmu_date_epoch() when available.
     Closes: #999665
   * Add a lintian overrides for some false positive tags.
Checksums-Sha1:
 18f07c97f07612c03c3a2b49ccc2404bf66def8a 2830 strip-nondeterminism_1.13.0-1.dsc
 061c87ef5318ce0fc63e64e103163faefaacbacb 241215 strip-nondeterminism_1.13.0.orig.tar.bz2
 565dff8db15428eefcc84551648c486d8123c3c3 833 strip-nondeterminism_1.13.0.orig.tar.bz2.asc
 6a325ace80bacfb25dc89b44263d0dc22b1ec267 33304 strip-nondeterminism_1.13.0-1.debian.tar.xz
 a15b5d199219a454f3cc86f95cf4fccc2e9b77fd 6644 strip-nondeterminism_1.13.0-1_amd64.buildinfo
Checksums-Sha256:
 d367dcdfc7f78943cbf91beec23ea2bf532025b70ba9df1b780e56ab6407078b 2830 strip-nondeterminism_1.13.0-1.dsc
 a70cdad5d728ea78b75d09880c4b51c7d887e89d0b610149b10cfb2abc70b4fc 241215 strip-nondeterminism_1.13.0.orig.tar.bz2
 eaadd8962fae5320f5da489da634292c40cc5f13277da092981b77959ee9bce5 833 strip-nondeterminism_1.13.0.orig.tar.bz2.asc
 cc128139301e53b1599431df3d7eac6366a76d162bd115958c5a6a655ff0283f 33304 strip-nondeterminism_1.13.0-1.debian.tar.xz
 40ca190900be3ef686d744be8f6cb17c65a9f4a23ee0b4109c89a9a3adb038ae 6644 strip-nondeterminism_1.13.0-1_amd64.buildinfo
Files:
 94926f611c2767c4f5182e2f50e86b64 2830 devel optional strip-nondeterminism_1.13.0-1.dsc
 f7a65b3eda2f7a49b199e34734c90f0e 241215 devel optional strip-nondeterminism_1.13.0.orig.tar.bz2
 43146f4fda7c5448fa86825ac2e88179 833 devel optional strip-nondeterminism_1.13.0.orig.tar.bz2.asc
 8ac27bf3c598d134fd89838ea0eef83f 33304 devel optional strip-nondeterminism_1.13.0-1.debian.tar.xz
 834f5c636c34308fd74d562bd9df17d4 6644 devel optional strip-nondeterminism_1.13.0-1_amd64.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmHAvMQACgkQCRq4Vgaa
qhy0LxAAomNxSrlvUt1mvhLrkPt13eEXaL96qCNh/SczPJG8ymMNW0dyJT2FjytU
J2fnwu3zwGMIrkqdIiVwamRwIsMEmxWAdITdXi6NKxxfVm4VaiAycWDom5ymNe2R
0WoYSMu9+BGwKh1v9YfdZ16H1mcZ0dlwbE1OPqXsNdqhxy7GfoEW76boWdPJHlAd
oCTtZVGTiMS70doWQltYf6r4gbgI4BTUI9giJXZ2zZhO4RUhMRQvn61/4KkzFKGW
oEnSbHfbMvSBtdnBOjFarNKHn4NG2SxqrF1YiN3tOaWDluf3RUeFJSvTv8UON5Jo
K016TFbeu0meKQ+9mvZbPQqm7ELw7xQacOl5NiY+yGTLkDZ2CRz9jgPev7HRN6+l
7xDeRexWUX79GB/8qt3f0W45+ed7ED5ghjkwFZdnYluXXk6Idz9og0YPXuzOBNPU
QZZPqUW/NEWOBrZaCp4je4IFbTb9lwFYbhvwaWpVy9AY22wHHOZHD8d92PjQMC2c
ziqNSnCVVuIJ4CRNYPLuPspTAFyKHttH7afGpHppiZPLH+KaZGDutOqUrYO9kHhk
qUIr4lfelx4R39kFbu01ENfc+mJWxAeqPcdgsIXDKNC71BirkItymi66MvxhCL8C
QgVXBNrtU2uJkwfZ69KVV98zgcmltFqQkdlqIosd6yjQCdKR75g=
=u3cz
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.