On Thu, Apr 01, 2010 at 15:57:53 +0800, Zhu, Yongsheng wrote: Thanks for caring about this. I think a solution could be to always create an ACTION of type DISPLAY, with the DESCRIPTION set to the SUMMARY of the VEVENT. Regards, Tino

It's a good suggestion. I find evolution also implement it in this way. So if 'SUMMARY' is present and 'DESCRIPTION' of 'VALARM' is absent, Is it ok to do the assignment? Ok, I'll do it. Cheers, Yongsheng > -----Original Message----- > From: Ohly, Patrick > Sent: Friday, April 02, 2010 12:20 AM > To: Tino Keitel > Cc: Zhu, Yongsheng; syncevolution(a)syncevolution.org > Subject: Re: [SyncEvolution] Alarms in the calendar: Evolution vs. vcal > > On Thu, 2010-04-01 at 16:18 +0100, Tino Keitel wrote: > > On Thu, Apr 01, 2010 at 15:57:53 +0800, Zhu, Yongsheng wrote: > > > Hi, Tino > > > I can verify your finding. Below bug entry is used to track this issue. > > > http://bugzilla.moblin.org/show_bug.cgi?id=10458 > > > You could track this issue to find the latest information. > > > thank you for raising this question. > > > > Thanks for caring about this. I think a solution could be to always > > create an ACTION of type DISPLAY, > > That's what we do now. I just merge Yongsheng's patch. > > > > I'm not sure whether this really is a problem in practice. Evolution > doesn't seem to care I assume, otherwise we would expect to have had bug > reports about it before, which is not the case. > > I'm not sure whether the problem is solved entirely with Mobical.net, > though. In a simple, relative alarm (15 minutes before event), this was > sent to the server: > > BEGIN:VCALENDAR > VERSION:1.0 > TZ:+01:00 > DAYLIGHT;ENCODING=QUOTED-PRINTABLE:TRUE;+02;20110327T010000Z;2010103 > 1T010000Z;;freeassociation.sourceforge.net;Tzfile;Europe;Berlin > BEGIN:VEVENT > LAST-MODIFIED:20100401T161612Z > DCREATED:20100401T161612Z > CLASS:PUBLIC > SUMMARY:custom alarm > DESCRIPTION:custom alarm > DTSTART:20100401T103000Z > DTEND:20100401T110000Z > AALARM:-PT15M;;;custom alarm > DALARM:-PT15M;;;custom alarm > END:VEVENT > END:VCALENDAR > > This came back: > BEGIN:VCALENDAR > VERSION:1.0 > BEGIN:VEVENT > DTSTART:20100401T103000Z > DTEND:20100401T110000Z > SUMMARY:custom alarm > DESCRIPTION:custom alarm > LAST-MODIFIED:20100401T161623Z > END:VEVENT > END:VCALENDAR > > > -- > Best Regards, Patrick Ohly > > The content of this message is my personal opinion only and although > I am an employee of Intel, the statements I make here in no way > represent Intel's position on the issue, nor am I authorized to speak > on behalf of Intel on this matter. >

Hi, Using daemon is the default behavior if the option '--enable-dbus-service' is enabled when configuration. If you don't want to use daemon, please don't enable that option in the configuration step. Cheers, Yongsheng

On Wed, Apr 07, 2010 at 08:13:28 +0200, Patrick Ohly wrote: [...] I did it the following way: I just built the Debian packages (which are currently at 1.0.0 alpha2) with the syncevolution source from git, and installed the packages. The build process automatically enabled the server, so this was the default mode. I think that for distributions it would be a good idea to make the default mode configureable. Maybe they want to include the server in the package, but also support existing setups. I don't know very much about the server mode in syncevolution (but I'll try it out soon), but for me the default did not work after I installed the new packages. I always got the message "[ERROR] Background sync daemon has gone.". Maybe this is all nonsense and I have an incomplete installation or something like this. Please ignore this suggestion in this case. Also, I want to point out that I like the server addition. I hope it can be made to run on a headless server with Debian Lenny, so I don't have to use some external service for private data anymore. Regards, Tino

On Wed, Apr 07, 2010 at 10:01:16 +0200, Patrick Ohly wrote: [...] It does, indeed. No debug symbols, so here is just the strace output. Regards, Tino open("/usr/share/syncevolution/xml/scripting/10newuid.xml", O_RDONLY) = 16 read(16, " <function><![CDATA[\n // create a UID\n string newuid() {\n return \"syuid\" + NUMFORMAT(RANDOM(1000000),6,\"0\") + \".\" + (string)MILLISECONDS(NOW());\n }\n ]]></function>\n\n\n", 8192) = 194 read(16, "", 7998) = 0 close(16) = 0 open("/usr/share/syncevolution/xml/scripting/11calendar.xml", O_RDONLY) = 16 read(16, " <!-- define script macros for scripts that are used by both vCalendar 1.0 and iCalendar 2.0 -->\n\n <macro name=\"VCALENDAR_INCOMING_SCRIPT\"><![CDATA[\n STRING MATCHES[];\n STRING CAT,CN,EM;\n INTEGER i;\n // make sure we have all trailing and leading spaces eliminated\n DESCRIPTION=NORMALIZED(DESCRIPTION);\n SUMMARY=NORMALIZED(SUMMARY);\n // make sure that we have a DESCRIPTION\n if (DESCRIPTION==EMPTY) DESCRIPTION=SUMMARY;\n // calendar or todo\n if (ISEVENT) {\n // VEVENT\n // - handle duration cases\n if (ISDURATION(DURATION)) {\n if (DTEND==EMPTY) DTEND = DTSTART + DURATION;\n if (DTSTART==EMPTY) DTSTART = DTEND - DURATION;\n }\n // - detect alldays in vCalendar 1.0 (0:00-0:00 or 23:59 localtime)\n i = ALLDAYCOUNT(DTSTART,DTEND,TRUE);\n if (ITEMDATATYPE()==\"vCalendar10\" && i>0) {\n // DTSTART and DTEND represent allday event, make them date-only values\n // - convert start to user zone (or floating) so it represents midnight\n DTSTART = CONVERTTOUSERZONE(DTSTART);\n MAKEALLDAY(DTSTART,DTEND,i);\n }\n else {\n // iCalendar 2.0 - only if DTSTART is a date-only value this really is an allday\n if (ISDATEONLY(DTSTART)) {\n // reshape to make sure we don't have invalid zero-duration alldays (old OCS 9 servers)\n MAKEALLDAY(DTSTART,DTEND,i);\n }\n }\n\n // Make sure that all EXDATE times are in the same timezone as the start\n // time. Some servers send them as UTC, which is all fine and well, but\n // only if the timezone definition doesn't change. Also, libical does not\n // handle such UTC EXDATEs, so let's convert it while the UTC and\n // time zone definition (hopefully) are in sync.\n if (TIMEZONE(DTSTART) != \"UTC\" && !ISFLOATING(DTSTART)) {\n i = 0;\n timestamp exdate;\n while (i<SIZE(EXDATES)) {\n exdate = EXDATES[i];\n if (!ISDATEONLY(exdate) &&\n (TIMEZONE(exdate) == \"UTC\" || ISFLOATING(exdate))) {\n // \"unfloat\" floating time stamps: not sure whether that occcurs\n // in practice, but it looks as wrong as UTC EXDATEs\n EXDATES[i] = CONVERTTOZONE(exdate,DTSTART,TRUE);\n }\n i=i+1;\n }\n }\n // If vcalendar1.0, rrule is not secondly, minutely, or hourly, we strip time information\n // and only reserve date information\n if (ITEMDATATYPE()==\"vCalendar10\" && RR_FREQ!=\"h\" && RR_FREQ!=\"m\" && RR_FREQ!=\"s\") {\n timestamp exdate;\n i = 0;\n while (i<SIZE(EXDATES)) {\n exdate = EXDATES[i];\n if (!ISDATEONLY(exdate)) {\n EXDATES[i] = DATEONLY(exdate);\n }\n i=i+1;\n } \n }\n\n // - shape attendees (and make sure ATTENDEES[] is assigned even for empty email addresses)\n i=0;\n while(i<SIZE(ATTENDEES) || i<SIZE(ATTENDEE_CNS)) {\n PARSEEMAILSPEC(ATTENDEES[i], CN, EM);\n ATTENDEES[i] = EM; // pure email address\n // in case we have no specific common name, use the one extracted from the email\n // This catches the vCalendar 1.0 case and eventually ill-formed iCalendar 2.0 as well\n if (ATTENDEE_CNS[i]==EMPTY)\n ATTENDEE_CNS[i]=CN;\n // default participation status to needs-action\n if (ATTENDEE_PARTSTATS[i]==EMPTY)\n ATTENDEE_PARTSTATS[i]=1; // 1=needs action\n i=i+1;\n }\n // - shape organizer\n PARSEEMAILSPEC(ORGANIZER, CN, EM);\n ORGANIZER = EM; // pure email address\n if (ORGANIZER_CN==EMPTY)\n ORGANIZER_CN=CN;\n }\n else {\n // VTODO\n // - make sure we have at least a summary\n if (SUMMARY==EMPTY) SUMMARY=DESCRIPTION; // use description if we don't have a summary\n if (SUMMARY==EMPTY) SUMMARY=\"unnamed\"; // set dummy summary if we still don't have one\n // due shaping for non-iCalendar 2."..., 8192) = 6905 read(16, "", 1287) = 0 close(16) = 0 brk(0xb37000) = 0xb37000 --- SIGSEGV (Segmentation fault) @ 0 (0) --- recvfrom(10, 0x867290, 1023, 66, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) dup2(8, 1) = 1 close(8) = 0 close(9) = 0 close(10) = 0 recvfrom(7, 0x867290, 1023, 66, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) dup2(5, 2) = 2 close(5) = 0 close(6) = 0 close(7) = 0 tgkill(15746, 15746, SIGSEGV) = 0 rt_sigreturn(0x3d82) = 4294967296 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Segmentation fault

