[yocto] How do I patch binutils for the SDK

2017-10-11 Thread Paul D. DeRocco 
I found a bug in the GNU assembler that makes it produce corrupted
listings, reported it on sourceware bugzilla, and it has been fixed. Now
I'd like to take those small patches and apply them to the assembler that
winds up in the SDK. The patches are shown here:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=39865a7f420ab4c
a4dec6ed27339618a5d5dc366

The only recipe I found in Pyro that seemed appropriate was
meta/recipes-devtools/binutils/binutils-crosssdk_2.28.bb, so I created a
binutils-crosssdk_%.bbappend in my layer with a FILESEXTRAPATHS_prepend
and a SRC_URI listing the patches, which I put into a binutils
subdirectory.

When I ran the populate_sdk task, the patches failed because they didn't
find the source files, which are supposed to be in a subdirectory called
gas.

So I'm wondering, is this the wrong recipe? Does something else build gas?
Or am I just doing this wrong? The workings of the build system are pretty
opaque and mysterious.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

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

Re: [yocto] How to use two recipes to satisfy different PROVIDES -- gpu support

2017-10-11 Thread Gutierrez, Hernan Ildefonso (Boise R&D, FW) 
Raj,

Thanks for the response.

Is there an example of what you mentioned below which is open source?

So far my two references have been Freescale and Mali. I found mali much 
simpler than Freescale, however Mali GPU doesn't really have a refactor of 
mesa, they only do a simple bbappend to mesa with 
the PROVIDES_remove statement I stated in my original note.

For reference here:  https://github.com/ARM-software/meta-mali

--Hernan



> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: Wednesday, October 11, 2017 7:01 PM
> To: Gutierrez, Hernan Ildefonso (Boise R&D, FW)
> 
> Cc: yocto 
> Subject: Re: [yocto] How to use two recipes to satisfy different PROVIDES --
> gpu support
> 
> On Wed, Oct 11, 2017 at 3:15 PM, Gutierrez, Hernan Ildefonso (Boise R&D,
> FW)  wrote:
> > Hi,
> >
> > We have a GPU in our system. We created a recipe to satisfy all the
> dependencies for core-image-weston (virtual/egl, virtual/libgl, etc.), except
> virtual/mesa, which is not provided by our GPU recipe.
> >
> > When one builds core-image-weston, the image requires mesa to build as
> well.
> >
> > Our approach to satisfy dependencies is very similar to what Freescale and
> other vendors with Mali GPU support use, which is through the following
> statements:
> >
> > PREFERRED_PROVIDER_virtual/egl = "my-gpu-recipe"
> > PREFERRED_PROVIDER_virtual/libgles1 = " my-gpu-recipe "
> > PREFERRED_PROVIDER_virtual/libgles2 = " my-gpu-recipe "
> > PREFERRED_PROVIDER_virtual/libgl = "my-gpu-recipe"
> > PREFERRED_PROVIDER_virtual/mesa = "mesa"
> >
> > The way to remove mesa support for virtual/egl, virtual/libgles1, etc. is by
> adding a mesa_%.bbappend where it states explicitly to remove those
> provides from mesa recipe.
> >
> > e.g.
> > PROVIDES_remove = "virtual/libgles1 virtual/libgles2 virtual/libopenvg
> virtual/egl"
> >
> >
> > The problem I am running into is that bitbake complains stating that
> > virtual/mesa is not satisfied (Nothing PROVIDES 'virtual/mesa')
> >
> > When I do bitbake-layers show-recipes, I see that mesa recipe is skipped
> because it gave priority to my-gpu-recipe.
> >
> > How can two recipes be used and let bitbake satisfy parts of each recipe?
> >
> > Any hints will be appreciated.
> 
> there is no easy way to control providers once a recipe is pulled in.
> you can refactor mesa recipe like we have done for mesa and mesa-gl which
> will mean adding a another recipe which just builds the needed portions of
> mesa in each recipe, if your GPU driver provides everything you need to run
> weston, then you can let it provide everything that mesa provides and
> bitbake wont pick up mesa at all.
> 
> >
> > Thanks,
> >
> > --Hernan
> > --
> > ___
> > 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] [meta-cgl][PATCH 2/2] cgl-common.inc: append SRC_URI for poky-cgl only

2017-10-11 Thread Huang, Jie (Jackie) 


> -Original Message-
> From: Andre McCurdy [mailto:armccu...@gmail.com]
> Sent: Thursday, October 12, 2017 06:51
> To: Huang, Jie (Jackie)
> Cc: Yocto discussion list
> Subject: Re: [yocto] [meta-cgl][PATCH 2/2] cgl-common.inc: append SRC_URI
> for poky-cgl only
> 
> On Mon, Oct 9, 2017 at 8:30 PM,   wrote:
> > From: Jackie Huang 
> >
> > Someone may want to add meta-cgl-common layer into their
> > distro and only use some of the packages, but these kernel
> > features will be also added by the bbappend and may cause
> > unexpected issue, so change to append the SRC_URI for poky-cgl
> > distro only.
> >
> > Signed-off-by: Jackie Huang 
> > ---
> >  meta-cgl-common/recipes-kernel/linux/cgl-common.inc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta-cgl-common/recipes-kernel/linux/cgl-common.inc b/meta-
> cgl-common/recipes-kernel/linux/cgl-common.inc
> > index 52cf773..362a7c4 100644
> > --- a/meta-cgl-common/recipes-kernel/linux/cgl-common.inc
> > +++ b/meta-cgl-common/recipes-kernel/linux/cgl-common.inc
> > @@ -1,6 +1,6 @@
> >  FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> >
> > -SRC_URI += "file://cfg/1-systemtap.cfg \
> > +SRC_URI_append_poky-cgl = "file://cfg/1-systemtap.cfg \
> 
> Needs a leading space.

Fixed and sent v2.

Thanks,
Jackie

> 
> >  file://cfg/2-oprofile.cfg \
> >  file://cfg/3-lttng.cfg \
> >  file://cfg/4-kgdb.cfg \
> > --
> > 2.11.0
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-cgl][PATCH 2/2 v2] cgl-common.inc: append SRC_URI for poky-cgl only

2017-10-11 Thread jackie.huang 
From: Jackie Huang 

Someone may want to add meta-cgl-common layer into their
distro and only use some of the packages, but these kernel
features will be also added by the bbappend and may cause
unexpected issue, so change to append the SRC_URI for poky-cgl
distro only.

Signed-off-by: Jackie Huang 
---
 meta-cgl-common/recipes-kernel/linux/cgl-common.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-cgl-common/recipes-kernel/linux/cgl-common.inc 
b/meta-cgl-common/recipes-kernel/linux/cgl-common.inc
index 52cf773..1c93d7d 100644
--- a/meta-cgl-common/recipes-kernel/linux/cgl-common.inc
+++ b/meta-cgl-common/recipes-kernel/linux/cgl-common.inc
@@ -1,6 +1,6 @@
 FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
 
