1.8.0-2 FTBFS in zesty 17.04

I would note that this is the first gpgme version from gpg directly, with the Qt bindings built. These will be essential for future KDE applications and frameworks, as the gpgmepp previously built in KDE's own packages is being dropped.

Subscribing kubuntu in that case

iiuc, the hardening options for qgpgme need to match the hardening
options for qtcore. if ubuntu is not setting at least the pie hardening
option for qtcore, then it's missing out on the possibility of address
space layout randomization (aslr) for many packages.

I recommend that ubuntu should track debian's improvements in pie
hardening for qt.

        --dkg

I note that Jose has some apparently successful builds of 1.8.0-3 in the following ppa

https://launchpad.net/~panfaust/+archive/ubuntu/kde-test-good

so I would like to enquire if the changes contained there are acceptable, as if so can these be applied to the ubuntu archive package to enable moving forward with applications that now require the new Qt bindings to build.

Seems the indefinite hang in running tests occurs in

lang/python/tests/t-callbacks.py

at the point where

c.op_genkey(parms, None, None)

is called in the '# Test the progress callback' and '# Test exception handling' sections

Looking at the testing work Jose did a couple of weeks ago (and doesn't seem to have come back to yet), his testing changes consolidate to effectively the attached diff.

I am unsure if such changes are acceptable for a package upload, or if they are only acceptable as diagnostic/troubleshooting changes.

The attachment "gpgme1.0_1.8.0-3ubuntu1.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

No, that's not really acceptable. firstly +pic is not an hardening option AFAIK, what you effectively did was disabling pie. Then I don't particularly like disabling tests just because they hang; please somebody investigate why they hang and actually fix them.

Unsubscribing sponsors for now.

Unfortunately it is only on the ubuntu build system that the test in question seems to hang. On debian's build system, and local pbuilder/sbuild chroot and straight from source, the tests complete without issue. So I am unable to investigate the cause further.

Sounds like the problem is that this build leaves processes hanging around from its tests. Unfortunately this currently causes builds to hang, basically because launchpad-buildd uses sbuild's sudo mode rather than its schroot mode. So the hang is a known bug in launchpad-buildd, but it should still be possible to fix this: make sure that the test suite cleans up all its processes on exit, which is something that should be actionable with a bit of care.

On Fri 2016-12-30 20:19:04 -0500, Colin Watson wrote:
> Sounds like the problem is that this build leaves processes hanging
> around from its tests. Unfortunately this currently causes builds to
> hang, basically because launchpad-buildd uses sbuild's sudo mode rather
> than its schroot mode. So the hang is a known bug in launchpad-buildd,
> but it should still be possible to fix this: make sure that the test
> suite cleans up all its processes on exit, which is something that
> should be actionable with a bit of care.

it wouldn't surprise me if there are indeed processes still hanging
around due to modern GnuPG's multi-process model (with dirmngr and
gpg-agent getting launched as-needed).

If you're doing the build on a modern linux system, and you haven't
explicitly disabled the GnuPG's inotify support, and the test suite
deletes any temporary GNUPGHOME homedirs, the subprocesses should notice
the deletion and terminate promptly. This might depend on relatively
recent versions of "modern" GnuPG, though (debian's currently shipping
2.1.17, fwiw).

              --dkg

On 31/12/16 01:19, Colin Watson wrote:
> Sounds like the problem is that this build leaves processes hanging
> around from its tests. Unfortunately this currently causes builds to
> hang, basically because launchpad-buildd uses sbuild's sudo mode rather
> than its schroot mode. So the hang is a known bug in launchpad-buildd,
> but it should still be possible to fix this: make sure that the test
> suite cleans up all its processes on exit, which is something that
> should be actionable with a bit of care.
>

As discussed, the hang is not on exit/completion of the testsuite
though, but seems to be at a particular call midway through a one test.
So seems there is something a little different at play here.

The issue with the buildd hang is now reported against launchpad-builds as:

Bug #1655298 - Indefinite build hangs during python tests of gpgme1.0 v1.8

Did the debdiff get deleted? I've landed here because gpgme1.0 ftbfs is blocking claws-mail 3.14.1-2 promotion. I'm stuck (local build) on the Qt-related build crash. If I can fix that, I'll investigate the Python test suite hang.

