SUMMARY Adding events as described in the docs (https://docs.kde.org/stable5/en/pim/kalarm/cmdline-operation.html) does not work anymore STEPS TO REPRODUCE 1. have a freshly istalled instance of current KDE Neon (Ubuntu 18.04 based); have kalarm installed 2. open konsole and enter the following line kalarm -t 27-22:00 "test" OBSERVED RESULT a) an error message stating "org.kde.pim.kalarm: AlarmCalendar::addEvent: Error! Cannot create Active alarm (No default calendar is defined)" b) no alarm is set EXPECTED RESULT a) no error b) a new alarm with the message "test" at 1.11 should be entered at 10 p.m. on the 27th of this month SOFTWARE/OS VERSIONS Windows: - macOS: - Linux/KDE Plasma: 4.15.076-generic KDE Plasma Version: 5.17.5 KDE Frameworks Version: 5.66.0 Qt Version: 5.13.2 ADDITIONAL INFORMATION The error message is incorrect, as the only calendar named ActiveAlarms *is* active
This bug resulted from the processing of some command line options not waiting until calendars had become available. This caused failures such as the one you reported. The bug is now fixed by commit 9d0308396a74e64dbbd67a7b162f0d025c16123f, for KAlarm version 2.13.3, which will be released as part of KDE Applications 19.12.3.
Gladly installed todays unpdates and rebooted the machine, just to be sure. Indeed, something has changed, if you try add reminders via script like so: kalarm -c yellow -t 2020-07-01-15:00 --reminder 2D 'Do, 02.07.: some reminder' kalarm -c yellow -t 2020-07-29-15:00 --reminder 2D 'Do, 30.07.: some reminder' kalarm -c yellow -t 2020-08-26-15:00 --reminder 2D 'Do, 27.08.: some reminder' kalarm -c yellow -t 2020-09-23-15:00 --reminder 2D 'Do, 24.09.: some reminder' kalarm -c yellow -t 2020-10-21-15:00 --reminder 2D 'Do, 22.10.: some reminder' kalarm -c yellow -t 2020-11-18-15:00 --reminder 2D 'Do, 19.11.: some reminder' kalarm -c yellow -t 2020-12-16-15:00 --reminder 2D 'Do, 17.12.: some reminder' some of then are imported, but, sadly not all of them. On subsequent tests, results varied. Mostly only the first one was accepted: $ kalarm -c yellow -t 2020-07-01-15:00 --reminder 2D 'Do, 02.07.: some reminder' QCommandLineParser: already having an option named "v" QCommandLineParser: already having an option named "h" QCommandLineParser: already having an option named "help-all" QObject::disconnect: Unexpected nullptr parameter QObject::disconnect: Unexpected nullptr parameter QObject::disconnect: Unexpected nullptr parameter QObject::disconnect: Unexpected nullptr parameter QCommandLineParser: already having an option named "v" QCommandLineParser: already having an option named "h" QCommandLineParser: already having an option named "help-all" Failed to register /MainApplication on DBus "" (then hangs) In some cases several lines were processed, some from the beginning as well as the last ones, but the dates in between were missing - and this is almost worse than an import that did not work at all... Versions are now: kalarm -v QCommandLineParser: already having an option named "v" QCommandLineParser: already having an option named "h" QCommandLineParser: already having an option named "help-all" kalarm 2.13.3 (KDE Apps 19.12.3) If it would be useful, I would like to help by testing - unfortunately I am not a developer.
2020-03-06
You say you ran the commands from a script, so I tried the following script: #!/bin/bash kalarm -c yellow -t 2020-07-01-15:00 --reminder 2D 'Do, 02.07.: some reminder' kalarm -c yellow -t 2020-07-29-15:00 --reminder 2D 'Do, 30.07.: some reminder' kalarm -c yellow -t 2020-08-26-15:00 --reminder 2D 'Do, 27.08.: some reminder' kalarm -c yellow -t 2020-09-23-15:00 --reminder 2D 'Do, 24.09.: some reminder' kalarm -c yellow -t 2020-10-21-15:00 --reminder 2D 'Do, 22.10.: some reminder' kalarm -c yellow -t 2020-11-18-15:00 --reminder 2D 'Do, 19.11.: some reminder' kalarm -c yellow -t 2020-12-16-15:00 --reminder 2D 'Do, 17.12.: some reminder' This just hung on the first command, since KAlarm doesn't exit. I then tried adding '&' at the end of each line, to background the command. This worked correctly, creating all the specified alarms, without errors. Can you please say exactly how you ran the commands.
Yes, commands were submitted by pasting this block of lines into konsole, i.e. as if they were run as a batch file. An additional observation, the kalarm GUI window crashed (and system tray icon vanished), and at least on the surface, this does not look very like a clean process, and in any case not like the previous functionality. However, I did not watch the process list. As I am elsewhere on an older plasma version at the moment, I can take a deeper look on it next week. So long!
If you pasted those lines into konsole, each line would wait until you quitted KAlarm, before continuing on to the next line. Did you actually quit KAlarm 6 times? If not, what exactly did you paste into konsole? Did you get a crash trace when KAlarm crashed? It isn't possible to investigate a crash without this, unless the crash is easily reproduceable.
Sorry, of course if KAlarm is already running before you enter those commands, they will all run without waiting. Anyway, when I do the same, all the commands run successfully. Did the crash occur when you ran these commands, or at some other time?
Created attachment 126692 [details] Batch import of events (test 1)
Created attachment 126693 [details] Batch import of events (test 2)
So for further evaluataion I ran 2 batch files: ################################################################# #!/bin/bash kalarm -c yellow -t 2020-03-10-15:00 --reminder 2D 'Test entry 1' kalarm -c yellow -t 2020-03-14-13:00 --reminder 2D 'Test entry 2' kalarm -c yellow -t 2020-03-18-16:00 --reminder 2D 'Test entry 3' kalarm -c yellow -t 2020-03-24-19:00 --reminder 2D 'Test entry 4' kalarm -c yellow -t 2020-03-30-21:00 --reminder 2D 'Test entry 5' kalarm ################################################################# and ################################################################# #!/bin/bash kalarm -c yellow -t 2020-03-10-15:00 --reminder 2D 'Test entry 1' & kalarm -c yellow -t 2020-03-14-13:00 --reminder 2D 'Test entry 2' & kalarm -c yellow -t 2020-03-18-16:00 --reminder 2D 'Test entry 3' & kalarm -c yellow -t 2020-03-24-19:00 --reminder 2D 'Test entry 4' & kalarm -c yellow -t 2020-03-30-21:00 --reminder 2D 'Test entry 5' & kalarm ################################################################# As you can see in the screen recordings attached above, the first one remained waiting while displaying the first imported entry. (This dialog was hiding somewhere in the background, you can easily overlook it.) Result: only the first entry was imported (The other two entries were already there before). The second script caused the first and last entry to be imported, the rest ignored. The expected (and previously familiar) behavior of n consecutive "kalarm -t" calls (without a final "&") would be the silent import of n events, as if they had been entered via the GUI. Am I wrong? Where to look for a crash trace?
If you're running a plasma desktop, when an application crashes, the KDE crash dialog should normally appear prompting you to report the crash, and allowing the crash trace to be viewed and copied. I don't know how to make the dialog appear if it doesn't already. In this case, you would need to use gdb to obtain the crash trace, as follows: 1) Install gdb if it is not already installed. 2) Quit kalarm and run it in a terminal window, using gdb: gdb kalarm 3) In response to gdb's prompt, enter start --nofork 4) When kalarm crashes, there should be another gdb prompt in the terminal window. To display the crash trace, enter bt
I suspect that the QObject::disconnect errors probably come from inside QCommandLineParser rather than KAlarm itself, although I can't be sure. Certainly, there isn't any obvious place in KAlarm where a set of four such errors could be generated together. I've looked at your recordings, and tried running the same scripts (also on a Neon system), but I have been unable to reproduce the errors which you have seen. The command "kalarm -v" doesn't produce the error for me either. So there must be some difference between our systems which is causing the different results - one possibility is because I'm running a slightly older version of Qt. Unfortunately, until I'm able to update my Neon system (which will mess up my current development setup), it's difficult to know how I can investigate this further, and given that you are not a developer, I can't think of how you could help either. I'll look at this again once I do update my system.
I've now tested this on the latest Neon system, with Qt 5.14, and see the errors which you report when trying to create new alarms from the command line. This is the second major breakage which has happened in KAlarm due to Qt 5.14. I don't see the QCommandLineParser or disconnect errors. These may have been fixed by other changes since you reported the bug.
I'm not sure whether it was Qt 5.14 or KDE Frameworks 5.69 which made things go wrong, but it turned out that the code which handles multiple invocations of KAlarm needed improvement. It is now fixed by commit c907ac805bfc605e29a79455d78aad0dde4acf71 in release/20.04 branch. Thank you for your help in identifying the problem.
Dear David, thanks for fixing! Indeed, no error messages anymore. However, unfortunately no event (alarm) is set, too. My current state is: OBSERVED RESULT a) no error message b) no alarm is set c) "kalarm --help" does not give any output, too, so on the surface, it looks as if arguments are completely ignored. d) However watch this: $ kalarm --doyoulikeqt ; echo $? 1 $ kalarm --help ; echo $? 0 Something about parameter processing is still broken. SOFTWARE/OS VERSIONS Operating System: KDE neon 5.19 KDE Plasma Version: 5.19.2 KDE Frameworks Version: 5.71.0 Qt Version: 5.14.2 Kernel Version: 4.15.0-109-generic OS Type: 64-bit
What version of KAlarm are you running?
Hi David, that's exactly why I tried "kalarm -v" (and "--version"), and that's why I finally discovered the effect of totally missing commandline output. However, then I forgot the kalarm GUI, which tells us: Version 2.14.2 (*KDE Apps 20.04.2*) Sadly, this matches "Version Fixed In: 20.04.2", as I expected. Nevertheless, good luck anyway!
The latest KAlarm (not yet released) works on my current system, which is Neon with Plasma 5.18.4, KDE Frameworks 5.70.0, Qt 5.14.2. I'm now updating my system, and will check once that is complete.
I've now updated my Neon system to Plasma 5.19.2, KDE Frameworks 5.72.0, Qt 5.14.2, Linux kernel 5.3.0-62, and rebuilt kalarm and other KDE PIM packages. It still works for me.
Having my KDE Neon dist-upgraded to Ubuntu20.04 and installed the latest Updates, I've got Kalarm now in "Version 2.14.3 (KDE Apps 20.04.3)", and finally commandline works™ again! Therefore, thank you very much for troubleshooting and fixing!
Sadly, it is broken again, like described in the very first posting here. user@machine:~$ kalarm -t 27-22:01 "test1" user@machine:~$ kalarm -t 27-22:02 "test2" user@machine:~$ There is no error, it "looks" like a successful import, but the list of upcoming events in kalarm's main window remains unchanged. "kalarm --list" hoewever works. If you terminate the running kalarm process and retry a commandline entry again, then the fllowing error is displayed: user@machine:~$ kalarm -t 27-22:03 "test3" org.kde.pim.kalarm: ResourcesCalendar::addEvent: Error! Cannot create Active alarms (No default calendar is defined) ^C and you have to terminate the commandline by ctrl+c, because it is stuck. The GUI window has no problem with its default calendar. Current Versions: Operating System: KDE neon 5.20 KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 Kernel Version: 5.6.0-1028-oem OS Type: 64-bit kalarm: 3.1.2 (KDE Apps 20.12.2)
I have reproduced the issues which you report. Can you please tell me the status of your active alarms calendar. To check this, do View -> Show Calendars, and then right click on the active calendar which is listed in the Calendars panel, and select Show Details. Please report what is shown in the last line in the displayed details ("Default calendar").
If there is only one active alarm calendar, creating an alarm from the command line will now work even if the calendar is not already marked as the default calendar. This fits what happens if you create an alarm interactively. This is implemented by commit 05bf384f67c59b6375726ddf53ca4298c095e376 in release/20.12 branch, and will be in KAlarm version 3.1.3 in KDE release 20.12.3. If KAlarm was not already running, and a command line command to create a new alarm fails, KAlarm will exit. This is implemented by commit 5ca740ebcbd8299c3c53720707385b49dad8e669 in release/20.12 branch, and will be in KAlarm version 3.1.3 in KDE release 20.12.3. If the failure to create a new alarm from the command line is due to no default calendar being defined, an error message will be output on the terminal. This is implemented by commit fc678bcaaddad744efe3ccb83916427d92b97713 in master, and will be in KAlarm version 3.2 in KDE release 21.04. If an alarm is created from the command line when KAlarm was not previously running, KAlarm will not quit after creating the alarm. This is to ensure that an alarm created from the command line will actually trigger when it is due.
Dear David, sorry for the delay, and thanks for your research on this matter! I am happy to confirm that after the release of version (at the latest) "3.1.3 (KDE Apps 20.12.3)" the command line feeding of multiple entries works again as it should.