swupdate update failure.<error logs> #swupdate


Hi Team,
Recently, I am able to integrate SWUPDATE on my Linux target.
After building successfully, I tried to do a local update using SD_CARD.
Getting below error after doing the update. Please guide me on how to resolve this.
Starting swupdate ...
dd: writing to '/dev/fb0': No space left on device
8001+0 records in
8000+0 records out
4096000 bytes (4.1 MB, 3.9 MiB) copied, 0.0848937 s, 48.2 MB/s
/etc/rc5.d/S99MyBoard: line 5: /HelloWorld: No such file or directory
Swupdate v2018.3.0

Licensed under GPLv2. See source distribution for detailed copyright notices.

[TRACE] : SWUPDATE running :  [start_swupdate_subprocess] : Started webserver with pid 581 and fd 4
[TRACE] : SWUPDATE running :  [start_swupdate_subprocess] : Started suricatta with pid 582 and fd 5
Running on imx6s-comgx-MyBoard Revision 1.0
Registered handlers:
[TRACE] : SWUPDATE running :  [listener_create] : creating socket at /tmp/swupdateprog
[TRACE] : SWUPDATE running :  [network_initializer] : Main loop Daemon
[TRACE] : SWUPDATE running :  [listener_create] : creating socket at /tmp/sockinstctrl
[TRACE] : SWUPDATE running :  [suricatta_configdata_settings] : Identify for configData: board --> imx6s-comgx-MyBoard

Mongoose web server version 6.11 with pid 581 started on port(s) 8080 with web root [/www] and API v2
Cannot parse config file '/etc/fw_env.config': No such file or directory
[ERROR] : SWUPDATE failed [0] ERROR bootloader/uboot.c : bootloader_env_get : 93 : Error: environment not initialized, No such file or directory

[INFO ] : SWUPDATE running :  [read_state] : Key 'ustate' not found in Bootloader's environment.

[TRACE] : SWUPDATE running :  [get_state] : Read state=4 from persistent storage.

[DEBUG] : SWUPDATE running :  [server_handle_initial_state] : State is STATE_OK/STATE_NOT_AVAILABLE, nothing to report to server.

[TRACE] : SWUPDATE running :  [start_suricatta] : Server initialized, entering suricatta main loop.

[DEBUG] : SWUPDATE running :  [server_get_device_info] : Getting information for device 'imx6s-comgx-MyBoard'

[DEBUG] : SWUPDATE running :  [channel_set_options] : cURL's low download speed timeout is disabled, this is most probably not what you want. Adapted it to 300s instead.

[DEBUG] : SWUPDATE running :  [channel_get] : Trying to GET http://varupdate:8080/default/controller/v1/imx6s-comgx-MyBoard
Trying to connect to SWUpdate...
Connected to SWUpdate via /tmp/swupdateprog
* Could not resolve host: varupdate
* Closing connection 0
[ERROR] : SWUPDATE failed [0] ERROR corelib/channel_curl.c : channel_get : 955 : Channel get operation failed (6): 'Couldn't resolve host name'

[TRACE] : SWUPDATE running :  [server_send_target_data] : KEYVALUE= "board": "imx6s-comgx-MyBoard" board imx6s-comgx-MyBoard
[TRACE] : SWUPDATE running :  [server_send_target_data] : CONFIGDATA= "board": "imx6s-comgx-MyBoard"
[TRACE] : SWUPDATE running :  [server_send_target_data] : URL=http://varupdate:8080/default/controller/v1/imx6s-comgx-MyBoard/configData JSON={ "id": "", "time": "20211129T102651", "status": { "result": { "finished": "success" }, "execution": "closed", "details" : [ "" ] }, "data" : {  "board": "imx6s-comgx-MyBoard" } }
[DEBUG] : SWUPDATE running :  [channel_set_options] : cURL's low download speed timeout is disabled, this is most probably not what you want. Adapted it to 300s instead.

* Could not resolve host: varupdate
* Closing connection 1
[ERROR] : SWUPDATE failed [0] ERROR corelib/channel_curl.c : channel_put_method : 659 : Channel put operation failed (6): 'Couldn't resolve host name'

[DEBUG] : SWUPDATE running :  [suricatta_wait] : Sleeping for 3600 seconds.
Thanks in advance .

Yocto Project 3.1.12 (hardknott-23.0.12) is Released

Lee Chee Yang



We are pleased to announce the Yocto Project 3.1.12 (dunfell-23.0.12) Release is now available for download.


A gpg signed version of these release notes is available at:


Full Test Report:


Thank you for everyone's contributions to this release.


Chee Yang Lee chee.yang.lee@...

Yocto Project Build and Release


- --------------------------

yocto-3.1.12 Release Notes

- --------------------------



- --------------------------


