May 2010 - Syncevolution-issues

[Bug 2566] New: Evolution contacts loose "Other" email-addresses when synced two-way with a Nokia S60

by bugzilla＠meego.com

http://bugs.meego.com/show_bug.cgi?id=2566 Summary: Evolution contacts loose "Other" email-addresses when synced two-way with a Nokia S60 Classification: MeeGo Projects Product: SyncEvolution Version: unspecified Platform: All URL: http://bugzilla.moblin.org/show_bug.cgi?id=10505 OS/Version: --- Status: ASSIGNED Severity: enhancement Priority: Medium Component: SyncEvolution AssignedTo: patrick.ohly(a)intel.com ReportedBy: patrick.ohly(a)intel.com QAContact: jingke.zhang(a)intel.com CC: syncevolution-bugs(a)meego.bugs, syncevolution-default-bugs(a)meego.bugs Estimated Hours: 0.0 Copied from http://bugzilla.moblin.org/show_bug.cgi?id=10505 Description From oliver-joos 2010-05-28 15:24:05 PST (-) [reply] I use Evolution 2.28.1 on Ubuntu 9.10 and SyncEvolution 1.0beta3, compiled from sources. I tried to sync contacts with my Nokia N81 (Symbian S60v3). In Evolution a contact may have upto 4 email-addresses, each of type Home, Work or Other. Multiple Home or Work addresses are sync'ed ok. But my phone seems to dispose addresses of type "Other" that come from Evolution! When I then modify other items of such a contact, then it is sync'ed back to Evolution - without the "Other" addresses. They get lost on both sides! The output shows that Evolution addresses of type "Other" seem to have no "TYPE=" at all. Perhaps Symbian S60v3 does not like that. EMAIL;TYPE=HOME:my_home@mail.com EMAIL:my_other@mail.com I am not sure, but I think I experienced similar problems with "Other" phone numbers. -- Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.

9 years, 10 months

1
10
0 / 0

[Bug 1371] New: SAN fail when syncing with N900 phone

by bugzilla＠meego.com

http://bugs.meego.com/show_bug.cgi?id=1371 Summary: SAN fail when syncing with N900 phone Classification: MeeGo Projects Product: SyncEvolution Version: unspecified Platform: Netbook OS/Version: IA Status: ASSIGNED Severity: major Priority: High Component: SyncEvolution AssignedTo: syncevolution-bugs(a)meego.bugs ReportedBy: jingke.zhang(a)intel.com QAContact: jingke.zhang(a)intel.com CC: syncevolution-bugs(a)meego.bugs, syncevolution-default-bugs(a)meego.bugs Estimated Hours: 0.0 This is from http://bugzilla.moblin.org/show_bug.cgi?id=10483 Description From ZhangJingke 2010-04-15 22:39:19 PST (-) [reply] Created an attachment (id=4684) --> (http://bugs.meego.com/attachment.cgi?id=4684) [details] N900 connection failure log syncevolution 0.9.99.20 Description: =============== This is a regression. Sync with N900 will meet "SANFormat 12 failed", please see the attachment. ------- Comment #1 From Chen Congwu 2010-04-15 22:57:08 PST (-) [reply] ------- It might be the phone is not responding for some reason, try reboot it.. ------- Comment #2 From ZhangJingke 2010-04-15 23:12:37 PST (-) [reply] ------- (In reply to comment #1) > It might be the phone is not responding for some reason, try reboot it.. I reboot phone, re-pair N900. Then it still fail with the same reason. :( ------- Comment #3 From Chen Congwu 2010-04-16 00:53:30 PST (-) [reply] ------- (In reply to comment #2) That's strange, works on my environment.. > (In reply to comment #1) > > It might be the phone is not responding for some reason, try reboot it.. > > I reboot phone, re-pair N900. Then it still fail with the same reason. :( ------- Comment #4 From Chen Congwu 2010-04-16 02:17:38 PST (-) [reply] ------- (In reply to comment #2) The connect system call will fail immediately with error code '104' (that is 'Connection reset by peer'), that's different when failed with pairing problem, error code '111' ('Connection refused') Any way, since it failed early enough before involving the Obex library, I suspect it might be: 1) Phone side mess 2) Bluez library or driver change in the image Jingke, could you 1) retest with another N900? 2) retest with an older image? > (In reply to comment #1) > > It might be the phone is not responding for some reason, try reboot it.. > > I reboot phone, re-pair N900. Then it still fail with the same reason. :( ------- Comment #5 From ZhangJingke 2010-04-19 20:12:18 PST (-) [reply] ------- (In reply to comment #4) > (In reply to comment #2) > The connect system call will fail immediately with error code '104' (that is > 'Connection reset by peer'), > that's different when failed with pairing problem, error code '111' > ('Connection refused') > Any way, since it failed early enough before involving the Obex library, I > suspect it might be: > 1) Phone side mess > 2) Bluez library or driver change in the image > > Jingke, could you > 1) retest with another N900? > 2) retest with an older image? I tried another N900, still the same failure. So, is it the error of "Nokia N900" template? I am sure N900 could sync in some old image. ------- Comment #6 From Chen Congwu 2010-04-20 00:44:36 PST (-) [reply] ------- (In reply to comment #5) right, this is a real problem > > I tried another N900, still the same failure. So, is it the error of "Nokia > N900" template? I am sure N900 could sync in some old image. Actually the failing scenario is as following: Moblin: connect() OK write() OBEX_Connect cmd read() --104 (Connection reset by peer) My PC: connect() OK write() OBEX_Connect cmd read() OK ------ see the detailed strace log: ---Moblin--- bind(8, {sa_family=AF_BLUETOOTH, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 10) = 0 fcntl64(8, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(8, F_SETFL, O_RDWR) = 0 fstat64(8, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0 fcntl64(8, F_GETFL) = 0x2 (flags O_RDWR) connect(8, {sa_family=AF_BLUETOOTH, sa_data="KO\324:\275\0\31\0\37\0\0\0\0\0"}, 10) = 0 time(NULL) = 1271795229 write(8, "\200\0\25\20\0\177\377F\0\16SYNCML-SYNC", 21) = 21 gettimeofday({1271795229, 351568}, {240, 0}) = 0 open("/home/moblin/.cache/syncevolution/nokia n900-2010-04-20-16-27/syncevolution-log.html", O_WRONLY|O_CREAT|O_APPEND, 0666) = 9 fstat64(9, {st_mode=S_IFREG|0644, st_size=21384, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb745b000 fstat64(9, {st_mode=S_IFREG|0644, st_size=21384, ...}) = 0 _llseek(9, 21384, [21384], SEEK_SET) = 0 write(9, "<li><i>[2010-04-20 16:27:09.351]"..., 61) = 61 close(9) = 0 munmap(0xb745b000, 4096) = 0 recv(5, 0x88cf218, 1023, MSG_PEEK|MSG_DONTWAIT) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=6, events=POLLIN}, {fd=8, events=POLLIN|POLLOUT}], 2, -1) = 1 ([{fd=8, revents=POLLOUT}]) time(NULL) = 1271795229 select(9, [8], NULL, NULL, {1, 0}) = 1 (in [8], left {0, 986552}) read(8, 0x88b2ce8, 3) = -1 ECONNRESET (Connection reset by peer) ----------- --PC-- bind(8, {sa_family=AF_BLUETOOTH, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 10) = 0 fcntl64(8, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(8, F_SETFL, O_RDWR) = 0 fstat64(8, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0 fcntl64(8, F_GETFL) = 0x2 (flags O_RDWR) connect(8, {sa_family=AF_BLUETOOTH, sa_data="KO\324:\275\0\31\0\37\0\0\0\0\0"}, 10) = 0 time(NULL) = 1271748604 write(8, "\200\0\25\20\0\177\377F\0\16SYNCML-SYNC", 21) = 21 gettimeofday({1271748604, 731927}, {4294966816, 0}) = 0 open("/home/cchen35/.cache/syncevolution/n900-2010-04-20-15-30/syncevolution-log.html", O_WRONLY|O_CREAT|O_APPEND, 0666) = 9 fstat64(9, {st_mode=S_IFREG|0644, st_size=21220, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7851000 fstat64(9, {st_mode=S_IFREG|0644, st_size=21220, ...}) = 0 _llseek(9, 21220, [21220], SEEK_SET) = 0 write(9, "<li><i>[2010-04-20 01:30:04.731]"..., 61) = 61 close(9) = 0 munmap(0xb7851000, 4096) = 0 recv(5, 0x9c61160, 1023, MSG_PEEK|MSG_DONTWAIT) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=6, events=POLLIN}, {fd=8, events=POLLIN|POLLOUT}], 2, -1) = 1 ([{fd=8, revents=POLLOUT}]) time(NULL) = 1271748604 select(9, [8], NULL, NULL, {1, 0}) = 1 (in [8], left {0, 911726}) read(8, "\240\0\32", 3) = 3 read(8, "\20\0\4\0\313K\315Y\241J\0\16SYNCML-SYNC", 23) = 23 ---------- ------- Comment #7 From pohly 2010-04-26 06:43:34 PST (-) [reply] ------- Congwu, Jingke, what is the status regarding this issue? We agreed that this looks like a regression in the underlying Bluetooth transports (Bluez, kernel). To proof that, we need to find an old image where this kind of sync still works, then install the same SyncEvolution version on a recent image and show that it fails. If SyncEvolution is the same in this test but the OS is not, then it should be investigated by the OS maintainers. -- Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

