@abbradar, thanks for your PR! By analyzing the history of the files in this pull request, we identified @peterhoeg, @ttuegel and @dezgeg to be potential reviewers.

It looks like the search path for plugins is empty. Could you post the contents of the wrapper?

@ttuegel

#! /nix/store/2nflzcrfs8xlnghx4v6gb9wk31rwh9r6-bash-4.4-p5/bin/bash -e
export PATH=$PATH${PATH:+:}/nix/store/8inkcdibcx98s5fa3qkpby4h6q1kn7kl-okular-16.12.3/bin
export XDG_CONFIG_DIRS=/nix/store/8inkcdibcx98s5fa3qkpby4h6q1kn7kl-okular-16.12.3/etc/xdg${XDG_CONFIG_DIRS:+:}$XDG_CONFIG_DIRS
export XDG_DATA_DIRS=/nix/store/8inkcdibcx98s5fa3qkpby4h6q1kn7kl-okular-16.12.3/share:/nix/store/qhc2mc8kgrjg1lgjqryz0bgkw1jcd1lj-gtk+3-3.22.8/share/gsettings-schemas/gtk+3-3.22.8${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS
export QML_IMPORT_PATH="/nix/store/8inkcdibcx98s5fa3qkpby4h6q1kn7kl-okular-16.12.3/lib/qt5/imports"
export QML2_IMPORT_PATH="/nix/store/8inkcdibcx98s5fa3qkpby4h6q1kn7kl-okular-16.12.3/lib/qt5/qml"
export QT_PLUGIN_PATH="/nix/store/8inkcdibcx98s5fa3qkpby4h6q1kn7kl-okular-16.12.3/lib/qt5/plugins"
export GIO_EXTRA_MODULES=/nix/store/g37zbc9sd140amn82aifn1b27m9n9hmp-dconf-0.26.0-lib/lib/gio/modules${GIO_EXTRA_MODULES:+:}$GIO_EXTRA_MODULES
exec -a ""$0"" "/nix/store/7b9r0nq7rg2anp7g89wz8dnpkgfh7nya-okular-16.12.3/bin/okular"  "${extraFlagsArray[@]}" "$@"

Notice that okular is not wrapped by makeQtWrapper, rather by kdeWrapper which has different code (I wanted to unify them but let's skip this for minimal patch).

Notice that okular is not wrapped by makeQtWrapper, rather by kdeWrapper which has different code (I wanted to unify them but let's skip this for minimal patch).

Agreed. I am trying to remove makeQtWrapper so we should revisit that issue later.

That wrapper, though. That is all kinds of messed up. ☹️

1. The Qt paths are not set correctly.
2. $0 is not quoted correctly.
3. extraFlagsArray is not initialized.

Something is seriously wrong with kdeWrapper. That's a separate issue; I think we need to put off fixing that for the moment.

I think there's more to it:

This application failed to start because it could not find or load the Qt platform plugin "xcb"
in "".

Available platform plugins are: minimal, offscreen, xcb, vnc.

Reinstalling the application may fix this problem.
[1]    29183 abort      result/bin/antimicro

That's some random Qt 5 application on master. It was unwrapped but when I wrapped it nothing has changed. Any idea what's going on (this is without the patch)?

That's some random Qt 5 application on master. It was unwrapped but when I wrapped it nothing has changed. Any idea what's going on (this is without the patch)?

Yeah, actually I know exactly what's going on.

kdeWrapper uses the following to build the environment:

  env = buildEnv {
    inherit name meta;
    paths = builtins.map lib.getBin (unwrapped ++ paths);
    pathsToLink = [ "/bin" "/share" "/lib/qt5" "/etc/xdg" ];
  };

The old kdeWrapper would set up propagatedUserEnvPkgs automatically. Now it uses buildEnv, which doesn't do that, so we need to go back and set up propagatedUserEnvPkgs manually for every KDE package.

@ttuegel Strange thing is -- it's not a kdeWrappered application, it's rather a plain Qt 5 one (antimicro, just a random one that I stumbled upon). makeQtWrapper doesn't help either, and strace shows this:

stat("/nix/store/zsz96vx1q78xispygdzj823lm9yni7gv-qtbase-5.7.1/lib/qt5/plugins/platforms/libqxcb.so", {st_mode=S_IFREG|0555, st_size=14696, ...}) = 0
open("/nix/store/izxnyg94352qxa4a4783dzgnpy5cwazj-glibc-2.25/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=2997, ...}) = 0
read(3, "# Locale name alias data base.\n#"..., 4096) = 2997
read(3, "", 4096)                       = 0
close(3)                                = 0
open("/nix/store/izxnyg94352qxa4a4783dzgnpy5cwazj-glibc-2.25/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/nix/store/izxnyg94352qxa4a4783dzgnpy5cwazj-glibc-2.25/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/nix/store/izxnyg94352qxa4a4783dzgnpy5cwazj-glibc-2.25/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/nix/store/izxnyg94352qxa4a4783dzgnpy5cwazj-glibc-2.25/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/nix/store/izxnyg94352qxa4a4783dzgnpy5cwazj-glibc-2.25/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/nix/store/izxnyg94352qxa4a4783dzgnpy5cwazj-glibc-2.25/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/dev/tty", O_RDONLY|O_CLOEXEC)    = 3
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
close(3)                                = 0
write(2, "This application failed to start"..., 218This application failed to start because it could not find or load the Qt platform plugin "xcb"

EDIT: maybe it's just broken -- any idea of another plain Qt 5 application?

@abbradar As for antimicro, I can't get X to start in a VM on master, so I'm trying to reproduce this on unstable channel. But, everything works fine on unstable (for me). If you can't reproduce it on unstable either, it is probably related to the Qt 5.8 update.

The old kdeWrapper would set up propagatedUserEnvPkgs automatically. Now it uses buildEnv, which doesn't do that, so we need to go back and set up propagatedUserEnvPkgs manually for every KDE package.

Let me retract this statement: there is no problem here. We did have this bug at one time, but it was fixed in a non-obvious way by propagating everything to the environment.

@ttuegel I do this on unstable too and I can reproduce it perfectly. Anyway, I also can't start qutebrowser from master because of the same reason and other people on IRC can't reproduce that. So this is something with my system... Trying to investigate with strace.

Interesting... if I build the package with Qt 5.7 on master it works. There may be another source of impurity like what you fixed some time ago. I have /run/current-system/sw/lib/qt5 on my system; should it be there?

So, in the end it was qt5.env "qt-${qt5.qtbase.version}" (with qt5; [ qtdeclarative ]) in my environment.systemPackages causing problems. I installed it there so that qtcreator finds it.

I have /run/current-system/sw/lib/qt5 on my system; should it be there?

It may be there. What package does /run/current-system/sw/lib/qt5/plugins/platforms/libqxcb.so belong to?

With removed qt5.env I don't have this path anymore.

EDIT: looking at strace logs: 5.8.0 loaded a platform plugin from my system environment and predictably crashed then.

looking at strace logs: 5.8.0 loaded a platform plugin from my system environment and predictably crashed then.

Yeah, I had a feeling about something like that. The disclaimer that should come with Qt-based applications on NixOS is like the standard FCC disclaimer "this device may not produce harmful impurities, but it must accept any impurities." I should really find a way to block off the system profile entirely...

I've managed now to test those patches properly and fix several things. File dialogs now work for me, along with their settings.

Hope it's okay (my limited tests are fine and luckily this is no mass rebuild so it's a bit easier to fix if something is wrong after all).

I haven't cherry-picked dconf split to release to avoid any more breakage.

I actually cannot reproduce the okular bug on 17.03, are you sure that happens there, too? 🤔
(before your cherry-pick)

Hm, it should (because Qt 5.7 supports GTK3 and has it in buildInputs). Not sure why it doesn't, investigating (other fixes are relevant anyway).

Really not sure, it should matter -- maybe Qt 5.7 doesn't use file chooser dialogs from GTK so the problem doesn't trigger?

Still, there are other places where GTK uses dconf and it could manifest itself somewhere. so let's be on the safe side (this shouldn't break anything, only grow closure size :D).

Hm, it should (because Qt 5.7 supports GTK3 and has it in buildInputs).

Qt 5.6 should be the default Qt version on the release branch.