| 20 Nov 2025 |
samasaur | those are actually totally separate things. the system in system = "aarch64-darwin" (or whatever other arch) is an argument to the nix-darwin.lib.darwinSystem function that takes an architecture and a list of modules and produces a nix-darwin system configuration. its analogous form is the system argument to the nixpkgs.lib.nixosSystem function that takes an architecture and a list of modules and produces a NixOS system configuration.
the system with configurationRevision, stateVersion, and primaryUser (among others) is a namespace of nix-darwin options that you can set which will affect the generated configuration. some of those fields (such as configurationRevision) are the same as the corresponding NixOS fields, while others (such as primaryUser) are unique to nix-darwin
| 23:14:10 |
samasaur | so the short answer is "no, in your flake.nix both the nixpkgs.lib.nixosSystem and nix-darwin.lib.darwinSystem functions take the same type (a string representing an architecture) for the system argument" | 23:15:48 |
samasaur | (i'm saying architecture above to avoid saying "system" even more times to avoid confusion, but given that those strings have kernel information as well, they don't truly represent only an architecture) | 23:17:08 |
John Wiegley | Has anyone seen this sort of error before? It happens every time I try to darwin-rebuild switch now, but only on one of my machines. I've wiped ~/.cache/nix, rebooted the machine, repaired the store, etc., with no effect:
… while fetching the input 'github:nixos/nixpkgs/a8d610af3f1a5fb71e23e08434d8d61a466fc942?narHash=sha256-v5afmLjn/uyD9EQuPBn7nZuaZVV9r%2BJerayK/4wvdWA%3D'
error: cannot enqueue a work item while the thread pool is shutting down
| 23:37:33 |
John Wiegley | aha, https://brainxx.site/blog/fixing-too-many-open-files gives the answer: need to raise my file limit, although the error message really doesn't indicate that | 23:41:36 |
| 21 Nov 2025 |
debtquity | anybody else seeing this while updating to latest nixpkgs?
system-applications> building '/nix/store/qb1b66gq4fla4zgwi1k3fari06a84afs-system-applications.drv'
system-applications> building '/nix/store/xrhfxwxhmqxg1j0yblsp8zdrgcbbij58-system-applications.drv'
system-path> building '/nix/store/dm8cdyp905l4v4nyxl95x587fbw8kw9h-system-path.drv'
system-applications> created 5 symlinks in user environment
system-applications> pkgs.buildEnv error: Can't use string ("/Applications") as an ARRAY ref while "strict refs" in use at /nix/store/xk1hzr5rxgwmqm3lxspr2clayv1a4m7n-builder.pl line 18.
error: builder for '/nix/store/xrhfxwxhmqxg1j0yblsp8zdrgcbbij58-system-applications.drv' failed with exit code 255;
| 00:52:02 |
samasaur | you're probably using buildEnv in your own config | 00:52:28 |
debtquity | hmm | 00:53:05 |
samasaur | see eg https://github.com/nix-darwin/nix-darwin/issues/1640 | 00:53:11 |
debtquity | oh, thanks samasaur. I'll fix and try again | 00:54:10 |
samasaur | anything like
pkgs.buildEnv {
name = "foo";
pathsToLink = "/Applications";
}
should become
pkgs.buildEnv {
name = "foo";
pathsToLink = [ "/Applications" ];
}
| 00:54:12 |
samasaur | * anything like
pkgs.buildEnv {
name = "foo";
pathsToLink = "/Applications";
}
should become
pkgs.buildEnv {
name = "foo";
pathsToLink = [ "/Applications" ];
}
| 00:54:17 |
debtquity | its been so long since i used that haah | 00:54:39 |
Randy Eckenrode | I needed to add (lib.mesonEnable "shared-llvm" true). I guess Mesa tries to link LLVM statically, which breaks when SPIRV-LLVM-Translator links it dynamically. | 01:23:03 |
Randy Eckenrode | result/bin/mesa-overlay-control.py
result/bin/mesa-screenshot-control.py
result/lib/libGL.1.dylib
result/lib/libVkLayer_MESA_anti_lag.dylib
result/lib/libgallium-26.0.0-devel.dylib
result/lib/libVkLayer_MESA_screenshot.dylib
result/lib/libVkLayer_MESA_vram_report_limit.dylib
result/lib/libvulkan_kosmickrisp.dylib
result/lib/libVkLayer_MESA_overlay.dylib
result/share/vulkan/explicit_layer.d/VkLayer_MESA_screenshot.json
result/share/vulkan/explicit_layer.d/VkLayer_MESA_vram_report_limit.json
result/share/vulkan/explicit_layer.d/VkLayer_MESA_overlay.json
result/share/vulkan/implicit_layer.d/VkLayer_MESA_anti_lag.json
result/share/vulkan/icd.d/kosmickrisp_mesa_icd.aarch64.json
| 01:45:16 |
Randy Eckenrode | Looking at a diff between MoltenVK and KosmicKrisp, MoltenVK supports more extensions. Where their feature sets align, KosmicKrisp usually has higher limits. | 01:55:55 |
Randy Eckenrode | For the things they both support, KosmicKrisp is presumably more conformant. | 01:56:43 |
Randy Eckenrode | I’m currently waiting on vkquake to build to see if it works. | 01:56:53 |
Randy Eckenrode |  Download VKQuake - KosmicKrisp.png | 02:46:33 |
Randy Eckenrode |  Download vulkan-caps-viewer.png | 02:48:03 |
Randy Eckenrode | For VkQuake, I had to disable its checks for MoltenVK. | 02:48:45 |
Randy Eckenrode | For vulkan-caps-viewer, I had to fix the derivation on Darwin, which I’ll be submitting shortly. | 02:49:03 |
validitymaiden | Thanks for the feedback; that helps a lot :) | 02:49:27 |
Randy Eckenrode | https://gist.github.com/reckenrode/94666977418beef5aec79d1b1e977e64 | 03:07:54 |
Randy Eckenrode | Patch to build KosmicKrisp in Mesa. The commit is HEAD as of a few minutes ago. Picked because that’s what it was. | 03:08:15 |
Randy Eckenrode | $ otool -L result/lib/libvulkan_kosmickrisp.dylib
result/lib/libvulkan_kosmickrisp.dylib:
/nix/store/9nis19ya24mhzb5j9ykdcrf96p6z5qdb-mesa-25.3.0-unstable-2025-11-20/lib/libvulkan_kosmickrisp.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0)
/nix/store/vxg3p6z49h881sk5q6qa86pjlj4r123d-libxcb-1.17.0/lib/libxcb.1.dylib (compatibility version 3.0.0, current version 3.0.0)
/nix/store/89ck3bns3nfl0r40i4g891nv57jdd7l7-libx11-1.8.12/lib/libX11-xcb.1.dylib (compatibility version 2.0.0, current version 2.0.0)
/nix/store/vxg3p6z49h881sk5q6qa86pjlj4r123d-libxcb-1.17.0/lib/libxcb-xfixes.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/nix/store/vxg3p6z49h881sk5q6qa86pjlj4r123d-libxcb-1.17.0/lib/libxcb-randr.0.dylib (compatibility version 2.0.0, current version 2.0.0)
/System/Library/Frameworks/Metal.framework/Versions/A/Metal (compatibility version 1.0.0, current version 370.63.1)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1900.180.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
| 03:13:24 |
Randy Eckenrode | How does Vulkan work with X11? | 03:15:01 |
K900 | I don't think it does on macOS+ | 08:22:57 |
K900 | * I don't think it does on macOS? | 08:23:02 |
niklaskorz | I was about to say "I'm surprised XQuartz is still maintained" but I guess it isn't really | 10:58:45 |