Date   

Writing do_compile in python and importing modules

Patrick Doyle <wpdster@...>
 

i was just reviewing a recipe I wrote a month or two ago and saw that I wrote:

do_compile() {
python3 ${WORKDIR}/assemble-tsk-blob.py -o tsk-blob -d
${DEPLOY_DIR_IMAGE}/foo -t ${DEPLOY_DIR_IMAGE}/bar
}

and I thought to myself, why did I write assemble-tsk-blob.py (which
is a fairly trivial python 10 line script) instead of embedding it
inline in my bitbake recipe?

The answer is: because I could iterate on that 10 line script and test
it much more quickly as a standalone python script than I could if I
embedded it in a recipe. (There are another 10-15 lines of argparse
and if __name__ == '__main__' stuff beyond the 10 lines of actual
code).

Since I'm in a cleaning-up mood, I started wondering if I could change
my do_compile() function to a python function and then embed the 10
lines in there. Of course I can.

But then I started wondering if I could change do_compile to python,
have it import assemble-tsk-blob, and get the best of both worlds --
the ability to test assemble-tsk-blob outside of bitbake, and the
efficiency of including its core operation directly within
do_compile() and not requring that I spin up another python instance.

Aside... there is nothing python3-ish about this code, I am just in
the habit of unquestioningly using python3 for all new development.

Any thoughts?

--wpd


[OE-core] [PATCH 0/2] fix can't login when debug-tweaks is not in IMAGE_FEATURES

Varun A <vashok890@...>
 

Was going through this thread. I see root password defined as root explicitly in the base-passwd master file I am using which is of security concern. Has any development come about this?Is there a patch to get around this issue?


Kernel modules build fails with bitbake but not host toolchain

Dimitris Tassopoulos
 

Hi all.

I'm having difficult to debug an issue I have.
Although I'm able to build my kernel, overlays, dtb and modules without any errors using a specific git repo and my toolchain on my host, the bitbake fails to build in the `do_compile_kernelmodules` step and the error I get is:

```
| /docker/build/tmp/work-shared/nanopi-duo2/kernel-source/drivers/net/wireless/realtek/rtl8189fs/core/rtw_cmd.c:22:10: fatal error: drv_types.h: No such file or directory
|    22 | #include <drv_types.h>
|       |          ^~~~~~~~~~~~~
| compilation terminated.
| /docker/build/tmp/work-shared/nanopi-duo2/kernel-source/scripts/Makefile.build:280: recipe for target 'drivers/net/wireless/realtek/rtl8189fs/core/rtw_cmd.o' failed
| make[6]: *** [drivers/net/wireless/realtek/rtl8189fs/core/rtw_cmd.o] Error 1
| /docker/build/tmp/work-shared/nanopi-duo2/kernel-source/scripts/Makefile.build:497: recipe for target 'drivers/net/wireless/realtek/rtl8189fs' failed
| make[5]: *** [drivers/net/wireless/realtek/rtl8189fs] Error 2
| /docker/build/tmp/work-shared/nanopi-duo2/kernel-source/scripts/Makefile.build:497: recipe for target 'drivers/net/wireless/realtek' failed
| make[4]: *** [drivers/net/wireless/realtek] Error 2
| make[4]: *** Waiting for unfinished jobs....
```

Of course the drv_types.h file is there and I've said the kernel builds fine using any toolchain from version 7.2 up to 8, I've tried locally on my workstation.

The kernel recipe is located here:

I've also tried to override the default do_compile_kernelmodules and simplify it down to this, but it still fails with the same error:
```
oe_runmake modules
```

Any good ideas?

Thanks!


[meta-selinux][PATCH] support policy module configuration at recipe level

Joe MacDonald
 

On highly storage-limited machines it may be beneficial to completely
remove some or all non-essential policy modules. refpolicy already
supports this with the 'no' option in modules.conf, so we'll just expose
this feature (with an appropriate warning) at the recipe-level.

Signed-off-by: Joe MacDonald <joe_macdonald@...>
---
.../refpolicy/refpolicy-minimum_2.20190201.bb | 10 ++++++++++
recipes-security/refpolicy/refpolicy-minimum_git.bb | 11 +++++++++++
recipes-security/refpolicy/refpolicy_common.inc | 10 ++++++++++
3 files changed, 31 insertions(+)

