Debian Patches

Status for chromium/131.0.6778.204-1~deb12u1

Patch Description Author Forwarded Bugs Origin Last update
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/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
ppc64le/third_party/0001-Add-PPC64-support-for-boringssl.patch =================================================================== no
ppc64le/fixes/fix-study-crash.patch =================================================================== no
ppc64le/core/add-ppc64-architecture-to-extensions.diff =================================================================== no
ppc64le/core/cargo-add-ppc64.diff =================================================================== no
ppc64le/fixes/fix-unknown-warning-option-messages.diff =================================================================== 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-lss-Don-t-look-for-mmap2-on-ppc64.patch =================================================================== no
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/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-skia-musttail.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
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
fixes/ps-print.patch add postscript (ps) printing capability Salvatore Bonaccorso no
fixes/widevine-revision.patch set widevine version as undefined Michael Gilbert <mgilbert@debian.org> 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
ppc64le/third_party/skia-vsx-instructions.patch =================================================================== 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/perfetto.patch More simple build fixes needed by libstdc++-dev 13 Andres Salomon <dilinger@debian.org> no
fixes/strlcpy.patch fixes https://bugs.debian.org/1066235 Andres Salomon <dilinger@debian.org> no
fixes/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
fixes/memory-allocator-dcheck-assert-fix.patch =================================================================== no
fixes/clang-rust-target.patch On amd64, Clang defaults to generating x86_64-pc-linux-gnu, while Rust
generates x86_64-unknown-linux-gnu. When ThinLTO is enabled, this leads
to link errors of the form

ld.lld-16: error: Linking two modules of different target triples:
$C_CXX_OBJECT is 'x86_64-pc-linux-gnu' whereas $RUST_OBJECT is
'x86_64-unknown-linux-gnu'
Daniel Richard G. <skunk@iSKUNK.ORG> no
fixes/highway-include-path.patch Fix an #include path so we can use our packaged version of libhwy-dev.

Reported upstream at https://issues.chromium.org/357975577



Oops, and upstream broke stuff further by "fixing" the header
issue with a private .gni:

ERROR at //third_party/highway/BUILD.gn:3:1: Unable to load "/chromium-128.0.6613.36/third_party/highway/src/hwy.gni".
import("src/hwy.gni")
^-------------------
See //third_party/distributed_point_functions/BUILD.gn:71:5: which caused the file to be included.
"$dpf_highway_cpp_dir:libhwy",
^----------------------------
make[1]: *** [debian/rules:170: override_dh_auto_build-arch] Error 1
no
fixes/gpu-crash.patch =================================================================== no
fixes/predictor-denial-of-service.patch no
fixes/fix-assert-in-vnc-sessions.patch no
ppc64le/third_party/use-sysconf-page-size-on-ppc64.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/freetype.patch Upstream added an enable_freetype arg (744782efe9622b4), but only
declares it for the bundled freetype. When building against the
system's freetype, we get errors about enable_freetype being undeclared.
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/absl-optional.patch work around a clang bug with libstdc++ (bookworm version)
Chromium 119 used absl's 'optional' implementation. Chromium 120 switched to
aliasing absl::optional to std::optional. In theory that should be all fine
and good, except for the fact that there's a bug in clang:

https://github.com/llvm/llvm-project/issues/50248

This bug is worked around in libc++, but not in libstdc++. There's (so far)
two types of errors we hit. The first is specifically with
absl::optional::emplace() -

>> gen/ui/gfx/x/randr.cc:482:13: error: no matching member function for call to 'emplace'
>> data.lc.emplace();
>> ~~~~~~~~^~~~~~~
>> /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/optional:914:2: note: candidate template ignored: requirement 'is_constructible_v<x11::RandR::NotifyEvent::Lc>' was not satisfied [with _Args = <>]
>> emplace(_Args&&... __args)
>>

..and a similar error with just a few calls to absl::make_optional() -

>> ./../third_party/blink/renderer/core/loader/history_item.cc:185:19: error: no matching function for call to 'make_optional'
>> view_state_ = absl::make_optional<ViewState>();

