Hi, I'm pleased to announce that the C++ bindings for GnuPG's GPGME library and the Qt Job API for GpgME++ (QGpgME) that was previously in Libkleo are now part of the upstream GPGME repository and have been released today with GPGME-1.7:
https://lists.gnupg.org/pipermail/gnupg-devel/2016-September/031647.html This means: * With Applications 16.12 there will be no more release of pim/gpgmepp * Libkleo will still be released with the focus of providing common classes to be used in different Applications working with GnuPG based crypto. The backend abstraction and Chiasmus support (which was untested for years and probably didn't work anymore) will be removed. For Packagers this will also mean that you are likely (at least until we are done adding support for GnuPG's latest features in KMail / Kleopatra) to require a very new GPGME (not GnuPG itself) version that is built with the qt and c++ binding enabled. Thanks to the CI Team we already have GPGME on build.kde.org :-). Sorry about that, but this will mean that there are two PIM libraries fewer (yay) and in the long term that these bindings are maintained by the GnuPG Project. (And there will be many less Ifdefs in our code as we previously supported multiple versions of GPGME in GpgMEpp). Another bad thing: As a concession to the GPGME maintainer I ported the build system back in time to autotools *brr*. But then your GnuPG Packagers are probably more used to that anyway ;-). At least the libraries still install CMake Config files. So cmake based users will be able to easily switch from find_package(KF5Gpgmepp) to find_package(Gpgmepp) Both libraries should be coinstallable by default. But the header names of GpgMEpp will conflict with the headers from KDE4's kdepimlibs/gpgme++. QGpgME: -------------- QGpgME is now basically a Tier 0 (requires qtbase only) library. It provides a consistent Job based API and is heavily used by KMail and Kleopatra as the highest Abstraction for crypto. Please not that because QGpgME was mostly part of Libkleo (although confusingly libqpgme was part of gpgmepp) it is licensed under the GPLv2+ and not under LGPL as the rest of GPGME. There was some inconsistent error handling code in libkleo that required KMessageBox and Ki18n in the past. This as been removed and applications need to handle these errors themself. The API is mostly untouched but functionality moved from the Libkleo Namspace to the QGpgME Namespace. Instead of using the CryptoBackendFactory / Protocol to obtain jobs you now just use: QGpgME::openpgp()->someJob(...) or QGpgME::smime()->someJob(...) GpgMEpp: --------------- Yes we use a different casing for GPGME everywhere, sorry, historic reasons,... This should be mostly a drop in replacement for KF5Gpgmepp. There were some API breaks to get rid of boost (in favour of C++11) so you might need to replace some boost::shared_ptr with the standard equivalent. For the Assuan based API (I am not aware of a use outside of Kleopatra) there was a larger break to port from the deprecated auto_ptr to unique_ptr. We'll start switching to the new Library soon in Kdepim there are already some branches prepared for this. For developers I'll try to add gpgme to kdesrc- build so that the transition will not break your development builds. My task for the transition is: https://phabricator.kde.org/T3158 Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
signature.asc
Description: This is a digitally signed message part.
