[pkg-gnupg-maint] gpgme 1.7.0~ alpha or beta to debian experimental?

[Sandro Knauß]

Hey,

I now started to build cpp and qt bindings for gpgme but ran into a issue with the hardening flags. The problem is the -fPIE. With this enabled configure stops with:
configure:19628: checking whether a simple qt program can be built
configure:19639: g++ -o conftest -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/include/x86_6
4-linux-gnu/qt5 -fpic -fPIE -pie -Wl,-z,relro -Wl,-z,now conftest.cpp -lQt5Core >&5
In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qcoreapplication.h:37:0,
                 from /usr/include/x86_64-linux-gnu/qt5/QtCore/QCoreApplication:1,
                 from conftest.cpp:33:
/usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1087:4: error: #error "You must build your code with position independent code if Qt was built with -reduce-relocations. " "Compile your code with -fPIC (
-fPIE is not enough)."
 #  error "You must build your code with position independent code if Qt was built with -reduce-relocations. "\
    ^~~~~

full log: http://sandroknauss.de/files/gpgme1.0_1.7.0-2_amd64_with_hardening.build
with hardening disabled it builds successfully and also via replacing -fPIE with -fPIC, but than lintian is unhappy about the missing -fPIE for gpgme-tool.
http://sandroknauss.de/files/gpgme1.0_1.7.0-2_amd64_without_hardening.build

How do I need to change the CPP/C++/CFLAGS, so we get what we want? Or is this a bug from Qt side?

Regards,

sandro

Am Donnerstag, 22. September 2016, 17:44:38 CEST schrieb Daniel Kahn Gillmor:
> On Sat 2016-09-10 13:00:26 -0400, Daniel Kahn Gillmor wrote:
> > As i understand it from a talk given by Andre Heinecke (GPGME upstream,
> > cc'ed here) at OpenPGP.conf, GPGME 1.7.0 is likely to take over as
> > upstream from pyme, gpgmepp, and qgpgme.  (it will also add a
> > common-lisp binding, but that's not in debian at all, so i'll ignore it
> > for now).  1.7.0 isn't yet released, but it sounds like the release is
> > due fairly soon.
> 
> 1.7.0 was released a couple days ago, and i just uploaded it to debian
> unstable, along with a fair bit of debian packaging cleanup.
> 
> The source package i uploaded currently only builds the C library.  It
> does not build or attempt to ship the python, common-lisp, c++, or qt
> bindings yet.
> 
> > I don't think it'd be unreasonable for the debian GnuPG packaging team
> > take on these additional binary packages within the gpgme1.0 source
> > package, which would mean that the source packages for python-pyme, and
> > gpgmepp would probably go away, and the kdepimlibs library would stop
> > building libqgpgme1 and libgpgme++2v5.
> 
> I plan to work in experimental for a version that will produce the
> python3 bindings -- binary package python3-pyme in particular.  I'm not
> yet aiming to "hijack" the 2.x bindings with this source package, since
> i haven't heard from Arnaud.
> 
> Arnaud, at some point we should let the gpgme1.0 source package take
> over the python-pyme binary package, though, since i understand that it
> is now python2-compatible upstream.  I haven't heard back from you here,
> but given that the transition has happened upstream, i hope it will be
> OK.  Would you like to help out with this?  I'd be happy to have your
> input and experience on the python bits (and elsewhere if you're
> willing).
> 
> If someone wants to collaborate on doing the same kind of work for qt
> and c++, i'm happy to coordinate via the pkg-gnupg-maint git repo,
> and/or on IRC #debian-gnupg on oftc.
> 
>        --dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20161007/1c51010b/attachment.sig>