[OE-core] [master][PATCH] qemu: CVE-2022-35414 can perform an uninitialized read on the translate_fail path, leading to an io_readx or io_writex crash

[Hitendra Prajapati]

Upstream-Status: Backport 
[https://github.com/qemu/qemu/commit/418ade7849ce7641c0f7333718caf5091a02fd4c]
CVE: CVE-2022-35414
Signed-off-by: Hitendra Prajapati 
---
 meta/recipes-devtools/qemu/qemu.inc   |  1 +
 .../qemu/qemu/CVE-2022-35414.patch| 53 +++
 2 files changed, 54 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2022-35414.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index c9e48f4a5a..0db6701735 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -27,6 +27,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \

file://0008-tests-meson.build-use-relative-path-to-refer-to-file.patch \

file://0009-Define-MAP_SYNC-and-MAP_SHARED_VALIDATE-on-needed-li.patch \

file://0010-hw-pvrdma-Protect-against-buggy-or-malicious-guest-d.patch \
+   file://CVE-2022-35414.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2022-35414.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2022-35414.patch
new file mode 100644
index 00..fe79a749ae
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2022-35414.patch
@@ -0,0 +1,53 @@
+From a10c33942dc8cb31b3762b9dd4adde4c490eed9c Mon Sep 17 00:00:00 2001
+From: Hitendra Prajapati 
+Date: Wed, 3 Aug 2022 10:11:11 +0530
+Subject: [PATCH] CVE-2022-35414
+
+Upstream-Status: Backport 
[https://github.com/qemu/qemu/commit/418ade7849ce7641c0f7333718caf5091a02fd4c]
+CVE: CVE-2022-35414
+Signed-off-by: Hitendra Prajapati 
+---
+ softmmu/physmem.c | 13 -
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+diff --git a/softmmu/physmem.c b/softmmu/physmem.c
+index 4e1b27a20..ad8a90dec 100644
+--- a/softmmu/physmem.c
 b/softmmu/physmem.c
+@@ -669,7 +669,7 @@ void tcg_iommu_init_notifier_list(CPUState *cpu)
+ 
+ /* Called from RCU critical section */
+ MemoryRegionSection *
+-address_space_translate_for_iotlb(CPUState *cpu, int asidx, hwaddr addr,
++address_space_translate_for_iotlb(CPUState *cpu, int asidx, hwaddr orig_addr,
+   hwaddr *xlat, hwaddr *plen,
+   MemTxAttrs attrs, int *prot)
+ {
+@@ -678,6 +678,7 @@ address_space_translate_for_iotlb(CPUState *cpu, int 
asidx, hwaddr addr,
+ IOMMUMemoryRegionClass *imrc;
+ IOMMUTLBEntry iotlb;
+ int iommu_idx;
++hwaddr addr = orig_addr;
+ AddressSpaceDispatch *d =
+ qatomic_rcu_read(>cpu_ases[asidx].memory_dispatch);
+ 
+@@ -722,6 +723,16 @@ address_space_translate_for_iotlb(CPUState *cpu, int 
asidx, hwaddr addr,
+ return section;
+ 
+ translate_fail:
++/*
++ * We should be given a page-aligned address -- certainly
++ * tlb_set_page_with_attrs() does so.  The page offset of xlat
++ * is used to index sections[], and PHYS_SECTION_UNASSIGNED = 0.
++ * The page portion of xlat will be logged by memory_region_access_valid()
++ * when this memory access is rejected, so use the original untranslated
++ * physical address.
++ */
++assert((orig_addr & ~TARGET_PAGE_MASK) == 0);
++*xlat = orig_addr;
+ return >map.sections[PHYS_SECTION_UNASSIGNED];
+ }
+ 
+-- 
+2.25.1
+
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168802): 
https://lists.openembedded.org/g/openembedded-core/message/168802
Mute This Topic: https://lists.openembedded.org/mt/92786848/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] pybootchartgui: render memory pressure as well

[Martin Jansa]

* memory pressure is already collected in buildstats, render it as well
  when available
---
 scripts/pybootchartgui/pybootchartgui/draw.py | 44 +--
 .../pybootchartgui/pybootchartgui/parsing.py  |  5 +++
 .../pybootchartgui/pybootchartgui/samples.py  |  8 
 3 files changed, 54 insertions(+), 3 deletions(-)

diff --git a/scripts/pybootchartgui/pybootchartgui/draw.py 
b/scripts/pybootchartgui/pybootchartgui/draw.py
index a13df3a3fa..3926bdd11e 100644
--- a/scripts/pybootchartgui/pybootchartgui/draw.py
+++ b/scripts/pybootchartgui/pybootchartgui/draw.py
@@ -88,6 +88,10 @@ CPU_PRESSURE_TOTAL_COLOR = CPU_COLOR
 IO_PRESSURE_AVG10_COLOR = (0.0, 0.0, 0.0, 1.0)
 # delta total IO pressure color
 IO_PRESSURE_TOTAL_COLOR = IO_COLOR
+# avg10 memory pressure color
+MEM_PRESSURE_AVG10_COLOR = (0.0, 0.0, 0.0, 1.0)
+# delta total memory pressure color
+MEM_PRESSURE_TOTAL_COLOR = DISK_TPUT_COLOR
 
 
 
@@ -460,12 +464,12 @@ def render_charts(ctx, options, clip, trace, curr_y, w, 
h, sec_w):
 
 curr_y = curr_y + 30 + bar_h
 
-# render delta total io
+# render I/O pressure chart
 if trace.io_pressure:
 draw_legend_line(ctx, "avg10 I/O Pressure", IO_PRESSURE_AVG10_COLOR, 
off_x, curr_y+20, leg_s)
 draw_legend_box(ctx, "delta total I/O Pressure", 
IO_PRESSURE_TOTAL_COLOR, off_x + 140, curr_y+20, leg_s)
 
-# render avg10 io
+# render delta total io
 chart_rect = (off_x, curr_y+30, w, bar_h)
 if clip_visible (clip, chart_rect):
 draw_box_ticks (ctx, chart_rect, sec_w)
@@ -474,7 +478,7 @@ def render_charts(ctx, options, clip, trace, curr_y, w, h, 
sec_w):
 [(sample.time, sample.deltaTotal) for sample in 
trace.io_pressure], \
 proc_tree, None)
 
-# render io pressure
+# render avg10 io
 max_sample = max (trace.io_pressure, key = lambda s: s.avg10)
 if clip_visible (clip, chart_rect):
 draw_chart (ctx, IO_PRESSURE_AVG10_COLOR, False, chart_rect, \
@@ -487,11 +491,45 @@ def render_charts(ctx, options, clip, trace, curr_y, w, 
h, sec_w):
 if (pos_x < off_x + 245):
 shift_x, shift_y = 5, 40
 
+
 label = "%d%%" % (max_sample.avg10)
 draw_text (ctx, label, IO_PRESSURE_AVG10_COLOR, pos_x + shift_x, 
curr_y + shift_y)
 
 curr_y = curr_y + 30 + bar_h
 
+# render MEM pressure chart
+if trace.mem_pressure:
+draw_legend_line(ctx, "avg10 MEM Pressure", MEM_PRESSURE_AVG10_COLOR, 
off_x, curr_y+20, leg_s)
+draw_legend_box(ctx, "delta total MEM Pressure", 
MEM_PRESSURE_TOTAL_COLOR, off_x + 140, curr_y+20, leg_s)
+
+# render delta total mem
+chart_rect = (off_x, curr_y+30, w, bar_h)
+if clip_visible (clip, chart_rect):
+draw_box_ticks (ctx, chart_rect, sec_w)
+draw_annotations (ctx, proc_tree, trace.times, chart_rect)
+draw_chart (ctx, MEM_PRESSURE_TOTAL_COLOR, True, chart_rect, \
+[(sample.time, sample.deltaTotal) for sample in 
trace.mem_pressure], \
+proc_tree, None)
+
+# render avg10 mem
+max_sample = max (trace.mem_pressure, key = lambda s: s.avg10)
+if clip_visible (clip, chart_rect):
+draw_chart (ctx, MEM_PRESSURE_AVG10_COLOR, False, chart_rect, \
+[(sample.time, sample.avg10) for sample in 
trace.mem_pressure], \
+proc_tree, None)
+
+pos_x = off_x + ((max_sample.time - proc_tree.start_time) * w / 
proc_tree.duration)
+
+shift_x, shift_y = -20, 20
+if (pos_x < off_x + 245):
+shift_x, shift_y = 5, 40
+
+
+label = "%d%%" % (max_sample.avg10)
+draw_text (ctx, label, MEM_PRESSURE_AVG10_COLOR, pos_x + shift_x, 
curr_y + shift_y)
+
+curr_y = curr_y + 30 + bar_h
+
 # render disk space usage
 #
 # Draws the amount of disk space used on each volume relative to the
diff --git a/scripts/pybootchartgui/pybootchartgui/parsing.py 
b/scripts/pybootchartgui/pybootchartgui/parsing.py
index 004d6fb953..362d5153e8 100644
--- a/scripts/pybootchartgui/pybootchartgui/parsing.py
+++ b/scripts/pybootchartgui/pybootchartgui/parsing.py
@@ -51,6 +51,7 @@ class Trace:
 self.monitor_disk = None
 self.cpu_pressure = []
 self.io_pressure = []
+self.mem_pressure = []
 self.times = [] # Always empty, but expected by draw.py when drawing 
system charts.
 
 if len(paths):
@@ -564,6 +565,8 @@ def _parse_pressure_logs(file, filename):
 pressure_stats = []
 if filename == "cpu.log":
 SamplingClass = CPUPressureSample
+elif filename == "memory.log":
+SamplingClass = MemPressureSample
 else:
 SamplingClass = IOPressureSample
 for time, lines in _parse_timed_blocks(file):
@@ -769,6 +772,8 @@ def _do_parse(writer, state, filename, file):
 state.cpu_pressure = _parse_pressure_logs(file, name)
 

Re: [OE-core] [dunfell][PATCH] u-boot: fix CVE-2022-34835

[Tom Rini]

On Tue, Aug 02, 2022 at 07:17:23AM -1000, Steve Sakoman wrote:
> On Mon, Aug 1, 2022 at 8:04 AM Tom Rini  wrote:
> >
> > On Sun, Jul 31, 2022 at 01:01:27PM +0200, Minjae Kim wrote:
> >
> > > i2c: fix stack buffer overflow vulnerability in i2c md command
> > >
> > > CVE: CVE-2022-34835
> > >
> > > Signed-off-by:Minjae Kim 
> >
> > Reviewed-by: Tom Rini 
> 
> Hi Tom,
> 
> Thanks for reviewing.
> 
> Did you build test this? I'm getting do_patch errors on both local and
> autobuilder builds.

Ah, no, just that it's indeed the whole of the fix for that CVE,
backported.  There are a handful of them fixed in v2022.07, fwiw.

-- 
Tom

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168800): 
https://lists.openembedded.org/g/openembedded-core/message/168800
Mute This Topic: https://lists.openembedded.org/mt/92725052/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] [dunfell][PATCH] u-boot: fix CVE-2022-34835

[Steve Sakoman]

On Mon, Aug 1, 2022 at 8:04 AM Tom Rini  wrote:
>
> On Sun, Jul 31, 2022 at 01:01:27PM +0200, Minjae Kim wrote:
>
> > i2c: fix stack buffer overflow vulnerability in i2c md command
> >
> > CVE: CVE-2022-34835
> >
> > Signed-off-by:Minjae Kim 
>
> Reviewed-by: Tom Rini 

Hi Tom,

Thanks for reviewing.

Did you build test this? I'm getting do_patch errors on both local and
autobuilder builds.

Steve

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168799): 
https://lists.openembedded.org/g/openembedded-core/message/168799
Mute This Topic: https://lists.openembedded.org/mt/92725052/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][kirkstone 01/29] qemu: CVE-2022-35414 can perform an uninitialized read on the translate_fail path, leading to an io_readx or io_writex crash

[Steve Sakoman]

On Tue, Aug 2, 2022 at 4:41 AM Richard Purdie
 wrote:
>
> On Fri, 2022-07-29 at 04:46 -1000, Steve Sakoman wrote:
> > From: Hitendra Prajapati 
> >
> > Source: https://github.com/qemu/qemu
> > MR: 119830
> > Type: Security Fix
> > Disposition: Backport from 
> > https://github.com/qemu/qemu/commit/418ade7849ce7641c0f7333718caf5091a02fd4c
> > ChangeID: 41d6646e06319e629da574b9b2e8a3a197a73441
> > Description:
> > CVE-2022-35414 qemu: can perform an uninitialized read on the 
> > translate_fail path, leading to an io_readx or io_writex crash.
> >
> > Signed-off-by: Hitendra Prajapati 
> > Signed-off-by: Steve Sakoman 
> > ---
> >  meta/recipes-devtools/qemu/qemu.inc   |  1 +
> >  .../qemu/qemu/CVE-2022-35414.patch| 53 +++
> >  2 files changed, 54 insertions(+)
> >  create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2022-35414.patch
>
> This isn't fixed in master yet?

Hi Hitendra,

Have you tried this patch on master branch? CVE-2022-35414 is the sole
open CVE on master so it would be great to get this fixed there too!

Steve

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168798): 
https://lists.openembedded.org/g/openembedded-core/message/168798
Mute This Topic: https://lists.openembedded.org/mt/92692270/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][kirkstone 11/29] xserver-xorg: update 21.1.3 -> 21.1.4

[Steve Sakoman]

On Tue, Aug 2, 2022 at 6:19 AM Marta Rybczynska  wrote:
>
> On Tue, Aug 2, 2022 at 4:57 PM Steve Sakoman  wrote:
> >
> > On Tue, Aug 2, 2022 at 4:37 AM Steve Sakoman via
> > lists.openembedded.org 
> > wrote:
> > >
> > > On Mon, Aug 1, 2022 at 7:56 PM Marta Rybczynska  
> > > wrote:
> > > >
> > > > On Fri, Jul 29, 2022 at 4:47 PM Steve Sakoman  wrote:
> > > > >
> > > > > From: Alexander Kanavin 
> > > > >
> > > > > Security update
> > > > >
> > > >
> > > > With this update we're getting:
> > > >
> > > > Parsing recipes...WARNING:
> > > > /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb:
> > > > Exception during build_dependencies for AUTOREV
> > > > WARNING: 
> > > > /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb:
> > > > Error during finalise of
> > > > /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb
> > > > ERROR: ExpansionError during parsing
> > > > /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb
> > > > Traceback (most recent call last):
> > > > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/git.py", line
> > > > 249, in Git.urldata_init(ud= > > > 0x7fc0cb054970>, d= > > > 0x7fc0cafbd0d0>):
> > > > > ud.setup_revisions(d)
> > > > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
> > > > line 1347, in FetchData.setup_revisions(d= > > > object at 0x7fc0cafbd0d0>):
> > > > for name in self.names:
> > > > > self.revisions[name] = srcrev_internal_helper(self, d, name)
> > > > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
> > > > line 1212, in srcrev_internal_helper(ud= > > > 0x7fc0cb054970>, d=,
> > > > name='default'):
> > > > if srcrev == "AUTOINC":
> > > > > srcrev = ud.method.latest_revision(ud, d, name)
> > > > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
> > > > line 1624, in Git.latest_revision(ud= > > > 0x7fc0cb054970>, d=,
> > > > name='default'):
> > > > except KeyError:
> > > > > revs[key] = rev = self._latest_revision(ud, d, name)
> > > > return rev
> > > > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/git.py", line
> > > > 752, in Git._latest_revision(ud= > > > 0x7fc0cb054970>, d=,
> > > > name='default'):
> > > > return sha1
> > > > > raise bb.fetch2.FetchError("Unable to resolve '%s' in upstream git 
> > > > > repository in git ls-remote output for %s" % \
> > > > (ud.unresolvedrev[name], ud.host+ud.path))
> > > > bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
> > > > expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception
> > > > FetchError: Fetcher failure: Unable to resolve '21.1.4_2022_05_23' in
> > > > upstream git repository in git ls-remote output for
> > > > github.com/JeffyCN/xorg-xserver
> > >
> > > Is there a bbappend to xserver-xorg somewhere in your layers?
> > >
> > > The recipe in core is building from a tarball fetched from
> > > https://www.x.org/releases/
> > >
> > > It appears that a bbappend is changing this to look in
> > > github.com/JeffyCN/xorg-xserver, which doesn't have 21.1.4
> > >
> > > So my best guess is that the issue is with a bbappend in some other
> > > layer, not with this patch in oe-core.
> >
> > I'm going to guess you've included meta-rockchip in your build which
> > does include this bbappend:
> >
> > https://github.com/JeffyCN/meta-rockchip/blob/master/recipes-graphics/xorg-xserver/xserver-xorg_%25.bbappend
> >
> > That's where github.com/JeffyCN/xorg-xserver and the AUTOREV are coming 
> > from.
> >
>
> Oh my yes. I was grepping around in meta-zephyr as it fails only there.

I'm not going to hold up this patch based on the meta-rockchip
bbappend.  IMHO the use of a fork of xserver-xorg and an AUTOREV is
beyond the scope of what the LTS should deal with!

Steve

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168797): 
https://lists.openembedded.org/g/openembedded-core/message/168797
Mute This Topic: https://lists.openembedded.org/mt/92692286/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] Yocto Project Status 02 August 2022 (WW31)

[Steve Sakoman]

On Tue, Aug 2, 2022 at 6:30 AM Marta Rybczynska  wrote:
>
> On Tue, Aug 2, 2022 at 4:49 PM Neal Caidin  
> wrote:
> >
> > Current Dev Position: YP 4.1 M3
> >
> > Next Deadline: 22nd August 2022 YP 4.1 M3 Build
> >
> >
> > Next Team Meetings:
> >
> > Bug Triage meeting Thursday August 4th 7:30 am PDT 
> > (https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
> >
> > Weekly Project Engineering Sync Tuesday August  2nd  at 8 am PDT 
> > (https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09)
> >
> > Twitch -  See https://www.twitch.tv/theyoctojester
> >
> >
> > Key Status/Updates:
> >
> > YP 4.1 M2 was released
> >
> > YP 3.1.18 passed QA and is due to be released
> >
> > The debug file mapping issues have moved slightly further forward thanks to 
> > some help from Ross but are stalling due to insufficient developer time 
> > available to resolve the issues.
> >
> > Some rust toolchain improvements did merge, including an automated rust 
> > toolchain test. The bulk of the rework is stalled on a handful of remaining 
> > issues, particularly a couple of reproducibility problems but also a mips 
> > n32 toolchain issue.
> >
> > We have one open CVE on master against qemu, help to backport that fix 
> > would be very welcome to keep the numbers down. CVEs in kirkstone (LTS) 
> > significantly reduced.
>
> Do you mean CVE-2022-35414?

Yes!  We have a patch under review for kirkstone:
https://lists.openembedded.org/g/openembedded-core/message/168636

I think Richard is hoping someone will see if that also will work on
master and if so send a patch.

Steve

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168796): 
https://lists.openembedded.org/g/openembedded-core/message/168796
Mute This Topic: https://lists.openembedded.org/mt/92771754/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] Yocto Project Status 02 August 2022 (WW31)

[Marta Rybczynska]

On Tue, Aug 2, 2022 at 4:49 PM Neal Caidin  wrote:
>
> Current Dev Position: YP 4.1 M3
>
> Next Deadline: 22nd August 2022 YP 4.1 M3 Build
>
>
> Next Team Meetings:
>
> Bug Triage meeting Thursday August 4th 7:30 am PDT 
> (https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
>
> Weekly Project Engineering Sync Tuesday August  2nd  at 8 am PDT 
> (https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09)
>
> Twitch -  See https://www.twitch.tv/theyoctojester
>
>
> Key Status/Updates:
>
> YP 4.1 M2 was released
>
> YP 3.1.18 passed QA and is due to be released
>
> The debug file mapping issues have moved slightly further forward thanks to 
> some help from Ross but are stalling due to insufficient developer time 
> available to resolve the issues.
>
> Some rust toolchain improvements did merge, including an automated rust 
> toolchain test. The bulk of the rework is stalled on a handful of remaining 
> issues, particularly a couple of reproducibility problems but also a mips n32 
> toolchain issue.
>
> We have one open CVE on master against qemu, help to backport that fix would 
> be very welcome to keep the numbers down. CVEs in kirkstone (LTS) 
> significantly reduced.

Do you mean CVE-2022-35414?

Regards,
Marta

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168795): 
https://lists.openembedded.org/g/openembedded-core/message/168795
Mute This Topic: https://lists.openembedded.org/mt/92771754/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] kernel.bbclass: Add shared_workdir_prepare task

[Jacob Kroon]

On 7/20/22 13:30, Jose Quaresma wrote:

The task do_compile_kernelmodules runs after the shared_workdir and
is installing some files in STAGING_KERNEL_BUILDDIR, this can races
in other recipes that depends on "virtual/kernel:do_shared_workdir"
as the STAGING_KERNEL_BUILDDIR is not fully populated when the
shared_workdir task ends.

To address this issue a new task is added in place of the previows one
so the shared_workdir will run after the do_compile_kernelmodules and
the new shared_workdir_prepare will replce of the old shared_workdir.

Signed-off-by: Jose Quaresma 
---
  meta/classes/kernel.bbclass | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 5d2f17c3be..5558769c92 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -504,7 +504,8 @@ do_kernel_version_sanity_check() {
exit 0
  }
  
-addtask shared_workdir after do_compile before do_compile_kernelmodules

+addtask shared_workdir_prepare after do_compile before do_compile_kernelmodules
+addtask shared_workdir after do_compile_kernelmodules
  addtask shared_workdir_setscene
  
  do_shared_workdir_setscene () {

@@ -520,10 +521,16 @@ emit_depmod_pkgdata() {
  
  PACKAGEFUNCS += "emit_depmod_pkgdata"
  
-do_shared_workdir[cleandirs] += " ${STAGING_KERNEL_BUILDDIR}"

  do_shared_workdir () {
cd ${B}
  
+	kerneldir=${STAGING_KERNEL_BUILDDIR}

+}


Does the above do anything actually useful ? I thought neither the 
current workdir or a variable set in a shell function would be preserved 
for the next task ?



+
+do_shared_workdir_prepare[cleandirs] += " ${STAGING_KERNEL_BUILDDIR}"
+do_shared_workdir_prepare () {
+   cd ${B}
+
kerneldir=${STAGING_KERNEL_BUILDDIR}
install -d $kerneldir
  


Jacob

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168794): 
https://lists.openembedded.org/g/openembedded-core/message/168794
Mute This Topic: https://lists.openembedded.org/mt/92502346/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][kirkstone 11/29] xserver-xorg: update 21.1.3 -> 21.1.4

[Marta Rybczynska]

On Tue, Aug 2, 2022 at 4:57 PM Steve Sakoman  wrote:
>
> On Tue, Aug 2, 2022 at 4:37 AM Steve Sakoman via
> lists.openembedded.org 
> wrote:
> >
> > On Mon, Aug 1, 2022 at 7:56 PM Marta Rybczynska  
> > wrote:
> > >
> > > On Fri, Jul 29, 2022 at 4:47 PM Steve Sakoman  wrote:
> > > >
> > > > From: Alexander Kanavin 
> > > >
> > > > Security update
> > > >
> > >
> > > With this update we're getting:
> > >
> > > Parsing recipes...WARNING:
> > > /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb:
> > > Exception during build_dependencies for AUTOREV
> > > WARNING: 
> > > /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb:
> > > Error during finalise of
> > > /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb
> > > ERROR: ExpansionError during parsing
> > > /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb
> > > Traceback (most recent call last):
> > > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/git.py", line
> > > 249, in Git.urldata_init(ud= > > 0x7fc0cb054970>, d= > > 0x7fc0cafbd0d0>):
> > > > ud.setup_revisions(d)
> > > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
> > > line 1347, in FetchData.setup_revisions(d= > > object at 0x7fc0cafbd0d0>):
> > > for name in self.names:
> > > > self.revisions[name] = srcrev_internal_helper(self, d, name)
> > > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
> > > line 1212, in srcrev_internal_helper(ud= > > 0x7fc0cb054970>, d=,
> > > name='default'):
> > > if srcrev == "AUTOINC":
> > > > srcrev = ud.method.latest_revision(ud, d, name)
> > > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
> > > line 1624, in Git.latest_revision(ud= > > 0x7fc0cb054970>, d=,
> > > name='default'):
> > > except KeyError:
> > > > revs[key] = rev = self._latest_revision(ud, d, name)
> > > return rev
> > > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/git.py", line
> > > 752, in Git._latest_revision(ud= > > 0x7fc0cb054970>, d=,
> > > name='default'):
> > > return sha1
> > > > raise bb.fetch2.FetchError("Unable to resolve '%s' in upstream git 
> > > > repository in git ls-remote output for %s" % \
> > > (ud.unresolvedrev[name], ud.host+ud.path))
> > > bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
> > > expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception
> > > FetchError: Fetcher failure: Unable to resolve '21.1.4_2022_05_23' in
> > > upstream git repository in git ls-remote output for
> > > github.com/JeffyCN/xorg-xserver
> >
> > Is there a bbappend to xserver-xorg somewhere in your layers?
> >
> > The recipe in core is building from a tarball fetched from
> > https://www.x.org/releases/
> >
> > It appears that a bbappend is changing this to look in
> > github.com/JeffyCN/xorg-xserver, which doesn't have 21.1.4
> >
> > So my best guess is that the issue is with a bbappend in some other
> > layer, not with this patch in oe-core.
>
> I'm going to guess you've included meta-rockchip in your build which
> does include this bbappend:
>
> https://github.com/JeffyCN/meta-rockchip/blob/master/recipes-graphics/xorg-xserver/xserver-xorg_%25.bbappend
>
> That's where github.com/JeffyCN/xorg-xserver and the AUTOREV are coming from.
>

Oh my yes. I was grepping around in meta-zephyr as it fails only there.

Marta

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168793): 
https://lists.openembedded.org/g/openembedded-core/message/168793
Mute This Topic: https://lists.openembedded.org/mt/92692286/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][kirkstone 11/29] xserver-xorg: update 21.1.3 -> 21.1.4

[Steve Sakoman]

On Tue, Aug 2, 2022 at 4:37 AM Steve Sakoman via
lists.openembedded.org 
wrote:
>
> On Mon, Aug 1, 2022 at 7:56 PM Marta Rybczynska  wrote:
> >
> > On Fri, Jul 29, 2022 at 4:47 PM Steve Sakoman  wrote:
> > >
> > > From: Alexander Kanavin 
> > >
> > > Security update
> > >
> >
> > With this update we're getting:
> >
> > Parsing recipes...WARNING:
> > /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb:
> > Exception during build_dependencies for AUTOREV
> > WARNING: 
> > /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb:
> > Error during finalise of
> > /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb
> > ERROR: ExpansionError during parsing
> > /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb
> > Traceback (most recent call last):
> > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/git.py", line
> > 249, in Git.urldata_init(ud= > 0x7fc0cb054970>, d= > 0x7fc0cafbd0d0>):
> > > ud.setup_revisions(d)
> > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
> > line 1347, in FetchData.setup_revisions(d= > object at 0x7fc0cafbd0d0>):
> > for name in self.names:
> > > self.revisions[name] = srcrev_internal_helper(self, d, name)
> > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
> > line 1212, in srcrev_internal_helper(ud= > 0x7fc0cb054970>, d=,
> > name='default'):
> > if srcrev == "AUTOINC":
> > > srcrev = ud.method.latest_revision(ud, d, name)
> > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
> > line 1624, in Git.latest_revision(ud= > 0x7fc0cb054970>, d=,
> > name='default'):
> > except KeyError:
> > > revs[key] = rev = self._latest_revision(ud, d, name)
> > return rev
> > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/git.py", line
> > 752, in Git._latest_revision(ud= > 0x7fc0cb054970>, d=,
> > name='default'):
> > return sha1
> > > raise bb.fetch2.FetchError("Unable to resolve '%s' in upstream git 
> > > repository in git ls-remote output for %s" % \
> > (ud.unresolvedrev[name], ud.host+ud.path))
> > bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
> > expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception
> > FetchError: Fetcher failure: Unable to resolve '21.1.4_2022_05_23' in
> > upstream git repository in git ls-remote output for
> > github.com/JeffyCN/xorg-xserver
>
> Is there a bbappend to xserver-xorg somewhere in your layers?
>
> The recipe in core is building from a tarball fetched from
> https://www.x.org/releases/
>
> It appears that a bbappend is changing this to look in
> github.com/JeffyCN/xorg-xserver, which doesn't have 21.1.4
>
> So my best guess is that the issue is with a bbappend in some other
> layer, not with this patch in oe-core.

I'm going to guess you've included meta-rockchip in your build which
does include this bbappend:

https://github.com/JeffyCN/meta-rockchip/blob/master/recipes-graphics/xorg-xserver/xserver-xorg_%25.bbappend

That's where github.com/JeffyCN/xorg-xserver and the AUTOREV are coming from.

Steve

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

[OE-core] Yocto Project Status 02 August 2022 (WW31)

[Neal Caidin]

Current Dev Position: YP 4.1 M3

Next Deadline: 22nd August 2022 YP 4.1 M3 Build

Next Team Meetings:

   -

   Bug Triage meeting Thursday August 4th 7:30 am PDT (
   https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
   -

   Weekly Project Engineering Sync Tuesday August  2nd  at 8 am PDT (
   https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09)
   
   -

   Twitch -  See https://www.twitch.tv/theyoctojester


Key Status/Updates:

   -

   YP 4.1 M2 was released
   -

   YP 3.1.18 passed QA and is due to be released
   -

   The debug file mapping issues have moved slightly further forward thanks
   to some help from Ross but are stalling due to insufficient developer time
   available to resolve the issues.
   -

   Some rust toolchain improvements did merge, including an automated rust
   toolchain test. The bulk of the rework is stalled on a handful of remaining
   issues, particularly a couple of reproducibility problems but also a mips
   n32 toolchain issue.
   -

   We have one open CVE on master against qemu, help to backport that fix
   would be very welcome to keep the numbers down. CVEs in kirkstone (LTS)
   significantly reduced.
   -

   Some development workflow changes around the eSDK workflow merged. There
   are also some layer workflow patches still pending review.
   -

   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 4.1. See:
   
https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_4.1_Unassigned_Enhancements.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/maintainers.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 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 3.1.18 Release date 2022/08/05
   -

   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 2404 (last week 2399) (
   https://wiki.yoctoproject.org/charts/combo.html)
   -

   OE-Core/Poky Patch Metrics
   -

  Total patches found: 1163 (last week 1155)
  -

  Patches in the Pending State: 325 (28%) [last week 326 (28%)]
  -

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


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

https://wiki.yoctoproject.org/wiki/TSC

The Status reports are now stored on the wiki at:
https://wiki.yoctoproject.org/wiki/Weekly_Status

[If anyone has suggestions for other information you’d like to see on this
weekly status update, let us know!]

Cheers

*Neal Caidin*
Program Manager, Program Management & Operations
The Linux Foundation
+1 (919) 238-9104 (w/h)
+1 (919) 949-1861 (m)
ncai...@linuxfoundation.org

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168791): 
https://lists.openembedded.org/g/openembedded-core/message/168791
Mute This Topic: https://lists.openembedded.org/mt/92771754/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][kirkstone 01/29] qemu: CVE-2022-35414 can perform an uninitialized read on the translate_fail path, leading to an io_readx or io_writex crash

[Richard Purdie]

On Fri, 2022-07-29 at 04:46 -1000, Steve Sakoman wrote:
> From: Hitendra Prajapati 
> 
> Source: https://github.com/qemu/qemu
> MR: 119830
> Type: Security Fix
> Disposition: Backport from 
> https://github.com/qemu/qemu/commit/418ade7849ce7641c0f7333718caf5091a02fd4c
> ChangeID: 41d6646e06319e629da574b9b2e8a3a197a73441
> Description:
> CVE-2022-35414 qemu: can perform an uninitialized read on the 
> translate_fail path, leading to an io_readx or io_writex crash.
> 
> Signed-off-by: Hitendra Prajapati 
> Signed-off-by: Steve Sakoman 
> ---
>  meta/recipes-devtools/qemu/qemu.inc   |  1 +
>  .../qemu/qemu/CVE-2022-35414.patch| 53 +++
>  2 files changed, 54 insertions(+)
>  create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2022-35414.patch

This isn't fixed in master yet?

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168790): 
https://lists.openembedded.org/g/openembedded-core/message/168790
Mute This Topic: https://lists.openembedded.org/mt/92692270/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][kirkstone 11/29] xserver-xorg: update 21.1.3 -> 21.1.4

[Steve Sakoman]

On Mon, Aug 1, 2022 at 7:56 PM Marta Rybczynska  wrote:
>
> On Fri, Jul 29, 2022 at 4:47 PM Steve Sakoman  wrote:
> >
> > From: Alexander Kanavin 
> >
> > Security update
> >
>
> With this update we're getting:
>
> Parsing recipes...WARNING:
> /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb:
> Exception during build_dependencies for AUTOREV
> WARNING: 
> /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb:
> Error during finalise of
> /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb
> ERROR: ExpansionError during parsing
> /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb
> Traceback (most recent call last):
> File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/git.py", line
> 249, in Git.urldata_init(ud= 0x7fc0cb054970>, d= 0x7fc0cafbd0d0>):
> > ud.setup_revisions(d)
> File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
> line 1347, in FetchData.setup_revisions(d= object at 0x7fc0cafbd0d0>):
> for name in self.names:
> > self.revisions[name] = srcrev_internal_helper(self, d, name)
> File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
> line 1212, in srcrev_internal_helper(ud= 0x7fc0cb054970>, d=,
> name='default'):
> if srcrev == "AUTOINC":
> > srcrev = ud.method.latest_revision(ud, d, name)
> File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
> line 1624, in Git.latest_revision(ud= 0x7fc0cb054970>, d=,
> name='default'):
> except KeyError:
> > revs[key] = rev = self._latest_revision(ud, d, name)
> return rev
> File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/git.py", line
> 752, in Git._latest_revision(ud= 0x7fc0cb054970>, d=,
> name='default'):
> return sha1
> > raise bb.fetch2.FetchError("Unable to resolve '%s' in upstream git 
> > repository in git ls-remote output for %s" % \
> (ud.unresolvedrev[name], ud.host+ud.path))
> bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
> expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception
> FetchError: Fetcher failure: Unable to resolve '21.1.4_2022_05_23' in
> upstream git repository in git ls-remote output for
> github.com/JeffyCN/xorg-xserver

Is there a bbappend to xserver-xorg somewhere in your layers?

The recipe in core is building from a tarball fetched from
https://www.x.org/releases/

It appears that a bbappend is changing this to look in
github.com/JeffyCN/xorg-xserver, which doesn't have 21.1.4

So my best guess is that the issue is with a bbappend in some other
layer, not with this patch in oe-core.

Steve

> The variable dependency chain for the failure is: SRCPV -> 
> AUTOREV[vardepvalue]

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168789): 
https://lists.openembedded.org/g/openembedded-core/message/168789
Mute This Topic: https://lists.openembedded.org/mt/92692286/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 5/6] scripts/oe-setup-layers: add a script that restores the layer configuration from a json file

[Alexander Kanavin]

That's python 3.6 giving an error about a 3.7 and later parameter. I
sent an adjusted patchset.

Alex

On Tue, 2 Aug 2022 at 15:12, Luca Ceresoli  wrote:
>
> Hi Alex,
>
> On Fri, 29 Jul 2022 16:10:48 +0200
> "Alexander Kanavin"  wrote:
>
> > This script can be used directly from poky, or can be copied directly into a
> > layer or any other repository - it is self-suffucient and requires only 
> > python3
> > and git on the host where it will run. It is also copied by the 
> > bitbake-layers
> > layers-setup plugin together with the json, unless requested otherwise.
> >
> > 1. How to restore the layers from the saved configuration:
> >
> > a) Clone the bootstrap layer or some other repository to obtain the json 
> > config and the setup script that can use it.
> > (use 'bitbake-layers create-layer-setup' from the previous commit to create 
> > them)
> >
> > b) Running with default options:
> > (note: this will work to update an existing checkout as well)
> >
> > alex@Zen2:/srv/work/alex/my-build$ meta-alex/setup-layers
> > Note: not checking out source meta-alex, use 
> > --force-bootstraplayer-checkout to override.
> >
> > Setting up source meta-intel, revision 15.0-hardknott-3.3-310-g0a96edae, 
> > branch master
> > Running 'git init -q /srv/work/alex/my-build/meta-intel'
> > Running 'git remote remove origin > /dev/null 2>&1; git remote add origin 
> > git://git.yoctoproject.org/meta-intel' in /srv/work/alex/my-build/meta-intel
> > Running 'git fetch -q origin || true' in /srv/work/alex/my-build/meta-intel
> > Running 'git checkout -q 0a96edae609a3f48befac36af82cf1eed6786b4a' in 
> > /srv/work/alex/my-build/meta-intel
> >
> > Setting up source poky, revision 4.1_M1-372-g55483d28f2, branch 
> > akanavin/setup-layers
> > Running 'git init -q /srv/work/alex/my-build/poky'
> > Running 'git remote remove origin > /dev/null 2>&1; git remote add origin 
> > git://git.yoctoproject.org/poky' in /srv/work/alex/my-build/poky
> > Running 'git fetch -q origin || true' in /srv/work/alex/my-build/poky
> > Running 'git remote remove poky-contrib > /dev/null 2>&1; git remote add 
> > poky-contrib ssh://g...@push.yoctoproject.org/poky-contrib' in 
> > /srv/work/alex/my-build/poky
> > Running 'git fetch -q poky-contrib || true' in /srv/work/alex/my-build/poky
> > Running 'git checkout -q 11db0390b02acac1324e0f827beb0e2e3d0d1d63' in 
> > /srv/work/alex/my-build/poky
> >
> > Available build configurations:
> > /srv/work/alex/my-build/meta-alex/conf/templates/configuration-gadget
> > /srv/work/alex/my-build/meta-alex/conf/templates/configuration-gizmo
> > /srv/work/alex/my-build/poky/meta-poky/conf
> >
> > You can set up a build with:
> > TEMPLATECONF=one/of/the/above . 
> > /srv/work/alex/my-build/poky/oe-init-build-env
> >
> > 2. Command line options:
> >
> > alex@Zen2:/srv/work/alex/my-build$ meta-alex/setup-layers -h
> > usage: setup-layers [-h] [--force-bootstraplayer-checkout] [--destdir 
> > DESTDIR] [--jsondata JSONDATA]
> >
> > A self contained python script that fetches all the needed layers and sets 
> > them to correct revisions
> >
> > optional arguments:
> >   -h, --helpshow this help message and exit
> >   --force-bootstraplayer-checkout
> > Force the checkout of the layer containing this 
> > file (by default it is presumed that as this script is in it, the layer is 
> > already in place).
> >   --destdir DESTDIR Where to check out the layers (default is 
> > /srv/work/alex/my-build).
> >   --jsondata JSONDATA   File containing the layer data in json format 
> > (default is /srv/work/alex/my-build/meta-alex/setup-layers.json).
> >
> > Signed-off-by: Alexander Kanavin 
>
> This patch triggers an AB error:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/3916/steps/15/logs/stdio
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168788): 
https://lists.openembedded.org/g/openembedded-core/message/168788
Mute This Topic: https://lists.openembedded.org/mt/92691486/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][kirkstone 11/29] xserver-xorg: update 21.1.3 -> 21.1.4

[Steve Sakoman]

On Mon, Aug 1, 2022 at 7:57 PM Marta Rybczynska  wrote:
>
> On Tue, Aug 2, 2022 at 7:56 AM Marta Rybczynska  wrote:
> >
> > On Fri, Jul 29, 2022 at 4:47 PM Steve Sakoman  wrote:
> > >
> > > From: Alexander Kanavin 
> > >
> > > Security update
> > >
> >
> > With this update we're getting:
> >
> > Parsing recipes...WARNING:
> > /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb:
> > Exception during build_dependencies for AUTOREV
> > WARNING: 
> > /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb:
> > Error during finalise of
> > /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb
> > ERROR: ExpansionError during parsing
> > /tmp/workspace.Pvlp4fXTtK/oe-core/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.4.bb
> > Traceback (most recent call last):
> > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/git.py", line
> > 249, in Git.urldata_init(ud= > 0x7fc0cb054970>, d= > 0x7fc0cafbd0d0>):
> > > ud.setup_revisions(d)
> > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
> > line 1347, in FetchData.setup_revisions(d= > object at 0x7fc0cafbd0d0>):
> > for name in self.names:
> > > self.revisions[name] = srcrev_internal_helper(self, d, name)
> > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
> > line 1212, in srcrev_internal_helper(ud= > 0x7fc0cb054970>, d=,
> > name='default'):
> > if srcrev == "AUTOINC":
> > > srcrev = ud.method.latest_revision(ud, d, name)
> > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/__init__.py",
> > line 1624, in Git.latest_revision(ud= > 0x7fc0cb054970>, d=,
> > name='default'):
> > except KeyError:
> > > revs[key] = rev = self._latest_revision(ud, d, name)
> > return rev
> > File "/tmp/workspace.Pvlp4fXTtK/bitbake/lib/bb/fetch2/git.py", line
> > 752, in Git._latest_revision(ud= > 0x7fc0cb054970>, d=,
> > name='default'):
> > return sha1
> > > raise bb.fetch2.FetchError("Unable to resolve '%s' in upstream git 
> > > repository in git ls-remote output for %s" % \
> > (ud.unresolvedrev[name], ud.host+ud.path))
> > bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
> > expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception
> > FetchError: Fetcher failure: Unable to resolve '21.1.4_2022_05_23' in
> > upstream git repository in git ls-remote output for
> > github.com/JeffyCN/xorg-xserver
> > The variable dependency chain for the failure is: SRCPV -> 
> > AUTOREV[vardepvalue]
> >
> Additional information: it happens on zephyr and freertos builds.

Do you see this on master too?  Since this is a backport it would be
interesting to see if it fails there too.

Steve

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168787): 
https://lists.openembedded.org/g/openembedded-core/message/168787
Mute This Topic: https://lists.openembedded.org/mt/92692286/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] [meta-oe][PATCH] wic/direct.py: ignore root mountpoint in fstab updater

[Markus Volk]

Maybe we could do like this in base-files.bb ?

FSTAB_HAVE_WIC = "${@bb.utils.contains('IMAGE_FSTYPES', 'wic', 'true', 
'false', d)}"
FSTAB_WIC_UPDATER = "${@bb.utils.contains('WIC_CREATE_EXTRA_ARGS', 
'--no-fstab-update', 'false', 'true', d)}"


