On Tue, 7 Dec 2021 19:43:10 +0100 Tomas Pospisek <t...@sourcepole.ch> 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 issues. Regarding system library replacement, note that debian's libpng has a rendering bug when viewing animated png files [5], so the bundled version ought to be used instead. Also, debian's libvpx is often too old to be unbundled and/or requires extra patches. Unless there are licensing or technical objections, I would suggest building with upstream bundled clang to avoid all sorts of incompatibilities and obviate the need for extra patching (stable's clang is often too old and upstream currently uses clang-14 vs unstable's 13). As an added bonus, this is a prerequisite to, and allows building with PGO enabled. Refer to my rules file to see how download of upstream clang/llvm binaries can be automated [6]. A list of patches which could be considered for deletion is at the end [7], with quite a few having been fixed upstream. In terms of maintenance. Other distro/packager repos are useful when it comes to fixing build errors and major bugs. A list is provided at the end [8]. I've been building ungoogled-chromium-debian for a few years now, and hope the above helps anyone who wants to restart debian chromium releases. Finally, it's good to see some of the maintainability issues being discussed, as when debian chromium development was restarted a year or so ago, I became frustrated when my questions on the issue went unanswered. So many patches seemed to be superfluous, yet nobody seemed to have the motivation, authority or courage to delete them. [1] - https://github.com/ungoogled-software/ungoogled-chromium-debian [2] - https://github.com/berkley4/ungoogled-chromium-debian/tree/unified_pgo_hardened [3] - https://github.com/Eloston/ungoogled-chromium [4] - https://salsa.debian.org/mimi89999/chromium (Michel Le Bihan's unreleased v94) [5] - https://github.com/ungoogled-software/ungoogled-chromium-debian/issues/169 [6] - https://github.com/berkley4/ungoogled-chromium-debian/blob/unified_pgo_hardened/debian/rules [7] :- bullseye/ffmpeg.patch bullseye/icu-types.patch debianization/explicit-python2.patch debianization/optimization.patch disable/chromeos.patch disable/google-api-warning.patch disable/ios.patch fixes/chromeos_devicetype.patch fixes/closure.patch fixes/connection-message.patch fixes/gnu-as.patch fixes/inspector.patch fixes/widevine-revision.patch gn/explicit-python2.patch gn/parallel.patch system/clang-format.patch system/convertutf.patch system/ffmpeg.patch system/harfbuzz.patch system/use-desktop-gl-as-default.patch warnings/gcc-diagnostic.patch warnings/int-in-bool-context.patch warnings/stringop-overflow.patch warnings/unused-but.patch [8] :- https://github.com/archlinux/svntogit-packages/tree/packages/chromium/trunk https://src.fedoraproject.org/rpms/chromium/tree/rawhide https://gitweb.gentoo.org/repo/gentoo.git/tree/www-client/chromium/files https://github.com/PF4Public/gentoo-overlay/tree/master/www-client/ungoogled-chromium/files https://github.com/stha09/chromium-patches
