Date   

Re: OE Linux & board-support-package

csimmonds
 

BSP is not a well defined term in embedded Linux. Back in the day, Montavista tried to popularise the term LSP, meaning Linux Support Package but it never caught on. These days, BSP generally means all the things you need to run a basic system. So that's bootloader, device tree, kernel config, kernel patches (if any), and firmware blobs. It can also include user space config such as video codecs, opengl libraries, and systemd units to start the respective daemons.

SoC and SoM vendors often overload their OE BSPs with irrelevant demo apps as well. Constant bugbear of system integrators.

HTH,
Chris


On 5 May 2022 10:51:39 BST, "jchludzinski via lists.yoctoproject.org" <jchludzinski=vivaldi.net@...> wrote:
OK, let me try this:

With other embedded OS's, the hardware specifics that are in the BSP are in the device trees in Linux. I assume the BSP's for OE Linux are rather simple?



On 2022-05-05 04:47, Josef Holzmayr wrote:
Howdy!

Am Do., 5. Mai 2022 um 10:43 Uhr schrieb jchludzinski via
lists.yoctoproject.org
<jchludzinski=vivaldi.net@...>:

OK, let's go with that.

I've watched the "Live Coding with Yocto Project #1: download and first
build" youtube video. Where is the BSP built in this procedure?

The BSP that is implicitly used in that video is the generic QEMU one,
which comes included with poky. Technically speaking, it lives in
https://git.yoctoproject.org/poky/tree/meta/conf/machine and
https://git.yoctoproject.org/poky/tree/meta/recipes-kernel/linux/linux-yocto_5.15.bb

A BSP can be many things, and this one is a rather small one, as
booting into and running linux on QEMU doesn't need patching and all
that, so in that case it comes pretty close to the perfect world that
Michael mentioned.

Greetz,
Josef (who did that video, actually)




On 2022-05-05 03:16, Michael Opdenacker via lists.yoctoproject.org
wrote:
On 5/5/22 08:39, jchludzinski via lists.yoctoproject.org wrote:
A board-support-package (BSP) is software that provides a layer of
abstraction from the physical board specifics for the host embedded OS
(e.g., VXworks).

I believe the device tree files (*.dts, *dtsi) in OE Linux provide the
same function. It allows to OE kernel code to be independent of device
specifics.


The Device Tree files are just descriptions of the hardware. In a
perfect world, you could indeed use the same mainline kernel to support
all possible devices. However, that kernel would be unnecessarily big
for your custom system. You most probably want to customize its
configuration, and may also need custom kernel drivers and patches.
There's also the need for a bootloader compiled for your platform.

That's why we need BSPs :-)

Cheers,
Michael.










Re: OE Linux & board-support-package

jchludzinski
 

OK, let me try this:

With other embedded OS's, the hardware specifics that are in the BSP are in the device trees in Linux. I assume the BSP's for OE Linux are rather simple?

On 2022-05-05 04:47, Josef Holzmayr wrote:
Howdy!
Am Do., 5. Mai 2022 um 10:43 Uhr schrieb jchludzinski via
lists.yoctoproject.org
<jchludzinski=vivaldi.net@...>:
OK, let's go with that.
I've watched the "Live Coding with Yocto Project #1: download and first
build" youtube video. Where is the BSP built in this procedure?
The BSP that is implicitly used in that video is the generic QEMU one,
which comes included with poky. Technically speaking, it lives in
https://git.yoctoproject.org/poky/tree/meta/conf/machine and
https://git.yoctoproject.org/poky/tree/meta/recipes-kernel/linux/linux-yocto_5.15.bb
A BSP can be many things, and this one is a rather small one, as
booting into and running linux on QEMU doesn't need patching and all
that, so in that case it comes pretty close to the perfect world that
Michael mentioned.
Greetz,
Josef (who did that video, actually)

On 2022-05-05 03:16, Michael Opdenacker via lists.yoctoproject.org
wrote:
On 5/5/22 08:39, jchludzinski via lists.yoctoproject.org wrote:
A board-support-package (BSP) is software that provides a layer of
abstraction from the physical board specifics for the host embedded OS
(e.g., VXworks).

I believe the device tree files (*.dts, *dtsi) in OE Linux provide the
same function. It allows to OE kernel code to be independent of device
specifics.

The Device Tree files are just descriptions of the hardware. In a
perfect world, you could indeed use the same mainline kernel to support
all possible devices. However, that kernel would be unnecessarily big
for your custom system. You most probably want to customize its
configuration, and may also need custom kernel drivers and patches.
There's also the need for a bootloader compiled for your platform.