diff --git a/recipes-security/refpolicy/refpolicy-minimum_2.20190201.bb b=
/recipes-security/refpolicy/refpolicy-minimum_2.20190201.bb
index 40abe35..01c9fc0 100644
--- a/recipes-security/refpolicy/refpolicy-minimum_2.20190201.bb
+++ b/recipes-security/refpolicy/refpolicy-minimum_2.20190201.bb
@@ -44,6 +44,16 @@ EXTRA_POLICY_MODULES +=3D "mta"
# hostname_t, ping_t, netutils_t) from modules:
EXTRA_POLICY_MODULES +=3D "modutils consoletype hostname netutils"
=20
+# Add specific policy modules here that should be purged from the system
+# policy. Purged modules will not be built and will not be installed on=
the
+# target. To use them at some later time you must specifically build an=
d load
+# the modules by hand on the target.
+#
+# USE WITH CARE! With this feature it is easy to break your policy by p=
urging
+# core modules (eg. userdomain)
+#=20
+# PURGE_POLICY_MODULES +=3D "xdg xen"
+
POLICY_MODULES_MIN =3D "${CORE_POLICY_MODULES} ${EXTRA_POLICY_MODULES}"
=20
# re-write the same func from refpolicy_common.inc
diff --git a/recipes-security/refpolicy/refpolicy-minimum_git.bb b/recipe=
s-security/refpolicy/refpolicy-minimum_git.bb
index 40abe35..3b3ca15 100644
--- a/recipes-security/refpolicy/refpolicy-minimum_git.bb
+++ b/recipes-security/refpolicy/refpolicy-minimum_git.bb
@@ -44,6 +44,17 @@ EXTRA_POLICY_MODULES +=3D "mta"
# hostname_t, ping_t, netutils_t) from modules:
EXTRA_POLICY_MODULES +=3D "modutils consoletype hostname netutils"
=20
+# Add specific policy modules here that should be purged from the system
+# policy. Purged modules will not be built and will not be installed on=
the
+# target. To use them at some later time you must specifically build an=
d load
+# the modules by hand on the target.
+#
+# USE WITH CARE! With this feature it is easy to break your policy by p=
urging
+# core modules (eg. userdomain)
+#=20
+# PURGE_POLICY_MODULES +=3D "xdg xen"
+
+
POLICY_MODULES_MIN =3D "${CORE_POLICY_MODULES} ${EXTRA_POLICY_MODULES}"
=20
# re-write the same func from refpolicy_common.inc
diff --git a/recipes-security/refpolicy/refpolicy_common.inc b/recipes-se=
curity/refpolicy/refpolicy_common.inc
index 137ccee..2d9ace5 100644
--- a/recipes-security/refpolicy/refpolicy_common.inc
+++ b/recipes-security/refpolicy/refpolicy_common.inc
@@ -122,8 +122,18 @@ python __anonymous () {
d.setVar('DEFAULT_ENFORCING', 'permissive')
}
=20
+disable_policy_modules () {
+ for module in ${PURGE_POLICY_MODULES} ; do
+ sed -i "s/^\(\<${module}\>\) *=3D *.*$/\1 =3D off/" ${S}/policy/module=
s.conf
+ done
+}
+
do_compile() {
+ if [ -f "${WORKDIR}/modules.conf" ] ; then
+ cp -f ${WORKDIR}/modules.conf ${S}/policy/modules.conf
+ fi
oe_runmake conf
+ disable_policy_modules
oe_runmake policy
}
=20
--=20
2.20.1


Fixing vulnerabilities in glibc #yocto

Milun Jovanovic
 

My greeting to all
I am new on yocto project and yocto build environment is also new to me ...
My working task is removing  vulnerabilities from libc library...
The processor is based on arm5 while newer yoctos 2.7.x and 3.x. do not provide environment support for arm5 based processors.

The glibc vulnerabilities are fixed in the latest glibc 2.30 released. package while yocto 2.6.x  includes 2.28 package.
Also some of glibc vulnerabilities are patched in 2.6.4 (\oecore-thud-20.0.4.tar\oecore-thud-20.0.4\meta\recipes-core\glibc\glibc):

