gpgme and the C++, Qt 5 and Python bindings can be configured, built and installed with the following commands:

./autogen-all.sh  # runs autogen.sh for gpgme, lang/cpp, lang/qt and lang/python
mkdir build
cd build
../configure --prefix=/opt/gnupg/2.4 --enable-maintainer-mode --enable-languages="cpp qt python" --enable-qt-version=5
make
make check
make install

i.e. the only difference is that one needs to run ./autogen-all.sh instead of ./autogen.sh. And that one needs to enable the bindings and specify the Qt version. (By default, the Qt 6 are built if Qt 6 is found.)

The current proposal has been pushed to the branch ikloecker/t7110-nested-bindings-packages.

Adding vsd33 for testing with next VSD

This can be tested with T6879: Kleopatra: Add support for adding an ADSK.

In future, when spawn function API is used by libassuan (and stable), we can support gpgme with no gpgme-w32-spawn.exe.
(And it will be simpler, just using native functions in libassuan, instead of replacing ones by assuan_system_hooks.)

Information about revocation keys can now be retrieved from a Key object. Verified with internal test runners. Independent tests will be done with T7095.

great, thanks!

With caching, did you have something like this in mind?

Actually we are using gpgme already for 64 bit Windows; but statically linked.

In T7036#186290, @ebo wrote:

Tested with VS-Desktop-3.2.93.391-Beta:

Tested with VS-Desktop-3.2.93.391-Beta:

Hopefully fixed by disabling the DeviceInfoWatcher on Windows again.

Ah, I see what's up with the man page. It's documenting the Glibc getdents64() wrapper interface, so that's why it uses the Glibc types. But gpgme isn't using that wrapper, it's doing the syscall directly, so it should use the types the kernel uses, which as you've noticed are just generic unsigned and signed 64-bit integers, matching what my patch does.

/include/linux/dirent.h defines

struct linux_dirent64 {
	u64		d_ino;
	s64		d_off;
	unsigned short	d_reclen;
	unsigned char	d_type;
	char		d_name[];
};

In D600#6448, @ikloecker wrote:

$ man getdents64

getdents64()
    The  original  Linux getdents() system call did not handle large filesystems and large file offsets.  Consequently, Linux 2.4
    added getdents64(), with wider types for the d_ino and d_off fields.  In addition, getdents64() supports an  explicit  d_type
    field.

    The  getdents64()  system call is like getdents(), except that its second argument is a pointer to a buffer containing struc‐
    tures of the following type:

        struct linux_dirent64 {
            ino64_t        d_ino;    /* 64-bit inode number */
            off64_t        d_off;    /* 64-bit offset to next structure */
            unsigned short d_reclen; /* Size of this dirent */
            unsigned char  d_type;   /* File type */
            char           d_name[]; /* Filename (null-terminated) */
        };

$ man getdents64

getdents64()
    The  original  Linux getdents() system call did not handle large filesystems and large file offsets.  Consequently, Linux 2.4
    added getdents64(), with wider types for the d_ino and d_off fields.  In addition, getdents64() supports an  explicit  d_type
    field.

In D600#6445, @gniibe wrote:

If it is intentional change by musl (requiring some changes by an application), we can use __ino64_t_defined and __off64_t_defined macro to see if those types are defined or not.

Fixed in gpgme 1.21.0.

If it is intentional change by musl (requiring some changes by an application), we can use __ino64_t_defined and __off64_t_defined macro to see if those types are defined or not.

Meanwhile version 1.32.2 builds. Greatest change is Python 3.12 instead of 3.11…

off64_t mat not the same as int64_t

Breaks them how?

In D600#6438, @werner wrote:

This breaks existing 32 bit systems with the 64 bit types.

This breaks existing 32 bit systems with the 64 bit types. Thus a test for off64_t is required which redefines it to int64_t if it does not exist.

Sorry, I meant they do *not* arrive at the web interface, they are not visible to me.

It seems my eMails to gnupg-devel@gnupg.org do reach the list …

Of course, it should be possible to toggle "disabled" in Kleopatra.
A (context) menu entry "disable certificate" (or "enable certificate") should be sufficient.

Oops. I closed the task accidentally.

Fixed (for GnuPG 2.4). I hope 2.2 prints the same status messages.

The General Error happens also when the PIN is blocked and no Pinentry opens.
As in this case, where the indicated "Generate New Keys" button was used on a blocked card.

Trying to reach Ralph Seichter via the eMail address he is using failed – Osterferien?

strcasecmp is pretty standard on Unix. However, in GnuPG we test for it and mostly use our own ascii_strcasecmp to avoid fun with locales. Ralph Seichter is providing macOS builds for GnuPG (https://sourceforge.net/p/gpgosx/docu/Download/) . Maybe it is worth to contact him via the gnugp-devel mailing list and ask him whether he has experience with your toochain.

By adding "-Wl,-t" to the arguments g++ reported:

Libtool invocation has "--tag=CXX --mode=link /opt/local/bin/g++-mp-7 -std=c++11 -pipe -Os -std=c++17 -D_GLIBCXX_USE_CXX11_ABI=0", but g++ then has no -lstdc++ – in C -lc is automatically used because there all C library functions can be taken from… (same for mathematical functions and -lm)

It seems libtool fails to add the standard C and C++ libraries to the link command line. On Linux I have "[...] -lstdc++ -lm -lc [...]" in the libtool link command line. Looks like a bug in the tooling (macports or libtool).

Thanks, that patch works for me.

We have discussed this yesterday. The idea/plan is to release the core library and the bindings as separate tarballs (created from the same repo) in the future.

This can be tested with Kleopatra by configuring an invalid keyserver and then updating an OpenPGP certificate.

In 2.4 we have rG1383aa475 which does

Pushed the change in: rGf50c543326c2: agent: Allow simple KEYINFO command when restricted.

No, thank you both for the speedy responses :)

Thanks a lot for your quick testing.
The commit rGff42ed0d69bb: gpg: Enhance agent_probe_secret_key to return bigger value. of GnuPG 2.2 introduced this bug.

Ah, thanks Werner, I'll keep that in mind.

Although I don't think this is the case here one should be aware that tests mail fail due to global configuration of GnuPG (/etc/gnupg/*.conf). There is no easy way so solve this except for running a per-test local installation of GnuPG using the gpgconf.ctl feature.

You can get more information by applying a patch below (and also tests/json/Makefile.in):

diff --git a/tests/json/Makefile.am b/tests/json/Makefile.am
index 90fba79e..7523bb6b 100644
--- a/tests/json/Makefile.am
+++ b/tests/json/Makefile.am
@@ -106,6 +106,8 @@ gpg-agent.conf:
 # a key from a smartcard reader (error might be: Unusable secret key)
 	echo pinentry-program $(abs_srcdir)/../gpg/pinentry > ./gpg-agent.conf
 	echo disable-scdaemon >> ./gpg-agent.conf
+	echo debug-all >> ./gpg-agent.conf
+	echo log-file /tmp/gpg-agent-logfile.log >> ./gpg-agent.conf

T4820 is not related (it's a failure of t-keylist-secret in t-json), while this is failure of t-decrypt.