NixOS Reproducible Builds | 536 Members | |
| Report: https://reproducible.nixos.org Project progress: https://github.com/orgs/NixOS/projects/30 | 122 Servers |
| Sender | Message | Time |
|---|---|---|
| 26 Aug 2024 | ||
| because you'd prefer to patch stuff? | 14:28:01 | |
| yeah | 14:28:24 | |
| adisbladis: fwiw apparently macOS already scrubs this info for Python https://matrix.to/#/!lheuhImcToQZYTQTuI:nixos.org/$d2JnDxYdhDRsYkHK84BfURKIr4LVjWNiKHAdjVHrmNo?via=nixos.org&via=matrix.org&via=nixos.dev | 14:30:11 | |
| and it has caused a few issues, so be aware if you follow suit | 14:30:19 | |
| 22:14:24 | ||
| 27 Aug 2024 | ||
| 18:02:33 | ||
| 4 Sep 2024 | ||
| 21:48:47 | ||
| 5 Sep 2024 | ||
| Just to confirm for a talk: At some point, the minimal ISO was reproducible, right? | 14:11:57 | |
| yes (https://discourse.nixos.org/t/nixos-reproducible-builds-minimal-installation-iso-successfully-independently-rebuilt/34756) - AFAIK it still is, but I'll admit I haven't tried since June | 14:13:23 | |
I thought jfsutils was scuppering it | 14:13:42 | |
| yes and no: we have a strong indication that jfsutils sometimes produces a different output (https://github.com/NixOS/nixpkgs/issues/276433), but it's rare enough that I have never actually ran into that when trying to reproduce the ISO | 14:17:06 | |
| so we're tracking it and want to fix it to avoid false negatives, but it didn't prevent us from reproducing the ISO so far | 14:18:09 | |
| (aka worst-case the issue would cause us not to trust a build that was actually safe, it will never cause us to trust a build that was actually unsafe) | 14:21:03 | |
| maybe I should get around to removing JFS to help you out :) | 14:21:15 | |
| https://github.com/NixOS/nixpkgs/pull/339821 | 15:01:31 | |
| merry christmas | 15:01:33 | |
| I merged it. | 18:30:22 | |
| I've noticed lately that the key to getting things merged in Nixpkgs is to have a PR message of approximately 5 times the length of the diff | 18:31:41 | |
| It does help that it reads like a motion made with careful forethought and background. In this case, it was actually an anime gif from the release manager that sealed the deal. | 18:33:51 | |
In reply to @raboof:matrix.org by the way, this problem is most likely caused by the gnu&llvm strip bug, since I can't reproduce this very strange output with and this is the end, my strength was not enough for further debugging :( | 20:04:39 | |
| and I was able to reproduce this only in the nix build sandbox, but I did't try to reproduce this with genericBuild under the jfsutils's nix-shell | 20:07:55 | |
| thank you for your work on it :) | 20:08:47 | |
| I hope someone does figure it out | 20:08:54 | |
| even if it won't affect the ISO any longer | 20:09:00 | |
In reply to @raboof:matrix.org* by the way, this problem is most likely caused by the gnu&llvm strip bug, since I can't reproduce this very strange output with and this is the end, my strength was not enough for further debugging :( | 20:11:28 | |
reproducibility-focused friends, i have a derivation which uses the arm embedded and the rpi pico toolchain which builds a .bin and a .elf. i'd like to avoid stripping the debug info but the .elf becomes filled with /build/<8 random chars>.o object names which breaks reproducibility. how can i fix it? | 20:37:39 | |
* reproducibility-focused friends, i have a derivation which uses the arm embedded and the rpi pico toolchain which builds a .bin and a .elf. i'd like to avoid stripping the debug info but the .elf becomes filled with /build/<random chars>.o object names which breaks reproducibility. how can i fix it? | 20:37:58 | |
In reply to @kamillaova:matrix.orgYeah thanks for your awesome work on this! Is there any upstream reference to a strip bug? Or are we only observing it here? | 20:38:31 | |
| i can share it if you like but i'm really just looking for the right strip/objdump invocation. the toolchain integration with nixpkgs is slightly broken | 20:38:36 | |
| * i can share it if you like but i'm really just looking for the right strip/objdump invocation. the toolchain integration with nixpkgs is slightly broken so maybe something that's already supposed to handle this doesn't | 20:39:54 | |