From twanfox at gmail.com Thu Feb 1 17:15:23 2007 From: twanfox at gmail.com (Twan Fox) Date: Thu, 01 Feb 2007 16:15:23 -0600 Subject: [OTR-dev] TrillianOTR is now GPL'd Message-ID: <45C2667B.1060904@gmail.com> Greetings, I had previously mentioned on this list that I had written a OTR plugin for Trillian. Sadly, this plugin is in, what I would call, a development state due to the fact that it doesn't behave nearly as well as I would like with the dialog messages. There are reasons for that, some of which may be beyond my control. Regardless, at the time I made such an announcement, I had not released the source code for it. Some had prompted for the ability to see the source, to ensure that nothing nefarious was happening. That and a bit of slowdown on my part has prompted the GPLing of the source code. For those curious, for those that want to spot check my work, and for those that won't trust it any other way, the source for the plugin can be found on the project's homepage at http://trillianotr.kittyfox.net/. A bundled development environment of the plugin itself as well as a slightly modified libgcrypt (prereq for the plugin) is present there. (The modification revolves around a severe lag in initializing the secure memory pool of libgcrypt. Instead of letting it run until it runs out of source information, the patch simply caps it out. The source is there for it and the changes, including the build environment used to make it all). Enjoy! Twanfox From paul at cypherpunks.ca Fri Feb 2 10:47:54 2007 From: paul at cypherpunks.ca (Paul Wouters) Date: Fri, 2 Feb 2007 16:47:54 +0100 (CET) Subject: [OTR-dev] TrillianOTR is now GPL'd In-Reply-To: <45C2667B.1060904@gmail.com> References: <45C2667B.1060904@gmail.com> Message-ID: On Thu, 1 Feb 2007, Twan Fox wrote: > I had previously mentioned on this list that I had written a OTR plugin for > Trillian. Sadly, this plugin is in, what I would call, a development state due > to the fact that it doesn't behave nearly as well as I would like with the > dialog messages. There are reasons for that, some of which may be beyond my > control. Regardless, at the time I made such an announcement, I had not > released the source code for it. Some had prompted for the ability to see the > source, to ensure that nothing nefarious was happening. That and a bit of > slowdown on my part has prompted the GPLing of the source code. This is great news! Thanks for your contribution! Paul From Tommy.B at gmx.net Sun Feb 11 12:17:01 2007 From: Tommy.B at gmx.net (Thomas B.) Date: Sun, 11 Feb 2007 18:17:01 +0100 Subject: [OTR-dev] [Patch] Internationalisation for gaim-otr Message-ID: <45CF4F8D.60308@gmx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! A few days ago, there was a discussion on otr-users about the translation of OTR, and I've commited to implement internationalisation support. Here's the first result: I've attached a tarball containing a patch with the changes I made to gaim-otr and also some new files that should go into the new po/ subdirectory. I was able to compile and run the patched gaim-otr on my Ubuntu 6.10 system with a Gaim 2.0.0beta6 (compiled from source) as well as on Windows (see below). Please test it for yourselves and send me results and comments. Basically, I tried to follow these instructions while writing the patch: http://gaim.sourceforge.net/api/plugin-i18n.html So, to add new translations, follow the steps at the bottom of that page. How to compile: Under Linux and similar systems, the usual "makedist" followed by "configure; make; make install" should be all that's needed, thanks to the autotools magic. Just be sure to have intltool installed when you do "makedist". I also wanted to test it under Windows, which was a bit trickier. I don't know if this can be done in a better way (it's long ago that I compiled something for Windows), but it worked for me. First, I followed Ian's instructions to set up a cross-compiling environment with MinGW under Linux: http://lists.cypherpunks.ca/pipermail/otr-users/2006-November/000792.html That worked quite well and enabled me to cross-compile the current CVS version of gaim-otr. Then, after applying my patch, I needed two extra steps: 1.) The MinGW environment was lacking a libintl.h. The libintl.h from my system was not suitable, as it belongs to glibc (and the code of libintl is built into glibc). So I downloaded the gettext package, cross-compiled it and installed it into /usr/i586-mingw32msvc/, so that I had a libintl.h and a libintl.a in my MinGW environment. 2.) Inside gaim-otr, LOCALEDIR needs to be correctly defined so that the language files can be found. The tricky thing is that in Win32 Gaim, the directory containing the locale files is generally only known at runtime (it depends on where the user has installed Gaim). So in Gaim's win32dep.h, LOCALEDIR is defined as a function call to wgaim_locale_dir(). Therefore I included that file in otr-plugin.c, and placed win32dep.h and the other headers in libgaim/win32 (from the Gaim source tarball) into /usr/i586-mingw32msvc/include/gaim. Then, after making some adjustments to Makefile.mingw, I was able to cross-compile the patched gaim-otr for Windows with a "make -f Makefile.mingw". So again, feel free to test the patch and send me your comments and suggestions. Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFz0+C0pI8wKmP0c4RAtzfAJ0Tan1gA2RRTZL+vzHx4Cr+vFGO8ACfWnP7 g5Y57UekNL0M6Df+nloA/Fg= =gcz1 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: gaim-otr-i18n-patch.tar.gz Type: application/x-gzip Size: 10268 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gaim-otr-i18n-patch.tar.gz.sig Type: application/octet-stream Size: 65 bytes Desc: not available URL: From mail at scottellis.com.au Sun Feb 11 18:03:51 2007 From: mail at scottellis.com.au (Scott Ellis) Date: Mon, 12 Feb 2007 10:03:51 +1100 Subject: [OTR-dev] [Patch] Internationalisation for gaim-otr In-Reply-To: <45CF4F8D.60308@gmx.net> References: <45CF4F8D.60308@gmx.net> Message-ID: <96e269140702111503i21102c38hcf1f75271b89d961@mail.gmail.com> Hi Thomas, I use libotr for the Miranda (http://miranda-im.org) OTR plugin, and I build it on a windows machine using mingw. I've already had to patch the library because of some of the text inside it - specifically, Miranda does not handle HTML in message windows and some of the messages from the library contained HTML. There are other bits of text in the library, which could use some internationalization. Do you have any plans to go that far? If so, am I going to need to build more gnu libraries under windows? It's already quite a nightmare to build if you don't cross compile from a linux machine. Also, Miranda already contains its own simple but quite effective translation machanism. Would it be possible to use callback functions or similar to allow applications using the library to do their own translation? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tommy.B at gmx.net Sun Feb 11 20:16:17 2007 From: Tommy.B at gmx.net (Thomas B.) Date: Mon, 12 Feb 2007 02:16:17 +0100 Subject: [OTR-dev] [Patch] Internationalisation for gaim-otr In-Reply-To: <96e269140702111503i21102c38hcf1f75271b89d961@mail.gmail.com> References: <45CF4F8D.60308@gmx.net> <96e269140702111503i21102c38hcf1f75271b89d961@mail.gmail.com> Message-ID: <45CFBFE1.80707@gmx.net> Hi Scott! Scott Ellis wrote: > There are other bits of text in the library, which could use some > internationalization. Do you have any plans to go that far? If so, am > I going to need to build more gnu libraries under windows? It's > already quite a nightmare to build if you don't cross compile from a > linux machine. Yes, I wanted to wait for feedback on my gaim-otr patch first, but then I'd like to put internationalisation support into libotr, too. The most obvious idea would be to implement that using gettext, which would introduce a new dependency on gettext, if you want to use it. But I would try to implement that as an optional feature, so that you can turn it off with a configure option or with a #define or something like that. And even if you want to use it, maybe you don't have to build gettext yourself, I just noticed that you can download precompiled gettext packages from the GNOME ftp server: http://ftp.gnome.org/pub/GNOME/binaries/win32/dependencies/ > Also, Miranda already contains its own simple but quite effective > translation machanism. Would it be possible to use callback functions > or similar to allow applications using the library to do their own > translation? I have also thought about something like that, and that should be possible. However, I think a disadvantage of letting applications translate the messages themselves could be that then each of those applications would have to maintain the set of translations for the libotr messages themselves. But if that's less a nightmare for you than linking gettext into your plugin, then I could try to implement that ;-) Thomas From ian at cypherpunks.ca Mon Feb 12 08:49:23 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 12 Feb 2007 08:49:23 -0500 Subject: [OTR-dev] [Patch] Internationalisation for gaim-otr In-Reply-To: <45CFBFE1.80707@gmx.net> References: <45CF4F8D.60308@gmx.net> <96e269140702111503i21102c38hcf1f75271b89d961@mail.gmail.com> <45CFBFE1.80707@gmx.net> Message-ID: <20070212134923.GA28991@thunk.cs.uwaterloo.ca> On Mon, Feb 12, 2007 at 02:16:17AM +0100, Thomas B. wrote: > > Also, Miranda already contains its own simple but quite effective > > translation machanism. Would it be possible to use callback functions > > or similar to allow applications using the library to do their own > > translation? > > I have also thought about something like that, and that should be > possible. However, I think a disadvantage of letting applications > translate the messages themselves could be that then each of those > applications would have to maintain the set of translations for the > libotr messages themselves. But if that's less a nightmare for you than > linking gettext into your plugin, then I could try to implement that ;-) I think it *might* be better to remove all of the strings from libotr, and let the applications deal with any user-visible behaviour; that way, when an app like Miranda that doesn't use the usual markup comes along, it can easily do the right thing. Of course, there could be some default behaviour for apps that don't provide explicit functionality. - Ian From mail at scottellis.com.au Mon Feb 12 09:57:43 2007 From: mail at scottellis.com.au (Scott Ellis) Date: Tue, 13 Feb 2007 01:57:43 +1100 Subject: [OTR-dev] [Patch] Internationalisation for gaim-otr In-Reply-To: <20070212134923.GA28991@thunk.cs.uwaterloo.ca> References: <45CF4F8D.60308@gmx.net> <96e269140702111503i21102c38hcf1f75271b89d961@mail.gmail.com> <45CFBFE1.80707@gmx.net> <20070212134923.GA28991@thunk.cs.uwaterloo.ca> Message-ID: <96e269140702120657t7c4b7a6cs64c678b0a436564@mail.gmail.com> excellent idea - enum'd error codes or something would be great On 2/13/07, Ian Goldberg wrote: > > On Mon, Feb 12, 2007 at 02:16:17AM +0100, Thomas B. wrote: > > > Also, Miranda already contains its own simple but quite effective > > > translation machanism. Would it be possible to use callback functions > > > or similar to allow applications using the library to do their own > > > translation? > > > > I have also thought about something like that, and that should be > > possible. However, I think a disadvantage of letting applications > > translate the messages themselves could be that then each of those > > applications would have to maintain the set of translations for the > > libotr messages themselves. But if that's less a nightmare for you than > > linking gettext into your plugin, then I could try to implement that ;-) > > I think it *might* be better to remove all of the strings from libotr, > and let the applications deal with any user-visible behaviour; that way, > when an app like Miranda that doesn't use the usual markup comes along, > it can easily do the right thing. Of course, there could be some > default behaviour for apps that don't provide explicit functionality. > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tommy.B at gmx.net Fri Feb 16 07:21:46 2007 From: Tommy.B at gmx.net (Thomas B.) Date: Fri, 16 Feb 2007 13:21:46 +0100 Subject: [OTR-dev] [Patch] Internationalisation for gaim-otr In-Reply-To: <96e269140702120657t7c4b7a6cs64c678b0a436564@mail.gmail.com> References: <45CF4F8D.60308@gmx.net> <96e269140702111503i21102c38hcf1f75271b89d961@mail.gmail.com> <45CFBFE1.80707@gmx.net> <20070212134923.GA28991@thunk.cs.uwaterloo.ca> <96e269140702120657t7c4b7a6cs64c678b0a436564@mail.gmail.com> Message-ID: <45D5A1DA.4060909@gmx.net> Yes, separating the user-interface from the library sounds like a good idea, and enum'd error codes and a callback to handle them might be a good way to do that. Do we care about backward compatibility? If we do, then maybe the current behaviour should just be kept as the default (for the moment) and the new callback added as an option. Scott Ellis wrote: > excellent idea - enum'd error codes or something would be great > > On 2/13/07, *Ian Goldberg* > wrote: > > I think it *might* be better to remove all of the strings from > libotr, > and let the applications deal with any user-visible behaviour; > that way, > when an app like Miranda that doesn't use the usual markup comes > along, > it can easily do the right thing. Of course, there could be some > default behaviour for apps that don't provide explicit functionality. > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > From ian at cypherpunks.ca Fri Feb 16 08:25:18 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 16 Feb 2007 08:25:18 -0500 Subject: [OTR-dev] [Patch] Internationalisation for gaim-otr In-Reply-To: <45D5A1DA.4060909@gmx.net> References: <45CF4F8D.60308@gmx.net> <96e269140702111503i21102c38hcf1f75271b89d961@mail.gmail.com> <45CFBFE1.80707@gmx.net> <20070212134923.GA28991@thunk.cs.uwaterloo.ca> <96e269140702120657t7c4b7a6cs64c678b0a436564@mail.gmail.com> <45D5A1DA.4060909@gmx.net> Message-ID: <20070216132518.GA14266@thunk.cs.uwaterloo.ca> On Fri, Feb 16, 2007 at 01:21:46PM +0100, Thomas B. wrote: > Yes, separating the user-interface from the library sounds like a good > idea, and enum'd error codes and a callback to handle them might be a > good way to do that. > Do we care about backward compatibility? If we do, then maybe the > current behaviour should just be kept as the default (for the moment) > and the new callback added as an option. Feel free to break back-compatibility at the API level; we had to do at least a little of that to implement fragmentation, anyway. Therefore, the next official release of libotr will be version 4.0.0. - Ian From ian at cypherpunks.ca Sat Feb 17 20:38:22 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sat, 17 Feb 2007 20:38:22 -0500 Subject: [OTR-dev] Re: Bug#411301: gaim DNS children die when gaim-otr is installed In-Reply-To: <7d01f9f00702171548j69a007baldef1168f6ead5b48@mail.gmail.com> References: <20070217231343.21075.82095.reportbug@server.misumasu.dyndns.org> <7d01f9f00702171548j69a007baldef1168f6ead5b48@mail.gmail.com> Message-ID: <20070218013822.GM19501@yoink.cs.uwaterloo.ca> On Sun, Feb 18, 2007 at 12:48:26AM +0100, Thibaut VARENE wrote: > tags 411301 upstream help > thanks > > This bug looks a lot like #404590. I think upstream is working on a fix. > > Michael: do you happen to have 'combined' contacts, as in #404590? I don't think this looks like #404590 at all. That bug has to do with multiple conversations being assigned to the same window (something new in gaim 2 beta, and somewhat of a security problem in and of itself). Here, Michael is reporting that gaim doesn't start up at all! This can't be a widespread problem, though, since we'd definitely have heard about it by now. Is anyone else running Debian amd64 (x86_64) that can test this? Michael, what other gaim plugins do you have installed? Can you send me the entire output of gaim -d? > Ian and OTR people, FYI, if this bug isn't fixed ASAP, gaim-otr will > unfortunately likely be removed from Debian 4.0 (etch) because of the > severity of this bug... What version of gaim is etch going to have? gaim-otr still works great with the last release (1.5), but is apparently having some issues with the rapidly changing gaim 2 betas. - Ian > HTH > > T-Bone > > On 2/18/07, Michael Berg wrote: > >Package: gaim-otr > >Version: 3.0.0+cvs20060530-3 > >Severity: grave > >Justification: renders package unusable > > > >After installing gaim-otr, when gaim is started it pops up a dialog box > >titled "GStreamer Failure" and with contents "GStreamer failed to > >initialize" > > > >In the console I started gaim from, several lines that looks like > >===== > >*** glibc detected *** free(): invalid pointer: 0x00000000005f9fd8 *** > >===== > >print out, and then one new line is printed about every 18 seconds. > > > >In the buddy list window, each messaging service is off-line and has > >an error message to the effect of > >"disconnected: ... unable to send request to resolver process" or > >"disconnected: Couldn't connect to host" > > > > > >When I run gaim in debug mode (gaim -d), the following is in the output: > >===== > >.... > >*** glibc detected *** free(): invalid pointer: 0x00000000005f9fd8 *** > >dns: Created new DNS child 21220, there are now 1 children. > >dns: DNS child 21220 no longer exists > >dnsquery: Unable to send request to resolver process > > > >proxy: Connection attempt failed: Unable to send request to resolver > >process > > > >*** glibc detected *** free(): invalid pointer: 0x00000000005f9fd8 *** > >dns: Created new DNS child 21221, there are now 1 children. > >dns: DNS child 21221 no longer exists > >dnsquery: Unable to send request to resolver process > > > >proxy: Connection attempt failed: Unable to send request to resolver > >process > >.... > >===== > > > > > >When I remove gaim-otr, gaim works properly. > >Without gaim-otr installed, the same section in debug mode looks like: > >===== > >.... > >dns: Created new DNS child 21274, there are now 1 children. > >dns: Successfully sent DNS request to child 21274 > >dns: Created new DNS child 21275, there are now 2 children. > >dns: Successfully sent DNS request to child 21275 > >.... > >===== > > > > > >-- System Information: > >Debian Release: 4.0 > > APT prefers unstable > > APT policy: (500, 'unstable') > >Architecture: amd64 (x86_64) > >Shell: /bin/sh linked to /bin/bash > >Kernel: Linux 2.6.20-amd64-smp > >Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > > > >Versions of packages gaim-otr depends on: > >ii gaim 1:2.0.0+beta5-10 multi-protocol instant > >messaging c > >ii libc6 2.3.6.ds1-12 GNU C Library: Shared > >libraries > >ii libgcrypt11 1.2.3-2 LGPL Crypto library - runtime > >libr > >ii libgpg-error0 1.4-2 library for common error > >values an > >ii libotr2 3.0.0-2 Off-the-Record Messaging > >library > > > >gaim-otr recommends no packages. > > > >-- no debconf information > > > > > > > -- > Thibaut VARENE > http://www.parisc-linux.org/~varenet/ From ian at cypherpunks.ca Sun Feb 18 10:13:11 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sun, 18 Feb 2007 10:13:11 -0500 Subject: [OTR-dev] Re: Bug#411301: gaim DNS children die when gaim-otr is installed In-Reply-To: <7d01f9f00702180149w78a1c757vb7445b4c302f7d50@mail.gmail.com> References: <20070217231343.21075.82095.reportbug@server.misumasu.dyndns.org> <7d01f9f00702171548j69a007baldef1168f6ead5b48@mail.gmail.com> <20070218013822.GM19501@yoink.cs.uwaterloo.ca> <7d01f9f00702180149w78a1c757vb7445b4c302f7d50@mail.gmail.com> Message-ID: <20070218151311.GN19501@yoink.cs.uwaterloo.ca> On Sun, Feb 18, 2007 at 10:49:45AM +0100, Thibaut VARENE wrote: > >This can't be a widespread problem, though, since we'd definitely have > >heard about it by now. Is anyone else running Debian amd64 (x86_64) > >that can test this? > > Unfortunately, if gaim doesn't start at all because of the plugin, > there's no way I can lower the severity level of this bug... What I'm saying is can we find someone else with a Debian amd64 to try this (apt-get install gaim-otr, see if gaim still works) in order to see if it's really a gaim-otr problem, or some weird side-effect of something else. - Ian From ian at cypherpunks.ca Sun Feb 18 10:30:11 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sun, 18 Feb 2007 10:30:11 -0500 Subject: [OTR-dev] Re: Bug#411301: gaim DNS children die when gaim-otr is installed In-Reply-To: <45D7B344.4030604@gmail.com> References: <20070217231343.21075.82095.reportbug@server.misumasu.dyndns.org> <7d01f9f00702171548j69a007baldef1168f6ead5b48@mail.gmail.com> <45D7B344.4030604@gmail.com> Message-ID: <20070218153011.GP19501@yoink.cs.uwaterloo.ca> On Sat, Feb 17, 2007 at 07:00:36PM -0700, Berg, Michael wrote: > I'm not using the "combined" contacts mentioned in bug #404590. > > My original bug post was from an amd64 Debian install (64-bit Linux) > The glib message is always for the same address on the 64-bit system > ===== > *** glibc detected *** free(): invalid pointer: 0x00000000005f9fd8 *** > ===== > > I just installed gaim and gaim-otr in my 32-bit chroot environment to test > there and have the same problems. > The glibc error is always the following address in the 32-bit chroot > ===== > *** glibc detected *** free(): invalid pointer: 0x08118838 *** > ===== > (maybe the 32-bit address will help track down the problem if you don't > have a 64-bit system to debug on) > > I just checked /proc//maps on my 64-bit install when I was > running gaim+otr, and the offending address of 0x00000000005f9fd8 is in the > heap space of the gaim process. > ===== > 005aa000-009f6000 rw-p 005aa000 00:00 0 [heap] > ===== > (what you'd expect for a call to free(), but having the base address of the > heap may also help with debugging) > > > I've also checked with several friends who are running Debian unstable and > are using gaim + gaim-otr -- but who aren't having this problem. > The only difference I can identify between our systems so far is that I'm > using ldap for authenticating users on my home network, while my friend's > machines are "/etc/passwd and /etc/shadow" only for user authentication. > I can't test this easily right now as my effected user won't be able to log > in to test if I turn ldap off. I've got a laptop I'm going to put Debian > back on tonight. It won't be using ldap for user auth on the laptop, and I > can test then to see if that makes a difference. I can't imagine how ldap could cause a problem like this in gaim. Can you check the versions of all the libraries gaim and gaim-otr depend on, on both systems? Can you run gaim under valgrind, and see what that says? Thanks, - Ian From ian at cypherpunks.ca Mon Feb 19 07:42:25 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 19 Feb 2007 07:42:25 -0500 Subject: [OTR-dev] Re: Bug#411301: gaim DNS children die when gaim-otr is installed In-Reply-To: <20070219094322.GE8603@mauritius.dodds.net> References: <20070217231343.21075.82095.reportbug@server.misumasu.dyndns.org> <7d01f9f00702171548j69a007baldef1168f6ead5b48@mail.gmail.com> <20070218013822.GM19501@yoink.cs.uwaterloo.ca> <7d01f9f00702180149w78a1c757vb7445b4c302f7d50@mail.gmail.com> <20070218151311.GN19501@yoink.cs.uwaterloo.ca> <20070219094322.GE8603@mauritius.dodds.net> Message-ID: <20070219124225.GU19501@yoink.cs.uwaterloo.ca> On Mon, Feb 19, 2007 at 01:43:23AM -0800, Steve Langasek wrote: > > What I'm saying is can we find someone else with a Debian amd64 to try > > this (apt-get install gaim-otr, see if gaim still works) in order to see > > if it's really a gaim-otr problem, or some weird side-effect of > > something else. > > Well, this problem indeed doesn't seem to be reproducible on i386 or amd64 > when not using nss_ldap. Is it reproducible on other systems that *do* use nss_ldap? Can you turn nss_ldsp on on one of those other systems you tested, and try again? The output of valgrind should definitely help find the problem, in any event. Thanks, - Ian From ian at cypherpunks.ca Tue Feb 20 06:10:18 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 20 Feb 2007 06:10:18 -0500 Subject: [OTR-dev] Re: Bug#411301: gaim DNS children die when gaim-otr is installed In-Reply-To: <45DA6C3D.6040001@gmail.com> References: <20070217231343.21075.82095.reportbug@server.misumasu.dyndns.org> <7d01f9f00702171548j69a007baldef1168f6ead5b48@mail.gmail.com> <20070218013822.GM19501@yoink.cs.uwaterloo.ca> <7d01f9f00702180149w78a1c757vb7445b4c302f7d50@mail.gmail.com> <20070218151311.GN19501@yoink.cs.uwaterloo.ca> <20070219094322.GE8603@mauritius.dodds.net> <45DA6C3D.6040001@gmail.com> Message-ID: <20070220111018.GB19501@yoink.cs.uwaterloo.ca> On Mon, Feb 19, 2007 at 08:34:21PM -0700, Berg, Michael wrote: > > Steve Langasek wrote: > > Well, this problem indeed doesn't seem to be reproducible on i386 or amd64 > > when not using nss_ldap. Given that users of other gnutls- or gcrypt-using > > packages aren't reporting similar problems, it seems likely that this is a > > bug in gaim-otr or libotr, but I don't think it's one that should block the > > package from being released; it is generally usable, just not in certain > > system configurations. > > Yeah, I do have a system configuration that you don't run across every day ;-) > > > Ian Goldberg wrote: > > Is it reproducible on other systems that *do* use nss_ldap? Can you > > turn nss_ldsp on on one of those other systems you tested, and try > > again? > > I did a clean install of Debian unstable onto a x86 (32-bit) laptop, tested > gaim with and without gaim-otr installed. gaim and gaim+otr both worked > properly. > > Then I installed libnss-ldap and libpam-ldap and configured them for my > network setup. gaim (without otr) worked, but gaim+otr had the same errors > as I reported for my amd64 system (and the 32-bit chroot I also tested > there). So I can duplicate the bug when nss_ldap is in use. > > Valgrind output is attached for the following 4 test cases: > 1) gaim (without otr or nss_ldap): gaim.9110.gz > 2) gaim+otr (without nss_ldap): gaim+otr.9180.gz > 3) gaim with nss_ldap in use: gaim+ldap.10134.gz > 4) gaim+otr with nss_ldap in use: gaim+otr+ldap.10038.gz > > Unfortunately, all of these valgrind runs on that x86 laptop have a TON of > ===== > Conditional jump or move depends on uninitialised value(s) > at 0x5C55DC7: (within /usr/lib/libsoftokn3.so.0d) > by 0x5C5617D: (within /usr/lib/libsoftokn3.so.0d) > by 0x5C56243: (within /usr/lib/libsoftokn3.so.0d) > by 0x5C56471: (within /usr/lib/libsoftokn3.so.0d) > by 0x5C566D8: (within /usr/lib/libsoftokn3.so.0d) > by 0x5C445C4: (within /usr/lib/libsoftokn3.so.0d) > by 0x5C44721: (within /usr/lib/libsoftokn3.so.0d) > by 0x5B9B7C2: (within /usr/lib/libnss3.so.0d) > by 0x5B9B8C2: (within /usr/lib/libnss3.so.0d) > by 0x5BA4133: SECMOD_LoadModule (in /usr/lib/libnss3.so.0d) > by 0x5BA428A: SECMOD_LoadModule (in /usr/lib/libnss3.so.0d) > by 0x5B8342D: (within /usr/lib/libnss3.so.0d) > ===== > that occur in each capture. > I didn't see these on the amd64 system or the x86 chroot I set up on that > system. Do you guys get pages and pages of that output when you run > valgrind on gaim on a 32-bit x86 system? If not, I'll try to figure out > what's causing it on that freshly installed laptop. OK, I think I see the problem. libldap_r.so.2.0.130 and gaim-otr both use libgcrypt. libgcrypt has a well-known problem that it can't be used as a shared library by more than one client in the same program. This is because it uses global variables that the two clients (gaim-otr and libldap) both need to use in different ways. We also see this problem, for example, if you try to use gaim-otr and another encrypting plugin that uses libgcrypt. One solution would be to statically link libgcrypt into gaim-otr (so it gets its own copies of global data). Can one of the Debian people try to build a package like that? A better solution, of course, would be to make libgcrypt sharing-friendly. This had been discussed on libgcrypt's mailing list a while back, but I don't know what, if anything, became of it. Thanks, - Ian