Reference: https://bugzilla.redhat.com/show_bug.cgi?id=2413564#c1 Reproducible: Always Steps to Reproduce: Found a way to reproduce 1. Install fresh F42 KDE from livecd 2. `dnf install fedora-repos-archive` to install qt 6.9.1 3. `dnf install qt6-qtbase-6.9.1` 4. `dnf update --exclude=qt6*` update system to update kwin to 6.5.2 but keep qt 6.9.1 5. Reboot Actual Results: Failed to show sddm loginui and error message: Error message ``` sddm-helper-start-wayland[1914]: "/usr/bin/kwin_wayland: symbol lookup error: /usr/bin/kwin_wayland: undefined symbol: _ZN21QPlatformBackingStore8rhiFlushEP7QWindowdRK7QRegionRK6QPointP20QPlatformTextureListbd, version Qt_6.9_PRIVATE_API\n" ``` Expected Results: shows SDDM loginui Additional Information: Qt would not be updated to 6.9.3 if other package (like fcitx5-qt) have a stricter requirement.and under this situation, dnf will not prevent this happen. The problematic API QPlatformBackingStore::rhiFlush(QWindow*, double, QRegion const&, QPoint const&, QPlatformTextureList*, bool, double) changed betwwen 6.9.1 and 6.9.2): https://github.com/qt/qtbase/commit/512d3f9a13b61e23d1554b39669a7464dce30b55#diff-fbfe84ad0d32a3dd977608c7621a2af545b1e3ebfb16a7a33e2e893ebede91a7
KWin has been rebuilt against Qt 6.9.3 and both updates were shipped together.I don't know what do you want us to do here.
stricter qt requirements for kwin. maybe ?
Sorry, KWin was rebuilt against Qt 6.9.2 and not 6.9.3, but I'm against forcing KWin to be tied to Qt version it was built against, because that would mean to rebuild KWin everytime we do Qt update, but that's not really necessary.
> but I'm against forcing KWin to be tied to Qt version it was built against, because that would mean to rebuild KWin everytime we do Qt update, but that's not really necessary. Thanks for your reply. I'm ok with this. ---- Just some more beginner's question: 1) Could we make some condition like "qt >= a minimum version" which follows kwin's CMakeLists.txt. Although this time qt version in kwin's CMakeLists.txt breaks too. 2) how could we prevent similar situation happening in the future.
1) This has nothing to do with what Qt version is required by KWin or declared in its CMakeLists.txt, the problem here is that the signature for a function that is part of private API has changed, which is allowed on the Qt side as it's a private API after all, it's just unfortunate it happened in a bugfix release now. 2) Make KWin to depend on Qt version it was built against, but that would mean we have to rebuild KWin for every single Qt update, which is not really necessary and I don't want to do that.