5 ms·

So happy someone are spending time on this issue, it's like a breath of fresh air and intelligence in the midst of all the usual software (security/privacy/etc.

So happy someone are spending time on this issue, it's like a breath of fresh air and intelligence in the midst of all the usual software (security/privacy/etc. take your pick) mayhem. It's worth reading https://reproducible-builds.org/ https://reproducible-builds.org/ for a brief (re-)reminder on why this project is important. Outtake: "With reproducible builds, multiple parties can redo this process independently and ensure they all get exactly the same result. We can thus gain confidence that a distributed binary code is indeed coming from a given source code."

Kenji 9y ago
Reproducible builds are extremely useful. There are more benefits. For example, suppose you have a build server compiling software packages. If your builds are not reproducible and you want to debug a core dump, but you have no debug information, you are out of luck (well, you could dive into the assembly code, but it's inconvenient). If you want to keep debug information, you need to store them for every single build (what a waste of storage...) because the binary for each build is different. Not so with reproducible builds, you could simply check out the old version and compile it with debug information!
- mschuster91 9y ago
  Most huge Debian packages carry a separate -debug package so you can get the symbols without huge recompilation times + having to set up a buildchain and associated dev libraries of all the packages.
  - jakeogh 9y ago
    Similarly Gentoo has 'splitdebug': https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces#Stripping https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backt...
    - deleted 9y ago
      [deleted]
  - tomjakubowski 9y ago
    I'm nitpicking here, but the convention is -dbg or (recently) -dbgsym as the suffix for packages in the Debian repositories. The Debain repository containing the debug packages itself itself is suffixed with -debug though, as in "unstable-debug".
  - lamby 9y ago
    If you're interested, the old way was to have an explicit -dbg package which often had to be requested, but now they can mostly autogenerated into -dbgsym packages. These are also uploaded to a separate archive these days too to keep the mirror sizes down.
- bennofs 9y ago
  Well, reproducible builds doesn't necessarily mean that it stays reproducible when you turn on debug info.
  - lgas 9y ago
    If both builds turn on debug info, why wouldn't they still be the reproducible?
    - rhencke 9y ago
      Debug information often is choc-full of environment specific goodies that can easily cause builds not to be reproducible. For example, debug information for several languages I've worked with embed the full path to where the source code file was originally compiled. This can easily vary across two machines in a way that when debug information is turned on, the builds are different, but when turned off they are the same.
      - JoshTriplett 9y ago
        While the reproducible builds efforts try to make builds path-independent, at the moment they often settle for reproducibility when built at the same common path. That's still enough that you can reproduce the build yourself.
        m-j-fox 9y ago
        Does path-independent mean what I think it means? One thing I hate about Linux is having to set prefix at build time. You can't tar up a software and move to your home directory on another machine. That and the lack of compatibility between base libraries/kernels means you can't hope to upgrade chrome for yourself easily like anyone on Windows or Mac can trivially do.
        asdfaoeu 9y ago
        No, in this case it just means binaries won't contain / depend on the path you used to compile it in.
- mmagin 9y ago
  Another wonderful side effect: making it easier to change out other parts of the build infrastructure while being able to verify that you haven't broken anything. e.g. trying out experimental changes to ccache.

Kenji 9y ago

Reproducible builds are extremely useful. There are more benefits. For example, suppose you have a build server compiling software packages. If your builds are not reproducible and you want to debug a core dump, but you have no debug information, you are out of luck (well, you could dive into the assembly code, but it's inconvenient). If you want to keep debug information, you need to store them for every single build (what a waste of storage...) because the binary for each build is different. Not so with reproducible builds, you could simply check out the old version and compile it with debug information!

mschuster91 9y ago
Most huge Debian packages carry a separate -debug package so you can get the symbols without huge recompilation times + having to set up a buildchain and associated dev libraries of all the packages.
- jakeogh 9y ago
  Similarly Gentoo has 'splitdebug': https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces#Stripping https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backt...
  - deleted 9y ago
    [deleted]
- tomjakubowski 9y ago
  I'm nitpicking here, but the convention is -dbg or (recently) -dbgsym as the suffix for packages in the Debian repositories. The Debain repository containing the debug packages itself itself is suffixed with -debug though, as in "unstable-debug".
- lamby 9y ago
  If you're interested, the old way was to have an explicit -dbg package which often had to be requested, but now they can mostly autogenerated into -dbgsym packages. These are also uploaded to a separate archive these days too to keep the mirror sizes down.
bennofs 9y ago
Well, reproducible builds doesn't necessarily mean that it stays reproducible when you turn on debug info.
- lgas 9y ago
  If both builds turn on debug info, why wouldn't they still be the reproducible?
  - rhencke 9y ago
    Debug information often is choc-full of environment specific goodies that can easily cause builds not to be reproducible. For example, debug information for several languages I've worked with embed the full path to where the source code file was originally compiled. This can easily vary across two machines in a way that when debug information is turned on, the builds are different, but when turned off they are the same.
    - JoshTriplett 9y ago
      While the reproducible builds efforts try to make builds path-independent, at the moment they often settle for reproducibility when built at the same common path. That's still enough that you can reproduce the build yourself.
      - m-j-fox 9y ago
        Does path-independent mean what I think it means? One thing I hate about Linux is having to set prefix at build time. You can't tar up a software and move to your home directory on another machine. That and the lack of compatibility between base libraries/kernels means you can't hope to upgrade chrome for yourself easily like anyone on Windows or Mac can trivially do.
        asdfaoeu 9y ago
        No, in this case it just means binaries won't contain / depend on the path you used to compile it in.
mmagin 9y ago
Another wonderful side effect: making it easier to change out other parts of the build infrastructure while being able to verify that you haven't broken anything. e.g. trying out experimental changes to ccache.