Re: [OE-core] [qa-build-notification] QA notification for completed autobuilder build (yocto-4.3_M3.rc1)

[Jing Hui Tham]

Hi all,
 
Intel and WR YP QA is planning for QA execution for YP build yocto-4.3_M3.rc1. 
We are planning to execute following tests for this cycle:
 
OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw
 
Runtime auto test for following platforms:
1. MinnowBoard Turbot - 32bit
2. Kaby Lake (7th Generation Intel(r) Core(tm) Processors)
3. Tiger Lake (11th Generation Intel(r) Core(tm) Processors)
4. Alder Lake-S (12th Generation Intel(r) Core(tm) Processors)
5. Raptor Lake-P (13th Generation Intel(r) Core(tm) Processors)
6. Beaglebone

 
ETA for completion Thursday, 14 September.
 
Best regards,
Jing Hui


> -Original Message-
> From: qa-build-notificat...@lists.yoctoproject.org  notificat...@lists.yoctoproject.org> On Behalf Of Pokybuild User
> Sent: Sunday, September 10, 2023 8:55 PM
> To: yo...@lists.yoctoproject.org
> Cc: qa-build-notificat...@lists.yoctoproject.org
> Subject: [qa-build-notification] QA notification for completed autobuilder
> build (yocto-4.3_M3.rc1)
> 
> 
> A build flagged for QA (yocto-4.3_M3.rc1) was completed on the
> autobuilder and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-4.3_M3.rc1
> 
> 
> Build hash information:
> 
> bitbake: 033896da8daaff69df3c2adb4ad5fee29121e831
> meta-agl: e654a050a3a2f2e780b35f90e6be7a453bb0c305
> meta-arm: a262d308e78b9ad5c0f92c77714c7a354c5ddcfb
> meta-aws: 3095240fb84be8fc78facdd2cdb91f77abf4e62d
> meta-intel: 0ccbd5e710b827a1cc73acf0ac75c395edc57b59
> meta-mingw: 65ef95a74f6ae815f63f636ed53e140a26a014ce
> meta-openembedded: 7554afa9b38c12a066b5970e18c1a7d60584f47e
> meta-virtualization: 113af45b75d2a19726d3e084e9ba05826128097b
> oecore: 03d37854b1dacbecd2c522821c59ef01d9bd305c
> poky: 61531cd3956c56644fc1c4cc77f130e60db1a771
> 
> 
> 
> This is an automated message from the Yocto Project Autobuilder
> Git: git://git.yoctoproject.org/yocto-autobuilder2
> Email: richard.pur...@linuxfoundation.org
> 
> 
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187475): 
https://lists.openembedded.org/g/openembedded-core/message/187475
Mute This Topic: https://lists.openembedded.org/mt/101285641/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/3] linux/generate-cve-exclusions: fix mishandling of boundary values

[Yuta Hayama]

On 2023/09/08 19:57, Ross Burton via lists.openembedded.org wrote:
> On 6 Sep 2023, at 13:30, Ross Burton via lists.openembedded.org 
>  wrote:
 On 5 Sep 2023, at 08:29, Yuta Hayama  wrote:
>
> affected_versions in kernel_cves.json does not mean "first affected 
> version
> to last affected version" but actually "first affected version to fixed
> version". Therefore, the variable names, conditional expressions, and
> CVE_STATUS descriptions should be fixed.

 I’m happy to believe you on this, but do you have a source?
>>>
>>> Unfortunately, I have not found any official explanation for this. All I 
>>> know
>>> is what I wrote in the following message. And that is what I have been able 
>>> to
>>> confirm empirically.
>>>
>>> https://lists.openembedded.org/g/openembedded-core/message/186994
>>
>> Based on that evidence you appear to be right, yes.  I’ve just mailed the 
>> maintainer of the JSON to see if he’d like to make a statement either way.
> 
> I got a reply:
> 
> "The code takes the breaking_cmt to fixing_cmt. So it would be First Affected 
> version to First Fixed version in the mainline.”
> 
> Yes, you’re correct.

Thank you, Ross.
I am relieved to hear that I was not mistaken.

Also, thank you to the maintainers for applying the patch to the master.


Yuta Hayama

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187474): 
https://lists.openembedded.org/g/openembedded-core/message/187474
Mute This Topic: https://lists.openembedded.org/mt/101164830/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [langdale][kirkstone][PATCH] go-mod.bbclass: Allow network in do_compile

[Martin Jansa]

On Sun, Mar 12, 2023 at 10:15 AM Martin Jansa via lists.openembedded.org
 wrote:

> On Tue, Jan 3, 2023 at 5:03 PM Lukas Funke <
> lukas.funke-...@weidmueller.com> wrote:
>
>> Martin,
>>
>> first of all: thank you for testing the patches. As usual the corner
>> cases are the most tricky ones.
>>
>> tl;dr: I'm working on an updated patch series to address the reported
>> issues.
>>
>
> Hi Lukas, Stefan,
>
> and update on this series?
>
> It doesn't have to be perfect, other people can help with remaining corner
> cases and right now there is nothing for this in oe-core, so any version
> will be big improvement :) and it will make it easier for others to submit
> incremental improvements - I have some as well, but haven't sent them as I
> don't know what you've already updated locally, so I'm waiting for v2.
>
> Mickledore is already in feature freeze, but maybe RP will make an
> exception as this is new important functionality which isn't likely to
> break other existing code.
>

Hello Lukas,

any progress on updated patch series? Nanbield release is near and I don't
remember seeing the updated patch series in last couple months.

Is there anything I can do to help? The last version looked reasonably well
and IMHO could be used as starting point for everybody to help fixing those
corner cases where it didn't work well.

Regards,


> Kind Regards,
>
>
> I've looked into the issues and would like to give some explanation.
>>
>> 1) the first module you mention ('gonum.org/v1/gonum
>> ') does not obey the go documentation for
>> resolving the modules source-code repository (see
>> https://go.dev/ref/mod#go-mod-download , Section 'Version control
>> systems'). The documentation states that there should be a html page,
>> queried by "?go-get=1", with a -tag which contains the original
>> URL to the source-code repository. For 'gonum' there is only a 404-page.
>> This page contains javascript-code that redirects to the actual gonum
>> package page. Unnecessary hard to process. I'll open an issue for that.
>> The second module 'code.cloudfoundry.org/clock
>> ' has a broken certificate. I
>> already opend an issue on github for this.
>>
>> I addressed this issue above by maintaining a list of modules and their
>> actual repo URLs inside the go-recipetool as an absolute fallback. Would
>> do you think about this solution?
>>
>
> Yes, that's what I was starting to do in:
>
> https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/go=b973c7f17c8a613233a1a18de0bf6daa352c47d8
>
> https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/go=61c6c9962b3b7d4c1cf6e6823de6c32b09998b00
>
>
>> 2) yes, my bad :)
>>
>
> as work around I was using
>
> https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/go=5767819bfe96de29ab751d4a37a431a324f7e547
>
>
> 3) The problem is that some repositories have a prefix in their tags.
>> The tags usually only contain the semantic version string. I'm curretly
>> working on this issue.
>>
>> Best regards
>>
>> Lukas
>>
>> Am 22.12.2022 um 20:08 schrieb Martin Jansa via lists.openembedded.org:
>> > On Thu, Dec 22, 2022 at 7:39 PM Vyacheslav Yurkov 
>> > wrote:
>> >
>> > On 22.12.2022 17:48, Bruce Ashfield wrote:
>> > > On Thu, Dec 22, 2022 at 11:20 AM Richard Purdie
>> > >  wrote:
>> > >> This patch is not in master and is not a backport therefore not
>> > >> eligible for kirkstone/langdale.
>> >
>> > My bad, the intention was to have it in all three branches: master,
>> > kirkstone, and langdale.
>> >
>> > > 'nor should it go to master.
>> > >
>> > > If someone wants to allow go to fetch sources during builds, it
>> > needs
>> > > to be done in their own layers.
>> > >
>> > > Bruce
>> >
>> > Probably I misunderstood the outcome of the discussion in my first
>> > link.
>> > Bruce and Richard, you both suggested to have it in go-mod with the
>> > warning. I agree that it breaks reproducibility, and is considered
>> > a bad
>> > practice in general (I'm aware of a few more build systems with
>> > the same
>> > shortcoming).
>> >
>> > My point is, until a proper solution is in place, it should be at
>> > least
>> > documented somewhere that this should be done in own layer/recipe.
>> > Any
>> > suggestions where this can be documented if not in OE-Core?
>> >
>> >
>> > Have you tried the changes submitted by Lukas/Stefan in:
>> > https://lists.openembedded.org/g/openembedded-architecture/message/1539
>> > ?
>> >
>> > It's not perfect, I was testing it on
>> > https://github.com/influxdata/telegraf/blob/master/go.mod and I've
>> > found some corner cases where it failed.
>> >
>> > But it seems like very good start and we should work with Lukas/Stefan
>> > to get it merged in master. Then all branches could consume recipes
>> > created in master and only the exceptions would need to have 

Re: [OE-core] [PATCH] defaultsetup: Inherit create-spdx by default

[Alexandre Belloni via lists.openembedded.org]

https://autobuilder.yoctoproject.org/typhoon/#/builders/47/builds/7743/steps/11/logs/stdio
 :(



On 10/09/2023 09:25:56+0100, Richard Purdie wrote:
> This has been tested in poky by default for a while and ew've hopefully 
> resolved
> most of the gremlins. THis is the direction we're recommending for 
> license/manifest
> requirements so set it by default for OE.
> 
> Signed-off-by: Richard Purdie 
> ---
>  meta/conf/distro/defaultsetup.conf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/conf/distro/defaultsetup.conf 
> b/meta/conf/distro/defaultsetup.conf
> index 1abb5096293..90b68057ad4 100644
> --- a/meta/conf/distro/defaultsetup.conf
> +++ b/meta/conf/distro/defaultsetup.conf
> @@ -14,7 +14,7 @@ TMPDIR .= "${TCLIBCAPPEND}"
>  
>  USER_CLASSES ?= ""
>  PACKAGE_CLASSES ?= "package_ipk"
> -INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
> +INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool create-spdx"
>  INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}"
>  
>  INIT_MANAGER ??= "none"
> -- 
> 2.39.2
> 

> 
> 
> 


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187472): 
https://lists.openembedded.org/g/openembedded-core/message/187472
Mute This Topic: https://lists.openembedded.org/mt/101269714/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] OE-core CVE metrics for master on Sun 10 Sep 2023 01:00:01 AM HST

[Khem Raj]

On Sun, Sep 10, 2023 at 8:54 AM Marta Rybczynska 
wrote:

>
>
> On Sun, 10 Sept 2023, 17:14 Khem Raj,  wrote:
>
>> On Sun, Sep 10, 2023 at 4:18 AM Steve Sakoman  wrote:
>> >
>> > Branch: master
>> >
>> > New this week: 10 CVEs
>> > CVE-2022-3563 (CVSS3: 5.7 MEDIUM): bluez5
>> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3563 *
>> > CVE-2022-3637 (CVSS3: 5.5 MEDIUM): bluez5
>> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3637 *
>>
>> These two are addressed in the 5.69 release which is already in
>> master. So I wonder how the CVE scanner missed it.
>
>
> The NVD entry does not include any version numbers, so all bluez versions
> are matched as vulnerable. Have you mailed them? Can do it if you haven't.
>

I have not so please go ahead


> Kind regards,
> Marta
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187471): 
https://lists.openembedded.org/g/openembedded-core/message/187471
Mute This Topic: https://lists.openembedded.org/mt/101270898/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][PATCH v6 12/12] docs: cover devtool ide

[Adrian Freihofer]

Signed-off-by: Adrian Freihofer 
---
 documentation/sdk-manual/extensible.rst | 97 -
 1 file changed, 96 insertions(+), 1 deletion(-)

diff --git a/documentation/sdk-manual/extensible.rst 
b/documentation/sdk-manual/extensible.rst
index 9e08e57a4e7..d05d4e36aa7 100644
--- a/documentation/sdk-manual/extensible.rst
+++ b/documentation/sdk-manual/extensible.rst
@@ -237,7 +237,7 @@ all the commands.
devtool
quick reference.
 
-Three ``devtool`` subcommands provide entry-points into
+Four ``devtool`` subcommands provide entry-points into
 development:
 
 -  *devtool add*: Assists in adding new software to be built.
@@ -245,6 +245,8 @@ development:
 -  *devtool modify*: Sets up an environment to enable you to modify
the source of an existing component.
 
+-  *devtool ide*: Generates a configuration for an IDE.
+
 -  *devtool upgrade*: Updates an existing recipe so that you can
build it for an updated set of source files.
 
@@ -632,6 +634,99 @@ command:
   proceed with your work. If you do use this command, realize that
   the source tree is preserved.
 
+Use ``devtool ide`` to generate an configuration for the IDE
+
+
+``devtool ide`` automatically configures the IDE for cross-compiling and 
remote debugging.
+The IDE is configured to call for example cmake directly. This has several 
advantages.
+First of all it is much faster than using e.g. ``devtool build``. But it also 
allows to
+use the very good integration of build tools like cmake or gdb with VSCode 
directly.
+
+Two different use cases are supported:
+
+- Generate the IDE configuration for a workspace created by ``devtool modify``.
+
+- Generate the IDE configuration for using a cross-toolchain as provided by
+  ``bitbake meta-ide-support build-sysroots``.
+
+Assuming the development environment is set up correctly and a workspace has 
been created
+for the recipe using ``devtool modify recipe``, the following command can 
create the
+configuration for VSCode in the recipe workspace:
+
+   $ devtool ide recipe core-image-minimal --target root@192.168.7.2
+
+What this command does exactly depends on the recipe or the build tool used by 
the recipe.
+Currently, only CMake and Meson are supported natively.
+
+For a recipe which inherits cmake it does:
+
+- Prepare the SDK by calling bitbake core-image-minimal, gdb-cross, 
qemu-native...
+
+- Generate a cmake-preset with configures cmake to use exactly the same 
environent and
+  the same cmake-cache configuration as used by ``bitbake recipe``. The 
cmake-preset referres
+  to the per-recipe-sysroot of the recipe.
+
+  Currently Configure, Build and Test presets are supported. Test presets 
execute the test
+  binaries with Qemu.
+
+- Generates a helper script to handle the do_install with pseudo
+
+- Generates some helper scripts to start the gdbserver on the target device
+
+- Generates the ``.vscode`` folder containing the following files:
+
+  - c_ccp_properties.json: configure the code navigation
+
+  - extensions.json: Recommend the extensions which are used.
+
+  - launch.json: Provide a configuration for remote debugging with gdb-cross 
and gdbserver.
+The debug-symbols are searched in the build-folder, the per-recipe-sysroot 
and the rootfs-dbg
+folder which is provided by the image.
+
+  - settings.json: confgure the indexer to ignore the build folders
+
+  - tasks.json: Provide some helpers for running
+
+- do_install and ``devtool deploy-target``
+
+- start the gdbserver via ssh
+
+For a recipe which inherits meson a similar configuration is generated.
+Because there is nothing like a meson-preset a wrapper script for meson is 
generated.
+
+For some special recipes and use cases a per-recipe-sysroot based SDK is not 
suitable.
+Therefore devtool ide also supports setting up the shared sysroots environment 
and generating
+a IDE configurations referring to the shared sysroots. Recipes leading to a 
shared sysroot
+are for example meta-ide-support or shared-sysroots. Also passing none as a 
recipe name leads
+to a shared sysroot SDK.
+
+   $ devtool ide none core-image-minimal
+
+In case of a shared sysroot SDK the configuration which gets generated for 
VSCode exposes the
+cross-tool-chain as a cmake-kit. If a cmake project is loaded into VSCode the 
cross-toolchain
+can be selected for compiling.
+
+The default IDE is VSCode. Some hints about using VSCode:
+
+- To work with cmake press ``Ctrl + Shift + p``, type cmake.
+  This will show some possible commands like selecting a cmake preset, 
compiling or running ctest.
+  A cmake kit might be activated by ``Ctrl + Shift + p``, type cmake quick 
start,
+  if not preset file is in the wokspace.
+
+- To work with meson press ``Ctrl + Shift + p``, type meson.
+  This will show some possible commands like compiling or executing the unit 
tests.
+
+- For the deployment to the target device, just press ``Ctrl + Shift + p``, 

[OE-core][PATCH v6 11/12] oe-selftest devtool: ide tests

[Adrian Freihofer]

Signed-off-by: Adrian Freihofer 
---
 meta/lib/oeqa/selftest/cases/devtool.py | 179 
 1 file changed, 179 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/devtool.py 
b/meta/lib/oeqa/selftest/cases/devtool.py
index b577f6d62a1..158e016b895 100644
--- a/meta/lib/oeqa/selftest/cases/devtool.py
+++ b/meta/lib/oeqa/selftest/cases/devtool.py
@@ -11,6 +11,7 @@ import tempfile
 import glob
 import fnmatch
 import unittest
+import json
 
 from oeqa.selftest.case import OESelftestTestCase
 from oeqa.utils.commands import runCmd, bitbake, get_bb_var, create_temp_layer
@@ -2196,3 +2197,181 @@ class DevtoolUpgradeTests(DevtoolBase):
 
 #Step 4.5
 runCmd("grep %s %s" % (modconfopt, codeconfigfile))