9 years, 10 months

1
48
0 / 0

[Bug 1350] New: support ovi.com (Nokia sync service)

by bugzilla＠meego.com

http://bugs.meego.com/show_bug.cgi?id=1350 Summary: support ovi.com (Nokia sync service) Classification: MeeGo Projects Product: SyncEvolution Version: unspecified Platform: Netbook OS/Version: IA Status: ASSIGNED Severity: normal Priority: Medium Component: SyncML AssignedTo: syncevolution-bugs(a)meego.bugs ReportedBy: jingke.zhang(a)intel.com QAContact: jingke.zhang(a)intel.com CC: syncevolution-bugs(a)meego.bugs, syncevolution-syncml-bugs(a)meego.bugs Estimated Hours: 0.0 This is from http://bugzilla.moblin.org/show_bug.cgi?id=3182 Description From jku 2009-06-03 08:59:15 PST (-) [reply] Created an attachment (id=1027) --> (http://bugs.meego.com/attachment.cgi?id=1027) [details] synthesis log Nokia seems to be pushing ovi a lot now, we'll probably want to talk to them... The settings aren't really advertized anywhere so I have no idea if Ovi even wants other clients than Nokia phones. In any case it does start syncing with this: Server URL: https://sync.ovi.com/services/syncml Addressbook URI: ./Contact/Unfiled Calendar URI: ./EventTask/Tasks Memo URI: ./Note/Unfiled Currently synthesis fails with: smlProcessData failed, returned 0x2011 - Jussi ------- Comment #1 From pohly 2009-06-08 07:16:55 PST (-) [reply] ------- Turning this into a feature request. I'm not sure about the priority: I suggest to work on the other server first and then check again. ------- Comment #2 From Zhiqiang 2009-07-13 20:16:59 PST (-) [reply] ------- Assign this bug to Congwu.. ------- Comment #3 From Chen Congwu 2009-07-15 01:12:25 PST (-) [reply] ------- The synthesis fail has gone but I could not successfully authenticate. It seems the username/pwd used during sync is not the same as ovi.com. Since Nokia has not provide access for PCs, I have no idea how to get a valid account. http://discussions.europe.nokia.com/discussions/board/message?board.id=ov... Jussi, do you have any idea? (In reply to comment #0) > Created an attachment (id=1027) --> (http://bugs.meego.com/attachment.cgi?id=1027) [details] [details] > synthesis log > > Nokia seems to be pushing ovi a lot now, we'll probably want to talk to them... > > The settings aren't really advertized anywhere so I have no idea if Ovi even > wants other clients than Nokia phones. In any case it does start syncing with > this: > > Server URL: https://sync.ovi.com/services/syncml > Addressbook URI: ./Contact/Unfiled > Calendar URI: ./EventTask/Tasks > Memo URI: ./Note/Unfiled > > Currently synthesis fails with: > smlProcessData failed, returned 0x2011 > > - Jussi ------- Comment #4 From Chen Congwu 2009-10-24 20:05:22 PST (-) [reply] ------- Suyog has provided some updates on the account setting: Ovi.com has added manual configurations. > Today I played around sync settings on my mobile and found out 1 thing. My previous understanding that "Manual settings don't work" is not entirely correct. I found out from OVI.com->Login->Add device > You have to specify your Nokia Phone Model and then enter your mobile number. > > After this OVI.com will send you config settings , you will need PIN to open config setting, this PIN is provided on web interface. > > But I found that they have mentioned , if you dont get config settings due to some reasons, you can create settings manually. I tried that option and found that the Password which was mentioned there for Sync setting is different from actual OVI password. This password looks like auto generated and different every time you add device. > > If you remove device and try to add it again with same number/model, password changes. > > This is the reason why Sync doesn't work in SyncEvolution. I am going to try using this password in SyncEvolution. All other settings are same as you have also mentioned in Bug 3182. > > See the following which I have copied from Add Device procedure on OVI.com, I have masked my password. ------- Comment #5 From Chen Congwu 2009-10-24 20:12:06 PST (-) [reply] ------- More from Suyog: (The manual settings you need to set up) > You can make the necessary synchronization settings for your device manually by following the instructions below: > > > > 1. Go to Sync menu on your device Usually the Sync menu is found from Menu grid/Tools or under Menu grid/Settings depending on your device. > > 2. Select and open "Sync" icon from the grid Press Options an select "New sync profile" from the opened view. DO NOT copy values from other profile. > > 3. Name the new profile or use the default name Select and open "Sync profile name" list item. Write the name to the opened text input field. > > 4. Select and open "Applications" list item Open each desired application from the list in turn.From the opened submenu, switch "Yes", if you want to synchronize the opened application. Set(write) the Remote Database as listed below for each application: > for Contacts: ./Contact/Unfiled > for Calendar: ./EventTask/Tasks > for Notes: ./Note/Unfiled > Set "Synchronization type" for each desired application to be "normal" or "both ways" (depending on the device). > > 5. Select and open "Connections settings" from the Sync profile list Set or write (depending on the setting) the following values: > Server version: Leave the default value > Server ID: Leave the default name > Data Bearer: Internet > Access point: Chose the internet access point > Host address: https://sync.ovi.com/services/syncml > Port: 443 > User name: suyog > Password: ****************** > Allow sync requests: Leave the default value > Accept all sync reqs.: Leave the default value > Network authentication: This setting depends on the details of your data connectivity service. If you select "Yes", you have to fill also your Nokia account username and password > > You have now done your sync settings for your device. To synchronize your device go back to the sync instructions screen by pressing the button below. > ------- Comment #6 From pohly 2009-10-26 06:03:44 PST (-) [reply] ------- That looks promising. Let's consider adding OVI as a supported service in SyncEvolution 1.0. We have many issues to work on for 1.0, so it's not the highest priority, though. Is there anything that can be done to make device setup easier for users? Not being able to find the password easily which is to be used could be a stumbling block for users. I can imagine several solutions, with varying degrees of effort involved: - add an OVI template in SyncEvolution - needs to be done in any case - change the OVI web site so that it clearly documents how to add SyncEvolution as device and what the password ist - when adding SyncEvolution in the web interface, send a "SyncML client configuration" with a specific MIME type that we could register SyncEvolution for, then create the configuration We don't have such a MIME type and config format at the moment. Would have to be defined, if there isn't anything that we can reuse. ------- Comment #7 From Chen Congwu 2009-10-26 21:29:30 PST (-) [reply] ------- Summarize status: Contacts works (Suyog): " Also I tried all 3 options , Merge, Delete local data and replace, Delete Server data and replace. All work very well with contacts, and with Memos , I get same rejections error but it deletes server data. " Memo content rejection: Client changes rejected by server and Server changed not reflected during client sync. I have tried both plain text and ical2.0. Not sure what the problem is. calendar (ical) works, I can sync both changes from server and changes from client. No task (itodo) url mentioned in the manual configuration settings, though there is a todo page in the web interface. As Suyog metioned: "Please note that in Nokia Phones , there is nothing defined separately for To-dos, somehow they are treated as part of Calendar( May be ./EventTasks/Tasks). Also as I use OpenSync to sync my phone over Bluetooth with Evolution, I noted that To-dos sync with Tasks in Evolution" I'm still have no idea how Nokia differentiate from calendar and tasks.. I am thinking that if we don't have server side operator support, we may get some hints by syncing nokia phone with our syncevolution server (seeing what behavior Nokia clients are behaving..) ------- Comment #8 From Chen Congwu 2009-10-28 18:06:00 PST (-) [reply] ------- More updates: Nokia stores calendar and tasks together in the client side and synced to to-dos and calendars in ovi.com. To support this, we need to (as pointed by Patrick): " Synthesis supports such a combined storage either directly (write a backend which handles both) or via a "superdatastore" which combines a backend for VEVENT and VTODO (see XML configuration guide). We need to support this in several ways: - configure a data source which maps to a superdatastore - figure out how to represent that in the GUI " ------- Comment #9 From jku 2009-11-20 05:27:38 PST (-) [reply] ------- (In reply to comment #8) > More updates: > Nokia stores calendar and tasks together in the client side and synced to > to-dos and calendars in ovi.com. > To support this, we need to (as pointed by Patrick): > " > Synthesis supports such a combined storage either directly (write a > backend which handles both) or via a "superdatastore" which combines a > backend for VEVENT and VTODO (see XML configuration guide). > > We need to support this in several ways: > - configure a data source which maps to a superdatastore > - figure out how to represent that in the GUI > " If this is a specific case, I can just special case "calendar+todo" in the GUI. First idea: Addressbook URI [ ] Calendar URI [ ] [ ] Calendar includes Tasks Tasks URI [ ] (The "tasks" line would be insensitive if the checkbutton is checked) Not sure what to do with unknown combined sources. ------- Comment #10 From jku 2010-02-08 14:08:33 PST (-) [reply] ------- Thought I'd update this wrt to GUI: virtual sources are supported (at least in jku-configuration-redesign branch) in the sense that they are shown in the main view and configuration and the 'underlying' sources should be hidden. ------- Comment #11 From pohly 2010-02-10 08:20:36 PST (-) [reply] ------- Congwu, have you ever successfully used a virtual source in a SyncML client? I'm trying it for the first time with SyncEvolution as both client and server and get a crash in sysync::TBinfileClientConfig::findOrCreateTargetIndexByDBInfo(). A virtual function call jumps to NULL: 2157 cfgP->initTarget(target,aProfileID,NULL,DEFAULT_DATASTORES_ENABLED); // init default I suspect that the following type cast was invalid: for (pos=fDatastores.begin();pos!=fDatastores.end();pos++) { TBinfileDSConfig *cfgP = static_cast<TBinfileDSConfig *>(*pos); I'm currently experimenting with adding a <dbtypeid> for a <superdatastore>. Not sure whether it'll make a difference. ------- Comment #12 From Chen Congwu 2010-02-10 18:19:34 PST (-) [reply] ------- (In reply to comment #0) Ah, The error still exists. I used wbxml before that's why the error did not occur. I have fixed this and posted to synthesis. > > Currently synthesis fails with: > smlProcessData failed, returned 0x2011 > > - Jussi ------- Comment #13 From Chen Congwu 2010-02-10 22:38:34 PST (-) [reply] ------- (In reply to comment #11) > Congwu, have you ever successfully used a virtual source in a SyncML client? No, not yet. You are right, it seg faults currently. > I'm trying it for the first time with SyncEvolution as both client and server > and get a crash in > sysync::TBinfileClientConfig::findOrCreateTargetIndexByDBInfo(). A virtual > function call jumps to NULL: > > 2157 > cfgP->initTarget(target,aProfileID,NULL,DEFAULT_DATASTORES_ENABLED); // init > default > > I suspect that the following type cast was invalid: > for (pos=fDatastores.begin();pos!=fDatastores.end();pos++) { > TBinfileDSConfig *cfgP = static_cast<TBinfileDSConfig *>(*pos); Yes, you are right. With a simple patch it works now, see my posts in synthesis mail list. ------- Comment #14 From pohly 2010-02-11 01:58:18 PST (-) [reply] ------- (In reply to comment #13) > (In reply to comment #11) > > Congwu, have you ever successfully used a virtual source in a SyncML client? > No, not yet. You are right, it seg faults currently. After fixing the segfault I end up with errors because the underlying sources get activated for the sync *as if they were normal active sources*. In other words, SyncEvolution as client tries to synchronize "calendar", "todo", and "calendar+todo" with the server all at once, instead of just synchronizing "calendar+todo" with the server. Congwu, unless you tell me otherwise I'll have a closer look. ------- Comment #15 From Chen Congwu 2010-03-07 23:28:57 PST (-) [reply] ------- I pushed the template and integration tests for Ovi to ovi branch, please review The key messages are: -- +* Know Limitations in Ovi server: +The server is unstable, during testing, it returns '400' error from time to +time. +The authentication process need 3 retries to success. +Delete in normal sync (including two-way, one-way-from-client) does not +effectively delete the data in the server, we can only use (refresh-+ from-client). because of this limitation, many cases failed. + Memo does not work (contents rejected both way) I used vcard30 for addressbook and vcalendar 1.0 for calendar+todo. ------- Comment #16 From pohly 2010-03-08 09:08:43 PST (-) [reply] ------- (In reply to comment #15) > +The authentication process need 3 retries to success. What does that mean for users? Does a user have to run syncevolution multiple times before it will eventually succeed? ------- Comment #17 From Chen Congwu 2010-03-08 16:54:23 PST (-) [reply] ------- (In reply to comment #16) > (In reply to comment #15) > > +The authentication process need 3 retries to success. > > What does that mean for users? Does a user have to run syncevolution multiple > times before it will eventually succeed? No, the retry process is automatic (just extra round of message and time) ------- Comment #18 From pohly 2010-03-09 10:02:34 PST (-) [reply] ------- I've merged this. Left to do: - add to nightly testing - discuss some of the known issues with Nokia - set "consumerReady" flag -- Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

