...at least, gpg-agent failt to start because of the missing libgcrypt.so.1 The new version (.91) installs just the so.7 version :-( Also, gpgme (latest ~x86 -> 0.4.0) fails to build when the .91 version of libgcrypt is installed... This is rather a quick note, not a fully detailed bug report, sorry... I have no time right now... :-( Ask me further if you desire... Radek
this is known ... newpg is deprecated (thats why it doesnt work) as for other packages that fail, file specific bugs for them please
Sorry, I can't understand this... I don't know much about PGP libs and their dependancies... :-( Can you, please, at least issue the bug for the gpg-agent? Thanks...
i lied, we'll use this as a tracker bug
look at portage, i can't find a single package that depends on newpg. kmail (part of kdepim) seem to use gnupg just fine.
i dont know what you mean about kmail using it just fine because it doesnt work over here even if i upgrade to latest libgcrypt and all the other latest gnupg packages see Bug 42081 ... but that's a diff issue, the issue here is libgcrypt-1.1.9x breaks packages that havent been updated
oh, i mean that i can't find the newpg dep anywhere .. but anyway, now we know there are other things are broken with the libgcrypt stuff
*** Bug 55638 has been marked as a duplicate of this bug. ***
Since my bug has been - appropriately - merked duplicate, I might add that I also ran into this when trying to make kmail use crypto modules. KMail uses gnupg just fine for standard old pgp, but the new S/MIME stuff is supported via crypto-modules. kmail needs a gpg-agent for that, which is part of the newpg package, and gpgsm, also part of newpg.
yeah, i dont know how to get the crypto stuff working in kmail with the newer gnupg and friends ... if someone could shed some light on this that'd be cool ;) newpg is pretty much dead upstream :/
Found it!
Found it! Ägypten2 is the successor (since newpg, part of the Ägypten project, has been merged with gnupg) and has an updated toolchain: http://www.gnupg.org/aegypten2/index.html I haven't yet tried it, though - look at the end, you'll have to recompile it, and I don't know whether portage perhaps disables gpgme-support.
Ägypten2 is still alpha, as gnupg 1.9 (which on my system merely fails to work at all). newpg isn't deprecated, simply it's stabled. KMail *need* it to work right, see http://kmail.kde.org/kmail-pgpmime-howto.html . The solution is to mark libgcrypt with two different SLOTs, afaics.
While the problem is still unsolved, a simple workaround is to symlink ln -s /usr/lib/libgcrypt.so.1.1.94 /usr/lib/libgcrypt.so.1 so gpg-agent is happy.
*** Bug 58384 has been marked as a duplicate of this bug. ***
libgcrypt should be slotet. Please do it soon. app-crypt/gpgme-0.9.0-r1 depends on libgcrypt-1.1.94 while kde-base/kdeutils-3.3.0_rc2 depends on dev-libs/libgcrypt-1.1.12
On my system I had to do: # ln -s /usr/lib/libgcrypt.so.11 /usr/lib/libgcrypt.so.1 rather than symlinking to /usr/lib/libgcrypt.so.1.1.94 which does *not* exist... Now gpg-agent starts, and gpgme compiles fine, however it is first necessary to manually unmerge app-crypt/newpg, which is not automatically done since the ebuild is currently out of portage tree.
so are we going to see a version of gpg-agent in portage that works with kmail from kdepim >= 3.3.0? I'm really starting to get sick of typing in my superlong passphrase every email I send (which is between 1-200 a day heh) -Jeremy
To get gpg-agent working with old gpg you should install both gpg 1.2 and gpg 1.9 currently the ebuilds in portage seems not to be able to do that, becaus gpg 1.9 symlinks gpg2 -> gpg executable.
i supposed this neglected bug can be closed because of of the new 1.2.1 that is in portage.
