[kde-linux] 'Fetch Error' on exit

[Duncan]

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> 
wrote:

>> The problem seems to be that the Akonadi server configuration says 
that it
>> 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 
by default.

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>
  +akonadi-server-1.4.0-r1.ebuild:
  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 
upgrades.


>> 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:
>> Driver=QMYSQL
>>
>> Change that to
>>
>> Driver=QSQLITE3
>>
> 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