On 2017-11-05 at 19:56:07 +0100, deb...@activityworkshop.net wrote: > Thanks very much for looking at this so promptly, and sorry for the > incompleteness of the description.
it's fine, thanks for answering back promptly with the clarifications. > On 2017-11-05 18:22, Elena ``of Valhalla'' wrote: > > > from gpg import GPG > > > > is this a typo for ``from gnupg import GPG``? > Yes, you're right, sorry. NP, just wanted to be sure before spending time on a wild chase :) > [...] > Unfortunately when I tried it again with a fresh keyring I realised that I'd > made a mistake earlier, and the GPG construction wasn't what I had thought. > I was actually doing this: > gpg = GPG(gnupghome="/path/to/keyring", gpgbinary="gpg") > [...] then I know what the issue is: the version of python3-gnupg currently in stretch has known issues with gnupg version 2.1+: it had support for gnupg 2.0, but there were enough changes in 2.1 that some features broke and they weren't fixed in time for the freeze, so python(3)-gnupg was configured to default on gpg1 as the gpgbinary. The difference between stable and oldstable is that in jessie the binary gpg was provided by gnupg 1.4, while in stretch this is gnupg 2.1, with a significant interface difference. > I need to do some reading about gpg1 and gpg2 and presumably just take the > default instead of trying to specify one (I don't yet understand the > differences). I had thought that specifying the gpgbinary was necessary > because on non-linux platforms it wouldn't necessarily be called "gpg". I'm sorry that I don't know enough of non-linux platforms to help on this point, but in the upstream code of this module there is already a default set on gpgbinary to be 'gpg', so I believe that you probably don't need to set it unless you need to do so in a platform-dependant way in the cases where it has to differ from the default. As for the choice between gpg1 and 2, python(3)-gnupg tries to autodetect what it's working with and do the right thing, so if you don't need the features provided by gpg2 you are probably fine just using the default as that will work the same way on jessie, stretch and buster even if the backend gpg changes. It is true, however, that debian is migrating towards gnupg2, so if you (or anybody else) don't want to be stuck with both versions for another release what I can do is to provide a backport of the version currently in testing, as that one has gone back to use gpg as the gpgbinary. In that case, if you don't specify a gpgbinary yourself the users of your program can choose whether to install the dependency from stable (and live with both versions of gnupg installed) or use the one in backports and be able to be rid of gnupg1. (A note to myself, so that I don't forget about it: before uploading the backport I need to check that it does not break gajim and act appropriately if it does.) -- Elena ``of Valhalla''
