Steps to (hopefully) reproduce
Cloned the developtment branch and reverified the commit hash described in
https://www.gnupg.org/download/git.html
[Removing https://git.gnupg.org/gnupg.git would be great, since cloning that did not work]
$ ./autogen.sh
$ ./configure --sysconfdir=/etc --enable-maintainer-mode && make
$ make check &> check.log
make does not exist also, though cpu seems to not work on

You need the development package installed (e.g. libbz2-dev on Debian-like systems). Then, rerun configure and rebuild.

$ gpg2 --with-colons --list-config compressname
cfg:compressname:nicht komprimiert;ZIP;ZLIB

Adressed in 94645311f8a3e9ae33643512f87fbef41bf0556f.

The 4gb-packet test reads an OpenPGP message compressed with BZIP2. If that test fails, it most certainly means that you compiled GnuPG without support for BZIP2. You can check this with:

'82' is the line of the failing assertion.

fwiw, this remains a problem on 2.1.20: https://buildd.debian.org/status/fetch.php?pkg=gnupg2&arch=s390x&ver=2.1.20-1&stamp=1491409561&raw=0

While I can't reproduce this problem myself, I think I found an issue of gpg-agent passphrase caching.
Double free may happen when multiple threads enter agent_put_cache, for example.

Err... npth repo is not yet added under dev.gnupg.org.
I requested as T3064.

Thank you. I just tried:

autoreconf -fiv && ./configure && make && make check
...
Making check in src
Making check in tests
make  check-TESTS
PASS: t-mutex
PASS: t-thread
PASS: t-fork
==================
All 3 tests passed
==================

on NetBSD-7.99.67/amd64.

git://git.gnupg.org/npth.git

Thanks for working on this.
I can't seem to find a link to the repository for testing, can you please point me in the right direction?

I found that FreeBSD also requires -lpthread thing. I also commit the change to the repo.
Tested with FreeBSD 11.0.
I think that TrueOS can be considered as FreeBSD variant.

Fixed in the repo for DragonFlyBSD 4.8 too.

In T2998, NetBSD was fixed.
I'll check for DragonFlyBSD.
IIUC, FreeBSD and OpenBSD has no issue.

It works for me on NetBSD 7.1. Please test.

I tested with NetBSD 7.1 and -lrt is not required.
Nevertheless, it would be required for older NetBSD, so I leave -lrt check for NetBSD.
I'm going to push the change of D415 now.

Could you please look at https://dev.gnupg.org/T2998 ?

In 2.1.19, gpg-agent uses getpeerucred for macOS. I changed it (since it seemed not working). In 2.1.20, gpg-agent now uses getsockopt with LOCAL_PEERPID.
It seems for me that the crash occurs by ucred_free. If this is the case, 2.1.20 fixes this issue.

Fix published in 2.1.19.

Fix published in 2.1.20.

I don't have one of these systems handy to test with, but if the fix in dee026d7 does what it says it does, this sounds like it's probably OK to close in my book. if there are more problems, i'm sure we can re-open it.

Sure:

user@group: make check XTESTS=4gb-packet.scm verbose=4 &> 4gb-packet.scm_execution.log
and content of 4gb-packet.scm.log appended for completeness{F66019}

Time to say good bye my dear bug.

we are now at 2.1.20 - time to mark this one as resolved.

dkg: Can we close this now that 2.1.20 is out?

Fix is in 2.1.20

I think we can close this bug now that we switched off the roundup instace (modulo DNS TTL). Welcome to al-kindi, aka dev.gnupg.org. Old bug reports are redirected to here.

To make this more precise I think above might actually be more then one bug.

Can you please run

cd tests/openpgp
make check XTESTS=4gb-packet.scm verbose=4

This is no a bug but a non-proper installation of libgcrypt. In fact the output
of libgcrypt's "make install" shows hints on how to finish the install; also
pointing to ldconfig.

In general it is not easy to install a newer version of a library on a system
which already has an older version of that library.

Fixed in 348da58fe0c3656e6177c98fef6b4c4331326c8e.

Well, if you ask *this* nicely, then I will most certainly get *right* to it.

You know what I find annoying? Me writing tests, and then on the first sight of
trouble, we back them out or disable them.

Then please fix that. TBH I find it annoying that you did not check that your
commit actually solves the problem. I mean just using the "stable" branch would
have been enough to see that.

It's important that GPGME builds / runs against all versions of GnuPG and most
distros treat test failures as build failures. Now 1.9 will again need patches
or the python bindings disabled which is creating unnecessary work downstream
which already had enough work with the recent releases.

Indeed. We did not address the issues at all, we decided to skip all tests and
some fell through the cracks.

Unfortunately 1.9.0 doesn't address fully the issues:

[ 108s] Traceback (most recent call last):
[ 108s] File "./t-protocol-assuan.py", line 27, in <module>
[ 108s] err = c.assuan_transact('nop')
[ 108s] File "/home/abuild/rpmbuild/BUILD/gpgme-1.9.0/lang/python/python2.7-gpg/build/lib.linux-
x86_64-2.7/gpg/core.py", line 790, in assuan_transact
[ 108s] errorcheck(err)
[ 108s] File "/home/abuild/rpmbuild/BUILD/gpgme-1.9.0/lang/python/python2.7-gpg/build/lib.linux-
x86_64-2.7/gpg/errors.py", line 62, in errorcheck
[ 108s] raise GPGMEError(retval, extradata)
[ 108s] gpg.errors.GPGMEError: GPGME: IPC connect call failed

Two tests fail.

gnupg2-2.1.19-1.fc27.x86_64
libgpg-error-1.27-1.fc27.x86_64
libassuan-2.4.3-2.fc26.x86_64

Which version of _GnUPG_ are you using?

D416: 991_0001-qt-pass-fmt-to-gpgrt_asprintf.patch