Re: [linux-yocto][linux-yocto v5.15/standard/nxp-sdk-5.15/nxp-soc & v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-soc][PATCH 1/3] arm64: dts: imx8m: add imx8mq-evk-b3.dts for imx8mq old boards

[Bruce Ashfield]

merged.

Bruce

In message: [linux-yocto][linux-yocto v5.15/standard/nxp-sdk-5.15/nxp-soc & 
v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-soc][PATCH 1/3] arm64: dts: imx8m: 
add imx8mq-evk-b3.dts for imx8mq old boards
on 23/05/2022 Xiaolei Wang wrote:

> Refer to SDK4.19 commit 21cb81b4f0bc("arm64: dts: Copy all imx8 dts")
> Change OV5640_MIPI IIC bus and address and MIPI_HDMI IIC bus
> 
> Signed-off-by: Xiaolei Wang 
> Signed-off-by: Bruce Ashfield 
> ---
>  .../boot/dts/freescale/imx8mq-evk-b3.dts  | 94 +++
>  1 file changed, 94 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-evk-b3.dts
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk-b3.dts 
> b/arch/arm64/boot/dts/freescale/imx8mq-evk-b3.dts
> new file mode 100644
> index ..4caf9bde7f48
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mq-evk-b3.dts
> @@ -0,0 +1,94 @@
> +/*
> + * Copyright 2018 NXP
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include "imx8mq-evk.dts"
> +/delete-node/ _bridge;
> +/delete-node/ _dsx_ts;
> +/delete-node/ _mipi;
> +/delete-node/ _mipi2;
> +
> + {
> +
> + ov5640_mipi2: ov5640_mipi2@2c {
> +compatible = "ovti,ov5640_mipi";
> +reg = <0x2c>;
> +status = "okay";
> +pinctrl-names = "default";
> +pinctrl-0 = <_csi2_pwn>, <_csi_rst>;
> +clocks = < IMX8MQ_CLK_CLKO2>;
> +clock-names = "csi_mclk";
> +assigned-clocks = < IMX8MQ_CLK_CLKO2>;
> +assigned-clock-parents = < IMX8MQ_SYS2_PLL_200M>;
> +assigned-clock-rates = <2000>;
> +csi_id = <1>;
> +pwn-gpios = < 5 GPIO_ACTIVE_HIGH>;
> +mclk = <2000>;
> +mclk_source = <0>;
> +port {
> +ov5640_mipi2_ep: endpoint {
> +remote-endpoint = <_sensor_ep>;
> +};
> +};
> +};
> +
> + ov5640_mipi: ov5640_mipi@1c {
> +compatible = "ovti,ov5640_mipi";
> +reg = <0x1c>;
> +status = "okay";
> +pinctrl-names = "default";
> +pinctrl-0 = <_csi1_pwn>;
> +clocks = < IMX8MQ_CLK_CLKO2>;
> +clock-names = "csi_mclk";
> +assigned-clocks = < IMX8MQ_CLK_CLKO2>;
> +assigned-clock-parents = < IMX8MQ_SYS2_PLL_200M>;
> +assigned-clock-rates = <2000>;
> +csi_id = <0>;
> +pwn-gpios = < 3 GPIO_ACTIVE_HIGH>;
> +mclk = <2000>;
> +mclk_source = <0>;
> +port {
> +ov5640_mipi1_ep: endpoint {
> +remote-endpoint = <_sensor_ep>;
> +};
> +};
> +};
> +
> + synaptics_dsx_ts: synaptics_dsx_ts@20 {
> +compatible = "synaptics_dsx";
> +reg = <0x20>;
> +pinctrl-names = "default";
> +pinctrl-0 = <_i2c1_dsi_ts_int>;
> +interrupt-parent = <>;
> +interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
> +synaptics,diagonal-rotation;
> +status = "disabled";
> +};
> +
> + adv_bridge: adv7535@3d {
> +compatible = "adi,adv7535";
> +reg = <0x3d>;
> +adi,addr-cec = <0x3b>;
> +adi,dsi-lanes = <4>;
> +pinctrl-0 = <_i2c1_dsi_ts_int>;
> +interrupt-parent = <>;
> +interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
> +
> +status = "disabled";
> +};
> +
> +};
> +
> + {
> +status = "disabled";
> +};
> -- 
> 2.25.1
> 

In message: [linux-yocto][linux-yocto v5.15/standard/nxp-sdk-5.15/nxp-soc & 
v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-soc][PATCH 3/3] media: ov5640 mipi 
v2: fix kernel warning when no camera is plugged in
on 23/05/2022 Xiaolei Wang wrote:

> the regulator need to be disabled before calling regulator_put().
> If not do so, the kernel will print warning message as below.
> 
> [2.834247] ov5640_mipi 1-003c: Camera is not found
> [2.839198] [ cut here ]
> [2.844386] WARNING: CPU: 0 PID: 33 at drivers/regulator/core.c:2039 
> _regulator_put+0x34/0xd8
> [2.852954] Modules linked 

Re: [linux-yocto][linux-yocto v5.10/standard/nxp-sdk-5.10/nxp-soc][PATCH] net: dsa: reference count the host mdb addresses

[Bruce Ashfield]

merged.

Bruce

In message: [linux-yocto][linux-yocto 
v5.10/standard/nxp-sdk-5.10/nxp-soc][PATCH] net: dsa: reference count the host 
mdb addresses
on 20/05/2022 Xulin Sun wrote:

> From: Vladimir Oltean 
> 
> Currently any DSA switch that implements the multicast ops (properly,
> that is) gets these errors after just sitting for a while, with at least
> 2 ports bridged:
> 
> [  286.013814] mscc_felix :00:00.5 swp3: failed (err=-2) to del object
> (id=3)
> 
> The reason has to do with this piece of code:
> 
> netdev_for_each_lower_dev(dev, lower_dev, iter)
> br_mdb_switchdev_host_port(dev, lower_dev, mp, type);
> 
> called from:
> 
> br_multicast_group_expired
> -> br_multicast_host_leave
>-> br_mdb_notify
>   -> br_mdb_switchdev_host
> 
> Basically, that code is correct. It tells each switchdev port that the
> host can leave that multicast group. But in the case of DSA, all user
> ports are connected to the host through the same pipe. So, because DSA
> translates a host MDB to a normal MDB on the CPU port, this means that
> when all user ports leave a multicast group, DSA tries to remove it N
> times from the CPU port.
> 
> We should be reference-counting these addresses.
> 
> Fixes: 5f4dbc50ce4d ("net: dsa: slave: Handle switchdev host mdb add/del")
> Signed-off-by: Vladimir Oltean 
> [Xulin: Pick patch from Link: 
> https://www.mail-archive.com/netdev@vger.kernel.org/msg362526.html]
> Signed-off-by: Xulin Sun 
> ---
>  include/net/dsa.h |  9 +
>  net/dsa/dsa2.c|  2 ++
>  net/dsa/slave.c   | 92 ++-
>  3 files changed, 94 insertions(+), 9 deletions(-)
> 
> diff --git a/include/net/dsa.h b/include/net/dsa.h
> index 35429a140dfa..38e9d449ce76 100644
> --- a/include/net/dsa.h
> +++ b/include/net/dsa.h
> @@ -251,6 +251,13 @@ struct dsa_link {
>   struct list_head list;
>  };
>  
> +struct dsa_host_addr {
> +   unsigned char addr[ETH_ALEN];
> +   u16 vid;
> +   refcount_t refcount;
> +   struct list_head list;
> +};
> +
>  struct dsa_switch {
>   bool setup;
>  
> @@ -333,6 +340,8 @@ struct dsa_switch {
>*/
>   boolmtu_enforcement_ingress;
>  
> + struct list_headhost_mdb;
> +
>   size_t num_ports;
>  };
>  
> diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
> index f543fca6dfcb..045a39323bae 100644
> --- a/net/dsa/dsa2.c
> +++ b/net/dsa/dsa2.c
> @@ -417,6 +417,8 @@ static int dsa_switch_setup(struct dsa_switch *ds)
>   if (ds->setup)
>   return 0;
>  
> + INIT_LIST_HEAD(>host_mdb);
> +
>   /* Initialize ds->phys_mii_mask before registering the slave MDIO bus
>* driver and before ops->setup() has run, since the switch drivers and
>* the slave MDIO bus driver rely on these values for probing PHY
> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
> index 65b125bb3b86..dae7071dd4c4 100644
> --- a/net/dsa/slave.c
> +++ b/net/dsa/slave.c
> @@ -376,6 +376,87 @@ static int dsa_slave_vlan_add(struct net_device *dev,
>   return 0;
>  }
>  
> +static struct dsa_host_addr *
> +dsa_host_mdb_find(struct dsa_switch *ds,
> + const struct switchdev_obj_port_mdb *mdb)
> +{
> +   struct dsa_host_addr *a;
> +
> +   list_for_each_entry(a, >host_mdb, list)
> +   if (ether_addr_equal(a->addr, mdb->addr) && a->vid == 
> mdb->vid)
> +return a;
> +
> +   return NULL;
> +}
> +
> +/* DSA can directly translate this to a normal MDB add, but on the CPU port.
> + * But because multiple user ports can join the same multicast group and the
> + * bridge will emit a notification for each port, we need to add/delete the
> + * entry towards the host only once, so we reference count it.
> + */
> +static int dsa_host_mdb_add(struct dsa_port *dp,
> +   const struct switchdev_obj_port_mdb *mdb,
> +   struct switchdev_trans *trans)
> +{
> +   struct dsa_port *cpu_dp = dp->cpu_dp;
> +   struct dsa_switch *ds = dp->ds;
> +   struct dsa_host_addr *a;
> +   int err;
> +
> +   /* Only the commit phase is refcounted, which means that for the
> +* second, third, etc port which is member of this host address,
> +* we'll call the prepare phase but never commit.
> +*/
> +   if (switchdev_trans_ph_prepare(trans))
> +   return dsa_port_mdb_add(cpu_dp, mdb, trans);
> +
> +   a = dsa_host_mdb_find(ds, mdb);
> +   if (a) {
> +   refcount_inc(>refcount);
> +   return 0;
> +   }
> +
> +   a = kzalloc(sizeof(*a), GFP_KERNEL);
> +   if (!a)
> +   return -ENOMEM;
> +
> +   err = dsa_port_mdb_add(cpu_dp, mdb, trans);
> +   if (err)
> +   return err;
> +
> +   ether_addr_copy(a->addr, mdb->addr);
> +   a->vid = mdb->vid;
> +   refcount_set(>refcount, 1);
> +   list_add_tail(>list, >host_mdb);
> +
> +   return 0;
> +}