9 years, 11 months

1
3
0 / 0

[Bug 1657] New: Nokia phones: absolute alarm time?

by bugzilla＠meego.com

http://bugs.meego.com/show_bug.cgi?id=1657 Summary: Nokia phones: absolute alarm time? Classification: MeeGo Projects Product: SyncEvolution Version: unspecified Platform: Netbook OS/Version: IA Status: ASSIGNED Severity: normal Priority: Undecided Component: SyncML AssignedTo: syncevolution-bugs(a)meego.bugs ReportedBy: patrick.ohly(a)intel.com QAContact: jingke.zhang(a)intel.com CC: syncevolution-bugs(a)meego.bugs, syncevolution-syncml-bugs(a)meego.bugs Estimated Hours: 0.0 At least the Nokia E55 is only able to deal with alarm times in UTC. A new src/syncevo/configs/remoterules/server/46_E55.xml rule enables the conversion to UTC, similar to how it was done before for Mobical. The open question is whether *all* Nokia phones should get this treatment, unless specified otherwise explicitly. Need to ask Nokia. -- Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

10 years, 2 months

1
5
0 / 0

[Bug 1245] New: [ERROR] http://server_url:8080/funambol/ds via libsoup: Not Found

by bugzilla＠meego.com

http://bugs.meego.com/show_bug.cgi?id=1245 Summary: [ERROR] http://server_url:8080/funambol/ds via libsoup: Not Found Classification: MeeGo Projects Product: SyncEvolution Version: unspecified Platform: Netbook OS/Version: IA Status: NEW Severity: normal Priority: Undecided Component: SyncEvolution AssignedTo: syncevolution-bugs(a)meego.bugs ReportedBy: juergenoschumacher(a)gmx.de QAContact: jingke.zhang(a)intel.com CC: syncevolution-bugs(a)meego.bugs, syncevolution-default-bugs(a)meego.bugs Estimated Hours: 0.0 Server-System: Ubuntu Linux Server, 9.10 Client-System: Ubuntu Linux Desktop, 9.10 [ERROR] http://server_url:8080/funambol/ds via libsoup: Not Found [INFO] todo: normal sync done unsuccessfully [INFO] addressbook: normal sync done unsuccessfully [INFO] calendar: normal sync done unsuccessfully [INFO] memo: normal sync done unsuccessfully Synchronization failed, see /home/schm/.cache/syncevolution/funambol-2010-04-23-15-07/sysynclib_linux.html for details. Changes applied during synchronization: +---------------|-------ON CLIENT-------|-------ON SERVER-------|-CON-+ | | rejected / total | rejected / total | FLI | | Source | NEW | MOD | DEL | NEW | MOD | DEL | CTS | +---------------+-------+-------+-------+-------+-------+-------+-----+ | addressbook | 0/0 | 0/0 | 0/0 | 0/0 | 0/0 | 0/0 | 0 | | item(s) in database backup: 2052 before sync, 2052 after it | +---------------+-------+-------+-------+-------+-------+-------+-----+ | calendar | 0/0 | 0/0 | 0/0 | 0/0 | 0/0 | 0/0 | 0 | | item(s) in database backup: 5039 before sync, 5039 after it | +---------------+-------+-------+-------+-------+-------+-------+-----+ | memo | 0/0 | 0/0 | 0/0 | 0/0 | 0/0 | 0/0 | 0 | | item(s) in database backup: 791 before sync, 791 after it | +---------------+-------+-------+-------+-------+-------+-------+-----+ | todo | 0/0 | 0/0 | 0/0 | 0/0 | 0/0 | 0/0 | 0 | | item(s) in database backup: 17 before sync, 17 after it | +---------------+-------+-------+-------+-------+-------+-------+-----+ | start Fri Apr 23 15:07:07 2010, duration 3:53min | | synchronization failed (status code 20043) | +---------------+-------+-------+-------+-------+-------+-------+-----+ Output of the file: funambol-2010-04-23-15-07/sysynclib_linux.html Start of log - Synthesis SyncML Engine 3.2.0.32 * [-- collapse all --][++ expand all ++] * [2010-04-23 15:07:07.642] SyncML server account: schm * [2010-04-23 15:07:07.642] client: SyncEvolution 0.9 for desktop ... # [2010-04-23 15:10:04.293] 'DSStateChange' - Datastore changes state, datastore=memo, oldstate=client_sent_alert, newstate=completed [--][++] [->end] * [2010-04-23 15:10:04.293] Sync Statistics for 'memo' (), normal sync * [2010-04-23 15:10:04.293] ================================================== on Client on Server Added: 0 0 Deleted: 0 0 Updated: 0 0 Rejected with error: 0 0 Content Data Bytes sent: 0 Content Data Bytes received: 0 Duration of sync [seconds]: 0 * [2010-04-23 15:10:04.294] Warning: Failed with status code=20017, statistics are incomplete!! –[2010-04-23 15:10:04.294] End of 'DSStateChange' [->top] # + – [2010-04-23 15:10:04.294] 'DSStateChange' - Datastore changes state, datastore=memo, oldstate=completed, newstate=idle [--][++] [->end] * [2010-04-23 15:10:04.294] endDataWrite called, write not started –[2010-04-23 15:10:04.294] End of 'DSStateChange' [->top] # [2010-04-23 15:10:04.294] Never received status for command 'SyncHdr', (outgoing MsgID=1, CmdID=0) # [2010-04-23 15:10:04.294] Deleted command 'SyncHdr' (outgoing MsgID=1, CmdID=0) # [2010-04-23 15:10:04.295] Never received status for command 'Put', (outgoing MsgID=1, CmdID=1) # [2010-04-23 15:10:04.295] Deleted command 'Put' (outgoing MsgID=1, CmdID=1) # [2010-04-23 15:10:04.295] Never received status for command 'Get', (outgoing MsgID=1, CmdID=2) # [2010-04-23 15:10:04.295] Deleted command 'Get' (outgoing MsgID=1, CmdID=2) # [2010-04-23 15:10:04.295] Never received status for command 'Alert', (outgoing MsgID=1, CmdID=3) # [2010-04-23 15:10:04.295] Deleted command 'Alert' (outgoing MsgID=1, CmdID=3) # [2010-04-23 15:10:04.295] Never received status for command 'Alert', (outgoing MsgID=1, CmdID=4) # [2010-04-23 15:10:04.295] Deleted command 'Alert' (outgoing MsgID=1, CmdID=4) # [2010-04-23 15:10:04.295] Never received status for command 'Alert', (outgoing MsgID=1, CmdID=5) # [2010-04-23 15:10:04.295] Deleted command 'Alert' (outgoing MsgID=1, CmdID=5) # [2010-04-23 15:10:04.295] Never received status for command 'Alert', (outgoing MsgID=1, CmdID=6) # [2010-04-23 15:10:04.295] Deleted command 'Alert' (outgoing MsgID=1, CmdID=6) # [2010-04-23 15:10:04.296] --------- END of embedded log for session ID '212138831404169' --------- -- Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