That's why we need BSPs :-)

Cheers,
Michael.



Re: OE Linux & board-support-package

Josef Holzmayr
 

Howdy!

Am Do., 5. Mai 2022 um 10:43 Uhr schrieb jchludzinski via
lists.yoctoproject.org
<jchludzinski=vivaldi.net@...>:

OK, let's go with that.

I've watched the "Live Coding with Yocto Project #1: download and first
build" youtube video. Where is the BSP built in this procedure?
The BSP that is implicitly used in that video is the generic QEMU one,
which comes included with poky. Technically speaking, it lives in
https://git.yoctoproject.org/poky/tree/meta/conf/machine and
https://git.yoctoproject.org/poky/tree/meta/recipes-kernel/linux/linux-yocto_5.15.bb

A BSP can be many things, and this one is a rather small one, as
booting into and running linux on QEMU doesn't need patching and all
that, so in that case it comes pretty close to the perfect world that
Michael mentioned.

Greetz,
Josef (who did that video, actually)




On 2022-05-05 03:16, Michael Opdenacker via lists.yoctoproject.org
wrote:
On 5/5/22 08:39, jchludzinski via lists.yoctoproject.org wrote:
A board-support-package (BSP) is software that provides a layer of
abstraction from the physical board specifics for the host embedded OS
(e.g., VXworks).

I believe the device tree files (*.dts, *dtsi) in OE Linux provide the
same function. It allows to OE kernel code to be independent of device
specifics.

The Device Tree files are just descriptions of the hardware. In a
perfect world, you could indeed use the same mainline kernel to support
all possible devices. However, that kernel would be unnecessarily big
for your custom system. You most probably want to customize its
configuration, and may also need custom kernel drivers and patches.
There's also the need for a bootloader compiled for your platform.

That's why we need BSPs :-)

Cheers,
Michael.




Re: OE Linux & board-support-package

jchludzinski
 

OK, let's go with that.

I've watched the "Live Coding with Yocto Project #1: download and first build" youtube video. Where is the BSP built in this procedure?

On 2022-05-05 03:16, Michael Opdenacker via lists.yoctoproject.org wrote:
On 5/5/22 08:39, jchludzinski via lists.yoctoproject.org wrote:
A board-support-package (BSP) is software that provides a layer of
abstraction from the physical board specifics for the host embedded OS
(e.g., VXworks).
I believe the device tree files (*.dts, *dtsi) in OE Linux provide the
same function. It allows to OE kernel code to be independent of device
specifics.
The Device Tree files are just descriptions of the hardware. In a
perfect world, you could indeed use the same mainline kernel to support
all possible devices. However, that kernel would be unnecessarily big
for your custom system. You most probably want to customize its
configuration, and may also need custom kernel drivers and patches. 
There's also the need for a bootloader compiled for your platform.
That's why we need BSPs :-)
Cheers,
Michael.


Re: OE Linux & board-support-package

Michael Opdenacker
 

On 5/5/22 08:39, jchludzinski via lists.yoctoproject.org wrote:
A board-support-package (BSP) is software that provides a layer of
abstraction from the physical board specifics for the host embedded OS
(e.g., VXworks).

I believe the device tree files (*.dts, *dtsi) in OE Linux provide the
same function. It allows to OE kernel code to be independent of device
specifics.

The Device Tree files are just descriptions of the hardware. In a
perfect world, you could indeed use the same mainline kernel to support
all possible devices. However, that kernel would be unnecessarily big
for your custom system. You most probably want to customize its
configuration, and may also need custom kernel drivers and patches. 
There's also the need for a bootloader compiled for your platform.

That's why we need BSPs :-)

Cheers,
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: OE Linux & board-support-package

jchludzinski
 

A board-support-package (BSP) is software that provides a layer of abstraction from the physical board specifics for the host embedded OS (e.g., VXworks).

I believe the device tree files (*.dts, *dtsi) in OE Linux provide the same function. It allows to OE kernel code to be independent of device specifics.

On 2022-05-05 01:54, Zoran Stojsavljevic wrote:
Hello J,
Please, could you be more specific?
Thank you,
Zee
_______
On Thu, May 5, 2022 at 5:42 AM jchludzinski via lists.yoctoproject.org
<jchludzinski=vivaldi.net@...> wrote:
OE Linux uses device tree files (*.dts and *.dtsi files), so is there
any need for a board-support-package?


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

Richard Purdie
 

On Thu, 2022-05-05 at 01:15 +0000, Teoh, Jay Shen wrote:
Hi TSC,

Intel and WR are good for QA execution.
Shall we proceed?
Yes please, the TSC is concerned but doesn't believe there is much we can do
about these issues and that they shouldn't affect the release quality.

Cheers,

Richard


Re: OE Linux & board-support-package

Zoran
 

Hello J,

Please, could you be more specific?

Thank you,
Zee
_______


On Thu, May 5, 2022 at 5:42 AM jchludzinski via lists.yoctoproject.org
<jchludzinski=vivaldi.net@...> wrote:

OE Linux uses device tree files (*.dts and *.dtsi files), so is there
any need for a board-support-package?



OE Linux & board-support-package

jchludzinski
 

OE Linux uses device tree files (*.dts and *.dtsi files), so is there any need for a board-support-package?


[ANNOUNCEMENT] Yocto Project 3.1.16 (dunfell-23.0.16) is Released

Lee Chee Yang
 

Hello

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

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.16/poky-dunfell-23.0.16.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.16/poky-dunfell-23.0.16.tar.bz2

 

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

 

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

 

Full Test Report:

 

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

 

Thank you for everyone's contributions to this release.

 

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

Yocto Project Build and Release



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

yocto-3.1.16 Release Notes

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

 

 

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

Repositories/Downloads

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

 

Repository Name: poky

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

Branch: dunfell

Tag: yocto-3.1.16

Git Revision: f14992950eb90dc168eb82823ab69538f668f8bc

Release Artefact: poky-dunfell-23.0.16

sha: 67253123a6a23a772ca56823ce367fb7a42878af09380ab67deac80095d1aa27

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.16/poky-dunfell-23.0.16.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.16/poky-dunfell-23.0.16.tar.bz2

 

Repository Name: openembedded-core

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

Branch: dunfell

Tag: yocto-3.1.16

Git Revision: 8e81d38048c953d0823abf04d5b2506cd988f0bb

Release Artefact: oecore-dunfell-23.0.16

sha: 259c9605280ee4e3d57a402626e9f126e3fe5de38adc9a2f7f3815d14f24132e

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.16/oecore-dunfell-23.0.16.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.16/oecore-dunfell-23.0.16.tar.bz2

 

Repository Name: meta-mingw

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

Branch: dunfell

Tag: yocto-3.1.16

Git Revision: 524de686205b5d6736661d4532f5f98fee8589b7

Release Artefact: meta-mingw-dunfell-23.0.16

sha: 55c647dbb29abf0f2b9fefc2b8633e4a07fd6c04a4f7cb3fdb388560455f8572

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.16/meta-mingw-dunfell-23.0.16.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.16/meta-mingw-dunfell-23.0.16.tar.bz2

 

Repository Name: meta-gplv2

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

Branch: dunfell

Tag: yocto-3.1.16

Git Revision: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac

Release Artefact: meta-gplv2-dunfell-23.0.16

sha: 514360c9bbb769bf489f53e26f13aca96b24628db21372c66c543fb034366a6e

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.16/meta-gplv2-dunfell-23.0.16.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.16/meta-gplv2-dunfell-23.0.16.tar.bz2

 

Repository Name: bitbake

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

Branch: dunfell

Tag: yocto-3.1.16

Git Revision: 0784db7dd0fef6f0621ad8d74372f44e87fef950

Release Artefact: bitbake-dunfell-23.0.16

sha: f2eae8cb80c7d5c5d6b7a9b82ef649e9cb331e5b66e758e99649ff911bc68c84

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.16/bitbake-dunfell-23.0.16.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.16/bitbake-dunfell-23.0.16.tar.bz2

 

Repository Name: yocto-docs

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

Branch: dunfell

Tag: yocto-3.1.16

Git Revision: e8cf0e7290d07448af3b55dcd478e200a10cee42

 

 

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

Known Issues

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

N/A

 

 

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

Security Fixes

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

apt: fix CVE-2020-3810

bluez5: fix CVE-2021-3658 CVE-2022-0204

ghostscript: fix CVE-2020-15900 and CVE-2021-45949 for -native

ghostscript: fix CVE-2021-3781

git: Ignore CVE-2022-24975

go: fix CVE-2021-38297

grub: ignore CVE-2021-46705

gzip: fix CVE-2022-1271

libsolv: fix CVE: CVE-2021-44568-71 and CVE-2021-44573-77

libxml2: fix CVE-2022-23308 and regression

python3: ignore CVE-2022-26488

qemu: fix CVE-2020-13253 CVE-2020-13791

re2c: fix CVE-2018-21232

util-linux: fix CVE-2022-0563

xz: fix CVE-2022-1271

zlib: fix CVE-2018-25032

 

 

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

Fixes

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

 

apt: add -fno-strict-aliasing to CXXFLAGS to fix SHA256 bug

bind: update to 9.11.37

bitbake: fetch2: add check for empty SRC_URI hash string

bitbake: server/process: Disable gc around critical section

bitbake: server/process: Note when commands complete in logs

bitbake: tinfoil: Allow run_command not to wait on events

boost: fix native build with glibc-2.34

build-appliance-image: Update to dunfell head revision

conf.py/poky.yaml: Move version information to poky.yaml and read in conf.py

documentation: update for 3.1.15 release

documentation: update for 3.1.16 release

git update from 2.24.3 to 2.24.4

gnu-config: update SRC_URI

libxml2: move to gitlab.gnome.org

libxshmfence: Correct LICENSE to HPND

license_image.bbclass: close package.manifest file

linux-firmware: upgrade 20220310 -> 20220411

linux-yocto/5.4: update to v5.4.190

metadata_scm.bbclass: Use immediate expansion for the METADATA_* variables

mirrors: Add missing gitsm entries for yocto/oe mirrors

mobile-broadband-provider-info: upgrade 20210805 -> 20220315

oeqa/runtime/ping: Improve failure message to include more detail

oeqa/selftest/tinfoil: Fix intermittent event loss issue in test

oeqa/selftest/tinfoil: Improve tinfoil event test debugging

openssl: upgrade 1.1.1l -> 1.1.1n

poky.conf: Bump version for 3.1.16 release

poky: Drop PREMIRRORS entries for scms

pseudo: Add patch to workaround paths with crazy lengths

pseudo: Fix handling of absolute links

python3-jinja2: Correct HOMEPAGE

python3: upgrade 3.8.12 -> 3.8.13

python3targetconfig: Use for nativesdk too

tzdata: update to 2022a

u-boot: Correct the SRC_URI

vim: Upgrade 8.2.4524 -> 8.2.4681

virglrenderer: update SRC_URI

wireless-regdb: upgrade 2022.02.18 -> 2022.04.08

xserver-xorg: update to 1.20.14

 


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

Teoh, Jay Shen
 

Hi TSC,

Intel and WR are good for QA execution.
Shall we proceed?

Regards,
Jay

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Richard Purdie
Sent: Wednesday, 4 May, 2022 4:09 PM
To: qa-build-notification@...; yocto@...
Cc: Yocto TSC <tsc@...>; Mittal, Anuj
<anuj.mittal@...>; Elberger, Richard <elberger@...>
Subject: Re: [qa-build-notification] QA notification for completed autobuilder
build (yocto-3.4.4.rc1)

Hi TSC,

On Wed, 2022-05-04 at 02:32 +0000, Pokybuild User wrote:
A build flagged for QA (yocto-3.4.4.rc1) was completed on the autobuilder
and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.4.4.rc1
This build of 3.4.4 had some issues on the autobuilder:

* qemux86-64 ptest failure in lttng-tools - known issue
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14263
https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/3449
* logrotate in testimage failed on qemuarm64-armhost - known issue
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14686
https://autobuilder.yoctoproject.org/typhoon/#/builders/97/builds/4490
* meta-aws shows the warnings we used to see on master about
SRCREV_FORMAT:
https://autobuilder.yoctoproject.org/typhoon/#/builders/122/builds/1129
* alma8 perf working failure - same issue as dunfell, we need the same fix
https://autobuilder.yoctoproject.org/typhoon/#/builders/133/builds/120

I don't think any of these are blocking, just sad we have so many issues that
keep cropping up. Do we proceed to QA or retry? We have no known fix for
two of the above.

Cheers,

Richard





[PATCH yocto-autobuilder-helper v13] Add a banner on the old documentation docs. Script to add banners to the old docs and outdated dunfell docs

Abongwa Amahnui Bonalais <abongwabonalais@...>
 

Signed-off-by: Abongwa Bonalais Amahnui <abongwabonalais@...>
---
scripts/docs_add_banner.py | 104 +++++++++++++++++++++++++++++++++++++
scripts/run-docs-build | 2 +
2 files changed, 106 insertions(+)
create mode 100644 scripts/docs_add_banner.py

diff --git a/scripts/docs_add_banner.py b/scripts/docs_add_banner.py
new file mode 100644
index 0000000..4b65664
--- /dev/null
+++ b/scripts/docs_add_banner.py
@@ -0,0 +1,104 @@
+#!/usr/bin/env python3
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+#Signed-off-by: Abongwa Bonalais Amahnui <abongwabonalais@...>
+#
+#
+# Script to add banners to the old docs and outdated dunfell docs
+#
+#
+
+
+import os
+
+
+
+html_content_dunfell = '''
+<div id="outdated-warning">This document is outdated, you should select the <a href="https://docs.yoctoproject.org/dunfell">latest release version</a> in this series.</div>
+<div xml:lang="en" class="body" lang="en">
+'''
+html_content = '''
+<div id="outdated-warning">This version of the project is now considered obsolete, please select and use a <a href="https://docs.yoctoproject.org">more recent version</a>.</div>
+<div xml:lang="en" class="body" lang="en">
+'''
+
+# the class body and the last_div are used to make sure any .body property existing in any css file is not overwritten
+last_div = '''
+</div>
+
+'''
+
+css_replacement_content = '''
+
+ font-family: Verdana, Sans, sans-serif;
+
+ width: 100%;
+ margin: 0;
+ padding: 0;
+ color: #333;
+ overflow-x: hidden;
+ }
+
+.body{
+margin: 0 auto;
+min-width: 640px;
+padding: 0 5em 5em 5em;
+}
+#outdated-warning{
+text-align: center;
+background-color: rgb(255, 186, 186);
+color: rgb(106, 14, 14);
+padding: 0.5em 0;
+width: 100%;
+position: fixed;
+top: 0;
+
+
+'''
+
+def add_banner_old_docs(dir):
+ exclude = []
+ for root, dirs, filenames in os.walk(dir):
+ # exclude banner for 3.1.x upward as it is an LTS release and is still supported
+ exclude = [ name for name in os.listdir(dir) if name.startswith('3.1') ]
+ for d in dirs:
+ if d in exclude:
+ dirs.remove(d)
+ for filename in filenames:
+ if filename.endswith('.html'):
+ with open(os.path.join(root, filename), 'r', encoding="ISO-8859-1") as f:
+ current_content = f.read()
+ with open(os.path.join(root, filename), 'w') as f:
+ f.write(current_content.replace('<body>', '<body>' + html_content))
+ f.write(current_content.replace('</body>', last_div + '</body>'))
+ if filename.endswith('.css'):
+ with open(os.path.join(root, filename), 'r', encoding="ISO-8859-1") as f:
+ css_content = f.read()
+ with open(os.path.join(root, filename), 'w') as f:
+ f.write(css_content.replace(css_content[css_content.find('body {'):css_content.find('}'[0])], 'body {' + css_replacement_content ))
+add_banner_old_docs('.')
+
+
+
+
+def dunfell_docs(dir):
+ dunfell_banners = []
+ for root, dirs, filenames in os.walk(dir):
+ dunfell_banners = [ name for name in os.listdir(dir) if not name.startswith('3.1') ]
+ for d in dirs:
+ if d in dunfell_banners:
+ dirs.remove(d)
+ for filename in filenames:
+ if filename.endswith('.html'):
+ with open(os.path.join(root, filename), 'r', encoding="ISO-8859-1") as f:
+ current_content = f.read()
+ with open(os.path.join(root, filename), 'w') as f:
+ f.write(current_content.replace('<body>', '<body>' + html_content_dunfell))
+ f.write(current_content.replace('</body>', last_div + '</body>'))
+ if filename.endswith('.css'):
+ with open(os.path.join(root, filename), 'r', encoding="ISO-8859-1") as f:
+ css_content = f.read()
+ with open(os.path.join(root, filename), 'w') as f:
+ f.write(css_content.replace(css_content[css_content.find('body {'):css_content.find('}'[0])], 'body {' + css_replacement_content ))
+dunfell_docs('.')
\ No newline at end of file
diff --git a/scripts/run-docs-build b/scripts/run-docs-build
index ecc5332..307ac19 100755
--- a/scripts/run-docs-build
+++ b/scripts/run-docs-build
@@ -37,6 +37,8 @@ cd $outputdir
echo Extracing old content from archive
tar -xJf $docbookarchive

+$scriptdir/docs_fix_all_html_css.py
+
cd $bbdocs
mkdir $outputdir/bitbake

--
2.25.1


Re: Adding systemd to yocto

Edgar Mobile
 

Ok, that worked thanks everyone!


From: Scott Murray <scott.murray@...>
Sent: Tuesday, May 3, 2022 12:53 PM
To: Edgar Mobile <heideggm@...>
Cc: Yocto-mailing-list <yocto@...>
Subject: Re: [yocto] Adding systemd to yocto
 
On Tue, 3 May 2022, Edgar Mobile wrote:

> Apparently, this is not enough:
>
> bitbake core-image-weston
> /usr/lib/python3.6/importlib/_bootstrap.py:219: ImportWarning: can't resolve package from __spec__ or __package__, falling back on __name__ and __path__
>   return f(*args, **kwds)
> Loading cache: 100% |############################################| Time: 0:00:00
> Loaded 1472 entries from dependency cache.
> NOTE: Resolving any missing task queue dependencies
> ERROR: Nothing RPROVIDES 'pam' (but /media/user/SSD1TB/yoctoqemu/poky/meta/recipes-graphics/images/core-image-weston.bb RDEPENDS on or otherwise requires it)
> NOTE: Runtime target 'pam' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['pam']
> ERROR: Required build target 'core-image-weston' has no buildable providers.
> Missing or unbuildable dependency chain was: ['core-image-weston', 'pam']
>
> These are my current additions to local.conf:
>
> INIT_MANAGER="systemd"
> CORE_IMAGE_EXTRA_INSTALL += " mesa-demos gdb"
> IMAGE_INSTALL:append += " pam"

^ This line what is causing your error, remove it.  With pam in
DISTRO_FEATURES the required packages will get pulled in via dependencies.

> DISTRO_FEATURES:append = " systemd wayland pam x11"

If you specify INIT_MANAGER = "systemd", then you do not need to add
systemd here.

> VIRTUAL-RUNTIME_init_manager = "systemd"
> DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
> VIRTUAL-RUNTIME_initscripts = ""

Similarly, with INIT_MANAGER = "systemd" these 3 lines are not required.
If you look at meta/conf/distro/include/init-manager-systemd.inc you can
see what INIT_MANAGER = "systemd" tweaks.

> IMAGE_ROOTFS_EXTRA_SPACE = "38048576"
[snip]

Scott


Re: Failed to build kirkstone branch

Quentin Schulz
 

Hi Jupiter,

On 5/4/22 06:55, JH wrote:
I was able to build u-boot-imx-2021.04-r0 in honister branch, but
could not build it in kirkstone branch, here is the error message:
ERROR: u-boot-imx-2021.04-r0 do_fetch: Fetcher failure: Fetch command
export PSEUDO_DISABLED=1; export
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"; export
PATH="/build/KirkstoneRam/build/tmp-glibc/work/solar-oe-linux-gnueabi/u-boot-imx/2021.04-r0/recipe-sysroot-native/usr/bin/python3-native:/build/KirkstoneRam/oe-core/scripts:/build/KirkstoneRam/build/tmp-glibc/work/solar-oe-linux-gnueabi/u-boot-imx/2021.04-r0/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi:/build/KirkstoneRam/build/tmp-glibc/work/solar-oe-linux-gnueabi/u-boot-imx/2021.04-r0/recipe-sysroot/usr/bin/crossscripts:/build/KirkstoneRam/build/tmp-glibc/work/solar-oe-linux-gnueabi/u-boot-imx/2021.04-r0/recipe-sysroot-native/usr/sbin:/build/KirkstoneRam/build/tmp-glibc/work/solar-oe-linux-gnueabi/u-boot-imx/2021.04-r0/recipe-sysroot-native/usr/bin:/build/KirkstoneRam/build/tmp-glibc/work/solar-oe-linux-gnueabi/u-boot-imx/2021.04-r0/recipe-sysroot-native/sbin:/build/KirkstoneRam/build/tmp-glibc/work/solar-oe-linux-gnueabi/u-boot-imx/2021.04-r0/recipe-sysroot-native/bin:/build/KirkstoneRam/bitbake/bin:/build/KirkstoneRam/build/tmp-glibc/hosttools";
export HOME="/home/jupiter"; LANG=C git -c core.fsyncobjectfiles=0 -c
gc.autoDetach=false clone --bare --mirror
https://urldefense.proofpoint.com/v2/url?u=https-3A__source.codeaurora.org_external_imx_uboot-2Dimx.git&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=zR34sw-YnO57-Zac0PotHxM9ERTqYXBvVh5cWoolCog9tY7jCwNJUmq_3SahhlfR&s=J4bkX_EUta16oZ6Gq-nskMIou7CoiN-sXX1_sn_xZbo&e=
/build/KirkstoneRam/build/downloads/git2/source.codeaurora.org.external.imx.uboot-imx.git
--progress failed with exit code 128, no output
ERROR: u-boot-imx-2021.04-r0 do_fetch: Bitbake Fetcher Error:
FetchError('Unable to fetch URL from any source.',
'git://source.codeaurora.org/external/imx/uboot-imx.git;protocol=https;branch=lf_v2021.04')
I've had numerous issues in the past with codeaurora being down or extremely slow, so I wouldn't be surprised if that was a network blip of some kind. If it happens reliably in Yocto but never outside, let us know, then there might be something wrong somewhere.