+
+
+
+class DevtoolIdeTests(DevtoolBase):
+def __devtool_ide_recipe(self, recipe_name, build_file, testimage):
+self._check_runqemu_prerequisites()
+tempdir = tempfile.mkdtemp(prefix='devtoolqa')
+self.track_for_cleanup(tempdir)
+self.track_for_cleanup(self.workspacedir)
+self.add_command_to_tearDown('bitbake -c clean %s' % recipe_name)
+self.add_command_to_tearDown('bitbake-layers remove-layer */workspace')
+
+conf_lines = [
+'IMAGE_CLASSES += "image-combined-dbg"',
+'IMAGE_GEN_DEBUGFS = "1"',
+'IMAGE_INSTALL:append = " gdbserver %s-ptest"' % recipe_name
+]
+self.write_config("\n".join(conf_lines))
+
+result = runCmd('devtool modify %s -x %s' % (recipe_name, tempdir))
+self.assertExists(os.path.join(tempdir, build_file),
+  'Extracted source could not be found')
+self.assertExists(os.path.join(self.workspacedir, 'conf',
+  'layer.conf'), 'Workspace directory not created')
+matches = glob.glob(os.path.join(self.workspacedir,
+'appends', recipe_name + '.bbappend'))
+self.assertTrue(matches, 'bbappend not created %s' % result.output)
+
+# Test devtool status
+result = runCmd('devtool status')
+self.assertIn(recipe_name, result.output)
+self.assertIn(tempdir, result.output)
+self._check_src_repo(tempdir)
+
+# Usually devtool ide would initiate the build of the SDK.
+# But there is a circular dependency with starting Qemu and passing 
the IP of runqemu to devtool ide.
+bitbake("%s qemu-native qemu-helper-native" % testimage)
+deploy_dir_image = get_bb_var('DEPLOY_DIR_IMAGE')
+self.add_command_to_tearDown('bitbake -c clean %s' % testimage)
+self.add_command_to_tearDown('rm -f %s/%s*' % (deploy_dir_image, 
testimage))
+
+return tempdir
+
+def __devtool_ide_qemu(self, tempdir, qemu, recipe_name, bitbake_sdk_cmd, 
example_exe):
+# Verify do_install works
+with open(os.path.join(tempdir, '.vscode', 'tasks.json')) as tasks_j:
+tasks_d = json.load(tasks_j)
+tasks = tasks_d["tasks"]
+task_install = next((task for task in tasks if task["label"] == 
"install && deploy-target %s"  % recipe_name), None)
+self.assertIsNot(task_install, None)
+install_deploy_cmd = task_install["command"]
+# execute only the bb_run_do_install script since the deploy would 
require e.g. Qemu running.
+install_cmd = install_deploy_cmd.replace("install_and_deploy", 
"bb_run_do_install")
+runCmd(install_cmd, cwd=tempdir)
+
+# Verify if re-building the SDK still works and the deploy and install 
script gets generated
+runCmd(bitbake_sdk_cmd)
+self.assertExists(install_deploy_cmd, 'install_and_deploy script not 
found')
+
+MAGIC_STRING_ORIG = "Magic: 123456789"
+MAGIC_STRING_NEW = "Magic: 987654321"
+ptest_cmd = "ptest-runner " + recipe_name
+
+# Verify the unmodified example prints the magic string
+status, output = qemu.run(example_exe)
+self.assertEqual(status, 0, msg="%s failed: %s" % (example_exe, 
output))
+self.assertIn(MAGIC_STRING_ORIG, output)
+
+# Verify the unmodified ptests work
+status, output = qemu.run(ptest_cmd)
+self.assertEqual(status, 0, msg="%s failed: %s" % (ptest_cmd, output))
+self.assertIn("PASS: cpp-example-lib", output)
+
+# Replace the Magic String in the code, compile and deploy to Qemu
+cpp_example_lib_hpp = os.path.join(tempdir, 'cpp-example-lib.hpp')
+with open(cpp_example_lib_hpp, 'r') as file:
+cpp_code = file.read()
+cpp_code = cpp_code.replace(MAGIC_STRING_ORIG, MAGIC_STRING_NEW)
+with open(cpp_example_lib_hpp, 'w') as file:
+file.write(cpp_code)
+runCmd(install_deploy_cmd, cwd=tempdir)
+
+# Verify the modified example prints the modified magic string
+status, output = qemu.run(example_exe)
+self.assertEqual(status, 0, msg="%s failed: %s" % (example_exe, 
output))
+ 

[OE-core][PATCH v6 10/12] oe-selftest devtool: refactor runqemu pre-requisites

[Adrian Freihofer]

Split runqemu pre-requisites into a function which can be re-used by
other tests as well.

Signed-off-by: Adrian Freihofer 
---
 meta/lib/oeqa/selftest/cases/devtool.py | 48 +
 1 file changed, 26 insertions(+), 22 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/devtool.py 
b/meta/lib/oeqa/selftest/cases/devtool.py
index a2b77e528de..b577f6d62a1 100644
--- a/meta/lib/oeqa/selftest/cases/devtool.py
+++ b/meta/lib/oeqa/selftest/cases/devtool.py
@@ -256,6 +256,31 @@ class DevtoolTestCase(OESelftestTestCase):
 if remaining_removelines:
 self.fail('Expected removed lines not found: %s' % 
remaining_removelines)
 
+def _check_runqemu_prerequisites(self):
+"""Check runqemu is available
+
+Whilst some tests would seemingly be better placed as a runtime test,
+unfortunately the runtime tests run under bitbake and you can't run
+devtool within bitbake (since devtool needs to run bitbake itself).
+Additionally we are testing build-time functionality as well, so
+really this has to be done as an oe-selftest test.
+"""
+machine = get_bb_var('MACHINE')
+if not machine.startswith('qemu'):
+self.skipTest('This test only works with qemu machines')
+if not os.path.exists('/etc/runqemu-nosudo'):
+self.skipTest('You must set up tap devices with 
scripts/runqemu-gen-tapdevs before running this test')
+result = runCmd('PATH="$PATH:/sbin:/usr/sbin" ip tuntap show', 
ignore_status=True)
+if result.status != 0:
+result = runCmd('PATH="$PATH:/sbin:/usr/sbin" ifconfig -a', 
ignore_status=True)
+if result.status != 0:
+self.skipTest('Failed to determine if tap devices exist with 
ifconfig or ip: %s' % result.output)
+for line in result.output.splitlines():
+if line.startswith('tap'):
+break
+else:
+self.skipTest('No tap devices found - you must set up tap devices 
with scripts/runqemu-gen-tapdevs before running this test')
+
 def _test_devtool_add_git_url(self, git_url, version, pn, 
resulting_src_uri):
 self.track_for_cleanup(self.workspacedir)
 self.add_command_to_tearDown('bitbake-layers remove-layer */workspace')
@@ -1616,28 +1641,7 @@ class DevtoolExtractTests(DevtoolBase):
 
 @OETestTag("runqemu")
 def test_devtool_deploy_target(self):
-# NOTE: Whilst this test would seemingly be better placed as a runtime 
test,
-# unfortunately the runtime tests run under bitbake and you can't run
-# devtool within bitbake (since devtool needs to run bitbake itself).
-# Additionally we are testing build-time functionality as well, so
-# really this has to be done as an oe-selftest test.
-#
-# Check preconditions
-machine = get_bb_var('MACHINE')
-if not machine.startswith('qemu'):
-self.skipTest('This test only works with qemu machines')
-if not os.path.exists('/etc/runqemu-nosudo'):
-self.skipTest('You must set up tap devices with 
scripts/runqemu-gen-tapdevs before running this test')
-result = runCmd('PATH="$PATH:/sbin:/usr/sbin" ip tuntap show', 
ignore_status=True)
-if result.status != 0:
-result = runCmd('PATH="$PATH:/sbin:/usr/sbin" ifconfig -a', 
ignore_status=True)
-if result.status != 0:
-self.skipTest('Failed to determine if tap devices exist with 
ifconfig or ip: %s' % result.output)
-for line in result.output.splitlines():
-if line.startswith('tap'):
-break
-else:
-self.skipTest('No tap devices found - you must set up tap devices 
with scripts/runqemu-gen-tapdevs before running this test')
+self._check_runqemu_prerequisites()
 self.assertTrue(not os.path.exists(self.workspacedir), 'This test 
cannot be run with a workspace directory under the build directory')
 # Definitions
 testrecipe = 'mdadm'
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187468): 
https://lists.openembedded.org/g/openembedded-core/message/187468
Mute This Topic: https://lists.openembedded.org/mt/101275538/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][PATCH v6 08/12] devtool: refactor deploy-target

[Adrian Freihofer]

Signed-off-by: Adrian Freihofer 
---
 scripts/lib/devtool/__init__.py |   5 +-
 scripts/lib/devtool/deploy.py   | 230 +---
 2 files changed, 124 insertions(+), 111 deletions(-)

diff --git a/scripts/lib/devtool/__init__.py b/scripts/lib/devtool/__init__.py
index 702db669de3..7d64547616e 100644
--- a/scripts/lib/devtool/__init__.py
+++ b/scripts/lib/devtool/__init__.py
@@ -78,12 +78,15 @@ def exec_fakeroot(d, cmd, **kwargs):
 """Run a command under fakeroot (pseudo, in fact) so that it picks up the 
appropriate file permissions"""
 # Grab the command and check it actually exists
 fakerootcmd = d.getVar('FAKEROOTCMD')
+fakerootenv = d.getVar('FAKEROOTENV')
+exec_fakeroot_no_d(fakerootcmd, fakerootenv, cmd, kwargs)
+
+def exec_fakeroot_no_d(fakerootcmd, fakerootenv, cmd, **kwargs):
 if not os.path.exists(fakerootcmd):
 logger.error('pseudo executable %s could not be found - have you run a 
build yet? pseudo-native should install this and if you have run any build then 
that should have been built')
 return 2
 # Set up the appropriate environment
 newenv = dict(os.environ)
-fakerootenv = d.getVar('FAKEROOTENV')
 for varvalue in fakerootenv.split():
 if '=' in varvalue:
 splitval = varvalue.split('=', 1)
diff --git a/scripts/lib/devtool/deploy.py b/scripts/lib/devtool/deploy.py
index e14a5874177..ea7e2cb1ae8 100644
--- a/scripts/lib/devtool/deploy.py
+++ b/scripts/lib/devtool/deploy.py
@@ -16,7 +16,7 @@ import bb.utils
 import argparse_oe
 import oe.types
 
-from devtool import exec_fakeroot, setup_tinfoil, check_workspace_recipe, 
DevtoolError
+from devtool import exec_fakeroot_no_d, setup_tinfoil, check_workspace_recipe, 
DevtoolError
 
 logger = logging.getLogger('devtool')
 
@@ -133,16 +133,11 @@ def _prepare_remote_script(deploy, verbose=False, 
dryrun=False, undeployall=Fals
 
 return '\n'.join(lines)
 
-
-
-def deploy(args, config, basepath, workspace):
-"""Entry point for the devtool 'deploy' subcommand"""
+def deploy_cached(srcdir, workdir, path, strip_cmd, libdir, base_libdir, 
max_process, fakerootcmd, fakerootenv, args):
 import math
 import oe.recipeutils
 import oe.package
 
-check_workspace_recipe(workspace, args.recipename, checksrc=False)
-
 try:
 host, destdir = args.target.split(':')
 except ValueError:
@@ -152,116 +147,131 @@ def deploy(args, config, basepath, workspace):
 if not destdir.endswith('/'):
 destdir += '/'
 
+recipe_outdir = srcdir
+if not os.path.exists(recipe_outdir) or not os.listdir(recipe_outdir):
+raise DevtoolError('No files to deploy - have you built the %s '
+'recipe? If so, the install step has not installed '
+'any files.' % args.recipename)
+
+if args.strip and not args.dry_run:
+# Fakeroot copy to new destination
+srcdir = recipe_outdir
+recipe_outdir = os.path.join(workdir, 'devtool-deploy-target-stripped')
+if os.path.isdir(recipe_outdir):
+exec_fakeroot_no_d(fakerootcmd, fakerootenv, "rm -rf %s" % 
recipe_outdir, shell=True)
+exec_fakeroot_no_d(fakerootcmd, fakerootenv, "cp -af %s %s" % 
(os.path.join(srcdir, '.'), recipe_outdir), shell=True)
+os.environ['PATH'] = ':'.join([os.environ['PATH'], path or ''])
+oe.package.strip_execs(args.recipename, recipe_outdir, strip_cmd, 
libdir, base_libdir, max_process)
+
+filelist = []
+inodes = set({})
+ftotalsize = 0
+for root, _, files in os.walk(recipe_outdir):
+for fn in files:
+fstat = os.lstat(os.path.join(root, fn))
+# Get the size in kiB (since we'll be comparing it to the output 
of du -k)
+# MUST use lstat() here not stat() or getfilesize() since we don't 
want to
+# dereference symlinks
+if fstat.st_ino in inodes:
+fsize = 0
+else:
+fsize = int(math.ceil(float(fstat.st_size)/1024))
+inodes.add(fstat.st_ino)
+ftotalsize += fsize
+# The path as it would appear on the target
+fpath = os.path.join(destdir, os.path.relpath(root, 
recipe_outdir), fn)
+filelist.append((fpath, fsize))
+
+if args.dry_run:
+print('Files to be deployed for %s on target %s:' % (args.recipename, 
args.target))
+for item, _ in filelist:
+print('  %s' % item)
+return 0
+
+extraoptions = ''
+if args.no_host_check:
+extraoptions += '-o UserKnownHostsFile=/dev/null -o 
StrictHostKeyChecking=no'
+if not args.show_status:
+extraoptions += ' -q'
+
+scp_sshexec = ''
+ssh_sshexec = 'ssh'
+if args.ssh_exec:
+scp_sshexec = "-S %s" % args.ssh_exec
+ssh_sshexec = args.ssh_exec
+scp_port = ''
+ssh_port = ''
+if args.port:
+scp_port = "-P %s" % args.port
+ssh_port = 

[OE-core][PATCH v6 09/12] devtool: ide make deploy-target quicker

[Adrian Freihofer]

Instead of calling devtool deploy-target which starts a bitbake server
to get some variables the previous refactoring allows to generate a
simple script which does no longer depend on variables from bitbake.
This is much faster.
---
 scripts/lib/devtool/ide.py | 115 ++---
 1 file changed, 55 insertions(+), 60 deletions(-)

diff --git a/scripts/lib/devtool/ide.py b/scripts/lib/devtool/ide.py
index 7c7040232c4..9c724509d48 100755
--- a/scripts/lib/devtool/ide.py
+++ b/scripts/lib/devtool/ide.py
@@ -9,6 +9,7 @@
 
 import os
 import stat
+import sys
 import logging
 import json
 import re
@@ -360,15 +361,19 @@ class RecipeModified:
 self.bbappend = None
 # recipe variables from d.getVar
 self.b = None
+self.base_libdir = None
 self.bpn = None
 self.d = None
 self.fakerootcmd = None
 self.fakerootenv = None
+self.libdir = None
+self.max_process = None
 self.package_arch = None
 self.path = None
 self.recipe_sysroot = None
 self.recipe_sysroot_native = None
 self.staging_incdir = None
+self.strip_cmd = None
 self.target_arch = None
 self.workdir = None
 # replicate bitbake build environment
@@ -387,11 +392,6 @@ class RecipeModified:
 self.meson_cross_file = None
 # vscode
 self.dot_code_dir = None
-# TODO: remove calling devtool
-self.bb_env_passthrough_additions = None
-self.bbpath = None
-self.bitbakepath = None
-self.topdir = None
 
 def initialize(self, config, workspace, tinfoil):
 recipe_d = parse_recipe(
@@ -413,10 +413,14 @@ class RecipeModified:
 shutil.rmtree(self.temp_dir)
 
 self.b = recipe_d.getVar('B')
+self.base_libdir = recipe_d.getVar('base_libdir')
 self.bpn = recipe_d.getVar('BPN')
 self.d = recipe_d.getVar('D')
 self.fakerootcmd = recipe_d.getVar('FAKEROOTCMD')
 self.fakerootenv = recipe_d.getVar('FAKEROOTENV')
+self.libdir = recipe_d.getVar('libdir'),
+self.max_process = int(recipe_d.getVar(
+"BB_NUMBER_THREADS") or os.cpu_count() or 1)
 self.package_arch = recipe_d.getVar('PACKAGE_ARCH')
 self.path = recipe_d.getVar('PATH')
 self.recipe_sysroot = os.path.realpath(
@@ -425,15 +429,10 @@ class RecipeModified:
 recipe_d.getVar('RECIPE_SYSROOT_NATIVE'))
 self.staging_incdir = os.path.realpath(
 recipe_d.getVar('STAGING_INCDIR'))
+self.strip_cmd = recipe_d.getVar('STRIP')
 self.target_arch = recipe_d.getVar('TARGET_ARCH')
 self.workdir = os.path.realpath(recipe_d.getVar('WORKDIR'))
 
-self.bb_env_passthrough_additions = recipe_d.getVar(
-'BB_ENV_PASSTHROUGH_ADDITIONS')
-self.bbpath = recipe_d.getVar('BBPATH')
-self.bitbakepath = recipe_d.getVar('BITBAKEPATH')
-self.topdir = recipe_d.getVar('TOPDIR')
-
 self.__init_exported_variables(recipe_d)
 
 if bb.data.inherits_class('cmake', recipe_d):
@@ -971,6 +970,38 @@ class RecipeModified:
 cmd_lines.append(install_cmd)
 return self.write_script(cmd_lines, 'bb_run_do_install')
 
+def gen_deploy_target_script(self, args):
+"""Generate a quicker (works without tinfoil) variant of devtool 
target-deploy"""
+cmd_lines = ['#!/usr/bin/env python3']
+cmd_lines.append('import sys')
+cmd_lines.append('devtool_sys_path = %s' % str(sys.path))
+cmd_lines.append('devtool_sys_path.reverse()')
+cmd_lines.append('for p in devtool_sys_path:')
+cmd_lines.append('if p not in sys.path:')
+cmd_lines.append('sys.path.insert(0, p)')
+cmd_lines.append('from devtool.deploy import deploy_cached')
+args_filter = ['debug', 'dry_run', 'key', 'no_check_space', 
'no_host_check',
+   'no_preserve', 'port', 'recipename', 'show_status', 
'ssh_exec', 'strip', 'target']
+filtered_args_dict = {key: value for key, value in vars(
+args).items() if key in args_filter}
+cmd_lines.append('filtered_args_dict = %s' % str(filtered_args_dict))
+cmd_lines.append('class Dict2Class(object):')
+cmd_lines.append('def __init__(self, my_dict):')
+cmd_lines.append('for key in my_dict:')
+cmd_lines.append('setattr(self, key, my_dict[key])')
+cmd_lines.append('filtered_args = Dict2Class(filtered_args_dict)')
+cmd_lines.append('deploy_cached("%s", "%s", "%s", "%s", "%s", "%s", 
%d, "%s", "%s", filtered_args)' %
+ (self.d, self.workdir, self.path, self.strip_cmd,
+  self.libdir, self.base_libdir, self.max_process,
+  self.fakerootcmd, self.fakerootenv))
+return self.write_script(cmd_lines, 'deploy_target')
+
+def 

[OE-core][PATCH v6 07/12] refactor: make strip_execs callable without d

[Adrian Freihofer]

This allows to call strip_execs function from devtool without going
via tinfoil and a bitbake server process.

Signed-off-by: Adrian Freihofer 
---
 meta/classes-global/staging.bbclass | 3 ++-
 meta/lib/oe/package.py  | 7 ---
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/meta/classes-global/staging.bbclass 
b/meta/classes-global/staging.bbclass
index 3a300c32e7c..d229f401073 100644
--- a/meta/classes-global/staging.bbclass
+++ b/meta/classes-global/staging.bbclass
@@ -92,7 +92,8 @@ python sysroot_strip () {
 qa_already_stripped = 'already-stripped' in (d.getVar('INSANE_SKIP:' + pn) 
or "").split()
 strip_cmd = d.getVar("STRIP")
 
-oe.package.strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, d,
+max_process = oe.utils.get_bb_number_threads(d)
+oe.package.strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, 
max_process,
qa_already_stripped=qa_already_stripped)
 }
 
diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index 9d70925b9b7..1dd20f85ebd 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -114,7 +114,7 @@ def is_static_lib(path):
 return start == magic
 return False
 
-def strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, d, 
qa_already_stripped=False):
+def strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, max_process, 
qa_already_stripped=False):
 """
 Strip executable code (like executables, shared libraries) _in_place_
 - Based on sysroot_strip in staging.bbclass
@@ -122,6 +122,7 @@ def strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, 
d, qa_already_stripp
 :param strip_cmd: Strip command (usually ${STRIP})
 :param libdir: ${libdir} - strip .so files in this directory
 :param base_libdir: ${base_libdir} - strip .so files in this directory
+:param max_process: number of stripping processes started in parallel
 :param qa_already_stripped: Set to True if already-stripped' in 
${INSANE_SKIP}
 This is for proper logging and messages only.
 """
@@ -164,7 +165,7 @@ def strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, 
d, qa_already_stripp
 # ...but is it ELF, and is it already stripped?
 checkelf.append(file)
 inodecache[file] = s.st_ino
-results = oe.utils.multiprocess_launch(is_elf, checkelf, d)
+results = oe.utils.multiprocess_launch_mp(is_elf, checkelf, max_process)
 for (file, elf_file) in results:
 #elf_file = is_elf(file)
 if elf_file & 1:
@@ -192,7 +193,7 @@ def strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, 
d, qa_already_stripp
 elf_file = int(elffiles[file])
 sfiles.append((file, elf_file, strip_cmd))
 
-oe.utils.multiprocess_launch(runstrip, sfiles, d)
+oe.utils.multiprocess_launch_mp(runstrip, sfiles, max_process)
 
 
 def file_translate(file):
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187465): 
https://lists.openembedded.org/g/openembedded-core/message/187465
Mute This Topic: https://lists.openembedded.org/mt/101275535/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][PATCH v6 06/12] refactor: make multiprocess_launch callable without d

[Adrian Freihofer]

This is a preparation for making the strip_execs function callable from
devtool without going via tinfoil and a bitbake server process.

Signed-off-by: Adrian Freihofer 
---
 meta/conf/bitbake.conf |  2 +-
 meta/lib/oe/utils.py   | 12 +---
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 0bcc8215c5d..69e854ecedc 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -975,5 +975,5 @@ BB_UNIHASH ?= "${BB_TASKHASH}"
 oe.sstatesig.find_sstate_manifest[vardepsexclude] = "BBEXTENDCURR 
BBEXTENDVARIANT OVERRIDES PACKAGE_EXTRA_ARCHS"
 oe.utils.get_multilib_datastore[vardepsexclude] = 
"DEFAULTTUNE_MULTILIB_ORIGINAL OVERRIDES"
 oe.path.format_display[vardepsexclude] = "TOPDIR"
-oe.utils.multiprocess_launch[vardepsexclude] = "BB_NUMBER_THREADS"
+oe.utils.get_bb_number_threads[vardepsexclude] = "BB_NUMBER_THREADS"
 oe.packagedata.emit_pkgdata[vardepsexclude] = "BB_NUMBER_THREADS"
diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
index 1658f3555d3..a3b1bb1087d 100644
--- a/meta/lib/oe/utils.py
+++ b/meta/lib/oe/utils.py
@@ -264,10 +264,17 @@ def execute_pre_post_process(d, cmds):
 bb.note("Executing %s ..." % cmd)
 bb.build.exec_func(cmd, d)
 
-# For each item in items, call the function 'target' with item as the first 
+def get_bb_number_threads(d):
+return int(d.getVar("BB_NUMBER_THREADS") or os.cpu_count() or 1)
+
+def multiprocess_launch(target, items, d, extraargs=None):
+max_process = get_bb_number_threads(d)
+return multiprocess_launch_mp(target, items, max_process, extraargs)
+
+# For each item in items, call the function 'target' with item as the first
 # argument, extraargs as the other arguments and handle any exceptions in the
 # parent thread
-def multiprocess_launch(target, items, d, extraargs=None):
+def multiprocess_launch_mp(target, items, max_process, extraargs=None):
 
 class ProcessLaunch(multiprocessing.Process):
 def __init__(self, *args, **kwargs):
@@ -302,7 +309,6 @@ def multiprocess_launch(target, items, d, extraargs=None):
 self.update()
 return self._result
 
-max_process = int(d.getVar("BB_NUMBER_THREADS") or os.cpu_count() or 1)
 launched = []
 errors = []
 results = []
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187464): 
https://lists.openembedded.org/g/openembedded-core/message/187464
Mute This Topic: https://lists.openembedded.org/mt/101275534/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][PATCH v6 05/12] cpp-example: workaround for pseudo breakeage

[Adrian Freihofer]

Signed-off-by: Adrian Freihofer 
---
 meta-selftest/recipes-test/cpp/cmake-example.bb | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta-selftest/recipes-test/cpp/cmake-example.bb 
b/meta-selftest/recipes-test/cpp/cmake-example.bb
index 96d543180b4..fbf1f266721 100644
--- a/meta-selftest/recipes-test/cpp/cmake-example.bb
+++ b/meta-selftest/recipes-test/cpp/cmake-example.bb
@@ -15,3 +15,9 @@ SRC_URI += "\
 "
 
 FILES:${PN}-ptest += "${bindir}/test-cmake-example"
+
+# This is a workaround for packages with sources in-tree
+# Without this bitbake ... does not work after running the install script.
+# newenv['PSEUDO_IGNORE_PATHS'] = newenv['PSEUDO_IGNORE_PATHS'] + ""
+# path mismatch [3 links]: ino 37529096 db 
'/home/adrian/projects/oss/meta-yocto-upstream/projects/poky-oe-glibc-sd/tmp/work/cortexa57-poky-linux/cmake-example/1.0-r0/package/usr/src/debug/cmake-example/1.0-r0/oe-local-files/cmake-example-lib.cpp'
 req 
'/home/adrian/projects/oss/meta-yocto-upstream/projects/poky-oe-glibc-sd/workspace/sources/cmake-example/oe-local-files/cmake-example-lib.cpp'.
+PACKAGE_DEBUG_SPLIT_STYLE = "debug-without-src"
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187463): 
https://lists.openembedded.org/g/openembedded-core/message/187463
Mute This Topic: https://lists.openembedded.org/mt/101275532/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][PATCH v6 04/12] tests: add a C++ example recipe

[Adrian Freihofer]

This simple C++ project supports compilation with cmake and with meson.
It's supposed to be used with oe-selftest for the devtool ide plugin.

Signed-off-by: Adrian Freihofer 
---
 meta-selftest/recipes-test/cpp/.gitignore |  1 +
 .../recipes-test/cpp/cmake-example.bb | 17 ++
 .../recipes-test/cpp/cmake-example/run-ptest  | 10 
 .../recipes-test/cpp/cpp-example.inc  | 24 
 .../recipes-test/cpp/files/CMakeLists.txt | 60 +++
 .../cpp/files/cpp-example-lib.cpp | 17 ++
 .../cpp/files/cpp-example-lib.hpp | 16 +
 .../recipes-test/cpp/files/cpp-example.cpp| 16 +
 .../recipes-test/cpp/files/meson.build| 34 +++
 .../cpp/files/test-cpp-example.cpp| 19 ++
 .../recipes-test/cpp/meson-example.bb | 17 ++
 .../recipes-test/cpp/meson-example/run-ptest  | 10 
 12 files changed, 241 insertions(+)
 create mode 100644 meta-selftest/recipes-test/cpp/.gitignore
 create mode 100644 meta-selftest/recipes-test/cpp/cmake-example.bb
 create mode 100644 meta-selftest/recipes-test/cpp/cmake-example/run-ptest
 create mode 100644 meta-selftest/recipes-test/cpp/cpp-example.inc
 create mode 100644 meta-selftest/recipes-test/cpp/files/CMakeLists.txt
 create mode 100644 meta-selftest/recipes-test/cpp/files/cpp-example-lib.cpp
 create mode 100644 meta-selftest/recipes-test/cpp/files/cpp-example-lib.hpp
 create mode 100644 meta-selftest/recipes-test/cpp/files/cpp-example.cpp
 create mode 100644 meta-selftest/recipes-test/cpp/files/meson.build
 create mode 100644 meta-selftest/recipes-test/cpp/files/test-cpp-example.cpp
 create mode 100644 meta-selftest/recipes-test/cpp/meson-example.bb
 create mode 100644 meta-selftest/recipes-test/cpp/meson-example/run-ptest

diff --git a/meta-selftest/recipes-test/cpp/.gitignore 
b/meta-selftest/recipes-test/cpp/.gitignore
new file mode 100644
index 000..30d388a12b7
--- /dev/null
+++ b/meta-selftest/recipes-test/cpp/.gitignore
@@ -0,0 +1 @@
+build*
\ No newline at end of file
diff --git a/meta-selftest/recipes-test/cpp/cmake-example.bb 
b/meta-selftest/recipes-test/cpp/cmake-example.bb
new file mode 100644
index 000..96d543180b4
--- /dev/null
+++ b/meta-selftest/recipes-test/cpp/cmake-example.bb
@@ -0,0 +1,17 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+SUMMARY = "A C++ example compiled with cmake."
+
+inherit cmake
+
+require cpp-example.inc
+
+SRC_URI += "\
+file://CMakeLists.txt \
+"
+
+FILES:${PN}-ptest += "${bindir}/test-cmake-example"
diff --git a/meta-selftest/recipes-test/cpp/cmake-example/run-ptest 
b/meta-selftest/recipes-test/cpp/cmake-example/run-ptest
new file mode 100644
index 000..94b620a1984
--- /dev/null
+++ b/meta-selftest/recipes-test/cpp/cmake-example/run-ptest
@@ -0,0 +1,10 @@
+#!/bin/sh
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+test-cmake-example
+
+# Note: run-ptests exits with exit value from test-cmake-example
diff --git a/meta-selftest/recipes-test/cpp/cpp-example.inc 
b/meta-selftest/recipes-test/cpp/cpp-example.inc
new file mode 100644
index 000..39c61cf4ceb
--- /dev/null
+++ b/meta-selftest/recipes-test/cpp/cpp-example.inc
@@ -0,0 +1,24 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
+
+inherit ptest
+
+DEPENDS += "json-c"
+
+PV = "1.0"
+
+S = "${WORKDIR}"
+
+SRC_URI = "\
+file://cpp-example.cpp \
+file://cpp-example-lib.hpp \
+file://cpp-example-lib.cpp \
+file://test-cpp-example.cpp \
+file://run-ptest \
+"
diff --git a/meta-selftest/recipes-test/cpp/files/CMakeLists.txt 
b/meta-selftest/recipes-test/cpp/files/CMakeLists.txt
new file mode 100644
index 000..839aa59b5e3
--- /dev/null
+++ b/meta-selftest/recipes-test/cpp/files/CMakeLists.txt
@@ -0,0 +1,60 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+cmake_minimum_required(VERSION 3.22)
+
+project(cmake-example
+  VERSION 1.0.0
+  LANGUAGES CXX
+)
+
+option(BUILD_SHARED_LIBS "Build using shared libraries" ON)
+
+set(CMAKE_CXX_STANDARD 17)
+set(CMAKE_CXX_STANDARD_REQUIRED On)
+set(CMAKE_CXX_EXTENSIONS Off)
+
+include(GNUInstallDirs)
+
+# Find json-c
+# find_package(PkgConfig REQUIRED)
+# pkg_check_modules(JSONC REQUIRED json-c)
+find_package(json-c)
+
+# A simple library linking json-c library found by pkgconfig
+add_library(cmake-example-lib cpp-example-lib.cpp cpp-example-lib.hpp)
+set_target_properties(cmake-example-lib PROPERTIES 
+VERSION ${PROJECT_VERSION}
+SOVERSION ${PROJECT_VERSION_MAJOR}
+)
+target_link_libraries(cmake-example-lib PRIVATE json-c::json-c)
+# target_link_libraries(cmake-example-lib ${JSONC_LIBRARIES})
+# target_include_directories(cmake-example-lib PUBLIC ${JSONC_INCLUDE_DIRS})
+# target_compile_options(cmake-example-lib PUBLIC 

[OE-core][PATCH v6 03/12] devtool: new ide plugin

[Adrian Freihofer]

The new devtool ide plugin configures an IDE to work with the eSDK.

With this initial implementation VSCode is the default IDE.
The plugin works for recipes inheriting the cmake or the meson bbclass.
Support for more programming languages and build tools may be added in
the future.

Using the plugin in recipe modes:
$ devtool modify a-recipe
$ devtool ide a-recipe a-image
$ code "$BUILDDIR/workspace/sources/a-recipe"
Work in VSCode, after installing the proposed plugins

Using the plugin without a recipe
$ devtool ide none a-image
vscode where/the/sources/are
Use the cross tool-chain which is provided as a cmake-kit.

The goal of this implementation is to create a configuration for VSCode
(or other IDEs) that allows to work on the code of a recipe completely
independent from bitbake. bitbake is only called if the configuration or
the whole SDK has to be regenerated. But bitbake should not need to be
called while working in the IDE. This has two major advantages over
calling devtool build from the IDE:
- The IDE provides plugins for integration with cmake, for example.
  These features are usable, which would not be the case if bitbake or
  devtool are called from within the IDE.
- It is much faster.

Signed-off-by: Adrian Freihofer 
---
 scripts/lib/devtool/ide.py | 1190 
 1 file changed, 1190 insertions(+)
 create mode 100755 scripts/lib/devtool/ide.py

diff --git a/scripts/lib/devtool/ide.py b/scripts/lib/devtool/ide.py
new file mode 100755
index 000..7c7040232c4
--- /dev/null
+++ b/scripts/lib/devtool/ide.py
@@ -0,0 +1,1190 @@
+#! /usr/bin/env python3
+#
+# Copyright (C) 2023 Siemens AG
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+
+"""Devtool ide plugin"""
+
+import os
+import stat
+import logging
+import json
+import re
+import shutil
+from argparse import RawTextHelpFormatter
+from enum import IntEnum, auto
+
+import bb
+from devtool import exec_build_env_command, setup_tinfoil, 
check_workspace_recipe, DevtoolError, parse_recipe
+from devtool.standard import get_real_srctree
+
+SHARED_SYSROOT_RECIPES = ['none', 'meta-ide-support', 'build-sysroots']
+SUPPORTED_IDES = ['code', 'none']
+
+logger = logging.getLogger('devtool')
+
+
+class TargetDevice:
+"""SSH remote login parameters"""
+
+def __init__(self, args):
+self.extraoptions = ''
+if args.no_host_check:
+self.extraoptions += '-o UserKnownHostsFile=/dev/null -o 
StrictHostKeyChecking=no'
+self.ssh_sshexec = 'ssh'
+if args.ssh_exec:
+self.ssh_sshexec = args.ssh_exec
+self.ssh_port = ''
+if args.port:
+self.ssh_port = "-p %s" % args.port
+if args.key:
+self.extraoptions += ' -i %s' % args.key
+
+self.target = args.target
+target_sp = args.target.split('@')
+if len(target_sp) == 1:
+self.login = ""
+self.host = target_sp[0]
+elif len(target_sp) == 2:
+self.login = target_sp[0]
+self.host = target_sp[1]
+else:
+logger.error("Invalid target argument: %s" % args.target)
+
+
+class RecipeNative:
+def __init__(self, name, target_arch=None):
+self.name = name
+self.target_arch = target_arch
+self.bootstrap_tasks = [self.name + ':do_addto_recipe_sysroot']
+self.staging_bindir_native = None
+self.target_sys = None
+self.__native_bin = None
+
+def initialize(self, config, workspace, tinfoil):
+recipe_d = parse_recipe(
+config, tinfoil, self.name, appends=True, filter_workspace=False)
+if not recipe_d:
+raise DevtoolError("Parsing %s recipe failed" % self.name)
+self.staging_bindir_native = os.path.realpath(
+recipe_d.getVar('STAGING_BINDIR_NATIVE'))
+self.target_sys = recipe_d.getVar('TARGET_SYS')
+
+@property
+def native_bin(self):
+if not self.__native_bin:
+raise DevtoolError("native binary name is not defined.")
+return self.__native_bin
+
+
+class RecipeGdbCross(RecipeNative):
+def __init__(self, args, target_arch, target_device, gdbserver_multi=True):
+super().__init__('gdb-cross-' + target_arch, target_arch)
+self.target_device = target_device
+self.gdb = None
+self.gdbserver_port_next = int(args.gdbserver_port_start)
+self.gdbserver_multi = gdbserver_multi
+self.config_db = {}
+
+def initialize(self, config, workspace, tinfoil):
+super().initialize(config, workspace, tinfoil)
+gdb_bin = self.target_sys + '-gdb'
+gdb_path = os.path.join(
+self.staging_bindir_native, self.target_sys, gdb_bin)
+self.gdb = gdb_path
+
+@property
+def host(self):
+return self.target_device.host
+
+def __gdbserver_start_cmd(self, binary, port):
+if self.gdbserver_multi:
+gdbserver_cmd = "/usr/bin/gdbserver --multi :%s" % (

[OE-core][PATCH v6 02/12] cmake.bbclass: support qemu

[Adrian Freihofer]

Define the CMAKE_CROSSCOMPILING_EMULATOR variable similar to what the
meson bbclass does. This allows for example to execute cross compilied
unit tests on the build machine.

CMAKE_CROSSCOMPILING_EMULATOR is a semi colon separated list of
paramters which could directly handle the -L and the -E parameters.
Creating a wrapper script is not absolutely mandatory. But anyway lets
do it similar to what the meson.bbclass does and also disable pseudo.

Signed-off-by: Adrian Freihofer 
---
 meta/classes-recipe/cmake.bbclass | 21 +
 1 file changed, 21 insertions(+)

diff --git a/meta/classes-recipe/cmake.bbclass 
b/meta/classes-recipe/cmake.bbclass
index 41748b08207..68b4e83bbe8 100644
--- a/meta/classes-recipe/cmake.bbclass
+++ b/meta/classes-recipe/cmake.bbclass
@@ -4,6 +4,13 @@
 # SPDX-License-Identifier: MIT
 #
 
+inherit qemu
+
+EXEWRAPPER_ENABLED:class-native = "False"
+EXEWRAPPER_ENABLED:class-nativesdk = "False"
+EXEWRAPPER_ENABLED ?= "${@bb.utils.contains('MACHINE_FEATURES', 
'qemu-usermode', 'True', 'False', d)}"
+DEPENDS:append = "${@' qemu-native' if d.getVar('EXEWRAPPER_ENABLED') == 
'True' else ''}"
+
 # Path to the CMake file to process.
 OECMAKE_SOURCEPATH ??= "${S}"
 
