Re: [yocto] ERROR: gcc-source-6.3.0-6.3.0-r0 do_fetch: Fetcher failure for URL: 'file://0002-uclibc-conf.patch'. Unable to fetch URL from any source.

2017-08-14 Thread Riko 

Do you mean this one ?

Build Configuration:
BB_VERSION= "1.34.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "universal"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "beaglebone"
DISTRO= "poky"
DISTRO_VERSION= "2.3.1"
TUNE_FEATURES = "arm armv7a vfp neon callconvention-hard cortexa8"
TARGET_FPU= "hard"
meta
meta-poky
meta-yocto-bsp= "pyro:4a39979c8d1e560fa54240e99734a651dfbaa63a"
meta  = "master:5a25ed1071f0d9b7d95edcc2b5b4545f960d5f95"
meta-oe
meta-xfce
meta-gnome
meta-python
meta-multimedia
meta-networking   = "master:a8b54e300be027fefe8a774ca1861d0fb8e80d99"
meta-browser  = "master:e3c3aa0591506672245904227a46519a276957e0"


On 15/08/17 13:30, Khem Raj wrote:

On Mon, Aug 14, 2017 at 9:42 PM, Riko  wrote:

Dear Team Yocto Member,

How can I get gcc6.30 ?

I got error :

ERROR: gcc-source-6.3.0-6.3.0-r0 do_fetch: Fetcher failure for URL:
'file://0002-uclibc-conf.patch'. Unable to fetch URL from any source.


what branch are you using and if you are using additonal layers which ones
are those and what branches are they on.


Here's the log :

===

DEBUG: Executing python function clean_recipe_sysroot
DEBUG: Python function clean_recipe_sysroot finished
DEBUG: Executing python function extend_recipe_sysroot
NOTE: Direct dependencies are []
NOTE:
DEBUG: Python function extend_recipe_sysroot finished
DEBUG: Executing python function do_fetch
DEBUG: Executing python function base_do_fetch
DEBUG: Searching for 0001-gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch in paths:
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/
DEBUG: Searching for 0002-uclibc-conf.patch in paths:
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/arm

Re: [yocto] ERROR: gcc-source-6.3.0-6.3.0-r0 do_fetch: Fetcher failure for URL: 'file://0002-uclibc-conf.patch'. Unable to fetch URL from any source.

2017-08-14 Thread Riko 

which branch are you talking about ?

I don't understand your question


On 15/08/17 13:30, Khem Raj wrote:

On Mon, Aug 14, 2017 at 9:42 PM, Riko  wrote:

Dear Team Yocto Member,

How can I get gcc6.30 ?

I got error :

ERROR: gcc-source-6.3.0-6.3.0-r0 do_fetch: Fetcher failure for URL:
'file://0002-uclibc-conf.patch'. Unable to fetch URL from any source.


what branch are you using and if you are using additonal layers which ones
are those and what branches are they on.


Here's the log :

===

DEBUG: Executing python function clean_recipe_sysroot
DEBUG: Python function clean_recipe_sysroot finished
DEBUG: Executing python function extend_recipe_sysroot
NOTE: Direct dependencies are []
NOTE:
DEBUG: Python function extend_recipe_sysroot finished
DEBUG: Executing python function do_fetch
DEBUG: Executing python function base_do_fetch
DEBUG: Searching for 0001-gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch in paths:
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/
DEBUG: Searching for 0002-uclibc-conf.patch in paths:
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/
DEBUG: Defaulting to
/home/bianchi/poky/build/downloads/0002-uclibc-conf.patch for
0002-uclibc-conf.patch
DEBUG:

Re: [yocto] How can I use PREFERRED_VERSION_ ?

2017-08-14 Thread Khem Raj 
On Mon, Aug 14, 2017 at 7:15 PM, Riko  wrote:
> Dear Yocto Team Members,
>
> How can I use PREFERRED_VERSION_ ?
>
>

read through
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-PREFERRED_VERSION

> ERROR: Multiple versions of openssl are due to be built
> (/home/bianchi/poky/openembedded-core/meta/recipes-connectivity/openssl/openssl_1.1.0f.bb
> /home/bianchi/poky/meta/recipes-connectivity/openssl/openssl_1.0.2k.bb).
> Only one version of a given PN should be built in any given build. You
> likely need to set PREFERRED_VERSION_openssl to select the correct version
> or don't depend on multiple versions.
>
>
> Regards,
>
> Riko
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ERROR: gcc-source-6.3.0-6.3.0-r0 do_fetch: Fetcher failure for URL: 'file://0002-uclibc-conf.patch'. Unable to fetch URL from any source.

2017-08-14 Thread Khem Raj 
On Mon, Aug 14, 2017 at 9:42 PM, Riko  wrote:
> Dear Team Yocto Member,
>
> How can I get gcc6.30 ?
>
> I got error :
>
> ERROR: gcc-source-6.3.0-6.3.0-r0 do_fetch: Fetcher failure for URL:
> 'file://0002-uclibc-conf.patch'. Unable to fetch URL from any source.
>

what branch are you using and if you are using additonal layers which ones
are those and what branches are they on.

> Here's the log :
>
> ===
>
> DEBUG: Executing python function clean_recipe_sysroot
> DEBUG: Python function clean_recipe_sysroot finished
> DEBUG: Executing python function extend_recipe_sysroot
> NOTE: Direct dependencies are []
> NOTE:
> DEBUG: Python function extend_recipe_sysroot finished
> DEBUG: Executing python function do_fetch
> DEBUG: Executing python function base_do_fetch
> DEBUG: Searching for 0001-gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch in paths:
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/poky
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/poky
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/poky
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/poky
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/poky
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/beaglebone
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/beaglebone
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/beaglebone
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/beaglebone
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/beaglebone
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/armv7a
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/armv7a
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/armv7a
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/armv7a
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/armv7a
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/arm
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/arm
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/arm
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/arm
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/arm
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/
> DEBUG: Searching for 0002-uclibc-conf.patch in paths:
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/poky
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/poky
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/poky
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/poky
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/poky
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/beaglebone
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/beaglebone
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/beaglebone
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/beaglebone
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/beaglebone
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/armv7a
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/armv7a
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/armv7a
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/armv7a
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/armv7a
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/arm
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/arm
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/arm
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/arm
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/arm
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/
> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/
> DEBUG: Defaulting to
> /home/bianchi/poky/build/downloads/0002-uclibc-conf.patch for

[yocto] ERROR: gcc-source-6.3.0-6.3.0-r0 do_fetch: Fetcher failure for URL: 'file://0002-uclibc-conf.patch'. Unable to fetch URL from any source.

2017-08-14 Thread Riko 

Dear Team Yocto Member,

How can I get gcc6.30 ?

I got error :

ERROR: gcc-source-6.3.0-6.3.0-r0 do_fetch: Fetcher failure for URL: 
'file://0002-uclibc-conf.patch'. Unable to fetch URL from any source.