On 12/01/17 18:29, Barry Warsaw wrote:
> Did the debdiff get deleted? I've landed here because gpgme1.0 ftbfs is
> blocking claws-mail 3.14.1-2 promotion. I'm stuck (local build) on the
> Qt-related build crash. If I can fix that, I'll investigate the Python
> test suite hang.
>

There is a diff here that was the original solution to getting configure
to find Qt, and then continue to the build and tests.

http://paste.ubuntu.com/23788286/

That should result in a successful LOCAL build with no test suite hang.

However, as said, the same build on the launchpad builders result(ed) in
a hang at the point in the tests already discussed.

I have just quickly uploaded a test example here:

https://launchpad.net/~rikmills/+archive/ubuntu/gpgme-tests

I will cancel the amd64 build when it hangs to make the buildlog
available, but will leave the other architectures to time out and
eventually be killed by the launchpad build system itself.

This diff gets past the build failure:

1 file changed, 1 insertion(+), 1 deletion(-)
debian/rules | 2 +-

modified debian/rules
@@ -1,6 +1,6 @@
 #!/usr/bin/make -f

-export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie,+pic
 export QT_SELECT := qt5
 export DEBIAN_VERSION = $(shell dpkg-parsechangelog | sed -n -e '/^Version:/s/.*: //p')

[back]

On 12/01/17 19:38, Barry Warsaw wrote:
> This diff gets past the build failure:
>

It does, but sadly still FTBFS or hangs in tests when built on launchapd

On Jan 12, 2017, at 07:30 PM, Rik Mills wrote:

>I will cancel the amd64 build when it hangs to make the buildlog
>available, but will leave the other architectures to time out and
>eventually be killed by the launchpad build system itself.

Any results yet?

Is it possible that the test suite tries to hit the internet? And if it does
but external hosts are unavailable, what's the failure mode?

That's another difference between local builds and the Launchpad buildds. The
latter do not allow access to the internet.

This probably isn't it though. I added a patch to set `offline=True` to the
Context constructor and while it hasn't been killed yet, a PPA build of mine
still appears hung. Just thought I'd mention it.

Sorry, I did a 2nd build as something odd happened in the arm64 builder of the 1st.

As you rightly say, they just hand now and will be killed by L.

Manually cancelling a build reveals some more about what what happening at the time. see below:

This agree with other diagnostic builds I did which show the hanging call is

c.op_genkey(parms, None, None)

---------- Log from manually cancelled build ------------

GNUPGHOME=/<<PKGBUILDDIR>>/lang/python/tests LC_ALL=C GPG_AGENT_INFO= top_srcdir=../../.. srcdir=. LD_LIBRARY_PATH="../../../src/.libs:" /usr/bin/python3 ./run-tests.py \
  --interpreters="/usr/bin/python /usr/bin/python3" --srcdir=. \
  initial.py t-wrapper.py t-callbacks.py t-data.py t-encrypt.py t-encrypt-sym.py t-encrypt-sign.py t-sign.py t-signers.py t-decrypt.py t-verify.py t-decrypt-verify.py t-sig-notation.py t-export.py t-import.py t-trustlist.py t-edit.py t-keylist.py t-wait.py t-encrypt-large.py t-file-name.py t-idiomatic.py t-protocol-assuan.py final.py
starting gpg-agent
RUN: /usr/share/launchpad-buildd/slavebin/scan-for-processes ['scan-for-processes', 'PACKAGEBUILD-11850388']
Scanning for processes to kill in build /home/buildd/build-PACKAGEBUILD-11850388/chroot-autobuild...
Traceback (most recent call last):
  File "./t-callbacks.py", line 105, in <module>
    c.op_genkey(parms, None, None)
  File "/<<PKGBUILDDIR>>/lang/python/build/lib.linux-x86_64-2.7/gpg/core.py", line 151, in wrapper
    return _funcwrap(self, *args)
  File "/<<PKGBUILDDIR>>/lang/python/build/lib.linux-x86_64-2.7/gpg/core.py", line 135, in _funcwrap
    return errorcheck(result, "Invocation of " + name)
  File "/<<PKGBUILDDIR>>/lang/python/build/lib.linux-x86_64-2.7/gpg/errors.py", line 62, in errorcheck
    raise GPGMEError(retval, extradata)
gpg.errors.GPGMEError: Invocation of gpgme_op_genkey: GnuPG: End of file

As I also commented in Bug #1655298 :

Adding some debug statements on other the builds showed that that hang is occurring in

lang / python / tests / t-callbacks.py

specifically, when the c.op_genkey call is made in the section shown below.

# Test the progress callback.
parms = """<GnupgKeyParms format="internal">
Key-Type: RSA
Key-Length: 1024
Name-Real: Joe Tester
Name-Comment: with stupid passphrase
Name-Email: <email address hidden>
Passphrase: Crypt0R0cks
Expire-Date: 2020-12-31
</GnupgKeyParms>
"""

messages = []
def progress_cb(what, typ, current, total, hook=None):
    assert hook == messages
    messages.append(
        "PROGRESS UPDATE: what = {}, type = {}, current = {}, total = {}"
        .format(what, typ, current, total))

c = gpg.Context()
c.set_progress_cb(progress_cb, messages)
c.op_genkey(parms, None, None) <---- HANGS HERE
assert len(messages) > 0

# Test exception handling.
def progress_cb(what, typ, current, total, hook=None):
    raise myException

c = gpg.Context()
c.set_progress_cb(progress_cb, None)
try:
    c.op_genkey(parms, None, None) <---- HANGS HERE
except Exception as e:
    assert e == myException
else:
    assert False, "Expected an error, got none"

On 12/01/17 21:52, Barry Warsaw wrote:
> Any results yet?

[FAILEDTOBUILD] amd64
[FAILEDTOBUILD] arm64
[FAILEDTOBUILD] armhf
[FAILEDTOBUILD] i386
[FULLYBUILT] ppc64el

Failures hung in the usual place and were killed by LP after 2 hours 40
minutes

ppc64el hung for nearly that whole time, then for some bizarre reason
decided to complete. Not seen that before.

On Jan 12, 2017, at 10:49 PM, Rik Mills wrote:

>ppc64el hung for nearly that whole time, then for some bizarre reason
>decided to complete. Not seen that before.

That sure is weird.

Seems that even completely disabling the hanging tests is not enough now. Doing that results in failing tests on arm64 and armhf.

amd64, i386 and ppc64el pass

As in this build https://launchpad.net/~rikmills/+archive/ubuntu/staging-kde-apps-16.12/+sourcepub/7397892/+listing-archive-extra

On Thu 2017-01-12 17:10:07 -0500, Rik Mills wrote:
> Adding some debug statements on other the builds showed that that hang
> is occurring in
>
> lang / python / tests / t-callbacks.py
>
> specifically, when the c.op_genkey call is made in the section shown
> below.

a hang during key generation is often due to lack of entropy on the
system. Can you ensure that the system isn't entropy-starved somehow?

         --dkg

On Jan 13, 2017, at 09:26 PM, dkg wrote:

>a hang during key generation is often due to lack of entropy on the
>system. Can you ensure that the system isn't entropy-starved somehow?

Oh, oh. I wonder if you're getting bitten by PEP 524

https://www.python.org/dev/peps/pep-0524/

I don't believe this was back ported to Python 3.5 or 2.7 though.

> https://www.python.org/dev/peps/pep-0524/

This has nothing to do with it. GpgME does not gather the entropy / randomness itself but leaves this to libgcrypt / gpg-agent. On Linux system this means to add some entropy from /dev/random into the mix. If nothing is available there it will block indefinitely until enough entropy is available.

So I agree with dkg's suggestion that a lack of entropy in your build environments is a likely explanation.
I can reproduce a fairly long hang by starving my system of entropy using "cat /dev/random > /dev/null" and then running make check.

It could be worked around by something like "rngd -r /dev/urandom" but the testsuite should not rely on hard entropy. GnuPG's testsuite itself includes a solution to that problem, launching gpg-agent with --debug-quick-random.

I've changed the start script of the gpg-agent in gpgme accordingly with:

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=a98951a30a6ae603ffac4ec8c5168aa6d1019933

To also use that option. Please confirm if this fixes the Problem in your build environment.

On 25/01/17 13:22, Andre Heinecke wrote:
> I've changed the start script of the gpg-agent in gpgme accordingly
> with:
>
> https://git.gnupg.org/cgi-
> bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=a98951a30a6ae603ffac4ec8c5168aa6d1019933
>
> To also use that option. Please confirm if this fixes the Problem in
> your build environment.
>

Applied the patch to 1.8.0-3, and does not seem to have made any difference.

am64, i386 and armhf builds still hang at the same point and are killed
by launchpad with

"Build killed with signal TERM after 150 minutes of inactivity"

arm64 build just fails somewhere, and LP fails to render a buildlog for
some strange reason

ppc64el, as it did before, hangs for a bit then completes ok.

Indeed my fix was incomplete, according to your build log the gpg-agent for the python tests is already running when the modified start-stop-agent script is called so it was still started without debug quick random.

This was because in difference to my local system gpg is gpg2.1 and not gpg1 so the environment setup for the python scripts already launches the agent when importing secret keys.

The additional fix for that is:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=f3ca2c9ce9fd4a03e293065f10b92589a7e642d6

I've tested in a personal ppa and with this patch it successfully compiled:
https://launchpad.net/~aheinecke/+archive/ubuntu/gpgme-test

Sorry for the extra work.

On 26/01/17 10:26, Andre Heinecke wrote:
> I've tested in a personal ppa and with this patch it successfully compiled:
> https://launchpad.net/~aheinecke/+archive/ubuntu/gpgme-test
>
> Sorry for the extra work.
>

Thank you :)

Rebuilt that in my ppa, and while the 5 (out of 7) archive architectures
I can test on now get past the hang and complete their test, armhf &
arm64 builds fail the tests and so fail the build.

These passed when building on debian for those architectures as far as I
can see.

Regarding the armhf failure in t-thread-keylist-verify This is a test for a race condition bug we had in the past. It's fairly resource intensive so maybe it runs into resource problems on the armhf builder. Maybe we can just reduce the number of threads there or disable the test.

Regarding the arm64 failure. The Qt tests use new style connects and lambdas googling a bit brought me to https://bugreports.qt.io/browse/QTBUG-36129 but I'm not sure what the suggestion from this should be. Adding pie to the compile flags? Or removing the -Bsymbolic-functions (Debian does not use that flag).

Maybe someone from a KDE Packaging team can help here because this probably is not a QGpgME specific issue.

Thanks; I'm testing this in my own PPA now. If it succeeds, then I'm happy to upload this to Zesty. I have my own patch, which I'll attach here, but I'm also happy to sponsor a fix authored by you if you want to attach a debdiff to apply to the Zesty package. Or, if you are an Ubuntu developer, don't wait for me!

Barry: The build with your patch seemed to hang again, and be killed on LP timeout.

This one builds in my ppa.

I don't think Barry included the patch against entropy starvation in his PPA so It's expected that it would hang.

I've discussed possibly high resource usage of the gpgme test suite (there were also other complaints) and we reduced it accordingly: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=7bd6ab4a91d43d7cbf5d347c0c12e0e4f9f7e3bf

This might fix the armhf error in t-thread-keylist-verify

Is there still something open here that would block GpgME-1.8 from making it into ubuntu?

Otherwise we'll probably also release a new GpgME Version including these changes soon.

On 30/01/17 13:27, Andre Heinecke wrote:
> I've discussed possibly high resource usage of the gpgme test suite
> (there were also other complaints) and we reduced it accordingly:
> https://git.gnupg.org/cgi-
> bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=7bd6ab4a91d43d7cbf5d347c0c12e0e4f9f7e3bf
> This might fix the armhf error in t-thread-keylist-verify

Applied as a patch to v1.8, the first hunk of that modifying
/tests/gpg/t-gpgconf.c fails to apply due to other commits since v1.8.

I am not 100% certain if it is redundant on the older revision, or not.

> Is there still something open here that would block GpgME-1.8 from
> making it into ubuntu?

Presumably the Qt test issue for arm64 would still exist, although from
my perspective that is not critical, or maybe fixable later.

Whether it would block things, I am not sure.

> Otherwise we'll probably also release a new GpgME Version including
> these changes soon.

That would be good.

On Jan 30, 2017, at 09:42 AM, Rik Mills wrote:

>** Patch added: "gpgme1.0_1.8.0-3ubuntu1.debdiff"
> https://bugs.launchpad.net/ubuntu/+source/gpgme1.0/+bug/1647204/+attachment/4810708/+files/gpgme1.0_1.8.0-3ubuntu1.debdiff

Thanks for the debdiff. LGTM; building in my PPA. If it passes, I'll sponsor
this. You might consider reporting this bug (and attaching the debdiff) to
Debian since we'll need to resync the package at some point.

The PPA build is looking good. I'll check autopkgtests next and if that all looks good, I'll sponsor your debdiff. Thanks!

All looks good, so I'm uploading. Thanks very much for all the help!

On 30/01/17 16:23, Barry Warsaw wrote:
> The PPA build is looking good. I'll check autopkgtests next and if that
> all looks good, I'll sponsor your debdiff. Thanks!

Ummm. If you are Ok with that FTBFS still on arm64 and armhf, then ok.

On Jan 30, 2017, at 04:42 PM, Rik Mills wrote:

>Ummm. If you are Ok with that FTBFS still on arm64 and armhf, then ok.

Dang. Well, we'll have to deal with that next.

On 30/01/17 13:27, Andre Heinecke wrote:
> I've discussed possibly high resource usage of the gpgme test suite
> (there were also other complaints) and we reduced it accordingly:
> https://git.gnupg.org/cgi-
> bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=7bd6ab4a91d43d7cbf5d347c0c12e0e4f9f7e3bf
>
> This might fix the armhf error in t-thread-keylist-verify

I tried building today's git snapshot, and still get test failures on
armhf and arm64

https://launchpad.net/~rikmills/+archive/ubuntu/staging1/+sourcepub/7468978/+listing-archive-extra

I can't test powerpc in a ppa.

Ah but now armhf and arm64 fail because of the same problem. The connects in the Qt Testsuite fail.

As I already mentioned I think its some incompatibility between the Qt buildflags and the QGpgME buildflags:

https://bugreports.qt.io/browse/QTBUG-36129 but I'm not sure what the suggestion from this should be. Adding pie to the compile flags? Or removing the -Bsymbolic-functions (Debian does not use that flag). I don't have much knowledge on these kinds of problems.

Maybe you could look at some Tier 0 KDE Framework and check what they are using as compile flags? They should have similar problems.

On 10/02/17 09:48, Andre Heinecke wrote:
> Ah but now armhf and arm64 fail because of the same problem. The
> connects in the Qt Testsuite fail.
>
> As I already mentioned I think its some incompatibility between the Qt
> buildflags and the QGpgME buildflags:
>
> https://bugreports.qt.io/browse/QTBUG-36129 but I'm not sure what the
> suggestion from this should be. Adding pie to the compile flags? Or
> removing the -Bsymbolic-functions (Debian does not use that flag). I
> don't have much knowledge on these kinds of problems.

thiago = Thiago Macieira (from your buglink)

#kde-devel on irc.freenode.net

[20:59] <thiago> acheronuk: any chance you can get me the build logs in
the actual server?
[20:59] <thiago> if the -Bsymbolic-functions argument is there, that's
the reason
[20:59] <thiago> that option is ABI-incompatible outside
strictly-controlled environments
[21:00] <thiago> it should be opt-in, not opt-out
[21:03] <acheronuk> all I have
https://launchpadlibrarian.net/305535133/buildlog_ubuntu-zesty-arm64.gpgme1.0_1.8.0+git20170207-0build1_BUILDING.txt.gz
[21:23] <thiago> acheronuk: thanks
[21:24] <thiago> acheronuk: /bin/bash ../../../libtool --tag=CXX
--mode=link g++ [...] -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now
-o libqgpgme.la [...]
[21:24] <thiago> culprit found
[21:25] <svuorela> thiago: that log file seems to be full of
-Bsymbolic-functions
[21:25] <thiago> it is
[21:26] <thiago> the one that matters is the one I pasted: libqgpgme.so
was linked with it
[21:27] <svuorela> the debian build log does not look like it contains that
[21:28] <thiago> as I said, outside of x86-64, you have to make it opt-in
[21:28] <acheronuk> thiago: thx. now I have to work out how to get rid
of that without nuking the rest of the build
[21:29] <svuorela> acheronuk: talk to your toolchain maintainers
[21:29] <svuorela> I guess that's where it is injected
[21:32] <thiago> acheronuk: nuke the rest of the build and rebuild the world
[21:33] <thiago> I'm not kidding
[21:33] <thiago> rebuild the world
[21:33] <thiago> if your toolchain people don't like the change, they
can join the club. I've been trying to get GCC+binutils folks to do
something about unnecessary ELF interposition for some time