do_install:append() {
	if [ ${FSTAB_HAVE_WIC} = true ] && [ ${FSTAB_WIC_UPDATER} = true ]; 
then

sed -i '/\/dev\/root/d' ${D}${sysconfdir}/fstab
fi
}

This would remove the hardcoded '/dev/root' entry  if all conditions 
are met to add the root entry with wic fstab-update


It’s looking like the easiest fix here is to revert your patch, so 
at least we don’t have warnings and unexpected behaviour on boot.  
Unless you’re willing to rework your patch so that it allows edits 
to the root mount point but doesn’t end up creating duplicates?



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168786): 
https://lists.openembedded.org/g/openembedded-core/message/168786
Mute This Topic: https://lists.openembedded.org/mt/92649199/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 5/5] selftest/bblayers: add a test for creating a layer setup and using it to restore the layers

[Alexander Kanavin]

This does a basic run-through of the bitbake-layers plugin, and the resulting 
json layer config
and the layer setup script that uses it. Only poky is actually fetched by the 
script.

Signed-off-by: Alexander Kanavin 
---
 meta/lib/oeqa/selftest/cases/bblayers.py | 12 
 1 file changed, 12 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/bblayers.py 
b/meta/lib/oeqa/selftest/cases/bblayers.py
index 4f4952f3eb..1f5c576356 100644
--- a/meta/lib/oeqa/selftest/cases/bblayers.py
+++ b/meta/lib/oeqa/selftest/cases/bblayers.py
@@ -140,3 +140,15 @@ class BitbakeLayers(OESelftestTestCase):
 def test_validate_examplelayersjson(self):
 json = os.path.join(get_bb_var('COREBASE'), 
"meta/files/layers.example.json")
 self.validate_layersjson(json)
