Date   

[ANNOUNCEMENT] Yocto Project 3.2.2 (gatesgarth-24.0.2) is Released

Vineela
 

Hello,

 

We are pleased to announce the Yocto Project 3.2.2 (gatesgarth-24.0.2) Release is now available for download.

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.2/poky-gatesgarth-24.0.2.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.2.2/poky-gatesgarth-24.0.2.tar.bz2

 

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

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.2/RELEASENOTES

 

Full Test Report:

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.2/testreport.txt

 

Thank you for everyone's contributions to this release.

 

Vineela Tummalapalli

Yocto Project Build and Release

vineela.tummalapalli@...

 

 

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

yocto-3.2.2 Release Notes

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

 

 

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

Repositories/Downloads

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

 

Repository Name: poky

Repository Location: https://git.yoctoproject.org/git/poky

Branch: gatesgarth

Tag: yocto-3.2.2

Git Revision: d5d6286a66f46f4523e35e0e3f20cd7396195fdc

Release Artefact: poky-gatesgarth-24.0.2

sha: b892e2a70f307c1bb2fdbeef401bfac80ab2d88cb2f564db93c22a62889515be

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.2/poky-gatesgarth-24.0.2.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.2.2/poky-gatesgarth-24.0.2.tar.bz2

 

Repository Name: openembedded-core

Repository Location: https://git.openembedded.org/openembedded-core

Branch: gatesgarth

Tag: 2020-10.2-gatesgarth

Git Revision: ebaaee50cb3ac75112827f935c48affaf622ce7f

Release Artefact: oecore-gatesgarth-24.0.2

sha: 1a269ac8883745fcd9809eb03ab9ab72cf29096ec956e8493598f212adb0a1a3

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.2/oecore-gatesgarth-24.0.2.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.2.2/oecore-gatesgarth-24.0.2.tar.bz2

 

Repository Name: meta-mingw

Repository Location: https://git.yoctoproject.org/git/meta-mingw

Branch: gatesgarth

Tag: yocto-3.2.2

Git Revision: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879

Release Artefact: meta-mingw-gatesgarth-24.0.2

sha: c1ede73885c46820a309cbde0ad6314b83ae3167859acb9cf10152691da3f2a3

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.2/meta-mingw-gatesgarth-24.0.2.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.2.2/meta-mingw-gatesgarth-24.0.2.tar.bz2

 

Repository Name: meta-gplv2

Repository Location: https://git.yoctoproject.org/git/meta-gplv2

Branch: gatesgarth

Tag: yocto-3.2.2

Git Revision: 6e8e969590a22a729db1ff342de57f2fd5d02d43

Release Artefact: meta-gplv2-gatesgarth-24.0.2

sha: 27d72c88ba45d8f2e3f397194a4e3cb1ff6d76cca9ada8bc0b14c1fadb1845cd

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.2/meta-gplv2-gatesgarth-24.0.2.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.2.2/meta-gplv2-gatesgarth-24.0.2.tar.bz2

 

Repository Name: bitbake

Repository Location: https://git.openembedded.org/bitbake

Branch: gatesgarth

Tag: 2020-10.2-gatesgarth

Git Revision: 0a3bf681530bd63fc0036ca81ef868ab53fde56c

Release Artefact: bitbake-gatesgarth-24.0.2

sha: fb4dc9d2f85b7303383dff532360da4ae87a72ad778a252fe0738f2eae09741e

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.2/bitbake-gatesgarth-24.0.2.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.2.2/bitbake-gatesgarth-24.0.2.tar.bz2

 

Repository Name: yocto-docs

Repository Location: https://git.yoctoproject.org/git/yocto-docs

Branch: gatesgarth

Tag: yocto-3.2.2

Git Revision:6bc7e80e4ce0004e8e42ac8dddbff75c521bc19f

 

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

Contributors

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

Adrian Herrera

Alexander Kanavin

Andrey Mozzhuhin

Anuj Mittal

Awais Belal

Bruce Ashfield

Chandana kalluri

Changqing Li

Chen Qi

Chris Laplante

Dmitry Baryshkov

Dorinda

Gratian Crisan

Kai Kang

Kamel Bouhara

Khairul Rohaizzat Jamaluddin

Khem Raj

Lee Chee Yang

Li Wang

Mans Rullgard

Marek Vasut

Mark Jonas

Martin Jansa

Matt Hoosier

Michael Halstead

Mike Looijmans

Mikko Rapeli

Nathan Rossi

Oleksiy Obitotskyy

Oleksiy Obitotskyy yIEf0zt.mo

Ovidiu Panait

Paul Barker

Peter Bergin

Peter Kjellerstedt

Richard Purdie

Robert Joslyn

Robert Yang

Ross Burton

saloni

sangeeta jain

Scott Murray

Steve Sakoman

Tomasz Dziendzielski

Vyacheslav Yurkov

Wang Mingyu

Yi Fan Yu

zangrc

zhengruoqin

Zhixiong Chi

 

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

Known Issues

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

N/A

 

 

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

Security Fixes

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

libcroco: Added CVE

libgcrypt: Whitelisted CVEs

sudo: fix CVE-2021-3156

sudo: fix CVE-2021-23240

openssl: set CVE_VERSION_SUFFIX

cve_check: add CVE_VERSION_SUFFIX to indicate suffix in versioning

gdk-pixbuf: fix CVE-2020-29385

sudo: fix CVE-2021-23239

python3: fix CVE-2021-3177

binutils: Fix CVE-2020-35448

zip: whitelist CVE-2018-13410 and CVE-2018-13684

ffmpeg: Fix CVE-2020-35964, CVE-2020-35965

glibc: CVE-2019-25013

curl: Fix CVE-2020-8284, CVE-2020-8285, CVE-2020-8286

qemu: CVE-2020-28916

qemu: CVE-2020-25723

patch: fix CVE-2019-20633

grub: fix "CVE:" line in one of the patches

libexif: fix CVE-2020-0198; CVE-2020-0452

glib-2.0: fix CVE-2020-35457

glibc: CVE-2020-29562 and CVE-2020-29573

cups: Mark CVE-2008-1033 as a non-issue

cups: Mark CVE-2009-0032 as a non-issue

cups: whitelist CVE-2018-6553

coreutils: add SUSE-specific issues to CVE whitelist

qemu: CVE-2020-25624

qemu: CVE-2020-29129 CVE-2020-29130

 

 

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

Fixes

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

build-appliance-image: Update to gatesgarth head revision

poky.conf: Bump version for 3.2.2 gatesgarth release

bitbake: lib/bb/fetch2/__init__.py: drop _PYTHON_SYSCONFIGDATA_NAME unsetting

python3targetconfig.bbclass: Make py3 dep and tasks only for target recipes

gpgme: use python3targetconfig

meta: drop _PYTHON_SYSCONFIGDATA_NAME hacks

distutils3-base.bbclass: use python3targetconfig

python3-pycairo: use python3targetconfig

python3: split python target configuration into own class

uninative: Upgrade to 2.10

pseudo: Update to work with glibc 2.33

openssh: Backport a fix to fix with glibc 2.33 on some platforms

systemd: change /bin/nologin to /sbin/nologin

license_image.bbclass: Don't attempt to symlink to the same file

image_types.bbclass: tar: use posix format instead of gnu

qemu.inc: Should depend on qemu-system-native, not qemu-native

kernel.bbclass: fix deployment for initramfs images

package: Ensure do_packagedata is cleaned correctly

wic/selftest: test_permissions also test bitbake image

sstatesig: Add descriptive error message to getpwuid/getgrgid "uid/gid not found" KeyError

sanity.bbclass: Check if PSEUDO_IGNORE_PATHS and paths under pseudo control overlap

linux-yocto/5.4: update to v5.4.94

linux-yocto-rt/5.4: fix 5.4-stable caused build breakage

linux-yocto/5.4: update to v5.4.90

staging: Clean up files installed into the sysroot

python3: Avoid installing test data into recipe-sysroot

ncurses: Don't put terminfo into the sysroot

glibc: update to latest release/2.32/master branch

npm.bbclass: use python3 for npm config

recipetool: create: only add npmsw url if required

npm.bbclass: make shrinkwrap file optional

image_types: Ensure tar archives are reproducible

strace: increase ptest timeout duration 120->240s

ovmf-shell-image: image is only buildable on x86-64

core-image-sato-sdk-ptest: these images need ptest

dtc: improve reproducibility

python3: Use addtask statement instead of task dependencies

lib/oe/patch.py: Don't return command stderr from runcmd function

cve-check: replace Looseversion with custom version class

ca-certificates: upgrade 20200601 -> 20210119

pseudo: Update to include passwd and file renaming fixes

gobject-introspection: Fix variable override order

buildhistory.bbclass: avoid exception for empty BUILDHISTORY_FEATURES variable

externalsrc: Detect code changes in submodules

sanity.bbclass: sanity check for if bitbake is present in PATH

sanity: Verify that user isn't building in PSEUDO_IGNORE_PATHS

timezone: upgrade to 2021a

gstreamer1.0: fix failing ptest

devtool: Fix file:// fetcher symlink directory structure

oeqa/selftest/cases/tinfoil.py: increase timeout 10->60s test_wait_event

externalsrc: Fix parsing error with devtool non-git sources

p11-kit: upgrade 0.23.21 -> 0.23.22

linux-yocto: update genericx86 to v5.4.87

bitbake: fetch/git: download LFS content too during do_fetch

linuxloader: Avoid confusing string concat errors

flex: Fix --noline option behavior

devtool: Fix source extraction for gcc shared source

toolchain-shar-relocate.sh: Fix handling files with colons

wic: Optimise fstab modification for ext2/3/4 and msdos partitions

wic: Copy rootfs dir if fstab needs updating

wic: Update pseudo db when excluding content from rootfs

image_types_wic: Move wic working directory

wic: Allow exec_native_cmd to run HOSTTOOLS

wic: Ensure internal workdir is not reused

wic: Add workdir argument

gcc: Backport patch to resolve i*86 tune configuration overrides

lib/oe/utils: Return empty string in parallel_make

meta: toolchain-shar-relocate.sh: Filter out post-relocate-setup script

meta: toolchain-shar-relocate.sh: Do not use $target_sdk_dir as regex

boost: drop arm-intrinsics.patch

systemd.bbclass: improve error message when a service unit specified in SYSTEMD_SERVICE is not found

toolchain-shar-extract.sh: Handle special characters in script path

scripts: oe-run-native, fix *-native directories

bitbake: data_smart: Ensure hash reflects vardepvalue flags correctly

systemd: upgrade 246.6 -> 246.9

binutils: upgrade 2.35 -> 2.35.1

linux-yocto/5.4: update to v5.4.87

mobile-broadband-provider-info: upgrade 20190618 ->20201225

pseudo: Update for arm host and memleak fixes/cleanup

pseudo: Add lchmod wrapper

pseudo: Drop patches merged into upstream branch

pseudo: Update to print PSEUDO_LOGFILE in abort message on path mismatches

bitbake.conf: Add /run/ to PSEUDO_IGNORE_PATHS

selftest: Add argument to keep build dir

license.bbclass: Add COMMON_LICENSE_DIR and LICENSE_PATH dirs to PSEUDO_IGNORE_PATHS

bitbake.conf: Prevent pyc file generation in pseudo context

wic: Pass canonicalized paths in PSEUDO_IGNORE_PATHS

bitbake.conf: Canonicalize paths in PSEUDO_IGNORE_PATHS

lib/oe/path: Add canonicalize()

oeqa/commands: Ensure sync can be found regardless of PATH

initscripts: use quotes for shell variable comparision

coreutils: enable xattrs by default for nativesdk

diffstat: point the license checksum at the license

linux-yocto/5.4: update to v5.4.85

linux-yocto/5.4/cfg: fix FIRMWARE_LOADER warnings

linux-yocto/5.4/cfg: fix -tiny warnings

linux-yocto/5.8/cfg: fix -tiny warnings

linux-yocto/5.4: update to v5.4.83

linux-yocto/cfg: qemuarm64-gfx.cfg: add CONFIG_INPUT_UINPUT

linux-yocto/5.4: update to v5.4.82

linux-yocto/cfg: qemuppc: set CONFIG_SCSI to '=y'

timezone: upgrade to 2020f

man-db: Fix reproducibility issue

wic/direct/kparser: ensure fsuuid for vfat and msdos align with format

grub: Further reproducibility fix

devtool: gitsm:// should be handled same as git:// in upgrades

timezone: upgrade to 2020e

openssl: Update to 1.1.1i

oeqa/selftest/cases/devtool.py: fix typo in ignore_patterns call

apr-util: Only specify --with-dbm=gdbm if gdbm support is enabled

valgrind: exclude bar_bad/bar_bad_xml from ptests

archiver.bbclass: Fix --runall=deploy_archives for images

minicom: RDEPENDS on ncurses-terminfo-base

ncurses: Make ncurses-tools depend on ncurses-terminfo-base

gcc: Add patch to resolve i*86 tune configuration overrides

go.bbclass: Use external linker for native packages

go: Update 1.15.5 -> 1.15.6

go: Update to 1.15.5

go: upgrade 1.15.2 -> 1.15.3

timezone: upgrade to 2020d

kea: fix reproducibility

man-db: Avoid reproducibility failures after fixing groff-native

groff: Fix reproducibility issue

u-boot-tools: Fix reproducibility issue

ffmpeg: fix reproducibility

ruby: fix reproducibility

perl: fix installation failure because of shell issue

parted: Make readline dependency optional

glibc: Make adjtime() for 32 bit support being called with delta == NULL

lttng-modules: fix build against v5.10+

linux-yocto/5.4: update to v5.4.80

linux-yocto-rt/5.4: update to -rt44

grub: Add second fix for determinism issue

grub: Fix build reproducibility issue

linux-firmware: package firmware for Lontium lt9611uxc bridge

linux-firmware: upgrade 20201118 -> 20201218

linux-firmware: package ath11k firmware

linux-firmware: upgrade 20201022 -> 20201118

linux-firmware: upgrade 20200817 -> 20201022

wireless-regdb: upgrade 2020.04.29 -> 2020.11.20

uninative: Don't use single sstate for pseudo-native

kernel-module-split.bbclass: fix kernel modules getting marked as CONFFILES

webkitgtk: fix reproducibility

llvm: fix reproducibility

meta/lib/oe/reproducible.py: gitsm:// works just as fine as git:// for timestamps

populate_sdk_ext: use SDK_CUSTOM_TEPLATECONF variable to enable custom templateconf.cfg

meta/lib/oeqa/manual/oe-core.json: Update test_bitbake_devshell

image_types: remove obsolete tar comment

image_types: sort tarball file listings

oeqa/devtool: use Yocto mirror for pv-1.5.3 tarball

lz4: Use the new branch naming from upstream

buildtools-tarball: add wic dependency into extended buildtools

sudo: fix multilib conflict

cve-update-db-native: handle all-wildcard versions

libsdl2: Add directfb to PACKAGECONFIG rdepends


Re: #yocto #sdk #yocto #sdk

Monsees, Steven C (US)
 

Thanks, will go through it...

-----Original Message-----
From: Khem Raj <raj.khem@gmail.com>
Sent: Tuesday, February 23, 2021 2:30 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.


https://wiki.yoctoproject.org/wiki/TipsAndTricks/Understanding_what_changed_(diffsigs_etc)

On Tue, Feb 23, 2021 at 10:03 AM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



I am trying to understand the warnings/error as seen below…



Building for zeus…



Built kernel image clean updated my SSTATE_MIRRORS directory with the state_cache generated.

Rebuilt my image clean again using SSTATE_MIRRORS

Image builds clean and behaves correctly when booted…



I then build the SDK, my SSTATE_MIRRORS is defined in sdk-extra.conf,
and does properly show up in local.conf (checked after failure)

Building extended SDK has no issues.



But on install I see the following warnings and the error at the end…

I am not sure what is causing the issue here…



What would cause issues like this ?, and why ?



WARNING: The initscripts:do_install sig is computed to be
375d3c24b574b83fb04dc079fb52dd5e3a0ac31ed265acece2bb689f72f9adfa, but
the sig is locked to
40f5d2ac4affab9c60691714590ca00f30130ad2f5dc79f53aaf774957e1d927 in
SIGGEN_LOCKEDSIGS_t-corei7-64



There isn’t much in the documentation on this or SIGGEN…

What would be the best/proper approach to resolve issues like this ?



Thanks,

Steve



10:44 smonsees@yix490016
/disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default> bitbake
sbcb-defaultfs-full -c populate_sdk_ext

Loading cache: 100%
|#####################################################################
#################| Time: 0:00:00

Loaded 3645 entries from dependency cache.

NOTE: Resolving any missing task queue dependencies



Build Configuration:

BB_VERSION = "1.44.0"

BUILD_SYS = "x86_64-linux"

NATIVELSBSTRING = "rhel-7.9"

TARGET_SYS = "x86_64-poky-linux"

MACHINE = "sbcb-default"

DISTRO = "limws"

DISTRO_VERSION = "3.0.4"

TUNE_FEATURES = "m64 corei7"

TARGET_FPU = ""

meta

meta-poky = "my_yocto_3.0.4:f2eb22a8783f1eecf99bd4042695bab920eed00e"

meta-perl

meta-python

meta-filesystems

meta-networking

meta-initramfs

meta-oe = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b"

meta = "master:a32ddd2b2a51b26c011fa50e441df39304651503"

meta-intel = "zeus:d9942d4c3a710406b051852de7232db03c297f4e"

meta-intel = "v2019.02:f635a364c55f1fb12519aff54924a0a5b947091e"



Initialising tasks: 100%
|#####################################################################
############| Time: 0:00:04

Checking sstate mirror object availability: 100%
|#########################################################| Time:
0:00:00

Sstate summary: Wanted 566 Found 298 Missed 268 Current 1794 (52%
match, 88% complete)

NOTE: Executing Tasks

NOTE: Setscene tasks completed

NOTE: Tasks Summary: Attempted 6669 tasks of which 5861 didn't need to be rerun and all succeeded.

11:59 smonsees@yix490016
/disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default> cd
/disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default/tmp/depl
oy/sdk

11:59 smonsees@yix490016
/disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default/tmp/depl
oy/sdk>ls

limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.host.mani
fest

limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.sh

limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.target.ma
nifest

limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.testdata.
json

x86_64-buildtools-nativesdk-standalone-3.0.4.host.manifest

x86_64-buildtools-nativesdk-standalone-3.0.4.sh

x86_64-buildtools-nativesdk-standalone-3.0.4.target.manifest

x86_64-buildtools-nativesdk-standalone-3.0.4.testdata.json

11:59 smonsees@yix490016
/disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default/tmp/depl
oy/sdk>./limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.
sh

LIMWS (BAE LIMWS base distro) Extensible SDK installer version 3.0.4

====================================================================

Enter target directory for SDK (default: ~/limws_sdk):
/disk0/scratch/smonsees/testSDK

You are about to install the SDK to "/disk0/scratch/smonsees/testSDK".
Proceed [Y/n]? Y

Extracting
SDK...................................................................
...........done

Setting it up...

Extracting buildtools...

Preparing build system...

Parsing recipes: 100%
|#####################################################################
###############| Time: 0:01:32

Initialising tasks: 100%
|#####################################################################
############| Time: 0:00:04

Checking sstate mirror object availability: 100%
|#########################################################| Time:
0:00:03

WARNING: The initscripts:do_install sig is computed to be
375d3c24b574b83fb04dc079fb52dd5e3a0ac31ed265acece2bb689f72f9adfa, but
the sig is locked to
40f5d2ac4affab9c60691714590ca00f30130ad2f5dc79f53aaf774957e1d927 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The linux-intel:do_compile sig is computed to be
9898137f78ba37d2fcf7df5a7b7a5dd0e5ddcbc7ce7ade89905bf5132a005a99, but
the sig is locked to
06c08387009f9808044e03144d1fa0b984be9f4ad64251e688503c2dabdf5b7c in
SIGGEN_LOCKEDSIGS_t-corei7-64-intel-common

The imagerecv:do_compile sig is computed to be
644b002b181f27a407c33cc69cfc790201f1b48c4d7783c062d53c247d5704a5, but
the sig is locked to
a74b10cfc4bad050ca98549b3df41fcd0fa986e08c14e05db44b0227d0b90a0a in
SIGGEN_LOCKEDSIGS_t-sbcb-default

