Alien Pastures

My thoughts on Slackware, life and everything

Tag: akonadi

Common questions on Akonadi and Nepomuk in KDE PIM 4.8

March 14, 2012 / / 4 Comments

 I am not usually a copy/paste kind of guy but I thought it is good to have the following information visible on this blog instead of “just” being a forum post.

I was triggered by a linuxquestions.org post which pointed to another post on forum.kde.org called “Common questions on Akonadi and Nepomuk in KDE PIM“. The post contains a Q&A between one of the board admins and Christian Mollenkopf. This is its full text, copied verbatim (and reformatted for this post). I hope this helps some people who wonder why their PC is so busy indexing on every boot.

 

Q&A session with Christian Mollenkopf:

Starting from version 4.7, KDE PIM has integrated Nepomuk for many operations such as search, message tagging, and address auto-completion. This post answers some of the common questions related to the state of this integration.

Q. Will email which is encrypted be indexed in any form, or will it be ignored?
A. It will be ignored since the search index is not secure.

Q. Will the indexer attempt to match the contents of my address book against emails?
A. Yes, the extracted contacts should be merged by email address.

Q. What occurs when email is read or deleted using other clients on shared mail boxes (such as IMAP mail boxes)?
A. It’s either removed or re-indexed.

Q. If the IMAP server supports it, does Akonadi use the server’s search capabilities or index it using Nepomuk anyway?
A. The indexer is protocol agnostic, that is, it works regardless of the server type used, be it POP, IMAP, or local mailbox. If a supported item (a message) is in Akonadi, it’s indexed. If it is changed it’s reindexed, and if it is deleted it’s removed from the index. It doesn’t really matter where the item is coming from.

Q. The performance of mail indexing is slow, how can it be improved?
A. There are different ways to achieve that:

  • Index only what you need. Right click on a folder, select Folder Properties, then the Maintenance tab, then “Disable fulltext indexing“: this will disable indexing for that specific folder;
  • Turn off email indexing altogether by unchecking the relevant option in System Settings, Desktop Search (only available from 4.8 and later);
  • Wait until initial indexing has completed. Indexing is completed when the akonadi_nepomuk_feederrc file in your KDEHOME/share/config directory (KDEHOME is usually .kde or .kde4) contains the following:
    [InitialIndexing]
    IndexCompatLevel=3
  • Locate the akonadi_nepomuk_feederrc file and change DisableIdleDetection to true:
    [akonadi_nepomuk_feeder]
    DisableIdleDetection=true

    This will cause the feeder to keep on indexing regardless of idle status, increasing CPU usage significantly but on the long run reducing the time to complete indexing. As a matter of fact, the real performance issue is the initial indexing, as it can take very long (days with large mailboxes), and is restarted if interrupted (i.e. because of a restart, not by sleep-mode or alike). Once initial indexing is over, performance will be significantly better. The KDE PIM developers are aware of this problem and will work on a solution.

Eric

kmail terminates during startup with “Failed to fetch the resource collection”

November 13, 2011 / / 11 Comments

One thing that keeps boggling people’s minds when they use KDE is Akonadi, the framework used to access PIM-like data. PIM being “Personal Information Management”. Akonadi leaves me in the dark too, sometimes!

If you want to know a bit more about how Akonadi sits at the core of your personal data management in KDE, you might want to read these articles first, one being two  years old and the other a bit more recent… http://thomasmcguire.wordpress.com/2009/10/03/akonadi-nepomuk-and-strigi-explained/ and http://vizzzion.org/blog/2010/08/demystifying-akonadi/ . This is also a nice article “Akonadi misconception #1: where is my data?“: http://blogs.kde.org/node/4503 which is definitely worth checking out.

In the meantime, there is an issue I wanted to discuss with you, considering Akonadi. When you upgrade to KDE 4.7.x coming from Slackware’s KDE 4.5.5, the upgrade process is not always smooth. The PIM suite in KDE 4.7.x is now using Akonadi as its backend, meaning your PIM data (kmail, kontact etc) are migrated over to the Akonadi storage the very first time you start your new KDE. This migration is not always proceeding perfectly.

There’s a thread on LinuxQuestions.org about kmail crashing on startup with a very specific error message “Failed to fetch the resource collection“. I provided the solution in that thread but thought it would be good to document it here in the blog as well. The bug is fairly old, it is being discussed in https://bugs.kde.org/show_bug.cgi?id=259355

What you have to do if you encounter this issue, is the following:

  1. Launch Akonadi Console (for instance by pressing “Alt-F2” to open krunner and typing “akonadiconsole”).
  2. In the “Agents” tab, select the “Local Folders” resource.
  3. Select “Configure > Configure natively…”.
  4. If an error appears indicating that “the current folder does not exist” don’t worry. Select a new directory which does not yet exist, for instance: /home/<USERNAME>/.kde/share/apps/kmail/mail/

