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
Attachment:
signature.asc
Description: signature