I recommend to host a PREMIRRORS on your premises so that you don't rely on upstream websites being up.

Cheers,
Quentin


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

Richard Purdie
 

Hi TSC,

On Wed, 2022-05-04 at 02:32 +0000, Pokybuild User wrote:
A build flagged for QA (yocto-3.4.4.rc1) was completed on the autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.4.4.rc1
This build of 3.4.4 had some issues on the autobuilder:

* qemux86-64 ptest failure in lttng-tools - known issue
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14263
https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/3449
* logrotate in testimage failed on qemuarm64-armhost - known issue
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14686
https://autobuilder.yoctoproject.org/typhoon/#/builders/97/builds/4490
* meta-aws shows the warnings we used to see on master about SRCREV_FORMAT:
https://autobuilder.yoctoproject.org/typhoon/#/builders/122/builds/1129
* alma8 perf working failure - same issue as dunfell, we need the same fix
https://autobuilder.yoctoproject.org/typhoon/#/builders/133/builds/120

I don't think any of these are blocking, just sad we have so many issues that
keep cropping up. Do we proceed to QA or retry? We have no known fix for two of
the above.

Cheers,

Richard


Failed to build kirkstone branch

JH
 

I was able to build u-boot-imx-2021.04-r0 in honister branch, but
could not build it in kirkstone branch, here is the error message:

ERROR: u-boot-imx-2021.04-r0 do_fetch: Fetcher failure: Fetch command
export PSEUDO_DISABLED=1; export
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"; export
PATH="/build/KirkstoneRam/build/tmp-glibc/work/solar-oe-linux-gnueabi/u-boot-imx/2021.04-r0/recipe-sysroot-native/usr/bin/python3-native:/build/KirkstoneRam/oe-core/scripts:/build/KirkstoneRam/build/tmp-glibc/work/solar-oe-linux-gnueabi/u-boot-imx/2021.04-r0/recipe-sysroot-native/usr/bin/arm-oe-linux-gnueabi:/build/KirkstoneRam/build/tmp-glibc/work/solar-oe-linux-gnueabi/u-boot-imx/2021.04-r0/recipe-sysroot/usr/bin/crossscripts:/build/KirkstoneRam/build/tmp-glibc/work/solar-oe-linux-gnueabi/u-boot-imx/2021.04-r0/recipe-sysroot-native/usr/sbin:/build/KirkstoneRam/build/tmp-glibc/work/solar-oe-linux-gnueabi/u-boot-imx/2021.04-r0/recipe-sysroot-native/usr/bin:/build/KirkstoneRam/build/tmp-glibc/work/solar-oe-linux-gnueabi/u-boot-imx/2021.04-r0/recipe-sysroot-native/sbin:/build/KirkstoneRam/build/tmp-glibc/work/solar-oe-linux-gnueabi/u-boot-imx/2021.04-r0/recipe-sysroot-native/bin:/build/KirkstoneRam/bitbake/bin:/build/KirkstoneRam/build/tmp-glibc/hosttools";
export HOME="/home/jupiter"; LANG=C git -c core.fsyncobjectfiles=0 -c
gc.autoDetach=false clone --bare --mirror
https://source.codeaurora.org/external/imx/uboot-imx.git
/build/KirkstoneRam/build/downloads/git2/source.codeaurora.org.external.imx.uboot-imx.git
--progress failed with exit code 128, no output
ERROR: u-boot-imx-2021.04-r0 do_fetch: Bitbake Fetcher Error:
FetchError('Unable to fetch URL from any source.',
'git://source.codeaurora.org/external/imx/uboot-imx.git;protocol=https;branch=lf_v2021.04')

