| 15 Nov 2024 |
|  diamond (it/its) changed their profile picture. | 23:00:53 |
| 17 Nov 2024 |
|  @orzklv:matrix.org joined the room. | 02:29:19 |
| 19 Nov 2024 |
| diamond (it/its) changed their profile picture. | 21:15:40 |
| 20 Nov 2024 |
|  Inayet removed their profile picture. | 00:59:09 |
| 22 Nov 2024 |
|  Morgan (@numinit) joined the room. | 17:50:55 |
| 27 Nov 2024 |
|  @sky1e:mildlyfunctional.gay left the room. | 03:15:14 |
|  @meidam:matrix.org left the room. | 10:58:30 |
|  jopejoe1 (4094@39c3) changed their display name from jopejoe1 to jopejoe1 [4094]. | 18:17:52 |
| 28 Nov 2024 |
|  Honnip left the room. | 04:03:35 |
|  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 |
