Date   

Re: Navigating the layer labyrinth

Joshua Lock <joshua.g.lock@...>
 

On 12/10/17 10:34, Bernd wrote:
I am a new user for a few weeks now, trying to make a customized image
for a toradex colibri-vf module, so far I have succeeded in the
following disciplines:
* adding the 3rd party layers that I need
* making my own layers
* using a .bbappend to patch the device tree
* using a .bbappend to workaround a bug(?) in one of the freescale layers
* writing my own recipe to install a python script
* writing recipes for pulling additional python packages with pypi and
setuptools3
* writing my own image recipe
* making it boot and run on the target platform
During this learning experience I have made the following observations
of circumstances that made it especially hard for me to get things
done, I'm not yet really sure if this is a documentation issue or if
it is really a missing feature but I feel I could have had a much
*much* easier time learning and understanding the concepts and
relationships and the inner workings of existing layers upon which I
want to build my system if the following things were possible (and/or
if they are already possible they should be documented in the very
first chapter of the documentation):
* Finding the *file path* of an existing recipe (or append file or
class) *by its name* and also all existing .bbappends for it, i
imagine something simple like bitbake --show-paths foo-bar would
output me the small list of absolute paths of recipe files by the name
foo-bar and all matching .bbappend files in the order in which they
would be applied, it would show me only this small list of paths and
not dump 100kb of unrelated information along with it. This would be
incredibly helpful when I need to inspect an existing recipe in order
to understand how I can bbappend it or even just to see and understand
what it actually does.
bitbake-layers supports at least some of this functionality:

$ bitbake-layers -h
NOTE: Starting bitbake server...
usage: bitbake-layers [-d] [-q] [-F] [--color COLOR] [-h] <subcommand> ...

BitBake layers utility

optional arguments:
-d, --debug Enable debug output
-q, --quiet Print only errors
-F, --force Force add without recipe parse verification
--color COLOR Colorize output (where COLOR is auto, always, never)
-h, --help show this help message and exit

subcommands:
<subcommand>
add-layer Add a layer to bblayers.conf.
remove-layer Remove a layer from bblayers.conf.
flatten flatten layer configuration into a separate output
directory.
layerindex-fetch Fetches a layer from a layer index along with its
dependent layers, and adds them to conf/bblayers.conf.
layerindex-show-depends
Find layer dependencies from layer index.
show-layers show current configured layers.
show-overlayed list overlayed recipes (where the same recipe exists
in another layer)
show-recipes list available recipes, showing the layer they are
provided by
show-appends list bbappend files and recipe files they apply to
show-cross-depends Show dependencies between recipes that cross layer
boundaries.
create-layer Create a basic layer

Use bitbake-layers <subcommand> --help to get help on a specific command

Thanks,

Joshua


Re: Navigating the layer labyrinth

Alexander Kanavin <alexander.kanavin@...>
 

On 10/12/2017 12:34 PM, Bernd wrote:
* Finding the *file path* of an existing recipe (or append file or
class) *by its name* and also all existing .bbappends for it, i
imagine something simple like bitbake --show-paths foo-bar would
output me the small list of absolute paths of recipe files by the name
foo-bar and all matching .bbappend files in the order in which they
would be applied, it would show me only this small list of paths and
not dump 100kb of unrelated information along with it. This would be
incredibly helpful when I need to inspect an existing recipe in order
to understand how I can bbappend it or even just to see and understand
what it actually does.
* A simple way to track the assignment of a certain variable, to
inspect its contents and if it refers to other variables then
recursively show their contents too (and also the path of the bb file
where this happens), and also show which other recipes will directly
and indirectrly depend on this variable further down the line, I
imagine this should output two tree-like structures where one can see
at one glance how and where all the contents of that variable come
from and where they are going to be used. Again this should be a
simple command that formats and outputs that (and only that)
information in a well formatted and compact tree-like representation.
I think bitbake -e could be of some help with these two things. It's not particularly compact, but it tells you the full story.

Alex


Re: Navigating the layer labyrinth

Aaron Schwartz <aaron.schwartz@...>
 

 Hello,

I am not sure if you've found the OpenEmbedded Layer Index [0] yet, but that's a good resource and an example of what can be done.  I believe the source code is available [1] and I've toyed with the idea of getting it working locally (although I've not had the time to do so).

