[gentoo-amd64] Re: kmail - akonadi Server Self Test FAILURE

[Duncan]

Paul Stear posted on Wed, 22 Sep 2010 11:12:53 +0100 as excerpted:

> Hi all,
> I have updated kde to 4.5.1 and now have runtime errors. The following
> is the self test report:-

> Test 5:  ERROR
> --------
>
> MySQL server log contains errors.
> Details: The MySQL server error log file &apos;<a
> href='/home/paul/.local/share/akonadi/db_data/mysql.err'>/home/
paul/.local/share/akonadi/db_data/mysql.err</a>&apos;
> contains errors.
>
> File content of '/home/paul/.local/share/akonadi/db_data/mysql.err':
> InnoDB: The InnoDB memory heap is disabled InnoDB: use atomic builtins.
> InnoDB: Error: log file ./ib_logfile1 is of different size 0 0 bytes
> InnoDB: than specified in the .cnf file 0 67108864 bytes! 100922
> 10:43:05 [ERROR] Default storage engine (InnoDB) is not available 100922
> 10:43:05 [ERROR] Aborting
>
> 100922 10:43:05 [Note] /usr/sbin/mysqld: Shutdown complete

As VAH mentions, do try revdep-rebuild.  You may also wish to --update
--deep --newuse @world, if you don't routinely use --deep --newuse.

Meanwhile, I see two issues here, tho only one (your choice) needs 
corrected.

1) Gentoo has changed its default akonadi backend from mysql to sqlite.  
Previously, mysql was the only backend mature enough to really work 
properly.  sqlite had threading related problems (now fixed), and postgres 
had issues as well.

To change with it, however, requires rebuilding gt-sql and IIRC a couple 
other packages with the appropriate USE flags.  (sqlite, now on by 
default, for qt-sql, others similarly on by default.)  New enough versions 
are also required, thus the --deep --newuse, with revdep-rebuild to fix up 
reverse dependencies as usual.

The other problem is that the config as to which backend to use is per-
user, with emerges not touching user config.  So to run the new default 
sqlite backend, you have to manually adjust your user config.  I'm not 
exactly sure what the proper way to do that is.  I simply backed up a 
couple dirs here (with kde and mysqld stopped) and deleted them, then 
restarted kde/akonadi and ran akonaditray to fix things.  But I ended up 
having to recreate my address-book resource (the only one I really use 
ATM, no kopete or similar to worry about), pointing it at the old vcf 
files using akonaditray, then restarting kde and along with it akonadi, 
for it to work.  There should be a smoother way to do that upgrade, 
probably involving manually changing the existing config, instead of 
blowing it away so it can be recreated, and I know nothing about the kopete 
side if you run it, since I don't.

That bypasses the mysql error entirely, since you're switching to sqlite 
instead.

2) You can instead choose to stick with the (heavier but older and better 
tested) mysql backend.  In that case, the above error, that it can't find 
and start the innodb mysql engine, becomes the one of worry.  That one's 
very likely due to screwed "deep" interdependencies, so again, --update
--deep --newuse and revdep-rebuild are your friends.

I know there was a recent mysql update, but I didn't bother with it here, 
as I had seen the changelog notes about switching to sqlite by default and 
decided to do that, kill the mysql USE flags, and then unmerge it, since 
akonadi was the only reason mysql was on my system anyway.  That and the 
fact that I routinely use --deep --newuse on my updates, and revdep-
rebuild and --depclean after every update as well, to keep my system as 
self-consistent as possible, is probably why I didn't run into the innodb 
error you're seeing.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman