Confirmed to be a windows-only issue:

The problem was that the interval sync doesn't work as expected.

The problem is that the interval sync is never executed. Every collection overrides the parent's cache policy, so the sync settings are effectively ignored.

Works when syncing the folder manually, or opening the quick-view which also triggers a sync.

also works with a message from korganizer. All tested on linux.

This seems to work when sending the invitation from roundcube, and selecting Kolab/Calendar as target calendar.

Looks like this is not counterproposal but "Accept conditionally".

Resolved in kdepim a3177a2

The crash is provoked by editing a field in the model's delegate.

korganizer(391) IncidenceEditorNG::IncidenceDialogPrivate::load: Loading item 5 ; parent 24 ; storage 24

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

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:

https://phabricator.kde.org/project/view/62/

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

Looks like using this hack works:

set(CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES
    ${CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES}                                                                                                                                                                                                            
    "${CMAKE_INSTALL_PREFIX}/include"                                                                                                                                                                                                                    
)

seems related but the "solution" in there doesn't seem to work

The path in AM_OLD_COMPILE_SETTINGS was probably only an artifact of me messing around, the path is not reliably included there.

In AM_OLD_COMPILE_SETTINGS in AutomocOldMocDefinitions.cmake we can see /work/install/include as part of the passed in arguments still.

The moc options can also be found in CMakeFiles/searchjobtest_automoc.dir/AutogenInfo.cmake

I think the problem is that system include paths are for some reason stripped from the list passed to the moc, but the /work/install/include directory doesn't make it into the list. If we include a symlink to /work/install/include in include_directories it appears as expected in the moc commandline.

bash-4.3$ cmake --version
cmake version 3.3.2

Thanks for the patch =)

This unconditionally removes the output, so rather wrap it into

#ifndef NDEBUG
#endif

?

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.