Debian Patches

Status for chromium/140.0.7339.80-1

Patch Description Author Forwarded Bugs Origin Last update
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
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/strlcpy.patch fixes https://bugs.debian.org/1066235 Andres Salomon <dilinger@debian.org> 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/libsync-rk3588-panthor.patch thirdparty: fix libsync for rk3588 panthor gpu driver
Chromium will crash with panthor gpu driver on rk3588 when running with
ozone wayland. There is a bug reported upstream:

https://issues.chromium.org/issues/343592370

I find the fix from an upstream commit:

https://chromium.googlesource.com/aosp/platform/system/core/libsync/+/941fe299d072723ddd475c173fe122a4f97b8cdf%5E%21/

diff --git a/third_party/libsync/src/sync.c b/third_party/libsync/src/sync.c
index 9ed03dba88..0e9ad43822 100644		 Jianfeng Liu <liujianfeng1994@gmail.com> no
fixes/headless-gn.patch don't hardcode gn path
When building headless_shell, don't use the bundled gn binary; instead
use the gn debian system binary.		 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
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/android.patch disable dependency on chrome/android Michael Gilbert <mgilbert@debian.org> no
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/widevine-cdm-cu.patch Disable Widevine CDM component updater Michel Le Bihan <michel@lebihan.pl> no
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
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
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
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
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
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/bindgen.patch fix bindgen-related stuff
Two separate but related fixes:

Crabbyav1f is calling bindgen features which are not currently in
bookworm or sid; --allowlist-item was added in bindgen 0.68. As far
as I can tell the build.rs stuff calls allowlist_item from there as
well, so these arguments may just be redundant? Hopefully I'm not
breaking stuff.. Drop this for sid once bindgen gets upgraded.


Also, the call to bindgen sets the path for libclang to
rust_bindgen_root, which is wrong. We're already passing
clang_base_path with the path to libclang, there's no reason that
we'd expect libclang to be in the same directory as bindgen. That
fix should probably go upstream.		 Andres Salomon <dilinger@debian.org> no
bookworm/clang19.patch no
bookworm/gn-allowlist.patch Newer gn added a synonym for whitelist; but our older gn doesn't support
it.		 Andres Salomon <dilinger@debian.org> 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-privacy-sandbox.patch disable Privacy Sandbox completely
https://github.com/ungoogled-software/ungoogled-chromium/blob/master/patches/core/ungoogled-chromium/disable-privacy-sandbox.patch		 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/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-Properly-generate-gni-on-ppc64.patch [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 [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/0001-third-party-hwy-wrong-include.patch =================================================================== no
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
ppc64le/workarounds/HACK-debian-clang-disable-pa-musttail.patch =================================================================== no
ppc64le/libaom/0001-Add-ppc64-target-to-libaom.patch [PATCH] Add ppc64 target to libaom Shawn Anastasio <shawnanastasio@gmail.com> no 2019-03-10
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 =================================================================== no
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
ppc64le/third_party/0002-regenerate-xnn-buildgn.patch File regenerated by running 'python3 generate_build_gn.py'

===================================================================		 no
ppc64le/third_party/skia-vsx-instructions.patch =================================================================== no
ppc64le/breakpad/0001-Implement-support-for-ppc64-on-Linux.patch [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 [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 [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-clang-selection.patch =================================================================== no
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
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/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

All known versions for source package 'chromium'

Links