-SRC_URI += "file://cfg/1-systemtap.cfg \
+SRC_URI_append_poky-cgl = " file://cfg/1-systemtap.cfg \
 file://cfg/2-oprofile.cfg \
 file://cfg/3-lttng.cfg \
 file://cfg/4-kgdb.cfg \
-- 
2.11.0

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

[yocto] [meta-cgl][PATCH 1/2 v2] poky-cgl.conf: add poky-cgl into DISTROOVERRIDES

2017-10-11 Thread jackie.huang 
From: Jackie Huang 

Add poky-cgl into DISTROOVERRIDES, otherwise it's
"poky:linuxstdbase" since it requires poky-lsb.conf.

Signed-off-by: Jackie Huang 
---
 meta-cgl-common/conf/distro/poky-cgl.conf | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta-cgl-common/conf/distro/poky-cgl.conf 
b/meta-cgl-common/conf/distro/poky-cgl.conf
index 92c2ac8..269ce49 100644
--- a/meta-cgl-common/conf/distro/poky-cgl.conf
+++ b/meta-cgl-common/conf/distro/poky-cgl.conf
@@ -1,6 +1,7 @@
 require conf/distro/poky-lsb.conf
 
 DISTRO = "poky-cgl"
+DISTROOVERRIDES .= ":poky-cgl"
 
 DISTRO_FEATURES_append = " selinux ptest argp ext2 xattr nfs pci ipv4 ipv6"
 
-- 
2.11.0

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

[yocto] [meta-cgl][PATCH 0/2 v2] poky-cgl: avoid the linux bbappend adding cfgs for other distro

2017-10-11 Thread jackie.huang 
From: Jackie Huang 

v2 changes:
add the missing leading space for _append.


--
The following changes since commit 73d32950c45cc8d8d468e584be68c54c6e6574b9:

  kernel: Fix config warning for CONFIG_I2C_ALGOBIT (2017-10-03 10:15:47 +0200)

are available in the git repository at:

  https://github.com/jackiehjm/meta-cgl.git jhuang0/d_poky-cgl-kernel_171012_0
  https://github.com//tree/jhuang0/d_poky-cgl-kernel_171012_0

Jackie Huang (2):
  poky-cgl.conf: add poky-cgl into DISTROOVERRIDES
  cgl-common.inc: append SRC_URI for poky-cgl only

 meta-cgl-common/conf/distro/poky-cgl.conf   | 1 +
 meta-cgl-common/recipes-kernel/linux/cgl-common.inc | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

-- 
2.11.0

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

Re: [yocto] How to use two recipes to satisfy different PROVIDES -- gpu support

2017-10-11 Thread Khem Raj 
On Wed, Oct 11, 2017 at 3:15 PM, Gutierrez, Hernan Ildefonso (Boise
R&D, FW)  wrote:
> Hi,
>
> We have a GPU in our system. We created a recipe to satisfy all the 
> dependencies for core-image-weston (virtual/egl, virtual/libgl, etc.), except 
> virtual/mesa, which is not provided by our GPU recipe.
>
> When one builds core-image-weston, the image requires mesa to build as well.
>
> Our approach to satisfy dependencies is very similar to what Freescale and 
> other vendors with Mali GPU support use, which is through the following 
> statements:
>
> PREFERRED_PROVIDER_virtual/egl = "my-gpu-recipe"
> PREFERRED_PROVIDER_virtual/libgles1 = " my-gpu-recipe "
> PREFERRED_PROVIDER_virtual/libgles2 = " my-gpu-recipe "
> PREFERRED_PROVIDER_virtual/libgl = "my-gpu-recipe"
> PREFERRED_PROVIDER_virtual/mesa = "mesa"
>
> The way to remove mesa support for virtual/egl, virtual/libgles1, etc. is by 
> adding a mesa_%.bbappend where it states explicitly to remove those provides 
> from mesa recipe.
>
> e.g.
> PROVIDES_remove = "virtual/libgles1 virtual/libgles2 virtual/libopenvg 
> virtual/egl"
>
>
> The problem I am running into is that bitbake complains stating that 
> virtual/mesa is not satisfied (Nothing PROVIDES 'virtual/mesa')
>
> When I do bitbake-layers show-recipes, I see that mesa recipe is skipped 
> because it gave priority to my-gpu-recipe.
>
> How can two recipes be used and let bitbake satisfy parts of each recipe?
>
> Any hints will be appreciated.

there is no easy way to control providers once a recipe is pulled in.
you can refactor mesa recipe like we have done for mesa and mesa-gl
which will mean adding a another recipe which just builds the needed
portions of mesa in each recipe, if your GPU driver provides everything
you need to run weston, then you can let it provide everything that mesa
provides and bitbake wont pick up mesa at all.

>
> Thanks,
>
> --Hernan
> --
> ___
> 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] [meta-cgl][PATCH 2/2] cgl-common.inc: append SRC_URI for poky-cgl only

2017-10-11 Thread Andre McCurdy 
On Mon, Oct 9, 2017 at 8:30 PM,   wrote:
> From: Jackie Huang 
>
> Someone may want to add meta-cgl-common layer into their
> distro and only use some of the packages, but these kernel
> features will be also added by the bbappend and may cause
> unexpected issue, so change to append the SRC_URI for poky-cgl
> distro only.
>
> Signed-off-by: Jackie Huang 
> ---
>  meta-cgl-common/recipes-kernel/linux/cgl-common.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta-cgl-common/recipes-kernel/linux/cgl-common.inc 
> b/meta-cgl-common/recipes-kernel/linux/cgl-common.inc
> index 52cf773..362a7c4 100644
> --- a/meta-cgl-common/recipes-kernel/linux/cgl-common.inc
> +++ b/meta-cgl-common/recipes-kernel/linux/cgl-common.inc
> @@ -1,6 +1,6 @@
>  FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>
> -SRC_URI += "file://cfg/1-systemtap.cfg \
> +SRC_URI_append_poky-cgl = "file://cfg/1-systemtap.cfg \

Needs a leading space.

>  file://cfg/2-oprofile.cfg \
>  file://cfg/3-lttng.cfg \
>  file://cfg/4-kgdb.cfg \
> --
> 2.11.0
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] How to use two recipes to satisfy different PROVIDES -- gpu support

2017-10-11 Thread Gutierrez, Hernan Ildefonso (Boise R&D, FW) 
Hi,

We have a GPU in our system. We created a recipe to satisfy all the 
dependencies for core-image-weston (virtual/egl, virtual/libgl, etc.), except 
virtual/mesa, which is not provided by our GPU recipe.

When one builds core-image-weston, the image requires mesa to build as well.

Our approach to satisfy dependencies is very similar to what Freescale and 
other vendors with Mali GPU support use, which is through the following 
statements:

PREFERRED_PROVIDER_virtual/egl = "my-gpu-recipe"
PREFERRED_PROVIDER_virtual/libgles1 = " my-gpu-recipe "
PREFERRED_PROVIDER_virtual/libgles2 = " my-gpu-recipe "
PREFERRED_PROVIDER_virtual/libgl = "my-gpu-recipe"
PREFERRED_PROVIDER_virtual/mesa = "mesa"

