[buildd-tools-devel] Bug#843773: Bug#843773: Bug#843773: misleading timestamps in binnmus

Johannes Schauer josch at debian.org
Mon Nov 14 17:10:57 UTC 2016


Hi,

Quoting Ian Jackson (2016-11-14 17:33:55)
> Unless the timestamp is of the binnmu request, plumbing to try to get
> the same timestamp will be difficult.
> 
> I'm not a fan of the idea of merely adding 1 second per binnmu.  That
> would mean that making a second binnmu correctly would involve looking
> in the archive to see what the previous binnmu timestamp was.  It
> would also mean that the timestamps would be quite blatant lies: for
> example, there would be files claiming to have been generated with
> compiler X at time T, where compiler X did not exist at time T.
> 
> If the timestamp is of the binnmu request then I guess it will all
> work, but the extra plumbing seems unnecessary.
> 
> > I also don't see why it's a problem that a package might only be
> > rebuilt on some architectures. If only some architectures of a
> > M-A:same package get a binNMU, then they are not co-installable
> > anyways.
> 
> I think you're right that this isn't a problem.
> 
> Can I ask you the converse question: what same-timestamp proposal do
> you think is best and why ?

I found Guillem's suggestion the most sensible and as far as I understand the
matter also the easiest to implement:

Quoting Guillem Jover (2016-11-09 00:18:25)
> 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.

but that proposal did not get any attention so I somehow assumed that there's
probably a reason not to do so and thus I suggested an alternative: choose the
new timestamp by using the binNMU number and add that many number of seconds. A
+b17 binNMU would add 17 seconds to the original changelog timestamp. Thus, no
archive lookups would be required.

But maybe to talk about this option: what would speak against changing the
"nmu" command of wanna-build to also add an option that allows setting a
timestamp, or even let wanna-build generate that timestamp itself (from the
time it processes the "nmu" command) and then pass it to sbuild via a
not-yet-existing --binNMU-timestamp option?

With that solution we would not have to change anything other than wanna-build
and sbuild. And I would take care of the latter.

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20161114/5aceb82c/attachment.sig>


More information about the Buildd-tools-devel mailing list