- --------------------------


Repository Name: poky

Repository Location:

Branch: dunfell

Tag: yocto-3.1.12

Git Revision: 0839888394a6e42e96f9f0d201376eb38bc79b24

Release Artefact: poky-dunfell-23.0.12

sha: 6d8c70cb17100d6dd5056b8dcae7027833c8f9a53006fd5b651bf9a56494eb01

Download Locations:


Repository Name: openembedded-core

Repository Location:

Branch: dunfell

Tag: yocto-3.1.12

Git Revision: 44b1970c40e9d73f6e63fb10cdc55837a26f5921

Release Artefact: oecore-dunfell-23.0.12

sha: 2ddef2bbcd156c971b6ce8a05eee64ddc51237d9ad2e17186d8afb840c31e7f9

Download Locations:


Repository Name: meta-mingw

Repository Location:

Branch: dunfell

Tag: yocto-3.1.12

Git Revision: 524de686205b5d6736661d4532f5f98fee8589b7

Release Artefact: meta-mingw-dunfell-23.0.12

sha: 7a3e2f9922d9677c2357221d00f0e92a54feb7170f5df079527be9654d61b869

Download Locations:


Repository Name: meta-gplv2

Repository Location:

Branch: dunfell

Tag: yocto-3.1.12

Git Revision: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac

Release Artefact: meta-gplv2-dunfell-23.0.12

sha: b6e4f8d9270849154f37db1c5b64febc5339f421caae877efbe6c32873307aa3

Download Locations:


Repository Name: bitbake

Repository Location:

Branch: dunfell

Tag: yocto-3.1.12

Git Revision: c0348de8121c3a842bf44906f7e2f79e93f7275b

Release Artefact: bitbake-dunfell-23.0.12

sha: d87dd125bb9715ccc259d1ecbc8278a1ed48c3f834eee9bcdb569e7c296e9d2d

Download Locations:


Repository Name: yocto-docs

Repository Location:

Branch: dunfell

Tag: yocto-3.1.12

Git Revision: f1cd4d8ae58037609556de51b33a4dbeab7f45ff


- ----------------


- ----------------


Alexander Kanavin

Alexandre Belloni

Andrej Valek

Armin Kuster

Bruce Ashfield

Chandana kalluri

Chris Laplante

Christian Eggers

Claudius Heine

Daniel McGregor

Hongxu Jia

Jon Mason

Jose Quaresma

Joshua Watt

Justin Bronder

Kai Kang

Khem Raj

Marco Felsch

Marek Vasut

Mark Hatle

Markus Volk

Michael Halstead

Mike Crowe

Mingli Yu

Minjae Kim

Oleksandr Kravchuk

Pavel Zhukov

Ralph Siemsen

Ranjitsinh Rathod

Richard Purdie

Robert P. J. Day

Ross Burton

Sakib Sajal


Stefano Babic

Steve Sakoman

Teoh Jay Shen

Tom Pollard

Visa Hankala

Wang Mingyu

William A. Kennington III

sana kazi


- ---------------

Known Issues

- ---------------

Bug 14622 - bsps-hw.bsps-hw.Test_Seek_bar_and_volume_control manual test case failure


- ---------------

Security Fixes

- ---------------

curl: Whitelist CVE-2021-22897

ffmpeg: Add fix for CVEs

openssh: Fix CVE-2021-28041

vim: fix CVE-2021-3778

vim: Backport fix for CVE-2021-3770

tar: ignore node-tar CVEs

squashfs-tools: fix CVE-2021-40153

nettle: Security fix for CVE-2021-20305

curl: Fix CVE-2021-22946 and CVE-2021-22947, whitelist CVE-2021-22945

nettle: Security fix for CVE-2021-3580

qemu: fix CVE-2021-3682

qemu: Security fix for CVE-2020-28916

qemu: Security fix for CVE-2020-27617

qemu: Security fix CVE-2020-12829

libsndfile: Security fix for CVE-2021-3246

apr: Security fix for CVE-2021-35940

libgcrypt: Security fix CVE-2021-33560



- ---------------


- ---------------

connman: add CVE_PRODUCT

tar: filter CVEs using vendor name

build-appliance-image: Update to dunfell head revision

mirrors: Add sources mirror for

selftest/reproducible: add webkitgtk back to exclusion list for dunfell

reproducible_build: Remove BUILD_REPRODUCIBLE_BINARIES checking

sstate: Avoid deploy_source_date_epoch sstate when unneeded

sstate: Ensure SDE is accounted for in package task timestamps

sstate: another fix for touching files inside pseudo

mirrors: Add uninative mirror on

piglit: upgrade to latest revision

pseudo: Add fcntl64 wrapper

pseudo: Add in ability to flush database with shutdown request

