!lheuhImcToQZYTQTuI:nixos.org

Nix on macOS

1098 Members
“There are still many issues with the Darwin platform but most of it is quite usable.” — http://yves.gnu-darwin.org171 Servers

Load older messages


SenderMessageTime
12 Jul 2025
@reckenrode:matrix.orgRandy Eckenrode
In reply to @zhaofeng:zhaofeng.li
IIRC the "error" always occurs for ad-hoc signed executables that the system has not seen before
*
18:43:11
@reckenrode:matrix.orgRandy Eckenrode
In reply to @ihar.hrachyshka:matrix.org

ok added darwin.sigtool to native inputs but then

>   ⨯ Command failed: codesign --sign - --force --timestamp --options runtime --entitlements /private/tmp/nix-build-podman-desktop-1.20.0.drv-0/source/node_modules/app-builder-lib/templates/entitlements.mac.plist /private/tmp/nix-build-podman-desktop-1.20.0.drv-0/source/dist/mac-arm64/Podman Desktop.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Resources/af.lproj/locale.pak
       > The following arguments were not expected: --options --timestamp
       > Run with --help for more information.
       >   failedTask=build stackTrace=Error: Command failed: codesign --sign - --force --timestamp --options runtime --entitlements /private/tmp/nix-build-podman-desktop-1.20.0.drv-0/source/node_modules/app-builder-lib/templates/entitlements.mac.plist /private/tmp/nix-build-podman-desktop-1.20.0.drv-0/source/dist/mac-arm64/Podman Desktop.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Resources/af.lproj/locale.pak
       > The following arguments were not expected: --options --timestamp
sigtool is pretty primitive. You’ll probably have to rework it to use rcodesign.
18:44:39
@sarahec:matrix.orgSarah Clark Anyone up for a mystery? pytorchCheckHook segfaults for some tests on some packages on Apple silicon: https://github.com/NixOS/nixpkgs/issues/423831 20:09:09
@reckenrode:matrix.orgRandy EckenrodeIs there a native stack trace from the crash?20:24:50
@reckenrode:matrix.orgRandy EckenrodeI reflexively want to blame GNU binutils for being in the torch closure, but I don’t think that’s it.20:29:36
@reckenrode:matrix.orgRandy Eckenrode (Can we use stdenv.cc.bintools instead of hardcoding binutils?) 20:29:46
@reckenrode:matrix.orgRandy Eckenrode It just needs addr2line, which should be in it. 20:29:59
@reckenrode:matrix.orgRandy Eckenrode python3Packages.torch is going to be broken by the Darwin minimum version bump …. 20:31:47
@sarahec:matrix.orgSarah ClarkI will see if I can pull a native stack trace.20:41:45
@sarahec:matrix.orgSarah ClarkI'm bisecting around another broken package to see if it also converges on gpytorch20:42:05
@sarahec:matrix.orgSarah Clark* I'm currently bisecting around another broken package to see if it also converges on gpytorch20:42:27
@sarahec:matrix.orgSarah Clark Though, the common denominator is looking more like numpy 20:42:47
@sarahec:matrix.orgSarah ClarkAlso, Thank You20:44:54
@sarahec:matrix.orgSarah Clark

Here's the thread that crashed:

Thread 22 Crashed:
0   libomp.dylib                  	       0x125575360 __kmp_suspend_initialize_thread + 32
1   libomp.dylib                  	       0x125575e70 void __kmp_suspend_64<false, true>(int, kmp_flag_64<false, true>*) + 68
2   libomp.dylib                  	       0x14726f988 kmp_flag_64<false, true>::wait(kmp_info*, int, void*) + 1936

3 libomp.dylib 0x14726aa78 __kmp_hyper_barrier_release(barrier_type, kmp_info*, int, int, int, void*) + 168
4 libomp.dylib 0x14726e410 __kmp_fork_barrier(int, int) + 464
5 libomp.dylib 0x147245148 __kmp_launch_thread + 352
6 libomp.dylib 0x1472907f0 __kmp_launch_worker(void*) + 284
7 libsystem_pthread.dylib 0x18dff6c0c _pthread_start + 136
8 libsystem_pthread.dylib 0x18dff1b80 thread_start + 8

20:48:41
@reckenrode:matrix.orgRandy EckenrodeThanks. That’s a crash in OpenMP.20:52:59
@reckenrode:matrix.orgRandy Eckenrodehttps://github.com/pytorch/pytorch/issues/14920120:53:38
@sarahec:matrix.orgSarah Clark Of course, libomp 20:54:23
@sarahec:matrix.orgSarah ClarkD'oh20:54:26
@reckenrode:matrix.orgRandy Eckenrode I only see one llvmPackages.openmp in its closure. I don’t think it’s quite that upstream issue. 20:55:50
@reckenrode:matrix.orgRandy Eckenrode Sarah Clark: Regarding the crash on x86_64-darwin you mentioned in that issue. Is it running on native hardware or under Rosetta 2? 20:59:22
@reckenrode:matrix.orgRandy EckenrodeRosetta 2 has some limitations in its floating point support that I have caused problems for numeric Python stuff in the past.20:59:40
@sarahec:matrix.orgSarah ClarkI'ven had it happen on native hardware and on the build machines (Rosetta)21:00:07
@reckenrode:matrix.orgRandy EckenrodeIf it affects native hardware, it’s very unlikely to be a Rosetta 2 issue.21:00:24
@sarahec:matrix.orgSarah Clark* I've had it happen on native hardware and on the build machines (Rosetta)21:00:30
@sarahec:matrix.orgSarah ClarkWait (checks logs), no I didn't repro it on nnative HW21:00:46
@sarahec:matrix.orgSarah Clark* Wait (checks logs), no I didn't repro it on native HW21:00:54
@sarahec:matrix.orgSarah ClarkRosetta seems likely. 21:01:40
@sarahec:matrix.orgSarah ClarkHold on, yes it's happening on native aarch6421:02:30
@sarahec:matrix.orgSarah ClarkI had tested it on native x86 and it worked there too21:02:53
@sarahec:matrix.orgSarah Clark (nix-build -A python312Packages.gpytorch --check will show you the problem. In this case, it hangs forever. 21:03:41

Show newer messages


Back to Room ListRoom Version: 6