On Tue, 11 Aug 2020 14:56, Brian Minton said:
> Why does gpg -k need to write to the tofu db? I should mention that gpg
> is running at 100% cpu in the R state. Before starting the gpg -k
I was not able to replicate it but I must say that I don't have a large
useful tofu.db. AFAICS, gpg
On Tue, Aug 11, 2020 at 05:40:44PM -0400, Brian Minton wrote:
> real 117m26.112s
> user 25m56.486s
> sys 90m31.859s
Sorry about the bad signature. But, the question remains, why would
just listing 13 thousand keys take 2 hours? By comparison, gpg1 takes
just over a second with the same keys
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Tue, Aug 11, 2020 at 5:32 PM Brian Minton wrote:
>
> I have a lot of public keys in my keybox (it's about 45 MB or so).
> I was trying to figure out why seemingly innocent tasks in gpg take
> a very long time. It seems that gnupg is making a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Tue, Aug 11, 2020 at 5:32 PM Brian Minton wrote:
>
> I have a lot of public keys in my keybox (it's about 45 MB or so).
> I was trying to figure out why seemingly innocent tasks in gpg take
> a very long time. It seems that gnupg is making a
I have a lot of public keys in my keybox (it's about 45 MB or so). I
was trying to figure out why seemingly innocent tasks in gpg take a very
long time. It seems that gnupg is making a very long running
transaction to the sqlite3 database ~/.gnupg/tofu.db
laptop:~/.gnupg$ date;ls -last
Tue 11