On Thu, Oct 12, 2017 at 03:33:53AM +0000, Gutierrez, Hernan Ildefonso (Boise R&D, FW) wrote:

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.

you can also look at meta-raspberrypi

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

update to 1.2.15

plus
ERROR: openscap-1.2.14-r0 do_package_qa: QA Issue: /usr/lib/openscap/ptest/tests/probes/process58/all.sh contained in package openscap-ptest requires /bin/bash, but no providers found in RDEPENDS_openscap-ptest? [file-rdeps]
ERROR: openscap-1.2.14-r0 do_package_qa: QA Issue: /usr/lib/openscap/ptest/tests/xmldiff.pl contained in package openscap-ptest requires /usr/bin/perl, but no providers found in RDEPENDS_openscap-ptest? [file-rdeps]
ERROR: openscap-1.2.14-r0 do_package_qa: QA Issue: /usr/lib/openscap/ptest/tests/nist/test_worker.py contained in package openscap-ptest requires /usr/bin/python2, but no providers found in RDEPENDS_openscap-ptest? [file-rdeps]

Signed-off-by: Armin Kuster <akuster808@...>
---
.../openscap/{openscap_1.2.14.bb => openscap_1.2.15.bb} | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
rename meta-security-compliance/recipes-openscap/openscap/{openscap_1.2.14.bb => openscap_1.2.15.bb} (94%)

diff --git a/meta-security-compliance/recipes-openscap/openscap/openscap_1.2.14.bb b/meta-security-compliance/recipes-openscap/openscap/openscap_1.2.15.bb
similarity index 94%
rename from meta-security-compliance/recipes-openscap/openscap/openscap_1.2.14.bb
rename to meta-security-compliance/recipes-openscap/openscap/openscap_1.2.15.bb
index 0d26959..4dacfa2 100644
--- a/meta-security-compliance/recipes-openscap/openscap/openscap_1.2.14.bb
+++ b/meta-security-compliance/recipes-openscap/openscap/openscap_1.2.15.bb
@@ -11,7 +11,7 @@ DEPENDS = "autoconf-archive pkgconfig gconf procps curl libxml2 rpm \

DEPENDS_class-native = "autoconf-archive-native pkgconfig-native swig-native curl-native libxml2-native libxslt-native dpkg-native libgcrypt-native nss-native"

-SRCREV = "7a924c0eea10d05f512660192c8c4aef447801a6"
+SRCREV = "240930d42611983c65ecae16dbca3248ce130921"
SRC_URI = "git://github.com/akuster/openscap.git;branch=oe \
file://crypto_pkgconfig.patch \
file://run-ptest \
@@ -66,6 +66,7 @@ do_install_append_class-native () {
TESTDIR = "tests"

do_compile_ptest() {
+ sed -i 's:python2:python:' ${S}/${TESTDIR}/nist/test_worker.py
echo 'buildtest-TESTS: $(check)' >> ${TESTDIR}/Makefile
oe_runmake -C ${TESTDIR} buildtest-TESTS
}
@@ -78,5 +79,6 @@ do_install_ptest() {
FILES_${PN} += "${PYTHON_SITEPACKAGES_DIR}"

RDEPENDS_${PN} += "libxml2 python libgcc"
+RDEPENDS_${PN}-ptest = "bash perl python"

BBCLASSEXTEND = "native"
--
2.7.4

On Thu, Oct 12, 2017 at 06:23:03AM +0000, Paul D. DeRocco wrote:

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.

You can apply the patch to all binutils variants, its fine. Send a patch or if you
want, file a ticket in bugzilla and we will take care.

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@...

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

I'm confused as to how the devtool sdk-install command is supposed to work. Take for example:

devtool sdk-install cxxtest

This installs all the /usr/lib and /usr/include stuff into the sysroot, but doesn't install the /usr/bin stuff required to actually use cxxtest.

So should I install nativesdk-cxxtest instead? Still doesn't work, but I was just curious about the nativesdk- prefix.
cxxtest-native doesn't work either.
Does the cxxtest recipe need a SYSROOT_DIRS_append = " ${bindir}" in order to get the /usr/bin files installed in the eSDK when someone installs it?



PS - often devtool sdk-install <recipe> will act like it is working and then print an error at the end:

NOTE: Tasks Summary: Attempted 105 tasks of which 71 didn't need to be rerun and all succeeded.
ERROR: Failed to install nativesdk-cxxtest - unavailable



PPS - a google search for devtool sdk-install returns nothing, so hopefully the mailing list can help.

Hi All,

Had a question about kernel-fitimage.bbclass. I am enabling the fitimage using KERNEL_CLASSES += "kernel-fitimage" and KERNEL_IMAGETYPE = "fitImage".
It works and I see fitimage in my deploy directory without any issues.

However when I enable initramfs along with fitimage, using INITRAMFS_IMAGE = "core-image-minimal" and INITRAMFS_IMAGE_BUNDLE = "1", kernel build fails.
It's mostly from kernel.bbclass because it tries to deploy fitimage https://github.com/openembedded/openembedded-core/blob/master/meta/classes/kernel.bbclass#L639
Am I using this featurecorrectly? anyone else facing same issue?

Below is a initial patch which I did to get me across the error, but I am not sure if this is the correct answer.

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 756707a..d5342b4 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -208,14 +208,16 @@ do_bundle_initramfs () {
# Backing up kernel image relies on its type(regular file or symbolic link)
tmp_path=""
for type in ${KERNEL_IMAGETYPES} ; do
- if [ -h ${KERNEL_OUTPUT_DIR}/$type ] ; then
- linkpath=`readlink -n ${KERNEL_OUTPUT_DIR}/$type`
- realpath=`readlink -fn ${KERNEL_OUTPUT_DIR}/$type`
- mv -f $realpath $realpath.bak
- tmp_path=$tmp_path" "$type"#"$linkpath"#"$realpath
- elif [ -f ${KERNEL_OUTPUT_DIR}/$type ]; then
- mv -f ${KERNEL_OUTPUT_DIR}/$type ${KERNEL_OUTPUT_DIR}/$type.bak
- tmp_path=$tmp_path" "$type"##"
+ if [ "$type" != "fitImage" ]; then
+ if [ -h ${KERNEL_OUTPUT_DIR}/$type ] ; then
+ linkpath=`readlink -n ${KERNEL_OUTPUT_DIR}/$type`
+ realpath=`readlink -fn ${KERNEL_OUTPUT_DIR}/$type`
+ mv -f $realpath $realpath.bak
+ tmp_path=$tmp_path" "$type"#"$linkpath"#"$realpath
+ elif [ -f ${KERNEL_OUTPUT_DIR}/$type ]; then
+ mv -f ${KERNEL_OUTPUT_DIR}/$type ${KERNEL_OUTPUT_DIR}/$type.bak
+ tmp_path=$tmp_path" "$type"##"
+ fi
fi
done
use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=${B}/usr/${INITRAMFS_IMAGE_NAME}.cpio
@@ -627,8 +629,10 @@ MODULE_TARBALL_DEPLOY ?= "1"

kernel_do_deploy() {
for type in ${KERNEL_IMAGETYPES} ; do
- base_name=${type}-${KERNEL_IMAGE_BASE_NAME}
- install -m 0644 ${KERNEL_OUTPUT_DIR}/${type} ${DEPLOYDIR}/${base_name}.bin
+ if [ "$type" != "fitImage" ]; then
+ base_name=${type}-${KERNEL_IMAGE_BASE_NAME}
+ install -m 0644 ${KERNEL_OUTPUT_DIR}/${type} ${DEPLOYDIR}/${base_name}.bin
+ fi
done
if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
mkdir -p ${D}/lib
@@ -637,21 +641,25 @@ kernel_do_deploy() {
fi

for type in ${KERNEL_IMAGETYPES} ; do
- base_name=${type}-${KERNEL_IMAGE_BASE_NAME}
- symlink_name=${type}-${KERNEL_IMAGE_SYMLINK_NAME}
- ln -sf ${base_name}.bin ${DEPLOYDIR}/${symlink_name}.bin
- ln -sf ${base_name}.bin ${DEPLOYDIR}/${type}
+ if [ "$type" != "fitImage" ]; then
+ base_name=${type}-${KERNEL_IMAGE_BASE_NAME}
+ symlink_name=${type}-${KERNEL_IMAGE_SYMLINK_NAME}
+ ln -sf ${base_name}.bin ${DEPLOYDIR}/${symlink_name}.bin
+ ln -sf ${base_name}.bin ${DEPLOYDIR}/${type}
+ fi
done

cd ${B}
# Update deploy directory
for type in ${KERNEL_IMAGETYPES} ; do
- if [ -e "${KERNEL_OUTPUT_DIR}/${type}.initramfs" ]; then
- echo "Copying deploy ${type} kernel-initramfs image and setting up links..."
- initramfs_base_name=${type}-${INITRAMFS_BASE_NAME}
- initramfs_symlink_name=${type}-initramfs-${MACHINE}
- install -m 0644 ${KERNEL_OUTPUT_DIR}/${type}.initramfs ${DEPLOYDIR}/${initramfs_base_name}.bin
- ln -sf ${initramfs_base_name}.bin ${DEPLOYDIR}/${initramfs_symlink_name}.bin
+ if [ "$type" != "fitImage" ]; then
+ if [ -e "${KERNEL_OUTPUT_DIR}/${type}.initramfs" ]; then
+ echo "Copying deploy ${type} kernel-initramfs image and setting up links..."
+ initramfs_base_name=${type}-${INITRAMFS_BASE_NAME}
+ initramfs_symlink_name=${type}-initramfs-${MACHINE}
+ install -m 0644 ${KERNEL_OUTPUT_DIR}/${type}.initramfs ${DEPLOYDIR}/${initramfs_base_name}.bin
+ ln -sf ${initramfs_base_name}.bin ${DEPLOYDIR}/${initramfs_symlink_name}.bin
+ fi
fi
done
}

Thanks,
Manju

Hi

On 12.10.2017 20:47, Ayoub Zaki wrote:

Hi,
On 12.10.2017 20:34, Josef Holzmayr wrote:

Hi

On 12.10.2017 19:07, Ayoub Zaki wrote:

Hi,
I would like to generate an image that contains a custom directories layout for expl:


foo/
├── bar1
│   └── bar2
│       ├── config
│       └── data
└── work
     └── var
         └── lib
             ├── config
             └── data

It should contains only those directories an nothing else, is there anyway to achieve that ? without using ROOTFS_POSTPROCESS_COMMAND.

Should be possible if your image installs only your specific recipes that populate those directories. Means: no packagegroup-core-boot, no base-passwd, no.... -> then nothing should bring along other directories.

I tried that but it does pull other packages even if I set in my image:
IMAGE_FEATURES = ""
IMAGE_LINGUAS = ""
PACKAGE_INSTALL = "my-layout-recipe"
Regards

Probably you're inheriting from some more complex image class that pulls in the undesired packages. Have you already checked bitbake -e to see how the variables get expanded?

Greetz

--
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———————————————
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

Hi,


On 12.10.2017 20:34, Josef Holzmayr wrote:

Hi

On 12.10.2017 19:07, Ayoub Zaki wrote:

Hi,
I would like to generate an image that contains a custom directories layout for expl:


foo/
├── bar1
│   └── bar2
│       ├── config
│       └── data
└── work
     └── var
         └── lib
             ├── config
             └── data

It should contains only those directories an nothing else, is there anyway to achieve that ? without using ROOTFS_POSTPROCESS_COMMAND.

Should be possible if your image installs only your specific recipes that populate those directories. Means: no packagegroup-core-boot, no base-passwd, no.... -> then nothing should bring along other directories.

I tried that but it does pull other packages even if I set in my image:

IMAGE_FEATURES = ""
IMAGE_LINGUAS = ""
PACKAGE_INSTALL = "my-layout-recipe"

Regards

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

On 12.10.2017 19:07, Ayoub Zaki wrote:

Hi,
I would like to generate an image that contains a custom directories layout for expl:
foo/
├── bar1
│   └── bar2
│       ├── config
│       └── data
└── work
    └── var
        └── lib
            ├── config
            └── data
It should contains only those directories an nothing else, is there anyway to achieve that ? without using ROOTFS_POSTPROCESS_COMMAND.

Should be possible if your image installs only your specific recipes that populate those directories. Means: no packagegroup-core-boot, no base-passwd, no.... -> then nothing should bring along other directories.

Greetz
--
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———————————————
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

Hi,

On 12.10.2017 12:32, Bernd wrote:

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?

you can add to local.conf or distro.conf :

include conf/machine/${MACHINE}-extra.conf

then create in your meta layer or bsp layer :

conf/machine/beaglebone-extra.conf
conf/machine/rasberrypi-extra.conf
conf/machine/xyz-extra.conf

which contains overrides for your machine settings.
Note that is an include and not require, which means that if you machine has no *extra.conf then it's simply skkiped ( no overrides)

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?

--
Ayoub Zaki
Embedded Systems Consultant

Vaihinger Straße 2/1
D-71634 Ludwigsburg

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

When publishing a layer, send an email notification to all of that
layer's maintainers.

Fixes [YOCTO #11208]

Signed-off-by: Amanda Brindle <amanda.r.brindle@...>
---
layerindex/views.py | 22 +++++++++++++++++++++-
templates/layerindex/publishemail.txt | 7 +++++++
templates/layerindex/publishemailsubject.txt | 1 +
3 files changed, 29 insertions(+), 1 deletion(-)
create mode 100644 templates/layerindex/publishemail.txt
create mode 100644 templates/layerindex/publishemailsubject.txt

diff --git a/layerindex/views.py b/layerindex/views.py
index bcf6671..35949dd 100644
--- a/layerindex/views.py
+++ b/layerindex/views.py
@@ -5,7 +5,7 @@
# Licensed under the MIT license, see COPYING.MIT for details

import sys
-from django.shortcuts import get_object_or_404, render
+from django.shortcuts import get_object_or_404, get_list_or_404, render
from django.http import HttpResponse, HttpResponseRedirect, HttpResponseForbidden, Http404
from django.core.urlresolvers import reverse, reverse_lazy, resolve
from django.core.exceptions import PermissionDenied
@@ -261,6 +261,26 @@ def _check_url_branch(kwargs):
def publish(request, name):
if not (request.user.is_authenticated() and request.user.has_perm('layerindex.publish_layer')):
raise PermissionDenied
+ from_email = settings.SUBMIT_EMAIL_FROM
+ plaintext = get_template('layerindex/publishemail.txt')
+ subjecttext = get_template('layerindex/publishemailsubject.txt')
+ e = Context({
+ 'layer_name': layeritem.name,
+ 'site_name': request.META['HTTP_HOST'],
+ })
+ subject = subjecttext.render(e).rstrip()
+ layeritem = get_object_or_404(LayerItem, name=name)
+ layerbranch = get_object_or_404(LayerBranch, layer=layeritem)
+ maintainers = get_list_or_404(LayerMaintainer, layerbranch=layerbranch)
+ layer_url = request.build_absolute_uri(reverse('layer_item', args=(layerbranch.branch, layeritem.name)))
+ for m in maintainers:
+ d = Context({
+ 'maintainer_name': m.name,
+ 'layer_name': layeritem.name,
+ 'layer_url': layer_url,
+ })
+ text_content = plaintext.render(d)
+ tasks.send_email.apply_async((subject, text_content, from_email, [m.email]))
return _statuschange(request, name, 'P')

def _statuschange(request, name, newstatus):
diff --git a/templates/layerindex/publishemail.txt b/templates/layerindex/publishemail.txt
new file mode 100644
index 0000000..2500bff
--- /dev/null
+++ b/templates/layerindex/publishemail.txt
@@ -0,0 +1,7 @@
+Hi {{ maintainer_name }},
+
+You are listed as a maintainer for the new layer, {{ layer_name }}. This layer has been published. You can view it at the following URL:
+
+ {{ layer_url }}
+
+Thanks!
diff --git a/templates/layerindex/publishemailsubject.txt b/templates/layerindex/publishemailsubject.txt
new file mode 100644
index 0000000..a46eaf2
--- /dev/null
+++ b/templates/layerindex/publishemailsubject.txt
@@ -0,0 +1 @@
+{{layer_name }} was published to {{site_name}}
--
2.7.4

The following changes since commit ad1aac4ea5d4f2b327f7bd9611aed13f7c31ff7e:

Show note if layer branch hasn't been indexed (2017-10-04 13:49:00 +1300)

are available in the git repository at:

git://git.yoctoproject.org/layerindex-web abrindle/email_notification_publication
http://git.yoctoproject.org/cgit.cgi/layerindex-web/log/?h=abrindle/email_notification_publication

Amanda Brindle (1):
Send email notification on publication

layerindex/views.py | 22 +++++++++++++++++++++-
templates/layerindex/publishemail.txt | 7 +++++++
templates/layerindex/publishemailsubject.txt | 1 +
3 files changed, 29 insertions(+), 1 deletion(-)
create mode 100644 templates/layerindex/publishemail.txt
create mode 100644 templates/layerindex/publishemailsubject.txt

--
2.7.4

On Thu, Oct 12, 2017 at 3:32 AM, Bernd <prof7bit@...> wrote:

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?

That would be one way. You could also over-ride from any other global
config file, e.g. local.conf or the distro config file (if you have
one).

So far I have not found any elegant way to otherwise force this
variable to its correct value in my image recipe

Right, the variable is not used by the image recipe, so setting it
there won't change anything. Variables in an image recipe generally
only relate to how the image is constructed (what packages it contains
and format of the final image - tar.gz, squashfs, etc).

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

For variables which are specific to one recipe then over-riding in the
context of that recipe is OK. However, SERIAL_CONSOLES is used in a
few different recipes, so over-riding from a global config file would
necessary to be sure of changing it consistently wherever it's used.

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.

If you run bitbake -e for inittab and for the image recipe and compare
the two it should show that setting the variable from within the image
recipe has no effect on the inittab recipe. That's not a bug.

* 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

Similar to above, bitbake -e will give different results for each recipe.

* 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?

Because the machine config is a global config file and any variables
it sets are seen by every recipe.

Hi,
I would like to generate an image that contains a custom directories layout for expl:


foo/
├── bar1
│   └── bar2
│       ├── config
│       └── data
└── work
    └── var
        └── lib
            ├── config
            └── data

It should contains only those directories an nothing else, is there anyway to achieve that ? without using ROOTFS_POSTPROCESS_COMMAND.

I would like to use in a seperate partition.

Thank you !


--
Ayoub Zaki
Embedded Systems Consultant

Vaihinger Straße 2/1
D-71634 Ludwigsburg

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

Or better yet use
http://www.yoctoproject.org/docs/2.3.2/mega-manual/mega-manual.html#ref-classes-image-buildinfo

to get:

-----------------------
Build Configuration: |
-----------------------
DISTRO = nodistro
DISTRO_VERSION = nodistro.0
-----------------------
Layer Revisions: |
-----------------------
meta = master:8ca61a5464743ff85b6d26886112750d6ddd13e0
meta-xilinx = master:74a0d90e52cca346d05a69bbd628c6ec9e49fbcb
meta-oe = master:5c9a4a08844c215ebd6f2146f50de753b8e7ecef
meta-networking = master:5c9a4a08844c215ebd6f2146f50de753b8e7ecef
meta-filesystems = master:5c9a4a08844c215ebd6f2146f50de753b8e7ecef
meta-python = master:5c9a4a08844c215ebd6f2146f50de753b8e7ecef
meta-multimedia = master:5c9a4a08844c215ebd6f2146f50de753b8e7ecef
meta-sdr = qt5-test:dacc304b01eac7448ec1ebf0b3d0eab761c41a26 --
modified
meta-qt5 = master:2c3ef00f53683fbdce5b390950b49b67da85d3a1
meta-qcom = master:bae28268a9387bb842ab7bbe8200b98c1210604c
meta-raspberrypi = master:9d84186870a6f9bde44575690105b9bb5e44ca24

Philip

Hi Richard (and all),

@Richard: Thanks for the input regarding the topic and apologies for not replying until now, I was a bit buried under workload and simultaneously completing my Masters studies. I also wanted to take some time to digest your comments amid working on this CDEPENDS concept, and I just want to say that I'm very open to finding another way to implement this concept of rebuild avoidance in Yocto.

I think the idea of a non-invasive approach can be a bit tricky, but your idea of a secondary sstate signature and mapping table sounds workable to me. (In fact, as I slowly developed out this concept, I think it's almost required). One point though with the removal of the metadata changes is that the view of "what is compatible" will be concrete and cannot differ among children. Sometimes you have only specific children of a recipe that can handle compatibility changes (and at different levels of compatibility) while others cannot handle any change at all, and that is why I developed with the metadata changes as a basis. But definitely, yes, the change to metadata makes things more complex and does in a sense impose policy, which I understand would be undesirable. Maybe we can figure out an approach that avoids metadata changes but keeps this ability to differ compatibility handling among children.

Currently I have a working proof of concept (I've developed out the earlier shared patches further) that I'd like to share soon and demonstrate. It still needs some further refinement but I think it's showing some interesting results already. I'll think further about the topic and see what I can come up with that matches your line of thoughts.

@Martin Jansa: Thank you for the comments and information, it's good to know that there's some interest from the community to look into this idea.

@Mike Looijmans: Yes, that's essentially the problem I want to resolve with this proof of concept, breaking long build chains at points where a clear precision cut could've been made depending on whether a rebuild is actually required or not (i.e. the bitstream tool not changing). In that case I would even use the tool version and assume even if the tool binary has changed, that the output result of tool would stay the same so it is compatible in essence (and avoid rebuilding 31 hours of stuff).

@Trevor Woerner: Thanks for the suggestion, I was planning to cross-post when I had a more stable proof of concept code to share.

Note: I'll be following my colleague, Mario Domenech Goulart (mario-goulart), to OEDEM 2017 where I hope to discuss the current concept code and show some potential use cases.

Kind regards,
Michael Ho

--
BMW Car IT GmbH
Michael Ho
Spezialist Entwicklung - Linux Software Integration
Lise-Meitner-Str. 14
89081 Ulm

Tel.: +49 731 3780 4071
Mobil: +49 152 5498 0471
Fax: +49-731-37804-001
Mail: michael.ho@...
Web: http://www.bmw-carit.de
--------------------------------------------------------
BMW Car IT GmbH
Gechäftsführer: Kai-Uwe Balszuweit und Alexis Trolin
Sitz und Registergericht: München HRB 134810
--------------------------------------------------------

________________________________________
From: Richard Purdie <richard.purdie@...>
Sent: 21 September 2017 18:11
To: Michael Ho; yocto@...
Subject: Re: [yocto] RFC: Backwards compatibility checking sstate-cache

On Fri, 2017-06-30 at 09:48 +0000, Michael Ho wrote:

Hi, at BMW Car IT we are working on an experimental feature to
improve sstate cache hits and we are looking for comments on the
approach who might have some insights to the problem and seeing if
anyone is interested in the feature for mainline.

Sorry I didn't see this before now but it was brought to my attention.

I have given this problem quite some thought off and on. I do worry
that the interface you propose is complex and requires changes
throughout the metadata and those changes impose "policy". One of our
strengths is that we're managed to keep "policy" out of the metadata.

In this context by policy, I mean when a recipe is equivalent and when
it is not.

I do have a counter-proposal of how we could solve this in a less
invasive way. This isn't implemented but wouldn't in theory be hard to
do.

The idea would be to have some kind of equivalence list. The first
built object's sstate checksum would become the definitive checksum and
the object added to the sstate cache.

If a new object is built, it would be compared with the one in sstate.
If deemed equivalent (by whatever policy), a mapping would be added to
the list. If not, there is no mapping and it becomes a new definitive
checksum.

All runqueue would then have to do is present its list of sstate
checksums to the list and convert them (in dependency order) into
canonical checksums.

This list could be a local equivalence file, or an equivalence server
which could resolve list of checksums.

Doing it this way totally isolates the comparison from the metadata
itself and in my view protects us from future changes in definition of
equivalence.

How does that sound?

Cheers,

Richard

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