| 20 Mar 2025 |
K900 | Yes, but that is not magically there, it needs to be bootstrapped | 17:34:59 |
K900 | And on whatever host you're bootstrapping from, it can be something else entirely | 17:35:14 |
K900 | So it should not be relied on | 17:35:18 |
Tristan Ross | That's fair, though for exploring this concept I don't think that'd have an impact with native. | 17:38:27 |
Tristan Ross | Splitting up lib.systems, likely will be organized into a few different PR's based on what is being touched. Once the feature lands, I'd like to start wiring up the linker to work. | 18:42:16 |
Tristan Ross | I've been thinking that it'd be nice to be able to override lib.systems to be able to change a lot of it. Like if someone wants to add a new platform, it could be done there without a PR. It should be possible to implement new platforms with overlays. Obviously, if someone wants to upstream that work then it should be possible. | 19:59:32 |
| Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) joined the room. | 20:12:15 |
Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | Alright, i have come with questions about eldritch horrors beyond human comprehension. What the hell is happening to libiconv here: https://github.com/NixOS/nixpkgs/blob/e83345870e4c1c38b5ade36fe4c89a154f8da403/pkgs/top-level/all-packages.nix#L9517-L9531 ? Github gives up on blame (getting unicorned). It seems the oldest release with this curse is 15.09: https://github.com/NixOS/nixpkgs/blob/release-15.09/pkgs/top-level/all-packages.nix#L7192-L7201 However, whatever preceeded it already was terrible, maybe even more so: https://github.com/NixOS/nixpkgs/blob/release-14.12/pkgs/top-level/all-packages.nix#L5983-L5995
What is going on here, why do we need this, can we clean this up (and how)?
| 20:16:41 |
Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | * Alright, i have come with questions about eldritch horrors beyond human comprehension. What the hell is happening to libiconv here: https://github.com/NixOS/nixpkgs/blob/e83345870e4c1c38b5ade36fe4c89a154f8da403/pkgs/top-level/all-packages.nix#L9517-L9531 ? Github gives up on blame (getting unicorned). It seems the oldest release with this curse is 15.09: https://github.com/NixOS/nixpkgs/blob/release-15.09/pkgs/top-level/all-packages.nix#L7192-L7201, anything more specific needs a local git blame However, whatever preceeded it already was terrible, maybe even more so: https://github.com/NixOS/nixpkgs/blob/release-14.12/pkgs/top-level/all-packages.nix#L5983-L5995
What is going on here, why do we need this, can we clean this up (and how)?
| 20:17:01 |
Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | Credit to K900 who hunted down glibc-iconv derivation to that part in all-packages.nix | 20:17:55 |
Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | * Credit to K900 who hunted down glibc-iconv derivation to that part in all-packages.nix after i was already confused about it | 20:18:12 |
Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | * Credit to K900 who hunted down glibc-iconv derivation to that part in all-packages.nix after i was already confused about where it came from | 20:18:17 |
Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) |  Download image.png | 20:32:36 |
Artturin | alias bb="git log -p -M --follow --stat --" | 20:33:39 |
Alyssa Ross | What's happening is just that some libcs have iconv built in, and others don't, and the appropriate iconv to use varies by platform, no? | 20:34:13 |
Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | right, but why can't we have one iconv package and use that everywhere, ignoring what libc provides altogether? | 20:36:54 |
Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | i understand what it does, but why is this needed in the first place? | 20:37:47 |
Alyssa Ross | Because that would violate assumptions programs make about those platforms, and also now there are two iconv implementations at once, because the libc one will still be there. | 20:43:31 |
Alyssa Ross | Like AIUI packages will expect a slightly different iconv API on Darwin and break if we mess with that property of the platform. | 20:43:31 |
Alyssa Ross | Same reason we don't swap out other random bits of libc to try to make them more consistent between platforms. | 20:43:32 |
emily | copying from #dev:nixos.org:
I think it's a required dependency on literally 0 platforms that work right now IMO we should probably drop it and just require any future especially weird platforms to include it in stdenv Darwin does, for instance looks like MinGW, Android, OpenBSD are the only platforms we have any kind of support for where it's not just libc or included in stdenv?
| 20:56:28 |
emily | it does seem like OpenBSD genuinely doesn't include it in libc (FreeBSD and NetBSD do), but IMO it seems fine to just have it in stdenv | 20:57:09 |
emily | Android is weird anyway and I think only works with prebuilt tooling so I have no idea what the status of that is. | 20:57:29 |
emily | MinGW kinda barely works half the time anyway but it seems fine to put it in stdenv. I'm pretty sure you need libiconv for bootstrap anyway because of GNU build tools wanting it. | 20:58:04 |
emily | (fwiw, while this is true and we include Apple's libiconv in stdenv, there are also packages that require the GNU oneā¦) | 20:59:15 |
Alyssa Ross | I remember @Ericson2314:matrix.org wanted to go the exact opposite direction and explicitly specify dependencies on more things that might not be part of libc on all platforms. | 21:05:59 |
Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | About freebsd: https://github.com/NixOS/nixpkgs/commit/2b6b8e29c7696deaf8aefb7c666325354a9e2399
libiconv on freebsd seems to be cursed | 21:06:13 |
Alyssa Ross | And I broadly vibe with that approach tbh. Explicit is better than implicit. | 21:06:16 |
emily | (okay let's settle on this room) | 21:06:19 |
emily | I agree with that in general, but I think that not providing some sort of common base basically just harms rare platforms in practice | 21:06:41 |