zOn Thu, 2016-01-28 at 19:01:59 +0100, Holger Levsen wrote:
> On Donnerstag, 28. Januar 2016, Guillem Jover wrote:
> > Hmmm, leaking the hostname seems slightly privacy-concerning? If the
> > information therein is not relevant I'd rather use something like an
> > UUID (although that would require increasing the pseudo-build-essential
> > set), or just hashing the hostname-timestamp with something like md5
> > or sha1 or similar.
> yeah, "something / anything" is fine. dak / the archive software can rename 
> it 
> anyway, as it likes.

Ah ok, perfect then.

> (I'd be in favor of naming the first accepted buildinfo 
> file of the archive just "00000000" so that it's predictable…

I'm not sure how we'd use a sequential number in a distributed manner
starting with 0s though? :9

> > I've some pending changes I'll be committing to master or a separate
> > branch, that I'd like to be tested on the reproducible setup (ideally
> > against the already generated and pre-existing reproducible binaries),
> > if that's possible, I'll ask about that when those land, I just need
> > to finish up fewm more unit tests.
> That's possible, though not (yet nor in near future) against pre-existing 
> binaries. (We lack the code for that.)
> What we can do easily, is build and upload dpkg to our repo and use it to 
> build the whole Debian archive on amd64, which roughly takes 8 days for both 
> sid+stretch, and thus roughly 4 days for one suite, if we disable building 
> the 
> other. (Which we can definitly do, especially if we don't disable building of 
> new versions in that other suite…)

Oh ok, that's a bit unfortunate, it would be nice to be able to catch
any possible regressions in the generated binaries, and it would also
show how to use reproducible builds to see that nothing has actually
changed, even after implementation changes in the toolchain.

On Thu, 2016-01-28 at 19:02:53 +0100, Holger Levsen wrote:
> +many thanks for your thorough review! :-)

No problem!


Reproducible-builds mailing list

Reply via email to