GpgME++ and QGpgME now Released as part of GpgME

[Andre Heinecke]

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	
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20160921/ce58fed6/attachment.sig>