This fix is also in VSD 3.3

This is included in test installers since some time already.

This change is also used for VSD 3.3

This works with gpg4win-beta-70.

I've checked and can confirm this is working as intended.

Alright, finally supported by gpgme (fot 1.24) For testing you may use

Solved for gnupg 2.2, 2.4 and 2.6. GPGME support still missing.

The new API isn't used anywhere. For now it can only be tested with the test runners. -> setting to resolved

This is also relevant for VSD 3.3. Backport is not needed, but gpg4win/VSD needs to include current gpgme.

I knew that we'd need something like D604 when I saw rM409e31458227, but then I forgot about it. :/

should be fixed with D604

with gpg4win-Beta-50: "Rückstellcode" is shown correctly with an ü

gpgme now checks for a SUCCESS status emitted by gpgtar when creating a signed and/or encrypted archive. If gpgtar is killed (or exits without emitting SUCCESS for some other reason) then the partially created archive is removed and Kleopatra reports a failure.

Status messages on successful creation of signed & encrypted archive

2024-09-18 15:21:33 gpgme[3250.d47]     _gpgme_io_read: check: [GNUPG:] PROGRESS gpgtar c 0 3<LF>
2024-09-18 15:21:33 gpgme[3250.d47]     _gpgme_io_read: check: [GNUPG:] PROGRESS gpgtar s 0 62 B<LF>

This ticket got superseded by T7262: gpgme: Move C++ bindings, Qt bindings and Python bindings to separate git repositories.

In T4060#190972, @werner wrote:

We need a way to pass --known-notation to gpgme_op_verify

We need a way to pass --known-notation to gpgme_op_verify

Fixed.

I can reproduce this: It works with setuptools 72.1.0 and it fails with setuptools 72.2.0.

Okay. Let us split it into different tarballs and repos. We will bump the gpgme core version to 2.0 to indicate this split despite that there will be non-ABI/API incompatibility. C++, Qt, Python will then go into separate projects. The old common List stuff will be kept in gpgme core for now. The gpgme core sticks with autoconf stuff but for C++ and Qt cmake style will be used instead.

Done. Unit tests verify the API. End-to-end testing will be done with T7234: Kleopatra: add disable/enable certificate in context menu. Hence, setting to Resolved.

with gpg4win-Beta-41:

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.