| 20 Mar 2025 |
 Philip Taron (UTC-8) | (To be clear, this was a "I want to play around with this cursed thing in order to learn" not a serious proposal for how to do it.) | 17:21:36 |
| Philip Taron (UTC-8) | * (To be clear, this was a "I want to play around with this cursed thing in order to learn" not a serious proposal for how to do it in nixpkgs production.) | 17:22:37 |
| Philip Taron (UTC-8) | Previous experimentation: https://determinate.systems/posts/nuenv/ | 17:23:23 |
 Tristan Ross | There's a reason why I mentioned "concept" | 17:24:25 |
| Tristan Ross | We don't have to fully implement it but it could be an interesting thing to show what is capable | 17:24:53 |
| Philip Taron (UTC-8) | Other related proposals that involve shipping computational machinery with Nix:
- System-agnostic builders
- Nix on WASI
libnixstore-pure
| 17:26:16 |
| Philip Taron (UTC-8) | Yes, and I believe it's wired through to provide busybox-sandbox-shell specifically. Is that incorrect? | 17:34:10 |
 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 |
