hi sparc porters, we need net-im/msnlib-3.2 to be bumped to stable before oct 15 because the older versions will not work after the lock out. if you guys could take some time to test out the new version, it would be great. the developer has told me he's tested on sparc, but i'd rather someone from the team double check. thanks
I tried it out here. It works but the UI is slow (multiple keystrokes before text prints). I also have a rather lengthy and long compile going, so that could be part of it. Sparc Devs, do you get this behavior?
it is pretty responsive for me, but i don't have a sparc to test on ;)
OK, I've tried this on both a Sun Ultra 2 Enterprise and a Sun Blade 100. In both cases, the msnsetup utility runs fine. No problems, no delay in running. However on both systems, the client, msn, does not respond in real time. Keystrokes don't appear or get acted on for at least two keystrokes afterwards.
Alberto, Do you have any ideas about the delayed responses on sparc?
Hi, thanks for taking the time to test this =) Sorry it took so long for me to step into but I don't follow bugs in gentoo very closely, so thanks for adding me to the CC list. Well, I've tested it but without termios support and it works fine; however now I'm looking at this with termios enabled (since this is a fairly updated gentoo install) and I can easily reproduce the problem. I use termios support to make my own terminal handling functuons and be able to, basically, read one char at time from stdin in order to do some tab completion and stuff. Normally I do that by importing termios and fcntl, set a couple of terminal bits to avoid echo, and fcntl to set stdin nonblocking so select returns as soon as a char from stdin is typed. Termios detection is done automatically at runtime by a simple try-except in importing the termios module, and if it's not available we fall back to use the good old readline() After some testing, I've found that python's fcntl module (that I use to set stdin nonblocking) it's not making the system call as it should (and does on x86), so stdin never gets into nonblocking mode and this is what is causing the bug. It's not msnlib specific, but it's a python bug. The code hasn't been touched since msnlib 2.0 so it's also present there, I'm guessing python's previous version worked fine and that's why this bug went undetected. You can reproduce the problem by running this python code and stracing it: import fcntl, sys fcntl.fcntl(sys.stdin.fileno(), fcntl.F_SETFL, os.O_NONBLOCK) You'll see that on x86 there IS a fcntl system call, but there is none on sparc, as the fcntl was never called. I'm not sure if this is a python specific bug or it's caused by some gentoo install parameter because the only sparc I've got at hand has gentoo on it. Anyone has any idea on where to report this? Thanks a lot, Alberto
I've reported this bug to the python bug tracker on sourceforge. The bug ID is 821948, titled "fcntl() not working on sparc (python 2.2.3)", and you can find it in http://sourceforge.net/tracker/index.php?func=detail&aid=821948&group_id=5470&atid=105470 I'm going to see what they come up with because from my side, sadly, there isn't really much I can do. Please let me know if you have any ideas.
sorry i haven't been a little more responsive. as far as i know for python, we just distribute the stock standard python-2.2. from the bug report you filed, it seems like they think it might be some exception happening in the code (fcntl) for sparc only.
Do we want to try and upstream the fcntl issue? Since the problem doesn't lie with msnlib, we could stabilize it, even though it kind of will be not all that usable on sparc.
Well, I couldn't do any further testing on the issue due to problems of other nature, so all I did was create a bug in sourceforge but I couldn't even try to reproduce it on later Python versions and the report got stucked. I don't know if it's not fixed in python 2.3, if so we could just require it on sparc. It's strange because fcntl is an important module, I thought more people used it. People has reported success with msnlib on solaris/sparc, so I guess it's only a linux/sparc bug in python. Anyway, msnlib 3.3 has been out for a while, but I don't think it should be made stable on sparc (and on sparc only, x86 seems to work fine) because until we know for sure which python version fixes this issue it's not going to work in a stable way, regardless the code is good and it's not msnlib's fault. If you can try msnlib under a sparc with a modern Python version, please let me know; I won't be able to test on sparc for sometime. Then the ebuild can be modified to require this version on sparc, and 2.2.2 on x86 (i have no idea if it works under other linux-based platforms than these two). Thanks, Alberto
When do we get to see msnlib 3.3? (It's been available since november 12th... :)
the 3.3 upgrade kind of got lost in this whole bug about sparc. i think its pretty much CANTFIX at the moment. i think it should be sufficient to have msnlib marked as ~sparc for now.