Nix on macOS | 1190 Members | |
| “There are still many issues with the Darwin platform but most of it is quite usable.” — http://yves.gnu-darwin.org | 195 Servers |
| Sender | Message | Time |
|---|---|---|
| 24 Apr 2026 | ||
| 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 | |
| * 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 on ios | 15:17: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 edit: 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 on ios | 15:18:04 | |
* 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. | 15:19:06 | |
| 18:08:54 | ||
| 25 Apr 2026 | ||
| how do i patch this perl snippet to behave on nix?
| 09:26:54 | |
it works if i nix run it, but not when installed | 09:27:32 | |
| hi, can someone have a look at ffmpeg-headless sign issue on darwin https://github.com/NixOS/nixpkgs/pull/513225 | 10:09:47 | |
| Does restarting the build not fix it? I think the transient code signing failure still happens. | 10:21:26 | |
| toonn: which thread are you replying to ? | 10:22:14 | |
| Your question about ffmpeg-headless. | 10:23:34 | |
| thanks, i am new to this issue, so that means there is a known transient build issue, and it was cached ? | 10:25:16 | |
| eg maybe a better fix is not my PR but re trigger build ? | 10:26:02 | |
| One of the dylibs has a bad signature. | 10:32:10 | |
| Darwin needs a hook to fail the build if there are any bad signatures. It won’t fix the underlying problem, but it will at least (hopefully) prevent another mess like this. | 10:33:41 | |
| * | 10:33:56 | |
| how come ffmpeg full doenst have this issue but headless does ? | 10:35:05 | |
| Random coincidence | 10:38:28 | |
| fair enough... | 10:39:50 | |
| Unfortunately, I ran into it when bringing my system back up, so I don’t have my shell history anymore where I fixed it locally. | 10:45:07 | |
| as for fixing issue on master, what is the best approach ? | 10:50:52 | |
| I’m not sure. How far off is the staging-next merge? | 10:51:41 | |
| this is the consequences of recent staging-next merge | 10:52:17 | |
| Oh. ☹️ | 10:52:45 | |
| I wonder if the problem is the way it’s calculating the signature, and it’s a happy accident that both ld64 and ld-prime are effected. | 11:11:02 | |
| Do the linkers use different code to perform signing? | 11:21:17 | |
| We don’t have the source to ld-prime. My hypothesis is that the signing calculation is shared between them. | 11:31:07 | |
| this seems hard to reconcile with the state dependence observed by zhaofengli | 11:33:14 | |