+
+def test_bitbakelayers_setup(self):
+result = runCmd('bitbake-layers create-layers-setup 
{}'.format(self.testlayer_path))
+jsonfile = os.path.join(self.testlayer_path, "setup-layers.json")
+self.validate_layersjson(jsonfile)
+
+testcheckoutdir = os.path.join(self.builddir, 'test-layer-checkout')
+result = runCmd('{}/setup-layers --destdir 
{}'.format(self.testlayer_path, testcheckoutdir))
+# May not necessarily be named 'poky'
+pokydir = os.listdir(testcheckoutdir)[0]
+testcheckoutfile = os.path.join(testcheckoutdir, pokydir, 
"oe-init-build-env")
+self.assertTrue(os.path.exists(testcheckoutfile), "File {} not found 
in test layer checkout".format(testcheckoutfile))
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168785): 
https://lists.openembedded.org/g/openembedded-core/message/168785
Mute This Topic: https://lists.openembedded.org/mt/92770562/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 4/5] scripts/oe-setup-layers: add a script that restores the layer configuration from a json file

[Alexander Kanavin]

This script can be used directly from poky, or can be copied directly into a
layer or any other repository - it is self-suffucient and requires only python3
and git on the host where it will run. It is also copied by the bitbake-layers
layers-setup plugin together with the json, unless requested otherwise.

1. How to restore the layers from the saved configuration:

a) Clone the bootstrap layer or some other repository to obtain the json config 
and the setup script that can use it.
(use 'bitbake-layers create-layer-setup' from the previous commit to create 
them)

b) Running with default options:
(note: this will work to update an existing checkout as well)

