SleepyHead: use qt5.makeDerivation and fix for Darwin

[fiksn]

Motivation for this change

I wasn't able to install sleepyhead on my machines.

On NixOS I got:
qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""

On Darwin I got:
qt.qpa.plugin: Could not find the Qt platform plugin "cocoa" in ""

Additionally package was marked as broken.

Read https://hydra.nixos.org/build/96804884/download/1/nixpkgs/manual.html#sec-language-qt and tinkered with the thing until it worked 😃

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[fiksn]

For reference I also tried with libsForQt5.callPackage and then wrapQtAppsHook as an input parameter (so it would work also in the sandbox case).

However I get:

dyld: Library not loaded: /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
  Referenced from: /nix/store/xkxq0dd7kfagz04gwbmvgjjbvf33bl4s-qtbase-5.12.7-dev/bin/qmake
  Reason: no suitable image found.  Did find:
        /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation: file system sandbox blocked stat()
        /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation: file system sandbox blocked stat()
./configure: line 26: 17806 Abort trap: 6           ${QMAKE} "${DIR}"

if anyone can shed some light I am more than happy to do it the "proper way".

[veprbl]

For reference I also tried with libsForQt5.callPackage and then wrapQtAppsHook as an input parameter (so it would work also in the sandbox case).

Those have nothing to do with sandboxing. As far as I understand, you should be able to switch to libsForQt5.callPackage without even a rebuild.

[fiksn]

Those have nothing to do with sandboxing. As far as I understand, you should be able to switch to libsForQt5.callPackage without even a rebuild.

Sandboxing was meant in the context that on Darwin I just use wrapQtApp without ever declaring where that comes from. If the build was done in a sandbox it would fail.

My understanding was that with
nativeBuildInputs = [ wrapQtAppsHook ];

this would become a proper build input but of course I might be totally wrong here. BTW, found a similar issue just regarding Emacs (#47413). I have the store on MacOS on a dedicated volume called /nix - if that causes the problems. That is some security sandbox, but I don't understand yet how to solve this (using my method the built application works perfectly).

[fiksn]

Ah silly me. It was caused since I experimented with sandbox = true in /etc/nix/nix.conf

[veprbl]

Sandboxing was meant in the context that on Darwin I just use wrapQtApp without ever declaring where that comes from. If the build was done in a sandbox it would fail.

The call to "wrapQtApp" from a shell script is resolved using the "PATH" environment variable, which is initialized by the stdenv and should not contain any impure paths unless it's somehow modified.

My understanding was that with
nativeBuildInputs = [ wrapQtAppsHook ];

this would become a proper build input but of course I might be totally wrong here.

If I'm not mistaken, mkDerivation provided by the libsForQt5.callPackage may implicitly include wrapQtAppsHook to nativeBuildInputs for you.

BTW, found a similar issue just regarding Emacs (#47413). I have the store on MacOS on a dedicated volume called /nix - if that causes the problems. That is some security sandbox, but I don't understand yet how to solve this (using my method the built application works perfectly).

Sandboxing on darwin is currently not properly supported by nixpkgs for the impure Apple frameworks (#67166 mentions a workaround).

[veprbl]

@GrahamcOfBorg build sleepyhead

[veprbl]

Works on x86_64-linux (NixOS)