I've noticed with wrapGAppsHook that if there's binaries at sbin that they don't get wrapped.
I'm thinking this was because move-sbin fixupOutputHooks came after wrapGAppsHook so they don't get touched.

Mentioning because I'd think wrapQtAppsHook could inherit that issue.

What happens when a bin/ executable execs a libexec/ executable? Won't the environment grow?

What happens when a bin/ executable execs a libexec/ executable? Won't the environment grow?

Yes, environment variables are going to propagate to child processes and often they can be wrapped too.
So this leakage can be problematic, but it's a known drawback to this approach.

LGTM. This resolved the activitymanagerd failure I noted in #54525 (comment)

However, the plasma 5 test is still failing. A different failure. Does not appear to be a regression caused by this change. Log:

• https://gist.github.com/coreyoconnor/410e5291aebce30c611f68abcf448870

Not clear to me what failed this time.

LGTM. This resolved the activitymanagerd failure I noted in #54525 (comment)

However, the plasma 5 test is still failing. A different failure. Does not appear to be a regression caused by this change. Log:

* https://gist.github.com/coreyoconnor/410e5291aebce30c611f68abcf448870

Not clear to me what failed this time.

Can you run the test interactively and debug from there?

nix-build nixos/tests/plasma5.nix -A driver 

Running the test interactively everything works for me

What the issue here is that the wrappers fuzzed the argv0 so the test needs to be adapted
* https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/plasma5.nix#L53

I'll include a commit for that here.

Ok, after inspecting dolphin it's not being wrapped so it gets that error at runtime...
Pretty confused by that.

@ttuegel I was also looking at the wrapper make for okular and it has these entries

export XDG_DATA_DIRS='/nix/store/i5s8firmgld1wc8b9fsbq8kivwv51lw2-cmake-3.14.5/share'${XDG_DATA_DIRS:+':'}$XDG_DATA_DIRS
export XDG_DATA_DIRS='/nix/store/01a3dppfi3rv03m8yx2nwxbkklggyzf9-pkg-config-0.29.2/share'${XDG_DATA_DIRS:+':'}$XDG_DATA_DIRS

I'm almost certain those dependencies shouldn't be collected for the wrapper.

I've discovered that isQtApp wasn't returning a non-zero exit status for dolphin's binaries.
Decided to just remove it 4908d38

So the NixOS test now "passes", but I'm seeing errors in the output like

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-alice'

among others that somehow get drawn to the desktop after I run it interactively

Thanks! I can confirm the test passes. I haven't tried running the driver interactively. If I get a chance I'll try it and see.

@worldofpeace please remove the WIP label when it's not applicable.

@ttuegel Was isQtApp meant to prevent scripts from being wrapped?

I'm thinking that the new issues I'm seeing are because of that happening.
Though it's still possible that a script could need to be wrapped with $XDG* variables.

@worldofpeace isQtApp was intended to prevent wrapping scripts and non-GUI binaries that may not even depend on Qt. If it's causing problems, then remove it.

So with the latest commit, plasma5 test succeeds for me locally and interactively nothing seems wrong with the session.

I'm going to merge this to master so the channels can get unblocked.

7d6ab0a breaks Python scripts that use Qt5 because they don't get wrapped because of the isELF check.

I have patches in my nixpkgs that may impact this. Adding the issue I'm encountering here just in case it's actually related to this change. Plus, takes a while to build a variation. ;)

Some QT apps, for instance QGIS and OpenSCAD, encounter an infinite recursion that has a stack trace like so:

#0  0x000015554e001680 in QWindow::flags() const () from /nix/store/v4s0nq286hxwjms4k1sd378n597l3rka-qtbase-5.12.3/lib/libQt5Gui.so.5
#1  0x000015554e0016b9 in QWindow::type() const () from /nix/store/v4s0nq286hxwjms4k1sd378n597l3rka-qtbase-5.12.3/lib/libQt5Gui.so.5
#2  0x000015553e630c61 in ?? () from /nix/store/35855h0lfnpr21xbs48kd1ianwzzw0yv-qtbase-5.12.0-bin/lib/qt-5.12/plugins/xcbglintegrations/libqxcb-glx-integration.so
#3  0x000015554e001682 in QWindow::flags() const () from /nix/store/v4s0nq286hxwjms4k1sd378n597l3rka-qtbase-5.12.3/lib/libQt5Gui.so.5
#4  0x000015554e0016b9 in QWindow::type() const () from /nix/store/v4s0nq286hxwjms4k1sd378n597l3rka-qtbase-5.12.3/lib/libQt5Gui.so.5
#5  0x000015553e630c61 in ?? () from /nix/store/35855h0lfnpr21xbs48kd1ianwzzw0yv-qtbase-5.12.0-bin/lib/qt-5.12/plugins/xcbglintegrations/libqxcb-glx-integration.so
#6  0x000015554e001682 in QWindow::flags() const () from /nix/store/v4s0nq286hxwjms4k1sd378n597l3rka-qtbase-5.12.3/lib/libQt5Gui.so.5
#7  0x000015554e0016b9 in QWindow::type() const () from /nix/store/v4s0nq286hxwjms4k1sd378n597l3rka-qtbase-5.12.3/lib/libQt5Gui.so.5
#8  0x000015553e630c61 in ?? () from /nix/store/35855h0lfnpr21xbs48kd1ianwzzw0yv-qtbase-5.12.0-bin/lib/qt-5.12/plugins/xcbglintegrations/libqxcb-glx-integration.so

Note the libqxcb-glx-integration library.

(This is the issue I mentioned running qt apps in #63829 .)

I have patches in my nixpkgs that may impact this. Adding the issue I'm encountering here just in case it's actually related to this change. Plus, takes a while to build a variation. ;)

I've reverted to nixos-unstable plus a few necessary patches and am not able to reproduce the above issue. I'll be adding back in QT PRs to see if they repro the issue.