KAlarm fails to launch. So, I launched it from within Konsole as a regular user, with these results:
TuxBox@theo:~> kalarm
QCoreApplication::arguments: Please instantiate the QApplication object first
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
then it hangs forever.
My system:
openSUSE Leap 42.1 for x86_64
kalarm5 v15.12.3-40.6 from from the KDE Applications repo at http://download.opensuse.org/repositories/KDE:/Applications/openSUSE_Leap_42.1/
libKF5AlarmCalendar5 v15.12.3-17.1 from the KDE Applications repo at http://download.opensuse.org/repositories/KDE:/Applications/openSUSE_Leap_42.1/
akonadi5 v15.12.3-37.8 from the from the KDE Applications repo at http://download.opensuse.org/repositories/KDE:/Applications/openSUSE_Leap_42.1/
akonadi_resources v15.12.3-40.6 from the KDE Applications repo at http://download.opensuse.org/repositories/KDE:/Applications/openSUSE_Leap_42.1/
Qt 5.5 from the repo at http://download.opensuse.org/repositories/KDE:/Qt55/openSUSE_Leap_42.1/
I know very little about the inner workings of the KDE PIM system, and the description of my system is my best guess at what may be involved; so, please expect I know nothing about how to fix this problem.
I do not have kalarm (KDE4) installed.
I use KAlarm quite frequently, so this is very frustrating. Please help.
Are you sure it hangs? And is not just among the hidden items in the system tray?
Try clicking on the up-arrow just left of the digital clock whether you see it there.
You seem to have an unnecessary (and maybe even incompatible) mixture of repos.
Please post your full list.
zypper lr -d
Just so much at this point: KDE:Qt55 is the unstable Qt 5.5 development version, and it’s practically useless for you as Leap 42.1 does contain the latest 5.5(.1) version anyway (as 5.6.0 has been released recently, 5.5 will not be developed further).
You don’t need KDE:Applications either, as you get those packages via the standard update repo as well.
So maybe remove those additional repos (at least KDE:Qt55) and run “zypper dup”, that might fix the problems.
Or at least try to do a full switch to those repos. Mixtures of the Akonadi components between the standard repos (which is still at 15.12.2) and KDE:Applications might cause problems too, and other mixtures (like for the Qt5 packages) might as well.
Every time a new alarm calander is added, KAlarm and automatically also creates a calander named “akonadi_kalarm_resource_N+1” where “N+1” is an integer 1 greater than the last created alarm calander. For example, “akonadi_kalarm_resource_21”. When I select an “akonadi_kalarm_resource_N+1” calander and click the button labeled “Edit”, I discover the “akonadi_kalarm_resource_N+1” contains the same data as the newly added calander that immediately preceeded the creation of the “akonadi_kalarm_resource_N+1” calander. For example, If I add a new calander named “Test”, KAlarm immediately and automatically adds a calander named “akonadi_kalarm_resource_10”. When I select the “akonadi_kalarm_resource_10” calander and click the button labeled “Edit”, I discover “akonadi_kalarm_resource_10” contains the same data as “Test”.
Whan a new alarm is created, it is saved as 1 hour ahead of the desired time. For example, if I create an alarm for 9:30 AM, it will actually be saved as 10:30 AM, and the alarm will not fire at 9:30 AM. I checked the setting in the KDE clock for my region, and it is correct. I checked the setting for my region in YaST Date and Time, and it is correct. The correct time is displayed on both my KDE clock and in YaST Date and Time.
I thought I should mention that I am open to deleting any and all PIM data and PIM configuration files to get KAlarm working correctly. I am working in a new account that is mostly for testing purposes.
I created a new account for a fresh start, and did some testing there.
KAlarm behaves the same as described in my previous post, such that:
Every time a new alarm calander is added, KAlarm and automatically also creates a calander named “akonadi_kalarm_resource_N+1” where “N+1” is an integer 1 greater than the last created alarm calander. For example, “akonadi_kalarm_resource_21”. When I select an “akonadi_kalarm_resource_N+1” calander and click the button labeled “Edit”, I discover the “akonadi_kalarm_resource_N+1” contains the same data as the newly added calander that immediately preceeded the creation of the “akonadi_kalarm_resource_N+1” calander. For example, If I add a new calander named “Test”, KAlarm immediately and automatically adds a calander named “akonadi_kalarm_resource_10”. When I select the “akonadi_kalarm_resource_10” calander and click the button labeled “Edit”, I discover “akonadi_kalarm_resource_10” contains the same data as “Test”.
Whan a new alarm is created, it is saved as 1 hour ahead of the desired time. For example, if I create an alarm for 9:30 AM, it will actually be saved as 10:30 AM, and the alarm will not fire at 9:30 AM. I checked the setting in the KDE clock for my region, and it is correct. I checked the setting for my region in YaST Date and Time, and it is correct. The correct time is displayed on both my KDE clock and in YaST Date and Time.
Remove the “VLC - VideoLAN” repo as well. This is incompatible with Packman, and Packman contains vlc anyway.
That’s unrelated to KAlarm though of course.
KAlarm now launches. Good progress.
Great.
There are now 2 new problems:
Every time a new alarm calander is added, KAlarm and automatically also creates a calander named “akonadi_kalarm_resource_N+1” where “N+1” is an integer 1 greater than the last created alarm calander. For example, “akonadi_kalarm_resource_21”. When I select an “akonadi_kalarm_resource_N+1” calander and click the button labeled “Edit”, I discover the “akonadi_kalarm_resource_N+1” contains the same data as the newly added calander that immediately preceeded the creation of the “akonadi_kalarm_resource_N+1” calander. For example, If I add a new calander named “Test”, KAlarm immediately and automatically adds a calander named “akonadi_kalarm_resource_10”. When I select the “akonadi_kalarm_resource_10” calander and click the button labeled “Edit”, I discover “akonadi_kalarm_resource_10” contains the same data as “Test”.
The “bug” is probably that the resources (calendars) are configured to use the same ical file. In that case it’s clear that they contain the same data.
Set a different file/folder in the edit dialog, that should fix it.
Whan a new alarm is created, it is saved as 1 hour ahead of the desired time. For example, if I create an alarm for 9:30 AM, it will actually be saved as 10:30 AM, and the alarm will not fire at 9:30 AM. I checked the setting in the KDE clock for my region, and it is correct. I checked the setting for my region in YaST Date and Time, and it is correct. The correct time is displayed on both my KDE clock and in YaST Date and Time.
Hm.
I don’t use KAlarm, so I cannot tell whether this is a general problem or not. I can give it a try later though…
Thank you for that information. I was unaware of that.
I used a different file every time I created a new calendar, and the “N+1” problem still happened. Even so, I took your advice and did a lot of experimenting with many different file names, in multiple sub-directories. No joy. The problem persists.
I appreciate your assistance very much.
I checked the settings you referenced, and they were correct.
I made no changes to any setting. I then tested an alarm. The alarm displayed in KAlarm’s main pane as the proper time entered, and the alarm fired at the correct time. Apparently, this was a bug that has been fixed.
Overall, as far as I can tell, it seems KAlarm is working correctly with the exception of the “N+1” behavior; which is very disappointing to me.
Oh, it seems I slightly misunderstood you.
So the problem is that it actually creates two calendars, one with the name you specified and another “copy” with “akonadi_kalarm_resource_x”?
That sounds indeed like a bug.
Probably a timing problem (i.e. creating the calendar takes too long and is considered as failed and is being retried), maybe in Akonadi itself. I’ve seen similar behaviour on Akonadi’s first start on a fresh user account, when the default (calendar and addressbook) resources are created.
But similar issues happen in other places too, like mail filtering e.g.
I can only suggest to run “akonadictl fsck” (as user) to clean up/fix the Akonadi database. That might help if the problem is caused by garbage in there.
Please help.