The tpm2-tss:do_configure sig is computed to be
04cf4c8e1424a46467a43620214fc3a5304863f5cbb662b5b26a5b82d792586f, but
the sig is locked to
ec4b02e1e3b1796883093be2aca63ec5e51df3dc14b9179be6f86f2675b3fa53 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The efitools:do_compile sig is computed to be
c2e6dc60a7b8b2414b3761fe4966e031901144e3d32eed60bd580cc46e9b5358, but
the sig is locked to
327fbae2aa4a419554ede6847fcc7c367da018e5e9d907a0051e68df5a5a2063 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_configure sig is computed to be
8a5cfb349fa84ca524bf680a922d0e1781f5dc9e0b5e0f6e0b135ea88e3f8fa1, but
the sig is locked to
8d2bf2edd3194e44de0143088e68703c02a88032bb089ef0a4600f7528695362 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_compile sig is computed to be
819f7700a7f611335b8a5e4f8243623c4f01b187f197aa19cd034383af17b41b, but
the sig is locked to
822db696400b5a788fbcc0e80f1fe242bd58cab992ff196efac191444d7b3b99 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_install sig is computed to be
f2f8cb58b07a350eefd41af13e1156abd85659b1865dc278238277d9230e2e3f, but
the sig is locked to
9e1ca795df7d73347f0efeeac54c24f1004d59011b97262207e1055f771ee95c in
SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_populate_sysroot sig is computed to be
ca8fe144be00929f3c42cb36b809a06b85d70c4f9fa1c0f6fd67b07af84d17a1, but
the sig is locked to
2a41afd838cdac669dd99deefdc530c5d503329fb1fae2fb3641b490a2bbec8a in
SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_package sig is computed to be
29a5daea524a219c5216b5d76447160d006e7db633e38c7d1ade6b599eb6c2ab, but
the sig is locked to
2b2cef367c44399221b07f14facff9b1ae598ccc272c4b98ddfc4b08009fc090 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_configure sig is computed to be
613844241ce15b245abe2fb9306415616c72553e943183307b3496f85637345e, but
the sig is locked to
68a818acd3281e28bd57efcd449a0bac0ffaa2733fcb02f6b28b2fe31d36e835 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_compile sig is computed to be
8b37e4a0e6ec0068b7dda0eccd1e32577daedf248f1c3e71f82f6454d3e4338d, but
the sig is locked to
6f291a0f9ba59f355d9a88d646f72bf99a001f862b310e5e435e8b406632b6b4 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_install sig is computed to be
3a20f56cc04551f13378e9e596daa5eebc385ca965ebdf18adacfa7ef94c9018, but
the sig is locked to
8fc761f8bf0215ea2fb9609037a5df0c7e2ad6dd9253555ea5f492b7068e7bff in
SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_populate_sysroot sig is computed to be
97d2f34ef4b40fe8e324c04346ad0cdf22cde6cc774f336400797cb6a483d08c, but
the sig is locked to
93700035bc1a42b4f7e5f05ef30d4bc6fdf2abc0dd1f707b2e745ceed25d5770 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_package sig is computed to be
f59f3584026d4acf71d4300a18ff4bf05c0f3e3b42c2d5264af9be63820a0386, but
the sig is locked to
bdc6003bbd7a42a83e9a6a7ebe691e93a9744ae96c664d8656907a15af84be1c in
SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi-native:do_clean_grub sig is computed to be
17c62b3df5a57ee4cbd0e7abf1284a5d499ba4c814aaded564a24085b9fd326c, but
the sig is locked to
c8835ffb27e0d97b332dddad3fb83bdb849a267a8a0fa7142e66a76696c910ff in
SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_configure sig is computed to be
a6dfb6cd633432b36b818b63fd6e06e086d189b62cd7fc6370c4e66e9668fa1d, but
the sig is locked to
194602954bb4993b85397aeb06557d10ff14b15d52a321389cdbb0139d2ce34c in
SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_compile sig is computed to be
583800a58ca2e602d50b4e23485774e8b681f79bf48a1a854b71264a0ddcb733, but
the sig is locked to
e642b6c931bda1d51bc5394596cdacce7099875d1e873b39849607e03972c5b9 in
SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_mkimage sig is computed to be
87a6528cb8624851708b1f4d3fa26beb96f71f1a3cb0c4d48fe0aaf9255fb244, but
the sig is locked to
bc04f79c9988122be8297c3ea2e7aa13fbe18444b1151a547332112616e11480 in
SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_install sig is computed to be
6e8a988562949ae845beb0150acf7702a360094db56096b6e2bbb65820bbb3f0, but
the sig is locked to
38427ff1c0bfa569a27a6c5acf51bb3483d882b18a1fa0bfbfaa371822df7837 in
SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_populate_sysroot sig is computed to be
3ba3744800732b69e71d33ea0db797a78bb2340727fc54f211bd0f7c1325374c, but
the sig is locked to
fcd9daa126de91d4d1de701ed1ff1c2774c3e42207e1fff85b86109eb54b290c in
SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi:do_clean_grub sig is computed to be
928fbd9c1d534333f18a6f751ad705c03f083ff00374a781b02e1aee47b92bee, but
the sig is locked to
67a039367c0593803d8c70207f079fd8be28dbc6c548b13837fa7eb177b156e0 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi-native:do_deploy sig is computed to be
4875f4b51c38f31140775a2a4457839eabef2529791cccbb9ed656eef63892fc, but
the sig is locked to
6576c95aa5c0c7b505ca2cc02fdde3f678f2b039c2f0b57810b17694b6070a46 in
SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi:do_configure sig is computed to be
84ab069273c4b2703ca4fa200d5fb66adcaffa39b8f36138339d4837b9281a9d, but
the sig is locked to
e8900241347d4616468e7a4a4c37b8496a1167c2b3d58f7bb55332da645bd7e0 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_compile sig is computed to be
619bdca4f1a6df8c8c2c7ad49b7289af3477e3c76c00b84229584793f23fb115, but
the sig is locked to
56ca563b3bcb66b72f53f51562f41dd0cf9af878335836e8fd6b6a07e32fa8bc in
SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_mkimage sig is computed to be
f212bd74eb95f4d413c9867f853171747fe4fe86912138a0ac79234fe4be73b7, but
the sig is locked to
80e9256f12e3070737c81f76310cc408473b92b877b23494cd1b4c2abdffd56d in
SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_install sig is computed to be
45753f50a553391bd80cf679039cccf879ef1eaca90e1dcfefb432621dfc0000, but
the sig is locked to
3910d27330229314b793a94c7085c231a56c1073d7e79d4cceade5a373600252 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_populate_sysroot sig is computed to be
3437833e837748a59e002f95773a8f61a715bb56c0f20671fa39a71556ad6d5d, but
the sig is locked to
d0d60bc1d9bf488c7568e592b3b1aeeb2e2796c9994f83fe1b781e0d006e432b in
SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_package sig is computed to be
81fa6cf23920cea4139ed3cefd6c94a3878580f6a45925279c7d75e3c487f162, but
the sig is locked to
d7ec82448f34ec8c0169f613fdd14237cebb1951efa3d35d53dc71d24f220cb8 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_deploy sig is computed to be
f7831a1a7e1d8683e1c0c86fd32486ec8d9e5e713d63e39984aa36f50bff7f91, but
the sig is locked to
1c781659fad7fb174716d05aa5727f68e710ad7c6593dc178f40866d6e868f19 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The tpm2-tools:do_configure sig is computed to be
10fa6cf0c4fa307a427978392ecf60d7a8853e11ca1747ea5ad8743fd42280f3, but
the sig is locked to
5e6a2caa27901f95518467ca35b68043fee7802dfa8be39ae51e61c9eedf9a8d in
SIGGEN_LOCKEDSIGS_t-corei7-64

The wolfssl:do_configure sig is computed to be
5569ddf9b10e2df9f5de456ca35b9baeb34a1f67617357d5e1a9264baf3d1e0e, but
the sig is locked to
eaf1b380210718071d8962eeccbd97efad180fabc750b18f4e98661de06ae11f in
SIGGEN_LOCKEDSIGS_t-corei7-64

The crush:do_configure sig is computed to be
f034116fd9598a09aa975e94dd48964e0d49deecf63d96c436bd4cccc7b68298, but
the sig is locked to
64dfc5ff4a9ee29e9a20f1166ec2ee6fe20ffcd93e7618eabd02435c29f219ed in
SIGGEN_LOCKEDSIGS_t-corei7-64

ERROR: Task quilt-native.do_fetch attempted to execute unexpectedly














Adding USB modem support to Yocto #raspberrypi

José Amador Demeneghi
 

Hi!
I'm a new Yocto user trying to develop a fork of Chirpstack's Gateway OS for Raspberry Pi based LoRaWAN gateways. Although I have successfully modified and added new recipes, I'm struggling with adding a USB cellular modem to my image.

I have a Huawei E303C USB modem and followed the instructions from the Embexus website with no success. It basically proposes using oFono + connman to create a network interface, but after running the instructed commands, I get this error:

$ sudo /usr/lib/ofono/test/activate-context
Error activating /huawei_0/context1: org.ofono.Error.NotImplemented: Implementation not provided

As an additional step, I enabled roaming using the set-roaming-allowed script in the oFono tests directory. I made the kernel configuration in layers/targets/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_%.bbappend and the connman package configuration in meta/conf/distro/chirpstack-gateway-os.conf.

 


I considered installing NetworkManager from the OpenEmbedded layer. Still, it has a declared conflict with connman, which is used to set a WIFI AP, and I don't want to remove that feature.

This is the output from the list-modems script:
[ /huawei_0 ]
    Online = 1
    Powered = 1
    Lockdown = 0
    Emergency = 0
    Manufacturer = huawei
    Model = E303C
    Revision = 21.157.01.01.18
    Serial = 867360018081349
    SystemPath = /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3
    Interfaces = org.ofono.CellBroadcast org.ofono.NetworkRegistration org.ofono.SupplementaryServices org.ofono.CallBarring org.ofono.CallSettings org.ofono.CallForwarding org.ofono.MessageWaiting org.ofono.ConnectionManager org.ofono.SmartMessaging org.ofono.PushNotification org.ofono.MessageManager org.ofono.RadioSettings org.ofono.Phonebook org.ofono.AudioSettings org.ofono.VoiceCallManager org.ofono.AllowedAccessPoints org.ofono.SimManager
    Features = cbs net ussd gprs sms rat sim
    Type = hardware
    [ org.ofono.CellBroadcast ]
        Powered = 0
        Topics = 2,4,36,50,118,135,255,555,569
    [ org.ofono.NetworkRegistration ]
        Status = roaming
        Mode = auto
        Technology = umts
        MobileCountryCode = 334
        MobileNetworkCode = 020
        Name = EMnify (Mx Telcel GSM)
        Strength = 41
    [ org.ofono.SupplementaryServices ]
        State = idle
    [ org.ofono.CallBarring ]
        VoiceOutgoing = disabled
        VoiceIncoming = disabled
    [ org.ofono.CallSettings ]
        CallingLinePresentation = enabled
        CallingNamePresentation = unknown
        ConnectedLinePresentation = disabled
        ConnectedLineRestriction = unknown
        CalledLinePresentation = disabled
        CallingLineRestriction = off
        HideCallerId = default
        VoiceCallWaiting = disabled
    [ org.ofono.CallForwarding ]
        VoiceUnconditional =
        VoiceBusy =
        VoiceNoReply =
        VoiceNoReplyTimeout = 20
        VoiceNotReachable =
        ForwardingFlagOnSim = 0
    [ org.ofono.MessageWaiting ]
        VoicemailWaiting = 0
        VoicemailMessageCount = 0
        VoicemailMailboxNumber =
    [ org.ofono.ConnectionManager ]
        Attached = 1
        Bearer = umts
        RoamingAllowed = 1
        Powered = 1
        Suspended = 0
    [ org.ofono.SmartMessaging ]
    [ org.ofono.PushNotification ]
    [ org.ofono.MessageManager ]
        ServiceCenterAddress = +42379010570
        UseDeliveryReports = 0
        Bearer = cs-preferred
        Alphabet = default
    [ org.ofono.RadioSettings ]
    [ org.ofono.Phonebook ]
    [ org.ofono.AudioSettings ]
        Active = 0
    [ org.ofono.VoiceCallManager ]
        EmergencyNumbers = 118 110 08 911 000 112 999 119
    [ org.ofono.AllowedAccessPoints ]
    [ org.ofono.SimManager ]
        Present = 1
        CardIdentifier = 89883030000055775206
        SubscriberIdentity = 295050901033049
        ServiceProviderName = EMnify
        FixedDialing = 0
        BarredDialing = 0
        MobileCountryCode = 295
        MobileNetworkCode = 05
        SubscriberNumbers =
        LockedPins =
        PreferredLanguages = de en
        PinRequired = none
        Retries = [pin = 3] [pin2 = 3] [puk = 10] [puk2 = 10]
        CardSlotCount = 1
        ActiveCardSlot = 1




