chromium: update to 111.0.5563.147

nrpt-m commented 1 year ago

Release notes: https://chromereleases.googleblog.com/2023/03/stable-channel-update-for-desktop_27.html

Summary:

The upgrade builds successfully for all the branches. For dunfell, all systems work well except rpi4, see below. For master, all systems work well except qemuarm & qemuarm64, see below.

Build and patch changes:

No changes required.

License changes:

No license changes.

Test-built:

chromium-ozone-wayland:
- master, clang, MACHINE=qemux86-64, qemuarm64
- kirkstone, clang, MACHINE=qemux86-64, qemuarm64
chromium-x11
- master, clang, MACHINE=raspberrypi4-64, qemux86-64, qemuarm64, qemuarm
- kirkstone, clang, MACHINE=raspberrypi4-64, qemux86-64, qemuarm64, qemuarm
- dunfell, clang**, MACHINE=raspberrypi3, qemux86-64, qemuarm64, qemuarm

** Please note that Chromium requires clang version to be >= 12. For that, when on dunfell branch, use the latest meta-clang/dunfell-clang12 branch.

Runtime Test Status:

For dunfell, we see the following error: Network service crashed, restarting service.

For master, which is using the 6.1.20 kernel, we see the following errors: qemuarm: vmap allocation for size 4100096 failed: use vmalloc= to increase size

qemuarm64: system appears to boot well but, user-interface is not responding.

nrpt-m commented 1 year ago

For dunfell, we don't have any plan to work on the error. For master qemuarm*, we assume it's related to kernel 6.1.20 update so, we will report this as a bug in yocto bugzilla project.

Given that the dunfell issue is not a new regression and the master issue is likely related to the kernel update, a merge seems sensible. Note that qemux86-64 and rpi4 both work well on master.

rwmacleod commented 1 year ago

For dunfell, we don't have any plan to work on the error.

Agreed. We've seen this issue before and haven't been able to resolve it. Perhaps the chromium-112 update will help; we'll see later this week.

For master qemuarm*, we assume it's related to kernel 6.1.20 update so, we will report this as a bug in yocto bugzilla project.

For qemuarm, this is caused by asking runqemu to use more memory than the qemuarm BSP can handle. The kernel error goes away for core-image-sato and: $ runqemu qemuarm serialstdio publicvnc qemuparams="-m 512"

but there's still a problem with the sato interface being frozen just as it is for qemuarm64. I'm bisecting poky/master to see if I can identify when the regression started.

Given that the dunfell issue is not a new regression and the master issue is likely related to the kernel update, a merge seems sensible. Note that qemux86-64 and rpi4 both work well on master.

I agree that it's reasonable to merge this update given that is resolves https://nvd.nist.gov/vuln/detail/CVE-2023-1529 and as far as we know, works just as well as the old version of 111.0.5563.64 across all stable branches that we support.

rwmacleod commented 1 year ago

@rakuco @MaxIhlenfeldt Any comments.

MaxIhlenfeldt commented 1 year ago

LGTM!

rakuco commented 1 year ago

LGTM too, thanks!

Can you file a new issue for the network service crash on dunfell? I don't recall seeing reports of that one before.

OSSystems / meta-browser