Dear all,

> I installed SOGo 1.3.3 on Debian/Lenny with Funambol 8.7.0 (and connector)
> using a Postgres database on a dedicated database server and everything
> seemed to work just fine.
The issue persists with 1.3.4. I just did the upgrade -- everything went
smooth! Thanks for developing and maintaining such a great groupware!

-- Adi

PS: Is there anything I can do to help further debug the issue?

===== 
> The trouble started when I created an event on a Nokia N900 and copied it
> over to SOGo via Funambol using Syncevolution. The webinterface is unable to
> display any event from the personal calendar anymore.
> Interesting enough: A caldav client (KOrganizer with caldav plugin) as well
> as the N900 does display the event and Funambol syncs the event on any
> other client as well; just the web interface crashes with the following 
> message:
> 
> | 2010-11-15 18:36:10.071 sogod[10193] <0x0x925a840[PostgreSQL72Channel]:
> |    connection=<0x0x925d308[PGConnection]:  connection=0x0x92c4918>>: 
> message:
> |    LOG:  duration: 0.150 ms
> | Nov 15 18:36:10 sogod [10162]: <0x0x90f97f8[WOWatchDogChild]> child 10193
> |    exited
> | Nov 15 18:36:10 sogod [10162]: <0x0x90f97f8[WOWatchDogChild]>  (terminated
> |    due to signal 11)
> | Nov 15 18:36:10 sogod [10162]: <0x0x90f97f8[WOWatchDogChild]> avoiding to
> |    respawn child before 2010-11-15 18:36:14 +0100
> | Nov 15 18:36:14 sogod [10162]: <0x0x90dd718[WOWatchDog]> child spawned with
> |    pid 10196
> 
> The event itself looks like this (from sogotool that is as well able to
> read the event):
> |         {
> |            c_content = "BEGIN:VCALENDAR^M
> |VERSION:2.0^M
> |BEGIN:VTIMEZONE^M
> |TZID:Europe/Berlin^M
> |BEGIN:DAYLIGHT^M
> |DTSTART:20100328T020000^M
> |RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3^M
> |TZOFFSETFROM:+0100^M
> |TZOFFSETTO:+0200^M
> |TZNAME:Europe/Berlin^M
> |END:DAYLIGHT^M
> |BEGIN:STANDARD^M
> |DTSTART:20101031T030000^M
> |RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10^M
> |TZOFFSETFROM:+0200^M
> |TZOFFSETTO:+0100^M
> |TZNAME:Europe/Berlin^M
> |END:STANDARD^M
> |END:VTIMEZONE^M
> |BEGIN:VTIMEZONE^M
> |TZID:GMT^M
> |BEGIN:STANDARD^M
> |DTSTART:19700101T000000^M
> |RDATE:19700101T000000^M
> |TZOFFSETFROM:+0000^M
> |TZOFFSETTO:+0000^M
> |TZNAME:GMT^M
> |END:STANDARD^M
> |END:VTIMEZONE^M
> |BEGIN:VEVENT^M
> |UID:426^M
> |SUMMARY:Test vom N900^M
> |DESCRIPTION:Test vom N900^M
> |LOCATION:Office^M
> |CLASS:PUBLIC^M
> |DTSTART;TZID=Europe/Berlin:20101115T133000^M
> |DTEND;TZID=Europe/Berlin:20101115T143000^M
> |SEQUENCE:0^M
> |LAST-MODIFIED:20101115T120636Z^M
> |DCREATED;TZID=Europe/Berlin:20101115T130636^M
> |X-FUNAMBOL-ALLDAY:0^M
> |END:VEVENT^M
> |END:VCALENDAR^M
> |";
> |            c_name = 426;
> |        }
> 
> ...right after deleting the event on eg. the N900 and syncing it to SOGo all
> the other events are showing up again in the web interface. (deleting only
> sets "c_deleted" to 1 in the database)
> 
> Is this a known bug? Any workaround for this? Anything I should try?
> Thanks for your help!
> 
> -- Adi
> 
> PS: I tried all the verbose logging options mentioned on
> http://www.sogo.nu/fr/nc/support/faq/article/how-to-enable-more-verbose-logging-in-sogo.html
> and all I got were the SQL statements right before the crash. They all work
> fine and result in reasonable responses; I tried them manually in the
> database.
> -- 
> users@sogo.nu
> https://inverse.ca/sogo/lists
> 
-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Reply via email to