On 10.07.2017 12:37, Daniel Shahaf wrote:
> Daniel Shahaf wrote on Sun, 02 Jul 2017 04:36 +0000:
>> That error is from tools/dist/security/_gnupg.py. The error disappears when
>> I install that module via my OS packages, so I assume we should update our
>> import.
> Another issue: gnupg.py seems to only use gpg1 keyring files, so after running
> 'release.py get-keys' which populated a gpg2 keybox file in ~/.gnupg/, I had to
> run 'gpg2 --export | gpg1 --import' in order for 'release.py check-sigs' to work.
>
> This is a bit too fragile to my liking: it would be good for release.py to not need
> both gpg1 and gpg2 to be available and configured.
>
> I think release.py would Just Work if the 'gpg' binary in $PATH were a gpg1
> binary, but on my system that 'gpg' binary is gpg2.
It works fine for me, and I only have a 'gpg' binary which is 'gpg2'.
The only issue is that 'release.py check-sigs' gets confused when a new
key is imported from the keyserver, and bails out; a second run, when
the key is already in my keyring, works fine.
-- Brane
Received on 2017-07-10 14:29:51 CEST