Tracking issue for wrapQtAppsHook

[ttuegel]

This issue is to track the open pull requests for Qt applications broken by the addition of wrapQtAppsHook.

Maintainers, please refer to the manual for instructions to update your packages. Packages that conformed to the prior version of the manual should not need to be updated.

Pull requests

• pulseview,pavucontrol-qt: use qt5.mkDerivation #65366
• qt5.wrapQtAppsHook: wrap more than just ELF's #65372

[bjornfor]

@ttuegel: Can you please clarify this. In the manual you linked to the example expression starts with

{ mkDerivation, lib, qtbase }:

and the text says

Import mkDerivation and Qt (such as qtbase modules directly. Do not import Qt package sets; [...].

This confuse me, since in this comment you seem to say the correct fix is to use qt5.mkDerivation (which AFAICT uses the qt5 package set). So, is using { fetchurl, qt5 }: qt5.mkDerivation { ... } ok?

Packages that conformed to the prior version of the manual should not need to be updated.

This also confuse me:

• Where is the prior version of the manual?
• If the manual changed (new recommended way to write expressions for Qt apps), why shouldn't every expression be updated to follow the latest guideline?

[ttuegel]

So, is using { fetchurl, qt5 }: qt5.mkDerivation { ... } ok?

I'm sorry for being unclear. What I mean is, you should write

{ mkDerivation }: mkDerivation { ... }

and call the package with qt5.callPackage or libsForQt5.callPackage.

If the manual changed (new recommended way to write expressions for Qt apps), why shouldn't every expression be updated to follow the latest guideline?

The prior version of the manual is still on the NixOS website. The recommended way to write expressions for Qt applications has not changed. I updated the manual to include information about wrapQtAppsHook because that is new. Using stdenv.mkDerivation with Qt applications has always been unsupported. Expressions that already conformed to the manual do not need to be updated. Expressions that did unsupported things before are probably broken now.

[Thra11]

I think the lxqt desktop may have been broken. lxqt-session complains that it can't find the "xcb" plugin in "", which probably means its platform plugin path is wrong or not set.

My NixOS xserver config in case it's relevant:

services.xserver = {
      enable = true;
      videoDrivers = [ "vesa" "modesetting" ];
      displayManager.sddm.enable = true;
      desktopManager.lxqt.enable = true;
};

[worldofpeace]

@Thra11 It appears that all of the expressions for lxqt use stdenv.mkDerivation instead of mkDerivaiton.

Edit: PR incoming to fix this.

[samueldr]

Hmmm, I'm hitting some weirdness on master right now, from a nixos-19.03 system.

Tell me if it's not related.

~/tmp/nixpkgs/nixpkgs $ git checkout master
Already on 'master'
Your branch is up to date with 'origin/master'.

~/tmp/nixpkgs/nixpkgs $ git rev-parse HEAD
a7d6390804c1f18737f71be62a02799f1b23e9a6

~/tmp/nixpkgs/nixpkgs $ nix-build -A cool-retro-term
/nix/store/3laxbqbiwclcvf6iir0rw9d391yjyd6a-cool-retro-term-1.1.1

~/tmp/nixpkgs/nixpkgs $ result/bin/cool-retro-term
Cannot mix incompatible Qt library (version 0x50c00) with this library (version 0x50c03)
Aborted

~/tmp/nixpkgs/nixpkgs 134 $ env -i DISPLAY="$DISPLAY" XAUTHORITY="$XAUTHORITY" result/bi
n/cool-retro-term
[... basically it works ...]

The fact that it works with env -i makes me think there may be contamination from my env.

What's peculiar is that from not too far back, it worked, so I'm bisecting.

eb4e067686d1121d2d4a3d7ac2ed080339125eeb # bad
70eae830431368d04abc387069a30450220e9247 # good

The bad commit being the merge of the good to master.

(Though I cannot test using cool-retro-term for bisecting.)

---

EDIT: it started after #64598. (The first commit itself won't build, but the second commit will. The parent commit is fine.)

This regression seems to coincide with, if not come from, the upgrade to 5.12.3.

[ttuegel]

It seems like there is some part of Qt 5.12.0 (0x50c00) is sticking around after the upgrade to Qt 5.12.3 (0x50c03), but I'm at a complete loss as to what. I do not think this is related to wrapQtAppsHook, at least not directly.

[samueldr]

The reason I think it may be related, is that when clearing the environment with env -i it ends up working. It may be that something needs to be added to the wrapper that wasn't already.

---

Digging more, now that I have slept, I think I traced the issue.

16510 openat(AT_FDCWD, "/nix/store/9q4gqkxpzfy0sl37wsnqw4mycyv53pi5-qtbase-5.12.0-bin/lib/qt-5.12/plugins/platforminputcontexts/libibusplatforminputcontextplugin.so", O_RDONLY|O_CLOEXEC) = 7
16510 read(7, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\216\0\0\0\0\0\0"..., 832) = 832

libibusplatforminputcontextplugin

unset QT_IM_MODULE and it crashes later. So, there is at least an input method impurity...

(Following up in another comment for the other impurity.)

[samueldr]

(Ensure you're not on a fresh master as the upgrade has been reverted.)

Without the input method impurity, I have multimc, and cool-retro-term somehow loading from the system path.

1603 16752 readlink("/nix/store/2d365d3hrp4h9ybpr60dxv74hbwyb0df-system-path/lib/qt-5.12/plugins/platforms", "/nix/store/9q4gqkxpzfy0sl37wsnqw"..., 4095) = 91
1606 16752 lstat("/nix/store/9q4gqkxpzfy0sl37wsnqw4mycyv53pi5-qtbase-5.12.0-bin", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
[...]
8149 17520 openat(AT_FDCWD, "/nix/store/9q4gqkxpzfy0sl37wsnqw4mycyv53pi5-qtbase-5.12.0-bin/lib/qt-5.12/plugins/bearer/libqconnmanbearer.so", O_RDONLY|O_CLOEXEC <unfinished ...>

 1307 18954 readlink("/nix/store/2d365d3hrp4h9ybpr60dxv74hbwyb0df-system-path/lib/qt-5.12/plugins/platforms", "/nix/store/9q4gqkxpzfy0sl37wsnqw"..., 4095) = 91
1310 18954 lstat("/nix/store/9q4gqkxpzfy0sl37wsnqw4mycyv53pi5-qtbase-5.12.0-bin", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
[...]
14675 18954 openat(AT_FDCWD, "/nix/store/9q4gqkxpzfy0sl37wsnqw4mycyv53pi5-qtbase-5.12.0-bin/lib/qt-5.12/plugins/sqldrivers/libqsqlite.so", O_RDONLY|O_CLOEXEC) = 14

I have unset QT_PLUGIN_PATH and QTWEBKIT_PLUGIN_PATH, I have no other Q* environment variables; unsetting XDG_DATA_DIRS is not the solution either.

Though, unsetting PATH helps.

---

Quoting myself from #44047

What is going on currently is that for any Qt plugin, they will be loaded according to the environment, and according to some hard-coded paths relative to components of PATH. This will not work properly when the environment is cleared or manipulated. (With non-NixOS platforms, using nix-shell to start a Qt application when none have been installed using nix may cause such failure.)

The current wrapper does not handle adding components to PATH so they will be searched.

[ttuegel]

So, there is at least an input method impurity...

This is intentional: we don't want for users to rebuild the world to change input methods. 🙁

The current wrapper does not handle adding components to PATH so they will be searched.

Searching PATH components is another intentional impurity which predates the wrapQtAppsHook changes. However, this improves with the wrapper because fewer things need to have their plugins propagated into the system environment.

[samueldr]

This is intentional: we don't want for users to rebuild the world to change input methods. 🙁

I figured, sorry if it seemed to imply otherwise, I was just stating the fact. Though I think the impurity is not "the input method is giving a full path to use as a library", but instead that it has to be resolved with the libraries path the software is given to work with. Sorry if that sentence is hard to parse, I'm still testing one final thing related to this.

Searching PATH components is another intentional impurity which predates the wrapQtAppsHook changes. However, this improves with the wrapper because fewer things need to have their plugins propagated into the system environment.

Yeah, I understand, but in real world use, it is part of the main issue, having mismatched Qt versions in the (overall) environment will break Qt apps.

After my test is done building, I'll share a, hopefully, good fix for the problem.

[samueldr]

#65526 is likely to solve the mismatched minor versions for good.

[peterzky]

#65543 fix qt5ct

[teto]

I've tried 2 things to make the problem disappear with wireshark but I still have the issue
Cannot mix incompatible Qt library (version 0x50c00) with this library (version 0x50c03) when I run result/bin/wireshark.
see the last 2 commits at https://github.com/teto/nixpkgs/tree/nixos-unstable

I have 2 other questions:

• wireshark can build without qt (the console binary). What would be the most elegant way of achieving that
• Also I wonder if with the new infrastructure, the wireshark binary is supposed to work in a nix-shell, as it's not wrapped yet (just after running the buildPhase) ?

I believe fcitx might be the culprit; strace log https://transfer.sh/EsQHH/log , rebuilding...

[teto]

seems like it got fixed with my changes and that PR #65526

[stale]

Hello, I'm a bot and I thank you in the name of the community for opening this issue.

To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it.

If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them.

Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel.

[worldofpeace]

I believe this is like 99% no longer an issue.

[Xe]

I'm encountering this with plover on NixOS 20.09:

$ nix-env -iA nixos.plover.dev
installing 'python3.6-plover-4.0.0.dev8'
these paths will be fetched (26.60 MiB download, 149.08 MiB unpacked):
  /nix/store/1c86mzzxdn1gh3zsr8m48pf31vqwk92p-python3.6-PyQt5.sip-4.19.24
  /nix/store/1yzd3q817p1kznaxh5nqwgbqqk24pdhc-python3.6-dbus-python-1.2.16
  /nix/store/50bbqdln7l97b36awlw019r25bl3f8xw-python3.6-appdirs-1.4.4
  /nix/store/6j31qc3nv1znmp98bvbcrydy5bikrpwc-python3.6-pytz-2020.1
  /nix/store/9hw5qi4q2gsw7gjyb1z9mz0qa4szf20f-python3.6-six-1.15.0
  /nix/store/bb47dgrdx1qgyw5zjvlmy503g2yj6b0b-python3.6-pyserial-3.4
  /nix/store/bjncdzcpgvv52sbq0qr8c6aa3lk1basa-python3.6-xlib-0.25
  /nix/store/bl7cj3fxgr43qwy48w96xrbxrqgi89a3-python3.6-dbus-python-1.2.16-dev
  /nix/store/d3lxh9n89rsf28v5zyn8pbghbc0cwqmg-python3.6-PyQt5-5.15.1
  /nix/store/hss1wvb697a1wwnakbxsqm6q14wd2pb5-python3.6-plover-4.0.0.dev8
  /nix/store/im3nhrxmbmdszffm56p64d938hvhl7im-python3.6-wcwidth-0.2.5
  /nix/store/iswawhahkrdvwcwkr9qkkf36v7rxgfm4-python3.6-PyQt5-5.15.1-dev
  /nix/store/l0pzd5jxgg6hj23si7kf3cp9cpkj3r96-python3-3.6.12
  /nix/store/whxcnpcdi8rvwgx1cg794ximylvf38rr-python3.6-setuptools-47.3.1
  /nix/store/x6fxich0cyszdiq34zh7jwl2470xk57k-python3.6-Babel-2.7.0
copying path '/nix/store/l0pzd5jxgg6hj23si7kf3cp9cpkj3r96-python3-3.6.12' from 'https://cache.nixos.org'...
copying path '/nix/store/1yzd3q817p1kznaxh5nqwgbqqk24pdhc-python3.6-dbus-python-1.2.16' from 'https://cache.nixos.org'...
copying path '/nix/store/50bbqdln7l97b36awlw019r25bl3f8xw-python3.6-appdirs-1.4.4' from 'https://cache.nixos.org'...
copying path '/nix/store/bb47dgrdx1qgyw5zjvlmy503g2yj6b0b-python3.6-pyserial-3.4' from 'https://cache.nixos.org'...
copying path '/nix/store/whxcnpcdi8rvwgx1cg794ximylvf38rr-python3.6-setuptools-47.3.1' from 'https://cache.nixos.org'...
copying path '/nix/store/6j31qc3nv1znmp98bvbcrydy5bikrpwc-python3.6-pytz-2020.1' from 'https://cache.nixos.org'...
copying path '/nix/store/9hw5qi4q2gsw7gjyb1z9mz0qa4szf20f-python3.6-six-1.15.0' from 'https://cache.nixos.org'...
copying path '/nix/store/bl7cj3fxgr43qwy48w96xrbxrqgi89a3-python3.6-dbus-python-1.2.16-dev' from 'https://cache.nixos.org'...
copying path '/nix/store/1c86mzzxdn1gh3zsr8m48pf31vqwk92p-python3.6-PyQt5.sip-4.19.24' from 'https://cache.nixos.org'...
copying path '/nix/store/bjncdzcpgvv52sbq0qr8c6aa3lk1basa-python3.6-xlib-0.25' from 'https://cache.nixos.org'...
copying path '/nix/store/x6fxich0cyszdiq34zh7jwl2470xk57k-python3.6-Babel-2.7.0' from 'https://cache.nixos.org'...
copying path '/nix/store/d3lxh9n89rsf28v5zyn8pbghbc0cwqmg-python3.6-PyQt5-5.15.1' from 'https://cache.nixos.org'...
copying path '/nix/store/im3nhrxmbmdszffm56p64d938hvhl7im-python3.6-wcwidth-0.2.5' from 'https://cache.nixos.org'...
copying path '/nix/store/iswawhahkrdvwcwkr9qkkf36v7rxgfm4-python3.6-PyQt5-5.15.1-dev' from 'https://cache.nixos.org'...
copying path '/nix/store/hss1wvb697a1wwnakbxsqm6q14wd2pb5-python3.6-plover-4.0.0.dev8' from 'https://cache.nixos.org'...
building '/nix/store/lyy5m5m81iygkxcmh9vgb74sk8ai2jkf-user-environment.drv'...
created 2252 symlinks in user environment

$ plover
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.

fish: “plover” terminated by signal SIGABRT (Abort)

[delroth]

@Xe already tracked in #98069, and I think it's more similar to #98067 than this particular issue.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/streamdeck-ui-on-unstable-getting-qt-error/27996/1

[zukigay]

this also seems to effect melonDS
I was wrong so sorry