Macos: nixpkgs-24.11 qtdeclarative-6.8.3 result in `/bin/sh: codesign: command not found`

Help
1

Hi everyone. I’m trying to update a flake to the latest of nixos-24.11. Previously the branch was using qt 6.8.2 and everything was pulled from the nix binary cache.

I’m trying to update the inputs to the flake, and it somehow recompile qt from source (ok why not this is what nix is for) but it fails with missing codesign executable.

I can reproduce that on my machine, and in a github runner macos environment (arm). On my system codesign is available at /usr/bin/codesign but I guess this accessible by the nix builder.

Here is the log.

builder for '/nix/store/6jy3h8ybv89p52w09hckql8rd7c4110l-qtdeclarative-6.8.3.drv' failed with exit code 1;
       last 25 log lines:
       > [3516/3536] Linking CXX shared module lib/qt-6/plugins/qmltooling/libqmldbg_preview.dylib
       > [3517/3536] Linking CXX shared module lib/qt-6/plugins/qmllint/libquicklintplugin.dylib
       > [3518/3536] Linking CXX static library lib/qt-6/qml/Assets/Downloader/libqmlassetdownloaderplugin.a
       > [3519/3536] Linking CXX shared module lib/qt-6/plugins/qmlls/libqmllsquickplugin.dylib
       > [3520/3536] Linking CXX shared module lib/qt-6/qml/QtQuick/tooling/libquicktoolingplugin.dylib
       > [3521/3536] Linking CXX executable bin/qmldom
       > [3522/3536] Linking CXX executable bin/qmllint
       > [3523/3536] Linking CXX executable bin/qmltc
       > [3524/3536] Linking CXX executable libexec/qmljsrootgen
       > [3525/3536] Linking CXX executable libexec/qmlimportscanner
       > [3526/3536] Linking CXX executable bin/qmlformat
       > [3527/3536] Linking CXX executable bin/qmlls
       > [3528/3536] Linking CXX executable bin/qmlprofiler
       > [3529/3536] Linking CXX executable bin/qmlpreview
       > [3530/3536] Building CXX object src/assets/downloader/CMakeFiles/QmlAssetDownloaderplugin_init.dir/QmlAssetDownloaderplugin_init.cpp.o
       > [3531/3536] Linking CXX executable bin/qml
       > [3532/3536] Linking CXX executable bin/qmlscene
       > [3533/3536] Linking CXX executable bin/qmltime
       > [3534/3536] Linking CXX executable bin/qmlplugindump
       > [3535/3536] Linking CXX executable bin/qmltestrunner
       > FAILED: bin/qmltestrunner
       > : && /nix/store/i23fimy9l2ffc4l91rlclg82gc0s4xzi-clang-wrapper-16.0.6/bin/clang++ -DNDEBUG -O2 -isysroot /nix/store/5ms26hmyppkpx1v26xxrxzivrp770qc8-apple-sdk-15.2/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names -fPIE -Xlinker -pie tools/qmltestrunner/CMakeFiles/qmltestrunner.dir/qmltestrunner_autogen/mocs_compilation.cpp.o tools/qmltestrunner/CMakeFiles/qmltestrunner.dir/main.cpp.o -o bin/qmltestrunner -F/nix/store/g8fwqsmq98vhk3bib13bqc25czybzff8-qtdeclarative-6.8.3/.build/qtdeclarative-everywhere-src-6.8.3/build/lib -F/nix/store/jc5zcjz74nc6rpqbr6hn7v7rrd8pcidh-qtbase-6.8.3/lib -Wl,-rpath,/nix/store/g8fwqsmq98vhk3bib13bqc25czybzff8-qtdeclarative-6.8.3/.build/qtdeclarative-everywhere-src-6.8.3/build/lib  lib/QtQuickTest.framework/Versions/A/QtQuickTest  /nix/store/jc5zcjz74nc6rpqbr6hn7v7rrd8pcidh-qtbase-6.8.3/lib/QtTest.framework/Versions/A/QtTest  -framework Security  -framework ApplicationServices  -framework Foundation  lib/QtQuick.framework/Versions/A/QtQuick  lib/QtQmlMeta.framework/Versions/A/QtQmlMeta  lib/QtQmlWorkerScript.framework/Versions/A/QtQmlWorkerScript  lib/QtQmlModels.framework/Versions/A/QtQmlModels  lib/QtQml.framework/Versions/A/QtQml  /nix/store/jc5zcjz74nc6rpqbr6hn7v7rrd8pcidh-qtbase-6.8.3/lib/QtNetwork.framework/Versions/A/QtNetwork  /nix/store/jc5zcjz74nc6rpqbr6hn7v7rrd8pcidh-qtbase-6.8.3/lib/QtOpenGL.framework/Versions/A/QtOpenGL  /nix/store/jc5zcjz74nc6rpqbr6hn7v7rrd8pcidh-qtbase-6.8.3/lib/QtGui.framework/Versions/A/QtGui  -framework AGL  -framework AppKit  -framework OpenGL  -framework ImageIO  -framework Metal  /nix/store/jc5zcjz74nc6rpqbr6hn7v7rrd8pcidh-qtbase-6.8.3/lib/QtDBus.framework/Versions/A/QtDBus  /nix/store/jc5zcjz74nc6rpqbr6hn7v7rrd8pcidh-qtbase-6.8.3/lib/QtCore.framework/Versions/A/QtCore  -framework IOKit  -framework DiskArbitration  -framework UniformTypeIdentifiers && cd /nix/store/g8fwqsmq98vhk3bib13bqc25czybzff8-qtdeclarative-6.8.3/.build/qtdeclarative-everywhere-src-6.8.3/build/tools/qmltestrunner && codesign --sign - --entitlements /nix/store/jc5zcjz74nc6rpqbr6hn7v7rrd8pcidh-qtbase-6.8.3/lib/cmake/Qt6/macos/test.entitlements.plist /nix/store/g8fwqsmq98vhk3bib13bqc25czybzff8-qtdeclarative-6.8.3/.build/qtdeclarative-everywhere-src-6.8.3/build/bin/qmltestrunner
       > /bin/sh: codesign: command not found
       > [3536/3536] Linking CXX executable bin/qmleasing

