Bug#995212: ungoogled-chromium? [
❦ 14 December 2021 09:13 GMT, Jeff Blake: > 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]. Unfortunately, packages are not allowed to fetch external stuff during build. You'll need to vendor clang, either directly in the source tarball or as an additional tarball. I just cite this part, but I agree with everything else you said. > 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. The situation didn't change that much. When a maintainer is inactive, it is always a bit difficult to know how to move forward. The issue has now gotten a bit more light, but it is still unclear on how to proceed. I don't think we had a similar case in the past (pretty popular package, totally unable to push security fixes). It is a pity the package got an exception to go in Bullseye while it was pretty clear we would get into this situation. -- As flies to wanton boys are we to the gods; they kill us for their sport. -- Shakespeare, "King Lear"
Bug#995212: ungoogled-chromium? [was: Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)]
On Wed, 15 Dec 2021 21:08:28 +0100 Stephen Kitt wrote: > Hi Jeff, > > On Tue, 14 Dec 2021 09:13:42 +, Jeff Blake wrote: > [...] > > 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. > > convertutf at least is required for licensing reasons — it replaces code > which is stripped from the upstream tarball because it’s not DFSG-free. See > https://lintian.debian.org/tags/license-problem-convert-utf-code for details. > > Regards, > > Stephen Hi Stephen, That's a good point, however upstream Chromium currently requires version 69 of icu which only exists in Debian Experimental (via icu70). Stable and Unstable both have icu67 available. I'm not sure what the solution would be. I suppose patching chromium to work with icu67, trying to get icu69/70 into unstable (and backporting this to stable/dropping chromium from stable) or even moving chromium to non-free would be among the options. Best wishes, Jeff
Bug#995212: ungoogled-chromium? [was: Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)]
Hi Jeff, On Tue, 14 Dec 2021 09:13:42 +, Jeff Blake wrote: [...] > 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. convertutf at least is required for licensing reasons — it replaces code which is stripped from the upstream tarball because it’s not DFSG-free. See https://lintian.debian.org/tags/license-problem-convert-utf-code for details. Regards, Stephen pgpjqbqVKwhVK.pgp Description: OpenPGP digital signature
Bug#995212: ungoogled-chromium? [was: Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)]
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
Bug#995212: ungoogled-chromium? [was: Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)]
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