Skip to contentSkip to conversation

runqemu bugfix

PATCH In review Scott Garman 2 participants 4 messages Sep 14, 2012 – Sep 19, 2012

lore
Share & tools
lore
#0 lore raw

cover runqemu bugfix

Hello,

This is a fix for Yocto bug #3112, where there are certain edge cases where the bitbake command is avalable to fails to run. Previously we mistakenly treated that as the same case as if bitbake didn't exist in the user's $PATH, and this fix causes us to show the user the output of bitbake so they can view the error message.

Scott

The following changes since commit 7887b99646d8e1e736ad6e4a306e47df9955221e:

local.conf.sample: change valgrind support architecture comment (2012-09-14 17:05:59 +0100)

are available in the git repository at:

git://git.yoctoproject.org/poky-contrib sgarman/runqemu-bitbake-fix-oe
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=sgarman/runqemu-bitbake-fix-oe

Scott Garman (1):
runqemu: show bitbake errors to user

 scripts/runqemu |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)
Signature · 1 line
1.7.9.5
#1 lore raw

PATCH 1/1 runqemu: show bitbake errors to user

In certain edge cases, bitbake may fail to run and cause setup_tmpdir() within runqemu to fail, and not give the user a helpful error message. Catch this case and show the user the output of bitbake -e.

This fixes [YOCTO #3112]

---
 scripts/runqemu |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)
scripts/runqemu +10 -2
index e843946..8bb77ff 100755
@@ -283,8 +283,16 @@ setup_tmpdir() {
         # We have bitbake in PATH, get OE_TMPDIR from bitbake
         OE_TMPDIR=`MACHINE=$MACHINE bitbake -e | grep ^TMPDIR=\" | cut -d '=' -f2 | cut -d '"' -f2`
         if [ -z "$OE_TMPDIR" ]; then
-            echo "Error: this script needs to be run from your build directory,"
-            echo "or you need to explicitly set OE_TMPDIR in your environment"
+            # Check for errors from bitbake that the user needs to know about
+            BITBAKE_OUTPUT=`bitbake -e`
+            if [ -z "$BITBAKE_OUTPUT" ]; then
+                echo "Error: this script needs to be run from your build directory,"
+                echo "or you need to explicitly set OE_TMPDIR in your environment"
+            else
+                echo "There was an error running bitbake to determine TMPDIR"
+                echo "Here is the output from 'bitbake -e':"
+                bitbake -e
+            fi
             exit 1
         fi
     fi
Signature · 1 line
1.7.9.5
#2 lore raw

Re: [PATCH 1/1] runqemu: show bitbake errors to user

Quoted 16 lines · Scott Garman

In certain edge cases, bitbake may fail to run and cause setup_tmpdir() within runqemu to fail, and not give the user a helpful error message. Catch this case and show the user the output of bitbake -e.

This fixes [YOCTO #3112]

---
  scripts/runqemu |   12 ++++++++++--
  1 file changed, 10 insertions(+), 2 deletions(-)
scripts/runqemu +0 -0
index e843946..8bb77ff 100755

scripts/runqemu setup_tmpdir() { · line 287

Quoted 7 lines
scripts/runqemu +2 -2
@@ -283,8 +283,16 @@ setup_tmpdir() {
          # We have bitbake in PATH, get OE_TMPDIR from bitbake
          OE_TMPDIR=`MACHINE=$MACHINE bitbake -e | grep ^TMPDIR=\" | cut -d '=' -f2 | cut -d '"' -f2`
          if [ -z "$OE_TMPDIR" ]; then
-            echo "Error: this script needs to be run from your build directory,"
-            echo "or you need to explicitly set OE_TMPDIR in your environment"
+            # Check for errors from bitbake that the user needs to know about
+            BITBAKE_OUTPUT=`bitbake -e`

I'm not sure that is a good idea. If there is a failure (anything on stderr) it will just be dumped to the screen...

If it does succeed, it could attempt to load that variable with many MB of data, which also likely isn't what is desired.

It might be better to dump the items to a tmp file (securely created of course)
;) and then keep processing the same file for error messages, warnings, etc...

Quoted 12 lines
scripts/runqemu +8 -0
+            if [ -z "$BITBAKE_OUTPUT" ]; then
+                echo "Error: this script needs to be run from your build directory,"
+                echo "or you need to explicitly set OE_TMPDIR in your environment"
+            else
+                echo "There was an error running bitbake to determine TMPDIR"
+                echo "Here is the output from 'bitbake -e':"
+                bitbake -e
+            fi
              exit 1
          fi
      fi
#3 lore raw

Re: [PATCH 1/1] runqemu: show bitbake errors to user

Quoted 23 lines · Mark Hatle
Quoted 22 lines · Scott Garman

In certain edge cases, bitbake may fail to run and cause setup_tmpdir() within runqemu to fail, and not give the user a helpful error message. Catch this case and show the user the output of bitbake -e.

This fixes [YOCTO #3112]

---
  scripts/runqemu |   12 ++++++++++--
  1 file changed, 10 insertions(+), 2 deletions(-)
scripts/runqemu +0 -0
index e843946..8bb77ff 100755
@@ -283,8 +283,16 @@ setup_tmpdir() {
          # We have bitbake in PATH, get OE_TMPDIR from bitbake
          OE_TMPDIR=`MACHINE=$MACHINE bitbake -e | grep ^TMPDIR=\" |

cut -d '=' -f2 | cut -d '"' -f2`

          if [ -z "$OE_TMPDIR" ]; then

- echo "Error: this script needs to be run from your build
directory,"

Quoted 8 lines
Quoted 5 lines

- echo "or you need to explicitly set OE_TMPDIR in your
environment"
+ # Check for errors from bitbake that the user needs to
know about
+ BITBAKE_OUTPUT=bitbake -e

I'm not sure that is a good idea. If there is a failure (anything on stderr) it will just be dumped to the screen...

I'm afraid this is not the case with the error case I was testing this against. That case being when there is an LCONF_VERSION mismatch in bblayers.conf. Those user instructions are written to STDOUT.

Quoted 2 lines

If it does succeed, it could attempt to load that variable with many MB of data, which also likely isn't what is desired.

This is a valid point. I could change it to bitbake -e | wc -l, and check the number of lines of output. I'm basically just checking to see that this is greater than 0.

Quoted 3 lines

It might be better to dump the items to a tmp file (securely created of course) ;) and then keep processing the same file for error messages, warnings, etc...

This code path should only be run on very unusual edge cases, so I'm not inclined to add additional tmpfile handling complexity and have to deal with cleaning up the files, etc.

I will re-spin this patch with the wc -l modification.

Scott

Signature · 3 lines
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center