A modern groupware client based on QtQuick and Sink.
The code can be found at: git://anongit.kde.org/kube
The documentation can be found at: http://kube.readthedocs.io/en/latest/
Also, see https://kube-project.com
A modern groupware client based on QtQuick and Sink.
The code can be found at: git://anongit.kde.org/kube
The documentation can be found at: http://kube.readthedocs.io/en/latest/
Also, see https://kube-project.com
This would be 'Epic'.
fwiw, memory-hole also breaks threading (because those headers are also encrypted).
We now execute "kill $(pidof sink_synchronizer)" at the end of the wrapper script to hopefully avoid running multiple synchronizer instances in parallel.
This should be fixed as of bd1ec892f40b24092dcb52a39fd7ffb2e22f5fde
I updated gpg related stuff and we're building sasl ourselves. Seems to work just fine.
Note that clang seems broken, but gcc builds everything fine.
I believe the reason is always if we start a gpg-agent inside the container without the necessary options, which makes the broken default lookup pick the wrong pinentry: https://github.com/flatpak/freedesktop-sdk-images/issues/70
restarting the flatpak can still result in:
Why not use include(ECMEnableSanitizers)?
We still get this but with a different backtrace:
For the time being we're using the approach that sets dtend to the recurrence end (calculated for 10 years).
This seems to work well enough for the time being.
An alternative approach would be to redefine dtstart as the end date of the overall recurrence.
Revert and rename only in the UI
Sorry if I wasn't clear enough in the first message.
In D15001#313863, @rnicole wrote:Renamed the "GMail" account to "Google". It seems that those who already have a Google account can remove their account from the command-line only, and then add it again from Kube
Renamed the "GMail" account to "Google". It seems that those who already have a Google account can remove their account from the command-line only, and then add it again from Kube
great =)
Let's figure out why carddav doesn't work and rename in the Ui only to Google.
I think the only usable approach will be to decrypt messages as they arrive. Otherwise things like search etc. break.
To re-secure the indexes we *should* probably encrypt the indexes using AES or something else that is fast, but for an initial implementation I don't care too much.
Use full-disk encryption if necessary.