akonadi-19.08.3 (whole kdepim doesnt work since update) I tried to rebuild database (delete ~/.local/share/akonadi/ ~/.config/akonadi/ ~/.config/akonadi*) Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) org.kde.pim.akonadiserver: Starting up the Akonadi Server... org.kde.pim.akonadiserver: database server stopped unexpectedly org.kde.pim.akonadiserver: Database process exited unexpectedly during initial connection! org.kde.pim.akonadiserver: executable: "/usr/sbin/mysqld" org.kde.pim.akonadiserver: arguments: ("--defaults-file=/home/USER/.local/share/akonadi/mysql.conf", "--datadir=/home/USER/.local/share/akonadi/db_data/", "--socket=/run/user/1000/akonadi/mysql.socket", "--pid-file=/run/user/1000/akonadi/mysql.pid") org.kde.pim.akonadiserver: stdout: "" org.kde.pim.akonadiserver: stderr: "" org.kde.pim.akonadiserver: exit code: 1 org.kde.pim.akonadiserver: process error: "Unknown error" mysqladmin: connect to server at 'localhost' failed error: 'Can't connect to local MySQL server through socket '/run/user/1000/akonadi/mysql.socket' (2)' Check that mysqld is running and that the socket: '/run/user/1000/akonadi/mysql.socket' exists! org.kde.pim.akonadiserver: Failed to remove runtime connection config file org.kde.pim.akonadiserver: Shutting down AkonadiServer... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadiserver' exited normally... reemerge akonadi* and qtsql with new mysql doesn't work =dev-db/mysql-8.0.19-r1 =dev-db/mysql-connector-c-8.0.19 =dev-db/mariadb-connector-c-3.1.6 in package.mask works with resetting (delete folders) akodai-files again. Now adding recources one by one...
REFERENCE: https://bugs.gentoo.org/709624#c2
Looks like you are not running a normal mysqld. Instead you are running an own instance for akonadi (I don't know akonadi). Make sure that this server configuration is compatible with MySQL v8. When mysqld starts, you will get some logs (normally in /var/log/mysql... but when using an own configuration like your do, see --defaults-file=... your path could be different, according to Google search, it maybe '~/.local/share/akonadi/db_data/mysql.err'). Hopefully the CFG is just incompatible and mysqld-8 rejects to start.
Completely deleting ~/.config/akonadi* and ~/.local/share/akonadi* : $ akonadictl start Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) org.kde.pim.akonadiserver: Starting up the Akonadi Server... 2020-02-16T15:48:58.722252Z 0 [Warning] [MY-010139] [Server] Changed limits: max_open_files: 1024 (requested 8161) 2020-02-16T15:48:58.722258Z 0 [Warning] [MY-010142] [Server] Changed limits: table_open_cache: 431 (requested 4000) 2020-02-16T15:48:58.722516Z 0 [System] [MY-013169] [Server] /usr/sbin/mysqld (mysqld 8.0.19) initializing of server in progress as process 2672 2020-02-16T15:49:02.642998Z 5 [Note] [MY-010454] [Server] A temporary password is generated for root@localhost: nihnvGb9##2H org.kde.pim.akonadiserver: database server stopped unexpectedly org.kde.pim.akonadiserver: Database process exited unexpectedly during initial connection! org.kde.pim.akonadiserver: executable: "/usr/sbin/mysqld" org.kde.pim.akonadiserver: arguments: ("--defaults-file=/home/manfred/.local/share/akonadi/mysql.conf", "--datadir=/home/manfred/.local/share/akonadi/db_data/", "--socket=/run/user/1111/akonadi/mysql.socket", "--pid-file=/run/user/1111/akonadi/mysql.pid") org.kde.pim.akonadiserver: stdout: "" org.kde.pim.akonadiserver: stderr: "" org.kde.pim.akonadiserver: exit code: 1 org.kde.pim.akonadiserver: process error: "Unknown error" mysqladmin: connect to server at 'localhost' failed error: 'Can't connect to local MySQL server through socket '/run/user/1111/akonadi/mysql.socket' (2)' Check that mysqld is running and that the socket: '/run/user/1111/akonadi/mysql.socket' exists! org.kde.pim.akonadiserver: Failed to remove runtime connection config file org.kde.pim.akonadiserver: Shutting down AkonadiServer... org.kde.pim.akonadicontrol: Application '/usr/bin/akonadiserver' exited normally... The error message is correct: $ lla /run/user/1111/akonadi/ <---! empty insgesamt 0 drwxr-xr-x 2 manfred manfred 40 16. Feb 11:56 . drwx------ 5 manfred manfred 140 16. Feb 11:40 .. Two of the files mentioned as arguments have not been created.
This doesn't help. Of course, in the end, akonadi will fail, because mysqld didn't start and therefore didn't create PID file or socket. The question is *why* did the mysql instance from akonadi fail to start? Two important things: Mysql-8 is a new major release. Some config options from previous versions are no longer valid and mysqld will reject to start when these parameters are present. The error log will tell you about that. I don't know what you mean with "I delete database". From my understanding, you cleaned akonadi's mysql data dir. If this is the case you can't just start mysql again. You will first have to re-initialize that data dir. I can't tell you how to to that. tl;dr Please find akonadi's mysqld error log and show us its content.
Created attachment 614034 [details] /home/manfred/.local/share/akonadi/mysql.conf ~/.local/share $ ll akonadi/mysql.conf akonadi/db_data/ -rw-r--r-- 1 manfred manfred 3,4K 16. Feb 16:48 akonadi/mysql.conf akonadi/db_data/: insgesamt 185M -rw-r----- 1 manfred manfred 56 16. Feb 16:49 auto.cnf -rw-r----- 1 manfred manfred 0 16. Feb 16:49 binlog.index -rw------- 1 manfred manfred 1,7K 16. Feb 16:49 ca-key.pem -rw-r--r-- 1 manfred manfred 1,1K 16. Feb 16:49 ca.pem -rw-r--r-- 1 manfred manfred 1,1K 16. Feb 16:49 client-cert.pem -rw------- 1 manfred manfred 1,7K 16. Feb 16:49 client-key.pem -rw-r----- 1 manfred manfred 5,7K 16. Feb 16:49 ib_buffer_pool -rw-r----- 1 manfred manfred 12M 16. Feb 16:49 ibdata1 -rw-r----- 1 manfred manfred 64M 16. Feb 16:49 ib_logfile0 -rw-r----- 1 manfred manfred 64M 16. Feb 16:49 ib_logfile1 drwxr-x--- 2 manfred manfred 4,0K 16. Feb 16:49 '#innodb_temp' drwxr-x--- 2 manfred manfred 4,0K 16. Feb 16:49 mysql -rw-r----- 1 manfred manfred 1,3K 16. Feb 16:49 mysql.err -rw-r----- 1 manfred manfred 24M 16. Feb 16:49 mysql.ibd drwxr-x--- 2 manfred manfred 4,0K 16. Feb 16:49 performance_schema -rw------- 1 manfred manfred 1,7K 16. Feb 16:49 private_key.pem -rw-r--r-- 1 manfred manfred 452 16. Feb 16:49 public_key.pem -rw-r--r-- 1 manfred manfred 1,1K 16. Feb 16:49 server-cert.pem -rw------- 1 manfred manfred 1,7K 16. Feb 16:49 server-key.pem drwxr-x--- 2 manfred manfred 4,0K 16. Feb 16:49 sys -rw-r----- 1 manfred manfred 10M 16. Feb 16:49 undo_001 -rw-r----- 1 manfred manfred 10M 16. Feb 16:49 undo_002
Created attachment 614036 [details] ~/.local/share/akonadi/db_data/mysql.err HTH: 2020-02-16T15:49:08.304474Z 1 [ERROR] [MY-011087] [Server] Different lower_case_table_names settings for server ('1') and data dictionary ('0'). 2020-02-16T15:49:08.304799Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed. 2020-02-16T15:49:08.305056Z 0 [ERROR] [MY-010119] [Server] Aborting
If you rely on lower_case_table_names, this option must be already set during initialization. It cannot be set afterwards, see https://bugs.mysql.com/bug.php?id=90814. Like said, I don't know akonadi but I would try to get rid of lower_case_table_names from mysql.conf if possible.
Is this a change in defaults by mysql or a remainder of a past workaround? For reference: https://bugs.kde.org/show_bug.cgi?id=409753#c4 https://bugs.kde.org/show_bug.cgi?id=409234 Supposedly fixed in: https://cgit.kde.org/akonadi.git/commit/?id=8b8db29d10b2ef92deb2d87ff613f3d7f39af34e
Mysql-8 is stricter. It will recognize that you didn't initialize data dir with this option set and therefore rejects to start. See the linked mysql bug: If you need that option, you must set it already during initialization. You cannot cahnge after initialization.
Created attachment 614068 [details] ~/.local/share/akonadi/db_data
(In reply to Luis Ferreira from comment #10) > Created attachment 614068 [details] > ~/.local/share/akonadi/db_data --> unknown variable 'log_warnings=2' Good point - missed that one
I'm using kde straight in gentoo since version 2. I did never set up a mysql-server. I am an mysql-auto-configuration-user. Introducing akonadi, kde started using mysql with an auto-configurated local instance. Upgrading a major version, I usually stop akonadi (akonadictl stop), upgrade kdepim and/or mysql and start akonadi again. If migration of akonadi/mysql data fails, the deletion of the akonadi-cache or in the end the whole reset (delete akonadi-files, see my first comment) should be sufficient. In my case it did fail too. Downgrade worked. My amateurish conclusion: akonadi-19.08.3 autoconfiguration of local mysqld-instance can't handle mysql-8 yet? As akonadi uses mysql for working with data, but not as a place the data itself, there is no real loss of data for me. But it is a (for a private user) hell of work to set it up all again...
(In reply to Stephan Karacson from comment #12) > ... akonadi-19.08.3 ... ..............^^.^^.^ [IP-] [ ] kde-apps/akonadi-19.12.2:5 et al. TEST: # grep mysql /etc/portage/package.mask >=dev-db/mysql-8.0.0:0 # 709812 --> Downgrade dev-db/mysql to [IP-] [ ] dev-db/mysql-5.7.29:0/18 Afterwards, a) starting kaddressbook works, including implicit akonadi start, but no entries show up as AdressBook Name entries. b) Confirming "/home/manfred/.local/share/contacts/" in AdressBook Properties dialog, stop KAddressBook c) start KAddressBook again: now entries show up as expected. RESUMEE: Observations fit to suspected causation. Thanks @ Thomas! (comment #7)
WORKAROUND: - disable ">=dev-db/mysql-8.0.0:0" package mask <--- in case you entered one - un-merge dev-db/mysql-5.7.29:0/18 <--- no need to unmerge -8.0.19-r1 !!! ONLY -if you have no separate db instances !!! - delete mysql data directory at '/var/lib/mysql' !!! ONLY -if you have no separate db instances !!! - emerge dev-db/mysql-8.0.19-r1:0 - emerge --config =dev-db/mysql-8.0.19-r1 - > select "caching_sha2_password" - > provide a password for the mysql 'root' user - rm -r ~/.config/akonadi* - rm -r ~/.local/share/akonadi* $ akonadictl start --verbose <--- this will fail, as expected, but <--- populize ~/.config/ and <--- populize ~/.local/share/ $ rm -r ~/.local/share/akonadi/db_data (or move it, for comparison) $ mkdir ~/.local/share/akonadi/db_data (empty, to be initialized) $ edit ~/.local/share/akonadi/mysql.conf : # log_warnings=2 # (unknown) lower_case_table_names=0 # (=1 does not work) # query_cache_size=0 # (unknown) # query_cache_type=0 # (unknown) $ akonadictl start --verbose <--- this time will start up and <--- thereby initialize the empty db_data a-new - start KAddressBook - end KAddressBook - start KAddressBook again - > enable your AdressBook <--- this time you should see your entries HTH.
(ADDENDUM to comment #14) > - emerge dev-db/mysql-8.0.19-r1:0 Of course, this is only needed if you had previously fallen back to -5.7.29; no need to re-emerge the identical package; just continue with the following "--config" step.
Currently I have to look having time to do this workaround. Seems I have to reorganize all akonadi-recources again. And I still not get why I have to configure mysql with a root-password, as akonadi makes its own and so there is no /var/lib/mysql (you see I'm no developer). Anyway this workaround seems to be a great help. Please tell me if I'm wrong, but you have to do this workaround every time akonadi is making a new db or clean it (for example after an broken upgrade of kdepim, a new install, a new kde-user...). I'm not from the gentoo-team, but current stable akonadi seems not to "initialize data dir with this option" (Thomas). So shouldn't akonadis ebuild depend on maximum mysql-5.7.x until it can handle the case?
(In reply to Stephan Karacson from comment #16) > Currently I have to look having time to do this workaround. Seems I have to > reorganize all akonadi-recources again. And I still not get why I have to > configure mysql with a root-password, as akonadi makes its own and so there > is no /var/lib/mysql (you see I'm no developer). Anyway this workaround > seems to be a great help. If akonadi really uses its own data dir, running `emerge --config dev-db/mysql` should be pointless. > I'm not from the gentoo-team, but current stable akonadi seems not to > "initialize data dir with this option" (Thomas). So shouldn't akonadis > ebuild depend on maximum mysql-5.7.x until it can handle the case? Sure, this is one way to handle this if akonadi can't be fixed to work with mysql-8.
(In reply to Stephan Karacson from comment #16) In WORKAROUND, my intention was to re-set to a "clean new (8.0) track" for other (non-akonadi) applications not to be limited by old (< 2003) initial setups. Anybody who is only interested in akonadi should feel free to simply mask >=8.0 as already demonstrated / tested in my earlier comment #13. Please, grant the KDE team sufficient time to sort things out properly; e.g. @ Andreas: Any fallout to be expected when adding restrictions into an akonadi-19.12.2-r1.ebuild (RDEPEND: lines 63..64), esp. for those who have already run the update, then forcibly being switched back to mysql-5.7 again? Currently, here on x86_64: # equery list -p virtual/mysql [-P-] [ ~] virtual/mysql-5.5-r2:0 [IP-] [ ] virtual/mysql-5.6-r13:0/18 <--- # grep "mysql-\${PV}" /usr/portage/virtual/mysql/mysql*.ebuild .../mysql-5.5-r2.ebuild: =dev-db/mysql-${PV}*[static?,static-libs(-)?] .../mysql-5.6-r13.ebuild: >=dev-db/mysql-${PV}[embedded(-)?,server?,static(-)?] <--- .....^..... @ Thomas: Would it make sense to limit virtual/mysql-5.6-r13:0/18 and to introduce a new virtual/mysql-8.0 ?
For me, mysql.err indicated that content of /etc/xdg/akonadi/mysql-global.conf was used, and some of its obsolete flags were regarded as fatal error now by mysql. By uncommenting those three flag below #log_warnings=2 #query_cache_size=0 #query_cache_type=0 and restarting with "akonadictl start", all was working again. This seems simpler than previous comment 14, particularly if no .local conf files exists, i.e. if the /etc/xdg/akonadi/mysql-global*.conf templates are used. According to "equery belongs", those files are installed by "kde-apps/akonadi-19.2.2". For testing, also deleted the original etc files and reinstalled "kde-apps/akonadi", hoping for an upstream version with mysql8 support, but they are still insufficient. Would be interesting if this simple three line patch works also for others, because could also be applied as patch on "kde-apps/akonadi". But safest obviously is to avoid mysql8 and wait for akonadi upstream fix.
Anybody reporting this as an upstream bug in Akonadi? Because that's what it is. Akonadi should detect the mysql version and not put this stuff in the config.
It should also block https://bugs.gentoo.org/709812, because mysqld 8 effectively breaks akonadi.
(In reply to Victor Mataré from comment #20) > Anybody reporting this as an upstream bug in Akonadi? Because that's what it > is. Akonadi should detect the mysql version and not put this stuff in the > config. Please do, I haven't had time for it nor use the mysql backend.
I'm sorry for the late response, but as the situation on my job needed more focus in the last weeks/month I reported it today upstream: https://bugs.kde.org/show_bug.cgi?id=421922
A Problem raised. mysql-connector-c prior to 8 removed from portage so an upgrade to incompatible mysql 8 is going to be forced. Does akonadi support an local-user-auto-config-mariadb-instance? Akonady-ebuild seems to just provice useflags for mysql, sqlite and postgresql. Sqlite is not recommend by upstream, is postgresql running configless? What is the default option for the desktop-users? The currend default: mysql 8 seems to be still broken. Any way to hold on dev-db/mysql-connector-c 6.1.11-r2 until upstream resolved?
Hannes Schweizer has attached an patch on bugs.kde.org with the workarounds likewise your suggestions on the mysql-global.conf which seems to be the main config file for local mysql instance. At least it works now, but it doesn't seem to become an official upstream solution. https://bugs.kde.org/show_bug.cgi?id=421922#c5
Well, I said that this is an upstream bug but now I'm not so sure any more: The problem lies with the config template in /etc/xdg/akonadi/mysql-global.conf, which is shipped with the ebuild. Sure, if that file is from the akonadi source distribution, it should be fixed upstream but if it's added by Gentoo packaging, it's a Gentoo issue. So which is it?
Why do you think it comes from Gentoo packaging? https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-apps/akonadi/akonadi-20.08.1.ebuild
Created attachment 664570 [details, diff] patch against source package This patch removes the illegal config values from the config template. We should be able to just apply it unconditionally in the ebuild since older mysql versions have long been removed from portage. Btw, seems to me this broke the entire Akonadi even for stable users, for several months now. Is that correct? Oh and one more thing: I'm not sure when this template is actually copied over to ~/.local/akonadi. So while the patch might prevent further breakage, I'm not sure it'll fix Akonadi for people who already have a broken ~/.local/akonadi/mysql.conf...
I've seen a similar patch in linked bug, but upstream says it might break mariadb - can you confirm it does indeed not break mariadb and communicate with them?
After recent *stable* updates, problem still persists: # equery list akonadi* [IP-] [ ] kde-apps/akonadi-20.08.3:5 # equery list dev-db/mysql [IP-] [ ] dev-db/mysql-8.0.21-r1:8.0 CONFIRMATION: same WORKAROUND still applies: A) patch /etc/xdg/akonadi/mysql-global.conf # diff mysql-global.conf-20.08.3____ORIG mysql-global.conf 65c65 < log_warnings=2 --- > #log_warnings=2 80c80 < query_cache_size=0 --- > #query_cache_size=0 83c83 < query_cache_type=0 --- > #query_cache_type=0 Before that, I also completely removed ~/.local/share/akonadi* ; now I can't test anymore if that was really necessary. B) kaddressbook: Re-start a second time, then it will load the contents of /home/manfred/.local/share/contacts/
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/kde.git/commit/?id=6b90510ab328d1bdbba167d9ccd4c6ba0cb4bfed commit 6b90510ab328d1bdbba167d9ccd4c6ba0cb4bfed Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2020-12-25 21:36:01 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2020-12-25 21:41:15 +0000 kde-apps/akonadi: Switch QMYSQL from virtual/mysql -> dev-db/mariadb Bug: https://bugs.gentoo.org/709812 Package-Manager: Portage-3.0.12, Repoman-3.0.2 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> kde-apps/akonadi/akonadi-20.12.49.9999.ebuild | 30 +++++++++++++++++---------- kde-apps/akonadi/akonadi-9999.ebuild | 30 +++++++++++++++++---------- kde-apps/akonadi/metadata.xml | 1 + 3 files changed, 39 insertions(+), 22 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=33860f6df4062a2f19b2e526bee582daec437df7 commit 33860f6df4062a2f19b2e526bee582daec437df7 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2021-01-07 12:57:52 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2021-01-07 17:28:38 +0000 kde-apps/akonadi: 20.12.1 version bump Bug: https://bugs.gentoo.org/709812 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> kde-apps/akonadi/Manifest | 1 + kde-apps/akonadi/akonadi-20.12.1.ebuild | 138 ++++++++++++++++++++++++++++++++ kde-apps/akonadi/metadata.xml | 1 + 3 files changed, 140 insertions(+)
Well, completely ditching mysql support for mariadb is a bit of a sledgehammer approach now, isn't it? @asturm I can totally understand you're fed up with this mess. I'm sorry but I simply don't have the time to switch back and forth between mysql and mariadb all the time so I can't experimentally confirm that my patch works with mariadb as well. What I can say is that it only *removes* values from the config, thus reverting them back to the defaults, and those values deal with logging and caching. So yes, I'm VERY CONFIDENT that it'll work with mariadb, too. I'm also quite positive that it will cause significantly less disruption than forcing everyone to switch from mysql to mariadb. So please bring back the mysql USE-flag and apply the patch? I'm sure the unstable akonadi users are a hardy bunch and we'll know quickly that it turned out fine ;-)
Oh, important detail I forgot: The patch they have upstream changes the settings instead of removing them, so that's why it may break things while the patch we have here won't. Thinking of it, I should probably tell them that ;-)
Resurrection: Same problems again with -20.12.2 Culprit: . . . . . . . . /etc/xdg/akonadi/mysql-global.conf containing . . . . . . . . log_warnings=2 . . . . . . . . query_cache_size=0 . . . . . . . . query_cache_type=0 # equery belongs /etc/xdg/akonadi/mysql-global.conf . . . . . . . . kde-apps/akonadi-20.12.2 (In reply to Victor Mataré from comment #33) > So please bring back the mysql USE-flag and apply the patch + 1 Hint: Again: re-start kaddressbook a second time
It is rather a waste of time to duplicate logs of known issues.
(In reply to Andreas Sturmlechner from comment #36) > It is rather a waste of time to duplicate logs of known issues. ....................................................^^^^^ SORRY if I missed something - definitely did not want to create unnecessary noise; but AFAIK, - we were talking about -20.08.3 up to -20.12.1 - your commits were supposed to have fixed the issue? Help to understanding welcome. Regards
It works with mariadb, you are unsupported if using mysql.
(In reply to Andreas Sturmlechner from comment #38) > It works with mariadb, you are unsupported if using mysql. That's exactly what puzzles me: I have *not* explicitly set any preference! # emerge -pv akonadi kaddressbook [ebuild R ~] kde-apps/akonadi-20.12.2:5::gentoo USE="kaccounts mariadb xml -debug -designer -postgres -sqlite -test -tools" ..................^^^^^^^ [ebuild R ~] kde-apps/kaddressbook-20.12.2:5::gentoo USE="-debug -handbook -telemetry -test"
As mentioned above there was no downstream fix to mysql-global.conf and there will not be one without upstream finding a solution, we can only enforce dependencies. If you reproduce that problem with dev-db/mariadb installed, and your akonadi configuration pointing to a mariadb instance, that's relevant, and the version is relevant. There must be a difference between running mysqld or an external mariadb/mysql instance, or else I don't know what. What we could not influence so far was what dev-qt/qtsql[mysql] was linking with - here's an effort to introduce IUSE=mariadb on it: https://github.com/gentoo/qt/pull/234 If you want to test it, then copy it to your local overlay and `USE=mariadb emerge --nodeps -1 qtsql` and see if it makes a difference.
Please check out the newly linked MR in the referenced KDE bug and test it with your MySQL instances. I can only confirm that it does not break MariaDB.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8b744749e2562e7593b07b93c018d4e6cbd51986 commit 8b744749e2562e7593b07b93c018d4e6cbd51986 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2021-02-16 22:25:09 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2021-02-16 22:35:25 +0000 kde-apps/akonadi: Switch back mariadb -> mysql, use 'loose_' options This is reverting commit 6b90510a (kde overlay), instead trying to fix MySQL server settings while keeping MariaDB settings intact. KDE-Bug: https://bugs.kde.org/show_bug.cgi?id=421922 Reported-by: Stephan Karacson <stkaopen@gmx.at> Thanks-to: Victor Mataré <vmatare+gbug@posteo.de> Thanks-to: Thomas Deutschmann <whissi@gentoo.org> Bug: https://bugs.gentoo.org/709812 Package-Manager: Portage-3.0.14, Repoman-3.0.2 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> kde-apps/akonadi/akonadi-20.12.2-r1.ebuild | 39 +++++------ .../files/akonadi-20.12.2-mysql8-conf.patch | 75 ++++++++++++++++++++++ 2 files changed, 92 insertions(+), 22 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/kde.git/commit/?id=b555756d45fff488bc600669bb655aa027b89bb8 commit b555756d45fff488bc600669bb655aa027b89bb8 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2021-02-16 22:25:09 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2021-02-16 22:47:30 +0000 kde-apps/akonadi: Switch back IUSE=mariadb -> mysql This is reverting commit 6b90510a (kde overlay), fix is already upstream. Upstream commit: 9c666d0d6039a87f6286014c7d9c7281a5bd9dd1 KDE-Bug: https://bugs.kde.org/show_bug.cgi?id=421922 Reported-by: Stephan Karacson <stkaopen@gmx.at> Thanks-to: Victor Mataré <vmatare+gbug@posteo.de> Thanks-to: Thomas Deutschmann <whissi@gentoo.org> Bug: https://bugs.gentoo.org/709812 Package-Manager: Portage-3.0.14, Repoman-3.0.2 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> kde-apps/akonadi/akonadi-20.12.49.9999.ebuild | 34 ++++++++++----------------- kde-apps/akonadi/akonadi-9999.ebuild | 34 ++++++++++----------------- kde-apps/akonadi/metadata.xml | 1 - 3 files changed, 26 insertions(+), 43 deletions(-)
Okay, I'll close this as it is fixed upstream hopefully for good. Thanks to everyone who reported here and helped figure out the problematic config keys.
kde-apps/akonadi-20.12.2-r1 works just fine with default supplied mysql-config (just one akonadi-cleanout was needed first) Thank you all for resolve and great expertise! I would never have this level of SQL.
