[rrdtool-maint] multi-arch:same failures when bin-nmus changelog dates are not the same

[Jean-Michel Vourgère]

On Thursday, 29 March 2018 18:43:25 CEST Julien Cristau wrote:
> On 03/29/2018 06:35 PM, Jean-Michel Vourgère wrote:
> > (...)
> > On arm64 [1] the binnmu .buildinfo contains:
> > Environment:
> >  (...)
> >  SOURCE_DATE_EPOCH="1522153653"
> > 
> > while on armhf [2] the binnmu .buildinfo contains:
> > Environment:
> >  (...)
> >  SOURCE_DATE_EPOCH="1522224789"
> > 
> > /s/b/dpkg-buildpackage (...)
> It parses debian/changelog, which is where sbuild writes the binNMU info
> in the unpacked source.  (...)

I suppose then the best thing to do would be to have dpkg-buildpackage ignore 
the d/changelog entries that are tagged "binary-only=yes" when setting 
SOURCE_DATE_EPOCH, right?

Other options I can think of:

- Have "dch --bin-nmu" keep the last date. Or whatever tool WB uses when 
creating the new changelog entry.

- Have wanna-build set SOURCE_DATE_EPOCH to the last non-binnmu changelog 
entry. This would break package that overwrite SOURCE_DATE_EPOCH themselves. 
So this is a bad idea.

- Prohibit bin-nmu of packages tagged Multi-Arch:same and only do full source 
upload for these. Eeerk :(


Any tough anyone?

I'll fill a bug against dpkg-dev if nobody moves. Please don't wait for me as 
I am sure there are many people more qualified that me in this list.


By the way, shouldn't the "binary-only=yes" property in the changelog should 
be documented in the policy 4.4, especially if unrelated processes start using 
it?