Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 749777 - sys-apps/portage: kde-frameworks/kitemviews-5.74.0 rebuilt before qtgui upgrade
Summary: sys-apps/portage: kde-frameworks/kitemviews-5.74.0 rebuilt before qtgui upgrade
Status: RESOLVED DUPLICATE of bug 199856
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 751766 (view as bug list)
Depends on: 199856
Blocks: build-order
  Show dependency tree
 
Reported: 2020-10-17 16:11 UTC by Pavel Cernohorsky
Modified: 2021-11-26 18:04 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Logs from the update session when kitemviews failed (emerge.log,148.18 KB, text/x-log)
2020-10-19 17:44 UTC, Pavel Cernohorsky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Cernohorsky 2020-10-17 16:11:59 UTC
The compilation fails with
```
/var/tmp/portage/kde-frameworks/kitemviews-5.74.0/work/kitemviews-5.74.0/src/kwidgetitemdelegatepool.cpp:198:43: error: ‘class QTabletEvent’ has no member named ‘deviceType’; did you mean ‘device’?
  198 |                              tabletEvent->deviceType(),
      |                                           ^~~~~~~~~~
      |                                           device
```

The above mentioned indicates that the code tries to use API which has been added to QT 5.15 (see changes here https://codereview.qt.nokia.com/c/qt/qtbase/+/290694). QT 5.14 does not have any `deviceType`, thus package cannot compile.
Comment 1 Andreas Sturmlechner gentoo-dev 2020-10-17 16:25:34 UTC
Your output indicates you have mixed Qt 5.14.2/5.15.1 installation which is going to lead to all kinds of trouble.
Comment 2 Pavel Cernohorsky 2020-10-17 16:38:35 UTC
Yes, I have mixed installation, because my update failed in the middle because of the wrong QTMIN in the ebuild file...

Emerge cannot calculate correct order to first fully update to 5.15 when there is incorrect dependency. When you are updating system from 5.14, it can calculate order where kitemviews will be updated earlier than qtgui to 5.15.

The newer ebuild kitemviews-5.75.0 suffers from the same problem, by the way...
Comment 3 Andreas Sturmlechner gentoo-dev 2020-10-17 16:39:42 UTC
(In reply to Pavel Cernohorsky from comment #2)
> Yes, I have mixed installation, because my update failed in the middle
> because of the wrong QTMIN in the ebuild file...
Your assumption is wrong.
Comment 4 Pavel Cernohorsky 2020-10-17 16:47:54 UTC
Then how did my `emerge --update --newuse --with-bdeps=y --deep --ask --changed-use @world` failed? It actually tried to update `kitemviews-5.70.0` -> `5.74.0` before `qtgui-5.14.2-r1` -> `5.15.1-r1`. Based on what you are saying that my assumption is wrong? It actually did it... it and it failed... and based on the link I posted, it is clear that `kitemviews-5.74.0` can never ever compile with Qt `5.14.2`, so, why to close obvious bug without solving it?
Comment 5 Andreas Sturmlechner gentoo-dev 2020-10-17 17:04:44 UTC
I happen to be KDE proj member and as such you can trust me that KDE Frameworks minimum Qt dependency will be *5.12* for the better part of even 2021. But you can easily look that up yourself.

Your problem is caused by Portage letting kitemviews come up in the upgrade queue after dev-qt/qtcore-5.15.1 but before dev-qt/qtgui-5.15.1. As a result, #ifdef condition in kitemviews for >=Qt-5.15 strikes true while the conditional code it enables is bound to fail with still installed <dev-qt/qtgui-5.15.

Now, kde-frameworks/kitemviews properly depends on >=dev-qt/qtgui-5.14.2 and dev-qt/qtgui properly has a slot operator on dev-qt/qtcore to be triggered for rebuild, but Portage has no concept of upgrade A breaking B then package C depending on B will be broken; it will happily sometimes queue A, C, B. That's what happened to you. Somewhere in Gentoo bugzie there's a bug about that...
Comment 6 Pavel Cernohorsky 2020-10-17 17:29:13 UTC
(In reply to Andreas Sturmlechner from comment #5)
...
> Now, kde-frameworks/kitemviews properly depends on >=dev-qt/qtgui-5.14.2 and
> dev-qt/qtgui properly has a slot operator on dev-qt/qtcore to be triggered
> for rebuild, but Portage has no concept of upgrade A breaking B then package
> C depending on B will be broken; it will happily sometimes queue A, C, B.
> That's what happened to you. Somewhere in Gentoo bugzie there's a bug about
> that...

Thank you very much for explanation. Now it makes sense. Didn't know about this "feature" of Portage. If somebody encounters this bug in the future same as I did, what helped me was manual oneshot update of all the not yet updated qt packages...
Comment 7 Andreas Sturmlechner gentoo-dev 2020-10-17 18:24:36 UTC
Since Qt 5.15 is the last in the series that problem shouldn't happen again that soon, at least in this context.
Comment 8 Zac Medico gentoo-dev 2020-10-19 04:21:41 UTC
(In reply to Pavel Cernohorsky from comment #4)
> Then how did my `emerge --update --newuse --with-bdeps=y --deep --ask
> --changed-use @world` failed? It actually tried to update
> `kitemviews-5.70.0` -> `5.74.0` before `qtgui-5.14.2-r1` -> `5.15.1-r1`.
> Based on what you are saying that my assumption is wrong? It actually did
> it... it and it failed... and based on the link I posted, it is clear that
> `kitemviews-5.74.0` can never ever compile with Qt `5.14.2`, so, why to
> close obvious bug without solving it?

Could you attach the portion of your /var/log/emerge.log from that emerge session?
Comment 9 Pavel Cernohorsky 2020-10-19 17:44:39 UTC
Created attachment 667151 [details]
Logs from the update session when kitemviews failed

Hello, I am attaching the relevant part of the emerge log, specifically log from the update session which ended up with the failure. My whole emerge.log is too big, even compressed. If you need some bigger portion, let me know.

The exact update command was actually `emerge --update --deep --reinstall=changed-use --regex-search-auto=y --verbose @world` as you can see there, not the one I posted above, that one I took just from my bash history and probably it was one of my other attempts to fix the problem.
Comment 10 Zac Medico gentoo-dev 2020-10-19 18:18:10 UTC
(In reply to Pavel Cernohorsky from comment #9)
> Created attachment 667151 [details]
> Logs from the update session when kitemviews failed
> 
> Hello, I am attaching the relevant part of the emerge log, specifically log
> from the update session which ended up with the failure. My whole emerge.log
> is too big, even compressed. If you need some bigger portion, let me know.
> 
> The exact update command was actually `emerge --update --deep
> --reinstall=changed-use --regex-search-auto=y --verbose @world` as you can
> see there, not the one I posted above, that one I took just from my bash
> history and probably it was one of my other attempts to fix the problem.

Thanks. This confirms that it's the same issue as bug 199856. There must be some kind of circular dependencies involved in this.

*** This bug has been marked as a duplicate of bug 199856 ***
Comment 11 Andreas Sturmlechner gentoo-dev 2020-10-20 11:48:06 UTC
(In reply to Zac Medico from comment #10)
> There must be some kind of circular dependencies involved in this.
Not sure how to interpret that. At least kde-frameworks/kitemviews does not depend on any other kde-frameworks/* package (exceptions are only runtime-relevant kf-env-5 and only build-time relevant extra-cmake-modules that does exactly what it says). And certainly, no single dev-qt/* package depends on kde-frameworks.

One observation is that this became more of an issue after revdeps of e.g. kde-frameworks/kitemviews got slot operators on dev-qt/qt{core,gui,widgets} and as a result it came up earlier in the queue.
Comment 12 Zac Medico gentoo-dev 2020-10-20 22:06:18 UTC
(In reply to Andreas Sturmlechner from comment #11)
> (In reply to Zac Medico from comment #10)
> > There must be some kind of circular dependencies involved in this.
> Not sure how to interpret that. At least kde-frameworks/kitemviews does not
> depend on any other kde-frameworks/* package (exceptions are only
> runtime-relevant kf-env-5 and only build-time relevant extra-cmake-modules
> that does exactly what it says). And certainly, no single dev-qt/* package
> depends on kde-frameworks.

In order to trigger bug 199856, it's enough for qtgui or one of it's dependencies to be involved in a circular dependency. It causes the build planner to delay merge of anything in the cycle, and it searches desperately for something that it can merge. In this case it decided to merge kde-frameworks/kitemviews because the 
>=dev-qt/qtgui-5.14.2:5 dependency was seemingly installed (though we know it was broken and that's bug 199856).

> One observation is that this became more of an issue after revdeps of e.g.
> kde-frameworks/kitemviews got slot operators on dev-qt/qt{core,gui,widgets}
> and as a result it came up earlier in the queue.

Slot operator deps are given higher priority than non-slot-operator deps, and since kde-frameworks/kitemviews doesn't have a slot operator dep on qtgui, it's given less priority and therefore more likely to be merged prematurely and trigger bug 199856.
Comment 13 Richard Ash 2020-10-27 15:33:05 UTC
Just a comment to note that because the affected package name is not mentioned in the bug this is closed as a duplicate of, it's not possible to find this bug (or any help) without resorting to advanced search on bugzilla. This is hitting amd64 stable who got QT 5.14 and KDE 5.74 recently, both packages are in the same world update and so a compile error with no obvious way round.
emerge --resume --skipfirst can't continue because of slotted version dependencies (logical enough) but these also make it impossible to one-shot anything to break the ordering issue (not least because portage keeps trying to re-install KDE 5.70* and complaining the ebuilds are not available. There does not seem to be a way to globally tell it to upgrade to the current stable KDE).

Is sudo emerge -av1 --nodeps =dev-qt/qtgui-5.15.1-r1 really the only way out of this hole, and if so how would I know to do that?
Comment 14 Zac Medico gentoo-dev 2020-10-27 19:25:32 UTC
(In reply to Richard Ash from comment #13)
> Just a comment to note that because the affected package name is not
> mentioned in the bug this is closed as a duplicate of, it's not possible to
> find this bug (or any help) without resorting to advanced search on
> bugzilla. This is hitting amd64 stable who got QT 5.14 and KDE 5.74
> recently, both packages are in the same world update and so a compile error
> with no obvious way round.
> emerge --resume --skipfirst can't continue because of slotted version
> dependencies (logical enough) but these also make it impossible to one-shot
> anything to break the ordering issue (not least because portage keeps trying
> to re-install KDE 5.70* and complaining the ebuilds are not available. There
> does not seem to be a way to globally tell it to upgrade to the current
> stable KDE).

I recommend to repeat whatever world update command you would normally use, something like emerge -uD @world.

> Is sudo emerge -av1 --nodeps =dev-qt/qtgui-5.15.1-r1 really the only way out
> of this hole, and if so how would I know to do that?

Alternatively, you could emerge --unmerge qtgui. I've re-opened this bug so that it will more easily show in search results.
Comment 15 Richard Ash 2020-10-28 10:14:31 UTC
(In reply to Zac Medico from comment #14)
> (In reply to Richard Ash from comment #13)
> > emerge --resume --skipfirst can't continue because of slotted version
> > dependencies (logical enough) but these also make it impossible to one-shot
> > anything to break the ordering issue (not least because portage keeps trying
> > to re-install KDE 5.70* and complaining the ebuilds are not available. There
> > does not seem to be a way to globally tell it to upgrade to the current
> > stable KDE).
> 
> I recommend to repeat whatever world update command you would normally use,
> something like emerge -uD @world.

That definitely didn't work, because kitemviews came to the front of the emerge list (ahead of qtgui) every time I tried it, so no progress.
 
> > Is sudo emerge -av1 --nodeps =dev-qt/qtgui-5.15.1-r1 really the only way out
> > of this hole, and if so how would I know to do that?
> 
> Alternatively, you could emerge --unmerge qtgui.
Ah, --unmerge rather than --depclean - much the same effect and --nodeps --oneshot. You have to switch off dependency resolution in order to force the order to not be the one Portage generates. I wish I'd realised that earlier!

> I've re-opened this bug so
> that it will more easily show in search results.
Thank you.
Comment 16 Andreas Sturmlechner gentoo-dev 2020-10-29 17:28:34 UTC
*** Bug 751766 has been marked as a duplicate of this bug. ***
Comment 17 Larry the Git Cow gentoo-dev 2020-10-30 11:36:01 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d4e2b952c7451abe3e073ea1b4df4dd496ba0126

commit d4e2b952c7451abe3e073ea1b4df4dd496ba0126
Author:     Andreas Sturmlechner <asturm@gentoo.org>
AuthorDate: 2020-10-30 11:24:44 +0000
Commit:     Andreas Sturmlechner <asturm@gentoo.org>
CommitDate: 2020-10-30 11:35:35 +0000

    kde-frameworks: Try to help remaining users over Qt 5.15.1 upgrade
    
    Qt <5.15 versions are gone from Gentoo ebuild repo so we can do this.
    
    - New baseline QTMIN=5.15.1, bumping packages w/ slot op (+ KF5ItemViews):
      kde-frameworks/frameworkintegration
      kde-frameworks/kdeclarative
      kde-frameworks/kio
      kde-frameworks/kitemviews
      kde-frameworks/kxmlgui
      kde-frameworks/qqc2-desktop-style
    - Cleanup obsolete slot ops where possible
    
    Bug: https://bugs.gentoo.org/749777
    Package-Manager: Portage-3.0.8, Repoman-3.0.2
    Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>

 ...tegration-5.74.0.ebuild => frameworkintegration-5.74.0-r1.ebuild} | 5 ++---
 .../{kdeclarative-5.74.0-r1.ebuild => kdeclarative-5.74.0-r2.ebuild} | 5 ++---
 kde-frameworks/kio/{kio-5.74.1-r1.ebuild => kio-5.74.1-r2.ebuild}    | 5 ++---
 .../{kitemviews-5.74.0.ebuild => kitemviews-5.74.0-r1.ebuild}        | 2 +-
 .../kxmlgui/{kxmlgui-5.74.0-r1.ebuild => kxmlgui-5.74.0-r2.ebuild}   | 2 +-
 ...op-style-5.74.0-r1.ebuild => qqc2-desktop-style-5.74.0-r2.ebuild} | 2 +-
 6 files changed, 9 insertions(+), 12 deletions(-)
Comment 18 Larry the Git Cow gentoo-dev 2020-11-11 21:57:59 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2df910a26c4c00533b9681cab35ebfee625ea34e

commit 2df910a26c4c00533b9681cab35ebfee625ea34e
Author:     Andreas Sturmlechner <asturm@gentoo.org>
AuthorDate: 2020-11-11 21:56:54 +0000
Commit:     Andreas Sturmlechner <asturm@gentoo.org>
CommitDate: 2020-11-11 21:57:42 +0000

    kde-frameworks/kwidgetsaddons: One more attempt to aid Qt 5.15.1 upgrade
    
    Bug: https://bugs.gentoo.org/749777
    Package-Manager: Portage-3.0.9, Repoman-3.0.2
    Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>

 .../{kwidgetsaddons-5.74.0.ebuild => kwidgetsaddons-5.74.0-r1.ebuild}   | 2 +-
 .../{kwidgetsaddons-5.75.0.ebuild => kwidgetsaddons-5.75.0-r1.ebuild}   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
Comment 19 Mike Gilbert gentoo-dev 2021-11-26 18:04:39 UTC

*** This bug has been marked as a duplicate of bug 199856 ***