kdeApplications uses qt514 by default while all-packages.nix uses qt515, causing incompatibilites

[doronbehar]

Describe the bug

Consider this:

https://github.com/NixOS/nixpkgs/blob/0826f2efaed5c64d3c574f87dd4dcf978207f576/pkgs/top-level/all-packages.nix#L21555-L21562

Where all other libsForQt5.callPackage usages in all-packages.nix use libsForQt515. This causes incompatibilities if derivations available in kdeApplications are used in conjunction with expressions called with libsForQt5.callPackage used in all-packages.nix.

To Reproduce

For example, kile has:

https://github.com/NixOS/nixpkgs/blob/0826f2efaed5c64d3c574f87dd4dcf978207f576/pkgs/applications/editors/kile/default.nix#L51-L52

Which causes it to have the environment of kdeApplications.konsole in it's wrapper. The environment of kdeApplications.konsole has qt514 vars but kile is built with qt515 causing it not to start.

Additional context

A fix for this should be similar to the sprint in #99956 . FYI @piegamesde .

Notify maintainers

@ttuegel

[Congrav1ty]

Discovered this when most of the stuff in kdeconnect wouldn't work:

[jdnixx@JNIXX:~]$ kdeconnect-sms
Cannot mix incompatible Qt library (5.14.2) with this library (5.15.0)
Aborted (core dumped)

[jdnixx@JNIXX:~]$ kdeconnect-app
file:///nix/store/bv6wyf4k0ahla4fr0kcrrm0yrs42yj1q-kirigami2-5.73.0/lib/qt-5.15.0/qml/org/kde/kirigami.2/private/RefreshableScrollView.qml:143:13: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
file:///nix/store/bv6wyf4k0ahla4fr0kcrrm0yrs42yj1q-kirigami2-5.73.0/lib/qt-5.15.0/qml/org/kde/kirigami.2/templates/AbstractApplicationHeader.qml:153:9: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
file:///nix/store/bv6wyf4k0ahla4fr0kcrrm0yrs42yj1q-kirigami2-5.73.0/lib/qt-5.15.0/qml/org/kde/kirigami.2/templates/AbstractApplicationHeader.qml:108:9: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
file:///nix/store/bv6wyf4k0ahla4fr0kcrrm0yrs42yj1q-kirigami2-5.73.0/lib/qt-5.15.0/qml/org/kde/kirigami.2/templates/AbstractApplicationHeader.qml:80:5: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
file:///nix/store/bv6wyf4k0ahla4fr0kcrrm0yrs42yj1q-kirigami2-5.73.0/lib/qt-5.15.0/qml/org/kde/kirigami.2/templates/AbstractApplicationHeader.qml:102:9: QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
Cannot mix incompatible Qt library (5.14.2) with this library (5.15.0)
Aborted (core dumped)

[jmercouris]

Kontact, Kmail, Korganizer, and Digikam appear not to be working for me at the current time, all of them are spitting out similar errors to what has been referenced here. Is there a solution for users in the meantime to run KDE Applications, or should we just wait?

[doronbehar]

@jmercouris & @Congrav1ty the fix for the issue is #101369 . We'd appreciate your help in testing it. Don't run nixpkgs-review on it, as it will take a long time to build all new attributes, but you can build your own system with it and hopefully report to us if you experience any issues.

If you also see some packages on the list of packages in the 1st comment, that you are sure to be working with the PR, it'd be helpful to list them for us, so we can mark them as good. As I said in my last comment there, I'm rather sure most packages should be OK, but I'm just not sure. (I'm a Gnome user).

[jmercouris]

I would like to help, but I have no idea how to test the aforementioned fix. If you could assist me or point me into the direction of how to do it, I would.

[doronbehar]

Sure :) With a clone of Nixpkgs, I think this should work for you:

# git clone https://github.com/nixos/nixpkgs if needed
cd nixpkgs
git remote add doronbehar https://github.com/doronbehar/nixpkgs
git fetch doronbehar
git checkout doronbehar/pkg/kdeApplications/qt515
sudo nixos-rebuild switch -I nixpkgs=$PWD

You can also use nixos-rebuild test or boot if you feel it's more appropriate. It will take quiet some time and CPU to build all the new packages.

[jmercouris]

I've tried to do a nixos-rebuild switch and received the following error:

error: undefined variable 'services' at /path/to/nixpkgs/on/my/machine nixos/modules/services/x11/display-managers/sddm.nix:12:13

thanks,

-John

[jmercouris]

Please note that on master I am able to build.

[doronbehar]

Aish, had a few typos.. Please try now:

# cd nixpkgs
git fetch doronbehar
git checkout doronbehar/pkg/kdeApplications/qt515
sudo nixos-rebuild switch -I nixpkgs=$PWD

If this doesn't work for you and you are on the tracked git branch pkg/kdeApplications/qt515, you should get the updated branch with git pull -f.

[doronbehar]

I'm rather sure it should evaluate for you.

[peterhoeg]

I've been thinking a little about this and seems like we're not really approaching this with an proper end-goal in mind. This particular PR will fix the issue right now by bumping Qt for kdeApplications, but next time there's an update, we are surely going to have to deal with this again in some shape or form.

How about propagating the Qt version from the transitive dependencies vs those that have direct dependencies on Qt? This way anything that needs Qt either depends on it directly (and can depend on a specific version) or it will otherwise get the Qt of its dependenc(y|ies)?

[doronbehar]

How about propagating the Qt version from the transitive dependencies vs those that have direct dependencies on Qt? This way anything that needs Qt either depends on it directly (and can depend on a specific version) or it will otherwise get the Qt of its dependenc(y|ies)?

You mean using passthrus? And what if you have say 3 deps from say kdeFrameworks, that each depends on qtbase, which dep's qtbase do you choose? Do you verify they all use the same qtbase?

I think because this can become a mess, we have lib.newScope. The problem is that we have slightly forgot about it, and we used different scopes' callPackages all in all-packages.nix.

@FRidh is right in 2 points: 1) "always use the callPackage of the scope you are in", and 2) for that to be made clear, we need a qt-applications.nix.

[FRidh]

Qt packaging is in a way similar to Python packaging. With Python it is important that all packages involved use the same versions of common dependencies. With Qt it is important that an application or your environment (e.g. plasma with its widgets) has dependencies that are all working with the same Qt version. Hence the reason we have a versioned libsForQt. This works fine, however, it breaks as soon as libraries are called from outside that set. This used to be the case with Python until about 4~5 years ago and is why I am strict regarding how we call Python packages.

The work mainly done now by @doronbehar is to put the libraries back in the correct scope and call applications with the correct scope in all-packages.nix. In principle that is sufficient, however, for clarity it may be wiser to put both applications and libraries in a qt-packages.nix.

Whether we should separate applications from libraries I don't know. With Python that is done because applications may override transitive dependencies, whereas with the libraries that would lead to inconsistencies. With Qt, it typically does not happen that we need to consider other versions of dependencies aside from Qt versions, so I don't think there is a need to do so. There is however the practical part to consider regarding recurseIntoAttrs; do we actually want to recurse into the set for all versions, especially when applications are in there as well?

As @doronbehar quoted me, I think we should avoid this myscope.callPackage pattern in all-packages.nix, and thus preferably have Qt-based applications also somewhere else, whether that is in a qt-packages.nix or qt-applications.nix, I leave open for now.

[nixos-discourse]

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

https://discourse.nixos.org/t/package-breeze-qt-broken-when-upgrading-to-20-09/9736/2