On Fri Feb 16, 2018 at 11:57:44AM +0000, Stuart Henderson wrote: > On 2018/02/16 07:33, Rafael Sadowski wrote: > > Hi All, > > > > tl;dr: x11/kde-applications/gpgmepp is dead upstream. Long live > > security/qgpgme. > > > > Since Sep. 2016[1] the C++ bindings for GnuPG's GPGME library and > > the Qt Job API for GpgME++ (QGpgME) is part of the GPGME repository. > > > > It wasn't a good idea to make an FLAVOR in security/gpgme; discussed > > here[2]. > > That thread isn't about adding a FLAVOR but a PSEUDO_FLAVOR mechanism > (and defaults can be set as appropriate for arches which can't build qt5 > - though I don't see why qt5 would need to be disabled by default on > arches which do support it unless there's a cyclical dependency; > otherwise just having the no_qt pseudo-flavour available should be > good enough there). > > The part in there which is an actual problem for this is qt5.port.mk > changing the compiler. One way around that would be to use "base-clang > ports-clang ports-gcc" explicitly for gpgme. But gpgme is C not C++ > anyway so just setting MODQT5_USE_CXX11=No might do the trick too. > > jca said, "And I agree with you that requiring Qt5 to build gpgme in > bulk builds is not reasonable, as said in my previous mail." - but > that doesn't matter for full bulks (which will have qgpgme anyway) > only partial ones - and those are already a special enough case that > adding extra complexity to cope with them doesn't seem worthwhile > (especially when the builder can use ,no_qt in their build list entry). > > > For this reason, you will find attached the diffs/tarball with the > > following content: > > > > 1.) gpgme.1.10.diff > > Simple update to the latest stable version 1.10.0. Tested with neomutt > > and trojita ond amd64. > > Looks sane and independent of the other parts, but I would like to know > that at least builds have been done with more of the ports depending on > it especially if enough changed to need a major bump.
https://abi-laboratory.pro/tracker/objects_report/gpgme/1.9.0/1.10.0/report.html You're right, it doesn't need a major bump. > > > 2.) trojita_qgpgme.diff > > Patch trojita to play with qgpgme from GPGME based on the idea from > > archlinux[3]. Tested on amd64. All tests are green. > > Is there any chance of upstream adopting these patches? (not a show > stopper but they're complex enough it would be nice not to have to > keep carrying and updating them). I'm trying to take care of it. > > > 3.) qgpgme.tar.gz > > Based on security/gpgme with the following changes: > > - Add --enable-languages='cpp qt' > > - remove all duplicated stuff with gpgme in post-install. > > - QGpgME is GPLv2 and not LGPL > > - Add security/gpgme=${VERSION} so keep in snyc with gpgme. > > I'd be happier with this being part of a single gpgme port if the > compiler settings thing can be fixed as above. Apart from anything > else these fixed-version dependencies make it a pain to test updates > (also see irssi, dovecot) because you have to uninstall existing > packages to get the new ones built. I see your point but qgpgme unfortunately needs a C++11 compiler.