The way to remove mesa support for virtual/egl, virtual/libgles1, etc. is by 
adding a mesa_%.bbappend where it states explicitly to remove those provides 
from mesa recipe.

e.g.
PROVIDES_remove = "virtual/libgles1 virtual/libgles2 virtual/libopenvg 
virtual/egl"


The problem I am running into is that bitbake complains stating that 
virtual/mesa is not satisfied (Nothing PROVIDES 'virtual/mesa')

When I do bitbake-layers show-recipes, I see that mesa recipe is skipped 
because it gave priority to my-gpu-recipe.

How can two recipes be used and let bitbake satisfy parts of each recipe?

Any hints will be appreciated.

Thanks,

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

Re: [yocto] image dependent pkg versions/pkg variations

2017-10-11 Thread Andre McCurdy 
On Wed, Oct 11, 2017 at 11:24 AM, Robert Berger
 wrote:
> Hi,
>
> 3) Different package versions depending on the image recipe?
> Well actually I would like to have root file systems with different recipe
> versions inside
> e.g.
> Customer 1: prg1_1.1.bb, prg2_2.2.bb
> Customer 2: prg1_1.2.bb, prg2_2.1.bb
>
> 4) Different package variants (e.g. extra compile flags) depending on the
> image recipe? Again different content of rootfs.
> e.g.
> Customer 3: prg1_1.1.bb (default), prg2_2.2.bb with extra CFLAGS=-DUMMY)
> Customer 4: prg1_1.2.bb (default), prg2_2.1.bb(default)
>
> ===
>
> Is this possible at all?
>
> I could define per distro image versions, but the name of the distro e.g.
> "poky" seems to be part of the compiler prefix, which is not nice and I
> would need to build the same toolchain multiple times, which again is not
> nice.
>
> If the choice is based on e.g. the distro variable I could use it to
> distinguish in the recipes between different build variations, but again not
> nice.
>
> What would you suggest?

Create additional variants of the machine config to cover each case,
e.g. myboard.conf, myboard-debug.conf, myboard-dummy.conf, etc

The -debug, -dummy, etc variants can include the original base version
of the machine config file, so there doesn't need to be any
duplication.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] errors in recipe after move from devtool

2017-10-11 Thread Greg Wilson-Lindberg 
Hi Paul,

That did the trick. Thanks, you've been more than helpful.

Cheers,
Greg

> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: Wednesday, October 11, 2017 12:56 PM
> To: Greg Wilson-Lindberg 
> Cc: yocto@yoctoproject.org; Burton, Ross 
> Subject: Re: [yocto] errors in recipe after move from devtool
> 
> On Thursday, 12 October 2017 6:07:55 AM NZDT Greg Wilson-Lindberg wrote:
> > Thanks for the info, now I understand what is going on. Hopefully I
> > can find a way to get rid of the RPATH, I don't like ignoring errors or
> warnings.
> >
> > I've spent some more time looking into this, I haven't been able to
> > find out where the -rpath comes from. If I start a devshell none of
> > the environment variables have it set. In the run.do_compile log none
> > of the environment variables have it set, it's not set in the
> > run.do_configure log. But in the log.do_compile file the command that links
> the library:
> >
> > /home/gwilson/Qt-5.9/Yocto-build-RPi3/build-raspberrypi3/tmp/sysroots/
> > x86_64-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc
> ...
> > -Wl,-rpath,/usr/lib
> >
> > There it is at the end of the command line.
> >
> > As you can see the build for zint is based on CMake. Do you have any
> > suggestions as to where I can look to figure out how this is getting
> > set, I've done searches of all of the files in the zint download and
> > the only ones that have -rpath in them are some files that build a tcl
> > based support program that has its own autotools based build system.
> 
> This seems to be something that CMake handles itself. From a quick google
> which found the CMake wiki page on the subject [1], you may perhaps set
> CMAKE_SKIP_RPATH? In theory you could do that via EXTRA_OECMAKE in
> the recipe i.e.
> 
> EXTRA_OECMAKE += "-DCMAKE_SKIP_RPATH=TRUE"
> 
> Cheers,
> Paul
> 
> [1] https://cmake.org/Wiki/CMake_RPATH_handling
> 
> --
> 
> Paul Eggleton
> Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] errors in recipe after move from devtool

2017-10-11 Thread Paul Eggleton 
On Thursday, 12 October 2017 6:07:55 AM NZDT Greg Wilson-Lindberg wrote:
> Thanks for the info, now I understand what is going on. Hopefully I can find
> a way to get rid of the RPATH, I don't like ignoring errors or warnings.
> 
> I've spent some more time looking into this, I haven't been able to find out
> where the -rpath comes from. If I start a devshell none of the environment
> variables have it set. In the run.do_compile log none of the environment
> variables have it set, it's not set in the run.do_configure log. But in the
> log.do_compile file the command that links the library:
> 
> /home/gwilson/Qt-5.9/Yocto-build-RPi3/build-raspberrypi3/tmp/sysroots/
> x86_64-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc ... 
> -Wl,-rpath,/usr/lib 
> 
> There it is at the end of the command line.
> 
> As you can see the build for zint is based on CMake. Do you have any
> suggestions as to where I can look to figure out how this is getting set,
> I've done searches of all of the files in the zint download and the only
> ones that have -rpath in them are some files that build a tcl based support
> program that has its own autotools based build system.

This seems to be something that CMake handles itself. From a quick google 
which found the CMake wiki page on the subject [1], you may perhaps set 
CMAKE_SKIP_RPATH? In theory you could do that via EXTRA_OECMAKE in the recipe
i.e.

EXTRA_OECMAKE += "-DCMAKE_SKIP_RPATH=TRUE"

Cheers,
Paul

[1] https://cmake.org/Wiki/CMake_RPATH_handling

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] image dependent pkg versions/pkg variations

2017-10-11 Thread Robert Berger 

Hi,

I would like something like this:

1) Produce just a single toolchain like

2) Choose packages depending on image recipe

So far so good. This should be pretty standard, but

3) Different package versions depending on the image recipe?
Well actually I would like to have root file systems with different 
recipe versions inside

e.g.
Customer 1: prg1_1.1.bb, prg2_2.2.bb
Customer 2: prg1_1.2.bb, prg2_2.1.bb

4) Different package variants (e.g. extra compile flags) depending on 
the image recipe? Again different content of rootfs.

e.g.
Customer 3: prg1_1.1.bb (default), prg2_2.2.bb with extra CFLAGS=-DUMMY)
Customer 4: prg1_1.2.bb (default), prg2_2.1.bb(default)

===

Is this possible at all?

I could define per distro image versions, but the name of the distro 
e.g. "poky" seems to be part of the compiler prefix, which is not nice 
and I would need to build the same toolchain multiple times, which again 
is not nice.


