| 28 Nov 2024 |
|  shawn8901 left the room. | 18:48:41 |
| shawn8901 joined the room. | 18:54:09 |
| 29 Nov 2024 |
 p14 | https://r13y.com/ is broken, giving an S3 bucket access error | 15:37:55 |
| p14 | On reproducible builds and -frandom-seed:
- Technically nixpkgs is abusing it.
- https://github.com/bitcoin/bitcoin/issues/2290 -> Concluded it's not needed anymore for reproducible builds in practice.
- https://github.com/NixOS/nixpkgs/issues/153793 -> Noted it is being misused; AND that it breaks CA builds causing a rebuild.
- https://discourse.llvm.org/t/what-is-frandom-seed-useful-for/83345 -> Noted it does nothing on LLVM.
I ponder if it can be simply dropped. Anyone got experience with that?
Does anyone know or have evidence of the lack of frandom-seed causing reproducibility issues on modern GCC? https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/setup-hooks/reproducible-builds.sh
| 15:38:17 |
 raboof | In reply to @p14:matrix.org
https://r13y.com/ is broken, giving an S3 bucket access error where did you still find a reference to it? the new place is https://reproducible.nixos.org | 15:38:36 |
| p14 | Ah. Here: https://github.com/NixOS/nixpkgs/pull/102251#issuecomment-720133612 | 15:38:51 |
| p14 | So I guess a good threshold for determining whether frandom-seed is needed or not would be the minimal iso reproducibility? | 15:39:22 |
| p14 | Oof, rsync isn't deterministic on nixos-unstable @ 4633a7c72337 as it is. | 15:42:35 |
| p14 | error: derivation '/nix/store/gppvg32hwnf1h9dvf38mjwfrs74s12jz-rsync-3.3.0.drv' may not be deterministic: output '/nix/store/x850848v3xl4wxjqzc3q9jp7j6fbkh27-rsync-3.3.0' differs
| 15:42:50 |
| raboof | interesting, it reproduces for me. could you diffoscope it and file an issue (https://github.com/NixOS/nixpkgs/issues/new?assignees=&labels=0.kind%3A+enhancement%2C6.topic%3A+reproducible+builds&projects=&template=unreproducible_package.md&title=)? | 15:45:33 |
| p14 | How do I diffoscope it; how do I get my hands on the installed paths? I just did --keep-failed but from what I see this keeps the build directory but not the install directory? | 15:46:40 |
| p14 | If I diff the rsync binary in the build directory against the installed one, they seem quite different, and the build directory's one hasn't been stripped | 15:47:19 |
| raboof | the --keep-failed should keep something like /nix/store/x850848v3xl4wxjqzc3q9jp7j6fbkh27-rsync-3.3.0.check or so and tell you about it | 15:49:28 |
| raboof | file $(nix-build '<nixpkgs>' -A rsync)/bin/rsync is also not stripped for me | 15:49:55 |
| p14 | OK, nix build --rebuild is different from nix-build --check; the latter reports that as you say. | 15:50:54 |
| p14 | It's just the rsync binary which is differing, and it's differing in various virtual addresses leading to quite a large binary diff. | 15:53:45 |
| raboof | ok, so nothing obvious in the 'readable' parts of the diffoscope output? | 15:55:16 |
| raboof | sometimes 'strings' produces some hint? | 15:55:56 |
| p14 | Filed https://github.com/NixOS/nixpkgs/issues/360152 -- apologies I didn't see the link was to an issue template | 15:59:25 |
| raboof | thanks! nothing jumps out at me at first glance either | 16:02:47 |
| raboof | back to the original topic, though: I'm surprised specifying a -frandom-seed does seem to cause content-adressed rebuilds, but at the same time leaving it unspecified does not cause reproducibility issues. worth an experiment, though, of course. | 16:43:20 |
| raboof | * back to the original topic: I'm surprised specifying a -frandom-seed does seem to cause content-adressed rebuilds, but at the same time leaving it unspecified does not cause reproducibility issues. worth an experiment, though, of course. | 16:43:32 |
 Atemu | It depends on how you define the random seed i.g. If you used $out to deduce it, that'd obviously cause CA rebuilds | 16:51:52 |
| raboof | what is it set to when you leave it unspecified? | 16:52:17 |
| Atemu | It's random IIRC | 16:54:02 |
| raboof | then wouldn't that just-as-obviously cause reproducibility issues? | 16:54:23 |
| Atemu | Sure would | 16:55:08 |
| p14 | It depends how or whether it is used, right? Clang for example doesn’t use it | 16:55:13 |
| Atemu | I fixed that in the kernel once | 16:55:19 |
| p14 | I am unclear how it is used in gcc, is there information about that somewhere? At least for some standard builds of some software, removing it improves reproducibility by removing the outpath from affecting the build. | 16:56:57 |
