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

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

--

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?

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

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

--
Ayoub Zaki
Embedded Systems Consultant

Vaihinger Straße 2/1
D-71634 Ludwigsburg

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

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

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@...

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

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

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

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

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

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

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

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.

Hi Paul,

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

Cheers,
Greg

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