www-client/chromium: sync with upstream

This commit is contained in:
github-actions[bot] 2025-01-21 00:03:11 +00:00 committed by GitHub
parent a0cfb31b04
commit e43f589f1f
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
3 changed files with 0 additions and 182 deletions

View file

@ -1,45 +0,0 @@
From b6cda4bc2283a02a5b5209c0f4282a8365f6f33e Mon Sep 17 00:00:00 2001
From: Matt Jolly <Matt.Jolly@footclan.ninja>
Date: Tue, 21 May 2024 10:04:24 +1000
Subject: [PATCH] www-client/chromium: work around dead oauth2 credentials -
126 update
126 changed the function proto; patch rebased.
Google doesn't let us bake in OAuth2 credentials, and for some time,
Google sign-in has been broken. Arch dealt with this in March, and so
did we to some degree, but in the last few months, our sign-in
credentials have been broken. It appears that we actually did remove API
credentials in March around Chrome 89, but they got added back, perhaps
when rotating newer versions to replace older versions. Work around this
by following Arch's lead: we remove the predefined credentials, as
before, but also we patch Chromium so that people can use their own
easily, using Arch's patch for that.
For more info, see:
https://archlinux.org/news/chromium-losing-sync-support-in-early-march/
https://bodhi.fedoraproject.org/updates/FEDORA-2021-48866282e5
https://hackaday.com/2021/01/26/whats-the-deal-with-chromium-on-linux-google-at-odds-with-package-maintainers/
Bug: https://bugs.gentoo.org/791871
Signed-off-by: Matt Jolly <kangie@gentoo.org>
--- a/google_apis/google_api_keys-inc.cc
+++ b/google_apis/google_api_keys-inc.cc
@@ -193,11 +193,11 @@ class APIKeyCache {
std::string default_client_id = CalculateKeyValue(
GOOGLE_DEFAULT_CLIENT_ID,
STRINGIZE_NO_EXPANSION(GOOGLE_DEFAULT_CLIENT_ID), std::string(),
- nullptr, std::string(), environment.get(), command_line, gaia_config);
+ ::switches::kOAuth2ClientID, std::string(), environment.get(), command_line, gaia_config);
std::string default_client_secret = CalculateKeyValue(
GOOGLE_DEFAULT_CLIENT_SECRET,
STRINGIZE_NO_EXPANSION(GOOGLE_DEFAULT_CLIENT_SECRET), std::string(),
- nullptr, std::string(), environment.get(), command_line, gaia_config);
+ ::switches::kOAuth2ClientSecret, std::string(), environment.get(), command_line, gaia_config);
// We currently only allow overriding the baked-in values for the
// default OAuth2 client ID and secret using a command-line
--
2.45.1

View file

@ -1,102 +0,0 @@
From 6df5a080f58ddb6a49a9d33e4a3619a34fffa78c Mon Sep 17 00:00:00 2001
From: Matt Jolly <Matt.Jolly@footclan.ninja>
Date: Fri, 5 Jul 2024 20:49:01 +1000
Subject: [PATCH] Make bindgen wrapper work with unbundled toolchain
The `run_bindgen.py` wrapper takes a --libclang-path option
and uses it to set the appropriate environment variable.
This is currently hardcoded to use libclang shipped alongside
bindgen (in our rust toolchain), but distributions may want to
override this and use a system path.
Additionally enable distros to feed in appropriate library paths.
--- a/build/config/rust.gni
+++ b/build/config/rust.gni
@@ -60,6 +60,17 @@ declare_args() {
# the bindgen exectuable).
rust_bindgen_root = "//third_party/rust-toolchain"
+ # Directory under which to find one of `libclang.{dll,so}` (a `lib[64]` or
+ # `bin` directory containing the libclang shared library).
+ # We don't need to worry about multlib, but specify the full path here
+ # in case a distribution does.
+ if (host_os == "win") {
+ bindgen_libclang_path = "//third_party/rust-toolchain/bin"
+ } else {
+ bindgen_libclang_path = "//third_party/rust-toolchain/lib"
+ }
+
+
# If you're using a Rust toolchain as specified by rust_sysroot_absolute,
# set this to the output of `rustc -V`. Changing this string will cause all
# Rust targets to be rebuilt, which allows you to update your toolchain and
--- a/build/rust/rust_bindgen.gni
+++ b/build/rust/rust_bindgen.gni
@@ -16,13 +16,13 @@ if (host_os == "win") {
_bindgen_path = "${_bindgen_path}.exe"
}
-# On Windows, the libclang.dll is beside the bindgen.exe, otherwise it is in
-# ../lib.
-_libclang_path = rust_bindgen_root
-if (host_os == "win") {
- _libclang_path += "/bin"
+if (clang_base_path != default_clang_base_path && custom_toolchain == "//build/toolchain/linux/unbundle:default") {
+ # Assume that the user has set this up properly, including handling multilib
+ _clang_libpath = clang_base_path + "/include"
+ _clang_ld_libpath = bindgen_libclang_path
} else {
- _libclang_path += "/lib"
+ _clang_libpath = clang_base_path + "/lib/clang/" + clang_version
+ _clang_ld_libpath = clang_base_path + "/lib"
}
# Template to build Rust/C bindings with bindgen.
@@ -100,7 +100,7 @@ template("rust_bindgen") {
"--output",
rebase_path(out_gen_rs, root_build_dir),
"--libclang-path",
- rebase_path(_libclang_path, root_build_dir),
+ rebase_path(bindgen_libclang_path, root_build_dir),
]
if (wrap_static_fns) {
@@ -117,7 +117,7 @@ template("rust_bindgen") {
# point to.
args += [
"--ld-library-path",
- rebase_path(clang_base_path + "/lib", root_build_dir),
+ rebase_path(_clang_ld_libpath, root_build_dir),
]
}
@@ -145,8 +145,7 @@ template("rust_bindgen") {
# make it behave consistently with our other command line flags and allows
# system headers to be found.
clang_resource_dir =
- rebase_path(clang_base_path + "/lib/clang/" + clang_version,
- root_build_dir)
+ rebase_path(_clang_libpath, root_build_dir)
args += [
"-resource-dir",
clang_resource_dir,
@@ -167,6 +166,15 @@ template("rust_bindgen") {
}
}
+ if (custom_toolchain == "//build/toolchain/linux/unbundle:default") {
+ # We need to pass the path to the libstdc++ headers to bindgen so that it
+ # can find them when parsing C++ headers.
+ args += [
+ "-I",
+ rebase_path(clang_base_path + "/include/", root_build_dir),
+ ]
+ }
+
if (is_win) {
# On Windows we fall back to using system headers from a sysroot from
# depot_tools. This is negotiated by python scripts and the result is
--
2.45.2

View file

@ -1,35 +0,0 @@
From 403ee5b14df12c8ee3b3583177bbd30d930e9aaf Mon Sep 17 00:00:00 2001
From: Matt Jolly <kangie@gentoo.org>
Date: Sat, 12 Oct 2024 13:45:37 +1000
Subject: [PATCH] Convert 'Const AtomicString' to 'const char *'.
I don't know why this is suddenly required?
--- a/third_party/blink/renderer/platform/wtf/text/text_codec_icu.cc
+++ b/third_party/blink/renderer/platform/wtf/text/text_codec_icu.cc
@@ -323,7 +323,10 @@ void TextCodecICU::CreateICUConverter() const {
DCHECK(!converter_icu_);
#if defined(USING_SYSTEM_ICU)
- const char* name = encoding_.GetName();
+ //convert to WTF::String to use existing `const char *` dependent functions
+ WTF::String nameString = encoding_.GetName();
+ std::string nameUtf8 = nameString.Utf8();
+ const char* name = nameUtf8.c_str();
needs_gbk_fallbacks_ =
name[0] == 'G' && name[1] == 'B' && name[2] == 'K' && !name[3];
#endif
@@ -448,7 +451,10 @@ String TextCodecICU::Decode(base::span<const uint8_t> data,
// <http://bugs.webkit.org/show_bug.cgi?id=17014>
// Simplified Chinese pages use the code A3A0 to mean "full-width space", but
// ICU decodes it as U+E5E5.
- if (!strcmp(encoding_.GetName(), "GBK")) {
+ // Convert AtomicString to String
+ WTF::String nameString = encoding_.GetName();
+ std::string nameUtf8 = nameString.Utf8();
+ if (!strcmp(nameUtf8.c_str(), "GBK")) {
if (EqualIgnoringASCIICase(encoding_.GetName(), "gb18030"))
resultString.Replace(0xE5E5, kIdeographicSpaceCharacter);
// Make GBK compliant to the encoding spec and align with GB18030
--
2.46.2