@@ -156,6 +163,20 @@ EOF
 
 addtask generate_toolchain_file after do_patch before do_configure
 
+cmake_do_generate_toolchain_file:append:class-target() {
+if [ "${EXEWRAPPER_ENABLED}" = "True" ]; then
+# Write out a qemu wrapper that will be used as exe_wrapper so that 
camake
+# can run target helper binaries through that. This also allows to 
execute ctest.
+qemu_binary="${@qemu_wrapper_cmdline(d, '${STAGING_DIR_HOST}', 
['${STAGING_DIR_HOST}/${libdir}','${STAGING_DIR_HOST}/${base_libdir}'])}"
+echo "#!/bin/sh" > "${WORKDIR}/cmake-qemuwrapper"
+echo "$qemu_binary \"\$@\"" >> "${WORKDIR}/cmake-qemuwrapper"
+chmod +x "${WORKDIR}/cmake-qemuwrapper"
+echo "set( CMAKE_CROSSCOMPILING_EMULATOR 
${WORKDIR}/cmake-qemuwrapper)" \
+  >> ${WORKDIR}/toolchain.cmake
+fi
+}
+
+
 CONFIGURE_FILES = "CMakeLists.txt"
 
 do_configure[cleandirs] = "${@d.getVar('B') if d.getVar('S') != d.getVar('B') 
