Hi, David Kalnischkies wrote (06 Nov 2014 21:52:10 GMT) : > On Tue, Nov 04, 2014 at 08:14:24PM +0100, intrigeri wrote: >> David Kalnischkies wrote (28 Oct 2014 14:00:40 GMT) : >> > Upgrading irssi from 0.8.16-1+b1 to 0.8.17-1 seems to break the OTR >> > plugin for me. >> >> I'm wondering if this could be a side-effect of #767230. >> Can you reproduce this after upgrading libotr5 to 4.1.0-1?
> Sounds like it and I had some hope, but trying with: > irssi 0.8.17-1 > irssi-plugin-otr 1.0.0-1+b1 (+b1 for rebuild against libgcrypt20) > libgcrypt20:amd64 1.6.2-4 > libgcrypt20:i386 1.6.2-4 > libotr5 4.1.0-2 > I still have this problem. :( OK, thanks. > I see that irssi-plugin-otr has an unversioned dependency on libotr5. > Doing an "apt-get source irssi-plugin-otr -b" results in a package with > a versioned dependency "libotr5 (>= 4.0.0)" and after installing and > restarting irssi I can run "/otr init" without the mentioned error message > and the remote gets the '?OTRv23?', so that looks about right. Can you confirm you've built it against libotr from sid (that introduces a proper symbols file)? > Looks like libotr5 still has an ABI break somewhere – I'd be surprised, as several people looked pretty closely and didn't find one, but well. > or the +b1 happened at the time libotr5 had one, so that it picked > it up accidentally (at least in the amd64 rebuild)? The only relevant change that was reverted in libotr 4.1.0-2 is a version check that happens at runtime, so I doubt it. > So, next action is reassigning to release team for another binNMU, > to libotr5 to find the possible regression or … ? I'm asking upstream (Cc'd): David (Goulet), may you please have a look at this bug report? Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
