| 26 Aug 2024 |
 emily | and it has caused a few issues, so be aware if you follow suit | 14:30:19 |
|  Sami Liedes joined the room. | 22:14:24 |
| 27 Aug 2024 |
|  @aloisw:kde.org left the room. | 18:02:33 |
| 4 Sep 2024 |
|  SomeoneSerge (utc+3) changed their display name from SomeoneSerge (UTC+3) to SomeoneSerge (nix.camp). | 21:48:47 |
| 5 Sep 2024 |
 Moritz Sanft | Just to confirm for a talk: At some point, the minimal ISO was reproducible, right? | 14:11:57 |
 raboof | 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 |
| emily | I thought jfsutils was scuppering it | 14:13:42 |
| raboof | 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 |
| raboof | 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 |
| raboof | (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 |
| emily | maybe I should get around to removing JFS to help you out :) | 14:21:15 |
| emily | https://github.com/NixOS/nixpkgs/pull/339821 | 15:01:31 |
| emily | merry christmas | 15:01:33 |
 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
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: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
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 |
