Hi,
so I created a first set of patches to get rid of kf5gpgmepp.
Just to make it super clear if I talk about kf5gpgmepp I mean [0],
if I say GpgME is mean [1], that inclued Gpgmepp and QGpgME).
* kwallet-kf5 - is fixed
( the support of GppME >= 1.7.1 is already provided by upstream)
* messagelib/kdepim/kleopatra:
I created a patch to get rid of direct dependency of kf5gpgmepp
messagelib[debian/sid] 16da74f8b884e02a2835c6c1c92f8c2041aa27a1
kdepim[debian/sid] fe28dd2cc76a4c13b5f214fb8d024a529bf2bb9c
kleopatra[debian/sid] f5bf98dabe305aa781eb43abcc0c345bd265a38d
sune/maxy: please review
the tricky part is libkleo. Because parts of libkleo the moved into QGpgME,
and we have changes of boost::shared_ptr -> std::shared_ptr and other such
kind of changes. I created a patch to compile libkleo on its own without Kf5Gpgme.
But if I try to use this libkleo to build messagelib it fails :(
libkleo[dev/hefee] ee3cae709395e14070cdc9b7979771029d576b16
buildlof of messagelib:
[...]
/<<PKGBUILDDIR>>/messagecomposer/src/composer/keyresolver.cpp: In function 'bool ByKeyID(const GpgME::Key&, const GpgME::Key&)':
/<<PKGBUILDDIR>>/messagecomposer/src/composer/keyresolver.cpp:119:75: error: 'bool ByKeyID(const GpgME::Key&, const GpgME::Key&)' redeclared as different kind of symbol
static inline bool ByKeyID(const GpgME::Key &left, const GpgME::Key &right)
^
In file included from /usr/include/gpgme++/key.h:27:0,
from /usr/include/KF5/libkleo/keyapprovaldialog.h:45,
from /usr/include/KF5/Libkleo/KeyApprovalDialog:1,
from /<<PKGBUILDDIR>>/messagecomposer/src/composer/keyresolver.h:41,
from /<<PKGBUILDDIR>>/messagecomposer/src/composer/keyresolver.cpp:37:
/usr/include/gpgme++/key.h:426:1: note: previous declaration 'template<template<class U> class Op> struct ByKeyID'
GPGMEPP_MAKE_STRCMP(ByKeyID, .keyID());
^
messagecomposer/src/CMakeFiles/KF5MessageComposer.dir/build.make:917: recipe for target 'messagecomposer/src/CMakeFiles/KF5MessageComposer.dir/composer/keyresolver.cpp.o' failed
At least one questino from my side, if we update all fist dependencies to not
use gpgmepp, we would also need to recompile the second level of dependencies
(f.ex. libkleo->messagelib->kdepim). This is normally handled by a transition,
but now we have transitions freeze... So how we get rid of kf5gpgmepp for
stretch smoothly( after we found a way to handle libkleo)?
Best Regards,
sandro
[0] KF5Gpgmepp: https://tracker.debian.org/pkg/gpgmepp
[1] GpgME: https://tracker.debian.org/pkg/gpgme1.0
--
Am Montag, 28. November 2016, 23:39:50 CET schrieb Daniel Kahn Gillmor:
> Hi Qt/KDE maintainers--
>
> Any status on https://bugs.debian.org/840652 ? If we could remove the
> gpgmepp source package from the archive, it will help us make stretch
> more maintainable.
>
> I understand that we might not be able to remove kdepimlibs due to qt4
> remaining in the archive, but i think even having two co-installable
> versions of gpgmepp in stretch would be better than having three
> co-installable versions.
>
> --dkg
Attachment:
signature.asc
Description: This is a digitally signed message part.