<!DOCTYPE html><html><head><title></title></head><body><div>On Wed, Jul 2, 2025, at 09:14, Simon Josefsson via rb-general wrote:</div><blockquote type="cite" id="qt" style=""><div>Ismael Luceno <<a href="mailto:ismael@iodev.co.uk">ismael@iodev.co.uk</a>> writes:<br></div><div>> On 30/Jun/2025 08:59, Simon Josefsson wrote:</div><div>>> An example of 1) is the Debian Live CD situation, it is reproducibly</div><div>>> built mostly based on previous binaries, and some of those binaries we</div><div>>> don't have source code for and they are not freely licensed.</div><div>></div><div>> So you're asking to bend common sense so you can include proprietary</div><div>> drivers and/or firmware and call it "reproducible".</div><div>></div><div>> That literally opens the door to call anything "reproducible".</div><div>></div><div>> Maybe just label that as "I want to believe" builds instead.</div><div><br></div><div>I dislike binaries that are not built from source code using tools that</div><div>themselves where not built from source code. But I believe there is</div><div>enough people interested in having a term for the above situation. If I</div><div>understand Holger's description of the history correct, the above</div><div>situation is what we have been called reproducible for many years or</div><div>even since the start for reproducible Debian packages (that are built</div><div>using build dependencies that have some earlier build dependency from</div><div>seeds that have long since bit-rottened or are undistributable).</div></blockquote><div><br></div><div>I would say "build dependenc[ies] from seeds that have long since bit-rottened or are undistributable" are part of the "build environment", not part of the "sources", so that is fine from a reproducible builds perspective (and in "bootstrappable" territory instead). Binary firmware that is embedded into the result is more tricky, though.</div><div><br></div><blockquote type="cite" id="qt" style=""><div>My interpretation of the history is that either we make people who like</div><div>the traditional de-facto definition of "reproducible" unhappy, or we</div><div>make more purist theoretical people who want a rigid definition of the</div><div>terms unhappy. </div></blockquote><div><br></div><div><div>That's an interesting perspective. My own impression is that we've traditionally had a reasonable shared understanding of what we mean by 'reproducible', but that people are trying to stretch the definition too far in the 'loose' direction (e.g. "my product has Reproducible Builds, it only differs in timestamps"). That prompts us to have another look at our definitions to see if we can/should refine them, and perhaps make them more precise/nuanced/'rigid'. I like to think the 'rigid' and 'traditional' people are actually fairly closely aligned, and the shared goal is to avoid diluting the definition too far in the 'loose' direction.</div><div><br></div><div><br></div><div>Kind regards,</div></div><div><br></div><div id="sig124436424"><div class="signature">-- </div><div class="signature">Arnout Engelen</div><div class="signature">Engelen Open Source</div><div class="signature"><a href="https://engelen.eu">https://engelen.eu</a></div></div><div><br></div></body></html>