4732 2013-06-14 17:16:25 +0000 Wrong path to terminfo files in buildtools-tarball causes python version check to fail 2013-07-30 02:13:19 +0000 1 1 6 Yocto Project Subprojects ADT adt 1.5 x86 Multiple RESOLVED FIXED Medium+ normal 1.5 M3 1 sgw hongxu.jia hongxu.jia kai.kang liezhi.yang mark.hatle ning.zhang poky.adt.watcher poky.watcher Qi.Chen richard.purdie sen.zhang sgw wenzong.fan yi.zhao --- --- --- oldest_to_newest 33908 0 sgw 2013-06-14 17:16:25 +0000 With the addition of the build tools tarball, the version check for python will sometimes be incorrect due to the terminal type. There is a mismatch between the nativesdk tinfo and the system's terminfo files. This can be seen with by strace'ing the write90 syscall, depending on your TERM setting you might see: write(1, "\33[?1034hTrue\n", 13True ) = 13 or write(1, "True\n", 13True ) = 13 The first variation will cause the version check to fail, we could modify the version check to ignore the leading escapes and/or point tinfo at the right terminfo files. Adding TERMINFO shell variable pointing to the nativesdk will work for the common TERM types, but still seems to fail for xterm-256color, which is not in our nativesdk terminfo. I propose that we modify the version check to ignore the leading escapes. 33910 1 sgw 2013-06-14 20:44:46 +0000 I tried setting TERMPATH TERMINFO_DIRS, TERMINFO, all had no effect with the xterm-256color entry, it would search the nativesdk terminfo if set, but failing to find it would then search the system terminfo files More interesting is is works OK on Fedora, but fails on Ubuntu for the same TERM settings Since we are operating in a script, preserving TERM and unsetting TERM seems like the right approach with a consistent result. 33911 2 richard.purdie 2013-06-14 21:06:40 +0000 (In reply to comment #1) > Since we are operating in a script, preserving TERM and unsetting TERM seems > like the right approach with a consistent result. No, this is a really bad idea. Think about devshell for example. Setting TERM and running python should not break and this is a problem in the nativesdk. Lets fix the nativesdk, not hack around it. 33912 3 sgw 2013-06-14 21:23:06 +0000 devshell works fine, it's the value that the shell is testing from python. Vi and all the other tools work fine in a devshell since they are using distro tools, distro terminfo. Even knotty looks correct and sets the correct colors. I agree we need to fix the nativesdk's python build, but until then, people are going to be running into this with older releases and will be getting failures with master. 33933 4 richard.purdie 2013-06-17 16:09:15 +0000 Have a better fix for this pending... 33996 5 richard.purdie 2013-06-20 12:13:44 +0000 This was fixed by http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=c281cd149bdbce29fc69cb34c65c4295cfed2060 and http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=534c4d0f1e287d0ac82504b273a5497d3457582a 34378 6 wenzong.fan 2013-07-08 09:44:49 +0000 (In reply to comment #5) > This was fixed by > http://git.yoctoproject.org/cgit.cgi/poky/commit/ > ?id=c281cd149bdbce29fc69cb34c65c4295cfed2060 and > http://git.yoctoproject.org/cgit.cgi/poky/commit/ > ?id=534c4d0f1e287d0ac82504b273a5497d3457582a This should fixed the xterm issue but xterm-256color still failed, shall we add a tinfo file for xterm-256color? or just link it to xterm-color simply? 34655 7 hongxu.jia 2013-07-18 06:44:54 +0000 I think the issue is still there since xterm-256color is added to terminfo-base in ncurses: NATIVELSBSTRING = "Ubuntu-13.04" TARGET_SYS = "i586-poky-linux" MACHINE = "emenlow-noemgd" master 3dee534f1e25109e0bdb681de0746c336f4b8840 * On host bitbake nativesdk-python -cdevshell root:Python-2.7.3# export TERM=xterm-256color root:Python-2.7.3# which python /home/jiahongxu/yocto/build-20130522-pmount-sysvinit/tmp/sysroots/x86_64-linux/usr/bin/python-native/python root:Python-2.7.3# python -c "import readline;print 'a'" | hexdump -c 0000000 033 [ ? 1 0 3 4 h a \n 000000a * On target root@emenlow-noemgd:~# export TERM=xterm-256color root@emenlow-noemgd:~# which python /usr/bin/python root@emenlow-noemgd:~# python -c "import readline;print 'a'" | hexdump -c 0000000 033 [ ? 1 0 3 4 h a \n 34656 8 hongxu.jia 2013-07-18 06:48:36 +0000 While imports readline in python, if the term in terminfo is available and it contains the variable 'km' and 'smm', the readline initialization will output the value of 'smm' which is the escape sequence '\E[?1034h'. 'km' means the terminal has a meta key which is a special key on MIT keyboards, 'smm' means turn on the meta key if this terminal has one. There are ** solutin to fix this issue: 1) Preserving TERM and unsetting TERM, or setting TERM with a terminal without 'smm' (such as terminal 'dumb'). This is the most common approach. https://bugzilla.redhat.com/show_bug.cgi?id=304181 http://bugs.python.org/issue11390 http://lists.gnu.org/archive/html/bug-readline/2013-06/msg00000.html But the effect is global even we don't import readline. 2) Modify readline.c in python, let readline use a term without 'smm' as default terminal (such as 'dumb'), it is similar to the above solution, but it localizes the effect in readline. 3) Modify terminfo.src in ncurses, let terminfo database doesn't contian 'smm', but the kinds of terms we supported is limited. 4) Modify terminal.c and readline.c in GNU Readline library to explicity disable meta key, or just comment out the outputing code. I prefer solution 2, because it has the least side effect. Explicitly use dumb as default terminal to avoid probably escape sequence output. The dumb is used to label tty lines when you don't know what kind of terminal is on it. The characteristics of an unknown terminal are the lowest common denominator. 34680 9 sgw 2013-07-18 17:17:39 +0000 Another option is for the nativesdk version to not hardcode include the readline library, since bitbake imports readline it will work correctly. Hardcoding the terminal to dumb would break the bitbake knotty interface. 34692 10 hongxu.jia 2013-07-19 08:08:31 +0000 How about to explicitly disable meta key in python readline module while readline initialization. Meta key is a special key on MIT keyboards such as the space-cadet keyboard, and on Sun Microsystems keyboards, marked as a solid diamond. It almost doesn't exist in our keyboards, so it has no side effect to disable it. 35138 11 hongxu.jia 2013-07-30 02:13:19 +0000 Merged into master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=fcfee5c46cdb8797cba0097994815d59157bac7c