alex@Zen2:/srv/work/alex/my-build$ meta-alex/setup-layers
Note: not checking out source meta-alex, use --force-bootstraplayer-checkout to 
override.

Setting up source meta-intel, revision 15.0-hardknott-3.3-310-g0a96edae, branch 
master
Running 'git init -q /srv/work/alex/my-build/meta-intel'
Running 'git remote remove origin > /dev/null 2>&1; git remote add origin 
git://git.yoctoproject.org/meta-intel' in /srv/work/alex/my-build/meta-intel
Running 'git fetch -q origin || true' in /srv/work/alex/my-build/meta-intel
Running 'git checkout -q 0a96edae609a3f48befac36af82cf1eed6786b4a' in 
/srv/work/alex/my-build/meta-intel

Setting up source poky, revision 4.1_M1-372-g55483d28f2, branch 
akanavin/setup-layers
Running 'git init -q /srv/work/alex/my-build/poky'
Running 'git remote remove origin > /dev/null 2>&1; git remote add origin 
git://git.yoctoproject.org/poky' in /srv/work/alex/my-build/poky
Running 'git fetch -q origin || true' in /srv/work/alex/my-build/poky
Running 'git remote remove poky-contrib > /dev/null 2>&1; git remote add 
poky-contrib ssh://g...@push.yoctoproject.org/poky-contrib' in 
/srv/work/alex/my-build/poky
Running 'git fetch -q poky-contrib || true' in /srv/work/alex/my-build/poky
Running 'git checkout -q 11db0390b02acac1324e0f827beb0e2e3d0d1d63' in 
/srv/work/alex/my-build/poky

Available build configurations:
/srv/work/alex/my-build/meta-alex/conf/templates/configuration-gadget
/srv/work/alex/my-build/meta-alex/conf/templates/configuration-gizmo
/srv/work/alex/my-build/poky/meta-poky/conf

You can set up a build with:
TEMPLATECONF=one/of/the/above . /srv/work/alex/my-build/poky/oe-init-build-env

2. Command line options:

alex@Zen2:/srv/work/alex/my-build$ meta-alex/setup-layers -h
usage: setup-layers [-h] [--force-bootstraplayer-checkout] [--destdir DESTDIR] 
[--jsondata JSONDATA]

A self contained python script that fetches all the needed layers and sets them 
to correct revisions

optional arguments:
  -h, --helpshow this help message and exit
  --force-bootstraplayer-checkout
Force the checkout of the layer containing this file 
(by default it is presumed that as this script is in it, the layer is already 
in place).
  --destdir DESTDIR Where to check out the layers (default is 
/srv/work/alex/my-build).
  --jsondata JSONDATA   File containing the layer data in json format (default 
is /srv/work/alex/my-build/meta-alex/setup-layers.json).

Signed-off-by: Alexander Kanavin 
---
 scripts/oe-setup-layers | 85 +
 1 file changed, 85 insertions(+)
 create mode 100755 scripts/oe-setup-layers

diff --git a/scripts/oe-setup-layers b/scripts/oe-setup-layers
new file mode 100755
index 00..39cc16a30d
--- /dev/null
+++ b/scripts/oe-setup-layers
@@ -0,0 +1,85 @@
+#!/usr/bin/env python3
+#
+# This file was copied from poky(or oe-core)/scripts/oe-setup-layers by running
+#
+# bitbake-layers create-layers-setup destdir
+#
+# It is recommended that you do not modify this file directly, but rather 
re-run the above command to get the freshest upstream copy.
+#
+
+import argparse
+import json
+import os
+import subprocess
+
+def _do_checkout(args, json):
+layers = json['sources']
+buildconfs = []
+oecorepath = ""
+for l_name in layers:
+l_data = layers[l_name]
+layerdir = os.path.abspath(os.path.join(args['destdir'], 
l_data['path']))
+
+for ll_name in l_data['layers']:
+if ll_name == 'meta':
+oecorepath = layerdir
+ll_data = l_data['layers'][ll_name]
+if 'buildconfigs' in ll_data:
+for c in ll_data['buildconfigs']:
+buildconfs.append(os.path.join(layerdir, 
ll_data['subpath'], c))
+
+if 'contains_this_file' in l_data.keys():
+force_arg = 'force_bootstraplayer_checkout'
+if not args[force_arg]:
+print('Note: not checking out source {layer}, use {layerflag} 
to override.'.format(layer=l_name, layerflag='--force-bootstraplayer-checkout'))
+continue
+l_remote = l_data['git-remote']
+rev = l_remote['rev']
+desc = l_remote['describe']
+if not desc:
+desc = rev[:10]
+branch = l_remote['branch']
+remotes = 

[OE-core] [PATCH 3/5] bitbake-layers: add ability to save current layer repository configuration into a json file

[Alexander Kanavin]

This addresses a long standing gap in the core offering:
there is no tooling to capture the currently configured layers
with their revisions, or restore the layers from a configuration
file (without using external tools, some of which aren't particularly
suitable for the task). This plugin addresses the 'capture' part.

How to save a layer configuration:

a) Running with default choices:

NOTE: Starting bitbake server...
NOTE: Created /srv/work/alex/meta-alex/setup-layers.json
NOTE: Created /srv/work/alex/meta-alex/setup-layers

b) Command line options:

alex@Zen2:/srv/work/alex/poky/build-layersetup$ bitbake-layers 
create-layers-setup -h
NOTE: Starting bitbake server...
usage: bitbake-layers create-layers-setup [-h] [--output-prefix OUTPUT_PREFIX] 
[--json-only] destdir

 Writes out a python script and a json config that replicate the directory 
structure and revisions of the layers in a current build.

positional arguments:
  destdir   Directory where to write the output
(if it is inside one of the layers, the layer becomes a 
bootstrap repository and thus will be excluded from fetching by the script).

optional arguments:
  -h, --helpshow this help message and exit
  --output-prefix OUTPUT_PREFIX, -o OUTPUT_PREFIX
File name prefix for the output files, if the default 
(setup-layers) is undesirable.
  --json-only   Write only the layer configuruation in json format. 
Otherwise, also a copy of poky/scripts/oe-setup-layers is provided, which is a 
self contained python script that fetches all the needed layers and sets them 
to correct revisions using the data from the json.

Signed-off-by: Alexander Kanavin 
---
 meta/lib/bblayers/makesetup.py | 139 +
 1 file changed, 139 insertions(+)
 create mode 100644 meta/lib/bblayers/makesetup.py

