Re: [buildd-tools-devel] Bug#843773: misleading timestamps in binnmus
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
(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
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
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