Here's the log :

===

DEBUG: Executing python function clean_recipe_sysroot
DEBUG: Python function clean_recipe_sysroot finished
DEBUG: Executing python function extend_recipe_sysroot
NOTE: Direct dependencies are []
NOTE:
DEBUG: Python function extend_recipe_sysroot finished
DEBUG: Executing python function do_fetch
DEBUG: Executing python function base_do_fetch
DEBUG: Searching for 0001-gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch in paths:
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/
DEBUG: Searching for 0002-uclibc-conf.patch in paths:
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/poky
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/beaglebone
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/armv7a
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/arm
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3/backport/
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc-6.3.0/
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/
/home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/
DEBUG: Defaulting to 
/home/bianchi/poky/build/downloads/0002-uclibc-conf.patch for 
0002-uclibc-conf.patch

DEBUG: Trying PREMIRRORS
DEBUG: For url ['file', '', '0002-uclibc-conf.patch', '', '', 
OrderedDict()] comparing ['bzr', '.*', '/.*', '', '', OrderedDict()] to 
['http', 'downloads.yoctoproject.org', '/mirror/sources/', '', '', 
OrderedDict()]
DEBUG: For url ['file', '', '0002-uclibc-conf.patch', '',

Re: [yocto] Idea for bbappend / layer organization and naming convention

2017-08-14 Thread Bruce Ashfield 

On 2017-08-14 3:36 PM, Gunnar Andersson wrote:


Yocto community,

Triggered by the previous email request to yocto@ about best practices for
layer organization I'm finally firing off this email for (hopefully) some
feedback on an idea we first kicked around, discussed for rough consensus
and then decided to implement in the Yocto based GDP project [1].  You can
see it as a trial, anything can be changed, but so far so good...

We adopted a somewhat novel (but actually not really unique, see inside)
naming convention [2] for all modifications to components that belong to
other layers.



I've been using a similar naming/sorting mechanism in layers that
I maintain for several years now. When you have a single layer that
is carrying bbappends to many other layers, I find that it really
helps keep everything separated and aids finding the original
recipe.

(that being said, recent work with layer index, etc, make it
easier to locate the original recipe and any bbappends .. but that
doesn't preclude keeping things organized in a layer).

Cheers,

Bruce


This convention shows what layers are being modified by the .bbappends by
actually naming the layer it is (intending to**) modify.  The initiative
also aims to highlight and separate .bbappends (modifications) from uniquely
added components in our project (new .bb files) in GDP.

**Note that we are well aware this does NOT control bitbake behavior (as
neither does the recipe-xxx/ directory convention), and is therefore just a
guide.  If the project is misconfigured, bitbake could do something
different than the naming convention implies and it could even be
misleading, but at least the *programmer intent* is shown clearly.

I think it also makes .bbappends more explicitly visible and might trigger
the idea:   Do we really need this?  Are we really modifying *that* adopted
layer, and if so, why?

To Russel who wrote the previous request for guidance - feel free to
consider, but I won't recommend this directly since it's by no means an
agreed best practice in all of the community.  I'm rather asking for other
experienced OE developers to consider and comment on the idea.

For oldtimers it's probably easy to find this odd and just be negative
against it since well, "standard practice", inertia, NIH and all that, but
I'll stick my neck out anyway because it seems to solve some issues of
organization and understanding at least for us (and I'm a sucker for some
flamebait ;)

If the intro is too formal and long, just look at the final examples.  I
think you'll get it.  Feel free to ask.


- Gunnar

--
Gunnar Andersson 
Development Lead
GENIVI Alliance

[1] https://github.com/GENIVI/genivi-dev-platform
[2] Naming strategy for bitbake extension layers:   
https://at.projects.genivi.org/wiki/x/w4Xk





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

[linux-yocto] [PATCH 2/3] mm: fix new crash in unmapped_area_topdown()

2017-08-14 Thread jianchuan.wang 
From: Hugh Dickins 

commit f4cb767d76cf7ee72f97dd76f6cfa6c76a5edc89 upstream

Trinity gets kernel BUG at mm/mmap.c:1963! in about 3 minutes of
mmap testing.  That's the VM_BUG_ON(gap_end < gap_start) at the
end of unmapped_area_topdown().  Linus points out how MAP_FIXED
(which does not have to respect our stack guard gap intentions)
could result in gap_end below gap_start there.  Fix that, and
the similar case in its alternative, unmapped_area().

Cc: sta...@vger.kernel.org
Fixes: 1be7107fbe18 ("mm: larger stack guard gap, between vmas")
Reported-by: Dave Jones 
Debugged-by: Linus Torvalds 
Signed-off-by: Hugh Dickins 
Acked-by: Michal Hocko 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jianchuan Wang 
---
 mm/mmap.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index 945ff3b..91581c6 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1814,7 +1814,8 @@ unsigned long unmapped_area(struct vm_unmapped_area_info 
*info)
/* Check if current node has a suitable gap */
if (gap_start > high_limit)
return -ENOMEM;
-   if (gap_end >= low_limit && gap_end - gap_start >= length)
+   if (gap_end >= low_limit &&
+   gap_end > gap_start && gap_end - gap_start >= length)
goto found;
 
/* Visit right subtree if it looks promising */
@@ -1917,7 +1918,8 @@ unsigned long unmapped_area_topdown(struct 
vm_unmapped_area_info *info)
gap_end = vm_start_gap(vma);
if (gap_end < low_limit)
return -ENOMEM;
-   if (gap_start <= high_limit && gap_end - gap_start >= length)
+   if (gap_start <= high_limit &&
+   gap_end > gap_start && gap_end - gap_start >= length)
goto found;
 
/* Visit left subtree if it looks promising */
-- 
2.8.1

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

[linux-yocto] [PATCH 3/3] ipx: call ipxitf_put() in ioctl error path

2017-08-14 Thread jianchuan.wang 
From: Dan Carpenter 

upstream ee0d8d8482345ff97a75a7d747efc309f13b0d80 commit

We should call ipxitf_put() if the copy_to_user() fails.

Reported-by: 李强 
Signed-off-by: Dan Carpenter 
Signed-off-by: David S. Miller 
Signed-off-by: Jianchuan Wang 
---
 net/ipx/af_ipx.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/net/ipx/af_ipx.c b/net/ipx/af_ipx.c
index 8a9219f..fa31ef2 100644
--- a/net/ipx/af_ipx.c
+++ b/net/ipx/af_ipx.c
@@ -1168,11 +1168,10 @@ static int ipxitf_ioctl(unsigned int cmd, void __user 
*arg)
sipx->sipx_network  = ipxif->if_netnum;
memcpy(sipx->sipx_node, ipxif->if_node,
sizeof(sipx->sipx_node));
-   rc = -EFAULT;
+   rc = 0;
if (copy_to_user(arg, , sizeof(ifr)))
-   break;
+   rc = -EFAULT;
ipxitf_put(ipxif);
-   rc = 0;
break;
}
case SIOCAIPXITFCRT:
-- 
2.8.1

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

[linux-yocto] [PATCH 1/3] mm: larger stack guard gap, between vmas

2017-08-14 Thread jianchuan.wang 
From: Hugh Dickins 

commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream.

Stack guard page is a useful feature to reduce a risk of stack smashing
into a different mapping. We have been using a single page gap which
is sufficient to prevent having stack adjacent to a different mapping.
But this seems to be insufficient in the light of the stack usage in
userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
which is 256kB or stack strings with MAX_ARG_STRLEN.

This will become especially dangerous for suid binaries and the default
no limit for the stack size limit because those applications can be
tricked to consume a large portion of the stack and a single glibc call
could jump over the guard page. These attacks are not theoretical,
unfortunatelly.

Make those attacks less probable by increasing the stack guard gap
to 1MB (on systems with 4k pages; but make it depend on the page size
because systems with larger base pages might cap stack allocations in
the PAGE_SIZE units) which should cover larger alloca() and VLA stack
allocations. It is obviously not a full fix because the problem is
somehow inherent, but it should reduce attack space a lot.

One could argue that the gap size should be configurable from userspace,
but that can be done later when somebody finds that the new 1MB is wrong
for some special case applications.  For now, add a kernel command line
option (stack_guard_gap) to specify the stack gap size (in page units).

Implementation wise, first delete all the old code for stack guard page:
because although we could get away with accounting one extra page in a
stack vma, accounting a larger gap can break userspace - case in point,
a program run with "ulimit -S -v 2" failed when the 1MB gap was
counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
and strict non-overcommit mode.

Instead of keeping gap inside the stack vma, maintain the stack guard
gap as a gap between vmas: using vm_start_gap() in place of vm_start
(or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
places which need to respect the gap - mainly arch_get_unmapped_area(),
and and the vma tree's subtree_gap support for that.

Original-patch-by: Oleg Nesterov 
Original-patch-by: Michal Hocko 
Signed-off-by: Hugh Dickins 
Acked-by: Michal Hocko 
Tested-by: Helge Deller  # parisc
Signed-off-by: Linus Torvalds 
[wt: backport to 4.11: adjust context]
[wt: backport to 4.9: adjust context ; kernel doc was not in admin-guide]
Signed-off-by: Willy Tarreau 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Paul Gortmaker 
Signed-off-by: Jianchuan Wang 
---
 arch/arc/mm/mmap.c  |   2 +-
 arch/arm/mm/mmap.c  |   4 +-
 arch/frv/mm/elf-fdpic.c |   2 +-
 arch/mips/mm/mmap.c |   2 +-
 arch/parisc/kernel/sys_parisc.c |  15 ++--
 arch/powerpc/mm/hugetlbpage-radix.c |   2 +-
 arch/powerpc/mm/mmap.c  |   4 +-
 arch/powerpc/mm/slice.c |   2 +-
 arch/s390/mm/mmap.c |   4 +-
 arch/sh/mm/mmap.c   |   4 +-
 arch/sparc/kernel/sys_sparc_64.c|   4 +-
 arch/sparc/mm/hugetlbpage.c |   2 +-
 arch/tile/mm/hugetlbpage.c  |   2 +-
 arch/x86/kernel/sys_x86_64.c|   4 +-
 arch/x86/mm/hugetlbpage.c   |   2 +-
 arch/xtensa/kernel/syscall.c|   2 +-
 fs/hugetlbfs/inode.c|   2 +-
 fs/proc/task_mmu.c  |   4 -
 include/linux/mm.h  |  53 ++---
 mm/gup.c|   5 --
 mm/memory.c |  38 -
 mm/memory.c.rej |  10 ---
 mm/mmap.c   | 148 ++--
 23 files changed, 145 insertions(+), 172 deletions(-)
 delete mode 100644 mm/memory.c.rej

diff --git a/arch/arc/mm/mmap.c b/arch/arc/mm/mmap.c
index 2e06d56..cf4ae69 100644
--- a/arch/arc/mm/mmap.c
+++ b/arch/arc/mm/mmap.c
@@ -64,7 +64,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
 
vma = find_vma(mm, addr);
if (TASK_SIZE - len >= addr &&
-   (!vma || addr + len <= vma->vm_start))
+   (!vma || addr + len <= vm_start_gap(vma)))
return addr;
}
 
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index 66353ca..641334e 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -89,7 +89,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
 
vma = find_vma(mm, addr);
if (TASK_SIZE - len >= addr &&
-   (!vma || addr + len <= vma->vm_start))
+   (!vma ||

[yocto] How can I use PREFERRED_VERSION_ ?

2017-08-14 Thread Riko 

Dear Yocto Team Members,

How can I use PREFERRED_VERSION_ ?


ERROR: Multiple versions of openssl are due to be built 
(/home/bianchi/poky/openembedded-core/meta/recipes-connectivity/openssl/openssl_1.1.0f.bb 
/home/bianchi/poky/meta/recipes-connectivity/openssl/openssl_1.0.2k.bb). 
Only one version of a given PN should be built in any given build. You 
likely need to set PREFERRED_VERSION_openssl to select the correct 
version or don't depend on multiple versions.



Regards,

Riko

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

Re: [yocto] layer.conf on openembedded-core ?

2017-08-14 Thread Riko 

Dear Team Yocto Members,

I continue compiling, and got :

ERROR: 
/home/bianchi/poky/openembedded-core/meta/recipes-core/images/build-appliance-image_15.0.0.bb: 
No IMAGE_CMD defined for IMAGE_FSTYPES entry 'wic.vmdk' - possibly 
invalid type name or missing support class
ERROR: Failed to parse recipe: 
/home/bianchi/poky/openembedded-core/meta/recipes-core/images/build-appliance-image_15.0.0.bb


How can I fix it ?

regards,

Riko


On 14/08/17 23:56, Christopher Larson wrote:

The openembedded-core root isn’t a layer, openembedded-core/meta is.

On Mon, Aug 14, 2017 at 8:49 AM, Leonardo Sandoval 
> wrote:


On Mon, 2017-08-14 at 15:11 +0800, Riko wrote:
> Dear Yocto Members,
>
> How can I find this file ?


this is a pretty general question. are you running bitbake from the
build directory? double check your conf/bblayers.conf and make sure
paths there are pointing correctly.


>
> ==
>
> ERROR: Unable to parse
> /home/bianchi/poky/openembedded-core/conf/layer.conf: [Errno 2] file
> /home/bianchi/poky/openembedded-core/conf/layer.conf not found
>
>
> Thanks,
>
> Riko
>


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





--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics


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

Re: [yocto] layer.conf on openembedded-core ?

2017-08-14 Thread Riko 

Thanks for the clue, now it's compiling,


On 14/08/17 23:56, Christopher Larson wrote:

The openembedded-core root isn’t a layer, openembedded-core/meta is.

On Mon, Aug 14, 2017 at 8:49 AM, Leonardo Sandoval 
> wrote:


On Mon, 2017-08-14 at 15:11 +0800, Riko wrote:
> Dear Yocto Members,
>
> How can I find this file ?


this is a pretty general question. are you running bitbake from the
build directory? double check your conf/bblayers.conf and make sure
paths there are pointing correctly.


>
> ==
>
> ERROR: Unable to parse
> /home/bianchi/poky/openembedded-core/conf/layer.conf: [Errno 2] file
> /home/bianchi/poky/openembedded-core/conf/layer.conf not found
>
>
> Thanks,
>
> Riko
>


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





--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics


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

[yocto] [patchwork][PATCH V2] tools/test-series: automate test-build process for series

2017-08-14 Thread Jose Lamego 
Testing patch series' for appropriate integration and further
build against a branch requires several manual steps, providing
a poor code maintainer experience and increasing overall patch
integration workflow.

This change adds a script to automate the test-build process for
one or more patch series by downloading one or more series from
patchwork, applying it/them to a test branch, uploading the test
branch to a repository and starting a build at a Yocto Autobuilder.
Then a message is posted at the series view in patchwork with a
link to the builder's web page.
The build results can later be queried at the autobuilder api using
the "reason" field, where the script includes the tested series' ID
and the date when it was started as unique identifier.

[YOCTO #8714]

Signed-off-by: Jose Lamego 
---

Notes:
Changes in V2:

- Updated script description to be more clear about its purpose.
- Moved the script to a new directory that now also contains a
  requirements file.
- Removed hardcoded paths and pointed the default paths into
  current user's home directory.
- Default autobuilder URL points to https://autobuilder.yocto.io
- Use subprocess' checkout_output function instead of Popen+PIPE
- Removed if/else argument validation by setting default values
- Added publish_build function to use git-pw command to post a
  notification for the started build at the series view in
  patchwork. The posted message at the test-results section can
  later be updated with a direct link to the build results when
  available.

 tools/test-series/requirements.txt |   3 +
 tools/test-series/test-series  | 496 +
 2 files changed, 499 insertions(+)
 create mode 100644 tools/test-series/requirements.txt
 create mode 100755 tools/test-series/test-series

diff --git a/tools/test-series/requirements.txt 
b/tools/test-series/requirements.txt
new file mode 100644
index 000..14d817a
--- /dev/null
+++ b/tools/test-series/requirements.txt
@@ -0,0 +1,3 @@
+beautifulsoup4
+lxml
+python-requests >= 2.4.2
diff --git a/tools/test-series/test-series b/tools/test-series/test-series
new file mode 100755
index 000..e037fce
--- /dev/null
+++ b/tools/test-series/test-series
@@ -0,0 +1,496 @@
+#!/usr/bin/env python3
+#
+# Patch series test build automation script
+#
+# Copyright (C) 2015-2017 Intel Corporation
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+#
+#
+# Requirements:
+#   - Using pip:
+#
+# $ pip install beautifulsoup4 lxml
+#
+# Setup:
+#
+# - Path to a local git repository directory that can
+#   push to a remote repository must be provided.
+# - if no local "git patchwork.default.url" is set,
+#   http://patchwork.openembedded.org will be used
+
+import argparse
+import git
+import os
+import sys
+import subprocess
+from datetime import datetime
+import getpass
+import requests
+import re
+
+# * Default values * #
+sourceDir = os.path.dirname(os.path.realpath(__file__))
+default_user = getpass.getuser()
+default_patchwork_dir = "/home/%s/patchwork/patchwork" % default_user
+default_patchwork_url = "https://patchwork.openembedded.org;
+default_builder = "nightly-oecore"
+default_autobuilder_dir = "/home/%s/yocto-autobuilder" % default_user
+default_autobuilder_url = "https://autobuilder.yocto.io;
+default_password = "password"
+default_repo_name = "origin"
+default_repo_url = None
+default_base_branch = "master"
+# delete test-branch after starting build
+default_delete_branch = False
+# push branch to repoUrl
+default_no_push = False
+# skip starting the build
+default_no_build = False
+default_update_basebranch = False
+default_test_success_only = False
+test_name = "test-build"
+initial_result = "pending"
+
+
+class TestSeriesAPI(object):
+
+def __init__(self, cmd):
+self.cmd = cmd
+
+def _checkout_to_branch(self, branch):
+try:
+msg = subprocess.check_output(['git', 'checkout', branch]
+  ).decode('utf-8').strip()
+if msg != "":
+print("I: %s" % msg)
+return 0
+except subprocess.CalledProcessError:
+return 1
+
+def _get_current_branch(self):
+try:
+msg =

[yocto] [layerindex-web][PATCH] Redirect user to correct url after editing a layer

2017-08-14 Thread Amanda Brindle 
Before, if a user edited a layer's name, they would be redirected
to a url utilizing the old name and then receive a 404 Page not
found error. Now, the url utilizes the new name.

Signed-off-by: Amanda Brindle 
---
 layerindex/views.py | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/layerindex/views.py b/layerindex/views.py
index eaeb5c3..2a25455 100644
--- a/layerindex/views.py
+++ b/layerindex/views.py
@@ -105,11 +105,6 @@ def edit_layer_view(request, template_name, 
branch='master', slug=None):
 layerbranch = get_object_or_404(LayerBranch, layer=layeritem, 
branch=branchobj)
 deplistlayers = 
LayerItem.objects.exclude(id=layeritem.id).order_by('name')
 returnto = request.GET.get('returnto', 'layer_item')
-if returnto:
-if returnto == 'layer_review':
-return_url = reverse_lazy(returnto, args=(layeritem.name,))
-else:
-return_url = reverse_lazy(returnto, args=(branch, 
layeritem.name))
 else:
 # Submit mode
 layeritem = LayerItem()
@@ -185,6 +180,15 @@ def edit_layer_view(request, template_name, 
branch='master', slug=None):
 msg.send()
 return HttpResponseRedirect(reverse('submit_layer_thanks'))
 messages.success(request, 'Layer %s saved successfully.' % 
layeritem.name)
+if slug:
+returnto = request.GET.get('returnto', 'layer_item')
+if returnto:
+if returnto == 'layer_review':
+return_url = reverse_lazy(returnto, 
args=(layeritem.name,))
+else:
+return_url = reverse_lazy(returnto, args=(branch, 
layeritem.name))
+
+
 if return_url:
 return HttpResponseRedirect(return_url)
 else:
-- 
2.7.4

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

Re: [yocto] release management

2017-08-14 Thread Russell Peterson 
Thanks very much, Gunnar, for your detailed and helpful response.

Not sure I will go the git submodule path.  My initial try is using a script in 
my build environment that pulls in whatever layers it needs via git clone and 
then using a specific commit in a specific branch for that specific build.  The 
cloned layers are considered “read only”.  Right now we clone directly from 
yocto or github but we could easily switch to local, non-public mirrors that we 
could populate to specific versions.

Thanks again!

Regards,

Russell


> On Aug 14, 2017, at 3:10 PM, Gunnar Andersson  wrote:
> 
> 
> Hey Russell
> 
> I don't claim to be an authority on best practices but I will share some
> thoughts.
> 
> On Sun, 2017-08-13 at 06:58 -0400, Russell Peterson wrote:
>> Hello.
>> 
>> As I learn more about yocto and more importantly gain practical experience
>> with it I have started to think about my release structure.  Is there a
>> “best practices” document or something like that that speaks to this?
>> For example, how does everyone deal with “external” meta layer
>> dependencies?  My software uses poky and meta-openembedded, of course.  
> 
> We simply use a parent project [1] that includes git submodules, one per
> yocto layer.  I'm of the opinion that if git (only) can be used, why
> introduce other tools?   But it requires you to learn and master that
> feature.
> 
> For the primary layer that is unique to this project, meta-genivi-dev, we
> later on decided to merge it into the parent git repository instead, but
> keep all other layers as submodules.  Since there are frequent changes to
> the primary layer, it reduces the complexity of having to update a submodule
> for them continuously.  But the purpose is also to keep *only* unique things
> there, and thereby such things that are reusable by others will be naturally
> pushed to the other layers (those that are reusable, and therefore should be
> separate repos).
> 
> There's a natural tradeoff between layers being developed independently (and
> widely reused by other projects), vs. the complexity of hacking on your
> project.
> 
> Other projects use Google's "repo" tool but I have yet to understand what
> that adds compared to git-submodules (in a medium sized project at least),
> other than just additional hoops to jump through.
> 
>> It also relies on some recipes in meta-linaro and meta-virtualization.  I
>> suspect there will be more as time goes by.  I have tweaked my layer
>> priorities as well as used BBMASK to avoid unwanted bbappend files etc…
>> works but seems slightly clunky… still better than duplicating recipes in
>> my meta layer I think.
> 
> I think you've got it.  Those are the tools you have.  I haven't found too
> frequent needs to mask away that which is provided by other layers, but it
> depends on your needs...
> 
>> 
>> Also… I quickly came to the conclusion that “thou shall not modify poky or
>> meta-openembedded”.  
>> That is, ALWAYS use bbappend files instead of modifying external layers.  
> 
> Absolutely that's the Yocto way.  But .bbappends are a kind of patches,
> so who's to say what is right or wrong?  Some people might think that git is
> actually a better tool to keep track of local modifications - keeping those
> on branches that can be efficiently diffed and merged when upstream changes.
> 
> But clearly most Yocto proficient developers will be used to a .bbappend
> based workflow, and I would wager that you will be better received with any
> support questions than if you say "I have made my own branch of poky/meta-
> oe).  Strictly speaking the two option ought to be equivalent, but I'm just
> guessing it will still be perceived differently.  Yocto devs might agree or
> disagree.
> 
> 
>> If I think that poky or some other layer has a recipe bug or want to
>> change something in poky, for example, I plan to upstream a fix to the
>> project and when that becomes available I rebase my poky and remove the
>> bbappend from my meta layer. 
> 
>> One thing about modifying poky and not using bbappend files is that I
>> would then need to ship patches for poky instead of just directing users
>> to to use this branch and this commit for release x.y.z.
> 
> You're not really asking a question here - just drawing the standard open-
> source process conclusions.  I for one agree with you.  Use bbappends.  Talk
> to the upstream.  Always second-guess why you need to change anything at
> all.  Then if the appends become very complex, consider if finally
> overriding with a new .bb file fits better.  
> 
> In our policy that I will describe further (below) we also mostly prefer the
> more explicit separate bbappend files that by virtue of having its own path
> location can be selectively included or not included in the local.conf for
> different project variations.  This feels less magical than having various
> hardware-specific overrides and other deeply embedded tweaks.  But there's
> not 100% right or

[yocto] Idea for bbappend / layer organization and naming convention

2017-08-14 Thread Gunnar Andersson 

Yocto community,

Triggered by the previous email request to yocto@ about best practices for
layer organization I'm finally firing off this email for (hopefully) some
feedback on an idea we first kicked around, discussed for rough consensus
and then decided to implement in the Yocto based GDP project [1].  You can
see it as a trial, anything can be changed, but so far so good...

We adopted a somewhat novel (but actually not really unique, see inside)
naming convention [2] for all modifications to components that belong to
other layers.

This convention shows what layers are being modified by the .bbappends by
actually naming the layer it is (intending to**) modify.  The initiative
also aims to highlight and separate .bbappends (modifications) from uniquely
added components in our project (new .bb files) in GDP.

**Note that we are well aware this does NOT control bitbake behavior (as
neither does the recipe-xxx/ directory convention), and is therefore just a
guide.  If the project is misconfigured, bitbake could do something
different than the naming convention implies and it could even be
misleading, but at least the *programmer intent* is shown clearly.

I think it also makes .bbappends more explicitly visible and might trigger
the idea:   Do we really need this?  Are we really modifying *that* adopted
layer, and if so, why?

To Russel who wrote the previous request for guidance - feel free to
consider, but I won't recommend this directly since it's by no means an
agreed best practice in all of the community.  I'm rather asking for other
experienced OE developers to consider and comment on the idea.  

For oldtimers it's probably easy to find this odd and just be negative
against it since well, "standard practice", inertia, NIH and all that, but
I'll stick my neck out anyway because it seems to solve some issues of
organization and understanding at least for us (and I'm a sucker for some
flamebait ;)

If the intro is too formal and long, just look at the final examples.  I
think you'll get it.  Feel free to ask.


- Gunnar

-- 
Gunnar Andersson 
Development Lead
GENIVI Alliance

[1] https://github.com/GENIVI/genivi-dev-platform
[2] Naming strategy for bitbake extension layers:   
https://at.projects.genivi.org/wiki/x/w4Xk



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

Re: [yocto] release management

2017-08-14 Thread Gunnar Andersson 

Hey Russell

I don't claim to be an authority on best practices but I will share some
thoughts.

On Sun, 2017-08-13 at 06:58 -0400, Russell Peterson wrote:
> Hello.
> 
> As I learn more about yocto and more importantly gain practical experience
> with it I have started to think about my release structure.  Is there a
> “best practices” document or something like that that speaks to this?
> For example, how does everyone deal with “external” meta layer
> dependencies?  My software uses poky and meta-openembedded, of course.  

We simply use a parent project [1] that includes git submodules, one per
yocto layer.  I'm of the opinion that if git (only) can be used, why
introduce other tools?   But it requires you to learn and master that
feature.

For the primary layer that is unique to this project, meta-genivi-dev, we
later on decided to merge it into the parent git repository instead, but
keep all other layers as submodules.  Since there are frequent changes to
the primary layer, it reduces the complexity of having to update a submodule
for them continuously.  But the purpose is also to keep *only* unique things
there, and thereby such things that are reusable by others will be naturally
pushed to the other layers (those that are reusable, and therefore should be
separate repos).

