Bug 2193111

Summary: Dependencies broken for updating qt5-qtbase from 5.15.3-1 to 5.15.3-2
Product: Red Hat Enterprise Linux 9 Reporter: Dr. Stephan Wonczak <wonczak>
Component: qt5-qtbaseAssignee: Troy Dawson <tdawson>
Status: CLOSED CURRENTRELEASE QA Contact: Tomas Pelka <tpelka>
Severity: medium Docs Contact:
Priority: unspecified    
Version: CentOS StreamCC: bstinson, ggr.seaton, jwboyer, massi.ergosum, tpelka
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-05-22 13:39:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
output of "dnf update --nobest"
none
Failed update on CentOS Stream 9 none

Description Dr. Stephan Wonczak 2023-05-04 11:15:41 UTC 
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.
Comment 1 Jan Grulich 2023-05-04 11:36:41 UTC 
We have updated Qt to 5.15.9 in CentOS Stream 9 so some of the packages will need to be rebuild.
Comment 2 Dr. Stephan Wonczak 2023-05-04 12:06:07 UTC 
(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.
Comment 3 Troy Dawson 2023-05-04 13:24:27 UTC 
I'm working on rebuilding all of KDE on epel9-next, but it is not going to be finished until next week sometime.
Comment 4 Dr. Stephan Wonczak 2023-05-04 15:18:51 UTC 
(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.
Comment 5 Dr. Stephan Wonczak 2023-05-12 09:22:55 UTC 
(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
Comment 6 Dr. Stephan Wonczak 2023-05-16 08:54:41 UTC 
Created attachment 1964853 [details]
output of "dnf update --nobest"
Comment 7 Dr. Stephan Wonczak 2023-05-16 13:49:08 UTC 
Updates of qt5 (and parts of kf5) are still broken.
For better debugging I attached the output of "dnf update --nobest" to this case.
Comment 8 Troy Dawson 2023-05-17 16:00:13 UTC 
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.
Comment 9 Dr. Stephan Wonczak 2023-05-19 12:46:04 UTC 
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.
Comment 10 Troy Dawson 2023-05-19 13:31:47 UTC 
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
Comment 11 Massimiliano 2023-05-20 11:31:52 UTC 
(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
Comment 12 Dr. Stephan Wonczak 2023-05-22 10:56:29 UTC 
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!
Comment 13 Troy Dawson 2023-05-22 13:38:59 UTC 
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.
Comment 14 Massimiliano 2023-06-23 15:41:14 UTC 
Hello,
CentOS Stream 9 is still broken. Do we need to file another bug?
Comment 15 Troy Dawson 2023-06-23 16:10:46 UTC 
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.
Comment 16 Massimiliano 2023-06-23 21:27:11 UTC 
Hmm it seem quite similar to this bug: I attached a log of failing update.
Note: I'm not using epel-next, just epel.
Comment 17 Massimiliano 2023-06-23 21:29:21 UTC 
Created attachment 1972322 [details]
Failed update on CentOS Stream 9

Failed update.
Comment 18 Troy Dawson 2023-06-23 21:34:55 UTC 
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.
Comment 19 Massimiliano 2023-06-25 16:09:18 UTC 
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?
Comment 20 Troy Dawson 2023-06-26 13:15:03 UTC 
(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.
Comment 21 Massimiliano 2023-06-26 16:57:38 UTC 
(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.
Comment 22 Troy Dawson 2023-06-30 13:34:49 UTC 
(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.
Comment 23 Massimiliano 2023-07-02 13:22:59 UTC 
(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.