How to achieve a working solution is something I still don't know though.

For my purposes, I care very little if arm* builds break/fail, but is
obviously an issue for others, and regards getting this out of
'-proposed' wilderness.

Hi,

> No, that's not really acceptable. firstly +pic is not an hardening option AFAIK, what you
> effectively did was disabling pie. Then I don't particularly like disabling tests just because
> they hang; please somebody investigate why they hang and actually fix them.

> Unsubscribing sponsors for now.

I just wanted to say that the package I had in my kde-test-good PPA was just an experiment, nothing actually intended to be uploaded. Before finishing completely the fixing of this, I had to pause for a while my work on Ubuntu (I'm sorry about that).

After catching up again with the work I was doing I see the problems I spotted initially (the entropy starvation and the tests hanging) were solved, thank you!

However there are still at least a couple of problems more with this package. Right now, I'm doing some experiments here:
https://launchpad.net/~panfaust/+archive/ubuntu/gpgme/

Yes, it's not something acceptable for uploading for now! But I hope to get something finished soon.

Cheers.

Hi again, I think I'm done now with a proposal for upload, the package was tested in this PPA:
https://launchpad.net/~panfaust/+archive/ubuntu/gpgme

Note that I also tested a rebuild of kf5-kdepim-apps-libs against it; right now kf5-kdepim-apps-libs is failing against the current version in -proposed, making some autopkgtests fail and blocking the migration of some kde libraries. See, for instance:
https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kiconthemes

So we would really appreciate if someone could upload this fixed package.

If you think the proposed fix can be improved, suggestions are welcomed :)

@panfaust: the patch looks pretty reasonable. I'll give it a try in my ppa, which builds all arches except powerpc and s390x.

So far so good: https://launchpad.net/~barry/+archive/ubuntu/experimental/+packages

I'm going to test encryption with claws-mail in a VM. If that looks good too, I'll sponsor gpgme1.0 with your patch.

Testing LGTM. Thanks very much for the patch. I will sponsor it.

Uploaded. Now we just have to get the archive admins to let it pass now that we've entered feature freeze, if that's even a good idea.

This bug was fixed in the package gpgme1.0 - 1.8.0-3ubuntu2

---------------
gpgme1.0 (1.8.0-3ubuntu2) zesty; urgency=medium

  * Add in libgpgme-dev a libgpgme-pthread.so pointing to libgpgme.so, this
    will fix the build failures of kf5-kdepim-apps-libs when built against this
    gpgme package.
  * Set LDFLAGS=-Wl,-z,relro in debian/rules, this avoids passing
    "-Bsymbolic-functions" which seems to be the cause of FTBFS'es for some
    architectures.
  * Add 0005-tests-Reduce-iterations-threads.patch, this fixes another cause of
    FTBFS'es on some architectures.
  * Previous two changes fix (LP: #1647204)
  * Thank you to Rik Mills for his help fixing the above problems.

 -- José Manuel Santamaría Lema <email address hidden> Sat, 18 Feb 2017 22:22:02 +0100

On Thu 2017-02-23 16:57:12 -0500, Launchpad Bug Tracker wrote:
> * Add in libgpgme-dev a libgpgme-pthread.so pointing to libgpgme.so, this
> will fix the build failures of kf5-kdepim-apps-libs when built against this
> gpgme package.

As i wrote when asked on IRC, i think this is the wrong fix for this
problem.

if kf5-kdepim-apps-libs is being built correctly, it should be using
gpgme-config from libgpgme-dev itself to choose how to link, which
should know which .so to link against.

why should this additional symlink be necessary for the build of
kf5-kdepim-apps-libs?

maybe i'm misunderstanding something about the build of
kf5-kdepim-apps-libs. can you explain more?

                       --dkg