Debian Patches

Status for chromium/150.0.7871.100-1

Patch Description Author Forwarded Bugs Origin Last update
ppc64le/libaom/0001-Add-pregenerated-config-for-libaom-on-ppc64.patch =================================================================== no
ppc64le/third_party/0002-third_party-libvpx-Remove-bad-ppc64-config.patch =================================================================== no
ppc64le/third_party/0003-third_party-libvpx-Add-ppc64-generated-config.patch commit 50e76d04c69447701ea1bcea8e77b72d0b8b4489

woinewf

===================================================================		 Timothy Pearson <tpearson@raptorengineering.com> no 2026-06-04
ppc64le/third_party/0003-third_party-ffmpeg-Add-ppc64-generated-config.patch =================================================================== no
ppc64le/third_party/0004-third_party-libvpx-work-around-ambiguous-vsx.patch =================================================================== no
ppc64le/third_party/0001-add-xnn-ppc64el-support.patch =================================================================== no
loongarch64/0006-loong64-sandbox-sandbox-linux-system_headers-Update-.patch loong64: sandbox: sandbox/linux/system_headers: Update linux signal header for loongarch64 Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-05-30
loongarch64/0007-loong64-sandbox-sandbox-linux-seccomp-bpf-Add-loonga.patch loong64: sandbox: sandbox/linux/seccomp-bpf: Add loongarch64 syscall stub Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-05-30
loongarch64/0008-loong64-sandbox-sandbox-linux-services-credentials.c.patch loong64: sandbox: sandbox/linux/services/credentials.cc: Add loongarch64 support Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-05-30
loongarch64/0009-loong64-sandbox-sandbox-linux-bpf_dsl-Modify-seccomp.patch loong64: sandbox: sandbox/linux/bpf_dsl: Modify seccomp_macros to add support for loongarch64 Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-05-30
loongarch64/0010-loong64-sandbox-seccomp-bpf-helpers-fix-build-for-lo.patch loong64: sandbox: seccomp-bpf-helpers: fix build for loongarch64 Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-05-30
loongarch64/0011-sandbox-linux-system_headers-Update-linux-seccomp-he.patch sandbox/linux/system_headers: Update linux seccomp header for loongarch64 Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-05-30
loongarch64/0012-sandbox-linux-add-statx-support-for-loongarch64.patch sandbox/linux: add statx support for loongarch64 Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-05-30
loongarch64/0013-swiftshader-support-for-loongarch.patch swiftshader support for loongarch Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-04-03
loongarch64/0014-crashpad-support-for-loongarch.patch crashpad support for loongarch Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-04-03
loongarch64/0015-ffmpeg-support-for-loongarch.patch ffmpeg support for loongarch Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-04-03
loongarch64/0016-medium-cmodel-support-for-loongarch64.patch medium cmodel support for loongarch64 Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-04-03
loongarch64/0017-sys_info-add-loongarch64-architecture-string.patch sys_info: add loongarch64 architecture string Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-05-15
loongarch64/0018-fix-study-crash.patch fix study crash Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-05-15
loongarch64/0019-boringssl-add-loongarch-support.patch boringssl: add loongarch support Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-05-15
loongarch64/0020-user_agent-add-loongarch-architecture-support.patch user_agent: add loongarch architecture support Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-05-15
loongarch64/0021-components-metrics-add-loongarch64-support.patch components/metrics: add loongarch64 support Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-05-15
loongarch64/0022-blink-fix-lsx-code-of-webgl_image_conversion_lsx.patch blink: fix lsx code of webgl_image_conversion_lsx Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-05-15
loongarch64/0023-loongarch64-enable-lsx-by-default.patch loongarch64: enable lsx by default Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-05-15
system/rapidjson.patch build against debian's rapidjson-dev package
Due to some questionable licensing (the JSON "do not use this for evil"
license), debian deletes all of third_party/angle/third_party/rapidjson/src
even though a small portion of it falls under that license. The library is
tiny and doesn't change much, so this lets chromium build against the
system's rapidjson-dev header files.		 Andres Salomon <dilinger@debian.org> no
system/rollup.patch include debian node libs (needed for rollup)
This is strictly just needed for bullseye's rollup , but may be useful
later on when we drop more nodejs stuff.		 Andres Salomon <dilinger@debian.org> no
ppc64le/workarounds/HACK-debian-clang-disable-pa-musttail.patch =================================================================== no
ppc64le/libaom/0001-Add-ppc64-target-to-libaom.patch Add ppc64 target to libaom Shawn Anastasio <shawnanastasio@gmail.com> no 2019-03-10
ppc64le/third_party/0002-Add-PPC64-generated-files-for-boringssl.patch =================================================================== no
ppc64le/third_party/0002-third_party-lss-kernel-structs.patch =================================================================== no
ppc64le/webrtc/Rtc_base-system-arch.h-PPC.patch =================================================================== no
ppc64le/third_party/0004-third_party-crashpad-port-curl-transport-ppc64.patch =================================================================== no
ppc64le/workarounds/HACK-third_party-libvpx-use-generic-gnu.patch =================================================================== no
ppc64le/workarounds/HACK-debian-clang-disable-base-musttail.patch =================================================================== no
disable/widevine-cdm-cu.patch Disable Widevine CDM component updater Michel Le Bihan <michel@lebihan.pl> no
debianization/manpage.patch manpage updates/fixes Daniel Echeverry <epsilon77@gmail.com> yes
debianization/sandbox.patch debian specific instructions when no working sandbox is available Michael Gilbert <mgilbert@debian.org> no
debianization/master-preferences.patch search for {initial,master}_preferences in /etc/chromium
The default chromium behavior of checking the current binary directory for
initial_preferences or master_preferences doesn't conform to debian policy.		 Andres Salomon <dilinger@debian.org> no
debianization/clang-version.patch hardcode lld for whatever version of clang we're using
Upstream doesn't allow overridding the linker name (other than toggling
lld vs gold).		 Andres Salomon <dilinger@debian.org> no
debianization/swiftshader-use-llvm-16.patch switching to llvm-16 for swiftshader Bo Yu <tsu.yubo@gmail.com> not-needed 2024-12-09
debianization/cross-build.patch Enable QEMU-based cross build of Chromium
The modifications in this patch allow our cross build of Chromium to run
foreign-arch build tooling via QEMU, without requiring binfmt-support to be
set up in the build environment.

Note that this is not the standard cross-build approach supported by the GN
build system. Instead of having two separate configurations for host_cpu vs.
target_cpu, we use a single one---that of the foreign arch---and rely on
QEMU for any foreign binary invocations needed by the build. This turns out
to be much easier to set up, since we don't have to worry about two large
(and overlapping) sets of build dependencies.

Main objectives of this patch:

* Wherever a compiled tool may be executed, look at the HOST_EXEC_WRAPPER
environment variable. If it is set, then split the value on whitespace,
and prepend the resulting words to the tool invocation. This will usually
be the appropriate QEMU user mode emulation binary, e.g. "qemu-armhf";

