This could be related to upgrades. It seems that the db is regulary corrupt after installing a new version of kdepim (even with the same mysql version).

it is already gone to the wild

The findRIDDuplicates job in the storagejanitor (akonadictl fsck) finds all duplicates, but only removes them if they don't match the mimetype of the parent collection.
Also removing other duplicates requires taking a random guess which one to nuke and we have to ensure that we don't end up replaying that change to the server.

The user reported that query "select * from pimitemtable where collectionId=770 and remoteId=572;" only returns one result (with id 859243), which contradicts what we see above.

Inside the fetch we see:

* 859243 FETCH (UID 859243 REV 2 REMOTEID "572" MIMETYPE "message/rfc822" COLLECTIONID 770 SIZE 35614 FLAGS (\SEEN))
...
* 854863 FETCH (UID 854863 REV 2 REMOTEID "572" MIMETYPE "message/rfc822" COLLECTIONID 770 SIZE 15378 FLAGS (\SEEN))

Which means we have a duplicate (collectionId, mimeType, remoteId) tuple, which is illegal.

In total we see on the folder:

• LIST
• A couple of MERGE with data and GID
• A couple of MERGE without data (flags) <= in here we have the rollback
• A full fetch of all items

The Archive folder has a subfolder and in there we see this:

Works for me. #4095 and #5046 are already closed.

Our immediate build proplems seem to be solved with the above patch added.

Codewise it should be work now; i can compile it successfully and there is no more occurence of the KRecursiveFilterProxyModel.

Pretty sure this works if gpgme is installed

This was worked around.

This race condition has been worked around.

Recently seen in SyncCollectionAttribute, and the same system showed an error message "unknown attribute collectioncolor".
It's not entirely sure that the installation is clean though (proper packages etc).

Available in the latest installer.

I wrote a readme and moved the repository here:

The help script creates a database with the uid of the user, so multiple users can live on the same database.
I verified that collections and items are correctly synced, and that the script can be run multiple times without problems.

The process as described above works fine (except that I had to create ~/kdebuild/automatedupdate manually because it had the wrong permissions, I guess it should be created before running the container).

The redist has now been added to the installer as well.

(when I write ipython i mean ipython - the problem is that the normal python interpreter has problems with the inter-module import of f.ex. settings)

there is now a testenvionment in dev/autoupdate

The target platform is Ubuntu 12.04 LTS, not debian wheezy.

We also need a defined testenvironment (a dockercontainer that can work against a test kolab server)

The script doesn't seem to handle a missing connection to the server, it simply stalls forever.

The target platform is debian wheezy.

And we also get to see notes in the taskview when having a tag selected. Not what we want.

They only have no effect when a tag is selected. It works fine with inbox.

Not reproducible

a first version is now available at:

Not reproducible.

Have now all bits together, but need to polish everything a little bit:

starting full sync and get the end:

• dbus method org.freedesktop.Akonadi.Resource.akonadi_kolab_resource_0rc /org.freedesktop.Akonadi.Resource /sychronize
• dbus signal org.freedesktop.Akonadi.Resource.akonadi_kolab_resource_0rc /org.freedesktop.Akonadi.Agent.Status /status this one indecated with "0, ready" that it is ready.

The non-blocking behavior has been implemented in the akonadi server.