Nix on macOS | 1209 Members | |
| “There are still many issues with the Darwin platform but most of it is quite usable.” — http://yves.gnu-darwin.org | 202 Servers |
| Sender | Message | Time |
|---|---|---|
| 23 Apr 2026 | ||
| Don't get close to full either... the latency gets absurd in the high 90%s 😢 | 14:22:52 | |
| Does anyone know how to set up a Linux builder with Determinate Nix? I wanted to try it, but maybe it is hidden behind some feature toggle or I'm clueless. With nix-darwin I can set nix.linux-builder.enable = true, does determinate have its own module I need to include? | 14:39:21 | |
| afaiu the linux builder for determinate is experimental and invite-only,at least last I checked | 14:41:33 | |
| you can email them for access: https://docs.determinate.systems/troubleshooting/native-linux-builder/ | 14:42:13 | |
| Thanks, I should have read the fine print. I will try the email route. | 16:01:54 | |
Okay, I’m back. Deleting the store and doing some cleanup freed up ~400 GiB of space. I should hopefully be good for a while. Took the opportunity to update to Lix 2.95.1. Yay for being able to set log-format in nix.conf. | 16:32:15 | |
| RandyEckenrode: Do you mean Nix won't be able to GC? Or does APFS suffer from the issues Btrfs used to run into? | 17:58:57 | |
| APFS needs free space to delete files in a volume. I had to make space by deleting a volume in the same container. | 18:32:01 | |
| I think that’s the same as btrfs and ZFS. | 18:32:31 | |
| Btrfs used to have such a problem but reserves some space to always be able to delete something now I think. | 19:54:18 | |
| Has anyone else seen a Python package die due to code signing? Termination Reason: Namespace CODESIGNING, Code 2, Invalid Page | 23:16:24 | |
| Does it build a native extension? If so, I guess that could end up with a bad signature. | 23:17:19 | |
| It's definitely using Cython | 23:19:06 | |
| Is this on staging or master? | 23:20:19 | |
| master | 23:20:27 | |
| Staging got linker upgrade. (though I doubt it will help.) | 23:20:51 | |
| I had no luck bisecting it -- ran into xxHash being missing (looks like one of the backport PRs did that) | 23:22:23 | |
| 24 Apr 2026 | ||
| Since I'm planning to fork xcbuild to include the bits needed for swift-build, I wanted to ask about the fate of tools in
| 01:09:56 | |
| * Since I'm planning to fork xcbuild to include the bits needed for swift-build, I wanted to ask about the fate of tools in
I'm leaning towards option 2 and let projects include specific tools as needed, but could be convinced otherwise. Do people have strong opinions here? | 01:10:00 | |
| * Since I'm planning to fork xcbuild to include the bits needed for swift-build, I wanted to ask about the fate of tools in
I'm leaning towards option 2 and let projects include specific tools as needed, but could be convinced otherwise. Do people have strong opinions here? | 01:10:45 | |
| 01:20:34 | ||
| I found that after updating nixpkg, the permissions granted in the macOS settings will be invalid. Is there any good solution to this problem? | 08:54:22 | |
| direnv is failing on nixpkgs-unstable https://github.com/NixOS/nixpkgs/issues/513019
Does this mean that failure on direnv builds for darwin can be ignored and we get a broken nikpkgs - or is this just a one off manual error? | 10:06:02 | |
| Unfortunately, no. If the application is ad hoc signed, you’ll have to reauthorized every time it’s updated. | 11:54:00 | |
| It’s the issue with Fish having an invalid signature. | 11:54:26 | |
| My build environment is back to where it was before running out of disk space (except with ~265 GiB free). I’m working on wrapping Swift. It’s unfortunately necessary to use a binary bootstrap. The alternative is requiring builds to inform Swift of where to find libc++ and libc (on Linux), but that’s unreasonable to require of users using Swift in dev shells. | 11:58:41 | |
| I so really hate the wrapper-based model we have. Compilers understand sysroots. Building a sysroot on demand with all the dependencies would let them find their dependencies in the store without having to know anything about Nix. Darwin has an advantage over Linux thanks to install names, but it might be possible to emulate something rpaths and a linker script. | 11:59:47 | |
| Ok, I've got an xcbuild update, but there seem to be unnecessarily many deps. I don't believe many of them actually use xcbuild. I'm just wondering if there's a better way to detect use than creating a fake xcbuild with all binaries screaming ERROR and exiting with 1, because that could actually pass by accident. I know I can adjust the sandbox in some package's build - there's no easy wait to enforce a custom sandbox for downstream packages, right? | 13:12:53 | |
feels like i landed at a reasonable spot with https://github.com/NixOS/nixpkgs/pull/512100 so i opened it for review. i was able to remove the hackier patches for sqlcipher with flags found upstream/remove the hardcoded xcode path, as well as keep the original propagate-inputs.nix in the apple-sdk largely unchanged apart from a single ios-specific flag for tls. working on submitting a very small pr to gnulib to remove the patch for gnugrep. rerunning builds for darwin/ios platforms after rebasing on the latest staging, and also happy to wait for 'realLibiconv' to land so I can verify with that as well | 14:22:02 | |
| * feels like i landed at a reasonable spot with https://github.com/NixOS/nixpkgs/pull/512100 so i opened it for review. i was able to remove the hackier patches for sqlcipher with flags found upstream/remove the hardcoded xcode path, as well as keep the original after actually looking at gnulib, it seems can simplify the gnugrep package for iOS as well, since the libc/nlist headers weren't used and the stackvma stuff is actually available | 15:17:49 | |