[OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
varenet at debian.org
Sat Sep 1 13:25:37 EDT 2012
On Sat, Sep 1, 2012 at 6:22 PM, Ian Goldberg <ian at cypherpunks.ca> wrote:
> On Sat, Sep 01, 2012 at 11:55:33AM -0400, Greg Troxel wrote:
>> Ian Goldberg <ian at 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
> 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
> 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.
More information about the OTR-dev