If the choice is based on e.g. the distro variable I could use it to 
distinguish in the recipes between different build variations, but again 
not nice.


What would you suggest?

Regards,

Robert



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

Re: [yocto] Basic question: "core-image-minimal" v.s "core-image-base" ?

2017-10-11 Thread Andre McCurdy 
On Wed, Oct 11, 2017 at 9:30 AM, Jerry Lian  wrote:
> Thanks for answers from Ross and Andre.
> Now further question:
> * If we look at file \poky\meta\recipes-core\images\core-image-minimal.bb
> 
> SUMMARY = "A small image just capable of allowing a device to boot."
>
> IMAGE_INSTALL = "packagegroup-core-boot ${CORE_IMAGE_EXTRA_INSTALL}"
>
> IMAGE_LINGUAS = " "
>
> LICENSE = "MIT"
>
> inherit core-image
> 
> * "inherit core-image" comes after "IMAGE_INSTALL = ..."
> * Will the "IMAGE_INSTALL" in this file be overridden by "IMAGE_INSTALL" in
> "core-image"
>
> So what is the rule for "overridden"?

http://www.yoctoproject.org/docs/2.3/bitbake-user-manual/bitbake-user-manual.html#basic-syntax
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2017-10-11 Thread Fabien Lahoudere 
Maxin,

Is this patch submitted or applied for next release?

Thanks

On Wed, 2017-10-11 at 14:37 +0300, Maxin B. John wrote:
> Hi Fabien,
> 
> On Wed, 2017-10-11 at 13:06 +0300, Henrik Lindblom wrote:
> > > I think you'll want RDEPENDS instead of DEPENDS in your recipe. DEPENDS 
> > > implies build time
> > > dependencies (e.g. libraries) while RDEPENDS actually gets the component 
> > > installed as a
> > > runtime
> > > dependency.
> > > 
> > Thanks Henrik
> > I tried to add RDEPENDS too without success. The problem is that users and 
> > groups are not
> > installed
> > IIUC.
> 
> Could you apply this patch and see if it helps here ?
> 
> Best Regards,
> Maxin
-- 
Fabien
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2017-10-11 Thread Fabien Lahoudere 
Thanks a lot Maxin

Your patch fix the issue.

\o/

On Wed, 2017-10-11 at 14:37 +0300, Maxin B. John wrote:
> Hi Fabien,
> 
> On Wed, 2017-10-11 at 13:06 +0300, Henrik Lindblom wrote:
> > > I think you'll want RDEPENDS instead of DEPENDS in your recipe. DEPENDS 
> > > implies build time
> > > dependencies (e.g. libraries) while RDEPENDS actually gets the component 
> > > installed as a
> > > runtime
> > > dependency.
> > > 
> > Thanks Henrik
> > I tried to add RDEPENDS too without success. The problem is that users and 
> > groups are not
> > installed
> > IIUC.
> 
> Could you apply this patch and see if it helps here ?
> 
> Best Regards,
> Maxin
-- 
Fabien
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] errors in recipe after move from devtool

2017-10-11 Thread Greg Wilson-Lindberg 
Hi Paul,
Thanks for the info, now I understand what is going on. Hopefully I can find a 
way to get rid of the RPATH, I don't like ignoring errors or warnings.

I've spent some more time looking into this, I haven't been able to find out 
where the -rpath comes from. If I start a devshell none of the environment 
variables have it set. In the run.do_compile log none of the environment 
variables have it set, it's not set in the run.do_configure log. But in the 
log.do_compile file the command that links the library:

/home/gwilson/Qt-5.9/Yocto-build-RPi3/build-raspberrypi3/tmp/sysroots/x86_64-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc
  -fPIC  -march=armv7ve -marm -mfpu=neon-vfpv4  -mfloat-abi=hard 
-mcpu=cortex-a7  
--sysroot=/home/gwilson/Qt-5.9/Yocto-build-RPi3/build-raspberrypi3/tmp/sysroots/raspberrypi3
 -O2 -pipe -g -feliminate-unused-debug-types 
-fdebug-prefix-map=/home/gwilson/Qt-5.9/Yocto-build-RPi3/build-raspberrypi3/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/zint/2.6.1-r0=/usr/src/debug/zint/2.6.1-r0
 
-fdebug-prefix-map=/home/gwilson/Qt-5.9/Yocto-build-RPi3/build-raspberrypi3/tmp/sysroots/x86_64-linux=
 
-fdebug-prefix-map=/home/gwilson/Qt-5.9/Yocto-build-RPi3/build-raspberrypi3/tmp/sysroots/raspberrypi3=
  -march=armv7ve -marm -mfpu=neon-vfpv4  -mfloat-abi=hard -mcpu=cortex-a7  
--sysroot=/home/gwilson/Qt-5.9/Yocto-build-RPi3/build-raspberrypi3/tmp/sysroots/raspberrypi3
 -O2 -g -DNDEBUG  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -shared 
-Wl,-soname,libzint
 .so.2.6 -o libzint.so.2.6.1 CMakeFiles/zint.dir/render.c.o 
CMakeFiles/zint.dir/ps.c.o CMakeFiles/zint.dir/svg.c.o 
CMakeFiles/zint.dir/emf.c.o CMakeFiles/zint.dir/bmp.c.o 
CMakeFiles/zint.dir/pcx.c.o CMakeFiles/zint.dir/gif.c.o 
CMakeFiles/zint.dir/png.c.o CMakeFiles/zint.dir/tif.c.o 
CMakeFiles/zint.dir/raster.c.o CMakeFiles/zint.dir/common.c.o 
CMakeFiles/zint.dir/library.c.o CMakeFiles/zint.dir/large.c.o 
CMakeFiles/zint.dir/reedsol.c.o CMakeFiles/zint.dir/gs1.c.o 
CMakeFiles/zint.dir/eci.c.o CMakeFiles/zint.dir/code.c.o 
CMakeFiles/zint.dir/code128.c.o CMakeFiles/zint.dir/2of5.c.o 
CMakeFiles/zint.dir/upcean.c.o CMakeFiles/zint.dir/telepen.c.o 
CMakeFiles/zint.dir/medical.c.o CMakeFiles/zint.dir/plessey.c.o 
CMakeFiles/zint.dir/rss.c.o CMakeFiles/zint.dir/postal.c.o 
CMakeFiles/zint.dir/auspost.c.o CMakeFiles/zint.dir/imail.c.o 
CMakeFiles/zint.dir/code16k.c.o CMakeFiles/zint.dir/codablock.c.o 
CMakeFiles/zint.dir/dmatrix.c.o CMakeFiles/zint.dir/pdf417.c.o 
CMakeFiles/zint.dir/qr.c.o C
 MakeFiles/zint.dir/maxicode.c.o CMakeFiles/zint.dir/composite.c.o 
