Re: [OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack
On 3 April 2015 at 15:13, Cristian Iorga wrote: > -# Define a variable that expands to the recipe (package) providing core > -# bluetooth support on the platform: > +# Define a variable that expands to the recipe (package) providing > +# core bluetooth support on the platform: > # "" if bluetooth is not in DISTRO_FEATURES > -# else "bluez5" if bluez5 is in DISTRO_FEATURES > -# else "bluez4" > +# else "bluez4" if bluez4 is in DISTRO_FEATURES > +# else "bluez5" > That wasn't the behaviour that 1.8 sets. We think we should continue to respect the bluez5 DISTRO_FEATURE and add it to DISTRO_FEATURES_BACKFILL. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [wic][PATCH] wic: extended list of paths in find_binary_path
On 04/04/2015 10:20 AM, Ed Bartosh wrote:
> wic requires tools that are not always possible to find in $PATH.
> This causes wic to fail with confusing errors like this:
> External command 'parted' not found, exiting.
>(Please install 'parted' on your host system)
>
> Adding ~/bin/, /usr/local/sbin, /usr/local/bin, /usr/sbin, /usr/bin,
> /sbin and /bin to the list of paths makes find_binary_path to
> produce more reliable results.
I'm with Otavio. Given wic is intimately dependent on internal build
artifacts, it should use utilities from the sysroot and not depend on
tools from the path. Let's make wic 100% before creating a tool to build
images from packages.
Philip
>
> [YOCTO #7122]
>
> Signed-off-by: Ed Bartosh
> ---
> scripts/lib/wic/utils/fs_related.py | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/scripts/lib/wic/utils/fs_related.py
> b/scripts/lib/wic/utils/fs_related.py
> index ea9f85c..832a44a 100644
> --- a/scripts/lib/wic/utils/fs_related.py
> +++ b/scripts/lib/wic/utils/fs_related.py
> @@ -32,13 +32,16 @@ from wic.utils.errors import *
> from wic.utils.oe.misc import *
>
> def find_binary_path(binary):
> +paths = []
> if os.environ.has_key("PATH"):
> paths = os.environ["PATH"].split(":")
> -else:
> -paths = []
> -if os.environ.has_key("HOME"):
> -paths += [os.environ["HOME"] + "/bin"]
> -paths += ["/usr/local/sbin", "/usr/local/bin", "/usr/sbin",
> "/usr/bin", "/sbin", "/bin"]
> +if os.environ.has_key("HOME"):
> +path = os.path.join(os.environ["HOME"], "bin")
> +if path not in paths:
> +paths.append(path)
> +for path in ["/usr/local/sbin", "/usr/local/bin", "/usr/sbin",
> "/usr/bin", "/sbin", "/bin"]:
> +if path not in paths:
> +paths.append(path)
>
> for path in paths:
> bin_path = "%s/%s" % (path, binary)
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [wic][PATCH] wic: extended list of paths in find_binary_path
On 04/04/2015 02:34 PM, Ed Bartosh wrote: > On Sat, Apr 04, 2015 at 03:34:59PM -0300, Otavio Salvador wrote: >> Em 04/04/2015 14:21, "Ed Bartosh" escreveu: >>> >>> wic requires tools that are not always possible to find in $PATH. >>> This causes wic to fail with confusing errors like this: >>> External command 'parted' not found, exiting. >>>(Please install 'parted' on your host system) >>> >>> Adding ~/bin/, /usr/local/sbin, /usr/local/bin, /usr/sbin, /usr/bin, >>> /sbin and /bin to the list of paths makes find_binary_path to >>> produce more reliable results. >>> >>> [YOCTO #7122] >>> >>> Signed-off-by: Ed Bartosh >> >> I think we shouldn't do that. If user wants something to be found the PATH >> environment variable should have them included. >> > Some users think that this is confusing: > https://bugzilla.yoctoproject.org/show_bug.cgi?id=7122 > For current implementation of wic it practically means that it must be always > run as "PATH=/usr/sbin:$PATH wic" on OpenSUSE systems. > >> This also brings one serious error off wic which is it relying on host >> utilities. It should use parted from native sysroot instead otherwise we >> cannot be sure if witch version we will be using. > > This makes sense to me. Not sure how easy is to do it as I suspect that not > only parted is used this way. > > BTW, this approach conflicts with this feature request: > https://bugzilla.yoctoproject.org/show_bug.cgi?id=6558 > So, should wic rely on system utilities or not? > If it should not then what would you suggest to do with #6558? I added a comment to this. Basically wic is very dependent on data from the build system. It has no knowledge of packages. If we want to build images outside the build system from packages/package feeds, that would be a different tool than wic. Philip > > -- > Regards, > Ed > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
