In my stable system with kde-plasma/*, kde-frameworks/*, kde-apps/* and dev-qt/* in package.accept_keywords after update of qt-5.9.3 akonadi crash all the time in a loop. With a simple rebuild of akonadi the problem will be solved. This happend in my two system with similar configurations. Reproducible: Always
Created attachment 507052 [details] emerge-info.txt
I'm not sure what we can do here, may have been caused by an unfortunate order of toolchain/frameworks/Qt/deps as I personally haven't seen such crashes.
Did you upgrade from Qt-5.7.1 or Qt-5.9.2?
(In reply to Andreas Sturmlechner from comment #3) > Did you upgrade from Qt-5.7.1 or Qt-5.9.2? No, I updated from 5.9.2 to 5.9.3
Which akonadi backend did you choose?
(In reply to Andreas Sturmlechner from comment #5) > Which akonadi backend did you choose? sqlite3 is my backend
Which is probably the explanation. akonadi ships with a forked sqlite driver that uses private Qt API and may break at any Qt upgrade. There is no obvious fix except to keep that in mind. I don't know what else to do than stable masking sqlite (or trying to, once again), a backend that is half-broken anyway.
Same problem when update from 5.9.3 to 5.9.4
@qt, I don't suppose we can get something like SLOT="5/${PN}" for qtsql?
(In reply to Andreas Sturmlechner from comment #9) > @qt, I don't suppose we can get something like SLOT="5/${PN}" for qtsql? *PV of course...
Same problem when update from 5.10.0 to 5.10.1 Reinstall akonadi solves the problem.
(In reply to Andreas Sturmlechner from comment #9) > @qt, I don't suppose we can get something like SLOT="5/${PV}" for qtsql? Technically, that wouldn't be incorrect, since the private API/ABI can break at any time, including patch releases. It could result in unnecessary rebuilds, but as long as reverse deps use ":=" only where it's really necessary, I don't see a big problem. We can adopt the new subslot starting with 5.10.x. @kensington, any concerns?
And I would do the same for all qt modules, not just qtsql.
(In reply to Davide Pesavento from comment #13) > And I would do the same for all qt modules, not just qtsql. If we do this for all modules, we will definitely introduce unnecessary rebuilds because there's revdeps currently using the 5.x subslot to handle stuff like #if QT_VERSION >= QT_VERSION_CHECK(5, 7, 0)
I would only do this for QtSql, so far it is the only confirmed regular cause of issues (for akonadi[sqlite] at least).
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=db775da0c9c6b9b1cd336680772d71730ed1032d commit db775da0c9c6b9b1cd336680772d71730ed1032d Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2018-07-06 20:51:30 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2018-07-12 09:59:31 +0000 kde-apps/akonadi: Rebuild on dev-qt/qtsql[mysql] version bump Closes: https://bugs.gentoo.org/639140 Package-Manager: Portage-2.3.41, Repoman-2.3.9 kde-apps/akonadi/akonadi-18.04.2.ebuild | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad4b44faa018a11241f9661e803d0962ee10c398 commit ad4b44faa018a11241f9661e803d0962ee10c398 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2018-07-06 20:45:54 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2018-07-12 09:59:30 +0000 dev-qt/qtsql: Use full version subslot Bug: https://bugs.gentoo.org/639140 Package-Manager: Portage-2.3.41, Repoman-2.3.9 dev-qt/qtsql/qtsql-5.11.1-r1.ebuild | 58 ++++++++++++++++++++++++++++++++++ dev-qt/qtsql/qtsql-5.9.6-r1.ebuild | 63 +++++++++++++++++++++++++++++++++++++ 2 files changed, 121 insertions(+)