CMakeFiles/zint.dir/aztec.c.o CMakeFiles/zint.dir/code49.c.o 
CMakeFiles/zint.dir/code1.c.o CMakeFiles/zint.dir/gridmtx.c.o 
CMakeFiles/zint.dir/hanxin.c.o CMakeFiles/zint.dir/dotcode.c.o -lpng -lz -lm 
-Wl,-rpath,/usr/lib 

There it is at the end of the command line.

As you can see the build for zint is based on CMake. Do you have any 
suggestions as to where I can look to figure out how this is getting set, I've 
done searches of all of the files in the zint download and the only ones that 
have -rpath in them are some files that build a tcl based support program that 
has its own autotools based build system.

I'm very confused at this point.

Regards,
Greg

> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: Tuesday, October 10, 2017 2:16 PM
> To: Greg Wilson-Lindberg 
> Cc: yocto@yoctoproject.org; Burton, Ross 
> Subject: Re: [yocto] errors in recipe after move from devtool
> 
> Hi Greg,
> 
> On Wednesday, 11 October 2017 7:50:45 AM NZDT Greg Wilson-Lindberg
> wrote:
> > I'm still getting the:
> >
> > ERROR: zint-2.6.1-r0 do_package_qa: QA Issue: zint:
> > /work/cortexa7hf-neon-
> > vfpv4-poky-linux-gnueabi/zint/2.6.1-r0/packages-split/zint/usr/lib/
> > libzint.so.2.6.1 contains probably-redundant RPATH /usr/lib
> 
> There's a short hint about this QA issue in the manual:
> 
>   http://www.yoctoproject.org/docs/current/ref-manual/ref-
> manual.html#ref-qa-checks
> 
> Ultimately it depends on the build system for the software your recipe is
> building, but somewhere it will be explicitly adding this rpath to the 
> compiler
> command line, so you need to figure out the best way to remove that - if the
> software's build system makes it optional, turn it off, but you may find you
> need to patch it out. If you don't care about this particular issue, you could
> alternatively use INSANE_SKIP to ignore it.
> 
> Cheers,
> Paul
> 
> --
> 
> Paul Eggleton
> Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Basic question: "core-image-minimal" v.s "core-image-base" ?

2017-10-11 Thread Jerry Lian 
Thanks for answers from Ross and Andre.
Now further question:
* If we look at file \poky\meta\recipes-core\images\core-image-minimal.bb


SUMMARY = "A small image just capable of allowing a device to boot."

IMAGE_INSTALL = "packagegroup-core-boot ${CORE_IMAGE_EXTRA_INSTALL}"

IMAGE_LINGUAS = " "

LICENSE = "MIT"

inherit core-image

* "inherit core-image" *comes after* "IMAGE_INSTALL = ..."
* Will the "IMAGE_INSTALL" in this file be overridden by "IMAGE_INSTALL" in
"core-image"

So what is the rule for "overridden"?

On Tue, Oct 10, 2017 at 6:07 PM, Andre McCurdy  wrote:

> On Fri, Oct 6, 2017 at 1:40 PM, Jerry Lian  wrote:
> > Hi, all:
> >
> > I have a basic question: how to tell the difference between
> > "core-image-minimal" and "core-image-base"?
> > * If we look at file \poky\meta\recipes-core\images\core-image-base.bb
> > 
> ===
> > SUMMARY = "A console-only image that fully supports the target device
> > hardware."
> >
> > IMAGE_FEATURES += "splash"
> >
> > LICENSE = "MIT"
> >
> > inherit core-image
> > 
> ===
> > * how can we tell that "core-image-base" will include "support for a
> variety
> > of hardware such as WIFI, bluetooth...", as compare to
> "core-image-minimal"?
> > * Do I miss any other document that I need to read?
>
> core-image-base takes the default value of IMAGE_INSTALL from
> meta/classes/core-image.bbclass, but core-image-minimal over-rides the
> default value and effectively removes packagegroup-base-extended.
>
> See meta/recipes-core/packagegroups/packagegroup-base.bb for more
> details of what gets pulled in by packagegroup-base-extended.
>
> > Thanks!
> > Jerry
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] pb when building core-image-sato

2017-10-11 Thread Stéphane Ancelot 

Hi,

I don't know where it can com from,  but I have following mistake from 
toaster when building qemux86-64 core-sato-image :


bash -c "source 
/var/www/toaster/poky/_toaster_clones/_git___git.yoctoproject.org_poky_master/oe-init-build-env 
/var/www/toaster/poky/build-toaster-6; BITBAKE_UI="knotty" 
/var/www/toaster/poky/_toaster_clones/_git___git.yoctoproject.org_poky_master/bitbake/bin/bitbake 
--read /var/www/toaster/poky/build-toaster-6/conf/toaster.conf --read 
/var/www/toaster/poky/build-toaster-6/conf/toaster-bblayers.conf 
--server-only -t xmlrpc -B 0.0.0.0:0"



bitbake: error: no such option: -t


Regards

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

Re: [yocto] Adding test case in LTP in Yocto

2017-10-11 Thread Alexander Kanavin 

On 10/11/2017 03:28 PM, Umamahesh Yelchuruvenkata wrote:

Hi Maxin,

Thanks for the reply. Before sending it for review, I have to test via 
LTP/Yocto.  I am new to yocto /LTP, trying to understand how to add it.
It is that only way to add my files is through patch files?.

Please suggest.


You can use 'devtool modify ltp' to get a local copy of ltp source tree, 
and then modify it as needed. Then issue 'bitbake ' as usual to 
build an image with the local modifications to ltp. When you are happy, 
create commits using git in the local source tree of ltp, and issue 
'devtool update-recipe ltp' to get them added as patches to the ltp recipe.


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

Re: [yocto] Adding test case in LTP in Yocto

2017-10-11 Thread Umamahesh Yelchuruvenkata 
Hi Maxin,

Thanks for the reply. Before sending it for review, I have to test via 
LTP/Yocto.  I am new to yocto /LTP, trying to understand how to add it.
It is that only way to add my files is through patch files?. 

Please suggest.

Thanks
Umamahesh

-Original Message-
From: Maxin B. John [mailto:maxin.j...@intel.com] 
Sent: 11 October 2017 17:44
To: Umamahesh Yelchuruvenkata 
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Adding test case in LTP in Yocto

Hi Umamahesh, 

>Hi,
>
>Anyone suggest me how to add an test case in LTP (Linux Test Procedure) in 
>Yocto distribution.
>
>  Please suggest.

Prepare patch for Linux Test Project and then, update the ltp recipe by 
following the steps mentioned here:
http://www.yoctoproject.org/docs/2.3.2/mega-manual/mega-manual.html#new-recipe-patching-code

You could also send the new test case to LTP mailing list (l...@lists.linux.it) 
for review. Then, it could be included in the next release and will be part of 
the distro later (slow process)

>   Thanks
>   Umamahesh

Best Regards,
Maxin


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.



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

Re: [yocto] Adding test case in LTP in Yocto

2017-10-11 Thread Maxin B. John 
Hi Umamahesh, 

