
Debian reproducibility statistics - lamby
https://tests.reproducible-builds.org/debian/reproducible.html
======
YouKnowBetter
On a side note: A point that many a company ignores when they demand some
assurance so their software vendor a) can be held liable b) will hand over the
source in case of drama, is to give the source code in Escrow. The number one
error these companies make is to think that source code without a reproducible
build environment means anything at all. Reproducibility is not easy. I
applaud Debian (and in the older days TrueCrypt) for giving this more
exposure.

~~~
bluGill
Someplace my company has a closet with a computer containing Windows XP (not
sure which service pack, but not the latest), and and old version of visual
studio, just in case we need to fix a bug. I know we still have it because the
project got resurrected recently and we had to clone the harddrive a few times
because nobody could find a copy of that version of visual studio that can be
installed. (Microsoft dropped support for whatever version of WinCE with no
upgrade path)

~~~
monocasa
We have a bunch of VMs cloned from ancient machines for the same reason.

------
agumonkey
What a nice progression [https://tests.reproducible-
builds.org/debian/stats_issues.pn...](https://tests.reproducible-
builds.org/debian/stats_issues.png)

Project started in 2014 it seems.

~~~
Mchl
I'd invest in that

~~~
tome
_But would you have been able to hold your nerve through May?_

------
bialpio
Can someone shed some light on what exactly "reproducible" means in this
context?

~~~
dozzie
It's a term for binaries (usually ELF) being byte-to-byte equal in two
different runs of a compiler. This way you can build a binary package from
source package and if its content is the same, you know what source code was
used to build the package, and then you can e.g. inspect the code for
backdoors or build debug symbols without planning for that beforehand.

[https://en.wikipedia.org/wiki/Reproducible_build](https://en.wikipedia.org/wiki/Reproducible_build)

~~~
gnasr
And why Debian is not reproducible?

~~~
wiz21c
because during the compilation, some package use date-dependent stuff, for
example (I dunno the exact details though)

~~~
vertex-four
Also some build systems create artifacts as a result of timing-dependent
algorithms. Simply put, if two things A and B run simultaneously, and A
completes before B, then in some compilers/build systems/etc the result can be
different from B completing before A. GHC, as a well-known example, suffers
from this problem.

------
mmagin
See also this page of tools: [https://reproducible-
builds.org/tools/](https://reproducible-builds.org/tools/)

disorderfs is nice for ferreting out readdir()-ordering effects.

------
vegbrasil
Is Docker (or any other container platform) a facilitator to reproducible
builds? Making the environment standard between builds is probably easier in a
container.

~~~
0xcde4c3db
Docker is part of a broader "reproducible build environment" strategy, but
doesn't really help with some of the things that cause problems (timestamps,
kernel version, random IDs).

~~~
wtallis
Docker seeks to reproduce a functionally equivalent software environment,
motivated by version management concerns. Debian is trying to reproduce
bitwise identical build products, motivated by security concerns.

------
entelechy
I wonder if switching from cmake to buck[1] and buckaroo[2] would simplify and
increase reproducibility.

[1] [https://buckbuild.com](https://buckbuild.com)

[2] [https://buckaroo.pm](https://buckaroo.pm)

~~~
moosingin3space
Based on the experiences of systemd, gtk, and X11 in switching to Meson, I'd
think Meson might be the best choice here. While Buck, Bazel, Pants, etc. are
designed for large projects, Meson is designed for small-to-medium-size
projects and integrates with pkg-config, which in turn should provide simpler
integration with distribution package managers. My experiences with Bazel
demonstrated that integration with distribution packages can be quite
difficult.

~~~
entelechy
why I'm consider that using pkg-config in buck may break reproducibility:
[https://github.com/facebook/buck/issues/1430](https://github.com/facebook/buck/issues/1430)

------
pavlov
The lack of a .yet TLD is a real missed opportunity.

~~~
penpapersw
Meh, joke sites like this aren't nearly as prominent as sites for apps, I'd
really like a .app TLD instead. That said, the distinction between app and
service is blurring a lot, so Spotify and VS Code probably both qualify for
.app but one also has a web interface. Everything is confusing, let's just
stick to .com

~~~
thinkMOAR
Why do you consider this a joke site?

And just because you are easily confused, everybody should stick to .com only?

~~~
forbiddenlake
The link was originally to
[http://isdebianreproducibleyet.com/](http://isdebianreproducibleyet.com/) .

------
lamby
Mods, how come my post was completely edited? :)

~~~
dang
The _is-foo-bar-yet.com - > NO/YES_ trope has been off topic on HN for years,
mainly because such pages are unsubstantive but also because it's long been a
cliché.

If we can find a more substantive page to link to on the same topic, we'll
sometimes change the URL. Usually we post a comment explaining that we did so,
but it depends who's on duty at the time.

~~~
Sir_Cmpwn
I personally don't think _is-foo-bar-yet.com_ has been played out, nor do I
agree with editing cliche links like this. The link is more substantive than
you let on.

------
hmmm___food
Maybe im missing something but it seems the justification behind this is based
on a situation in which source wasnt open. Debian _is_ open so why is
reproducibility a priority?

~~~
thechao
I know Debian has lofty goals with respect to reproducibility, but on a purely
"I hate waiting for builds", getting deterministic object files can prevent
spurious linking. For example: change a comment, watch your code link for 10
minutes.

~~~
lamby
Mmm. Think of the CO2/power savings at a big coding shop like, I dunno,
Google...

