(funny due date removed)
Lot of things pertaining to keyservers changed in the meantime and we have a
couple of other things in mind as well.
(funny due date removed)
Lot of things pertaining to keyservers changed in the meantime and we have a
couple of other things in mind as well.
Yes, auto-detection in dirmngr-client would be great, thanks!
Is this still a problem?
You can implemnnt something like this using 2.1 and the --extra-socket feature.
Give the extra socket appropriate permissions/ACLs
FWIW, 2.1.4 will also bring a
gpg --quick-adduid USER_ID NEW_USER_ID
I close this bug because the new features won't be backported to 1.4 or 2.0.
All updated in the meantime.
Actually "make distcheck" does such a check and thus I wonder how this can
aheppn. Well (make distcheck and me) we are always doint out-of-source builds
so this might be the reason.
This bug report is quite old and a lot of code has been improved. Thus please
re-open it if it persists with 2.1.3.
This won't happen in 2.1 anymore. We can't do much about it in 1.4. sorry.
Thanks.
Can you please try with the latest version (2.1.4 will be released tomorrow)
When updating a key gpg uses the keyring where it was found in the first place
and only this. Thus it is better to have only one copy.
I am not sure whether this patch is the best for all platforms.
For now I install a fix that detects INT32_MAX and returns 256 then. May it be
that AIX does not use a fixed size structure? In this case it would be usable
to know whether there is a way to get information on the highest fd currently in
use.
This report was for which version of GnuPG?
Implement that for export.
1793 has been fixed thus we can close this.
May I assume this problem has been fixed?
(BTW, I sign my commits now)
Please try 2.1.3 or the soon to be released 2.1.4
I have fixed it for the gca functions percent and percent+ but won't do it in
the generic percent_exacpe C function. Changing the latter may introduce
regressions.
Fixed for 2.0 and 2.1.
You need to use --pem:
dirmngr-client -v --pem ~/tmp/google.pem
There is no auto-detection in dirmngr-client. If you think this is useful
please change Priority to "feature " and adjust the title.
We fixed some things related to this in 2.1.3.
(2.1.4 will be released tomorrow)
This looks more like a problem with the way that versionnhas been build in
Fedora. I suggest to take this problem to Fedora or the gnupg-users mailing list.
Okay that can be done. It won't be in 2.1., though.
From looking at the error (I don't have gcc 5 at hand) this looks to me like a
problem in the stdc++ library.
It appears that the basic_string implementation wants to put the templates class
(QChar) into a Union and it fails because it has a non-trivial constructor and
this is not allowed.
As this currently works, either the stdc++ library does this differently or gcc
does not check that rule.
Depending on the GCC Version during build configuration I guess we could add
-std=gnu++11 as the error message suggests if the GCC mayor version is > 5
Afaik this is not a pinentry-qt issue as the style looks ok under Unity (ubuntu)
and Windows.
I want to investigate why that is the case and figure out what the problem is
exactly (other KDE password entries in the same style environment look slightly
better) so I left this open to remind me.
I've clarified the title.
Duplicate of T1936
See also T1974.
[I granted you the User role (see https://bugs.gnupg.org)]
fixed by using
...
Andre: Can we fix that without the need to require a newer gcc version?
Okay. The secentry needs some work anyway to allow for a hide/show button. This
will probably go in the 0.9.3 release because it is too late for 0.9.2
We had 7 more releases after 0.7.6 Can you please test with 0.9.2 which will
be released today.
Does this still happen with 0.9.1 or 0.9.2 which will be released later the day.
Fixed with 0.9.1 which has a new option parser.
Ludwig: Is that still an issue with a decent pinentry (0.9.1)?
Fixed with commit 726c005 for 0.9.2.
You will now get an gpg-error codes like ENOENT, ENOTTY and GPG_ERR_TOO_SHORT
and not always GPG_ERR_CANCELED. I was not able to replicate a crash but that
might have been fixed in an earlier version.
Fixed with commit d7f2081 for 0.9.2.
The report is quite old.
Let's assume that has been fixed by newer gtk versions.