Create Task
Maniphest T3158

Transition to GpgMEpp and QGpgME from GpgME 1.7.0
Closed, ResolvedPublic
Actions

Description

This is something for after Applications 16.08 are branched off. For 16.08 I plann to keep QGpgME as a backend in Libkleo and GpgMEpp. I've already ported some bugfixes and features from GpgME 1.7.0 back there.

But in the future I don't want to add new features two both of them. E.g. I've added TOFU Support in GpgME 1.7.0 but not in KF5::GpgMEpp

My checklist to make the transition as painless as possible:

  1. Ensure that GpgME 1.7.0 and GpgMEpp / Libkleo from 16.08 are coinstallable
    1. There is currently a problem that API breaks in GpgMEpp cause Kleopatra's build to fail as it Picks up the wrong headers (GpgME 1.7.0 installs c++ headers under /usr/include/gpgme++) and so #include <gpgme++/foo.h> picks up the headers from 1.7.0 even if cmake looks for and finds the KF5 version of GpgME++
  2. Ensure that GpgME 1.7.0 is released.
    1. Review API if more C++11 API breaks like the auto_ptr change are required.
    2. Check if Windows builds are OK.
    3. Install version headers.
    4. Maybe install CamelCase headers for QGpgME as they were also installed from libkleo.
  3. Ensure that GpgME 1.7.0 is available on CI.
    1. Once release is done.
  4. Notify KDEPIM / Kde-packagers
  5. Test build / prepare patches for other users of GpgMEpp outside of KDEPIM (KGet, probably Trojitá)
  6. Switch libkleo to branch gpgme-next and remove the QGpgME backend there.
  7. Retire GpgMEpp repo.
  8. Test and fix builds against GpgME 1.7 in KDEPIM repos without KF5::GpgME and new libkleo.
  9. Switch to builds against GpgME 1.7
  10. Notify packagers and outline rationale for this.
  11. Apologize to everyone whose build fails because a very recent version of GpgME will be required :-/

Related Objects
Search...

aheinecke added a comment.Jul 4 2016, 10:49 AM
  1. Apologize to everyone whose build fails because a very recent version of GpgME will be required :-/

The best way to solve this would probably be add it to kdesrc-build as an external thing like grantlee so that kdesrc-build still works.

aheinecke added a comment.Jul 12 2016, 9:56 AM

Ensure that GpgME 1.7.0 and GpgMEpp / Libkleo from 16.08 are coinstallable

Done, by removing the direct dependency kleopatra had to gpgme core we can ensure that the KF5::GpgMEpp / QGpgME include paths come before the include dir of gpgme itself. This ensure that the headers from the libraries searched in CMake are included.

Install version headers.

Done

Install camelcase headers.

Done for QGpgME.

Ensure that GpgME 1.7.0 is available on CI.

GnuPG now also has CI now for gpgme http://jenkins.gnupg.org/gpgme/ (ipv6 access only) that should help us ensure that there are less problems on KDE CI. It also builds / tests with ASAN.

aheinecke added a comment.Aug 26 2016, 2:21 PM

Still delayed with the release, we had some API breaking changes inside of 1.7.0 (where the policy is that breaking unreleased API is ok).

But we need to move forward on this. I hope for a release next week.

aheinecke added a comment.Sep 21 2016, 10:49 AM

GPGME-1.7 was released today.
Next steps: Inform packagers, try to add it to kdesrc-build and then start switching to it.

aheinecke added a comment.Sep 24 2016, 8:22 PM

I have informed packagers, I am a bit discouraged that debian has currently disabled the bindings for cpp / qt. We need to work with them there.

For kdesrc-build of gpgme we need a patch to kdesrc-build because of the ./autogen.sh stuff that needs to be done in the src directory. Kdesrc build does not handle this. I open a review on Monday with a proposed fix / workaround

knauss added a subscriber: knauss.Sep 26 2016, 2:46 PM

Well on Debian side it is takeover of two formular non related groups, so it needs some time. Hope I'll find time soon to look into.

dvratil claimed this task.EditedOct 11 2016, 12:23 PM
dvratil added a subscriber: dvratil.

Repositories to port:

  • libkleo (rebased gpgme-next branch and ported away from boost::shared_ptr/boost::bind)
  • messagelib
  • kleopatra (and ported away from boost::shared_ptr/boost::bind)
  • kmail (and ported away from boost)
  • kaddressbook (only buildsystem adjustment needed)
  • kdepim-addons
  • kmail-account-wizard

Changes checklist:

  • adjust CMakeLists.txt: find_package(KF5Gpgmepp) -> find_package(Gpgmepp)
  • some places might require that we now include boost/shared_ptr.hpp manually
  • port from boost::shared_ptr to C++11 smart ptrs (this one might be tricky if we forward the objects to our public API as boost, might need to change out public API then

Once the switch is done, we could also consider porting libkleo away from boost completely.

aheinecke added a comment.Oct 11 2016, 12:24 PM

In libkleo I already have a gpgme_next branch that compiles but is not up to date. Especially since we moved code from kleopatra into libkleo.

dvratil added a comment.Oct 11 2016, 12:26 PM
In T3158#58968, @aheinecke wrote:

In libkleo I already have a gpgme_next branch that compiles but is not up to date. Especially since we moved code from kleopatra into libkleo.

Yup, I know. I'm rebasing it on current master locally, then I'll merge it to master directly to avoid hassles with force-push.

I'll wait with pushes until I have everything compiling locally, so that CI does not complain too much :)

aheinecke closed this task as Resolved.Oct 31 2016, 1:57 PM

Dan did the switch so this can be resolved imo.

Thanks.