On Tue, 7 Dec 2021 19:43:10 +0100 Tomas Pospisek wrote:
> On 06.12.21 20:43, Noah Meyerhans wrote:
> > On Sun, Dec 05, 2021 at 07:58:17PM +0300, Dmitry Alexandrov wrote:
> So what's happening with chromium in both sid and stable? I saw on
> d-release that it was removed from testing (#998676 and #998732), with a
> discussion about ending security support for it in stable.
> >>>
> >>> The problem really is lack of maintenance. In my opinion, chromium
> >>> deserves an active *team* to support it in Debian. <...> The security
> >>> team doesn't have the bandwidth to do it themselves, they need a team to
> >>> help them.
> >>
> >> Sorry for a silly question, but whatʼs so wrong with the build done by
> >> linuxmint.com [1], so Debian needs a whole team to duplicate their effort?
> >> Itʼs for Debian 10 (i. e. oldstable) as of now, but works fine at Sid in
> >> my (limited) experience.
> >>
> >
> > Well, you can start with the fact that the Mint chromium source packages
> > don't even include the chromium source, let alone the sources for all
> > the other things they build (NodeJS, and more).
> >
> > The biggest difficulty, as far as I can tell from my look at Chromium
> > from several months ago, is that our patch set [1] needs a lot of
> > attention with every chromium release. Mint doesn't apply any patches
> > at all to the source, at least none of any real complexity.
> >
> > One lesson we may take from Mint, though, is that it's not worth trying
> > to patch Chromium as much as we'd like. Anything that we can do to
> > simplify the Chromium packaging will help us keep the package
> > up-to-date, which in turn will help us keep our users safer. In my
> > opinion, we should be pretty aggressive about dropping as many of the
> > Chromium patches as possible, even if that means we link against
> > bundled/vendored dependencies.
> >
> > Legal/licensing considerations are still important and I don't know if
> > we actually *can* ship builds based on the bundled stuff. But based on
> > the number of patches we have to disable various things [2] or build
> > against system dependencies [3], I can't help but think we'd have an
> > easier time keeping this package fresh if we could drop some of those.
> >
> > noah
> >
> > 1.
> > https://salsa.debian.org/chromium-team/chromium/-/blob/master/debian/patches/series
> > 2.
> > https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/disable
> > 3.
> > https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/system
>
> I'd also like to point out, that the ungoogled-chromium project has some
> overlap in goals with Debian and it'd possibly be interessing to join
> forces:
>
> https://github.com/ungoogled-software/ungoogled-chromium-debian
>
> (I have been running an ungoogled-chromium for a while (ca. a year
> ago?), however at that time their chrome wasn't extremely stable so I
> gave up again. Does anybody have experience using it recently?)
> *t
>
>
>
I have recently forked the debian version of ungoogled chromium [1] [2] [3] to
(amongst other reasons) re-incorporate many of the previous debian patches and
features [4].
I haven't had any of the major problems which have blocked the main upstream
version of it
over the last couple of release, and the latest chromium version builds and
runs on both
unstable and stable.
Most of the debian patches aren't too much bother to update, and are mainly
context changes.
Many of them seem worth having, but several are problematic, and if anyone
wants to make
maintenance easier then the low hanging fruit to delete for enhanced
maintainability is as
follows.
## Plainly not a good idea
debianization/optimization.patch
system/use-desktop-gl-as-default.patch
## Too complex or not worth the trouble to maintain
fixes/inspector.patch
fixes/widevine-revision.patch
system/convertutf.patch
## GCC specific
fixes/gnu-as.patch
warnings/int-in-bool-context.patch
warnings/stringop-overflow.patch
# System lib replacements which are too changeable and/or incompatible between
stable/unstable
bullseye/ffmpeg.patch
bullseye/icu-types.patch
system/clang-format.patch
system/ffmpeg.patch
system/harfbuzz.patch
Upstream is better placed to judge optimisation levels per build target, and
all you'll
achieve with a flat '-O2 everywhere' is a slower binary. With upstream bundled
clang
(discussed below) dpkg buildflags doesn't appear to be picked up by the build
system anyway.
The desktop gl patch is questionable since it can be set as a runtime flag in
the existing
debian/etc/default-flags file.
Inspector and convertutf are the worst offenders in terms of being unnecessary
and complex.
The disable/catapult.patch could also be dropped, since profiling might be
desirable to some
users.
Using gcc to build chromium was dropped by debian ages ago and is not supported
upstream, so
I don't see the point in patching gcc-related build
