On 22/02/18 21:50, Dmitry Gudkov wrote: > my bad, I should have started a new thread, well noted > > on the other hand that's probably why I suddenly had all the big gnupg > minds helping me)
Hehe, I think this is all just pure chance, it depends who has the time to read and respond. I don't think it's related to threading. What does make a difference, possibly a large one, by the way, is when the question is accompanied by much useful contextual information. If I'm reading a mail here and can already get a long way towards the solution by all the information in a question, I'm more inclined to respond then when my response would still be asking a lot of questions back. But this is just some general musing on my part. And it is also unrelated to your specific mail, it's a general observation. And by the way, my knowledge of GnuPG is not exceptional, I'm not a developer, just an enthousiast who has made it a hobby to try and help people here on the list :-). > seriously now ... Yes, let's :-). > it was a fresh ubuntu 16.04 install > > it came with gnupg 1.4.20 and 2.1.11 > > i compiled gnupg 2.2.4 Ah! I see. I didn't know or had forgotten that Ubuntu 16.04 forked Debian at a time when the gnupg2 package was a 2.1. AFAICT, looking at .deb files, /usr/bin/gpg is GnuPG 1.4 from the gnupg package and /usr/bin/gpg2 is 2.1 from the gnupg2 package in Ubuntu, which corresponds to what you say. Now let's list problems and solutions: - Programs invoking "gpg" (or explicitly /usr/bin/gpg) expect it to be a 1.4 installation. This should be fixed by having your locally installed GnuPG 2.2.5 provide a "gpg2" binary, not a "gpg" binary: ./configure --enable-gpg-is-gpg2 (include whatever other configure options you want, but also include that one). Since it requires recompilation, let's pick the latest and greatest 2.2.5 :-). Since in Ubuntu 16.04, anything invoking "gpg2" or "/usr/bin/gpg2" is either working with a 2.1 version or is not working as shipped by the distribution, you won't create more breakage (anything working with 2.1 should work with 2.2). - You have a GnuPG 2.1.11 in /usr/bin/gpg2 and a 2.2.4 in /usr/local/bin/gpg2. A similar situation occurs with any locally compiled libraries and stuff. The best solution would be to create Debian packages yourself, based on the Ubuntu packaging but utilising the latest GnuPG 2.2 instead of the 2.1.11 of Ubuntu that was last updated 2 years ago (on 8 April 2016, to be precise) and contains known bugs. That is some work, but doable. It requires looking at how Ubuntu packaged it, and create something equal but using a vanilla 2.2.5 instead of a 2.1.11 with backported fixes. Well, with a 2.1.11 that had backported fixes 2 years ago. I think it's unfortunate they stopped backporting fixes once they released 16.04. I'm not 100% sure about other good solutions. I think it's not a good idea to have 2.1.11 in /usr and 2.2.5 in /usr/local. But if it works for you, you could see if it keeps working for you. I'll come back to this. Another solution is installing the stuff in /usr/local like you did, but with some additional actions: Make sure everything has /usr/local/bin in its PATH and ld.so is looking for libraries in /usr/local/lib. On Debian, I think this is already in place. And then replace the gnupg2 package, the gpg-agent package and all the others for which you just installed a /usr/local package by an equivs package. Just have a look at each file you installed in /usr/local with your local compile, and do something like: You see: /usr/local/bin/gpg2 You inquire: dpkg -S /usr/bin/gpg2 And dpkg tells you it is part of package gnupg2, so you need to build an equivs for that. Etcetera. Install the "equivs" package. Read its manual, and create packages named "gnupg2" etcetera. Replace all real Ubuntu packages by these dummy equivs package. What did I just propose doing? I don't like the situation where there is a full real GnuPG in /usr and another one in /usr/local. The one in /usr might interfere with what you intend with the one in /usr/local. But you can't just deinstall the Ubuntu packages, because stuff depends on it. It would force deinstallation of all packages depending upon gnupg2, gpg-agent etcetera. With equivs, you can build an empty package. It doesn't install anything in /usr, so there will no longer be a /usr/bin/gpg2 at all. But any package that depends on "gnupg2" will see the empty equivs package named "gnupg2" and be happy that it is installed. I have done this myself with other packages, but never with GnuPG. > it worked just fine in terminal and after configuring Enigmail with the > new gpg location works there as well You could just see if it gives you any issues. I'm slightly worried about silent issues, though, where you think everything is working fine but it is failing in some subtle but nefarious way. I'm also slightly worried about the 2.1.11 Ubuntu 16.04 users have installed, which hasn't seen any maintenance since Ubuntu 16.04 was released two years ago. > do you think i still have a problem? It is your decision how thorough you wish to be. IMO, a true locally built Debian package is the epitome of thoroughness ;-). HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users