You may start the gpg-agent by hand:

In T4978#135418, @werner wrote:

The 5 second timeout is to give the agent time to get ready and accept connections.

The problem is that I have not yet found a _portable_ way to detect proper working v6 or v4 networking without doing a test connection. For privacy reasons we don't want to do that.

The 5 second timeout is to give the agent time to get ready and accept connections. I can't say with this infor why it takes longer at your site. Can you please try without putty support?

Minicloud is up. I found that the altivec flags are never passed when libgcrypt is compiled big-endian.

I am using Duff's device which is not in that version (and makes it considerably simpler), but it certainly is influenced by that version (and the preprocessing of the table taking advantage of the communicative nature of carryless multiplication is novel in that version), and I can add a note to that effect.

Just one question at the moment.

(1) Has no (flags eddsa) in key in SEXP.
(2) Has no (flags eddsa) and no (hash-algo shake256) in data to be signed in SEXP.
(3) Has no (flags eddsa) and no (hash-algo shake256) in data to be verified in SEXP.
(4) Uses SHA256 for hashing of OpenPGP data

Update to rG4bdade5b0bea: agent: Use get_pk_algo_from_key.

Thanks for the new version. Unfortunately Minicloud seems to be down and therefore cannot test patch at the moment. I'll take look when I regain power64 access.

That is unfortunately not possible because there is no fixed link between the key and the rev cert. Instead they are linked via cryptographic signatures. The pre-generated rev certs are a fail stop measure in the case that the user lost access to the private key and can't create a revocation with a concrete reasons etc.

The changes just follow the existing practice of Ed25519, which does:

You are very welcome, i'll let you know if i found more issues in the future, same goes to libgcrypt.

Switching to assembly for the shifts made a significant speed-up. As Minicloud is seemingly broken (can't open up ssh port) I cannot test on 64-bit big-endian or 32-bit and have thus made it 64le-only.

Changes pushed to master.

To explain the use case, I've started coming up with a good passphrase and this took a bit of time with a pencil and paper in front of me. When I wanted to type it in, it was too late. Thus I guess that some people will look up good rules of passphrases or at least make sure they can remember the one they are typing in.

Pushed the patch to master.

It's me who should say "thank you".

Yes, i always build it with PKG_CONFIG_SYSROOT_DIR but never had any issues with it until 1.38 version, your suggestion definitely fixed it. Thank you.

Or one liner patch would be enough:

IIUC, you build libgpg-error with setting PKG_CONFIG_SYSROOT_DIR.
It results errors, because while old gpg-error-config never supports PKG_CONFIG_SYSROOT_DIR, it compares result from old gpg-error-config and gpgrt-config gpg-error.

Please give us full build log here, so that we can investigate what's going on. You can upload log file by the "upload" button in comment edit dialog.

Any news on this?

5 or 10 minutes are not reasonable in this case. Users are expected to attend the key generation. Your idea of having a countdown after, say 30 seconds, makes sense and should be easy to implement in the pinentries.

Thanks for explaining; this may indeed lead to a followup processing error of correct data. However, I don't expect to ever see a fixed length header of 2GiB or more because the sender would have had to buffer all that data in the first place.

Confirm gpg-error-config works... no

• Please report to https://bugs.gnupg.org with gpg-error-config-test.log

Makefile:1667: recipe for target 'gpg-error-config' failed

Please describe the problem and don't just paste compiler output.

No problem, in fact there's several issues with the cross build code, i'll report them later today.

Sorry for repeated mistake of mine.
I fixed it and tested with 'make distcheck' in the environment of cross-build for ppc64el host.

After this change:

Thanks for your report. I think it fails to generate src/lock-obj-pub.native.h.

Thank you also for the reply, the environment / build host is Ubuntu 18.04 LTS x86-x64 GNU/Linux and target host systems are MIPS and ARM.

This appears to still be a problem, despite upgrading to libksba 1.4.0:

Thanks for the report. It would be helpful if you can tell us your environment; in particular your build and target(host ) system.

Shall we backport this to 2.2 which is our LTS release?