Bug 2414020

Summary: kwin 6.5.2 failed to start with qt 6.9.1
Product: [Fedora] Fedora Reporter: jackyzy823
Component: kwinAssignee: marcdeop
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 42CC: jgrulich, kde-sig, marcdeop, suraj.ghimire7, than
Target Milestone: ---Keywords: Desktop, Upgrades
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2025-11-11 12:53:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description jackyzy823 2025-11-11 12:00:14 UTC 
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
Comment 1 Jan Grulich 2025-11-11 12:53:19 UTC 
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.
Comment 2 jackyzy823 2025-11-11 13:00:47 UTC 
stricter qt requirements for kwin. maybe ?
Comment 3 Jan Grulich 2025-11-11 13:02:10 UTC 
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.
Comment 4 jackyzy823 2025-11-11 13:16:59 UTC 
>  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.
Comment 5 Jan Grulich 2025-11-11 13:46:30 UTC 
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.