There's a natural tradeoff between layers being developed independently (and
widely reused by other projects), vs. the complexity of hacking on your
project.

Other projects use Google's "repo" tool but I have yet to understand what
that adds compared to git-submodules (in a medium sized project at least),
other than just additional hoops to jump through.

> It also relies on some recipes in meta-linaro and meta-virtualization.  I
> suspect there will be more as time goes by.  I have tweaked my layer
> priorities as well as used BBMASK to avoid unwanted bbappend files etc…
> works but seems slightly clunky… still better than duplicating recipes in
> my meta layer I think.

I think you've got it.  Those are the tools you have.  I haven't found too
frequent needs to mask away that which is provided by other layers, but it
depends on your needs...

> 
> Also… I quickly came to the conclusion that “thou shall not modify poky or
> meta-openembedded”.  
> That is, ALWAYS use bbappend files instead of modifying external layers.  

Absolutely that's the Yocto way.  But .bbappends are a kind of patches,
so who's to say what is right or wrong?  Some people might think that git is
actually a better tool to keep track of local modifications - keeping those
on branches that can be efficiently diffed and merged when upstream changes.

But clearly most Yocto proficient developers will be used to a .bbappend
based workflow, and I would wager that you will be better received with any
support questions than if you say "I have made my own branch of poky/meta-
oe).  Strictly speaking the two option ought to be equivalent, but I'm just
guessing it will still be perceived differently.  Yocto devs might agree or
disagree.


> If I think that poky or some other layer has a recipe bug or want to
> change something in poky, for example, I plan to upstream a fix to the
> project and when that becomes available I rebase my poky and remove the
> bbappend from my meta layer. 

> One thing about modifying poky and not using bbappend files is that I
> would then need to ship patches for poky instead of just directing users
> to to use this branch and this commit for release x.y.z.

You're not really asking a question here - just drawing the standard open-
source process conclusions.  I for one agree with you.  Use bbappends.  Talk
to the upstream.  Always second-guess why you need to change anything at
all.  Then if the appends become very complex, consider if finally
overriding with a new .bb file fits better.  

In our policy that I will describe further (below) we also mostly prefer the
more explicit separate bbappend files that by virtue of having its own path
location can be selectively included or not included in the local.conf for
different project variations.  This feels less magical than having various
hardware-specific overrides and other deeply embedded tweaks.  But there's
not 100% right or wrong here -- it's clearly a case of use the right tool
depending on the situation.

> 
> Comments and suggestions welcome.

In the GENIVI community we decided on a quite specific organization for
layer modifications / bbappends.  I have been meaning to write an email to
gather community feedback on it, but it's better done in a separate thread I
think.

Best Regards
- Gunnar

[1] https://github.com//GENIVI/genivi-dev-platform

-- 
Gunnar Andersson 
Development Lead
GENIVI Alliance


> 
> Regards,
> 
> Russell
> 
> 
> 
> 

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

Re: [yocto] layer.conf on openembedded-core ?

2017-08-14 Thread Christopher Larson 
The openembedded-core root isn’t a layer, openembedded-core/meta is.

On Mon, Aug 14, 2017 at 8:49 AM, Leonardo Sandoval <
leonardo.sandoval.gonza...@linux.intel.com> wrote:

> On Mon, 2017-08-14 at 15:11 +0800, Riko wrote:
> > Dear Yocto Members,
> >
> > How can I find this file ?
>
>
> this is a pretty general question. are you running bitbake from the
> build directory? double check your conf/bblayers.conf and make sure
> paths there are pointing correctly.
>
>
> >
> > ==
> >
> > ERROR: Unable to parse
> > /home/bianchi/poky/openembedded-core/conf/layer.conf: [Errno 2] file
> > /home/bianchi/poky/openembedded-core/conf/layer.conf not found
> >
> >
> > Thanks,
> >
> > Riko
> >
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] layer.conf on openembedded-core ?

2017-08-14 Thread Leonardo Sandoval 
On Mon, 2017-08-14 at 15:11 +0800, Riko wrote:
> Dear Yocto Members,
> 
> How can I find this file ?


this is a pretty general question. are you running bitbake from the
build directory? double check your conf/bblayers.conf and make sure
paths there are pointing correctly.


> 
> ==
> 
> ERROR: Unable to parse 
> /home/bianchi/poky/openembedded-core/conf/layer.conf: [Errno 2] file 
> /home/bianchi/poky/openembedded-core/conf/layer.conf not found
> 
> 
> Thanks,
> 
> Riko
> 


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

[yocto] [meta-oracle-java][PATCH] Fix build for intel 32 bit systems

2017-08-14 Thread Siegfried Steiger 
---
 recipes-devtools/oracle-java/oracle-jse-jdk-i586_1.8.0.bb | 2 +-
 recipes-devtools/oracle-java/oracle-jse-jre_1.8.0.bb  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-devtools/oracle-java/oracle-jse-jdk-i586_1.8.0.bb 
b/recipes-devtools/oracle-java/oracle-jse-jdk-i586_1.8.0.bb
index 318d0f7..05be622 100644
--- a/recipes-devtools/oracle-java/oracle-jse-jdk-i586_1.8.0.bb
+++ b/recipes-devtools/oracle-java/oracle-jse-jdk-i586_1.8.0.bb
@@ -8,4 +8,4 @@ SRC_URI = 
"http://download.oracle.com/otn-pub/java/jdk/8u${PV_UPDATE}-b${BUILD_N
 SRC_URI[md5sum] = "a6741fd674372366546bd8480be735c7"
 SRC_URI[sha256sum] = 
"0069a2b1b1cddbefa45f1ff12933fca3b114b6544d536ec0e2d4861a830d7154"
 
-COMPATIBLE_HOST = "(i586.*-linux)"
+COMPATIBLE_HOST = "(i[56]86.*-linux)"
diff --git a/recipes-devtools/oracle-java/oracle-jse-jre_1.8.0.bb 
b/recipes-devtools/oracle-java/oracle-jse-jre_1.8.0.bb
index ebf0265..19ace5b 100644
--- a/recipes-devtools/oracle-java/oracle-jse-jre_1.8.0.bb
+++ b/recipes-devtools/oracle-java/oracle-jse-jre_1.8.0.bb
@@ -7,7 +7,7 @@ def get_java_pkg(d):
javaPkg = "oracle-jse-ejre-arm-sflt-client-headless"
else:
javaPkg = "oracle-jse-ejre-arm-vfp-hflt-client-headless"
-   elif TA == "i586":
+   elif TA == "i586" or TA == "i686":
javaPkg = "oracle-jse-jre-i586"
elif TA == "x86_64":
javaPkg = "oracle-jse-jre-x86-64"
-- 
2.11.0

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

[yocto] Debugging Yocto Project build failures

2017-08-14 Thread Never Read 
Hi,

I am trying to build a yocto project for a particular platform and get a 
compile error after about 45 minutes or so.

