Description of problem: Latest update of qt5-qtbase (and related packages) seem to have broken dependencies. Version-Release number of selected component (if applicable): update from 5.15.3-1 to 5.15.3-2 (via dnf update) How reproducible: always Steps to Reproduce: dnf update qt5-qtbase Actual results: [root@mycroft~]$ LANG=C dnf update qt5-qtbase Last metadata expiration check: 0:29:21 ago on Thu May 4 12:42:46 2023. Error: Problem: problem with installed package kf5-kxmlgui-5.104.0-1.el9.next.x86_64 - package kf5-kxmlgui-5.104.0-1.el9.next.x86_64 requires libQt5Core.so.5(Qt_5.15.3_PRIVATE_API)(64bit), but none of the providers can be installed - cannot install both qt5-qtbase-5.15.9-2.el9.x86_64 and qt5-qtbase-5.15.3-1.el9.x86_64 - cannot install the best update candidate for package qt5-qtbase-5.15.3-1.el9.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) Expected results: update should run without dependency errors Additional info: This is a reduced test case - when I try to update my system, a total of 30 problems are listed, most of which relate to problems with libQt5Core.so.5. Details available on request.
We have updated Qt to 5.15.9 in CentOS Stream 9 so some of the packages will need to be rebuild.
(In reply to Jan Grulich from comment #1) > We have updated Qt to 5.15.9 in CentOS Stream 9 so some of the packages will > need to be rebuild. Ouch - I need new glasses! I didn't notice we went from 5.15.3-1 to 5.15.NINE-2 :-) So we need to wait until other packages are rebuilt.
I'm working on rebuilding all of KDE on epel9-next, but it is not going to be finished until next week sometime.
(In reply to Troy Dawson from comment #3) > I'm working on rebuilding all of KDE on epel9-next, but it is not going to > be finished until next week sometime. Great! I will report back as soon as the packages are rolled out.
(In reply to Dr. Stephan Wonczak from comment #4) > (In reply to Troy Dawson from comment #3) > > I'm working on rebuilding all of KDE on epel9-next, but it is not going to > > be finished until next week sometime. > > Great! I will report back as soon as the packages are rolled out. Status report: Over the week a bunch of kf5-packages got updated, but the qt5 update is still broken. Three kf5-packages are still problematic (not updated to 5.105): kf5-ki18n x86_64 5.96.0-1.el9 epel 1.7 M kf5-kwayland x86_64 5.96.0-1.el9 epel 512 k kf5-kxmlgui x86_64 5.96.0-1.el9 epel 726 k
Created attachment 1964853 [details] output of "dnf update --nobest"
Updates of qt5 (and parts of kf5) are still broken. For better debugging I attached the output of "dnf update --nobest" to this case.
I'm sorry this is taking longer than expected. I tried to combine the rebuilds needed for the new qt5, with updating the rest of the KDE Plasma Desktop. This didn't go well. I will be removing the updates from epel-next-testing and starting again with just the packages that need a rebuild due to the qt5 update. I'm sorry for the inconvenience, and appreciate the patience you have shown.
No problem - actually I appreciate your work in maintainig this stuff. Mistakes happen. When it does get fixed in the end, I'm happy that everyone gets a smooth experience. And my part was -really- small: Just making you aware that something has to be fixed. I will report back as soon as I see new packages arriving.
My latest attempt, which just have the qt5 rebuilds, has passed my tests, but I wouldn't mind an extra pair of eyes. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2023-22498da84c Would you be able to test by doing the following and reporting back the results. dnf --enablerepo=epel-next-testing clean all dnf --enablerepo=epel-next-testing update
(In reply to Troy Dawson from comment #10) > My latest attempt, which just have the qt5 rebuilds, has passed my tests, > but I wouldn't mind an extra pair of eyes. > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2023-22498da84c > > Would you be able to test by doing the following and reporting back the > results. > > dnf --enablerepo=epel-next-testing clean all > dnf --enablerepo=epel-next-testing update Works for me. It will be available also in EPEL? My live kickstarts [1] are broken right now. [1] https://github.com/mbugni/centos-remix
Yes, this looks rather better! (nb: I still had three problems due to some local packages stupidly reqiring an exact Version of a qt5-library, but I can work around that) Normal update now works: --- [root@mycroft~]$ LANG=C dnf update Last metadata expiration check: 0:07:50 ago on Mon May 22 12:47:26 2023. Dependencies resolved. ============================================================================== Package Arch Version Repo Size ============================================================================== Upgrading: kf5-ki18n x86_64 5.105.0-3.el9.next epel-next 1.7 M kf5-kiconthemes x86_64 5.105.0-3.el9.next epel-next 177 k kf5-kirigami2 x86_64 5.105.0-4.el9.next epel-next 450 k kf5-kwayland x86_64 5.105.0-5.el9.next epel-next 513 k kf5-kxmlgui x86_64 5.105.0-3.el9.next epel-next 741 k qgnomeplatform x86_64 0.9.0-1.el9 appstream 187 k qt5-designer x86_64 5.15.9-3.el9 appstream 160 k qt5-doctools x86_64 5.15.9-3.el9 appstream 684 k qt5-linguist x86_64 5.15.9-3.el9 appstream 873 k qt5-qtbase x86_64 5.15.9-3.el9 appstream 3.6 M qt5-qtbase-common noarch 5.15.9-3.el9 appstream 9.9 k qt5-qtbase-devel x86_64 5.15.9-3.el9 appstream 3.7 M qt5-qtbase-gui x86_64 5.15.9-3.el9 appstream 6.3 M qt5-qtbase-private-devel x86_64 5.15.9-3.el9 appstream 1.1 M qt5-qtdeclarative x86_64 5.15.9-3.el9 appstream 4.3 M qt5-qtdeclarative-devel x86_64 5.15.9-3.el9 appstream 1.5 M qt5-qtgraphicaleffects x86_64 5.15.9-1.el9 appstream 120 k qt5-qtimageformats x86_64 5.15.9-1.el9 appstream 104 k qt5-qtmultimedia x86_64 5.15.9-1.el9 appstream 817 k qt5-qtmultimedia-devel x86_64 5.15.9-1.el9 appstream 176 k qt5-qtquickcontrols x86_64 5.15.9-1.el9 appstream 1.1 M qt5-qtquickcontrols2 x86_64 5.15.9-1.el9 appstream 1.7 M qt5-qtquickcontrols2-devel x86_64 5.15.9-1.el9 appstream 103 k qt5-qtsvg x86_64 5.15.9-1.el9 appstream 186 k qt5-qtsvg-devel x86_64 5.15.9-1.el9 appstream 30 k qt5-qttools x86_64 5.15.9-3.el9 appstream 40 k qt5-qttools-common noarch 5.15.9-3.el9 appstream 11 k qt5-qttools-devel x86_64 5.15.9-3.el9 appstream 246 k qt5-qttools-libs-designer x86_64 5.15.9-3.el9 appstream 2.7 M qt5-qttools-libs-designercomponents x86_64 5.15.9-3.el9 appstream 784 k qt5-qttools-libs-help x86_64 5.15.9-3.el9 appstream 156 k qt5-qtwayland x86_64 5.15.9-1.el9 appstream 1.1 M qt5-qtx11extras x86_64 5.15.9-1.el9 appstream 35 k qt5-qtx11extras-devel x86_64 5.15.9-1.el9 appstream 16 k qt5-qtxmlpatterns x86_64 5.15.9-2.el9 appstream 1.0 M Transaction Summary ============================================================================== Upgrade 35 Packages Total download size: 36 M --- So for my part the problem can be marked as "fixed". Thanks for your work!
Thank you for confirming. Other people have confirmed this as well. I am going to mark this a done. There is still one qt5 problem, qt-creator, but that has it's own bug, and it's own problems.
Hello, CentOS Stream 9 is still broken. Do we need to file another bug?
What part is broken for you? If it is qt-creator, then yes, please file a separate bug. Each time I touch it, I make things worse. I'd prefer the regular maintainer fix it. If I missed something else, please let me know.
Hmm it seem quite similar to this bug: I attached a log of failing update. Note: I'm not using epel-next, just epel.
Created attachment 1972322 [details] Failed update on CentOS Stream 9 Failed update.
If you are using CentOS Stream 9, and you are using just the epel repository, then that is the problem. CentOS Stream 9 has an updated qt5. I have fixed the incompatible updates in epel9-next. You need to have both epel9 and epel9-next repo's enabled.
Ok, but does it mean that is not possible anymore to have KDE just using epel repo? Or it's a matter of waiting for fixes?
(In reply to Massimiliano from comment #19) > Ok, but does it mean that is not possible anymore to have KDE just using > epel repo? I don't understand the "anymore" in your question. If you are running CentOS Stream, you should enable both epel and epel-next. It has ALWAYS been this way. > Or it's a matter of waiting for fixes? Yes, you can wait it out. In six months (when RHEL 9.3 is released with the updated qt5) the KDE changes in epel-next 9 will be put into regular epel 9. Why do you not want to enable epel-next? I'm curious if there is something we've done or are doing that would make you not want to enable it.
(In reply to Troy Dawson from comment #20) > I don't understand the "anymore" in your question. > If you are running CentOS Stream, you should enable both epel and epel-next. Yes, I know I can enable both. The instance that now is broken was built using just epel. What I meant is: is still possible to build a CentOS Stream KDE live by using epel only? > > Or it's a matter of waiting for fixes? > Yes, you can wait it out. > In six months (when RHEL 9.3 is released with the updated qt5) the KDE > changes in epel-next 9 will be put into regular epel 9. > Copy that. > > Why do you not want to enable epel-next? > I'm curious if there is something we've done or are doing that would make > you not want to enable it. > Nothing special. AFAIK epel-next contains more recent features. CentOS represents for me a "peaceful OS", since Fedora is the innovative one. So I considered a good idea to use only the epel repo. But a point remains: right now is not possible to install Plasma/KDE using epel only, isn't it? And, at a certain day in the future (RHEL 9.3), it should be possible, isn't it? It's not clear for me if CentOS Stream KDE is supposed to be stable without epel-next.
(In reply to Massimiliano from comment #21) > But a point remains: right now is not possible to install Plasma/KDE using > epel only, isn't it? Correct > And, at a certain day in the future (RHEL 9.3), it should be possible, isn't > it? Correct > It's not clear for me if CentOS Stream KDE is supposed to be stable without > epel-next. Stability is a good point I hadn't thought of. epel-next is where I stage the next KDE Plasma Desktop update for epel. It get's KDE updated every couple of months, whenever it looks like a good time. Occasionally more frequently if there is an important feature/bug. I test it to make sure things install properly, expected features work, and what new dependencies are needed. So it depends on your definition of stability. If your definition of stability is that it will get the same amount of testing and bugs looked after, then yes. Possibly more testing, and I tend to jump on the bugs quite fast. If your definition of stability is that it only get's updated once every 6 months, then no, it is not stable. Thank you for bringing this up. Except for bugs, I don't get much feedback and I appreciate seeing your use case and concerns.
(In reply to Troy Dawson from comment #22) > So it depends on your definition of stability. Stability, I think not only for me, it's a statistic matter. Given the same repos (base + epel), the probability to get broken updates should be the same as GNOME. For an enterprise-class OS it should be very close to zero. A little bit more can be acceptable for Fedora. The opposite sounds strange to me. > Thank you for bringing this up. Except for bugs, I don't get much feedback and I appreciate seeing your use case and concerns. Honestly, I planned to abandon my CentOS remix, because the lack of RH support (#2029075) and a poor community. Things are changing, because of Flatpak. A solid KDE could be a good base for a workstation where to add apps (office, communication, browsers, multimedia, games and so on). But I doesn't seem to exist a clear goal/community about desktop usage for this OS.