Bug 30650 – stable bump for net-im/msnlib 3.2

• Product: Gentoo Linux
• Status: RESOLVED CANTFIX

[Description Alastair Tse (RETIRED) 2003-10-08 03:28:32 UTC]

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

[Comment 1 Jason Wever (RETIRED) 2003-10-08 14:58:45 UTC]

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?

[Comment 2 Alastair Tse (RETIRED) 2003-10-09 01:23:15 UTC]

it is pretty responsive for me, but i don't have a sparc to test on ;)

[Comment 3 Jason Wever (RETIRED) 2003-10-11 06:24:47 UTC]

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.

[Comment 4 Alastair Tse (RETIRED) 2003-10-11 07:48:19 UTC]

Alberto,

Do you have any ideas about the delayed responses on sparc?

[Comment 5 Alberto Bertogli 2003-10-11 11:24:33 UTC]

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

[Comment 6 Alberto Bertogli 2003-10-13 10:14:34 UTC]

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.

[Comment 7 Alastair Tse (RETIRED) 2003-10-30 01:42:50 UTC]

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.

[Comment 8 Jason Wever (RETIRED) 2003-11-24 17:25:28 UTC]

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.

[Comment 9 Alberto Bertogli 2003-11-26 04:54:53 UTC]

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

[Comment 10 Daath 2004-01-29 15:44:17 UTC]

When do we get to see msnlib 3.3? (It's been available since november 12th... :)

[Comment 11 Alastair Tse (RETIRED) 2004-02-04 10:52:15 UTC]

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.