[PATCH 0/1] runqemu: fix run from testimage with non-standard DEPLOY_DIR_IMAGE

[PATCH 0/1] runqemu: fix run from testimage with non-standard DEPLOY_DIR_IMAGE

[Joshua Lock]

Note: This patch is against master-next, as the Python 3 runqemu hasn't made it
to master yet.

This fixes a workflow where the contents of DEPLOY_DIR_IMAGE are copied to a
user-created directory which doesn't follow the standard OE naming of 
DEPLOY_DIR_IMAGE and then DEPLOY_DIR_IMAGE is set to point at that directory in
local.conf

Per the commit message it's possible that we don't want to try and check the
value a user uses for MACHINE and just let runqemu fail later, but this change
fixes the mentioned workflow without changing too much of the runqemu behaviour.


The following changes since commit 958c05bfa1009c57d8acc45ea0ed4b7f6f0d377a:

  maintainers.inc: rename gtk-doc-stub to gtk-doc, reassign to me (2016-09-08 17:05:37 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib joshuagl/runqemu
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=joshuagl/runqemu

Joshua Lock (1):
  runqemu: fix run from testimage with non-standard DEPLOY_DIR_IMAGE

 scripts/runqemu | 13 +++++++++++++
 1 file changed, 13 insertions(+)

-- 
2.7.4

[PATCH 1/1] runqemu: fix run from testimage with non-standard DEPLOY_DIR_IMAGE

[Joshua Lock]

testimage.bbclass uses runqemu to execute runtime tests on a qemu
target, this means that bitbake is already running and `bitbake -e`
can't be called to obtain bitbake variables.

runqemu tries to work around being unable to read values for
bitbake variables by inferring the MACHINE from the
DEPLOY_DIR_IMAGE setting, however if a user sets that variable in
a manner which doesn't follow the systems expectations (i.e. if
running `bitbake -c testimage` against a directory of pre-generated
images in a user-specified path) the inferring of the MACHINE name
from the DEPLOY_DIR_IMAGE location will fail.

It's possible that check_arg_machine() shouldn't cause runqemu to
fail and that runqemu should proceed with the user-supplied value
even if it can't be verified. This patch simply ensures that a
workflow where the user sets DEPLOY_DIR_IMAGE continues to work
without changing too much of the runqemu code.

[YOCTO #10238]

Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
---
 scripts/runqemu | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/scripts/runqemu b/scripts/runqemu
index 7919564..9af13f3 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -278,6 +278,19 @@ class BaseConfig(object):
         elif self.get('MACHINE') == arg:
             return
         logger.info('Assuming MACHINE = %s' % arg)
+
+        # if we're running under testimage, or similarly as a child
+        # of an existing bitbake invocation, we can't invoke bitbake
+        # to validate the MACHINE setting and must assume it's correct...
+        # FIXME: testimage.bbclass exports these two variables into env,
+        # are there other scenarios in which we need to support being
+        # invoked by bitbake?
+        deploy = os.environ.get('DEPLOY_DIR_IMAGE', None)
+        bbchild = deploy and os.environ.get('OE_TMPDIR', None)
+        if bbchild:
+            self.set_machine_deploy_dir(arg, deploy)
+            return
+
         cmd = 'MACHINE=%s bitbake -e' % arg
         logger.info('Running %s...' % cmd)
         self.bitbake_e = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE).stdout.read().decode('utf-8')
-- 
2.7.4