Re: [yocto] bitbake core-image-web-kiosk question ?

On Tue, Jun 13, 2017 at 9:10 PM, Riko Ho wrote: > Hello Everyone, > > I tried doing "bitbake core-image-web-kiosk" > > And I got this : > > > > Loading cache: 100% >

[yocto] bitbake core-image-web-kiosk question ?

Hello Everyone, I tried doing "bitbake core-image-web-kiosk" And I got this : Loading cache: 100% |#| Time: 0:00:00 Loaded 1310 entries

[yocto] [meta-security][PATCH] apparmor: Rework such that the utilities are functional by default

This introduces a number of changes: - Fix the python PACKAGECONFIG knob - The included python support is python3-based, so use those classes. - When set, make sure to RDEPEND on the python modules the tools use. - Fix the perl PACKAGECONFIG knob - Add two patches so that configure will find

Re: [yocto] Image lacks libraries needed by SDK

> From: Andre McCurdy [mailto:armccu...@gmail.com] > > > I noticed that when I built an SDK under > > core-image-minimal, it didn't include libasound, but that > > was included > > when I built it under my own image which includes ALSA. So > > it's obviously > > paying attention to what's in

Re: [yocto] Image lacks libraries needed by SDK

On Tue, Jun 13, 2017 at 4:24 PM, Paul D. DeRocco wrote: > I have a working system image for my 32-bit Atom-based hardware, based on > Morty. My application is a C++ program that runs as a systemd service. > I've always built the application outside Yocto, using the Eclipse

[yocto] Image lacks libraries needed by SDK

I have a working system image for my 32-bit Atom-based hardware, based on Morty. My application is a C++ program that runs as a systemd service. I've always built the application outside Yocto, using the Eclipse CDT and whatever GCC was on my Ubuntu system. It gets installed into my hardware on a

Re: [yocto] Preventing a package from building

Yes that's very good in the theoretical, but I was looking for actual commands to get this done. Solution was from Leo Sandoval, COMPATIBLE_HOST = "null" inside of the chromium_52.0.2743.76.bbappend On 06/13/2017 02:56 PM, Burton, Ross wrote: The canonical solution here is to write

Re: [yocto] Preventing a package from building

On 13 June 2017 at 20:26, Jimi Damon wrote: > This package is being built on the host side during a bitbake using a > Boundary Devices Yocto build ( > > * MACHINE=nitrogen6x DISTRO=fslc-x11 . setup-environment build * > > + > > * bitbake boundary-eval-image-xfce* > > The

Re: [yocto] Preventing a package from building

Is there a way to apply this ( or something like it ) inside the current bblayers.conf file ? I've already built most of this image and I don't want to accidentally lose all of that work by changing a global configuration file nor do I wish to change the global recicpe itself if that's

Re: [yocto] Preventing a package from building

This package is being built on the host side during a bitbake using a Boundary Devices Yocto build ( * MACHINE=nitrogen6x DISTRO=fslc-x11 . setup-environment build * + * bitbake boundary-eval-image-xfce * ) . I was looking for an easy way to disable even building this into the image

Re: [yocto] Preventing a package from building

On Tue, 2017-06-13 at 11:32 -0700, Jimi Damon wrote: > Hi, > > > I tried using the PACKAGE_EXCLUDE = "chromium" in my local.conf file > but I'm finding that my build it is still trying to build this > package. > is it on your image? at the end, this variable is to exclude the package on the

[yocto] Preventing a package from building

Hi, I tried using the PACKAGE_EXCLUDE = "chromium" in my local.conf file but I'm finding that my build it is still trying to build this package. Is there a way to prevent this build stage from occurring ? Thanks -- ___ yocto mailing list

[yocto] useradd and one sysroot per recipe in pyro

Hello, currently I am trying the newest Yocto release (pyro). It seems I have a problem with useradd and the new concept of one sysroot per recipe. I have a base recipe (let's call it my-base.bb) which inherits useradd and creates a new user (let's call him myuser): inherit useradd

[yocto] [qa-tools][PATCH 4/4] testopia_update: Add support to create_wiki functionality

From: Jose Perez Carranza Add option that allows using –create-wiki under setup option,this potion takes date and project as a parameter and search for tests runs and generates the wiki report data in a file. Signed-off-by: Jose Perez Carranza

[yocto] [qa-tools][PATCH 3/4] testopia_update/utils: Add utils directory

From: Jose Perez Carranza Add utils directory to be used as the repository for different utilities -wikimaker.py : scripts that creates the wiki report data saves it to the data inside a file to be copied on the already created wiki page Signed-off-by: Jose

[yocto] [qa-tools][PATCH 2/4] poduct/init: Add functions to get product and environment names

From: Jose Perez Carranza Add functions as follows: - get_test_plan_by_id : Get test plan providing the plan ID - get_product_name: Get product name providing the product ID - get_environment_by_id: Get environment providing the environment ID Signed-off-by:

[yocto] [qa-tools][PATCH 1/4] external/testopia: Modify commands to get Product and Environment

From: Jose Perez Carranza Modify commands to get Product and Environment name providing the ID. Signed-off-by: Jose Perez Carranza --- external/testopia.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff

[yocto] swupate.bblcass dependencies not triggering rebuild

Hi list, I want to create a swupdate file, which is a cpio file with rootfs and some metadata to control software update. My problem is, that it is not rebuilt everytime the rootfs changes. I checked in the cooker log. NOTE: recipe swupdate-image-1.0-r4: task do_populate_sysroot_setscene:

Re: [yocto] Setting directories permissions

Hi Oliver, It is not not clear to me what the root cause of this could be... Is this directory shared by several pacakages by any chance? One trick I am using to figure out in which recipe/package a file or directory is found is the following (from the build directory): echo

[yocto] Setting directories permissions

Hello List, I try to define a directory permission for a folder to 0775 instead of 0755 in my recipe. But somewhere in the install and packaging process this is overwritten. in my receipe I do this: do_install() { install -m 0775 -d ${D}${sysconfdir}/folder1/folder2/ I expect this on the