Re: [yocto] Working on Dependent Recipes in eSDK

[Aaron_Wright]

> ChenQi  wrote on 10/22/2018 07:04:32 PM:
> 
> Hi Aaron,
> 
> The main pain for now is that `devtool sdk-install ' does 

> not work as expected, right?
> I just checked the codes of sdk-install, and found that it does not fit 
> the current RSS design.
> I'd like to check with you if this is the major concern from your team?
> Do you have some other concerns?
> I'll open enhancements/bugs on bugzilla and hopefully will work on them 
> in the 2.7 development cycle.
> 
> Best Regards,
> Chen Qi
> 
> ... snip ...

Well, I'm not quite sure how "devtool sdk-install " 
relates after "devtool modify " has been called. 

My developers use devtool to install dependent recipes into the eSDK when
they start working on something. Often they find that they need to make a
change in the library code that a dependent recipe provides. In effect,
they are developing a patch for the dependent recipe. So they use devtool
to say they're going to modify that dependent recipe, and they go and
make the changes they want. Then what? How do they get those changes,
that patch, available to the eSDK?

Any changes made to the library code provided by the dependent recipe are
not available to the eSDK, except through devtool commands. In effect
there are two different worlds at play, the eSDK sysroots versus the
recipe sysroots. The devtool commands seem to make use of the recipe
sysroots, but in my mind that defeats the purpose of an eSDK. So I made
a plug-in for devtool were I can force the eSDK sysroots to be updated.
I'm not sure how that works, but it seems to propagate the workspace 
(recipe sysroot land) to the eSDK, so changes that developers make are
now available for use.

I want my developers to use the toolchain (cmake, make, gcc, etc) 
provided by the eSDK and by things installed into it 
(devtool sdk-install), rather than having to use devtool as their
iterative build command.

Ultimately, I would like to be able to skip my devtool plug-in, as it 
requires the use of "devtool build " and 
"devtool sdk-sysroot" each time a dependent recipe is modified. But I am
not sure how that would work, other than the devtool build command 
should be updating the eSDK sysroots itself.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Working on Dependent Recipes in eSDK

[Aaron_Wright]

> Paul Eggleton  wrote on 10/18/2018 
12:30:07 PM:
>
> I think we would *like* this to be possible, from what I can tell I 
think the 
> issue is that the copies of the library in the sysroots of other 
dependent 
> recipes aren't being updated. The eSDK (and devtool) were originally 
written 
> when there weren't recipe-specific sysroots, and this stuff was a bit 
simpler.
> 
> Moving back to the full build system won't automatically fix this, 
though it 
> does make workarounds possible - you'd need to rebuild the dependent 
recipes 
> to get their sysroots updated.
> 
> Cheers,
> Paul
> ... snip ...

I put together a devtool plugin to almost do what I want:

> from devtool import exec_build_env_command, DevtoolError
> 
> def sdk_sysroot(args, config, basepath, workspace):
> """Entry point for the devtool sdk-sysroot command"""
> 
> try:
> exec_build_env_command(config.init_path, basepath, 'bitbake 
build-sysroots', watch=True)
> except bb.process.ExecutionError as e:
> raise DevtoolError('Failed to bitbake build-sysroots:\n%s' % 
(str(e)))
> 
> def register_commands(subparsers, context):
> """Register devtool subcommands from the sdk plugin"""
> if context.fixed_setup:
> parser_sdk_sysroot = subparsers.add_parser(
> 'sdk-sysroot',
> help='Update the SDK sysroot',
> description='Updates the SDK sysroot so that changes made to 
recipes in the workspace will be available,',
> group='sdk')
> parser_sdk_sysroot.set_defaults(func=sdk_sysroot)

This allows me to "devtool modify ", edit the code, 
"devtool build ", "devtool sdk-sysroot", and use the new 
code from the dependent recipe immediately.

This makes me wonder if "bitbake build-sysroots" should not be a part of 
"devtool build", like it is for "devtool sdk-install" (where I stole it 
from).
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Working on Dependent Recipes in eSDK

[Aaron_Wright]

> Alexander Kanavin  wrote on 10/18/2018 11:30:17 
AM:
>
> I don’t think esdk is designed for this kind of ‘full stack’ 
> development. You can go back to working directly with yocto layers, 
> and skip the esdk altogether. Devtool will work exactly same (minus 
> the sdk specific commands).
> 
> Alex

I'm trying to get the developers away from using bitbake and devtool to 
build their code, as those tools have overhead and don't easily allow the 
developers to iterate quickly or allow them to run other make targets for 
unit testing, etc. I really want the developers at the "make" level for 
the majority of their time. When it comes time for recipes and image 
creation, then they'll use devtool.

> > On 18 Oct 2018, at 19.37, aaron_wri...@selinc.com wrote:
> > 
> > My team recently started using the eSDK for day-to-day development. 
> > Previously, they were using the bitbake command to build, which works, 
but 
> > has overhead. Yesterday three different people came up to me a 
question 
> > about workflow with the eSDK, and they all had to do with dependent 
> > recipes in the eSDK.
> > 
> > For example, a developer would sit down to make something new that 
relies 
> > on a library provided by a recipe in the eSDK. So they "devtool 
> > sdk-install needed-library", and get to work. While working, they 
> > discover, I need to add something to this library I depend on so that 
it 
> > does what I want in the way I want. So they "devtool modify 
> > needed-library" and change the source of that library to do what they 
> > want, and build that library using its build system (CMake or 
Autotools). 
> > Then they return to working on the new something and find that none of 

> > their changes to the library they depend on are available. 
> > 
> > At this point, they are lost. They just start trying things to make it 

> > work, like "devtool build needed-library", which successfully 
completes, 
> > but doesn't help. Some people also try to use the build system of the 
> > library they modified to install it into the machine sysroot of the 
eSDK 
> > with a command like, "make install 
> > DESTDIR=/tmp/sysroots/", and that actually does 
help. 
> > They can now use the changes they made to the library in the new 
something 
> > they are working on. However, when they use the "devtool sdk-install" 
> > command again, their changes to the needed library that they installed 

> > into the machine sysroot are reverted.
> > 
> > So--what is the workflow they are supposed to use? 
> > 
> > Pushing the changes to the library upstream, updating the recipe, and 
> > waiting for a new eSDK is not practical given that the developers may 
have 
> > to iterate on the changes to the library quite a bit before they get 
it 
> > just right for their new something.
> > 
> > Is there a way to update the eSDK sysroots with recipes that are in 
the 
> > workspace? Could "devtool build" also update the eSDK sysroots? Or is 
> > there a different way to get this done?
> > -- 
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://urldefense.proofpoint.com/v2/url?
> u=https-3A__lists.yoctoproject.org_listinfo_yocto=DwIFaQ=-
> _uRSsrpJskZgEkGwdW-
> sXvhn_FXVaEGsm0EI46qilk=GBJubmJUwwrr1B4TJFRqESMrRsDipvY66vPwm4-
> gtNQ=-
> 
C-70rjnGksaogzIkgE5MdoY3IfA3x62MZVOwbZmw4c=T5PxZ3bNB429M76sWwBqgrtMsMhB-
> kz1BXkdY8hOIRY=

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Working on Dependent Recipes in eSDK

[Aaron_Wright]

My team recently started using the eSDK for day-to-day development. 
Previously, they were using the bitbake command to build, which works, but 
has overhead. Yesterday three different people came up to me a question 
about workflow with the eSDK, and they all had to do with dependent 
recipes in the eSDK.

For example, a developer would sit down to make something new that relies 
on a library provided by a recipe in the eSDK. So they "devtool 
sdk-install needed-library", and get to work. While working, they 
discover, I need to add something to this library I depend on so that it 
does what I want in the way I want. So they "devtool modify 
needed-library" and change the source of that library to do what they 
want, and build that library using its build system (CMake or Autotools). 
Then they return to working on the new something and find that none of 
their changes to the library they depend on are available. 

At this point, they are lost. They just start trying things to make it 
work, like "devtool build needed-library", which successfully completes, 
but doesn't help. Some people also try to use the build system of the 
library they modified to install it into the machine sysroot of the eSDK 
with a command like, "make install 
DESTDIR=/tmp/sysroots/", and that actually does help. 
They can now use the changes they made to the library in the new something 
they are working on. However, when they use the "devtool sdk-install" 
command again, their changes to the needed library that they installed 
into the machine sysroot are reverted.

So--what is the workflow they are supposed to use? 

Pushing the changes to the library upstream, updating the recipe, and 
waiting for a new eSDK is not practical given that the developers may have 
to iterate on the changes to the library quite a bit before they get it 
just right for their new something.

Is there a way to update the eSDK sysroots with recipes that are in the 
workspace? Could "devtool build" also update the eSDK sysroots? Or is 
there a different way to get this done?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] How to patch local source files

[Aaron_Wright]

I've been using "devtool modify/update-recipe" in order to generate 
patches in bbappends in my layer. However, I've run into a problem that 
seems like it should be easy, but it isn't.

I want to patch a local source file. As in, a file referenced in SRC_URI 
that isn't the source code but more like a configuration file or init 
script. 

Using the devtool method I get a copy of the file in my layer, but that 
seems like that would cause maintenance problems down the road when 
upstream changes the file as I won't automatically pick up the changes. 
This seems to be the intended behavior though, as this patch[1] says, "We 
don't want to create patches against the local source files but rather 
update them directly. Thus, 'oe-local-file' directory is ignored in patch 
generation when doing update-recipe..." This seems completely opposite of 
what I want. Why would I want a copy of the file if I changed one line, 
causing maintenance issues in the future?

Am I understanding this right? Is there a workflow that allows for 
patching local source files?

[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.openembedded.org_patch_104075_=DwIBAg=zVFQZQ67ypsA9mYKSCqWmQHiVkCCaN-Gb60_N6TVnLk=IZ3mUDA8X9CZR4hNctKngDDYs_BhK3qVNLG-nWGbW2E=8pcye74JGQLQcBV99bh9bpRb7bX3WqHFUiIq157bDY4=XLqetQZfaf9jTNco2uT4jCN6FbQ1tHD9F_ZJQvBouJI=
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [multilib] 64-bit and 32-bit package install the same executable

[Aaron_Wright]

I've noticed that for my custom image both the 32-bit and the 64-bit 
versions of the same package are getting installed. For example, it has 
both shadow-base and lib32-shadow-base installed. When I check the 
/bin/su.shadow executable I find it is 32-bit.

Is it expected that the lib32 version of the package will "win" when both 
packages install the same /bin/su.shadow file?

Is this something that is always true, so that I can always assume, when 
two packages install the same executable, that it will end up being 
32-bit?

Why does the packaging system, PACKAGE_CLASSES = "package_ipk", not give 
an error when both packages install the same file?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] eSDK and Multilib

[Aaron_Wright]

> Don't install both into the SDK? 

Interesting, I assumed the populate_sdk_ext was building both lib32 and 
non-lib32 versions of the recipes on its own.

I'll have to double check my image definition for recipes that are having 
both variants pulled in.

Thanks for the idea.

> If you must, oe_multlib_header might help.
> 
> Ross
> 
>>  I'm running pyro, and I'm struggling to create an eSDK for multilib
>> custom image. I keep running into FileExistsError errors during the 
>> do_sdk_depends task. 
>> 
>> It seems as though the lib32 and non-lib32 versions of a recipe are 
>> both creating a -dev package that tries to install the same headers. 
>> 
>> Am I missing an easy solution to this?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] eSDK and Multilib

[Aaron_Wright]

 I'm running pyro, and I'm struggling to create an eSDK for multilib 
custom image. I keep running into FileExistsError errors during the 
do_sdk_depends task.

It seems as though the lib32 and non-lib32 versions of a recipe are both 
creating a -dev package that tries to install the same headers.

Am I missing an easy solution to this?-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] How to use iconv natively in do_compile?

[Aaron_Wright]

I'm on pyro, and I have a do_compile step that converts some files to 
UTF8. I use iconv to do this.

According to `oe-pkgdata-util find-path /usr/bin/iconv`, iconv is provided 
by the glibc-utils package. So I tried adding glibc-native or glibc to my 
DEPENDS, but that didn't work. 

I also tried virtual/libiconv-native without any luck. virtual/libiconv is 
listed in ASSUME_PROVIDED but iconv isn't in HOSTTOOLS. I'm not 100% sure 
how those variables are supposed to work.

What do I put in my DEPENDS so that iconv is natively available during 
do_compile?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BKM for Importing Python Modules

[Aaron_Wright]

"Burton, Ross"  wrote on 11/30/2017 02:47:43 AM:
> Python functions in classes are executed by the Python that is 
> executing bitbake, which doesn't have access to the modules in the 
> native sysroot (and won't, as any compiled modules in there are 
> linked against the native python, not the host python).

So adding to sys.path works, but only accidentially?

sys.path.append(
d.getVar("STAGING_DIR_NATIVE", True) +
d.getVar("PYTHON_SITEPACKAGES_DIR", True))
 
> You can solve this by either mandating python-cryptography on the 
> host, or writing a standalone script that is executed using 
> nativepython (which is the python built by python-native).

Not a terrible idea. I'll just have to pull lots of stuff out of d and 
pass them as arguments. Thanks. 

> Ross
> 
> On 30 November 2017 at 00:09,  wrote:
> I have a python function that I've added to PACKAGEFUNCS in a 
> bbclass, and I want to use python-cryptography in that function. 
> However, sys.path doesn't seem setup to allow this import. I'm 
> curious to know the best known method for using python modules that 
> are outside of  /lib directory. Should I just append 
> STAGING_LIBDIR_NATIVE to sys.path? 
> 
> python do_stuff() { 
> import cryptography # <-- this fails 
> 
> # Other stuff... 
> } 
> 
> python () { 
> if (not bb.data.inherits_class("native", d) and 
> not bb.data.inherits_class("cross", d)): 
> 
> d.appendVar("PACKAGEFUNCS", " do_stuff") 
> d.appendVarFlag( 
> "do_package", 
> "depends", 
> " python-cryptography-native:do_populate_sysroot") 
> }
> --
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] BKM for Importing Python Modules

[Aaron_Wright]

I have a python function that I've added to PACKAGEFUNCS in a bbclass, and 
I want to use python-cryptography in that function. However, sys.path 
doesn't seem setup to allow this import. I'm curious to know the best 
known method for using python modules that are outside of  /lib 
directory. Should I just append STAGING_LIBDIR_NATIVE to sys.path?

python do_stuff() {
import cryptography # <-- this fails

# Other stuff...
}

python () {
if (not bb.data.inherits_class("native", d) and
not bb.data.inherits_class("cross", d)):

d.appendVar("PACKAGEFUNCS", " do_stuff")
d.appendVarFlag(
"do_package", 
"depends", 
" python-cryptography-native:do_populate_sysroot")
}-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] devtool sdk-install

[Aaron_Wright]

I'm confused as to how the devtool sdk-install command is supposed to 
work. Take for example:

devtool sdk-install cxxtest

This installs all the /usr/lib and /usr/include stuff into the sysroot, 
but doesn't install the /usr/bin stuff required to actually use cxxtest.

So should I install nativesdk-cxxtest instead? Still doesn't work, but I 
was just curious about the nativesdk- prefix.
cxxtest-native doesn't work either.
Does the cxxtest recipe need a SYSROOT_DIRS_append = " ${bindir}" in order 
to get the /usr/bin files installed in the eSDK when someone installs it?



PS - often devtool sdk-install  will act like it is working and 
then print an error at the end:

NOTE: Tasks Summary: Attempted 105 tasks of which 71 didn't need to be 
rerun and all succeeded.
ERROR: Failed to install nativesdk-cxxtest - unavailable



PPS - a google search for devtool sdk-install returns nothing, so 
hopefully the mailing list can help.-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to use same user in two recipes?

[Aaron_Wright]

> Hi
> 
> I want to use the same user in two different recipe. 
> I create the user in recipe A.bb and it works fine.
> Now I want to use the same user in B.bb so I add DEPENDS = "A" 
> thinking that sysroot will be
> populated with A.bb users.
> 
> But when I bitbake the recipe, user is not found. 
> I conclude that I have to use USERADD_* in each recipe, right?
> 
> What happen if I use different USERADD_PARAM_${PN} in each recipe?
> 
> I also try to use EXTRA_USERS_PARAMS but without success?
> 
> Is there a way to populate sysroot with users?
> 
> Thanks
> 
> -- 
> Fabien
> -- 

When I have this issue I just make a separate recipe that creates the 
user, and have all the other recipes depend on it.
That way the user is always created with the same parameters, without 
possibility of getting out of sync.-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] populate_sdk_ext => "Cannot install package nativesdk-git-perltools"

[Aaron_Wright]

I'm trying to create an extended SDK for a multilib environment and I run 
into this error during the buildtools-tarball-1.0-r0 do_populate_sdk task:

...snip lots of configuring lines...

Configuring nativesdk-buildtools-perl-dummy.
Collected errors:
 * check_conflicts_for: The following packages conflict with 
nativesdk-perl:
 * check_conflicts_for: nativesdk-buildtools-perl-dummy *
 * opkg_solver_install: Cannot install package nativesdk-git-perltools.

...snip lots of configuring lines...

I'm using morty:

commit 493b1c9aeaeb60440085bb3692e9362a87553bce
Author: Richard Purdie 
Date:   Tue Oct 10 11:01:38 2017 +0100

I'm not sure what to look for to solve this issue. Any ideas?-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] local fetcher and devtool don't work well together

[Aaron_Wright]

Paul Eggleton  wrote on 10/04/2017 06:47:50 
PM:
> Hi Aaron,
> 
> On Thursday, 5 October 2017 11:54:32 AM NZDT aaron_wri...@selinc.com 
wrote:
> > I have a recipe with:
> > 
> > SRC_URI = "file://a/b/c/d;subdir=src"
> > S = "${WORKDIR}/src/a/b/c/d"
> > 
> > First off, ${S} must be set to the full path because the basepath uri 
> > parameter[1] doesn't work. So this doesn't work:
> > 
> > SRC_URI = "file://a/b/c/d;subdir=src;basepath=a/b/c/d"
> > S = "${WORKDIR}/src"
> > 
> > I wish it would, but that's ok. I can deal with the long ${S} path as 
it 
> > compiles and works fine with bitbake. 
> 
> My question would be what are you trying to achieve here? Should you be 
using
> the externalsrc class perhaps?

I've waffled between externalsrc and the local fetcher, but the local 
fetcher seems to behave the best.

What I'm trying to do is a little odd, but we are trying to use yocto with 
the recipes, meta layer, and source code in the same repository. This 
makes the continuous integration server much simpler, and developers can 
see the results of their commit/push in the context of the whole product 
being put together with yocto.

This might not be the best idea, and yocto certainly seems to be based on 
the fact that the source is remote, but things are generally working well 
for us; at least continuous integration server wise. Right now I'm trying 
to figure out how to get developers developing.

>   https://urldefense.proofpoint.com/v2/url?
> 
u=http-3A__www.yoctoproject.org_docs_current_dev-2Dmanual_dev-2Dmanual.html-23building-2Dsoftware-2Dfrom-2Dan-2Dexternal-2Dsource=DwICAg=zVFQZQ67ypsA9mYKSCqWmQHiVkCCaN-
> Gb60_N6TVnLk=rUGbzRLPRvFX3fKfyNvK9Xgz1MfBXwYtoWGtKfkzG3k=o9VVMczGF-
> R7-
> 
EC8L6cShpCsU-3GWfug-0DbDpHLamU=JFZPoF89tSSrPhrhqmYSV5VrbkGpTM4jsqr1ij9sBa4=
> 
> > However, it doesn't work with 
> > devtool:
> > 
> > $ devtool modify -n d ~/mysrc/a/b/c/d
> > NOTE: Creating workspace layer in <... snip 
> > ...>/yocto/poky/build/workspace
> > NOTE: Enabling workspace layer in bblayers.conf
> > Parsing recipes..done.
> > NOTE: Recipe d now set up to build from ~/mysrc/a/b/c/d/b/c/d
> > 
> > Where is the extra 'b/c/d' coming from in where it will be built from? 

> > This directory is reflected in the bbappends created the workspace:
> > 
> > FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> > FILESPATH_prepend := "~/mysrc/a/b/c/d/b/c/d/oe-local-files:"
> >
> > Is it possible to have a ${S} of "${WORKDIR}/src" in this situation?
> > How can I get devtool to behave and not duplicate the path?
> 
> The ~ shouldn't be in the value of FILESPATH, it ought to be expanded, 
so
> that's something we need to fix. 

Don't worry about the ~, that was just something I passed in the email to 
obscure my path. Sorry.

> With regard to the path doubling of the
> subdirectories, it's assuming that because you have that subdirectory 
path in
> S then you need that underneath the specified source directory (since 
that is
> usually true if you were for example pointing to a checkout of a git
> repository, or an extracted source tarball).

You are correct. I can't believe I didn't think of that before. Thank you 
so much. That gets me going at least.

> devtool hasn't been written to handle this usage (which is unusual 
-typically
> the recipe is pointing at remote source). It would be good to get an
> understanding of your use case here so we can figure out where to go 
from
> here.
> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] local fetcher and devtool don't work well together

[Aaron_Wright]

I have a recipe with:

SRC_URI = "file://a/b/c/d;subdir=src"
S = "${WORKDIR}/src/a/b/c/d"

First off, ${S} must be set to the full path because the basepath uri 
parameter[1] doesn't work. So this doesn't work:

SRC_URI = "file://a/b/c/d;subdir=src;basepath=a/b/c/d"
S = "${WORKDIR}/src"

I wish it would, but that's ok. I can deal with the long ${S} path as it 
compiles and works fine with bitbake. However, it doesn't work with 
devtool:

$ devtool modify -n d ~/mysrc/a/b/c/d
NOTE: Creating workspace layer in <... snip 
...>/yocto/poky/build/workspace
NOTE: Enabling workspace layer in bblayers.conf
Parsing recipes..done.
NOTE: Recipe d now set up to build from ~/mysrc/a/b/c/d/b/c/d

Where is the extra 'b/c/d' coming from in where it will be built from? 
This directory is reflected in the bbappends created the workspace:

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
FILESPATH_prepend := "~/mysrc/a/b/c/d/b/c/d/oe-local-files:"

inherit externalsrc
# NOTE: We use pn- overrides here to avoid affecting multiple variants in 
the case where the recipe uses BBCLASSEXTEND
EXTERNALSRC_pn-backtrace = "~/mysrc/a/b/c/d/b/c/d"

If I fix the path in the workspace bbappends, it does compile and work 
file.

Is it possible to have a ${S} of "${WORKDIR}/src" in this situation?
How can I get devtool to behave and not duplicate the path?

PS - This also doesn't work with a normal 'devtool modify d'.

[1] - 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.yoctoproject.org_docs_latest_bitbake-2Duser-2Dmanual_bitbake-2Duser-2Dmanual.html-23bb-2Dthe-2Dunpack=DwIBAg=zVFQZQ67ypsA9mYKSCqWmQHiVkCCaN-Gb60_N6TVnLk=IZ3mUDA8X9CZR4hNctKngDDYs_BhK3qVNLG-nWGbW2E=wH_YZj_cv9gBOhJqSKTr4fiuM5UCTphWx9zfY2ceudg=2z9LBCu2xDjBhB51eToRNH7-wsLrFY4NPKy4_cwuRI0=
 -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto eSDK nativesdk vs native vs normal

[Aaron_Wright]

I'm having a hard time figuring out what specific package to install when 
I'm in the eSDK environment.

Say I want to install cmake, do I:

   devtool sdk-install cmake

or:

   devtool sdk-install cmake-native

or:

   devtool sdk-install nativesdk-cmake

CMake is just one example, any other package would cause the same 
confusion for me. 
Does it depend on the package; tools for use in the eSDK vs libraries for 
the target?-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto eSDK, Editing/Adding Recipes, and VCS

[Aaron_Wright]

I've been trying to document some workflows for my developers using the 
Yocto eSDK for our image, but I am coming up empty when it comes to 
editing or adding recipes. I can use devtool to edit a recipe like so:

devtool edit-recipe -a my-recipe

But any changes I make are hidden away in the 
esdk/layers/poky/meta-mylayer directory, which isn't managed by a VCS (git 
in this instance). So there's this modified file in a directory--great. 
What is the developer supposed to do with it? Copy it over to a VCS 
managed directory of meta-mylayer, commit, and push?

I feel like I'm missing something with the devtool workflow. Can anyone 
point me in the right direction?
 -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Minimal eSDK with PKGDATA causes licensing issues

[Aaron_Wright]

I added these lines to my eSDK image I'm trying to build:
 
SDK_EXT_TYPE = "minimal"
SDK_INCLUDE_TOOLCHAIN = "1"
SDK_INCLUDE_PKGDATA = "1"

But bitbake comes back with lots of license issues (mpv, gstreamer, 
libvdpau, etc). These are all the commercial licensed recipes.

I don't want PKGDATA for recipes that I haven't already listed in 
LICENSE_FLAGS_WHITELIST to end up the eSDK, so I don't care about 
these errors, but they stop the build in its tracks.

How can I exclude commercial licensed (or any incompatible license) 
recipes from my eSDK?-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto