- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mon, May 12
Fri, May 9
I think we have another report on this in the tracker. The problem is indeed the ugly Windows time functions to print a string. Let me only remeber that untile a few years, Windows had the opinion that Germany is the the Westeuropäische Zeit, i.e. Portugal or the UK.
That is quite possible because we do not have a test system for RISC-V and the make release tarbegt is not abale to verify this.
Thu, May 8
I can't see any documentation that a value of 0 disables the cache. The user might have used some undefined behaviour. For example in the old code we did a housecleaning when we were idle but the new code uses a timer and another thread for flushing the cache. We could open a feature request to entire disable the cache but I bet that we will get a lot of new bug reports because users will then need to enter their passphrase too often for one operation.
Wed, May 7
Lucas Mülling commented yesterday on gnupg-devel:
Tue, May 6
Right now we have
Mon, May 5
I doubt that this is a gpgme problem. With a gpgme log we will be able see the exact commands send to gpg and replicate this on the command line.
And the US administration might even change the definition of a year to, say, 100 months so that potus can rightfully keep his promise that there won't be more election in the foreseeable future ;-)
But the function works and returns the peer's credentials?
The main problem here was that this all is not async-safe and thus I once implemented only the standard cases I could test easily.
For the records:
A bug tracker shall never be used for discussion because the audience is not as expected. Only very few people follow a certain bug but several hundreds are following discussion on gnupg-devel@. That is basic hacker knowledge.
Sun, May 4
Heiko, I told you already in T7106 that it is not a good idea to re-open a ticket. If you really want to discuss stuff, take that to a mailing list.
May 2 2025
Yes, this is related to T7547. With my last fix for that I overlooked that we use PUBKEY_USAGE_CERT to internally request the primary key but that one is not set because in general USAGE_SIG means the same (except for some case in PGP7 mode).
> I'm not sure i understand why "the latest" should be preferred.