That could be a part of what you're looking for, at least.

Hope that helps,
Aaron





On Thu, Oct 12, 2017 at 5:34 AM, Bernd <prof7bit@...> wrote:
I am a new user for a few weeks now, trying to make a customized image
for a toradex colibri-vf module, so far I have succeeded in the
following disciplines:

* adding the 3rd party layers that I need
* making my own layers
* using a .bbappend to patch the device tree
* using a .bbappend to workaround a bug(?) in one of the freescale layers
* writing my own recipe to install a python script
* writing recipes for pulling additional python packages with pypi and
setuptools3
* writing my own image recipe
* making it boot and run on the target platform

During this learning experience I have made the following observations
of circumstances that made it especially hard for me to get things
done, I'm not yet really sure if this is a documentation issue or if
it is really a missing feature but I feel I could have had a much
*much* easier time learning and understanding the concepts and
relationships and the inner workings of existing layers upon which I
want to build my system if the following things were possible (and/or
if they are already possible they should be documented in the very
first chapter of the documentation):

* Finding the *file path* of an existing recipe (or append file or
class) *by its name* and also all existing .bbappends for it, i
imagine something simple like bitbake --show-paths foo-bar would
output me the small list of absolute paths of recipe files by the name
foo-bar and all matching .bbappend files in the order in which they
would be applied, it would show me only this small list of paths and
not dump 100kb of unrelated information along with it. This would be
incredibly helpful when I need to inspect an existing recipe in order
to understand how I can bbappend it or even just to see and understand
what it actually does.

* A simple way to track the assignment of a certain variable, to
inspect its contents and if it refers to other variables then
recursively show their contents too (and also the path of the bb file
where this happens), and also show which other recipes will directly
and indirectrly depend on this variable further down the line, I
imagine this should output two tree-like structures where one can see
at one glance how and where all the contents of that variable come
from and where they are going to be used. Again this should be a
simple command that formats and outputs that (and only that)
information in a well formatted and compact tree-like representation.

* The absolute killer application would be an IDE or an editor plugin
where I open any .bb file and can then just CTRL-click on any include,
require, inherit, depend, rdepend, or any variable name and it would
open another editor containing that recipe file where it is defined
and/or populate a sidebar with a list or a tree of direct and indirect
references to that name, backward and forward, and I could just click
on any node of that tree an and it would open the file in the editor
and jump to that line of code. Such a thing would be an incredibly
helpful tool, it would make even the most complex and tangled
labyrinth of recipes navigable with ease.

Please tell me that such a thing already exists and I just have not
found it yet.

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



--

Aaron Schwartz
Production
Logic Supply
Direct: +1 802 861 2300 Ext. 530
Main: +1 802 861 2300
www.logicsupply.com

Google+ | Twitter | LinkedIn | YouTube


possible to append or patch existing machine .conf file?

Bernd <prof7bit@...>
 

Suppose I have the following bugfix patch for a 3rd party machine conf
file I am using:

diff --git a/conf/machine/colibri-vf.conf b/conf/machine/colibri-vf.conf
index 3ddef79..ba47488 100644
--- a/conf/machine/colibri-vf.conf
+++ b/conf/machine/colibri-vf.conf
@@ -35,6 +35,6 @@ MKUBIFS_ARGS = " -c 8112 -e 124KiB -m 2KiB -F"
UBINIZE_ARGS = " -p 128KiB -m 2048 -s 2048"
UBI_VOLNAME = "rootfs"

-SERIAL_CONSOLE ?= "115200 ttyLP0"
+SERIAL_CONSOLE = "115200 ttyLP0"

MACHINE_FEATURES += "usbgadget usbhost vfat alsa touchscreen"

Is there a proper way to somehow temporarily add something to my layer
to apply this patch until it makes its way upstream and into the
branch I am using? Or should I make my own machine file, include the
original one and then change the variable?

So far I have not found any elegant way to otherwise force this
variable to its correct value in my image recipe, the only way I have
found to work around this bug is to .bbappend the inittab recipe where
this variable is actually used and change the value of another
variable (SERIAL_CONSOLES, note the S at the end) which is derived
from SERIAL_CONSOLE right there in this bbappend file. This seems to
help.

But while doing this I have also noticed a strange anomaly in the
output of bitbake -e:

