Re: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta)

2016-09-13 Thread deloptes 

Hi,
I added a line to dump the incoming item/payload in the backend. I couldn't
see what was sent when using SYNCEVOLUTION_DEBUG=4.

TrackingSyncSource::InsertItemResult TDEPIMCalendarSource::insertItem(const
std::string , const std::string , bool raw)
{
SE_LOG_DEBUG(getDisplayName(), "Item payload: ( %s )", item.data() );

It looks like the item is already broken, when passed to the backend[1].

I fixed similar issue related to vcal v1 in TDE/libkcal in the vcc.y/cpp
file[2] today, while trying to reproduce and looking into the v1 parser.
This here looks very very similar to what I fixed, so how is the converter
in the engine handling the v1 quoted printable with charset: utf-8. It
looks like the versit parser does not honor white space in the beginning of
the line for the quoted-printable encoding [3].

The test text says: "This is a test for a very long summary in Cyrillic 2"
and it should look like this: "Това е тест за много дълго заглавие на
кирилица 2"

Help is highly appreciated.

Should I file a bug somewhere, let me know and thanks in advance again.

Thank you in advance

regards


[1]
[2016-09-14 00:50:08.326] Executing Script 'beforewritescript'
[2016-09-14 00:50:08.326] calendar: updating "Това е тест за �= 
�ного дълго за= 
главие на кир�= 
�лица 2"
[2016-09-14 00:50:08.326] calendar: Item payload: ( BEGIN:VCALENDAR 
VERSION:2.0 
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.47//EN 
BEGIN:VEVENT 
LAST-MODIFIED:20160913T225045Z 
DTSTAMP:20160914T005008Z 
CREATED:20160913T212613Z 
UID:libkcal-442883373.612 
SEQUENCE:7 
CLASS:PUBLIC 
TRANSP:OPAQUE 
PRIORITY:0 
SUMMARY:Това е тест за �=\n�ного дълго за=\nглавие на кир�=\n�лица 2 
DTSTART:20160914T103000Z 
DTEND:20160914T104500Z 
END:VEVENT 
END:VCALENDAR 
 )
[2016-09-14 00:50:08.326] calendar: Item deleted for merge: (
libkcal-442883373.612 )
[2016-09-14 00:50:08.606] calendar: Item saved: ( libkcal-442883373.612 )
[2016-09-14 00:50:08.606] calendar: Item ( libkcal-442883373.612 :
20160913T225045Z ) done.
[2016-09-14 00:50:08.606] calendar: aID=(libkcal-442883373.612,) res=0


[2] https://bugs.trinitydesktop.org/show_bug.cgi?id=2688
[3] https://www.scribd.com/document/31243097/vCalendar-V1-0-Specifications

___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

[Syncevolution-issues] [Bug 97780] Backends for the Trinity Desktop (TDE)

2016-09-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=97780

--- Comment #2 from EKO  ---
Thanks for the hint - will do next.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.___
Syncevolution-issues mailing list
Syncevolution-issues@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution-issues

Re: [SyncEvolution] survey: providing SyncEvolution binaries

2016-09-13 Thread Tino Mettler 
On Mon, Aug 22, 2016 at 15:22:31 +0200, Patrick Ohly wrote:
> Debian Stable, which only has an old version (1.4.99).

Hi,

I just remembered that one reason for that somewhat ugly version in
Jessie was that the 1.5 release came slightly after the freeze for
Jessie. So FYI the current roadmap for Stretch says "Q3 2016: Please finish up 
things for
Stretch" with the first freeze (for library transitions) scheduled for
November 5th.

Regards,
Tino
___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

[Syncevolution-issues] [Bug 97780] Backends for the Trinity Desktop (TDE)

2016-09-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=97780

--- Comment #1 from Patrick Ohly  ---
Regarding testing: you can re-use the existing tests and get them applied to
your new backend, using either the existing testcases or testcases specific to
your backend.

See how AkonadiSyncSourceRegister.cpp instantiates one custom
RegisterSyncSourceTest per item type:

static class vCard30Test : public RegisterSyncSourceTest {
public:
vCard30Test() : RegisterSyncSourceTest("kde_contact", "eds_contact") {}

virtual void updateConfig(ClientTestConfig ) const
{
config.m_type = "kde-contacts";
}
} vCard30Test;

This defines the "Client::Source::kde_contact" tests, using the existing
eds_contact = syncevolution/test/testcases/eds_contact.vcf testcases.

Build with integration testing enabled, dynamic linking disabled (easier that
way) and then you can run (without installation, directly in the "src"
directory:
./client-test Client::Source::kde_contact (or whatever you are going to call
it).

The HACKING document has some more information about this, although I can't
vouch for it being entirely up-to-date.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.___
Syncevolution-issues mailing list
Syncevolution-issues@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution-issues

Re: [SyncEvolution] Explicit type 'text/x-vcalendar' specified in command or item meta

2016-09-13 Thread deloptes 
Patrick Ohly wrote:

> On Tue, 2016-09-13 at 00:26 +0200, deloptes wrote:
>> Hi,
>> sorry for bothering further but I am wondering why I see this when in
>> slow sync but not in normal mode.
> 
> You should see it also in normal mode when creating a new calendar entry
> on the phone.
> 
>> [2016-09-09 17:12:34.846] Explicit type 'text/x-vcalendar' specified in
>> command or item meta
>> [2016-09-09 17:12:34.846] Version '1.0' obtained from item data
>> 
>> Does this mean that (if I recall correctly) the item pushed to the
>> backend is v1.0 calendar?
> 
> No, that's a log entry about the data as it comes from the peer,
> probably a phone in this case. Run with a higher log level (starting
> with 4, if I remember correctly) and you will see the actual data
> getting dumped, with "Parsing" for the original data and "Generated"
> after re-encoding.
> 
>> If yes how can I tell (enforce) the engine to send v2.0?
> 
> It will already do the conversion to 2.0. The "generated" item is what
> it will store in the local database.
> 

Thanks for the response. I trust you - I was thinking it is saying what it
would send to the backend.
The problem I have is that there is a bug in TDM vcal converter, that breaks
non ascii chars when converting from quated-printable to utf8. I think I
observe this problem only when in slow sync mode, but it could be also
something else.
However it makes me think that with high probability the item is not
converted to v2 (ical) format before it gets send to the backend.

I'll try testing this with higher debug as suggested.

thanks

___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] Explicit type 'text/x-vcalendar' specified in command or item meta

2016-09-13 Thread Patrick Ohly 
On Tue, 2016-09-13 at 00:26 +0200, deloptes wrote:
> Hi,
> sorry for bothering further but I am wondering why I see this when in slow
> sync but not in normal mode.

You should see it also in normal mode when creating a new calendar entry
on the phone.

> [2016-09-09 17:12:34.846] Explicit type 'text/x-vcalendar' specified in
> command or item meta
> [2016-09-09 17:12:34.846] Version '1.0' obtained from item data
> 
> Does this mean that (if I recall correctly) the item pushed to the backend
> is v1.0 calendar?

No, that's a log entry about the data as it comes from the peer,
probably a phone in this case. Run with a higher log level (starting
with 4, if I remember correctly) and you will see the actual data
getting dumped, with "Parsing" for the original data and "Generated"
after re-encoding.

> If yes how can I tell (enforce) the engine to send v2.0?

It will already do the conversion to 2.0. The "generated" item is what
it will store in the local database.

-- 
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.



___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution