Proposal for making Multi-Arch:same binNMU-safe

[Adrian Bunk]

On Thu, Apr 23, 2026 at 03:17:46PM +0200, Johannes Schauer Marin Rodrigues wrote:
>...
> Translating the binNMU +bX suffix into X additional seconds sounds like a hack
> which shows the limitations of the current tooling and which is actually a lie
> because it would create a debian/changelog entry with a date of the past. As a
> human reader I imagine I could find it confusing to read that timestamp.
> Embedding the actual timestamp of when the binNMU was triggered sounds like
> less of a lie and more like the expected thing to happen, at least to me.
>...

I am not sure whether the debian/changelog entry needs a date in the 
past here, my understanding of the problem is that this is only about 
the timestamps of files.

>...
> Why can
> whatever tooling is used (that's not something I'm familiar with) to transform
> "wb nmu <package> . ANY" into the actual command which triggers a rebuild not
> pass a common timestamp as well? The timestamp will be chose by the part which
> processes the "wb nmu <package> . ANY" line and then make sure that on each
> architecture, sbuild is called with the same --binNMU-timestamp=XXX argument.
>...

New architectures are an interesting corner case.

  wb nmu 1 <package> . ANY . -m "Rebuild for time_t"
  # 2 years later:
  wb nmu 1 <package> . loong64 . -m "Rebuild to sync binNMU versions"

This is not a hypothetical example, the "sync binNMU versions" 
binNMUs for loong64 happened this month.

Everything discussed so far is a hack, but a simple and robust hack 
would be preferable.

Would dh_strip_nondeterminism obtaining the binNMU number (which might 
be 0) and adding it to get_non_binnmu_date_epoch() be sufficient for
making Multi-Arch:same binNMU-safe?

> Thanks!
> 
> cheers, josch

cu
Adrian