It might be related to T4257 - try with -j4 for now which is what I use for building.
For further investigations we need to enable tracing using
GPGME_DEBUG=8:gpgme.trc make check
It might be related to T4257 - try with -j4 for now which is what I use for building.
For further investigations we need to enable tracing using
GPGME_DEBUG=8:gpgme.trc make check
Probably the same as T4257
We can't do anything about it except for corner cases which we won't do right now. In case there will be an easy solution to help Debian please re-open this bug.
Sorry, I can't replicate this
From 1.14.0 on these functions will return a Not Implemented error and the documentation has been removed.
Its a year since I worked on the mentioned wait code change (wk/new-wait branch) and I more or less forgot about it. it will to risky to release that as 1.14 so this change and the fix to this bug needs to be postponed to 1.15. Sorry.
I have also relaxed the test in gpgme for that GnuPG version.
See T4897 for a patch to gnupg.
It turns out that a test case in GPGME fails with that version. This is due to a regression I introduced in the passphrase repetition code for symmetric encryption. This will be fixed with the next GnuPG version; in the meantime you may use the patch F1646254.
It is a pecularity of the test case. A new release is long overdue anyway, so please have a few days patience for a new release with a foxed test case.
To change the expiration date, I would suggest to use
Pretty please write a useful bug report; we need information on versions, OSes, compilers, any special environment, and all the steps you did to get the build failure. The configure run already prints a lot of useful information; you may want to extract them or provide a complete build log.
Creating is not that useful - we prefer modern curves anyway.
I think that retrieving a parameter in compressed format is all what we need as per API.
Because a few minutes don't matter. If you have the time to figure the reason out, please go ahead. It might be that we take the timestamp in the addkey case earlier and only set the expiration date after the key has been created.
The default for GnuPG 2.2 is still 2048 (Debian changed that in their distributed version). The reason for this is that we don't want to generate such keys but move on to Curve25519 for the new defaults.
Duplicate - see T4702 instead
I won't fix it. In fact it can't anyway be completely fixed because gpg has code to make sure that a new key is at least one second newer than the previous generated.
It has now been implemented for all types of symmetric encryption (not just -cs). To go into 2.2.21
The first, I guess. The problem is that you are technical capable of _decryption_ but gpg does not allow this because for some reasons the key is arbitrary limited to signing. A warning message should be printed in thus a case but decryption should succeed.
The qualitybar has now been removed from 2.2 and master.
We will need this for 1.9
Yes please.
Yes, its on my agenda.
Your welcome.
Fixed; In master the code already uses our generic scheme parser.
DANE for OpenPGP is an experimental RFC (RFC-7929) and it is likely that we will remove the support because it is too hard for most users to add keys to a zone. Further a validating resolver on the desktop is too hard to maintain and the cause of too many other failures. And no, unbound etc is not an option because it is not usable by the majority of GnuPG users.