diff --git a/meta/lib/bblayers/makesetup.py b/meta/lib/bblayers/makesetup.py
new file mode 100644
index 00..b7f62900f4
--- /dev/null
+++ b/meta/lib/bblayers/makesetup.py
@@ -0,0 +1,139 @@
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+
+import logging
+import os
+import stat
+import sys
+import shutil
+import json
+
+import bb.utils
+import bb.process
+
+from bblayers.common import LayerPlugin
+
+logger = logging.getLogger('bitbake-layers')
+
+sys.path.insert(0, os.path.dirname(os.path.dirname(__file__)))
+
+import oe.buildcfg
+
+def plugin_init(plugins):
+return MakeSetupPlugin()
+
+class MakeSetupPlugin(LayerPlugin):
+
+def _write_python(self, input, output):
+with open(input) as f:
+script = f.read()
+with open(output, 'w') as f:
+f.write(script)
+st = os.stat(output)
+os.chmod(output, st.st_mode | stat.S_IEXEC | stat.S_IXGRP | 
stat.S_IXOTH)
+
+def _write_json(self, repos, output):
+with open(output, 'w') as f:
+json.dump(repos, f, sort_keys=True, indent=4)
+
+def _get_repo_path(self, layer_path):
+repo_path, _ = bb.process.run('git rev-parse --show-toplevel', 
cwd=layer_path)
+return repo_path.strip()
+
+def _get_remotes(self, repo_path):
+remotes = {}
+remotes_list,_ = bb.process.run('git remote', cwd=repo_path)
+for r in remotes_list.split():
+uri,_ = bb.process.run('git remote get-url {r}'.format(r=r), 
cwd=repo_path)
+remotes[r] = {'uri':uri.strip()}
+return remotes
+
+def _get_describe(self, repo_path):
+try:
+describe,_ = bb.process.run('git describe --tags', cwd=repo_path)
+except bb.process.ExecutionError:
+return ""
+return describe.strip()
+
+def _get_confs(self, conf_path):
+try:
+   files = os.listdir(conf_path)
+except:
+   return []
+return {f.replace(".conf",""):{} for f in files if f.endswith(".conf")}
+
+def _get_distros(self, layer_path):
+return self._get_confs(os.path.join(layer_path, "conf/distro"))
+
+def _get_machines(self, layer_path):
+return self._get_confs(os.path.join(layer_path, "conf/machine"))
+
+def _get_buildconfigs(self, layerpath):
+return {os.path.relpath(dir, start=layerpath):{} for (dir, subdirs, 
files) in os.walk(layerpath) if 'local.conf.sample' in files and 
'bblayers.conf.sample' in files}
+
+def _make_repo_config(self, destdir):
+repos = {}
+layers = oe.buildcfg.get_layer_revisions(self.tinfoil.config_data)
+try:
+destdir_repo = self._get_repo_path(destdir)
+except bb.process.ExecutionError:
+destdir_repo = None
+
+for (l_path, l_name, l_branch, l_rev, l_ismodified) in layers:
+if l_name == 'workspace':
+continue
+if l_ismodified:
+logger.error("Layer {name} in {path} has uncommitted 
modifications or is not in a git repository.".format(name=l_name,path=l_path))
+return
+  

[OE-core] [PATCH 2/5] meta/files: add layer setup JSON schema and example

[Alexander Kanavin]

From: Joshua Watt 

Defines a common schema for layer setup that can be consumed by tools to
know how to fetch and assemble layers for end users. Also includes an
example of the layer setup that constructs poky/meta-intel/imaginary product 
layer
for reference.

The schema can be used to validate a layer setup file with the commands:

 $ python3 -m pip install jsonschema
 $ jsonschema -i meta/files/layers.example.json meta/files/layers.schema.json

Signed-off-by: Joshua Watt 

Alex: I made the following modifications to Joshua's original commit:

- moved the files from meta/lib to meta/files

- the example json showcases a multi-repo, multi-layer setup with additional
configurations and machines, instead of just poky - closer to a typical product

- added oe-selftest that validates the example json against the schema using 
python3-jsonschema-native

- the schema is modified so that:

-- all lists (sources, layers, remotes) are replaced by objects keyed by 'name' 
properties of the list items.
This allows using them as dicts inside Python, and makes the json more compact 
and readable.

-- added 'contains_this_file' property to source object

-- added 'buildconfigs', 'machines' and 'distros' properties to layer objects.

-- replaced 'remote' property with a 'oneOf' definition for git with a specific
'git-remote' property. 'oneOf' is problematic when schema validation fails:
the diagnostic is only that none of oneOf variants matched, which is too 
non-specific.

-- added 'describe' property to 'git-remote' object.

-- removed description property for a layer source: it is not clear how to add 
that
when auto-generating the json

Signed-off-by: Alexander Kanavin 
---
 meta/files/layers.example.json   | 115 +
 meta/files/layers.schema.json| 121 +++
 meta/lib/oeqa/selftest/cases/bblayers.py |  16 ++-
 3 files changed, 251 insertions(+), 1 deletion(-)
 create mode 100644 meta/files/layers.example.json
 create mode 100644 meta/files/layers.schema.json

diff --git a/meta/files/layers.example.json b/meta/files/layers.example.json
new file mode 100644
index 00..b6e35c615d
--- /dev/null
+++ b/meta/files/layers.example.json
@@ -0,0 +1,115 @@
+{
+"sources": {
+"meta-alex": {
+"contains_this_file": true,
+"git-remote": {
+"branch": "master",
+"describe": "",
+"remotes": {
+"remote-alex": {
+"uri": "https://github.com/kanavin/meta-alex;
+}
+},
+"rev": "05b25605fb8b2399e4706d7323828676bf0da0b5"
+},
+"layers": {
+"meta-alex": {
+"buildconfigs": {
+"conf/templates/configuration-gadget": {},
+"conf/templates/configuration-gizmo": {}
+},
+"subpath": ""
+}
+},
+"path": "meta-alex"
+},
+"meta-intel": {
+"git-remote": {
+"branch": "master",
+"describe": "15.0-hardknott-3.3-310-g0a96edae",
+"remotes": {
+"origin": {
+"uri": "git://git.yoctoproject.org/meta-intel"
+}
+},
+"rev": "0a96edae609a3f48befac36af82cf1eed6786b4a"
+},
+"layers": {
+"meta-intel": {
+"machines": {
+"intel-core2-32": {},
+"intel-corei7-64": {},
+"intel-skylake-64": {}
+},
+"subpath": ""
+}
+},
+"path": "meta-intel"
+},
+"poky": {
+"git-remote": {
+"branch": "akanavin/setup-layers",
+"describe": "4.1_M1-374-g9dda719b2a",
+"remotes": {
+"origin": {
+"uri": "git://git.yoctoproject.org/poky"
+},
+"poky-contrib": {
+"uri": "ssh://g...@push.yoctoproject.org/poky-contrib"
+}
+},
+"rev": "9dda719b2a4727a4d43a6ab8d9e23f8ca68790ec"
+},
+"layers": {
+"meta": {
+"distros": {
+"defaultsetup": {}
+},
+"machines": {
+"qemuarm": {},
+"qemuarm64": {},
+"qemuarmv5": {},
+"qemumips": {},
+"qemumips64": {},
+"qemuppc": {},
+"qemuppc64": {},
+"qemuriscv32": {},
+"qemuriscv64": {},
+

[OE-core] [PATCH 1/5] bitbake-layers: add a command to save the active build configuration as a template into a layer

[Alexander Kanavin]

This is the reverse of setting up a build by pointing TEMPLATECONF to a 
directory
with a template and running '. oe-init-build-env': this takes the config files 
from build/conf,
replaces site-specific paths in bblayers.conf with ##OECORE##-relative paths, 
and copies
the config files into a specified layer under a specified template name.

In many or perhaps most cases such static prefabricated configurations (that 
require no
further editing) are just enough, and I believe they should be offered by the
official configuration management. On the other hand, generating build 
configurations with a
sufficiently versatile tool is a far more complex problem, and one we should 
try to tackle
once we see where and how static configs fall short.

Tooling to discover and select these templates when setting up a build will be 
provided later on.

How to use:

alex@Zen2:/srv/work/alex/poky/build-layersetup$ bitbake-layers save-build-conf 
../../meta-alex/ test-1
NOTE: Starting bitbake server...
NOTE: Configuration template placed into 
/srv/work/alex/meta-alex/conf/templates/test-1
Please review the files in there, and particularly provide a configuration 
description in /srv/work/alex/meta-alex/conf/templates/test-1/conf-notes.txt
You can try out the configuration with
TEMPLATECONF=/srv/work/alex/meta-alex/conf/templates/test-1 . 
/srv/work/alex/poky/oe-init-build-env build-try-test-1
alex@Zen2:/srv/work/alex/poky/build-layersetup$

Signed-off-by: Alexander Kanavin 
---
 meta/lib/bblayers/buildconf.py   | 83 
 meta/lib/oeqa/selftest/cases/bblayers.py |  5 ++
 2 files changed, 88 insertions(+)
 create mode 100644 meta/lib/bblayers/buildconf.py

diff --git a/meta/lib/bblayers/buildconf.py b/meta/lib/bblayers/buildconf.py
new file mode 100644
index 00..ece8836d5a
--- /dev/null
+++ b/meta/lib/bblayers/buildconf.py
@@ -0,0 +1,83 @@
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+
+import logging
+import os
+import stat
+import sys
+import shutil
+import json
+
+import bb.utils
+import bb.process
+
+from bblayers.common import LayerPlugin
+
+logger = logging.getLogger('bitbake-layers')
+
+sys.path.insert(0, os.path.dirname(os.path.dirname(__file__)))
+
+import oe.buildcfg
+
+def plugin_init(plugins):
+return BuildConfPlugin()
+
+class BuildConfPlugin(LayerPlugin):
+notes_fixme = """FIXME: Please place here the description of this build 
configuration.
+It will be shown to the users when they set up their builds via TEMPLATECONF.
+"""
+
+def _save_conf(self, templatename, templatepath, oecorepath, 
relpaths_to_oecore):
+confdir = os.path.join(os.environ["BBPATH"], "conf")
+destdir = os.path.join(templatepath, "conf", "templates", templatename)
+os.makedirs(destdir, exist_ok=True)
+
+with open(os.path.join(confdir, "local.conf")) as src:
+with open(os.path.join(destdir, "local.conf.sample"), 'w') as dest:
+dest.write(src.read())
+
+with open(os.path.join(confdir, "bblayers.conf")) as src:
+with open(os.path.join(destdir, "bblayers.conf.sample"), 'w') as 
dest:
+bblayers_data = src.read()
+
+for (abspath, relpath) in relpaths_to_oecore:
+bblayers_data = bblayers_data.replace(abspath, 
"##OEROOT##/" + relpath)
+dest.write(bblayers_data)
+
+with open(os.path.join(destdir, "conf-notes.txt"), 'w') as dest:
+dest.write(self.notes_fixme)
+
+logger.info("""Configuration template placed into {}
+Please review the files in there, and particularly provide a configuration 
description in {}
+You can try out the configuration with
+TEMPLATECONF={} . {}/oe-init-build-env build-try-{}"""
+.format(destdir, os.path.join(destdir, "conf-notes.txt"), destdir, oecorepath, 
templatename))
+
+def do_save_build_conf(self, args):
+""" Save the currently active build configuration (conf/local.conf, 
conf/bblayers.conf) as a template into a layer.\n This template can later be 
used for setting up builds via TEMPLATECONF. """
+repos = {}
+layers = oe.buildcfg.get_layer_revisions(self.tinfoil.config_data)
+targetlayer = None
+oecore = None
+
+for l in layers:
+if l[0] == os.path.abspath(args.layerpath):
+targetlayer = l[0]
+if l[1] == 'meta':
+oecore = os.path.dirname(l[0])
+
+if not targetlayer:
+logger.error("Layer {} not in one of the currently enabled 
layers:\n{}".format(args.layerpath, "\n".join([l[0] for l in layers])))
+elif not oecore:
+logger.error("Openembedded-core not in one of the currently 
enabled layers:\n{}".format("\n".join([l[0] for l in layers])))
+else:
+relpaths_to_oecore = [(l[0], os.path.relpath(l[0], start=oecore)) 
for l in layers]
+self._save_conf(args.templatename, targetlayer, oecore, 
relpaths_to_oecore)
+
+def 

Re: [OE-core] [PATCH 5/6] scripts/oe-setup-layers: add a script that restores the layer configuration from a json file

[Luca Ceresoli via lists.openembedded.org]

Hi Alex,

On Fri, 29 Jul 2022 16:10:48 +0200
"Alexander Kanavin"  wrote:

> This script can be used directly from poky, or can be copied directly into a
> layer or any other repository - it is self-suffucient and requires only 
> python3
> and git on the host where it will run. It is also copied by the bitbake-layers
> layers-setup plugin together with the json, unless requested otherwise.
> 
> 1. How to restore the layers from the saved configuration:
> 
> a) Clone the bootstrap layer or some other repository to obtain the json 
> config and the setup script that can use it.
> (use 'bitbake-layers create-layer-setup' from the previous commit to create 
> them)
> 
> b) Running with default options:
> (note: this will work to update an existing checkout as well)
> 
> alex@Zen2:/srv/work/alex/my-build$ meta-alex/setup-layers
> Note: not checking out source meta-alex, use --force-bootstraplayer-checkout 
> to override.
> 
> Setting up source meta-intel, revision 15.0-hardknott-3.3-310-g0a96edae, 
> branch master
> Running 'git init -q /srv/work/alex/my-build/meta-intel'
> Running 'git remote remove origin > /dev/null 2>&1; git remote add origin 
> git://git.yoctoproject.org/meta-intel' in /srv/work/alex/my-build/meta-intel
> Running 'git fetch -q origin || true' in /srv/work/alex/my-build/meta-intel
> Running 'git checkout -q 0a96edae609a3f48befac36af82cf1eed6786b4a' in 
> /srv/work/alex/my-build/meta-intel
> 
> Setting up source poky, revision 4.1_M1-372-g55483d28f2, branch 
> akanavin/setup-layers
> Running 'git init -q /srv/work/alex/my-build/poky'
> Running 'git remote remove origin > /dev/null 2>&1; git remote add origin 
> git://git.yoctoproject.org/poky' in /srv/work/alex/my-build/poky
> Running 'git fetch -q origin || true' in /srv/work/alex/my-build/poky
> Running 'git remote remove poky-contrib > /dev/null 2>&1; git remote add 
> poky-contrib ssh://g...@push.yoctoproject.org/poky-contrib' in 
> /srv/work/alex/my-build/poky
> Running 'git fetch -q poky-contrib || true' in /srv/work/alex/my-build/poky
> Running 'git checkout -q 11db0390b02acac1324e0f827beb0e2e3d0d1d63' in 
> /srv/work/alex/my-build/poky
> 
> Available build configurations:
> /srv/work/alex/my-build/meta-alex/conf/templates/configuration-gadget
> /srv/work/alex/my-build/meta-alex/conf/templates/configuration-gizmo
> /srv/work/alex/my-build/poky/meta-poky/conf
> 
> You can set up a build with:
> TEMPLATECONF=one/of/the/above . /srv/work/alex/my-build/poky/oe-init-build-env
> 
> 2. Command line options:
> 
> alex@Zen2:/srv/work/alex/my-build$ meta-alex/setup-layers -h
> usage: setup-layers [-h] [--force-bootstraplayer-checkout] [--destdir 
> DESTDIR] [--jsondata JSONDATA]
> 
> A self contained python script that fetches all the needed layers and sets 
> them to correct revisions
> 
> optional arguments:
>   -h, --helpshow this help message and exit
>   --force-bootstraplayer-checkout
> Force the checkout of the layer containing this file 
> (by default it is presumed that as this script is in it, the layer is already 
> in place).
>   --destdir DESTDIR Where to check out the layers (default is 
> /srv/work/alex/my-build).
>   --jsondata JSONDATA   File containing the layer data in json format 
> (default is /srv/work/alex/my-build/meta-alex/setup-layers.json).
> 
> Signed-off-by: Alexander Kanavin 

This patch triggers an AB error:

https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/3916/steps/15/logs/stdio

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168780): 
https://lists.openembedded.org/g/openembedded-core/message/168780
Mute This Topic: https://lists.openembedded.org/mt/92691486/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 v6] Rust Oe-Selftest implementation

[Pgowda]

Hi Luca,

Thanks very much for checking the patch and comment about the elf-tls.

An explanatory comment has been added as per your suggestion and patch
posted as:-
https://lists.openembedded.org/g/openembedded-core/message/168778

Thanks,
Pgowda

On Tue, Aug 2, 2022 at 3:22 PM Luca Ceresoli  wrote:
>
> Hi Pgowda,
>
> On Tue, 2 Aug 2022 14:37:54 +0530
> "Pgowda"  wrote:
>
> > Hi Luca,
> >
> > There were around 270 testcase failing when "has-elf-tls" has been
> > enabled while building llvm.
> > Hence, we had to remove the option to enable the proper working of these 
> > tests.
> > The patch has been tested on Ubuntu and also fedora (using docker image).
>
> Thanks for the explanation. Then why not adding an explanatory comment,
> as below?
>
> # Disabled because.
> #tspec['has-elf-tls'] = True
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168779): 
https://lists.openembedded.org/g/openembedded-core/message/168779
Mute This Topic: https://lists.openembedded.org/mt/92764644/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 v7] Rust Oe-Selftest implementation

[Pgowda]

From: pgowda 

The patch implements Rust testing framework similar to other selftest,
specifically the gcc selftest in OE. It uses the client and server
based method to test the binaries for cross-target on the image.
The test framework is a wrapper around the Rust build system as ./x.py
test.
It tests many functionalities of Rust distribution like tools,
documentation, libraries, packages, tools, Cargo, Crater etc.
Please refer the following link for detailed description of Rust
testing:-
https://rustc-dev-guide.rust-lang.org/tests/intro.html#tool-tests

To support the rust tests in oe-core, the following functions were
added:-
setup_cargo_environment(): Build bootstrap and some early stage tools.
do_rust_setup_snapshot(): Install the snapshot version of rust binaries.
do_configure(): To generate config.toml
do_compile(): To build "remote-test-server" for qemu target image.

Approximate Number of Tests Run in the Rust Testsuite :- 18000
Approximate Number of Tests that FAIL in bitbake environment :- 100-150
Normally majority of the testcases are present in major folder "test/"
It contributes to more than 80% of the testcases present in Rust test
framework. These tests pass as expected on any Rust versions without
much fuss. The tests that fail are of less important and contribute to
less than 2% of the total testcases. These minor tests are observed to
work on some versions and fail on others. They have to be added, ignored
or excluded for different versions as per the behavior.
These tests have been ignored or excluded in the Rust selftest
environment to generate success of completing the testsuite.

These tests work in parallel mode even in the skipped test mode as
expected. Although the patch to disable tests is large, it is very simple
in that it only disables tests. When updating to a newer version of Rust,
the patch can usually be ported in a day.

Signed-off-by: pgowda 
Signed-off-by: Vinay Kumar 
---
 meta/classes/rust-target-config.bbclass   |   3 +-
 meta/lib/oeqa/selftest/cases/rust.py  |  57 +++
 meta/recipes-devtools/rust/rust-testsuite.inc | 164 ++
 .../rust-testsuite/rust-oe-selftest.patch | 477 ++
 .../rust/rust-testsuite_1.62.0.bb |   3 +
 5 files changed, 703 insertions(+), 1 deletion(-)
 create mode 100644 meta/lib/oeqa/selftest/cases/rust.py
 create mode 100644 meta/recipes-devtools/rust/rust-testsuite.inc
 create mode 100644 
meta/recipes-devtools/rust/rust-testsuite/rust-oe-selftest.patch
 create mode 100644 meta/recipes-devtools/rust/rust-testsuite_1.62.0.bb

diff --git a/meta/classes/rust-target-config.bbclass 
b/meta/classes/rust-target-config.bbclass
index 87b7dee3ed..17eb18eba1 100644
--- a/meta/classes/rust-target-config.bbclass
+++ b/meta/classes/rust-target-config.bbclass
@@ -344,7 +344,8 @@ def rust_gen_target(d, thing, wd, arch):
 tspec['linker-is-gnu'] = True
 tspec['linker-flavor'] = "gcc"
 tspec['has-rpath'] = True
-tspec['has-elf-tls'] = True
+# FIXME: Around 270 testcases fail with elf-tls enabled.
+# tspec['has-elf-tls'] = True
 tspec['position-independent-executables'] = True
 tspec['panic-strategy'] = d.getVar("RUST_PANIC_STRATEGY")
 
diff --git a/meta/lib/oeqa/selftest/cases/rust.py 
b/meta/lib/oeqa/selftest/cases/rust.py
new file mode 100644
index 00..80d6f310c9
--- /dev/null
+++ b/meta/lib/oeqa/selftest/cases/rust.py
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: MIT
+import os
+import subprocess
+from oeqa.core.decorator import OETestTag
+from oeqa.core.case import OEPTestResultTestCase
+from oeqa.selftest.case import OESelftestTestCase
+from oeqa.utils.commands import runCmd, bitbake, get_bb_var, get_bb_vars, 
runqemu, Command
+from oeqa.utils.sshcontrol import SSHControl
+
+# Total time taken for testing is of about 2hr 20min, with PARALLEL_MAKE set 
to 40 number of jobs.
+class RustSelfTestBase(OESelftestTestCase, OEPTestResultTestCase):
+
+   def run_check_emulated(self, *args, **kwargs):
+   # build remote-test-server before image build
+   recipe = "rust-testsuite"
+   bitbake("{} -c compile".format(recipe))
+   builddir = get_bb_var("B", "rust-testsuite")
+   # build core-image-minimal with required packages
+   default_installed_packages = ["libgcc", "libstdc++", 
"libatomic", "libgomp"]
+   features = []
+   features.append('IMAGE_FEATURES += "ssh-server-openssh"')
+   features.append('CORE_IMAGE_EXTRA_INSTALL += "{0}"'.format(" 
".join(default_installed_packages)))
+   self.write_config("\n".join(features))
+   bitbake("core-image-minimal")
+   # wrap the execution with a qemu instance
+   with runqemu("core-image-minimal", runqemuparams = "nographic", 
qemuparams = "-m 512") as qemu:
+   # Copy remote-test-server to image through scp
+   ssh = SSHControl(ip=qemu.ip, 

Re: [OE-core] [meta-oe][PATCH v4] classes: rootfs-postcommands: autologin root on serial-getty

[Luca Ceresoli via lists.openembedded.org]

Hi Johannes,

On Tue,  2 Aug 2022 11:40:19 +0200
"Johannes Schneider via lists.openembedded.org"
 wrote:
   

As you can see above, your sender address is getting mangled. This is
not your fault, but it makes applying your patches annoying.

Can you please try to work around that by setting the sendemail.from
parameter in your git config?

You can read the details in this discussion:
https://lists.openembedded.org/g/openembedded-core/message/166515?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Acreated%2C0%2Crootfs.py%3A+find+.ko.zst+kernel+modules%2C20%2C2%2C0%2C91453338

Thank you very much!

However you don't need to resend this patch just for this. I fixed it
manually while applying to my testing branch.

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168777): 
https://lists.openembedded.org/g/openembedded-core/message/168777
Mute This Topic: https://lists.openembedded.org/mt/92767146/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 v6] Rust Oe-Selftest implementation

[Luca Ceresoli via lists.openembedded.org]

Hi Pgowda,

On Tue, 2 Aug 2022 14:37:54 +0530
"Pgowda"  wrote:

> Hi Luca,
> 
> There were around 270 testcase failing when "has-elf-tls" has been
> enabled while building llvm.
> Hence, we had to remove the option to enable the proper working of these 
> tests.
> The patch has been tested on Ubuntu and also fedora (using docker image).

Thanks for the explanation. Then why not adding an explanatory comment,
as below?

# Disabled because.
#tspec['has-elf-tls'] = True

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168776): 
https://lists.openembedded.org/g/openembedded-core/message/168776
Mute This Topic: https://lists.openembedded.org/mt/92764644/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] [meta-oe][PATCH v4] classes: rootfs-postcommands: autologin root on serial-getty

[Johannes Schneider via lists.openembedded.org]

Hi,

v4 adds a variant for sysv - when/if using util-linux getty, since busybox does 
not seem to support an autologin option
also adds some documentation to the bbclass

regards

From: Johannes Schneider 
Sent: Tuesday, August 2, 2022 11:40
To: openembedded-core@lists.openembedded.org 

Cc: SCHNEIDER Johannes 
Subject: [meta-oe][PATCH v4] classes: rootfs-postcommands: autologin root on 
serial-getty

when empty-root-password AND serial-autologin-root are part of the
IMAGE_FEATURES, save some of the developers time by not having to type
the (then still sole) 'root' username on the serial console after each
and every reboot

this is done by inserting '--autologin root' into the command line of
the responsible 'getty' service

Signed-off-by: Johannes Schneider 
---
 meta/classes/core-image.bbclass   |  1 +
 meta/classes/image.bbclass|  2 +-
 meta/classes/rootfs-postcommands.bbclass  | 20 +++
 .../sysvinit/sysvinit-inittab/start_getty |  3 ++-
 4 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/meta/classes/core-image.bbclass b/meta/classes/core-image.bbclass
index 84fd3eeb38..6764035729 100644
--- a/meta/classes/core-image.bbclass
+++ b/meta/classes/core-image.bbclass
@@ -29,6 +29,7 @@
 #   - allow-empty-password
 #   - allow-root-login
 #   - post-install-logging
+# - serial-autologin-root - with 'empty-root-password': autologin 'root' on 
the serial console
 # - dev-pkgs- development packages (headers, etc.) for all 
installed packages in the rootfs
 # - dbg-pkgs- debug symbol packages for all installed packages in 
the rootfs
 # - lic-pkgs- license packages for all installed pacakges in the 
rootfs, requires
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 2139a7e576..fe32cdefd5 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -34,7 +34,7 @@ INHIBIT_DEFAULT_DEPS = "1"
 # IMAGE_FEATURES may contain any available package group
 IMAGE_FEATURES ?= ""
 IMAGE_FEATURES[type] = "list"
-IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs 
read-only-rootfs-delayed-postinsts stateless-rootfs empty-root-password 
allow-empty-password allow-root-login post-install-logging overlayfs-etc"
+IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs 
read-only-rootfs-delayed-postinsts stateless-rootfs empty-root-password 
allow-empty-password allow-root-login serial-autologin-root 
post-install-logging overlayfs-etc"

 # Generate companion debugfs?
 IMAGE_GEN_DEBUGFS ?= "0"
diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index a8a952f31d..3dadba6047 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -8,6 +8,9 @@ ROOTFS_POSTPROCESS_COMMAND += 
'${@bb.utils.contains_any("IMAGE_FEATURES", [ 'deb
 # Allow dropbear/openssh to accept root logins if debug-tweaks or 
allow-root-login is enabled
 ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [ 
'debug-tweaks', 'allow-root-login' ], "ssh_allow_root_login; ", "",d)}'

+# Autologin the root user on the serial console, if empty-root-password and 
serial-autologin-root are active
+ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("IMAGE_FEATURES", [ 
'empty-root-password', 'serial-autologin-root' ], "serial_autologin_root; ", 
"",d)}'
+
 # Enable postinst logging if debug-tweaks or post-install-logging is enabled
 ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [ 
'debug-tweaks', 'post-install-logging' ], "postinst_enable_logging; ", "",d)}'

@@ -196,6 +199,23 @@ ssh_allow_root_login () {
 fi
 }

+#
+# Autologin the 'root' user on the serial terminal,
+# if empty-root-password' AND 'serial-autologin-root are enabled
+#
+serial_autologin_root () {
+   if ${@bb.utils.contains("DISTRO_FEATURES", "sysvinit", "true", "false", 
d)}; then
+   # add autologin option to util-linux getty only
+   sed -i 's/options="/&--autologin root /' \
+   "${IMAGE_ROOTFS}${base_bindir}/start_getty"
+   elif ${@bb.utils.contains("DISTRO_FEATURES", "systemd", "true", 
"false", d)}; then
+   if [ -e 
${IMAGE_ROOTFS}${systemd_system_unitdir}/serial-getty@.service ]; then
+   sed -i '/^\s*ExecStart\b/ s/getty /&--autologin root /' 
\
+   
"${IMAGE_ROOTFS}${systemd_system_unitdir}/serial-getty@.service"
+   fi
+   fi
+}
+
 python sort_passwd () {
 import rootfspostcommands
 rootfspostcommands.sort_passwd(d.expand('${IMAGE_ROOTFS}${sysconfdir}'))
diff --git a/meta/recipes-core/sysvinit/sysvinit-inittab/start_getty 
b/meta/recipes-core/sysvinit/sysvinit-inittab/start_getty
index 699a1ead1a..7106fb72fb 100644
--- a/meta/recipes-core/sysvinit/sysvinit-inittab/start_getty
+++ 

[OE-core] [meta-oe][PATCH v4] classes: rootfs-postcommands: autologin root on serial-getty

[Johannes Schneider via lists.openembedded.org]

when empty-root-password AND serial-autologin-root are part of the
IMAGE_FEATURES, save some of the developers time by not having to type
the (then still sole) 'root' username on the serial console after each
and every reboot

this is done by inserting '--autologin root' into the command line of
the responsible 'getty' service

Signed-off-by: Johannes Schneider 
---
 meta/classes/core-image.bbclass   |  1 +
 meta/classes/image.bbclass|  2 +-
 meta/classes/rootfs-postcommands.bbclass  | 20 +++
 .../sysvinit/sysvinit-inittab/start_getty |  3 ++-
 4 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/meta/classes/core-image.bbclass b/meta/classes/core-image.bbclass
index 84fd3eeb38..6764035729 100644
--- a/meta/classes/core-image.bbclass
+++ b/meta/classes/core-image.bbclass
@@ -29,6 +29,7 @@
 #   - allow-empty-password
 #   - allow-root-login
 #   - post-install-logging
+# - serial-autologin-root - with 'empty-root-password': autologin 'root' on 
the serial console
 # - dev-pkgs- development packages (headers, etc.) for all 
installed packages in the rootfs
 # - dbg-pkgs- debug symbol packages for all installed packages in 
the rootfs
 # - lic-pkgs- license packages for all installed pacakges in the 
rootfs, requires
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 2139a7e576..fe32cdefd5 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -34,7 +34,7 @@ INHIBIT_DEFAULT_DEPS = "1"
 # IMAGE_FEATURES may contain any available package group
 IMAGE_FEATURES ?= ""
 IMAGE_FEATURES[type] = "list"
-IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs 
read-only-rootfs-delayed-postinsts stateless-rootfs empty-root-password 
allow-empty-password allow-root-login post-install-logging overlayfs-etc"
+IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs 
read-only-rootfs-delayed-postinsts stateless-rootfs empty-root-password 
allow-empty-password allow-root-login serial-autologin-root 
post-install-logging overlayfs-etc"
 
 # Generate companion debugfs?
 IMAGE_GEN_DEBUGFS ?= "0"
diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index a8a952f31d..3dadba6047 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -8,6 +8,9 @@ ROOTFS_POSTPROCESS_COMMAND += 
'${@bb.utils.contains_any("IMAGE_FEATURES", [ 'deb
 # Allow dropbear/openssh to accept root logins if debug-tweaks or 
allow-root-login is enabled
 ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [ 
'debug-tweaks', 'allow-root-login' ], "ssh_allow_root_login; ", "",d)}'
 