10 years, 2 months

1
6
0 / 0

[Bug 1366] New: automatic sync - improved startup on Moblin

by bugzilla＠meego.com

http://bugs.meego.com/show_bug.cgi?id=1366 Summary: automatic sync - improved startup on Moblin Classification: MeeGo Projects Product: SyncEvolution Version: unspecified Platform: Netbook OS/Version: IA Status: ASSIGNED Severity: normal Priority: Low Component: SyncEvolution AssignedTo: yongsheng.zhu(a)intel.com ReportedBy: jingke.zhang(a)intel.com QAContact: jingke.zhang(a)intel.com CC: syncevolution-bugs(a)meego.bugs, syncevolution-default-bugs(a)meego.bugs Estimated Hours: 0.0 This is from http://bugzilla.moblin.org/show_bug.cgi?id=10335 Description From pohly 2010-03-22 02:48:31 PST (-) [reply] Currently we use a shell wrapper script around syncevo-dbus-server with a "sleep 60" inside to prevent starting the daemon right away at user login. It turned out that in Moblin and thus MeeGo there is a better way: - add X-Moblin-Priority = Late to the .desktop file - start the syncevo-dbus-server directly I'm uncertain how important doing this is. We have a working solution which is currently getting reviewed by QA which also works in other distros. On the other hand, packaging an extra file is a nuisance and costs some small amount of CPU time at startup. Yongsheng, what do you think? -- Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.