Re: #yocto #sdk #yocto #sdk

Khem Raj
 

https://wiki.yoctoproject.org/wiki/TipsAndTricks/Understanding_what_changed_(diffsigs_etc)

On Tue, Feb 23, 2021 at 10:03 AM Monsees, Steven C (US) via
lists.yoctoproject.org
<steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:




I am trying to understand the warnings/error as seen below…



Building for zeus…



Built kernel image clean updated my SSTATE_MIRRORS directory with the state_cache generated.

Rebuilt my image clean again using SSTATE_MIRRORS

Image builds clean and behaves correctly when booted…



I then build the SDK, my SSTATE_MIRRORS is defined in sdk-extra.conf, and does properly show up in local.conf (checked after failure)

Building extended SDK has no issues.



But on install I see the following warnings and the error at the end…

I am not sure what is causing the issue here…



What would cause issues like this ?, and why ?



WARNING: The initscripts:do_install sig is computed to be 375d3c24b574b83fb04dc079fb52dd5e3a0ac31ed265acece2bb689f72f9adfa, but the sig is locked to 40f5d2ac4affab9c60691714590ca00f30130ad2f5dc79f53aaf774957e1d927 in SIGGEN_LOCKEDSIGS_t-corei7-64



There isn’t much in the documentation on this or SIGGEN…

What would be the best/proper approach to resolve issues like this ?



Thanks,

Steve



10:44 smonsees@yix490016 /disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default> bitbake sbcb-defaultfs-full -c populate_sdk_ext

Loading cache: 100% |######################################################################################| Time: 0:00:00

Loaded 3645 entries from dependency cache.

NOTE: Resolving any missing task queue dependencies



Build Configuration:

BB_VERSION = "1.44.0"

BUILD_SYS = "x86_64-linux"

NATIVELSBSTRING = "rhel-7.9"

TARGET_SYS = "x86_64-poky-linux"

MACHINE = "sbcb-default"

DISTRO = "limws"

DISTRO_VERSION = "3.0.4"

TUNE_FEATURES = "m64 corei7"

TARGET_FPU = ""

meta

meta-poky = "my_yocto_3.0.4:f2eb22a8783f1eecf99bd4042695bab920eed00e"

meta-perl

meta-python

meta-filesystems

meta-networking

meta-initramfs

meta-oe = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b"

meta = "master:a32ddd2b2a51b26c011fa50e441df39304651503"

meta-intel = "zeus:d9942d4c3a710406b051852de7232db03c297f4e"

meta-intel = "v2019.02:f635a364c55f1fb12519aff54924a0a5b947091e"



Initialising tasks: 100% |#################################################################################| Time: 0:00:04

Checking sstate mirror object availability: 100% |#########################################################| Time: 0:00:00

Sstate summary: Wanted 566 Found 298 Missed 268 Current 1794 (52% match, 88% complete)

NOTE: Executing Tasks

NOTE: Setscene tasks completed

NOTE: Tasks Summary: Attempted 6669 tasks of which 5861 didn't need to be rerun and all succeeded.

11:59 smonsees@yix490016 /disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default> cd /disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default/tmp/deploy/sdk

11:59 smonsees@yix490016 /disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default/tmp/deploy/sdk>ls

limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.host.manifest

limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.sh

limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.target.manifest

limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.testdata.json

x86_64-buildtools-nativesdk-standalone-3.0.4.host.manifest

x86_64-buildtools-nativesdk-standalone-3.0.4.sh

x86_64-buildtools-nativesdk-standalone-3.0.4.target.manifest

x86_64-buildtools-nativesdk-standalone-3.0.4.testdata.json

11:59 smonsees@yix490016 /disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default/tmp/deploy/sdk>./limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.sh

LIMWS (BAE LIMWS base distro) Extensible SDK installer version 3.0.4

====================================================================

Enter target directory for SDK (default: ~/limws_sdk): /disk0/scratch/smonsees/testSDK

You are about to install the SDK to "/disk0/scratch/smonsees/testSDK". Proceed [Y/n]? Y

Extracting SDK..............................................................................done

Setting it up...

Extracting buildtools...

Preparing build system...

Parsing recipes: 100% |####################################################################################| Time: 0:01:32

Initialising tasks: 100% |#################################################################################| Time: 0:00:04

Checking sstate mirror object availability: 100% |#########################################################| Time: 0:00:03

WARNING: The initscripts:do_install sig is computed to be 375d3c24b574b83fb04dc079fb52dd5e3a0ac31ed265acece2bb689f72f9adfa, but the sig is locked to 40f5d2ac4affab9c60691714590ca00f30130ad2f5dc79f53aaf774957e1d927 in SIGGEN_LOCKEDSIGS_t-corei7-64

The linux-intel:do_compile sig is computed to be 9898137f78ba37d2fcf7df5a7b7a5dd0e5ddcbc7ce7ade89905bf5132a005a99, but the sig is locked to 06c08387009f9808044e03144d1fa0b984be9f4ad64251e688503c2dabdf5b7c in SIGGEN_LOCKEDSIGS_t-corei7-64-intel-common

The imagerecv:do_compile sig is computed to be 644b002b181f27a407c33cc69cfc790201f1b48c4d7783c062d53c247d5704a5, but the sig is locked to a74b10cfc4bad050ca98549b3df41fcd0fa986e08c14e05db44b0227d0b90a0a in SIGGEN_LOCKEDSIGS_t-sbcb-default

The tpm2-tss:do_configure sig is computed to be 04cf4c8e1424a46467a43620214fc3a5304863f5cbb662b5b26a5b82d792586f, but the sig is locked to ec4b02e1e3b1796883093be2aca63ec5e51df3dc14b9179be6f86f2675b3fa53 in SIGGEN_LOCKEDSIGS_t-corei7-64

