recurring alarms disappear from indicator (but not clock-app) after first kick

[Charles Kerr]

I'm not sure yet what's causing this, but the symptom is for ~/.local/share/evolution/tasks/${foo}@ubuntu-phablet/tasks.ics to have entries whose rrule looks like this:

> RRULE;X-EVOLUTION-ENDDATE=19700101T000000Z:FREQ=WEEKLY;COUNT=32639;
> BYDAY=MO,TU,WE,TH,FR
> SUMMARY:Weekday wakeup

When is should look more like this:

> RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR

Alarms appear / trigger again after manually editing tasks.ics to remove the invalid X-EVOLUTION-ENDDATE and COUNT values, then restarting evolution-calendar-factory and indicator-datetime.

ENDDATE's clearly coming from a (time_t)0. Not sure about 32639, but it's INT16_MAX - 128, so we've got that.

Edit: this doesn't appear to be the full story -- if I create a brand new recurring alarm it works correctly even though the epoch ENDDDATE is present. For me they disappeared later, after a few days had passed and the system had been rebooted dozens of times. I'll see if I can reproduce the bug and, if so, how to reproduce it.

[Charles Kerr (charlesk)]

"X-EVOLUTION-ENDDATE" is set only in one place, evolution-data-server/calendar/libecal/e-cal-recur.c's function , e_cal_recur_set_rule_end_date(), which is only called in this block:

> /* Calculate the end date. Note that we initialize end_date to 0, so
> * if the RULE doesn't generate COUNT instances we save a time_t of 0.
> * Also note that we use the UTC timezone as the default timezone.
> * In get_end_date () if the DTSTART is a DATE or floating time, we will
> * convert the ENDDATE to the current timezone. */
> cb_data.count = rule.count;
> cb_data.instances = 0;
> cb_data.end_date = 0;
> e_cal_recur_generate_instances_of_rule (
> comp, prop, -1, -1,
> e_cal_recur_ensure_rule_end_date_cb,
> &cb_data, tz_cb, tz_cb_data,
> icaltimezone_get_utc_timezone ());
>
> /* Store the end date in the "X-EVOLUTION-ENDDATE" parameter of the
> * rule. */
> e_cal_recur_set_rule_end_date (prop, cb_data.end_date);

It looks like somehow e_cal_recur_generate_instances_of_rule() here generated no instances so that end_date became the epoch.

[Charles Kerr (charlesk)]

This repeated for me again overnight in vivid r109 on mako.

1. create recurring mon-fri wakeup alarm
2. wait a day for alarm to kick
3. after alarm kicks, it disappears from indicator (bug)
4. open clock-app, alarm still appears there (???)
5. reboot phone to see if it's an error with indicator's state
6. same results as 3-4

[Launchpad Janitor (janitor)]

This bug was fixed in the package qtorganizer5-eds - 0.1.1+15.04.20150227-0ubuntu1

---------------
qtorganizer5-eds (0.1.1+15.04.20150227-0ubuntu1) vivid; urgency=medium

  [ Renato Araujo Oliveira Filho ]
  * Use '0' as value for recurrence count if this is unset. (LP:
    #1424924)
 -- CI Train Bot <email address hidden> Fri, 27 Feb 2015 19:51:10 +0000