10 years, 2 months

1
2
0 / 0

[Bug 1354] New: EDS: protect against concurrent editing + revision handling

by bugzilla＠meego.com

http://bugs.meego.com/show_bug.cgi?id=1354 Summary: EDS: protect against concurrent editing + revision handling Classification: MeeGo Projects Product: SyncEvolution Version: unspecified Platform: Netbook OS/Version: IA Status: ASSIGNED Severity: normal Priority: High Component: SyncEvolution AssignedTo: ross(a)linux.intel.com ReportedBy: jingke.zhang(a)intel.com QAContact: jingke.zhang(a)intel.com CC: syncevolution-bugs(a)meego.bugs, syncevolution-default-bugs(a)meego.bugs Estimated Hours: 0.0 This is from http://bugzilla.moblin.org/show_bug.cgi?id=3479 Description From pohly 2009-06-12 09:21:04 PST (-) [reply] If a user edits items while a synchronization is running, then all kinds of "interesting" things can happen: change is overwritten by server change (definitely!), change is made locally but never sent to server (not so sure), ... Part of the problem is that the EDS API is prone to race conditions. This needs to be fixed first, as discussed with the EDS developers: http://www.mail-archive.com/evolution-hackers@gnome.org/msg03029.html Since that discussion I have implemented automatic restore from backup, which has changed my view on the necessary APIs a bit: it would be nice to store items with a specific REV or LAST-MODIFIED if the libebook/libecal user knows what he is doing. Not bumping these fields when restoring an items has the advantage that other clients which were in sync with the restored data don't see any unnecessary changes. The other part of the problem is getting a set of item ID + revision string (REV for contacts, LAST-MODIFIED for event/tasks) in an atomic way. I'm not sure whether the current methods are really atomic. But worse, they are also much slower than they could be because we have to transmit the whole content of the database via D-Bus just to extract the much smaller set of required information. Ross wanted to work on a call to return pairs of UID+REV for libebook. I don't think he got very far with that, though. I think this is a fairly import optimization. ------- Comment #1 From Chen Congwu 2009-08-06 01:16:53 PST (-) [reply] ------- I will look at it. ------- Comment #2 From Chen Congwu 2009-08-09 22:22:42 PST (-) [reply] ------- I have several questions regarding the api implementation. Do we need to impl this concurrent feature for all backends? (groupwise, google, exchange, etc.) When is eds-dbus port ready? Do we need work on this feature on both bonobo and dbus? If so, which one has more priority? [1] http://mail.gnome.org/archives/evolution-hackers/2009-August/msg00004.html (In reply to comment #0) > If a user edits items while a synchronization is running, then all kinds of > "interesting" things can happen: change is overwritten by server change > (definitely!), change is made locally but never sent to server (not so sure), > ... > > Part of the problem is that the EDS API is prone to race conditions. This needs > to be fixed first, as discussed with the EDS developers: > http://www.mail-archive.com/evolution-hackers@gnome.org/msg03029.html > > Since that discussion I have implemented automatic restore from backup, which > has > changed my view on the necessary APIs a bit: it would be nice to store > items with a specific REV or LAST-MODIFIED if the libebook/libecal user > knows what he is doing. Not bumping these fields when restoring an items > has the advantage that other clients which were in sync with the > restored data don't see any unnecessary changes. > > The other part of the problem is getting a set of item ID + revision string > (REV for contacts, LAST-MODIFIED for event/tasks) in an atomic way. I'm not > sure whether the current methods are really atomic. But worse, they are also > much slower than they could be because we have to transmit the whole content of > the database via D-Bus just to extract the much smaller set of required > information. > > Ross wanted to work on a call to return pairs of UID+REV for libebook. I don't > think he got very far with that, though. I think this is a fairly import > optimization. ------- Comment #3 From pohly 2009-08-10 02:17:11 PST (-) [reply] ------- (In reply to comment #2) > Do we need to impl this concurrent feature for all backends? (groupwise, > google, exchange, etc.) Doing it for the file backend would be enough. > When is eds-dbus port ready? Ross, what is the timeline for merging this into master? > Do we need work on this feature on both bonobo and > dbus? If so, which one has more priority? I'd say D-Bus is more important, but I don't think upstream would merge this unless we also do Bonobo/CORBA - it remains alive. Ross, do you know what the plans are regarding that? ------- Comment #4 From Ross Burton 2009-08-10 02:28:49 PST (-) [reply] ------- We're merging the addressbook port in the next week or so, but I expect moblin 2.1 to ship eds-dbus still. Please work on eds-dbus first so that we can ship this code. ------- Comment #5 From pohly 2009-08-10 03:14:18 PST (-) [reply] ------- (In reply to comment #4) > We're merging the addressbook port in the next week or so, but I expect moblin > 2.1 to ship eds-dbus still. > > Please work on eds-dbus first so that we can ship this code. Is that the "dbus" branch in git.gnome.org? Do you rebase that branch or is it safe to pull from it and create the new API in a feature branch based on the "dbus" branch? ------- Comment #6 From Ross Burton 2009-08-10 06:41:35 PST (-) [reply] ------- At present, and I expect for 2.1 unless magic happens, we're shipping eds-dbus from git.o-hand.com. ------- Comment #7 From Chen Congwu 2009-08-10 18:24:46 PST (-) [reply] ------- So I will work on this repo and provide patch against this. (In reply to comment #6) > At present, and I expect for 2.1 unless magic happens, we're shipping eds-dbus > from git.o-hand.com. ------- Comment #8 From Chen Congwu 2009-08-11 18:13:27 PST (-) [reply] ------- After reading the eds-dbus code, I suspect "RETURN-REV" capability can't be implemented for existing non-atomic calls. The reason is: the dbus call does not return "revision" or "Contact", the changed item is asynchronously popped up by another signal ("contacts-changed", etc.). What's worse, the signal has a buffering mechanism, it will not emit as soon as a contact is changed(maybe delayed to a later point to pop up a batch of changes). Two solutions: 1) change the dbus interface (incompatible) 2) Use the workaround which was used by syncevolution in libebook (get the whole contact again by another dbus call, which still can not guarantee the correct semantic (the contacts may already be changed by another client). I suggest not support "RETURN-REV" capability in existing non-atomic calls. For the new added atomic calls, we can use a different dbus interface which will return the "revision" information from the dbus method call. Ross and Patrick, do you think so? ------- Comment #9 From pohly 2009-08-11 23:36:23 PST (-) [reply] ------- (In reply to comment #8) > After reading the eds-dbus code, I suspect "RETURN-REV" capability can't be > implemented for existing non-atomic calls. > > The reason is: the dbus call does not return "revision" or "Contact", the > changed item is asynchronously popped up by another signal ("contacts-changed", > etc.). What's worse, the signal has a buffering mechanism, it will not emit as > soon as a contact is changed(maybe delayed to a later point to pop up a batch > of changes). > Two solutions: 1) change the dbus interface (incompatible) Isn't that interface EDS internal anyway and thus can be changed as necessary? Packagers must be sure to not put incompatible libebook and EDS on the same system, but that has always been the case. That packagers sometimes forgot about the necessary "conflicts" entries in their packages is a different problem... > For > the new added atomic calls, we can use a different dbus interface which will > return the "revision" information from the dbus method call. Using different communication paths with EDS to implement the old and new update/delete calls smells like unnecessary code duplication to me. I'd rather extend the protocol so that it works for the more advanced new calls and then map the old ones to the new ones in libebook (they are intentionally strict subsets). ------- Comment #10 From Ross Burton 2009-08-12 00:20:17 PST (-) [reply] ------- I've been telling everyone who wants to talk to EDS via DBus directly not to because the protocol isn't stable, and this is exactly why. We can change the DBus protocol easily, what would the exact changes be? ------- Comment #11 From Chen Congwu 2009-08-12 00:47:52 PST (-) [reply] ------- Thant's good, so I will change the dbus api. The modification apis(create,remove,modify) need be extended to: 1) return the new rev in the dbus call 2) add a new input parameter "flags" to indicate different semantics (ignore rev check, use rev check and do not update rev) Another thing is can I take this assumption also to the backends? That is can I modify existing backends apis instead of adding new apis? Personally I don't think so (The backends api is not internal, there maybe third party backend implementations existed). (In reply to comment #10) > I've been telling everyone who wants to talk to EDS via DBus directly not to > because the protocol isn't stable, and this is exactly why. We can change the > DBus protocol easily, what would the exact changes be? ------- Comment #12 From Ross Burton 2009-08-12 02:28:21 PST (-) [reply] ------- The backend API is meant to be somewhat stable, but we've broken it anyway for the DBus branch so if you want to break it more, do it soon! ------- Comment #13 From Chen Congwu 2009-08-21 08:27:40 PST (-) [reply] ------- Created an attachment (id=2325) --> (http://bugs.meego.com/attachment.cgi?id=2325) [details] patch set for this issue Ross & Patrick, this is the patch I provided for this issue, could you please help review? ------------- This patch set aims at solve eds atomic modification problem, see posts in evolution-hackers mailing list. The first 3 patches are api changes. The next 8 patches are: 0004 addressbook libebook (dbus client) new api implementation 0005 addressbook libedata-book (dbus serivce) new api implementation 0006 addressbook file backend new api implementation 0007 addressbook unit test 0008 calendar libecal (dbus client) new api implementation 0009 calendar libedata-cal (dbus service) new api implementaion 0010 calendar file backend new api implementaion 0011 calendar unit test Interface changes and impact: 1. Dbus api has been extended. Applications use dbus directly will break 2. Backend virtual method has been changed. Old backends has to be changed according to work with the new api (Even if it does not provide the new capability) 3. libebook api has a small change (subjet to change): For the async modification apis, "return-rev" capability requires the new revision information be returned to client by the user-supplied callback. Therefore the callback function is changed to add another input parameter. Mutlti-thread problems: Added a multi-thread test for addressbook, see patch 0007. The test fails because of a known bug in libdbus (Phantom OOM). With a patch found in the mailinglist, the test can pass but sometimes client will block a while. Seems this is also caused by libdbus or glib binding. ------- Comment #14 From pohly 2009-10-22 06:29:29 PST (-) [reply] ------- Without this feature, running syncs in the background is risky because of the race conditions. ------- Comment #15 From Chen Congwu 2009-10-24 20:09:43 PST (-) [reply] ------- More from Suyog: (The manual settings you need to set up) > You can make the necessary synchronization settings for your device manually by following the instructions below: > > > > 1. Go to Sync menu on your device Usually the Sync menu is found from Menu grid/Tools or under Menu grid/Settings depending on your device. > > 2. Select and open "Sync" icon from the grid Press Options an select "New sync profile" from the opened view. DO NOT copy values from other profile. > > 3. Name the new profile or use the default name Select and open "Sync profile name" list item. Write the name to the opened text input field. > > 4. Select and open "Applications" list item Open each desired application from the list in turn.From the opened submenu, switch "Yes", if you want to synchronize the opened application. Set(write) the Remote Database as listed below for each application: > for Contacts: ./Contact/Unfiled > for Calendar: ./EventTask/Tasks > for Notes: ./Note/Unfiled > Set "Synchronization type" for each desired application to be "normal" or "both ways" (depending on the device). > > 5. Select and open "Connections settings" from the Sync profile list Set or write (depending on the setting) the following values: > Server version: Leave the default value > Server ID: Leave the default name > Data Bearer: Internet > Access point: Chose the internet access point > Host address: https://sync.ovi.com/services/syncml > Port: 443 > User name: suyog > Password: ****************** > Allow sync requests: Leave the default value > Accept all sync reqs.: Leave the default value > Network authentication: This setting depends on the details of your data connectivity service. If you select "Yes", you have to fill also your Nokia account username and password > > You have now done your sync settings for your device. To synchronize your device go back to the sync instructions screen by pressing the button below. > ------- Comment #16 From Chen Congwu 2009-10-24 20:11:17 PST (-) [reply] ------- (In reply to comment #15) Sorry, I just copy & pasted to a wrong bug entry... ------- Comment #17 From pohly 2009-11-25 00:56:44 PST (-) [reply] ------- Ross, as I said in our chat, we need to decide how to move forward with this patches because they are needed for automatic sync. Therefore I am raising the priority to P1 temporarily and assign this to you. Next steps: * check as many of the patches as you can * rebase/update remaining patches according to your comments * create bugzilla.gnome.org and request inclusion there (?) ------- Comment #18 From Ross Burton 2009-12-02 04:03:24 PST (-) [reply] ------- As we'll shortly be switched to eds from upstream master, would it be possible to rebase these patches on evolution-data-server from git.gnome.org? ------- Comment #19 From Chen Congwu 2009-12-02 21:44:00 PST (-) [reply] ------- Ok, I will do this, you may have to wait 1~2 days as the patch is a little large. (In reply to comment #18) > As we'll shortly be switched to eds from upstream master, would it be possible > to rebase these patches on evolution-data-server from git.gnome.org? ------- Comment #20 From Chen Congwu 2009-12-06 01:18:24 PST (-) [reply] ------- (In reply to comment #19) Done, you may pull from http://mob-sync1.sh.intel.com/evolution-data-server.git > Ok, I will do this, you may have to wait 1~2 days as the patch is a little > large. > > (In reply to comment #18) > > As we'll shortly be switched to eds from upstream master, would it be possible > > to rebase these patches on evolution-data-server from git.gnome.org? ------- Comment #21 From Chen Congwu 2010-01-10 22:07:00 PST (-) [reply] ------- (In reply to comment #20) Ross, do you have any plan for reviewing this? > (In reply to comment #19) > Done, you may pull from > http://mob-sync1.sh.intel.com/evolution-data-server.git > > > Ok, I will do this, you may have to wait 1~2 days as the patch is a little > > large. > > > > (In reply to comment #18) > > > As we'll shortly be switched to eds from upstream master, would it be possible > > > to rebase these patches on evolution-data-server from git.gnome.org? -- Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.

