[Bug 2422] Funambol: enable and test calendar and tasks
by bugzilla@moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=2422
--- Comment #74 from pohly <patrick.ohly(a)intel.com> 2009-07-23 02:27:51 ---
(In reply to comment #73)
> > delete*** glibc detected *** client-test: double free or corruption (fasttop):
> > 0x09a62458 ***
> > ======= Backtrace: =========
> > /lib/libc.so.6[0x4f128894]
> > /lib/libc.so.6(cfree+0x96)[0x4f12a876]
> > /usr/lib/libical.so.0(icalmemory_add_tmp_buffer+0x37)[0x4e3e40b6]
> > /usr/lib/libical.so.0(icalcomponent_as_ical_string+0x25)[0x4e3e2e51]
> > /usr/lib/libsynthesis.so.0[0x4e5d66d2]
> > /usr/lib/libsynthesis.so.0[0x4e5a92e6]
> It should be a memory double free bug of libical.
This is similar to #4576. A workaround which avoids
icalcomponent_as_ical_string is already in the beta 3, so I hope that you won't
run into this anymore.
> I tested it with libecal and
> it could be passed. Maybe we need find the root cause and deliver a patch for
> this issue or directly report bug to them?
There's been a lot of activity on fixing libical memory handling by someone
from Nokia which did not yet go into the libical that we are using. I don't
think we need to do anything further.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
13 years, 1 month
[Bug 4126] ScheduleWorld: data not in sync between server and client (after contact delete on server)
by bugzilla@moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=4126
--- Comment #10 from pohly <patrick.ohly(a)intel.com> 2009-07-23 01:15:25 ---
(In reply to comment #9)
> (In reply to comment #1)
> > run in slow mode could sync item from client to server (client-win)
> > $syncevolution --run -s slow test
> > now, server and client both have one item
> >
> > and then delete the item on server and run two-way still have problem:
> > $syncevolution --run -s two-way test
> > now sever has no item and client remains one item, the status of server and
> > client is not synchronized.
>
> After execute the first step (one-way-client and two-way), then running slow
> mode will let server/device sync, but then still have problem:
> 1. delete the item on server
> 2. $syncevolution --run -s two-way test
> now sever has no item and client remains one item, the status of server and
> client is not synchronized.
>
> This is always existed after refresh the page, seems the sync status is not
> correct after one-way-client, and can't be reset by slow mode sync.
Please create a new issue for this, including all steps that are necessary to
trigger it. I agree that a slow sync should get client and server into sync, so
that the delete on the server afterwards should be propagated to the client.
That the server doesn't do that is a bug.
This is different from the original description because of the intermediate
slow sync.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
13 years, 1 month
[Bug 4638] New: Google: Large contact picture can not synced to google
by bugzilla@moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=4638
Summary: Google: Large contact picture can not synced to google
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: NEW
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: patrick.ohly(a)intel.com
ReportedBy: guannan.ou(a)intel.com
QAContact: yanshuang.zheng(a)intel.com
CC: shuang.wan(a)intel.com, syncevolution(a)lists.intel.com,
congwu.chen(a)intel.com
---------------------------
Summary
---------------------------
Large contact picture can not synced to google.
---------------------------
Detail
---------------------------
In two-way sync, added contact with picture size 220k will synced to google
without the picture. While added contact with picture size 770 bytes will
synced to google with the picture.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
13 years, 1 month
[Bug 2422] Funambol: enable and test calendar and tasks
by bugzilla@moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=2422
--- Comment #73 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-07-23 00:49:47 ---
> delete*** glibc detected *** client-test: double free or corruption (fasttop):
> 0x09a62458 ***
> ======= Backtrace: =========
> /lib/libc.so.6[0x4f128894]
> /lib/libc.so.6(cfree+0x96)[0x4f12a876]
> /usr/lib/libical.so.0(icalmemory_add_tmp_buffer+0x37)[0x4e3e40b6]
> /usr/lib/libical.so.0(icalcomponent_as_ical_string+0x25)[0x4e3e2e51]
> /usr/lib/libsynthesis.so.0[0x4e5d66d2]
> /usr/lib/libsynthesis.so.0[0x4e5a92e6]
It should be a memory double free bug of libical. I tested it with libecal and
it could be passed. Maybe we need find the root cause and deliver a patch for
this issue or directly report bug to them?
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
13 years, 1 month
[Bug 2422] Funambol: enable and test calendar and tasks
by bugzilla@moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=2422
yuering <guannan.ou(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |guannan.ou(a)intel.com
--- Comment #72 from yuering <guannan.ou(a)intel.com> 2009-07-23 00:44:03 ---
netbook image: moblin-netbook-beta-refresh-20090721-001
syncevolution version: Syncevolution 0.8.1+0.9+beta2+20090717
In netbook, we come across the following issue when testing
Client::Sync::ical20::testDelete. The issue block verifing this bug.
delete*** glibc detected *** client-test: double free or corruption (fasttop):
0x09a62458 ***
======= Backtrace: =========
/lib/libc.so.6[0x4f128894]
/lib/libc.so.6(cfree+0x96)[0x4f12a876]
/usr/lib/libical.so.0(icalmemory_add_tmp_buffer+0x37)[0x4e3e40b6]
/usr/lib/libical.so.0(icalcomponent_as_ical_string+0x25)[0x4e3e2e51]
/usr/lib/libsynthesis.so.0[0x4e5d66d2]
/usr/lib/libsynthesis.so.0[0x4e5a92e6]
/usr/lib/libsynthesis.so.0[0x4e543da0]
/usr/lib/libsynthesis.so.0[0x4e564ee4]
/usr/lib/libsynthesis.so.0[0x4e5d565e]
/usr/lib/libsynthesis.so.0[0x4e5d7502]
/usr/lib/libsynthesis.so.0[0x4e5d7592]
/usr/lib/libsynthesis.so.0[0x4e596487]
/usr/lib/libsynthesis.so.0[0x4e5d5407]
/usr/lib/libsynthesis.so.0(SySync_ConnectEngine+0x48)[0x4e596846]
/usr/lib/syncevolution/libsyncevolution.so.0(_ZN6sysync10UI_ConnectERPNS_17SDK_InterfaceTypeERPvPKcmt+0x24a)[0x4e4d5465]
/usr/lib/syncevolution/libsyncevolution.so.0(_ZN6sysync19TEngineModuleBridge4InitEv+0x3b)[0x4e4d410b]
/usr/lib/syncevolution/libsyncevolution.so.0(_ZN6sysync17TEngineModuleBase7ConnectESsmt+0x8c)[0x4e4d596a]
/usr/lib/syncevolution/libsyncevolution.so.0(_ZN12SharedEngine7ConnectERKSsmt+0x3b)[0x4e4a055f]
/usr/lib/syncevolution/libsyncevolution.so.0(_ZN19EvolutionSyncClient12createEngineEv+0x6f)[0x4e4b3a13]
/usr/lib/syncevolution/libsyncevolution.so.0(_ZN19EvolutionSyncClient4syncEP10SyncReport+0x23c)[0x4e4b88c8]
client-test(_ZN13TestEvolution6doSyncEPKiRKSsRK11SyncOptions+0x22a)[0x8063954]
client-test(_ZN9SyncTests6doSyncERK11SyncOptions+0x1fc)[0x80a9ed8]
client-test(_ZN9SyncTests6doSyncEPKcRK11SyncOptions+0x55)[0x80f2647]
client-test(_ZN9SyncTests10testDeleteEv+0x128)[0x80ec468]
/usr/lib/libcppunit-1.12.so.1(_ZNK7CppUnit21TestCaseMethodFunctorclEv+0x2b)[0xb7fdbcf5]
/usr/lib/libcppunit-1.12.so.1(_ZN7CppUnit16DefaultProtector7protectERKNS_7FunctorERKNS_16ProtectorContextE+0x20)[0xb7fd461c]
/usr/lib/libcppunit-1.12.so.1(_ZNK7CppUnit14ProtectorChain14ProtectFunctorclEv+0x18)[0xb7fd9bf0]
/usr/lib/libcppunit-1.12.so.1(_ZN7CppUnit14ProtectorChain7protectERKNS_7FunctorERKNS_16ProtectorContextE+0x1f7)[0xb7fd98f3]
/usr/lib/libcppunit-1.12.so.1(_ZN7CppUnit10TestResult7protectERKNS_7FunctorEPNS_4TestERKSs+0x44)[0xb7fe11f2]
/usr/lib/libcppunit-1.12.so.1(_ZN7CppUnit8TestCase3runEPNS_10TestResultE+0x10a)[0xb7fdbbb4]
/usr/lib/libcppunit-1.12.so.1(_ZN7CppUnit10TestResult7runTestEPNS_4TestE+0x1d)[0xb7fe0d13]
/usr/lib/libcppunit-1.12.so.1(_ZN7CppUnit10TestRunner3runERNS_10TestResultERKSs+0x39)[0xb7fe2cb1]
/usr/lib/libcppunit-1.12.so.1(_ZN7CppUnit14TextTestRunner3runERNS_10TestResultERKSs+0x20)[0xb7fe4bcc]
/usr/lib/libcppunit-1.12.so.1(_ZN7CppUnit14TextTestRunner3runESsbbb+0x57)[0xb7fe4c75]
client-test(main+0x2e9)[0x80f4a6a]
/lib/libc.so.6(__libc_start_main+0xe5)[0x4f0cd6d5]
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
13 years, 1 month
[Bug 4598] Funambol: Company phone property will lost in syncing addressbook with funambol
by bugzilla@moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=4598
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
AssignedTo|patrick.ohly(a)intel.com |yongsheng.zhu(a)intel.com
--- Comment #4 from pohly <patrick.ohly(a)intel.com> 2009-07-23 00:29:57 ---
(In reply to comment #3)
> (In reply to comment #2)
> > I vaguely remember that I discussed this with Funambol already a while ago.
> > Their mapping of TEL numbers was weird.
> > Can you provide more information about this issue?
> > First, is it necessary to create the contact on the server first? In other
> > words, do you get the same behavior when creating the contact locally from
> > scratch?
>
> To reproduce the issue, it is required that the contact is created in server at
> first.
>
> > Second, can you provide a dump of what is sent to the server? Open the .html
> > log in a browser, unfold it completely (+++ at the top of the file), then
> > search for "Generated" (or something like it) and the contact underneath that.
>
> -----------------------
> incoming contact info
> -----------------------
> BEGIN:VCARD
> VERSION:2.1
> N:;Jessy;;;
> FN:Jessy
> BDAY:
> TEL;TYPE=PREF:13798000000
> TITLE:
> ORG:;
> TEL;TYPE="X-EVOLUTION-COMPANY":13523456789
> END:VCARD
It's unusual that Funambol uses "X-EVOLUTION-COMPANY". It's not something that
I have seen in use by Evolution when I documented vCard extensions:
http://en.wikipedia.org/wiki/Vcard#vCard_extensions
The normal type for this would be "WORK". We should ask Funambol for
clarification and for compatibility reasons (if they don't change it quickly,
which I wouldn't expect) try to treat X-EVOLUTION-COMPANY as an alias for WORK.
This might be possible by adding a new line to syncclient_sample_config.xml:
<property name="TEL">
<value field="TEL"/>
<position field="TEL" repeat="array" increment="1" minshow="1"/>
<parameter name="TYPE" default="yes" positional="no" show="yes">
<value field="TEL_FLAGS" conversion="multimix" combine=",">
<enum name="HOME" value="B0"/>
<enum name="WORK" value="B1"/>
=> <enum name="X-EVOLUTION-COMPANY" value="B2"/>
<enum mode="ignore" value="B2"/> <!-- OTHER -->
<enum name="VOICE" value="B3"/>
A potential problem with this approach is that we don't want to encode WORK
telephone numbers as TYPE=WORK;TYPE=X-EVOLUTION-COMPANY, which might happen
with the code above.
Yongsheng, as our Funambol expert, can you have a look at this?
> -----------------------
> outgoing contact info
> -----------------------
> BEGIN:VCARD
> VERSION:2.1
> REV:20090721T164654Z
> N:;Jessy;;;
> FN:Jessy
> X-EVOLUTION-FILE-AS:Jessy
> NICKNAME:
> TITLE:
> ORG:;;;
> ROLE:
> TEL;PREF:13798000000
> TEL:13523456789
> EMAIL:
> URL:
> X-MOZILLA-HTML:
> ADR:;;;;;;
> BDAY:
> NOTE:
> PHOTO:
> END:VCARD
No surprise here, the extension is not preserved after receiving it from the
server and parsing it with the Synthesis configuration. Therefore the steps to
reproduce this problem could be simplified to:
1. create complex event on server
2. sync from server to Evolution
3. look at the even in Evolution and check whether it
looks like the original event
In this case, the company phone should be displayed as "other" in Evolution.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
13 years, 1 month
[Bug 4660] Can not do sync from GUI, and error info is inconsistent with commands
by bugzilla@moblin.org
http://bugzilla.moblin.org/show_bug.cgi?id=4660
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|Undecided |P2
Status|NEW |ASSIGNED
Component|GTK UI |* Feature Request
CC| |patrick.ohly(a)intel.com
AssignedTo|jku(a)linux.intel.com |syncevolution(a)lists.intel.c
| |om
QAContact|jingke.zhang(a)intel.com |
Target Milestone|--- |future
Severity|critical |normal
--- Comment #2 from pohly <patrick.ohly(a)intel.com> 2009-07-23 00:10:41 ---
(In reply to comment #0)
> Description:
> ===================
> This is a big regression.
Let me quote Douglas Adams: don't panic. The code we are debating has been
around for a while, so this is not a regression. Perhaps the Moblin
installation has changed, see my questions regarding that in bug #4659.
> So, syncUI does not give the
> correct error info.
This is indeed a problem of the GUI that we should look into and fix if
possible, but it is not critical. I can think of many error scenarios where
only the stdout of the "syncevolution" command line will show the real error.
Reproducing this with syncevo-dbus-server is hard to get right in all case. For
example, how do you send debug output to the GUI if the debug output is about a
communication or fundamental setup problem?
> Steps for reproducing:
> ===================
0. set logDir to a directory which cannot be created, like /foo
> 1. Launch syncUI and use scheduleworld as the service.
> 2. Add a valid username and password. Make sure http_proxy is configured
> correctly.
> 3. Choose "Todo" and click "sync now".
> 4. The GUI show error: "Service configuration not found".
--
Configure bugmail: http://bugzilla.moblin.org/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.
13 years, 1 month