> 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
> 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
> wh
> 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).
>
> A
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 t
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 li
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
> 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_m
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.
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
"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 hos
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. Shoul
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 natives
> 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'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
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 p
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
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 pack
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
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 r
19 matches
Mail list logo