else ''}"
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187460): 
https://lists.openembedded.org/g/openembedded-core/message/187460
Mute This Topic: https://lists.openembedded.org/mt/101275529/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][PATCH v6 01/12] vscode: add minimal configuration

[Adrian Freihofer]

It is essential to configure VSCode indexer plugins to ignore the build
folder of bitbake. Otherwise, the indexer plugins run with 100% CPU load
until an OOM exception occurs. In practice, this makes VSCode more or
less unusable for working with Yocto until a file like the one added by
this commit is deployed before VSCode starts. From the user's point of
view, it is not obvious why the system runs at 100% CPU load and
eventually crashes.

It is even more misleading that VSCode starts the indexers immediately,
but does not stop or reconfigure them when the ignore list is updated.
In practice, this means that every time the ignore list is changed,
VSCode immediately starts indexing the build folder until the OOM
exception stops it. Depending on the system's OOM handler, the entire
build machine may crash.
Particularly annoying is the Python plugin that ignores the general
ignore list and requires an extra ignore section.

The settings are suitable for workflows like bitbake, devtool modify,
devtool reset. The settings are not intended to work on the source code
of a recipe. It is assumed that a separate instance of VSCode is used
per workspace folder. These per workspace instances can have different
settings depending on the details of the sources that come with the
recipe. The new devtool ide plugin will generate settings to match this.

Signed-off-by: Adrian Freihofer 
---
 .gitignore|  2 ++
 .vscode/settings.json | 32 
 2 files changed, 34 insertions(+)
 create mode 100644 .vscode/settings.json

diff --git a/.gitignore b/.gitignore
index 8f48d452dab..f6ce090b5fc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -36,3 +36,5 @@ _toaster_clones/
 downloads/
 sstate-cache/
 toaster.sqlite
+.vscode/
+vscode-bitbake-build/
diff --git a/.vscode/settings.json b/.vscode/settings.json
new file mode 100644
index 000..517a86d1bfa
--- /dev/null
+++ b/.vscode/settings.json
@@ -0,0 +1,32 @@
+{
+"files.watcherExclude": {
+"**/.git/**": true,
+"**/cache/**": true,
+"**/tmp*/**": true,
+"**/downloads/**": true,
+"**/sstate-cache/**": true,
+"**/vscode-bitbake-build/**": true,
+"**/workspace/sources/**": true,
+"**/workspace/attic/**": true
+},
+"files.exclude": {
+"**/.git/**": true,
+"**/cache/**": true,
+"**/tmp*/**": true,
+"**/downloads/**": true,
+"**/sstate-cache/**": true,
+"**/vscode-bitbake-build/**": true,
+"**/workspace/sources/**": true,
+"**/workspace/attic/**": true
+},
+"python.analysis.exclude": [
+"**/.git/**",
+"**/cache/**",
+"**/tmp*/**",
+"**/downloads/**",
+"**/sstate-cache/**",
+"**/vscode-bitbake-build/**",
+"**/workspace/sources/**",
+"**/workspace/attic/**"
+]
+}
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187459): 
https://lists.openembedded.org/g/openembedded-core/message/187459
Mute This Topic: https://lists.openembedded.org/mt/101275527/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][PATCH v6 00/12] devtool ide plugin

[Adrian Freihofer]

Changes in comparison to v5:

Fix the oe-selftests 
  AssertionError: 127 != 0 : cmake-example failed: sh: cmake-example:  not found
  and
  AssertionError: 127 != 0 : mesonex failed: sh: mesonex: not found
Since v1 of this patchset, there has been more than one problem that caused the 
autobuilder to abort with the same error. The hopefully last error is now 
probably fixed as well. The main cause was that the test case did IMAGE_INSTALL 
+= instead of IMAGE_INSTALL:append.
Unfortunately, I had the same IMAGE_INSTALL:append in my local.conf file which 
made the bug invisible in my test runs. The v5 run on the AB led me in the 
right direction in the improved error message.

With the v5 tests running on the AB there were also test_devtool_add_fetch_git 
failures.
I just can't see any relation between my changes and this error. It's also a 
bit strange that this error didn't occur with previous versions of almost the 
same patches. Please let me know if I should investigate further. 




According to 
https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/
one of the proposed areas for development of the Yocto project is "VSCode IDE 
Integration - New developer tooling".
One aspect of this larger topic is helping application developers configure the 
IDE to work on a recipe's source code using Yocto's eSDK. This patchset 
provides a new devtool plugin (devtool ide) that does this fully automatically 
for recipes inheriting the cmake or the meson bbclass. Support for more 
programming languages and build tools may be added in the future.

Let's start with a brief introduction of how it looks like from a user's 
perspective.

Reference setup
---

$ . oe-init-build-env

Add the following layers to bblayers.conf file:
- meta
- meta-poky
- meta-yocto-bsp
- meta-selftest
  
Add the following to the local.conf

IMAGE_CLASSES += "image-combined-dbg"
IMAGE_GEN_DEBUGFS = "1"
IMAGE_FEATURES += "ssh-server-dropbear debug-tweaks"
IMAGE_INSTALL:append = "\
cmake-example-ptest \
meson-example-ptest \
gdbserver \
"

Working on a recipe
---

Note for those who "hate cmake with passion": Replace cmake by meson in the 
following commands.

1. Add the recipe which should be modified to the workspace

   $ devtool modify cmake-example

2. Build the eSDK. This provides all the host tools as well as an image which 
can be used on the target device.
   Since everything is built with one bitbake command also all the debug 
symbols are expected to be consistent.

   $ devtool ide cmake-example core-image-minimal

3. Install the image on the target device or simply use Qemu

   $ runqemu

4. Start VSCode

   $ code "$BUILDDIR/workspace/sources/cmake-example"

5. Work in VSCode, after installing the proposed plugins

   Ctrl + Shift + p, cmake Select Configure Preset
   Ctrl + Shift + p, cmake Build

6. Execute the unit tests on the host works with Qemu even for cross compiled 
test executables.

   Ctrl + Shift + p, cmake Test

7. Remote debugging with GDB

   Ctrl + Shift + p, Run Task --> install && deploy-target cmake-example
   F5 (Debug configuration might be selected before)

8. Work on the recipes and call bitbake again to get the SDK updated.
   Building the application by calling cmake (from the IDE) or by calling 
