 | Nixpkgs Stdenv | 230 Members |
| 75 Servers |
| Nixpkgs Stdenv | 230 Members |
| 75 Servers |
| Sender | Message | Time |
|---|---|---|
| 15 Nov 2024 | ||
 emily | right. tragic | 09:57:46 |
 p14 | (but thanks for the hint! Hopefully I remember that trick when I future have to target staging) | 09:58:08 |
| emily | usually you can just base it on master. the merge base stuff only matters if something from the 6-hour window before the next merge is relevant to your change | 09:58:44 |
| emily | well, relevant or conflicting | 09:59:15 |
| p14 | Depending on the nature of the change I guess there is always some risk from the delta. | 10:00:07 |
| p14 | But same can be said from the delta of when the PR was made vs when it lands I suppose.. | 10:00:26 |
| emily | staging is kind of an aggregator of fun unexpected risk | 10:01:39 |
| emily | mostly by successfully decoupling making changes from dealing with the pain they produce 😅 | 10:02:21 |
 zoechi joined the room. | 10:17:15 | |
| p14 | emily: one thing I wanted to discuss with you which is a CA /storage footgun: https://github.com/NixOS/nixpkgs/issues/153793 The route is that the current implementation does (-frandom-seed=drvHash). | 10:40:05 |
| emily | -frandom-seed is a real pain | 10:40:59 |
| emily | "the hash of the path of the object file being built so that it is unique to the object file rather than the project being built" doesn't even work because you can have two copies of the same file, or compile the same file twice, or whatever, I think | 10:41:30 |
| emily | maybe hash of the file contents + hash of command line + a counter (but then, nondeterminism from parallelism?) | 10:41:57 |
| emily | ideally C++ wouldn't work like that | 10:42:12 |
| emily | I wonder how viable it would be to just set -frandom-seed=0 and set it specifically in packages that would break | 10:42:28 |
| p14 | https://github.com/NixOS/nixpkgs/issues/151475#issuecomment-1245992562 | 10:42:36 |
| p14 | I've been doing -frandom-seed=fixed in some projects and haven't become aware of ill effects but I do not know what the true generalised consequences might be. | 10:43:10 |
| p14 | The need to have such a seed seems a bit bonkers from a reproducible builds standpoint | 10:43:33 |
| p14 | The idea of hashing stuff in the compiler wrapper is really unappealing from a performance standpoint too | 10:44:06 |
| emily | it's because of C++ saying you can define things in multiple files and they shouldn't collide or whatever | 10:44:14 |
| emily | I want compiler wrappers to die anyway, so 😅 | 10:44:25 |
| emily | btw, as a ca-derivations enjoyer you may enjoy this long but fruitful conversation I had with amjoseph on the Discourse about how we can achieve proper short-circuiting for shared libraries with stubs (like the macOS .tbds I was talking about) and splitting out linking into multiple steps https://discourse.nixos.org/t/why-does-the-nixos-infrastructure-have-to-be-hosted-in-a-centralized-way/46789/32 | 10:44:33 |
| emily | even header cleaning is relevant! | 10:44:39 |
| emily | (also this could dovetail with runtime performance improvements by doing the "dynamic loading" part of things at the time of the "relink" build) | 10:47:45 |
| p14 | That's a great thread, thanks for sharing. | 11:08:30 |
| p14 | I have a feeling I've read it before too. | 11:09:34 |
| p14 | So, how to actually make some of these things happen? | 11:09:43 |
| p14 | I guess there are two parts: 1) get fundamental infra inplace 2) an immense amount of grind to actually make it work sensibly in practice. | 11:10:34 |
| p14 | I've come up with a possible use case for this abandoned PR https://github.com/NixOS/nixpkgs/pull/355000 Being able to put link-only flags in it for | 11:13:11 |
| p14 | * I've come up with a possible use case for this abandoned PR https://github.com/NixOS/nixpkgs/pull/355000 Being able to put link-only flags in it for | 11:13:24 |