[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: GpgME++ and QGpgME now Released as part of GpgME
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2016-09-29 23:00:35
Message-ID: 81968757.LNkrr9AZvK () xps
[Download RAW message or body]


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:
> 
> 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

Ok, done
https://quickgit.kde.org/?p=sysadmin%2Frelease-tools.git&a=blobdiff&h=b56bb046e74551c7 \
b83feb57cf8b21ad14f37bd7&hp=1d7ed49477941ff302f4fafd31696b7e282663e5&hb=a843ec23c5b4be895e4b5df6e76ea5d73a7b2c7f&f=modules.git


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?

Cheers,
  Albert

> 
> * 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


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]