Bug 732551 - Alarm Procedure unreliable and representation in calendar file is inconsistent
Summary: Alarm Procedure unreliable and representation in calendar file is inconsistent
Alias: None
Product: Fedora
Classification: Fedora
Component: orage
Version: 15
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Kevin Fenzi
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-08-22 21:54 UTC by Paul DeStefano
Modified: 2011-10-02 22:59 UTC (History)
1 user (show)

Fixed In Version: orage-4.8.2-1.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-10-02 18:18:21 UTC

Attachments (Terms of Use)

Description Paul DeStefano 2011-08-22 21:54:19 UTC
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):

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:


But, after another event is added, the data in the previously created event is changed.  It now shows:


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.

Comment 1 Kevin Fenzi 2011-08-23 04:05:55 UTC
Would you be willing to file this upstream? I could do so if you prefer, but you seem to have a very good handle on the issue and could try things from them.

Comment 2 Paul DeStefano 2011-08-23 15:39:49 UTC
Sure, of course.  I'll file upstream.

Comment 3 Paul DeStefano 2011-08-31 16:15:03 UTC
This bug was reported and fixed upstream (see  v4.8.1.11)


I'm not sure how this will find it's way into the repositories.  I would appreciate knowing if this will come to F15 or F16 repositories, if you know.

Comment 4 Kevin Fenzi 2011-08-31 22:34:00 UTC
Well, when there's a new orage release we would get it. ;) 

But I can also look at backporting this fix to the 4.8.1 we have... will see how difficult that will prove to be.

Comment 5 Paul DeStefano 2011-08-31 23:24:54 UTC
Great, thanks!

That would be really awesome.  Sorry about the extra work; I thought maybe was just bug-fixes and you could just roll it out.  But, I don't know what I'm talking about; however the packaging works is fine.  It would be cool if there was an update to F15, at least, since (I gather) it was a lib change rolled out with F15 that necessitated in this patch.  But, whatever is convenient will be great.  The fix exists up-stream, so that's a relief.

Comment 6 Kevin Fenzi 2011-09-04 20:10:44 UTC
I looked at backporting this, but it's somewhat messy. 

I've asked upstream if they are going to be doing a 4.8.2 release soon. That would be more ideal. ;)

Comment 7 Paul DeStefano 2011-09-05 04:20:03 UTC
Sorry, Kevin.  Thanks so much for looking into it.  Looking forward to the next release, but that is typical.  Cheers.

Comment 8 Fedora Update System 2011-09-17 20:04:42 UTC
orage-4.8.2-1.fc16 has been submitted as an update for Fedora 16.

Comment 9 Fedora Update System 2011-09-17 20:06:03 UTC
orage-4.8.2-1.fc15 has been submitted as an update for Fedora 15.

Comment 10 Fedora Update System 2011-09-18 00:57:49 UTC
Package orage-4.8.2-1.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing orage-4.8.2-1.fc15'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 11 Paul DeStefano 2011-09-19 17:54:52 UTC
Wow!  That was fast.  Update installed, will report back after testing in a few days.

Comment 12 Paul DeStefano 2011-09-20 18:01:16 UTC
Excellent!  Seems to be working perfectly, again.  Many thanks.

Comment 13 Fedora Update System 2011-10-02 18:18:16 UTC
orage-4.8.2-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 14 Fedora Update System 2011-10-02 22:59:09 UTC
orage-4.8.2-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.