From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Humberto Ibarra <humberto.ibarra.lopez@intel.com>,
bitbake-devel@lists.openembedded.org
Subject: Re: [PATCH v3] bitbake/lib/bb/cookerdata.py: Improve response when bitbake-layers can't find layer conf file
Date: Thu, 12 May 2016 23:55:20 +0100 [thread overview]
Message-ID: <1463093720.9746.57.camel@linuxfoundation.org> (raw)
In-Reply-To: <1463080671-27074-1-git-send-email-humberto.ibarra.lopez@intel.com>
On Thu, 2016-05-12 at 14:17 -0500, Humberto Ibarra wrote:
> If an invalid layer is added to bblayers.conf, the parsing of said
> file
> ends with a trace and an "Unable to parse" exception. This is not the
> ideal output, especially considering that we know exactly why this is
> failing.
>
> This patch handles this situation failing with a graceful error
> message. The
> message shows the path to the conf file that couldn't be found.
>
> [Yocto #9506]
>
> Signed-off-by: Humberto Ibarra <humberto.ibarra.lopez@intel.com>
> ---
> bitbake/lib/bb/cookerdata.py | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/bitbake/lib/bb/cookerdata.py
> b/bitbake/lib/bb/cookerdata.py
> index 50259a9..a1b0457 100644
> --- a/bitbake/lib/bb/cookerdata.py
> +++ b/bitbake/lib/bb/cookerdata.py
> @@ -178,9 +178,13 @@ def catch_parse_error(func):
> try:
> return func(fn, *args)
> except IOError as exc:
> - import traceback
> - parselog.critical(traceback.format_exc())
> - parselog.critical("Unable to parse %s: %s" % (fn, exc))
> + import errno
> + if exc.errno == errno.ENOENT:
> + parselog.critical("Unable to find the configuration
> file: %s" % fn)
> + else:
> + import traceback
> + parselog.critical(traceback.format_exc())
> + parselog.critical("Unable to parse %s: %s" % (fn,
> exc))
> sys.exit(1)
> except bb.data_smart.ExpansionError as exc:
> import traceback
I think I'm not going to take this patch. My concern is that we have a
number of places where we'd have this problem and adding in specific
exception handling in all of them is going to be tricky.
I do agree we need to solve the problem and started to wonder if we
could make the standard exception more useful. I then realised that in
python3, they already did. If I try this under python3, I see:
FileNotFoundError: [Errno 2] file /foo/bar/conf/layer.conf not found
ERROR: Unable to parse /foo/bar/conf/layer.conf: [Errno 2] file /foo/bar/conf/layer.conf not found
So with python3, we get better exceptions for free with no code changes.
Can we therefore say this will be fixed with the move to python3?
It would be good to double check as I just tested this with bitbake and
bitbake-layers hasn't been ported to python3 yet but I'd imagine its
the same.
Cheers,
Richard
next prev parent reply other threads:[~2016-05-12 22:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-12 19:17 [PATCH v3] bitbake/lib/bb/cookerdata.py: Improve response when bitbake-layers can't find layer conf file Humberto Ibarra
2016-05-12 22:55 ` Richard Purdie [this message]
2016-05-12 23:10 ` Richard Purdie
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=1463093720.9746.57.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=bitbake-devel@lists.openembedded.org \
--cc=humberto.ibarra.lopez@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.