I have 6 resources: 3 that are labeled 'ready' named ______ Alarms and 3 labeled 'no file selected' named akonadi_kalarm_resource_n. When hovered they all say "loads data from a Kalarm calendar file'

Can I just delete the "no file selected" ones" or will they serve a purpose in the future?

The no file selected ones are likely broken and can probably be removed safely.
Given the number of working (3) and broken (3) closely matches, I would say the broken ones are the result of a failed migration.

This is an issue I've been working on in the last couple of weeks.

One possible reason for the "No file selected" resources is that their config files might not exist - there should be one file ~/.kde/share/config/akonadi_kalarm_resource_*rc for each KAlarm resource. If akonadi_kalarm_resource_0rc etc are missing, this would result in what you see for these resources.

Another possible explanation could be to do with how the calendar file location is stored in these resource config files. There seems to have been an unwanted change from storing the calendar file path to storing its URL (with "file://" prefixed to its path). This causes problems for the Akonadi resource in recognising the file.

In any case, deleting an Akonadi resource will not affect your calendar files. You can then recreate the resource after deletion if you want to - if the other resources don't already point to the calendar files you want.

I hope to have this fixed very soon, hopefully in time for the KDE 4.9 release.

Update - this is now fixed for single file resources, and the fix should be in KDE 4.9.0 (and 4.8.5 if that is ever released). I'm still working on fixing these issues for directory resources.

Hello,
in the course of my almost daily Debian Wheezy/sid upgrades I replaced a compiled version of kalarm (due to crashes in the Debian package) with the fixed Debian 4.7.4 package. However, since that time I could no longer save a new alarm because I would be asked which calendar to use and choosing in the preferences the standard calendar would not suffice. Deferring alarms also would not work because the defer button is missing. I posted this in the debian-kde group and received the advice "You are missing Kalarm akonadi resources. You can't save alarm without resources."

Indeed kalarm resources are missing in my installation of Debian KDE SC 4.8.4. But I never saw or needed them before and they should not be necessary in the setup wtih the Debian package. Well, then I compiled a new kalarm, hoping after reading the above postings that this might introduce the resources. No joy. Now the new kalarm 2.9 built from sources on and amd64 system crashes upon startup, and neither are there akonadi kalarm resources visible. In a test account with a new KDE profile kalarm starts up and krashes (pun not intended) not immediately but a few seconds later, but I can not set new alarms either. BTW, mysql was upgraded from 5.1 to 5.5 in the past week as well and throws a set of error messages like "[ERROR] Native table 'performance_schema'.'events_waits_current' has the wrong structure" but Akonadi starts and kaddressbook is working, and maybe these messages are not new. I found a bug report about mysql rpms, the gist was that this was not important.

Kalarm is important for me. Can I do something to fix it or help that it will work again? Should I file a bug report because of the crashes?
Regards, Andreas

It would be useful if you filed a KDE bug report, containing the crash trace plus any other relevant information. If you are also seeing the issue which was first reported in this forum topic, note that you should try building kdepim-runtime and KAlarm with the latest git sources first.

When using the Akonadi version of KAlarm (which is the default for version 2.9), it should automatically create Akonadi resources if they don't already exist. These will be copied from your pre-Akonadi resource settings if these are available; otherwise, it will just set up the default active, expired and template calendar Akonadi resources.

If you are having mysql problems, I'm afraid I don't know about that - the Akonadi server and its workings are a black box as far as I'm concerned. Applications don't know about the database operations going on in the background - the Akonadi interface library handles that.

If you really can't get it to work at all, there is the option of reverting to the pre-Akonadi method. This involves rebuilding the kalarmcal library in kdepimlibs using the KResources options, and then rebuilding KAlarm. From my point of view, of course, it would be preferable to fix the Akonadi problem in case other people who can't build from source also have the same issue.