But I was able to run the same command manually git -c
core.fsyncobjectfiles=0 -c gc.autoDetach=false clone --bare --mirror
https://source.codeaurora.org/external/imx/uboot-imx.git.

What could I be missing?

Thank you very much.

jupiter


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

Pokybuild User <pokybuild@...>
 

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


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


Build hash information:

bitbake: c2d8f9b2137bd4a98eb0f51519493131773e7517
meta-agl: 8543843eeb47fa9b45786d3e09bf497fcd5f95e0
meta-arm: 2623e69db362b357db45c343e6d504909552c2d5
meta-aws: c92344938ab4d37de8bd8b799186dbbe3019a069
meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400
meta-intel: daf5c125a744d45d8fa395b576147edd5a714f5c
meta-mingw: f5d761cbd5c957e4405c5d40b0c236d263c916a8
meta-openembedded: 9a0caf5b09e14a28a54c3f8524d97530aeb8152c
meta-virtualization: bd7511c53b921c9ce4ba2fdb42778ca194ebc3e8
oecore: 1a6f5e27249afb6fb4d47c523b62b5dd2482a69d
poky: 780eeec8851950ee6ac07a2a398ba937206bd2e4



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


Re: [PATCH yocto-autobuilder-helper v12] Add a banner on the old documentation docs.

Abongwa Amahnui Bonalais <abongwabonalais@...>
 

Hi Quentin

On Tue, May 3, 2022 at 10:51 AM, Quentin Schulz wrote:
+
+
+
+def dunfell_tags(dir):
+ dunfell_banners = []
+ for root, dirs, filenames in os.walk(dir):
+ dunfell_banners = [ name for name in os.listdir(dir) if not name.startswith('3.1') ]
+ for d in dirs:
+ if d in dunfell_banners:
+ dirs.remove(d)
+
+ for filename in filenames:
+ if filename.endswith('.html'):
+ with open(os.path.join(root, filename), 'r', encoding="ISO-8859-1") as f:
+ current_content = f.read()
+ with open(os.path.join(root, filename), 'w') as f:
+ f.write(current_content.replace('<body>', '<body>' + html_content_dunfell))
+ f.write(current_content.replace('</body>', last_div + '</body>'))
+ if filename.endswith('.css'):
+ with open(os.path.join(root, filename), 'r', encoding="ISO-8859-1") as f:
+ css_content = f.read()
+ with open(os.path.join(root, filename), 'w') as f:
+ f.write(css_content.replace(css_content[css_content.find('body {'):css_content.find('}'[0])], 'body {' + css_replacement_content ))
+ print(dunfell_banners)
This is all extremely complex just for using a different variable depending on the name of the directory.
I wish to ask if your'e referring to the last line of code or this entire function, I have actuallly removed the print(dunfell_banners) line

Thanks a lot for reviewing.


Re: Maintaining ABI Compatibility for LTS branch

Richard Purdie
 

On Mon, 2022-05-02 at 17:44 -0400, Sinan Kaya wrote:
On 2/9/2022 4:38 PM, Richard Purdie wrote:
This probably does need a discussion on the architecture list and we need some
discussion and decisions about where/what buildhistory could/should do. Adding
this to buildhistory is all well and good but we don't have a meaningful
integration/monitoring of existing buildhistory issues in our
autobuilder/workflow today even before adding new things.
I was hoping for free cycles. I didn't get one. This will be an intern
project.

The way I'm thinking is to have the ABI compat XML be part of the state
cache tgz file and come up with a CVE check kind of hook maybe called
"ABI check" that will start flagging problems.

Would this be a better architecture?
I'm not sure it would.

Shared state works by computing inputs into a checksum and then using that
checksum to access the cache. Finding a "previous version" or a history to
compare to therefore isn't a good fit for it.

Buildhistory does fit much better but isn't scaling in a controlled way and I
think we need the architecture discussion and an agreed plan rather than trying
to tack things onto it. That does mean someone stepping back and considering the
various needs users have rather than just an isolated use case.

Cheers,

Richard


meta-selinux release for kirkstone #selinux

jared_terry@...
 

I'm not sure where to get a status on meta-selinux officially released branch with kirkstone support, I'm hoping this is the right place.  I see it has been added to main but is it planned to be branched anytime soon as a kirkstone branch?