From twanfox@gmail.com Thu Feb 1 22:15:23 2007 From: twanfox@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@cypherpunks.ca Fri Feb 2 15:47:54 2007 From: paul@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@gmx.net Sun Feb 11 17:17:01 2007 From: Tommy.B@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> This is a multi-part message in MIME format. --------------080306040203070309000708 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit -----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----- --------------080306040203070309000708 Content-Type: application/x-gzip; name="gaim-otr-i18n-patch.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="gaim-otr-i18n-patch.tar.gz" H4sIAD1Az0UAA+w8a3fixpL5av+KvmTmXjAII8DvsTMMxgw7GPsCztyczKyOQI3RWkhED3u8 9+S/b1U/pBYIjO08TnaXZIzU6q6urndVN7o17Znmhb5m64euNjfD8bRs2ZPJd7/hpwKf/Xod v/WDvYr6DVd6rXagf6dX9vZr+zVo1r+r6PW6rn9HKr8lEqs+URCaPiHfhd5s9rim31PP/6Kf H8jc2+64Fv12TC7NOzqxHVo2Z9unr/9s95sDgvCOye74PvA9L9wFSdu9FSK3q8xXut/2aejb 9N52b4kPX4HtuUQvs/+2USKJFhHNFy0pXDVNU++36nD3SKqVyh7RD47rR8f1faKhrG1JeMVi MTVC18kFHeGQA6LvH1cOjqsVPmT7/Xui6aV9UtRLR+T9+23SuDSaF91Ge3C69b7b+dBu9n+6 Hoqm9wSbrob95L71r2G/IW+V0cXTLe38ZtDptY328BPRztuNzqVx3b1pd3oD8mVb29oSbQju x1Z/0LnqnX7JvReX77/ktotP9wFIrFf3qtnots47fXj8Jm+ZoWnZfmHX8camQxHUdnFw8wGe w7K2QCTINpk70a3tQjdoefNvxx7B5a+Me/CUkUUv1YEu9dIBIww+MYCvhmMa3XO5SIVGcKVQ iN3hPJxC553BECaybNPxboPylNyGdxq/EzeRDRdoqjhicMNaGKm2Ym7OQIAeyNwc35nQ6RZX v/TQ213VnZNry3ZDJ/Q8R6PfQt8ch2XbJXHbjPq3NNUSzYGg2IRkxIU0u61G76LTbSE1F4Et QFoEs6SNDMU/ViHZlCt1cj+lj/uLmKbUkTVtVQ9Jz7tH/don1dpx7eB47yhWyf20OvIRT2hk DTWyJjTyezKcUnJPfYafG81G1CehR+YR0pqE8JCLDNxNQLQXNYacklq5Uq6AMBa/Jz1zRok3 YcNuaRgC14jlzUzkbrs1HIK4GteN5qdGuwUDJe2A84BHn84dc0xhrB2QBzuc8slNvPDYNc5N ptS0AFuByeDqpt9skR9OyW4U+Lv23uG+xohQq86C+/Gu7Y6dyKIpzTvA9VcrJb2qUACVOTSR BoA+6CugVTbL24QrHPwF9SZiFnjMl9vFQckYFMbydLsIvTu9YbfTayqDVqGGYp8NyYwhpadf goT4FOVCwCMD5bfJsNEHiitULgeeoED1AKxOsbZfOmQEWO5pOQ6snJshaNc+OyVNo645cqhm RqGn2TPzlmojM6DYD60RdHuTV4lV2JVUJJqDJujBdmtVrVqu4D08k5fWnTG3v42iCWtAi4St 3ui/6DiUfQAxDkVejf3HeYgX81uN+r4HMvSiYcxmEa3LcE9IXYA+yINtQh1c48V1p4mEmMB3 ijIzz4ocSjTz3rMtTagRI3IdfV5xTy+BNiKVm02U0tvxeJt40M+3LUq4NyNFAHQLVDYdh2id N3lFsgtAVXBxxsfz/qAAyJIt7MDpzOULeyB6gPJ6l5jp7cRkSmOB+cbNOzMKCqQSqUdsWr3G h27L6HUHiE5a+zm0dBvOTMCnARmOYVFcLAsA/U3+svEJSKE1wf0AExaNJoyJux+rXs5DL+cR 6Rc96Qo91UGCVsAMTSQgMCGYmj61UJY5k4G8/0k0j7x5z9pQ1AuMv3sssNmvCSWyXYiFEXET dWdL3BINQQEHho1uF8miPpqRysHeXoL6Qs8n1y3nRN0fO9R0jwG6P8OOO2xV/DqhpHCOY8+d 2LeRD9Hb+A9xjeqEKx1jPeUY62ks0S2qDVtV6RP3SLV6XKkf1w9in1hnPjHV/QmPWGXBGPzV a4yZ2+T6U9tofmw1PxmXV+c3EIvkWaRVIrHlOjslVUATBKmYukdLA9d6uVIiJdJoGpeDttHq 96/6eRxbwhHEdC3e06e/RDYIXAEkY1uD3lc3w+ubYf5nyeqvIAjQfN2/ahuoXsOrqy66jEV9 Snwp9IZodDBcUi/26Lx10em1jJveP2+uhq3zxU4l8nPuzUJb7iu0ngM2Lk05dh74UfTOI0qi gFqILMzS7UKA2mvfNAanOTAmELa3QW+Mdu/GEKBZt+XFpqJL2/0ai6yirn+MyKoTrs6vFpIr PY0nCq3asD6S03lmlRqQIbY1NbVikQz8FS6G7BBy4UWuxUKJEum443KJwBxDOpsDda8xviqR QWSHlNRqIKAfvCDEnpcNQipVXdc1vQZzkZtBA8HtYpizuyN0CfIFaCl+b08sOiEfGz+2jOYV ROpt4yO28nCG5GRn4Pz3FFKgCdonABI8BiGdyfiNAY8HvQtCy/bK07OFNlAYbGRR6xEutl6X i00mBJLZs2k4c3BOpT0Kbd4U45x4JLYs8PDUdxmxTMcOeACm4Jcs6h2q7u4tq/MInNKL47HO isXxh7vWdGGBon3u2/d39FEu9KBeBZ9SPNirCteyBRQNQjIGz0R2zPEYOByWiNo4973QG3sO GJF/A9/g0wZBvuZx+878ZFvDNnVEaIcgEKck16Yu9WHlINmIB+RQBHDJZQyBxzPTf8RB1+Bt AkoeTDuEnsVVwI38KvCFjFEJfBinzgCd2Zp4t4DCIAs6ytYMOhgAyw1Fh3Z499m2wGiRHccc UeeEUxkjswqQeZ99M/WBz1Xo354z9fsMU38EOw0rmbKvE/QL+JmLUNkAi2jBVHMnHzNA0C2N CPTPz8kPZK6dYRKlnbmYJh2T3I1753oPbkyOzYYBeeKBSJstjhZIYdOnSGE00oKAuIpyuSxC IJRLhl9MRFyKEYS+Fc35pJNVPCMTiJbfBiT/NigAxFyJo7wO0kr+L8IqlGAVCC2W7jQllFWK hZySMVurwe95YNq7GnYufmIOt9O7uCoRJogIjElWKUG2xGTgsFLDROhQr4kqTCJlLn2AIXfR POa651i8BRca3hlMlgwQK37FovRu40Orm+fiop2x9oIUiRhiFsmBFueeS4GqyTxSKNYNNJSh hfRYgXaCagCo8qcrcS0lk0mlw/EPTH2MYOo9LAzgunRYPWJ0rB0pdFTUDqyz1EXr7sIDyd6Z eEw/OWnotzlApb6grLw1ABkDCwHGzKUzz7XH+ZzxeWqG/whYkeCHWG82B2AsgVAXOvK+GRjV GFjXDhmZPlz9K38P7UAbCbZELhrdQSv+qkgQEx8VlOPArhGBfO+m21UnAREMTYilfMO0LDYH eNFhA6Kyfl5OAbMxAJLA9Qoj8F5FIfATnH2AVQa4RoAVX2dJx4pFU77oeGjWqhn3Zp5PN+Hc JfRjyi6Yttk4Qx25Aa8E2gh8JZ+Cse+ImeHScxxqwayu5T3EDCuR57ANZ4NJEa7k2H61pEP+ f3hQLVWrIqkATEN7TLBUQACIEbl36ENuqc/UOSZDXtEdlL0SH7KDlWfm4ouJocKpV5oHrG3A B2zEF/eLy/++M8nUpxNIwOE+d/Y2eLdrnqE1Z12B3J0JefQin4wiy3oE3xdwToWg+QQMDelc JmYazDjE/WqPnJwTu4692TwKUWPAI81MhHYPF5ET2hiPKmsPmBOIcfjoPdB7HIeuzHOdR4gE HiFrIvZsDiEraDog4FgE1urYY/QqOJ0nMI9xYEsAVVcnInZARo/ACwoxH7gldK3+jMd+E9+D ABU6xBDkChT0IH9qt/rXfcjGjI+t7vVNv6tg3gR87mC5QA90coww6hTmyIvCxZVLOUOhiBXO wLHM9pSwJobYNMi70Zky9t3u6AzXY5LItX+JYCaLuqE9sbGGC3CQHATMNpIql+D4OjDcU+eA 75j5mRGwCDozJiRyUyakb99OQ23M6OHxSvLVsA+PQ0g5EjgQoSbDgFegZ1hG49TiWlli+fJ4 6nkw55fcj9S3J48AQVBFWcmXHAYmmnzyWlHWXibKqGbx4NeKsvZqUdYWRDmFXmIOclmSTXJg I+LOLxBuZl3Q5GfyKlaqxIxJ93ALLpTSfOoB+RXNKAS6AwhFQFxFMMhRQAogjYGLQmxNIK3v 02AOQR/IKAGf6BWYGARwy+30URX3AYpHlT25H8DiFDV9Whvus+4iQgx9Fq9iMmfALFMj9Ixp NDPdPN6VVMIkiYJMerJiQoyPGb4+HVP7nlooNxGP/VVoii4g298GxxBICsnGpKFExHPIJ/7+ 93RCUViXmKD/95LsZBWuxnOxLS5gW1hEt/gcdNWESGLMHf26NAfdISwQWVOIQ9H1WcXnRr8H OlKKCaQuS2ZEG4JIkE4BiVOhjKSF6DwsKa2NHpLQRQQvXJEEPBGfHEGsrh+C3O9V8VvKPaoW RB2oRtxOg8Wxx1ghYpEms8O43QpGr8yKHELuDeyUFz3B3Dlq5JQEqVg2VEJUkXQI2WTjyOkp GfZvBkMDjFFn8LF1DvzOXdiuHUyplSPH2Z3BZv3YGLaw7zVPM1d2ven92Op3Ljoc8g06G/R0 CuxczwtltpqYrtXoASdjBAsAJbN/giFWNyTwVb1TSDJJidFMxkB7ClOV5oJJASe7Pc9DI3pW 7Uw+KQkOryA/iKxK1QEG2WBQZRKvemlOOU66PgVhC8TWbVbfWDoz152eFRa4dl5OCkmLJ6cu LGqGIu0z6kbExvokF3R0bzJi+WdEwYLgw0Tms5KvhcwlkXME/gsCWSvwmRQ3NiV4dsdn0nkF kEwyr+i7QF03sEP7v2maxhBpwv9z8KIAAw9/pMgqqw3sHxt/TxkxP3dwF5FRk7pWQVga8reM RUkrd3RQquIxm4pewQs0c4BWw7IYQlPqzAnbypDszt3b9AEsbsAq/DYYBVGLZxgu5m+sn7V5 2qZtEuP/BLH2GB1nII5CQKwOLiCCUCvBi0XsEH1bXoR78uMphbgsDgJiDRg/YiD5zj5jgHgY mzDr3a59lgqXhx6557E1QkhmY8XmEE/fKNH0vW2SwAP/m3tVOrphUvpS1ESSASTwYKCPS06l LJhWmK5LHfCz0XiKgokThNSh8ykSLAYBEtK+bmuBfevCKFik7UCS0zJhEA/WZYYEYx2BjccS JkHdqelM5NkYCJTv1WXIEy4MyWRIXlnUgw1gWdLBKICRjzIe8Ia+zKYnZ2eSBIaBZQggTgWW AkByhInJI8gGRM4zPL0K6U80Z5mKy6VGgQES6GMQvShBZETDB0pFFieTDBYppPK6pTwEsxdh QxZSktEZ+DV6zIQc1YEtHazFyBxB+uQi1oISqAFMS4AV2DOOLDcndjaNY0AbE3uJxqmCxmbE XknjpKKxGbGzaJzC51U0Fhoh5N3F9M+BQdxiKRl6Ktkjk8gdi622UMne8RADNa3VWemgNcCj Jp3z1+Sk3GowKxqPTDi6mKVKnBKSLSHx7JKPgoEyMXOYxbV+IZ7nNZ6h+ALPIMqom6blwjvG TnAHE4NbA106d6IGOldDoGpb+abnuvCPOeCdMb/gZ2v0SpXtgeqV2l7pMGtLgUMUAW/kCqss dwjFDOq+ITbqP1f1ryV2WcVLucm5sP24lCleJ5GOS8eiMAVq/1axahSWP3JYEoC7OGI52hlW I1xeyS9uMpnxxHTFjOkK2fMli1/aNMUs3D6JtzydASdZx/qI9uthao+nzJKdJoBjqhr45ETw Cfij7yGj6od4ITkFwp+3Tysn9jvbwu4OdU+KRbtAArFMxoNivrpjA/K5t5Xqt5xMfOOJfraL 8eivcanl6f3LwaJOHKuWJYBgDUjJYgy8PiPLTVgYeHp7E2IVgPwMgFKRlxBMsn6F9KeYfHSN xPJcdPoQ5X5sdC+MD1ddyAxhDF/UA8VaK1hL9DxoM49JLscFXd8E8qDVvOqdPxd0NSmbPGtX NkvAs/Qol7lzGxdBOIOeNXO2cmUpFerU2snFfvVyFrBR+UXXq+w4i67Xq8qWHshXBKHsvT95 TJV2MIOAnGJiwTrxOqXbLKkMFcWWpQLoXDnJDs5j7OwJyQNc7WzCZtLOAIMgxKrbcuvPla8F PF+ypUygy/XU9tlxCl3fq8jzFHyGKTgxsdmGl2yHbXFDDsKVkSc6sWtD9OQVI1ksTT+GBBLS wKSm1Ly6/HDF9gBZH7QrHR7CuB47RPIaGPGu5XPHY+ynYPFqMOkyTwIC02VIg2SuvAxBMk0S gtc51LMMyJlcIj2shM7CA/zfJRPMsliUikX1cRiTJBuS8TxYG2ztTvnWLlvQyr3dp8czFF8y XhwDmLLUfnk41wPwgweoBvtSr5mdaBvNRrf7odH8lF9SbkxAbynWM0DlErvxhN4kPAyzXJNa bueHbeITOysHGdnDYt/ELMJifJHNfD5HTFNuAuNGTqm9w1K1hqTCLfI9tQTdpagvJhk5pntH HDx3qhaI1rMnjQizxZnM3qwa87qtUm2jrdLVJRhl4o1qMC+svryoBvMM3P7UIkzmNplaAUhn nqsTdQU6/rKPcVH8QopXGGIYIiaJ5QFECE03kx3FJKZouITFX37juphB6g1rIhuQuvgKUi9i 8Zc/7kL+V50R+MPO3GxYd/ktTt086QNeVmxhGwxLZRZmpNUYI3+hGMEdHtSLSot+xM7A6tWK enhTZP3gRWQGIFpOkrQh7nPKMx7i0zDy3di1rimoLNcHRbQhY5S19ZHVo+NQZWU5hOdQmQkW ixcm8XljTp5qpcbOh+hV/Ug9ILLmrAcw2PYNceJDUC998mP1OfIY78wD5YbLz5c+9xTHyQZF k4sFarICtzjUcSxDhFjJryN/7vnouZe5IHqrRTD1bIdy0v2Z61GPeZxsdPp8w0UVN19UYdWq 5KENuSxwFpGUgiVpZIZeCMlLiyjLWpB7YUkkA9Lmp1AWVSnOYrj9wkjNdAxRbcm3jasP/9Fq DvMcJ8yvLQps8x7j8t+6VEn0VZIlrqTVKt/mrdYOSzVeL1Z+B9NUTxRiofk+VT8ZRZNUlYT7 DYM1s25DLH502V4z23GOFRhBAZmZ/eW/ODUEq9Ea4FOp0EC0OGHiO/GrRrFKixyWyAZgs+KM 2MJ5SV4nZpkRtcrMompbWxsel1nslz4ro4YByRPpj9mbJDASSM6qML+enFWAzG6I0YZj4g92 8NcpcgdJ7DZhFQQkzXbHlDxQgqoux5IdaPkH8+uk1WOvxGids115eRBCPQoji7dAjvE0zw8k 4bHpLTZrigbyME3CdYXOC9X4tXQuxAHMCNTu7gR/4qjOl1Bs7ZSK9VpIyNJ0ZZEFEDwDLRUv 7hSx5zLHshC26MSEeFWi+CKWFZ/g2BMEVxiZTXSx8rW0x+tf+Vc2fZPp0fBsMT+szsZ+2YO2 GnXxnp3Z2VryzoZ8bwZojI4qQshn03fBYh1DooDhtjwBwGVUjovft6GXeUGd4f80fKypZc9Q XDNDQU4hK9JLa33w7ZAvVJp2pAt/w8ZlazBotFvG4KfBsHWJv6kCmrCAb6G8A0MW4taExsnk Ikblr2sRP51SrN2vwqLvVXlUeijLaC+0uGut51rVdiDximtmK3V0AxCxL31KxmJ6/p784eQ9 rLDt1ZpeEdur4sescXD/N4bRYki/2gth3gwgIHaaJkcOMqgCEdhJkm4qiZLlxedacP90A1qt Z8zzcSqux6mwEVK/PwNlYnJUx6op8LBaL9Ur/4dinkE0HtMgmER45sTnpxFFkWcxHGKWNyfU cYNgaP6bB0PRnxMMub9TMLSG9lK/Vsclwe8TJq3BSeCyEEileZJhEMSwt4jxXzCAWkMQRS6e z6j/j6n+0jFVrbqPb6TSawfybYyrnUVyziAJCbLZid3EKnPszUvxrxHwwPMWRxffGdEIQzqb szcBhJ4Uy5WH9WNJLJfxDRMJHKzHvhiSpO6v7LVeaxEM1vzwYHPkNoUSI8a/1qnXnxKGMAGq HxziC5KK+l61lrwpSVg5fG2P2NHnZWF22l9u27IbvkmMl6zUqp7IYI38pyqhw08wXLZ6N+ys PxaJ8GcYl2DT/qe9a29O5Ebi+y98ijnWyUIwNm+wHSchXuwji8FlcJKt7NYsj8GeWmAoBq/j 1N13v+6WNCPNAwZiO3e5UVJre0ZqtdSSRt3q/olwJhVfjA0lQSKesu60ccIyZM4wPiEofN0R kVvpnTGdctcNp169B9+GtqjdqSEMTUHJwMPpWXhDFJ70JuQLjfvYjpi+ltyujcc4jTVN56/5 8MJQzAIOr5KLaLRDnbYRCl4hvXY7G5o5idTbQXZSqZ8j0tFDKO3axVjtuvaK91KDMcYlQoN/ xny6z8NYbXQ0Wvoaajs3HAiubTh/z0ZXJV8mi0KlfOTB0HiuseUcKkYaXIG4JtuQWI9sErWR LmpISDOVDDI82735gtBsWFkoLFtJQWUrudwJQDb8I1Goat3RiiNdV44rR8elsgPGVnKw2Fhe Pw5b5e+JwwZNxg4moDIGu1YktOCaH3YNdAlYxDyYa1AWYdfsXXHXtoRdE4MiuDUpBxBbxYUz 8QFheB6R02r1SLis/lu7N2ED/WjdEzqROGYfEcbYLUc3Q2sF+p6tDPu3jzAzeWCf5wSCPZMC d8WjK08WJ3aYzfmON6x3330uhwFLj68CsroRydCqE6/LAD+6ZMsCd0DUR0M5ghGXmX1SDxos s4s9x0Gf9mEKZY/oBzk6JuSjOtpYKjH9MmgCwqCCSiEfi9NuHLl3QgT2NfkA91j76qCet1Ne GIWst5B67iuKZbzlmE0WuXBEfnDL0MoMnYVGZ0iLDQtJDS3GHQwTkpbhbVfHIhi0BWguBt9G BDTDm+uZuS4wrn0qkodxLlRt8GVgThESmrHvYz0gH1WwkXnvZ2erXmdaFFuVYVrjJ79OPx1f XFIU7N/yH+XoFnEyL/ew83Jm39J0dyInLnsXvX6j39Qdu4z29dciZELyD0CO5QNsjFX2jfkE Z6iADMEURyBVUiuVFzT76ZUzChwRaWrWNF+oMsJGoqxYkWywH0/ciO8dSrssqn1eJPakHpDi DfxPKd7gezLhvjdsMup0LNYzGA0HjzLMKwSeOjVuA8Li88uReS0hr1hEPI/qruNxBNnJXye7 MxHVSUZpUfnjGpiZUHcdGFwuH+4KJKI14Pu9kreUZ+1Wr5+GzscXGQ7BaHMTQjlfJ2+qcqEu nKnEmYX74UH7ydD6vbDv/Fp09tQWNJTh0Lve8RTiyBcBd1/MrGCpJmWWbJ785GkmGxMc0oht jz6Do4jUGyI/xb9KIa2wVmF1otrg2tDRk+eIWN81Q4ve0JzsLj2lB/RV1kdcpr5lZ+n+7spu 7i65wq37Sw/qscBGbYZD5NEFSreKg93gWJBKsYIaZ6VUCUbF5GC03seE++gM+GBIydTlowyn ajtSD86uBxSIHu9CdIJDKIjCxBXGF0+gSkV0RYmU70q5rJzmrwlxqUTgb7I+HmddlNM7jkHL V7rjzbFM/hJPEXHE45edPQ2nLsyl+LVB8mK7bi3IjOuYUJkNt8A25JUKobBWql4Dh9cHD5jj Xnjh2zDY6hFyH+kt3DEPyvVaF51GWz+/6ZylRREZVmddn3MoYGNzX7s51Vi3cADOdQ0RSLUu ShvzloYy/MRE9pQWI7ZOcVyVo3rw5MWxt+PcfctOCAlaqGes8KggwgQOLvUis1gsaNUCXnaR rbrWf0/z7wI7BWNqDf9jvvxJEfh8m1IhnVpL9UZLw5jjrgP2JghQtLpH7Y+5q3KFOiGreviS 66op1HmzAaT5U/avrAngualboRCHZwfOmfC8LfK3DmOe9yX+/jzAcCxvzfALydkPWhsYVO2D OV8DXZv3RDJ686AutbBgYj/S+OidXXfb7eZb/ZdW5233l3RAZTB0mPAJezhbrcpfMzc/X1z4 rOMcul/ltMJUhPVIpRdlORIl3MBud2Fatywx5Cvp2IOX3rxMhZfcftnytddZtQQdmkb6YLUa jO507mVgE70+GtfS9B4KhtEU/ZYnB+48U/eZZGmpq9ZKgZIdm/ZTC9dHMop8pULbithzrhVZ wGHlthdvUIufQMI+sqqQ4f+iEHK1SkKuFwKFzEOGnkrACrkowvWHLEWT7JojuVCpbjp8iyZR bxOfQJoKSdFTKEN1utbKTJJHgZKEPSoazZ5Kkgq5KJLkBbaW5DmV206SQWW2l6S3iU8gSYWk KklpTtaKeAljtlaqS/44s8FnZUNqwz5Vtpjhbk7RV+cWqsPWZwEisRjcMjeITrff/LHbfZcW OVQTuBTl7lWOvKC0sjOYXzEKyi1331YMskOrcN7O6P06fpwcajdJZ5j6YDpl22JxOlwvMNeD erGmoECH4E2FKPESHIvOYiWz3scO+gomjvYyGjJ4F/r3VEMsNWuUts0/DGuSVvJITSIfbXrm 9dF2or+kiFDHLsJGpM2cYhw1whs3tq6k7ilL3u2YuENR3vmbVoZ+9wxWlXf79Nd1s3fV7fSa +EAuxedDvVQm6yBec8GxpBz3IoHTyq4WogNRdzXReayqz7bJgJg8EEYadi38NcWLMpdy6LLc MB73x/GbhEc6BeuSuxVHPICxZA7sND3PKAtWGFOeDpRCV7NulMA29YTfKhO1+Q4whNtatwnu mAteh1Xd330XeCmJuGZGIZ/dumBglLTnleZ7JVrjrw4hRvSH5SCoxv71TVPxpIA9F0PbmcL3 c2bM2ZfzstU7c8rkXaW5Xq6j0lyv1nikRYDH3MAeDcaEgmGMPsO6ZNjSCMdJnvuOf3Yi2olv bEPjJTRldNvyqCPHEhpRzqd2h8p0b3XZCNVFMrniz7etRrt7IcJFc99xa4aXz3BLLPdQwc8q 7JZXL+KhIirb+mJ2h0v0VBF/RLyS3cm+wVmF/DncqKrX7jjE0ksTpIxMgiQObv+gZjKcCMxx 9nMPb0FiQdLislstmTX5LdyI9JzLgbBH+HNkLR6TiHhgLTF4GNpqazkzqR24F4JCrtmArkmn m43p8lXovjk8XyyNifk7PU9qE+AR+5laSYwKwUq3vb6M+5FcYbiA1dtMC2WVTxSv/CBRLGs/ 3U/ZzZAgs0r1GD6EjozZhaZKgQAh1yQhl+mOb/iXY/srDjriCviUG/YV6KnjPETzUKlIrjvd ufYL3uO8rwmKdK3z2Fgc3LFxgh4jNN85tBeuDHTCwy63bnfPGu0m3matePqkXDKOvxIukqxq yvvnXYdkwtLlxEQ86iWOC/eyxqCX1soS9zgeFZg7KyJIFPwXOTpRBdzOL2z8+NF3YhXMcZo/ p5PXkf8iSH467CMhHBqU8tGvNcklOGSgfRu0s0AoWpiqFE/CQYunj8JGYhDCMou9Ek4g4rI/ z70kmGfb03Ha+q/jTo/IXzaIP89NJJhph5N36m06aRD7aHKW0+nO8XSgW9Q+XptiLkwDHayw 69AJzOEY+g0aK12ekOBuYm6OjJpFSwj0GPuW/nT0BEwiJqTGPPrLR6pD/60DU4uDnT4C2M/D e3M61vFPGlo0fHCgQSuXaagfw8jeNd+fdxqXTfUGNdJXJHI8OkT4DK1gwi3Rz/9+hYvEzJhZ y0eNqsOVVdRo/+MDl7+3JO6qo5QN6gn6gbyxoIuJBWpqWuIV+HrIDlOePaXcGG8jJyHNO+OA 2SuNIjHUKzGB0JrWRSka2Dgm6CNC5cwW80X5ttMg7z7PYmLT+hA8ZJV2i3WG/JGebKERV+T8 RetIaPX/PcuEh8XAhcKbZ4elolwlY1W5VpGMVSR42SWMeQrZ9wvcI9o6vGKyzshmCvhuTnjM UeOn7rX+c/MacYi1b7UiB2UcOaNwSP5Fc2tsELopt2J6zBd0AxE7G7f10dBtfCRifotGGD3Y Lk1tw8cjHcev4S5NMXaD6XQIOk7GQ9vHpJdaAHvrCTJNSL3EUg7v/0Z4F+iy7xY9xUEtADpr RVgyymiedJaMBCO6TYJdFWzqMAp/PjJBr2XO7AmSPnwtutet/nu8k75x0+6vpQyEYFpaS7w7 gCUihDGHqa1Ywk3kWHlCcdOp7mSSAx0ndw26ynIsRYyFUQdCNKUVQtnd+shPiPcRiF7Mj81E gZAIUZWbthUzgpB9PyMENplQ6mppfTHHhgumgBdP8JAeOWCMBdrvVC9QHy1NGs5yvQbsMr4Y thvlyS4waF0i6OLsfo6AelgxYh0uiEv89ruo4vPR8nHBojEkCD76G4amORiaeCsFu2hyYSwn qLi4l+pZy4fBkloKiy8Btu4oZ3+v7kjI303abv2NvQHKmsQRTKqO+dlcDbQfYbrZ1hfqlBYo 5RfWdDw0lrcf5h9W+N+3MPl+GD0u7ozl4n7+2T4YEWAsELhbrRbHh4cPDw8H6nvSpQOmFHBy Z80MPBtwOWH3tJMqS9e011QDWov8BqfieilcJUEPW2L/irhT8tZudVr9E0mdlXVczDSEfQna BsfWbGDO0xfNfr/5a1+/apy9a1zAPtZRWcUnBQvobgl9BF8U21j5S6Zu+ue5Ou00nLAVooA7 ggN50pP3R+gSJCqmYvIYOmWQ9lFnpUJHHkKcTuRZxmNVAlNKmYLrZt5aKqHT0jcbMyccFJNW TJS2ftW+uWh10jDYYPOso/mB71D2qe0ZYT16saC1tQFrqrGorDnBapsD1ZhpKCxIrfb3DFID tYibdJh2UyyTTfPIH6OGsWie6C++B36hALWnNSnVjtgx5ZEcH71Wbwv06Xc9/f+0JhccARGi zDVULYqDGqNOO0TkXhiL9GUN1cYilGfHkVpILAPFw+ykJ0YvF12/iygbFSbFhRB1ugM7gPee V/cLKCb1o1twS4XwVZwwLazDZ68D1+9apYI/C7VKXv4p0qtCvlItVfM12CS9yhfy1XzplVZ5 ds4g3eOBnaa9WsHu4HFNvk3v/0cTyP+q2z9vtZu9A3P+PHWggKvlcqj8i+Uikz+Iv1IsgfyL pQrIP/887Kjp/1z+r7W2aZPRGbd+NgN/T9NXKaNx5zP08nGPwJeDuT2l7UQyKYLTR85vd0lE HOA3zo7kP9gb2hfyX+6Syomi9MddkvJRnr+6h/7eCeb/GcXOt63b56pj0/wX63+xWi7QdwLm fzme/y+SQP7oPIGT/2AGk/zhGerYIP9CrSi+/6CMleB5oVQqV2L5v0RivjOu+JOvk6+1t65Z 5dh5jwfOIjJNm1nse0HZhwPbGGugXqKi9cbWfGMKckG2DioX/D7jW2NFvoXM+pT0WJ24joZW BywIO/jJbEX2m8F8nLy47F2cX/a170818rgZmvNDlgUzXw1Wd9oDXaRCF7ZzRgVm5RCxKEHk GFGUZCb8ro6uHIIa89+ZWqPB1Ei2Or1+o90WeU61vfTbZq+PdrS9tFQ6k0we9G7Oz1u/NnvH 0q/awcLSDm5nFnAGPfVa63Vvrs+avX2Nean38HHyrNFHD7Ee0V8MVvb9ED7JX0HZ/a+w8P5e +sGcjkdoMfoGnmYygtz1DezbiAY8xqzHycRypuUm2t4PqOkBk6yzMlouR+Ap9soc2VrOwgx7 3wo6/cY1iIBTuvpnt/P+WIMuEl2ljabGAD738Osx0BT8Ahs8A+VOJmafx+ZSyy0gj9pzmWTi h9FgRVuE0zcShTcn2odkglxtYN8BW429PZHvBLGL4aWGr04/4SAj9ZRyfDphr6bw6Tr9ZIzu LPZc+5eGY/GNffgBu2Nv7/DwjciLLlo+xg739pDGYftMoAf2eHa3MXvwC39owvA1QDi5Javv hN19Te+A0QXngooc7qX5eM4czKwTkYmYTfGOQysaKzKwnVKe2YClU7z4xKRfxtbcSCZJKo7E v6Fx9levJ3GKU5ziFKc4xSlOcYpTnOIUpzjFKU5xilOc4hSnOMUpTnGKU5ziFKc4xenl038A eTaWmADIAAA= --------------080306040203070309000708 Content-Type: application/octet-stream; name="gaim-otr-i18n-patch.tar.gz.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="gaim-otr-i18n-patch.tar.gz.sig" iD8DBQBFz0Bg0pI8wKmP0c4RAlGPAJ9BG3dC42EFb+q+Bfoti5ssP79NtgCgh4BeWHDiMdLX WNpAA/vNBUI7Pp4= --------------080306040203070309000708-- From mail@scottellis.com.au Sun Feb 11 23:03:51 2007 From: mail@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> ------=_Part_88713_7633978.1171235031896 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 ------=_Part_88713_7633978.1171235031896 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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

------=_Part_88713_7633978.1171235031896-- From Tommy.B@gmx.net Mon Feb 12 01:16:17 2007 From: Tommy.B@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@cypherpunks.ca Mon Feb 12 13:49:23 2007 From: ian@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@scottellis.com.au Mon Feb 12 14:57:43 2007 From: mail@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> ------=_Part_101538_10767998.1171292263184 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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@lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > ------=_Part_101538_10767998.1171292263184 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline excellent idea - enum'd error codes or something would be great

On 2/13/07, Ian Goldberg <ian@cypherpunks.ca > 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@lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev

------=_Part_101538_10767998.1171292263184-- From Tommy.B@gmx.net Fri Feb 16 12:21:46 2007 From: Tommy.B@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@lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > From ian@cypherpunks.ca Fri Feb 16 13:25:18 2007 From: ian@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@cypherpunks.ca Sun Feb 18 01:38:22 2007 From: ian@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@cypherpunks.ca Sun Feb 18 15:13:11 2007 From: ian@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@cypherpunks.ca Sun Feb 18 15:30:11 2007 From: ian@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@cypherpunks.ca Mon Feb 19 12:42:25 2007 From: ian@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@cypherpunks.ca Tue Feb 20 11:10:18 2007 From: ian@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