Tino, you're using 64bit linux? It seems to me that it's a bug of xml parser in libsynthesis on 64bit platform. Could you please share us how to reproduce the crash? Thanks. Cheers, Yongsheng

On Thu, 2010-04-08 at 05:46 +0100, Tino Keitel wrote: This is with SyncEvolution compiled from source, right? In order to compile it, did you install the libsynthesis-dev pacckage (assuming that you are on Debian or Ubuntu)? Which version of it? I think Debian unstable and testing both have 3.4.0.5 as packaged with SyncEvolution 1.0 beta 2. In any case, that doesn't explain the segfault. In order to gather more information, can you also checkout git://git.moblin.org/libsynthesis, then compile SyncEvolution again with "--with-synthesis-src=<path to libsynthesis source> --disable-shared --prefix=<some non-system dir> CFLAGS=-g CXXFLAGS=-g"? After "make install" you can invoke <some non-system-dir>/libexec/syncevo-dbus-server and it won't interfere with your normal installation. Do you still see the crash? Does valgrind report anything useful? Finally, we could also make a recent snapshot available as .deb. If it works, we still won't know what the root cause was, though, so I'd rather investigate the issue first. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.

I run syncevolution on Ubuntu64 following up the steps Tino said, but can't reproduce the error. It's an issue just on Debian?! Cheers, Yongsheng

On Thu, Apr 08, 2010 at 11:43:15 +0200, Patrick Ohly wrote: [...] I rebuilt libsynthesis with --with-xmltok=builtin and replaced libxmltok1-dev with libexpat1-dev in the build dependencies. Now the segfault does not happen anymore. Thanks, I'll test this. Regards, Tino

On Thu, Apr 08, 2010 at 16:42:11 +0200, Patrick Ohly wrote: [...] Hi, I attached is a valgrind output of syncevo-dbus-server with libsynthesis git master as of today. Regards, Tino

On Mon, Apr 12, 2010 at 23:16:53 +0200, Tino Keitel wrote: [...] In the old mb10458 branch (before it was rebased), there was a commit e554b749bf4378e829f9b9b12c667cae09a04acc: Calendar: add workaround for 'alarm' in vCalendar1.0 (MB#10458) Mobical.net syncML server only accepts 'trigger' time of alarms as 'UTC' time. If 'trigger' time is a duration, it ignores that. To prevent this, when the outgoing format is 'vCalendar1.0', convert the duration time into 'UTC' time. This is missing in the current mb10458 and master branches. I guess that this is the reason for lost alarms on the phone when creating an appointment in Evolution. Regards, Tino

On Di, 2010-04-13 at 02:27 +0100, Zhu, Yongsheng wrote: Indeed, thanks for testing. Now "master" really contains the right patches. Yes, merged. I think the reason why I (incorrectly) thought that this patch had already been merged is that there is another patch with exactly the same "Calendar: add workaround for 'alarm' in vCalendar1.0 (MB#10458)" summary. But the older one is about DISPLAY DESCRIPTION, the new one about alarm time. As always when something goes wrong, we can learn from it. First, the summary must be more specific, and/or we need different bug numbers. Second, perhaps this whole rebasing thing isn't such a good idea after all. We are doing it to keep history on "master" linear, but it is an invitation for several mistakes: * I rebase in order to merge while someone else works on the branch. * When I push the rebased branch, changes on the remote repo may get lost (someone pushed further patches or I hadn't really merged correctly). Any opinions, anyone? -- Best Regards Patrick Ohly Senior Software Engineer Intel GmbH Open Source Technology Center Pützstr. 5 Phone: +49-228-2493652 53129 Bonn Germany