Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 542768 - digikam and akonadi do not start with internal mysql database. Their conf uses obsolete system variables
Summary: digikam and akonadi do not start with internal mysql database. Their conf us...
Status: RESOLVED WORKSFORME
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] KDE (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo KDE team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-09 23:09 UTC by Paul Gover
Modified: 2015-06-26 22:08 UTC (History)
0 users

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


Attachments
emerge --info output for my system (emergeinfo.log,5.56 KB, text/plain)
2015-03-09 23:09 UTC, Paul Gover
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Gover 2015-03-09 23:09:17 UTC
Created attachment 398558 [details]
emerge --info output for my system

After upgrading to mysql-5.6 both akonadi failed to start.  My akonadi uses the default configuration, an internal MySQL database.  I tried deleting the akonadi database .local/share/akonadi (which is only a cache), but it still would not start.  Investigation shows a known issue with using the obsolete system variable "table_cache" in mysql.conf.  Renaming this to "table_open_cache" fixed the problem with akonadi.  However, please note that I had deleted mysql.conf (it was in the database directory) and akonadi had recreated it from scratch, but still using the obsolete variable name.

Later, I found a similar problem with digikam, also configured to use an internal MySQL database.  Its mysql.conf also used table_cache.  However, renaming it was not enough to get digikam to start.  It turns out it also uses "log_slow_queries", which needs to be renamed to "slow_query_log".  With both changes, digikam starts.  Again, deleting mysql.conf causes digikam to recreate it with the obsolete variable names.

IMHO this is really an upstream problem, but it may make sense to patch the programs to save newcomers hitting the problem.

Steps to reproduce
On a system with akonadi or digikam installed and using >=dev-db/mysql-5.6 for their internal database, delete (or rename out of the way) .kde4/share/apps/digikam/mysql.conf or .local/share/akonadi/mysql.conf, and try starting akonadi or digikam.  They won't start.  Correcting the system variable names in the newly-created mysql.conf files will enable them to start.
Comment 1 Michael Palimaka (kensington) gentoo-dev 2015-03-10 14:04:07 UTC
Could this be bug #530012 ?
Comment 2 Paul Gover 2015-03-10 14:37:37 UTC
No, it's not bug #530012, though I think I recognize that from akonadi problems I had earlier.

If that's the same, it's worth deleting (or renaming) mysql.conf from the akonadi directory, and any local overrides (possibly in .local, I forget).  That causes akonadi to write a new (simpler) mysql.conf.  That won't work either, but it's now 'cos of the renamed system variables in THIS bug!  So editing by hand should be a working bypass.
Comment 3 Johannes Huber (RETIRED) gentoo-dev 2015-06-26 22:08:42 UTC
As there are no more cc's on the bug i guess the bug can be closed.