Thanks for the detailed setup log. That answers a lot of questions already. It all looks good.

(In reply to comment #0)
> [roubach@localhost ~]$ syncevolution --print-items @default todo
> [roubach@localhost ~]$

Are you absolutely sure that akonadi:?collection=262 contains items?

Do you know how to use gdb or how to recompile SyncEvolution?

I have the suspicion that the items are found, but their mime type isn't what is expected. In a recent commit, the "sub mime type" was changed from "text/calendar" to the more specific "application/x-vnd.akonadi.calendar.todo", because that is the type used by Akonadi to describe what kinds of items the collection contains. See

commit 05fb1aebc3242c0cf734f18f0582df8cb05e0999
Author: Diane Trout <diane@ghic.org>
Date:   Thu Apr 25 10:07:25 2013 +0200

    KDE: fix Akonadi backend for tasks
    
    Because of a too generic mime type in SyncEvolution, task collections
    were not found.

diff --git a/src/backends/akonadi/akonadisyncsource.h b/src/backends/akonadi/akonadisyncsource.h
index 5c11ff9..6e88188 100644
--- a/src/backends/akonadi/akonadisyncsource.h
+++ b/src/backends/akonadi/akonadisyncsource.h
@@ -128,7 +128,7 @@ class AkonadiTaskSource : public AkonadiSyncSource
 {
 public:
     AkonadiTaskSource(const SyncSourceParams &params)
-        : AkonadiSyncSource("text/calendar", params)
+        : AkonadiSyncSource("application/x-vnd.akonadi.calendar.todo", params)
     {
     }



Perhaps it uses that type for the collection and "text/calendar" for the items?
In that case, the following code will not find the tasks:

void AkonadiSyncSource::listAllItems(SyncSourceRevisions::RevisionMap_t &revisions)
{
    // copy all local IDs and the corresponding revision
    std::auto_ptr<ItemFetchJob> fetchJob(DisableAutoDelete(new ItemFetchJob(m_collection)));

    if (!fetchJob->exec()) {
        throwError("listing items");
    }
    BOOST_FOREACH (const Item &item, fetchJob->items()) {
        // Filter out items which don't have the right type (for example, VTODO when
        // syncing events)
        if (item.mimeType() == m_subMime.c_str()) {
            revisions[QByteArray::number(item.id()).constData()] =
                      QByteArray::number(item.revision()).constData();
        }
    }
}

You can check this theory by single-stepping through that function. Bonus points for the output of "print item.mimeType()". Not sure whether gdb will be able to call the function. In that case, recompile and add
         LOG_INFO(NULL, "item mime type: %s", item.mimeType());

>> Are you absolutely sure that akonadi:?collection=262 contains items?

how to know this ? is there any tool to explore the akonadi db ?

kde calendar and kde tasks have the same "262" collection number as you can see above (see syncevolution --print-databases result) 

>> Do you know how to use gdb or how to recompile SyncEvolution?

- gdb : i hardly know it.

- compile

i only know to type ./configure , make , su -c "make install"
if there is a pb i am lost

>> the "sub mime type" was changed from "text/calendar" to the more specific
>> "application/x-vnd.akonadi.calendar.todo"

yes in the list of the file types associated to apps there is "application/x-vnd.akonadi.calendar.todo"

perhaps to avoid futur pb it would be easier not to hardcode the mime/type and to have the ability to assign a value by the way of syncevolution cli tool.

(In reply to comment #2)
> >> Are you absolutely sure that akonadi:?collection=262 contains items?
> 
> how to know this ? is there any tool to explore the akonadi db ?

There is a tool called akonadiconsole. Typically is packaged separately because only developers need it. I don't remember whether it shows individual items.

There may be another check:

syncevolution --export - @default calendar | grep -e BEGIN:VEVENT -e BEGIN:VTODO

If you see BEGIN:VTODO, then the tasks in the collection are impossible to tell apart from events by their mime type, and therefore the SyncEvolution code needs to be changed.

> kde calendar and kde tasks have the same "262" collection number as you can
> see above (see syncevolution --print-databases result) 

Yes, that's why it is important that only VTODO items are used when acting as task source - the engine can only one or the other, but not both mixed in the same data source.

> >> Do you know how to use gdb or how to recompile SyncEvolution?
> 
> - gdb : i hardly know it.
> 
> - compile
> 
> i only know to type ./configure , make , su -c "make install"
> if there is a pb i am lost

Let's try the check above first.

$ syncevolution --export - @default calendar | grep -e BEGIN:VEVENT -e BEGIN:VTODO
BEGIN:VEVENT
BEGIN:VEVENT
BEGIN:VEVENT
...
BEGIN:VEVENT
BEGIN:VEVENT
BEGIN:VEVENT
$

no BEGIN:VTODO

Created attachment 81173 [details]
here is the sole task i recorded

Created attachment 81174 [details]
here is the sole task i recorded (another try)

Created attachment 81176 [details]
payload of the task

Created attachment 81177 [details]
raw payload of the task

I just realized that the version you are using, 1.3.99.3, does not yet contain the patch that I mentioned.

Change akonadisyncsource.h as shown in comment #1 and recompile. In other words, it should look like:


     AkonadiTaskSource(const SyncSourceParams &params)
        : AkonadiSyncSource("application/x-vnd.akonadi.calendar.todo", params)

Because of the incorrect type, the search for items of the right type never succeeds, leading to the empty list. I was thrown off track because I thought the incorrect type also (and only) prevented listing the task collections (that was the original error report), and that worked for you.

I believe this problem was fixed in 1.3.99.4. Please reopen if it persists.

i use the free version of funv10 10.1.3

i think this version does not take care of any task

anyway it is only to make test;

i don't use task feature


thanks