Proposal for making Multi-Arch:same binNMU-safe

[Helmut Grohne]

Hi Johannes and Adrian,

On Thu, Apr 23, 2026 at 05:06:33PM +0300, Adrian Bunk wrote:
> 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.

The timestamp of files very much is not a problem. dpkg is still happy
to have those timestamps differ between multiple instances of the same
binary package for various architectures.

What is a problem is timestamps embedded into files. Those cause
differences in content and cause dpkg to fail installation. If you
disregard binNMUs, this problem has been largely solved via
SOURCE_DATE_EPOCH. The last timestamp of debian/changelog is exported
via this variable and build systems therefore those timestamps embedded
into generated files become reproducible across architectures.

> On Thu, Apr 23, 2026 at 03:17:46PM +0200, Johannes Schauer Marin Rodrigues wrote:
> > 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.

This feels fairly close to what I initially proposed. There, wanna-build
would record the timestamp of the action and buildd or pybuildd would
turn that into the --binNMU-timestamp option.

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

I agree that this example is broken with the approach of recording the
timestamp in wanna-build and that it would not be broken with the
incrementing approach.

This can be addressed with process. A wb action syncing binNMUs can
simply use ". ANY ." and cause slightly more builds. The release team is
fairly disciplined in this regard.

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

>From my pov, all we need is consensus around one of those hacks.
Getting consensus on abandoning binNMUs seems harder.

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

This would fix some of the problems, but not all. It is not just
dh_strip_nondeterminism that consumes SOURCE_DATE_EPOCH but also
upstream build systems. At present, it is dpkg-buildpackage that
initializes SOURCE_DATE_EPOCH from the debian/changelog. Therefore, the
hack could be done in dpkg-buildpackage in principle. I expect Guillem
to disagree here.

Helmut