The efitools:do_compile sig is computed to be c2e6dc60a7b8b2414b3761fe4966e031901144e3d32eed60bd580cc46e9b5358, but the sig is locked to 327fbae2aa4a419554ede6847fcc7c367da018e5e9d907a0051e68df5a5a2063 in SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_configure sig is computed to be 8a5cfb349fa84ca524bf680a922d0e1781f5dc9e0b5e0f6e0b135ea88e3f8fa1, but the sig is locked to 8d2bf2edd3194e44de0143088e68703c02a88032bb089ef0a4600f7528695362 in SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_compile sig is computed to be 819f7700a7f611335b8a5e4f8243623c4f01b187f197aa19cd034383af17b41b, but the sig is locked to 822db696400b5a788fbcc0e80f1fe242bd58cab992ff196efac191444d7b3b99 in SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_install sig is computed to be f2f8cb58b07a350eefd41af13e1156abd85659b1865dc278238277d9230e2e3f, but the sig is locked to 9e1ca795df7d73347f0efeeac54c24f1004d59011b97262207e1055f771ee95c in SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_populate_sysroot sig is computed to be ca8fe144be00929f3c42cb36b809a06b85d70c4f9fa1c0f6fd67b07af84d17a1, but the sig is locked to 2a41afd838cdac669dd99deefdc530c5d503329fb1fae2fb3641b490a2bbec8a in SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_package sig is computed to be 29a5daea524a219c5216b5d76447160d006e7db633e38c7d1ade6b599eb6c2ab, but the sig is locked to 2b2cef367c44399221b07f14facff9b1ae598ccc272c4b98ddfc4b08009fc090 in SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_configure sig is computed to be 613844241ce15b245abe2fb9306415616c72553e943183307b3496f85637345e, but the sig is locked to 68a818acd3281e28bd57efcd449a0bac0ffaa2733fcb02f6b28b2fe31d36e835 in SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_compile sig is computed to be 8b37e4a0e6ec0068b7dda0eccd1e32577daedf248f1c3e71f82f6454d3e4338d, but the sig is locked to 6f291a0f9ba59f355d9a88d646f72bf99a001f862b310e5e435e8b406632b6b4 in SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_install sig is computed to be 3a20f56cc04551f13378e9e596daa5eebc385ca965ebdf18adacfa7ef94c9018, but the sig is locked to 8fc761f8bf0215ea2fb9609037a5df0c7e2ad6dd9253555ea5f492b7068e7bff in SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_populate_sysroot sig is computed to be 97d2f34ef4b40fe8e324c04346ad0cdf22cde6cc774f336400797cb6a483d08c, but the sig is locked to 93700035bc1a42b4f7e5f05ef30d4bc6fdf2abc0dd1f707b2e745ceed25d5770 in SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_package sig is computed to be f59f3584026d4acf71d4300a18ff4bf05c0f3e3b42c2d5264af9be63820a0386, but the sig is locked to bdc6003bbd7a42a83e9a6a7ebe691e93a9744ae96c664d8656907a15af84be1c in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi-native:do_clean_grub sig is computed to be 17c62b3df5a57ee4cbd0e7abf1284a5d499ba4c814aaded564a24085b9fd326c, but the sig is locked to c8835ffb27e0d97b332dddad3fb83bdb849a267a8a0fa7142e66a76696c910ff in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_configure sig is computed to be a6dfb6cd633432b36b818b63fd6e06e086d189b62cd7fc6370c4e66e9668fa1d, but the sig is locked to 194602954bb4993b85397aeb06557d10ff14b15d52a321389cdbb0139d2ce34c in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_compile sig is computed to be 583800a58ca2e602d50b4e23485774e8b681f79bf48a1a854b71264a0ddcb733, but the sig is locked to e642b6c931bda1d51bc5394596cdacce7099875d1e873b39849607e03972c5b9 in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_mkimage sig is computed to be 87a6528cb8624851708b1f4d3fa26beb96f71f1a3cb0c4d48fe0aaf9255fb244, but the sig is locked to bc04f79c9988122be8297c3ea2e7aa13fbe18444b1151a547332112616e11480 in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_install sig is computed to be 6e8a988562949ae845beb0150acf7702a360094db56096b6e2bbb65820bbb3f0, but the sig is locked to 38427ff1c0bfa569a27a6c5acf51bb3483d882b18a1fa0bfbfaa371822df7837 in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_populate_sysroot sig is computed to be 3ba3744800732b69e71d33ea0db797a78bb2340727fc54f211bd0f7c1325374c, but the sig is locked to fcd9daa126de91d4d1de701ed1ff1c2774c3e42207e1fff85b86109eb54b290c in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi:do_clean_grub sig is computed to be 928fbd9c1d534333f18a6f751ad705c03f083ff00374a781b02e1aee47b92bee, but the sig is locked to 67a039367c0593803d8c70207f079fd8be28dbc6c548b13837fa7eb177b156e0 in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi-native:do_deploy sig is computed to be 4875f4b51c38f31140775a2a4457839eabef2529791cccbb9ed656eef63892fc, but the sig is locked to 6576c95aa5c0c7b505ca2cc02fdde3f678f2b039c2f0b57810b17694b6070a46 in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi:do_configure sig is computed to be 84ab069273c4b2703ca4fa200d5fb66adcaffa39b8f36138339d4837b9281a9d, but the sig is locked to e8900241347d4616468e7a4a4c37b8496a1167c2b3d58f7bb55332da645bd7e0 in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_compile sig is computed to be 619bdca4f1a6df8c8c2c7ad49b7289af3477e3c76c00b84229584793f23fb115, but the sig is locked to 56ca563b3bcb66b72f53f51562f41dd0cf9af878335836e8fd6b6a07e32fa8bc in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_mkimage sig is computed to be f212bd74eb95f4d413c9867f853171747fe4fe86912138a0ac79234fe4be73b7, but the sig is locked to 80e9256f12e3070737c81f76310cc408473b92b877b23494cd1b4c2abdffd56d in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_install sig is computed to be 45753f50a553391bd80cf679039cccf879ef1eaca90e1dcfefb432621dfc0000, but the sig is locked to 3910d27330229314b793a94c7085c231a56c1073d7e79d4cceade5a373600252 in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_populate_sysroot sig is computed to be 3437833e837748a59e002f95773a8f61a715bb56c0f20671fa39a71556ad6d5d, but the sig is locked to d0d60bc1d9bf488c7568e592b3b1aeeb2e2796c9994f83fe1b781e0d006e432b in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_package sig is computed to be 81fa6cf23920cea4139ed3cefd6c94a3878580f6a45925279c7d75e3c487f162, but the sig is locked to d7ec82448f34ec8c0169f613fdd14237cebb1951efa3d35d53dc71d24f220cb8 in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_deploy sig is computed to be f7831a1a7e1d8683e1c0c86fd32486ec8d9e5e713d63e39984aa36f50bff7f91, but the sig is locked to 1c781659fad7fb174716d05aa5727f68e710ad7c6593dc178f40866d6e868f19 in SIGGEN_LOCKEDSIGS_t-corei7-64

The tpm2-tools:do_configure sig is computed to be 10fa6cf0c4fa307a427978392ecf60d7a8853e11ca1747ea5ad8743fd42280f3, but the sig is locked to 5e6a2caa27901f95518467ca35b68043fee7802dfa8be39ae51e61c9eedf9a8d in SIGGEN_LOCKEDSIGS_t-corei7-64

The wolfssl:do_configure sig is computed to be 5569ddf9b10e2df9f5de456ca35b9baeb34a1f67617357d5e1a9264baf3d1e0e, but the sig is locked to eaf1b380210718071d8962eeccbd97efad180fabc750b18f4e98661de06ae11f in SIGGEN_LOCKEDSIGS_t-corei7-64

The crush:do_configure sig is computed to be f034116fd9598a09aa975e94dd48964e0d49deecf63d96c436bd4cccc7b68298, but the sig is locked to 64dfc5ff4a9ee29e9a20f1166ec2ee6fe20ffcd93e7618eabd02435c29f219ed in SIGGEN_LOCKEDSIGS_t-corei7-64

ERROR: Task quilt-native.do_fetch attempted to execute unexpectedly














Re: Kernel Header UAPI Issue

Bruce Ashfield
 

On Tue, Feb 23, 2021 at 9:56 AM Karthik Poduval
<karthik.poduval@gmail.com> wrote:

Hi Mikko,

Do you have an example on how you do that ? Do you bbapend the
linux-libc-headers recipe file ?
I have an application that uses dmabuf heap that potentially extends
across multiple BSP's as its BSP agnostic. I don't want to be patching
individual BSP recipes and generating headers. The issue I am facing
is due to backporting the patch from 5.6 to 5.4 so the required header
isn't a part of the linux-libc-headers.bb recipe. Best would have been
a virtual/kernel-keaders target that applications that require BSP
headers would add to their recipe DEPENDS. Why is this not a solved
issue by yocto project ? Why do individual BSP's need to deal with
this differently when the header install mechanism (make
headers_install) is the same irrespective of the type of BSP ?
Because it's not a simple thing to solve (and there's a bugzilla around for it
already, where the thoughts and issues are captured, but that one seems to
have been closed and I can't find it at the moment). I do have a WIP
class that provides some different modes
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=5305),
but with corner cases and concerns, it keeps slipping. Feel free to try it
out and comment in the bug (I'll try myself to be sure it still applied, it has
been a few months).

What works for your case, doesn't mean it is a general/supporable
solution.

But generally speaking, It's an incredibly bad idea to have your libc-headers
tied to the kernel you are building. Every time that kernel changes, you
basically need to rebuild the entire stack .. hence the bad idea. It is such
a common question, that we actually put a warning in the libc-headers
recipe itself.

We do not really want a parallel set of headers in the shared workdir, that are
from the currently built kernel. You'd end up with all sorts of mismatches
and cross includes and potential different behaviour per-application.

We already have the kernel source installed into the shared workdir,
which is what the tips in the libc-headers recipe suggest using. And it
honestly isn't so common the need for sanitized headers that the need for
something like I did in that bug has made it necessary.

Bruce


On Tue, Feb 23, 2021 at 5:18 AM <Mikko.Rapeli@bmw.de> wrote:

Hi,

I know it's not the best or recommended approach, but I find it
hard to avoid merging linux-libc-headers recipe with the actual
kernel recipe that a distro is using. At least a static copy
of some version of uapi headers from that kernel can be used
instead of the poky side linux-libc-headers. This helps to get
the actual BSP SW delivery headers into userspace, SDK etc.

Cheers,

-Mikko


--
Regards,
Karthik Poduval

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


OpenEmbedded Happy Hour February 24 9pm/2100 UTC

Denys Dmytriyenko
 

Hi,

Please join us for the upcoming OpenEmbedded Happy Hour on February 24 for
Asia/Pacific timezones @ 2100/9pm UTC (4pm EST):

https://www.openembedded.org/wiki/Calendar
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+Happy+Hour+February+24&iso=20210224T21

--
Regards,
Denys Dmytriyenko <denis@denix.org>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964


#yocto #sdk #yocto #sdk

Monsees, Steven C (US)
 

 

I am trying to understand the warnings/error as seen below…

 

Building for zeus…

 

Built kernel image clean updated my SSTATE_MIRRORS directory with the state_cache generated.

Rebuilt my image clean again using SSTATE_MIRRORS

Image builds clean and behaves correctly when booted…

 

I then build the SDK, my SSTATE_MIRRORS is defined in sdk-extra.conf, and does properly show up in local.conf (checked after failure)

Building extended SDK has no issues.

 

But on install I see the following warnings and the error at the end…

I am not sure what is causing the issue here…

 

What would cause issues like this ?, and why ?

 

WARNING: The initscripts:do_install sig is computed to be 375d3c24b574b83fb04dc079fb52dd5e3a0ac31ed265acece2bb689f72f9adfa, but the sig is locked to 40f5d2ac4affab9c60691714590ca00f30130ad2f5dc79f53aaf774957e1d927 in SIGGEN_LOCKEDSIGS_t-corei7-64

 

There isn’t much in the documentation on this or SIGGEN…

What would be the best/proper approach to resolve issues like this ?

 

Thanks,

Steve

 

10:44 smonsees@yix490016 /disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default> bitbake sbcb-defaultfs-full -c populate_sdk_ext

Loading cache: 100% |######################################################################################| Time: 0:00:00

Loaded 3645 entries from dependency cache.

NOTE: Resolving any missing task queue dependencies

 

Build Configuration:

BB_VERSION           = "1.44.0"

BUILD_SYS            = "x86_64-linux"

NATIVELSBSTRING      = "rhel-7.9"

TARGET_SYS           = "x86_64-poky-linux"

MACHINE              = "sbcb-default"

DISTRO               = "limws"

DISTRO_VERSION       = "3.0.4"

TUNE_FEATURES        = "m64 corei7"

TARGET_FPU           = ""

meta                

meta-poky            = "my_yocto_3.0.4:f2eb22a8783f1eecf99bd4042695bab920eed00e"

meta-perl           

meta-python         

meta-filesystems    

meta-networking     

meta-initramfs      

meta-oe              = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b"

meta                 = "master:a32ddd2b2a51b26c011fa50e441df39304651503"

meta-intel           = "zeus:d9942d4c3a710406b051852de7232db03c297f4e"

meta-intel           = "v2019.02:f635a364c55f1fb12519aff54924a0a5b947091e"

 

Initialising tasks: 100% |#################################################################################| Time: 0:00:04

Checking sstate mirror object availability: 100% |#########################################################| Time: 0:00:00

Sstate summary: Wanted 566 Found 298 Missed 268 Current 1794 (52% match, 88% complete)

NOTE: Executing Tasks

NOTE: Setscene tasks completed

NOTE: Tasks Summary: Attempted 6669 tasks of which 5861 didn't need to be rerun and all succeeded.

