Date   

Re: [External] Re: [yocto] Yocto- Apache2 build guide

Randy MacLeod
 

On 2021-02-24 10:37 p.m., D, Sharmila wrote:
Hi MacLeod,
Thanks for your e-mail.
Yes, without apach2 I am able to build the core-image-minimal successfully. The issue is only when I add apache2 in IMAGE_INSTALL.
I am using TI processor SDK and I have setup the arago based yocto environment based on TI user guide.
version is THUD.
Do you need any further details about the setup?
Please provide me the steps to include apache2 package into my final image.
Looking forward to hearing from you at your earliest convenience.
Hello Sharmila,

If you can reproduce the problem with only the oe-core/poly + meta-openembedded layers then perhaps someone on this list can help you.
Otherwise, you should contact the people who provided the
TI processor SDK.

By the way, Thud is EOL in the YP community:
https://wiki.yoctoproject.org/wiki/Releases
but commercial vendors do have longer support cycles
so hopefully TI can help you out.

../Randy
With Best Regards,
Sharmila D
-----Original Message-----
From: Randy MacLeod <randy.macleod@windriver.com>
Sent: Thursday, February 25, 2021 12:08 AM
To: D, Sharmila <Sharmila.D@Honeywell.com>; yocto@lists.yoctoproject.org
Subject: [External] Re: [yocto] Yocto- Apache2 build guide
On 2021-02-24 5:04 a.m., D, Sharmila via lists.yoctoproject.org wrote:
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/omapl
138_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-co
re/images/core-image-minimal.bb:do_rootfs)
failed with exit code '1'

Please provide the solution for the same
Hi Sharmila,
This doesn't appear to be related to adding apache.
Are you able to build core-image-minimal without adding apache2?
Can you provide detailed steps wrt what layers and HEAD commits for each layer you are using? Ideally, you'd reproduce on a supported release or on master. That's Dunfell/3.1 or later:
https://wiki.yoctoproject.org/wiki/Releases
../Randy


With Best Regards,

Sharmila D



--
# Randy MacLeod
# Wind River Linux

--
# Randy MacLeod
# Wind River Linux


Yocto Technical Team Minutes/Engineering Sync for Feb 23, 2021

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for Feb 23, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolley, Scott Murray, Armin Kuster, Michael
Halstead, Steve Sakoman, Richard Purdie, Randy MacLeod, Saul Wold, Jon
Mason, Joshua Watt, Paul Barker, Tim Orling, Mark Morton, John Kaldas,
Alejandro H, Ross Burton

== notes ==
- 3.2.2 passed QA clean, awaiting final approval from TSC
- 3.1.6 built and in QA
- 1 week before -m3 should be built (feature freeze for 3.3)
- adding RPM to reproducibility, still needs some work
- recipe maintainers: please review the patches we’re carrying (push
upstream as many as possible)
- glibc 2.33 issue should be resolved with latest pseudo
- AUH patches are now merged or queued, few of the failures handled
- AB issue list is at record high (not good)

== general ==
RP: can’t get stable test results out of AB on master


RP: would be nice to get RPM reproducibility issues ironed out, but there are
some epoch issues to work through which messes up diffoscope
RP: was surprised to see how bad the interactive response is on the cmdline on
the builders. it seems like an I/O bottleneck
Randy: mostly I/O to SSDs?
RP: i believe so
RP: it was immediately after a build had been started. so it could be related
to downloads or sstate fetching. how much sstate did you expect that build
to be reusing?
SteveS: version bumps to conman, kernel… yea that could lead to a lot of
rebuilds
Michael: we’ve been optimizing for throughput for a while. on some other
build systems we leave some overhead available for cmdline interactivity.
should we start to do that with the YP AB?
RP: i think it would have to be backed off by a significant amount to get that
breathing space. so maybe yes, but we’d have to look at it to see what
to backoff and by how much. looking through the build i see that 77% was
pulled from sstate (therefore pulling data off the NAS, then extracting
it).
Randy: and that’s not coordinated at all, if there are 100 items, then 100
threads?
RP: but limited by BB_THREADS
JPEW: run by buildbot? maybe we could use cgroups?
RP: i don’t think it’s CPU bound, the CPU was 50% idle when the cmdline
was very slow
MichaelH: sometimes we see that when the system isn’t healthy, i wonder if
it’s isolated to specific machines?
RP: on the CentOS machine, a command took over 5 minutes to complete. then
tried debian, same thing. then logged into the fedora machine and was
able to do stuff. but it didn’t seem isolated to any machines, it
seemed localized in time (i.e. right after a build had been started),
then dropped off. so i feel that it might be related to the initial build
startup, probably related to sstate pulling/extraction
Randy: could also limit I/O using cgroups
RP: we do use IOnice for parts of the build (2.1 and 2.7)
Michael: translation: class 2 priority 1; class 2 priority 7
Alejandro: are these sharing any hardware
RP: they’re all connected to the NAS
Michael: and they’re 100% dedicated to this work
RP: i don’t think this is a network bottleneck, i think this is sstate extraction
JPEW: maybe a different compression algorithm? gzip is notoriously slow
RP: wouldn’t that make it worse?
JPEW: does each AB have their own mirror
RP: it’s all done over NFS
JPEW: network bandwidth should be lower than local unzipping/extraction bandwidth?
Alejandro: could we try different I/O scheduling?
RP: don’t know

RP: had a look at patches. 1,300 patches in oe-core, ~600 in pending the rest
are submitted or not appropriate. some of these are 10 years or older,
do we still need them? i sent 2 upstream and was told it wasn’t needed
anymore (problem fixed in other ways). there’s also one in valgrind that
looks similar (different fix upstream) and not needed.
Ross: if some people could try to do 1 a day that would be a huge help
RP: lots of patches related to reproducibility
JPEW: the big issue with perf is that it uses bison (which needs patches)

PaulB: read-only mode for PR server. i’ve been working on it, but it’s 1
big patch. there’s code to handle daemonizing and forking which in hash
server is using the python mutli-processing. we also want to use the
same RPC mechanisms that python is using. are those good lines along which
to break the patches down?
RP: that sounds perfect
PaulB: it was easier to bash on it all together, then go back and break it up
into digestible chunks
RP: it’s 10 year old code, so i’m not surprised
PaulB: i’ve broken out a part that uses JSON RPC, then use that for the
server
RP: sounds good to me
JPEW: me too
RP: scaling that code under python2 was a challenge. glad to see this moving
forward

RP: Randy posted rust patch set. felt it couldn’t be merged in this form
(too many patches)
Randy: do you want the history squashed?
RP: that was my feeling
Randy: i’ve been working on it bit by bit as stuff happens upstream which
leads to lots of little commits. but i can reorg by logical group and
squash the log
RP: yes. in one case there were lots of commits to the rust version, then in
the end you end up with 2
Randy: someone from MS worked on getting the sdk stuff working
RP: given that next Monday is the feature freeze, let’s get the patched out
sooner, and worry about the sdk later
Randy: ok. last remaining issue is the pre-fetcher but i don’t know much
about it. looked at PaulB’s patches
PaulB: there are 3 methods floating around, i’ve focused on one of them that
i like
1. doing the download ahead of time in do_fetch()
2. let rust-bin do the downloads itself in do_compile() which i don’t like
3. haven’t looked at the last one yet
PaulB: i like 1 because it asks rust to output a cargo which the fetcher can
then act on
Randy: doesn’t rely on crates?
PaulB: i think it relies on crates for things that it can’t resolve. however
Andreas’ approach relies on getting bitbake to understand cargo-toml
file, not sure if that’s a good approach
Randy: are there any lessons with Go that we can use?
Scott: Bruce would be a good one to talk to
PaulB: my understanding with Go is that the code tends to all be placed
together in the git repository, so the fetch side is a little simpler
Randy: so given the approach we’re using is there anything that needs to be
added
PaulB: it needs testing
Randy: i have a team working on testing the rust compiler itself. they can
successfully execute 2/3 of the tests now (of which 99.9% pass). i have
a reproducibility test for rust hello world, but it takes a long time to
run. any tests you’re thinking of?
PaulB: fetcher tests. if you have a “crate://” in a URL, just making sure
it gets translated correctly to make sure it doesn’t bitrot
Randy: is that an -m3 or -m4 activity
RP: if we’ll get it in -m4 for sure we can wait until then. in oe-core
we’d want some sort of hello world (make sure compiler works and we can
run the binaries)
Randy: we have that already
RP: both for cross-compiling and target. then reproducibility tests. i’m
happy to build them up, as long as there’s a roadmap. for -m3 i think we
should get the baseline rust set and the crate fetcher
PaulB: crate fetcher overrides the wget fetcher and makes sure everything gets
put in the right place. so it just needs a couple test cases; a map of
inputs to outputs. i’ll resubmit the patch and include a list of tests
that we need to add
RP: if someone could reply to Andreas and let him know what’s going on and
why we’re going in a slightly different direction than the work he’s
submitted
PaulB: the fundamental unit is the recipe. devtool is the place for some of
the functionality not bitbake
Randy: building rust hello world works for all glibc qemu targets but some
breakage with musl (risc-v and powerpc) i think Khem is working on the
risc-v one. will that hold things up?
RP: no
PaulB: i have some slightly larger rust packages (larger than hello world)
that i think will test things a little more thoroughly, e.g. ripgrep
Randy: we’re testing that one already. should we add it to oe-core?
RP: it would be good to have something in oe-core to do testing
Randy: i think hello world would be good enough for oe-core and leave larger
tests for other layers
PaulB: there are rust things in oe-core (librsvg, etc) so i think oe-core will
have good test things already in them without having to add recipes just
for testing’s sake
Randy: things also seem to work well on ARM builders
Ross: yes, things are on-target

TrevorW: started work on 2021 YP conference. conversation moved to
conferences@lists.yoctoproject.org if you want to follow along or help

RP: fetch, workdir, can’t clean up workdir, config changes but can’t
cleanup. maybe we should fetch to a special dir and then just symlink
PaulB: would it be recipe-specific
RP: yes, it would be under $WORKDIR
PaulB: would make the archiver easier
TimO: there are a number of Go modules that don’t cleanup properly so maybe
this would help
ScottM: there are lots recipes that do post-processing on files in $WORKDIR
before moving them to the artifacts directory, so there could be breakage
there
PaulB: can we do it first thing next release
RP: we’ll give it a try and see
TrevorW: i think a lot of BSP layers will be affected
RP: i think there’s a lot of chance a lot of things (not just BSPs) will be
affected
ScottM: there are some BSP things that will be affected, but in AGL we’re
doing a lot of $WORKDIR manipulations that aren’t necessarily BSP
related as well
(several): overall it sounds like a good idea and a good cleanup to try


Re: BB_HASHBASE_WHITELIST

Monsees, Steven C (US)
 

Thanks, will try it out...

-----Original Message-----
From: Quentin Schulz <quentin.schulz@streamunlimited.com>
Sent: Thursday, February 25, 2021 8:42 AM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] BB_HASHBASE_WHITELIST

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.


On Thu, Feb 25, 2021 at 01:37:18PM +0000, Monsees, Steven C (US) via lists.yoctoproject.org wrote:

Where and when is it appropriate to add to/modify BB_HASHBASE_WHITELIST " ?

I tried to do : BB_HASHBASE_WHITELIST += "BB_TRACE" in my local.conf but it ended up replacing existing list with just "BB_TRACE"...
In local.conf, one usually wants to use _append instead of += since local.conf is parsed pretty early, += will override current values set with ?= or ??=. It might also be overridden if = is used in recipes/conf files.

Cheers,
Quentin
--
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
Fax: +43 1 667 20 02 4401
quentin.schulz@streamunlimited.com, www.streamunlimited.com


Re: BB_HASHBASE_WHITELIST

Quentin Schulz
 

On Thu, Feb 25, 2021 at 01:37:18PM +0000, Monsees, Steven C (US) via lists.yoctoproject.org wrote:

Where and when is it appropriate to add to/modify BB_HASHBASE_WHITELIST " ?

I tried to do : BB_HASHBASE_WHITELIST += "BB_TRACE" in my local.conf but it ended up replacing existing list with just "BB_TRACE"...
In local.conf, one usually wants to use _append instead of += since
local.conf is parsed pretty early, += will override current values set
with ?= or ??=. It might also be overridden if = is used in recipes/conf
files.

Cheers,
Quentin
--
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
Fax: +43 1 667 20 02 4401
quentin.schulz@streamunlimited.com, www.streamunlimited.com


BB_HASHBASE_WHITELIST

Monsees, Steven C (US)
 

 

Where and when is it appropriate to add to/modify BB_HASHBASE_WHITELIST “ ?

 

I tried to do : BB_HASHBASE_WHITELIST += “BB_TRACE” in my local.conf but it ended up replacing existing list with just “BB_TRACE”…

 

 

basewhitelist changed from '{'TERM', 'FILESPATH', 'CCACHE', 'COREBASE', 'BBPATH', 'STAMPS_DIR', 'EXTERNAL_TOOLCHAIN', 'LOGNAME', 'FILESEXTRAPATHS', 'CCACHE_NOHASHDIR', 'LICENSE_PATH', 'BB_WORKERCONTEXT', 'BB_HASHSERVE', 'BB_UNIHASH', 'HOME', 'DL_DIR', 'SSTATE_HASHEQUIV_OWNER', 'PRSERV_DUMPDIR', 'SDKPKGSUFFIX', 'WORKDIR', 'SSTATE_PKGARCH', 'SSTATE_HASHEQUIV_METHOD', 'PRSERV_HOST', 'CCACHE_DIR', 'PRSERV_LOCKDOWN', 'STAGING_DIR_TARGET', 'STAGING_DIR_HOST', 'PWD', 'USER', 'STAMPCLEAN', 'BUILD_ARCH', 'BBSERVER', 'BB_LIMITEDDEPS', 'SSTATE_HASHEQUIV_REPORT_TASKDATA', 'TMPDIR', 'SHELL', 'THISDIR', 'DEPLOY_DIR', 'PRSERV_DUMPFILE', 'ERROR_QA', 'WARN_QA', 'FILE_DIRNAME', 'extend_recipe_sysroot', 'CCACHE_TOP_DIR', 'PARALLEL_MAKE', 'FILE', 'BB_TASKHASH', 'PATH', 'SSTATE_DIR', 'PKGDATA_DIR'}' to '{'BB_TRACE'}'

changed items: {'TERM', 'FILESPATH', 'CCACHE', 'COREBASE', 'BBPATH', 'STAMPS_DIR', 'EXTERNAL_TOOLCHAIN', 'LOGNAME', 'FILESEXTRAPATHS', 'CCACHE_NOHASHDIR', 'BB_WORKERCONTEXT', 'LICENSE_PATH', 'BB_UNIHASH', 'BB_HASHSERVE', 'HOME', 'DL_DIR', 'SSTATE_HASHEQUIV_OWNER', 'PRSERV_DUMPDIR', 'PATH', 'WORKDIR', 'SSTATE_PKGARCH', 'SSTATE_HASHEQUIV_METHOD', 'SSTATE_DIR', 'PRSERV_HOST', 'CCACHE_DIR', 'STAGING_DIR_TARGET', 'STAGING_DIR_HOST', 'PWD', 'USER', 'STAMPCLEAN', 'BUILD_ARCH', 'BBSERVER', 'BB_LIMITEDDEPS', 'SSTATE_HASHEQUIV_REPORT_TASKDATA', 'TMPDIR', 'SHELL', 'THISDIR', 'DEPLOY_DIR', 'BB_TRACE', 'PRSERV_DUMPFILE', 'ERROR_QA', 'WARN_QA', 'FILE_DIRNAME', 'extend_recipe_sysroot', 'CCACHE_TOP_DIR', 'PARALLEL_MAKE', 'FILE', 'BB_TASKHASH', 'SDKPKGSUFFIX', 'PRSERV_LOCKDOWN', 'PKGDATA_DIR'}

 

Thanks,

Steve


Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.6.rc1)

Sangeeta Jain
 

Hi all,

This is the full report for yocto-3.1.6.rc1:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.

no new issue found

Thanks,
Sangeeta

-----Original Message-----
From: qa-build-notification@lists.yoctoproject.org <qa-build-
notification@lists.yoctoproject.org> On Behalf Of Pokybuild User
Sent: Tuesday, 23 February, 2021 6:48 AM
To: yocto@lists.yoctoproject.org
Cc: qa-build-notification@lists.yoctoproject.org
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.1.6.rc1)


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


https://autobuilder.yocto.io/pub/releases/yocto-3.1.6.rc1


Build hash information:

bitbake: fa94374baea75a94e3a488126ca7d8e241a77acd
meta-arm: 02c660521619ddb7a9495d65403aaa2636747ce8
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 4bd62a7e154b8c9e8a114f452d3b062d8d058118
meta-kernel: f793168bd19af3d8c5a260dd35f387ed9a31794b
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: a8debddd6cbdd70db74e096d72f97fbee008ee63
poky: a13bda44fcda4e79e9aed39ca1495eabecb6a7b7



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@linuxfoundation.org







Re: Yocto- Apache2 build guide

Randy MacLeod
 

On 2021-02-24 5:04 a.m., D, Sharmila via lists.yoctoproject.org wrote:
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
Hi Sharmila,

This doesn't appear to be related to adding apache.
Are you able to build core-image-minimal without adding apache2?

Can you provide detailed steps wrt what layers and HEAD commits for each layer you are using? Ideally, you'd reproduce on a supported release or
on master. That's Dunfell/3.1 or later:
https://wiki.yoctoproject.org/wiki/Releases

../Randy

With Best Regards,
Sharmila D

--
# Randy MacLeod
# Wind River Linux


Re: [meta-security] [PATCH V2 0/8] Some fixes for IMA/EVM

Armin Kuster
 

merged

On 2/20/21 4:18 AM, liu.ming50@gmail.com wrote:
From: Ming Liu <liu.ming50@gmail.com>

Changes in patch set V2:

1 Split patches as suggested by Dmitry Baryshkov.

Ming Liu (8):
ima-evm-utils: set native REQUIRED_DISTRO_FEATURES to empty
initramfs-framework-ima: fix a wrong path
ima-evm-keys: add recipe
initramfs-framework-ima: RDEPENDS on ima-evm-keys
meta: refactor IMA/EVM sign rootfs
README.md: update according to the refactoring in
ima-evm-rootfs.bbclass
initramfs-framework-ima: let ima_enabled return 0
ima-evm-rootfs.bbclass: avoid generating /etc/fstab for wic

meta-integrity/README.md | 4 ++-
meta-integrity/classes/ima-evm-rootfs.bbclass | 33 +++++++++----------
.../initrdscripts/initramfs-framework-ima.bb | 2 +-
.../initrdscripts/initramfs-framework-ima/ima | 3 +-
.../ima-evm-keys/ima-evm-keys_1.0.bb | 16 +++++++++
.../ima-evm-utils/ima-evm-utils_git.bb | 1 +
6 files changed, 38 insertions(+), 21 deletions(-)
create mode 100644 meta-integrity/recipes-security/ima-evm-keys/ima-evm-keys_1.0.bb


Multi-planar API support in g_webcam

Sheraz Ali
 

Hi All,

I wanted to know whether g_webcam supports multi-planar API.

--
Thanks and Regards
Sheraz Ali Shah


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

1761 - 1780 of 54213