Re: [OE-core] [qa-build-notification] QA notification for completed autobuilder build (yocto-4.2_M2.rc2)

[Jing Hui Tham]

Hi All,
 
QA for yocto-4.2_M2.rc2 is completed. This is the full report for this release: 
 
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults
 
=== Summary 
No high milestone defects.
 
No new issue found. 
 
Thanks,
Jing Hui



> -Original Message-
> From: qa-build-notificat...@lists.yoctoproject.org  notificat...@lists.yoctoproject.org> On Behalf Of Pokybuild User
> Sent: Friday, 27 January, 2023 1:13 PM
> To: yo...@lists.yoctoproject.org
> Cc: qa-build-notificat...@lists.yoctoproject.org
> Subject: [qa-build-notification] QA notification for completed autobuilder
> build (yocto-4.2_M2.rc2)
> 
> 
> A build flagged for QA (yocto-4.2_M2.rc2) was completed on the
> autobuilder and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-4.2_M2.rc2
> 
> 
> Build hash information:
> 
> bitbake: c19035e8e71c419c5688a86bfc9c946c96f638e8
> meta-agl: 09135164a21a216c6e3e75d7decce896b92962f0
> meta-arm: d8383c11f3f8220d2b989ec73604e5faff988299
> meta-aws: 7b4f54b3e1f675e2033f6a589ac519e44e62b58b
> meta-intel: b3c7d3ee44e4ab71df44b5be3c48d2f47d89d8a0
> meta-mingw: 250617ffa524c082b848487359b9d045703d59c2
> meta-openembedded: ceceffcb1e3ef4f9ba7708f77c27e30a7aea61e5
> meta-virtualization: 31954471605ae3b41627a0ab7b0dcfe8c5851bd7
> oecore: 493f2d163718d78560a2b3ad5d3c0fb34caae8c0
> poky: 5e249ec855517765f4b99e8039cb888ffa09c211
> 
> 
> 
> This is an automated message from the Yocto Project Autobuilder
> Git: git://git.yoctoproject.org/yocto-autobuilder2
> Email: richard.pur...@linuxfoundation.org
> 
> 
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176526): 
https://lists.openembedded.org/g/openembedded-core/message/176526
Mute This Topic: https://lists.openembedded.org/mt/96648684/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] gnutls: add initial ptest support

[Ravineet Singh]

On Mon, Jan 30, 2023 at 10:32:53AM +0100, Ravineet Singh wrote:
> On Mon, Jan 30, 2023 at 10:08:13AM +0100, Alexander Kanavin wrote:
> > On Mon, 30 Jan 2023 at 09:49, Ravineet Singh  
> > wrote:
> > > > Those local files are provided by something, so you should find out
> > > > what that something is. Is it gnutls source tree itself? Or some other
> > > > component? Do we have a recipe for it?
> > > Yes, these are from gnutls source tree itself.
> > > I did not want to have the logic to install these files in this patch 
> > > (want to keep it short),
> > > rather later as I progress in my learning of bitbake magic.
> >
> > That's okay, but making the test set as complete as possible would be
> > appreciated. You have the knowledge and context for it in your head
> > right now, and it's going to be harder for someone else, or even for
> > you later on.
> makes sense, I'll put some effort into it and send upgraded patch.
> Thanks Alex!
>  Ravineet
So, tried to add missing files via autotools-brokensep (not recommendded), but 
still some tests will not
be possible to run since they are expected to be run via wrapper shell scripts. 
These are the test:
 - system-override-curves-allowlist"
 - system-override-hash"
 - system-override-sig"
 - system-override-sig-tls"
 - system-prio-file"
Giving up at this stage, don't really see a good way forward.

I will post initial patch updated with comments you had before, in case someone 
else wants to look at it.
I do understand that you may not want to integrate the patch.
/Ravineet

> >
> > Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176525): 
https://lists.openembedded.org/g/openembedded-core/message/176525
Mute This Topic: https://lists.openembedded.org/mt/96519581/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] httpserver: add error handler that write to the logger

[Ross Burton]

Signed-off-by: Ross Burton 
---
 meta/lib/oeqa/utils/httpserver.py | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/lib/oeqa/utils/httpserver.py 
b/meta/lib/oeqa/utils/httpserver.py
index 2aa172bf799..80752c13770 100644
--- a/meta/lib/oeqa/utils/httpserver.py
+++ b/meta/lib/oeqa/utils/httpserver.py
@@ -44,6 +44,12 @@ class HTTPService:
 self.port = self.server.server_port
 self.process = 
multiprocessing.Process(target=self.server.server_start, args=[self.root_dir, 
self.logger])
 
+def handle_error(self, request, client_address):
+import traceback
+exception = traceback.format_exc()
+self.logger.warn("Exception when handling %s: %s" % (request, 
exception))
+self.server.handle_error = handle_error
+
 # The signal handler from testimage.bbclass can cause deadlocks here
 # if the HTTPServer is terminated before it can restore the standard 
 #signal behaviour
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176524): 
https://lists.openembedded.org/g/openembedded-core/message/176524
Mute This Topic: https://lists.openembedded.org/mt/96655710/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] Current QA failure challenges (perf, QA http-server, asyncio prserv, bitbake runCommand timeout, unfsd test issue)

[Richard Purdie]

On Tue, 2023-01-31 at 16:14 +0100, Alexander Kanavin wrote:
> On Sun, 29 Jan 2023 at 16:41, Richard Purdie
>  wrote:
> > http-server in dnf tests breaking
> > =
> > 
> > We've started seeing a lot of short packets with the http-server used
> > by the dnf package manager tests. dnf retries and succeeds leaving a
> > failure in the logs which parse_logs picks up.
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/6592/steps/14/logs/stdio
> > Central error: 2023-01-29T11:43:32+ INFO Error during transfer: Curl 
> > error (18): Transferred a partial file for 
> > http://192.168.7.1:36183/cortexa15t2hf_neon/libc6-2.36-r0.cortexa15t2hf_neon.rpm
> >  [transfer closed with 15758 bytes remaining to read]
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/6592/steps/14/logs/stdio
> > Central error: 2023-01-29T11:07:31+ INFO Error during transfer: Curl 
> > error (18): Transferred a partial file for 
> > http://192.168.7.3:42417/core2_32/busybox-1.35.0-r0.core2_32.rpm [transfer 
> > closed with 14627 bytes remaining to read]
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/6598/steps/13/logs/stdio
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/6532
> > 
> > and a load more. Why the sudden increase in frequency, not sure. Could
> > be 6.1 kernel related.
> 
> 
> I ran this locally three times with master and it wouldn't reproduce.
> Probably build host has something to do with it too?

I think you need two different host OSes. Which two trigger it and why
I don't know.

The last run on the autobuilder was fedora37 and then alma8 FWIW.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176523): 
https://lists.openembedded.org/g/openembedded-core/message/176523
Mute This Topic: https://lists.openembedded.org/mt/96607332/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 31 January 2023 (WW05)

[Alexander Kanavin]

On Tue, 31 Jan 2023 at 15:14, Stephen Jolley  wrote:
> Key Status/Updates:
>
> YP 4.0.7 and YP 4.2 M2 are in QA
> We switched to the 6.1 kernel by default for M2. Unfortunately there are a 
> couple of intermittent issues that seem to have crept in. One is a 
> reproducibility issue in perf, likely with some host component causing it as 
> it only occurs on second builds. The second appears to be an intermittent 
> networking issue accessing a python http-server for testing dnf which 
> appeared after the kernel version change.
> We are continuing to see other intermittent failures which are limiting how 
> quickly we can merge changes. A summary of some of the key issues was sent to 
> the mailing list: 
> https://lists.openembedded.org/g/openembedded-core/message/176476
> There have been changes to the way the codeparser cache in bitbake stores 
> data which should reduce cache size, reduce the times data needs to be 
> written out and generally help performance.
> CVE levels in master are still high but there are patches in progress for 
> most issues as I understand it.
> We have a growing number of bugs in bugzilla, any help with them is 
> appreciated.

Please do notice there's a new public article by RP:
https://www.linux.com/audience/maintainer-confidential-opportunities-and-challenges-of-the-ubiquitous-but-under-resourced-yocto-project/

"Maintainer confidential: Opportunities and challenges of the
ubiquitous but under-resourced Yocto Project.
Maintainers are an important topic of discussion. I’ve read a few
perspectives, but I’d like to share mine as one of the lesser-known
maintainers in the open source world."

LWN has picked it up as well:
https://lwn.net/Articles/921646
(many of the comments are the usual 'yocto is hard' fare, which should
be treated like the weather - inevitable)

Alex

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176522): 
https://lists.openembedded.org/g/openembedded-core/message/176522
Mute This Topic: https://lists.openembedded.org/mt/96652593/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] Current QA failure challenges (perf, QA http-server, asyncio prserv, bitbake runCommand timeout, unfsd test issue)

[Alexander Kanavin]

On Sun, 29 Jan 2023 at 16:41, Richard Purdie
 wrote:
> http-server in dnf tests breaking
> =
>
> We've started seeing a lot of short packets with the http-server used
> by the dnf package manager tests. dnf retries and succeeds leaving a
> failure in the logs which parse_logs picks up.
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/6592/steps/14/logs/stdio
> Central error: 2023-01-29T11:43:32+ INFO Error during transfer: Curl 
> error (18): Transferred a partial file for 
> http://192.168.7.1:36183/cortexa15t2hf_neon/libc6-2.36-r0.cortexa15t2hf_neon.rpm
>  [transfer closed with 15758 bytes remaining to read]
> https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/6592/steps/14/logs/stdio
> Central error: 2023-01-29T11:07:31+ INFO Error during transfer: Curl 
> error (18): Transferred a partial file for 
> http://192.168.7.3:42417/core2_32/busybox-1.35.0-r0.core2_32.rpm [transfer 
> closed with 14627 bytes remaining to read]
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/6598/steps/13/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/6532
>
> and a load more. Why the sudden increase in frequency, not sure. Could
> be 6.1 kernel related.


I ran this locally three times with master and it wouldn't reproduce.
Probably build host has something to do with it too?

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176521): 
https://lists.openembedded.org/g/openembedded-core/message/176521
Mute This Topic: https://lists.openembedded.org/mt/96607332/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] Current QA failure challenges (perf, QA http-server, asyncio prserv, bitbake runCommand timeout, unfsd test issue)

[Bruce Ashfield]

On Sun, Jan 29, 2023 at 10:41 AM Richard Purdie
 wrote:
>
> Hi All,
>
> I've going to be a distracted this next week with other project related
> things and the autobuilder is showing a number of problems. I've spent
> part of my weekend trying to stabilise things so I could not have the
> distraction and whilst I've had partial success, things aren't
> resolved. I'm sending this out in the hope others may be able to
> help/assist. The issues:
>
> Kernel 6.1 reproducibility issue in perf
> 
>
> We've had two fixes which do seem to have fixed the kernel-devsrc issue
> but not the perf one. The diffoscope:
>
> http://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20230129-8bp_1b_z/packages/diff-html/
>
> The autobuilder failure:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/2314/steps/13/logs/stdio
>
> Part of the issue is this seems to be host contamination, so you do
> need to build on a different host. The first time the test runs, it
> does so on the same host and the output is unchanged which is why we've
> had green builds but then failures.
>
> I did try removing the sstate for perf, the issue came back, so it
> isn't a cache contamination issue afaik.


I don't have a great local setup for looking at reproducibility
issues, but once I'm through my current kernel upgrade issues, I'll
start looking at this.

Bruce

>
>
> bitbake timeout on sending commands
> ===
>
> Bitbake runCommand appears to be able to hang in the send since
> there is no timeout set there. This can cause things to block. We need
> to put a worse case timeout/exit in there.
>
>
> unfs tests leave nfs server running
> ===
>
> After the unfs NFS test runs, we seem to leave an unfs server hanging
> around after the builds are long gone. These build up on the
> autobuilder workers.
>
>
> http-server in dnf tests breaking
> =
>
> We've started seeing a lot of short packets with the http-server used
> by the dnf package manager tests. dnf retries and succeeds leaving a
> failure in the logs which parse_logs picks up.
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/6592/steps/14/logs/stdio
> Central error: 2023-01-29T11:43:32+ INFO Error during transfer: Curl 
> error (18): Transferred a partial file for 
> http://192.168.7.1:36183/cortexa15t2hf_neon/libc6-2.36-r0.cortexa15t2hf_neon.rpm
>  [transfer closed with 15758 bytes remaining to read]
> https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/6592/steps/14/logs/stdio
> Central error: 2023-01-29T11:07:31+ INFO Error during transfer: Curl 
> error (18): Transferred a partial file for 
> http://192.168.7.3:42417/core2_32/busybox-1.35.0-r0.core2_32.rpm [transfer 
> closed with 14627 bytes remaining to read]
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/6598/steps/13/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/6532
>
> and a load more. Why the sudden increase in frequency, not sure. Could
> be 6.1 kernel related.
>
>
> asyncio issues with PR Serv
> ===
>
> I've found at least one bug with what the code was doing and fixing
> that should help some of the test failures we've seen. When looking
> into that I found more problems though.
>
> If you run "oe-selftest -r prservice -j 3 -K" and then look at the
> bitbake-cookerdaemon.log, it shows a load of python asyncio issues. The
> first one is:
>
> /usr/lib/python3.10/asyncio/base_events.py:685: ResourceWarning:
> unclosed event loop <_UnixSelectorEventLoop running=False closed=False
> debug=False>
>   _warn(f"unclosed event loop {self!r}", ResourceWarning, source=self)
>
> showing connections to the PR service aren't being cleaned up.
>
> Also:
>
> /home/pokybuild/yocto-worker/oe-selftest-
> debian/build/bitbake/lib/bb/codeparser.py:472: ResourceWarning:
> unclosed  type=SocketKind.SOCK_STREAM, proto=6, laddr=('127.0.0.1', 47910),
> raddr=('127.0.0.1', 40751)>
>   self.process_tokens(more_tokens)
>
> but the codeparser reference isn't accurate, it is just from the
> garbage collection point.
>
> The second issue is that in running the selftests, a PR Service process
> often seems to be left behind without bitbake running. It suggests some
> kind of lifecycle issue somewhere. It might only be happening in
> failure cases, not sure.
>
> The third issue seems to be around event loop shutdown. On debian11
> with py 3.9, when bitbake is shutting down we're seeing:
>
> 412934 07:12:26.081334 Exiting (socket: True)
> /usr/lib/python3.9/signal.py:30: ResourceWarning: unclosed
>  type=SocketKind.SOCK_STREAM, proto=6, laddr=('127.0.0.1', 36287), r
> addr=('127.0.0.1', 36422)>
>   return enum_klass(value)
> ResourceWarning: Enable tracemalloc to get the object allocation
> traceback
> /usr/lib/python3.9/asyncio/selector_events.py:704: ResourceWarning:
> unclosed 

[OE-core] Yocto Project Status 31 January 2023 (WW05)

[Stephen Jolley]

Current Dev Position: YP 4.2 M3

Next Deadline: 20th February 2023 YP 4.2 M3 Build

 

Next Team Meetings:

*   Bug Triage meeting Thursday February 2nd 7:30 am PDT (

https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
*   Weekly Project Engineering Sync Tuesday January 31st at 8 am PDT (

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

 

Key Status/Updates:

*   YP 4.0.7 and YP 4.2 M2 are in QA
*   We switched to the 6.1 kernel by default for M2. Unfortunately there
are a couple of intermittent issues that seem to have crept in. One is a
reproducibility issue in perf, likely with some host component causing it as
it only occurs on second builds. The second appears to be an intermittent
networking issue accessing a python http-server for testing dnf which
appeared after the kernel version change.
*   We are continuing to see other intermittent failures which are
limiting how quickly we can merge changes. A summary of some of the key
issues was sent to the mailing list:

https://lists.openembedded.org/g/openembedded-core/message/176476
*   There have been changes to the way the codeparser cache in bitbake
stores data which should reduce cache size, reduce the times data needs to
be written out and generally help performance.
*   CVE levels in master are still high but there are patches in
progress for most issues as I understand it.
*   We have a growing number of bugs in bugzilla, any help with them is
appreciated.

 

Ways to contribute:

*   As people are likely aware, the project has a number of components
which are either unmaintained, or have people with little to no time trying
to keep them alive. These components include: patchtest, layerindex,
devtool, toaster, wic, oeqa, autobuilder, CROPs containers, pseudo and more.
Many have open bugs. Help is welcome in trying to better look after these
components!
*   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.2. See:

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

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

 

YP 4.2 Milestone Dates:

*   YP 4.2 M2 built and in QA
*   YP 4.2 M3 build date 2023/02/20
*   YP 4.2 M3 Release date 2023/03/03
*   YP 4.2 M4 build date 2023/04/03
*   YP 4.2 M4 Release date 2023/04/28

 

Upcoming dot releases:

*   YP 4.0.7 built and in QA
*   YP 3.1.23 build date 2023/02/13
*   YP 3.1.23 Release date 2023/02/24
*   YP 4.0.8 build date 2023/02/27
*   YP 4.0.8 Release date 2023/03/10
*   YP 4.1.3 build date 2023/03/06
*   YP 4.1.3 Release date 2023/03/17
*   YP 3.1.24 build date 2023/03/20
*   YP 3.1.24 Release date 2023/03/31
*   YP 4.0.9 build date 2023/04/10
*   YP 4.0.9 Release date 2023/04/21
*   YP 4.1.4 build date 2023/05/01
*   YP 4.1.4 Release date 2023/05/13
*   YP 3.1.25 build date 2023/05/08
*   YP 3.1.25 Release date 2023/05/19
*   YP 4.0.10 build date 2023/05/15
*   YP 4.0.10 Release date 2023/05/26

 

Tracking Metrics:

*   WDD 2447 (last week 2442) (

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

*   Total patches found: 1205 (last week 1190)
*   Patches in the Pending State: 280 (23%) [last week 279 (24%)]

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

 

The Yocto Project's technical governance is through its Technical Steering

Re: [OE-core] [PATCH] bootimg-efi.py: Skip installing kernel-image into boot partition for rootfs-reliant systems.

[Richard Purdie]

On Tue, 2023-01-31 at 13:04 +0100, Kareem Zarka wrote:
> From: Kareem Zarka 
> 
> The issue with installing the kernel-image to both rootfs
> and boot partition is that some systems rely on the kernel-image in
> rootfs and not in the boot partition.
> This leads to duplication of the kernel-image, which can cause
> unnecessary storage usage and potential compatibility issues.
> 
> This patch provides a solution to this problem by adding a new
> parameter "skip-kernel-install" to the wic kickstart file, which can
> be passed to the plugin.
> If the parameter is provided, the plugin will skip installing the
> kernel-image to the boot partition, avoiding duplication and potential
> issues.
> 
> By adding this new parameter, we give the users the option to install
> the kernel-image only in rootfs, or to install it in both rootfs and
> boot partition, depending on their needs and preferences.
> This will help to improve the system's storage usage and compatibility.
> 
> Signed-off-by: Kareem Zarka 
> ---
>  scripts/lib/wic/plugins/source/bootimg-efi.py | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py 
> b/scripts/lib/wic/plugins/source/bootimg-efi.py
> index 4b00913a70..e04d49abe6 100644
> --- a/scripts/lib/wic/plugins/source/bootimg-efi.py
> +++ b/scripts/lib/wic/plugins/source/bootimg-efi.py
> @@ -363,9 +363,13 @@ class BootimgEFIPlugin(SourcePlugin):
>  objcopy_cmd += " %s %s/EFI/Linux/linux.efi" % (efi_stub, 
> hdddir)
>  exec_native_cmd(objcopy_cmd, native_sysroot)
>  else:
> -install_cmd = "install -m 0644 %s/%s %s/%s" % \
> -(staging_kernel_dir, kernel, hdddir, kernel)
> -exec_cmd(install_cmd)
> +# skip_kernal_install was added to source_params to conifgure 
> installing the kernel-image.
> +# set skip_kernal_install in the kickstart file to skip 
> installing it into hdddir.
> +# if not set then the kernel-image will be installed.
> +if not  source_params.get('skip_kernal_install'):
> +install_cmd = "install -m 0644 %s/%s %s/%s" % \
> +(staging_kernel_dir, kernel, hdddir, kernel)
> +exec_cmd(install_cmd)
>  
>  if get_bitbake_var("IMAGE_EFI_BOOT_FILES"):
>  for src_path, dst_path in cls.install_task:

I'm fine with adding such an option but could you also add a test for
it please? wic has good test coverage and I'd like to keep that. You
can run the tests with:

oe-selftest -r wic

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176518): 
https://lists.openembedded.org/g/openembedded-core/message/176518
Mute This Topic: https://lists.openembedded.org/mt/96650530/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] bootimg-efi.py: Skip installing kernel-image into boot partition for rootfs-reliant systems.

[Kareem Zarka]

From: Kareem Zarka 

The issue with installing the kernel-image to both rootfs
and boot partition is that some systems rely on the kernel-image in
rootfs and not in the boot partition.
This leads to duplication of the kernel-image, which can cause
unnecessary storage usage and potential compatibility issues.

This patch provides a solution to this problem by adding a new
parameter "skip-kernel-install" to the wic kickstart file, which can
be passed to the plugin.
If the parameter is provided, the plugin will skip installing the
kernel-image to the boot partition, avoiding duplication and potential
issues.

By adding this new parameter, we give the users the option to install
the kernel-image only in rootfs, or to install it in both rootfs and
boot partition, depending on their needs and preferences.
This will help to improve the system's storage usage and compatibility.

Signed-off-by: Kareem Zarka 
---
 scripts/lib/wic/plugins/source/bootimg-efi.py | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py 
b/scripts/lib/wic/plugins/source/bootimg-efi.py
index 4b00913a70..e04d49abe6 100644
--- a/scripts/lib/wic/plugins/source/bootimg-efi.py
+++ b/scripts/lib/wic/plugins/source/bootimg-efi.py
@@ -363,9 +363,13 @@ class BootimgEFIPlugin(SourcePlugin):
 objcopy_cmd += " %s %s/EFI/Linux/linux.efi" % (efi_stub, 
hdddir)
 exec_native_cmd(objcopy_cmd, native_sysroot)
 else:
-install_cmd = "install -m 0644 %s/%s %s/%s" % \
-(staging_kernel_dir, kernel, hdddir, kernel)
-exec_cmd(install_cmd)
+# skip_kernal_install was added to source_params to conifgure 
installing the kernel-image.
+# set skip_kernal_install in the kickstart file to skip installing 
it into hdddir.
+# if not set then the kernel-image will be installed.
+if not  source_params.get('skip_kernal_install'):
+install_cmd = "install -m 0644 %s/%s %s/%s" % \
+(staging_kernel_dir, kernel, hdddir, kernel)
+exec_cmd(install_cmd)
 
 if get_bitbake_var("IMAGE_EFI_BOOT_FILES"):
 for src_path, dst_path in cls.install_task:
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176517): 
https://lists.openembedded.org/g/openembedded-core/message/176517
Mute This Topic: https://lists.openembedded.org/mt/96650530/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 v2 2/2] oeqa/utils/httpserver: connect up the request logging

[Ross Burton]

Call logger.info() in the log_message handler so that we get request
logging, and hopefully even error messages.

Create a child logger to be neat and compartmentalise the logging.

Add a __main__ entrypoint so this class can be exercised outside of oeqa.

Remove unused traceback import.

Signed-off-by: Ross Burton 
---
 meta/lib/oeqa/utils/httpserver.py | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/meta/lib/oeqa/utils/httpserver.py 
b/meta/lib/oeqa/utils/httpserver.py
index 8ce1dd42f49..2aa172bf799 100644
--- a/meta/lib/oeqa/utils/httpserver.py
+++ b/meta/lib/oeqa/utils/httpserver.py
@@ -5,9 +5,9 @@
 #
 
 import http.server
+import logging
 import multiprocessing
 import os
-import traceback
 import signal
 from socketserver import ThreadingMixIn
 
@@ -15,20 +15,24 @@ class HTTPServer(ThreadingMixIn, http.server.HTTPServer):
 
 def server_start(self, root_dir, logger):
 os.chdir(root_dir)
+self.logger = logger
 self.serve_forever()
 
 class HTTPRequestHandler(http.server.SimpleHTTPRequestHandler):
 
 def log_message(self, format_str, *args):
-pass
+self.server.logger.info(format_str, *args)
 
-class HTTPService(object):
+class HTTPService:
 
 def __init__(self, root_dir, host='', port=0, logger=None):
 self.root_dir = root_dir
 self.host = host
 self.port = port
-self.logger = logger
+if logger:
+self.logger = logger.getChild("HTTPService")
+else:
+self.logger = logging.getLogger("HTTPService")
 
 def start(self):
 if not os.path.exists(self.root_dir):
@@ -49,7 +53,7 @@ class HTTPService(object):
 signal.signal(signal.SIGTERM, orig)
 
 if self.logger:
-self.logger.info("Started HTTPService on %s:%s" % (self.host, 
self.port))
+self.logger.info("Started HTTPService for %s on %s:%s" % 
(self.root_dir, self.host, self.port))
 
 
 def stop(self):
@@ -61,3 +65,10 @@ class HTTPService(object):
 if self.logger:
 self.logger.info("Stopped HTTPService on %s:%s" % (self.host, 
self.port))
 
+if __name__ == "__main__":
+import sys, logging
+
+logger = logging.getLogger(__name__)
+logging.basicConfig(level=logging.DEBUG)
+httpd = HTTPService(sys.argv[1], port=, logger=logger)
+httpd.start()
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176516): 
https://lists.openembedded.org/g/openembedded-core/message/176516
Mute This Topic: https://lists.openembedded.org/mt/96650349/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 v2 1/2] sdkext/cases/devtool: pass a logger to HTTPService

