| 11 Mar 2026 |
 pveierland | 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 |
|  Theuni changed their display name from Theuni to Christian Theune. | 14:11:47 |
|  Tyler_PB joined the room. | 19:49:40 |
 Lisanna | 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 |
 Sergei Zimmerman (xokdvium) | 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 |
| Sergei Zimmerman (xokdvium) | (Same for the source too) | 22:10:55 |
| Lisanna | alright, I'll give it a shot <3 | 22:13:57 |
| Lisanna | man I don't even have nix registry resolve, is it new? | 22:17:41 |
| Lisanna | Gonna try something like this:
AsyncPostBuildHookInfo info;
info.act = std::make_unique<Activity>(
*logger,
lvlTalkative,
actPostBuildHook,
fmt("running async-post-build-hook '%s'", worker.settings.asyncPostBuildHook),
Logger::Fields{worker.store.printStorePath(drvPath)});
info.sink = std::make_unique<LogSink>(*info.act);
info.out = std::make_unique<Pipe>();
info.out->create();
info.out->writeSide.close();
info.handleOutput = std::thread([&](Descriptor readSide, Sink & sink) {
drainFD(readSide, sink);
}, info.out->readSide.get(), *info.sink);
// PushActivity pact(info.act->id);
auto pid = runAsyncPostBuildHook(worker.settings, worker.store, *info.out, drvPath, outputPaths);
worker.asyncPostBuildHooks[pid] = std::move(info);
| 23:03:32 |
| Lisanna | * Gonna try something like this:
AsyncPostBuildHookInfo info;
info.act = std::make_unique<Activity>(
*logger,
lvlTalkative,
actPostBuildHook,
fmt("running async-post-build-hook '%s'", worker.settings.asyncPostBuildHook),
Logger::Fields{worker.store.printStorePath(drvPath)});
info.sink = std::make_unique<LogSink>(*info.act);
info.out = std::make_unique<Pipe>();
info.out->create();
info.out->writeSide.close();
info.handleOutput = std::thread([](Descriptor readSide, Sink & sink) {
drainFD(readSide, sink);
}, info.out->readSide.get(), *info.sink);
// PushActivity pact(info.act->id);
auto pid = runAsyncPostBuildHook(worker.settings, worker.store, *info.out, drvPath, outputPaths);
worker.asyncPostBuildHooks[pid] = std::move(info);
| 23:04:31 |
| 12 Mar 2026 |
| pveierland | Yeah, November 2025: https://github.com/NixOS/nix/commit/063cdb5508bb4a6917eff25e8f8da55ecfedae2e | 00:28:38 |
| Lisanna | yep, it works! | 01:16:43 |
| Theuni changed their display name from Christian Theune to Theuni. | 07:17:57 |
 dramforever | i have made an abomination: binfmt-misc support in nix https://github.com/dramforever/nix/tree/binfmt-misc
see also tracking stuff in https://github.com/dramforever/nix/pull/25
tl;dr nix --extra-platforms x86_64-linux --binfmt-misc 'x86_64-linux=:x86_64-linux:M:...' build ...
"just" requires 6.7+ kernel and user namespaces, and it works with diverted store and uid-range
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 |
| dramforever | * i have made an abomination: binfmt-misc support in nix https://github.com/dramforever/nix/tree/binfmt-misc
see also tracking stuff in https://github.com/dramforever/nix/pull/25
tl;dr nix --extra-platforms x86_64-linux --binfmt-misc 'x86_64-linux=:x86_64-linux:M:...' build ...
"just" requires linux 6.7+ kernel and user namespaces, and it works with diverted store and uid-range
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 |
| dramforever | 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 |
| dramforever | boot.emulatedSystems but (hopefully) better | 13:11:06 |
| dramforever | * 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 |
 Artemis Tosini (NixOS) | 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 |
 magic_rb | (Linuxulator lol, thought its something you just made up, nope its the term used by freebsd docs, lol) | 15:12:06 |
|  @popcorn:xaos.space left the room. | 16:42:59 |
|  crstl changed their profile picture. | 18:02:38 |
| Lisanna | If I do copyPaths(sshStore1, sshStore2, ...), will everything get funneled through the local host? Or will a connection be made from the machine hosting sshStore1 to sshStore2? | 21:55:29 |
| Sergei Zimmerman (xokdvium) | In reply to @lisanna-dettwyler:matrix.org
If I do copyPaths(sshStore1, sshStore2, ...), will everything get funneled through the local host? Or will a connection be made from the machine hosting sshStore1 to sshStore2? The local machine will pull from store1 and push into store2. | 23:55:30 |
| Sergei Zimmerman (xokdvium) | There aren’t really mechanisms for doing ssh -> ssh copies directly | 23:56:10 |
| Lisanna | ok, I suppose to do that I will have to just invoke ssh-copy-closure on remote 1 to remote 2 | 23:57:01 |
| Lisanna | * ok, I suppose to do that I will have to just invoke nix-copy-closure on remote 1 to remote 2 | 23:57:25 |
| Lisanna | thanks for clarifying <3 | 23:57:49 |
| 13 Mar 2026 |
| Lisanna | Just checking my understanding, but there's no way with the current implementation for a build-hook to receive the full build graph (i.e. a top-level derivation with unbuilt dependencies), right? But acting like a store or a NIX_REMOTE it would? The nix client doesn't piecemeal request builds from the daemon in topological order, it just sends the full build graph, right? | 18:07:47 |
| 19 May 2021 |
|  @eelco:nixos.org changed the history visibility to "world_readable" from "shared". | 15:40:14 |
