[kde-linux] 'Fetch Error' on exit
1i5t5.duncan at cox.net
Thu Feb 23 02:56:52 UTC 2012
Mark Knecht posted on Wed, 22 Feb 2012 15:24:11 -0800 as excerpted:
> On Wed, Feb 22, 2012 at 2:39 PM, Kevin Krammer <kevin.krammer at gmx.at>
>> The problem seems to be that the Akonadi server configuration says
>> should be using a MySQL instance for its database needs.
> Might this have been be created by me having MySQL installed at one
> time, KDE choosing to use it, but it not being installed now? I bought
> a book on MySQL awhile back just to run through a bunch of learning
> experiments but then later removed it. All Gentoo dependencies are
> being met so maybe an ebuild needs to be improved or something.
FWIW, as a gentooer, kdeer and former akonadi/kmail user here, I know
enough of the history to explain what's going on.
The problem is indeed historical, but it has nothing to do with your
former mysql interest. Instead, here's the sequence.
There are AFAIK three possible akonadi-server backend databases, along
with their drivers, mysql, sqlite, and postgresql, and in gentoo, the
corresponding USE flags for that package (akonadi-server, you can verify
the USE flags and their state).
Back in the early kde4/akonadi days, to the kde 4.5.1 and akonadi-server
1.4.0-r1 time frame if you correlate the gentoo changelogs for akonadi-
server and say kdelibs, the mysql backend was the default, gentoo
following the upstream kde/akonadi lead, as it was the first to mature
and early-on the stablest.
However, mysql, while arguably a great full-sized database for those
willing to take the time to properly tune and administer it (that is,
professional server administrators), isn't particularly well suited to "I
just want it to work" installations (that is, average joe blow desktop
users). Among other things, mysql has at least a history of version
upgrade challenges that can involve converting the database as part of
the upgrade, and various weird (from the perspective of non-professional
non-server-admins who just want it to work) problems with calendars and
utf-8 charset issues.
Meanwhile, the sqlite backend was maturing and its capacities and
stability improving. Sqlite's history of course is as an application
library, and it originally had problems with multi-threading and
concurrent thread-safe access to the same databases from multiple
threads. But by late 2010 under the pressure of akonadi intended usage,
it had grown these features while still remaining much less of a problem
to properly administer and upgrade than the previous mysql default, so
first kde/akonadi and then gentoo as well, switched to the sqlite backend
Here's one of two entries, same day, from the gentoo akonadi-server
changelog, that cover the switch:
07 Sep 2010; Maciej Mrozowski <reavertm at gentoo.org>
Enable SQLite backend as default one, fix SQLite driver name
(QSQLITE3 is new one, adjust qt-sql USE dep)
Again, correlating with the kdelibs changelog for kde timing perspective,
that was right after kdelibs 4.5.1 was added to the tree on 06 Sep 2010.
Of course, that change would have hit stable rather later. From the
changelog again, it appears that would have been May 09 2011 (x86 and
amd64), with akonadi-server 1.5.2, parallel to kdelibs 4.6.2-r3
stabilization (again, x86 and amd64) on the same day.
OK, the default changed, which meant that new users installing it would
get the new setup. However, gentoo by policy does not muck with files in
a users's home dir: that's strictly up to the user and/or local admin.
The PROBLEM was that unlike MOST kde settings, where a system level
setting is the default and a user level setting doesn't appear unless it
is specifically changed from the default, in THIS case, the akonadi-
server active backend setting is stored in the USER config.
Thus, what happened is that local admins who had set no specific USE flag
preference manually, had the system default backend switched out from
mysql to sqlite, with the resulting change in dependencies and actually
installed packages if they kept up with emerge --depclean, removing no
longer needed package dependency cruft from their system.
But that did nothing at all to change out the already set user
configuration in $HOME dirs, on systems where akonadi had been installed
before the switch. These configurations remained mysql, until users
switched them manually. If the only thing that had pulled in mysql was
akonadi-server and an admin did an emerge --depclean before the user had
switched, they'd suddenly find themselves with a broken config!
One of the reasons this didn't hit more folks is that not everybody
actually uses akonadi or the various kdepim apps that use it, so it
didn't really matter to them. Another is that amarok continued to depend
on mysql, so anyone who had it, or for that matter, anything else
depending on mysql, installed, wouldn't have lost mysql. Yet another is
that a lot of folks don't regularly run emerge --depclean or otherwise
clear the old dependency cruft that's no longer pulled in as a current
dependency, and they'd have not seen the problem unless or until they
did. And of course there's the folks that don't upgrade very often in
any case, and never run emerge --update --deep when they do, in which
case the old mysql-default version would have stuck around for some time,
until it was removed from the tree and the user next did a tree sync.
So it would have only affected those who were simply using the gentoo
default-use for the package or who specifically changed it themselves,
who didn't still have mysql in their dependency tree for other reasons,
and even then, it would have taken quite some time to filter down to the
last stable user, updating only a few times a year and never doing --deep
>> Since you want SQLite instead you'll have to modify that.
>> I am not sure if Gentoo has patched the sources to make that
>> the defaut in case the config is missing or whether you have
>> to change the driver key manually.
>> In case of the latter, open ~/.config/akonadi/akonadiserverrc
>> and look for the section labelle [%General]
>> In it should be an entry like this:
>> Change that to
> The file is there but I want to double check. The only line I change
> is the Driver=QSQLITE line. I don't bother with the MYSQL section and
> SQLITE doesn't require a section of its own?
Having done that change here myself (very shortly after it was introduced
in Sept. 2010 IIRC, or even earlier when it hit the overlay, as I'm ~arch
and running the gentoo/kde overlay, here, regularly check the git
whatchanged logs for the overlay, and was by that time already quite fed
up with the various mysql issues... and of course looonngg before I
dumped kmail and then kdepim and akonadi entirely after getting fed up
with the kmail akonadification with kdepim 4.6 and 4.7)...
Yes, that's ALL you need change. If you want, you /can/ remove the mysql
stuff as it's obviously no longer doing anything, but the single Driver=
line change is the operational one, the rest can be left in case you ever
install and switch to the mysql backend again, or removed, as desired.
And sqlite being the much MUCH simpler "just works" solution (unlike
mysql, perfect for a desktop default), there's really nothing to
configure for the sqlite/QSQLITE3 driver; only to change to it.
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
More information about the kde-linux