| 5 Sep 2024 |
 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
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 * 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 dontStrip = true (after 1000+ rebuilds, with dontStrip = false it fails to reproduce under ~300 rebuilds)
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.org
by the way, this problem is most likely caused by the gnu&llvm strip bug, since I can't reproduce [this](https://reproducible.nixos.org/nixos-iso-minimal-runtime/diff/f6324ec1d2bd8e7eb94aa170221be10b9f59702ddd8c6eda0190dcb70f82e850-bb3de609e45cb1278589282568f7b92cf577c1a69c6aad2efc16f013a94dcceb.html#:~:text=0000000000402480%C2%B7%3C(-,null,-)%3E%3A) _very strange_ output with `dontStrip = true` (after 1000+ rebuilds, with `dontStrip = false` it fails to reproduce under ~300 rebuilds)
and this is the end, my strength was not enough for further debugging :( Yeah 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 | -fdebug-prefix-map
| 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 /build in debug info are completely unhelpful
| 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 |
| emily | In reply to @qyliss:fairydust.space
I think the main weird bit would be that we'd want to start unpacking tarballs in separate derivations. IIRC the times I've ended up doing this out of necessity it's been noticeably slow because of I guess hashing on store ingest | 08:10:48 |
| Alyssa Ross | And then still does it in the same derivation | 08:11:00 |
| emily | though that might have been incombination with copying it in another derivation too | 08:11:00 |
| emily | hm, that would mean we're not preserving original tarballs, which may or may not matter but makes me a little sad all the same | 08:11:32 |
| Alyssa Ross | We'd also need to apply patches as part of this | 08:11:46 |
| emily | you know, lazy trees would fix this 🤪 | 08:12:08 |