The error is reported as a do_compile error when trying to compile a source 
file for jq-1.5-r0 (JSON stream filter as far as I know). It reports that the 
file main.c could not be found. I have checked the particular directory an can 
see that it is in fact present.

My question is as follows.

Instead of running make to try and debug the problem (which takes ages to reach 
the point of error), is there a way to use do_compile to manually compile/build 
this one item?

I have tried running make in projects directory (where its Makefile is located) 
but this does not work because perhaps it is first necessary to setup the build 
environment first.
It appears that it needs x86_64-poky-linux-gcc to do the compile and on 
searching for this file there are about 8 or 9 versions/copies of this file, 
none of which are on the current path.

If this is the case how would I go about doing this?

I am running Ubuntu 16.04 from VirtualBox.

Regards
FarmerJo

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

Re: [yocto] How to generate cpio.gz AND cpio.gz.u-boot image from single recipe?

2017-08-14 Thread Michal Vokáč 

On 14.8.2017 15:37, Khem Raj wrote:

Please open a bugzilla entry for it

Done.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=11928

Thanks Raj.



On Mon, Aug 14, 2017 at 6:11 AM Michal Vokáč > wrote:

On 11.8.2017 18:31, Khem Raj wrote:
 > On Fri, Aug 11, 2017 at 5:52 AM, Vokáč Michal > wrote:
 >> Hi,
 >>
 >> I am in a process of upgrading our project from Jethro to Morty.
 >> For a while I am trying to solve an issue with generating initramfs 
images.
 >>
 >> We have an image recipe that says:
 >>
 >> IMAGE_FSTYPES = "tar.bz2 cpio.gz cpio.gz.u-boot"
 >> inherit core-image
 >> inherit image_types_uboot
 >>
 >> With the Jethro branch of the openembedded-core layer all thee defined 
image types are generated.
 >>
 >> After upgrade to Morty, the cpio.gz image is deleted somewhere in the 
process of generating
 >> the cpio.gz.u-boot image (which is probably the right behavior of 
image_types_uboot.bbclass).
 >>
 >> I wonder why it worked before and how to make it work again, properly.
 >
 > it is intentional. See
 > 
https://github.com/01org/luv-yocto/commit/09a5cb0cca109395a4835e25d483019ddd5e773c
 >

Thank you Raj, that explain why the gziped image is being removed.

I still need to figure out, how to produce both image types from one recipe.
Lets imagine I went through these steps.

1. I set up the recipe so that the tar.bz2 and cpio.gz images are 
generated.

IMAGE_FSTYPES = "tar.bz2 cpio.gz"
inherit core-image

The tar is just for development debugging and the cpio.gz is packed into
a FIT image that goes into production.

2. After some unspecified time a need arose to produce also
the cpio.gz.u-boot image that can be loaded manually in U-Boot during 
development.

I changed the recipe like this:

IMAGE_FSTYPES = "tar.bz2 cpio.gz cpio.gz.u-boot"
inherit core-image
inherit image_types_uboot

  From my point of view, the image_types_uboot class is removing
the cpio.gz image that was generated by someone else.
In my situation it is not "a middle file" as the commit you referenced says.

I would understand that the cpio.gz is removed when it is not stated in
the IMAGE_FSTYPES variable.

  From reading the IMAGE_FSTYPES variable documentation a user/developer 
can never
get the idea that some image types can not be generated simultaneously.
IMHO a proper behavior would be to generate and preserve all supported image
types stated in the IMAGE_FSTYPES variable.

Any ideas how to achieve that?





CONFIDENTIALITY NOTICE
This message is for the named person's use only. It may contain confidential, 
proprietary or legally privileged information.
If you receive this message in error, please immediately delete it and all 
copies of it from your system, destroy any hard copies of it and notify us by 
email to i...@ysoft.com with a copy of this message. You must not, directly or 
indirectly, use, disclose, distribute, print or copy any part of this message 
if you are not the intended recipient. Y Soft and any of its subsidiaries each 
reserves the right to monitor all e-mail communications through its networks.
Y Soft is neither liable for the proper, complete transmission of the 
information contained in this communication nor any delay in its receipt. This 
email was scanned for the presence of computer viruses. In the unfortunate 
event of infection Y Soft does not accept liability.
Any views expressed in this message are those of the individual sender, except 
where the message states otherwise and the sender is authorised to state them.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW33’17

2017-08-14 Thread Jolley, Stephen K 
Current Dev Position: YP 2.4 M3

Next Deadline: YP 2.4 M3 Cut off is Aug. 21, 2017


SWAT team rotation: Leo -> Juro on Aug. 11, 2017.

SWAT team rotation: Juro -> Paul on Aug. 18, 2017.

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

·YP 2.4 M2 rc3 should be publicly released shortly. This build had much 
better test results than rc2.  See the QA report at: 
https://wiki.yoctoproject.org/wiki/WW32_-_2017-08-09_-_Full_Test_Cycle_2.4_M2_rc3
 And the release Criteria at: 
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.4_Status#Milestone_2_-_Target_July_28.2C_2017

·Patches are flowing into master, albeit slowly. Vacations for various 
people is resulting in high workload for those who aren’t away.

·We’re seeing problems with new symbols in glibc 2.25 (getrandom and 
getentropy) interacting badly with uninative. For now we’re disabling those 
symbols in the native case since most code has fallback code, at least for now. 
We may need a better workaround. We’d prefer to avoid having to make uninative 
glibc version specific.

·The new autobuilder has been updated to newer worker distro instances 
(resulting in some of the failures) but is back to full strength after a while 
running without one or two workers for various issues. Having it at full 
strength should speed up builds/testing.

·YP 2.2 (Morty) is continuing to struggling due to build issues. The 
issue appears to be that certain ppc/lsb lsb images are taking a long time to 
run. We need to understand why the non-lsb images don’t suffer the same issues 
but are struggling to find anyone with the time to look into it properly. We 
need to get these resolved in order to unblock this release series.


Planned upcoming dot releases:

YP 2.2.2 Cut off June 5, 2017 - Not ready to do an rc2 yet.

YP 2.2.2 Release by June, 16 2017

YP 2.3.2 Cut off Sept. 1, 2017

YP 2.3.2 Release by Sept. 15, 2017


Key YP 2.4 Dates are:

YP 2.4 M3 Cut off is Aug. 21, 2017

YP 2.4 M3 Release by Sept. 1, 2017

YP 2.4 M4 (Final) Cut off is Sept. 18, 2017

YP 2.4 M4 (Final) Release by Oct. 20, 2017


Tracking Metrics:

WDD 2480 (last week 2433)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.4_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.4_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.4_Features


