We'll see what ofborg says, but my local review says this should rebuild about 200 packages, which is small enough that we can merge directly into master.

The first iteration of this pull request accidentally changed the hashes of qt512.qtbase and qt514.qtbase, but I think that is fixed now. I also pinned all the broken packages to Qt 5.14; I think some of them were broken in master, too, but at least now they aren't more broken.

The appstream-qt library was incorrectly pinned to the latest Qt version so that Plasma had mixed Qt 5.14 / Qt 5.15 dependencies through it.

plasma-desktop still has a build dependency on Qt 5.15 that I'm trying to track down.

plasma-wayland-protocols was also pinned to the latest version of Qt, giving a mixed version dependency.

Running Plasma on a non-default Qt version seems to be a good exercise for flushing out bugs, if nothing else!

I'm also going to pin lxqt to Qt 5.14 because it depends on plasma5.kwin.

@ttuegel can you build the current state?

I tried merging your pr into master and get the following error:

error: attribute 'qtbase' missing, at /home/bastian/projects/nixos/nixos-config/nixpkgs/pkgs/desktops/plasma-5/default.nix:85:43

@bkchr Sorry, a minor mistake on my end. It should be good to go now.

I think this was showing more rebuilds than there actually are because there was an update to appstream-qt in master which I hadn't rebased against. That should be fixed now.

I've verified that the hashes of packages depending on qt514 are unchanged from master branch, and the tests pass, so I'm just waiting for the final list of changes from ofborg to check that this can go into master.

Ahhh okay :)

That should be all of it. There are 27 failing builds, but they're all "new" packages: libraries that are don't build with qt515 and are marked broken.

Actually I got it down to 25! 😁

Was this the PR u needed in 20.09 @ttuegel? If so we already branched, but we're not "BETA FROZEN" yet.

Was this the PR u needed in 20.09 @ttuegel? If so we already branched, but we're not "BETA FROZEN" yet.

Yes. I will backport after merging this.

Hey, it's great to see this merged 🎉
Thanks for the great work also for getting it into the 20.09 release!

I am wondering if we could get some applications that would profit from a more recent Qt version updated. For example, qutebrowser is still using qtwebengine 5.14 with this. If you agree this should be updated, I can look into it and make a pull request.

Oh yes, updating qtwebengine is definitely important, just from a security perspective alone.

If you agree this should be updated, I can look into it and make a pull request.

Yes, it should be updated. I fully support updating anything that can be updated, I just didn't see any reason to block the Qt update because some things are (hopefully temporarily) broken.

I have another issue that's loosely related to this PR. On the release-20.09 branch the kdeApplications are built using Qt 5.12, but the latest release of the KDE Application bundle, 20.08, seems to require a later version of Qt. At least kdeApplications.kmime is failing to build on the release-20.09 branch, because it is looking for a Qt version >= 5.13. In general the kdeApplications seem to need some fixing on the release-20.09 branch. @ttuegel could you have a look at that?

At least kdeApplications.kmime is failing to build on the release-20.09 branch, because it is looking for a Qt version >= 5.13. In general the kdeApplications seem to need some fixing on the release-20.09 branch.

I will take a look, but I'm not sure if this will be fixable in a way that people like. Plasma 5.18 requires Qt 5.12, and for the sake of closure size we can't build Plasma with Qt 5.12 and Applications with Qt 5.15. It might be possible to build the core applications with Qt 5.12 (applications such as Konsole and Dolphin, that ship as part of the default environment). However, anything that gets built with Qt 5.15 will not be themed in the default environment! We may need to downgrade back to KDE Applications 20.04. I don't want to do that, but it wouldn't be as bad as it seems: Applications gets security updates much longer than Plasma and Frameworks and Applications 20.08 will be made obsolete by Applications 20.12 anyway.

In this case I would argue for downgrading the KDE Applications to 20.04 on the release branch. Everyone who wants more up-to-date versions of these applications with Qt 5.15 can pull them from unstable.

Everyone who wants more up-to-date versions of these applications with Qt 5.15 can pull them from unstable.

There are some issues pulling packages from unstable to a stable channel, and as such I usually can't reliably tell someone to "pull from unstable" because we can't really predict how things are going to interact perfectly.

However, anything that gets built with Qt 5.15 will not be themed in the default environment!

Perhaps this is what #98009 is about

Perhaps this is what #98009 is about

I don't think so. That issue is about GTK theming, which is built in to Qt. The problem is with external themes, like the Breeze theme that comes with Plasma. Breeze will be built with Qt 5.12, so a Qt 5.15 application can't load it.

In this case I would argue for downgrading the KDE Applications to 20.04 on the release branch.

I settled on a better idea. KDE Applications do not have to be updated in sync with one another; these are separate projects upstream that have just agreed to have a common release schedule. We can downgrade only the packages from 20.08 that require Qt 5.15. That will leave most packages at their latest version, but retain compatibility with Plasma for the remainder!

Edit: In fact, the applications and libraries requiring Qt 5.15 all seem to belong under the KDE PIM umbrella, so now I'm wondering if we should just separate that subset from the rest of KDE Applications in the future.

I settled on a better idea. KDE Applications do not have to be updated in sync with one another; these are separate projects upstream that have just agreed to have a common release schedule. We can downgrade only the packages from 20.08 that require Qt 5.15. That will leave most packages at their latest version, but retain compatibility with Plasma for the remainder!

My clever plan failed: Some of KDE Applications 20.04.3 don't build with the latest KDE Frameworks libraries. I don't want to also downgrade the libraries. So, we're back to Qt 5.15 for the KDE PIM suite. We can retain compatibility with Plasma by bundling the Breeze Qt 5 theme with these applications.