meta-browser
meta-browser copied to clipboard
OSSystems
Update to Chromium 123
Release notes:
- https://chromereleases.googleblog.com/2024/03/stable-channel-update-for-desktop_19.html
error[E0599]: no method named `as_encoded_bytes` found for reference `&OsStr` in the current scope
--> ../../third_party/rust/chromium_crates_io/vendor/clap_lex-0.7.0/src/ext.rs:186:26
|
186 | let bytes = self.as_encoded_bytes();
| ^^^^^^^^^^^^^^^^ method not found in `&OsStr`
std::ffi::OsStr::as_encoded_bytes() was stabilized in Rust 1.74, which was released on 16 Nov 2023. It seems Chromium is quite aggressive with requiring a recent version of the Rust compiler... Nanbield for example has only 1.70, and Scarthgap has 1.75.
I've asked on the Chromium Slack if there's any MSRV (minimum supported Rust version) policy for Chromium, as requiring such a recent Rust toolchain is (in my opinion) asking for quite much of external maintainers. But if upstream doesn't see a problem with this, we'll either have to start fixing build errors because of old compilers again (like we had to do for clang 12/14/15) or aggressively drop support for non-LTS Yocto releases with too old Rust versions and ensure that meta-lts-mixins always has a recent enough version of Rust for all LTS releases. I would really like to avoid the former.
@rakuco wdyt?
This was the response from danakj@ on Slack:
we don't [have a MSRV policy] we use nightly basically just like we use clang nightly, and they need to follow each other that said we kinda have a weird MSClangV for cronet right now but it's a big source of pain for us. Since we build with latest Rust it would be a pain for rust too because we'd have to run some extra bots on older Rust and it would not be in folks' workflows and cause reverts So, I would argue to avoid a MSRV for Chromium since our CI will track TOT (and dev environments)
Another option would be to switch to meta-rust-bin, which -- at least currently -- has recipes for recent Rust versions for all the Yocto releases we support.