On Mon, May 15, 2017 at 12:05:17AM +0200, Bill Allombert wrote: > On Sun, May 14, 2017 at 03:20:54PM +0000, Holger Levsen wrote: > > On Sun, May 14, 2017 at 05:05:36PM +0200, Bill Allombert wrote: > > a.) go to http://reproducible.debian.net/$srcpkg and see if its reproducible today. > As I said, I would like to check that my package build is reproducible before > I upload it, not after, so I can be sure that any bug is fixed in the > upload. b.), b.0), c.) and d.) were given as possible "tools" *to build twice with (some) variation(s) and compare the results*. "Reproducible Builds" (in the sense of bit by bit identicall builds) is really a rather new field in the era of software (well, not really, but thats history and bit rotted until it was rediscovered in the early 2010s…) What is trivial, if given, is to show that a package is *un*reproducible. It's much harder to show that a package is reproducible. And given that this is a new field I think it's ok, while somewhat unsatisfying, that maybe some unreproducibility will only be detected by a more advanced tool, like reproducible.debian.net (which aint a,b,c nor d, but e.) after an upload has taken place. This is one of the reasons we are aiming for "packages *should* be reproducible" now, and not "*must* be". > Some of my package were listed as reproducible for several months and > then became unreproducible without any new upload. I do not mind that. I guess this is because we introduced many more variations during 2014 and 2015. During 2016 I don't recall us introducing many varitions, or rather many causing many new unreproducibilty issues… For 2017 there weren't any. > However from a policy point of view, reproducible need to be defined > precisely. Yes! > Generally speaking, reproducible means that the build will > not change if some (but not all) parameters are changed. Yes. > What parameters > are allowed to change need to be defined. I sadly think this is impossible. > One way is specify that would be to provide an authoritative tool to > validate packages. the tool to validate builds should be diff/sha256sum. a tool to simulate all possible variations in the wild would probably need endless time to operate… > PS: I thanks you for your advices, I will reply to you privately if I > need to. While you surely can do so (and I will happily reply) I would even more happily prefer if you could ask me on public list (and ping in private if you havent gotten a reply in whatever you think is appropriate)… a.) then more people can learn b.) you'll probably get faster *and better replies* (esp. on language specific details) and c.) this helps me getting my inbox under control :-) -- cheers, Holger
Attachment:
signature.asc
Description: Digital signature