Re: KDEPIM (16.12) and Gpgme minimum requirement
On Thursday, 3 November 2016 at 11:45, Sandro Knauß wrote: > You may got the notice, that the cpp(gpgme++) and qt (QGpgme) interface, > previously build by KDEPIM in the libgpgmepp package, moved down to GpgME > directly. That's why KDEPIM depends on very recent GpgME. > > Together with Andre we came to the conclusion, that we want to support: > > GpgME >= 1.7.1 This decision also affects kde-runtime (more specifically, kwalletd-4), which is still released as part of KDE Applications even in 16.12. kwalletd (when built with gpg support) to this date is depending on the gpgmepp version of kdepimlibs-4, which is now conflicting with >=Gpgmepp-1.7.0. But someone has been working on a patch to port it to Gpgmepp as well: https://git.reviewboard.kde.org/r/129339/ I think it would make a lot of sense to get it in for 16.12. Regards, Andreas
Re: KDEPIM (16.12) and Gpgme minimum requirement
On jeudi 3 novembre 2016 21:25:45 CET Andre Heinecke wrote: > Because the > overall maintainer of gpgme thinks that pkg-config is an unportable devilish > thing, created by these young people who don't care about compatibility > with systems from the 70'ies, just like cmake . So if I can get in a > pkg-config file in I also should be able to get in a cmake config file in > and I already got the ok for pkg-config. Except that cmake *is* portable :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: KDEPIM (16.12) and Gpgme minimum requirement
Hi, On Thursday 03 November 2016 18:57:34 Rolf Eike Beer wrote: > Am Donnerstag, 3. November 2016, 11:45:47 schrieb Sandro Knauß: > That's good news from my (KGpg) point of view, as we were recently in a > discussion which versions we need to support. We do not need gpgme itself, > but we use the headers to get some algorithm defines. I really encourage you to use gpgme, It's the defined API for GnuPG and programs using gnupg should use it! :-). I held a talk about why you should use gpgme, or better qgpgme / gpgmepp recently but sadly the video from that talk is still not published. :-( Slides [1] and Abstract [2] are published but I don't think they capture the main point which is: "Use gpgme or don't ever complain about output / interface changes in gnupg, using gnupg in a program without GpgME is like using private API" > Does that version of GpgME bring a CMake config file with it so we can drop > the FindGpgME.cmake we copied somewhere from? I think I've convinced the maintainer of GpgME to install pkg-config files in the future for GpgME, we had some loud arguments (beer involved) about finding GpgME at build time (especially on Windows). I think I can get pkg-config files upstream and then the cmake config file should be doable, too. Because the overall maintainer of gpgme thinks that pkg-config is an unportable devilish thing, created by these young people who don't care about compatibility with systems from the 70'ies, just like cmake ;-) . So if I can get in a pkg-config file in I also should be able to get in a cmake config file in and I already got the ok for pkg-config. Just have to do it, but I think I can do it for 1.7.2. (no promises as the overall maintainer might veto it) Regards, Andre 1: https://files.intevation.de/users/aheinecke/gpgme.pdf 2: http://openpgp-conf.org/program.html#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.
Re: KDEPIM (16.12) and Gpgme minimum requirement
Hey, > That's good news from my (KGpg) point of view, as we were recently in a > discussion which versions we need to support. We do not need gpgme itself, > but we use the headers to get some algorithm defines. > > Does that version of GpgME bring a CMake config file with it so we can drop > the FindGpgME.cmake we copied somewhere from? As far as I see, no you can't drop it at the moment. 1.7.1 only creates cmake files for Qt (QGpgme) and C++(Gpgmepp) bindings. But maybe if you ask Andre nicely he will add cmake files for C interface too in 1.7.2 :) Also one thing to remake about QGpgme/Gpgmepp, there internal version numbers are 7.0.0(QGpgme) and 6.0.0(Gpgmepp) in 1.7.1, but these are unified to the same version like Gpgme to 1.7.2. Please be aware of this if you add a minimum version for those. Best regards, sandro
Re: KDEPIM (16.12) and Gpgme minimum requirement
Am Donnerstag, 3. November 2016, 11:45:47 schrieb Sandro Knauß: > Hey, > > Together with Andre Heinecke (developer of gpgme), we discussed the minimum > version of GpgME we want to support with the upcoming release of KDEPIM for > Applications 16.12. > > You may got the notice, that the cpp(gpgme++) and qt (QGpgme) interface, > previously build by KDEPIM in the libgpgmepp package, moved down to GpgME > directly. That's why KDEPIM depends on very recent GpgME. > > Together with Andre we came to the conclusion, that we want to support: > > GpgME >= 1.7.1 That's good news from my (KGpg) point of view, as we were recently in a discussion which versions we need to support. We do not need gpgme itself, but we use the headers to get some algorithm defines. Does that version of GpgME bring a CMake config file with it so we can drop the FindGpgME.cmake we copied somewhere from? Eike signature.asc Description: This is a digitally signed message part.
KDEPIM (16.12) and Gpgme minimum requirement
Hey, Together with Andre Heinecke (developer of gpgme), we discussed the minimum version of GpgME we want to support with the upcoming release of KDEPIM for Applications 16.12. You may got the notice, that the cpp(gpgme++) and qt (QGpgme) interface, previously build by KDEPIM in the libgpgmepp package, moved down to GpgME directly. That's why KDEPIM depends on very recent GpgME. Together with Andre we came to the conclusion, that we want to support: GpgME >= 1.7.1 We can't support 1.7.0 because the API is not complete in this version, to support KDEPIM. 1.7.2 will be released hopefully next week and will clean up some things and extend the API again (moved things from libkleo -> gpgme), but it is ABI compatible with 1.7.1. For KDE Applications 17.04 we will raise the minimum version very certainly again, to get rid of copies in libkleo. Regards, Sandro Knauß signature.asc Description: This is a digitally signed message part.