11:59 smonsees@yix490016 /disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default> cd /disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default/tmp/deploy/sdk

11:59 smonsees@yix490016 /disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default/tmp/deploy/sdk>ls

limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.host.manifest

limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.sh

limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.target.manifest

limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.testdata.json

x86_64-buildtools-nativesdk-standalone-3.0.4.host.manifest

x86_64-buildtools-nativesdk-standalone-3.0.4.sh

x86_64-buildtools-nativesdk-standalone-3.0.4.target.manifest

x86_64-buildtools-nativesdk-standalone-3.0.4.testdata.json

11:59 smonsees@yix490016 /disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default/tmp/deploy/sdk>./limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.sh

LIMWS (BAE LIMWS base distro) Extensible SDK installer version 3.0.4

====================================================================

Enter target directory for SDK (default: ~/limws_sdk): /disk0/scratch/smonsees/testSDK

You are about to install the SDK to "/disk0/scratch/smonsees/testSDK". Proceed [Y/n]? Y

Extracting SDK..............................................................................done

Setting it up...

Extracting buildtools...

Preparing build system...

Parsing recipes: 100% |####################################################################################| Time: 0:01:32

Initialising tasks: 100% |#################################################################################| Time: 0:00:04

Checking sstate mirror object availability: 100% |#########################################################| Time: 0:00:03

WARNING: The initscripts:do_install sig is computed to be 375d3c24b574b83fb04dc079fb52dd5e3a0ac31ed265acece2bb689f72f9adfa, but the sig is locked to 40f5d2ac4affab9c60691714590ca00f30130ad2f5dc79f53aaf774957e1d927 in SIGGEN_LOCKEDSIGS_t-corei7-64

The linux-intel:do_compile sig is computed to be 9898137f78ba37d2fcf7df5a7b7a5dd0e5ddcbc7ce7ade89905bf5132a005a99, but the sig is locked to 06c08387009f9808044e03144d1fa0b984be9f4ad64251e688503c2dabdf5b7c in SIGGEN_LOCKEDSIGS_t-corei7-64-intel-common

The imagerecv:do_compile sig is computed to be 644b002b181f27a407c33cc69cfc790201f1b48c4d7783c062d53c247d5704a5, but the sig is locked to a74b10cfc4bad050ca98549b3df41fcd0fa986e08c14e05db44b0227d0b90a0a in SIGGEN_LOCKEDSIGS_t-sbcb-default

The tpm2-tss:do_configure sig is computed to be 04cf4c8e1424a46467a43620214fc3a5304863f5cbb662b5b26a5b82d792586f, but the sig is locked to ec4b02e1e3b1796883093be2aca63ec5e51df3dc14b9179be6f86f2675b3fa53 in SIGGEN_LOCKEDSIGS_t-corei7-64

The efitools:do_compile sig is computed to be c2e6dc60a7b8b2414b3761fe4966e031901144e3d32eed60bd580cc46e9b5358, but the sig is locked to 327fbae2aa4a419554ede6847fcc7c367da018e5e9d907a0051e68df5a5a2063 in SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_configure sig is computed to be 8a5cfb349fa84ca524bf680a922d0e1781f5dc9e0b5e0f6e0b135ea88e3f8fa1, but the sig is locked to 8d2bf2edd3194e44de0143088e68703c02a88032bb089ef0a4600f7528695362 in SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_compile sig is computed to be 819f7700a7f611335b8a5e4f8243623c4f01b187f197aa19cd034383af17b41b, but the sig is locked to 822db696400b5a788fbcc0e80f1fe242bd58cab992ff196efac191444d7b3b99 in SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_install sig is computed to be f2f8cb58b07a350eefd41af13e1156abd85659b1865dc278238277d9230e2e3f, but the sig is locked to 9e1ca795df7d73347f0efeeac54c24f1004d59011b97262207e1055f771ee95c in SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_populate_sysroot sig is computed to be ca8fe144be00929f3c42cb36b809a06b85d70c4f9fa1c0f6fd67b07af84d17a1, but the sig is locked to 2a41afd838cdac669dd99deefdc530c5d503329fb1fae2fb3641b490a2bbec8a in SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_package sig is computed to be 29a5daea524a219c5216b5d76447160d006e7db633e38c7d1ade6b599eb6c2ab, but the sig is locked to 2b2cef367c44399221b07f14facff9b1ae598ccc272c4b98ddfc4b08009fc090 in SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_configure sig is computed to be 613844241ce15b245abe2fb9306415616c72553e943183307b3496f85637345e, but the sig is locked to 68a818acd3281e28bd57efcd449a0bac0ffaa2733fcb02f6b28b2fe31d36e835 in SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_compile sig is computed to be 8b37e4a0e6ec0068b7dda0eccd1e32577daedf248f1c3e71f82f6454d3e4338d, but the sig is locked to 6f291a0f9ba59f355d9a88d646f72bf99a001f862b310e5e435e8b406632b6b4 in SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_install sig is computed to be 3a20f56cc04551f13378e9e596daa5eebc385ca965ebdf18adacfa7ef94c9018, but the sig is locked to 8fc761f8bf0215ea2fb9609037a5df0c7e2ad6dd9253555ea5f492b7068e7bff in SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_populate_sysroot sig is computed to be 97d2f34ef4b40fe8e324c04346ad0cdf22cde6cc774f336400797cb6a483d08c, but the sig is locked to 93700035bc1a42b4f7e5f05ef30d4bc6fdf2abc0dd1f707b2e745ceed25d5770 in SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_package sig is computed to be f59f3584026d4acf71d4300a18ff4bf05c0f3e3b42c2d5264af9be63820a0386, but the sig is locked to bdc6003bbd7a42a83e9a6a7ebe691e93a9744ae96c664d8656907a15af84be1c in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi-native:do_clean_grub sig is computed to be 17c62b3df5a57ee4cbd0e7abf1284a5d499ba4c814aaded564a24085b9fd326c, but the sig is locked to c8835ffb27e0d97b332dddad3fb83bdb849a267a8a0fa7142e66a76696c910ff in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_configure sig is computed to be a6dfb6cd633432b36b818b63fd6e06e086d189b62cd7fc6370c4e66e9668fa1d, but the sig is locked to 194602954bb4993b85397aeb06557d10ff14b15d52a321389cdbb0139d2ce34c in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_compile sig is computed to be 583800a58ca2e602d50b4e23485774e8b681f79bf48a1a854b71264a0ddcb733, but the sig is locked to e642b6c931bda1d51bc5394596cdacce7099875d1e873b39849607e03972c5b9 in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_mkimage sig is computed to be 87a6528cb8624851708b1f4d3fa26beb96f71f1a3cb0c4d48fe0aaf9255fb244, but the sig is locked to bc04f79c9988122be8297c3ea2e7aa13fbe18444b1151a547332112616e11480 in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_install sig is computed to be 6e8a988562949ae845beb0150acf7702a360094db56096b6e2bbb65820bbb3f0, but the sig is locked to 38427ff1c0bfa569a27a6c5acf51bb3483d882b18a1fa0bfbfaa371822df7837 in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_populate_sysroot sig is computed to be 3ba3744800732b69e71d33ea0db797a78bb2340727fc54f211bd0f7c1325374c, but the sig is locked to fcd9daa126de91d4d1de701ed1ff1c2774c3e42207e1fff85b86109eb54b290c in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi:do_clean_grub sig is computed to be 928fbd9c1d534333f18a6f751ad705c03f083ff00374a781b02e1aee47b92bee, but the sig is locked to 67a039367c0593803d8c70207f079fd8be28dbc6c548b13837fa7eb177b156e0 in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi-native:do_deploy sig is computed to be 4875f4b51c38f31140775a2a4457839eabef2529791cccbb9ed656eef63892fc, but the sig is locked to 6576c95aa5c0c7b505ca2cc02fdde3f678f2b039c2f0b57810b17694b6070a46 in SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi:do_configure sig is computed to be 84ab069273c4b2703ca4fa200d5fb66adcaffa39b8f36138339d4837b9281a9d, but the sig is locked to e8900241347d4616468e7a4a4c37b8496a1167c2b3d58f7bb55332da645bd7e0 in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_compile sig is computed to be 619bdca4f1a6df8c8c2c7ad49b7289af3477e3c76c00b84229584793f23fb115, but the sig is locked to 56ca563b3bcb66b72f53f51562f41dd0cf9af878335836e8fd6b6a07e32fa8bc in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_mkimage sig is computed to be f212bd74eb95f4d413c9867f853171747fe4fe86912138a0ac79234fe4be73b7, but the sig is locked to 80e9256f12e3070737c81f76310cc408473b92b877b23494cd1b4c2abdffd56d in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_install sig is computed to be 45753f50a553391bd80cf679039cccf879ef1eaca90e1dcfefb432621dfc0000, but the sig is locked to 3910d27330229314b793a94c7085c231a56c1073d7e79d4cceade5a373600252 in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_populate_sysroot sig is computed to be 3437833e837748a59e002f95773a8f61a715bb56c0f20671fa39a71556ad6d5d, but the sig is locked to d0d60bc1d9bf488c7568e592b3b1aeeb2e2796c9994f83fe1b781e0d006e432b in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_package sig is computed to be 81fa6cf23920cea4139ed3cefd6c94a3878580f6a45925279c7d75e3c487f162, but the sig is locked to d7ec82448f34ec8c0169f613fdd14237cebb1951efa3d35d53dc71d24f220cb8 in SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_deploy sig is computed to be f7831a1a7e1d8683e1c0c86fd32486ec8d9e5e713d63e39984aa36f50bff7f91, but the sig is locked to 1c781659fad7fb174716d05aa5727f68e710ad7c6593dc178f40866d6e868f19 in SIGGEN_LOCKEDSIGS_t-corei7-64

The tpm2-tools:do_configure sig is computed to be 10fa6cf0c4fa307a427978392ecf60d7a8853e11ca1747ea5ad8743fd42280f3, but the sig is locked to 5e6a2caa27901f95518467ca35b68043fee7802dfa8be39ae51e61c9eedf9a8d in SIGGEN_LOCKEDSIGS_t-corei7-64

The wolfssl:do_configure sig is computed to be 5569ddf9b10e2df9f5de456ca35b9baeb34a1f67617357d5e1a9264baf3d1e0e, but the sig is locked to eaf1b380210718071d8962eeccbd97efad180fabc750b18f4e98661de06ae11f in SIGGEN_LOCKEDSIGS_t-corei7-64

The crush:do_configure sig is computed to be f034116fd9598a09aa975e94dd48964e0d49deecf63d96c436bd4cccc7b68298, but the sig is locked to 64dfc5ff4a9ee29e9a20f1166ec2ee6fe20ffcd93e7618eabd02435c29f219ed in SIGGEN_LOCKEDSIGS_t-corei7-64

