Closing.

I think that this would be more like something for a "Task" in Kleopatra and not for a job in GPGME. As a job usually is only one operation and having a single job do two operations is different from the rest of the API. So I would be against it. A signEncryptJob is IMO something that should be reserved for a time when GPGSM supports gpgsm -se

It's now possible to build the Qt 5 bindings and the Qt 6 bindings in the same build. In fact, it's the new default (if the needed Qt libraries are found).

This should be tested as part of testing T5960 by checking that the German error description "Falscher Rückstellcode" is shown after entering a wrong reset code (PUK) for an OpenPGP smart card (https://dev.gnupg.org/T5960#188013).

Can this be accepted? Since GPGME is doing a direct syscall, rather than going through the libc wrapper, there's no need for it to use libc-specific types. It makes more sense (and is more portable) to use the sized types equivalent to the definition that the kernel uses.

I verified that I can still build libkleo and kleopatra for gpg4win/24.05 (Qt 5) and master (Qt 6).

This should probably be tested with T7150.

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: