Re: misleading timestamps in binnmus
On 2016-11-08 22:30 -0200, Johannes Schauer wrote:
> Quoting Ian Jackson (2016-11-08 21:48:12)
>> Guillem Jover writes ("Re: misleading timestamps in binnmus"):
>> > So the actual problem is that the last timestamp gets reused for the
>> > binNMUs, which seems totally bogus to me. This needs to be fixed in
>> > whatever is injecting the binNMU entries on the buildds.
>>
>> The same is true for libpython2.7-stdlib.
>>
>> I've dropped the reproducible-builds list and added
>> debian-wb-team@l.d.o in the hope that they may be able to point us in the
>> right direction.
>
> it might be sbuild at fault here. Looking at the code that adds the binNMU
> entries about here:
>
> http://sources.debian.net/src/sbuild/0.72.0-2/lib/Sbuild/Build.pm/#L2045
>
> It seems that sbuild indeed re-uses the timestamp from the last
> debian/changelog entry in the binNMU changelog entry.
This has been done in an early attempt to make binNMUs co-installable in
a multiarch world:
,----
| sbuild (0.62.2-1) unstable; urgency=low
| [...]
| - Improve binNMU handling to permit binNMUs for multiarch packages
| (Closes: #620112). Currently, binary NMUs use the current date
| in the new changelog entry, but co-installable packages require
| an identical changelog. To avoid this, take the date from the
| previous changelog entry to ensure the same date for all binNMUs.
| [...]
| -- Roger Leigh <rleigh@debian.org> Tue, 05 Apr 2011 10:46:49 +0100
`----
Which did not help, because the changelog is not actually identical
anyway.
> Please file a bug report against sbuild with an explanation of what should be
> the correct behaviour that sbuild should follow here, i.e. which date should
> sbuild put into the binNMU entry and why?
I'm afraid I don't really have a good suggestion. Using current date
would work but obviously break reproducibility, and any other date seems
arbitrary.
Cheers,
Sven
Reply to: