Date   

Re: #yocto #sdk #yocto #sdk

Monsees, Steven C (US)
 

Thanks again, these utilities make it much easier to understand and correct the issues...

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Tuesday, February 23, 2021 3:42 PM
To: Khem Raj <raj.khem@gmail.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.



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














Re: Dunfell, nodejs and typescript - short experience report

TRO
 

Hi Simon,
I'm dealing actually with the same problem. Would you like to share your  "configure in my own subclass"?

I'm also thinking there is a need for a bbclass which actually is not using gyp, instead it should be able to "npm run build".

There is alsa a patch for speeding up npm npmsw fetcher https://www.mail-archive.com/openembedded-core@.../msg142406.html
cheers Thomas


Yocto- Apache2 build guide

D, Sharmila <sharmila.d@...>
 

Hi,

I am trying to enable httpd package into my yocto build, steps I followed is as below

1. Added below layer in bblayer.conf file

sources/meta-openembedded/meta-webserver

2. Added below line in local.conf file

IMAGE_INSTALL_append = "apache2"

The yocto build using bitbake core-image-minimal gives below error

WARNING: core-image-minimal-1.0-r0 do_rootfs: busybox.postinst returned 1, marking as unpacked only, configuration required on target.
ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of ['busybox'] have failed. If the intention is to defer them to first boot,
then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.
Details of the failure are in /home/h440246/Projects/rfid/BSP/tisdk/build/arago-tmp-glibc/work/omapl138_lcdk-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
ERROR: core-image-minimal-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in: /home/h440246/Projects/rfid/BSP/tisdk/build/arago-tmp-glibc/work/omapl138_lcdk-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.2937
ERROR: Task (/home/h440246/Projects/rfid/BSP/tisdk/sources/oe-core/meta/recipes-core/images/core-image-minimal.bb:do_rootfs) failed with exit code '1'

Please provide the solution for the same

With Best Regards,

Sharmila D


Re: Trouble booting basic x86 image

Paul D. DeRocco
 

From: Mittal, Anuj [mailto:anuj.mittal@intel.com]

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 for the advice. I decided to try wic, since that's actually the x86
default if you don't set IMAGE_FSTYPES. It also looks cleaner than hddimg,
since it has a real ext4 partition and no loop mounting.

For the 32-bit build, it produced something my BIOS wouldn't recognize as
bootable, even though it looked fine in gparted. For the 64-bit build, it
booted part way, crashing on an illegal instruction in systemd. For the
64x32-build, it booted but failed trying to run /sbin/init with error -8
(invalid executable). When I look at the drive in Ubuntu, the properties on
that file say it's a link to /lib/systemd/systemd, which makes sense.
Strangely, though, it describes it as a shared library. objdump -f says:

/media/pauld/platform/sbin/init: file format elf32-x86-64
architecture: i386:x64-32, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x00024490

So still no joy. I'd rather get this wic version working than go back to the
hddimg version, but I'm not sure what to try next.

Ultimately, I'm just trying to get a vanilla reference build, so that when
the "real" system I'm creating doesn't work (which is often), I can compare
kernel configs, etc., to a known working system.

--

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


Re: Huawei e3372h & Quectel EG25-G LTE modems

Zoltan Kerenyi Nagy
 

I'm reading the Quectel dokumentation, and it say that a GobiNet driver should be included as well. But there is no Yocto recipe for that

--
Zolee


Re: Huawei e3372h & Quectel EG25-G LTE modems

Zoltan Kerenyi Nagy
 

Hi Khem,

There is no NetworkManager.conf file on the device. Shoudl I create one?


--
Zolee


Re: Kernel Header UAPI Issue

Karthik Poduval
 

Hi Bruce,

Thanks a lot for your patch (attached in bugzilla
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5305). I am
summarizing all steps once again for the benefit of anyone else who
faces the same issue (including myself in the future) and may use this
email list as a reference. The basic need was to export kernel headers
from kernel source for an application recipe (those headers are not a
part of linux-libc-headers recipe).

I applied the patch pointed by Bruce
https://bugzilla.yoctoproject.org/attachment.cgi?id=4647 to my local
BSP layer. The patch has 2 modes of operation (described in the patch
documentation).

mode1: To make this work I added the following lines to my application recipe.

inherit cmake kernel-alt-headers
DEPENDS = "gtest rsync-native"
EXTRA_OECMAKE =
'-DKERNEL_HEADER_DIR:STRING=${WORKDIR}/${KERNEL_ALT_HEADER_DIR}/include'
Then in my CMakeLists.txt.
include_directories(${KERNEL_HEADER_DIR})

The application compiled fine but there was one side effect that
kernel menuconfig (bitbake virtual/kernel -c menuconfig) wasn't able
to run as it complained that the source tree wasn't clean and make
mrproper was needed. This was resolved by a simple fix to the
do_compile_prepend in the patch (added the mrproper command).
do_compile_prepend() {
if [ "${KERNEL_SOURCE_IS_LOCAL}" = "False" ]; then
# install from the staging kernel directory
oe_runmake -C ${STAGING_KERNEL_DIR} headers_install
INSTALL_HDR_PATH=${WORKDIR}/${KERNEL_ALT_HEADER_DIR}
oe_runmake -C ${STAGING_KERNEL_DIR} mrproper
fi
}

mode2: To make this work I added the following line to my kernel recipe.
inherit kernel-alt-headers

to my application recipe following lines were added.
DEPENDS += "virtual/kernel"
EXTRA_OECMAKE =
'-DKERNEL_HEADER_DIR:STRING=${STAGING_DIR_TARGET}/usr/alt-headers/include'
Then in my CMakeLists.txt.
include_directories(${KERNEL_HEADER_DIR})

--
Regards,
Karthik Poduval

On Tue, Feb 23, 2021 at 10:50 AM Bruce Ashfield
<bruce.ashfield@gmail.com> wrote:

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


Re: Huawei e3372h & Quectel EG25-G LTE modems

Khem Raj
 


On Tue, Feb 23, 2021 at 10:22 PM Zoltan Kerenyi Nagy <kerenyi.nagy.zoltan@...> wrote:
Hi,

I have a barix ipam400 module, the development is done with Yocto. Recently I managed to modify and include the needed kernel modules into the kernel with Yocto.
However it still doesnt work. Both module work seemleslly and out of the box with a RaspberryPi, but not with this ipam400 modul. The kernel is 4.10.

The latest issue is that when I try to pull up an internet connection the error message is this:
device lo not available because device is strictly unmanage

These are the kernel module which I have included with bitbake -c menuconfig linux, they are all on the target device now:

what does NetworkManager.conf look like on the device ?
especially mark managed=true and see if that helps

 


Do you guys have any idea whats wrong with this setup. I've read the out-of-tree kernel module yocto dokumentation, I did my best and had many suggestions on the forum as well.

--
Zolee



Huawei e3372h & Quectel EG25-G LTE modems

Zoltan Kerenyi Nagy
 

Hi,

I have a barix ipam400 module, the development is done with Yocto. Recently I managed to modify and include the needed kernel modules into the kernel with Yocto.
However it still doesnt work. Both module work seemleslly and out of the box with a RaspberryPi, but not with this ipam400 modul. The kernel is 4.10.

The latest issue is that when I try to pull up an internet connection the error message is this:
device lo not available because device is strictly unmanage

These are the kernel module which I have included with bitbake -c menuconfig linux, they are all on the target device now:


Do you guys have any idea whats wrong with this setup. I've read the out-of-tree kernel module yocto dokumentation, I did my best and had many suggestions on the forum as well.

--
Zolee


Re: [opkg-devel] [opkg-utils PATCH v2] Makefile: separate manpages and utils install

Alex Stewart
 

Merged 1 commit to opkg-utils:master.

74ccbee0f798822041dba5c6564df62a0c60d86b

Thanks,

--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stewart@ni.com


[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

1041 - 1060 of 53484