So my question is simple:

  • Is it some kind of bug in upstream nixpkgs?
  • Or is there an extra undocumented step to codesign things that you are building by yourself on your machine for nix on macos that I’m not aware? I’m using nix 2.24.12
2

Prefer nixpkgs-24.11-darwin for macOS. There have been some Darwin‐specific issues that are getting fixed, but nixos-* channels don’t block on Darwin builds.

3

Thank you for you answer!
So it means there is an issue on nixpkgs-24.11 regarding the qt build right? It’s not me that have an environment not setup correctly for codesigning?

4

Yeah, we just forgot to backport a fix patch. It’s in there now and Hydra is churning through builds, but since it doesn’t affect Linux it didn’t stop the nixos-* channel bumping. Usually we’d catch that stuff on staging-24.11-next, but it’s been a weird cycle because of rushing a Perl security fix directly to release branches.

If you use nixpkgs-unstable or nixpkgs-*-darwin things should be more reliable. But nixos-* usually works on Darwin at a pinch too, since they tend to stay pretty close – you can see from the channel status page that things have been a bit unfortunate lately.

5

Ok I see, Is there any PR I can follow the process? I’m curious to see what kind of fix it is

6

Original PR: qt6.qtdeclarative: fix code-signing on Darwin by reckenrode · Pull Request #398849 · NixOS/nixpkgs · GitHub

Backport: [Backport release-24.11] qt6.qtdeclarative: fix code-signing on Darwin by vcunat · Pull Request #401989 · NixOS/nixpkgs · GitHub

Though it seems like it might still be flaky. (But it went through on unstable, at least, so fingers crossed we’ll get a Darwin 24.11 channel bump soon.)

7

Ok thanks. I still don’t get the error I got about codesign not found, because I see the patch is about force signing something already signed. Which is different from my error. I see /bin/sh: codesign: command not found in the logs.

To me this mean the builder didn’t use /usr/bin/codesign. I know this installed on my mac, I guess it come with the operating system.

Is there a way for nix builder to access this codesign?

I’m asking because right now I’m running codesign for my app in an impure shell, and would love to understand how. Digging deeper I found:

Also I see many reference to GitHub - thefloweringash/sigtool around
nixpkgs.

So is it the answer I’m looking for that I need to disable sandbox on MacOS?

8

Following the PR discussion, everything makes now sense:

So adding darwin.sigtool was indeed the key for the builder to access codesign.

Coming back to my original questions:

  • Is it some kind of bug in upstream nixpkgs: Yes since Qt6.9 codesign was required in the build but missing.
  • Or is there an extra undocumented step to codesign: I haven’t tried that on my system but maybe sandboxing should be disabled?
9

No, in this case the sandbox saved you from being able to build a package nobody else could without having to magic up the exact same software as you. Nix is supposed to prevent this, it’s kind of the entire point of reproducible software builds. It means that if you see something break, everyone else should be able to see the same failure and help you fix it. Removing the sandbox would make this much harder, because then things could randomly access host dependencies, which can have all kinds of effectively unpredictable effects on your build outputs.

This was just a bug in nixpkgs, the correct fix is in that PR.

Incidentally, if you see a build you’re not expecting, this most likely means something along these lines happened. There was some kind of build failure upstream, either because someone made a mistake while packaging something, or because of gremlins causing a spurious failure - yeah, those can still happen, not all packages are perfectly reproducible, and even if they were build servers can still have the occasional hiccup.