CVE-2016-10739
CVE-2018-19591
CVE-2019-6488
CVE-2019-7309
CVE-2019-9169
while there are some others those have not been patched:


Re: Issues with alsa-state

Andy Pont
 

Quentin wrote...

Have a look at the paths traversed by Yocto to find your asound.state in
log.do_fetch in the WORKDIR.
 
You'll have the following:
DEBUG: Searching for asound.state in paths:
There are a lot of paths that it searched in for the file. I’ve moved the file in the file system changed the value of FILESEXTRAPATHS_prepend_mx6 from: 

FILESEXTRAPATHS_prepend_mx6 := "${THISDIR}/${PN}/imx:”

to:

FILESEXTRAPATHS_prepend_mx6 := "${THISDIR}/${PN}:”

That has made the build process find my version of asound.state first.

Thanks,

-Andy.


Re: Unable to build core-image-full-cmdline on openSUSE Leap 15.1: dnf can't find _curses module in do_rootfs task

Alexander Kanavin
 

This error means native python3 was somehow built without curses, or isn't able to use the curses module that was built, so installing host packages isn't going to help. You need to look into how python3 was built and installed into recipe-sysroot-native. I can't offer more specific guidance than that unfortunately.

Alex


On Sun, 8 Dec 2019 at 22:33, Rebecca Cran <rebecca@...> wrote:
I recently switched from Ubuntu 19.10 to openSUSE Leap 15.1, but I'm having problems building core-image-full-cmdline on it. I've installed all the host packages I can think of, including python-curses and python3-curses, with no success.

I'm on the zeus branch, and running "bitbake core-image-full-cmdline" results in the following error when running the do_rootfs task:

ERROR: core-image-full-cmdline-1.0-r0 do_rootfs: Could not invoke dnf. Command '/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/bin/dnf -v --rpmverbosity=info -y -c /home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/rootfs/etc/dnf/dnf.conf --setopt=reposdir=/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/rootfs/etc/yum.repos.d --installroot=/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/rootfs --setopt=logdir=/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/temp --repofrompath=oe-repo,/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/oe-rootfs-repo makecache --refresh' returned 1:
Traceback (most recent call last):
  File "/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/bin/dnf.real", line 57, in <module>
    from dnf.cli import main
  File "/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/dnf/cli/__init__.py", line 30, in <module>
    from dnf.cli.cli import Cli  # :api
  File "/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 44, in <module>
    from . import output
  File "/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/dnf/cli/output.py", line 34, in <module>
    import dnf.cli.progress
  File "/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/dnf/cli/progress.py", line 19, in <module>
    from dnf.cli.term import _term_width
  File "/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/dnf/cli/term.py", line 21, in <module>
    import curses
  File "/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/curses/__init__.py", line 13, in <module>
    from _curses import *
ModuleNotFoundError: No module named '_curses'

ERROR: Logfile of failure stored in: /home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/temp/log.do_rootfs.40254
ERROR: Task (/home/bcran/src/fsl-community-bsp/sources/poky/meta/recipes-extended/images/core-image-full-cmdline.bb:do_rootfs) failed with exit code '1'

--
Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#47593): https://lists.yoctoproject.org/g/yocto/message/47593
Mute This Topic: https://lists.yoctoproject.org/mt/67777408/1686489
Group Owner: yocto+owner@...
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  [alex.kanavin@...]
-=-=-=-=-=-=-=-=-=-=-=-


Re: Issues with alsa-state

Quentin Schulz
 

Hi Andy,

On Mon, Dec 09, 2019 at 10:40:49AM +0000, Andy Pont wrote:
Hello!

I am trying to add a custom asound.state file into my Zeus based i.MX6
image. I have created a custom .bbappend file with the following contents:

FILESEXTRAPATHS_prepend_mx6 := "${THISDIR}/${PN}/imx:”
PACKAGE_ARCH_mx6 = "${MACHINE_ARCH}”

The output from:

$ bitbake-layers show-appends | grep alsa

is (some names changed to protect the guilty):

alsa-state.bb:
/home/.../sources/meta-freescale/recipes-bsp/alsa-state/alsa-state.bbappend
/home/.../sources/meta-boundary/recipes-bsp/alsa-state/alsa-state.bbappend
/home/.../sources/meta-project/recipes-bsp/alsa-state/alsa-state.bbappend

