| 25 Nov 2024 |
 p14 | The next trick will be to write this as an overlay, stdenvStage, or minimal patch against nixpkgs that does this to everything through arcane magic. | 20:37:25 |
 emily | I think you can – just add multiple files and it can be git cloned? | 20:37:34 |
| emily | we need some of this ANSI art in Nixpkgs | 20:37:39 |
| p14 | :D | 20:37:44 |
| p14 | You can put multiple files in, but not multiple directories. They get rejected by the git remote when you try to push them. | 20:37:59 |
| p14 | It was a fun little exercise but I can see there is quite a bit more work involved even when it comes to handling a single package. I'm actually not sure what to reach for to do something as simple as replacing nix paths in a binary; patchelf obviously is the thing to reach for when the strings appear in a specific place, but substituteAll barf'd on the null characters. | 20:39:53 |
| emily | I think Nixpkgs just uses sed for that | 20:40:30 |
| emily | in e.g. remove-references-to | 20:40:33 |
| p14 | Yeah, I thought so too, but I had some issues. I may not have hit it with the stick hard enough. | 20:40:47 |
| emily | you might also want to add an example of a build tool that depends on a library, to screw all the nice properties up | 20:40:54 |
| p14 | Well yeah; that's going to be the interesting/unfortunate case. I was thinking of that in the context of 'glibc' upgrades. ISTM that if you have to relink users of glibc, this means relinking the compiler, which then means everything that uses the compiler has to be rebuilt. | 20:41:38 |
| emily | yes | 20:42:05 |
| emily | the alternative is letting buildPackages drift etc., which isn't fun | 20:42:21 |
| emily | ultimately compiler upgrades are compiler upgrades. what I worry about is more, like, random build stuff that has OpenSSL dependencies | 20:42:43 |
| emily | for hashing or because it has network functionality we don't use or – whatever | 20:42:51 |
| p14 | So I was wondering about how you could make stdenv.mkDerivation do what the gist above does under the hood. Perhaps by modifying how getDev works; I think this would be enough to handle buildInputs. Then you'd need some way to make packages 'be observed as' the relink. | 20:44:42 |
| p14 | Any bright ideas about where such logic could hide? | 20:44:54 |
| emily | it's basically splicing in miniature I think. | 20:46:10 |
| emily | the hard part is making relinking happen. | 20:46:21 |
| p14 | That's about where I was up to :) | 20:46:24 |
| p14 | Another thing I was wondering about was the eval cost of all of this, and whether that is an issue or not (for the likes of ofborg). | 20:47:03 |
 @trofi:matrix.org | In reply to @Ericson2314:matrix.org
trofi: I think it can go directly to master, no? Good catch! Updated as https://github.com/NixOS/nixpkgs/pull/359098#issuecomment-2499050124 (don't know why I did staging last time, possibly because the initial change I had to mitigate was introduced in staging) | 21:31:08 |
| 26 Nov 2024 |
|  Salar Rahmanian (softinio) joined the room. | 18:15:37 |
| 27 Nov 2024 |
| emily | John Ericson: re recent ca-derivations posts, you're aware that as of present it breaks aarch64-darwin basically entirely right? | 02:42:56 |
| emily | (I assume there is no obstacle to rolling it out for Linux only, and there are things that could be done to fix the incompatibility with engineering work, but I just wanted to check that you know this) | 02:43:16 |
| emily | (happy to discuss more) | 02:43:39 |
 John Ericson | @emilazy:matrix.org: err nope I'm not aware of this | 02:44:52 |
| emily | ok. so on aarch64-darwin, every binary must include a code signature or it won't start up. we use "ad-hoc signatures" for everything at present, which is what you get by default when running a compiler and is basically just an SHA-1 hash | 02:46:05 |
| emily | every time a binary is rewritten it must be re-signed, which all the basic tools (install_name_tool which is like macOS patchelf etc.) do out of the box | 02:46:28 |
| emily | therefore rewriting binaries for CA self-references breaks them | 02:46:37 |
