Using Poky 1.3 (danny) in a fresh environment (new project). On host machine A, set machine target in local.conf to "qemux86" and enable BB_GENERATE_MIRROR_TARBALLS so the downloaded sources can be shared. Run "bitbake -c menuconfig virtual/kernel" on host machine A. Kernel configuration terminal starts up without any issues. On host machine B, set machine target in local.conf to "qemux86" and SSTATE_MIRRORS/SOURCE_MIRROR_URL to utilize the sstate cache and downloaded sources saved on host machine A. Run "bitbake -c menuconfig virtual/kernel" on host machine B. Kernel configuration terminal terminates with the following error: scripts/kconfig/mconf Kconfig Error opening terminal: xterm. make[1]: *** [menuconfig] Error 1 make: *** [menuconfig] Error 2 Command failed. Press any key to continue...
Can you provide some additional details about machine A and machine B, what OS are they running are they both the same ARCH (x86 vs x86-64). Can you confirm xterm is available on machine B? Thanks
(In reply to comment #1) > Can you provide some additional details about machine A and machine B, what > OS are they running are they both the same ARCH (x86 vs x86-64). Can you > confirm xterm is available on machine B? Thanks Machine A: Ubuntu 12.04.1 LTS (x86) Machine B: Ubuntu 12.04.1 LTS (x86) "bitbake -c menuconfig virtual/kernel" brings up the kernel configuration terminal without any issues on host machine B when SSTATE_MIRRORS/SOURCE_MIRROR_URL aren't set in local.conf. Therefore, xterm is definitely available on machine B. Image builds are working fine on host machine B with SSTATE_MIRRORS/SOURCE_MIRROR_URL set in local.conf. So I can only assume that this is an issue specific to the menuconfig task when sstate cache and source mirrors are utilized.
I have a suspicion this issue was fixed by or at the very least related to http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=1a80329b3fcf23ecc23e409a260b9b2182652f65 Could you check and see if that change resolves the problem?
I believe this is fixed in master. 1.3 would need a backport of the change if we choose to fix this there though. Reassign to 1.3 maintainer. I'm assuming this patch does fix the problem, would be good to know either way. I'm assuming you're using different build paths on the two machines. It may even reproduce on a single machine with different build directories.
(In reply to comment #3) > I have a suspicion this issue was fixed by or at the very least related to > http://git.yoctoproject.org/cgit.cgi/poky/commit/ > ?id=1a80329b3fcf23ecc23e409a260b9b2182652f65 > > Could you check and see if that change resolves the problem? I can confirm this commit fixes the issue.
Merged to danny-next.
Wasn't actually merged! Is now merged to my branch.
It's merged into oe-core:danny now.