Nix Package Manager development | 894 Members | |
| For people hacking on Nix: https://github.com/NixOS/nix Nix maintainers can be reached here. | 187 Servers |
| Sender | Message | Time |
|---|---|---|
| 10 Mar 2026 | ||
| * Speaking about patchelf, there has been discussion about using fixpath or some alternative instead, which I don't remember. | 07:26:18 | |
| * Speaking about patchelf, there has been discussion about using fixpath or some alternative instead, which I don't remember. But the reason is for windows and unix are very different binary formats eg. windows being Pe (portable exe), linux being elf, macos being mach-o. | 07:29:18 | |
| if you mean https://github.com/nixcloud/fixPath i think that's PE-only, so "additionally", not "instead" | 07:33:45 | |
| 08:45:47 | ||
| 12:07:25 | ||
| 14:24:52 | ||
| 14:38:36 | ||
| 11 Mar 2026 | ||
| 03:48:02 | ||
Did something change in the behavior of indirect flakeref resolution? nix registry resolve nixpkgs/a3a3dda3bacf61e8a39258a0ed9c924eeca8e293 works but nix registry resolve nixpkgs/nixos-unstable/a3a3dda3bacf61e8a39258a0ed9c924eeca8e293 fails with error: cannot apply both a commit hash (a3a3dda3bacf61e8a39258a0ed9c924eeca8e293) and a branch/tag name ('nixos-unstable') to input 'github:NixOS/nixpkgs/nixpkgs-unstable' | 09:30:45 | |
| 14:11:47 | ||
| 19:49:40 | ||
| I'm trying to think of a way to asynchronously drain a file descriptor into a sink, is it safe to write to a sink from a different thread, assuming that's the only writer? | 21:51:32 | |
| I think source.drainInto(sink) is good for this, there are different overloads. A buffered sink only cares about having one writer | 22:10:32 | |
| (Same for the source too) | 22:10:55 | |
| alright, I'll give it a shot <3 | 22:13:57 | |
man I don't even have nix registry resolve, is it new? | 22:17:41 | |
| Gonna try something like this:
| 23:03:32 | |
| * Gonna try something like this:
| 23:04:31 | |
| 12 Mar 2026 | ||
| Yeah, November 2025: https://github.com/NixOS/nix/commit/063cdb5508bb4a6917eff25e8f8da55ecfedae2e | 00:28:38 | |
| yep, it works! | 01:16:43 | |
| 07:17:57 | ||
| i have made an abomination: binfmt-misc support in nix https://github.com/dramforever/nix/tree/binfmt-misc featuring: double namespacing! not yet even draft pr quality, docs are "i may be here to answer questions", but it's working well enough that i think it's worth having y'all take a look | 12:51:27 | |
| * i have made an abomination: binfmt-misc support in nix https://github.com/dramforever/nix/tree/binfmt-misc featuring: double namespacing! not yet even draft pr quality, docs are "i may be here to answer questions", but it's working well enough that i think it's worth having y'all take a look | 12:52:20 | |
| basically, this lets you run emulated-native builds with something like pkgsStatic.qemu-user (e.g. non-cross aarch64-linux builds on x86_64-linux) without configuring the emulators globally. you don't even need root for that. and also if you do have emulators configured globally this lets you get rid of them in the build sandbox, giving you more purity in cross builds. | 13:10:32 | |
| boot.emulatedSystems but (hopefully) better | 13:11:06 | |
| * basically, this lets you run emulated-native builds with something like pkgsStatic.qemu-user (e.g. non-cross aarch64-linux builds on x86_64-linux) without configuring the emulators globally. you don't even need root for that if you're fine with a diverted store. and also if you do have emulators configured globally this lets you get rid of them in the build sandbox, giving you more purity in cross builds. | 13:14:39 | |
| We were considering something somewhat related on FreeBSD at some point: configure the linuxulator in the nix sandbox runner so that we can run native linux derivations. It would be useful for bootstrapping some programming languages that only provide linux binaries (e.g. dotnet, rust on aarch64) | 15:10:28 | |
| (Linuxulator lol, thought its something you just made up, nope its the term used by freebsd docs, lol) | 15:12:06 | |
| 16:42:59 | ||
| 18:02:38 | ||