10 years, 3 months

1
2
0 / 0

[Bug 1356] New: extend vCard field list (Memotoo, ScheduleWorld)

by bugzilla＠meego.com

http://bugs.meego.com/show_bug.cgi?id=1356 Summary: extend vCard field list (Memotoo, ScheduleWorld) Classification: MeeGo Projects Product: SyncEvolution Version: unspecified Platform: Netbook OS/Version: IA Status: ASSIGNED Severity: normal Priority: Medium Component: SyncML AssignedTo: syncevolution-bugs(a)meego.bugs ReportedBy: jingke.zhang(a)intel.com QAContact: jingke.zhang(a)intel.com CC: syncevolution-bugs(a)meego.bugs, syncevolution-syncml-bugs(a)meego.bugs Estimated Hours: 0.0 This is from http://bugzilla.moblin.org/show_bug.cgi?id=6303 Description From pohly 2009-09-21 07:45:26 PST (-) [reply] Please include a detailed description as well as steps to reproduce the bug. The following vCard properties are in use by Memotoo: X-SKYPE-USERNAME:skype id X-EVOLUTION-ASSISTANT-TEL:assistant's phone X-EVOLUTION-PARENT:parents X-EVOLUTION-CHILDREN:children X-SYNCEVOLUTION-FBURL:http://www.memotoo.com/contactsIFB.php?uid=73fc9832... None of them are currently detected by the Synthesis config. We need to do three things: 1. figure out how we can have properties in the main configuration which are not supported by the active backend 2. add X-SKYPE-USERNAME, X-EVOLUTION-PARENT, X-EVOLUTION-CHILDREN, X-EVOLUTION-ASSISTANT-TEL; see bug #3473 3. map between X-SYNCEVOLUTION-FBURL and FBURL, see X-[EVOLUTION-]SPOUSE Adding the new properties without solving 1 has the undesirable effect that the SyncML server gets wrong information about the client, because the DevInf would include properties not supported by the data source. ------- Comment #1 From pohly 2009-09-23 07:37:35 PST (-) [reply] ------- ScheduleWorld also supports setting a timezone for the user, which is then sent as the TZ property. This falls into the same category as X-SKYPE-USERNAME: we want it in the field list and file backend, but not in Evolution (not supported there). -- Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

