Nixpkgs: 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

• #65366
• #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. :slightly_frowning_face:

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. :slightly_frowning_face:

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 https://github.com/NixOS/nixpkgs/pull/65526

[tadfisher]

The logic in wrapQtAppsHook() seems iffy: the elif [ -h "$file" ] branch will never run for symlinks to files, because if [ -f "$file" ] returns success for these. A simple fix is to swap these branches so the -h test runs first.

[skallinen]

not sure if related, but qutebrowser stopped working a couple of days ago for me on unstable.
```08:45:38 WARNING: Could not find the Qt platform plugin "xcb" in ""
08:45:38 CRITICAL: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Fatal Python error: Aborted

Current thread 0x00007f1c78a9ab80 (most recent call first):
File "/nix/store/jmy3swaz7ma3f3w6vfjcjm914rdlkqwn-qutebrowser-1.6.3/lib/python3.7/site-packages/qutebrowser/misc/earlyinit.py", line 87 in _die
File "/nix/store/jmy3swaz7ma3f3w6vfjcjm914rdlkqwn-qutebrowser-1.6.3/lib/python3.7/site-packages/qutebrowser/misc/earlyinit.py", line 222 in _check_modules
File "/nix/store/jmy3swaz7ma3f3w6vfjcjm914rdlkqwn-qutebrowser-1.6.3/lib/python3.7/site-packages/qutebrowser/misc/earlyinit.py", line 238 in check_libraries
File "/nix/store/jmy3swaz7ma3f3w6vfjcjm914rdlkqwn-qutebrowser-1.6.3/lib/python3.7/site-packages/qutebrowser/misc/earlyinit.py", line 296 in early_init
File "/nix/store/jmy3swaz7ma3f3w6vfjcjm914rdlkqwn-qutebrowser-1.6.3/lib/python3.7/site-packages/qutebrowser/qutebrowser.py", line 190 in main
File "/nix/store/jmy3swaz7ma3f3w6vfjcjm914rdlkqwn-qutebrowser-1.6.3/bin/..qutebrowser-wrapped-wrapped", line 11 in
Aborted
```

[MasseR]

65710 fix for flameshot

[volth]

also radare2-cutter

[worldofpeace]

@FRidh I think it's good if this is pinned? There is a very large amount of reports coming in daily.

[teto]

it totally makes sense to pin it since the longterm fix broke - in the short term - many things.

[worldofpeace]

it totally makes sense to pin it since the longterm fix broke - in the short term - many things.

Indeed, I think this is an issue that needs as much attention as a ZHF one would need.
Almost blocking release in fact.

[xaverdh]

An approximate list of packages called with qt5.callPackage that use stdenv.mkDerivation, generated by grepping through nixpkgs master, is:
../applications/misc/doomseeker/default.nix
../applications/graphics/fstl/default.nix
../applications/networking/browsers/otter/default.nix
../development/tools/analysis/snowman/default.nix
../development/libraries/gecode/3.nix
../development/libraries/gecode/default.nix
../os-specific/linux/i7z/default.nix
../os-specific/linux/v4l-utils/default.nix
../applications/audio/carla/default.nix
../applications/video/clipgrab/default.nix
../applications/radio/gqrx/default.nix
../applications/networking/instant-messengers/spectral/default.nix
../applications/radio/qsstv/default.nix
../applications/misc/cura/stable.nix
../applications/misc/cura/lulzbot.nix
../applications/misc/cura/plugins.nix
../applications/misc/vym/default.nix
../applications/radio/wsjtx/default.nix
../applications/graphics/scantailor/advanced.nix
../development/tools/minizinc/ide.nix
Maybe the maintainers of these should be pinged?

[vbgl]

It seems that the wrap-qt-apps-hook only wraps ELF executables. How to fix a python program?

[worldofpeace]

@vbgl To wrap manually.

[worldofpeace]

wrapQtApp in postFixup.

[knedlsepp]

I'm using the following command to find the remaining packages that need fixing:

find . -type f -exec grep -q 'qt5' {} \; -exec grep -l 'stdenv.mkDerivation' {} +

[knedlsepp]

Something that is still not completely clear to me: Should all Qt applications be changed to not use stdenv.mkDerivation or only those that are broken by the most recent changes? I did try to run a few Qt-applications that still use stdenv.mkDerivation but I couldn't get them to crash, so I'm wondering if they are fine already or if my NixOS machine is in a state that by chance has the right qt versions? Do I need to first install some older version of qt to make them reliable crash?

