Bug#767103: [pkg-otr-team] Bug#767103: Bug#767103: irssi-plugin-otr doesn't work with irssi 0.8.17
Hi, Holger Levsen wrote (10 Nov 2014 12:22:24 GMT) : Also, it would be good if someone tried current libotr (backported to Wheezy) + wheezy-backports' irssi-plugin-otr. I'd hate to break that one when I upload the backport. i can test that... I've just uploaded the latest libotr to wheezy-backports. If irssi-plugin-otr from wheezy-backports still works with that libotr, then this will help confirm that the problem is indeed unrelated to libotr, but instead caused by the irssi upgrade, as Rhonda pointed out. Holger, may you please test this? Another way to confirm the root cause of the problem would be to rebuild irssi-plugin-otr in testing or sid against: * the old libotr (4.0.x) * the new irssi (0.8.17-1) ... and test that on testing or sid (that is, with the new libotr and new irssi installed). Any taker? (I'm not using irssi myself, just giving a hand on this bug since I'm on the pkg-otr team.) If any of these two tests works, then I'll be fully convinced that indeed, this plugin needs to be binNMU'd every time irssi is updated, and then: * we should have irssi-plugin-otr binNMU'd in testing; * for Stretch, we'll need to have the discussion that Rhonda started about library packaging. Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767103: [pkg-otr-team] Bug#767103: Bug#767103: irssi-plugin-otr doesn't work with irssi 0.8.17
On Samstag, 15. November 2014, intrigeri wrote: Rhonda pointed out. Holger, may you please test this? definitly not before wednesday... signature.asc Description: This is a digitally signed message part.
Bug#767103: irssi-plugin-otr doesn't work with irssi 0.8.17
* intrigeri intrig...@debian.org [2014-11-04 20:14:24 CET]: 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? I'm not so much sure if that has anything to do with libotr API. irssi happens to change api/abi every now and then and plugins need to get recompiled on almost any new irssi release. I have the same issue with irssi 0.8.17 from backports and irssi-plugin-otr from stable. The plugin needs a tighter dependency on irssi. I'm not familiar with how library packaging works, and whether that could be used at all for irssi, thing is that the plugins (especially the otr one it seems) need to get recompiled every time a new irssi upstream release happens. Anyone who is willing to dig more into this is very much encouraged to do so and help out, either for the packaging part to ease that pain, or with upstream to make it more stable in that respect. I'm personally lacking the skills to do that because I haven't digged into any library packaging work at all, so my whole soname versioning knowledge is sort of non-existing (and I'm still uncertain if that could help here at all, if only to produce something that the irssi-plugin-* packages won't be installable anymore after a new irssi upload). Please get the binNMU done for now, and anyone more knowledgeable can figure out how to deal with that in the future. Sorry that I forgot to send a mail about the new upstream release this time. Enjoy, Rhonda -- Fühlst du dich mutlos, fass endlich Mut, los | Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden Fühlst du dich machtlos, geh raus und mach, los | 23.55: Alles auf Anfang Fühlst du dich haltlos, such Halt und lass los| -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767103: irssi-plugin-otr doesn't work with irssi 0.8.17
Dear team-mates, I don't care enough about irssi-plugin-otr to dig further into that bug. I don't understand how this can possibly break. Can anyone reproduce this RC bug and look into it? It might be an unspotted ABI breakage in libotr, who knows. David, does irssi-plugin-otr do anything strange that could tie it up more tightly than e.g. pidgin-otr into the internals of libotr? Shall we ask the release team for a binNMU of irssi-plugin-otr, and postpone understanding the root cause of the bug? I'm concerned that it may occur again each time we upgrade libotr, but as far as Jessie is concerned, this might be the way to go. Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767103: [pkg-otr-team] Bug#767103: irssi-plugin-otr doesn't work with irssi 0.8.17
Hi, On Montag, 10. November 2014, intrigeri wrote: I don't care enough about irssi-plugin-otr to dig further into that bug. I don't understand how this can possibly break. Can anyone reproduce this RC bug and look into it? yes, it's on my radar and todo list as a user of that plugin. That said, I don't expect I will have time for this before the weekend... Shall we ask the release team for a binNMU of irssi-plugin-otr, and postpone understanding the root cause of the bug? I'm concerned that it may occur again each time we upgrade libotr, but as far as Jessie is concerned, this might be the way to go. if were doing this I'd suggest to add a versioned dependency... cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#767103: [pkg-otr-team] Bug#767103: Bug#767103: irssi-plugin-otr doesn't work with irssi 0.8.17
Holger Levsen wrote (10 Nov 2014 11:54:53 GMT) :
On Montag, 10. November 2014, intrigeri wrote:
Shall we ask the release team for a binNMU of irssi-plugin-otr, and
postpone understanding the root cause of the bug? I'm concerned that
it may occur again each time we upgrade libotr, but as far as Jessie
is concerned, this might be the way to go.
if were doing this I'd suggest to add a versioned dependency...
I don't think that (and the corresponding source upload) is needed,
since the main libotr binary package was renamed from Wheezy to Jessie
(libotr2 - libotr5), so the only remaining problematic partial
upgrade case is wheezy+backports to Jessie, and I intend to upload the
latest libotr to wheezy-backports in the next few days (as per Julien
Cristau's suggestion) to avoid similar issues for pidgin-otr.
Anyway, if we do that, for future-proofness you'll want to make sure
that the manually added versioned dependency doesn't interfere badly
with ${shlibs:Depends} in case that one returns a dependency on
a newer version of libotr.
Also, it would be good if someone tried current libotr (backported to
Wheezy) + wheezy-backports' irssi-plugin-otr. I'd hate to break that
one when I upload the backport.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767103: [pkg-otr-team] Bug#767103: Bug#767103: irssi-plugin-otr doesn't work with irssi 0.8.17
Hi,
On Montag, 10. November 2014, intrigeri wrote:
I don't think that (and the corresponding source upload) is needed,
since the main libotr binary package was renamed from Wheezy to Jessie
(libotr2 - libotr5), so the only remaining problematic partial
upgrade case is wheezy+backports to Jessie, and I intend to upload the
latest libotr to wheezy-backports in the next few days (as per Julien
Cristau's suggestion) to avoid similar issues for pidgin-otr.
ack
Anyway, if we do that, for future-proofness you'll want to make sure
that the manually added versioned dependency doesn't interfere badly
with ${shlibs:Depends} in case that one returns a dependency on
a newer version of libotr.
how to do that? or: whether is an example of such breakage?
Also, it would be good if someone tried current libotr (backported to
Wheezy) + wheezy-backports' irssi-plugin-otr. I'd hate to break that
one when I upload the backport.
i can test that...
cheers,
Holger
signature.asc
Description: This is a digitally signed message part.
Bug#767103: [pkg-otr-team] Bug#767103: Bug#767103: Bug#767103: irssi-plugin-otr doesn't work with irssi 0.8.17
Holger Levsen wrote (10 Nov 2014 12:22:24 GMT) :
Anyway, if we do that, for future-proofness you'll want to make sure
that the manually added versioned dependency doesn't interfere badly
with ${shlibs:Depends} in case that one returns a dependency on
a newer version of libotr.
how to do that? or: whether is an example of such breakage?
No idea. I'm only afraid that ${shlibs:Depends} might not override
a (even lower) manually added dependency.
Also, it would be good if someone tried current libotr (backported to
Wheezy) + wheezy-backports' irssi-plugin-otr. I'd hate to break that
one when I upload the backport.
i can test that...
Cool, thanks!
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767103: irssi-plugin-otr doesn't work with irssi 0.8.17
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 libotr54.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-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767103: irssi-plugin-otr doesn't work with irssi 0.8.17
On Fri, Nov 07, 2014 at 10:15:22AM +0100, intrigeri wrote: 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 libotr54.1.0-2 I still have this problem. :( OK, thanks. Just to highlight, you asked for 4.1.0-_1_, but I am at -_2_ – which according to the changelog is the first one with the symbols file. 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)? Yes, libotr5-dev is at 4.1.0-2 just as libotr5. After all the -dev package has an equal-dependency on the library, so my beloved apt would be pretty pissed if it would be at an earlier version. ;) Best regards David Kalnischkies signature.asc Description: Digital signature
Bug#767103: irssi-plugin-otr doesn't work with irssi 0.8.17
Hi, 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 libotr54.1.0-2 I still have this problem. :( 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. (sorry, I can't test with a real remote at the moment) Looks like libotr5 still has an ABI break somewhere – or the +b1 happened at the time libotr5 had one, so that it picked it up accidentally (at least in the amd64 rebuild)? So, next action is reassigning to release team for another binNMU, to libotr5 to find the possible regression or … ? Best regards David Kalnischkies signature.asc Description: Digital signature
Bug#767103: irssi-plugin-otr doesn't work with irssi 0.8.17
Control: tag -1 + moreinfo Hi, 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? Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#767103: irssi-plugin-otr doesn't work with irssi 0.8.17
Processing control commands: tag -1 + moreinfo Bug #767103 [irssi-plugin-otr] irssi-plugin-otr doesn't work with irssi 0.8.17 Added tag(s) moreinfo. -- 767103: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767103 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767103: irssi-plugin-otr doesn't work with irssi 0.8.17
Package: irssi-plugin-otr Version: 1.0.0-1 Severity: grave X-Debbugs-CC: ir...@packages.debian.org Hello! Upgrading irssi from 0.8.16-1+b1 to 0.8.17-1 seems to break the OTR plugin for me. Opening a new query window and executing /otr init resulted usually in the initialisation of an OTR session. Doing it now seems to not send anything to the remote user I tried to init an OTR session with and instead a message like this shows up in the status window: 14:50:16 [oftc] OTR: Initiating OTR session... 14:50:20 [oftc] -!- H�G(�ff.�: No such nick/channel OTR inits from the remote end don't trigger any interesting status messages, but the query window contains the usual Gone secure message, but nearly after every message from the remote (sprinkled in with a message telling me that this wasn't sent inside the OTR session) and the indicator claims it is still plaintext. I haven't really investigated which one is true as that smells fishy either way. (I think it is unrelated, but for completeness: the remote end is Pidgin, but a simple webclient as remote doesn't show any message along the lines of ?OTRv23? if I try to init either; irssi is connected via ZNC). Downgrading irssi to the previous version solves this issue. I have CC'ed irssi maintainers in case they have an idea what is wrong and/or as this if unsolved effects jessie might warrant a Breaks. Best regards David Kalnischkies signature.asc Description: Digital signature