10 years, 3 months

1
1
0 / 0

[Bug 1367] New: nightly testing: include SyncEvolution <-> SyncEvolution testing

by bugzilla＠meego.com

http://bugs.meego.com/show_bug.cgi?id=1367 Summary: nightly testing: include SyncEvolution <-> SyncEvolution testing Classification: MeeGo Projects Product: SyncEvolution Version: unspecified Platform: Netbook OS/Version: IA Status: ASSIGNED Severity: normal Priority: Medium Component: SyncEvolution AssignedTo: syncevolution-bugs(a)meego.bugs ReportedBy: jingke.zhang(a)intel.com QAContact: jingke.zhang(a)intel.com CC: syncevolution-bugs(a)meego.bugs, syncevolution-default-bugs(a)meego.bugs Estimated Hours: 0.0 This is from http://bugzilla.moblin.org/show_bug.cgi?id=10344 Description From pohly 2010-03-22 06:28:44 PST (-) [reply] Since BMO#2425 was fixed, our own server is the first to pass all suspend/resume/resend tests. We should include that in our nightly testing, to ensure that we don't break this later on. Need to figure out how to start the server while testing. We should also capture the server's log files and copy them into the corresponding client log dir (see CLIENT_TEST_LOG) so that failure analysis becomes easier. -- Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug.

