 | NixOS Reproducible Builds | 482 Members |
| Report: https://reproducible.nixos.org Project progress: https://github.com/orgs/NixOS/projects/30 | 108 Servers |
| NixOS Reproducible Builds | 482 Members |
| Report: https://reproducible.nixos.org Project progress: https://github.com/orgs/NixOS/projects/30 | 108 Servers |
| Sender | Message | Time |
|---|---|---|
| 5 Sep 2024 | ||
 Philip Taron (UTC-8) | I merged it. | 18:30:22 |
 emily | 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 |
| Philip Taron (UTC-8) | 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 |
 Kamilla 'ova | 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 |
| Kamilla 'ova | 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 |
| emily | thank you for your work on it :) | 20:08:47 |
| emily | I hope someone does figure it out | 20:08:54 |
| emily | even if it won't affect the ISO any longer | 20:09:00 |
| Kamilla 'ova | 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 |
 tpw_rules | 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 |
| tpw_rules | * 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 |
 raboof | 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 |
| tpw_rules | 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 |
| tpw_rules | * 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 |
| tpw_rules | (there might be a compiler flag to add?) | 20:40:01 |
| raboof | I don't know - it might be interesting to consider 'separateDebugInfo' to move the debug info to a separate output that might be less important to have reproducible? | 20:44:35 |
| tpw_rules | it looks like these are FILE entries in the symbol table, i wonder if gcc can be controlled to omit the object names. source names are good | 20:53:00 |
| tpw_rules | looks like it's a quirk of the rpi pico toolchain that it uses a temporary file name anyway, bleh | 21:12:37 |
| 6 Sep 2024 | ||
 Alyssa Ross | There's a flag to have it be a relative path I think | 08:01:22 |
| Alyssa Ross |
| 08:01:53 |
| raboof | ah, https://reproducible-builds.org/docs/build-path/ | 08:02:09 |
| Alyssa Ross | It might be nice to use that globally in Nixpkgs, because paths starting with | 08:02:19 |
| Alyssa Ross | But even better would be to build directly from unpacked source store path, because then we'd be encoding the exact input files in the debug info paths… | 08:03:05 |
| emily | I wish I could believe that build systems would support out-of-tree builds well enough for that to work 🫠 | 08:08:57 |
| emily | would be cool though | 08:09:04 |
| Alyssa Ross | Most do | 08:09:08 |
| Alyssa Ross | We couldn't do it universally, but it could be the norm | 08:09:19 |
| Alyssa Ross | I think the main weird bit would be that we'd want to start unpacking tarballs in separate derivations. | 08:09:59 |
| Alyssa Ross | (We wouldn't want to just switch to fetchzip, because it's nice to be able to check the hash before operating on the output where it's reproducible) | 08:10:22 |
| Alyssa Ross | I guess we could have a mode where it checks the hash before unpacking | 08:10:48 |