Description of problem: Since Fedora 15, execution of external procedure for event alarms is unreliable, always failing under real conditions (i.e. all but the most simple test case). I don't think the alarm procedure has correctly run since upgrading to F15. Alarm procedures fail for both new and old events. However, a single, new, test event alarm set for a few minutes into the future will succeed, effectively hiding the bug. Version-Release number of selected component (if applicable): orage-4.8.1-3.fc15.x86_64 How reproducible: Almost always. Steps to Reproduce: 1. Create a new event to occur any time in the future. 2. Set the alarm for that event to occur a few minutes before the event and mark it as a persistent alarm. 3. Add a command to the "Procedure" field. 4. Save and close event editor. 5. Repeat steps 1-4 to create two more events in the future. 6. Wait until all three new alarms occur. Actual results: Alarms occur, but none of the procedures for any of the alarms are executed correctly. See errors in .xsession-errors for details. For example, if the command is echo "hi there" you will see sh: echohi there: no such file or directory in .xsession-errors. Expected results: Procedure commands should run without error Additional info: Furthermore, the representation of the procedure command text is constantly changing in the .ics file without cause. When an event is created, the procedure text <command><space><parameters> is stored in the .ics file under ATTACH and DESCRIPTION attributes in the following way: ATTACH:<command> DESCRIPTION:<space><parameters> But, after another event is added, the data in the previously created event is changed. It now shows: ATTACH:<command> DESCRIPTION:<parameters> This may or may not be related to the error running the procedure command, but it is suspicious because (1) it is not expected as the data representation of events should not change when other events are changed; and (2) the Procedure command fails because a space is missing between the command name and the parameters. Finally, I'm just trying to use the alarm procedure command to send e-mail to my local account. mailx -s "alarm title" used to work just fine, but now it doesn't.
I can reproduce the change of the command, but it actually grows by one space always. I do not see it being changed by modifying another event. I will fix the extra space, but I am not 100% this fixes your issue as it should not cause the procedure to fail.
Yes, I remember that. I think that still occurs, also. When you edit and save an old alarm, the first space between the command and the parameters grows. This is different. The alarms occur, but the procedures completely fail due to a *missing* space. I continue to see errors as described in original report in .xsession-errors . Did you try creating two or three new alarms? If you just create one new alarm which occurs before any other alarms, it works as expected. But, if you create one event and then create another, the first one you create will alarm but fail, then the second one will alarm and it's procedure fails, too. I just tried that recipe again and got the same result. It's reproducible on my system, at least. Perhaps I can send you more information. Just ask. I'm also getting the following warning in .xsession-errors, but I don't think it's related because it has been this way as long as I can remember using orage: ** (orage:2385): WARNING **: get_alarm_data: Unknown ACTION (10003) in alarm. Ignoring ALARM. ** (orage:2385): WARNING **: get_alarm_data: Unknown ACTION (10003) in alarm. Ignoring ALARM. ** (orage:2385): WARNING **: get_alarm_data: Unknown ACTION (10003) in alarm. Ignoring ALARM. ** (orage:2385): WARNING **: get_alarm_data: Unknown ACTION (10003) in alarm. Ignoring ALARM. ** (orage:2385): WARNING **: get_alarm_data: Unknown ACTION (10003) in alarm. Ignoring ALARM. This repeats every time an alarm occurs, and whenever I add or edit any events.
Maybe it is actually related to that warning from get_alarm_data, which I do not get. Can you paste one of those EVENTs with ALARM data, so that I can try it. Yes, I added 3 events with procedure alarms, but I only saw the extra space problem and no failures.
I can reproduce this now. Testing setup is the same then yesterday, but now I see the problem. Looking this.
This is now fixed in Orage version 4.8.1.11 available in GIT. It was the new operating system libical library, which removed the spaces from all those parameters. This did not happen with Orage integrated libical, which is why I was not able to reproduce this first. Now adding the one needed space early enough in the code between cmd and parameters. Also fixed the code, which removes the space so that the string does not grow anymore even when used with local libical.
Awesome. Nice catch. A library change makes perfect sense. I should have thought of that. Regarding these warnings, if you don't get them, then I must have some bad data somewhere. I've tried to track it down, before, but I can't figure out which events orage is complaining about. These warnings don't reference any particular events. Do you know what "ALARM (10003)" means?
looks like ICAL_ACTION_EMAIL = 10003 Orage only supports AUDIO, DISPLAY and PROCEDURE alarms. You seem to have EMAIL also, which causes this warning. Sending email from linux c code is not simple, so I was not able to get it work, which is why it does not exist. (Actually even sending email from shell is not simple anymore...)
Brilliant. Thanks so much for your help. I have removed the offending alarms; they were there as exported from another calendar system. Yes, I concur; sending e-mail has become much more difficult. I limp along with local delivery via the procedure. Many thanks.
Fix in 4.8.2