This is a generic parent task and does not require workboards for specific branches.

Applied to 2.4, too.

Merci vielmals. Cherry-picked.

I cherry picked it anyway. See my notes in T6813 I think I will at least workaround that one tomorrow.

Mh, I found some commits related to that 0796e04aa43c4500fb0f2c378b9a6cadf53a0a94 a43080fb0472afb46726cc555efffa102de9c7cc 810ed7b374f38eb7e038a83a557c8b6b91a65da3 if I remember correctly I even discussed this with Thiago and or David Faure back then and we figured it was a problem with default arguments. And there might have been a difference in KDE Compile settings and the compile settings with which QGpgME are compiled. It is pretty weird though even after some searching I can't find an initial commit from me that might be more verbose about the topic then just "Again new style connects won't work".

Another issue is that orca doesn't read the text of the certification key combo box. orca only reads the label of the combo box. Qt has a weird implementation for passing a value-changed event of a combo box to AT-SPI because "Combo Box with AT-SPI likes to be special. It requires a name-change to update caches and then selection-changed". Needs to be checked on Windows.

Regarding the visibility: If you certify after opening or closing the advanced options, the visibility is remembered, otherwise not.

Thank you for the tool tips!

Eva said this worked with older installers. Otherwise, she wouldn't have reported T6566 as-is. What changed is that we now use QuickJob/QGpgMEQuickJob instead of DefaultKeyGenerationJob (the one defined in QGpgME).

This may not be reproducible on Windows for the same reasons as T6813.

Me neither. But I take this since I can better debug this on Windows directly since this seems to be a windows only issue and it might be a build issue.

Not important for VSD 3.2 but yes I would like to see that fixed. Especially since we want the resolver also in KMail.

The only possible explanation I can see is that the signal-slot connections (using function pointers and lambdas) don't work because the progress dialog should be hidden when the job emits done() (which works on Linux with test_keyresolver).

I'm not seeing this on Linux with test_keyresolver as mentioned in T6566. Even after allowing test_keyresolver to be run in sign-only mode as seen in the screenshot.

Fixed with the above two commits.

To align the documentation of GnuPG, we should not use GNUPGHOME in FILES section.
It may be controlled by --homedir as well as GNUPGHOME.
GNUPGHOME is addressed in the ENVIRONMENT section, so, I don't think it makes sense using $GNUPGHOME}/trustedkeys.kbx.

Thank you. Applied and pushed in: rG260004747016: gpgv: Update used keyrings in doc FILES section

Belongs to T6789

The commits ^ added here accidentally linked the wrong task number.

We don't need that anymore in my opinion if customers do not complain that taskkill is too evil for them.

So the actual killing is now done with c5617e9f2426549cba54cb52f9faf9325f8e2929 we are using custom actions instead of CloseApplication to have more fine grained control when the steps are run. CloseApplication would only run in the main install sequence so basically only the Deferred part, but during an interactive upgrade like what one of our Entry users would do it would not avoid the first failure to kill a running gpg-agent this already would break the RestartManager support.

FWIW, the Fileversion is actually the Git revision in decimal

b) Is explained by the following documentation from: https://wixtoolset.org/docs/v3/howtos/updates/major_upgrade/

a) So with my current test upgrading from one beta to another it actually looks in the manifest and if you look there the beta230 of gnupg:

So with verbose logging /l*v inst.log (note the v) I finally saw the issue. My killing code works just fine.

tested with VS-Desktop-3.1.90.277-Beta

The reason for this is that this still uses the libkleo::gpg4win class for the version info, the about data in GpgOLs help dialog should be similarly broken.