* Rust macros need to be handled a little differently, because they are
dynamically loaded by rustc, and we are using the native-arch rustc.
We thus special-case the build logic so that they are compiled for the
native arch, unlike everything else.

Note that Debian and Chromium use different nomenclature for the native
versus target architectures, which can make "host arch" ambiguous:

| native arch | foreign arch
----------+----------------+---------------
Debian | DEB_BUILD_ARCH | DEB_HOST_ARCH
Chromium | host_cpu | target_cpu

(To make things even more confusing, there is also a DEB_TARGET_ARCH, but
it is relevant only to compilers and other tools that generate binaries.)

See dpkg-architecture(1) for more information on the Debian side, and the
generate-ninja reference for details on host_* versus target_* variables:
https://gn.googlesource.com/gn/+/master/docs/reference.md#predefined_variables

Quick-and-dirty guide to performing a cross build:

(This is written to target armhf, but any other architecture supported by
the package may be substituted. Note that this should be run in a temporary
environment, as the first three steps will result in major changes to the
system. Also, while cross-building via sbuild(1) or the like should work as
a matter of course, the steps below represent a simpler, "manual" approach.)

1. # dpkg --add-architecture armhf

2. # apt-get update

3. # mk-build-deps -ir --host-arch armhf -Pcross /path/to/chromium-src/debian/control

4. (in source tree) $ dpkg-buildpackage -b --host-arch armhf -Pcross		 Daniel Richard G. <skunk@iSKUNK.ORG> no
debianization/rustc-bootstrap.patch Set RUSTC_BOOTSTRAP=1 in the environment so that stable versions of rustc
allow the use of -Z* compiler options, rather than erroring out with

