Can you please run

gpg --debug ipc -vK

which will also start gpg-agent and print some diagnostics. You may want to redact the output. You can also run

gpg-agent -v --daemon

which should also print some more info.

Because the rules for downcasing are way to complicate to yield any stable result, the I-D requires that only ASCII acharacters are downcases, that is A-Z to a-z. Here is an example:

We fixed that in master and 2.2. Can you please test this with the next release and report or close this bug?

Thanks.

Last week:

• Allow import of secret keys created by PGP desktop
• Released 2.2.14
• gpg4vsnfd things
• PIV card and Yubikey-4

Thanks for the report. underscore followed by an uppercase letter is actually reserved for the system; thus we should not have used that.

That keeps the interface the same just in case we ever change the format. It has also the advantage that you can use the tool to extract the mail address from the user id and thus see whether it is valid.

So what about this:

I think that a small tool or feature for gpg-wks-client would be better than extending the --with-colons format. A --dry-run option for example could list the filenames which would be created.

See also
https://lists.gnupg.org/pipermail/gnupg-devel/2018-December/034131.html
for a first patch to implement this.

There are reasons why we sometimes don't consult the return code. That is even declared in the code with a cast to void. Further we use gpg_error_t and int interchangeable under the assumption that an unsigned int and an int value have the same bit pattern.

Maybe we should get rid of the _Pragma operator in particular because it is not used often and we cond on compiler type later anyway.

Will you be so kind and look into this?

Thanks.

Applied to master. This is not suitable for 1.8

BTW, for looking at such hexdumps I use this little tool:

News for 2.2.14, released 2019-03-19:

Thanks. Actually the same as arm7-unknown-linux-gnueabihf. I have added it to the alias table to be released with 1.36.

Please show an example regarding something else than a failed access to a pool of keyservers. I explained why it can't work for pools for you.

This file is readable. You must have changed the former one's visibility so that only you can view it.

No we can't we need to know the IP addresses to handle the pools. I have given a workaround for you in my previous comment. You can also use install Tor which we can use for DNS resolving.

We can't replicate that and got no more response for 9 months.

That was an intermediate commit on master - it is likely that there are memory leaks.
Moving the test around is not a solution. BTW {F630817} is not accessible.