>Hi,
>
>Anyone suggest me how to add an test case in LTP (Linux Test Procedure) in 
>Yocto distribution.
>
>  Please suggest.

Prepare patch for Linux Test Project and then, update the ltp recipe by 
following the steps
mentioned here:
http://www.yoctoproject.org/docs/2.3.2/mega-manual/mega-manual.html#new-recipe-patching-code

You could also send the new test case to LTP mailing list (l...@lists.linux.it) 
for review. Then,
it could be included in the next release and will be part of the distro later 
(slow process)

>   Thanks
>   Umamahesh

Best Regards,
Maxin
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2017-10-11 Thread Maxin B. John 
Hi Fabien,

On Wed, 2017-10-11 at 13:06 +0300, Henrik Lindblom wrote:
>> I think you'll want RDEPENDS instead of DEPENDS in your recipe. DEPENDS 
>> implies build time
>> dependencies (e.g. libraries) while RDEPENDS actually gets the component 
>> installed as a runtime
>> dependency.
>> 

>Thanks Henrik
>I tried to add RDEPENDS too without success. The problem is that users and 
>groups are not installed
>IIUC.

Could you apply this patch and see if it helps here ?

Best Regards,
Maxin
>From 36c75e348cd5bb3cff242783550b925623492297 Mon Sep 17 00:00:00 2001
From: "Maxin B. John" 
Date: Wed, 20 Sep 2017 18:05:49 +0300
Subject: [PATCH] sstate.bbclass: provide an exception for useradd scenario

Packages, which depend on users/groups created from other packages,
needs "shadow-native" as a build time dependency. So, add an exception
to the "shadow-native" from otherwise discarded native/cross tools
dependency.

Fixes [YOCTO #11960]

Signed-off-by: Maxin B. John 
---
 meta/classes/sstate.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 2a54993..e30fbe1 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -967,7 +967,8 @@ def setscene_depvalid(task, taskdependees, notneeded, d, 
log=None):
 if isNativeCross(taskdependees[dep][0]):
 return False
 # Native/cross tools depended upon by target sysroot are not needed
-if isNativeCross(taskdependees[task][0]):
+# Add an exception for shadow-native as required by useradd.bbclass
+if isNativeCross(taskdependees[task][0]) and 
taskdependees[task][0] != 'shadow-native':
 continue
 # Target populate_sysroot need their dependencies
 return False
-- 
2.4.0

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

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

2017-10-11 Thread Burton, Ross 
For this you definitely want DEPENDS.  Read the do_prepare_sysroot log to
for the recipe you're building, it might have an error that isn't causing
the build to fail.

Ross

On 11 October 2017 at 11:18, Fabien Lahoudere <
fabien.lahoud...@collabora.co.uk> wrote:

> On Wed, 2017-10-11 at 13:06 +0300, Henrik Lindblom wrote:
>
> I think you'll want RDEPENDS instead of DEPENDS in your recipe. DEPENDS
> implies build time dependencies (e.g. libraries) while RDEPENDS actually
> gets the component installed as a runtime dependency.
>
>
> Thanks Henrik
>
> I tried to add RDEPENDS too without success. The problem is that users and
> groups are not installed IIUC.
>
> On Wed, Oct 11, 2017 at 12:16 PM, Fabien Lahoudere <
> fabien.lahoud...@collabora.co.uk> wrote:
>
> FI, with bitbake testuser -c devshell
>
> # cat ../1.0-r1/recipe-sysroot/etc/passwd
> root::0:0:root:/root:/bin/sh
> daemon:*:1:1:daemon:/usr/sbin:/bin/sh
> bin:*:2:2:bin:/bin:/bin/sh
> sys:*:3:3:sys:/dev:/bin/sh
> sync:*:4:65534:sync:/bin:/bin/sync
> games:*:5:60:games:/usr/games:/bin/sh
> man:*:6:12:man:/var/cache/man:/bin/sh
> lp:*:7:7:lp:/var/spool/lpd:/bin/sh
> mail:*:8:8:mail:/var/mail:/bin/sh
> news:*:9:9:news:/var/spool/news:/bin/sh
> uucp:*:10:10:uucp:/var/spool/uucp:/bin/sh
> proxy:*:13:13:proxy:/bin:/bin/sh
> www-data:*:33:33:www-data:/var/www:/bin/sh
> backup:*:34:34:backup:/var/backups:/bin/sh
> list:*:38:38:Mailing List Manager:/var/list:/bin/sh
> irc:*:39:39:ircd:/var/run/ircd:/bin/sh
> gnats:*:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
> nobody:*:65534:65534:nobody:/nonexistent:/bin/sh
>
>
> Users are not found
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
> --
>
> Fabien
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2017-10-11 Thread Fabien Lahoudere 
On Wed, 2017-10-11 at 13:06 +0300, Henrik Lindblom wrote:
> I think you'll want RDEPENDS instead of DEPENDS in your recipe. DEPENDS 
> implies build time
> dependencies (e.g. libraries) while RDEPENDS actually gets the component 
> installed as a runtime
> dependency.
> 

Thanks Henrik
I tried to add RDEPENDS too without success. The problem is that users and 
groups are not installed
IIUC.
> On Wed, Oct 11, 2017 at 12:16 PM, Fabien Lahoudere 
>  wrote:
> > FI, with bitbake testuser -c devshell
> > 
> > # cat ../1.0-r1/recipe-sysroot/etc/passwd 
> > root::0:0:root:/root:/bin/sh
> > daemon:*:1:1:daemon:/usr/sbin:/bin/sh
> > bin:*:2:2:bin:/bin:/bin/sh
> > sys:*:3:3:sys:/dev:/bin/sh
> > sync:*:4:65534:sync:/bin:/bin/sync
> > games:*:5:60:games:/usr/games:/bin/sh
> > man:*:6:12:man:/var/cache/man:/bin/sh
> > lp:*:7:7:lp:/var/spool/lpd:/bin/sh
> > mail:*:8:8:mail:/var/mail:/bin/sh
> > news:*:9:9:news:/var/spool/news:/bin/sh
> > uucp:*:10:10:uucp:/var/spool/uucp:/bin/sh
> > proxy:*:13:13:proxy:/bin:/bin/sh
> > www-data:*:33:33:www-data:/var/www:/bin/sh
> > backup:*:34:34:backup:/var/backups:/bin/sh
> > list:*:38:38:Mailing List Manager:/var/list:/bin/sh
> > irc:*:39:39:ircd:/var/run/ircd:/bin/sh
> > gnats:*:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
> > nobody:*:65534:65534:nobody:/nonexistent:/bin/sh
> > 
> > Users are not found
> > --
> > 
> > ___
> > 
> > yocto mailing list
> > 
> > yocto@yoctoproject.org
> > 
> > https://lists.yoctoproject.org/listinfo/yocto
> > 
> > 
-- 
Fabien-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2017-10-11 Thread Henrik Lindblom 
I think you'll want RDEPENDS instead of DEPENDS in your recipe. DEPENDS
implies build time dependencies (e.g. libraries) while RDEPENDS actually
gets the component installed as a runtime dependency.

On Wed, Oct 11, 2017 at 12:16 PM, Fabien Lahoudere <
fabien.lahoud...@collabora.co.uk> wrote:

> FI, with bitbake testuser -c devshell
>
> # cat ../1.0-r1/recipe-sysroot/etc/passwd
> root::0:0:root:/root:/bin/sh
> daemon:*:1:1:daemon:/usr/sbin:/bin/sh
> bin:*:2:2:bin:/bin:/bin/sh
> sys:*:3:3:sys:/dev:/bin/sh
> sync:*:4:65534:sync:/bin:/bin/sync
> games:*:5:60:games:/usr/games:/bin/sh
> man:*:6:12:man:/var/cache/man:/bin/sh
> lp:*:7:7:lp:/var/spool/lpd:/bin/sh
> mail:*:8:8:mail:/var/mail:/bin/sh
> news:*:9:9:news:/var/spool/news:/bin/sh
> uucp:*:10:10:uucp:/var/spool/uucp:/bin/sh
> proxy:*:13:13:proxy:/bin:/bin/sh
> www-data:*:33:33:www-data:/var/www:/bin/sh
> backup:*:34:34:backup:/var/backups:/bin/sh
> list:*:38:38:Mailing List Manager:/var/list:/bin/sh
> irc:*:39:39:ircd:/var/run/ircd:/bin/sh
> gnats:*:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
> nobody:*:65534:65534:nobody:/nonexistent:/bin/sh
>
>
> Users are not found
>
>
> --
> ___
> 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] How to use same user in two recipes?

2017-10-11 Thread Fabien Lahoudere 
FI, with bitbake testuser -c devshell

# cat ../1.0-r1/recipe-sysroot/etc/passwd 
root::0:0:root:/root:/bin/sh
daemon:*:1:1:daemon:/usr/sbin:/bin/sh
bin:*:2:2:bin:/bin:/bin/sh
sys:*:3:3:sys:/dev:/bin/sh
sync:*:4:65534:sync:/bin:/bin/sync
games:*:5:60:games:/usr/games:/bin/sh
man:*:6:12:man:/var/cache/man:/bin/sh
lp:*:7:7:lp:/var/spool/lpd:/bin/sh
mail:*:8:8:mail:/var/mail:/bin/sh
news:*:9:9:news:/var/spool/news:/bin/sh
uucp:*:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:*:13:13:proxy:/bin:/bin/sh
www-data:*:33:33:www-data:/var/www:/bin/sh
backup:*:34:34:backup:/var/backups:/bin/sh
list:*:38:38:Mailing List Manager:/var/list:/bin/sh
irc:*:39:39:ircd:/var/run/ircd:/bin/sh
gnats:*:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:*:65534:65534:nobody:/nonexistent:/bin/sh

Users are not found-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2017-10-11 Thread Burton, Ross 
Looks like the useradd-example recipe isn't working properly. Check the
contents of the files in the sysroot to see if it did the right thing, and
for errors in the recipe's logs.

On 11 October 2017 at 10:10, Fabien Lahoudere <
fabien.lahoud...@collabora.co.uk> wrote:

