Skip to contentSkip to conversation

runqemu: fix run from testimage with non-standard DEPLOY_DIR_IMAGE

PATCH New Joshua Lock 1 participant 2 messages Sep 8, 2016

lore
Share & tools
lore
#0 lore raw

cover runqemu: fix run from testimage with non-standard DEPLOY_DIR_IMAGE

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(+)
Signature · 1 line
2.7.4
#1 lore raw

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

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]

---
 scripts/runqemu | 13 +++++++++++++
 1 file changed, 13 insertions(+)
scripts/runqemu +13 -0
index 7919564..9af13f3 100755
@@ -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')
Signature · 1 line
2.7.4