The file that is included in the image is the one from the meta-boundary
layer and not the one from my “meta-project” layer. Is there some way to
make my layer take priority or do I need to try to exclude the alsa-state
recipes from the meta-freescale and meta-boundary layers using BBMASK?
Have a look at the paths traversed by Yocto to find your asound.state in
log.do_fetch in the WORKDIR.

You'll have the following:
DEBUG: Searching for asound.state in paths:

The first path to have asound.state in it will be the provider for that
file.

This order is derived from OVERRIDES variable (rightmost to leftmost for
priority order). Basically, rightmost in OVERRIDES is taken, then looked
for in all FILESPATHS paths. Then the second rightmost.

What people usually do is that they use a lower priority OVERRIDES for
subdirectory filename and then the original one or one in a higher
priority OVERRIDES is taken.

Quentin


Issues with alsa-state

Andy Pont
 

Hello!

I am trying to add a custom asound.state file into my Zeus based i.MX6 image.  I have created a custom .bbappend file with the following contents:

FILESEXTRAPATHS_prepend_mx6 := "${THISDIR}/${PN}/imx:”
PACKAGE_ARCH_mx6 = "${MACHINE_ARCH}”

The output from:

    $ bitbake-layers show-appends | grep alsa

is (some names changed to protect the guilty):

    alsa-state.bb:
      /home/.../sources/meta-freescale/recipes-bsp/alsa-state/alsa-state.bbappend
      /home/.../sources/meta-boundary/recipes-bsp/alsa-state/alsa-state.bbappend
      /home/.../sources/meta-project/recipes-bsp/alsa-state/alsa-state.bbappend

The file that is included in the image is the one from the meta-boundary layer and not the one from my “meta-project” layer.  Is there some way to make my layer take priority or do I need to try to exclude the alsa-state recipes from the meta-freescale and meta-boundary layers using BBMASK?

-Andy.



Re: [meta-security][PATCH] meta-security: add layer index callouts

Diego Santa Cruz
 

-----Original Message-----
From: yocto@... <yocto@...> On Behalf
Of Armpit via Lists.Yoctoproject.Org
Sent: 06 December 2019 18:38
To: yocto@...
Cc: yocto@...
Subject: [yocto] [meta-security][PATCH] meta-security: add layer index callouts

Signed-off-by: Armin Kuster <akuster808@...>
---
meta-integrity/conf/layer.conf | 2 ++
meta-security-compliance/conf/layer.conf | 2 ++
meta-tpm/conf/layer.conf | 1 +
3 files changed, 5 insertions(+)

diff --git a/meta-integrity/conf/layer.conf b/meta-integrity/conf/layer.conf
index 962424c..bfc9c6f 100644
--- a/meta-integrity/conf/layer.conf
+++ b/meta-integrity/conf/layer.conf
@@ -24,3 +24,5 @@ OE_TERMINAL_EXPORTS += "INTEGRITY_BASE"
LAYERSERIES_COMPAT_integrity = "zeus"
# ima-evm-utils depends on keyutils from meta-oe
LAYERDEPENDS_integrity = "core openembedded-layer"
+
+BBLAYERS_LAYERINDEX_NAME_integrity = "meta-integrity"
diff --git a/meta-security-compliance/conf/layer.conf b/meta-security-
compliance/conf/layer.conf
index 0e93bd0..e346bf3 100644
--- a/meta-security-compliance/conf/layer.conf
+++ b/meta-security-compliance/conf/layer.conf
@@ -11,3 +11,5 @@ BBFILE_PRIORITY_scanners-layer = "10"
LAYERSERIES_COMPAT_scanners-layer = "zeus"

LAYERDEPENDS_scanners-layer = "core openembedded-layer meta-python"
+
+BBLAYERS_LAYERINDEX_NAME_integrity = "meta-security-compliance"
This looks like a copy & paste typo, shouldn't this be

+BBLAYERS_LAYERINDEX_NAME_scanners-layer = "meta-security-compliance"