bitbake or by calling devtool build is expected to produce the exact same 
results. To make that possible, the devtool ide plugin is designed to configure 
the IDE to call cmake with the exact same configuration as used by bitbake when 
building the recipe. Unlike the eSDK, the goal here is clearly that there is no 
longer a separation between the SDK and the application development process. 
Regardless of which tool is called, the same source files are edited and the 
same o-files are generated and re-used.

Working with a SDK without a recipe
---

If devtool ide is called for a recipe named none or meta-ide-support the eSDK 
with its generic environment file gets generated.
In case of using VSCode and cmake in addition to the well known environment 
file a cmake-kit
https://vector-of-bool.github.io/docs/vscode-cmake-tools/kits.html is added to 
the User-Local Kits.
This allows to work with cmake calling the cross-toolchain out of VSCode or a 
shell with the environment file sourced.

Design
--

The goal of this implementation is to create a configuration for VSCode (or 
other IDEs) that allows to work on the code of a recipe completely independent 
from bitbake. bitbake is only called if the configuration or the whole SDK has 
to be regenerated. But bitbake should not need to be called while working in 
the IDE. This has two major advantages over calling devtool build from the IDE:
- The IDE provides plugins for integration with cmake, for example. These 
features are usable, which would not be the case if bitbake or devtool are 
called from within the IDE.
- It is much faster.

Supporting other IDEs

Re: [OE-core] OE-core CVE metrics for master on Sun 10 Sep 2023 01:00:01 AM HST

[Marta Rybczynska]

On Sun, 10 Sept 2023, 17:14 Khem Raj,  wrote:

> On Sun, Sep 10, 2023 at 4:18 AM Steve Sakoman  wrote:
> >
> > Branch: master
> >
> > New this week: 10 CVEs
> > CVE-2022-3563 (CVSS3: 5.7 MEDIUM): bluez5
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3563 *
> > CVE-2022-3637 (CVSS3: 5.5 MEDIUM): bluez5
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3637 *
>
> These two are addressed in the 5.69 release which is already in
> master. So I wonder how the CVE scanner missed it.


The NVD entry does not include any version numbers, so all bluez versions
are matched as vulnerable. Have you mailed them? Can do it if you haven't.

Kind regards,
Marta

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187457): 
https://lists.openembedded.org/g/openembedded-core/message/187457
Mute This Topic: https://lists.openembedded.org/mt/101270898/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] OE-core CVE metrics for master on Sun 10 Sep 2023 01:00:01 AM HST

[Khem Raj]

On Sun, Sep 10, 2023 at 4:18 AM Steve Sakoman  wrote:
>
> Branch: master
>
> New this week: 10 CVEs
> CVE-2022-3563 (CVSS3: 5.7 MEDIUM): bluez5 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3563 *
> CVE-2022-3637 (CVSS3: 5.5 MEDIUM): bluez5 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3637 *

These two are addressed in the 5.69 release which is already in
master. So I wonder how the CVE scanner missed it.

> CVE-2023-4733 (CVSS3: 7.8 HIGH): vim 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4733 *
> CVE-2023-4734 (CVSS3: 7.8 HIGH): vim 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4734 *
> CVE-2023-4735 (CVSS3: 7.8 HIGH): vim 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4735 *
> CVE-2023-4736 (CVSS3: 7.8 HIGH): vim 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4736 *
> CVE-2023-4738 (CVSS3: 7.8 HIGH): vim 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4738 *
> CVE-2023-4750 (CVSS3: 7.8 HIGH): vim 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4750 *
> CVE-2023-4752 (CVSS3: 7.8 HIGH): vim 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4752 *
> CVE-2023-4781 (CVSS3: 7.8 HIGH): vim 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4781 *
>
> Removed this week: 3 CVEs
> CVE-2023-3772 (CVSS3: 4.4 MEDIUM): linux-yocto 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 *
> CVE-2023-3773 (CVSS3: 4.4 MEDIUM): linux-yocto 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 *
> CVE-2023-4128 (CVSS3: 7.8 HIGH): linux-yocto 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 *
>
> Full list:  Found 36 unpatched CVEs
> CVE-2019-14899 (CVSS3: 7.4 HIGH): linux-yocto 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 *
> CVE-2021-3714 (CVSS3: 7.5 HIGH): linux-yocto 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 *
> CVE-2021-3864 (CVSS3: 7.0 HIGH): linux-yocto 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 *
> CVE-2022-0400 (CVSS3: 7.5 HIGH): linux-yocto 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 *
> CVE-2022-1247 (CVSS3: 7.0 HIGH): linux-yocto 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 *
> CVE-2022-3219 (CVSS3: 3.3 LOW): gnupg:gnupg-native 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 *
> CVE-2022-33065 (CVSS3: 7.8 HIGH): libsndfile1 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-33065 *
> CVE-2022-3563 (CVSS3: 5.7 MEDIUM): bluez5 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3563 *
> CVE-2022-3637 (CVSS3: 5.5 MEDIUM): bluez5 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3637 *
> CVE-2022-36402 (CVSS3: 5.5 MEDIUM): linux-yocto 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-36402 *
> CVE-2022-38096 (CVSS3: 5.5 MEDIUM): linux-yocto 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 *
> CVE-2022-4543 (CVSS3: 5.5 MEDIUM): linux-yocto 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 *
> CVE-2022-46456 (CVSS3: 6.1 MEDIUM): nasm:nasm-native 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 *
> CVE-2023-0687 (CVSS3: 9.8 CRITICAL): glibc 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 *
> CVE-2023-1386 (CVSS3: 7.8 HIGH): qemu:qemu-native:qemu-system-native 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 *
> CVE-2023-28736 (CVSS3: 6.7 MEDIUM): mdadm 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-28736 *
> CVE-2023-28938 (CVSS3: 4.4 MEDIUM): mdadm 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-28938 *
> CVE-2023-3019 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3019 *
> CVE-2023-3180 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3180 *
> CVE-2023-3354 (CVSS3: 7.5 HIGH): qemu:qemu-native:qemu-system-native 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 *
> CVE-2023-3640 (CVSS3: 7.8 HIGH): linux-yocto 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 *
> CVE-2023-36664 (CVSS3: 7.8 HIGH): ghostscript 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-36664 *
> CVE-2023-37769 (CVSS3: 6.5 MEDIUM): pixman:pixman-native 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-37769 *
> CVE-2023-40030 (CVSS3: 6.1 MEDIUM): rust:rust-native 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40030 *
> CVE-2023-4010 (CVSS3: 4.6 MEDIUM): linux-yocto 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 *
> CVE-2023-4135 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 *
> CVE-2023-4569 (CVSS3: 5.5 MEDIUM): linux-yocto 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 *
> 

[OE-core] OE-core CVE metrics for mickledore on Sun 10 Sep 2023 04:00:01 AM HST

[Steve Sakoman]

Branch: mickledore

New this week: 8 CVEs
CVE-2023-4733 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4733 *
CVE-2023-4734 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4734 *
CVE-2023-4735 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4735 *
CVE-2023-4736 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4736 *
CVE-2023-4738 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4738 *
CVE-2023-4750 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4750 *
CVE-2023-4752 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4752 *
CVE-2023-4781 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4781 *

Removed this week: 2 CVEs
CVE-2023-4016 (CVSS3: 5.5 MEDIUM): procps 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4016 *
CVE-2023-40303 (CVSS3: 7.8 HIGH): inetutils 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40303 *

