Sender | Message | Time |
---|---|---|
7 Oct 2024 | ||
Sofie | Is there any reason why something like mrustc issn't used to bootstrap rustc in Nixpkgs? | 13:57:55 |
emily | I think concerns about how slow the bootstrap would be or something. that's not really a reproducible builds thing though, more of a bootstrappable builds thing | 13:59:49 |
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:
| 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:
| 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:
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 |