We can't simply revert to using absl's optional implmentation, because a) they
are planning to remove it (<https://abseil.io/about/design/dropin-types>), and
b) chromium devs, having switched over and viewing absl::optional and
std::optional as aliases, play fast and loose with those namespace. We end up
playing an ever-worsening game of whack-a-mole trying to fix build errors which
are just inability to do implicit conversions.

Another option (which some other distributions have chosen to do) is to simply
switch to building against libc++. However, that means bundling a bunch more
libraries that build statically against libc++. That's undesirable.

This patch provides the option of providing a workaround for libstdc++. Instead
of using the official libstdc++ header for optional, we provide our own with
the is_constructible assertions removed. There's no logic changes, it just
removes an assertion we _know_ is met, but the compiler too broken to know it.

I just copied over /usr/include/c++/12/optional, and changed a few of the
functions (where you see an '#if 0' commenting out the original function).
We'll need to update this patch with major libstdc++ upgrades.

hitting with gcc 12 and gcc 14:

../../optional:477: _Tp &std::_Optional_base_impl<content::DocumentAssociatedData, std::_Optional_base<content::DocumentAssociatedData>>::_M_get() [_Tp = content::DocumentAssociatedData, _Dp = std::_Optional_base<content::DocumentAssociatedData>]: Assertion 'this->_M_is_engaged()' failed.
[1218/170223.662125:ERROR:elf_dynamic_array_reader.h(64)] tag not found
Aborted
Andres Salomon <dilinger@debian.org> no
fixes/font-gc-asan.patch This is a workaround for the various issues around fonts being garbage
collected instead of manually refcounted and freed. Crashes show up when
using gcc's libstdc++ but not with llvm's libc++, because apparently
llvm's libc++ doesn't care if string destructors are called on invalid
strings. But gcc's libstdc++ does, as does upstream's ASAN builds (which
manually track/validate memory usage). So upstream created this ASAN
workaround - however, GCC needs it also.

This should go upstream, but in a form that selects for GCC and
clang with libstdc++.

Also, TODO: check if that DCHECK() is actually doing something useful
on ASAN builds, or if it's optimized away and/or calling has_value() is
actually truly a sanity check.

upstream ASAN fixes: https://chromium-review.googlesource.com/c/chromium/src/+/5629253
Andres Salomon <dilinger@queued.net> no
upstream/mojo.patch copy of missing files in content/test/data, taken from upstream git
This is just
cp chromium-git/content/test/data/*{html,mojom,js,ts} \
chromium-debian/content/test/data/

Upstream bug report about the missing files:
https://bugs.chromium.org/p/chromium/issues/detail?id=1293630
I'm not sure how much of them are actually needed, but it's easier to
just copy all of them for now. Hopefully this will be fixed upstream
shortly.

This copy is from chromium 130.
no
upstream/ruy-include.patch commit 587c2cf8b11d3c32fa26887063eda3171a3d353e

IWYU: add string for std::string

diff --git a/third_party/ruy/src/ruy/profiler/instrumentation.h b/third_party/ruy/src/ruy/profiler/instrumentation.h
index c4df1e6..2b15ae3 100644
Stephan Hartmann <stha09@googlemail.com> no 2023-03-31
upstream/blink-fix-size-assertions.patch =================================================================== no
ppc64le/third_party/dawn-fix-ppc64le-detection.patch =================================================================== no
upstream/dawn-strlen.patch commit 3ff08caa35db539fcc3dded353ec03c9f6a6efe7

StringViewUtils.cpp: Add include for std::strlen.

Bug: 42241188
Change-Id: I8950589cb51987d385d179b05655caeabf9462a6
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/210755
Reviewed-by: Loko Kung <lokokung@google.com>
Commit-Queue: Loko Kung <lokokung@google.com>
Corentin Wallez <cwallez@chromium.org> no 2024-10-14
upstream/ink-isfinite.patch commit 047055e64ec01205365d0b1357bc2b00c547eb93

Add namespace for usage of std::isfinite

libstdc++ implementation of cmath do not provide isfinite without
namespace.

Bug: chromium:41455655

diff --git a/third_party/ink/src/ink/brush/brush_paint.cc b/third_party/ink/src/ink/brush/brush_paint.cc
index 8c71a5c..b9078a5 100644
Jose Dapena Paz <jdapena@igalia.com> no 2024-09-30
upstream/webrtc-optional.patch In file included from ../../third_party/webrtc/api/crypto/crypto_options.cc:16:
../../third_party/webrtc/rtc_base/ssl_stream_adapter.h:190:16: error: no template named 'optional' in namespace 'std'
190 | virtual std::optional<absl::string_view> GetTlsCipherSuiteName() const = 0;
| ~~~~~^
1 error generated.

Fixed upstream (webrtc) as part of a larger commit:
commit 4060745995b8d054584969c7f55a6ef57da0a54d

spanify SSLStreamAdapter::SetPeerCertificateDigest

BUG=webrtc:357776213
Philipp Hancke <phancke@meta.com> no 2024-11-26
upstream/variant.patch In file included from ../../chrome/browser/browsing_data/chrome_browsing_data_lifetime_manager.cc:37:
In file included from ../../components/sync/service/sync_service.h:20:
../../components/sync/service/local_data_description.h:28:18: error: no template named 'variant' in namespace 'std'; did you mean 'absl::variant'?
28 | using DataId = std::variant<
| ^~~~~~~~~~~~
| absl::variant
../../third_party/abseil-cpp/absl/types/variant.h:123:7: note: 'absl::variant' declared here
123 | class variant;
| ^
1 error generated.

Fixed by three commits:

commit 33af9dc7d2801995990d1bb36ef1d98e3f80ca18

IWYU: Add missing include for std::variant usage in local_data_description.h

In the CL https://crrev.com/c/5934368 used std::variant in the
components/sync/service/local_data_description.h, but required
include was missed. Added missing include for std::variant usage.

Bug: 41455655
Change-Id: If67c513d3b9b89775afb2e36a9913ea67a284e0c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6028535
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Commit-Queue: Ivan Murashov <ivan.murashov@lge.com>
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1384535}

commit 8fa8d8f68f5bf71e70038994276e0225f006eb73

IWYU: missing include for usage of std::variant in saved_tab_groups/public/types.h

Bug: 41455655
Change-Id: Ic4fdb5baeda2e4be3c35c976dfa6dfd396a60643
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5899087
Reviewed-by: Shakti Sahu <shaktisahu@chromium.org>
Commit-Queue: Shakti Sahu <shaktisahu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1369048}

commit 1f9a4db9f8f0d8b1561a6e264d2d88f064f19fbc

IWYU: missing include for usage of std::variant in bookmark_merged_surface_service.h

Bug: 41455655
Change-Id: I00b251c7dc4a35a9bf7fd023fd35a9051c7a715c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5935116
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: José Dapena Paz <jdapena@igalia.com>
Cr-Commit-Position: refs/heads/main@{#1369030}
Jose Dapena Paz <jdapena@igalia.com> no 2024-10-15
upstream/array.patch ../../components/sync/base/unique_position.h:48:23: error: no template named 'array' in namespace 'std'
48 | using Suffix = std::array<uint8_t, kSuffixLength>;
| ~~~~~^


commit ee90b98ddd370e7adc35a4892c84be21d4ae813b

IWYU: Add missing include for std::array usage in unique_position.h

In the CL https://crrev.com/c/5899059 used std::array in the
components/sync/base/unique_position.h, but required include was missed.
Added missing include for std::array usage.

Bug: 41455655
Change-Id: I0c2a95cf087867d73b81b2028ee04027f2653c34
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6020662
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Commit-Queue: Ivan Murashov <ivan.murashov@lge.com>
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1384538}
Ivan Murashov <ivan.murashov@lge.com> no 2024-11-18
upstream/mrc-copy-op.patch commit 78c316b83ca926f250935198d43ad37d20069115

Fix MatchingReusedCredential copy operator.

It was wrongly declared without const.

Bug: 41455655
Change-Id: I7014fc7b1e4ffdc54b2232044540b8f0fc10a3d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5934460
Commit-Queue: José Dapena Paz <jdapena@igalia.com>
Reviewed-by: Ioana Pandele <ioanap@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1369261}

diff --git a/components/password_manager/core/browser/password_reuse_detector.cc b/components/password_manager/core/browser/password_reuse_detector.cc
index fbb8bce4fad45..6ed2427047d8f 100644
Jose Dapena Paz <jdapena@igalia.com> no 2024-10-16
disable/tests.patch 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
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/event.patch use system libevent Michael Gilbert <mgilbert@debian.org> no
system/openjpeg.patch no
system/opus.patch no
system/eu-strip.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 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
bookworm/libxml-parseerr.patch ../../third_party/blink/renderer/core/xml/xsl_style_sheet_libxslt.cc:125:26: error: no matching constructor for initialization of 'XMLDocumentParserScope'
XMLDocumentParserScope scope(OwnerDocument(), XSLTProcessor::GenericErrorFunc,
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../third_party/blink/renderer/core/xml/parser/xml_document_parser_scope.h:41:3: note: candidate constructor not viable: no known conversion from 'void (void *, const xmlError *)' (aka 'void (void *, const _xmlError *)') to 'xmlStructuredErrorFunc' (aka 'void (*)(void *, _xmlError *)') for 3rd argument
XMLDocumentParserScope(Document*,
^
../../third_party/blink/renderer/core/xml/parser/xml_document_parser_scope.h:40:12: note: candidate constructor not viable: requires 1 argument, but 4 were provided
explicit XMLDocumentParserScope(Document*);
^


libxml 2.12 changed the API slightly. This maintains compatibility with
libxml 2.9.
Andres Salomon <dilinger@debian.org> no
bookworm/freetype-COLRV1.patch Freetype 2.12 wasn't supposed to have COLRV1 enabled, but it was enabled
in bookworm. Then the maintainer issued a stable update to disable it,
which caused chromium to crash because we're actually using it. But
apparently we're not supposed to be, so drop this version check and always
disable COLRV1. This patch is only appropriate for bookworm.

See https://bugs.debian.org/1052455 for the description about freetype 2.12
having a broken COLRV1.
Andres Salomon <dilinger@debian.org> no
bookworm/gn-funcs.patch filter_labels_{include,exclude} was added to gn in Feb 2024
(https://gn.googlesource.com/gn/+/e05c0aa00938adc0797bda1e8f2c15675aa13c30%5E%21/),
so obviously bookworm's gn doesn't have it.

The old webrtc code just hardcoded abseil-cpp:absl if building
with chromium, which is simple enough..
Andres Salomon <dilinger@debian.org> no
bookworm/gn-absl.patch ERROR at //build/config/BUILDCONFIG.gn:533:5: Dependency not allowed.
target(_target_type, target_name) {
^----------------------------------
The item //third_party/webrtc/pc:media_protocol_names
can not depend on //third_party/abseil-cpp/absl/strings:string_view
because it is not in //third_party/abseil-cpp/absl/strings:string_view's visibility list: [
//third_party/abseil-cpp/*
//third_party/googletest/*
//third_party/webrtc/rtc_tools:frame_analyzer
//third_party/webrtc/rtc_tools:rtp_generator
//third_party/webrtc/rtc_tools:video_replay
//chromecast/internal/*
//libassistant/*
//components/optimization_guide/internal/*
]


Absl used to have absl_deps, but that got removed with:
commit 99c519b3fdac0cbedaecead04a841e89a5f0f69b

Mass removal of absl_deps in all BUILD.gn files

Newer gn is fine with s/absl_deps/deps/, but bookworm's gn
requires manually changing the visibility of all the absl
libs.
Florent Castelli <orphis@webrtc.org> no 2024-05-23
bookworm/highway-blink.patch The Blink code for vectorized HTML scanning requires at least highway
(i.e. libhwy-dev) version 1.2.0, or else the armhf + arm64 builds fail
with multiple errors like

../../third_party/blink/renderer/core/html/parser/html_document_parser_fastpath.cc:762:13: error: no member named 'Dup128VecFromValues' in namespace 'hwy::N_NEON_WITHOUT_AES'
hw::Dup128VecFromValues(tag, 0b0001, 0, 0, 0, 0, 0, 0b0100, 0, 0, 0, 0,
~~~~^
Daniel Richard G. <skunk@iSKUNK.ORG> no
bookworm/partially-deployed-mseal-syscall.patch =================================================================== no
bookworm/constexpr.patch ../../services/network/shared_dictionary/simple_url_pattern_matcher.cc:31:34: error: constexpr variable 'kDefaultOptions' must be initialized by a constant expression
31 | constexpr liburlpattern::Options kDefaultOptions = {.delimiter_list = "",
| ^ ~~~~~~~~~~~~~~~~~~~~~~
32 | .prefix_list = "",
| ~~~~~~~~~~~~~~~~~~
33 | .sensitive = true,
| ~~~~~~~~~~~~~~~~~~
34 | .strict = true};
| ~~~~~~~~~~~~~~~
Andres Salomon <dilinger@debian.org> no
ppc64le/core/add-ppc64-architecture-string.patch =================================================================== no
bookworm/constexpr2.patch same kind of clang/gcc constexpr workaround, except this location is trickier
Clang with gcc-12's libstdc++ can't handle constexpr std::strings; normally we can just make
them const. Because this is inside of a class declaration, it's a bit
more challenging. Use a C-style const char* instead, defaulting to "" and
can be overridden during the constexpr DisplayParams definition.

In file included from ../../ui/display/linux/test/virtual_display_util_linux.cc:5:
In file included from ../../ui/display/linux/test/virtual_display_util_linux.h:12:
../../ui/display/test/virtual_display_util.h:63:34: error: constexpr variable 'k1920x1080' must be initialized by a constant expression
static constexpr DisplayParams k1920x1080 = {gfx::Size(1920, 1080)};
^ ~~~~~~~~~~~~~~~~~~~~~~~
../../ui/display/test/virtual_display_util.h:63:34: note: pointer to subobject of heap-allocated object is not a constant expression
/usr/bin/../include/c++/v1/__memory/allocator.h:113:38: note: heap allocation performed here
return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
^
Andres Salomon <dilinger@debian.org> no
bookworm/bubble-contents.patch In file included from ../../chrome/browser/ui/commerce/commerce_ui_tab_helper.cc:28:
In file included from ../../chrome/browser/ui/views/side_panel/side_panel_web_ui_view.h:12:
../../chrome/browser/ui/views/bubble/bubble_contents_wrapper.h:153:9: error: static assertion expression is not an integral constant expression
views_metrics::IsValidWebUINameVariant("." + T::GetWebUIName()));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/unique_ptr.h:1065:34: note: in instantiation of member function 'BubbleContentsWrapperT<ShoppingInsightsSidePanelUI>::BubbleContentsWrapperT' requested here
{ return unique_ptr<_Tp>(new _Tp(std::forward<_Args>(__args)...)); }
^
../../chrome/browser/ui/commerce/commerce_ui_tab_helper.cc:458:16: note: in instantiation of function template specialization 'std::make_unique<BubbleContentsWrapperT<ShoppingInsightsSidePanelUI>, GURL, Profile *, int, bool, bool>' requested here
std::make_unique<BubbleContentsWrapperT<ShoppingInsightsSidePanelUI>>(
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/stl_construct.h:97:14: note: construction of subobject of member '_M_local_buf' of union with active member '_M_allocated_capacity' is not allowed in a constant expression
{ return ::new((void*)__location) _Tp(std::forward<_Args>(__args)...); }
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/char_traits.h:351:4: note: in call to 'construct_at(&ShoppingInsightsSidePanelUI::GetWebUIName().._M_local_buf[0], char())'
std::construct_at(__builtin_addressof(__c1), __c2);
^
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-linux-seccomp-bpf-ppc64-glibc-workaround-in-SIGSYS-h.patch [PATCH] linux/seccomp-bpf: ppc64+glibc workaround in SIGSYS handler
Workaround for an apparent issue with glibc negating syscall
parameters. Observed on a ppc64le machine with glibc.
More investigation required.
Shawn Anastasio <shawn@anastas.io> no 2019-01-15
ppc64le/sandbox/0001-sandbox-Enable-seccomp_bpf-for-ppc64.patch [PATCH 1/1] sandbox: Enable seccomp_bpf for ppc64 Shawn Anastasio <shawnanastasio@yahoo.com> no 2018-08-09
ppc64le/sandbox/0001-services-service_manager-sandbox-linux-Fix-TCGETS-de.patch [PATCH] services/service_manager/sandbox/linux: Fix TCGETS declaration on PPC64 Shawn Anastasio <shawnanastasio@yahoo.com> no 2018-08-10
ppc64le/sandbox/0001-sandbox-linux-bpf_dsl-Update-syscall-ranges-for-ppc6.patch [PATCH 1/4] sandbox/linux/bpf_dsl: Update syscall ranges for ppc64 Shawn Anastasio <shawnanastasio@yahoo.com> no 2018-08-09
ppc64le/core/add-ppc64-pthread-stack-size.patch =================================================================== no
ppc64le/sandbox/0001-sandbox-linux-Implement-partial-support-for-ppc64-sy.patch [PATCH] sandbox/linux: Implement partial support for ppc64 syscalls and ucontext

Unlike other architectures, the ppc64 files currently rely on applicable
headers being provided by the system. It is sufficient for standard
GNU/Linux environments, but may require expansion elsewhere.
Shawn Anastasio <shawnanastasio@yahoo.com> no 2018-08-09
ppc64le/sandbox/0001-sandbox-linux-Update-IsSyscallAllowed-in-broker_proc.patch [PATCH] sandbox/linux: Update IsSyscallAllowed in broker_process.cc Shawn Anastasio <shawnanastasio@yahoo.com> no 2018-10-23
ppc64le/sandbox/0001-sandbox-linux-Update-syscall-helpers-lists-for-ppc64.patch [PATCH] sandbox/linux: Update syscall helpers/lists for ppc64 Shawn Anastasio <shawnanastasio@yahoo.com> no 2018-09-18
ppc64le/sandbox/0002-sandbox-linux-bpf_dsl-Modify-seccomp_macros-to-add-s.patch [PATCH 1/4] sandbox/linux/bpf_dsl: Modify seccomp_macros to add support for ppc64 Shawn Anastasio <shawnanastasio@yahoo.com> no 2018-08-09
ppc64le/sandbox/0003-sandbox-linux-system_headers-Update-linux-seccomp-he.patch [PATCH 3/4] sandbox/linux/system_headers: Update linux seccomp header for ppc64 Shawn Anastasio <shawnanastasio@yahoo.com> no 2018-08-09
ppc64le/sandbox/0004-sandbox-linux-system_headers-Update-linux-signal-hea.patch [PATCH 4/4] sandbox/linux/system_headers: Update linux signal header for ppc64 Shawn Anastasio <shawnanastasio@yahoo.com> no 2018-08-09
ppc64le/sandbox/0005-sandbox-linux-seccomp-bpf-Add-ppc64-syscall-stub.patch [PATCH] sandbox/linux/seccomp-bpf: Add ppc64 syscall stub Shawn Anastasio <shawnanastasio@yahoo.com> no 2018-08-09
ppc64le/sandbox/0005-sandbox-linux-update-unit-test-for-ppc64.patch [PATCH 5/6] sandbox/linux: update unit test for ppc64 Shawn Anastasio <shawnanastasio@yahoo.com> no 2018-09-13
ppc64le/sandbox/0006-sandbox-linux-disable-timedwait-time64-ppc64.patch =================================================================== no
ppc64le/sandbox/0007-sandbox-linux-add-ppc64-stat.patch =================================================================== no
ppc64le/sandbox/Sandbox-linux-services-credentials.cc-PPC.patch =================================================================== no
ppc64le/sandbox/0008-sandbox-fix-ppc64le-glibc234.patch =================================================================== no
ppc64le/third_party/0001-third_party-angle-Include-missing-header-cstddef-in-.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-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/0002-Add-ppc64-trap-instructions.patch =================================================================== no
ppc64le/sandbox/fix-ppc64-linux-syscalls-headers.patch =================================================================== no

All known versions for source package 'chromium'

Links