Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
Hi, I'm about to upload pidgin-otr 4.0.0 to debian unstable, and it appears the calls exit() issue has moved to pidgin-otr. I don't know enough of pidgin plugin system to know whether this is a false positive or not, but I thought I might blow the whistle anyway... HTH Thibaut X: pidgin-otr: shlib-calls-exit usr/lib/pidgin/pidgin-otr.so N: N:The listed shared library calls the C library exit() or _exit() N:functions. -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
On Mon, Oct 1, 2012 at 7:24 PM, Paul Wouters p...@cypherpunks.ca wrote: On Mon, 1 Oct 2012, Thibaut VARENE wrote: I'm about to upload pidgin-otr 4.0.0 to debian unstable, and it debian already ships libotr-4? Did they add a libotr3 package? Did libotr5, per soname. other OTR software get ported to 4.x already? Or will it just break? libotr5 has been in experimental for a month now. If packages haven't been updated, they'll break, since libotr5 conflicts with libotr2. They'll need a rebuild against the new library package anyway. HTH -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
On Sat, Sep 1, 2012 at 6:22 PM, Ian Goldberg i...@cypherpunks.ca wrote: On Sat, Sep 01, 2012 at 11:55:33AM -0400, Greg Troxel wrote: Ian Goldberg i...@cypherpunks.ca writes: This looks a lot like one of you is logged in more than once. Could this possibly be the case? (If the other person is using Adium, you'd have fallen back to the OTRv2 protocol, so you don't get the protection from multiple logins that the new protocol added.) That could have been true, but I've been doing otr (v2 obviously) with this person for years, and not having trouble. I just picked someone else, and tried to initiate. That person shows (in pidgin) as being logged in only once. I got (11:52:08) Error setting up private conversation: Malformed message received same as before. It would be nice to print out the malformed message, but I don't know how (other than reading the source and changing the code). Weird. I believe if you run pidgin -d, it will show all of the Jabber messages it's sending and receiving. Give that a try? Also, in the pidgin chat window, i have multiple tabs. Two people don't do OTR, and that otr tab has 'start', other things greyed, a separator, their jid, and 'not private'. That's all fine. The other person has done OTR (johndoe@ above), and is set to 'no otr', and looks the same - but has the most recently looked at of the other parties' JID!!! It seems that it's enough to select the tab and come back, and that changes the JID in the OTR menu for the otr-troubled contact. I'll need to look into this. Is it replicatable on your end? It seems to be, at least with this person. setting otr to 'use default' fixes the problem. unchecking 'use default' and then unchecking 'enable' makes the OTR menu go away. But then selecting someone else's tab and then coming back makes the OTR menu re-appear, with the wrong jid. Yup, I've replicated it here, too, and I see the problem in the source. It shouldn't be too tough to fix, but I'm thinking Target: 4.0.1 for that one. Would the various packagers prefer a last-last-minute change to 4.0.0, or just to put this fix into the next version? As far as I (debian/ubuntu) is concerned, I'll let 4.0.0 live in experimental for a little while so at to leave time for dependencies to upgrade. Don't feel extraordinarily urged to push fixes tho. I'd rather upload a rock solid 4.0.1 to unstable a bit later. Cheers -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
On Fri, Aug 31, 2012 at 2:09 AM, Ian Goldberg i...@cypherpunks.ca wrote: On Thu, Aug 30, 2012 at 06:33:48PM -0400, Paul Wouters wrote: On Thu, 30 Aug 2012, Ian Goldberg wrote: So 7 clients use it, so I am not going to assume all of these can fix their code within a few days. Indeed not. They can continue to depend on the old version of libotr. (Your libotr3 package, if I understand it? But does that mean you have to change all of the above packages to explicitly name libotr3? If I understand the Debian/Ubuntu method correctly, the package name has been libotr2 all along, and all those other programs name libotr2 as their dependency. The new package will be libotr5, and programs that update their use of libotr can then switch their dependency to libotr5.) Yes, I will send patches to the maintainers of these to change their Require: libotr to Require: libotr 4. The libotr3 package will supply libotr 4, while the libotr package will supply libotr = 4. Since they're using the libotr 3 API, shouldn't they require libotr == 3? And the new libotr package will supply libotr == 4, and the new pidgin-otr package will require libotr == 4? (As opposed to = 4?) I think all that is relatively pointless. Ian: libotr2 will no longer be actively maintained/developed when libotr5 is released, right? If so, I plan to move on with the current state of things in Debian: libotr 4.0.0 (source package providing libotr5, -dev and -bin) will *replace* libotr 3.2.1 (source package providing libotr2, -dev and -bin) at which point packages that still require libotr2 will simply break, and their respective maintainers will have to take action. I don't think libotr has that many dependencies nor is that a critical package that it warrants the maintaining of 2 different versions over the lifetime of major linux and BSD distributions just for the sake of easing dependencies' transitions. At least for Debian, that's how things will be done. HTH -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
On Fri, Aug 31, 2012 at 2:14 PM, Ian Goldberg i...@cypherpunks.ca wrote: On Fri, Aug 31, 2012 at 12:43:58PM +0200, Thibaut VARENE wrote: Yes, I will send patches to the maintainers of these to change their Require: libotr to Require: libotr 4. The libotr3 package will supply libotr 4, while the libotr package will supply libotr = 4. Since they're using the libotr 3 API, shouldn't they require libotr == 3? And the new libotr package will supply libotr == 4, and the new pidgin-otr package will require libotr == 4? (As opposed to = 4?) I think all that is relatively pointless. Ian: libotr2 will no longer be actively maintained/developed when libotr5 is released, right? If there's a security release needed, I'll consider pushing out a 3.x security update for at least a little while, but I haven't set a firm timeline policy or anything like that. OK. That confirms what I was expecting. If so, I plan to move on with the current state of things in Debian: libotr 4.0.0 (source package providing libotr5, -dev and -bin) will *replace* libotr 3.2.1 (source package providing libotr2, -dev and -bin) at which point packages that still require libotr2 will simply break, and their respective maintainers will have to take action. Isn't that impolite to those maintainers? Or will you give them a heads-up in advance? The notion of politeness in FOSS makes me chuckle ;-) The heads up they have is 1) (for upstream) your release announcement: after all, they're writing code that uses your library, so they should know what they have to do already; and 2) (as far as Debian maintainers are concerned), the upload of the new version of the library to 'experimental', which has already happened and is pending validation. It appears people are already well aware of the upcoming change too: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685664 Again, we're not breaking libc here. From what I read, I don't think the new version of libotr will impose a complete rewrite of dependent software, right? ;-P I don't think libotr has that many dependencies nor is that a critical package that it warrants the maintaining of 2 different versions over the lifetime of major linux and BSD distributions just for the sake of easing dependencies' transitions. At least for Debian, that's how things will be done. Sounds reasonable. I plan to build the test releases of 4.0.0 today, including the patch to fix the exit() issue, and an extremely minor remove whitespace at the ends of a handful of lines source cleanup patch. OK. -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
On Tue, Aug 28, 2012 at 2:24 AM, Ian Goldberg i...@cypherpunks.ca wrote:
Indeed, otrl_init(ver_major, ver_minor, ver_sub) calls exit(1) if the
passed version numbers are incompatible with the library's actual
version.
Seeing as how it's intended to be called from this macro:
#define OTRL_INIT do { \
otrl_init(OTRL_VERSION_MAJOR, OTRL_VERSION_MINOR, OTRL_VERSION_SUB); \
} while(0)
I suppose we could change otrl_init to return an error code, and change
the *macro* to call exit() upon otrl_init returning an error. Although
technically the ABI would change, the API wouldn't.
As long as the macro itself isn't used in the library, this should indeed work.
I will consider this for inclusion before release.
Thanks for the note!
You're welcome!
--
Thibaut VARENE
http://www.parisc-linux.org/~varenet/
___
OTR-dev mailing list
OTR-dev@lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