> Thanks Ross
>
> The problem is that it fails with Pyro and also with oe-core master:
>
> I use recipe in meta-skeleton/recipes-skeleton/useradd/ to create users
> and the following testuser.bb:
>
> 
> testuser.bb
> SUMMARY = ""
> DESCRIPTION = ""
> PR = "r1"
> LICENSE = "MIT"
> LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=
> 3da9cfbcb788c80a0384361b4de20420"
>
> DEPENDS += " useradd-example "
>
> SRC_URI = " "
>
> S = "${WORKDIR}"
>
> do_install () {
> install -d -m 755 ${D}${datadir}/testuser1
> echo hello > ${D}${datadir}/testuser1/file
> chown -R user1 ${D}${datadir}/testuser1
> }
>
> FILES_${PN} = "${datadir}/testuser1/* "
> 
> ---
>
> and I have the following error and users are not populated in testuser
> recipe-sysroot/etc/passwd
>
> ERROR: testuser-1.0-r1 do_install: Function failed: do_install (log file
> is located at /home/aragua/src/oe-core/build/tmp-glibc/work/
> cortexa9hf-neon-oe-linux-gnueabi/testuser/1.0-r1/temp/
> log.do_install.26924)
> ERROR: Logfile of failure stored in: /home/aragua/src/oe-core/
> build/tmp-glibc/work/cortexa9hf-neon-oe-linux-
> gnueabi/testuser/1.0-r1/temp/log.do_install.26924
> Log data follows:
> | DEBUG: Executing python function extend_recipe_sysroot
> | NOTE: Direct dependencies are ['/home/aragua/src/oe-core/
> build/../meta-coerd/recipes-test/useradd/useradd-example.bb:do_populate_sysroot',
> 'virtual:native:/home/aragua/src/oe-core/meta/recipes-
> devtools/pseudo/pseudo_1.8.2.bb:do_populate_sysroot',
> '/home/aragua/src/oe-core/meta/recipes-core/glibc/glibc_2.26.bb:do_populate_sysroot',
> '/home/aragua/src/oe-core/meta/recipes-devtools/gcc/gcc-runtime_7.2.bb:
> do_populate_sysroot', '/home/aragua/src/oe-core/
> meta/recipes-devtools/quilt/quilt-native_0.65.bb:do_populate_sysroot',
> '/home/aragua/src/oe-core/meta/recipes-devtools/gcc/gcc-cross_7.2.bb:
> do_populate_sysroot']
> | NOTE: Installed into sysroot: ['pseudo-native']
> | NOTE: Skipping as already exists in sysroot: ['useradd-example',
> 'glibc', 'gcc-runtime', 'quilt-native', 'gcc-cross-arm', 'shadow',
> 'base-files', 'base-passwd', 'shadow-sysroot', 'linux-libc-headers',
> 'libgcc', 'xz-native', 'texinfo-dummy-native', 'binutils-cross-arm',
> 'gmp-native', 'libtool-native', 'zlib-native', 'libmpc-native',
> 'gnu-config-native', 'automake-native', 'mpfr-native', 'autoconf-native',
> 'opkg-utils', 'attr', 'gettext-minimal-native', 'flex-native',
> 'bison-native', 'm4-native']
> | DEBUG: Python function extend_recipe_sysroot finished
> | DEBUG: Executing shell function do_install
> | chown: invalid user: ‘user1’
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_install (log file is located at
> /home/aragua/src/oe-core/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-
> gnueabi/testuser/1.0-r1/temp/log.do_install.26924)
>
> Thanks
>
>
> On Wed, 2017-10-11 at 09:54 +0100, Burton, Ross wrote:
>
> Both of your recipes will need to depend on the user-creating recipe.
>
> Ross
>
> On 11 October 2017 at 07:45, Fabien Lahoudere  co.uk> wrote:
>
> On Tue, 2017-10-10 at 15:31 -0700, aaron_wri...@selinc.com wrote:
>
> > 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.
>
>
> Thanks Aaron
>
> Yes it is exactly what we do before with morty but now we use pyro and the
> sysroot is per recipe and not common to all recipe.
> And I search in the sysroot and the users created in recipe A are not
> applied to /etc/passwd.
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
> --
>
> Fabien
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists

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

2017-10-11 Thread Fabien Lahoudere 
Thanks Ross
The problem is that it fails with Pyro and also with oe-core master:
I use recipe in meta-skeleton/recipes-skeleton/useradd/ to create users and the 
following
testuser.bb:
testuser.bb-
---SUMMARY = ""DESCRIPTION = ""PR = "r1"LICENSE = 
"MIT"LIC_FILES_CHKSUM =
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
DEPENDS += " useradd-example "
SRC_URI = " "
S = "${WORKDIR}"
do_install () { install -d -m 755 ${D}${datadir}/testuser1  echo hello >
${D}${datadir}/testuser1/file   chown -R user1 ${D}${datadir}/testuser1}
FILES_${PN} = "${datadir}/testuser1/* 
"-
--
and I have the following error and users are not populated in testuser 
recipe-sysroot/etc/passwd
ERROR: testuser-1.0-r1 do_install: Function failed: do_install (log file is 
located at
/home/aragua/src/oe-core/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/testuser/1.0-
r1/temp/log.do_install.26924)ERROR: Logfile of failure stored in: 
/home/aragua/src/oe-
core/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/testuser/1.0-
r1/temp/log.do_install.26924Log data follows:| DEBUG: Executing python function
extend_recipe_sysroot| NOTE: Direct dependencies are 
['/home/aragua/src/oe-core/build/../meta-
coerd/recipes-test/useradd/useradd-example.bb:do_populate_sysroot',
'virtual:native:/home/aragua/src/oe-core/meta/recipes-
devtools/pseudo/pseudo_1.8.2.bb:do_populate_sysroot', 
'/home/aragua/src/oe-core/meta/recipes-
core/glibc/glibc_2.26.bb:do_populate_sysroot', 
'/home/aragua/src/oe-core/meta/recipes-
devtools/gcc/gcc-runtime_7.2.bb:do_populate_sysroot', 
'/home/aragua/src/oe-core/meta/recipes-
devtools/quilt/quilt-native_0.65.bb:do_populate_sysroot', 
'/home/aragua/src/oe-core/meta/recipes-
devtools/gcc/gcc-cross_7.2.bb:do_populate_sysroot']| NOTE: Installed into 
sysroot: ['pseudo-
native']| NOTE: Skipping as already exists in sysroot: ['useradd-example', 
'glibc', 'gcc-runtime',
'quilt-native', 'gcc-cross-arm', 'shadow', 'base-files', 'base-passwd', 
'shadow-sysroot', 'linux-
libc-headers', 'libgcc', 'xz-native', 'texinfo-dummy-native', 
'binutils-cross-arm', 'gmp-native',
'libtool-native', 'zlib-native', 'libmpc-native', 'gnu-config-native', 
'automake-native', 'mpfr-
native', 'autoconf-native', 'opkg-utils', 'attr', 'gettext-minimal-native', 
'flex-native', 'bison-
native', 'm4-native']| DEBUG: Python function extend_recipe_sysroot finished| 
DEBUG: Executing shell
function do_install| chown: invalid user: ‘user1’| WARNING: exit code 1 from a 
shell command.|
ERROR: Function failed: do_install (log file is located at 
/home/aragua/src/oe-core/build/tmp-
glibc/work/cortexa9hf-neon-oe-linux-gnueabi/testuser/1.0-r1/temp/log.do_install.26924)
Thanks
On Wed, 2017-10-11 at 09:54 +0100, Burton, Ross wrote:
> Both of your recipes will need to depend on the user-creating recipe.
> Ross
> On 11 October 2017 at 07:45, Fabien Lahoudere 
>  wrote:
> > On Tue, 2017-10-10 at 15:31 -0700, aaron_wri...@selinc.com wrote:
> > > > 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.
> > 
> > Thanks Aaron
> > 
> > Yes it is exactly what we do before with morty but now we use pyro and the 
> > sysroot is per recipe
> > and not common to all recipe.
> > And I search in the sysroot and the users created in recipe A are not 
> > applied to /etc/passwd.
> > --
> > 
> > ___
> > 
> > yocto mailing list
> > 
> > yocto@yoctoproject.org
> > 
> > https://lists.yoctoproject.org/listinfo/yocto
> > 
> > 
-- 
Fabien-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2017-10-11 Thread Burton, Ross 
Both of your recipes will need to depend on the user-creating recipe.

Ross

On 11 October 2017 at 07:45, Fabien Lahoudere <
fabien.lahoud...@collabora.co.uk> wrote:

> On Tue, 2017-10-10 at 15:31 -0700, aaron_wri...@selinc.com wrote:
>
> > 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.
>
>
> Thanks Aaron
>
> Yes it is exactly what we do before with morty but now we use pyro and the
> sysroot is per recipe and not common to all recipe.
> And I search in the sysroot and the users created in recipe A are not
> applied to /etc/passwd.
>
> --
> ___
> 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] Procedure for adding driver in Yocto

2017-10-11 Thread Vincent Prince 
Hi,

If you want to create a kernel module, you can use that kind of recipe

meta-x-bsp/recipes-kernel/kernel-module/kernel-module-modulename.bb:

SUMMARY = "Kernel loadable module"
DESCRIPTION = "This package includes loadable module"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=a04ba2d94725e7270af091f1f1cb6580"

PV .= "+git${SRCPV}"

SRCREV = "e26baba25fa792730d09c6e5334814b3037e7bc7"
SRC_URI = "git://url/modulename.git"

S = "${WORKDIR}/git"

inherit module

KERNEL_MODULE_AUTOLOAD = "modulename"

If it ok for you ?
Best Regards,
Vincent

2017-10-11 7:40 GMT+02:00 Umamahesh Yelchuruvenkata :
> Hi
>
>
>
> I am looking for a procedure how to add an new driver in Yocto Kernel. I
> tried adding an sample char driver by updating Kconfig and makefile of
> respective directory and by default marked as built in by default.
>
>
>
> But I do not see the driver is coming up while kernel is booted.
>
>
>
> Please suggest the procedure.
>
>
>
> Thanks
>
> Umamahesh
>
>
>
> ::DISCLAIMER::
> 
>
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as
> information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or may contain viruses in
> transmission. The e mail and its contents
> (with or without referred errors) shall therefore not attach any liability
> on the originator or HCL or its affiliates.
> Views or opinions, if any, presented in this email are solely those of the
> author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior written
> consent of authorized representative of
> HCL is strictly prohibited. If you have received this email in error please
> delete it and notify the sender immediately.
> Before opening any email and/or attachments, please check them for viruses
> and other defects.
>
> 
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto