| 20 Mar 2025 |
 Tristan Ross |
though I aim to make the one today if it happens.
It is still going to happen, 3 minutes.
| 15:57:55 |
| Tristan Ross |
If the problem is getting PRs reviewed, then one thing that could be done without increasing everybody's workload would be for a volunteer to try to act as a shepherd
I think in this capacity, it would be good if someone does volunteer to do review stuff that there be "office" hours. This would be so the reviewer and PR author could work in real time in tandem. Tom Berek has done this a lot and it's proven to work well it seems.
| 16:00:12 |
| Tristan Ross | https://jitsi.lassul.us/nixpkgs-stdenv meeting started here | 16:01:09 |
| Tristan Ross | https://pad.lassul.us/k_EnCfiJT6ykaiAaNjIYnA# notes will be here | 16:02:14 |
| Tristan Ross | I really like @[Philip Taron (UTC-8)]'s idea of non-shell builders. It's an interesting concept I feel like we should explore more. I think it could make bootstrapping easier if we didn't need something like coreutils and we could only bootstrap from specific compiler toolchain components we fetch. He also pointed out how Nix itself provides a BusyBox shell so this concept could be flushed out more to where we have the nixpkgs derivation builder bundled inside nix. | 17:10:43 |
 K900 | No | 17:18:13 |
| K900 | No no no no no no no | 17:18:15 |
| K900 | No | 17:18:16 |
| K900 | Stop | 17:18:17 |
| K900 | The LAST thing we need is more coupling between Nix and nixpkgs | 17:18:29 |
| K900 | Also, no, Nix does not provide a busybox shell | 17:18:51 |
| K900 | Nix provides whatever shell it's configured with at build time | 17:18:59 |
| K900 | Which in case of Nixpkgs nix is a Nixpkgs shell | 17:19:09 |
| K900 | Which makes this whole idea weirdly mutually recursive | 17:19:17 |
| K900 | You want easier bootstrapping, we have minimal bootstrap for that | 17:19:31 |
 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 |
