Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for wrapQtAppsHook #65399

Open
ttuegel opened this issue Jul 25, 2019 · 44 comments

Comments

@ttuegel
Copy link
Member

commented Jul 25, 2019

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

@worldofpeace worldofpeace pinned this issue Jul 26, 2019

@bjornfor

This comment has been minimized.

Copy link
Contributor

commented Jul 26, 2019

@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

This comment has been minimized.

Copy link
Member Author

commented Jul 26, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jul 27, 2019

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

This comment has been minimized.

Copy link
Member

commented Jul 27, 2019

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

Edit: PR incoming to fix this.

@samueldr

This comment has been minimized.

Copy link
Member

commented Jul 28, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Jul 28, 2019

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

This comment has been minimized.

Copy link
Member

commented Jul 28, 2019

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

This comment has been minimized.

Copy link
Member

commented Jul 28, 2019

(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.

@samueldr samueldr referenced this issue Jul 28, 2019
4 of 10 tasks complete
@ttuegel

This comment has been minimized.

Copy link
Member Author

commented Jul 28, 2019

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 comment has been minimized.

Copy link
Member

commented Jul 28, 2019

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

This comment has been minimized.

Copy link
Member

commented Jul 28, 2019

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

mmahut added a commit to mmahut/nixpkgs that referenced this issue Jul 28, 2019

coreyoconnor added a commit to coreyoconnor/nixpkgs that referenced this issue Jul 28, 2019

mmahut added a commit to mmahut/nixpkgs that referenced this issue Jul 28, 2019

nethack: wrapQtApp only in qtMode
Regression introduced in NixOS#54525, tracked in NixOS#65399.
@mmahut mmahut referenced this issue Jul 28, 2019
3 of 10 tasks complete

yegortimoshenko added a commit to Holo-Host/nixpkgs that referenced this issue Jul 29, 2019

@peterzky

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

#65543 fix qt5ct

teto added a commit to teto/nixpkgs that referenced this issue Jul 29, 2019

@teto

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

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

@gnidorah gnidorah referenced this issue Aug 13, 2019
3 of 10 tasks complete

vbgl added a commit that referenced this issue Aug 14, 2019

vbgl added a commit that referenced this issue Aug 14, 2019

@mixmixmix

This comment has been minimized.

Copy link

commented Aug 14, 2019

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

WhittlesJr added a commit to WhittlesJr/nixpkgs that referenced this issue Aug 14, 2019

WhittlesJr added a commit to WhittlesJr/nixpkgs that referenced this issue Aug 14, 2019

WhittlesJr added a commit to WhittlesJr/nixpkgs that referenced this issue Aug 14, 2019

vbgl added a commit to vbgl/nixpkgs that referenced this issue Aug 15, 2019

@vbgl vbgl referenced this issue Aug 15, 2019
3 of 10 tasks complete
@averelld averelld referenced this issue Aug 16, 2019
4 of 10 tasks complete
@oxij

This comment has been minimized.

Copy link
Contributor

commented Aug 17, 2019

@ivanbrennan ivanbrennan referenced this issue Aug 18, 2019
2 of 10 tasks complete

worldofpeace added a commit to ivanbrennan/nixpkgs that referenced this issue Aug 18, 2019

worldofpeace added a commit to ivanbrennan/nixpkgs that referenced this issue Aug 18, 2019

worldofpeace added a commit to vbgl/nixpkgs that referenced this issue Aug 18, 2019

@jtojnar

This comment has been minimized.

Copy link
Contributor

commented Aug 20, 2019

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

@aanderse

This comment has been minimized.

Copy link
Contributor

commented Aug 21, 2019

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

@ashkitten

This comment has been minimized.

Copy link
Contributor

commented Aug 22, 2019

taking a look, @aanderse

@ashkitten ashkitten referenced this issue Aug 22, 2019
2 of 10 tasks complete
@Ma27

This comment has been minimized.

Copy link
Member

commented Aug 22, 2019

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

teto added a commit to teto/nixpkgs that referenced this issue Aug 22, 2019

@greizgh greizgh referenced this issue Aug 22, 2019
4 of 10 tasks complete
@ttuegel

This comment has been minimized.

Copy link
Member Author

commented Aug 22, 2019

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) { ... }.

teto added a commit to teto/nixpkgs that referenced this issue Aug 23, 2019

greizgh added a commit to greizgh/nixpkgs that referenced this issue Aug 23, 2019

worldofpeace added a commit to greizgh/nixpkgs that referenced this issue Aug 23, 2019

worldofpeace added a commit to Alkeryn/nixpkgs that referenced this issue Aug 24, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.