Thu, May 27
Apr 4 2021
Mar 14 2021
Mar 9 2021
Actually we considerto remove this feature from the GUI because with the global config we have a more versatile feature now.
Feb 10 2021
Won't be done because the expectations of users are different on whether they use ssh-agent or gpg-agent. And it breaks scripts
Feb 9 2021
Done. FWIW. in 2.3 symcryptrun will be removed entirely.
Jan 29 2021
See also https://gitlab.com/openpgp-wg/webkey-directory/-/issues/3 which is the same issue.
Jan 26 2021
Sorry, we won't apply such changes. A couple of years we did this and all we earned were a few extra bugs aqnd useless diffs. Further many of those changes are in files which will be updated from upstream time to time and your chnages would be lost.
OK, I only edited documents and notes, no code changes.
Thanks. However, we need to go over the list one by one to decide this. For example
"http://gnupg.org/.well-known/openpgpkey/hu/12345678" is actually expected to return a 404 and test code may very well use http:
Jan 19 2021
Jan 15 2021
This ambiguity appears to be the cause of a recent epic (and to me, largely incomprehensible) thread on gnupg-users. It would be great to have the WKD guidance about fallback strategy be much more explicit. Any room for ambiguity here leads to different outcomes from different WKD clients, and quite a bit of confused discussion by their users.
Dec 23 2020
May I ask that how to get a new complete clean po file.
I'm not familiar with gettext.
The old one is confusing, and I think maybe I should completely clean the messy.
Really a big project.
Frankly, I more or less forgot about these help files. The German version for sure needs an update as weel.
Please and thanks, I imitated the English edition format :-)
- Remove a comment for use case of the file
- If needed, we could have support of another locale(s) with Chinese language: zh_HK, zh_SG, etc.
- It is not us, but it's users who decide which locale is better for them
- E.g., my friend in Düsseldorf uses ja_JP locale
- So, it's technically better not to address restriction in a translation
for that, I think you best keep that.
Use a locale to distinguish Chinese users always cause problems.
There isn't a big difference between the written language. And small region always lack translations.
Singapore's users who use simplified Chinese always use zh_CN if there is no a specific zh_SG.
And the traditional Chinese users from HK SAR and MC SAR sometimes use the translation for Taiwan Province.
So when translate it, the tip remiand you must consider all the users from anywhere.
Please note that many error messages are defined in: https://dev.gnupg.org/source/libgpg-error/browse/master/po/zh_CN.po
For D515, I will also apply it to master.
Applied D514 to master, with an editorial change (removing extra space before newline).
Dec 21 2020
also update doc/help.zh_TW.txt by the way
D515: update gnupg doc/help.zh_TW.txt
upload the v2 patch and create a revision
D514: update gnupg doc/help.zh_CN.txt
waiting for review
Please not that you can use this interface: https://dev.gnupg.org/differential/
I think that it is better when you update your patch. You can just refer a patch from this task by:
If translated, 'keygrip' should be different word to 'fingerprint', because 'fingerprint' is used as a technical term of OpenPGP.
Do you call gpg-agent as 'Gpg 代理'? IIUC, it is better keep it as is (gpg-agent), because it is the name of the program.
Dec 20 2020
Nov 23 2020
Sep 16 2020
Sep 15 2020
Aug 28 2020
Aug 21 2020
Read through it, thanks for the updated description!
Aug 20 2020
Thanks. Fixed for 2.2.22
Jul 16 2020
No info received
Jun 3 2020
May 28 2020
May 18 2020
Okay, makes sense.
No, it is widely understood as a means for reproducible builds and specified at: https://reproducible-builds.org/docs/source-date-epoch/
SOURCE_DATE_EPOCH is NixOS specific?
May 17 2020
Well, I had simply accepted that the rule for defsincdate is always triggered. I looked a bit more into it, and the cause for triggering is that Nixpkgs patches dirmngr.texi, hence defsincdate is cleared by the rule above and the fallback behaviour is triggered.
But this also means my suggested patch wouldn't help here as the modification date of dirmngr.texi would be picked up.
Looking at the rules I do not understand why we have a problem here, the rule