10 years, 3 months

1
1
0 / 0

[Bug 1352] New: local timezone

by bugzilla＠meego.com

http://bugs.meego.com/show_bug.cgi?id=1352 Summary: local timezone Classification: MeeGo Projects Product: SyncEvolution Version: unspecified Platform: Netbook OS/Version: IA Status: ASSIGNED Severity: normal Priority: Medium Component: SyncML AssignedTo: congwu.chen(a)intel.com ReportedBy: jingke.zhang(a)intel.com QAContact: jingke.zhang(a)intel.com CC: syncevolution-bugs(a)meego.bugs, syncevolution-syncml-bugs(a)meego.bugs Estimated Hours: 0.0 This is from http://bugzilla.moblin.org/show_bug.cgi?id=3477 Description From pohly 2009-06-12 09:06:13 PST (-) [reply] The Synthesis engine needs to know the local time zone of its environment when working with events that don't have a specific time zone declared. When using iCalendar 2.0, this should happen that often. The local time zone check in libsynthesis is rather crude: it's only based on the time offsets against GMT. Better use http://chrislord.net/docs/libjana-ecal/libjana-ecal-jana-ecal-utils.html jana_ecal_utils_guess_location() to find the exact location and then use the corresponding libical timezone. This needs to be configurable, so we need to improve the Synthesis configure script first (bug #3471). ------- Comment #1 From pohly 2009-12-02 00:45:49 PST (-) [reply] ------- (In reply to comment #0) > The Synthesis engine needs to know the local time zone of its environment when > working with events that don't have a specific time zone declared. When using > iCalendar 2.0, this should happen that often. ... should *not* happen that often... ------- Comment #2 From pohly 2009-12-02 04:40:57 PST (-) [reply] ------- Congwu, you ran into this when testing with a phone, right? So it seems that is a bit more important than originally anticipated, raising priority and pulling it into 1.0. Congwu, do you have time for this or should I ask someone else, like Raji? ------- Comment #3 From Chen Congwu 2009-12-07 18:07:11 PST (-) [reply] ------- (In reply to comment #2) > Congwu, you ran into this when testing with a phone, right? So it seems that is > a bit more important than originally anticipated, raising priority and pulling > it into 1.0. > Yes, but detecting local timezone does not have direct effect on phone syncing.. 1) If the phone does not support UTC time, the engine needs to use 'UserTimezone' (That is the timezone for the phone) when syncing not 'SystemTimeZone'. 2) If the phone supports UTC time, the engine can send UTC time. In my case, the N7210c did not declare support 'UTC' in devinf and 'UserTimeZone' defaults to 'SystemTimeZone', this then triggered the problem. After Lukas pointed out some phones just forget to declare 'UTC', I tries and it solved my problem now. Considering this is a bug need to be fixed but not very high priority. I will come up with this later when ready. -- Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.

10 years, 3 months

1
1
0 / 0

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Syncevolution-issues May 2010