Re: [linux-yocto][linux-yocto v5.15/standard/nxp-sdk-5.15/nxp-soc & v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-soc][PATCH] ARM64: dts: imx8mq: Fix a build error Unable to parse input tree

[Bruce Ashfield]

merged.

Bruce

In message: [linux-yocto][linux-yocto v5.15/standard/nxp-sdk-5.15/nxp-soc & 
v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-soc][PATCH] ARM64: dts: imx8mq: Fix 
a build error Unable to parse input tree
on 19/05/2022 Xiaolei Wang wrote:

> Due to the porting error of commit 38dad434a6b7("ARM64:
> dts: imx8mq: add csi and mipi csi node"), the property
> that needs to be deleted is not deleted.
> 
> Signed-off-by: Xiaolei Wang 
> ---
>  arch/arm64/boot/dts/freescale/imx8mq.dtsi | 22 +++---
>  1 file changed, 3 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi 
> b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> index 6d6d2fe9b9b0..60cb0625114d 100755
> --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> @@ -1159,33 +1159,17 @@ mipi_csi_1: mipi_csi1@30a7 {
>   reg = <0x30a7 0x1000>;
>   interrupts = ;
>   clocks = < IMX8MQ_CLK_CSI1_CORE>,
> -< IMX8MQ_CLK_CSI1_ESC>,
> -< IMX8MQ_CLK_CSI1_PHY_REF>;
> - clock-names = "core", "esc", "ui";
>   < IMX8MQ_CLK_CSI1_ESC>,
>   < IMX8MQ_CLK_CSI1_PHY_REF>;
>   clock-names = "clk_core", "clk_esc", "clk_pxl";
>   assigned-clocks = < IMX8MQ_CLK_CSI1_CORE>,
> - < IMX8MQ_CLK_CSI1_PHY_REF>,
> - < IMX8MQ_CLK_CSI1_ESC>;
> - assigned-clock-rates = <26600>, 
> <33300>, <6600>;
> - assigned-clock-parents = < 
> IMX8MQ_SYS1_PLL_266M>,
> - < IMX8MQ_SYS2_PLL_1000M>,
> - < IMX8MQ_SYS1_PLL_800M>;
> - < IMX8MQ_CLK_CSI1_PHY_REF>,
> - < IMX8MQ_CLK_CSI1_ESC>;
> - assigned-clock-rates = <13300>, 
> <1>, <6600>;
> +   < 
> IMX8MQ_CLK_CSI1_PHY_REF>,
> +   < IMX8MQ_CLK_CSI1_ESC>;
> +   assigned-clock-rates = 
> <13300>, <1>, <6600>;
>   power-domains = <_mipi_csi1>;
> - resets = < 
> IMX8MQ_RESET_MIPI_CSI1_CORE_RESET>,
> -  < 
> IMX8MQ_RESET_MIPI_CSI1_PHY_REF_RESET>,
> -  < 
> IMX8MQ_RESET_MIPI_CSI1_ESC_RESET>;
> - fsl,mipi-phy-gpr = <_gpr 0x88>;
> - interconnects = < IMX8MQ_ICM_CSI1  
> IMX8MQ_ICS_DRAM>;
> - interconnect-names = "dram";
>   csis-phy-reset = < 0x4c 7>;
>   phy-gpr = <_gpr 0x88>;
>   status = "disabled";
> -
>   };
>  
>   csi1_bridge: csi1_bridge@30a9 {
> -- 
> 2.25.1
> 

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

Re: [linux-yocto] [yocto-kernel-patch][yocto-5.15][PATCH 0/2] Enable MDIO bus config by default

[Bruce Ashfield]

In message: [linux-yocto] [yocto-kernel-patch][yocto-5.15][PATCH 0/2] Enable 
MDIO bus config by default
on 19/05/2022 Potin Lai wrote:

> Hi maintainer,
> 
> This patch series introduce mdio fragment to enable MDIO bus kernel
> configs, which required by mdio-tools for low-level MDIO bus
> communication.

The fragment itself looks fine, but in order to turn it on for the
standard kernel, we need to have a good reason .. since it introduces
size to every one of our builds.

Let me ask a few questions. Which boards (qemu or not) have you tested
this on ?

Are you enabling the option to ensure that the standard kernel has
this built-in, in case someone wants to use the mdio-tools ?

The reason I ask the questions above, is that we also have the option
to enable this in specific machine's, or tie it to a MACHINE/DISTRO
feature to have it automatically enabled (with a similar result, but
not enforced via the -standard kernel),

Bruce

> 
> Potin Lai (2):
>   cfg/net: introduce mdio fragment
>   ktypes/standard: enable MDIO by default
> 
>  cfg/net/mdio.cfg | 3 +++
>  cfg/net/mdio.scc | 5 +
>  kern-features.rc | 1 +
>  ktypes/standard/standard.scc | 1 +
>  4 files changed, 10 insertions(+)
>  create mode 100644 cfg/net/mdio.cfg
>  create mode 100644 cfg/net/mdio.scc
> 
> -- 
> 2.17.1
> 

> 
> 
> 


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

Re: [yocto] [meta-security][PATCH] meta-parsec: Update Parsec runtime tests

[Armin Kuster]

Very nice. This is much better than what I did.

may thanks,
Armin

On 5/24/22 11:05, Anton Antonov wrote:

Signed-off-by: Anton Antonov 
---
  meta-parsec/README.md |  65 +
  meta-parsec/lib/oeqa/runtime/cases/parsec.py  | 135 --
  .../images/security-parsec-image.bb   |   5 +-
  .../packagegroup-security-parsec.bb   |   1 -
  meta-tpm/classes/sanity-meta-tpm.bbclass  |   4 +-
  5 files changed, 191 insertions(+), 19 deletions(-)

diff --git a/meta-parsec/README.md b/meta-parsec/README.md
index 97026ea..f720cd2 100644
--- a/meta-parsec/README.md
+++ b/meta-parsec/README.md
@@ -88,6 +88,71 @@ https://github.com/meta-rust/cargo-bitbake
  2. Run cargo-bitbake inside the repository. It will produce a BB file.
  3. Create a new include file with SRC_URI and LIC_FILES_CHKSUM from the BB 
file.
  
+Automated Parsec testing with runqemu

+=
+
+ The Yocto build system has the ability to run a series of automated tests for 
qemu images.
+All the tests are actually commands run on the target system over ssh.
+
+ Meta-parsec includes automated unittests which run end to end Parsec tests.
+The tests are run against:
+- all providers pre-configured in the Parsec config file included in the image.
+- PKCS11 and TPM providers with software backends if softhsm and
+  swtpm packages included in the image.
+
+Meta-parsec also contains a recipe for `security-parsec-image` image with 
Parsec,
+softhsm and swtpm included.
+
+ Please notice that the account you use to run bitbake should have access to 
`/dev/kvm`.
+You might need to change permissions or add the account into `kvm` unix group.
+
+1. Testing Parsec with your own image where `parsec-service` and `parsec-tool` 
are already included.
+
+- Add into your `local.conf`:
+```
+INHERIT += "testimage"
+TEST_SUITES = "ping ssh parsec"
+```
+- Build your image
+```bash
+bitbake 
+```
+- Run tests
+```bash
+bitbake  -c testimage
+```
+
+2. Testing Parsec with pre-defined `security-parsec-image` image.
+
+- Add into your `local.conf`:
+```
+DISTRO_FEATURES += " tpm2"
+INHERIT += "testimage"
+TEST_SUITES = "ping ssh parsec"
+```
+- Build security-parsec-image image
+```bash
+bitbake security-parsec-image
+```
+- Run tests
+```bash
+bitbake security-parsec-image -c testimage
+```
+
+Output of a successfull tests run should look similar to:
+```
+RESULTS:
+RESULTS - ping.PingTest.test_ping: PASSED (0.05s)
+RESULTS - ssh.SSHTest.test_ssh: PASSED (0.25s)
+RESULTS - parsec.ParsecTest.test_all_providers: PASSED (1.84s)
+RESULTS - parsec.ParsecTest.test_pkcs11_provider: PASSED (2.91s)
+RESULTS - parsec.ParsecTest.test_tpm_provider: PASSED (3.33s)
+SUMMARY:
+security-parsec-image () - Ran 5 tests in 8.386s
+security-parsec-image - OK - All required tests passed (successes=5, 
skipped=0, failures=0, errors=0)
+```
+
+
  Manual testing with runqemu
  ===
  
diff --git a/meta-parsec/lib/oeqa/runtime/cases/parsec.py b/meta-parsec/lib/oeqa/runtime/cases/parsec.py

index 547f74c..d3d3f2e 100644
--- a/meta-parsec/lib/oeqa/runtime/cases/parsec.py
+++ b/meta-parsec/lib/oeqa/runtime/cases/parsec.py
@@ -1,33 +1,138 @@
  # Copyright (C) 2022 Armin Kuster 
+# Copyright (C) 2022 Anton Antonov 
  #
  import re
+from tempfile import mkstemp
  
  from oeqa.runtime.case import OERuntimeTestCase

  from oeqa.core.decorator.depends import OETestDepends
  from oeqa.runtime.decorator.package import OEHasPackage
+from oeqa.core.decorator.data import skipIfNotFeature
  
  class ParsecTest(OERuntimeTestCase):

+@classmethod
+def setUpClass(cls):
+cls.toml_file = '/etc/parsec/config.toml'
+
+def setUp(self):
+super(ParsecTest, self).setUp()
+if 'systemd' in self.tc.td['DISTRO_FEATURES']:
+self.parsec_status='systemctl status -l parsec'
+self.parsec_reload='systemctl restart parsec'
+else:
+self.parsec_status='pgrep -l parsec'
+self.parsec_reload='/etc/init.d/parsec reload'
+
+def copy_subconfig(self, cfg, provider):
+""" Copy a provider configuration to target and append it to Parsec config 
"""
+
+tmp_fd, tmp_path = mkstemp()
+with os.fdopen(tmp_fd, 'w') as f:
+f.write('\n'.join(cfg))
+
+(status, output) = self.target.copyTo(tmp_path, "%s-%s" % 
(self.toml_file, provider))
+self.assertEqual(status, 0, msg='File could not be copied.\n%s' % 
output)
+status, output = self.target.run('cat %s-%s >>%s' % (self.toml_file, 
provider, self.toml_file))
+os.remove(tmp_path)
+
+def check_parsec_providers(self, provider=None, prov_id=None):
+""" Get Parsec providers list and check for one if defined """
+
+status, output = self.target.run(self.parsec_status)
+self.assertEqual(status, 0, msg='Parsec service is not running.\n%s' % 
output)
+
+status, output = self.target.run('parsec-tool 

Re: [linux-yocto] [kernel-cache v5.15+] bpf: explicitly disable unpriv eBPF by default

[Bruce Ashfield]

merged.

SRCREVs will follow in a bit.

Things were delayed a bit .. for obvious reasons for anyone from
Ottawa.

Bruce

In message: [kernel-cache v5.15+] bpf: explicitly disable unpriv eBPF by default
on 12/05/2022 Paul Gortmaker wrote:

> This BPF_UNPRIV_DEFAULT_OFF option was introduced in v5.13 in
> 08389d888287 ("bpf: Add kconfig knob for disabling unpriv bpf by
> default")
> 
> But it was added as one of those somewhat confusing double negative
> things, and so the implicit "default n" that Kconfig processing meant
> that unpriv eBPF was enabled by default in v5.13 through v5.15.
> 
> In v5.16 it was corrected with commit 8a03e56b253e ("bpf: Disallow
> unprivileged bpf by default") since there were security concerns
> relating to having it enabled.
> 
> In that commit we see "Sync with what many distros are currently
> applying already, and disable unprivileged BPF by default."
> 
> In a generic x86-64 Yocto boot we currently see this in dmesg as:
> 
>   Spectre V2 : WARNING: Unprivileged eBPF is enabled with eIBRS on,
>   data leaks possible via Spectre v2 BHB attacks!
> 
> I've suggested the stable team do a backport to v5.15, but in any
> event, it probably makes sense for us to be explicit on our default.
> 
> Signed-off-by: Paul Gortmaker 
> 
> diff --git a/features/bpf/bpf.cfg b/features/bpf/bpf.cfg
> index b90e87a51e00..50c27ceb09c5 100644
> --- a/features/bpf/bpf.cfg
> +++ b/features/bpf/bpf.cfg
> @@ -3,4 +3,5 @@ CONFIG_BPF=y
>  CONFIG_BPF_SYSCALL=y
>  CONFIG_BPF_JIT=y
>  CONFIG_BPF_EVENTS=y
> +CONFIG_BPF_UNPRIV_DEFAULT_OFF=y
>  CONFIG_CGROUP_BPF=y
> -- 
> 2.25.1
> 

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

[yocto] [meta-security][PATCH] meta-parsec: Update Parsec runtime tests

[Anton Antonov]

Signed-off-by: Anton Antonov 
---
 meta-parsec/README.md |  65 +
 meta-parsec/lib/oeqa/runtime/cases/parsec.py  | 135 --
 .../images/security-parsec-image.bb   |   5 +-
 .../packagegroup-security-parsec.bb   |   1 -
 meta-tpm/classes/sanity-meta-tpm.bbclass  |   4 +-
 5 files changed, 191 insertions(+), 19 deletions(-)

diff --git a/meta-parsec/README.md b/meta-parsec/README.md
index 97026ea..f720cd2 100644
--- a/meta-parsec/README.md
+++ b/meta-parsec/README.md
@@ -88,6 +88,71 @@ https://github.com/meta-rust/cargo-bitbake
 2. Run cargo-bitbake inside the repository. It will produce a BB file.
 3. Create a new include file with SRC_URI and LIC_FILES_CHKSUM from the BB 
file.
 
+Automated Parsec testing with runqemu
+=
+
+ The Yocto build system has the ability to run a series of automated tests for 
qemu images.
+All the tests are actually commands run on the target system over ssh.
+
+ Meta-parsec includes automated unittests which run end to end Parsec tests.
+The tests are run against:
+- all providers pre-configured in the Parsec config file included in the image.
+- PKCS11 and TPM providers with software backends if softhsm and
+  swtpm packages included in the image.
+
+Meta-parsec also contains a recipe for `security-parsec-image` image with 
Parsec,
+softhsm and swtpm included.
+
+ Please notice that the account you use to run bitbake should have access to 
`/dev/kvm`.
+You might need to change permissions or add the account into `kvm` unix group.
+
+1. Testing Parsec with your own image where `parsec-service` and `parsec-tool` 
are already included.
+
+- Add into your `local.conf`:
+```
+INHERIT += "testimage"
+TEST_SUITES = "ping ssh parsec"
+```
+- Build your image
+```bash
+bitbake 
+```
+- Run tests
+```bash
+bitbake  -c testimage
+```
+
+2. Testing Parsec with pre-defined `security-parsec-image` image.
+
+- Add into your `local.conf`:
+```
+DISTRO_FEATURES += " tpm2"
+INHERIT += "testimage"
+TEST_SUITES = "ping ssh parsec"
+```
+- Build security-parsec-image image
+```bash
+bitbake security-parsec-image
+```
+- Run tests
+```bash
+bitbake security-parsec-image -c testimage
+```
+
+Output of a successfull tests run should look similar to:
+```
+RESULTS:
+RESULTS - ping.PingTest.test_ping: PASSED (0.05s)
+RESULTS - ssh.SSHTest.test_ssh: PASSED (0.25s)
+RESULTS - parsec.ParsecTest.test_all_providers: PASSED (1.84s)
+RESULTS - parsec.ParsecTest.test_pkcs11_provider: PASSED (2.91s)
+RESULTS - parsec.ParsecTest.test_tpm_provider: PASSED (3.33s)
+SUMMARY:
+security-parsec-image () - Ran 5 tests in 8.386s
+security-parsec-image - OK - All required tests passed (successes=5, 
skipped=0, failures=0, errors=0)
+```
+
+
 Manual testing with runqemu
 ===
 
diff --git a/meta-parsec/lib/oeqa/runtime/cases/parsec.py 
b/meta-parsec/lib/oeqa/runtime/cases/parsec.py
index 547f74c..d3d3f2e 100644
--- a/meta-parsec/lib/oeqa/runtime/cases/parsec.py
+++ b/meta-parsec/lib/oeqa/runtime/cases/parsec.py
@@ -1,33 +1,138 @@
 # Copyright (C) 2022 Armin Kuster 
+# Copyright (C) 2022 Anton Antonov 
 #
 import re
+from tempfile import mkstemp
 
 from oeqa.runtime.case import OERuntimeTestCase
 from oeqa.core.decorator.depends import OETestDepends
 from oeqa.runtime.decorator.package import OEHasPackage
+from oeqa.core.decorator.data import skipIfNotFeature
 
 class ParsecTest(OERuntimeTestCase):
+@classmethod
+def setUpClass(cls):
+cls.toml_file = '/etc/parsec/config.toml'
+
+def setUp(self):
+super(ParsecTest, self).setUp()
+if 'systemd' in self.tc.td['DISTRO_FEATURES']:
+self.parsec_status='systemctl status -l parsec'
+self.parsec_reload='systemctl restart parsec'
+else:
+self.parsec_status='pgrep -l parsec'
+self.parsec_reload='/etc/init.d/parsec reload'
+
+def copy_subconfig(self, cfg, provider):
+""" Copy a provider configuration to target and append it to Parsec 
config """
+
+tmp_fd, tmp_path = mkstemp()
+with os.fdopen(tmp_fd, 'w') as f:
+f.write('\n'.join(cfg))
+
+(status, output) = self.target.copyTo(tmp_path, "%s-%s" % 
(self.toml_file, provider))
+self.assertEqual(status, 0, msg='File could not be copied.\n%s' % 
output)
+status, output = self.target.run('cat %s-%s >>%s' % (self.toml_file, 
provider, self.toml_file))
+os.remove(tmp_path)
+
+def check_parsec_providers(self, provider=None, prov_id=None):
+""" Get Parsec providers list and check for one if defined """
+
+status, output = self.target.run(self.parsec_status)
+self.assertEqual(status, 0, msg='Parsec service is not running.\n%s' % 
output)
+
+status, output = self.target.run('parsec-tool list-providers')
+self.assertEqual(status, 0, msg='Cannot get a list of Parsec 
providers.\n%s' % output)
+if provider and 

[yocto] OpenEmbedded Happy Hour May 25 5pm/1700 UTC

[Tim Orling]

All,

You are cordially invited to the next OpenEmbedded Happy Hour on May 25
for Europe/Americas time zones @ 1700/5pm UTC (1pm ET / 10am PT).

https://www.openembedded.org/wiki/Calendar
https://www.openembedded.org/wiki/Happy_Hours
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+Happy+Hour+May+25=20220525T17=1440

Regards,
Tim "moto-timo" Orling

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

[yocto] [meta-selinux][master][kirkstone][PATCH 1/2] refpolicy: backport patches to fix policy issues for systemd 250

[Yi Zhao]

Backport the following patches to fix systemd-resolved and
systemd-netowrkd policy issues:
  systemd-systemd-resolved-is-linked-to-libselinux.patch
  sysnetwork-systemd-allow-DNS-resolution-over-io.syst.patch
  term-init-allow-systemd-to-watch-and-watch-reads-on-.patch
  systemd-add-file-transition-for-systemd-networkd-run.patch
  systemd-add-missing-file-context-for-run-systemd-net.patch
  systemd-add-file-contexts-for-systemd-network-genera.patch
  systemd-udev-allow-udev-to-read-systemd-networkd-run.patch

Signed-off-by: Yi Zhao 
---
 ...emd-resolved-is-linked-to-libselinux.patch | 33 +++
 ...md-allow-DNS-resolution-over-io.syst.patch | 63 +
 ...systemd-to-watch-and-watch-reads-on-.patch | 94 +++
 ...-transition-for-systemd-networkd-run.patch | 32 +++
 ...ing-file-context-for-run-systemd-net.patch | 29 ++
 ...-contexts-for-systemd-network-genera.patch | 38 
 ...ow-udev-to-read-systemd-networkd-run.patch | 34 +++
 .../refpolicy/refpolicy_common.inc|  7 ++
 8 files changed, 330 insertions(+)
 create mode 100644 
recipes-security/refpolicy/refpolicy/0062-systemd-systemd-resolved-is-linked-to-libselinux.patch
 create mode 100644 
recipes-security/refpolicy/refpolicy/0063-sysnetwork-systemd-allow-DNS-resolution-over-io.syst.patch
 create mode 100644 
recipes-security/refpolicy/refpolicy/0064-term-init-allow-systemd-to-watch-and-watch-reads-on-.patch
 create mode 100644 
recipes-security/refpolicy/refpolicy/0065-systemd-add-file-transition-for-systemd-networkd-run.patch
 create mode 100644 
recipes-security/refpolicy/refpolicy/0066-systemd-add-missing-file-context-for-run-systemd-net.patch
 create mode 100644 
recipes-security/refpolicy/refpolicy/0067-systemd-add-file-contexts-for-systemd-network-genera.patch
 create mode 100644 
recipes-security/refpolicy/refpolicy/0068-systemd-udev-allow-udev-to-read-systemd-networkd-run.patch

diff --git 
a/recipes-security/refpolicy/refpolicy/0062-systemd-systemd-resolved-is-linked-to-libselinux.patch
 
b/recipes-security/refpolicy/refpolicy/0062-systemd-systemd-resolved-is-linked-to-libselinux.patch
new file mode 100644
index 000..e0db7d3
--- /dev/null
+++ 
b/recipes-security/refpolicy/refpolicy/0062-systemd-systemd-resolved-is-linked-to-libselinux.patch
@@ -0,0 +1,33 @@
+From 52a4222397f5d3b28ca15a45bb2ace209a4afc3e Mon Sep 17 00:00:00 2001
+From: Kenton Groombridge 
+Date: Thu, 31 Mar 2022 13:09:10 -0400
+Subject: [PATCH] systemd: systemd-resolved is linked to libselinux
+
+systemd-resolved as of systemd 250 fails to start with this error:
+
+Failed to initialize SELinux labeling handle: No such file or directory
+
+Upstream-Status: Backport
+[https://github.com/SELinuxProject/refpolicy/commit/3a22db2410de479e5baa88f3f668a7a4ac198950]
+
+Signed-off-by: Kenton Groombridge 
+Signed-off-by: Yi Zhao 
+---
+ policy/modules/system/systemd.te | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/policy/modules/system/systemd.te 
b/policy/modules/system/systemd.te
+index 8cea6baa1..beb301cc6 100644
+--- a/policy/modules/system/systemd.te
 b/policy/modules/system/systemd.te
+@@ -1261,6 +1261,7 @@ fs_getattr_cgroup(systemd_resolved_t)
+ 
+ init_dgram_send(systemd_resolved_t)
+ 
++seutil_libselinux_linked(systemd_resolved_t)
+ seutil_read_file_contexts(systemd_resolved_t)
+ 
+ systemd_log_parse_environment(systemd_resolved_t)
+-- 
+2.25.1
+
diff --git 
a/recipes-security/refpolicy/refpolicy/0063-sysnetwork-systemd-allow-DNS-resolution-over-io.syst.patch
 
b/recipes-security/refpolicy/refpolicy/0063-sysnetwork-systemd-allow-DNS-resolution-over-io.syst.patch
new file mode 100644
index 000..63da7cd
--- /dev/null
+++ 
b/recipes-security/refpolicy/refpolicy/0063-sysnetwork-systemd-allow-DNS-resolution-over-io.syst.patch
@@ -0,0 +1,63 @@
+From 1ba0911e157c64ea15636c5707f38f1bdc9a46c8 Mon Sep 17 00:00:00 2001
+From: Kenton Groombridge 
+Date: Wed, 27 Apr 2022 01:09:52 -0400
+Subject: [PATCH] sysnetwork, systemd: allow DNS resolution over
+ io.systemd.Resolve
+
+Upstream-Status: Backport
+[https://github.com/SELinuxProject/refpolicy/commit/1a0acc9c0d8c7c49ad4ca2cabd44bc66450f45e0]
+
+Signed-off-by: Kenton Groombridge 
+Signed-off-by: Yi Zhao 
+---
+ policy/modules/system/sysnetwork.if |  1 +
+ policy/modules/system/systemd.if| 21 +
+ 2 files changed, 22 insertions(+)
+
+diff --git a/policy/modules/system/sysnetwork.if 
b/policy/modules/system/sysnetwork.if
+index 8664a67c8..140d48508 100644
+--- a/policy/modules/system/sysnetwork.if
 b/policy/modules/system/sysnetwork.if
+@@ -844,6 +844,7 @@ interface(`sysnet_dns_name_resolve',`
+   ifdef(`init_systemd',`
+   optional_policy(`
+   systemd_dbus_chat_resolved($1)
++  systemd_stream_connect_resolved($1)
+   ')
+   # This seems needed when the mymachines NSS module is used
+   optional_policy(`
+diff --git a/policy/modules/system/systemd.if 

[yocto] [meta-selinux][master][kirkstone][PATCH 2/2] refpolicy: add file context for findfs alternative

[Yi Zhao]

Add file context for findfs alternative which is provided by util-linux.

Signed-off-by: Yi Zhao 
---
 ...s-apply-policy-to-findfs-alternative.patch | 29 +++
 .../refpolicy/refpolicy_common.inc|  1 +
 2 files changed, 30 insertions(+)
 create mode 100644 
recipes-security/refpolicy/refpolicy/0069-fc-fstools-apply-policy-to-findfs-alternative.patch

diff --git 
a/recipes-security/refpolicy/refpolicy/0069-fc-fstools-apply-policy-to-findfs-alternative.patch
 
b/recipes-security/refpolicy/refpolicy/0069-fc-fstools-apply-policy-to-findfs-alternative.patch
new file mode 100644
index 000..6535a4b
--- /dev/null
+++ 
b/recipes-security/refpolicy/refpolicy/0069-fc-fstools-apply-policy-to-findfs-alternative.patch
@@ -0,0 +1,29 @@
+From 3e3ec39659ae068d20efbb5f13054d90960c3c3f Mon Sep 17 00:00:00 2001
+From: Yi Zhao 
+Date: Thu, 19 May 2022 16:51:49 +0800
+Subject: [PATCH] fc/fstools: apply policy to findfs alternative
+
+Add file context for findfs alternative which is provided by util-linux.
+
+Upstream-Status: Inappropriate [embedded specific]
+
+Signed-off-by: Yi Zhao 
+---
+ policy/modules/system/fstools.fc | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/policy/modules/system/fstools.fc 
b/policy/modules/system/fstools.fc
+index bef711850..91be0ef3d 100644
+--- a/policy/modules/system/fstools.fc
 b/policy/modules/system/fstools.fc
+@@ -77,6 +77,7 @@
+ /usr/sbin/fdisk   --  
gen_context(system_u:object_r:fsadm_exec_t,s0)
+ /usr/sbin/fdisk\.util-linux   --  
gen_context(system_u:object_r:fsadm_exec_t,s0)
+ /usr/sbin/findfs  --  
gen_context(system_u:object_r:fsadm_exec_t,s0)
++/usr/sbin/findfs\.util-linux  --  
gen_context(system_u:object_r:fsadm_exec_t,s0)
+ /usr/sbin/fsck.*  --  
gen_context(system_u:object_r:fsadm_exec_t,s0)
+ /usr/sbin/gdisk   --  
gen_context(system_u:object_r:fsadm_exec_t,s0)
+ /usr/sbin/hdparm  --  
gen_context(system_u:object_r:fsadm_exec_t,s0)
+-- 
+2.25.1
+
diff --git a/recipes-security/refpolicy/refpolicy_common.inc 
b/recipes-security/refpolicy/refpolicy_common.inc
index 1d5a5c0..bb0c0dd 100644
--- a/recipes-security/refpolicy/refpolicy_common.inc
+++ b/recipes-security/refpolicy/refpolicy_common.inc
@@ -84,6 +84,7 @@ SRC_URI += " \
 file://0066-systemd-add-missing-file-context-for-run-systemd-net.patch 
\
 file://0067-systemd-add-file-contexts-for-systemd-network-genera.patch 
\
 file://0068-systemd-udev-allow-udev-to-read-systemd-networkd-run.patch 
\
+file://0069-fc-fstools-apply-policy-to-findfs-alternative.patch \
 "
 
 S = "${WORKDIR}/refpolicy"
-- 
2.25.1


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

Re: [yocto] [ANNOUNCEMENT] Yocto Project 4.0.1 is Released

[Lee Chee Yang]

> Now that we also have release notes in the documentation (see
> https://docs.yoctoproject.org/migration-guides/release-notes-3.4.2.html
> for example, and the source code on
> https://git.yoctoproject.org/yocto-docs/tree/documentation/migration-
> guides/release-notes-3.4.2.rst),
> what about modifying the scripts to generate such notes directly in Sphinx
> syntax, and right before a new release is made, add them to the
> documentation directory?
This is in my to do list.  

Chee Yang  

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

[yocto] Enhancements/Bugs closed WW21

[Stephen Jolley]

All,

The below were the owners of enhancements or bugs closed during the last
week!


Who

Count


michael.opdenac...@bootlin.com

2


mhalst...@linuxfoundation.org

1


Grand Total

3

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


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

[yocto] Current high bug count owners for Yocto Project 4.1

[Stephen Jolley]

All,

Below is the list as of top 36 bug owners as of the end of WW21 of who have
open medium or higher bugs and enhancements against YP 4.1.   There are 110
possible work days left until the final release candidates for YP 4.1 needs
to be released.


Who

Count


michael.opdenac...@bootlin.com

38


ross.bur...@arm.com

23


david.re...@windriver.com

21


bruce.ashfi...@gmail.com

20


randy.macl...@windriver.com

17


sakib.sa...@windriver.com

12


richard.pur...@linuxfoundation.org

12


jpewhac...@gmail.com

9


tim.orl...@konsulko.com

8


saul.w...@windriver.com

7


kai.k...@windriver.com

4


jon.ma...@arm.com

4


pa...@zhukoff.net

4


mhalst...@linuxfoundation.org

3


akuster...@gmail.com

3


qi.c...@windriver.com

2


abongwabonal...@gmail.com

2


tvgamb...@gmail.com

2


hongxu@windriver.com

2


pgowda@gmail.com

2


aryaman.gu...@windriver.com

2


liezhi.y...@windriver.com

1


raj.k...@gmail.com

1


martin.bee...@online.de

1


shac...@vdoo.com

1


martin.ja...@gmail.com

1


alexandre.bell...@bootlin.com

1


aeh...@gmail.com

1


nicolas.deche...@linaro.org

1


sundeep.kokko...@gmail.com

1


thomas.per...@bootlin.com

1


mostthings...@gmail.com

1


jay.shen.t...@intel.com

1


kexin@windriver.com

1


open.sou...@oleksandr-kravchuk.com

1


alejan...@enedino.org

1


Grand Total

212

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


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

[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

[Stephen Jolley]

All,

 

The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means people
can find them. They're being listed on the triage page under the appropriate
heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please
review:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and
how to create a bugzilla account at:

https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 427
unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out
with these.  Bugs are split into two types, "true bugs" where things don't
work as they should and "enhancements" which are features we'd want to add
to the system.  There are also roughly four different "priority" classes
right now,  "4.1", "4.2", "4.99" and "Future", the more pressing/urgent
issues being in "4.1" and then "4.2".

 

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com
 ) an e-mail with the bug number you would
like and I will assign it to you (please make sure you have a Bugzilla
account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer
_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


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

[yocto] Yocto Project Status WW21`22

[Stephen Jolley]

Current Dev Position: YP 4.1 M1

Next Deadline: 30th May 2022 YP 4.1 M1 Build

 

Next Team Meetings:

*   Bug Triage meeting Thursday May 26th 7:30 am PDT (

https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
*   Monthly Project Meeting Tuesday June 7th at 8 am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Weekly Engineering Sync Tuesday May 24th  at 8 am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Twitch -  See  
https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

*   YP 4.0.1 was released
*   YP 4.1 M1 is due to build next week.
*   The Yocto Project Virtual Summit and OpenEmbedded Virtual Developer
Meeting both seemed to go well, many good presentations, demos and good
discussion. Thanks to everyone who helped organize it or attended.
*   There are some prototype scripts updating patchwork patch status for
OpenEmbedded-Core and BitBake which is covering about 75% of the patches to
the merged state along with revision information:

https://patchwork.yoctoproject.org/project/oe-core/list/
*   We have added a new "metrics" target on the autobuilder. This
currently has some simple patch status tracking information and can generate
a history graph but the hope is to extend this to CVE metrics and likely
other things. If anyone has interest in helping here, please let Richard
know.

 
https://autobuilder.yocto.io/pub/non-release/patchmetrics/

*   There are some known cve-check issues on kirkstone and dunfell,
patches addressing those issues are in testing.
*   Help is very much welcome in trying to resolve our autobuilder
intermittent issues. You can see the list of failures we're continuing to
see by searching for the "AB-INT" tag in bugzilla:

https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

 

Ways to contribute:

*   There are bugs identified as possible for newcomers to the project:

https://wiki.yoctoproject.org/wiki/Newcomers
*   There are bugs that are currently unassigned for YP 3.5. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.5_Unassigned_Enhan
cements.2FBugs
*   We'd welcome new maintainers for recipes in OE-Core. Please see the
list at:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/main
tainers.inc and discuss with the existing maintainer, or ask on the OE-Core
mailing list. We will likely move a chunk of these to "Unassigned" soon to
help facilitate this.
*   Help us resolve CVE issues:
 CVE metrics 

 

YP 4.1 Milestone Dates:

*   YP 4.1 M1 build date 2022/05/30
*   YP 4.1 M1 Release date 2022/06/10
*   YP 4.1 M2 build date 2022/07/11
*   YP 4.1 M2 Release date 2022/07/22
*   YP 4.1 M3 build date 2022/08/22
*   YP 4.1 M3 Release date 2022/09/02
*   YP 4.1 M4 build date 2022/10/03
*   YP 4.1 M4 Release date 2022/10/28

 

Upcoming dot releases:

*   YP 4.0.1 is released.
*   YP 3.1.17 build date 2022/06/06
*   YP 3.1.17 Release date 2022/06/17
*   YP 4.0.2 build date 2022/06/27
*   YP 4.0.2 Release date 2022/07/08
*   YP 3.1.18 build date 2022/07/18
*   YP 3.1.18 Release date 2022/07/29
*   YP 4.0.3 build date 2022/08/08
*   YP 4.0.3 Release date 2022/08/19
*   YP 3.1.19 build date 2022/08/29
*   YP 3.1.19 Release date 2022/09/09
*   YP 4.0.4 build date 2022/09/19
*   YP 4.0.4 Release date 2022/09/30
*   YP 3.1.20 build date 2022/10/10
*   YP 3.1.20 Release date 2022/10/21
*   YP 4.0.5 build date 2022/10/31
*   YP 4.0.5 Release date 2022/11/11

 

Tracking Metrics:

*   WDD 2479 (last week 2450) (

https://wiki.yoctoproject.org/charts/combo.html)
*   OE-Core/Poky Patch Metrics

*   Total patches found: 1171 (last week 1175)
*   Patches in the Pending State: 339 (29%) [last week 341 (29%)]

 

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

 

[yocto] Yocto-generated image does not pass the systemd-boot bootloader

[lucas]

Good morning,

I generated a Linux Image by following the intel document "Yocto Project*-based 
Board Support Package for Intel Atom® x6000E Series, and Intel® Pentium® and 
Celeron® N and J Series Pro"[1].

I built option C (mc:x86-2021-minimal:core-image-full-cmdline) using bitbake. 
And used bmaptool to prepare a bootable image (differently from the document, 
in my case the `.wic.bmap` file was not generated, only the .wic, so I had to 
pass the --nobmap option to bmaptool).

The Elkhart Lake CRB recognizes the bootable image, and boots into systemd-boot.

After selecting the only option in the systemd-boot bootloader, the following 
message is displayed: "EFI stub: Loaded initrd from command line option", and 
the boot process does not go any further, being stuck on a screen with this 
message.

I have tried, however, this same image on my desktop (a Xeon E5-2650 V3) and I 
can boot til the login screen and log into root. I can also test the image on 
qemu. But the boot process fails on the CRB.

What could be possibly hapenning?

[1]: 
https://cdrdv2.intel.com/v1/dl/getContent/619566?explicitVersion=true=619566

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

Re: [yocto] [ANNOUNCEMENT] Yocto Project 4.0.1 is Released

[Michael Opdenacker via lists.yoctoproject.org]

Hi Lee and others

On 5/24/22 05:01, Lee Chee Yang wrote:
>
> Hi
>
> We are pleased to announce the Yocto Project 4.0.1 Release is now
> available for download.
>
>
> http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.1/poky-8c489602f218bcf21de0d3c9f8cf620ea5f06430.tar.bz2
>
> http://mirrors.kernel.org/yocto/yocto/yocto-4.0.1/poky-8c489602f218bcf21de0d3c9f8cf620ea5f06430.tar.bz2
>
> A gpg signed version of these release notes is available at:
>
>  
>
> http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.1/RELEASENOTES
>

Many thanks for the new release!

Now that we also have release notes in the documentation (see
https://docs.yoctoproject.org/migration-guides/release-notes-3.4.2.html
for example, and the source code on
https://git.yoctoproject.org/yocto-docs/tree/documentation/migration-guides/release-notes-3.4.2.rst),
what about modifying the scripts to generate such notes directly in
Sphinx syntax, and right before a new release is made, add them to the
documentation directory?

This way I wouldn't have to convert the text release notes by hand, and
users would directly enjoy the HTML format, with links that are easy to
follow (currently for CVE details, but possibly, if generated by a
script, with links to individual).


What do you think?

Thanks again
Michael.

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


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

Re: [yocto] Building rust package fails with "can't find crate for `std`" #bitbake #toolchain #kirkstone

[martin . stolpe]

Forgot to mention that the build machine is x86_64 and I want to build for 
target aarch64.

This is the generated bitbake recipe:

# Auto-Generated by cargo-bitbake 0.3.15
#
inherit cargo pkgconfig

# If this is git based prefer versioned ones if they exist
# DEFAULT_PREFERENCE = "-1"

SRC_URI:append = " file://root/basestation/"
S = "${WORKDIR}/root/basestation"

DEPENDS:append = " \
libtss2 \
udev \
dbus \
"

# please note if you have entries that do not begin with crate://
# you must change them to how that package can be fetched
SRC_URI += " \
crate://crates.io/CoreFoundation-sys/0.1.4 \
crate://crates.io/IOKit-sys/0.1.5 \
crate://crates.io/ab_glyph_rasterizer/0.1.5 \
crate://crates.io/adler/1.0.2 \
crate://crates.io/adler32/1.2.0 \
crate://crates.io/aes/0.7.5 \
crate://crates.io/ahash/0.4.7 \
crate://crates.io/aho-corasick/0.6.10 \
crate://crates.io/aho-corasick/0.7.18 \
crate://crates.io/andrew/0.3.1 \
crate://crates.io/ansi_term/0.12.1 \
crate://crates.io/anyhow/1.0.52 \
crate://crates.io/arc-swap/0.4.8 \
crate://crates.io/async-channel/1.6.1 \
crate://crates.io/async-executor/1.4.1 \
crate://crates.io/async-global-executor/2.0.2 \
crate://crates.io/async-io/1.6.0 \
crate://crates.io/async-lock/2.4.0 \
crate://crates.io/async-mutex/1.4.0 \
crate://crates.io/async-std/1.10.0 \
crate://crates.io/async-task/4.0.3 \
crate://crates.io/async-trait/0.1.52 \
crate://crates.io/async_once/0.2.6 \
crate://crates.io/atk-sys/0.10.0 \
crate://crates.io/atk/0.9.0 \
crate://crates.io/atomic-waker/1.0.0 \
crate://crates.io/atty/0.2.14 \
crate://crates.io/autocfg/0.1.7 \
crate://crates.io/autocfg/1.0.1 \
crate://crates.io/base64/0.13.0 \
crate://crates.io/battery/0.7.8 \
crate://crates.io/bindgen/0.57.0 \
crate://crates.io/bindgen/0.59.2 \
crate://crates.io/bitflags/0.9.1 \
crate://crates.io/bitflags/1.3.2 \
crate://crates.io/block-buffer/0.9.0 \
crate://crates.io/block-modes/0.8.1 \
crate://crates.io/block-padding/0.2.1 \
crate://crates.io/block/0.1.6 \
crate://crates.io/blocking/1.1.0 \
crate://crates.io/btleplug/0.7.3 \
crate://crates.io/buf_redux/0.8.4 \
crate://crates.io/bumpalo/3.9.1 \
crate://crates.io/bytemuck/1.7.3 \
crate://crates.io/byteorder/1.4.3 \
crate://crates.io/bytes/0.5.6 \
crate://crates.io/bytes/1.1.0 \
crate://crates.io/cache-padded/1.2.0 \
crate://crates.io/cairo-rs/0.9.1 \
crate://crates.io/cairo-sys-rs/0.10.0 \
crate://crates.io/calloop/0.6.5 \
crate://crates.io/cc/1.0.72 \
crate://crates.io/cexpr/0.4.0 \
crate://crates.io/cexpr/0.6.0 \
crate://crates.io/cfg-if/0.1.10 \
crate://crates.io/cfg-if/1.0.0 \
crate://crates.io/chrono/0.4.19 \
crate://crates.io/cipher/0.3.0 \
crate://crates.io/clang-sys/1.3.0 \
crate://crates.io/clap/2.34.0 \
crate://crates.io/clap/3.0.10 \
crate://crates.io/clap_derive/3.1.4 \
crate://crates.io/cloudabi/0.0.3 \
crate://crates.io/cocoa-foundation/0.1.0 \
crate://crates.io/cocoa/0.24.0 \
crate://crates.io/color_quant/1.1.0 \
crate://crates.io/colored/1.9.3 \
crate://crates.io/com/0.2.0 \
crate://crates.io/com_macros/0.2.0 \
crate://crates.io/com_macros_support/0.2.0 \
crate://crates.io/concurrent-queue/1.2.2 \
crate://crates.io/const-sha1/0.2.0 \
crate://crates.io/core-foundation-sys/0.7.0 \
crate://crates.io/core-foundation-sys/0.8.3 \
crate://crates.io/core-foundation/0.7.0 \
crate://crates.io/core-foundation/0.9.2 \
crate://crates.io/core-graphics-types/0.1.1 \
crate://crates.io/core-graphics/0.19.2 \
crate://crates.io/core-graphics/0.22.3 \
crate://crates.io/core-video-sys/0.1.4 \
crate://crates.io/cpufeatures/0.2.1 \
crate://crates.io/crc32fast/1.3.0 \
crate://crates.io/crossbeam-channel/0.5.2 \
crate://crates.io/crossbeam-deque/0.8.1 \
crate://crates.io/crossbeam-epoch/0.9.6 \
crate://crates.io/crossbeam-queue/0.3.3 \
crate://crates.io/crossbeam-utils/0.8.6 \
crate://crates.io/crossbeam/0.8.1 \
crate://crates.io/crypto-mac/0.10.1 \
crate://crates.io/ctor/0.1.21 \
crate://crates.io/ctr/0.7.0 \
crate://crates.io/ctr/0.8.0 \
crate://crates.io/cty/0.2.2 \
crate://crates.io/custom_error/1.9.2 \
crate://crates.io/darling/0.10.2 \
crate://crates.io/darling_core/0.10.2 \
crate://crates.io/darling_macro/0.10.2 \
crate://crates.io/dashmap/4.0.2 \
crate://crates.io/dbus-codegen/0.9.1 \
crate://crates.io/dbus/0.9.5 \
crate://crates.io/deflate/0.8.6 \
crate://crates.io/derivative/2.2.0 \
crate://crates.io/diff/0.1.12 \
crate://crates.io/digest/0.9.0 \
crate://crates.io/dirs-sys/0.3.6 \
crate://crates.io/dirs/3.0.2 \
crate://crates.io/dispatch/0.2.0 \
crate://crates.io/displaydoc/0.2.3 \
crate://crates.io/dlib/0.4.2 \
crate://crates.io/dlib/0.5.0 \
crate://crates.io/docopt/1.1.1 \
crate://crates.io/downcast-rs/1.2.0 \
crate://crates.io/dyn-clone/1.0.4 \
crate://crates.io/either/1.6.1 \
crate://crates.io/env_logger/0.4.3 \
crate://crates.io/env_logger/0.8.4 \
crate://crates.io/env_logger/0.9.0 \
crate://crates.io/event-listener/2.5.1 \
crate://crates.io/extprim/1.7.1 \
crate://crates.io/fallible-iterator/0.2.0 \
crate://crates.io/fallible-streaming-iterator/0.1.9 \

Re: [yocto] Building rust package fails with "can't find crate for `std`" #bitbake #toolchain #rust #kirkstone

[Alexander Kanavin]

It helps if you can share the recipe that you're trying to build.

Alex

On Tue, 24 May 2022 at 10:08,  wrote:
>
> Hello,
>
> I'm trying to build a rust package which pulls openssl-sys as a dependency. 
> I've used cargo bitbake to create the build script.
>
> When I try to build the package using bitbake I get the following error 
> message:
> error: failed to run custom build command for `openssl-sys v0.9.72`
>
> Caused by:
>   process didn't exit successfully: 
> `/home/martin/yocto/build/tmp/work/cortexa72-poky-linux/basestation/0.1.0-r0/build/target/release/build/openssl-sys-0c915fe76d324495/build-script-main`
>  (exit status: 101)
>   --- stdout
>   cargo:rustc-cfg=const_fn
>   cargo:rerun-if-env-changed=AARCH64_POKY_LINUX_OPENSSL_NO_VENDOR
>   AARCH64_POKY_LINUX_OPENSSL_NO_VENDOR unset
>   cargo:rerun-if-env-changed=OPENSSL_NO_VENDOR
>   OPENSSL_NO_VENDOR unset
>
>   --- stderr
>   warning: target json file contains unused fields: has-elf-tls
>
>   warning: target json file contains unused fields: has-elf-tls
>
>   error[E0463]: can't find crate for `std`
> |
> = note: the `aarch64-poky-linux` target may not be installed
> = help: consider downloading the target with `rustup target add 
> aarch64-poky-linux`
>
> Does anyone know if it is possible to build the std (and core) crate for the 
> rust cross compile toolchain? I'm a beginner regarding Yocto/OpenEmbedded and 
> am really struggling to understand how the rust cross compile toolchain is 
> build. Any help would be appreciated.
>
> Best regards
> Martin
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57170): https://lists.yoctoproject.org/g/yocto/message/57170
Mute This Topic: https://lists.yoctoproject.org/mt/91306865/21656
Mute #toolchain:https://lists.yoctoproject.org/g/yocto/mutehashtag/toolchain
Mute #bitbake:https://lists.yoctoproject.org/g/yocto/mutehashtag/bitbake
Mute #rust:https://lists.yoctoproject.org/g/yocto/mutehashtag/rust
Mute #kirkstone:https://lists.yoctoproject.org/g/yocto/mutehashtag/kirkstone
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Building rust package fails with "can't find crate for `std`" #bitbake #toolchain #rust #kirkstone

[martin . stolpe]

Hello,

I'm trying to build a rust package which pulls openssl-sys as a dependency. 
I've used cargo bitbake to create the build script.

When I try to build the package using bitbake I get the following error message:
error: failed to run custom build command for `openssl-sys v0.9.72`

Caused by:
process didn't exit successfully: 
`/home/martin/yocto/build/tmp/work/cortexa72-poky-linux/basestation/0.1.0-r0/build/target/release/build/openssl-sys-0c915fe76d324495/build-script-main`
 (exit status: 101)
--- stdout
cargo:rustc-cfg=const_fn
cargo:rerun-if-env-changed=AARCH64_POKY_LINUX_OPENSSL_NO_VENDOR
AARCH64_POKY_LINUX_OPENSSL_NO_VENDOR unset
cargo:rerun-if-env-changed=OPENSSL_NO_VENDOR
OPENSSL_NO_VENDOR unset

--- stderr
warning: target json file contains unused fields: has-elf-tls

warning: target json file contains unused fields: has-elf-tls

error[E0463]: can't find crate for `std`
|
= note: the `aarch64-poky-linux` target may not be installed
= help: consider downloading the target with `rustup target add 
aarch64-poky-linux`

Does anyone know if it is possible to build the std (and core) crate for the 
rust cross compile toolchain? I'm a beginner regarding Yocto/OpenEmbedded and 
am really struggling to understand how the rust cross compile toolchain is 
build. Any help would be appreciated.

Best regards
Martin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57169): https://lists.yoctoproject.org/g/yocto/message/57169
Mute This Topic: https://lists.yoctoproject.org/mt/91306865/21656
Mute #bitbake:https://lists.yoctoproject.org/g/yocto/mutehashtag/bitbake
Mute #toolchain:https://lists.yoctoproject.org/g/yocto/mutehashtag/toolchain
Mute #rust:https://lists.yoctoproject.org/g/yocto/mutehashtag/rust
Mute #kirkstone:https://lists.yoctoproject.org/g/yocto/mutehashtag/kirkstone
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Index variables not unset in concat_dtb_helper

[Daniel Karlsson]

While testing Kirkstone I got a build error telling me that 
deploy-u-boot/u-boot.bin-flashloader is not found. The error is caused by not 
unsetting the index variables i and j in concat_dtb_helper. Is this something 
which is eligible for inclusion in the Kirkstone branch?

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

[yocto] yocto-check-layer fails checking signatures.

[Cardenas Jose Antonio (JCARDENA)]

Hi guys.

For learning purposes have used yocto-check-layer against meta-qt5 layer and I 
have got that fails checking signatures with this output:

INFO: test_signatures (common.CommonCheckLayer)
INFO:  ... FAIL

Stdout:
Loading cache...done.
Loaded 3995 entries from dependency cache.
WARNING: No bb files in default matched BBFILE_PATTERN_meta-geeking-bsp 
'^/home/geeking/workspace/yocto/meta-geeking-bsp/'

Summary: There was 1 WARNING message.
INFO: Traceback (most recent call last):
  File "/home/geeking/workspace/yocto/scripts/lib/checklayer/cases/common.py", 
line 81, in test_signatures
self.fail('Adding layer %s changed signatures.\n%s' % 
(self.tc.layer['name'], msg))
AssertionError: Adding layer meta-qt5 changed signatures.
39 signatures changed, initial differences (first hash before, second after):
   gdb:do_prepare_recipe_sysroot: 
3ebb2d1477e3eae773b471b0a588105804fe52ac00bd2da1c03a62baad61bd21 -> 
03cce43eee8f464a76ee7ba901aa1b750f1a9d3aa99afe51da5d5687c2aae948
  bitbake-diffsigs --task gdb do_prepare_recipe_sysroot --signature 
3ebb2d1477e3eae773b471b0a588105804fe52ac00bd2da1c03a62baad61bd21 
03cce43eee8f464a76ee7ba901aa1b750f1a9d3aa99afe51da5d5687c2aae948
  NOTE: Starting bitbake server...
  runtaskdeps changed:
  ['autoconf/autoconf_2.71.bb:do_populate_sysroot:virtual:native 
automake/automake_1.16.5.bb:do_populate_sysroot:virtual:native 
bison/bison_3.8.2.bb:do_populate_sysroot:virtual:native', 
-elfutils/elfutils_0.186.bb:do_populate_sysroot, 
'expat/expat_2.4.7.bb:do_populate_sysroot 
gcc/gcc-cross_11.2.bb:do_populate_sysroot 
gcc/gcc-runtime_11.2.bb:do_populate_sysroot gdb/gdb_11.2.bb:do_fetch 
gettext/gettext_0.21.bb:do_populate_sysroot:virtual:native 
glibc/glibc_2.35.bb:do_populate_sysroot gmp/gmp_6.2.1.bb:do_populate_sysroot 
libtool/libtool-cross_2.4.7.bb:do_populate_sysroot 
libtool/libtool-native_2.4.7.bb:do_populate_sysroot 
lttng/lttng-ust_2.13.2.bb:do_populate_sysroot 
ncurses/ncurses_6.3.bb:do_populate_sysroot 
pkgconfig/pkgconfig_git.bb:do_populate_sysroot:virtual:native 
pseudo/pseudo_git.bb:do_populate_sysroot:virtual:native', 
+python/python3_3.10.4.bb:do_populate_sysroot, 
'readline/readline_8.1.2.bb:do_populate_sysroot 
texinfo-dummy-native/texinfo-dummy-native.bb:do_populate_sysroot 
zlib/zlib_1.2.11.bb:do_populate_sysroot']
  elfutils/elfutils_0.186.bb:do_populate_sysroot with hash 
6bdde5ef4f55929012830ea7cbe8f3f0ef52c42d38832346d8eda3614e420f50
   changed to
  expat/expat_2.4.7.bb:do_populate_sysroot with hash 
c5fa50500fe0639a93edb56c76deebe115a4f43885fddabc939cca903ca1f5db
  expat/expat_2.4.7.bb:do_populate_sysroot with hash 
c5fa50500fe0639a93edb56c76deebe115a4f43885fddabc939cca903ca1f5db
   changed to
  gcc/gcc-cross_11.2.bb:do_populate_sysroot with hash 
8332df50d2a22a2003d6b9a77c21eccc4fafeb813af16c134a67b09e64e5a922
  gcc/gcc-cross_11.2.bb:do_populate_sysroot with hash 
8332df50d2a22a2003d6b9a77c21eccc4fafeb813af16c134a67b09e64e5a922
   changed to
  gcc/gcc-runtime_11.2.bb:do_populate_sysroot with hash 
440ce22e9e7e13ea604e5fd9b7c5d05272c05c76d8504b20fe8761527bb23d28
  gcc/gcc-runtime_11.2.bb:do_populate_sysroot with hash 
440ce22e9e7e13ea604e5fd9b7c5d05272c05c76d8504b20fe8761527bb23d28
   changed to
  gdb/gdb_11.2.bb:do_fetch with hash 
fc6369109e600af9324aa58c7b0cedcc52fd85400913b53ecabebdf990352add
  gdb/gdb_11.2.bb:do_fetch with hash 
fc6369109e600af9324aa58c7b0cedcc52fd85400913b53ecabebdf990352add
   changed to
  gettext/gettext_0.21.bb:do_populate_sysroot:virtual:native with hash 
32cc46ce9ab8e254999fe15746e6ac565211f08f248902a303acea27318ff6a5
  gettext/gettext_0.21.bb:do_populate_sysroot:virtual:native with hash 
32cc46ce9ab8e254999fe15746e6ac565211f08f248902a303acea27318ff6a5
   changed to
  glibc/glibc_2.35.bb:do_populate_sysroot with hash 
805ac1d9b8ed5009950195c8a0ad39052c612438b26acec72deff9c440f9dc8c
  glibc/glibc_2.35.bb:do_populate_sysroot with hash 
805ac1d9b8ed5009950195c8a0ad39052c612438b26acec72deff9c440f9dc8c
   changed to
  gmp/gmp_6.2.1.bb:do_populate_sysroot with hash 
14f5ccc5581727d9816bd3d994634a110104fce81d906a9680f023de221e
  gmp/gmp_6.2.1.bb:do_populate_sysroot with hash 
14f5ccc5581727d9816bd3d994634a110104fce81d906a9680f023de221e
   changed to
  libtool/libtool-cross_2.4.7.bb:do_populate_sysroot with hash 
47db5d7b09f5366e991add0acac1c1070ba8719df6b7e230eade5b56fb91cdc4
  libtool/libtool-cross_2.4.7.bb:do_populate_sysroot with hash 
47db5d7b09f5366e991add0acac1c1070ba8719df6b7e230eade5b56fb91cdc4
   changed to
  libtool/libtool-native_2.4.7.bb:do_populate_sysroot with hash 
ee4d5493221cd8cad2d048e512dd0b15a7a9ee3022e71ec92262bdd3ab7f056f
  libtool/libtool-native_2.4.7.bb:do_populate_sysroot with hash 
ee4d5493221cd8cad2d048e512dd0b15a7a9ee3022e71ec92262bdd3ab7f056f
   changed to
  lttng/lttng-ust_2.13.2.bb:do_populate_sysroot with hash