Is the .deb still the right thing to base our derivation on? Or would the AppImage (see https://www.tel.red/linux.php) be a more suitable base?

Should not make a difference the new deb can be found https://www.tel.red/repos/ubuntu/pool/non-free/sky_2.1.7520-1ubuntu+zesty_amd64.deb as an example, if you are more comfortable with an appimage go ahead :)

Should not make a difference the new deb can be found https://www.tel.red/repos/ubuntu/pool/non-free/sky_2.1.7520-1ubuntu+zesty_amd64.deb as an example,

Finding a new deb wasn't an issue, as you can see from the WIP diff. But now we have to get it to work.

if you are more comfortable with an appimage go ahead :)

I'm equally uncomfortable with both, just wondering what's more suitable for NixPkgs. 🤷

The reason for the failure to run the binary is that it isn't wrapped with wrapQtApp.

The reason for the failure to run the binary is that it isn't wrapped with wrapQtApp.

Thanks for the hint. If I understand the NixPkgs manual section on QT correctly, wrapQtApp (in combination with dontWrapQtApps = true; should be used when the implicit wrapping by nativeBuildInputs = [ wrapQtAppsHook ]; cannot be used, and wrapQtAppsHook should only be used when one cannot use the mkDerivation passed by libsForQt5.callPackage (instead of stdenv.mkDerivation). So in 2408d190eba26a193e465593544c213082c65b7a I tried to use mkDerivation instead of stdenv.mkDerivation and to call the package with libsForQt5.callPackage instead of stdenv.mkDerivation. For that, I had to adapt the names of the executable binaries that are being passed to patchelf.

It built and I can even start the application with sky ... but ... the application then seems to start itself in an endless loop spawning window after window, until I interrupt it by closing the then-latest window. I guess something is being patched doubly now from libsForQt5.callPackage combined with the remnants of what was necessary when libsForQt5.callPackage wasn't used. Though, I'm not sure what to remove to fix that.

If I leave out the --set-rpath $out/lib:${stdenv.cc.cc.lib}/lib${stdenv.lib.optionalString stdenv.is64bit "64"}:${stdenv.lib.makeLibraryPath buildInputs} for $out/bin/.sky-wrapped and $out/bin/.sky_sender-wrapped, I get the error message

/nix/store/jvnbx8yv5palzapcdj7nk3kshlbikq6w-sky-2.1.7520.1/bin/sky: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory

If I leave out the --set-interpreter $(cat $NIX_CC/nix-support/dynamic-linker) parts, I get

/nix/store/0ldw6dckchwfjfjpl5mawvv5k59ykqnr-sky-2.1.7520.1/bin/sky: line 10: /nix/store/0ldw6dckchwfjfjpl5mawvv5k59ykqnr-sky-2.1.7520.1/bin/.sky-wrapped: No such file or directory

/nix/store/0ldw6dckchwfjfjpl5mawvv5k59ykqnr-sky-2.1.7520.1/bin/.sky-wrapped is present and file reports it's an ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=50246c3925f3fdcc0bc2cd87be3c7aae2acaedac, for GNU/Linux 3.2.0, stripped, so I guess something it tries to open that's missing? (The "interpreter" /lib64/ld-linux-x86-64.so.2, probably? That does indeed not exist. Though if that's what's missing, why isn't it named in the error message?)

@peterhoeg Please advise. 🙈

Couple of things:

1. forget about the manual patching using patchelf, just use autoPatchelfHook
2. qt5.mkDerivation is for building from source, so use qt.wrapQtAppsHook instead (you don't have to manually patch the files if they are in the right place)
3. see if you can get rid of the vendored libraries if the ones we carry in nixpkgs work in their stead

On a separate note - I have customers who insist on using sfb/teams - I just run it in chrome, which is an awful lot better than spending time getting non-built-from-source stuff working on nixpkgs.

On a separate note - I have customers who insist on using sfb/teams - I just run it in chrome, which is an awful lot better than spending time getting non-built-from-source stuff working on nixpkgs.

MS Teams indeed works fine in Chrome and Chromium (though for Video Meetings not in Firefox).

For Skype-for-Business / Lync, I could use the web version only for text chat - it wouldn't let me use audio nor video without installing some native stuff. Even though MS backs both, I don't assume I can use MS Teams to access a Skype-for-Business / Lync meeting, can I? I guess I better ask the other meeting participants whether we can use Jitsi or something next time.

Couple of things:

1. forget about the manual patching using patchelf, just use autoPatchelfHook

2. qt5.mkDerivation is for building from source, so use qt.wrapQtAppsHook instead (you don't have to manually patch the files if they are in the right place)

Should both be combined? Tried that with d7daf13 and it also results in the application re-spawning itself infinitely. 🤔

Leaving autoPatchelfHook out leads to

/nix/store/nvsv2p358lqvyi3jx6bmgix9yhp752i8-sky-2.1.7520.1/bin/sky: line 10: /nix/store/nvsv2p358lqvyi3jx6bmgix9yhp752i8-sky-2.1.7520.1/bin/.sky-wrapped: No such file or directory

Leaving qt5.wrapQtAppsHook out leads to

sky: /nix/store/8zxiz4i59h1c7qfk5zg23x1bfzzyykiq-curl-7.68.0/lib/libcurl.so.4: no version information available (required by /nix/store/368g2wlj6s63yixblks7ivx2g9nbk8sv-sky-2.1.7520.1/bin/lib64/libsipw.so.1)
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Aborted (Speicherabzug geschrieben)

3. see if you can get rid of the vendored libraries if the ones we carry in nixpkgs work in their stead

Did that (I hope) in 22beae3 and it doesn't seem to negatively affect anything. 🎉

I marked this as stale due to inactivity. → More info

sky (Skype for Business client) has by now be removed through #98125.

Closing therefore.