A flaw was found on my Ubuntu 14.04.5 LTS, on which that gnome-terminal is the default terminal, when I run any of the tasks: bitbake busybox -c menuconfig/devshell/devpyshell bitbake virtual/kernel -c menuconfig/devshell/devpyshell I got a error as follows: "Failed to execute child process "oe-gnome-terminal-phonehome" (No such file or directory)" Seems the environment of the process calling Popen is not passed to the child process, this behaviour is a known issue in Python bug tracker: http://bugs.python.org/issue8557 I think it could be fixed by using an absolute path instead.
Patch sent to ML: http://lists.openembedded.org/pipermail/openembedded-core/2016-August/125276.html
Ming, Richard wants to know why this would be broken on 14.04 but not on 16.04 which he uses. Can you explain that? Also, no one else is reporting this bug so we're a little suspicious that it's a valid bug and not a problem limited to your system. Can anyone else reproduce this bug?
Just did a quick search in OE mail list, seems I am not the only one seeing this problem, Slater Joseph also had reported a similar one: http://lists.openembedded.org/pipermail/openembedded-core/2016-July/124215.html I have not managed to test it on other machines except my Ubuntu 14.04, but I have done a python3 test, like the follows: ...... peter-liu@peterliu-Precision-M4800:~/$ virtualenv /tmp/zzz New python executable in /tmp/zzz/bin/python Installing setuptools, pip...done. peter-liu@peterliu-Precision-M4800:~/$ python3 Python 3.4.3 (default, Oct 14 2015, 20:28:29) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from subprocess import * >>> p = Popen(['python', '-c', 'import sys;print(sys.executable)'], shell=True, stdin=PIPE,stdout=PIPE,stderr=PIPE, env={'PATH':'/tmp/zzz/bin'}) >>> stdout,stderr = p.communicate(None) >>> print(stdout) b'' >>> print(stderr) b'' >>> p = Popen(['python', '-c', 'import sys;print(sys.executable)'], stdin=PIPE,stdout=PIPE,stderr=PIPE, env={'PATH':'/tmp/zzz/bin'}) >>> stdout,stderr = p.communicate(None) >>> print(stdout) b'/tmp/zzz/bin/python\n' >>> print(stderr) b'' >>> ...... So seems python would not pass environment to subprocess executes if shell=True is set? I think my patch is kinda shoring up the oe terminal class to fit all hosts settings, and harmless, am I right?
Probably worth checking if this occurs on a fresh Ubuntu 14.04 install as well.
Many people at our site are seeing this error. We've applied Ming's fix and it works for us. I'm not sure why some users see it and some don't. On my Ubuntu 14.04.5 LTS install I don't see the issue but several other people do. Has this been accepted or is more verification needed to accept the fix?
I use Ubuntu 14.04 in a container, everything works fine for me. Can you please try the following? $ which oe-gnome-terminal-phonehome On my system oe-gnome-terminal-phonehome is found: /workdir/poky/scripts/oe-gnome-terminal-phonehome BTW, are you using "poky"? What is the output of your $PATH?
Yes we're using poky. $ which oe-gnome-terminal-phonehome /home/jonathar/work/yocto/project/poky/scripts/oe-gnome-terminal-phonehome $ echo $PATH /home/jonathar/work/yocto/project/poky/scripts:/home/jonathar/work/yocto/project/poky/bitbake/bin:/home/jonathar/bin:/home/jonathar/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
I also stumbled upon this bug. I have a fresh installation of Ubuntu 14.04.5 LTS. Mings solution worked for me. pschenker@yocto-vm:~/yocto/poky/build$ echo $PATH /home/pschenker/yocto/poky/scripts:/home/pschenker/yocto/poky/bitbake/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/jvm/java-8-oracle/bin:/usr/lib/jvm/java-8-oracle/db/bin:/usr/lib/jvm/java-8-oracle/jre/bin pschenker@yocto-vm:~/yocto/poky/build$ which oe-gnome-terminal-phonehome /home/pschenker/yocto/poky/scripts/oe-gnome-terminal-phonehome pschenker@yocto-vm:~/yocto/poky/build$ python --version Python 2.7.6
I'm not getting to this defect so I've assigned it to Kai. Once we get the 2.4 release out the door in a week or two, can you take the attached patch and get it into master, then backported to 2.4/2.3 please? If anyone else wants to send the attached patch to the oe-core list, please go ahead and just make note of that here.
(In reply to comment #9) > I'm not getting to this defect so I've assigned it to Kai. > Once we get the 2.4 release out the door in a week or two, can you take the > attached patch and get it into master, then backported to 2.4/2.3 please? If > anyone else wants to send the attached patch to the oe-core list, please go > ahead and just make note of that here. Got it. I'll do it right after 2.4 release.
Ming Liu will take over this defect.
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=c6987478313b12cbd174c816bc07cf27f727f091