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
