Hi Alex,

Thank you for the hint. It led me to the source of the problem, which was libepoxy.

It looks that after changing configuration (DISTRO_FEATURES_remove = " x11"), SSTATE was still populating sysroot of gtk+3 with the older version of libepoxy configuration file (*.pc) creating dependency to 'gl' and 'x11'. In my case I had to call:

bitbake -c cleanall libepoxy

bitbake -c cleanall gtk+3

bitbake gtk+3

In order to avoid such issues in the future, is there any way to force bitbake (after such considerable configuration change like modification of DISTRO_FEATURES) to rebuild sysroot for each recipe if necessary instead of grabbing them from the cache ? I know, one could delete sstate-cache directory, but obviously it will enormously increase rebuild time. I have been wondering whether there is an intermediate solution.

Regards,

Adrian

On 09.11.2020 15:28, Alexander Kanavin wrote:

Do you actually need gtk+3 in your image?

There is a poky configuration that builds core-image-weston without x11, and core-image-weston does pull in gtk+3, and all that happens without errors:

http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/tree/config.json?h=zeus#n638

so I'd suggest you reproduce that, get it to build, then investigate where your build diverges.

Alex

On Mon, 9 Nov 2020 at 14:10, Adrian <adrian.fiergolski@...> wrote:

Hi,

I am building an image based on core-image-weston.

I would like to use only wayland backend, thus I defined in my machine's configuration:

DISTRO_FEATURES_append = " wayland"
DISTRO_FEATURES_remove = " x11"

I have a problem with build of gtk+3:

| checking for pango pangocairo gdk-pixbuf-2.0 >= 2.30.0 cairo >= 1.14.0 cairo-gobject >= 1.14.0 gio-unix-2.0 >= 2.53.4  wayland-client >= 1.9.91 wayland-protocols >= 1.12 xkbcommon >= 0.2.0 wayland-cursor >= 1.9.91 wayland-egl   cairo epoxy >= 1.4  fribidi >= 0.19.7... no
| configure: error: Package requirements (pango pangocairo gdk-pixbuf-2.0 >= 2.30.0 cairo >= 1.14.0 cairo-gobject >= 1.14.0 gio-unix-2.0 >= 2.53.4  wayland-client >= 1.9.91 wayland-protocols >= 1.12 xkbcommon >= 0.2.0 wayland-cursor >= 1.9.91 wayland-egl   cairo epoxy >= 1.4  fribidi >= 0.19.7) were not met:
|
| Package 'x11', required by 'gl', not found

The configuration flags in config.log seems to be ok:

  $ ../gtk+-3.24.8/configure --build=x86_64-linux --host=aarch64-poky-linux --target=aarch64-poky-linux --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib --includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/home/afiergol/fastree/falcon/poky/build/tmp/work/aarch64-poky-linux/gtk+3/3.24.8-r0/recipe-sysroot --enable-introspection --disable-gtk-doc --disable-glibtest --disable-xinerama --enable-modules --disable-colord --disable-gtk-doc --disable-static --disable-cups --disable-glx --enable-opengl --enable-wayland-backend --disable-x11-backend --enable-nls

Has anybody else experience similar issue? Do you know a fix? I work with the latest zeus (d88d62c20d7d8da85f02edb170dae0280624ad7e) version.

Regards,

Adrian

HI,
That's what I did exactly, but failed with the same error.
Here is the python3-cffi-native recipe:

SUMMARY = "Foreign Function Interface for Python calling C code."
HOMEPAGE = "http://cffi.readthedocs.org"
AUTHOR = "Armin Rigo, Maciej Fijalkowski <python-cffi@...>"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE;md5=5677e2fdbf7cdda61d6dd2b57df547bf"
SRC_URI = "https://files.pythonhosted.org/packages/cb/ae/380e33d621ae301770358eb11a896a34c34f30db188847a561e8e39ee866/cffi-1.14.3.tar.gz"
SRC_URI[md5sum] = "c2a47ffd5d183b193ac8ed3414dcfd07"
SRC_URI[sha256sum] = "f92f789e4f9241cd262ad7a555ca2c648a98178a953af117ef7fad46aa1d5591"
S = "${WORKDIR}/cffi-1.14.3"
RDEPENDS_${PN} = "python3-pycparser"
BBCLASSEXTEND = "native"
inherit setuptools3

and here is python3-psycopg2cffi recipe

SUMMARY = ".. image:: https://travis-ci.org/chtd/psycopg2cffi.svg?branch=master"
HOMEPAGE = "http://github.com/chtd/psycopg2cffi"
AUTHOR = "Konstantin Lopuhin <konstantin.lopuhin@...>"
LICENSE = "LGPL-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=edf147a599198440160215f8111f5bcf"
SRC_URI = "https://files.pythonhosted.org/packages/95/50/5b94b81a57948ce0350559aad8c20d250ff3b87868a5615efcc79704ba49/psycopg2cffi-2.8.1.tar.gz"
SRC_URI[md5sum] = "f67394d47803dab8a481402754bf83a1"
SRC_URI[sha256sum] = "fcaa4d5477a8205b33e8e9e6707a5c331a0f5d7f4af354529b6564377b678079"
S = "${WORKDIR}/psycopg2cffi-2.8.1"
DEPENDS = "python3-cffi-native"
RDEPENDS_${PN} = ""
inherit setuptools3

Hi Talel,

On Tue, Nov 10, 2020 at 05:23:09AM -0800, Bel Hadj Salem Talel wrote:

HI All,
I created a recipe with pipoe for python3-psycopg2cffi when compiling this error occured:

ERROR: Do not try to fetch `cffi>=1.0' for building. Please add its native
recipe to DEPENDS.

I created a recipe for python3-cffi and I made it native with BBCLASSEXTEND = "native" and it depends also on python3-pycparser which is already native and exist.
Then I added DEPENDS = "python3-cffi" to python3-psycopg2cffi recipe but failed with same error, I tried to rename the python3-cffi to just cffi but same error.

If the native version of python3-cffi is needed, add
DEPENDS = "python3-cffi-native".

Quentin

HI All,
I created a recipe with pipoe for python3-psycopg2cffi when compiling this error occured:

ERROR: Do not try to fetch `cffi>=1.0' for building. Please add its native recipe to DEPENDS.

I created a recipe for python3-cffi and I made it native with BBCLASSEXTEND = "native" and it depends also on python3-pycparser which is already native and exist.
Then I added DEPENDS = "python3-cffi" to python3-psycopg2cffi recipe but failed with same error, I tried to rename the python3-cffi to just cffi but same error.

What I'm missing ?
Thanks ,Talel

Hi Byron,

On Tue, Nov 10, 2020 at 09:09:05PM +0800, ouyangxuan10@163.com wrote:

Dear all，


I would like to ask the reasons for the following problems and how to solve them? When compiling a program, how to make a package not hash checked?

Did you execute the commands that were suggested in the log you sent?

Can you send us the content of the log of the second command please?

Basically, two possible ways this happens:
1. you modified the recipe while bitbake was running. Solution => don't
do that.
2. bitbake parses tasks multiple times during a run, therefore, if a
variable changes between parses your task will have a different hash.
This usually happens with DATETIME. If you don't absolutely need this
variable, remove it or find a replacement. If you have to, I think the
vardepsexclude variable flag is the way to do it?

Quentin

On Tue, 10 Nov 2020 at 09:56, Andy Basey <a.basey@landguardsystems.com> wrote:

I have an existing build with packages defined in my own layer outside the build directory in the local.conf.sample
I want to add a package so I add it to my local.conf.sample and then source oe-init-build-env again
It doesn't overwrite the local.conf in poky/build/conf as it already exists

Is there a preferred way to make it update?
Or do I just need to manually delete the files in that directory and then run source oe-init-build-env?
I don't want to delete the whole build directory as it takes far too long to do it again from scratch

For reference I am using the local.conf.sample because that is my source controllable config file

If you're adding packages to an image, the best thing to do is to
create your own image recipe and put that in your layer (so it will be
under version control).

--
Paul Barker
Konsulko Group

I have an existing build with packages defined in my own layer outside the build directory in the local.conf.sample
I want to add a package so I add it to my local.conf.sample and then source oe-init-build-env again
It doesn't overwrite the local.conf in poky/build/conf as it already exists

Is there a preferred way to make it update?
Or do I just need to manually delete the files in that directory and then run source oe-init-build-env?
I don't want to delete the whole build directory as it takes far too long to do it again from scratch

For reference I am using the local.conf.sample because that is my source controllable config file

Howdy!

Am Sa., 7. Nov. 2020 um 16:04 Uhr schrieb Manuel Wagesreither
<ManWag@fastmail.fm>:

ERROR: Task linux-dummy.do_fetch attempted to execute unexpectedly
Task /data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-manwag/recipes-core/images/bora-container.bb:do_image_qa, unihash d18d2179024bc6595110c2f10112e7a8e2bd6021d3ea754af30ad9b68ebd9844, taskhash d18d2179024bc6595110c2f10112e7a8e2bd6021d3ea754af30ad9b68ebd9844
Task /data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-manwag/recipes-core/images/bora-container.bb:do_image_complete, unihash c2d86d42a7fc84df5f6ad94b3ed65f6991b3e680d99d40e07ee631aedee9970b, taskhash c2d86d42a7fc84df5f6ad94b3ed65f6991b3e680d99d40e07ee631aedee9970b
This is usually due to missing setscene tasks. Those missing in this build were: {'/data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-manwag/recipes-core/images/bora-container.bb:do_image_complete',
'/data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-manwag/recipes-core/images/bora-container.bb:do_image_qa'}
ERROR: Task (/data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-kernel/linux/linux-dummy.bb:do_fetch) failed with exit code 'setscene whitelist'
NOTE: Tasks Summary: Attempted 142 tasks of which 141 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
/data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-kernel/linux/linux-dummy.bb:do_fetch
Summary: There was 1 WARNING message shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
ERROR: Logfile of failure stored in: /data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/temp/log.do_populate_sdk_ext.8096
ERROR: Task (/data/proj/poky/build-bora-docker/../meta-manwag/recipes-core/images/bora-container.bb:do_populate_sdk_ext) failed with exit code '1'
NOTE: Tasks Summary: Attempted 2358 tasks of which 2356 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
/data/proj/poky/build-bora-docker/../meta-manwag/recipes-core/images/bora-container.bb:do_populate_sdk_ext
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
```

I can reproduce it, the issue being caused by the combination of
linux-dummy as kernel provider and the esdk. While there is no obvious
fix at the moment, Bruce (CCed) knows about it and will have a look.
Additionally it might be worth filing a bug.

Greetz

Hi,

This adds systemd and pam related recipes to upstream checks and devtool-driven updates.

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
scripts/auh-config/local.conf.append | 1 +
1 file changed, 1 insertion(+)

diff --git a/scripts/auh-config/local.conf.append b/scripts/auh-config/local.conf.append
index 9628737..b18590f 100644
--- a/scripts/auh-config/local.conf.append
+++ b/scripts/auh-config/local.conf.append
@@ -1,3 +1,4 @@

INHERIT += "buildhistory"
LICENSE_FLAGS_WHITELIST = "commercial"
+DISTRO_FEATURES_append = ' systemd pam'
--
2.29.1

Hi,

--

The Py_UNICODE_COPY, Py_UNICODE_FILL, PyUnicode_WSTR_LENGTH,
PyUnicode_FromUnicode(), PyUnicode_AsUnicode(), _PyUnicode_AsUnicode,
and PyUnicode_AsUnicodeAndSize() are marked as deprecated in Python 3.9.
(See: https://docs.python.org/3/whatsnew/3.9.html). But the current
python3-cython (0.29.21) hasn't adapt it yet.
Append '-Wno-deprecated-declarations' in CFLAGS as a workaround to fix
the build issue.

Fixes:
In file included from
/build/tmp-glibc/work/corei7-64-wrs-linux/setools/4.3.0-r0/recipe-sysroot/usr/include/python3.9/unicodeobject.h:1026,
from /build/tmp-glibc/work/corei7-64-wrs-linux/setools/4.3.0-r0/recipe-sysroot/usr/include/python3.9/Python.h:97,
from setools/policyrep.c:49:
/build/tmp-glibc/work/corei7-64-wrs-linux/setools/4.3.0-r0/recipe-sysroot/usr/include/python3.9/cpython/unicodeobject.h:446:26:
note: declared here
446 | static inline Py_ssize_t _PyUnicode_get_wstr_length(PyObject *op) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
setools/policyrep.c:97302:3: error: 'PyUnicode_AsUnicode' is deprecated [-Werror=deprecated-declarations]

Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
---
recipes-security/setools/setools_4.3.0.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-security/setools/setools_4.3.0.bb b/recipes-security/setools/setools_4.3.0.bb
index 8fdeeb0..0f166c8 100644
--- a/recipes-security/setools/setools_4.3.0.bb
+++ b/recipes-security/setools/setools_4.3.0.bb
@@ -30,6 +30,8 @@ RDEPENDS_${PN} += "python3-networkx python3-decorator python3-setuptools \

RDEPENDS_${PN}_class-native = ""

+CFLAGS_append = " -Wno-deprecated-declarations"
+
RPROVIDES_${PN} += "${PN}-console"

inherit setuptools3
--
2.17.1