* When I change the variable in my image recipe then bitbake -e will
show another "set" access and both variables SERIAL_CONSOLE and
SERIAL_CONSOLES will have the correct value as intended by me but the
produced image will have the **wrong** entry in its inittab.

* When I bbappend the inittab recipe to set SERIAL_CONSOLES right
there where it is used then my final image will have a correct inittab
and the serial console will work bit there is **no** mention of that
variable change in the output of bitbake -e

* Only when I change the machine conf file iitself to set the variable
then bitbake -e and the produced image both show the correct entry.
Why does it behave that way?


Navigating the layer labyrinth

Bernd <prof7bit@...>
 

I am a new user for a few weeks now, trying to make a customized image
for a toradex colibri-vf module, so far I have succeeded in the
following disciplines:

* adding the 3rd party layers that I need
* making my own layers
* using a .bbappend to patch the device tree
* using a .bbappend to workaround a bug(?) in one of the freescale layers
* writing my own recipe to install a python script
* writing recipes for pulling additional python packages with pypi and
setuptools3
* writing my own image recipe
* making it boot and run on the target platform

During this learning experience I have made the following observations
of circumstances that made it especially hard for me to get things
done, I'm not yet really sure if this is a documentation issue or if
it is really a missing feature but I feel I could have had a much
*much* easier time learning and understanding the concepts and
relationships and the inner workings of existing layers upon which I
want to build my system if the following things were possible (and/or
if they are already possible they should be documented in the very
first chapter of the documentation):

* Finding the *file path* of an existing recipe (or append file or
class) *by its name* and also all existing .bbappends for it, i
imagine something simple like bitbake --show-paths foo-bar would
output me the small list of absolute paths of recipe files by the name
foo-bar and all matching .bbappend files in the order in which they
would be applied, it would show me only this small list of paths and
not dump 100kb of unrelated information along with it. This would be
incredibly helpful when I need to inspect an existing recipe in order
to understand how I can bbappend it or even just to see and understand
what it actually does.

* A simple way to track the assignment of a certain variable, to
inspect its contents and if it refers to other variables then
recursively show their contents too (and also the path of the bb file
where this happens), and also show which other recipes will directly
and indirectrly depend on this variable further down the line, I
imagine this should output two tree-like structures where one can see
at one glance how and where all the contents of that variable come
from and where they are going to be used. Again this should be a
simple command that formats and outputs that (and only that)
information in a well formatted and compact tree-like representation.

* The absolute killer application would be an IDE or an editor plugin
where I open any .bb file and can then just CTRL-click on any include,
require, inherit, depend, rdepend, or any variable name and it would
open another editor containing that recipe file where it is defined
and/or populate a sidebar with a list or a tree of direct and indirect
references to that name, backward and forward, and I could just click
on any node of that tree an and it would open the file in the editor
and jump to that line of code. Such a thing would be an incredibly
helpful tool, it would make even the most complex and tangled
labyrinth of recipes navigable with ease.

Please tell me that such a thing already exists and I just have not
found it yet.

Bernd


Re: Layer versions at runtime

Ayoub Zaki <ayoub.zaki@...>
 

Hi,

That's easy to do :


do_install_append () {

    for layer in ${BBLAYERS}; do
        cd $layer
        echo -n "$(basename $layer) = "  >> ${D}${sysconfdir}/gitinfo
        git rev-parse HEAD >> ${D}${sysconfdir}/gitinfo
    done
}


add it in a recipe or add it to os-release.bbappend

On 12.10.2017 11:05, Alan Martinovic wrote:
I've noticed that bitbake prints the git commit versions of the layers when the build starts.

meta-python       = "HEAD:b40116cf457b88a2db14b86fda9627fb34d56ae6"
meta-mender-core  = "HEAD:c3b1b465ce3a27fc7b03a6b7ef596348835cff57"
meta-go           = "HEAD:514b2a80a2a4235687e92fb28328bb3e7c2d6c74"

Does this information find it's way into the rootfs?
If not, any suggestions on how to achieve this?

The goal is to have this info available while the image is running.

Be Well,
Alan

--
Ayoub Zaki
Embedded Systems Consultant

Vaihinger Straße 2/1
D-71634 Ludwigsburg

Tel. : +4971415074546
Mobile : +4917662901545
Email : ayoub.zaki@...
Homepage : https://embexus.com


Layer versions at runtime

Alan
 

I've noticed that bitbake prints the git commit versions of the layers when the build starts.

meta-python       = "HEAD:b40116cf457b88a2db14b86fda9627fb34d56ae6"
meta-mender-core  = "HEAD:c3b1b465ce3a27fc7b03a6b7ef596348835cff57"
meta-go           = "HEAD:514b2a80a2a4235687e92fb28328bb3e7c2d6c74"

Does this information find it's way into the rootfs?
If not, any suggestions on how to achieve this?

The goal is to have this info available while the image is running.

Be Well,
Alan


Re: How to use same user in two recipes?

Maxin B. John
 

Hi Fabien,

Good to know that it helps here.

On Wed, Oct 11, 2017 at 07:48:46PM +0200, Fabien Lahoudere wrote:
Maxin,

Is this patch submitted or applied for next release?
Submitted the patch to oe-core mailing list today:
http://lists.openembedded.org/pipermail/openembedded-core/2017-October/143288.html

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
Thanks and Regards,
Maxin


How do I patch binutils for the SDK

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
Paul mailto:pderocco@...


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

Gutierrez, Hernan Ildefonso (Boise R&D, FW) <hernan_gutierrez@...>
 

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.khem@...]
Sent: Wednesday, October 11, 2017 7:01 PM
To: Gutierrez, Hernan Ildefonso (Boise R&D, FW)
<hernan_gutierrez@...>
Cc: yocto <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) <hernan_gutierrez@...> 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@...
https://lists.yoctoproject.org/listinfo/yocto


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

Jackie Huang
 

-----Original Message-----
From: Andre McCurdy [mailto:armccurdy@...]
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, <jackie.huang@...> wrote:
From: Jackie Huang <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 <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/00001-systemtap.cfg \
+SRC_URI_append_poky-cgl = "file://cfg/00001-systemtap.cfg \
Needs a leading space.
Fixed and sent v2.

Thanks,
Jackie


file://cfg/00002-oprofile.cfg \
file://cfg/00003-lttng.cfg \
file://cfg/00004-kgdb.cfg \
--
2.11.0

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


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

Jackie Huang
 

From: Jackie Huang <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 <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/00001-systemtap.cfg \
+SRC_URI_append_poky-cgl = " file://cfg/00001-systemtap.cfg \
file://cfg/00002-oprofile.cfg \
file://cfg/00003-lttng.cfg \
file://cfg/00004-kgdb.cfg \
--
2.11.0


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

Jackie Huang
 

From: Jackie Huang <jackie.huang@...>

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

Signed-off-by: Jackie Huang <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


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

Jackie Huang
 

From: Jackie Huang <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


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

Khem Raj
 

On Wed, Oct 11, 2017 at 3:15 PM, Gutierrez, Hernan Ildefonso (Boise
R&D, FW) <hernan_gutierrez@...> 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@...
https://lists.yoctoproject.org/listinfo/yocto


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

Andre McCurdy <armccurdy@...>
 

On Mon, Oct 9, 2017 at 8:30 PM, <jackie.huang@...> wrote:
From: Jackie Huang <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 <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/00001-systemtap.cfg \
+SRC_URI_append_poky-cgl = "file://cfg/00001-systemtap.cfg \
Needs a leading space.

file://cfg/00002-oprofile.cfg \
file://cfg/00003-lttng.cfg \
file://cfg/00004-kgdb.cfg \
--
2.11.0

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


How to use two recipes to satisfy different PROVIDES -- gpu support

Gutierrez, Hernan Ildefonso (Boise R&D, FW) <hernan_gutierrez@...>
 

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


Re: image dependent pkg versions/pkg variations

Andre McCurdy <armccurdy@...>
 

On Wed, Oct 11, 2017 at 11:24 AM, Robert Berger
<yocto.user.mailinglist@...> 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.


Re: errors in recipe after move from devtool

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.eggleton@...]
Sent: Wednesday, October 11, 2017 12:56 PM
To: Greg Wilson-Lindberg <GWilson@...>
Cc: yocto@...; Burton, Ross <ross.burton@...>
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


Re: errors in recipe after move from devtool

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

19421 - 19440 of 57772