diff --git a/meta-tpm/conf/layer.conf b/meta-tpm/conf/layer.conf
index 3af2d95..175eba8 100644
--- a/meta-tpm/conf/layer.conf
+++ b/meta-tpm/conf/layer.conf
@@ -14,3 +14,4 @@ LAYERDEPENDS_tpm-layer = " \
core \
openembedded-layer \
"
+BBLAYERS_LAYERINDEX_NAME_tpm-layer = "meta-tpm"
--
2.17.1
--
Diego Santa Cruz, PhD
Technology Architect
spinetix.com


Dhcp-server rpm dependent on base-passwd rpm

Varun A <vashok890@...>
 

Wanted to know if dhcp-server has an actual dependency with base-passwd rpm or is it an optional dependency. I am using dhcp-server 4.3.2 rpm and when I try rpm -qpR dhcp-server 4.3.2.rpm I see base-passwd in it. Can I remove the dependency using a bbappend file?


[ Error ] python3-psycopg2-native recipe build error #yocto #python

dishant.arora1996@...
 

Recipe --> python3-psycopg2-native --> https://layers.openembedded.org/layerindex/recipe/72275/
Added this recipe using `IMAGE_INSTALL` variable in `sjpl-image.bb` file 

Got following errors while building the image :  

ERROR: Task do_populate_sdk in /home/ubuntu/build-torizon/meta-sjpl/recipes-sjpl/images/sjpl-image.bb rdepends upon non-existent task do_package_write_ipk in /home/ubuntu/layers/openembedded-core/meta-spdxscanner/recipes-devtools/python/python3-psycopg2-native_2.6.1.bb

ERROR: Command execution failed: 1

How can this error be resolved ?


[meta-selinux][PATCH] rename sed_4.2.2.bbappend to sed_4.%.bbappend

hongxu
 

Since upstream oe-core [bd40260cba sed: upgrade to 4.7],
renme bbappend to match the new version

Signed-off-by: Hongxu Jia <hongxu.jia@...>
---
recipes-extended/sed/{sed_4.2.2.bbappend => sed_4.%.bbappend} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename recipes-extended/sed/{sed_4.2.2.bbappend => sed_4.%.bbappend} (100%)

diff --git a/recipes-extended/sed/sed_4.2.2.bbappend b/recipes-extended/sed/sed_4.%.bbappend
similarity index 100%
rename from recipes-extended/sed/sed_4.2.2.bbappend
rename to recipes-extended/sed/sed_4.%.bbappend
--
2.21.0


[layerindex-web][PATCH 0/5] Misc bug fixes [cover letter only]

Paul Eggleton
 

Updates some bundled components (jQuery, Chart.js, Bootstrap) and fixes
a couple of bugs in the layer update script and background task display
for admins.


The following changes since commit f84223f4730cd171d25c980b43f07d89950f46=
bd:

README.devel: mention python SMTP server (2019-11-26 10:44:37 +1300)

are available in the Git repository at:

git://git.yoctoproject.org/layerindex-web paule/fixes15
http://git.yoctoproject.org/cgit.cgi/layerindex-web/log/?h=3Dpaule/fixe=
s15

Paul Eggleton (5):
Upgrade Bootstrap to 3.4.1
Upgrade jquery to 3.4.1
Upgrade Chart.js to 2.9.3
update: ensure removed recipe dependencies are removed from db
tasks: squash out CRs in task logs to avoid huge transfers

layerindex/recipeparse.py | 12 +-
layerindex/static/css/bootstrap-theme.css | 200 +-
layerindex/static/css/bootstrap-theme.css.map | 2 +-
layerindex/static/css/bootstrap-theme.min.css | 6 +-
.../static/css/bootstrap-theme.min.css.map | 2 +-
layerindex/static/css/bootstrap.css | 985 +-
layerindex/static/css/bootstrap.css.map | 2 +-
layerindex/static/css/bootstrap.min.css | 6 +-
layerindex/static/css/bootstrap.min.css.map | 2 +-
layerindex/static/js/Chart.js | 25319 +++++++++-------
layerindex/static/js/Chart.min.js | 13 +-
layerindex/static/js/bootstrap.js | 397 +-
layerindex/static/js/bootstrap.min.js | 7 +-
.../js/{jquery-3.3.1.js =3D> jquery-3.4.1.js} | 596 +-
layerindex/update_layer.py | 2 +-
layerindex/views.py | 7 +-
templates/base.html | 2 +-
17 files changed, 14925 insertions(+), 12635 deletions(-)
rename layerindex/static/js/{jquery-3.3.1.js =3D> jquery-3.4.1.js} (94%)

--=20
2.20.1


Unable to build core-image-full-cmdline on openSUSE Leap 15.1: dnf can't find _curses module in do_rootfs task

Rebecca Cran <rebecca@...>
 

I recently switched from Ubuntu 19.10 to openSUSE Leap 15.1, but I'm having problems building core-image-full-cmdline on it. I've installed all the host packages I can think of, including python-curses and python3-curses, with no success.

I'm on the zeus branch, and running "bitbake core-image-full-cmdline" results in the following error when running the do_rootfs task:

ERROR: core-image-full-cmdline-1.0-r0 do_rootfs: Could not invoke dnf. Command '/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/bin/dnf -v --rpmverbosity=info -y -c /home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/rootfs/etc/dnf/dnf.conf --setopt=reposdir=/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/rootfs/etc/yum.repos.d --installroot=/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/rootfs --setopt=logdir=/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/temp --repofrompath=oe-repo,/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/oe-rootfs-repo makecache --refresh' returned 1:
Traceback (most recent call last):
  File "/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/bin/dnf.real", line 57, in <module>
    from dnf.cli import main
  File "/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/dnf/cli/__init__.py", line 30, in <module>
    from dnf.cli.cli import Cli  # :api
  File "/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 44, in <module>
    from . import output
  File "/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/dnf/cli/output.py", line 34, in <module>
    import dnf.cli.progress
  File "/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/dnf/cli/progress.py", line 19, in <module>
    from dnf.cli.term import _term_width
  File "/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/dnf/cli/term.py", line 21, in <module>
    import curses
  File "/home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/curses/__init__.py", line 13, in <module>
    from _curses import *
ModuleNotFoundError: No module named '_curses'

ERROR: Logfile of failure stored in: /home/bcran/src/fsl-community-bsp/build-imx6slevk/tmp/work/imx6slevk-fslc-linux-gnueabi/core-image-full-cmdline/1.0-r0/temp/log.do_rootfs.40254
ERROR: Task (/home/bcran/src/fsl-community-bsp/sources/poky/meta/recipes-extended/images/core-image-full-cmdline.bb:do_rootfs) failed with exit code '1'

--
Rebecca Cran


Re: [meta-security][PATCH 0/2] tpm2-abrmd: startup fixes

Armin Kuster
 

merged.
thanks,
Armin

On 12/6/19 2:13 AM, Diego Santa Cruz via Lists.Yoctoproject.Org wrote:
This ports patches from the meta-measured layer that fix tpm2-abrmd
not starting up.
The first patch is necessary on kernels 4.12 and later.
The second patch is necessary after the update to 2.3.0.

Philip Tricca (1):
  tpm2-abrmd: Port command line options to new version.

Trevor Woerner (1):
  tpm2-abrmd-init.sh: fix for /dev/tpmrmX

 meta-tpm/recipes-tpm2/tpm2-abrmd/files/tpm2-abrmd-init.sh | 2 +-
 meta-tpm/recipes-tpm2/tpm2-abrmd/files/tpm2-abrmd.default | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#47581): https://lists.yoctoproject.org/g/yocto/message/47581
Mute This Topic: https://lists.yoctoproject.org/mt/67467010/1024635
Group Owner: yocto+owner@...
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  [akuster@...]
-=-=-=-=-=-=-=-=-=-=-=-


Re: What should I expect when using SSTATE_MIRROR?

Mans Zigher <mans.zigher@...>
 

Hi, 

I am also using docker when building but good point I will make sure that we are using the same version of the docker image.

Thanks

On Fri, Dec 6, 2019, 17:06 <Mikko.Rapeli@...> wrote:
Hi,

On Fri, Dec 06, 2019 at 02:07:47PM +0100, Mans Zigher wrote:
> Hi,
>
> I am trying to use the sstate cache by using a SSTATE_MIRROR. I have
> built everything from scratch once and pushed my sstate-cache
> directory to the server. I then wen't over to another machine and did
> a clean build but this time I made sure it used SSTATE_MIRROR but the
> result was not what I expected
>
> Sstate summary: Wanted 1255 Found 233 Missed 2044 Current 0 (18%
> match, 0% complete)
>
> I have tried it multiple times on different machines with the same
> result the only time it works as expect is when running the build on
> the first machine from which the sstate cache was originally coming
> from. Am I missing something? Or is this expected?

Maybe host tool versions differ which trigger recompilation of things
like gcc and thus everything gets recompiled. You can use bitbake-diffsigs
to figure out why rebuild was triggered.

I work around this by using a build container based on LXC and Debian stable
everywhere, in CI and on developer machines with various Linux distros.

Hope this helps,

-Mikko


[meta-mingw][PATCH] wayland: Disable DTD validation on i686 MinGW

Joshua Watt
 

DTD validation can't be built for i686 MinGW because the assembly file
used to encode the DTD string is incompatible (it works fine for x86_64
MinGW though).

Signed-off-by: Joshua Watt <JPEWhacker@...>
---
recipes-graphics/wayland/wayland_%.bbappend | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/recipes-graphics/wayland/wayland_%.bbappend b/recipes-graphics/wayland/wayland_%.bbappend
index 3713f2d..bbb1c52 100644
--- a/recipes-graphics/wayland/wayland_%.bbappend
+++ b/recipes-graphics/wayland/wayland_%.bbappend
@@ -1,2 +1,6 @@
+# The assembly file that encodes the DTD string into wayland-scanner is not
+# compatible with i686 MinGW
+PACKAGECONFIG_remove_mingw32_i686 = "dtd-validation"
+
EXTRA_OECONF_class-nativesdk_mingw32 = "--disable-documentation --disable-libraries"

--
2.23.0


[meta-security][PATCH] meta-security: add layer index callouts

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
meta-integrity/conf/layer.conf | 2 ++
meta-security-compliance/conf/layer.conf | 2 ++
meta-tpm/conf/layer.conf | 1 +
3 files changed, 5 insertions(+)

diff --git a/meta-integrity/conf/layer.conf b/meta-integrity/conf/layer.conf
index 962424c..bfc9c6f 100644
--- a/meta-integrity/conf/layer.conf
+++ b/meta-integrity/conf/layer.conf
@@ -24,3 +24,5 @@ OE_TERMINAL_EXPORTS += "INTEGRITY_BASE"
LAYERSERIES_COMPAT_integrity = "zeus"
# ima-evm-utils depends on keyutils from meta-oe
LAYERDEPENDS_integrity = "core openembedded-layer"
+
+BBLAYERS_LAYERINDEX_NAME_integrity = "meta-integrity"
diff --git a/meta-security-compliance/conf/layer.conf b/meta-security-compliance/conf/layer.conf
index 0e93bd0..e346bf3 100644
--- a/meta-security-compliance/conf/layer.conf
+++ b/meta-security-compliance/conf/layer.conf
@@ -11,3 +11,5 @@ BBFILE_PRIORITY_scanners-layer = "10"
LAYERSERIES_COMPAT_scanners-layer = "zeus"

LAYERDEPENDS_scanners-layer = "core openembedded-layer meta-python"
+
+BBLAYERS_LAYERINDEX_NAME_integrity = "meta-security-compliance"
diff --git a/meta-tpm/conf/layer.conf b/meta-tpm/conf/layer.conf
index 3af2d95..175eba8 100644
--- a/meta-tpm/conf/layer.conf
+++ b/meta-tpm/conf/layer.conf
@@ -14,3 +14,4 @@ LAYERDEPENDS_tpm-layer = " \
core \
openembedded-layer \
"
+BBLAYERS_LAYERINDEX_NAME_tpm-layer = "meta-tpm"
--
2.17.1


sdk rpi3 & rpi4 different sysroot

Ed Vidal
 

Hi,
Any and all help is appreciated. Thanks in advance.
Question 1
I tried using the sdk to build icestorm (a makefile project).  The sysroot for rpi3 sdk & rpi4 sdk are
missing a ftdi.h header.  The target rpi4 builds icestorm okay.  see steps below.

Question 2
What is the procedure to update the meta-raspberrypi repo?
An issue with core-image-sato for rpi3 required adding
vidal@ws009:~/wkg/yocto-zeus-3.0/raspberrypi4/poky/meta-raspberrypi$ git diff
diff --git a/conf/machine/raspberrypi3.conf b/conf/machine/raspberrypi3.conf
index 581e47c..43a0a25 100644
--- a/conf/machine/raspberrypi3.conf
+++ b/conf/machine/raspberrypi3.conf
@@ -18,3 +18,4 @@ UBOOT_MACHINE = "rpi_3_32b_config"
SERIAL_CONSOLES ?= "115200;ttyS0"
 
ARMSTUB ?= "armstub7.bin"
+ENABLE_UART = "1"
For rpi4 build I made the same in raspberrypi4.conf 
diff --git a/conf/machine/raspberrypi4.conf b/conf/machine/raspberrypi4.conf
index 1bcf931..0b91515 100644
--- a/conf/machine/raspberrypi4.conf
+++ b/conf/machine/raspberrypi4.conf
@@ -18,3 +18,4 @@ SERIAL_CONSOLES ?= "115200;ttyS0"
 
VC4DTBO ?= "vc4-fkms-v3d"
ARMSTUB ?= "armstub7.bin"
+ENABLE_UART = "1"
Question 3
Why is the header file ftdi.h missing in rpi4 sdk and not used in rpi3 sdk? 

vidal@ws009:~/wkg/test-yocto-sdk$ git clone https://github.com/develone/icestorm.git

vidal@ws009:~/wkg/test-yocto-sdk$ . /opt/poky/3.0.1/rpi4/environment-setup-cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi

vidal@ws009:~/wkg/test-yocto-sdk$ cd icestorm/

vidal@ws009:~/wkg/test-yocto-sdk$ echo ${CC}
arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/opt/poky/3.0.1/rpi4/sysroots/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi

vidal@ws009:~/wkg/test-yocto-sdk/icestorm$ time make -e

The following error:
make[1]: Entering directory '/home/vidal/wkg/test-yocto-sdk/icestorm/iceprog'
arm-poky-linux-gnueabi-gcc  -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/opt/poky/3.0.1/rpi4/sysroots/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi  -O2 -pipe -g -feliminate-unused-debug-types    -c -o iceprog.o iceprog.c
iceprog.c:27:10: fatal error: ftdi.h: No such file or directory
   27 | #include <ftdi.h>
      |          ^~~~~~~~
compilation terminated.

Tried to locate ftdi.h using the command below none was found in my rpi4 sdk sysroot.

vidal@ws009:~/wkg/test-yocto-sdk/icestorm$ find /opt/poky/3.0.1/rpi4/sysroots/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/ -name ftdi.h

A ftdi.h file was found in my rpi3 sdk sysroot.
vidal@ws009:~/wkg/test-yocto-sdk/icestorm$ find /opt/poky/3.0.1/sysroots/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/ -name ftdi.h
/opt/poky/3.0.1/sysroots/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/usr/include/libftdi1/ftdi.h

The only difference between the raspberrypi3 & raspberrypi4 builds are below.
vidal@ws009:~/wkg/yocto-zeus-3.0/raspberrypi4/build$ diff ../../build/conf/local.conf conf/local.conf 
39c39
< MACHINE ??= "raspberrypi3"
---
> MACHINE ??= "raspberrypi4"
66a67
> DL_DIR ?= "/home/vidal//wkg/yocto-zeus-3.0/build/downloads"
Testing rpi3 sdk

vidal@ws009:~/wkg/test-yocto-sdk/icestorm$ . /opt/poky/3.0.1/environment-setup-cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi

vidal@ws009:~/wkg/test-yocto-sdk/icestorm$ echo ${CC}
arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/opt/poky/3.0.1/sysroots/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi

vidal@ws009:~/wkg/test-yocto-sdk/icestorm$ make -e

The rpi3 sdk gets the same error as the rpi4 sdk (see above). 
target rpi4
real 23m38.686s
user 23m16.332s
sys 0m9.949s

AMD 6 core sdk
real 3m33.809s
user 3m33.304s
sys 0m0.556s


Let me know if I can provide additional information,
Regards
Edward Vidal Jr. e-mail develone@... 915-595-1613

9781 - 9800 of 57387