Proposal for making Multi-Arch:same binNMU-safe

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Helmut Grohne (2026-04-19 12:20:59)
> I would like to correct myself. In my previous reply to Adrian I agreed that
> this would be simple, but pybuildd (or now buildd) as a component does not
> have access to the relevant information (the last non-binNMU timestamp). It
> gets the source package and the version. In principle it could now download
> the package to extract that timestamp, but that would require access to the
> apt configuration of the build environment.  Otherwise downloading the source
> package using the machine environment's apt could easily fail. In addition to
> being error prone, downloading the source package just for extracting a
> timestamp also is less than ideal for resources.

yes, lets not do that.

But as far as I understand it, incrementing the existing timestamp by one
second compared to the last upload is just a workaround for the fact that when
scheduling the binNMU, no timestamp is passed.

As I understood Adrian's mail elsewhere in the thread, a line like:

wb nmu <package> . ANY

Will create around 18 wanna-build commands, one per architecture. 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.

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.

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20260423/36c2156e/attachment.sig>