GpgME++ and QGpgME now Released as part of GpgME

Albert Astals Cid aacid at
Thu Sep 29 23:00:35 UTC 2016

El dimecres, 21 de setembre de 2016, a les 17:46:43 CEST, Andre Heinecke va escriure:
> 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:
> This means:
> * With Applications 16.12 there will be no more release of pim/gpgmepp

Ok, done

I'm a bit confused because later you say "this will mean that there are two PIM libraries fewer (yay)"

Which is the other library that goes away? Do we need to remove its repository from being release too?


> * 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
> :-).
> 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:
> Regards,
> Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the release-team mailing list