Today
While working on https://dev.gnupg.org/T7962 I realized that https://dev.gnupg.org/T7717#208938 is probably not the best solution for separating the config files of different distributions of Kleopatra, Okular, etc. Changing the application name has many side effects, e.g. it changes the name of the config files, but that's unnecessary because we put the apps' files already in different folders. There are also other side effects that make things complicated (and require many changes in okular). Taking a step back what we need is different folders for VSD, GPD, and Gpg4win (and KDE Okular). And, for Kleopatra, we need different unique service IDs, but let's ignore this for now. That can easily be solved separately. For the different folders it would be sufficient (and maybe even nicer for selective backups) to use something like %(LOCAL)APPDATA%/GnuPG VS-Desktop, etc., as location for all apps' files of VSD/GPD/Gpg4win. Then we wouldn't have to change/patch anything in Okular (or any other Qt apps).
I also don't think, that a backport to 2.2 is neccessary.
As gnupg26 was tested in gpg4win5 beta413 as well, I also move this to done on the gnup26 workboard and mark this issue as resolved.
I believe the reason was simply that we wanted it short, "Upload successful." sounds better than"Publication successful." and I associate keyserver more with upload than publication. Furthermore "Certificate successfully published" has the disadvantage of being correct only for the upload of one certificates, not multiple. So you'd have to have case differentiation.
@werner For rCd5e3cbfd , my mingw (GCC version 14) complains about the function-return-type difference of the prototype with GetProcAddress.
If we need to backport the locking fixes to 2.2, these two will be the start of changes:
Yesterday
Still good for experiments.
That RFC is Experimental anyway
Still good for experiments.
Fixed and backported for VSD 3.4.
Ranking as discussed with @ebo
Tue, Dec 2
The remaining issue "Wrong language in GnuPG error messages" is now also fixed. Until there's a new version of libgpg-error I've added the changes as patches.
The root cause is that opening the details reloads the certificate. This triggers a change of the key cache. And that triggers are reload of the group.
Backported for VSD 3.4
This also happens in vsd 3.3.2 and gpg4win-5.0.0-beta413 @ win11
Mon, Dec 1
I meant more like if it's worth a ticket at all, as it's an edge case and not necessarily a problem. Ebo and me already agreed, that we can live with it - but if you think it's worth it, I'll create another ticket.
This is now implemented for Gpg4win 5.
Panel Used By
| Dashboard | Mitzie209's Dashboard |