[Ross Burton]

Pass our logger to the HTTPService instance so we can see the requests
and any errors.

Signed-off-by: Ross Burton 
---
 meta/lib/oeqa/sdkext/cases/devtool.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/sdkext/cases/devtool.py 
b/meta/lib/oeqa/sdkext/cases/devtool.py
index a5c6a76e02d..5ffb732556b 100644
--- a/meta/lib/oeqa/sdkext/cases/devtool.py
+++ b/meta/lib/oeqa/sdkext/cases/devtool.py
@@ -112,7 +112,7 @@ class SdkUpdateTest(OESDKExtTestCase):
 cmd = 'oe-publish-sdk %s %s' % (tcname_new, self.publish_dir)
 subprocess.check_output(cmd, shell=True)
 
-self.http_service = HTTPService(self.publish_dir)
+self.http_service = HTTPService(self.publish_dir, logger=self.logger)
 self.http_service.start()
 
 self.http_url = "http://127.0.0.1:%d; % self.http_service.port
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176515): 
https://lists.openembedded.org/g/openembedded-core/message/176515
Mute This Topic: https://lists.openembedded.org/mt/96650348/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] oeqa/qemurunner: do not use Popen.poll() when terminating runqemu with a signal

[Alexander Kanavin]

On Tue, 31 Jan 2023 at 08:38, Mikko Rapeli  wrote:
> On Mon, Jan 30, 2023 at 11:11:25PM +0100, Alexander Kanavin wrote:
> > This does not actually guarantee that the child runqemu process has 
> > completely exited:
> > poll() may return prematurely while the SIGTERM handler in runqemu is still 
> > running.
> > This thwarts the rest of the processing, and may terminate the handler 
> > before
> > it completes.
> >
> > Use Popen.communicate() instead: this is what python documentation 
> > recommends as well:
> > https://docs.python.org/3/library/subprocess.html#subprocess.Popen.communicate
>
> Was I trying to solve the same problem in
> https://lists.openembedded.org/g/openembedded-core/message/176203 ?
>
> I think so.

No, this is different. Your patch treats qemu process itself, mine
fixes the problem with runqemu script. The whole qemurunner.py is a
mess, for example it sends SIGTERM to both qemu and runqemu, where one
or the other should be sufficient (runqemu will shutdown qemu if it is
itself terminating, and will terminate if it detects that qemu
finished). But I left that for another time. I only want a clean,
reliable shutdown of runqemu.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176514): 
https://lists.openembedded.org/g/openembedded-core/message/176514
Mute This Topic: https://lists.openembedded.org/mt/96639889/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 V3] apt: fix do_package_qa failure

[Changqing Li]

From: Changqing Li 

bitbake nativesdk-apt failed with error:
ERROR: nativesdk-apt-2.4.5-r0 do_package_qa: QA Issue: nativesdk-apt installs 
files in 
/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/var/volatile,
 but it is expected to be empty [empty-dirs]

an empty dir apt is installed under /var/log/, fix the failure
by removing the empty dir apt as what we have done for target.
apt will create it when it does not exist.

Signed-off-by: Changqing Li 
---
 meta/recipes-devtools/apt/apt_2.4.5.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/apt/apt_2.4.5.bb 
b/meta/recipes-devtools/apt/apt_2.4.5.bb
index 4ecbf98554..7af9792a0d 100644
--- a/meta/recipes-devtools/apt/apt_2.4.5.bb
+++ b/meta/recipes-devtools/apt/apt_2.4.5.bb
@@ -127,6 +127,7 @@ do_install:append:class-native() {
 
 do_install:append:class-nativesdk() {
customize_apt_conf_sample
+rm -rf ${D}${localstatedir}/log
 }
 
 do_install:append:class-target() {
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176513): 
https://lists.openembedded.org/g/openembedded-core/message/176513
Mute This Topic: https://lists.openembedded.org/mt/96649148/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] [qa-build-notification] QA notification for completed autobuilder build (yocto-4.2_M2.rc2)

[Jing Hui Tham]

Hi all,
 
Intel and WR YP QA is planning for QA execution for YP build yocto-4.2_M2.rc2. 
We are planning to execute following tests for this cycle:
 
OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw
 
Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. NUC 7
3. ADL
4. TGL NUC 11
5. Edgerouter
6. Beaglebone
 
ETA for completion Wednesday, 1st Feb.
 
Best regards,
Jing Hui


> -Original Message-
> From: qa-build-notificat...@lists.yoctoproject.org  notificat...@lists.yoctoproject.org> On Behalf Of Pokybuild User
> Sent: Friday, 27 January, 2023 1:13 PM
> To: yo...@lists.yoctoproject.org
> Cc: qa-build-notificat...@lists.yoctoproject.org
> Subject: [qa-build-notification] QA notification for completed autobuilder
> build (yocto-4.2_M2.rc2)
> 
> 
> A build flagged for QA (yocto-4.2_M2.rc2) was completed on the
> autobuilder and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-4.2_M2.rc2
> 
> 
> Build hash information:
> 
> bitbake: c19035e8e71c419c5688a86bfc9c946c96f638e8
> meta-agl: 09135164a21a216c6e3e75d7decce896b92962f0
> meta-arm: d8383c11f3f8220d2b989ec73604e5faff988299
> meta-aws: 7b4f54b3e1f675e2033f6a589ac519e44e62b58b
> meta-intel: b3c7d3ee44e4ab71df44b5be3c48d2f47d89d8a0
> meta-mingw: 250617ffa524c082b848487359b9d045703d59c2
> meta-openembedded: ceceffcb1e3ef4f9ba7708f77c27e30a7aea61e5
> meta-virtualization: 31954471605ae3b41627a0ab7b0dcfe8c5851bd7
> oecore: 493f2d163718d78560a2b3ad5d3c0fb34caae8c0
> poky: 5e249ec855517765f4b99e8039cb888ffa09c211
> 
> 
> 
> This is an automated message from the Yocto Project Autobuilder
> Git: git://git.yoctoproject.org/yocto-autobuilder2
> Email: richard.pur...@linuxfoundation.org
> 
> 
> 
> 
> 
> 
> 


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

[OE-core][dunfell][PATCH v2] go: fix CVE-2022-1962 go/parser stack exhaustion in all Parse* functions

[vkumbhar]

From: Vivek Kumbhar 

Signed-off-by: Vivek Kumbhar 
---
 meta/recipes-devtools/go/go-1.14.inc  |   1 +
 .../go/go-1.14/CVE-2022-1962.patch| 357 ++
 2 files changed, 358 insertions(+)
 create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2022-1962.patch

diff --git a/meta/recipes-devtools/go/go-1.14.inc 
b/meta/recipes-devtools/go/go-1.14.inc
index 1d97001654..be9abb5b2d 100644
--- a/meta/recipes-devtools/go/go-1.14.inc
+++ b/meta/recipes-devtools/go/go-1.14.inc
@@ -51,6 +51,7 @@ SRC_URI += "\
 file://CVE-2022-28327.patch \
 file://CVE-2022-41715.patch \
 file://CVE-2022-41717.patch \
+file://CVE-2022-1962.patch \
 "
 
 SRC_URI_append_libc-musl = " 
file://0009-ld-replace-glibc-dynamic-linker-with-musl.patch"
diff --git a/meta/recipes-devtools/go/go-1.14/CVE-2022-1962.patch 
b/meta/recipes-devtools/go/go-1.14/CVE-2022-1962.patch
new file mode 100644
index 00..b2ab5d0669
--- /dev/null
+++ b/meta/recipes-devtools/go/go-1.14/CVE-2022-1962.patch
@@ -0,0 +1,357 @@
+From ba8788ebcead55e99e631c6a1157ad7b35535d11 Mon Sep 17 00:00:00 2001
+From: Roland Shoemaker 
+Date: Wed, 15 Jun 2022 10:43:05 -0700
+Subject: [PATCH] [release-branch.go1.17] go/parser: limit recursion depth
+
+Limit nested parsing to 100,000, which prevents stack exhaustion when
+parsing deeply nested statements, types, and expressions. Also limit
+the scope depth to 1,000 during object resolution.
+
+Thanks to Juho Nurminen of Mattermost for reporting this issue.
+
+Fixes #53707
+Updates #53616
+Fixes CVE-2022-1962
+
+Change-Id: I4d7b86c1d75d0bf3c7af1fdea91582aa74272c64
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/1491025
+Reviewed-by: Russ Cox 
+Reviewed-by: Damien Neil 
+(cherry picked from commit 6a856f08d58e4b6705c0c337d461c540c1235c83)
+Reviewed-on: https://go-review.googlesource.com/c/go/+/417070
+Reviewed-by: Heschi Kreinick 
+TryBot-Result: Gopher Robot 
+Run-TryBot: Michael Knyszek 
+
+Upstream-Status: Backport 
[https://github.com/golang/go/commit/ba8788ebcead55e99e631c6a1157ad7b35535d11]
+CVE: CVE-2022-1962
+Signed-off-by: Vivek Kumbhar 
+---
+ src/go/parser/interface.go   |  10 ++-
+ src/go/parser/parser.go  |  48 --
+ src/go/parser/parser_test.go | 169 +++
+ 3 files changed, 220 insertions(+), 7 deletions(-)
+
+diff --git a/src/go/parser/interface.go b/src/go/parser/interface.go
+index 54f9d7b..537b327 100644
+--- a/src/go/parser/interface.go
 b/src/go/parser/interface.go
+@@ -92,8 +92,11 @@ func ParseFile(fset *token.FileSet, filename string, src 
interface{}, mode Mode)
+   defer func() {
+   if e := recover(); e != nil {
+   // resume same panic if it's not a bailout
+-  if _, ok := e.(bailout); !ok {
++  bail, ok := e.(bailout)
++  if !ok {
+   panic(e)
++  } else if bail.msg != "" {
++  p.errors.Add(p.file.Position(bail.pos), 
bail.msg)
+   }
+   }
+ 
+@@ -188,8 +191,11 @@ func ParseExprFrom(fset *token.FileSet, filename string, 
src interface{}, mode M
+   defer func() {
+   if e := recover(); e != nil {
+   // resume same panic if it's not a bailout
+-  if _, ok := e.(bailout); !ok {
++  bail, ok := e.(bailout)
++  if !ok {
+   panic(e)
++  } else if bail.msg != "" {
++  p.errors.Add(p.file.Position(bail.pos), 
bail.msg)
+   }
+   }
+   p.errors.Sort()
+diff --git a/src/go/parser/parser.go b/src/go/parser/parser.go
+index 31a7398..586fe90 100644
+--- a/src/go/parser/parser.go
 b/src/go/parser/parser.go
+@@ -64,6 +64,10 @@ type parser struct {
+   unresolved []*ast.Ident  // unresolved identifiers
+   imports[]*ast.ImportSpec // list of imports
+ 
++  // nestLev is used to track and limit the recursion depth
++  // during parsing.
++  nestLev int
++  
+   // Label scopes
+   // (maintained by open/close LabelScope)
+   labelScope  *ast.Scope // label scope for current function
+@@ -236,6 +240,24 @@ func un(p *parser) {
+   p.printTrace(")")
+ }
+ 
++// maxNestLev is the deepest we're willing to recurse during parsing
++const maxNestLev int = 1e5
++
++func incNestLev(p *parser) *parser {
++  p.nestLev++
++  if p.nestLev > maxNestLev {
++  p.error(p.pos, "exceeded max nesting depth")
++  panic(bailout{})
++  }
++  return p
++}
++
++// decNestLev is used to track nesting depth during parsing to prevent stack 
exhaustion.
++// It is used along with incNestLev in a similar fashion to how un and trace 
are used.
++func decNestLev(p *parser) {
++  p.nestLev--
++}
++
+ // Advance to 

Re: [OE-core][kirkstone][PATCH] xorg-x11-server: fix multiple xorg-x11-server bugs.

[vkumbhar]

Thanks for the information. Okay, will modify the patch accordingly.

-Thanks,
Vivek

On Mon, Jan 30, 2023 at 11:17 PM Steve Sakoman  wrote:

> On Wed, Jan 25, 2023 at 1:55 AM vkumbhar  wrote:
> >
> > From: Vivek Kumbhar 
> >
> > Fixed Below CVE:
> > CVE-2022-4283
> > CVE-2022-46340
> > CVE-2022-46341
> > CVE-2022-46342
> > CVE-2022-46343
> > CVE-2022-46344
> >
> > Signed-off-by: Vivek Kumbhar 
> > ---
> >  .../xserver-xorg/CVE-2022-4283.patch  | 39 +
> >  .../xserver-xorg/CVE-2022-46340.patch | 55 
> >  .../xserver-xorg/CVE-2022-46341.patch | 86 +++
> >  .../xserver-xorg/CVE-2022-46342.patch | 78 +
> >  .../xserver-xorg/CVE-2022-46343.patch | 51 +++
> >  .../xserver-xorg/CVE-2022-46344.patch | 75 
> >  .../xorg-xserver/xserver-xorg_21.1.4.bb   |  6 ++
>
> We've done a version bump to 21.1.6 in kirkstone, so you'll need to
> rework this patch (if it is still necessary)
>
> Thanks!
>
> Steve
>
> >  7 files changed, 390 insertions(+)
> >  create mode 100644
> meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2022-4283.patch
> >  create mode 100644
> meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2022-46340.patch
> >  create mode 100644
> meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2022-46341.patch
> >  create mode 100644
> meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2022-46342.patch
> >  create mode 100644
> meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2022-46343.patch
> >  create mode 100644
> meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2022-46344.patch
> >
> > diff --git
> a/meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2022-4283.patch
> b/meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2022-4283.patch
> > new file mode 100644
> > index 00..ce642843ab
> > --- /dev/null
> > +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2022-4283.patch
> > @@ -0,0 +1,39 @@
> > +From ccdd431cd8f1cabae9d744f0514b6533c438908c Mon Sep 17 00:00:00 2001
> > +From: Peter Hutterer 
> > +Date: Mon, 5 Dec 2022 15:55:54 +1000
> > +Subject: [PATCH] xkb: reset the radio_groups pointer to NULL after
> freeing it
> > +
> > +Unlike other elements of the keymap, this pointer was freed but not
> > +reset. On a subsequent XkbGetKbdByName request, the server may access
> > +already freed memory.
> > +
> > +CVE-2022-4283, ZDI-CAN-19530
> > +
> > +This vulnerability was discovered by:
> > +Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
> > +
> > +Signed-off-by: Peter Hutterer 
> > +Acked-by: Olivier Fourdan 
> > +
> > +Upstream-Status: Backport [
> https://gitlab.freedesktop.org/xorg/xserver/-/commit/ccdd431cd8f1cabae9d744f0514b6533c438908c
> ]
> > +CVE: CVE-2022-4283
> > +Signed-off-by: Vivek Kumbhar 
> > +---
> > + xkb/xkbUtils.c | 1 +
> > + 1 file changed, 1 insertion(+)
> > +
> > +diff --git a/xkb/xkbUtils.c b/xkb/xkbUtils.c
> > +index dd089c204..3f5791a18 100644
> > +--- a/xkb/xkbUtils.c
> >  b/xkb/xkbUtils.c
> > +@@ -1326,6 +1326,7 @@ _XkbCopyNames(XkbDescPtr src, XkbDescPtr dst)
> > + }
> > + else {
> > + free(dst->names->radio_groups);
> > ++dst->names->radio_groups = NULL;
> > + }
> > + dst->names->num_rg = src->names->num_rg;
> > +
> > +--
> > +2.30.2
> > +
> > diff --git
> a/meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2022-46340.patch
> b/meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2022-46340.patch
> > new file mode 100644
> > index 00..9bdcdfa76e
> > --- /dev/null
> > +++
> b/meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2022-46340.patch
> > @@ -0,0 +1,55 @@
> > +From b320ca0ffe4c0c872eeb3a93d9bde21f765c7c63 Mon Sep 17 00:00:00 2001
> > +From: Peter Hutterer 
> > +Date: Tue, 29 Nov 2022 12:55:45 +1000
> > +Subject: [PATCH] Xtest: disallow GenericEvents in XTestSwapFakeInput
> > +
> > +XTestSwapFakeInput assumes all events in this request are
> > +sizeof(xEvent) and iterates through these in 32-byte increments.
> > +However, a GenericEvent may be of arbitrary length longer than 32 bytes,
> > +so any GenericEvent in this list would result in subsequent events to be
> > +misparsed.
> > +
> > +Additional, the swapped event is written into a stack-allocated struct
> > +xEvent (size 32 bytes). For any GenericEvent longer than 32 bytes,
> > +swapping the event may thus smash the stack like an avocado on toast.
> > +
> > +Catch this case early and return BadValue for any GenericEvent.
> > +Which is what would happen in unswapped setups anyway since XTest
> > +doesn't support GenericEvent.
> > +
> > +CVE-2022-46340, ZDI-CAN 19265
> > +
> > +This vulnerability was discovered by:
> > +Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
> > +
> > +Signed-off-by: Peter Hutterer 
> > +Acked-by: Olivier Fourdan 
> > +
> > +Upstream-Status: Backport [
> https://gitlab.freedesktop.org/xorg/xserver/-/commit/b320ca0ffe4c0c872eeb3a93d9bde21f765c7c63

[OE-core] [PATCH] glslang: branch rename master -> main

[Yu, Mingli]

From: Mingli Yu 

Branch name is changed from master to main.

Signed-off-by: Mingli Yu 
---
 meta/recipes-graphics/glslang/glslang_1.3.236.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/glslang/glslang_1.3.236.0.bb 
b/meta/recipes-graphics/glslang/glslang_1.3.236.0.bb
index 99eca6a6c1..22838dfc8c 100644
--- a/meta/recipes-graphics/glslang/glslang_1.3.236.0.bb
+++ b/meta/recipes-graphics/glslang/glslang_1.3.236.0.bb
@@ -9,7 +9,7 @@ LICENSE = "BSD-3-Clause & BSD-2-Clause & MIT & Apache-2.0 & 
GPL-3-with-bison-exc
 LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=2a2b5acd7bc4844964cfda45fe807dc3"
 
 SRCREV = "77551c429f86c0e077f26552b7c1c0f12a9f235e"
-SRC_URI = 
"git://github.com/KhronosGroup/glslang.git;protocol=https;branch=master \
+SRC_URI = 
"git://github.com/KhronosGroup/glslang.git;protocol=https;branch=main \
file://0001-generate-glslang-pkg-config.patch"
 PE = "1"
 UPSTREAM_CHECK_GITTAGREGEX = "sdk-(?P\d+(\.\d+)+)"
-- 
2.25.1


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