Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debian reproducibility statistics

tests.reproducible-builds.org

Post reply on HN
Print view View original

51–60 of 72 posts

Re: Debian reproducibility statistics

#51

Post by forbiddenlake »

thinkMOAR wrote: post #30
penpapersw wrote: post #27

Earlier quoted context omitted.

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

Why do you consider this a joke site? And just because you are easily confused, everybody should stick to .com only?

The link was originally to http://isdebianreproducibleyet.com/ .

Re: Debian reproducibility statistics

#53

Post by stordoff »

hmmm___food wrote: post #10

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?

Debian being open only gives you any sort of assurance if you can prove the binary you are using is compiled from that source. Without reproducible builds, you can only (easily) do that if you are building the source yourself (which obviously most people don't).

Reproducibility doesn't really make much sense when the code _isn't_ open - knowing that unknown source code can reliably produce the same output isn't that valuable.

Re: Debian reproducibility statistics

#56

Post by lamby »

thechao wrote: post #23
hmmm___food wrote: post #10

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?

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.

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

Re: Debian reproducibility statistics

#57

Post by noselasd »

wtallis wrote: post #38
noselasd wrote: post #34

Earlier quoted context omitted.

Surely it can't have "nothing to do" ? Many debian source packages specifies dependencies using >= , something has to account for performing a build using the same minor version of such a dependency.

If the dependency is packaged separately, then you typically wouldn't expect minor version changes in the dependency to affect the contents of the package being built. If there are major changes to the header files being exported or if there's static linking involved then changes are to be expected. But if not, you'd expect the changes to show up in the dynamically linked process image, not the on-disk package.

It really doesn't take big changes to a library that makes the relocation table of an executable linking to it be a tad different

Re: Debian reproducibility statistics

#58

Post by geofft »

entelechy wrote: post #31

I wonder if switching from cmake to buck[1] and buckaroo[2] would simplify and increase reproducibility. [1] https://buckbuild.com [2] https://buckaroo.pm

Well, this is Debian - they generally don't maintain the software, they just package it. Small changes can be pushed upstream, but "Here's a brand new build system that we promise is super cool" is generally not a patch that people like taking :)

Re: Debian reproducibility statistics

#59

Post by geofft »

easytiger wrote: post #19
0xcde4c3db wrote: post #17

Earlier quoted context omitted.

Debian seems to only considers a build reproducible if the entire .deb file is byte-for-byte identical, not just the ELF files. A bunch of the packages they're tracking are flagged for documentation files such as PDFs not coming out identical.

Lots of dates and build numbers, hashes and more get put in binaries let alone package files. How could they ever be b4b the same?

It's a good question! It's in fact such a good question that the reproducible builds folks had to draft a solution for it: the SOURCE_DATE_EPOCH specification. Reproducible builds read the timestamp of the last debian/changelog entry (you can imagine the last git commit or something, for non-Debian packages) and pass it through to the build system, so that the "current" time in tarballs etc. is actually the time of the changelog entry.

https://reproducible-builds.org/specs/source-date-epoch/

For things like build numbers, there's a tool called strip-nondeterminism that cleans them up:

https://packages.debian.org/sid/strip-nondeterminism

Re: Debian reproducibility statistics

#60

Post by yorwba »

philippnagel wrote: post #32
entelechy wrote: post #31

I wonder if switching from cmake to buck[1] and buckaroo[2] would simplify and increase reproducibility. [1] https://buckbuild.com [2] https://buckaroo.pm

Also interesting: https://bazel.build/

Funny that you should mention bazel on the topic of reproducible builds. When I last used it to build TensorFlow, the build was very much not reproducible. I took me three rebuilds with same flags to finally get GPU support compiled in.
Post reply on HN