jcccb
daniel:// stenberg://"Packages that can't be rebuilt byte-for-byte are now blocked from entering Debian's testing branch."
https://itsfoss.com/news/debian-makes-reproducible-builds-mandatory/
Banda BassottiSick! Is Debian the first major distro making this a hard requirement?
Haven't heard of any others.
Askold#nixos is somewhat of pioneer in the space of reproducible builds and is 20 years old
@gonzo_askold @orpach.neocities.org sure, but nix has still included packages that not in themselves were done reproducible I'm pretty sure.
Guilhem Saurel@bagder @gonzo_askold @orpach.neocities.org yes, https://reproducible-builds.org/ also apply to nix : https://reproducible.nixos.org/
there was 100% on minimal iso in december, but there is no hard constraint on the whole 100k+ package set from nixkpgs
there was 100% on minimal iso in december, but there is no hard constraint on the whole 100k+ package set from nixkpgs
I'm not that knowledgeable about inside workings, but in theory (in my head) hashing all inputs does equate to byte-to-byte reproducibility, even if previous steps in the build process weren't written specifically to be reproduced
@gonzo_askold @bagder sadly, that is not the case.
There are many corner cases, but the simplest example is "yes all your dependencies are reproducible, but you decide to `cat /dev/random > $PREFIX/my-seed`" or whatever.
There are many corner cases, but the simplest example is "yes all your dependencies are reproducible, but you decide to `cat /dev/random > $PREFIX/my-seed`" or whatever.
das-g@nim @gonzo_askold @bagder We have to just move one word in the sentence:
«NixOS is [a] pioneer in the space of *somewhat* reproducible builds […].» 🙃
(I use and contribute to NixOS, BTW., so I hope I'm allowed to make this joke.)
@gonzo_askold I'm only pointing out the difference, I'm not suggesting nix did anything bad or wrong.
@bagder idk what would be practical differences between these two systems and how one or the other would be more secure against supply chain attacks or other mitms
would be pretty interested in some reference materials
bmaxvSince it was a big problem with a very desirable outcome, they have a website.
https://reproducible-builds.org/
I think a major problem was that different hardware or architecture or versions of compilers produce different binaries that still work the same. That's why you couldn't just hash everything and compare.
And reproducible builds compensate for those minimal variations.
BB 
@gonzo_askold: this isn't true, as some builds embed things like the timestamp and build hostname in the artifacts. Nix sets some notion of the timestamp to epoch to account for this, but cannot fix every impurity everywhere (maven builds are notoriously finnicky, for instance).
Nix is great at this, but somewhat suffers from embracing the package without submitting the changes it makes to the package upstream. Because nix is so flexible (and doesn't always have the pull that Debian does with packagers), i believe nix has been less influential here than you would hope.
This change from Debian is awesome as we will all benefit from the fixes.
raboof@BryanBennett @gonzo_askold Maven has made good progress in its default behaviour over time, https://maven.apache.org/guides/mini/guide-reproducible-builds.html
I'm sad you get the impression Nix doesn't upstream as much, we really do try.
Debian has been a trailblazer in reproducibility historically and this most recent feat shows they still are - but part of the fun of the reproducible builds project is that it's not a competition but a cross-ecosystem collaboration.
@gonzo_askold: please don't hear that either I think nixpkgs contributors don't try or that nix and Debian are somehow competing here!
Nixpkgs is HUGE and complex and it requires a fair amount of effort to maintain in and of itself. Combined with the relatively small number of contributors, I simply think their focus is generally elsewhere and that nix's flexibility is both a boom and burden here. In my experience, big problems tend to get upstreamed while small ones tend to get substituteInPlace'd (or patchPhase'd away).
Re: Maven: I speak from experience, but my experience is admittedly pretty old. I am glad to hear the situation is improving!
@BryanBennett I've benn daily driving 2 nixos pcs and 2 servers and gf's laptop for the last several years, and I just love to mention nixos everywhere.
"nixos fixes this" "not a problem in nix" and all other little silly thigngs.
I'm connected with my local nix community, there is dozen of us!
for now my experience of writting nix is limited to small wrappers for packages that are not in pkgs and some server managment, but I would like to try to conribute to the upstream in future
@BryanBennett jup - I remember the days of https://github.com/Zlika/reproducible-build-maven-plugin - I was into JVM reproducibility before I even got into NixOS :)
mipIt's a different kind of reproducibility. The outputs may not be byte-for-byte identical because:
1. The build process included strings from the build env, like time of day, paths, username, or hostname
2. The build process included outright random data
3. The build process was naughty and accessed the network (pci.ids? certs?)
4. The build process isn't 100% deterministic (actually common with parallel builds!)
Sam Sneddon 🏳️⚧️@gonzo_askold @bagder there’s plenty of things where there are inputs which aren’t hashed in Nix: time/date, random, host name, username, file system enumeration ordering, memory allocation, etc.
@gsnedders best way of getting correct answer is being publicly wrong, thanks for clarifications
Pol Dellaiera@bagder @gonzo_askold @orpach.neocities.org Indeed, Nix greatly increases the chances of producing reproducible packages by controlling the build environment.
That said, it does not magically make the final artefact reproducible. There can still be sources of non-determinism, and we try to track them down as much as possible.
So far, things are going well! :)
Peder Bergebakken Sundt@Pol @bagder @gonzo_askold @orpach.neocities.org indeed, "replayable" and "hermetic" are better terms for what Nix provides. Some of the bitwise reproducibility of nixpkgs comes from rigorously defining all build inputs, various patches we apply and default build settings we default to. But the brunt of the work is the massive and steller upstream work of https://reproducible-builds.org/, without which nixpkgs would not even be close to bitwise reproducible
Richard J. Acton@bagder @gonzo_askold @orpach.neocities.org I think @guix may have the current highest fraction of reproducible builds in their main repo: https://qa.guix.gnu.org/branch/master If I'm interpreting their rather hard to find and minimal status page correctly. ~92.4% (34,765 of 37,618) of their packages are reproducible.
Data@gonzo_askold @orpach.neocities.org @bagder About reprocductibility, net install was there before ...
@domdel maybe I want there at that time
quick search of "net install reproducible" yields only dotnet stuff
@gonzo_askold In fact #Debian and others are reproductible too.
You can visit https://reproducible-builds.org/ to have an idea. When I worked in administration, we have a server with window NT to install via network on 200 same machines.
You can visit https://reproducible-builds.org/ to have an idea. When I worked in administration, we have a server with window NT to install via network on 200 same machines.
Lazy B0ythe last time i had to fix a nixos system was because a build failed due to a debotstrap deb package they tried to download (whysoever?!) but it went 404 because the old version was taken off the server
thats not very reproducible ;)
@lazyb0y This sort of issue is why Guix builds from source and can automatically fall back on a copy of that source in the software heritage archive even if the original source is not available anymore.
Andreas
Patrice@bagder Wow, that's awesome! Does anyone know if Ubuntu also will force reproducible builds considering that Ubuntu is based on Debian?
Nick Silkey 📻 N5ILK 🪓🪵 🪣💧@harmone I wouldn't bet on it. Ubuntu roadmap from Canonical for the year looks like it goes the other direction of user needs. 👀 💙
Ben Reynolds@nicksilkey @harmone hmmm I hope it really is “layered on top” in such a way that mint can just get rid of it (and that mint does so)
Fun Weirdo@bagder reproducing pkgs seems to be a cool and secure thing
2something@bagder
Sagemath has been absent from Debian Testing since late 2023, which also means it's not in Trixie Stable.
https://tracker.debian.org/pkg/sagemath
I'm betting it will be at least another 3 years before it makes it into testing again (if it ever does).
Sagemath has been absent from Debian Testing since late 2023, which also means it's not in Trixie Stable.
https://tracker.debian.org/pkg/sagemath
I'm betting it will be at least another 3 years before it makes it into testing again (if it ever does).
Dan Sugalski@bagder Nice! And also a little bit worrisome that this is new (though I realize there are some things that make it tricky) but better now than not.
Carlos SolísI checked the list of packages failing reproducibility, and one of the most puzzling items in the list was the LibreOffice suite. I wonder what exactly is making them fail the tests...
Brad Macpherson@bagder Deterministic, not stochastic. This is the way.
Mikel 🇺🇦
Peter H. Fröhlich@bagder This is good stuff and I wholeheartedly support it. In fact, I've been doing this at work with one of our own system images for a while now. Too bad that I don't want to run Debian anymore.
René von Wolfen-Nord 
@bagder awesome
Sharlatan@guix let's review packages acceptance based on their responsibility in light of GCD006
https://codeberg.org/guix/guix-consensus-documents/src/branch/main/006-package-deprecation.md