[samueldr]

All Qt applications not wrapped should end up crashing in those situations. Some had ad-hoc fixes added with custom wrappers, though, which could mask issues. It's possible, though, that it doesn't end up crashing because there's no mismatched Qts or other environmental non-issues.

[mmlb]

I'm trying to update flent (a python application using pyqt) to latest release. I've got the output working by running wrapQtApp in postFixup, but this new version wants to try running the gui as part of the tests. I've skipped that test to verify postFixup thing works but I'd rather not drop that test. How can I do the equivalent for running buildPythonApplication tests?

[FRidh]

I think we should avoid custom builders when we can, because they don't allow for composition when different frameworks/languages are used together. This is also the reason why I am splitting buildPythonPackage into hooks.

@mmlb you might be able to move it to postInstall. That way it is wrapped before tests start.

[mmlb]

I think we should avoid custom builders when we can, because they don't allow for composition when different frameworks/languages are used together. This is also the reason why I am splitting buildPythonPackage into hooks.

makes sense to me

@mmlb you might be able to move it to postInstall. That way it is wrapped before tests start.

This didn't work. I'm only wrapping the packaged programs, but need to make python setup.py test be wrapped. I'm thinking about writing a custom checkPhase that runs a wrapped script.

[xaverdh]

I tried to fix notepadqq, but apparently the wrapper does not pick up the necessary plugins (no QT_PLUGIN_PATH). Any ideas what I am doing wrong?
Resolved: The executable was a bash script.

[mmlb]

I'm thinking about writing a custom checkPhase that runs a wrapped script.

This worked. https://github.com/NixOS/nixpkgs/pull/66323

[worldofpeace]

Documented wrapQtAppsHook ignoring files that are not ELF headers #66325

[gnidorah]

@ttuegel

Do not import Qt package sets; the Qt versions of dependencies may not be coherent, causing build and runtime failures.

What does it mean? Could you provide some examples?

[ttuegel]

I updated the manual to show how to do this. I was uncomfortable demonstrating what _not_ to do, but since you asked, the import line of packages should look like this:

```.nix
{ qtbase, qtdeclarative }: /* et cetera */

and not like this:

```.nix
{ qt5 }: /* or qt59, qt512, or anything else like that */

Therefore, your buildInputs should look like this:

```.nix
{
buildInputs = [ qtbase ];
}

and not like this:

```.nix
{
  buildInputs = [ qt5.qtbase ];
}

[gnidorah]

@ttuegel Got it, thank you!

[mixmixmix]

@AndersonTorres: cutegram seems to suffer from the same issue.

[oxij]

Anki fixed in #66796.

[jtojnar]

Introducing wrapQtAppHook into qt5.mkDerivation pollutes a closure of non-Qt variants of packages using that deriver: https://github.com/NixOS/nixpkgs/pull/67134

[aanderse]

@MP2E dolphinEmuMaster is broken in master currently, requiring fixes as described by this issue.
cc @marius851000 @ashkitten @delroth

[ashkitten]

taking a look, @aanderse

[Ma27]

67244 bumps teamviewer, builds with the latest QT and uses the new QT hook.

[ttuegel]

Introducing wrapQtAppHook into qt5.mkDerivation pollutes a closure of non-Qt variants of packages using that deriver:

I would recommend selecting the deriver based on if the package is using Qt, i.e. (if withQt then mkDerivation else stdenv.mkDerivation) { ... }.

[peterhoeg]

There is an issue with variables added to qtWrapperArgs not being expanded properly.

In case of a gstreamer application, this doesn't work:

  qtWrapperArgs = [
    "--prefix GST_PLUGIN_SYSTEM_PATH_1_0 : $GST_PLUGIN_SYSTEM_PATH_1_0"
  ];

Where as this does:

