| 24 Apr 2026 |
insipx | * 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.
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 |
insipx | * 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.
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 |
insipx | * 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 |
| Sandro left the room. | 18:08:54 |
| 25 Apr 2026 |
xored | how do i patch this perl snippet to behave on nix?
my $script_path =
File::Spec->catfile($FindBin::Bin, '..', 'lib', 'media-control',
'mediaremote-adapter.pl');
my $framework_path = File::Spec->rel2abs(
File::Spec->catdir(
$FindBin::Bin, '..', 'Frameworks', 'MediaRemoteAdapter.framework'
)
);
my $test_client_path = File::Spec->rel2abs(
File::Spec->catdir(
$FindBin::Bin, '..', 'lib', 'media-control', 'MediaRemoteAdapterTestClient'
)
);
| 09:26:54 |
xored | it works if i nix run it, but not when installed | 09:27:32 |
kirillrdy | hi, can someone have a look at ffmpeg-headless sign issue on darwin https://github.com/NixOS/nixpkgs/pull/513225 | 10:09:47 |
toonn | Does restarting the build not fix it? I think the transient code signing failure still happens. | 10:21:26 |
kirillrdy | toonn: which thread are you replying to ? | 10:22:14 |
toonn | Your question about ffmpeg-headless. | 10:23:34 |
kirillrdy | thanks, i am new to this issue, so that means there is a known transient build issue, and it was cached ? | 10:25:16 |
kirillrdy | eg maybe a better fix is not my PR but re trigger build ? | 10:26:02 |
Randy Eckenrode | One of the dylibs has a bad signature. | 10:32:10 |
Randy Eckenrode | 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 |
Randy Eckenrode | * | 10:33:56 |
kirillrdy | how come ffmpeg full doenst have this issue but headless does ? | 10:35:05 |
K900 | Random coincidence | 10:38:28 |
kirillrdy | fair enough... | 10:39:50 |
Randy Eckenrode | 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 |
kirillrdy | as for fixing issue on master, what is the best approach ? | 10:50:52 |
Randy Eckenrode | I’m not sure. How far off is the staging-next merge? | 10:51:41 |
kirillrdy | this is the consequences of recent staging-next merge | 10:52:17 |
Randy Eckenrode | Oh. ☹️ | 10:52:45 |
Randy Eckenrode | 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 |
toonn | Do the linkers use different code to perform signing? | 11:21:17 |
Randy Eckenrode | We don’t have the source to ld-prime. My hypothesis is that the signing calculation is shared between them. | 11:31:07 |
emily | this seems hard to reconcile with the state dependence observed by zhaofengli | 11:33:14 |
emily | though really every data point is hard to reconcile :( | 11:33:33 |
Randy Eckenrode | Race condition? | 11:34:02 |
emily | it was "succeeds once on a machine and fails thereafter" IIRC | 11:35:48 |