Update to chromium 115

[rwmacleod]

https://chromereleases.googleblog.com/2023/07/stable-channel-update-for-desktop.html?m=1

@nrpt-m @MaxIhlenfeldt the usual approach?

[MaxIhlenfeldt]

Yes! Sorry, I was ooo at the end of last week, but I'll start working on the update today.

[MaxIhlenfeldt]

I think https://crrev.com/c/4517702 bumped Chromium's required Linux kernel version to 5.10 on arm64 - according to https://github.com/torvalds/linux/commit/3b714d24ef173f81c78af16f73dcc9b40428c803, HWCAP2_MTE was introduced in 5.10.

This is problematic because dunfell still uses Linux 5.4:

| ../../base/allocator/partition_allocator/tagging.cc:195:52: error: use of undeclared identifier 'HWCAP2_MTE'
|   if ((hwcap & _IFUNC_ARG_HWCAP) && (hw->_hwcap2 & HWCAP2_MTE)) {
|                                                    ^
| ../../base/allocator/partition_allocator/tagging.cc:203:52: error: use of undeclared identifier 'HWCAP2_MTE'
|   if ((hwcap & _IFUNC_ARG_HWCAP) && (hw->_hwcap2 & HWCAP2_MTE)) {
|                                                    ^
| ../../base/allocator/partition_allocator/tagging.cc:211:52: error: use of undeclared identifier 'HWCAP2_MTE'
|   if ((hwcap & _IFUNC_ARG_HWCAP) && (hw->_hwcap2 & HWCAP2_MTE)) {
|                                                    ^

I suspect reverting that CL will fix this one issue, but we might run into similar ones in the future.

[rakuco]

How about backporting https://chromium-review.googlesource.com/c/chromium/src/+/4610745?

[MaxIhlenfeldt]

Ah, good find, thanks!

[MaxIhlenfeldt]

As I mentioned in #716, there are new build errors that most likely wouldn't be there with clang 16. I'm wondering what a reasonable time estimate for fixing #716 (at least for kirkstone and mickledore) would be? (@kraj)

I have to admit that I'm not too keen on fixing these errors one by one if there's an alternative (that we'll have to implement in the near future in any case) that would fix them all in one go. What makes this decision even more difficult is that I don't know yet how many other build errors there are with clang < 16 in m115. It might be just one more, it might be ten - in the former case, it'd be no problem to patch the errors for m115 and target m116 to be the version we compile with clang 16; in the latter case, I'm not sure updating to m115 without updating clang at the same time is sensible.

[rakuco]

@MaxIhlenfeldt @kraj @rwmacleod A few days ago I pushed a dunfell-clang14 branch to my meta-clang fork with lots of cherry-picks from meta-clang's kirkstone branch. I'm not sure if this is the best approach and I've probably cherry-picked too many things.

I've built:

• chromium-ozone-wayland with MACHINE = "qemuarm64", TOOLCHAIN ?= "clang" and RUNTIME = "llvm". The latter did require some extra cherry-picks, and I did give up on some recipes and also passed TOOLCHAIN:pn-gnutls = "gcc" and TOOLCHAIN:pn-pulseaudio = "gcc".
• chromium-x11 with MACHINE = "qemux86-64". I've also run core-image-sato on QEMU and Chromium did run fine and show some websites.

I did this on a Fedora 37 installation that normally failed to build with dunfell and clang 12 due to #726.

If you have some spare cycles, do let me know if my tree works in your builds so we can see what to do with it.

[rwmacleod]

@nrpt-m please give this a spin for @rakuco

[nrpt-m]

If you have some spare cycles, do let me know if my tree works in your builds so we can see what to do with it.

@rakuco I have built and tested chromium-x11 with machine qemux86-64 for dunfell branch in below set-up. Chromium works fine without any issue. I have used meta-clang/dunfell-clang14 (https://github.com/rakuco/meta-clang/tree/dunfell-clang14) from your tree.

meta-xfce = "dunfell:b8b0b06821d4d4df0cce4f07fa31a8ca1dd38f46" meta-clang.git = "dunfell-clang14:0dc3caf541b8ea6d210220459974a7796ef9e722" meta-raspberrypi.git = "dunfell:2081e1bb9a44025db7297bfd5d024977d42191ed" meta-chromium = "master:1c6f9e97a58685799dfe412a3f437a27bd1fd2d6"

$cat conf/local.conf | tail -2 IMAGE_INSTALL:append = " chromium-x11" PREFERRED_VERSION_nodejs-native = "14.%"

Please correct me if this above set-up is the one, which you were testing and let me know if you want me to build for other machines (qemuarm64, qemauarm & rpi4) as well.

[rakuco]

The setup above looks correct, thank you for testing. Did you only build the recipe or was it runtime-tested as well?

It'd also be great if you could test qemuarm, as we've only tested 64-bit architectures so far.

[nrpt-m]

The setup above looks correct, thank you for testing. Did you only build the recipe or was it runtime-tested as well?

Yes, I have built core-image-sato and tested runtime as well.

It'd also be great if you could test qemuarm, as we've only tested 64-bit architectures so far.

Sure, will build and test qemuarm machine as well.

[nrpt-m]

It'd also be great if you could test qemuarm, as we've only tested 64-bit architectures so far.

Sure, will build and test qemuarm machine as well.

Have built and tested qemuarm machine as well and chromium works fine without any issue.

[rakuco]

Thank you!

@kraj how would you like to proceed? One option would be for you to create a new dunfell-clang14 branch identical to dunfell-clang12 and then I send a pull request with all the changes for review.

[MaxIhlenfeldt]

I did this on a Fedora 37 installation that normally failed to build with dunfell and clang 12 due to #726.

I can confirm this also fixes #726 on my machines. Thanks a lot, great work!

Regarding the m115 update, how do we want to proceed? Is it feasible to wait for clang16 for dunfell, kirkstone, and mickledore? Or should I see how far I can get with clang 14/15 (not a fan of that, but I'd be open to it anyway if you think it's sensible)?

[rakuco]

Regarding the m115 update, how do we want to proceed? Is it feasible to wait for clang16 for dunfell, kirkstone, and mickledore? Or should I see how far I can get with clang 14/15 (not a fan of that, but I'd be open to it anyway if you think it's sensible)?

At this point I think seeing how far a build with clang 14 goes (be it on dunfell or kirkstone) is the safest option. I don't know if the way I've approached the dunfell-clang14 branch works, and moving to clang 16 would require first landing those changes, then moving both dunfell and kirkstone to clang 16. I could help with that, but probably wouldn't have time to do it myself.

[MaxIhlenfeldt]

At this point I think seeing how far a build with clang 14 goes (be it on dunfell or kirkstone) is the safest option.

Makes sense. I'll see how far I can get and will update here!

[rakuco]

@kraj how would you like to proceed? One option would be for you to create a new dunfell-clang14 branch identical to dunfell-clang12 and then I send a pull request with all the changes for review.

I've filed kraj/meta-clang#835 to see how to move forward with clang 14 on dunfell.

[MaxIhlenfeldt]

I'm currently at three added downstream patches, one of which I'm pretty sure can be upstreamed, and mickledore builds successfully :tada: the kirkstone build is still running, dunfell will follow after that. If both builds succeed as well, I'll upload the PR tomorrow.