Tested in VS-Desktop-3.2.0.0-beta214 by encrypting a large file with Kleopatra. The progress bar shows percentage finished, progress looks all right

Re-open to add auto-detection.

Relevant lines from Arch's qconfig.pri:

QT.global.enabled_features = shared pkg-config rpath reduce_relocations signaling_nan zstd thread future concurrent dbus openssl-linked opensslv30 shared shared rpath reduce_exports no_direct_extern_access reduce_relocations openssl
QT.global.disabled_features = static cross_compile debug_and_release separate_debug_info appstore-compliant simulator_and_device force_asserts framework c++20 c++2a c++2b c++2b wasm-simd128 wasm-exceptions opensslv11
QT.global.disabled_features += release build_all
QT_CONFIG += shared rpath reduce_exports no_direct_extern_access reduce_relocations openssl release
CONFIG +=  shared plugin_manifest

Per IRC discussion, this could be autodetected in qt6.m4 by querying Qt6Platform.pc for mkspecsdir and grepping ${mkspecsdir}/qconfig.pri for QT_CONFIG.*no_direct_extern_access.

No need for QA on build issues.

The Qt 6 bindings will now be compiled with the -mno-direct-extern-access flag if --enable-no-direct-extern-access is passed to configure.

In T6696#175866, @antonio-rojas wrote:

This is a Qt issue. Reported at https://bugreports.qt.io/browse/QTBUG-117398

This is a Qt issue. Reported at https://bugreports.qt.io/browse/QTBUG-117398

Tested on the command line with

• a previously valid certificate after setting its root certificate to untrusted
• a expired certificate without the root certificate in the certificate list

Yes the error message is better now. In German it is "Entschlüsseln fehlgeschlagen: Fehlerhafte Daten." Which could be a bit more clear, but its ok

Was already with gpgme 1.21.0. Note that I used the done column but in future a milestone would be more useful than that catch all "done".

It might actually be useful to have an random number API in gpgme. When we do that we can also add a way t search for random numbers with an upper limit in each octet.

Well 5.4.2 o.O and we on Tumbleweed are at 13.x gcc

I found this in the change log of Qt 5.4.2:

- On x86 and x86-64 systems with ELF binaries (especially Linux), due to
  a new optimization in GCC 5.x in combination with a recent version of
  GNU binutils, compiling Qt applications with -fPIE is no longer
  enough with GCC 5.x. Applications now need to be compiled with
  the -fPIC option if Qt's option "reduce relocations" is active. For
  backward compatibility only, Qt accepts the use of -fPIE for GCC 4.x
  versions.
  Note that Clang is known to generate incompatible code even with -fPIC if
  the -flto option is active.

So I think that the problem here is that ArchLinux either does not build Qt6 with -fPIC or it does and others don't and that our check for wether or not to add -fPIC is not really working as it should. When compiling executables we should also add -fPIE instead of -fPIC.

I found this related to that: https://sourceware.org/bugzilla/show_bug.cgi?id=28875

Compiles for me, too with Qt 6.5.2 from tumbleweed.

The official build for Arch Linux doesn't seem to run into this problem. The Qt6 build is configured with

./configure \
  --prefix=/usr \
  --disable-fd-passing \
  --disable-static \
  --disable-gpgsm-test \
  --enable-languages=cpp,qt6

See https://archlinux.org/packages/core/x86_64/gpgme/

This is now mostly done. These 3 patches make it work:

Nevermind we clarified in chat that we would instead deprecate this API.

Kleopatra doesn't rely on the defaults in the library and other users shouldn't either. I would kill defaultkeygenerationjob. And it's use in newkeyapprovaldialog should be fixed, e.g. by using QuickJob::startCreate().

The MSI Package though is a 64 bit MSI Package. For 32 Bit Windows we would need to ship a different MSI Package. (Which we actually have build support for because I thought that was neccessary even in 2020)

No, everything in Gpg4win is 32 bit, except for gpgol, gpgex and gpgme, libgpg-error and libassuan. Which are addionally installed under bin_64. But for the whole KDE stack it should easily be switchable. The KDE Windows project regularly builds them as 64bit applications. Basically we would then need to invert the logic and use the 64 bit compiler as the main compiler and the 32 bit compiler as the _ex compiler for gpgol and gpgme.

Kleopatra is a 64 bit application, right? For GnuPG we are working on 64 bit support for Windows. This is planned for 2.6. problems are how to represent sockets, file descriptors, streams and so on. Regarding the time interface, we should have everything ready in the GPGME<->GnuPG interface. In GPGME we need to check that we don't use int instead of time_t, though. When that has been done/fixed we could use a 64 bit gpgme and kleopatra along with the 32 but gnupg. Might be easier for approval reasons.

Mh, since there are no 32bit Versions of Windows sold for quite some years now maybe we should consider just going full 64bit with everything to solve this? Or is this a stupid suggestion?

It turned out that we need to fix this for use by Kleopatra on Windows.

Fixed. Removing Gentoo tag because it's not Gentoo-specific.

I'll swap us over to out of source build for this as well. I've been doing it gradually for the gpg suite. Thanks.

The following patch fixes this (for me):

diff --git a/lang/qt/tests/Makefile.am b/lang/qt/tests/Makefile.am
index 32ad6466..aedd3264 100644
--- a/lang/qt/tests/Makefile.am
+++ b/lang/qt/tests/Makefile.am
@@ -51,10 +51,10 @@ LDADD = ../../cpp/src/libgpgmepp.la ../src/libqgpgme.la \
         ../../../src/libgpgme.la @GPGME_QT5_LIBS@ @GPG_ERROR_LIBS@ \
         @GPGME_QT5TEST_LIBS@ @LDADD_FOR_TESTS_KLUDGE@ -lstdc++

This happens because you build in the source directory and therefore the wrong debug.h is found. While this should work in general we strongly suggest to use a separate build directory.