| 29 Nov 2024 |
 raboof | https://reproducible-builds.org/docs/randomness/ mentions "Link-Time Optimizations" may have to do with it. if we figure out what exactly is going on it'd be good to add that to that page. | 17:00:04 |
 p14 | Yeah, I think it is used in LTO somehow; is LTO used in nixpkgs? If not it could be a noop. And even if it was, it would be good to use a different value for it which does not depend on outpath. | 17:01:22 |
| raboof | if it'd be a noop then setting it to the output shouldn't hurt, though | 17:01:48 |
| raboof | * if it'd be a noop then setting it to the output path shouldn't hurt, though | 17:02:01 |
| raboof | but I agree it doesn't seem like a great choice | 17:02:26 |
 Mindavi | It is at least used to generate the build-id, when separateDebugInfo is set you see that it differs | 17:09:36 |
| Mindavi | When the input path is different and the output is expected to be the same, e.g. when setting an unused environment variable | 17:10:36 |
| p14 | In reply to @raboof:matrix.org
if it'd be a noop then setting it to the output path shouldn't hurt, though Except that it breaks CA derivations because if something varies on the input then the outPath varies, which means now you are varying the compiler args, which results in changes to the bits in the output (e.g because compiler args go into the binaries or the build id) where otherwise you would have bitwise identical outputs.
So downstream packages then need to be rebuilt where otherwise they could have used the previous CA output. | 17:14:45 |
| raboof | aah, so the theory would be that the args are hashed into the output somewhere before being 'interpreted' - yeah I suppose that could be. | 17:19:18 |
| p14 | So it would be preferable to set it to a constant or a function of something which would not vary unless the output is going to vary anyway. | 17:20:41 |
| raboof | a constant would violate the "must be different for each translation unit" requirement even more though | 17:22:15 |
| raboof | but it'd be useful to find out what the impact of not specifying it at all like you suggested would be | 17:22:54 |
| raboof | * but it'd be useful to find out what the impact of not specifying it at all would be like you suggested | 17:23:11 |
| p14 | In reply to @raboof:matrix.org
a constant would violate the "must be different for each translation unit" requirement even more though I haven’t seen anyone articulate why this is important though, I am wondering if it is bogus. I also wonder exactly how/whether it affects the build id as was suggested | 17:31:14 |
|  lassulus changed their profile picture. | 18:30:27 |
| 30 Nov 2024 |
| p14 | raboof: the most significant lead I have for the rsync nonrepro is that the text section is different; and that a handful of symbols are different sizes. If I diff one of those symbols I find that it has extra code towards the end in my local build. | 09:15:03 |
| p14 | It seems as-if I have a reproducible build locally though, so what is divergent is my local build vs what is in cache.nixos.org | 09:16:00 |
| p14 | So I have another x86 machine, and the divergence with cache.nixos.org is not present there. Hardware difference? One's an old intel chip, another is a recent amd chip. | 10:31:20 |
| p14 | Diffing the config log shows that one machine is getting #define INET6 1 in the config.h and the other is not, from checking whether to enable ipv6. | 10:39:47 |
| p14 | What does one do about this sort of non-reproducibility according to machine configuration (in this case ipv6 being disabled)? Is this a tractable problem? Will upstream care? Or is reproducibility only defined if we talk about machines having identical configuration? | 11:54:33 |
| Mindavi | I think it makes sense to ask upstream whether this is intentional | 11:58:20 |
| p14 | I'm writing an issue. | 11:58:29 |
| p14 | In reply to @rick:matrix.ciphernetics.nl
I think it makes sense to ask upstream whether this is intentional https://github.com/RsyncProject/rsync/issues/675 | 11:59:59 |
| p14 | Off topic: I enabled ipv6 to prove that this brings the builds into alignment (which it does), and immediately firefox is now hanging with 'firefox is not responding, force quit?', immediately making me remember why I had ipv6 disabled in the first place :( | 12:11:14 |
 Atemu | Uh, huh, check whether your network's IPv6 configuration is actually correct. I once had a rogue WAP announcing a prefix for instance which caused massive issues (though not FF hanging O.o) | 12:38:30 |
| Atemu | I wonder how a program in the sandbox would even know that IPv6 is disabled | 12:38:49 |
| Atemu | How did you disable that? | 12:38:52 |
| p14 | Kernel command line ipv6.disable=1 | 12:39:03 |
| raboof | In reply to @atemu12:matrix.org
I wonder how a program in the sandbox would even know that IPv6 is disabled configure.sh does if (socket(AF_INET6, SOCK_STREAM, 0) < 0) | 12:39:58 |
| p14 | I don't know for sure that firefox hanging relates to ipv6 being enabled but it is suspicious since I've not otherwise observed that, and it happened pretty quickly after enabling it. But that's also my experience of ipv6 being enabled: random stuff stops working properly in tricky to diagnose ways | 12:40:16 |