ERROR: Task quilt-native.do_fetch attempted to execute unexpectedly

 

 

 

 

 


Yocto Project Status WW08`21

Stephen Jolley
 

Current Dev Position: YP 3.3 M3 development

Next Deadline: 1st March 2021 YP 3.3 M3 build and YP 3.3 Feature Freeze

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.2.2 has passed QA cleanly and awaiting final release approval.
  • YP 3.1.6 has been built and is in QA.
  • We have one week left before M3 is due to be built. This marks our feature freeze point for YP 3.3.
  • We are trying to add rpm to reproducibility testing however there are several issues we need to resolve before that can merge.
  • Looking through some of the patches in the “Pending” state, we have some really old stale ones which really need decisions to be made about their future. It would help a lot if recipe maintainers could recipe recipe patchsets and upstream them or remove them if they are no longer relevant. 
  • The glibc 2.33 issues encountered should now hopefully be resolved with the latest pseudo changes.
  • Most of the successful AUH (Automatic Upgrade Helper) patches are now merged or queued however many of the failed upgrades have yet to be handled
  • Intermittent autobuilder issues continue to occur and are now at a record high level. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

 

Ways to contribute:

 

YP 3.3 Milestone Dates:

  • YP 3.3 M3 build date 2021/03/01
  • YP 3.3 M3 Release date 2021/03/12
  • YP 3.3 M4 build date 2021/04/05
  • YP 3.3 M4 Release date 2021/04/30

 

Planned upcoming dot releases:

  • YP 3.2.2 being reviewed for release.
  • YP 3.1.6 is in QA.
  • YP 3.2.3 build date 2021/03/15
  • YP 3.2.3 release date 2021/03/26
  • YP 3.1.7 build date 2021/03/29
  • YP 3.1.7 release date 2021/04/09

 

Tracking Metrics:

 

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

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: Trouble booting basic x86 image

Anuj Mittal
 

On Tue, 2021-02-23 at 01:01 -0800, Paul D. DeRocco wrote:
Yocto Gatesgarth, using meta-intel to build core-image-minimal
Intel D2700MUD mini-ITX mobo with D2700 Atom
Ordinary USB 2.0 flash drive

I followed the instructions in the meta-intel README, and had no
problems
building the intel-core2-32 and intel-corei7-64 machines, as well as
the
latter with an x32 tune. But whenever I try to boot any of them, I
get the
following stuff from the kernel:

usb 1-6: new high-speed USB device number 4 using ehci-pci
usb-storage 1-6:1.0: USB Mass Storage device detected
usb-storage 1-6:1.0:  Quirks match for vid 090c pid 1000: 400
scsi host4: usb-storage 1-6:1.0
scsi 4:0:0:0: Direct-Access     FLASH    Drive SM_USB20   1100 PQ: 0
ANSI: 4
sd 4:0:0:0: Attached scsi generic sg0 type 0
sd 4:0:0:0: [sda] 3932160 512-byte logical blocks: (2.01 GB/1.88 GiB)
sd 4:0:0:0: [sda] Write Protect is off
sd 4:0:0:0: [sda] No Caching mode page found
sd 4:0:0:0: [sda] Assume drive cache: write through
 sda:
sd 4:0:0:0: [sda] Attached SCSI removable disk
(countdown from 27 to 0)
Mounted filesystems
Available block devices
major minor  #blocks  name
   1        0       4096 ram0
    ... (others edited out)
   1       15       4096 ram15
   8        0    1966080 sda
Cannot find rootfs.img file in /run/media/* , dropping to a shell
It looks like you are using the live option in hddimg image? Can you
try adding "rootwait" to kernel parameters and see if that works?

Not sure why it's not dropping to shell, but may be try adding explicit
call to /bin/sh in meta/recipes-core/initrdscripts/files/init-live.sh
before this point to make sure the media is actually mounted at that
point.

Also, have you tried wic image to see if that works?

Thanks,

Anuj


Re: Kernel Header UAPI Issue

Mikko Rapeli
 

Hi,

On Tue, Feb 23, 2021 at 06:56:02AM -0800, Karthik Poduval wrote:
Hi Mikko,

Do you have an example on how you do that ? Do you bbapend the
linux-libc-headers recipe file ?
A kernel recipe will provide linux-libc-headers after a
"make headers_install" call...

So the SRC_URI of linux-libc-headers can be the same as from the
linux kernel recipe, or linux kernel recipe can provide (with some
tricks, possibly) the linux-libc-headers binary packages.

I have an application that uses dmabuf heap that potentially extends
across multiple BSP's as its BSP agnostic. I don't want to be patching
individual BSP recipes and generating headers. The issue I am facing
is due to backporting the patch from 5.6 to 5.4 so the required header
isn't a part of the linux-libc-headers.bb recipe. Best would have been
a virtual/kernel-keaders target that applications that require BSP
headers would add to their recipe DEPENDS. Why is this not a solved
issue by yocto project ? Why do individual BSP's need to deal with
this differently when the header install mechanism (make
headers_install) is the same irrespective of the type of BSP ?
I guess the reason is to split userspace to BSP/board specific and common
parts. It's not good if whole userspace bootstrap depends on kernel
recipe and any kernel changes requires full bootstrap and recompilation
of all userspace.

But there are BSP/board specific recipes which do need the real effective
kernel headers to interface with kernel drivers, and there are SoC
architecture specific ones which just need enough to build gcc and glibc.

Both have their pross and cons, and to me there is no clear winner.

Cheers,

-Mikko


Re: Kernel Header UAPI Issue

Karthik Poduval
 

Hi Mikko,

Do you have an example on how you do that ? Do you bbapend the
linux-libc-headers recipe file ?
I have an application that uses dmabuf heap that potentially extends
across multiple BSP's as its BSP agnostic. I don't want to be patching
individual BSP recipes and generating headers. The issue I am facing
is due to backporting the patch from 5.6 to 5.4 so the required header
isn't a part of the linux-libc-headers.bb recipe. Best would have been
a virtual/kernel-keaders target that applications that require BSP
headers would add to their recipe DEPENDS. Why is this not a solved
issue by yocto project ? Why do individual BSP's need to deal with
this differently when the header install mechanism (make
headers_install) is the same irrespective of the type of BSP ?

On Tue, Feb 23, 2021 at 5:18 AM <Mikko.Rapeli@bmw.de> wrote:

Hi,

I know it's not the best or recommended approach, but I find it
hard to avoid merging linux-libc-headers recipe with the actual
kernel recipe that a distro is using. At least a static copy
of some version of uapi headers from that kernel can be used
instead of the poky side linux-libc-headers. This helps to get
the actual BSP SW delivery headers into userspace, SDK etc.

Cheers,

-Mikko
--
Regards,
Karthik Poduval


Re: Updating Yocto

Mikko Rapeli
 

On Tue, Feb 23, 2021 at 09:24:47AM -0500, Claude Bing wrote:
I mentioned that we remove that directory, and it does indeed solve a
lot of problems. Not sure that it was clear from the original message,
but whenever we get a random error on the first build after the upgrade
we run a "bitbake -c cleanall" on that package, and everything works
great. The errors do not show up again.
Yes, we're talking about the same thing :)

A lot of yocto things don't work well if major changes happen and WORKDIR
isn't completely cleaned in between. With various BSP layers things
can be even worse and they may actively break both work directory and
sstate caches.

For any major changes in open source or other meta layers, I wipe build/tmp
completely to avoid random problems. In our CI this is the default.
Only download cache and sstate mirror are re-used between builds.
After this, I don't see many problems and build failures which are not
real bugs in either our changes or in upstream, e.g. race conditions
in build scripts.

Cheers,

-Mikko


Re: Updating Yocto

Claude Bing
 

On 2/23/21 7:58 AM, Mikko Rapeli wrote:
Hi,

On Mon, Feb 22, 2021 at 12:12:21PM -0500, Claude Bing wrote:
Hello all. My organization has been working with Yocto recently, and we
have noticed that there are often weird errors encountered after
updating revisions within a release branch (e.g., 3.1.3 -> 3.1.5). Is
there an accepted process to merging in upstream changes? Here is a
distillation of our workflow:

* Yocto releases 3.1.0 / dunfell

* Create a local tracking branch for the Yocto release
"sample-yocto-dunfell" based on upstream 3.1.0 tag / dunfell branch.
This is necessary because some of our local tooling is located in the
top level directory and it is a pain to copy the files each time.

* Create firmware with Yocto

* Yocto releases 3.1.x

* Merge upstream yocto-3.1.x tag into local tracking branch

* Create firmware with Yocto

Sometimes, after this last step, we encounter problems where patches
cannot be applied, or files cannot be found when bitbake tries to build
the recipes. We have tried deleting build/{tmp,sstate-cache} whenever we
merge upstream changes, but random errors still persist. For each of
these packages, if we run "bitbake -c cleanall", the error goes away.
When both yocto update and your own changes are modifying the same recipes,
then conflicts can occur.>
Most of the time, these recipes have not been extended in our project,
so they are purely meta-oe / meta packages.
If builds are failing, then your environment is breaking something.
It might even be the BSP layers that you use>
Are we doing something wrong, or is there a more acceptable way to
handle updates?

How tightly should meta-openembedded be tied to the core Yocto release?
I update all open source meta layers for every run of the update and also resolve
any issues by digging into details why the failure happened. I've done dunfell
updates with several BSP layers for multiple arm64 SoC's and have not seen
major issues.

What is useful and one of the best practices, is to clear the bitbake tmp
directory in between builds. Depending on details, there can be some cruft there
which fails when rebuilding.
I mentioned that we remove that directory, and it does indeed solve a
lot of problems. Not sure that it was clear from the original message,
but whenever we get a random error on the first build after the upgrade
we run a "bitbake -c cleanall" on that package, and everything works
great. The errors do not show up again.

Thanks for the reply.


Cheers,

-Mikko





Re: Kernel Header UAPI Issue

Mikko Rapeli
 

Hi,

I know it's not the best or recommended approach, but I find it
hard to avoid merging linux-libc-headers recipe with the actual
kernel recipe that a distro is using. At least a static copy
of some version of uapi headers from that kernel can be used
instead of the poky side linux-libc-headers. This helps to get
the actual BSP SW delivery headers into userspace, SDK etc.

Cheers,

-Mikko


Re: Updating Yocto

Mikko Rapeli
 

Hi,

On Mon, Feb 22, 2021 at 12:12:21PM -0500, Claude Bing wrote:
Hello all. My organization has been working with Yocto recently, and we
have noticed that there are often weird errors encountered after
updating revisions within a release branch (e.g., 3.1.3 -> 3.1.5). Is
there an accepted process to merging in upstream changes? Here is a
distillation of our workflow:

* Yocto releases 3.1.0 / dunfell

* Create a local tracking branch for the Yocto release
"sample-yocto-dunfell" based on upstream 3.1.0 tag / dunfell branch.
This is necessary because some of our local tooling is located in the
top level directory and it is a pain to copy the files each time.

* Create firmware with Yocto

* Yocto releases 3.1.x

* Merge upstream yocto-3.1.x tag into local tracking branch

* Create firmware with Yocto

Sometimes, after this last step, we encounter problems where patches
cannot be applied, or files cannot be found when bitbake tries to build
the recipes. We have tried deleting build/{tmp,sstate-cache} whenever we
merge upstream changes, but random errors still persist. For each of
these packages, if we run "bitbake -c cleanall", the error goes away.
When both yocto update and your own changes are modifying the same recipes,
then conflicts can occur.

Most of the time, these recipes have not been extended in our project,
so they are purely meta-oe / meta packages.
If builds are failing, then your environment is breaking something.
It might even be the BSP layers that you use.

Are we doing something wrong, or is there a more acceptable way to
handle updates?

How tightly should meta-openembedded be tied to the core Yocto release?
I update all open source meta layers for every run of the update and also resolve
any issues by digging into details why the failure happened. I've done dunfell
updates with several BSP layers for multiple arm64 SoC's and have not seen
major issues.

What is useful and one of the best practices, is to clear the bitbake tmp
directory in between builds. Depending on details, there can be some cruft there
which fails when rebuilding.

Cheers,

-Mikko


Re: [error-report-web][PATCH] report-error.bbclass: Add layer and bitbake version info to error report

Milan Shah
 

Hi All,

This has not been reviewed yet and it is given since January 6th.
Please review it and provide review comments if any as soon as possible to resolve this issue.

Thanks & Regards,
Milan Shah

Milan Shah | Software Engineer
a: MontaVista Software, LLC | Bangalore, India
e: info@... | w: www.mvista.com/
p: +91-80-4939-5000


On Mon, Feb 1, 2021 at 10:06 AM Milan Shah <mshah@...> wrote:
Hi All,

A gentle reminder to review this patch.

-----------------------
Thanks & Regards,
Milan Shah
MontaVista Software, Bangalore, India


On Mon, Jan 11, 2021 at 6:45 PM Milan Shah <mshah@...> wrote:
Hi All,

This is a Gentle Reminder to review this Patch.

-----------------------
Thanks & Regards,
Milan Shah
MontaVista Software, Bangalore, India


On Wed, Jan 6, 2021 at 7:09 PM Milan Shah <mshah@...> wrote:
Instead of just providing local.conf info, add layer names and their
revisions with bitbake version information into error report
makes it easier to understand and reproduce failed build.

[YOCTO #9700]

Signed-off-by: Milan Shah <mshah@...>
---
 meta/classes/report-error.bbclass | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/classes/report-error.bbclass b/meta/classes/report-error.bbclass
index 1a12db1..9cb6b0b 100644
--- a/meta/classes/report-error.bbclass
+++ b/meta/classes/report-error.bbclass
@@ -6,6 +6,8 @@
 #
 # Licensed under the MIT license, see COPYING.MIT for details

+inherit base
+
 ERR_REPORT_DIR ?= "${LOG_DIR}/error-report"

 def errorreport_getdata(e):
@@ -64,6 +66,8 @@ python errorreport_handler () {
             data['failures'] = []
             data['component'] = " ".join(e.getPkgs())
             data['branch_commit'] = str(base_detect_branch(e.data)) + ": " + str(base_detect_revision(e.data))
+            data['bitbake_version'] = e.data.getVar("BB_VERSION")
+            data['layer_version'] = get_layers_branch_rev(e.data)
             data['local_conf'] = get_conf_data(e, 'local.conf')
             data['auto_conf'] = get_conf_data(e, 'auto.conf')
             lock = bb.utils.lockfile(datafile + '.lock')
--
2.7.4


Trouble booting basic x86 image

Paul D. DeRocco
 

Yocto Gatesgarth, using meta-intel to build core-image-minimal
Intel D2700MUD mini-ITX mobo with D2700 Atom
Ordinary USB 2.0 flash drive

I followed the instructions in the meta-intel README, and had no problems
building the intel-core2-32 and intel-corei7-64 machines, as well as the
latter with an x32 tune. But whenever I try to boot any of them, I get the
following stuff from the kernel:

usb 1-6: new high-speed USB device number 4 using ehci-pci
usb-storage 1-6:1.0: USB Mass Storage device detected
usb-storage 1-6:1.0: Quirks match for vid 090c pid 1000: 400
scsi host4: usb-storage 1-6:1.0
scsi 4:0:0:0: Direct-Access FLASH Drive SM_USB20 1100 PQ: 0 ANSI: 4
sd 4:0:0:0: Attached scsi generic sg0 type 0
sd 4:0:0:0: [sda] 3932160 512-byte logical blocks: (2.01 GB/1.88 GiB)
sd 4:0:0:0: [sda] Write Protect is off
sd 4:0:0:0: [sda] No Caching mode page found
sd 4:0:0:0: [sda] Assume drive cache: write through
sda:
sd 4:0:0:0: [sda] Attached SCSI removable disk
(countdown from 27 to 0)
Mounted filesystems
Available block devices
major minor #blocks name
1 0 4096 ram0
... (others edited out)
1 15 4096 ram15
8 0 1966080 sda
Cannot find rootfs.img file in /run/media/* , dropping to a shell

At this point, it doesn't drop to a shell, but just sits there, responding
to keys by echoing them, so I have no way of investigating. Ctrl-Alt-Del
reboots.

Since there is no kernel serial output on this board, even though the kernel
command requests it, I videoed the startup, but didn't anything that looked
suspicious. I didn't see any message, though, about mounting anything in
/run/media.

As I've said, I've tried three different builds, totally generic except for
using the Intel BSP layer. I've tried two different USB drives. I've tried
it with EFI enabled and disabled in the BIOS. I've looked at the drive on
the PC, and the contents look normal. So why can't it find the rootfs.img
file, which is right there on sda, large as life? Anyone have any ideas what
I could be doing wrong?

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com


#toolchain #sdk #qt5 - compiler missing from from do_populate_sdk #toolchain #sdk #qt5

vitalEol
 

Hi,

We have a functioning image built for our device/platform based on Ti Processor SDK 04.03.00.05; at this point I'm trying to build an SDK for the image that I can distribute to other members of our development team to develop Qt5-based application for our platform. I want to build an SDK installer that includes additional Qt5 components which aren't included in the default Ti SDK like QtConnectivity and QtVirtualKeyboard.


I've tried several methods to build the SDK including: 
  • adding inherit populate_sdk populate_sdk_qt5 to my image recipe and running bitbake {image} -c populate_sdk
  • creating a new image recipe for the SDK with IMAGE_FEATURES += " dev-pkgs tools-sdk tools-debug eclipse-debug debug-tweaks"
  • building meta-toolchain-qt5

None of the resulting SDK installers appear to include the compiler, after sourcing the environment script I get the following:
micheal:buildData$ source /buildData/customToolchain/environment-setup-armv7ahf-neon-linux-gnueabi
micheal:buildData$ $CC
bash: arm-linux-gnueabihf-gcc: command not found
micheal:buildData$

I know that in the past I did manage to get a working SDK/Toolchain using one of the methods above though at the moment none seem to work for me.


Regards,
Evan


Re: [error-report-web][PATCH] parser: make contains_tag ignore non-str fields

Yi Fan Yu
 

RP,

if you want to get this merged too that would be great.

yifan


[error-report-web][PATCH] Update to be compatible with python3.5

Yi Fan Yu
 

mostly changed the way to access request.GET
also tested on python2.7 to be backward compatible

Signed-off-by: Yi Fan Yu <yifan.yu@windriver.com>
---
Post/parser.py | 2 +-
Post/views.py | 14 +++++++-------
2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/Post/parser.py b/Post/parser.py
index f54482a..f411e02 100644
--- a/Post/parser.py
+++ b/Post/parser.py
@@ -17,7 +17,7 @@ from django.core.urlresolvers import reverse
class Parser:

def __init__(self, data):
- self.data = data
+ self.data = data.decode('utf-8')

# returns true if the values contain '<' char
# Ignore the failures field (which is an array anyway)
diff --git a/Post/views.py b/Post/views.py
index cc6aed9..fe7100e 100644
--- a/Post/views.py
+++ b/Post/views.py
@@ -15,9 +15,9 @@ from django.shortcuts import HttpResponse, render
from django.views.decorators.csrf import csrf_exempt
from django.shortcuts import redirect
from Post.models import BuildFailure, Build, ErrorType
-from parser import Parser
+from Post.parser import Parser
from django.conf import settings
-from createStatistics import Statistics
+from Post.createStatistics import Statistics
from django.core.paginator import Paginator, EmptyPage
from django.core.exceptions import FieldError, ObjectDoesNotExist
from django.http import JsonResponse
@@ -65,12 +65,12 @@ def addData(request, return_json=False):
if return_json:
response = JsonResponse(result)
else:
- if not result.has_key('error'):
+ if not 'error' in result:
response = HttpResponse("Your entry can be found here: "+result['build_url'])
else:
response = HttpResponse(result['error'])

- if result.has_key('error'):
+ if 'error' in result:
response.status_code=500
else:
if return_json:
@@ -125,7 +125,7 @@ def search(request, mode=results_mode.LATEST, **kwargs):

items = BuildFailure.objects.all()

- if request.GET.has_key("limit"):
+ if "limit" in request.GET:
try:
n_limit = int(request.GET['limit'])
if n_limit > 0:
@@ -202,14 +202,14 @@ def search(request, mode=results_mode.LATEST, **kwargs):
],
}

- if request.GET.has_key("filter") and request.GET.has_key("type"):
+ if "filter" in request.GET and "type" in request.GET:
items = apply_filter(context, items, request.GET['type'], request.GET['filter'])
if mode == results_mode.SPECIAL_SUBMITTER and hasattr(settings,"SPECIAL_SUBMITTER"):
#Special submitter mode see settings.py to enable
name = settings.SPECIAL_SUBMITTER['name']
items = items.filter(BUILD__NAME__istartswith=name)

- elif mode == results_mode.SEARCH and request.GET.has_key("query"):
+ elif mode == results_mode.SEARCH and "query" in request.GET:
query = request.GET["query"]

items = items.filter(
--
2.25.1

1021 - 1040 of 53454