I wonder if switching from cmake to buck[1] and buckaroo[2] would simplify and increase reproducibility.
Debian reproducibility statistics
31–40 of 72 posts
Re: Debian reproducibility statistics
#32I 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/
Re: Debian reproducibility statistics
#33Earlier 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?
The best approach that I have found is to use the git commit timestamp (or epoch 1 as a fallback) instead of the current timestamp. After all if the build is reproducible, it doesn't matter when it was built, only what input it was given.
To fix that kind of thing, patching is required.
Re: Debian reproducibility statistics
#34Earlier quoted context omitted.
Often, package is built using a certain library version (from a different package), that library is then updated - and the new package cannot build using the new library. Or... deeper parts of the compiler toolchain change, and the application doesn't re-build without changes.
That has nothing to do with reproducible builds - the issue being solved by reproducible builds is that even in exactly the same environment, running the same build script twice can result in differences in the output.
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.
Re: Debian reproducibility statistics
#35Is Docker (or any other container platform) a facilitator to reproducible builds? Making the environment standard between builds is probably easier in a container.
Docker images built with the first-party toolchain aren't reproducible - if you run `docker build ...` on a Dockerfile, then delete the image and rerun it, you'll get a different set of image hashes. This is likely due to timestamp embedding.
There are other toolsets that supposedly create byte-identical Docker images generation (Bazel, some others), but I haven't tried them.
Re: Debian reproducibility statistics
#36Mods, how come my post was completely edited? :)
Re: Debian reproducibility statistics
#37On 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.
Re: Debian reproducibility statistics
#38Earlier quoted context omitted.
That has nothing to do with reproducible builds - the issue being solved by reproducible builds is that even in exactly the same environment, running the same build script twice can result in differences in the output.
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.
Re: Debian reproducibility statistics
#39Is Docker (or any other container platform) a facilitator to reproducible builds? Making the environment standard between builds is probably easier in a container.
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).
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.
Re: Debian reproducibility statistics
#40I wonder if switching from cmake to buck[1] and buckaroo[2] would simplify and increase reproducibility. [1] https://buckbuild.com [2] https://buckaroo.pm
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.