| 7 Oct 2024 |
 Sofie | There exists this issue in nixpkgs, but its closed https://github.com/NixOS/nixpkgs/issues/229858 | 13:59:53 |
 emily | (do we have a channel for bootstrap?) | 13:59:55 |
| emily | it would be good to do it | 14:00:05 |
 raboof | there's https://github.com/NixOS/nixpkgs/issues/72606 / https://github.com/NixOS/nixpkgs/pull/85542 | 14:02:22 |
| emily | yeah, it's this:
Well the main problem still remains. And it does not look like mrustc is catching up build a new version of rust. It's just not feasible to have this long chain of rust builds for maintainers with commodity hardware. There 28 version of rust that need to be build in order. Guix has long delays in updating to the lastest version. They had rust 1.39 until very recently. If you want to see this happen consider contributing to mrustc.
| 14:03:10 |
| raboof | (https://github.com/NixOS/nixpkgs/issues/229858 was about the 'current' approach not being deterministic, but I don't think we've seen that problem anymore) | 14:03:13 |
| emily | personally, I don't think that objection makes sense if we're working towards switching to the minimal bootstrap by default | 14:03:25 |
| emily | which itself involves absurd grand tours of decades of software history | 14:03:36 |
| * raboof dreams about ca-derivations where the 'long-way' and 'shortcut' builds arrive at the same result, but that's probably too much work to be feasible :) ) | 14:06:37 |
| emily | I think as long as our rustc is reproducible that should already be the case | 14:07:55 |
| emily | it's more a matter of making contributors and Hydra do the whole rigmarole on staging | 14:08:08 |
| emily | anyway, hopefully we get an independent Rust implementation that can bootstrap rustc without a long chain at some point. e.g. https://notgull.net/announcing-dozer/ or something | 14:08:34 |
| emily | but I'd really like to see a source-based bootstrap, personally | 14:08:49 |
|  Sam Lehman changed their profile picture. | 14:24:49 |
| 8 Oct 2024 |
|  kait joined the room. | 11:00:40 |
| 9 Oct 2024 |
|  chayleaf joined the room. | 11:35:31 |
| chayleaf | can someone please look into https://github.com/NixOS/nixpkgs/issues/346419? the binary cache is missing a file compared to local build for some reason | 12:26:01 |
| raboof | interesting. testing with nix-build '<nixpkgs>' -A freeplane --check --keep-failed it seems to consistently not generate that file - do you think the nondeterminism is in the 'main' build or one of its inputs? | 12:35:44 |
| chayleaf | the inputs are all cached, so its definitely the main build | 12:38:30 |
| chayleaf | basically:
- i haven't built any of the native dependencies myself, they are copied from the cache
- the java dependencies from gradle are downloaded by url+hash pairs, so they can't really differ
| 12:44:20 |
| raboof | tbh I don't see anything obvious in https://github.com/search?q=repo%3Afreeplane%2Ffreeplane%20globalBin&type=code that'd put that file there... maybe compare the builds logs between your local build and the one from the binary cache? | 12:55:56 |
| chayleaf | the tasks run in a different order, maybe parallel building is the issue? | 14:16:40 |
| chayleaf | if its consistently not generating that file for you, can you try setting enableParallelBuilding to false? | 14:17:18 |
| raboof | then I indeed see it | 14:21:10 |
| 12 Oct 2024 |
|  steeringwheelrules joined the room. | 22:47:32 |
| 14 Oct 2024 |
 Moritz Sanft | Hey, we think there's a substantial problem about Nix's store optimisations in conjunction with reproducible builds, and we'd like to hear some opinions on it.
Consider the following:
2 distinct Files in Nix store, same content (-> same NAR hash). But different permissions, except for executability (e.g. 600 and 644). NAR hash is still the same. nix store optimise looks for deduplication possibilities by matching on NAR hashes. Finds the 2 files and hardlinks one to the other.
File is used in an archive, image, etc. (i.e. any file where the permissions influence its actual contents) - Now this file is inherently irreproducible.
I think that either Nix should not use NAR hashes for store optimisation, change NAR to reflect all permissions (which is unrealistic due to the impact of the change). But curious to hear what you think about this. We just tracked down a image reproducibility bug we fought with for a long time to this and it was very annoying to actually find this. | 08:16:40 |
| Moritz Sanft | CC @Paul Meyer (katexochen) | 08:16:50 |
 Sandro 🐧 | Isn't this a common thing that such files need to resolve hard links? | 15:47:15 |
| Sandro 🐧 | I think we had such problems before, not necessarily with permissions though | 15:47:34 |
| raboof | shouldn't files in the store typically have 444/555 permissions anyway? or is that different for hardlinks? | 15:49:47 |