Full list:  Found 68 unpatched CVEs
CVE-2020-11935 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11935 *
CVE-2020-22218 (CVSS3: 7.5 HIGH): libssh2:libssh2-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-22218 *
CVE-2021-3714 (CVSS3: 7.5 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 *
CVE-2021-3864 (CVSS3: 7.0 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 *
CVE-2022-0400 (CVSS3: 7.5 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 *
CVE-2022-1247 (CVSS3: 7.0 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 *
CVE-2022-3219 (CVSS3: 3.3 LOW): gnupg:gnupg-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 *
CVE-2022-33065 (CVSS3: 7.8 HIGH): libsndfile1 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-33065 *
CVE-2022-3533 (CVSS3: 5.7 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3533 *
CVE-2022-3606 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3606 *
CVE-2022-36402 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-36402 *
CVE-2022-38096 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 *
CVE-2022-3964 (CVSS3: 8.1 HIGH): ffmpeg 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3964 *
CVE-2022-3965 (CVSS3: 8.1 HIGH): ffmpeg 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3965 *
CVE-2022-4543 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 *
CVE-2022-46456 (CVSS3: 6.1 MEDIUM): nasm:nasm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 *
CVE-2022-48502 (CVSS3: 7.1 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-48502 *
CVE-2023-0160 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0160 *
CVE-2023-1206 (CVSS3: 5.7 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1206 *
CVE-2023-1386 (CVSS3: 7.8 HIGH): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 *
CVE-2023-1544 (CVSS3: 6.3 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1544 *
CVE-2023-2176 (CVSS3: 7.8 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-2176 *
CVE-2023-23039 (CVSS3: 5.7 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-23039 *
CVE-2023-2430 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-2430 *
CVE-2023-24329 (CVSS3: 7.5 HIGH): python3:python3-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-24329 *
CVE-2023-28736 (CVSS3: 6.7 MEDIUM): mdadm 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-28736 *
CVE-2023-28938 (CVSS3: 4.4 MEDIUM): mdadm 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-28938 *
CVE-2023-2898 (CVSS3: 4.7 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-2898 *
CVE-2023-29409 (CVSS3: 5.3 MEDIUM): 
go:go-binary-native:go-cross-core2-64:go-runtime 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-29409 *
CVE-2023-3019 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3019 *
CVE-2023-3180 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3180 *
CVE-2023-3354 (CVSS3: 7.5 HIGH): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 *
CVE-2023-35827 (CVSS3: 7.0 HIGH): linux-yocto 

[OE-core] OE-core CVE metrics for kirkstone on Sun 10 Sep 2023 03:00:01 AM HST

[Steve Sakoman]

Branch: kirkstone

New this week: 8 CVEs
CVE-2023-4733 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4733 *
CVE-2023-4734 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4734 *
CVE-2023-4735 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4735 *
CVE-2023-4736 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4736 *
CVE-2023-4738 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4738 *
CVE-2023-4750 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4750 *
CVE-2023-4752 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4752 *
CVE-2023-4781 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4781 *

Removed this week: 9 CVEs
CVE-2020-22218 (CVSS3: 7.5 HIGH): libssh2:libssh2-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-22218 *
CVE-2021-32292 (CVSS3: 9.8 CRITICAL): json-c 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-32292 *
CVE-2022-48554 (CVSS3: 5.5 MEDIUM): file:file-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-48554 *
CVE-2023-2908 (CVSS3: 5.5 MEDIUM): tiff 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-2908 *
CVE-2023-29491 (CVSS3: 7.8 HIGH): ncurses:ncurses-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-29491 *
CVE-2023-3316 (CVSS3: 6.5 MEDIUM): tiff 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3316 *
CVE-2023-3618 (CVSS3: 6.5 MEDIUM): tiff 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3618 *
CVE-2023-40217 (CVSS3: 5.3 MEDIUM): python3:python3-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40217 *
CVE-2023-40303 (CVSS3: 7.8 HIGH): inetutils 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40303 *

Full list:  Found 51 unpatched CVEs
CVE-2020-22219 (CVSS3: 7.8 HIGH): flac 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-22219 *
CVE-2021-35937 (CVSS3: 6.4 MEDIUM): rpm:rpm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-35937 *
CVE-2021-35938 (CVSS3: 6.7 MEDIUM): rpm:rpm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-35938 *
CVE-2021-35939 (CVSS3: 6.7 MEDIUM): rpm:rpm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-35939 *
CVE-2022-3219 (CVSS3: 3.3 LOW): gnupg:gnupg-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 *
CVE-2022-33065 (CVSS3: 7.8 HIGH): libsndfile1 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-33065 *
CVE-2022-3515 (CVSS3: 9.8 CRITICAL): gnupg:gnupg-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3515 *
CVE-2022-3553 (CVSS3: 6.5 MEDIUM): xserver-xorg 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3553 *
CVE-2022-3563 (CVSS3: 5.7 MEDIUM): bluez5 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3563 *
CVE-2022-3637 (CVSS3: 5.5 MEDIUM): bluez5 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3637 *
CVE-2022-36648 (CVSS3: 10.0 CRITICAL): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-36648 *
CVE-2022-3872 (CVSS3: 8.6 HIGH): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3872 *
CVE-2022-3964 (CVSS3: 8.1 HIGH): ffmpeg 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3964 *
CVE-2022-3965 (CVSS3: 8.1 HIGH): ffmpeg 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3965 *
CVE-2022-40090 (CVSS3: 6.5 MEDIUM): tiff 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-40090 *
CVE-2022-4055 (CVSS3: 7.4 HIGH): xdg-utils 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4055 *
CVE-2022-44840 (CVSS3: 7.8 HIGH): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-44840 *
CVE-2022-45703 (CVSS3: 7.8 HIGH): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-45703 *
CVE-2022-47007 (CVSS3: 5.5 MEDIUM): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-47007 *
CVE-2022-47008 (CVSS3: 5.5 MEDIUM): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-47008 *
CVE-2022-47010 (CVSS3: 5.5 MEDIUM): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-47010 *
CVE-2022-47011 (CVSS3: 5.5 MEDIUM): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-47011 *
CVE-2022-47673 (CVSS3: 7.8 HIGH): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-47673 *
CVE-2022-47695 (CVSS3: 7.8 HIGH): 

[OE-core] OE-core CVE metrics for dunfell on Sun 10 Sep 2023 02:00:01 AM HST

[Steve Sakoman]

Branch: dunfell

New this week: 8 CVEs
CVE-2023-4733 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4733 *
CVE-2023-4734 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4734 *
CVE-2023-4735 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4735 *
CVE-2023-4736 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4736 *
CVE-2023-4738 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4738 *
CVE-2023-4750 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4750 *
CVE-2023-4752 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4752 *
CVE-2023-4781 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4781 *

Removed this week: 2 CVEs
CVE-2023-29409 (CVSS3: 5.3 MEDIUM): go:go-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-29409 *
CVE-2023-40303 (CVSS3: 7.8 HIGH): inetutils 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40303 *

Full list:  Found 132 unpatched CVEs
CVE-2020-15705 (CVSS3: 6.4 MEDIUM): grub:grub-efi:grub-efi-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-15705 *
CVE-2020-21686 (CVSS3: 5.5 MEDIUM): nasm:nasm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-21686 *
CVE-2020-22219 (CVSS3: 7.8 HIGH): flac 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-22219 *
CVE-2020-24165 (CVSS3: 8.8 HIGH): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-24165 *
CVE-2020-25742 (CVSS3: 3.2 LOW): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-25742 *
CVE-2020-25743 (CVSS3: 3.2 LOW): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-25743 *
CVE-2020-27918 (CVSS3: 7.8 HIGH): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-27918 *
CVE-2020-29623 (CVSS3: 3.3 LOW): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-29623 *
CVE-2020-35503 (CVSS3: 6.0 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-35503 *
CVE-2020-35506 (CVSS3: 6.7 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-35506 *
CVE-2020-9948 (CVSS3: 8.8 HIGH): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-9948 *
CVE-2020-9951 (CVSS3: 8.8 HIGH): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-9951 *
CVE-2020-9952 (CVSS3: 7.1 HIGH): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-9952 *
CVE-2021-1765 (CVSS3: 6.5 MEDIUM): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1765 *
CVE-2021-1789 (CVSS3: 8.8 HIGH): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1789 *
CVE-2021-1799 (CVSS3: 6.5 MEDIUM): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1799 *
CVE-2021-1801 (CVSS3: 6.5 MEDIUM): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1801 *
CVE-2021-1870 (CVSS3: 9.8 CRITICAL): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1870 *
CVE-2021-20269 (CVSS3: 5.5 MEDIUM): kexec-tools 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-20269 *
CVE-2021-20295 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-20295 *
CVE-2021-27097 (CVSS3: 7.8 HIGH): u-boot 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-27097 *
CVE-2021-27138 (CVSS3: 7.8 HIGH): u-boot 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-27138 *
CVE-2021-31879 (CVSS3: 6.1 MEDIUM): wget 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-31879 *
CVE-2021-32292 (CVSS3: 9.8 CRITICAL): json-c 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-32292 *
CVE-2021-3418 (CVSS3: 6.4 MEDIUM): grub:grub-efi:grub-efi-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3418 *
CVE-2021-3445 (CVSS3: 7.5 HIGH): libdnf 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3445 *
CVE-2021-35937 (CVSS3: 6.4 MEDIUM): rpm:rpm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-35937 *
CVE-2021-35938 (CVSS3: 6.7 MEDIUM): rpm:rpm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-35938 *
CVE-2021-35939 (CVSS3: 6.7 MEDIUM): rpm:rpm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-35939 *
CVE-2021-3611 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3611 *
CVE-2021-3782 (CVSS3: 6.6 MEDIUM): wayland:wayland-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3782 *
CVE-2021-3947 (CVSS3: 5.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3947 *
CVE-2021-42762 

[OE-core] OE-core CVE metrics for master on Sun 10 Sep 2023 01:00:01 AM HST

[Steve Sakoman]

Branch: master

New this week: 10 CVEs
CVE-2022-3563 (CVSS3: 5.7 MEDIUM): bluez5 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3563 *
CVE-2022-3637 (CVSS3: 5.5 MEDIUM): bluez5 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3637 *
CVE-2023-4733 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4733 *
CVE-2023-4734 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4734 *
CVE-2023-4735 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4735 *
CVE-2023-4736 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4736 *
CVE-2023-4738 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4738 *
CVE-2023-4750 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4750 *
CVE-2023-4752 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4752 *
CVE-2023-4781 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4781 *

Removed this week: 3 CVEs
CVE-2023-3772 (CVSS3: 4.4 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 *
CVE-2023-3773 (CVSS3: 4.4 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 *
CVE-2023-4128 (CVSS3: 7.8 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 *

Full list:  Found 36 unpatched CVEs
CVE-2019-14899 (CVSS3: 7.4 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 *
CVE-2021-3714 (CVSS3: 7.5 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 *
CVE-2021-3864 (CVSS3: 7.0 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 *
CVE-2022-0400 (CVSS3: 7.5 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 *
CVE-2022-1247 (CVSS3: 7.0 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 *
CVE-2022-3219 (CVSS3: 3.3 LOW): gnupg:gnupg-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 *
CVE-2022-33065 (CVSS3: 7.8 HIGH): libsndfile1 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-33065 *
CVE-2022-3563 (CVSS3: 5.7 MEDIUM): bluez5 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3563 *
CVE-2022-3637 (CVSS3: 5.5 MEDIUM): bluez5 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3637 *
CVE-2022-36402 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-36402 *
CVE-2022-38096 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 *
CVE-2022-4543 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 *
CVE-2022-46456 (CVSS3: 6.1 MEDIUM): nasm:nasm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 *
CVE-2023-0687 (CVSS3: 9.8 CRITICAL): glibc 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 *
CVE-2023-1386 (CVSS3: 7.8 HIGH): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 *
CVE-2023-28736 (CVSS3: 6.7 MEDIUM): mdadm 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-28736 *
CVE-2023-28938 (CVSS3: 4.4 MEDIUM): mdadm 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-28938 *
CVE-2023-3019 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3019 *
CVE-2023-3180 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3180 *
CVE-2023-3354 (CVSS3: 7.5 HIGH): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 *
CVE-2023-3640 (CVSS3: 7.8 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 *
CVE-2023-36664 (CVSS3: 7.8 HIGH): ghostscript 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-36664 *
CVE-2023-37769 (CVSS3: 6.5 MEDIUM): pixman:pixman-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-37769 *
CVE-2023-40030 (CVSS3: 6.1 MEDIUM): rust:rust-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40030 *
CVE-2023-4010 (CVSS3: 4.6 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 *
CVE-2023-4135 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 *
CVE-2023-4569 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4569 *
CVE-2023-4611 (CVSS3: 6.3 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4611 *
CVE-2023-4733 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4733 *
CVE-2023-4734 (CVSS3: 7.8 HIGH): vim 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4734 *
CVE-2023-4735 (CVSS3: 7.8 

[OE-core] [PATCH] defaultsetup: Inherit create-spdx by default

[Richard Purdie]

This has been tested in poky by default for a while and ew've hopefully resolved
most of the gremlins. THis is the direction we're recommending for 
license/manifest
requirements so set it by default for OE.

Signed-off-by: Richard Purdie 
---
 meta/conf/distro/defaultsetup.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/distro/defaultsetup.conf 
b/meta/conf/distro/defaultsetup.conf
index 1abb5096293..90b68057ad4 100644
--- a/meta/conf/distro/defaultsetup.conf
+++ b/meta/conf/distro/defaultsetup.conf
@@ -14,7 +14,7 @@ TMPDIR .= "${TCLIBCAPPEND}"
 
 USER_CLASSES ?= ""
 PACKAGE_CLASSES ?= "package_ipk"
-INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
+INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool create-spdx"
 INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}"
 
 INIT_MANAGER ??= "none"
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187451): 
https://lists.openembedded.org/g/openembedded-core/message/187451
Mute This Topic: https://lists.openembedded.org/mt/101269714/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-