The unexpected-xfr patch fixes the issue described here: http://groups.google.com/group/py-transports/browse_thread/thread/2dbaff5cea2c2bb8 Short description: MSN server wants to transfer the client onto another server, but pymsn-t treats that as an error and fails to connect entirely. It was taken from (I removed unnecessary changes): http://groups.google.com/group/py-transports/browse_thread/thread/e4ea3fe7bf518a64/6d62cfa583638ad5#6d62cfa583638ad5 The other patch (twisted-compat) is selfmade and "fixes" compatibility issues with newer versions of twisted. I think the removal of "del sys.modules" is correct (the twisted manual only talks about install()ing the new reactor, not about removing the old). But removing the removePID callback is probably a bit wrong, but at least it gets the transport running... Reproducible: Always
Created attachment 165821 [details, diff] unexpected-xfr
Created attachment 165822 [details, diff] twisted-compat
Created attachment 165826 [details, diff] remove-pid Improved fix for remove pid, taken from: http://groups.google.com/group/py-transports/browse_thread/thread/8e3583a86a4bb053/6e286edb15a95077#6e286edb15a95077
Created attachment 165827 [details, diff] delete-reactor Decoupled removal of reactor deletion (was part of twisted-compat before)
Thanks for the patches! Assigning to maintainer.
Could you explain a bit why Gentoo needs to apply these patches directly instead of getting them through upstream releases?
They fix current issues... Getting them next year will not help anyone, since the transport is broken *now*, not in a few months... And some (what first went under the name "twisted-compat") are more or less specific to the versions Gentoo has in their stable repository. So one could argue that these issues are caused by the distribution's stabilisation policies... Do you know when the next upstream version of pymsn-t will be released? The last bugfix(!!, x.y.ZZZ) releases were 1.5 years apart and it seems the project has not grown in activity a lot. (At least not in the visibile kind.) Other ebuild maintainers include fixes into their ebuilds as well, even if they are already included upstream (which is afaik not the case here), just so their users get a stable and functional version in Portage. Instead of having to patch and install a version manually, *even though* there is version in Portage, which is marked *stable even though it is not*, one should be able to just rely on their distribution to provide them with something that works... Hope that makes it clear and does sound as objective to you as I intended it to be...
(In reply to comment #7) > They fix current issues... Getting them next year will not help anyone, since > the transport is broken *now*, not in a few months... Any non-trivial piece of software always contain bugs. I'm not saying we should stick to a vanilla upstream release, but just because there are known bugs in the last release doesn't mean Gentoo should include patches for them. For the latest and greatest you just need to get the source from the upstream repository. > And some (what first went under the name "twisted-compat") are more or less > specific to the versions Gentoo has in their stable repository. So one could > argue that these issues are caused by the distribution's stabilisation > policies... Ok. I didn't notice these errors in the log myself as my transport was (and is) still functioning. > Do you know when the next upstream version of pymsn-t will be released? The > last bugfix(!!, x.y.ZZZ) releases were 1.5 years apart and it seems the project > has not grown in activity a lot. (At least not in the visibile kind.) No, I don't, but maintenance has been taken over and there has been some activity in the repository in the last month or two. pymsn-t is not a really active project with longer times between releases as a result. > Other ebuild maintainers include fixes into their ebuilds as well, even if they > are already included upstream (which is afaik not the case here), just so their > users get a stable and functional version in Portage. > Instead of having to patch and install a version manually, *even though* there > is version in Portage, which is marked *stable even though it is not*, one > should be able to just rely on their distribution to provide them with > something that works... As I said, mine works. It was not so clear to me if the problems you referred to happened often or were just corner cases. > Hope that makes it clear yup > and does sound as objective to you as I intended it to > be... I can't say, but so do I =)
Committed as pymsn-t-0.11.3-r2. Thanks!
The unexpected-xfr issue seems to only appear for a limited number of users. Some claim it only happens for users of non-LiveID accounts. But I created a new LiveID testaccount and that did not work either, so my guess (I have no clue of the MSN protocol) is that it has something to do with a different domain, that @live.de might select a different server than @live.com or whatever. For the twisted issue: Do you also use twisted-8.1.0? Since that is what it would not start with...
