Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
114 views
Skip to first unread message
Sedat Dilek
Sep 27, 2021, 7:40:03 PM9/27/21
to
Package: chromium
Version: 93.0.4577.82-1
Severity: normal
X-Debbugs-Cc: sedat...@gmail.com
Dear Maintainer,
I updated my google-chrome-stable package to version 94.0.4606.61-1 on my Debian/unstable AMD64 system.
Debian's security-tracker for chromium [1] package shows several CVE security issues not fixed.
Open issues:
Bug stretch buster bullseye bookworm sid Description
CVE-2021-37973 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37972 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37971 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37970 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37969 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37968 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37967 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37966 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37965 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37964 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37963 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37962 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37961 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37960 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37959 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37958 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37957 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37956 vulnerable vulnerable vulnerable vulnerable vulnerable
For more details also see "Stable Channel Update for Desktop" at [2].
Please upgrade chromium from v93.x to v94.x.
Thanks.
Regards,
- Sedat -
[1] https://security-tracker.debian.org/tracker/source-package/chromium
[2] https://chromereleases.googleblog.com/search/label/Stable%20updates
[3] https://www.heise.de/news/Google-schliesst-19-Sicherheitsluecken-in-Chrome-6199412.html (German)
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (99, 'buildd-unstable'), (99, 'buildd-experimental'), (99, 'experimental'), (99, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.14.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages chromium depends on:
ii chromium-common 93.0.4577.82-1
ii libasound2 1.2.5.1-1
ii libatk-bridge2.0-0 2.38.0-2
ii libatk1.0-0 2.36.0-2
ii libatomic1 11.2.0-8
ii libatspi2.0-0 2.42.0-1
ii libavcodec58 7:4.4-6+b2
ii libavformat58 7:4.4-6+b2
ii libavutil56 7:4.4-6+b2
ii libc6 2.32-4
ii libcairo2 1.16.0-5
ii libcups2 2.3.3op2-7
ii libdbus-1-3 1.12.20-2
ii libdrm2 2.4.107-8
ii libevent-2.1-7 2.1.12-stable-1
ii libexpat1 2.4.1-2+b1
ii libflac8 1.3.3-2
ii libfontconfig1 2.13.1-4.2
ii libfreetype6 2.10.4+dfsg-1
ii libgbm1 21.2.2-1
ii libgcc-s1 11.2.0-8
ii libglib2.0-0 2.70.0-1+b1
ii libharfbuzz0b 2.7.4-1
ii libicu67 67.1-7
ii libjpeg62-turbo 1:2.0.6-4
ii libjsoncpp24 1.9.4-4
ii liblcms2-2 2.12~rc1-2
ii libminizip1 1.1-8+b1
ii libnspr4 2:4.32-1
ii libnss3 2:3.70-1
ii libopenjp2-7 2.4.0-3
ii libopus0 1.3.1-0.1
ii libpango-1.0-0 1.48.10+ds1-1
ii libpng16-16 1.6.37-3
ii libpulse0 15.0+dfsg1-2
ii libre2-9 20210901+dfsg-1
ii libsnappy1v5 1.1.8-1
ii libstdc++6 11.2.0-8
ii libwebp6 0.6.1-2.1
ii libwebpdemux2 0.6.1-2.1
ii libwebpmux3 0.6.1-2.1
ii libx11-6 2:1.7.2-2+b1
ii libxcb1 1.14-3
ii libxcomposite1 1:0.4.5-1
ii libxdamage1 1:1.1.5-2
ii libxext6 2:1.3.4-1
ii libxfixes3 1:5.0.3-2
ii libxml2 2.9.12+dfsg-5
ii libxrandr2 2:1.5.1-1
ii libxshmfence1 1.3-1
ii libxslt1.1 1.1.34-4
ii zlib1g 1:1.2.11.dfsg-2
Versions of packages chromium recommends:
ii chromium-sandbox 93.0.4577.82-1
Versions of packages chromium suggests:
pn chromium-driver <none>
ii chromium-l10n 93.0.4577.82-1
pn chromium-shell <none>
Versions of packages chromium-common depends on:
ii libc6 2.32-4
ii libstdc++6 11.2.0-8
ii libx11-6 2:1.7.2-2+b1
ii libxext6 2:1.3.4-1
ii x11-utils 7.7+5
ii xdg-utils 1.1.3-4.1
ii zlib1g 1:1.2.11.dfsg-2
Versions of packages chromium-common recommends:
ii chromium-sandbox 93.0.4577.82-1
ii fonts-liberation 1:1.07.4-11
ii gnome-shell [notification-daemon] 40.5-1
ii libgl1-mesa-dri 21.2.2-1
ii libu2f-udev 1.1.10-3
ii notification-daemon 3.20.0-4+b1
ii plasma-workspace [notification-daemon] 4:5.22.90-1~np2
ii system-config-printer 1.5.14-1
ii upower 0.99.13-1
Versions of packages chromium-sandbox depends on:
ii libc6 2.32-4
-- Configuration Files:
/etc/chromium.d/default-flags changed [not included]
-- no debconf information
Version: 93.0.4577.82-1
Severity: normal
X-Debbugs-Cc: sedat...@gmail.com
Dear Maintainer,
I updated my google-chrome-stable package to version 94.0.4606.61-1 on my Debian/unstable AMD64 system.
Debian's security-tracker for chromium [1] package shows several CVE security issues not fixed.
Open issues:
Bug stretch buster bullseye bookworm sid Description
CVE-2021-37973 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37972 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37971 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37970 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37969 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37968 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37967 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37966 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37965 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37964 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37963 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37962 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37961 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37960 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37959 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37958 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37957 vulnerable vulnerable vulnerable vulnerable vulnerable
CVE-2021-37956 vulnerable vulnerable vulnerable vulnerable vulnerable
For more details also see "Stable Channel Update for Desktop" at [2].
Please upgrade chromium from v93.x to v94.x.
Thanks.
Regards,
- Sedat -
[1] https://security-tracker.debian.org/tracker/source-package/chromium
[2] https://chromereleases.googleblog.com/search/label/Stable%20updates
[3] https://www.heise.de/news/Google-schliesst-19-Sicherheitsluecken-in-Chrome-6199412.html (German)
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (99, 'buildd-unstable'), (99, 'buildd-experimental'), (99, 'experimental'), (99, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.14.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages chromium depends on:
ii chromium-common 93.0.4577.82-1
ii libasound2 1.2.5.1-1
ii libatk-bridge2.0-0 2.38.0-2
ii libatk1.0-0 2.36.0-2
ii libatomic1 11.2.0-8
ii libatspi2.0-0 2.42.0-1
ii libavcodec58 7:4.4-6+b2
ii libavformat58 7:4.4-6+b2
ii libavutil56 7:4.4-6+b2
ii libc6 2.32-4
ii libcairo2 1.16.0-5
ii libcups2 2.3.3op2-7
ii libdbus-1-3 1.12.20-2
ii libdrm2 2.4.107-8
ii libevent-2.1-7 2.1.12-stable-1
ii libexpat1 2.4.1-2+b1
ii libflac8 1.3.3-2
ii libfontconfig1 2.13.1-4.2
ii libfreetype6 2.10.4+dfsg-1
ii libgbm1 21.2.2-1
ii libgcc-s1 11.2.0-8
ii libglib2.0-0 2.70.0-1+b1
ii libharfbuzz0b 2.7.4-1
ii libicu67 67.1-7
ii libjpeg62-turbo 1:2.0.6-4
ii libjsoncpp24 1.9.4-4
ii liblcms2-2 2.12~rc1-2
ii libminizip1 1.1-8+b1
ii libnspr4 2:4.32-1
ii libnss3 2:3.70-1
ii libopenjp2-7 2.4.0-3
ii libopus0 1.3.1-0.1
ii libpango-1.0-0 1.48.10+ds1-1
ii libpng16-16 1.6.37-3
ii libpulse0 15.0+dfsg1-2
ii libre2-9 20210901+dfsg-1
ii libsnappy1v5 1.1.8-1
ii libstdc++6 11.2.0-8
ii libwebp6 0.6.1-2.1
ii libwebpdemux2 0.6.1-2.1
ii libwebpmux3 0.6.1-2.1
ii libx11-6 2:1.7.2-2+b1
ii libxcb1 1.14-3
ii libxcomposite1 1:0.4.5-1
ii libxdamage1 1:1.1.5-2
ii libxext6 2:1.3.4-1
ii libxfixes3 1:5.0.3-2
ii libxml2 2.9.12+dfsg-5
ii libxrandr2 2:1.5.1-1
ii libxshmfence1 1.3-1
ii libxslt1.1 1.1.34-4
ii zlib1g 1:1.2.11.dfsg-2
Versions of packages chromium recommends:
ii chromium-sandbox 93.0.4577.82-1
Versions of packages chromium suggests:
pn chromium-driver <none>
ii chromium-l10n 93.0.4577.82-1
pn chromium-shell <none>
Versions of packages chromium-common depends on:
ii libc6 2.32-4
ii libstdc++6 11.2.0-8
ii libx11-6 2:1.7.2-2+b1
ii libxext6 2:1.3.4-1
ii x11-utils 7.7+5
ii xdg-utils 1.1.3-4.1
ii zlib1g 1:1.2.11.dfsg-2
Versions of packages chromium-common recommends:
ii chromium-sandbox 93.0.4577.82-1
ii fonts-liberation 1:1.07.4-11
ii gnome-shell [notification-daemon] 40.5-1
ii libgl1-mesa-dri 21.2.2-1
ii libu2f-udev 1.1.10-3
ii notification-daemon 3.20.0-4+b1
ii plasma-workspace [notification-daemon] 4:5.22.90-1~np2
ii system-config-printer 1.5.14-1
ii upower 0.99.13-1
Versions of packages chromium-sandbox depends on:
ii libc6 2.32-4
-- Configuration Files:
/etc/chromium.d/default-flags changed [not included]
-- no debconf information
Paul Gevers
Dec 5, 2021, 5:00:03 AM12/5/21
to
Hi Andres,
On 05-12-2021 03:36, Andres Salomon 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. I'm willing
> to help out with chromium packaging if the problem is simply lack of
> time (or I could just as easily help with something like
> ungoogled-chromium, #939406, if the plan is to have that in debian
> instead). Either way, both as a user and a developer, it is really not
> great to have chromium in limbo. :(
The problem really is lack of maintenance. In my opinion, chromium
deserves an active *team* to support it in Debian. What we have seen
over the past years, are just (more or less) incidental uploads. Not
enough for stable (we shipped it in bullseye because we had the
impression support was picked up again, but alas). We'll not ship it in
bookworm unless we see steady uploads in unstable and we see security
uploads in stable. The security team doesn't have the bandwidth to do it
themselves, they need a team to help them.
Paul
On 05-12-2021 03:36, Andres Salomon 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. I'm willing
> to help out with chromium packaging if the problem is simply lack of
> time (or I could just as easily help with something like
> ungoogled-chromium, #939406, if the plan is to have that in debian
> instead). Either way, both as a user and a developer, it is really not
> great to have chromium in limbo. :(
The problem really is lack of maintenance. In my opinion, chromium
deserves an active *team* to support it in Debian. What we have seen
over the past years, are just (more or less) incidental uploads. Not
enough for stable (we shipped it in bullseye because we had the
impression support was picked up again, but alas). We'll not ship it in
bookworm unless we see steady uploads in unstable and we see security
uploads in stable. The security team doesn't have the bandwidth to do it
themselves, they need a team to help them.
Paul
Moritz Mühlenhoff
Dec 5, 2021, 6:50:03 AM12/5/21
to
I'd suggest anyone who's interested in seeing Chromium supported to first
update it in unstable (and then work towards updated in bullseye-security).
If it gets actively maintained again there's no real blocker to have it in
bookworm, but it's a lot of work.
Cheers,
Moritz
Mattia Rizzolo
Dec 5, 2021, 7:00:05 AM12/5/21
to
> Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers:
> > The problem really is lack of maintenance. In my opinion, chromium deserves
> > an active *team* to support it in Debian.
[..]
> > The problem really is lack of maintenance. In my opinion, chromium deserves
> > an active *team* to support it in Debian.
> > We'll not ship it in bookworm unless we see steady uploads
> > in unstable and we see security uploads in stable.
FWIW, as the person currently sponsoring the (few) uploads thatt happen,
> > in unstable and we see security uploads in stable.
I also approve of this.
I had some hopes for the current "team" (m)ilbert and Michel), but
gilbert's mail even started bouncing, and Micheal became less and less
responsive :( - I understand it's a complicated package so yes, there
needs to be a real team: I also recommend you require an active (as
gilbert is not) DD in the team that actually maintains chromium (so not
me who just sponsor the uploads).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Noah Meyerhans
Dec 6, 2021, 2:51:12 PM12/6/21
to
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.
> >> 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.
> >
>
> 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
Mattia Rizzolo
Dec 6, 2021, 8:13:07 PM12/6/21
to
On Mon, Dec 06, 2021 at 08:53:37PM +0100, Paul Gevers wrote:
> I have good experience with some of my upstreams where they supported me by
> adapting their build system to enable building without the bundled/vendored
> dependencies. Has this been tried? Would it be worth pursuing?
It has been, yes.
I was looking when Micheal reported a few bugs (after my prodding) to
get a few build issues solved (actual FTBFS when building with specific
build flags). Even those bug reports were completely ignored with no
answer whatsoever; the patches also ignored.
I'm led to believe the chromium team is not really playing with the
community at all, rather they are just following their internal bug
tracker instead.
Likewise, they are obviously not interested in supporting anything that
is not the official Google Chrome build (if it can even said they are
"supoprting" that).
> I have good experience with some of my upstreams where they supported me by
> adapting their build system to enable building without the bundled/vendored
> dependencies. Has this been tried? Would it be worth pursuing?
It has been, yes.
I was looking when Micheal reported a few bugs (after my prodding) to
get a few build issues solved (actual FTBFS when building with specific
build flags). Even those bug reports were completely ignored with no
answer whatsoever; the patches also ignored.
I'm led to believe the chromium team is not really playing with the
community at all, rather they are just following their internal bug
tracker instead.
Likewise, they are obviously not interested in supporting anything that
is not the official Google Chrome build (if it can even said they are
"supoprting" that).
Jeff Blake
Dec 16, 2021, 5:40:04 AM12/16/21
to
On Wed, 15 Dec 2021 21:08:28 +0100 Stephen Kitt <sk...@debian.org> wrote:
> Hi Jeff,
>
> On Tue, 14 Dec 2021 09:13:42 +0000, Jeff Blake <jeffb...@gmail.com> 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
> Hi Jeff,
>
> On Tue, 14 Dec 2021 09:13:42 +0000, Jeff Blake <jeffb...@gmail.com> 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
Vincent Bernat
Dec 22, 2021, 6:00:03 AM12/22/21
to
❦ 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"
> 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"
Moritz Muehlenhoff
Jan 2, 2022, 1:30:03 PM1/2/22
to
On Sun, Jan 02, 2022 at 06:53:51PM +0100, Mattia Rizzolo wrote:
> Correlated, do you know how long do they plan on keeping using python2?
> That's plainly unsuitable, it really is not going to last much longer in
> debian.
Current state of the Python 3 upstream migration can be found here:
https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/python3_migration.md
So it sounds like it's almost ready except tests. But the migration
doesn't seem like a top priority either, https://bugs.chromium.org/p/chromium/issues/detail?id=941669
dates back to March 2019...
Cheers,
Moritz
> Correlated, do you know how long do they plan on keeping using python2?
> That's plainly unsuitable, it really is not going to last much longer in
> debian.
Current state of the Python 3 upstream migration can be found here:
https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/python3_migration.md
So it sounds like it's almost ready except tests. But the migration
doesn't seem like a top priority either, https://bugs.chromium.org/p/chromium/issues/detail?id=941669
dates back to March 2019...
Cheers,
Moritz
Andres Salomon
Jan 3, 2022, 5:20:03 AM1/3/22
to
On Sun, 2 Jan 2022 15:32:28 -0500
Andres Salomon <dili...@queued.net> wrote:
> On Sun, 2 Jan 2022 20:15:01 +0100
> Moritz Muehlenhoff <j...@inutil.org> wrote:
>
> > On Sat, Jan 01, 2022 at 01:23:09PM -0500, Andres Salomon wrote:
> > > How should I handle this? NMU to sid, let people try it out, and
> > > then deal with buster/bullseye?
> >
> > Yeah, let's proceed with unstable first in any case.
> >
> > > Upload everything all at once? I'm also
> > > going to try building for buster, unless the security team doesn't
> > > think I should bother.
> >
> > I saw
> > https://salsa.debian.org/dilinger/chromium/-/commit/5c05f430e192961527ec9a64bbaa64401dc14d95
> > , but buster now also includes LLVM/clang 11 (it was introduced to
> > support a more recent Rust toolchain needed for Firefox), so you
> > might be reduce complexity here further:
> > https://tracker.debian.org/pkg/llvm-toolchain-11
> >
> > It's in buster-proposed-updates since there hasn't been a point
> > release since, but for the purposes of buster-security builds, it
> > doesn't matter (they chroots have been modified to includen
> > buster-proposed-updates temporarily):
>
> Ah, very helpful, thanks! I'll give buster a try (just created
> the 'v96-buster' branch). Between that and various backports, I think
> we might be in good shape.
Unfortunately it needs a newer nodejs than what's in buster, so I'll go
back to focusing on bullseye & sid for now. :(
Andres Salomon <dili...@queued.net> wrote:
> On Sun, 2 Jan 2022 20:15:01 +0100
> Moritz Muehlenhoff <j...@inutil.org> wrote:
>
> > On Sat, Jan 01, 2022 at 01:23:09PM -0500, Andres Salomon wrote:
> > > How should I handle this? NMU to sid, let people try it out, and
> > > then deal with buster/bullseye?
> >
> > Yeah, let's proceed with unstable first in any case.
> >
> > > Upload everything all at once? I'm also
> > > going to try building for buster, unless the security team doesn't
> > > think I should bother.
> >
> > I saw
> > https://salsa.debian.org/dilinger/chromium/-/commit/5c05f430e192961527ec9a64bbaa64401dc14d95
> > , but buster now also includes LLVM/clang 11 (it was introduced to
> > support a more recent Rust toolchain needed for Firefox), so you
> > might be reduce complexity here further:
> > https://tracker.debian.org/pkg/llvm-toolchain-11
> >
> > It's in buster-proposed-updates since there hasn't been a point
> > release since, but for the purposes of buster-security builds, it
> > doesn't matter (they chroots have been modified to includen
> > buster-proposed-updates temporarily):
>
> Ah, very helpful, thanks! I'll give buster a try (just created
> the 'v96-buster' branch). Between that and various backports, I think
> we might be in good shape.
Unfortunately it needs a newer nodejs than what's in buster, so I'll go
back to focusing on bullseye & sid for now. :(
Mattia Rizzolo
Jan 3, 2022, 8:00:03 AM1/3/22
to
On Mon, Jan 03, 2022 at 01:39:21PM +0100, Mattia Rizzolo wrote:
> On Sun, Jan 02, 2022 at 06:53:52PM +0100, Mattia Rizzolo wrote:
> > > > the v96 branch of https://salsa.debian.org/dilinger/chromium
> >
> > FWIW, I'm trying to build it myself as well
>
> Here it started chrashing as soon as I tried to open a new tab, and
> after that it refuses to load my main profile (but it loads others).
After rolling back, it seems to have nuked all of the saved passwords
and login information I had (I don't know if this is only an effect of
the rollback and they are actually there somewhere), as well as all
cookies.
> On Sun, Jan 02, 2022 at 06:53:52PM +0100, Mattia Rizzolo wrote:
> > > > the v96 branch of https://salsa.debian.org/dilinger/chromium
> >
> > FWIW, I'm trying to build it myself as well
>
> Here it started chrashing as soon as I tried to open a new tab, and
> after that it refuses to load my main profile (but it loads others).
After rolling back, it seems to have nuked all of the saved passwords
and login information I had (I don't know if this is only an effect of
the rollback and they are actually there somewhere), as well as all
cookies.
Andres Salomon
Jan 3, 2022, 2:00:03 PM1/3/22
to
Thanks for testing! Are you doing this under sid?
On 1/3/22 7:39 AM, Mattia Rizzolo
wrote:
On Sun, Jan 02, 2022 at 06:53:52PM +0100, Mattia Rizzolo wrote:the v96 branch of https://salsa.debian.org/dilinger/chromiumFWIW, I'm trying to build it myself as well
Here it started chrashing as soon as I tried to open a new tab, and after that it refuses to load my main profile (but it loads others). Here is what it prints on the console: mattia@warren /tmp % chromium [3249439:3249439:0103/133254.120313:ERROR:power_monitor_device_source_stub.cc(11)] Not implemented reached in virtual bool base::PowerMonitorDeviceSource::IsOnBatteryPower() [3249485:3249485:0103/133254.419923:ERROR:gpu_init.cc(457)] Passthrough is not supported, GL is desktop, ANGLE is [3249485:3249485:0103/133254.445016:ERROR:sandbox_linux.cc(376)] InitializeSandbox() called with multiple threads in process gpu-process. [3249439:3249468:0103/133258.019370:ERROR:chrome_browser_main_extra_parts_metrics.cc(226)] crbug.com/1216328: Checking Bluetooth availability started. Please report if there is no report that this ends. [3249439:3249468:0103/133258.020176:ERROR:chrome_browser_main_extra_parts_metrics.cc(229)] crbug.com/1216328: Checking Bluetooth availability ended. [3249439:3249468:0103/133258.020199:ERROR:chrome_browser_main_extra_parts_metrics.cc(232)] crbug.com/1216328: Checking default browser status started. Please report if there is no report that this ends. [3249439:3249468:0103/133258.284415:ERROR:chrome_browser_main_extra_parts_metrics.cc(236)] crbug.com/1216328: Checking default browser status ended. [3249439:3249439:0103/133259.591406:FATAL:accessibility_paint_checks.cc(60)] Check failed: node_data.GetNameFrom() == ax::mojom::NameFrom::kAttributeExplicitlyEmpty (kAttribute vs. kAttributeExplicitlyEmpty) 0x55c6fb7c92d0: BookmarkButton is focusable but has no accessible name or placeholder, and is not explicitly marked as empty.
Hm, that's a new one.
Looks like upstream turned those assert crashes into debug statements in newer releases. Please try to following patch:
https://chromium.googlesource.com/chromium/src/+/409b167aac2cd07f6606febcc2b6f3fa286ce749%5E%21/
If that doesn't help, also try the following:
https://chromium.googlesource.com/chromium/src/+/ed83cbdb051c676083dde799cfec982f721e5b68%5E%21/
That second one adds a SkipAccessibilityPaintChecks
setting which will skip that whole code block.
BrowserRootView -> NonClientView -> OpaqueBrowserFrameView -> BrowserView -> TopContainerView -> BookmarkBarView -> BookmarkButton #0 0x55c6ef3a2d79 (/usr/lib/chromium/chromium+0x824bd78) [...] #39 0x55c6eaa1052a _start r8: 0000000000000000 r9: 00007fffbda69a50 r10: 0000000000000008 r11: 0000000000000246 r12: 00000000000001d0 r13: 000055c6f8cc8480 r14: 000055c6f8cc8490 r15: 00007fffbda6a508 di: 0000000000000002 si: 00007fffbda69a50 bp: 00007fffbda69ca0 bx: 00007f7cb6875540 dx: 0000000000000000 ax: 0000000000000000 cx: 00007f7cbdfe6891 sp: 00007fffbda69a50 ip: 00007f7cbdfe6891 efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000 trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000 [end of stack trace] [1] 3249439 IOT instruction (core dumped) chromium (It looks like it's not immediatly obvious how to start it under gdb, so I'm not providing a nicer stack trace)
In general, you install the -dbgsym packages and run chromium -g
Mattia Rizzolo
Jan 4, 2022, 12:00:03 PM1/4/22
to
On Mon, Jan 03, 2022 at 01:47:15PM -0500, Andres Salomon wrote:
> Thanks for testing! Are you doing this under sid?
yes!
> Thanks for testing! Are you doing this under sid?
> Hm, that's a new one.
>
> Looks like upstream turned those assert crashes into debug statements in
> newer releases. Please try to following patch:
>
> https://chromium.googlesource.com/chromium/src/+/409b167aac2cd07f6606febcc2b6f3fa286ce749%5E%21/
>
> If that doesn't help, also try the following:
>
> https://chromium.googlesource.com/chromium/src/+/ed83cbdb051c676083dde799cfec982f721e5b68%5E%21/
>
> That second one adds a SkipAccessibilityPaintChecks setting which will skip
> that whole code block.
mattia@warren ~ % chromium -g
# Env:
# LD_LIBRARY_PATH=
# PATH=/home/mattia/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
# GTK_PATH=
# CHROMIUM_FLAGS= --show-component-extension-options --enable-gpu-rasterization --no-default-browser-check --disable-pings --media-router=0 --enable-remote-extensions --load-extension= --force-device-scale-factor=1.50 --explicitly-allowed-ports=6668
/usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.pHbmsd
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/chromium/chromium...
Reading symbols from /usr/lib/debug/.build-id/ff/ff78741eca7546.debug...
(gdb) r
Starting program: /usr/lib/chromium/chromium --show-component-extension-options --enable-gpu-rasterization --no-default-browser-check --disable-pings --media-router=0 --enable-remote-extensions --load-extension= --force-device-scale-factor=1.50 --explicitly-allowed-ports=6668 --single-process
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 4136670]
[New Thread 0x7fffecbd3640 (LWP 4136675)]
[Detaching after fork from child process 4136676]
[Detaching after fork from child process 4136677]
[Detaching after fork from child process 4136678]
[New Thread 0x7fffe7fff640 (LWP 4136681)]
[New Thread 0x7fffe6e04640 (LWP 4136682)]
[New Thread 0x7fffe6603640 (LWP 4136683)]
[New Thread 0x7fffe5e02640 (LWP 4136684)]
[New Thread 0x7fffe5601640 (LWP 4136685)]
[New Thread 0x7fffe4e00640 (LWP 4136686)]
[New Thread 0x7fffcffff640 (LWP 4136687)]
[4136666:4136666:0104/174403.769154:ERROR:power_monitor_device_source_stub.cc(11)] Not implemented reached in virtual bool base::PowerMonitorDeviceSource::IsOnBatteryPower()
[New Thread 0x7fffcf7fe640 (LWP 4136689)]
[New Thread 0x7fffce7fc640 (LWP 4136690)]
[New Thread 0x7fffceffd640 (LWP 4136688)]
[New Thread 0x7fffcdffb640 (LWP 4136691)]
[New Thread 0x7fffccfcd640 (LWP 4136692)]
[New Thread 0x7fffb3fff640 (LWP 4136693)]
[New Thread 0x7fffb37fe640 (LWP 4136694)]
[New Thread 0x7fffb2ffd640 (LWP 4136695)]
[Thread 0x7fffb2ffd640 (LWP 4136695) exited]
[New Thread 0x7fffb2ffd640 (LWP 4136696)]
[New Thread 0x7fffec123640 (LWP 4136697)]
[New Thread 0x7fffb27fc640 (LWP 4136698)]
[New Thread 0x7fffb1ffb640 (LWP 4136699)]
[New Thread 0x7fffb17fa640 (LWP 4136700)]
[New Thread 0x7fffb0ff9640 (LWP 4136701)]
[New Thread 0x7fff87fff640 (LWP 4136702)]
[New Thread 0x7fff877fe640 (LWP 4136703)]
[4136666:4136666:0104/174403.959575:ERROR:system_network_context_manager.cc(681)] Cannot use V8 Proxy resolver in single process mode.
[4136666:4136666:0104/174403.982114:ERROR:system_network_context_manager.cc(681)] Cannot use V8 Proxy resolver in single process mode.
[New Thread 0x7fff86ffd640 (LWP 4136706)]
[New Thread 0x7fff85ffb640 (LWP 4136708)]
[New Thread 0x7fff867fc640 (LWP 4136707)]
[New Thread 0x7fff857fa640 (LWP 4136709)]
[New Thread 0x7fff84ff9640 (LWP 4136710)]
[New Thread 0x7fff6bfff640 (LWP 4136711)]
[New Thread 0x7fff6b7fe640 (LWP 4136712)]
[New Thread 0x7fff6affd640 (LWP 4136713)]
[4136666:4136666:0104/174404.068078:ERROR:system_network_context_manager.cc(681)] Cannot use V8 Proxy resolver in single process mode.
[4136666:4136666:0104/174404.146112:ERROR:system_network_context_manager.cc(681)] Cannot use V8 Proxy resolver in single process mode.
[4136666:4136666:0104/174404.290066:ERROR:system_network_context_manager.cc(681)] Cannot use V8 Proxy resolver in single process mode.
[4136666:4136666:0104/174404.300230:FATAL:render_process_host_impl.cc(4227)] Check failed: host->GetBrowserContext() == browser_context (0x5555645f47d0 vs. 0x5555658dcb30) Single-process mode does not support multiple browser contexts.
Thread 1 "chromium" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
49 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1 0x00007ffff4653536 in __GI_abort () at abort.c:79
#2 0x000055555d79e9e5 in base::debug::BreakDebuggerAsyncSafe() ()
#3 0x000055555d6ea9f4 in logging::LogMessage::~LogMessage() ()
#4 0x000055555d6eaffe in logging::LogMessage::~LogMessage() ()
#5 0x000055555aba348a in content::RenderProcessHostImpl::IsSuitableHost(content::RenderProcessHost*, content::IsolationContext const&, content::SiteInfo const&) ()
#6 0x000055555aba4733 in content::RenderProcessHostImpl::GetExistingProcessHost(content::SiteInstanceImpl*) ()
#7 0x000055555aba5b71 in content::RenderProcessHostImpl::GetProcessHostForSiteInstance(content::SiteInstanceImpl*) ()
#8 0x000055555acb37dc in content::SiteInstanceImpl::GetProcess() ()
#9 0x000055555ab7b3c4 in content::RenderFrameHostManager::CreateRenderFrameHost(content::RenderFrameHostManager::CreateFrameCase, content::SiteInstance*, int, mojo::PendingAssociatedRemote<content::mojom::Frame>, base::TokenType<blink::LocalFrameTokenTypeMarker> const&, bool) ()
#10 0x000055555ab7b235 in content::RenderFrameHostManager::InitRoot(content::SiteInstance*, bool) ()
#11 0x000055555aa4d59e in content::FrameTree::Init(content::SiteInstance*, bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
()
#12 0x000055555ad1a896 in content::WebContentsImpl::Init(content::WebContents::CreateParams const&) ()
#13 0x000055555ad0cbb1 in content::WebContentsImpl::CreateWithOpener(content::WebContents::CreateParams const&, content::RenderFrameHostImpl*) ()
#14 0x000055555ad0c8b1 in content::WebContents::Create(content::WebContents::CreateParams const&) ()
#15 0x00005555608c633b in ProfilePickerView::Init(Profile*) ()
#16 0x00005555608c61f0 in ProfilePickerView::OnSystemProfileCreated(Profile*, Profile::CreateStatus) ()
#17 0x000055555a62fec0 in base::internal::Invoker<base::internal::BindState<void (webapps::AppBannerManagerDesktop::*)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, web_app::InstallResultCode), base::WeakPtr<webapps::AppBannerManagerDesktop> >, void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, web_app::InstallResultCode)>::RunOnce(base::internal::BindStateBase*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, web_app::InstallResultCode) ()
#18 0x000055555d399bcb in ProfileManager::CreateProfileAsync(base::FilePath const&, base::RepeatingCallback<void (Profile*, Profile::CreateStatus)> const&) ()
#19 0x00005555608c4442 in ProfilePickerView::Display(ProfilePicker::EntryPoint) ()
#20 0x000055556076c476 in StartupBrowserCreator::LaunchBrowserForLastProfiles(base::CommandLine const&, base::FilePath const&, bool, Profile*, std::vector<Profile*, std::allocator<Profile*> > const&) ()
#21 0x000055556076df14 in StartupBrowserCreator::ContinueProcessingCommandLineAfterEarlyWebAppCheck(base::CommandLine const&, base::FilePath const&, Profile*, bool, Profile*, std::vector<Profile*, std::allocator<Profile*> > const&) ()
#22 0x000055556076bcd8 in StartupBrowserCreator::ProcessCmdLineImpl(base::CommandLine const&, base::FilePath const&, bool, Profile*, std::vector<Profile*, std::allocator<Profile*> > const&) ()
#23 0x000055556076ae30 in StartupBrowserCreator::Start(base::CommandLine const&, base::FilePath const&, Profile*, std::vector<Profile*, std::allocator<Profile*> > const&) ()
#24 0x000055555d1b86ef in ChromeBrowserMainParts::PreMainMessageLoopRunImpl() ()
#25 0x000055555d1b7ea8 in ChromeBrowserMainParts::PreMainMessageLoopRun() ()
#26 0x000055555a6b6ddc in content::BrowserMainLoop::PreMainMessageLoopRun() ()
#27 0x000055555acd2c36 in content::StartupTaskRunner::RunAllTasksNow() ()
#28 0x000055555a6b69ca in content::BrowserMainLoop::CreateStartupTasks() ()
#29 0x000055555a6b9598 in content::BrowserMainRunnerImpl::Initialize(content::MainFunctionParams const&) ()
#30 0x000055555a6b4e22 in content::BrowserMain(content::MainFunctionParams const&) ()
#31 0x000055555d176f7d in content::ContentMainRunnerImpl::RunBrowser(content::MainFunctionParams&, bool) ()
#32 0x000055555d1768df in content::ContentMainRunnerImpl::Run(bool) ()
#33 0x000055555d17419a in content::RunContentProcess(content::ContentMainParams const&, content::ContentMainRunner*) ()
#34 0x000055555d174a8b in content::ContentMain(content::ContentMainParams const&) ()
#35 0x0000555558e0d721 in ChromeMain ()
#36 0x00007ffff46547ed in __libc_start_main (main=0x555558e0d5f0 <main>, argc=11, argv=0x7fffffffdd38, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffdd28) at ../csu/libc-start.c:332
#37 0x0000555558e0d52a in _start ()
Andres Salomon
Jan 4, 2022, 3:00:04 PM1/4/22
to
On 1/4/22 11:46, Mattia Rizzolo wrote:
> [...]
I pushed a commit to the skip-a11y-checks branch, please give that a
try. I need to take a look at other distributions that are shipping
chromium to see if they're just disabling DCHECKs outright, or what.
> [...]
> [4136666:4136666:0104/174404.300230:FATAL:render_process_host_impl.cc(4227)] Check failed: host->GetBrowserContext() == browser_context (0x5555645f47d0 vs. 0x5555658dcb30) Single-process mode does not support multiple browser contexts.
Okay, that's funny - appears to be a fatal error due to being run under gdb.
I pushed a commit to the skip-a11y-checks branch, please give that a
try. I need to take a look at other distributions that are shipping
chromium to see if they're just disabling DCHECKs outright, or what.
Mattia Rizzolo
Jan 4, 2022, 3:20:03 PM1/4/22
to
On Tue, Jan 04, 2022 at 02:50:20PM -0500, Andres Salomon wrote:
> Okay, that's funny - appears to be a fatal error due to being run under gdb.
Well, it was also crashing outside of gdb ^^
> Okay, that's funny - appears to be a fatal error due to being run under gdb.
> I pushed a commit to the skip-a11y-checks branch, please give that a try. I
> need to take a look at other distributions that are shipping chromium to see
> if they're just disabling DCHECKs outright, or what.
Mattia Rizzolo
Jan 5, 2022, 1:20:03 PM1/5/22
to
On Wed, Jan 05, 2022 at 01:52:33PM +0100, Mattia Rizzolo wrote:
> I suppose I'll see how it goes in the coming few days.
So it's not crashing but it's being unbearably slow in gmail, to the
point that I just wasn't able to type a mail there, while throwing one
CPU core to 100%.
Also it was kind go generally slow in several other sites, compared to
v93. Always compared to v93, it takes far longer (and by far much much
more CPU) to reopen the whole session (I keep ~50 tabs in 3 windows open
all the time, trusting the browser to reopen them where I left when I
close it).
I didn't mesure anything and I don't have any numbers to share, but
that's what I see.
At least, it looks like it has not been leaking as much memory as v93
was (that in this regard was buggier than v90).
> I suppose I'll see how it goes in the coming few days.
So it's not crashing but it's being unbearably slow in gmail, to the
point that I just wasn't able to type a mail there, while throwing one
CPU core to 100%.
Also it was kind go generally slow in several other sites, compared to
v93. Always compared to v93, it takes far longer (and by far much much
more CPU) to reopen the whole session (I keep ~50 tabs in 3 windows open
all the time, trusting the browser to reopen them where I left when I
close it).
I didn't mesure anything and I don't have any numbers to share, but
that's what I see.
At least, it looks like it has not been leaking as much memory as v93
was (that in this regard was buggier than v90).
Andres Salomon
Jan 5, 2022, 1:20:03 PM1/5/22
to
On 1/5/22 13:14, Mattia Rizzolo wrote:
> On Wed, Jan 05, 2022 at 01:52:33PM +0100, Mattia Rizzolo wrote:
>> I suppose I'll see how it goes in the coming few days.
> So it's not crashing but it's being unbearably slow in gmail, to the
> point that I just wasn't able to type a mail there, while throwing one
> CPU core to 100%.
> Also it was kind go generally slow in several other sites, compared to
> v93. Always compared to v93, it takes far longer (and by far much much
> more CPU) to reopen the whole session (I keep ~50 tabs in 3 windows open
> all the time, trusting the browser to reopen them where I left when I
> close it).
>
> I didn't mesure anything and I don't have any numbers to share, but
> that's what I see.
>
>
> At least, it looks like it has not been leaking as much memory as v93
> was (that in this regard was buggier than v90).
>
I've been testing on x11 (under xfce). Are you using wayland, by chance?
> On Wed, Jan 05, 2022 at 01:52:33PM +0100, Mattia Rizzolo wrote:
>> I suppose I'll see how it goes in the coming few days.
> So it's not crashing but it's being unbearably slow in gmail, to the
> point that I just wasn't able to type a mail there, while throwing one
> CPU core to 100%.
> Also it was kind go generally slow in several other sites, compared to
> v93. Always compared to v93, it takes far longer (and by far much much
> more CPU) to reopen the whole session (I keep ~50 tabs in 3 windows open
> all the time, trusting the browser to reopen them where I left when I
> close it).
>
> I didn't mesure anything and I don't have any numbers to share, but
> that's what I see.
>
>
> At least, it looks like it has not been leaking as much memory as v93
> was (that in this regard was buggier than v90).
>
Andres Salomon
Jan 6, 2022, 3:00:04 AM1/6/22
to
On 1/5/22 13:14, Mattia Rizzolo wrote:
> On Wed, Jan 05, 2022 at 01:52:33PM +0100, Mattia Rizzolo wrote:
>> I suppose I'll see how it goes in the coming few days.
> So it's not crashing but it's being unbearably slow in gmail, to the
> point that I just wasn't able to type a mail there, while throwing one
> CPU core to 100%.
> Also it was kind go generally slow in several other sites, compared to
> v93. Always compared to v93, it takes far longer (and by far much much
> more CPU) to reopen the whole session (I keep ~50 tabs in 3 windows open
> all the time, trusting the browser to reopen them where I left when I
> close it).
>
> I didn't mesure anything and I don't have any numbers to share, but
> that's what I see.
>
>
> At least, it looks like it has not been leaking as much memory as v93
> was (that in this regard was buggier than v90).
>
If you want to try with chromium 97; it now builds as an official build,
>> I suppose I'll see how it goes in the coming few days.
> So it's not crashing but it's being unbearably slow in gmail, to the
> point that I just wasn't able to type a mail there, while throwing one
> CPU core to 100%.
> Also it was kind go generally slow in several other sites, compared to
> v93. Always compared to v93, it takes far longer (and by far much much
> more CPU) to reopen the whole session (I keep ~50 tabs in 3 windows open
> all the time, trusting the browser to reopen them where I left when I
> close it).
>
> I didn't mesure anything and I don't have any numbers to share, but
> that's what I see.
>
>
> At least, it looks like it has not been leaking as much memory as v93
> was (that in this regard was buggier than v90).
>
so those DCHECKs shouldn't even be compiled in. It also supports wayland
automatically, in case that's related to your slowdowns.
https://salsa.debian.org/dilinger/chromium/-/tree/v97
Andres Salomon
Jan 9, 2022, 2:40:03 AM1/9/22
to
On 1/9/22 00:56, Andres Salomon wrote:
>
> On 1/8/22 15:57, Mattia Rizzolo wrote:
>> reason taking much more space than the previous one? Here I have ~40 GB
>> free, and v96 built just fine (though I wasn't looking when it was
>> running), but now this failed already twice due to ENSPC.
>>
>> I'll try looking for someplace more spacy but it's odd :)
>>
>
> Yeah, I think it's the debugging info; it's also breaking lld. It's a
> result of enabling official build, I'm working on it.
In debian/rules, along with is_official_build=true, you can set
symbol_level=#. With is_official_build=false (which is the way it used
to build), it used level 0. The default for is_official_build=true is
level 2, which results in a lot more space (it used 50gb on my last
build) and also means I run out of ram linking the final chrome binary
on my 8gb build machine.
I'm not sure what we should use, as I'm not sure if 0 will break any of
the dbgsym packaging yet. I'm currently trying a build with symbol_level=1.
Fedora doesn't set it, and instead manually patches BUILD.gn to -g0.
Ungoogled-chromium sets it to 1. Arch sets it to 0 if strip is set. Mint
sets it to 0.
>
> On 1/8/22 15:57, Mattia Rizzolo wrote:
>> On Thu, Jan 06, 2022 at 02:55:20AM -0500, Andres Salomon wrote:
>>> If you want to try with chromium 97; it now builds as an official
>>> build, so
>>> those DCHECKs shouldn't even be compiled in. It also supports wayland
>>> automatically, in case that's related to your slowdowns.
>>>
>>> https://salsa.debian.org/dilinger/chromium/-/tree/v97
>> I wanted to do this, but could it be that this version is for some
>>> If you want to try with chromium 97; it now builds as an official
>>> build, so
>>> those DCHECKs shouldn't even be compiled in. It also supports wayland
>>> automatically, in case that's related to your slowdowns.
>>>
>>> https://salsa.debian.org/dilinger/chromium/-/tree/v97
>> reason taking much more space than the previous one? Here I have ~40 GB
>> free, and v96 built just fine (though I wasn't looking when it was
>> running), but now this failed already twice due to ENSPC.
>>
>> I'll try looking for someplace more spacy but it's odd :)
>>
>
> Yeah, I think it's the debugging info; it's also breaking lld. It's a
> result of enabling official build, I'm working on it.
In debian/rules, along with is_official_build=true, you can set
symbol_level=#. With is_official_build=false (which is the way it used
to build), it used level 0. The default for is_official_build=true is
level 2, which results in a lot more space (it used 50gb on my last
build) and also means I run out of ram linking the final chrome binary
on my 8gb build machine.
I'm not sure what we should use, as I'm not sure if 0 will break any of
the dbgsym packaging yet. I'm currently trying a build with symbol_level=1.
Fedora doesn't set it, and instead manually patches BUILD.gn to -g0.
Ungoogled-chromium sets it to 1. Arch sets it to 0 if strip is set. Mint
sets it to 0.
Andres Salomon
Jan 9, 2022, 7:10:03 PM1/9/22
to
them out: https://people.debian.org/~dilinger/chromium/.
Mattia Rizzolo
Jan 10, 2022, 5:10:04 AM1/10/22
to
On Sun, Jan 09, 2022 at 11:23:20PM -0500, Andres Salomon wrote:
> Btw, https://salsa.debian.org/dilinger/chromium/-/tree/stable is my branch
> with cleaned-up commits. That's what I'll use for the NMU, which I'm
> preparing now.
If you all agree, you could finalize the tree, then I'll build again,
after which I could sponsor this after a couple days of testing.
I see that you changed debian/copyright compared to the one I used in my
build here, so I'll export the orig tarball again. (normally with
Michel we'd share the sha256 of one's produced tarball to check we are
building with the same thing, so please share yours?)
Regarding the git repository/team on salsa. What would you all think
about asking the salsa admins to bypass the team admins (gilbert and
riku) that have been silent all this time?
When Micheal started taking over, I didn't want to be too involved so I
didn't ask to be added to team together with him, but I suppose I got
sucked in by this matter a bit too much.
Otherwise I wonder about simply creating a new repository under debian/.
> Btw, https://salsa.debian.org/dilinger/chromium/-/tree/stable is my branch
> with cleaned-up commits. That's what I'll use for the NMU, which I'm
> preparing now.
If you all agree, you could finalize the tree, then I'll build again,
after which I could sponsor this after a couple days of testing.
I see that you changed debian/copyright compared to the one I used in my
build here, so I'll export the orig tarball again. (normally with
Michel we'd share the sha256 of one's produced tarball to check we are
building with the same thing, so please share yours?)
Regarding the git repository/team on salsa. What would you all think
about asking the salsa admins to bypass the team admins (gilbert and
riku) that have been silent all this time?
When Micheal started taking over, I didn't want to be too involved so I
didn't ask to be added to team together with him, but I suppose I got
sucked in by this matter a bit too much.
Otherwise I wonder about simply creating a new repository under debian/.
Leandro Cunha
Jan 10, 2022, 8:40:04 AM1/10/22
to
Hi,
On Sat, Jan 1, 2022 at 3:39 PM Andres Salomon <dili...@queued.net> wrote:
>
> On Thu, 23 Dec 2021 01:49:53 -0500
> Andres Salomon <dili...@queued.net> wrote:
>
> > On 12/13/21 5:31 PM, Moritz Muehlenhoff wrote:
> > >> I started doing just that:
> > >> https://salsa.debian.org/dilinger/chromium (v96 and misc-fixes
> > >> branches).
I am replying to the email with the chromium. It seems ok and ready
for upload. Thank you for your excellent work!
--
Cheers,
Leandro Cunha
Debian Contributor and developer.
On Sat, Jan 1, 2022 at 3:39 PM Andres Salomon <dili...@queued.net> wrote:
>
> On Thu, 23 Dec 2021 01:49:53 -0500
> Andres Salomon <dili...@queued.net> wrote:
>
> > On 12/13/21 5:31 PM, Moritz Muehlenhoff wrote:
> > >> https://salsa.debian.org/dilinger/chromium (v96 and misc-fixes
> > >> branches).
I am replying to the email with the chromium. It seems ok and ready
for upload. Thank you for your excellent work!
--
Cheers,
Leandro Cunha
Debian Contributor and developer.
0 new messages