From: Scott Garman <scott.a.garman@intel.com>
To: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/1] runqemu: show bitbake errors to user
Date: Tue, 18 Sep 2012 22:35:04 -0700 [thread overview]
Message-ID: <50595988.5080901@intel.com> (raw)
In-Reply-To: <5053BBD6.6000202@windriver.com>
On 09/14/2012 04:20 PM, Mark Hatle wrote:
> On 9/14/12 6:15 PM, Scott Garman wrote:
>> 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]
>>
>> Signed-off-by: Scott Garman <scott.a.garman@intel.com>
>> ---
>> scripts/runqemu | 12 ++++++++++--
>> 1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/scripts/runqemu b/scripts/runqemu
>> index e843946..8bb77ff 100755
>> --- a/scripts/runqemu
>> +++ b/scripts/runqemu
>> @@ -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...
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.
> 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.
> 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
--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
next prev parent reply other threads:[~2012-09-19 5:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-14 23:15 [PATCH 0/1] runqemu bugfix Scott Garman
2012-09-14 23:15 ` [PATCH 1/1] runqemu: show bitbake errors to user Scott Garman
2012-09-14 23:20 ` Mark Hatle
2012-09-19 5:35 ` Scott Garman [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-09-19 5:50 [PATCH 0/1] runqemu bugfix [v2] Scott Garman
2012-09-19 5:50 ` [PATCH 1/1] runqemu: show bitbake errors to user Scott Garman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50595988.5080901@intel.com \
--to=scott.a.garman@intel.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox