Recipe --> python3-psycopg2-native --> https://layers.openembedded.org/layerindex/recipe/72275/

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 ?

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

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

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

merged.
thanks,
Armin

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

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

We are happy to inform everyone that tickets to the inaugural
OpenEmbedded Workshop are now on sale. Early bird tickets are
available for 1/3rd off regular price. Also, we are offering a
"Supporter Ticket". This is for those who are able to contribute more
to help support OpenEmbedded, and/or would like to see more events
similar to this in the future.
Both of these can be purchased at
https://pretix.eu/OpenEmbedded/oe-workshop-2020/

Get your tickets now, as we expect these to sellout quickly. Also,
early bird pricing ends on December 31st.

Finally, there are still a few slots open for Speakers. If you have a
talk you would like to give, go to
https://pretalx.com/oe-workshop-2020/cfp
CFP deadline is December 15th.

More information on the OpenEmbedded Workshop can be found at
https://pretalx.com/oe-workshop-2020/

Thank you,
The OpenEmbedded Board

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

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?

Thanks

/Måns Zigher

A little context before the actual questions. As a project that I have worked on grew, the number of repositories used for the application we're developing grew as well. To the point that it's gotten unbearable to keep making modifications to the codebase: when something is changed in the core library in one repository we need to make adjustments to other Python middleware projects that use this library. Whereas this sounds not that terrifying, managing this in Yocto has become a burden: on every version bump of the Python library we need to bump all of the dependant projects as well. After some thinking, we decided to try a monorepo approach to deal with the complexity. I'm omitting the logic behind choosing this approach but I can delve into it if you think this is wrong.

1) Phase 1 was easy. Just bring every component of our middleware to one repository. Right now we have a big repository with more than git 20 submodules. Submodules will be gone once we finish the transition but as the project doesn't stop while we're doing the transition, submodules were chosen to track the changes and keep the monorepo up to date. Every submodule is a Python code with a setup.py/Pipfile et al. that does the bootstrapping.

2) Phase 2 is to integrate everything in Yocto. It has turned out to be more difficult than I had anticipated.

Right now we have this:

Application monorepo

Pipfile
python-library1/setup.py
python-library1/Makefile
python-library1/python-library1/<code>


python-library2/setup.py
python-library2/Makefile
python-library2/python-library2/<code>


...
python-libraryN/setup.py
python-libraryN/Makefile
python-libraryN/python-libraryN/<code>

Naturally, right now we have python-library1_<some_version>.bb, python-library2_<some_other_version>.bb in Yocto. Now we want to get rid of this version hell and stick to monorepo versions so that we could have just monorepo_1.0.bb that is to be updated when anything changes in any part.

Right now I have the layout described below.

monorepo.inc is as follows:

SRC_URI=<gitsm://the location of the monorepo,branch=...,>
S = "${WORKDIR}/git"
SRCREV = <hash>

python-libraryN.inc:

require monorepo.inc
S = "${WORKDIR}/git/python-libraryN"
inherit setuptools

#some libraries also use entry points and the recipe needs to inherit systemd to enable some services.

This approach works. But it has a very significant drawback I can't ignore. Every time SRCREV (or PV/tag in the future) is changed every recipe downloads the whole repository that is quite big.

So, well, the question is how to structure the Yocto recipes for Python monorepo manipulation? I'm looking for a way to trick do_unpack and do_fetch to their thing on the monorepo basis.

This section of the documentation makes me think that I'm approaching this task wrong. I was trying to decipher gcc-source.inc and gcc-shared-source.inc files in the poky but they are out of my depth for now and look a little bit overcomplicated for my use-case. So basically my question boils down to how to deal with multiple recipes referencing the same source. Any structural change to either the monorepo or the recipe structure can be done now, so I would be very grateful for any feedback.

P.S. 1) The monorepo structure is not set in stone so if you have any suggestions, I'm more than open to any criticism 2) The .inc file structure might not be suitable for another reason. This stack is deployed across a dozen of different devices and some of those python-library_N.bb have .bbappends in other layers that are custom for the devices. I mean that some of them might require different components of the system installed or some configs and files/ modifications.

Any suggestion on how to deal with the complexity of a big Python application in Yocto will be welcome. Thanks in advance.

From: Philip Tricca <flihp@...>

These have changed upstream.

Signed-off-by: Philip Tricca <flihp@...>
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@...>
---
meta-tpm/recipes-tpm2/tpm2-abrmd/files/tpm2-abrmd.default | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-tpm/recipes-tpm2/tpm2-abrmd/files/tpm2-abrmd.default b/meta-tpm/recipes-tpm2/tpm2-abrmd/files/tpm2-abrmd.default
index 987978a..b4b3c20 100644
--- a/meta-tpm/recipes-tpm2/tpm2-abrmd/files/tpm2-abrmd.default
+++ b/meta-tpm/recipes-tpm2/tpm2-abrmd/files/tpm2-abrmd.default
@@ -1 +1 @@
-DAEMON_OPTS="--tcti=device --logger=syslog --max-connections=20 --max-transient-objects=20 --fail-on-loaded-trans"
+DAEMON_OPTS="--tcti=device --logger=syslog --max-connections=20 --max-transients=20 --flush-all"
--
2.18.1

From: Trevor Woerner <twoerner@...>

Newer kernels, in addition to the traditional /dev/tpmX device nodes, are now
also creating /dev/tpmrmX device nodes. This causes this script to get
confused and abort, meaning tpm2-abrmd does not get started during boot.

Fix for https://github.com/flihp/meta-measured/issues/56

Signed-off-by: Trevor Woerner <twoerner@...>
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@...>
---
meta-tpm/recipes-tpm2/tpm2-abrmd/files/tpm2-abrmd-init.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-tpm/recipes-tpm2/tpm2-abrmd/files/tpm2-abrmd-init.sh b/meta-tpm/recipes-tpm2/tpm2-abrmd/files/tpm2-abrmd-init.sh
index c8dfb7d..9bb7da9 100644
--- a/meta-tpm/recipes-tpm2/tpm2-abrmd/files/tpm2-abrmd-init.sh
+++ b/meta-tpm/recipes-tpm2/tpm2-abrmd/files/tpm2-abrmd-init.sh
@@ -27,7 +27,7 @@ case "${1}" in
start)
echo -n "Starting $DESC: "

- if [ ! -e /dev/tpm* ]
+ if [ ! -e /dev/tpm? ]
then
echo "device driver not loaded, skipping."
exit 0
--
2.18.1

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

--
2.18.1