error: the option `Z` is only accepted on the nightly compiler		 no
debianization/safe-libcxx.patch ERROR at //v8/BUILD.gn:791:1: Assertion failed.
assert(!v8_enable_sandbox || use_safe_libcxx,

We certainly don't want to disable the V8 sandbox, but since we're using a
custom libcxx setting enable_safe_libcxx=true in d/rules does nothing. So
we have to force this with a patch.		 Andres Salomon <dilinger@debian.org> no
fixes/ps-print.patch add postscript (ps) printing capability Salvatore Bonaccorso no
fixes/widevine-locations.patch try alternative locations for libwidevinecdm.so - $HOME/.local/lib/ (snap-friendly, see https://launchpad.net/bugs/1738149) Olivier Tilloy <olivier.tilloy@canonical.com> no
fixes/rust-clanglib.patch Rust adds some new clang dependencies; specifically:


This is in the libclang-rt-14-dev package, but with a different (and
architecture-specific) path. So we special-case linux instead of
doing the same thing that upstream does w/ chromeos.		 Andres Salomon <dilinger@debian.org> no
fixes/material-utils.patch ./../third_party/material_color_utilities/src/cpp/palettes/tones.cc:59:27: note: use function 'std::abs' instead
double smallest_delta = abs(smallest_delta_hct.get_chroma() - chroma);
^~~
std::abs
../../third_party/material_color_utilities/src/cpp/palettes/tones.cc:70:9: error: use of undeclared identifier 'round'
if (round(chroma) == round(smallest_delta_hct.get_chroma())) {
^		 no
fixes/gentoo-stylesheet.patch [PATCH 1/2] IWYU css_style_sheet.h
issues.chromium.org/issues/429365675 replaces a bunch of includes with
forward declarations. These builds clearly work with "normal" builds, which
likely use C++ modules or precompiled headers, but break if your workflow
does not use those features.

Add appropriate includes to fix the build on Linux platforms.		 Matt Jolly <kangie@gentoo.org> no 2025-09-09
fixes/libcpp-headers.patch ERROR at //build/config/BUILDCONFIG.gn:700:11: Unable to load "/chromium-141.0.7390.37/buildtools/third_party/libc++/BUILD.gn".
"//buildtools/third_party/libc++:libcxx_headers",
^-----------------------------------------------		 no
fixes/memory-allocator-dcheck-assert-fix.patch no
fixes/predictor-denial-of-service.patch no
fixes/fix-assert-in-vnc-sessions.patch no
fixes/armhf-timespec.patch fix armhf build failure:

../../media/gpu/v4l2/legacy/v4l2_video_decoder_backend_stateful.cc:446:20: error: non-constant-expression cannot be narrowed from type '__suseconds64_t' (aka 'long long') to 'long' in initializer list [-Wc++11-narrowing]
446 | .tv_nsec = timeval.tv_usec * 1000,
| ^~~~~~~~~~~~~~~~~~~~~~
../../media/gpu/v4l2/legacy/v4l2_video_decoder_backend_stateful.cc:446:20: note: insert an explicit cast to silence this issue
446 | .tv_nsec = timeval.tv_usec * 1000,
| ^~~~~~~~~~~~~~~~~~~~~~
| static_cast<long>( )
1 error generated.		 Andres Salomon <dilinger@debian.org> no
fixes/updater-test.patch and chrome/updater/BUILD.gn was still including old_updater with
the same logic..		 Andres Salomon <dilinger@debian.org> no
fixes/armhf-no-thumb.patch Don't use thumbv7neon Rust target
In the armhf build, Chromium wants to use a Rust target for NEON that
Debian does not ship. Force it to use the target that we do have.

[883/52770] ACTION //build/rust/std:find_stdlib(//build/toolchain/linux/unbundle:default_for_rust_host_build_tools)
FAILED: default_for_rust_host_build_tools/obj/build/rust/std/libstd.rlib [...]
python3 ../../build/rust/std/find_std_rlibs.py --rust-bin-dir ../../../../../usr/bin --output default_for_rust_host_build_tools/obj/build/rust/std --depfile default_for_rust_host_build_tools/obj/build/rust/std/stdlib.d --depfile-target std --rustc-revision rustc\ 1.85.0\ \(4d91de4e4\ 2025-02-17\)\ \(built\ from\ a\ source\ tarball\) --target thumbv7neon-unknown-linux-gnueabihf
Traceback (most recent call last):
File "/build/reproducible-path/chromium-136.0.7103.59/out/Release/../../build/rust/std/find_std_rlibs.py", line 132, in <module>
sys.exit(main())
~~~~^^
File "/build/reproducible-path/chromium-136.0.7103.59/out/Release/../../build/rust/std/find_std_rlibs.py", line 87, in main
name for name in os.listdir(rustlib_dir) if name.endswith('.rlib')
~~~~~~~~~~^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/usr/lib/rustlib/thumbv7neon-unknown-linux-gnueabihf/lib'		 Daniel Richard G. <skunk@iSKUNK.ORG> no
fixes/armhf-icf.patch disable ICF on armhf to avoid segfaults during build
Work around a clang/lld bug of some type on armhf, as seen here:
https://buildd.debian.org/status/fetch.php?pkg=chromium&arch=armhf&ver=137.0.7151.103-1&stamp=1749630295&raw=0

This only happens when linking libc++ statically, so it can go away once
we've got libc++1/libc++abi1/libunwind packages sorted out.		 Daniel Richard G. <skunk@iSKUNK.ORG> no
fixes/libpng-testonly.patch Commit 4f7637304eca894adf2e70078a55654a88224a30 creates a separate
libpng_for_testonly target in order to limit visiblity and enforce
correctness on testonly targets. However, they forgot to add the
target to build/linux/unbundle/libpng.gn.

I'd send this upstream, except they're planning on replacing libpng
with their own in-house rust implementation (see
<https://issues.chromium.org/issues/443128323>), so.. meh. Very much
not worth it.		 Andres Salomon <dilinger@debian.org> no
fixes/autofill-binarypb.patch Error processing node <?xml version="1.0" encoding="UTF-8"?>
<include compress="gzip" file="alternative_state_name_maps/DE.binarypb" name="IDR_STATE_NAME_MAP_DE_ALTERNATIVES" type="BINDATA" />: [Errno 2] No such file or directory: '../../components/autofill/core/browser/geo/alternative_state_name_maps/DE.binarypb'

Unfortunately, the two (non-empty) binarypb files originate from
<https://chrome-internal.googlesource.com/chrome/components/autofill_alternative_state_name_maps.git>,
which is not public. I can only assume that the source files (.textpb or
.textproto) are located in this internal repository, but only Googlers
know. We could probably reverse engineer it, but it might be easier to
just get some of their employees to make this stuff public.

protoc --decode_raw shows, for example:

1: "DE"
2 {
1: "bayern"
2: "by"
3: "bavaria"
}		 Andres Salomon <dilinger@debian.org> no
fixes/bindgen-paths.patch The bindgen build rules need to know the location of the rustfmt binary and
the libclang shared library.		 no
fixes/swiftshader-dependencies.patch no
fixes/bytemuck.patch Gate bytemuck's SIMD impls on rust version, not date, to fix FTBFS bytemuck 1.25.0 (vendored by Chromium) ships two implementations of Zeroable/Pod
for core::simd::Simd, selected with rustversion: one uses core::simd::LaneCount /
SupportedLaneCount, the other omits them (rust removed those on 2026-01-27;
upstream bytemuck issue 343). Upstream selects by compiler date.
.
rustversion mis-dates Debian's stable rustc 1.95 as before that date, so it picks
the LaneCount implementation -- but 1.95 already removed LaneCount, and the build
fails with E0425/E0405.
.
Select by rust version instead: before 1.95 (e.g. trixie/bookworm's 1.85) keeps
the LaneCount implementation; 1.95+ (sid) uses the other. Builds on both.
.
Supersedes the earlier bytemuck.patch (it added a bound that 1.25.0 now ships).

diff --git a/third_party/rust/chromium_crates_io/vendor/bytemuck-v1/src/pod.rs b/third_party/rust/chromium_crates_io/vendor/bytemuck-v1/src/pod.rs
index 330f722..c8a87b5 100644		 Juan Manuel Méndez Rey <juan.mendezr@proton.me> not-needed upstream 2026-06-02
fixes/arm-logging.patch ../../media/gpu/sandbox/hardware_video_decoding_sandbox_hook_linux.cc:123:9: error: use of undeclared identifier 'ERROR' no
upstream/sysroot.patch commit b93239da427a5019a9742d44e50e9996c1b04ea9

Only pass sysroot if use_sysroot.

Fixes the build when use_sysroot = false as then 'sysroot' variable is empty.

Bug: None
Change-Id: I7fc7ba35f3ba416af0cbd8df94393dc901724b8b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7927226
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Commit-Queue: Andrew Grieve <agrieve@chromium.org>
Reviewed-by: Andrew Grieve <agrieve@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1649706}		 Nathan Pratta Teodosio <nathan.teodosio@canonical.com> no 2026-06-19
disable/clang-version-check.patch remove strict clang version check during config
Chromium 107 has a strict clang version check, added in commit
8f23a2c2d14fd799813134e995c160354d75d3a0. This needs a proper fix
upstream; some way to check (or specify) whether it's a distribution
build, and therefore shouldn't require a particular git version of
clang.

For now, let's just get this building in debian.		 Andres Salomon <dilinger@debian.org> no
upstream/ar-path1.patch commit 60f987d8d5f7272793a40290d060b8f50933f825

build: Omit ar from inputs when resolved via $PATH

The GN build configuration previously added the `ar` tool to the inputs
list unconditionally. However, if the `ar` tool is specified simply by
its filename and is resolved via the system `$PATH`, it should not be
tracked as a direct input dependency.

This change adds a condition to verify if `ar` is an explicit path
rather than just a filename. It only includes `ar` in the action's
inputs list when it is not resolved from `$PATH`.

This is to address
https://crrev.com/c/7835150/8/build/toolchain/gcc_toolchain.gni#406

Bug: 358521078
Change-Id: I096ac4aa7f3b697c58c94af1349159b9c87f4201
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7904982
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Reviewed-by: Matt Stark <msta@google.com>
Auto-Submit: Takuto Ikuta <tikuta@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1643634}		 Takuto Ikuta <tikuta@chromium.org> no 2026-06-08
upstream/ar-path2.patch commit 7d6555b11f181bdc24ba56577f753a07add6e8c7

build: Fix get_path_info on empty ar in unbundle toolchain

Some toolchains leave ar empty during initial setup, causing GN to error
when get_path_info() is called with an empty string. Guard the check to
only run when ar is not empty.

Signed-off-by: Matt Jolly <kangie@gentoo.org>
Change-Id: I87615806ddfda6f262a7500b0c5b6fed1f452985
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7949777
Reviewed-by: Takuto Ikuta <tikuta@chromium.org>
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Reviewed-by: Matt Stark <msta@google.com>
Cr-Commit-Position: refs/heads/main@{#1648076}		 Matt Jolly <kangie@gentoo.org> no 2026-06-16
upstream/libyuv-loongarch-fix-row_lsx.cc-and-row_lasx.cc.patch loongarch: fix row_lsx.cc and row_lasx.cc
Remove custom ArgbConstants struct and use unified layout from row.h.		 yuanhecai <yuanhecai@loongson.cn> no 2026-06-24
disable/tests.patch no
disable/tests-swiftshader.patch no
disable/signin.patch disable browser sign-in no https://raw.githubusercontent.com/Eloston/ungoogled-chromium/master/resources/patches/ungoogled-chromium/disable-signin.patch
disable/catapult.patch remove dependencies on third_party catapult

See https://bugs.debian.org/922431 for more details, but tl;dr: we should
bring this back and just get rid of the (common) minified stuff in catapult/third_party/.

Stuff like chai, jszip, and node-d3 are packaged for debian already.		 Michael Gilbert <mgilbert@debian.org> no
disable/font-tests.patch disable building font tests Michael Gilbert <mgilbert@debian.org> no
disable/google-api-warning.patch disable the google api key warning when those aren't found Michael Gilbert <mgilbert@debian.org> no
disable/third-party-cookies.patch disable third-party cookies by default
This is easily configured in
Settings -> Security & Privacy -> Cookies & other site data

With this patch, we just change the default on a new chromium profile.		 Andres Salomon <dilinger@debian.org> no
disable/driver-chrome-path.patch Disable usage of google-chrome in driver Michel Le Bihan <michel@lebihan.pl> no
disable/screen-ai-blob.patch delete ~/.config/chromium/screen_ai and don't download libchromescreenai.so
This fixes https://bugs.debian.org/1066910

Chromium will download libchromescreenai.so (an opaque binary blob that
does OCR and other things) without warning the user when you
open a PDF in "reading mode". We don't actually know what's in the
binary blob, so we disable the ScreenAI service right up front (and
as an added benefit, that deletes everything in ~/.config/chromium/screen_ai		 Andres Salomon <dilinger@debian.org> no
disable/node-version-ck.patch disable the node version check
https://chromium-review.googlesource.com/c/chromium/src/+/6334038 added
a node version check, but we don't want that as we're using debian's
packaged node.		 Andres Salomon <dilinger@debian.org> no
disable/license-headless-shell.patch Don't generate the LICENSE.headless_shell file, since we don't need it, and
the rule for it is annoyingly fragile.		 no
disable/enterprise-tests.patch I don't actually know why this is needed; as far as I can tell, none of the
enterprise_companion stuff changed between v144 and v145.. But some gn
dependency is clearly pulling in the integration tests (which are deleted
along w/ the rest of the enterprise_companion stuff).		 no
disable/rustc-allow-features.patch Don't restrict the use of unstable Rust features
error[E0725]: the feature `foobaz` is not in the list of allowed features

We often need to make use of these to get the build working with older
versions of Rust.		 Daniel Richard G. <skunk@iSKUNK.ORG> no
disable/lint.patch Disable CSS/JavaScript linting tools
Not only do we have no use for these, they are implemented in Node.js code
that breaks on older systems.		 Daniel Richard G. <skunk@iSKUNK.ORG> no
disable/libei.patch We removed libei due to prebuilt upstream binaries. In
https://chromium-review.googlesource.com/c/chromium/src/+/7774469 moved
away from the prebuilt binaries, but in the process also add some references
to the deleted directory. For now, just remove those references; maybe later
we re-add libei.		 no
system/icu-shim.patch allow building against system icu even when is_offical_build=true
I noticed this when switching to an official build and trying to build against
the system's libicu, but it may be necessary for other system libs as well.
If we switch to using the bundled icu, we can see if it's possible to get rid
of it.		 Andres Salomon <dilinger@debian.org> no
system/jpeg.patch use system jpeg library Michael Gilbert <mgilbert@debian.org> no
system/openjpeg.patch no
system/opus.patch no
llvm-19/const-profile.patch Remove const-ness from functions due to the follow (clang19-specific) error:

/usr/bin/../include/c++/v1/__tree:2092:24: error: no matching function for call to object of type 'const value_compare' (aka 'const std::less<base::raw_ptr<Profile, partition_alloc::internal::RawPtrTraits::kMayDangle>>')		 no
llvm-19/static-assert.patch fixes various compile-time static_assert() checks that clang-19 doesn't like:


../../media/gpu/vaapi/vaapi_jpeg_encoder.cc:101:19: error: static assertion expression is not an integral constant expression
101 | static_assert(num_dc_codes.size() == dcTable.code_length.size());
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../media/gpu/vaapi/vaapi_jpeg_encoder.cc:101:42: note: initializer of 'dcTable' is not a constant expression
101 | static_assert(num_dc_codes.size() == dcTable.code_length.size());
| ^

Likely differences in llvm-19 vs llvm-22 c++ headers (there's probably
more inlined code in llvm-22, or stuff that's marked constexpr) means the
compiler can't do compile-time asserts.		 Andres Salomon <dilinger@debian.org> no
llvm-19/keyfactory.patch can't increment there, mate!

../../components/enterprise/client_certificates/core/private_key_factory.cc:126:14: error: expression is not assignable
126 | ++std::find(std::begin(kKeySourcesOrderedBySecurity),
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
127 | std::end(kKeySourcesOrderedBySecurity), source);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.		 Andres Salomon <diliger@debian.org> no
llvm-19/clang-19-crash.patch Whee, this code makes clang-19 crash!

clang++-19: error: clang frontend command failed with exit code 139 (use -v to see invocation)
Debian clang version 19.1.7 (20+b2)
Thread model: posix
clang++-19: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang++-19: note: diagnostic msg: ../clang-crashreports/origin_with_possible_wildcards-399e2d.cpp
clang++-19: note: diagnostic msg: ../clang-crashreports/origin_with_possible_wildcards-399e2d.sh
clang++-19: note: diagnostic msg:		 Andres Salomon <dilinger@queued.net> no
llvm-19/clone-traits.patch no
llvm-19/octal.patch Newer C++ supports 0o for octal notation, but clang-19 does not. Andres Salomon <dilinger@debian.org> no
llvm-19/value-or.patch ../../ui/gfx/paint_vector_icon.cc:238:53: error: no matching member function for call to 'value_or'
238 | const SkPoint last_point = path.getLastPt().value_or({0, 0});
| ~~~~~~~~~~~~~~~~~^~~~~~~~		 no
llvm-19/clang19.patch no
llvm-19/iota.patch ../../base/strings/string_util_impl_helpers.h:235:16: error: no member named 'iota' in namespace 'std::ranges' no
llvm-19/raw-ref-map-find.patch /usr/bin/../include/c++/v1/map:657:12: error: no matching function for call to object of type 'const std::less<base::raw_ref<permissions::PermissionRequest>>'

llvm-19 headers don't like when chromium switched from a C-style pointer
to a base::raw_ref, so we have to iterate through the map manually instead
of using std::map::find().		 Andres Salomon <dilinger@debian.org> no
llvm-19/i18n-builder-enum.patch In file included from ../../base/i18n/icubridge/icu_bridge.cc:7:
../../base/i18n/icubridge/date_time_formatter.h:142:19: error: use of non-static data member 'length' of 'DateTimeFormatterOptions' from nested type 'Builder'
142 | static_assert(length != DateTimeFormatterOptions::ItemLength::kNone,
| ^~~~~~
../../base/i18n/icubridge/date_time_formatter.h:151:22: error: use of non-static data member 'length' of 'DateTimeFormatterOptions' from nested type 'Builder'
151 | options.length = length;
| ^~~~~~
2 errors generated.

Clang-19 really doesn't like this out-of-line definition of Builder where
the inline declaration has a default value for length, but the definition
does not. It seems to get confused. So, just define it inline.		 Andres Salomon <dilinger@debian.org> no
llvm-19/0001-revert-v8-libm.patch Revert the following:

commit 43f04a52f24dab40d3d9ff7aa4849e70a0d10225

Implement Math.{atan,atan2}() using LLVM's libm

Before:

=======================================================================
Function Max ULP Mean ULP % CR % FR Accuracy Ops/sec
-----------------------------------------------------------------------
Math.atan 1.00 0.1754 82.5% 100.0% 85.1 208.1M
Math.atan2 1.00 0.1883 81.2% 100.0% 84.2 74.2M

After:

Math.atan 1.00 0.1214 87.9% 100.0% 89.2 290.6M
Math.atan2 1.00 0.1407 85.9% 100.0% 87.7 197.3M

Note that LLVM-libm's atan / atan2 isn't exact (yet?):
https://github.com/llvm/llvm-project/issues/197072

Having said that: It's a bit more accurate than fdlibm's, and it's
a lot faster (faster enough that it'll hopefully still be competitive
if it's made exact, which will likely slow it down some).

Bug: 510499297
Change-Id: I1a1854ae7f3c855ab352323b8ad0aa5778f5bdb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7864725
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#107532}		 Nico Weber <thakis@chromium.org> no 2026-05-20
llvm-19/0002-revert-v8-libm.patch Revert the following:

commit 716d3e3363c5bdb26e6de68327f6a1c559b8bf19

Implement base::ieee754::legacy::pow() using LLVM's libm

base::ieee754::legacy::pow() is only used if use_std_math_pow is
false, which is only the case on AIX at the moment. So no real
behavior change at the moment.

The old base::ieee754::pow() implementation contained some
javascript-specific code. Since LLVM's libm's pow() doesn't have
that, tweak v8::internal::math::pow() to call the javascript-specific
code in there out of the use_std_math_pow conditional, so that it's
used in the LLVM libm pow codepath as well.


With use_std_math_pow = true (default), on macOS:

=======================================================================
Function Max ULP Mean ULP % CR % FR Accuracy Ops/sec
-----------------------------------------------------------------------
Math.pow 1.00 0.0612 93.9% 100.0% 94.2 145.0M


With use_std_math_pow = false, before:

Math.pow 1.00 0.0685 93.1% 100.0% 93.6 58.0M


With use_std_math_pow = false, after:

Math.pow 1.00 0.0582 94.2% 100.0% 94.5 140.7M

Note: LLVM libm's pow() is not yet exact! It does have a lower mean ULP
than the other two, but not 0 yet. Performance is much better than
fdlibm's implementation, but a bit worse than macOS's libm.


Depends on https://github.com/llvm/llvm-project/issues/197212 which
fixes a correctness bug with llvm-libm. Without that, the last row
looks something like:

Math.pow 8.5e+303 684598378898 93.7% 99.6% 0.0 141.2M

i.e. very large mean ULP, and hence accuracy score of 0. That commit
was rolled into:

* Chromium in
https://chromium-review.googlesource.com/c/chromium/src/+/7855707
* V8 in:
https://chromium-review.googlesource.com/c/v8/v8/+/7857152
* node-CLI in:
https://chromium-review.googlesource.com/c/v8/node-ci/+/7857289

Bug: 510499297
Change-Id: I48eb5540839089b27b6d76e22300709f2227ca7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7857151
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Nico Weber <thakis@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#107409}		 Nico Weber <thakis@chromium.org> no 2026-05-18
llvm-19/0003-revert-v8-libm.patch Revert the following:

commit e5bb55463b592ea0cb9480736146941c10e6bb62

Implement Math.{exp,expm1}() using LLVM's libm

After another fix [1] to my benchmark to not pass in many values
that result in inf, this is a performance improvement (and comes
with full accuracy).

Before:

====================================================================
Function Max ULP Mean ULP % CR % FR Accuracy Ops/sec
--------------------------------------------------------------------
Math.exp 1.00 0.1973 80.3% 100.0% 83.5 248.2M
Math.expm1 1.00 0.1605 83.9% 100.0% 86.2 169.8M

After:

Math.exp 0.00 0.0000 100.0% 100.0% 100.0 311.2M
Math.expm1 0.00 0.0000 100.0% 100.0% 100.0 225.1M

The LLVM libm functions _are_ quite a bit slower for inputs >= 709,
where the result is inf. In practice, such inputs are hopefully rare.
We can also improve performance for such inputs significantly (without
hit to accuracy) by defining LIBC_MATH to
`(LIBC_MATH_NO_ERRNO | LIBC_MATH_NO_EXCEPT)`. We can improve it even
more (to even better than system libm on macOS) if we also get the
option I'm proposing in http://llvm.org/PR198276 (which also has
perf measurements). I'm leaving perf of big values to a future CL.

1: https://github.com/nico/js-math-bench/commit/67bb3d17b

Bug: 510499297
Change-Id: I180a46146d3b3d8ebf8a5a67c8108319ae1d2b3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7855008
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#107390}		 Nico Weber <thakis@chromium.org> no 2026-05-18
llvm-19/0004-revert-v8-libm.patch Revert the following:

commit bc40c180447a813feea283c7bcb531113a37738e

Implement Math.{acos,asin}() using LLVM's libm

After a fix [1] to my benchmark to not mostly pass in values that
are out of domain, this comes with a fairly small perf hit, in
return for full accuracy.

Before:

====================================================================
Function Max ULP Mean ULP % CR % FR Accuracy Ops/sec
--------------------------------------------------------------------
Math.acos 1.00 0.1296 87.0% 100.0% 88.5 164.1M
Math.asin 1.00 0.0285 97.1% 100.0% 97.2 174.6M

After:

Math.acos 0.00 0.0000 100.0% 100.0% 100.0 130.4M
Math.asin 0.00 0.0000 100.0% 100.0% 100.0 149.2M

(Passing in values outside the domain of [-1, 1] now produces nan
quite a bit slower. Before, we hit ~500-600 Ops/sec, now we hit
~170 Ops/sec for that use case.
`#define LIBC_MATH (LIBC_MATH_NO_ERRNO | LIBC_MATH_NO_EXCEPT)` gets
it to ~310 Ops / sec, so we'll likely want to set that at some point
as there isn't really a reason not to do it. But even then, the
out-of-domain case is quite a bit slower. In practice, this should
hopefully be rare, though.)

1: https://github.com/nico/js-math-bench/commit/807684d98

Bug: 510499297
Change-Id: I7985d2fac072186ab5486173553b53613f8755bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7849784
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Auto-Submit: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#107355}		 Nico Weber <thakis@chromium.org> no 2026-05-15
llvm-19/0005-revert-v8-libm.patch Revert the following:

commit 1e79e037bf40e0554d010a389d0635193bfca172

[math] Remove no-longer-needed Wshadow suppressions

Depends on:
https://chromium-review.googlesource.com/c/v8/node-ci/+/7841356

(In regular v8, llvm-libc is autorolled.)

Bug: 510499297
Change-Id: I98549a996e61320216ea2d9ee1a2a1a96376e811
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7837998
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#107328}		 Nico Weber <thakis@chromium.org> no 2026-05-11
llvm-19/0007-revert-v8-libm.patch Revert the following:

commit 7c1d2c3724000b4895ef95f75670ca0b6f3ebe4d

Implement non-glibc Math.{cos,sin}() using LLVM's libm

This only has an effect for `v8_use_libm_trig_functions = false`.
v8_use_libm_trig_functions defaults to `is_clang`, which means it's
true in chromium builds. In other words, this CL does not affect
production Chromium builds.

With v8_use_libm_trig_functions = true, both before and after this CL:

====================================================================
Function Max ULP Mean ULP % CR % FR Accuracy Ops/sec
--------------------------------------------------------------------
Math.cos 1.00 0.1840 81.6% 100.0% 84.5 228.0M
Math.sin 1063.00 1.0556 77.6% 99.9% 48.6 200.4M

(Note: `sin` is very off; this is crbug.com/511271840.)

With v8_use_libm_trig_functions = false, before:

Math.cos 1.00 0.1840 81.6% 100.0% 84.5 126.1M
Math.sin 1.00 0.2106 78.9% 100.0% 82.6 149.0M

With v8_use_libm_trig_functions = false, after:

Math.cos 0.00 0.0001 100.0% 100.0% 100.0 230.3M
Math.sin 0.00 0.0000 100.0% 100.0% 100.0 235.3M

So the new implementation is fully accurate, and it looks like it's
also faster for the inputs in my benchmark than glibc's sin/cos.
We might consider moving v8_use_libm_trig_functions back to false
and it might help with benchmarks too. (Looks like there's still a
flag for it, maybe we can use that flag to switch back.)

...but for sin/cos/tan, performance is pretty value-dependent due
to the range reduction step needed for large arguments. See
https://issues.chromium.org/issues/510499297#comment9 for some more
numbers.

Bug: 510499297,511271840,42203419
Change-Id: I4d63a5723b69e87147985ef361292beabc31965b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7837738
Auto-Submit: Nico Weber <thakis@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#107242}		 Nico Weber <thakis@chromium.org> no 2026-05-11
llvm-19/0008-revert-v8-libm.patch Revert the following:

commit cc1a6fcbdabbe4c912948bebe29371c084eade33

[math] Implement Math.tan() using LLVM's libm

Before:

====================================================================
Function Max ULP Mean ULP % CR % FR Accuracy Ops/sec
--------------------------------------------------------------------
Math.tan 1.00 0.1872 81.3% 100.0% 84.2 101.4M

After:

Math.tan 0.00 0.0000 100.0% 100.0% 100.0 187.4M

Quite a bit faster, and fully accurate.

Bug: 510499297
Change-Id: I1d3170716e7e4fadba2abdc5d7686208e5df31e4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7836487
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Nico Weber <thakis@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#107225}		 Nico Weber <thakis@chromium.org> no 2026-05-11
llvm-19/0009-revert-v8-libm.patch Revert the following:

commit 08be4445f60b3470b2b3130c97d41f09472bd076

Implement Math.{log,log1p,log2,log10}() using LLVM's libm

Before:

=======================================================================
Function Max ULP Mean ULP % CR % FR Accuracy Ops/sec
-----------------------------------------------------------------------
Math.log 1.00 0.1934 80.7% 100.0% 83.8 241.1M
Math.log1p 1.00 0.1582 84.2% 100.0% 86.3 204.1M
Math.log2 1.00 0.1848 81.5% 100.0% 84.4 262.1M
Math.log10 1.00 0.2263 77.4% 100.0% 81.5 148.5M

After:

Math.log 0.00 0.0000 100.0% 100.0% 100.0 263.6M
Math.log1p 0.00 0.0000 100.0% 100.0% 100.0 217.3M
Math.log2 0.00 0.0000 100.0% 100.0% 100.0 257.5M
Math.log10 0.00 0.0000 100.0% 100.0% 100.0 241.0M

So from "pretty accurate" to "100% perfectly accurate", and a bit
faster too (except for log2, which gets a bit slower).

Bug: 510499297
Change-Id: I3ca3e95fd477f8c4406dd8d0d6d05c76957e0a56
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7831096
Auto-Submit: Nico Weber <thakis@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#107201}		 Nico Weber <thakis@chromium.org> no 2026-05-09
llvm-22/ignore-for-ubsan.patch clang++-19: error: unknown argument: '-fsanitize-ignore-for-ubsan-feature=array-bounds' no
ungoogled/disable-ai.patch # Disable Glic ("Gemini Live in Chrome"), ScreenAI, and associated AI-based
# features.		 no
llvm-19/0011-revert-v8-libm.patch Revert the following:

commit 96ce1682b7e68a119353f5de1972f6eb8d6bdc01

Implement Math.cbrt() using LLVM's libm

This is the first Math function using LLVM's libm, so this sets up
a tiny bit of infrastructure to be able to use it too.

Every embedder of V8 that uses a GN build will have to add a change like
https://chromium-review.googlesource.com/c/chromium/src/+/7829957

https://chromium-review.googlesource.com/c/v8/node-ci/+/7829133 picked
up that change for node-ci for the node_ci_linux64_rel bot.

Bug: 510499297
Change-Id: I30424bd6a0bfea6f9d4b06c5a4e63963d7839714
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7828379
Auto-Submit: Nico Weber <thakis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#107185}		 Nico Weber <thakis@chromium.org> no 2026-05-08
trixie/rust-no-alloc-shim.patch work around the following build error (likely required by a newer rustc):

ld.lld-19: error: undefined symbol: __rust_no_alloc_shim_is_unstable
>>> referenced by raw_vec.rs:0 (library/alloc/src/raw_vec.rs:0)
>>> std-204c535bb1c72e7d.std.83f6108400cae6c8-cgu.04.rcgu.o:(core::slice::sort::stable::driftsort_main::h2af4412729044fb7) in archive prebuilt_rustc_sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd.rlib

This reverts commit 8393b61ba876c8e1614275c97767f9b06b889f48

[rust] Remove __rust_no_alloc_shim_is_unstable		 Hans Wennborg <hans@chromium.org> no 2025-06-30
trixie/rust-sanitize.patch --> ../../third_party/crabbyavif/src/src/capi/io.rs:210:41
|
210 | #[cfg_attr(feature = "disable_cfi", sanitize(cfi = "off"))]
| ^^^^^^^^

taken from https://github.com/ungoogled-software/ungoogled-chromium/pull/3514		 no
trixie/cookie-string-view.patch revert one std::string -> string_view conversion due to the following erorr:


../../net/cookies/cookie_util.cc:844:31: error: no viable conversion from 'const_iterator' (aka 'const char *') to 'std::string::const_iterator' (aka '__wrap_iter<const char *>')
844 | std::string::const_iterator i = header_value.begin();
| ^ ~~~~~~~~~~~~~~~~~~~~		 Andres Salomon <dilinger@debian.org> no
trixie/gn-string-hash.patch Work around a missing string_hash(), not present in trixie's gn version.


ERROR at //build/rust/gni_impl/rust_target.gni:51:17: Unknown function.
_dir_hash = string_hash(get_label_info(":${_target_name}", "dir"))
^----------		 Andres Salomon <dilinger@debian.org> no
trixie/nodejs-set-intersection.patch no
trixie/gn-inputs.patch Revert the following commit:

commit 9193ab90af24c23ee983e0a8da9bed45712f0d26

Reland "build: Use tool inputs instead of siso config for rust actions"

This reverts commit 080e6a7ab8ed54261b495db2b84140d6c5062af7.

Reason for revert: Added inputs for remote action in cog build.

Original change's description:
> Revert "build: Use tool inputs instead of siso config for rust actions"
>
> This reverts commit 3c3ae5ec818626d8efdaefd62ceb07dbbe5c6adf.
>
> Reason for revert: broke Cider build
>
> Original change's description:
> > build: Use tool inputs instead of siso config for rust actions
> >
> > Also remove unused filegroups.
> >
> > Bug: 491242305
> > Change-Id: If8da44a4741db7eced84ba20c1b69f4543b14217
> > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7710197
> > Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
> > Reviewed-by: Junji Watanabe <jwata@google.com>
> > Cr-Commit-Position: refs/heads/main@{#1607564}
>
> Bug: 491242305, 498008190
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: 491242305
> Change-Id: I2c9eb13d1a0bbed06b8b85353c6286bc542d74b1
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7716738
> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Auto-Submit: Takuto Ikuta <tikuta@chromium.org>
> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Cr-Commit-Position: refs/heads/main@{#1607814}

Bug: 491242305, 498008190
Bug: 491242305
Change-Id: I3c992a83dd50bb9695e9ab27f58906d16f05c367
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7719879
Reviewed-by: Junji Watanabe <jwata@google.com>
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1608267}		 Takuto Ikuta <tikuta@chromium.org> no 2026-03-31
trixie/gn-inputs2.patch Revert the following commit:

commit b660e95a13cd6f53aad2ec34a34de7df6a18a2a3

build: Use tool inputs instead of siso config for rust actions

Bug: 491242305
Change-Id: Id476f75efeb47eca7435b09befb1be47ab05f95f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7707348
Auto-Submit: Takuto Ikuta <tikuta@chromium.org>
Reviewed-by: Junji Watanabe <jwata@google.com>
Commit-Queue: Junji Watanabe <jwata@google.com>
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1606959}		 Takuto Ikuta <tikuta@chromium.org> no 2026-03-30
trixie/revert-v8-sanitize.patch Revert the following due to build failure:

commit d3f0ec122bd234aa82347cc0e838c8fae8cd6565

Revert "build: Move sanitizer defines into GN"

This reverts commit 3138277894378caa7211fb0ea36128f357c34653.

Reason for revert: Updated Chromium build config (see comments)

Original change's description:
> build: Move sanitizer defines into GN
>
> To accommodate Chromium defaulting `-fsanitize=array-bounds` in
> `//build/config`, this change moves V8's sanitizer `#define`s out of
> `base/macros.h` straight into a global-ish build config provided by
> the V8 build templates. This strongly ties the sanitizer gating macros
> to GN's `is_asan` etc.
>
> Bug: 430178746
> Change-Id: I4c1d96827db70d3309c093b3473998237ceeb1a0
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6966641
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Kalvin Lee <kdlee@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#102621}

Bug: 430178746
Change-Id: Id78435e16ab4765f64dde1895e25f87c770d4648
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7665605
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Kalvin Lee <kdlee@chromium.org>
Cr-Commit-Position: refs/heads/main@{#105818}		 Kalvin Lee <kdlee@chromium.org> no 2026-03-16
trixie/gn-expand-dir-allowlist.patch ERROR at //.gn:174:30: Assignment had no effect.
expand_directory_allowlist = build_dotfile_settings.expand_directory_allowlist
^------------------------------------------------
You set the variable "expand_directory_allowlist" here and it was unused before it went


This variable was added in https://gn.googlesource.com/gn/+/42ace47bb426ca9705175d866bb9bdf168d5535f
in April 2026.		 no
trixie/gn-additional-outputs.patch ERROR at //build/config/compiler/BUILD.gn:2817:9 (//build/toolchain/linux/unbundle:default_for_rust_host_build_tools): Assignment had no effect.
[ "{{target_out_dir}}/{{label_name}}/{{source_name_part}}.dwo" ]
^--------------------------------------------------------------
You set the variable "c_additional_outputs" here and it was unused before it went
out of scope.
See //build/config/BUILDCONFIG.gn:357:3: which caused the file to be

Partially reverts commit deffd02cfa87a0f69cab81068e289d3df39fe875

Reland^3 "build: add .dwo outputs to cc and cxx tools for debug fission"


(which requires a newer generate-ninja than we have in trixie.)		 Takuto Ikuta <tikuta@chromium.org> no 2026-05-10
bookworm/gn-revert-path-exists.patch This is a mix of commit fd011815c455976b15e31966f826628b4f9f61d4
("don't keep use_reclient=true with .reproxy_tmp") pulled from upstream
plus a revert of upstream's 49b23faa16ad14e96601aea8772c7279fcbd6b44
("sysroot.gni: Use path_exists() rather than exec_script("dir_exists.py")
in order to work on older gn that lacks path_exists().		 no
bookworm/foreach.patch work around an issue with libstdc++-12, where clang gets confused and can't
find base::Value::Dict's Append when inside a lambda inside of for_each:

In file included from ../../components/services/app_service/public/cpp/permission.cc:9:
../../base/containers/to_value_list.h:39:46: error: no matching member function for call to 'Append'
39 | [&]<typename T>(T&& value) { container.Append(std::forward<T>(value)); },
| ~~~~~~~~~~^~~~~~


Rather than call for_each, we iterate manually (but still call the lambda).		 Andres Salomon <dilinger@debian.org> no
ungoogled/disable-mei-preload.patch # Disables use of a binary for preloading the Media Engagement index
# Said binary is: chrome/browser/resources/media/mei_preload/preloaded_data.pb
# According to media/base/media_switches (for PreloadMediaEngagementData), it
# "enables a list of origins to be considered as having a high MEI until there
# is enough local data to determine the user's preferred behavior." This feature
# does not seem to outweigh the benefit of removing the binary, thus this patch.		 no
ungoogled/disable-privacy-sandbox.patch no
ungoogled/remove-navigation-source-param.patch # This removes a tracking parameter that is injected into the URL
# when navigating from the onmibox/realbox		 no
i386/support-i386.patch don't disable i386 builds on linux
https://chromium-review.googlesource.com/c/chromium/src/+/3583780

Chromium upstream decided to kill off i386 builds on Linux. They were
goin to add a 'force_x86_support' arg, but instead "[distributions that
still support i386] can patch the file."

At this point, i386 on linux is completely unsupported upstream, so
we're on our own with bugs.		 Andres Salomon <dilinger@debian.org> no
ppc64le/sandbox/0001-sandbox-Enable-seccomp_bpf-for-ppc64.patch =================================================================== no
ppc64le/sandbox/0009-sandbox-ignore-byte-span-error.patch =================================================================== no
ppc64le/third_party/0001-third_party-angle-Include-missing-header-cstddef-in-.patch =================================================================== no
ppc64le/third_party/0001-Add-PPC64-support-for-boringssl.patch =================================================================== no
ppc64le/third_party/0001-third_party-libvpx-Disable-vsx-on-ppc64.patch =================================================================== no
ppc64le/third_party/0001-third_party-libvpx-Properly-generate-gni-on-ppc64.patch third_party/libvpx: Properly generate gni on ppc64 Shawn Anastasio <shawnanastasio@yahoo.com> no 2018-09-04
ppc64le/third_party/0001-third_party-pffft-Include-altivec.h-on-ppc64-with-SI.patch third_party/pffft: Include altivec.h on ppc64 with SIMD enabled Shawn Anastasio <shawn@anastas.io> no 2019-04-24
ppc64le/third_party/0001-swiftshader-fix-build.patch fix swiftshader build issue on ppc64el yes upstream vendor, https://gitlab.raptorengineering.com/raptor-engineering-public/chromium/openpower-patches/-/blob/chromium-131/patches/ppc64le/third_party/0001-swiftshader-fix-build.patch 2024-12-20
ppc64le/third_party/0002-regenerate-xnn-buildgn.patch File regenerated by running 'python3 generate_build_gn.py'
Requires Bazel 8 or higher to regenerate

This causes various toolchain failures of the form:

While resolving toolchains for target @@rules_python+//python:current_py_toolchain
@@bazel_tools//tools/python:toolchain_type

===================================================================		 no
ppc64le/third_party/skia-vsx-instructions.patch =================================================================== no
ppc64le/breakpad/0001-Implement-support-for-ppc64-on-Linux.patch Implement support for ppc64 on Linux
This patch implements support for the ppc64 architecture on Linux systems.

Notable changes include:
* Modification of tests to support non-4K page sizes
* minidump_writer: Determine size of stack to capture based on page size
* dump_writer_common: Introduce member function GetVectorRegisters to
ThreadInfo on ppc64 systems. This allows Altivec/VMX registers to be
dumped like they are on OS X. linux_ptrace_dumper has been updated
to utilize this function along with the ptrace mode NT_PPC_VMX.
* processor/exploitability_unittest.cc: Tests were disabled on
non-x86 systems. They assume the system objdump is capable of
disassembling x86 binaries which is not the case on other
architectures.

To-do:
* tools/linux/md2core has been updated as well, but functionality
has not been confirmed and restoration of Altivec/VMX registers
has not been implemented

Note that proper functionality depends on updates to third_party/LSS
that introduce PPC64 support. An in-progress patch that allows
breakpad to build and run successfully is available at:
https://wiki.raptorcs.com/wiki/Porting/Chromium		 Shawn Anastasio <shawnanastasio@yahoo.com> no 2018-08-17
ppc64le/crashpad/0001-Implement-support-for-PPC64-on-Linux.patch Implement support for PPC64 on Linux
This patch implements support for the PPC64 architecture on Linux hosts.		 Shawn Anastasio <sanastasio@raptorengineering.com> no 2018-08-30
ppc64le/third_party/0001-Force-baseline-POWER8-AltiVec-VSX-CPU-features-when-.patch Force baseline POWER8 / AltiVec / VSX CPU features when on a PPC64 platform in LE mode Timothy Pearson <tpearson@raptorengineering.com> no 2018-09-21
ppc64le/fixes/fix-rustc.patch allow ppc64le to build by using proper rustc target=================================================================== Andres Salomon <dilinger@debian.org> no
ppc64le/fixes/fix-rust-linking.patch =================================================================== no
ppc64le/fixes/fix-breakpad-compile.patch =================================================================== no
ppc64le/fixes/fix-partition-alloc-compile.patch ===================================================================
===================================================================		 no
ppc64le/fixes/fix-page-allocator-overflow.patch =================================================================== no
loongarch64/0005-loong64-sandbox-sandbox-linux-bpf_dsl-Update-syscall.patch loong64: sandbox: sandbox/linux/bpf_dsl: Update syscall ranges for loongarch64 Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-05-30
ppc64le/fixes/fix-different-data-layouts.patch When building Chromium on unstable/ppc64el with ThinLTO enabled, this error
occurs in the final link:

ld.lld-16: error: Linking two modules of different data layouts:
$C_CXX_OBJECT is 'e-m:e-i64:64-n32:64-S128-v256:256:256-v512:512:512' whereas
$RUST_LIBRARY is 'e-m:e-Fn32-i64:64-n32:64-S128-v256:256:256-v512:512:512'

This is because the LLVM data layout for powerpc64le-unknown-linux-gnu has
evolved over time, gaining the "Fn32" bit that specifies function pointer
alignment. See the following source locations:

llvm-project/clang/lib/Basic/Targets/PPC.h
(class PPC64TargetInfo, under "Triple.getArch() == llvm::Triple::ppc64le")

rust/compiler/rustc_target/src/spec/powerpc64le_unknown_linux_gnu.rs
(note that this file was relocated in a later version)

This change occurred in clang-17, and rustc followed suit in 1.73.0. Since
we use an older clang and a newer rustc in our unstable build, we get an
inconsistency in data layouts when targeting this particular platform.

The error reported by the linker is not technically an error, however, only
a warning goosed up by a --fatal-warnings flag.

===================================================================		 Daniel Richard G. <skunk@iSKUNK.ORG> no
ppc64le/v8/0001-Enable-ppc64-pointer-compression.patch =================================================================== no
ppc64le/v8/0002-Add-ppc64-trap-instructions.patch =================================================================== no
ppc64le/third_party/dawn-fix-ppc64le-detection.patch =================================================================== no
ppc64le/third_party/0005-blink-add-audio-vector-support.patch =================================================================== no
ppc64le/core/add-ppc64-architecture-string.patch =================================================================== no
ppc64le/core/add-ppc64-pthread-stack-size.patch =================================================================== no
ppc64le/fixes/fix-study-crash.patch =================================================================== no
ppc64le/core/add-ppc64-architecture-to-extensions.diff =================================================================== no
ppc64le/fixes/fix-unknown-warning-option-messages.diff =================================================================== no
loongarch64/0001-loong64-core-add-loong64-architecture-to-extensions.patch loong64: core: add loong64 architecture to extensions Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-05-30
loongarch64/0002-loong64-sandbox-Enable-seccomp_bpf-for-loongarch64.patch loong64: sandbox: Enable seccomp_bpf for loongarch64 Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-05-30
loongarch64/0003-sandbox-linux-Implement-support-for-loong64-syscalls.patch sandbox/linux: Implement support for loong64 syscalls Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-05-30
loongarch64/0004-loong64-sandbox-sandbox-linux-Update-syscall-helpers.patch loong64: sandbox: sandbox/linux: Update syscall helpers lists for loongarch64 Jianfeng Liu <liujianfeng1994@gmail.com> no 2025-05-30

All known versions for source package 'chromium'

Links