```nix
postInstall = ''
qtWrapperArgs+=(--prefix GST_PLUGIN_SYSTEM_PATH_1_0 : $GST_PLUGIN_SYSTEM_PATH_1_0)
'';

[Shados]

@ttuegel

Using stdenv.mkDerivation with Qt applications has always been unsupported.

Why, though? The reasoning behind this doesn't seem to be documented anywhere that I can see, and I'm wondering what the benefit is versus using a hook. The manual merely says:

mkDerivation is a wrapper around stdenv.mkDerivation which applies some Qt-specific settings.

And as far as I can tell from reading the Nix expression for it, the only thing it does aside from adding wrapQtAppsHook is configuring some debug flags based on an argument to the Qt package set. So I have some questions:

1. Have I missed something that the custom deriver is doing?
2. Is the per-set debug flag configuration something that can only be done by using a custom deriver...?
3. Is the deriver approach more composable than the hook approach?
4. Why is it called mkDerivation rather than something like mkQtDerivation? The difference between stdenv.mkDerivation and mkDerivation is non-obvious to someone who is reading a derivation expression without having also read the call site, and even then they still need to know that qt5.mkDerivation exists a priori.

[lightbulbjim]

Why is it called mkDerivation rather than something like mkQtDerivation? The difference between stdenv.mkDerivation and mkDerivation is non-obvious to someone who is reading a derivation expression without having also read the call site, and even then they still need to know that qt5.mkDerivation exists a priori.

Agree that the naming isn't ideal. It would be a bit of a pain to rename everything now though.

[worldofpeace]

Why is it called mkDerivation rather than something like mkQtDerivation? The difference between stdenv.mkDerivation and mkDerivation is non-obvious to someone who is reading a derivation expression without having also read the call site, and even then they still need to know that qt5.mkDerivation exists a priori.

Agree that the naming isn't ideal. It would be a bit of a pain to rename everything now though.

Indeed. Though if someone wanted to submit a proposal to change this it would be considered.
(obviously after the branch off)

[ttuegel]

There is an issue with variables added to qtWrapperArgs not being expanded properly.

This may not be desirable, but it is expected that shell variables will not expand. Off hand, I don't know how (or when!) to expand them during the build.

[ttuegel]

And as far as I can tell from reading the Nix expression for it, the only thing it does aside from adding wrapQtAppsHook is configuring some debug flags based on an argument to the Qt package set. So I have some questions:

1. Have I missed something that the custom deriver is doing?

No, but the custom deriver reserves the right to claim more behaviors in the future.

2. Is the per-set debug flag configuration something that can only be done by using a custom deriver...?

3. Is the deriver approach more composable than the hook approach?

4. Why is it called `mkDerivation` rather than something like `mkQtDerivation`? The difference between `stdenv.mkDerivation` and `mkDerivation` is non-obvious to someone who is reading a derivation expression without having also read the call site, and even then they still need to know that `qt5.mkDerivation` exists a priori.

The answer to all these questions is roughly, "Because the largest package set I'm familiar with in Nixpkgs is haskellPackages, and this is how it works." That's not a great answer, but I figure we could do worse than to imitate a large, mature set of packages.

I'm open to switching to a hook-based architecture after NixOS 19.09. Whether we keep a custom deriver or switch to a hook, we should also start failing the build if the correct one isn't included.

[vandenoever]

I've a question regarding development of Qt applications on NixOS. I'll take the thing I'm attempting currently as an example.

I'd like to try out and possibly code on the current Kate master. To do so I've written a small nix expression:

{ pkgs ? import <nixpkgs> {} }:
with pkgs;
let
  kate = kdeApplications.kate.overrideAttrs (oldAttrs: rec {
    buildInputs = oldAttrs.buildInputs ++ [ ninja ripgrep vim strace ];
  });
in
  kate

This extends the buildInputs for Kate with some development tools. I enter the dev environment with nix-shell --pure. The --pure is there to avoid clashing with my installed version of kate.

However, the unit tests (ctest -V) fail with the infamous qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in "".

In this environment, QT_PLUGIN_PATH, QT_QPA_PLATFORM and QT_QUICK_CONTROLS_STYLE are not set. HOME, DISPLAY, XDG_CONFIG_DIRS and XDG_CONFIG_DIRS are not set. Setting the QT_* variables does not solve the problem.

Is this the right way to enter a dev environment for developing Qt applications? I'm especially keen on reusing the NixPkgs definitions of the applications.

Edit: This command does work:

PATH=$PATH:/run/current-system/sw/bin ctest -V

Is there a way to add that to the environment in the above Nix expression?

[ambrop72]

I want to fix #65564 but I still don't understand exactly what changed that caused VirtualBox to break. What exactly was changed in the behavior of the Qt derivations which results VirtualBox no longer finding what it needs? Was the default search behavior of Qt somehow modified?

[samueldr]

The following explanation might lack precision, but the gist of it is basically right.

"Nothing" changed in how Qt looks for its libraries, as far as Qt is concerned. What changed in #54525 is that with the change, it relies on adding wrappers to correctly find the right dependencies.

Those wrappers, in turn, AFAIUI, breaks assumptions in the hardening.

[ambrop72]

@samueldr The interesting thing is that the VirtualBoxVM binary, when used with hardening, always unsets QT_PLUGIN_PATH. So the reason that it worked before cannot be that QT_PLUGIN_PATH happened to include the right paths. So just by what mechanism did it find the plugins before? Maybe something related to propagatedBuildInputs?

Though, it really does not matter any more because I've just managed to make it work and will open a PR soon.

[ambrop72]

I meant propagatedUserEnvPkgs...

[ttuegel]

So the reason that it worked before cannot be that QT_PLUGIN_PATH happened to include the right paths. So just by what mechanism did it find the plugins before?

We have a custom patch which scans for plugins relative to entries in PATH, and this was probably how it worked. This mechanism has always been very fragile; the purpose of the changes made to Qt packaging was to avoid relying on this mechanism. I don't have an explanation for why this mechanism has broken _now_, though.

[ambrop72]

So the reason that it worked before cannot be that QT_PLUGIN_PATH happened to include the right paths. So just by what mechanism did it find the plugins before?

We have a custom patch which scans for plugins relative to entries in PATH, and this was probably how it worked. This mechanism has always been very fragile; the purpose of the changes made to Qt packaging was to avoid relying on this mechanism. I don't have an explanation for why this mechanism has broken _now_, though.

I think this should be removed. One problem is that it is a security issue for VirtualBox which is setuid (not sure exactly when it drops privileges though).

[ttuegel]

I think this should be removed.

So do I, that was the primary motivation introducing wrapQtAppsHook.

[leenaars]

Is there any guidance how to do this with PyQt based applications? See https://github.com/NixOS/nixpkgs/pull/68405

[acowley]

I am not certain which parts of this report are related to this issue:
I followed the nixos-unstable channel to e19054ab3cd5b7cc9a01d0efc71c8fe310541065

I have kdenlive among my systemPackages; after the update, running kdenlive from a Konsole window results in hundreds of warnings and "Unknown asset" lines followed by a segfault. I can launch kdenlive from the menu. It starts and seems to work, but rendering a video fails with this error log:

Rendering of /home/acowley/Videos/bloop.mp4 crashed

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, minimal, offscreen, vnc, xcb, wayland-org.kde.kwin.qpa.

Usually I start kdenlive from the terminal so I see all its gory log output, but I don't know how to reveal that when starting it from the launcher. This latter error looks like a helper executable not being wrapped, but I do not know which executable that might be.

[bjornfor]

@acowley: sounds related to https://github.com/NixOS/nixpkgs/issues/68404.

[acowley]

It seems like mlt might not be properly wrapped, which could be the rendering problem. No idea yet on the launching from a terminal problem.

Edit: I made the suggested changes to the mlt/qt5.nix expression (taking mkDerivation as a parameter), but nothing is changed: kdenlive segfaults when started from a terminal; starts okay from the launcher, but rendering fails with the same error message as above.

Edit 2: It turned out I had konsole toggled with "Pin to Task Manager" on the desktop. This created a multi-QT environment as the pinned version was stale; that was the cause of kdenlive segfaulting when launched from the terminal. Rendering crash still under investigation.

[acowley]

I think @bjornfor was correct that the melt executable is not properly wrapped, as I was able to follow the suggestion at his link and end up with a better-looking wrapper. However, it turns out this was not the cause of the error I saw. kdenlive caches paths for an MLT profiles folder and a Melt path under Settings -> Configure Kdenlive -> Environment. If you clear these out, it will discover the right paths and populate the GUI elements. I'm working on a patch to get us out of that hole.

[tobiasBora]

I'm just curious, if I understand, all apps should use mkDerivation instead of stdenv.mkDerivation no? Then, why can't we "just" search all stdenv.mkDerivation and turn them into mkDerivation, at least for simple enough packages? That could avoid bad surprises at runtime.

[worldofpeace]

@tobiasBora mkDerivaiton here is from qt*. Everyone should use stdenv.mkDerivation unless it's a qt application and needs that special deriver.

Though it was discussed if we could get a semi-automated way to figure out what expressions need to be fixed.

[ttuegel]

Though it was discussed if we could get a semi-automated way to figure out what expressions need to be fixed.

It would be simple, at least, to add a check to the qtbase setup hook that some special variable is set by the deriver, and fail those builds with do not use it.

[worldofpeace]

@ttuegel That actually does sound very simple :sparkles:

If we could set that up we could get a hydra jobset for the PR and I think have them all fixed.
I'm not sure at this point we could block 19.09 on that, we have to release eventually.
But all the fixes that come out of that should be completely fine for backports.

[nh2]

For meshlab, I'm moving to the hook in #70937.

[FRidh]

Is there really no way we can do without a custom deriver? I mean, Qt in the end are "just" libraries, its not its own build system. I get there are issues, but, using custom derivers prevents composition.

[ttuegel]

Is there really no way we can do without a custom deriver? I mean, Qt in the end are "just" libraries, its not its own build system.

@FRidh I think Qt is closer to Python or Emacs because it (effectively) has its own runtime system. It's not just a library on top of the C runtime. That aside, your point is well taken, and I will see about getting rid of the custom deriver.

[f--t]

@ttuegel It seems quite a few (perhaps all) of the python packages depending on pyqt5 an pyqt4 are currently broken, e.g. matplotlib qt backend, jupyter qt-console.

Since python packages don't directly use stdenv, the doc referenced above doesn't directly apply. Are there any suggestions on the idiomatic way fixing this. Using propagatedBuildInputs with wrapQtAppsHook in pyqt5 doesn't fix the problem.

[rnhmjoj]

Could someone finish the review at #67806?

[KoviRobi]

Not sure this is something we care about too much, but sometimes python+Qt packages seem to be double-wrapped. See openshot-qt and https://github.com/NixOS/nixpkgs/pull/71335. Is there a way to avoid this (seems like rapid-photo-downloader avoids it)? But it's also a hand-coded one, not sure if there should be a library function for it.

[worldofpeace]

You can do

dontWrapQtApps = true;
makeWrapperArgs = [
  "\${qtWrapperArgs[@]}"
];

I've documented to do the something like this for gtk applications recently

https://nixos.org/nixpkgs/manual/#ssec-gnome-common-issues

[edef1c]

I've needed to use "\"\${qtWrapperArgs[@]}\"", which I assume is what you meant. I've been saving some PRs for after I figure out how to get rid of that. Seems like an escaping issue we should be able to fix.

[worldofpeace]

I've needed to use "\"\${qtWrapperArgs[@]}\"", which I assume is what you meant. I've been saving some PRs for after I figure out how to get rid of that. Seems like an escaping issue we should be able to fix.

Oops, guess I misspelled. Updated the example.
I've actually suggested this a while ago so there's examples in nixpkgs that work fine

• https://github.com/NixOS/nixpkgs/blob/c9b85da380d4c15e3bec8b7d2124455e0fbae423/pkgs/applications/networking/browsers/webmacs/default.nix#L32

Then afterwards documented it for gtk.

[edef1c]

Basically, this approach seems to break with GTK, because the array may contain empty elements (for environment variables that don't actually need prefixing with anything). Improving that (by excluding empty vars from being appended) causes a rather huge rebuild, so I decided against it.
Frankly, I think the fix for that belongs in buildPythonApplication, since we shouldn't be doing word splitting on makeWrapperArgs anyway.

[laikq]

Hi, are there any ideas or progress on how to fix pyqt -> matplotlib & others?

[wucke13]

Some that are yielding the good ol' wrapQtAppsHook:

• https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/analysis/hotspot/default.nix
• https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/profiling/heaptrack/default.nix

[andersk]

I opened #75405 two months ago to fix muse, but aside from some nitpicking over whether to use Qt mkDerivation or wrapQtAppsHook, it seems to have been ignored and muse is still broken. Meanwhile, other PRs are being merged in both styles. Is one of mkDerivation or wrapQtAppsHook preferred over the other?

[worldofpeace]

I opened #75405 two months ago to fix muse, but aside from some nitpicking over whether to use Qt mkDerivation or wrapQtAppsHook, it seems to have been ignored and muse is still broken. Meanwhile, other PRs are being merged in both styles. Is one of mkDerivation or wrapQtAppsHook preferred over the other?

I merged it. It's not that big of a deal as long as it's fixed. In general we should just do what the docs say.

[wucke13]

paraview needs the hook too

[lapp0]

tikzit needs the hook as well

[wucke13]

qview needs a fix

[bbarker]

qgo appears to need this

[worldofpeace]

Various packages that were mentioned needed fixes are in https://github.com/NixOS/nixpkgs/pull/80982

[rnhmjoj]

If anyone has any idea what to do about matplotlib and python libraries... I would be happy to try implementing it. The issue is https://github.com/NixOS/nixpkgs/issues/80147

[yevhenshymotiuk]

android-studio (avd) seems to need this

9:29 PM Emulator: Fatal: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

9:29 PM Emulator: 

9:29 PM Emulator: Available platform plugins are: xcb.

9:29 PM Emulator: ((null):0, (null))

9:29 PM Emulator: Process finished with exit code 134 (interrupted by signal 6: SIGABRT)

[nixos-discourse]

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

https://discourse.nixos.org/t/please-fix-all-packages-which-were-broken-by-the-qt-wrapping-changes/6444/16

[unode]

mnemosyne is also failing.
Since it's a python application that uses pyqtwebengine and python.pkgs.buildPythonApplication, what is the recommendation for a fix here?

[rnhmjoj]

@unode: Take a look at expression for qutebrowser.

[unode]

Thanks @rnhmjoj . Pull request #84954

[shuhaowu]

I think this wrap with the python development mode is broken. See this demo repository I created: https://github.com/shuhaowu/nix-qt-python-dev-mode-failure.

To reproduce:

1. Clone that repository.
2. $ nix-shell
3. $ qt-test
4. Watch the following error occur and the program crashes:

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.

However, outside of nix-shell is fine. To reproduce:

1. Clone that repository.
2. $ nix-build
3. $ result/bin/qt-test
4. See the hello world message.

What's going on here? Also any criticism on my default.nix file is welcome as I'm still a nix noob.

[shuhaowu]

The previous issue seems to be solved if the wrapQtApp wrapped script's environment variable is exported into command line. For me this was:

export QT_PLUGIN_PATH='/nix/store/0d8hv33sqxbzi3gkvcv1wd7y101n9ldv-qtbase-5.12.7-bin/lib/qt-5.12.7/plugins'${QT_PLUGIN_PATH:+':'}$QT_PLUGIN_PATH
export QT_PLUGIN_PATH='/nix/store/a8b5vd0hy86pqmrsvxdx88qzpd4kkk09-qtsvg-5.12.7-bin/lib/qt-5.12.7/plugins'${QT_PLUGIN_PATH:+':'}$QT_PLUGIN_PATH
export QT_PLUGIN_PATH='/nix/store/jjyjr2ck1k21s6z7lr3ip2yj7d10k4iw-qtdeclarative-5.12.7-bin/lib/qt-5.12.7/plugins'${QT_PLUGIN_PATH:+':'}$QT_PLUGIN_PATH
export QML2_IMPORT_PATH='/nix/store/jjyjr2ck1k21s6z7lr3ip2yj7d10k4iw-qtdeclarative-5.12.7-bin/lib/qt-5.12.7/qml'${QML2_IMPORT_PATH:+':'}$QML2_IMPORT_PATH
export QML2_IMPORT_PATH='/nix/store/gbal6xsngnpsdbw40qqvfmddrqb8ck73-qtquickcontrols-5.12.7/lib/qt-5.12.7/qml'${QML2_IMPORT_PATH:+':'}$QML2_IMPORT_PATH
export QT_PLUGIN_PATH='/nix/store/j86x96jnfjk6f7p63kfm9q5c19c2dc9c-qtwayland-5.12.7-bin/lib/qt-5.12.7/plugins'${QT_PLUGIN_PATH:+':'}$QT_PLUGIN_PATH
export QML2_IMPORT_PATH='/nix/store/j86x96jnfjk6f7p63kfm9q5c19c2dc9c-qtwayland-5.12.7-bin/lib/qt-5.12.7/qml'${QML2_IMPORT_PATH:+':'}$QML2_IMPORT_PATH

Adding this before launching qt-test from nix-shell appears to work! Now to turn this into a nix-shell friendly solution is a different problem...

[stale[bot]]

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.