[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•   Work Telephone:(503) 712-0534
•Cell:   (208) 244-4460
• Email:  stephen.k.jol...@intel.com

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

Re: [yocto] How to generate cpio.gz AND cpio.gz.u-boot image from single recipe?

2017-08-14 Thread Khem Raj 
Please open a bugzilla entry for it

On Mon, Aug 14, 2017 at 6:11 AM Michal Vokáč  wrote:

> On 11.8.2017 18:31, Khem Raj wrote:
> > On Fri, Aug 11, 2017 at 5:52 AM, Vokáč Michal 
> wrote:
> >> Hi,
> >>
> >> I am in a process of upgrading our project from Jethro to Morty.
> >> For a while I am trying to solve an issue with generating initramfs
> images.
> >>
> >> We have an image recipe that says:
> >>
> >> IMAGE_FSTYPES = "tar.bz2 cpio.gz cpio.gz.u-boot"
> >> inherit core-image
> >> inherit image_types_uboot
> >>
> >> With the Jethro branch of the openembedded-core layer all thee defined
> image types are generated.
> >>
> >> After upgrade to Morty, the cpio.gz image is deleted somewhere in the
> process of generating
> >> the cpio.gz.u-boot image (which is probably the right behavior of
> image_types_uboot.bbclass).
> >>
> >> I wonder why it worked before and how to make it work again, properly.
> >
> > it is intentional. See
> >
> https://github.com/01org/luv-yocto/commit/09a5cb0cca109395a4835e25d483019ddd5e773c
> >
>
> Thank you Raj, that explain why the gziped image is being removed.
>
> I still need to figure out, how to produce both image types from one
> recipe.
> Lets imagine I went through these steps.
>
>1. I set up the recipe so that the tar.bz2 and cpio.gz images are
> generated.
>
>IMAGE_FSTYPES = "tar.bz2 cpio.gz"
>inherit core-image
>
>The tar is just for development debugging and the cpio.gz is packed into
>a FIT image that goes into production.
>
>2. After some unspecified time a need arose to produce also
>the cpio.gz.u-boot image that can be loaded manually in U-Boot during
> development.
>
>I changed the recipe like this:
>
>IMAGE_FSTYPES = "tar.bz2 cpio.gz cpio.gz.u-boot"
>inherit core-image
>inherit image_types_uboot
>
>  From my point of view, the image_types_uboot class is removing
> the cpio.gz image that was generated by someone else.
> In my situation it is not "a middle file" as the commit you referenced
> says.
>
> I would understand that the cpio.gz is removed when it is not stated in
> the IMAGE_FSTYPES variable.
>
>  From reading the IMAGE_FSTYPES variable documentation a user/developer
> can never
> get the idea that some image types can not be generated simultaneously.
> IMHO a proper behavior would be to generate and preserve all supported
> image
> types stated in the IMAGE_FSTYPES variable.
>
> Any ideas how to achieve that?
>
> 
>
> CONFIDENTIALITY NOTICE
> This message is for the named person's use only. It may contain
> confidential, proprietary or legally privileged information.
> If you receive this message in error, please immediately delete it and all
> copies of it from your system, destroy any hard copies of it and notify us
> by email to i...@ysoft.com with a copy of this message. You must not,
> directly or indirectly, use, disclose, distribute, print or copy any part
> of this message if you are not the intended recipient. Y Soft and any of
> its subsidiaries each reserves the right to monitor all e-mail
> communications through its networks.
> Y Soft is neither liable for the proper, complete transmission of the
> information contained in this communication nor any delay in its receipt.
> This email was scanned for the presence of computer viruses. In the
> unfortunate event of infection Y Soft does not accept liability.
> Any views expressed in this message are those of the individual sender,
> except where the message states otherwise and the sender is authorised to
> state them.
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to generate cpio.gz AND cpio.gz.u-boot image from single recipe?

2017-08-14 Thread Michal Vokáč 

On 11.8.2017 18:31, Khem Raj wrote:

On Fri, Aug 11, 2017 at 5:52 AM, Vokáč Michal  wrote:

Hi,

I am in a process of upgrading our project from Jethro to Morty.
For a while I am trying to solve an issue with generating initramfs images.

We have an image recipe that says:

IMAGE_FSTYPES = "tar.bz2 cpio.gz cpio.gz.u-boot"
inherit core-image
inherit image_types_uboot

With the Jethro branch of the openembedded-core layer all thee defined image 
types are generated.

After upgrade to Morty, the cpio.gz image is deleted somewhere in the process 
of generating
the cpio.gz.u-boot image (which is probably the right behavior of 
image_types_uboot.bbclass).

I wonder why it worked before and how to make it work again, properly.


it is intentional. See
https://github.com/01org/luv-yocto/commit/09a5cb0cca109395a4835e25d483019ddd5e773c



Thank you Raj, that explain why the gziped image is being removed.

I still need to figure out, how to produce both image types from one recipe.
Lets imagine I went through these steps.

  1. I set up the recipe so that the tar.bz2 and cpio.gz images are generated.

  IMAGE_FSTYPES = "tar.bz2 cpio.gz"
  inherit core-image

  The tar is just for development debugging and the cpio.gz is packed into
  a FIT image that goes into production.

  2. After some unspecified time a need arose to produce also
  the cpio.gz.u-boot image that can be loaded manually in U-Boot during 
development.

  I changed the recipe like this:

  IMAGE_FSTYPES = "tar.bz2 cpio.gz cpio.gz.u-boot"
  inherit core-image
  inherit image_types_uboot

From my point of view, the image_types_uboot class is removing
the cpio.gz image that was generated by someone else.
In my situation it is not "a middle file" as the commit you referenced says.

I would understand that the cpio.gz is removed when it is not stated in
the IMAGE_FSTYPES variable.

From reading the IMAGE_FSTYPES variable documentation a user/developer can never
get the idea that some image types can not be generated simultaneously.
IMHO a proper behavior would be to generate and preserve all supported image
types stated in the IMAGE_FSTYPES variable.

Any ideas how to achieve that?



CONFIDENTIALITY NOTICE
This message is for the named person's use only. It may contain confidential, 
proprietary or legally privileged information.
If you receive this message in error, please immediately delete it and all 
copies of it from your system, destroy any hard copies of it and notify us by 
email to i...@ysoft.com with a copy of this message. You must not, directly or 
indirectly, use, disclose, distribute, print or copy any part of this message 
if you are not the intended recipient. Y Soft and any of its subsidiaries each 
reserves the right to monitor all e-mail communications through its networks.
Y Soft is neither liable for the proper, complete transmission of the 
information contained in this communication nor any delay in its receipt. This 
email was scanned for the presence of computer viruses. In the unfortunate 
event of infection Y Soft does not accept liability.
Any views expressed in this message are those of the individual sender, except 
where the message states otherwise and the sender is authorised to state them.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] layer.conf on openembedded-core ?

2017-08-14 Thread Riko 

Dear Yocto Members,

How can I find this file ?

==

ERROR: Unable to parse 
/home/bianchi/poky/openembedded-core/conf/layer.conf: [Errno 2] file 
/home/bianchi/poky/openembedded-core/conf/layer.conf not found



Thanks,

Riko

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