For now I have prepared 2 ebuilds for psi otr encryption: * Added an useflag "otr" and patching psi. * created a simple ebuild "net-im/psi-plugin-otr-0.4
Created attachment 166296 [details] net-im/psi-0.12-r1.ebuild
Created attachment 166298 [details] net-im/psi-plugin-otr-0.4.ebuild
Created attachment 166366 [details] psi-0.12-r1.ebuild fixed some bugs
Created attachment 166367 [details] net-im/psi-plugin-otr-0.4 fixed some bugs
Created attachment 169971 [details] net-im/psi-plugin-otr-0.4-r1
Created attachment 169973 [details, diff] psi-plugin-otr-0.4-libotr.patch Bumps up dependency of libotr to version 0.3.2. Quote from website: "The plugin requires libotr 3.0.0 or libotr 3.1.0. If you have libotr 3.2.0 it's necessary to change line 57 in otrconnection.cpp to #if OTRL_VERSION_MAJOR==3 && OTRL_VERSION_MINOR==2"
*** Bug 188697 has been marked as a duplicate of this bug. ***
Created attachment 202215 [details] net-im/psi-plugin-otr-0.5.ebuild For psi-0.13, a new psi-otr-plugin has been created by Timo Engel (http://public.tfh-berlin.de/~s30935/), version 0.5. Therefore I have created & attached a new ebuild for this version and an ebuild to build the patched version of psi-0.13 accordingly. Both are largely the same as Stefan Kroegls ebuilds for the previous versions and the ebuild for psi-0.13 of the main portage tree respectively; only some neccessary modifications made. I hope there are no grave errors. (These are the first ebuilds i ever posted publicly.) Additional notes: * this otr patch conflicts with the patches from psi's "extras" use flag; therefore everything related to the "extra" flag is commented out in the ebuild; perhaps someone might be able to fix that ;) * Stefan Kroegl marked this ebuild (this bug) for x86; I have amd64; therefore the keyword is changed. But I suppose, that the ebuild would work for x86 as well.
Created attachment 202216 [details] psi-0.13-r1.ebuild and the psi-0.13-r1.ebuild
Heh, I'd really wanted to add this plugin but here is a problem: each time psi releases new version, plugin interface changes and we'll have to wait until otr-patch for psi will be updated too. I was following development of this patch for some time and it looks like it takes about month after upstream release or more to update the patch. So we have two alternatives: either wait and not bump psi until patch will be updated (really bad idea) or bump without patch and readd it later (bad idea too since this doubles work for maintainer, and makes hard life for those who use this plugin (they will have to avoid psi versions without this patch) and doubles compilation for those who don't use this plugin). I think until this patch will be added to psi it'll be hard to maintain this feature in the tree. Please, try to put psi developers attention to this feature and as soon as they add it, we'll add it to the tree.
Created attachment 213634 [details] net-im/psi-0.14-r1.ebuild First, Timo Engel published the psi-0.14 patch today. Here is the ebuild. Second, I think, You are right, this is somewhat difficult. We have the third option to keep the otr-patched and the unpatched psi distinct packages. (In this case the otr-patched psi should be given a slightly different name and should block the not otr-patched psi.) This might also be a good choice, since the otr patch and the extras patches conflict (because they are trying to patch the same files), at least until someone resolves this. (Which would probably have to be done again for every future release.) Third, however there is another issue with the otr-patching (at least for me). If a contact using the jabber-client pidgin (2.5.8, but probably all versions) requests an otr session, psi crashes with "*** glibc detected *** psi: malloc(): memory corruption: [...]" (I will add a traceback below.) Some additional notes: 1. This does not happen for psi-0.12, it does for psi-0.13 and psi-0.14. (Therefore, I'd recomment that those users that actually want to use psi with otr and without crashing patch the version 0.12 that is still in portage.) 2. It does on Gentoo (on my Gentoo) but not on Archlinux (I tested), and apparently neither on Debian (Timo Engel seems to have tested). 3. It does only happen for contacts using pidgin. 4. Since in might be an issue of my and only my system: my libotr version is 3.2.0, furthermore, glibc and qt4 may be somewhat related to this crash; qt4 version is (still) qt-core-4.5.2, glibc version is 2.9_p20081201-r2 This seems to be either an issue of Gentoo and the psi-otr-plugin-0.5 or an issue of some weird configuration of my system. Can someone else confirm the issue? I have to admit that I'm not sure whether I get what actually is the problem. It seems that psi or the plugin tries to use memory that is not allocated (but is in principle owed by the application since the kernel doesn't throw a segmentation fault); which is somehow detected by C++/malloc(). Correct? I will try to connect Timo Engel to ask him what he thinks about this.
Created attachment 213637 [details] psi-plugin-otr-0.5 for psi-0.14 the old ebuild for psi-0.14 would insist on pulling psi-0.13, therefore this update.
Created attachment 213642 [details] traceback of the psi-0.14 crash traceback of the psi-0.14 crash attached. reason described above ( http://bugs.gentoo.org/show_bug.cgi?id=238596#c11 ). The traceback seems somewhat incomplete; however this is all I have. If it is incomplete, the rest has not been piped into the terminal.
rainbow flag, thanks for sharing your observations with us. (In reply to comment #11) > It seems that psi or the plugin tries to use memory that is not allocated (but > is in principle owed by the application since the kernel doesn't throw a > segmentation fault); which is somehow detected by C++/malloc(). Correct? Correct. But it's still an error in application. Please, try to rebuild psi with debugging symbols like described here: http://www.gentoo.org/proj/en/qa/backtraces.xml and gather backtrace for us and Timo. Basically to get backtrace you need to add -ggdb to CFLAGS, drop -fomit-frame-pointers from CFLAGS and stop dropping of symbols (with stripping) by having splitdebug in FEATURES.
Created attachment 214232 [details] gdb backtraces of the crashing psi 0.14 Thanks Peter. I tried to extract all I could from gdb (with the "info threads", "bt", "bt full" and "thread apply all bt full") - everything in the attached file. The correspinding libc error message is this time "*** glibc detected *** psi: malloc(): memory corruption: 0x00007ff796a72a10 ***" (I thought the exact memory location mentioned there might be important.)
