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

[Raphael Hertzog]

Hi,

On Mon, 14 Nov 2016, Johannes Schauer wrote:
> > 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

I don't think so. Given the discussions we had, I agree that it would be
best if the bin-nmu timestamp could be set by wanna-build itself, at the
time the binnmus are requested. That would give a consistent (and real)
timestamp across all arches being rebuilt together.

> 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.

This is assuming that the bin-nmu versioning space is linear. It no longer
is because the bin-nmu is no longer defined by the "+bX" added to the
version but by the "binary-only=yes" changelog attribute.

In fact, I expect that we will want bin-nmu within PPA and that we will
have bin-nmu versions like +ppafoo1 in one repo and
+ppabar1 in another repository. (Ubuntu could also benefit
from this when it rebuilds a single source package for multiple release
in a PPA.)

That's something that you could already implement in sbuild BTW. It
currently does not allow to pass such a binNMU version while dpkg
allows it. :-)

Maybe it can be smart and if the parameter to --binNMU-version contains
(or starts with?) non-digits, then it should assume that it's the full
bin-NMU suffix that is passed.

> 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.

+1 from me on this solution. I don't see anything significant drawback.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

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

[Ximin Luo]

(resending again to the correct addresses; I could never get used to debbugs CC 
behaviour.)

Ximin Luo:
> Ansgar Burchardt wrote:
>> The date from the last sourceful upload should probably still be used
>> for any date/time information included in generated files to ensure
>> they are identical on all architectures (or at least to try to do so).
>>
>> If you change the date in the binNMU entry, SOURCE_DATE_EPOCH should
>> probably be set to the date of the last sourceful upload (instead of
>> just using the most recent changelog entry).
>>
> 
> Holger Levsen wrote:
>> On Thu, Nov 10, 2016 at 08:59:48AM -0200, Johannes Schauer wrote:
>>> One solution would be to increase SOURCE_DATE_EPOCH by 1 second for every
>>> binNMU to a package.
>>>
>>> Any other ideas?
>>
>> set SOURCE_DATE_EPOCH to the creation time of that changelog.$arch
>> entry?
>>
> 
> I'm tending towards the latter suggestion because it's simpler. There's no 
> need to stick to a +1 second scheme etc, and it might mislead people into 
> thinking they can do calculations with this - such as reversing the original 
> timestamp of the sourceful-upload.
> 
> Our naming of "SOURCE_DATE_EPOCH" did not really take into account the fact 
> that a source package can be built with many different configurations to 
> create many different build products that are each reproducible themselves. 
> (Debian itself also doesn't do this too clearly, the "+bn" syntax "looks 
> like" it's just a suffix but actually signals an entirely different namespace 
> from source package versions.)
> 
> If it helps one sleep better, one can interpret the "SOURCE" in 
> "SOURCE_DATE_EPOCH" to refer to "all implicit and explicit inputs of the 
> build result, including the source code of the package being built but also 
> the binary build dependencies".
> 
> (If you want to be super-accurate, you can take the max() of all of the 
> changelogs of all of the transitive build-deps, but I think that's going a 
> bit too far.)
> 
> X
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

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

[Holger Levsen]

On Thu, Nov 10, 2016 at 08:59:48AM -0200, Johannes Schauer wrote:
> One solution would be to increase SOURCE_DATE_EPOCH by 1 second for every
> binNMU to a package.
> 
> Any other ideas?

set SOURCE_DATE_EPOCH to the creation time of that changelog.$arch
entry?


-- 
cheers,
Holger


signature.asc
Description: Digital signature

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

[Johannes Schauer]

Hi,

Quoting Emilio Pozuelo Monfort (2016-11-10 07:04:55)
> On 10/11/16 10:00, Ansgar Burchardt wrote:
> > The date from the last sourceful upload should probably still be used
> > for any date/time information included in generated files to ensure
> > they are identical on all architectures (or at least to try to do so).
> > 
> > If you change the date in the binNMU entry, SOURCE_DATE_EPOCH should
> > probably be set to the date of the last sourceful upload (instead of
> > just using the most recent changelog entry).
> 
> There are many differences among different architectures, see e.g.:
> 
> lame (3.99.5+repack1-9+b1) sid; urgency=low, binary-only=yes
> 
>   * Binary-only non-maintainer upload for amd64; no source changes.
>   * Rebuild against ncurses 6.0.
> 
>  -- amd64 / i386 Build Daemon (x86-csail-01)
>   Thu, 11 Jun 2015 12:33:22 +0200
> 
> But that is not a problem as the entry is added to changelog.$arch for this 
> reason.

ansgar is not just talking about the changelog which indeed lives in different
files, depending on the host architecture.

What if there are files that are shared by a M-A:same package but with content
that depends on SOURCE_DATE_EPOCH? If we just generate a new date for every
individual build, then these files will be different and the package not be
co-installable anymore.

Quoting Sven Joachim (2016-11-10 07:14:27)
> Wouldn't this cause dpkg-deb to clamp the mtime to that date, precisely
> the problem this thread is all about?

yes, which is why we probably shouldn't set SOURCE_DATE_EPOCH to the same value
again but find a different solution.

One solution would be to increase SOURCE_DATE_EPOCH by 1 second for every
binNMU to a package.

Any other ideas?

Thanks!

cheers, josch


signature.asc
Description: signature