+# Autologin the root user on the serial console, if empty-root-password and 
serial-autologin-root are active
+ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("IMAGE_FEATURES", [ 
'empty-root-password', 'serial-autologin-root' ], "serial_autologin_root; ", 
"",d)}'
+
 # Enable postinst logging if debug-tweaks or post-install-logging is enabled
 ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [ 
'debug-tweaks', 'post-install-logging' ], "postinst_enable_logging; ", "",d)}'
 
@@ -196,6 +199,23 @@ ssh_allow_root_login () {
fi
 }
 
+#
+# Autologin the 'root' user on the serial terminal,
+# if empty-root-password' AND 'serial-autologin-root are enabled
+#
+serial_autologin_root () {
+   if ${@bb.utils.contains("DISTRO_FEATURES", "sysvinit", "true", "false", 
d)}; then
+   # add autologin option to util-linux getty only
+   sed -i 's/options="/&--autologin root /' \
+   "${IMAGE_ROOTFS}${base_bindir}/start_getty"
+   elif ${@bb.utils.contains("DISTRO_FEATURES", "systemd", "true", 
"false", d)}; then
+   if [ -e 
${IMAGE_ROOTFS}${systemd_system_unitdir}/serial-getty@.service ]; then
+   sed -i '/^\s*ExecStart\b/ s/getty /&--autologin root /' 
\
+   
"${IMAGE_ROOTFS}${systemd_system_unitdir}/serial-getty@.service"
+   fi
+   fi
+}
+
 python sort_passwd () {
 import rootfspostcommands
 rootfspostcommands.sort_passwd(d.expand('${IMAGE_ROOTFS}${sysconfdir}'))
diff --git a/meta/recipes-core/sysvinit/sysvinit-inittab/start_getty 
b/meta/recipes-core/sysvinit/sysvinit-inittab/start_getty
index 699a1ead1a..7106fb72fb 100644
--- a/meta/recipes-core/sysvinit/sysvinit-inittab/start_getty
+++ b/meta/recipes-core/sysvinit/sysvinit-inittab/start_getty
@@ -9,9 +9,10 @@ case $(readlink -f "${getty}") in
 if [ -x "/usr/bin/setsid" ] ; then
 setsid="/usr/bin/setsid"
 fi
+options=""
 ;;
 esac
 
 if [ -e /sys/class/tty/$2 -a -c /dev/$2 ]; then
-   ${setsid:-} ${getty} -L $1 $2 $3
+   ${setsid:-} ${getty} ${options:-} -L $1 $2 $3
 fi
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

[OE-core][PATCH] create-spdx: ignore packing control files from ipk and deb

[Jose Quaresma]

Otherwise spdx can have references for data that is not packed
in the package delivered because this contol data is temporarly
and only exist while the package is been write.

During do_package_write_ipk task in do_package_ipk the control
files is cleaned up at the end. This can create a race condiction
when the do_create_spdx task runs the add_package_files function
and these files is been deleted at same time in the
task do_package_write_ipk.

ERROR: alsa-topology-conf-1.2.5.1-r0 do_create_spdx: Error executing a python 
function in exec_func_python() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:do_create_spdx(d)
 0003:
File: 
'/srv/oe/build/conf/../../layers/openembedded-core/meta/classes/create-spdx.bbclass',
 lineno: 567, function: do_create_spdx
 0563:package_doc.add_relationship(package_doc, "DESCRIBES", 
spdx_package)
 0564:
 0565:package_archive = deploy_dir_spdx / "packages" / 
(package_doc.name + ".tar.zst")
 0566:with optional_tarfile(package_archive, archive_packaged) 
as archive:
 *** 0567:package_files = add_package_files(
 0568:d,
 0569:package_doc,
 0570:spdx_package,
 0571:pkgdest / package,
File: 
'/srv/oe/build/conf/../../layers/openembedded-core/meta/classes/create-spdx.bbclass',
 lineno: 234, function: add_package_files
 0230:info.mtime = source_date_epoch
 0231:
 0232:archive.addfile(info, f)
 0233:
 *** 0234:sha1 = bb.utils.sha1_file(filepath)
 0235:sha1s.append(sha1)
 0236:spdx_file.checksums.append(oe.spdx.SPDXChecksum(
 0237:algorithm="SHA1",
 0238:checksumValue=sha1,
File: '/srv/oe/bitbake/lib/bb/utils.py', lineno: 559, function: sha1_file
 0555:"""
 0556:Return the hex string representation of the SHA1 checksum of the 
filename
 0557:"""
 0558:import hashlib
 *** 0559:return _hasher(hashlib.sha1(), filename)
 0560:
 0561:def sha384_file(filename):
 0562:"""
 0563:Return the hex string representation of the SHA384 checksum of 
the filename
File: '/srv/oe/bitbake/lib/bb/utils.py', lineno: 528, function: _hasher
 0524:
 0525:def _hasher(method, filename):
 0526:import mmap
 0527:
 *** 0528:with open(filename, "rb") as f:
 0529:try:
 0530:with mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) as 
mm:
 0531:for chunk in iter(lambda: mm.read(8192), b''):
 0532:method.update(chunk)
Exception: FileNotFoundError: [Errno 2] No such file or directory: 
'/srv/oe/build/tmp-lmp/work/all-lmp-linux/alsa-topology-conf/1.2.5.1-r0/packages-split/alsa-topology-conf/CONTROL/control'

ERROR: Logfile of failure stored in: 
/srv/oe/build/tmp-lmp/work/all-lmp-linux/alsa-topology-conf/1.2.5.1-r0/temp/log.do_create_spdx.998864
INFO: recipe alsa-topology-conf-1.2.5.1-r0: task do_create_spdx: Failed

Signed-off-by: Jose Quaresma 
---
 meta/classes/create-spdx.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/create-spdx.bbclass b/meta/classes/create-spdx.bbclass
index 37b6b569a1..08ef7fd409 100644
--- a/meta/classes/create-spdx.bbclass
+++ b/meta/classes/create-spdx.bbclass
@@ -571,6 +571,7 @@ python do_create_spdx() {
 pkgdest / package,
 lambda file_counter: 
oe.sbom.get_packaged_file_spdxid(pkg_name, file_counter),
 lambda filepath: ["BINARY"],
+ignore_top_level_dirs=['CONTROL', 'DEBIAN'],
 archive=archive,
 )
 
-- 
2.37.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168773): 
https://lists.openembedded.org/g/openembedded-core/message/168773
Mute This Topic: https://lists.openembedded.org/mt/92767075/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 v6] Rust Oe-Selftest implementation

[Pgowda]

Hi Luca,

There were around 270 testcase failing when "has-elf-tls" has been
enabled while building llvm.
Hence, we had to remove the option to enable the proper working of these tests.
The patch has been tested on Ubuntu and also fedora (using docker image).

Thanks,
Pgowda

On Tue, Aug 2, 2022 at 2:08 PM Luca Ceresoli  wrote:
>
> On Tue,  2 Aug 2022 09:23:52 +0530
> "Pgowda"  wrote:
>
> > From: pgowda 
> >
> > The patch implements Rust testing framework similar to other selftest,
> > specifically the gcc selftest in OE. It uses the client and server
> > based method to test the binaries for cross-target on the image.
> > The test framework is a wrapper around the Rust build system as ./x.py
> > test.
> > It tests many functionalities of Rust distribution like tools,
> > documentation, libraries, packages, tools, Cargo, Crater etc.
> > Please refer the following link for detailed description of Rust
> > testing:-
> > https://rustc-dev-guide.rust-lang.org/tests/intro.html#tool-tests
> >
> > To support the rust tests in oe-core, the following functions were
> > added:-
> > setup_cargo_environment(): Build bootstrap and some early stage tools.
> > do_rust_setup_snapshot(): Install the snapshot version of rust binaries.
> > do_configure(): To generate config.toml
> > do_compile(): To build "remote-test-server" for qemu target image.
> >
> > Approximate Number of Tests Run in the Rust Testsuite :- 18000
> > Approximate Number of Tests that FAIL in bitbake environment :- 100-150
> > Normally majority of the testcases are present in major folder "test/"
> > It contributes to more than 80% of the testcases present in Rust test
> > framework. These tests pass as expected on any Rust versions without
> > much fuss. The tests that fail are of less important and contribute to
> > less than 2% of the total testcases. These minor tests are observed to
> > work on some versions and fail on others. They have to be added, ignored
> > or excluded for different versions as per the behavior.
> > These tests have been ignored or excluded in the Rust selftest
> > environment to generate success of completing the testsuite.
> >
> > These tests work in parallel mode even in the skipped test mode as
> > expected. Although the patch to disable tests is large, it is very simple
> > in that it only disables tests. When updating to a newer version of Rust,
> > the patch can usually be ported in a day.
> >
> > Signed-off-by: pgowda 
> > Signed-off-by: Vinay Kumar 
> > ---
> >  meta/classes/rust-target-config.bbclass   |   2 +-
> >  meta/lib/oeqa/selftest/cases/rust.py  |  57 +++
> >  meta/recipes-devtools/rust/rust-testsuite.inc | 164 ++
> >  .../rust-testsuite/rust-oe-selftest.patch | 477 ++
> >  .../rust/rust-testsuite_1.62.0.bb |   3 +
> >  5 files changed, 702 insertions(+), 1 deletion(-)
> >  create mode 100644 meta/lib/oeqa/selftest/cases/rust.py
> >  create mode 100644 meta/recipes-devtools/rust/rust-testsuite.inc
> >  create mode 100644 
> > meta/recipes-devtools/rust/rust-testsuite/rust-oe-selftest.patch
> >  create mode 100644 meta/recipes-devtools/rust/rust-testsuite_1.62.0.bb
> >
> > diff --git a/meta/classes/rust-target-config.bbclass 
> > b/meta/classes/rust-target-config.bbclass
> > index 87b7dee3ed..26dc931971 100644
> > --- a/meta/classes/rust-target-config.bbclass
> > +++ b/meta/classes/rust-target-config.bbclass
> > @@ -344,7 +344,7 @@ def rust_gen_target(d, thing, wd, arch):
> >  tspec['linker-is-gnu'] = True
> >  tspec['linker-flavor'] = "gcc"
> >  tspec['has-rpath'] = True
> > -tspec['has-elf-tls'] = True
> > +#tspec['has-elf-tls'] = True
>
> I'm not sure of the meaning of the above change, can you clarify that?
>
> Thanks.
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168772): 
https://lists.openembedded.org/g/openembedded-core/message/168772
Mute This Topic: https://lists.openembedded.org/mt/92764644/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 v6] Rust Oe-Selftest implementation

[Luca Ceresoli via lists.openembedded.org]

On Tue,  2 Aug 2022 09:23:52 +0530
"Pgowda"  wrote:

> From: pgowda 
> 
> The patch implements Rust testing framework similar to other selftest,
> specifically the gcc selftest in OE. It uses the client and server
> based method to test the binaries for cross-target on the image.
> The test framework is a wrapper around the Rust build system as ./x.py
> test.
> It tests many functionalities of Rust distribution like tools,
> documentation, libraries, packages, tools, Cargo, Crater etc.
> Please refer the following link for detailed description of Rust
> testing:-
> https://rustc-dev-guide.rust-lang.org/tests/intro.html#tool-tests
> 
> To support the rust tests in oe-core, the following functions were
> added:-
> setup_cargo_environment(): Build bootstrap and some early stage tools.
> do_rust_setup_snapshot(): Install the snapshot version of rust binaries.
> do_configure(): To generate config.toml
> do_compile(): To build "remote-test-server" for qemu target image.
> 
> Approximate Number of Tests Run in the Rust Testsuite :- 18000
> Approximate Number of Tests that FAIL in bitbake environment :- 100-150
> Normally majority of the testcases are present in major folder "test/"
> It contributes to more than 80% of the testcases present in Rust test
> framework. These tests pass as expected on any Rust versions without
> much fuss. The tests that fail are of less important and contribute to
> less than 2% of the total testcases. These minor tests are observed to
> work on some versions and fail on others. They have to be added, ignored
> or excluded for different versions as per the behavior.
> These tests have been ignored or excluded in the Rust selftest
> environment to generate success of completing the testsuite.
> 
> These tests work in parallel mode even in the skipped test mode as
> expected. Although the patch to disable tests is large, it is very simple
> in that it only disables tests. When updating to a newer version of Rust,
> the patch can usually be ported in a day.
> 
> Signed-off-by: pgowda 
> Signed-off-by: Vinay Kumar 
> ---
>  meta/classes/rust-target-config.bbclass   |   2 +-
>  meta/lib/oeqa/selftest/cases/rust.py  |  57 +++
>  meta/recipes-devtools/rust/rust-testsuite.inc | 164 ++
>  .../rust-testsuite/rust-oe-selftest.patch | 477 ++
>  .../rust/rust-testsuite_1.62.0.bb |   3 +
>  5 files changed, 702 insertions(+), 1 deletion(-)
>  create mode 100644 meta/lib/oeqa/selftest/cases/rust.py
>  create mode 100644 meta/recipes-devtools/rust/rust-testsuite.inc
>  create mode 100644 
> meta/recipes-devtools/rust/rust-testsuite/rust-oe-selftest.patch
>  create mode 100644 meta/recipes-devtools/rust/rust-testsuite_1.62.0.bb
> 
> diff --git a/meta/classes/rust-target-config.bbclass 
> b/meta/classes/rust-target-config.bbclass
> index 87b7dee3ed..26dc931971 100644
> --- a/meta/classes/rust-target-config.bbclass
> +++ b/meta/classes/rust-target-config.bbclass
> @@ -344,7 +344,7 @@ def rust_gen_target(d, thing, wd, arch):
>  tspec['linker-is-gnu'] = True
>  tspec['linker-flavor'] = "gcc"
>  tspec['has-rpath'] = True
> -tspec['has-elf-tls'] = True
> +#tspec['has-elf-tls'] = True

I'm not sure of the meaning of the above change, can you clarify that?

Thanks.
-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168771): 
https://lists.openembedded.org/g/openembedded-core/message/168771
Mute This Topic: https://lists.openembedded.org/mt/92764644/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] rng-tools: Replace obsolete "wants systemd-udev-settle"

[Khem Raj]

On Tue, Aug 2, 2022 at 8:24 AM Claudius Heine  wrote:

> Hi Drew,
>
> On 2022-08-01 20:44, Drew Moseley wrote:
> > On 7/26/22 9:17 AM, drew.mose...@gmail.com wrote:
> >
> >> From: Drew Moseley 
> >>
> >> The systemd-udev-settle service is listed as obsolete and does in
> >> some cases result in a significant boot time.  Replace that with
> >> "after systemd-modules-load" to allow the random source hardware
> >> to be loaded in the proper sequence.
> >>
> >> Before this change:
> >>
> >> Startup finished in 4.025s (kernel) + 2min 13.236s (userspace) =
> >> 2min 17.262s
> >> multi-user.target reached after 2min 8.153s in userspace
> >>
> >> After this change:
> >>
> >> Startup finished in 3.956s (kernel) + 13.294s (userspace) = 17.250s
> >> multi-user.target reached after 9.522s in userspace
> >>
> >> Signed-off-by: Drew Moseley 
> >> ---
> >>   meta/recipes-support/rng-tools/rng-tools/rngd.service | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service
> >> b/meta/recipes-support/rng-tools/rng-tools/rngd.service
> >> index 568686e80e..e818cfcf78 100644
> >> --- a/meta/recipes-support/rng-tools/rng-tools/rngd.service
> >> +++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service
> >> @@ -3,7 +3,7 @@ Description=Hardware RNG Entropy Gatherer Daemon
> >>   DefaultDependencies=no
> >>   After=systemd-udev-settle.service
> >>   Before=sysinit.target shutdown.target
> >> -Wants=systemd-udev-settle.service
> >> +After=systemd-modules-load.service
> >>   Conflicts=shutdown.target
> >>   [Service]
> >
> >
> > Hi Khem, Claudius,
> >
> > Any thoughts on this change? Obviously I cannot verify if the original
> > hardware combination issue is resolved and unfortunately it sounds like
> > you cannot either but I'm using this successfully to work around the
> > delayed boots I was seeing here.
>
> Well as I said, `systemd-modules-load.service` just waits until all
> statically configured modules are loaded, however not until the
> `/dev/hwrng` device node is available. `systemd-udev-settle.service`
> waits until all udev rules are applied, and that means it includes
> loading of all dynamically loaded modules as well as executing code that
> creates symlinks, etc.
>
> Instead of waiting for modules to be loaded, that might be unrelated or
> waiting for all (mostly unrelated) udev rules to be settled, I think
> waiting directly for the `/dev/hwrng` device node might be more explicit
> and specific.
>

Yeah something more surgical and pointed

Requires=dev-hwrng.device
After=dev-hwrng.device


Might be worth trying



> regards,
> Claudius
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168770): 
https://lists.openembedded.org/g/openembedded-core/message/168770
Mute This Topic: https://lists.openembedded.org/mt/92626958/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] rng-tools: Replace obsolete "wants systemd-udev-settle"

[Claudius Heine]

Hi Drew,

On 2022-08-01 20:44, Drew Moseley wrote:

On 7/26/22 9:17 AM, drew.mose...@gmail.com wrote:


From: Drew Moseley 

The systemd-udev-settle service is listed as obsolete and does in
some cases result in a significant boot time.  Replace that with
"after systemd-modules-load" to allow the random source hardware
to be loaded in the proper sequence.

Before this change:

    Startup finished in 4.025s (kernel) + 2min 13.236s (userspace) = 
2min 17.262s

    multi-user.target reached after 2min 8.153s in userspace

After this change:

    Startup finished in 3.956s (kernel) + 13.294s (userspace) = 17.250s
    multi-user.target reached after 9.522s in userspace

Signed-off-by: Drew Moseley 
---
  meta/recipes-support/rng-tools/rng-tools/rngd.service | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service 
b/meta/recipes-support/rng-tools/rng-tools/rngd.service

index 568686e80e..e818cfcf78 100644
--- a/meta/recipes-support/rng-tools/rng-tools/rngd.service
+++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service
@@ -3,7 +3,7 @@ Description=Hardware RNG Entropy Gatherer Daemon
  DefaultDependencies=no
  After=systemd-udev-settle.service
  Before=sysinit.target shutdown.target
-Wants=systemd-udev-settle.service
+After=systemd-modules-load.service
  Conflicts=shutdown.target
  [Service]



Hi Khem, Claudius,

Any thoughts on this change? Obviously I cannot verify if the original 
hardware combination issue is resolved and unfortunately it sounds like 
you cannot either but I'm using this successfully to work around the 
delayed boots I was seeing here.


Well as I said, `systemd-modules-load.service` just waits until all 
statically configured modules are loaded, however not until the 
`/dev/hwrng` device node is available. `systemd-udev-settle.service` 
waits until all udev rules are applied, and that means it includes 
loading of all dynamically loaded modules as well as executing code that 
creates symlinks, etc.


Instead of waiting for modules to be loaded, that might be unrelated or 
waiting for all (mostly unrelated) udev rules to be settled, I think 
waiting directly for the `/dev/hwrng` device node might be more explicit 
and specific.


regards,
Claudius

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#168769): 
https://lists.openembedded.org/g/openembedded-core/message/168769
Mute This Topic: https://lists.openembedded.org/mt/92626958/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 2/2] wic/bootimg-efi: Add support for loading devicetree files

[Jan Kiszka]

On 01.08.22 16:12, Luca Ceresoli wrote:
> Hello Jan,
> 
> On Sat, 30 Jul 2022 10:24:43 +0200
> "Jan Kiszka"  wrote:
> 
>> From: Jan Kiszka 
>>
>> For device tree using systems, add support to set a custom devices tree
>> during UEFI boot. This requires to copy the DTB file to the boot
>> partition and to add the respective loader entries to the configuration
>> files.
>>
>> Both grub and systemd-boot support only loading a specific device tree.
>> Therefore refuse to work if the 'dtb' parameter contains more than one
>> entry.
>>
>> Out of scope for now are overlays (only supported by systemd-boot).
>>
>> Signed-off-by: Jan Kiszka 
>> ---
> 
> [...]
> 
>> @@ -327,11 +350,13 @@ class BootimgEFIPlugin(SourcePlugin):
>>  objcopy_cmd = "objcopy \
>>  --add-section .osrel=%s --change-section-vma 
>> .osrel=0x2 \
>>  --add-section .cmdline=%s --change-section-vma 
>> .cmdline=0x3 \
>> +%s \
>>  --add-section .linux=%s --change-section-vma 
>> .linux=0x200 \
>>  --add-section .initrd=%s --change-section-vma 
>> .initrd=0x300 \
>>  %s %s" % \
>>  ("%s/usr/lib/os-release" % staging_dir_host,
>>  cmdline.name,
>> +dtb_params,
>>  "%s/%s" % (staging_kernel_dir, kernel),
>>  initrd.name,
>>  efi_stub,
> 
> This hunk conflicts with the changes introduced by [0], which is
> already in my testing branch. I have applied your patch with a little
> change to resolve the conflict, can you please have a look at the result
> [1] to ensure I correctly followed the logic of your patch?
> 
> [0] https://lists.openembedded.org/g/openembedded-core/message/168553
> [1]
> https://git.openembedded.org/openembedded-core-contrib/commit/?h=lucaceresoli/master-next=7547ec3e2065e55a8caa6118fc962130b8c6bd98
> 
> Best regards.

Looks good, thanks!

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

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