linunistring: Add missing gperf-native dependency

python3-magic: add missing DEPENDS

python3-magic: add the missing rdepends

webkitgtk: Fix reproducibility in minibrowser

oeqa: reproducible: Fix test not producing diffs

documentation: prepare for 3.1.12 release

ref-system-requirements.rst: Add Fedora 34 to list of supported distros

ref-system-requirements.rst: Add Debian 11 to list of supported distros

poky.conf: Bump version for 3.1.12 release

bitbake: fetch/wget: Add timeout for checkstatus calls (30s)

meta/scripts: Manual git url branch additions

meta: Add explict branch to git SRC_URIs, handle github url changes

scripts/convert-srcuri: Backport SRC_URI conversion script from master branch

bitbake: tests/fetch: Update address after github changes

bitbake: tests/fetch: Update github urls

bitbake: tests/fetch2: Fix quoting warning

bitbake: fetch/git: Handle github dropping git:// support

tzdata: update to 2021e

ca-certificates: update 20210119 -> 20211016

wireless-regdb: upgrade to 2021.08.28

linux-firmware: upgrade to 20210919

git: Fix determinism issue

stress-ng: improve reproducibility

stress-ng: convert to git, website is down

waffle: old website is down, update to new project URLs

mirrors.bbclass: remove dead infozip mirrors

oeqa/runtime/parselogs: modified drm error in common errors list

oeqa/runtime: search sys.path explicitly for modules

oeqa/runtime: load modules using importlib

testimage: fix unclosed testdata file

reproducible_build: Drop obsolete sstate workaround

oe/utils: log exceptions in ThreadedWorker functions

license.bbclass: implement ast.NodeVisitor.visit_Constant

oe/license: implement ast.NodeVisitor.visit_Constant

bitbake.conf: Add gpg-agent as a host tool

base: Use repr() for printing exceptions

base: Clean up unneeded len() calls

sstate: don't silently handle all exceptions in sstate_checkhashes

devtool: fix modify with patches in override directories

sstate: fix touching files inside pseudo

vim: fix 2021-3796

poky.yaml: fedora33: add missing pkgs

selftest/reproducible: adjust exclusion list for dunfell

classes/reproducible_build: Use atomic rename for SDE file

reproducible_build: Work around caching issues

rpm: Deterministically set vendor macro entry

poky.conf: Add debian 11 as a supported distro

poky.conf: Add fedora 34 as a supported distro

uninative: Upgrade to 3.4

target/ add HostKeyAlgorithms option to test commands

python3: Add a fix for a make install race

libnewt: Use python3targetconfig to fix reproducibility issue

libxml2: Use python3targetconfig to fix reproducibility issue

externalsrc: Fix a source date epoch race in reproducible builds

externalsrc: Work with reproducible_build

gobject-introspection: Don't write $HOME into scripts

libtool: Allow libtool-cross to reproduce

libtool: Fix lto option passing for reproducible builds

util-linux: Fix reproducibility

gnupg: Be deterministic about sendmail

mesa: Ensure megadrivers runtime mappings are deterministic

package: Ensure pclist files are deterministic and don't use full paths

uninative: Upgrade to 3.3, support glibc 2.34

uninative: Improve glob to handle glibc 2.34

nativesdk-pseudo: Fix to work with glibc 2.34 systems

pseudo: Update with fcntl and glibc 2.34 fixes

pseudo: Fix to work with glibc 2.34 systems

util-linux: disable raw

gpgme: Use glibc provided closefrom API when available

m4: Do not use SIGSTKSZ

gcc: fix missing dependencies for selftests

libpsl: Add config knobs for runtime/builtin conversion choices

patch.bbclass: when the patch fails show more info on the fatal error

oeqa/selftest/sstatetests: fix typo ware -> were

rng-tools: add systemd-udev-settle wants to service Add check before deleting path

binutils: Fix a missing break in case statement

oeqa/manual: Fix no longer valid URLs

multilib: Avoid sysroot race issues when multilib enabled

weston: Use systemd notify,

e2fsprogs: upgrade to 1.45.7

linux-yocto/5.4: update to v5.4.153

bitbake: fetch2/git: Use os.rename instead of mv

bitbake: fetch2/git: Avoid races over mirror tarball creation

bitbake: hashserv: let asyncio discover the running loop

bitbake: bitbake: correct deprecation warning in

bitbake: bitbake: adjust parser error check for python 3.10 compatibility

bitbake: bitbake: do not import imp in layerindexlib

bitbake: bitbake: fix regexp deprecation warnings

bitbake: bitbake: correct the collections vs deprecation

bitbake: remove file since it no longer actually implements anything

bitbake: test/fetch: Update urls to match upstream branch name changes

glew: Stop polluting /tmp during builds

oeqa/buildproject: Ensure temp directories are cleaned up

oeqa/selftest/gotoolchain: Fix temp file cleanup

rm_work.bbclass: Fix for files starting with -

libc_package/buildstats: Fix python regex quoting warnings

oeqa/qemurunner: Use oe._exit(), not sys.exit()

pybootchart: Avoid divide by zero

libsamplerate0: Set correct soname for 0.1.9

bzip2: Update soname for libbz2 1.0.8

common-licenses: add "Unlicense" license file

systemd: Add fix for systemd-networkd crash during free

mtd-utils: upgrade to 2.1.3

bitbake: build/msg: Cleanup verbose option handling

bitbake: cookerdata: Show a readable error for invalid multiconfig name

bitbake: bitbake-worker: Improve error handling

bitbake: cookerdata: Show error for no BBLAYERS in bblayers.conf

bitbake: cookerdata: Improve missing core layer error message

bitbake: data_smart: Improve error display for handled exceptions

bitbake: build: Catch and error upon circular task references

bitbake: build: Avoid duplicating logs in verbose mode

bitbake: process: Don't include logs in error message if piping them

bitbake: build: Handle SystemExit in python tasks correctly

bitbake: build: Match markup to real function name

bitbake: bitbake: bitbake-layers: add skip reason to output

bitbake: ui/taskexp: Fix to work with empty build directories

bitbake: ui/taskexp: Improve startup exception handling

bitbake: server: Fix early parsing errors preventing zombie bitbake

libsoup-2.4: remove obsolete intltool dependency

testimage: symlink the task log and qemu console log to tmp/log/oeqa

wic: keep rootfs_size as integer

core-image-sato: Fix runqemu error for qemuarmv5

Update mailing list address

bash: Ensure deterministic build

useradd: Ensure preinst data is expanded correctly in pkgdata

rpm: Handle proper return value to avoid major issues

iputils: Fix regression of arp table update

bitbake: tests/fetch2: Use our own git server for dtc test repo

[meta-rockchip][PATCH] README: Add intstructions to add patch template

Khem Raj

Signed-off-by: Khem Raj <raj.khem@...>
README | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/README b/README
index cec1b53..cc63d0a 100644
--- a/README
+++ b/README
@@ -45,10 +45,20 @@ Maintenance:

- For example, to send your most recent commit (i.e. just one patch),
+ Please send changes to the yocto mailing list with [meta-rockchip] in the subject line,
+ cc'ing the maintainer.
+ This can be configured within the repository with following commands:
+ git config yocto@...
+ git config twoerner@...
+ git config format.subjectprefix "meta-rockchip] [PATCH"
+ Then, to send your most recent commit (i.e. just one patch),
please use something like:
- git format-patch -M --subject-prefix="meta-rockchip][PATCH" HEAD^
- git send-email --to yocto@... --cc twoerner@... <your patch file>
+ git format-patch -M -1
+ git send-email <your patch file>


Bad ownership of directory in WIC generated partition



I'm using dunfell branch 3.1.11. My wks file is generating a 4th partition which is being mounted to /data via the --rootfs-dir argument. All directories within the mounted /data are owned 1000:1000 which I believe is a contamination via my host user running the build.

I've looked around online and haven't been able to ascertain the cause, although there are a few others which seem to be the same problem:

I've seen some patches addressing similar behavior in the wks files:
[v7,02/10] wic: Fix multi images .wks with bitbake
[v2,1/2] wic: Fix permissions when using exclude or include path

I've also found this post from a user that says "Just saw that the issue is that you can't use rootfs-dir with a subfolder". I am at a complete loss for where they have seen that information... perhaps I can't see the forest for the trees.

So I'm wondering if this is a bug, or if I have done something drastically incorrect? I have thrown a fair chunk of time at the issue, and in the end all I could do is write a script that runs on first boot to chown the directories and set permissions as we need. Could someone weigh in please? I'd love to assist in writing a patch but looking at some of the code, I literally have no idea where to start...

My wks file:

part /boot --source bootimg-partition --fstype=vfat --label boot --active --align 1024  --use-uuid
part / --source rootfs --fstype=ext4 --label A --align 1024 --use-uuid
part --source rootfs --fstype=ext4 --label B --align 1024 --use-uuid
part /data --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/data --fstype=ext4 --label data --align 1024  --use-uuid --size 10

Image recipe excerpt, I realize this shouldn't go in a ROOTFS_POSTPROCESS_COMMAND necessarily, this is just an artifact of my testing:


chmod_dirs() {
    mkdir -p ${IMAGE_ROOTFS}/data/firmware
    chown 0:421 ${IMAGE_ROOTFS}/data/firmware
    chmod 0770  ${IMAGE_ROOTFS}/data/firmware
    lnr ${IMAGE_ROOTFS}/data/firmware ${IMAGE_ROOTFS}/opt/Firmware

Resulting folder in image:
root@sgc30cube:~# ls -la /data
drwxr-xr-x    4 root     root          1024 Nov 30 09:00 .
drwxr-xr-x   21 root     root          1024 Nov 30 09:00 ..
drwxr-x---    2 1000     1000          1024 Mar  9  2018 firmware
drwx------    2 root     root         12288 Nov 30 09:00 lost+found

Is there a more elegant way to work around this issue, rather than scripted chmod/chown on the target?

Please let me know if I could provide more useful information.


Thank you,

Yocto Project Status WW48`21

Stephen Jolley

Current Dev Position: YP 3.5 M1

Next Deadline: 6th Dec. 2021 YP 3.5 M1 build


Next Team Meetings:


Key Status/Updates:

  • YP 3.1.12 is due for release this week
  • YP 3.4.1 is going into QA.
  • Next week is the first milestone build for 3.5.
  • There are some major changes with python modules to be able to support 5.16 and later kernels due to new dependencies
  • We continue to see a reduction in the number of patches in “Pending” state. Many thanks to everyone who has taken the time to review patch status and handle accordingly, particularly where they were accepted upstream. This will significantly benefit the project in the long term.
  • Intermittent issues continue to rise and help is very much welcome on these issues. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla:


Ways to contribute:


YP 3.5 Milestone Dates:

  • YP 3.5 M1 build date 2021/12/06
  • YP 3.5 M1 Release date 2021/12/17
  • YP 3.5 M2 build date 2022/01/10
  • YP 3.5 M2 Release date 2022/1/21
  • YP 3.5 M3 build date 2022/2/21
  • YP 3.5 M3 Release date 2022/03/04
  • YP 3.5 M4 build date 2022/04/04
  • YP 3.5 M4 Release date 2022/04/29


Upcoming dot releases:

  • YP 3.1.12 should be released soon.
  • YP 3.4.1 is in QA.
  • YP 3.4.1 Release date 2021/12/03
  • YP 3.1.13 build date 2021/12/13
  • YP 3.1.13 Release date 2021/12/22
  • YP 3.1.14 build date 2022/01/24
  • YP 3.1.14 Release date 2022/02/04
  • YP 3.4.2 build date 2022/02/07
  • YP 3.4.2 Release date 2022/02/18
  • YP 3.1.15 build date 2022/03/14
  • YP 3.1.15 Release date 2022/03/25
  • YP 3.4.3 build date 2022/03/21
  • YP 3.4.3 Release date 2022/04/01
  • YP 3.1.16 build date 2022/04/25
  • YP 3.1.16 Release date 2022/05/06


Tracking Metrics:


The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:


The Status reports are now stored on the wiki at:


[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]




Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:    


QA notification for completed autobuilder build (yocto-3.4.1.rc1)

Richard Purdie

A build flagged for QA (yocto-3.4.1.rc1) was completed on the autobuilder and is
available at:

Build hash information:

bitbake: 44a83b373e1fc34c93cd4a6c6cf8b73b230c1520
meta-agl: 83c5764a38902c6d17f106ea545533192ebd46fe
meta-arm: 55ae0eb1a6c210e6e87f5a553a1ebbb7dcc7a725
meta-aws: c92344938ab4d37de8bd8b799186dbbe3019a069
meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400
meta-intel: d0f1c1ebfd9b7fe8d22c6a62208f78bccc6f3bf6
meta-mingw: f5d761cbd5c957e4405c5d40b0c236d263c916a8
meta-openembedded: f31b9854b13e46cb74569538a33c36730c00c695
oecore: 70384dd958c57d1da924a66cffa35f80eb60d4b0
poky: b53230c08d9f02ecaf35b4f0b70512abbf10ae11

This is an automated message from the Yocto Project Autobuilder
Git: git://
Email: richard.purdie@...

Re: [meta-security][PATCH] python3-fail2ban: update to tip

Armin Kuster

On 11/29/21 8:03 AM, Konrad Weihmann wrote:

On 29.11.21 16:14, Armin Kuster wrote:
Signed-off-by: Armin Kuster <akuster808@...>
  recipes-security/fail2ban/ | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-security/fail2ban/
index 4e344c8..f6394cc 100644
--- a/recipes-security/fail2ban/
+++ b/recipes-security/fail2ban/
@@ -9,7 +9,7 @@ HOMEPAGE = ""
  LICENSE = "GPL-2.0"
  -SRCREV ="d6b884f3b72b8a42b21da863836569ef6836c2ea"
+SRCREV ="4fe4ac8dde6ba14841da598ec37f8c6911fe0f64"
according to github 80805cabfcf57dd0454d47d7f86d43c6738ce629 is the tip.
any specific reason to pick the commit before that?
It aligns with the tip of branch 0.11.


  SRC_URI = "
git://;branch=0.11;protocol=https \
          file://initd \
          file://run-ptest \

M+ & H bugs with Milestone Movements WW48

Stephen Jolley


YP M+ or high bugs which moved to a new milestone in WW48 are listed below:


Bug ID

Short Description







bitbake-layers crashes with incorrect layer configuration data is given (expected proper error printing and exit with error)



3.5 M1




Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:    


Enhancements/Bugs closed WW48!

Stephen Jolley


The below were the owners of enhancements or bugs closed during the last week!













Grand Total




Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:    


Current high bug count owners for Yocto Project 3.5

Stephen Jolley


Below is the list as of top 46 bug owners as of the end of WW48 of who have open medium or higher bugs and enhancements against YP 3.5.   There are 104 possible work days left until the final release candidates for YP 3.5 needs to be released.































































































Grand Total




Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:    


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley



The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:  Also please review: and how to create a bugzilla account at:

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.


Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 391 unassigned or newcomer bugs.


We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.4”, “3.5, "3.99" and "Future", the more pressing/urgent issues being in "3.4" and then “3.5”.


Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me ( an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at:




Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:    


Re: Problem installing python package from a wheel #bitbake #python

David Babich

On Thu, Nov 25, 2021 at 02:45 AM, Nicolas Jeker wrote:
On Wed, 2021-11-24 at 09:55 -0800, Tim Orling wrote:
On Mon, Nov 22, 2021 at 2:54 PM David Babich <ddbabich@...>
I made it a little further by adding --no-cache-dir to the pip3
install command.  That got rid fo the warning about not being able
to access the .cache/pip.  However I still have the error:
| ERROR: torch-1.10.0-cp36-cp36m-linux_aarch64.whl is not a
supported wheel on this platform.
Installing third-party wheels is not something we are likely to ever
support in Yocto Project/OpenEmbedded recipes.

Are you trying to install using pip3 on target?
Note that many factors will make it tricky for python wheels with
binary content (C or Rust extensions). The python3 version must
match, as will the libraries it requires. 

The wheel you listed was built for Python 3.6 (cp36) and ARM v8
(aarch64).  The error is what you would see if you were trying to
install an aarch64 wheel on an x86-64 target, but other reasons could
lead to that error. We don't know what version of glibc, gcc, etc.
was used and whether those are going to be compatible.
Ah OK, I wasn't aware of the the python naming convention.  That is likely my problem since I'm using Honister which uses Python 3.9.  I pulled the wheel from NVIDIA's forums for pytorch, unfortunately they've not released one for Python 3.9 so I will likely have to create it myself using the build from scratch method described in the article I linked.  Unfortunately this will likely open a new can of worms...
There's a section about building from source with a patch in the
article he linked with his first message. I don't know much about
python in yocto, but maybe doing that in a recipe could work?

Also, when asking questions, please tell us which release of Yocto
Project you are using, what the MACHINE you are building for is,
which layers you are using (and at what release) and other
information to help us help you.

I'm using Honister and the machine is 'jetson-tx2-dev-kit-tx2i', I'm making a custom distro based on the meta-tegra-demo from this:

A large part of the problem that I have is that many of these custom packages don't provide a nice .tar.gz pypi source distribution that I could use with the pypi class.  My target install ends up on a spacecraft, so there is a strong desire to have a fully managed build that can just be flashed onto the target tx2i without the need to do any post installation or configuration.  Sadly I'm finding that a lot of these third party dependencies do not lend themselves well to the yocto paradigm.  I'm thinking that I may have to setup the target board, install the third party packages on the target using whatever is required to do that, then copy the build products back to the host and use a bitbake recipe to just do_install:append the built products into the rootfs during the yocto build.  Does that sound feasible?  I've not had to do this before, but it seems like it might be a reasonable approach given the complexity of the situation.



Re: [meta-security][PATCH] python3-fail2ban: update to tip

Konrad Weihmann <kweihmann@...>

On 29.11.21 16:14, Armin Kuster wrote:
Signed-off-by: Armin Kuster <akuster808@...>
recipes-security/fail2ban/ | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-security/fail2ban/ b/recipes-security/fail2ban/
index 4e344c8..f6394cc 100644
--- a/recipes-security/fail2ban/
+++ b/recipes-security/fail2ban/
@@ -9,7 +9,7 @@ HOMEPAGE = ""
LIC_FILES_CHKSUM = "file://COPYING;md5=ecabc31e90311da843753ba772885d9f"
-SRCREV ="d6b884f3b72b8a42b21da863836569ef6836c2ea"
+SRCREV ="4fe4ac8dde6ba14841da598ec37f8c6911fe0f64"
according to github 80805cabfcf57dd0454d47d7f86d43c6738ce629 is the tip.
any specific reason to pick the commit before that?

SRC_URI = " git://;branch=0.11;protocol=https \
file://initd \
file://run-ptest \

Re: [meta-rockchip] dunfell: u-boot build issue when added patch to u-boot

Tom Rini

On Sat, Nov 27, 2021 at 09:24:56PM +0100, Marek Belisko wrote:

On Fri, Nov 26, 2021 at 11:55 PM Trevor Woerner <twoerner@...> wrote:

On Thu 2021-11-11 @ 08:44:48 AM, Marek Belisko wrote:

I'm trying to integrate mender for tinker-board-s using meta-rockchip
dunfell branch. When added meta-mender which add few patches to
u-boot I'm seeing u-boot compilation issues like:

Error: SPL image is too large (size 0x11000 than 0x8000)
| Error: Bad parameters for image type

Error is clear to me but patches which mender adds are related mostly
to the environment so I'm not sure how SPL can increase size. Any
ideas on how to resolve this issue?
Does the following help?
I'm adding dunfell support for mender :). In this link mender rockchip
integration is for older u-boot not 2020.01
Did some sort of "enable environment support in SPL" option get enabled
in your patches perhaps?


[meta-security][PATCH] python3-fail2ban: update to tip

Armin Kuster

Signed-off-by: Armin Kuster <akuster808@...>
recipes-security/fail2ban/ | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-security/fail2ban/ b/recipes-security/fail2ban/
index 4e344c8..f6394cc 100644
--- a/recipes-security/fail2ban/
+++ b/recipes-security/fail2ban/
@@ -9,7 +9,7 @@ HOMEPAGE = ""
LIC_FILES_CHKSUM = "file://COPYING;md5=ecabc31e90311da843753ba772885d9f"

-SRCREV ="d6b884f3b72b8a42b21da863836569ef6836c2ea"
+SRCREV ="4fe4ac8dde6ba14841da598ec37f8c6911fe0f64"
SRC_URI = " git://;branch=0.11;protocol=https \
file://initd \
file://run-ptest \

define extended partition in wks file

Silvan Murer

I'm using wic for creating a boot image in my yocto layer. An extended
partition is automatically created, when build an image with more than
four partitions.
The extended partition is added at the end and in my case, the last
two logic partitions are included there.

Does an option exist which allows the definition of the partitions
which are included in the extended partition? In may case, I'm looking
for an option to put the two rootfs partitions (rootfs1 and rootfs2)
into a common extended partition. And the data partition at the end
should be in its own logic partition. Does some option exist or is it
possible to handle them in another way? probably by creating an own
wic plugin?

The *.wks file contains the following entries:

part --source rawcopy --sourceparams="file=u-boot-splx4.sfp" --ondisk
mmcblk0 --system-id=a2 --align 1024 --fixed-size 10M
part /run/mount/bootloader --source bootimg-partition --ondisk mmcblk0
--fstype=vfat --label boot --active --align 1024 --size 500M
part / --source rootfs --ondisk mmcblk0 --fstype=ext4 --label rootfs1
--align 1024 --fixed-size 2G
part --source rootfs --ondisk mmcblk0 --fstype=ext4 --label rootfs2
--align 1024 --fixed-size 2G
part /run/mount/data --ondisk mmcblk0 --fstype=ext4 --label data
--align 1024 --fixed-size 3G


Re: [meta-security][PATCH 2/2] meta-parsec/ fix for append operator combined with +=

Armin Kuster



On 11/19/21 7:18 AM, Yi Zhao wrote:
Signed-off-by: Yi Zhao <yi.zhao@...>
meta-parsec/ | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta-parsec/ b/meta-parsec/
index c5635d3..bb4c2b9 100644
--- a/meta-parsec/
+++ b/meta-parsec/
@@ -80,7 +80,7 @@ Manual testing with runqemu
This layer also contains a recipe for pasec-tool which can be used for
manual testing of the Parsec service:

- IMAGE_INSTALL:append += " parsec-tools"
+ IMAGE_INSTALL:append = " parsec-tools"

There are a series of Parsec Demo videos showing how to use parsec-tool
to test the Parsec service base functionality:
@@ -104,7 +104,7 @@ enabled. No changes required.
The Software HSM can be used for manual testing of the provider by
including it into your test image:

- IMAGE_INSTALL:append += " softhsm"
+ IMAGE_INSTALL:append = " softhsm"

Inside the running VM:
- Stop Parsec
@@ -135,7 +135,7 @@ systemctl start parsec
The IBM Software TPM service can be used for manual testing of the provider by
including it into your test image:

- IMAGE_INSTALL:append += " ibmswtpm2 tpm2-tools libtss2 libtss2-tcti-mssim"
+ IMAGE_INSTALL:append = " ibmswtpm2 tpm2-tools libtss2 libtss2-tcti-mssim"

Inside the running VM:
- Stop Parsec

Re: [meta-security][PATCH 1/2] openssl-tpm-engine: fix warning for append operator combined with +=

Armin Kuster



On 11/19/21 7:18 AM, Yi Zhao wrote:
WARNING: CFLAGS:append += is not a
recommended operator combination, please replace it.

Signed-off-by: Yi Zhao <yi.zhao@...>
.../openssl-tpm-engine/ | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-tpm/recipes-tpm/openssl-tpm-engine/ b/meta-tpm/recipes-tpm/openssl-tpm-engine/
index ef663eb..2b969ed 100644
--- a/meta-tpm/recipes-tpm/openssl-tpm-engine/
+++ b/meta-tpm/recipes-tpm/openssl-tpm-engine/
@@ -35,10 +35,10 @@ inherit autotools-brokensep pkgconfig
srk_dec_pw ?= "\\"\\\x1\\"\\"nc\\"\\"\\\x3\\"\\"nd\\"\\"\\\x1\\"\\"a\\""
srk_dec_salt ?= "\\"r\\"\\"\\\x00\\\x00\\"\\"t\\""

-CFLAGS:append += "-DSRK_DEC_PW=${srk_dec_pw} -DSRK_DEC_SALT=${srk_dec_salt}"
+CFLAGS:append = " -DSRK_DEC_PW=${srk_dec_pw} -DSRK_DEC_SALT=${srk_dec_salt}"

# Uncomment below line if using the plain srk password for development

do_configure:prepend() {
cd ${B}

Re: [meta-security][PATCH] apparmor: fix warning of remove operator combined with +=

Armin Kuster

On 11/18/21 11:06 PM, kai wrote:
From: Kai Kang <kai.kang@...>

Fix warning for apparmor:

| WARNING: /path/to/meta-security/recipes-mac/AppArmor/
| RDEPENDS:${PN}:remove += is not a recommended operator combination,
| please replace it.

Signed-off-by: Kai Kang <kai.kang@...>
recipes-mac/AppArmor/ | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-mac/AppArmor/ b/recipes-mac/AppArmor/
index 389e72a..818be15 100644
--- a/recipes-mac/AppArmor/
+++ b/recipes-mac/AppArmor/
@@ -168,7 +168,7 @@ RDEPENDS:${PN}:libc-glibc += "glibc-utils"

# Add coreutils and findutils only if sysvinit scripts are in use
RDEPENDS:${PN} += "${@["coreutils findutils", ""][(d.getVar('VIRTUAL-RUNTIME_init_manager') == 'systemd')]} ${@bb.utils.contains('PACKAGECONFIG','python','python3-core python3-modules','', d)}"
-RDEPENDS:${PN}:remove += "${@bb.utils.contains('PACKAGECONFIG','perl','','perl', d)}"
+RDEPENDS:${PN}:remove = "${@bb.utils.contains('PACKAGECONFIG','perl','','perl', d)}"
RDEPENDS:${PN}-ptest += "perl coreutils dbus-lib bash"

INSANE_SKIP:${PN} = "ldflags"

[meta-security][PATCH] libest: does not build with openssl 3.x

Armin Kuster

blacklist for now. Remove from pkg grp

Signed-off-by: Armin Kuster <akuster808@...>
recipes-core/packagegroup/ | 1 -
recipes-security/libest/ | 3 +++
2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/recipes-core/packagegroup/ b/recipes-core/packagegroup/
index e9dad5b..fefc66d 100644
--- a/recipes-core/packagegroup/
+++ b/recipes-core/packagegroup/
@@ -38,7 +38,6 @@ RDEPENDS:packagegroup-security-utils = "\
python3-privacyidea \
python3-fail2ban \
softhsm \
- libest \
sshguard \
${@bb.utils.contains_any("TUNE_FEATURES", "riscv32 ", "", " libseccomp",d)} \
${@bb.utils.contains("DISTRO_FEATURES", "pam", "sssd google-authenticator-libpam", "",d)} \
diff --git a/recipes-security/libest/ b/recipes-security/libest/
index 31fbe3c..41a4025 100644
--- a/recipes-security/libest/
+++ b/recipes-security/libest/
@@ -25,3 +25,6 @@ S = "${WORKDIR}/git"
PACKAGES = "${PN} ${PN}-dbg ${PN}-dev"

FILES:${PN} = "${bindir}/* ${libdir}/"
+PNBLACKLIST[libest] ?= "Needs porting to openssl 3.x"

2361 - 2380 of 57772