This should fix the issue with kmail.

You can fix it the hard way, by removing all of your “.kde” directory content but that is so rude, and you lose a lot of other configurations besides your mail.

A whole section of the KDE User Base is devoted to Akonadi troubleshooting, I recommend you check that out if you run into Akonadi related issues: http://userbase.kde.org/Akonadi_4.4/Troubleshooting

Cheers, Eric

Starting with KDE 4.6

December 12, 2010 / / 35 Comments

Hi folks!

It took a while, because I have been fighting with properly packaging the LibreOffice software for so long, and playing with slackware-current to find bugs and areas of improvement.

But I finally found time to work on a set of Slackware packages for the second beta of the KDE 4.6 Software Compilation. The release of version 4.5.85, otherwise known as “4.6-beta2” was a few days ago. I had been following the issues which were reported in the days before making the sources public, so it was not too difficult to prepare the dependencies and update Slackware’s KDE build scripts.

Note #1: running Slackware-current (32-bit or 64-bit) is a requirement! Slackware 13.1 is simply too old for my packages.

Note #2: this is beta software, some things will not work reliable or are broken. Do not use this on machines you depend on for your daily work unless you know what you are doing! Use at your own risk!

Apart from the new KDE packages, there are several Slackware packages that need upgrading if you decide you want to test KDE 4.6-beta2. Also, four new non-KDE packages have entered the arena: these are libatasmart,sg3-utils, udisks and upower. The new packages are required because KDE 4.6 no longer depends on HAL. Instead, it uses udisks and upower (born out of the DeviceKit family). The reason is simple: HAL is no longer developed. The X.Org developers took this step away from HAL earlier during the development of X11R7.6 (the version of X in slackware-current does not use HAL anymore). This happened for the same reasons, however X.Org talks to udev directly and does not need udisks and upower. I wish KDE would have done the same… it seems we are now stuck with these DeviceKit offsprings…

Where are the packages?

Packages are available as usual in my “ktown” repository: http://alien.slackbook.org/ktown/4.5.85/ which is mirrored to http://taper.alienbase.nl/mirrors/alien-kde/ and http://repo.ukdw.ac.id/alien-kde/.

I have added a nice README with instructions on how to install or upgrade to this beta2 of KDE 4.6.

What are my experiences so far with this new software?

  • Of course, the first thing I tried was disabling HAL entirely by running “chmod -x /etc/rc.d/rc.hald” and rebooting.. That went well enough, apart from a piece of audio hardware that was no longer recognized: “HDA Intel (CONEXANT analog)” but I still have proper sound anyway. KDE will complain about hardware that goes missing and will ask you if it should forget about that hardware altogether, or ask again next time.
  • I found that k3b and kaudiocreator no longer worked. I have built new packages for both, with the latest sources checked out from the repositories, and that fixed k3b. Unfortunately, kaudiocreator still crashes on startup, complaining about “QSocketNotifier: Invalid socket 10 and type ‘Read’“. This is caused by the same change in the Solid API which made k3b crash initially, but that team fixed it. If you find a patch for kaudiocreator, tell me!
  • After the upgrade, I had big issues with akonadi. As you may know, akonadi is the storage service for PIM data (kmail wants to store its emails there) and meta data indexed by Strigi and Nepomuk. The upgrade from 4.5.4 to 4.5.85 caused disruption here. On login to KDE, I found that several instances of akonadi_control were being started as well multiple instances of mysqld (akonadi uses MySQL as the database backend) and every time I started KDE, more of these processes would run and all of them would complain about their brethren.  I have not found a decent troubleshooting and repair guide for Akonadi, and out of despair I deleted the akonadi directories “~/.local/share/akonadi” and “~/.config/akonadi” entirely… now that solved the issues!  However, you really do not want to end up with this scenario, especially if all your emails are stored in an akonadi database. Akonadi developers, please provide better documentation on how to fix a broken service!
  • I found that the guidance-power-manager package is no longer needed, because KDE’s own power-devil does a good job of managing the power. I simply removepkg-ed the guidance-power-manager.  There is a widget with a l battery gauge if you need one – it is not added to the system tray by default.
  • I added a package for “kwebkitpart” so that you can now switch konqueror’s rendering engine from KHTML to Webkit (which is a descendant of KHTML).

To sum it all up: if you are adventurous, get my packages and upgrade your Slackware computer with them. It’s a lot of fun trying to find the quirks and bugs in new software, especially if you find fixes for them. And generally, this software works well, even if it is still e beta. But like I said before, you should not use this beta software on a computer that you depend on for your daily business… unless you know what you are doing and are confident that you can overcome any hurdles.

Post your findings in the Slackware forum of linuxquestions.org. Or even better: let me know right here on this blog, and I’ll try to help you out.

Have fun, Eric.

© 2024 Alien Pastures

Theme by Anders Noren — Up ↑