Re: What do we really mean by "reproducible"?
Hi Santiago, I think you are confusing repeatable builds with reproducible builds. When we talk about reproducible builds, we mean what we documented at https://reproducible-builds.org/docs/definition/ to quote from there: "A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts." Whether a build succeeds 100% of the times tried or 2%, is basically out of scope here. And it's entirely plausable to have builds which fails some times, but each time they succeed the results are 100% identical. Surely not ideal, but… reproducible :) -- cheers, Holger signature.asc Description: Digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: What do we really mean by "reproducible"?
Santiago Vila: > Greetings. > > Before I use this rationale more times in some discussions out there, I'd > like to be sure that there is a consensus. > > What's the definition of reproducible? It is more like A or more like B? > > A. Every time the package is attempted to build, the build succeeds, > and the same .deb are always created. > > B. Every time the build is attempted and the builds succeeds, the > same .deb are always created. > > In other words: It is ok to consider "always build ok" as a prerequisite > to consider a source package "reproducible"? > If you are going to be defining things in documents that are meant to be composed and reused later on, then it is better to define terms to be orthogonal to each other, to make this more easy. So (B) is the better option. If you're just arguing with random people on the internet, pick whatever you feel like. If you're writing a standard policy item that people should follow, I'd define "reproducible" as (B) but then say "builds reproducibly" is what is required, with the same meaning as (A). X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: What do we really mean by "reproducible"?
On 2017-01-16, Santiago Vila wrote: > Before I use this rationale more times in some discussions out there, I'd > like to be sure that there is a consensus. > > What's the definition of reproducible? It is more like A or more like B? I don't know if you're aware of the recently created: https://reproducible-builds.org/docs/definition/ > A. Every time the package is attempted to build, the build succeeds, > and the same .deb are always created. > > B. Every time the build is attempted and the builds succeeds, the > same .deb are always created. > > In other words: It is ok to consider "always build ok" as a prerequisite > to consider a source package "reproducible"? If it reproducibly FTBFS, well, I guess that's a form of reproducibility... but I tend to think you need to actually have meaningfully produced binaries, packages, objects, etc. as a result of the build process compare to consider it reproducible. If there's randomness or variability inherent in the build process that causes the build to fail sometimes, I'd say that's not reproducible... so I'd be inclined to say "A". live well, vagrant signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: What do we really mean by "reproducible"?
On 2017-01-16 11:26, Santiago Vila wrote: Before I use this rationale more times in some discussions out there, I'd like to be sure that there is a consensus. What's the definition of reproducible? It is more like A or more like B? A. Every time the package is attempted to build, the build succeeds, and the same .deb are always created. I may be wrong, but I believe that it's not possible to guarantee that the build succeeds every single time, even once we've locked all inputs to be in a known state. Cosmic rays would be one potential breakage, or corruption of a built intermediate artifact etc. B. Every time the build is attempted and the builds succeeds, the same .deb are always created. So I expect this is likely to be more viable than your A. However, for a given set of inputs (including tooling) that are known to create a successful build once, they should always succeed provided there are no infrastructure glitches. I'd also say that reproducibility shouldn't be .deb specific. Other projects are seeking bit-for-bit reproducibility with other packaging mechanisms. So I'd replace "the same .deb" with the same binary artifacts" br Paul ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: What do we really mean by "reproducible"?
On 2017-01-16 14:28, Santiago Vila wrote: On Mon, Jan 16, 2017 at 02:19:44PM +, Paul Sherwood wrote: On 2017-01-16 11:26, Santiago Vila wrote: > Before I use this rationale more times in some discussions out there, > I'd > like to be sure that there is a consensus. > > What's the definition of reproducible? It is more like A or more like B? > > A. Every time the package is attempted to build, the build succeeds, > and the same .deb are always created. I may be wrong, but I believe that it's not possible to guarantee that the build succeeds every single time, even once we've locked all inputs to be in a known state. Cosmic rays would be one potential breakage, or corruption of a built intermediate artifact etc. But I'm not speaking about cosmic rays or disk failures, but things which are intrinsic to the package itself: A very simple and funny example: Would we call a package having this bug "reproducible"? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838828 (It has a mathematically-proved probability > 0 of failure). I would say that's *not* reproducible. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: What do we really mean by "reproducible"?
On Mon, Jan 16, 2017 at 02:19:44PM +, Paul Sherwood wrote: > On 2017-01-16 11:26, Santiago Vila wrote: > > Before I use this rationale more times in some discussions out there, > > I'd > > like to be sure that there is a consensus. > > > > What's the definition of reproducible? It is more like A or more like B? > > > > A. Every time the package is attempted to build, the build succeeds, > > and the same .deb are always created. > > I may be wrong, but I believe that it's not possible to guarantee that the > build succeeds every single time, even once we've locked all inputs to be in > a known state. Cosmic rays would be one potential breakage, or corruption of > a built intermediate artifact etc. But I'm not speaking about cosmic rays or disk failures, but things which are intrinsic to the package itself: A very simple and funny example: Would we call a package having this bug "reproducible"? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838828 (It has a mathematically-proved probability > 0 of failure). Thanks. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
