die if a .bbappend file matches no existing .bb recipe
cover die if a .bbappend file matches no existing .bb recipe
Please review the patch.
The following changes since commit 2152759b50cc3acc96ee57b242e0b896e65f5e93:
sanity.bbclass: only run check_pseudo_wrapper for bitbake (2011-06-19 19:50:46 +0800)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib dcui/bb
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/bb
Dexuan Cui (1):
die if a .bbappend file matches no existing .bb recipe
bitbake/bin/bitbake-layers | 19 ------------------- bitbake/lib/bb/cooker.py | 16 ++++++++++++++++ 2 files changed, 16 insertions(+), 19 deletions(-)
PATCH 1/1 die if a .bbappend file matches no existing .bb recipe
This patch moves the logic of show_appends_with_no_recipes from bitbake-layers into bitbake, and makes the script die with a fatal error message printed.
--- bitbake/bin/bitbake-layers | 19 ------------------- bitbake/lib/bb/cooker.py | 16 ++++++++++++++++ 2 files changed, 16 insertions(+), 19 deletions(-)
bitbake/bin/bitbake-layers +0 -19
@@ -85,8 +85,6 @@ class Commands(cmd.Cmd): self.show_appends_for_skipped() - self.show_appends_with_no_recipes() - def show_appends_for_pn(self, pn): filenames = self.cooker_data.pkg_pn[pn]
@@ -133,23 +131,6 @@ class Commands(cmd.Cmd): notappended.add(basename) return appended, notappended - def show_appends_with_no_recipes(self): - recipes = set(os.path.basename(f) - for f in self.cooker_data.pkg_fn.iterkeys()) - recipes |= set(os.path.basename(f) - for f in self.cooker.skiplist.iterkeys()) - appended_recipes = self.cooker_data.appends.iterkeys() - appends_without_recipes = [self.cooker_data.appends[recipe] - for recipe in appended_recipes - if recipe not in recipes] - if appends_without_recipes: - appendlines = (' %s' % append - for appends in appends_without_recipes - for append in appends) - logger.warn('No recipes available for:\n%s', - '\n'.join(appendlines)) - self.returncode |= 4 - def do_EOF(self, line): return True
bitbake/lib/bb/cooker.py +16 -0
@@ -471,6 +471,21 @@ class BBCooker: return pri return 0 + def die_if_any_appends_with_no_recipes( self ): + recipes = set(os.path.basename(f) + for f in self.status.pkg_fn.iterkeys()) + recipes |= set(os.path.basename(f) + for f in self.skiplist.iterkeys()) + appended_recipes = self.appendlist.iterkeys() + appends_without_recipes = [self.appendlist[recipe] + for recipe in appended_recipes + if recipe not in recipes] + if appends_without_recipes: + appendlines = (' %s' % append + for appends in appends_without_recipes + for append in appends) + bb.fatal('No recipes available for:\n%s' % '\n'.join(appendlines)) + def buildDepgraph( self ): all_depends = self.status.all_depends pn_provides = self.status.pn_provides
@@ -940,6 +955,7 @@ class BBCooker: if not self.parser.parse_next(): collectlog.debug(1, "parsing complete") + self.die_if_any_appends_with_no_recipes() self.buildDepgraph() self.state = state.running return None
Signature · 1 line
1.7.1
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 14 lines · Martin Jansa
Quoted 3 lines · Dexuan Cui
This patch moves the logic of
show_appends_with_no_recipesfrom bitbake-layers into bitbake, and makes the script die with a fatal error message printed.I agree that this is problem, but I'm not sure if it should be fatal.
Imagine the case when you enable some layer managed by someone else (lets call it LS) and you're using different oe-core revision, maybe current HEAD and that LS wasn't updated for that or vice versa you're using some oe-core release version and you want to reuse some recipes from LS in current version.
Quoted 8 lines
I think that big fat warning that some .bbappends does not match should be enough to decide if it's fatal for me (and I'll kill that build) or that's fine (when I'm not interested in those .bbappends from LS and I'm using only some other .bb files from LS).
If we make it fatal then I would be forced to remove unmatched .bbappends from LS before build which can be difficult to share (unless I create own LS branch and use it in my distro).
Thanks a lot for the explanation!
So looks we may as well change the "bb.fatal" to "bb.error"(that is not fatal and wouldn't be ignored by bitbake-layers). This is the new patch (on a new branch dcui/bb-v2):
http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a
Thanks,
-- Dexuan
Quoted 20 lines · Dexuan
Quoted 19 lines · Martin Jansa
Quoted 3 lines · Dexuan Cui
This patch moves the logic of
show_appends_with_no_recipesfrom bitbake-layers into bitbake, and makes the script die with a fatal error message printed.I agree that this is problem, but I'm not sure if it should be fatal.
Imagine the case when you enable some layer managed by someone else (lets call it LS) and you're using different oe-core revision, maybe current HEAD and that LS wasn't updated for that or vice versa you're using some oe-core release version and you want to reuse some recipes from LS in current version.
I think that big fat warning that some .bbappends does not match should be enough to decide if it's fatal for me (and I'll kill that build) or that's fine (when I'm not interested in those .bbappends from LS and I'm using only some other .bb files from LS).
Quoted 8 lines
Quoted 3 lines
If we make it fatal then I would be forced to remove unmatched .bbappends from LS before build which can be difficult to share (unless I create own LS branch and use it in my distro).
Thanks a lot for the explanation!
So looks we may as well change the "bb.fatal" to "bb.error"(that is not fatal and wouldn't be ignored by bitbake-layers). This is the new patch (on a new branch dcui/bb-v2):
http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a
Are you sure this shouldn't be a warning? Remember that any error displayed results in a non-zero exit code from bitbake.
Signature · 5 lines
Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
Quoted 24 lines · Chris Larson
Quoted 23 lines · Dexuan
Quoted 22 lines · Martin Jansa
Quoted 3 lines · Dexuan Cui
This patch moves the logic of
show_appends_with_no_recipesfrom bitbake-layers into bitbake, and makes the script die with a fatal error message printed.I agree that this is problem, but I'm not sure if it should be fatal.
Imagine the case when you enable some layer managed by someone else (lets call it LS) and you're using different oe-core revision, maybe current HEAD and that LS wasn't updated for that or vice versa you're using some oe-core release version and you want to reuse some recipes from LS in current version.
I think that big fat warning that some .bbappends does not match should be enough to decide if it's fatal for me (and I'll kill that build) or that's fine (when I'm not interested in those .bbappends from LS and I'm using only some other .bb files from LS).
If we make it fatal then I would be forced to remove unmatched .bbappends from LS before build which can be difficult to share (unless I create own LS branch and use it in my distro).
Quoted 8 lines
Quoted 5 lines
Thanks a lot for the explanation!
So looks we may as well change the "bb.fatal" to "bb.error"(that is not fatal and wouldn't be ignored by bitbake-layers).
This is the new patch (on a new branch dcui/bb-v2):
http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1aAre you sure this shouldn't be a warning? Remember that any error displayed results in a non-zero exit code from bitbake.
So, speaking of which - what is the practical use for bb.error? It gives an error message, but doesn't stop the build. Although it returns a non-zero exit code, which for most autobuilders indicate a failed build anyway... What's the point?
Signature · 1 line
Denys
Quoted 31 lines · Denys Dmytriyenko
Quoted 30 lines · Chris Larson
Quoted 28 lines · Dexuan
Quoted 14 lines · Martin Jansa
Quoted 3 lines · Dexuan Cui
This patch moves the logic of
show_appends_with_no_recipesfrom bitbake-layers into bitbake, and makes the script die with a fatal error message printed.I agree that this is problem, but I'm not sure if it should be fatal.
Imagine the case when you enable some layer managed by someone else (lets call it LS) and you're using different oe-core revision, maybe current HEAD and that LS wasn't updated for that or vice versa you're using some oe-core release version and you want to reuse some recipes from LS in current version.
Quoted 8 lines
I think that big fat warning that some .bbappends does not match should be enough to decide if it's fatal for me (and I'll kill that build) or that's fine (when I'm not interested in those .bbappends from LS and I'm using only some other .bb files from LS).
If we make it fatal then I would be forced to remove unmatched .bbappends from LS before build which can be difficult to share (unless I create own LS branch and use it in my distro).
Thanks a lot for the explanation!
So looks we may as well change the "bb.fatal" to "bb.error"(that is not fatal and wouldn't be ignored by bitbake-layers).
This is the new patch (on a new branch dcui/bb-v2):
http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a
Quoted 7 lines
Quoted 2 lines
Are you sure this shouldn't be a warning? Remember that any error displayed results in a non-zero exit code from bitbake.
So, speaking of which - what is the practical use for bb.error? It gives an error message, but doesn't stop the build. Although it returns a non-zero exit code, which for most autobuilders indicate a failed build anyway... What's the point?
It denotes something which the user really needs to know about and fix. The sanity tests are good example and I'd really like to see sanity issues becoming bb.errors in most cases.
You can also think about it as being a point on the error severity scale:
Note: Information only
Warning: Something happened which the user likely needs to fix
Error: Something happened the user is strongly recommended to fix - set
exit code accordingly.
Fatal: Something bad happened and there is no hope so stop.
I think in the scheme of different error priorities and actions, it makes sense...
Cheers,
Richard
Quoted 47 lines · Richard Purdie
Quoted 31 lines · Denys Dmytriyenko
Quoted 30 lines · Chris Larson
Quoted 28 lines · Dexuan
Quoted 14 lines · Martin Jansa
Quoted 3 lines · Dexuan Cui
This patch moves the logic of
show_appends_with_no_recipesfrom bitbake-layers into bitbake, and makes the script die with a fatal error message printed.I agree that this is problem, but I'm not sure if it should be fatal.
Imagine the case when you enable some layer managed by someone else (lets call it LS) and you're using different oe-core revision, maybe current HEAD and that LS wasn't updated for that or vice versa you're using some oe-core release version and you want to reuse some recipes from LS in current version.
Quoted 8 lines
I think that big fat warning that some .bbappends does not match should be enough to decide if it's fatal for me (and I'll kill that build) or that's fine (when I'm not interested in those .bbappends from LS and I'm using only some other .bb files from LS).
If we make it fatal then I would be forced to remove unmatched .bbappends from LS before build which can be difficult to share (unless I create own LS branch and use it in my distro).
Thanks a lot for the explanation!
So looks we may as well change the "bb.fatal" to "bb.error"(that is not fatal and wouldn't be ignored by bitbake-layers).
This is the new patch (on a new branch dcui/bb-v2):
http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1aQuoted 7 lines
Quoted 2 lines
Are you sure this shouldn't be a warning? Remember that any error displayed results in a non-zero exit code from bitbake.
So, speaking of which - what is the practical use for bb.error? It gives an error message, but doesn't stop the build. Although it returns a non-zero exit code, which for most autobuilders indicate a failed build anyway... What's the point?
It denotes something which the user really needs to know about and fix. The sanity tests are good example and I'd really like to see sanity issues becoming bb.errors in most cases.
You can also think about it as being a point on the error severity scale:
Quoted 8 lines
Note: Information only
Warning: Something happened which the user likely needs to fix
Error: Something happened the user is strongly recommended to fix - set exit code accordingly.
Fatal: Something bad happened and there is no hope so stop.I think in the scheme of different error priorities and actions, it makes sense...
I really don't think they're very useful right now. If our UIs actually captured the errors and summarized them at the end of the build, as well as had them in a global log, then I could see them being of use, but having an error message that might have scrolled past an hour ago result in a non-zero exit code is far from ideal. As a user, I have no idea why it seems to have failed.
Signature · 5 lines
Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
Quoted 61 lines · Chris Larson
Quoted 50 lines · Richard Purdie
Quoted 34 lines · Denys Dmytriyenko
Quoted 33 lines · Chris Larson
Quoted 30 lines · Dexuan
Quoted 21 lines · Martin Jansa
Quoted 3 lines · Dexuan Cui
This patch moves the logic of
show_appends_with_no_recipesfrom bitbake-layers into bitbake, and makes the script die with a fatal error message printed.I agree that this is problem, but I'm not sure if it should be fatal.
Imagine the case when you enable some layer managed by someone else (lets call it LS) and you're using different oe-core revision, maybe current HEAD and that LS wasn't updated for that or vice versa you're using some oe-core release version and you want to reuse some recipes from LS in current version.
I think that big fat warning that some .bbappends does not match should be enough to decide if it's fatal for me (and I'll kill that build) or that's fine (when I'm not interested in those .bbappends from LS and I'm using only some other .bb files from LS).
Quoted 3 lines
If we make it fatal then I would be forced to remove unmatched .bbappends from LS before build which can be difficult to share (unless I create own LS branch and use it in my distro).
Thanks a lot for the explanation!
So looks we may as well change the "bb.fatal" to "bb.error"(that is not fatal and wouldn't be ignored by bitbake-layers). This is the new patch (on a new branch dcui/bb-v2):
http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1aQuoted 7 lines
Quoted 2 lines
Are you sure this shouldn't be a warning? Remember that any error displayed results in a non-zero exit code from bitbake.
So, speaking of which - what is the practical use for bb.error? It gives an error message, but doesn't stop the build. Although it returns a non-zero exit code, which for most autobuilders indicate a failed build anyway... What's the point?
It denotes something which the user really needs to know about and fix. The sanity tests are good example and I'd really like to see sanity issues becoming bb.errors in most cases.
You can also think about it as being a point on the error severity scale:
Quoted 8 lines
Note: Information only
Warning: Something happened which the user likely needs to fix
Error: Something happened the user is strongly recommended to fix - set exit code accordingly. Fatal: Something bad happened and there is no hope so stop.I think in the scheme of different error priorities and actions, it makes sense...
Quoted 6 lines
I really don't think they're very useful right now. If our UIs actually captured the errors and summarized them at the end of the build, as well as had them in a global log, then I could see them being of use, but having an error message that might have scrolled past an hour ago result in a non-zero exit code is far from ideal. As a user, I have no idea why it seems to have failed.
I noticed in poky bb.error() doesn't cause bitbake to return a non-zero exit code.
Thanks,
-- Dexuan
Quoted 58 lines · Chris Larson
Quoted 47 lines · Richard Purdie
Quoted 31 lines · Denys Dmytriyenko
Quoted 30 lines · Chris Larson
Quoted 28 lines · Dexuan
Quoted 14 lines · Martin Jansa
Quoted 3 lines · Dexuan Cui
This patch moves the logic of
show_appends_with_no_recipesfrom bitbake-layers into bitbake, and makes the script die with a fatal error message printed.I agree that this is problem, but I'm not sure if it should be fatal.
Imagine the case when you enable some layer managed by someone else (lets call it LS) and you're using different oe-core revision, maybe current HEAD and that LS wasn't updated for that or vice versa you're using some oe-core release version and you want to reuse some recipes from LS in current version.
Quoted 8 lines
I think that big fat warning that some .bbappends does not match should be enough to decide if it's fatal for me (and I'll kill that build) or that's fine (when I'm not interested in those .bbappends from LS and I'm using only some other .bb files from LS).
If we make it fatal then I would be forced to remove unmatched .bbappends from LS before build which can be difficult to share (unless I create own LS branch and use it in my distro).
Thanks a lot for the explanation!
So looks we may as well change the "bb.fatal" to "bb.error"(that is not fatal and wouldn't be ignored by bitbake-layers).
This is the new patch (on a new branch dcui/bb-v2):
http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1aQuoted 7 lines
Quoted 2 lines
Are you sure this shouldn't be a warning? Remember that any error displayed results in a non-zero exit code from bitbake.
So, speaking of which - what is the practical use for bb.error? It gives an error message, but doesn't stop the build. Although it returns a non-zero exit code, which for most autobuilders indicate a failed build anyway... What's the point?
It denotes something which the user really needs to know about and fix. The sanity tests are good example and I'd really like to see sanity issues becoming bb.errors in most cases.
You can also think about it as being a point on the error severity scale:
Quoted 8 lines
Note: Information only
Warning: Something happened which the user likely needs to fix
Error: Something happened the user is strongly recommended to fix - set
exit code accordingly.
Fatal: Something bad happened and there is no hope so stop.I think in the scheme of different error priorities and actions, it makes sense...
Quoted 6 lines
I really don't think they're very useful right now. If our UIs actually captured the errors and summarized them at the end of the build, as well as had them in a global log, then I could see them being of use, but having an error message that might have scrolled past an hour ago result in a non-zero exit code is far from ideal. As a user, I have no idea why it seems to have failed.
Well, patches to improve the UIs in the regard are welcome. At least at this point we can do this kind of thing at the UI level which is way better than the situation used to be.
I'd also argue its better to have any indication there was a problem than none at all...
Cheers,
Richard
Quoted 6 lines · Martin Jansa
Imagine the case when you enable some layer managed by someone else (lets call it LS) and you're using different oe-core revision, maybe current HEAD and that LS wasn't updated for that or vice versa you're using some oe-core release version and you want to reuse some recipes from LS in current version.
Quoted 8 lines
I think that big fat warning that some .bbappends does not match should be enough to decide if it's fatal for me (and I'll kill that build) or that's fine (when I'm not interested in those .bbappends from LS and I'm using only some other .bb files from LS).
If we make it fatal then I would be forced to remove unmatched .bbappends from LS before build which can be difficult to share (unless I create own LS branch and use it in my distro).
I see what you're saying, but I'm worried about the visiblity (or lack thereof) of these warnings. If you start a build, go off somewhere and come back when the build is part way through or finished, you may be oblivious to the fact that there might be a serious problem - i.e. the customisations you expected to be applied haven't been.
It all depends on whether the bbappends are supposed to apply to recipes that are to be used in the build you're doing - if they are, then IMHO the error should be fatal. I wonder if it's practical to make it work that way...?
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 22 lines · Paul Eggleton
Quoted 6 lines · Martin Jansa
Imagine the case when you enable some layer managed by someone else (lets call it LS) and you're using different oe-core revision, maybe current HEAD and that LS wasn't updated for that or vice versa you're using some oe-core release version and you want to reuse some recipes from LS in current version.
Quoted 8 lines
I think that big fat warning that some .bbappends does not match should be enough to decide if it's fatal for me (and I'll kill that build) or that's fine (when I'm not interested in those .bbappends from LS and I'm using only some other .bb files from LS).
If we make it fatal then I would be forced to remove unmatched .bbappends from LS before build which can be difficult to share (unless I create own LS branch and use it in my distro).
I see what you're saying, but I'm worried about the visiblity (or lack thereof) of these warnings. If you start a build, go off somewhere and come back when the build is part way through or finished, you may be oblivious to the fact that there might be a serious problem - i.e. the customisations you expected to be applied haven't been.
Quoted 3 lines
It all depends on whether the bbappends are supposed to apply to recipes that are to be used in the build you're doing - if they are, then IMHO the error should be fatal. I wonder if it's practical to make it work that way...?
I think it should be fatal by default but have some kind of variable we can set to disable it...
Cheers,
Richard
Quoted 24 lines · Richard Purdie
Quoted 23 lines · Paul Eggleton
Quoted 6 lines · Martin Jansa
Imagine the case when you enable some layer managed by someone else (lets call it LS) and you're using different oe-core revision, maybe current HEAD and that LS wasn't updated for that or vice versa you're using some oe-core release version and you want to reuse some recipes from LS in current version.
Quoted 8 lines
I think that big fat warning that some .bbappends does not match should be enough to decide if it's fatal for me (and I'll kill that build) or that's fine (when I'm not interested in those .bbappends from LS and I'm using only some other .bb files from LS).
If we make it fatal then I would be forced to remove unmatched .bbappends from LS before build which can be difficult to share (unless I create own LS branch and use it in my distro).
I see what you're saying, but I'm worried about the visiblity (or lack thereof) of these warnings. If you start a build, go off somewhere and come back when the build is part way through or finished, you may be oblivious to the fact that there might be a serious problem - i.e. the customisations you expected to be applied haven't been.
Quoted 7 lines
Quoted 4 lines
It all depends on whether the bbappends are supposed to apply to recipes that are to be used in the build you're doing - if they are, then IMHO the error should be fatal. I wonder if it's practical to make it work that way...?
I think it should be fatal by default but have some kind of variable we can set to disable it...
Sorry -- what's the conclusion?
Keeping the v2 patch(http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a), or changing bb.error() to bb.warn()?
Thanks,
-- Dexuan
Quoted 4 lines · Dexuan
Sorry -- what's the conclusion?
Keeping the v2 patch
(http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a)
, or changingbb.error()tobb.warn()?
Where you have:
bb.error('No recipes available for:\n%s' % '\n'.join(appendlines))
this would become something like:
msg = 'No recipes available for:\n%s' % '\n'.join(appendlines) if d.getVar("BB_DANGLINGAPPENDS_WARNONLY", False):
bb.warn(msg)
else:
bb.fatal(msg)
which means we can have a strong default but advanced users/distros/whoever can avoid this.
Cheers,
Richard
Quoted 12 lines · Richard Purdie
Quoted 4 lines · Dexuan
Sorry -- what's the conclusion?
Keeping the v2 patch
(http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a)
, or changingbb.error()tobb.warn()?Where you have:
bb.error('No recipes available for:\n%s' % '\n'.join(appendlines))this would become something like:
Quoted 8 lines
msg = 'No recipes available for:\n%s' % '\n'.join(appendlines) if
d.getVar("BB_DANGLINGAPPENDS_WARNONLY", False):
bb.warn(msg)
else:
bb.fatal(msg)which means we can have a strong default but advanced users/distros/whoever can avoid this.
Hi Richard, thanks very much for the explanation!
I'll make and test a new version like this.
Thanks,
-- Dexuan
Quoted 12 lines · Richard Purdie
Quoted 4 lines · Dexuan
Sorry -- what's the conclusion?
Keeping the v2 patch
(http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a)
, or changingbb.error()tobb.warn()?Where you have:
bb.error('No recipes available for:\n%s' % '\n'.join(appendlines))this would become something like:
Quoted 8 lines
msg = 'No recipes available for:\n%s' % '\n'.join(appendlines) if
d.getVar("BB_DANGLINGAPPENDS_WARNONLY", False):
bb.warn(msg)
else:
bb.fatal(msg)which means we can have a strong default but advanced users/distros/whoever can avoid this.
Thanks! That's a nice compromise.
Signature · 1 line
Denys
Quoted 19 lines · Denys Dmytriyenko
Quoted 18 lines · Richard Purdie
Quoted 4 lines · Dexuan
Sorry -- what's the conclusion?
Keeping the v2 patch
(http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=dcui/bb-v2&id=2a520959f71ec2cd80ed2088bfcf082631161a1a)
, or changingbb.error()tobb.warn()?Where you have:
bb.error('No recipes available for:\n%s' % '\n'.join(appendlines))this would become something like:
msg = 'No recipes available for:\n%s' % '\n'.join(appendlines) if
d.getVar("BB_DANGLINGAPPENDS_WARNONLY", False):
bb.warn(msg)
else:
bb.fatal(msg)
Quoted 4 lines
Quoted 2 lines
which means we can have a strong default but advanced users/distros/whoever can avoid this.
Thanks! That's a nice compromise.
Agreed, looks good to me.
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]