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)
163 views
Skip to first unread message
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:04 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:35:21 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).
Tomas Pospisek
Dec 7, 2021, 3:00:03 AM12/7/21
to
On 06.12.21 22:53, Mattia Rizzolo wrote:
> 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 note that Steinar Gunderson [1] is now employed by Google to work on
> 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).
Chrome, so maybe there could be hope talking to him?
*t
[1] http://blog.sesse.net/blog/tech/2021-12-05-16-41_leaving_mysql.html
Steinar H. Gunderson
Dec 7, 2021, 4:30:04 AM12/7/21
to
On Tue, Dec 07, 2021 at 08:55:00AM +0100, Tomas Pospisek wrote:
> I note that Steinar Gunderson [1] is now employed by Google to work on
> Chrome, so maybe there could be hope talking to him?
Hi,
> I note that Steinar Gunderson [1] is now employed by Google to work on
> Chrome, so maybe there could be hope talking to him?
It's right that I'm just joining the Chromium team, although probably not in
an area that is interesting to you (Style & Font). (And of course, I don't
really have a say in anything yet, and I don't know anyone yet :-) )
I don't have the context here; what specifically is it that you're interested
in getting fixed?
/* Steinar */
--
Homepage: https://www.sesse.net/
Tomas Pospisek
Dec 7, 2021, 1:10:04 PM12/7/21
to
Hi Steinar,
On 07.12.21 10:07, Steinar H. Gunderson wrote:
> On Tue, Dec 07, 2021 at 08:55:00AM +0100, Tomas Pospisek wrote:
>> I note that Steinar Gunderson [1] is now employed by Google to work on
>> Chrome, so maybe there could be hope talking to him?
>
known please correct me):
* chromium in Debian is *way* behind upstream
* many security issues that are fixed upstream but not in Debian
* chromium maintenance team is too small wrt to maintenance load
* Debian is carrying many patches
* Debian has reported bugs and patches upstream in the bug tracker
* at least some build/build-options related
* no feedback at all from upstream, issues persist
* upstream's perception and attention seems to be limited to
internal bug tracker
So you being a DD and soon at work on Chromium the hope was that maybe
you could conduct some of upstream love to care about the world outside
of Google (?), here in particular Debian's effort to provide Chromium to
its users... to help that effort.
*t
[1] https://lists.debian.org/debian-devel/2021/12/msg00079.html
On 07.12.21 10:07, Steinar H. Gunderson wrote:
> On Tue, Dec 07, 2021 at 08:55:00AM +0100, Tomas Pospisek wrote:
>> I note that Steinar Gunderson [1] is now employed by Google to work on
>> Chrome, so maybe there could be hope talking to him?
>
> It's right that I'm just joining the Chromium team, although probably not in
> an area that is interesting to you (Style & Font). (And of course, I don't
> really have a say in anything yet, and I don't know anyone yet :-) )
> I don't have the context here; what specifically is it that you're interested
> in getting fixed?
problem explanation starts at [1]. Let me try to summarize (those in the
> an area that is interesting to you (Style & Font). (And of course, I don't
> really have a say in anything yet, and I don't know anyone yet :-) )
> I don't have the context here; what specifically is it that you're interested
> in getting fixed?
known please correct me):
* chromium in Debian is *way* behind upstream
* many security issues that are fixed upstream but not in Debian
* chromium maintenance team is too small wrt to maintenance load
* Debian is carrying many patches
* Debian has reported bugs and patches upstream in the bug tracker
* at least some build/build-options related
* no feedback at all from upstream, issues persist
* upstream's perception and attention seems to be limited to
internal bug tracker
So you being a DD and soon at work on Chromium the hope was that maybe
you could conduct some of upstream love to care about the world outside
of Google (?), here in particular Debian's effort to provide Chromium to
its users... to help that effort.
*t
[1] https://lists.debian.org/debian-devel/2021/12/msg00079.html
Steinar H. Gunderson
Dec 7, 2021, 1:20:03 PM12/7/21
to
On Tue, Dec 07, 2021 at 07:05:29PM +0100, Tomas Pospisek wrote:
> So you being a DD and soon at work on Chromium the hope was that maybe you
> could conduct some of upstream love to care about the world outside of
> Google (?), here in particular Debian's effort to provide Chromium to its
> users... to help that effort.
Hi,
> So you being a DD and soon at work on Chromium the hope was that maybe you
> could conduct some of upstream love to care about the world outside of
> Google (?), here in particular Debian's effort to provide Chromium to its
> users... to help that effort.
Obviously I cannot promise anything here; I'm currently even more in the dark
than you. :-) But if there's a list of relevant bugs somewhere, I at least
have a place to try to understand the issues at hand.
Tomas Pospisek
Dec 7, 2021, 1:40:03 PM12/7/21
to
On 07.12.21 19:14, Steinar H. Gunderson wrote:
> On Tue, Dec 07, 2021 at 07:05:29PM +0100, Tomas Pospisek wrote:
>> So you being a DD and soon at work on Chromium the hope was that maybe you
>> could conduct some of upstream love to care about the world outside of
>> Google (?), here in particular Debian's effort to provide Chromium to its
>> users... to help that effort.
>
> On Tue, Dec 07, 2021 at 07:05:29PM +0100, Tomas Pospisek wrote:
>> So you being a DD and soon at work on Chromium the hope was that maybe you
>> could conduct some of upstream love to care about the world outside of
>> Google (?), here in particular Debian's effort to provide Chromium to its
>> users... to help that effort.
>
> Obviously I cannot promise anything here; I'm currently even more in the dark
> than you. :-) But if there's a list of relevant bugs somewhere, I at least
> have a place to try to understand the issues at hand.
I think it'd be best if Debian's chromium maintainers (see the
> than you. :-) But if there's a list of relevant bugs somewhere, I at least
> have a place to try to understand the issues at hand.
recipients of this email) would reply to this question, however if you
go to chromium's BTS page [1] then all the bug reports that have a "↝"
(a wavy arrow) have been forwarded upstream and - judging by the fact
that the bugs are still open in the BTS - have probably not been dealt
with upstream.
*t
[1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=chromium;dist=unstable
PS: I have included Mattia Rizzolo, Michael Gilbert and the Debian
Chromium Team directly in the recipients, to be sure they see this
email. I do hope you all do not mind.
Mattia Rizzolo
Dec 7, 2021, 2:10:04 PM12/7/21
to
On Tue, Dec 07, 2021 at 07:31:09PM +0100, Tomas Pospisek wrote:
> > Obviously I cannot promise anything here; I'm currently even more in the dark
> > than you. :-) But if there's a list of relevant bugs somewhere, I at least
> > have a place to try to understand the issues at hand.
The one bug I had in mind when I wrote my email was this:
> > Obviously I cannot promise anything here; I'm currently even more in the dark
> > than you. :-) But if there's a list of relevant bugs somewhere, I at least
> > have a place to try to understand the issues at hand.
https://bugs.chromium.org/p/chromium/issues/detail?id=1250231
However I saw in the past also some cases of a bug reported, few
versions later bug fixed, but actually the bug wasn't even touched, so
most likely somebody else noticed "internally" but never saw the bug
report.
Besides that, look at the stupidly long list of patches. I consider it
fair to say that for most of them chromium upstream could just trivially
incorporate build flags or support our needs: none of those patches
change foundamental behaviour or so.
> PS: I have included Mattia Rizzolo, Michael Gilbert and the Debian Chromium
> Team directly in the recipients, to be sure they see this email. I do hope
> you all do not mind.
but I'm not actually involved in the maintenance.
Rather, I'm adding here Michel Le Bihan who actually maintained chromium
in the past 8+ months, and I can only say that he did a great job,
despite the short time.
Mathias Behrle
Dec 7, 2021, 4:00:02 PM12/7/21
to
* Tomas Pospisek: " ungoogled-chromium? [was: Re: Bug#995212: chromium: Update
to version 94.0.4606.61 (security-fixes)]" (Tue, 7 Dec 2021 19:43:10 +0100):
> (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?)
(Using chromium only as fallback browser if necessary):
Since the removal of chromium from Debian was announced I gave UngoogledChromium
on flatpak a try and it runs very stable so far.
--
Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
to version 94.0.4606.61 (security-fixes)]" (Tue, 7 Dec 2021 19:43:10 +0100):
> (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?)
(Using chromium only as fallback browser if necessary):
Since the removal of chromium from Debian was announced I gave UngoogledChromium
on flatpak a try and it runs very stable so far.
--
Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Vincent Bernat
Dec 7, 2021, 4:50:03 PM12/7/21
to
❦ 7 December 2021 21:46 +01, Mathias Behrle:
>> (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?)
>
> (Using chromium only as fallback browser if necessary):
>
> Since the removal of chromium from Debian was announced I gave UngoogledChromium
> on flatpak a try and it runs very stable so far.
Same here. And they are now following security updates closely (in the
past, there could lag two or three weeks behind). Flatpak compiles it
from source (while UngoogledChromium let contributors compile it and
publish the binary because GitHub CI does not allow such resource-heavy
build).
--
After all, all he did was string together a lot of old, well-known quotations.
-- H. L. Mencken, on Shakespeare
>> (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?)
>
> (Using chromium only as fallback browser if necessary):
>
> Since the removal of chromium from Debian was announced I gave UngoogledChromium
> on flatpak a try and it runs very stable so far.
past, there could lag two or three weeks behind). Flatpak compiles it
from source (while UngoogledChromium let contributors compile it and
publish the binary because GitHub CI does not allow such resource-heavy
build).
--
After all, all he did was string together a lot of old, well-known quotations.
-- H. L. Mencken, on Shakespeare
Bastian Blank
Dec 7, 2021, 5:30:03 PM12/7/21
to
On Tue, Dec 07, 2021 at 10:45:27PM +0100, Vincent Bernat wrote:
> Same here. And they are now following security updates closely (in the
> past, there could lag two or three weeks behind). Flatpak compiles it
> from source (while UngoogledChromium let contributors compile it and
> publish the binary because GitHub CI does not allow such resource-heavy
> build).
You mean th builds of the Flatpk stuff are not properly controlled? But
> Same here. And they are now following security updates closely (in the
> past, there could lag two or three weeks behind). Flatpak compiles it
> from source (while UngoogledChromium let contributors compile it and
> publish the binary because GitHub CI does not allow such resource-heavy
> build).
instead uncontrolled done by contributors?
Bastian
--
There are some things worth dying for.
-- Kirk, "Errand of Mercy", stardate 3201.7
Simon McVittie
Dec 7, 2021, 6:40:03 PM12/7/21
to
On Tue, 07 Dec 2021 at 23:08:41 +0100, Bastian Blank wrote:
> On Tue, Dec 07, 2021 at 10:45:27PM +0100, Vincent Bernat wrote:
> > Flatpak compiles it
> > from source (while UngoogledChromium let contributors compile it and
> > publish the binary because GitHub CI does not allow such resource-heavy
> > build).
>
> You mean th builds of the Flatpk stuff are not properly controlled? But
> instead uncontrolled done by contributors?
I think there is some confusion here.
> On Tue, Dec 07, 2021 at 10:45:27PM +0100, Vincent Bernat wrote:
> > Flatpak compiles it
> > from source (while UngoogledChromium let contributors compile it and
> > publish the binary because GitHub CI does not allow such resource-heavy
> > build).
>
> You mean th builds of the Flatpk stuff are not properly controlled? But
> instead uncontrolled done by contributors?
Flatpak is a piece of software (like apt/dpkg), not an organization or
provider of compiled software (like Debian). Anyone can host a Flatpak
repository, and you can deliver almost anything in Flatpak format (safe
or not, Free or not, compiled from source or not), just like you can
put almost anything in a .deb package.
Flathub is a major build and distribution service for Flatpak apps,
in the same way that Debian and Launchpad are major providers of .deb
packages. Perhaps a closer parallel is that if Flatpak is like the
Android app framework, then Flathub is like the Google Play store:
you can use Flatpak without using Flathub at all, but most Flatpak
users are using Flathub for at least some of their apps. If you think
you have installed an app "from Flatpak" without any further details,
it is probably from Flathub.
Flathub generally requires builds to be done on Flathub's
infrastructure, from source code if possible, in the same way Debian
generally requires builds to be done on buildds, from source if possible.
(Like Debian, it makes an exception for binary-only non-free software
where no public source code is available.)
At least one package on Flathub is built on third-party infrastructure
and directly contributed as binaries even though it is open-source.
The only example I'm aware of is Firefox, which is built by
Mozilla's CI and provided to Flathub as binaries.
I believe what Vincent meant is that the generic non-Flatpak binaries
provided by the "Ungoogled Chromium" project are compiled on unknown
machines and require trusting their submitters, whereas the Flatpak
binaries provided by Flathub are compiled from the same source
code provided by the "Ungoogled Chromium" project, but compiled on
Flathub infrastructure. Here's an example of a build log from Flathub
building Ungoogled Chromium, which does look like it came from source
code (at least superficially, I haven't examined it in detail):
https://flathub.org/builds/#/builders/12/builds/8123
It is possible that the "Ungoogled Chromium" Flatpak build on Flathub
takes some parts as prebuilt binaries while compiling other parts from
first principles. Someone would have to inspect the build in detail to
find out, the same way it isn't trivial to tell from looking at a Debian
package whether it is fully built-from-source or not.
However, when a Flatpak app is compiled using flatpak-builder (which is
what Flathub uses), the build is done in a sandbox that does not allow
network access; so we can be sure that if the "Ungoogled Chromium" build
contains prebuilt binaries, those prebuilt binaries must have been part
of one of the "source" components listed in the JSON or YAML manifest
that drives the build. This is similar to building a Debian package
with `pbuilder build --network no` [1], and then being able to inspect the
orig.tar.* and debian.tar.* to look for any prebuilt binaries that might
have been used.
smcv
[1] but not sbuild (#802850): our policy forbids network access during
build but our official infrastructure currently does not technically
prevent it
Stephan Verbücheln
Dec 7, 2021, 10:20:03 PM12/7/21
to
On Tue, 2021-12-07 at 23:35 +0000, Simon McVittie wrote:
> Flathub generally requires builds to be done on Flathub's
> infrastructure, from source code if possible, in the same way Debian
> generally requires builds to be done on buildds, from source if
> possible.
Are you sure about that? Is there a policy?
> Flathub generally requires builds to be done on Flathub's
> infrastructure, from source code if possible, in the same way Debian
> generally requires builds to be done on buildds, from source if
> possible.
> At least one package on Flathub is built on third-party
> infrastructure
> and directly contributed as binaries even though it is open-source.
> The only example I'm aware of is Firefox, which is built by
> Mozilla's CI and provided to Flathub as binaries.
downloading and unpacking the binary deb from the vendor.
https://github.com/flathub/org.signal.Signal/blob/master/org.signal.Signal.json
Signal itself is open source, but the build process is a complex NPM
rabbit hole.
Regards
Vincent Bernat
Dec 8, 2021, 2:30:03 AM12/8/21
to
❦ 7 December 2021 23:35 GMT, Simon McVittie:
> I believe what Vincent meant is that the generic non-Flatpak binaries
> provided by the "Ungoogled Chromium" project are compiled on unknown
> machines and require trusting their submitters, whereas the Flatpak
> binaries provided by Flathub are compiled from the same source
> code provided by the "Ungoogled Chromium" project, but compiled on
> Flathub infrastructure.
Yes.
--
Don't stop with your first draft.
- The Elements of Programming Style (Kernighan & Plauger)
> I believe what Vincent meant is that the generic non-Flatpak binaries
> provided by the "Ungoogled Chromium" project are compiled on unknown
> machines and require trusting their submitters, whereas the Flatpak
> binaries provided by Flathub are compiled from the same source
> code provided by the "Ungoogled Chromium" project, but compiled on
> Flathub infrastructure.
--
Don't stop with your first draft.
- The Elements of Programming Style (Kernighan & Plauger)
Tomas Pospisek
Dec 8, 2021, 3:40:03 AM12/8/21
to
On 08.12.21 08:27, Vincent Bernat wrote:
> ❦ 7 December 2021 23:35 GMT, Simon McVittie:
>
>> I believe what Vincent meant is that the generic non-Flatpak binaries
>> provided by the "Ungoogled Chromium" project are compiled on unknown
>> machines and require trusting their submitters, whereas the Flatpak
>> binaries provided by Flathub are compiled from the same source
>> code provided by the "Ungoogled Chromium" project, but compiled on
>> Flathub infrastructure.
>
> Yes.
The Debian packages get built by the open build service [1] though as
> ❦ 7 December 2021 23:35 GMT, Simon McVittie:
>
>> I believe what Vincent meant is that the generic non-Flatpak binaries
>> provided by the "Ungoogled Chromium" project are compiled on unknown
>> machines and require trusting their submitters, whereas the Flatpak
>> binaries provided by Flathub are compiled from the same source
>> code provided by the "Ungoogled Chromium" project, but compiled on
>> Flathub infrastructure.
>
> Yes.
far as I can see?
*t
[1] https://github.com/ungoogled-software/ungoogled-chromium-debian
Simon McVittie
Dec 8, 2021, 4:40:04 AM12/8/21
to
On Wed, 08 Dec 2021 at 03:10:31 +0000, Stephan Verbücheln wrote:
> On Tue, 2021-12-07 at 23:35 +0000, Simon McVittie wrote:
> > Flathub generally requires builds to be done on Flathub's
> > infrastructure, from source code if possible, in the same way Debian
> > generally requires builds to be done on buildds, from source if
> > possible.
>
> Are you sure about that? Is there a policy?
I thought there was a socially-enforced policy, but I can't find it
> On Tue, 2021-12-07 at 23:35 +0000, Simon McVittie wrote:
> > Flathub generally requires builds to be done on Flathub's
> > infrastructure, from source code if possible, in the same way Debian
> > generally requires builds to be done on buildds, from source if
> > possible.
>
> Are you sure about that? Is there a policy?
written down, and perhaps it doesn't exist. Certainly the preference is
that apps are built from source where possible, as Ungoogled Chromium
seems to be, but that's never going to be mechanically enforceable
without some sort of gatekeeper reviewing every update, which scales
poorly - imagine what would happen if every Debian package upload went
through NEW...
There is a weaker technically-enforced policy, similar to what we have in
Debian when non-free packages are built on buildds: the package needs
to be "built" on Flathub infrastructure from a flatpak-builder manifest,
but depending on the package, that might be from real source code, or it
might be just unpacking prebuilt binaries from the archives that are listed
as the "source code". I had thought that prebuilt binaries were only used
for non-free packages where source code is not available at all (like
Steam Link), but it seems it is also done for some packages where source
code is available but hard to build.
The way in which Firefox is different is that it has an exception to that
weaker technically-enforced policy: there's no flatpak-builder manifest
for Firefox in Flathub's Github project, and builds done by Mozilla get
imported into the ostree repository directly.
smcv
Moritz Mühlenhoff
Dec 17, 2021, 6:10:03 AM12/17/21
to
Mattia Rizzolo <mat...@debian.org> schrieb:
>
> --FJqzFV9NFse93u4l
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
wiki.debian.org which lists the alternative options to use a current
Chromium (Flatpak, ungoogled Chromium from elsewhere, snap, whatever else
there is)?
This would be useful to help people now looking for an alternative and
we can eventually also reuse this page if we need to EOL for stable/oldstable
(which we should do if the situation doesn't change in a sustainable
manner by early next year).
Cheers,
Moritz
>
> --FJqzFV9NFse93u4l
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
>> Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers:
>> > The problem really is lack of maintenance. In my opinion, chromium dese=
>> Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers:
> rves
>> > 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,
> 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).
Could anyone who's using Chromium on Debian please create a page on
>> > 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,
> 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).
wiki.debian.org which lists the alternative options to use a current
Chromium (Flatpak, ungoogled Chromium from elsewhere, snap, whatever else
there is)?
This would be useful to help people now looking for an alternative and
we can eventually also reuse this page if we need to EOL for stable/oldstable
(which we should do if the situation doesn't change in a sustainable
manner by early next year).
Cheers,
Moritz
Paul Wise
Dec 17, 2021, 7:50:03 PM12/17/21
to
On Fri, 2021-12-17 at 11:28 +0100, Moritz Mühlenhoff wrote:
> Could anyone who's using Chromium on Debian please create a page on
> wiki.debian.org which lists the alternative options to use a current
> Chromium (Flatpak, ungoogled Chromium from elsewhere, snap, whatever
> else there is)?
The existing Chromium page is probably the place to add that:
> Could anyone who's using Chromium on Debian please create a page on
> wiki.debian.org which lists the alternative options to use a current
> Chromium (Flatpak, ungoogled Chromium from elsewhere, snap, whatever
> else there is)?
https://wiki.debian.org/Chromium
The new info should link to the existing page about ungoogled Chromium:
https://wiki.debian.org/ungoogled-chromium
--
bye,
pabs
https://wiki.debian.org/PaulWise
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:03 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/.
Roger Shimizu
Feb 11, 2022, 6:40:03 AM2/11/22
to
Dear Andres,
Thanks for your work for chromium!
On Mon, Jan 3, 2022 at 7:33 PM Andres Salomon <dili...@queued.net> wrote:
> > > 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. :(
I tried to backport bullseye's v97 to buster, but error below occured.
I also tired the v96-buster branch from your salsa git repo, and got
similar error.
So this is the error you mentioned above that buster's nodejs package
is too old for chromium?
Is it possible to use embed nodejs to workaround this issue?
I also guess this might be related to incompatible between system's
nodejs and embed rollup binary.
Is it possible to add a patch to replace with system's rollup?
Error from buster-backports pbuilder for bullseye's chromium v97:
====
FAILED: gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.js
python3 ../../third_party/node/node.py
../../third_party/devtools-frontend/src/node_modules/rollup/dist/bin/rollup
--silent --config
../../third_party/devtools-frontend/src/scripts/build/rollup.config.js
--input gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.prebundle.js
--file gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.js
--configDCHECK
Traceback (most recent call last):
File "../../third_party/node/node.py", line 36, in <module>
RunNode(sys.argv[1:])
File "../../third_party/node/node.py", line 31, in RunNode
raise RuntimeError('%s failed: %s' % (cmd, stderr))
RuntimeError: ['/usr/bin/nodejs',
'../../third_party/devtools-frontend/src/node_modules/rollup/dist/bin/rollup',
'--silent', '--config',
'../../third_party/devtools-frontend/src/scripts/build/rollup.config.js',
'--input', 'gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.prebundle.js',
'--file', 'gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.js',
'--configDCHECK'] failed: b'[!] (plugin minify-html-template-literals)
TypeError: result.matchAll is not a
function\ngen/third_party/devtools-frontend/src/front_end/panels/timeline/components/WebVitalsTimeline.js\nTypeError:
result.matchAll is not a function\n at Object.minifyHTML
(/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/minify-html-literals/src/strategy.ts:145:41)\n
at Object.minifyHTML
(/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/scripts/build/rollup.config.js:80:37)\n
at templates.forEach.template
(/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/minify-html-literals/src/minifyHTMLLiterals.ts:322:24)\n
at Array.forEach (<anonymous>)\n at Object.minifyHTMLLiterals
(/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/minify-html-literals/src/minifyHTMLLiterals.ts:297:13)\n
at Object.transform
(/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/rollup-plugin-minify-html-template-literals/dist/index.js:15:47)\n
at Promise.resolve.then
(/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/rollup/dist/shared/rollup.js:20218:25)\n\n'
====
Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
Thanks for your work for chromium!
On Mon, Jan 3, 2022 at 7:33 PM Andres Salomon <dili...@queued.net> wrote:
> > > 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. :(
I also tired the v96-buster branch from your salsa git repo, and got
similar error.
So this is the error you mentioned above that buster's nodejs package
is too old for chromium?
Is it possible to use embed nodejs to workaround this issue?
I also guess this might be related to incompatible between system's
nodejs and embed rollup binary.
Is it possible to add a patch to replace with system's rollup?
Error from buster-backports pbuilder for bullseye's chromium v97:
====
FAILED: gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.js
python3 ../../third_party/node/node.py
../../third_party/devtools-frontend/src/node_modules/rollup/dist/bin/rollup
--silent --config
../../third_party/devtools-frontend/src/scripts/build/rollup.config.js
--input gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.prebundle.js
--file gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.js
--configDCHECK
Traceback (most recent call last):
File "../../third_party/node/node.py", line 36, in <module>
RunNode(sys.argv[1:])
File "../../third_party/node/node.py", line 31, in RunNode
raise RuntimeError('%s failed: %s' % (cmd, stderr))
RuntimeError: ['/usr/bin/nodejs',
'../../third_party/devtools-frontend/src/node_modules/rollup/dist/bin/rollup',
'--silent', '--config',
'../../third_party/devtools-frontend/src/scripts/build/rollup.config.js',
'--input', 'gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.prebundle.js',
'--file', 'gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.js',
'--configDCHECK'] failed: b'[!] (plugin minify-html-template-literals)
TypeError: result.matchAll is not a
function\ngen/third_party/devtools-frontend/src/front_end/panels/timeline/components/WebVitalsTimeline.js\nTypeError:
result.matchAll is not a function\n at Object.minifyHTML
(/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/minify-html-literals/src/strategy.ts:145:41)\n
at Object.minifyHTML
(/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/scripts/build/rollup.config.js:80:37)\n
at templates.forEach.template
(/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/minify-html-literals/src/minifyHTMLLiterals.ts:322:24)\n
at Array.forEach (<anonymous>)\n at Object.minifyHTMLLiterals
(/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/minify-html-literals/src/minifyHTMLLiterals.ts:297:13)\n
at Object.transform
(/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/rollup-plugin-minify-html-template-literals/dist/index.js:15:47)\n
at Promise.resolve.then
(/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/rollup/dist/shared/rollup.js:20218:25)\n\n'
====
Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
Andres Salomon
Feb 11, 2022, 12:30:03 PM2/11/22
to
12.0 onwards", according to
https://stackoverflow.com/questions/58558257/string-matchall-is-undefined
, which also says that String.match is available. I didn't put any
effort into working around it (either backporting a newer nodejs or
replacing all String.matchAlls with something else), since I wanted to
get chromium shipped for bullseye.
Unfortunately my chromium test builds are now breaking in sid due to
another node (library, I think) change, so we're going to need to figure
out something a bit more reliable with the node stuff. I'm not sure what
that will look like yet. We're currently using the system rollup,
although I think since there's multiple embedded node library copies, we
might have an embedded rollup in there somewhere. I don't recall if my
v96 branch used the system rollup or not, but I've merged everything
into the chromium-team repo so you can use the bullseye branch from
https://salsa.debian.org/chromium-team/chromium for testing this stuff.
It has chromium 98.
Roger Shimizu
Feb 13, 2022, 11:30:02 AM2/13/22
to
So we're on the same page.
I tried to backport nodejs 12 from bullseye to buster, but seems
nodejs 12 cannot coexist with nodejs 10, which means unless I backport
all the nodejs related packages, which has quite a long list ...
That's out of my capacity, so I give up.
> Unfortunately my chromium test builds are now breaking in sid due to
> another node (library, I think) change, so we're going to need to figure
> out something a bit more reliable with the node stuff. I'm not sure what
> that will look like yet. We're currently using the system rollup,
> although I think since there's multiple embedded node library copies, we
> might have an embedded rollup in there somewhere. I don't recall if my
> v96 branch used the system rollup or not, but I've merged everything
> into the chromium-team repo so you can use the bullseye branch from
> https://salsa.debian.org/chromium-team/chromium for testing this stuff.
> It has chromium 98.
My conclusion is that buster cannot get chromiium major version
updated easily (except flatpak way, of course).
Simon McVittie
Feb 13, 2022, 11:50:03 AM2/13/22
to
On Mon, 14 Feb 2022 at 01:06:11 +0900, Roger Shimizu wrote:
> I also tried v98 based tree, and result is the same, same build error as above.
> My conclusion is that buster cannot get chromiium major version
> updated easily (except flatpak way, of course).
buster's version of flatpak does not have features that Chromium needs,
> I also tried v98 based tree, and result is the same, same build error as above.
> My conclusion is that buster cannot get chromiium major version
> updated easily (except flatpak way, of course).
so running Chromium as a Flatpak app on buster requires an updated flatpak
from buster-backports. If the security and release teams want this to
be possible, the only way that I think is realistic would be to take
the bullseye version of flatpak, as backported into buster-backports,
and copy it into buster via -proposed-updates or -security; that seems
like it will be lower-risk than backporting arbitrary subsets of flatpak
1.10.x into (our fork of) flatpak 1.2.x.
Chromium as a Flatpak app also requires access to unprivileged creation
of user namespaces, which buster kernels don't allow by default. The
bullseye version of bubblewrap enables this as part of the transition
path to bullseye, but the buster-backports version does not.
I could easily make the buster-backports version of bubblewrap enable
unprivileged creation of user namespaces, but that doesn't seem like a
"least astonishment" change for oldstable, so I'm not going to do that
unless the security/stable-release teams ask me to.
If we aren't willing to backport this sort of thing, which we have
not historically been, then "don't use oldstable for desktop machines"
seems like the only proportionate response - sorry, Flatpak can do a lot
to facilitate app updates, but it isn't magic.
smcv
Andres Salomon
Feb 14, 2022, 3:20:03 AM2/14/22
to
On 2/14/22 02:27, Pirate Praveen wrote:
>
> 2022, ഫെബ്രുവരി 13 9:36:11 PM IST, Roger Shimizu <ro...@debian.org>ൽ എഴുതി
Thanks. We're already depending on babel (see
https://salsa.debian.org/chromium-team/chromium/-/commit/5a04d98bfa15dc4f96d84ce0f420e9eeed4184f7
), but there's currently a number of issues with the current state of
things. Because chromium depends on a bunch of unpackaged node
libraries, and it uses various node-based tools (tsc and rollup being
the obvious examples), we end up with a weird mix of newer and older
node libs. To make matters even more complicated, there isn't just one
set of node libraries and tools in the chromium source tree - they're
actually scattered throughout, and there's even multiple copies of many
of the libs. It's a mess! For example, here's a random node module I picked:
dilinger@7400:~/sid/chromium-98.0.4758.80$ find . -name parse5
./third_party/node/node_modules/parse5
./third_party/node/node_modules/polymer-css-build/node_modules/parse5
./third_party/node/node_modules/polymer-bundler/node_modules/parse5
./third_party/node/node_modules/polymer-analyzer/node_modules/parse5
./third_party/devtools-frontend/src/node_modules/parse5
./third_party/devtools-frontend/src/node_modules/eslint-plugin-lit-a11y/node_modules/eslint-plugin-lit/node_modules/parse5
./third_party/devtools-frontend/src/node_modules/dom5/node_modules/parse5
./third_party/devtools-frontend/src/node_modules/parse5-htmlparser2-tree-adapter/node_modules/parse5
./third_party/devtools-frontend/src/node_modules/@types/parse5
Are they even the same version? No, of course not:
dilinger@7400:~/sid/chromium-98.0.4758.80$ find . -name parse5 -exec
grep version '{}/package.json' \;
"version": "1.5.1",
"version": "4.0.0",
"version": "4.0.0",
"version": "4.0.0",
"version": "5.1.1",
"version": "6.0.1",
"version": "4.0.0",
"version": "6.0.1",
"version": "2.2.34",
I previously worked around this mess (as you can see in the above
commit) by depending on as much of the debian packages as possible, but
even that didn't work; for example, bullseye's tsc didn't work with the
remaining bundled modules, resulting in further workarounds:
https://salsa.debian.org/chromium-team/chromium/-/commit/568c497bac5e828fdf9718ced6a57d1110841fbc
. And random changes within the debian-packaged node libs are now
breaking it, as https://bugs.debian.org/1005466 shows.
I've finally give up and am just using ALL the bundled node packages:
https://salsa.debian.org/chromium-team/chromium/-/commit/a418d219f0217d6398a01c30035d35c42f7a76f1
It's not ideal, but at least with this we'll match all of the node stuff
with what upstream is testing, with the single exception of nodejs
itself (which we're still using from debian). The only other alternative
I can think of is to get all the node packages into debian, and they'd
also need to be backported to bullseye. I haven't looked into this yet,
but it might be necessary if upstream breaks compatibility with nodejs
12. So, uh, if anyone is bored and looking for some node packages to
maintain.... :)
>
> 2022, ഫെബ്രുവരി 13 9:36:11 PM IST, Roger Shimizu <ro...@debian.org>ൽ എഴുതി
>> On Sat, Feb 12, 2022 at 2:12 AM Andres Salomon <dili...@queued.net> wrote:
>>> Yes, that's the error. "String.matchAll is only available from Node.js
>>> 12.0 onwards", according to
>>> https://stackoverflow.com/questions/58558257/string-matchall-is-undefined
>>> , which also says that String.match is available. I didn't put any
>>> effort into working around it (either backporting a newer nodejs or
>>> replacing all String.matchAlls with something else), since I wanted to
>>> get chromium shipped for bullseye.
>> Thanks for your confirmation!
>> So we're on the same page.
>> I tried to backport nodejs 12 from bullseye to buster, but seems
>> nodejs 12 cannot coexist with nodejs 10, which means unless I backport
>> all the nodejs related packages, which has quite a long list ...
>> That's out of my capacity, so I give up.
> I think using babel (already packaged) to transpile the js to run on nodejs 10 could be another option.
>>> Yes, that's the error. "String.matchAll is only available from Node.js
>>> 12.0 onwards", according to
>>> https://stackoverflow.com/questions/58558257/string-matchall-is-undefined
>>> , which also says that String.match is available. I didn't put any
>>> effort into working around it (either backporting a newer nodejs or
>>> replacing all String.matchAlls with something else), since I wanted to
>>> get chromium shipped for bullseye.
>> Thanks for your confirmation!
>> So we're on the same page.
>> I tried to backport nodejs 12 from bullseye to buster, but seems
>> nodejs 12 cannot coexist with nodejs 10, which means unless I backport
>> all the nodejs related packages, which has quite a long list ...
>> That's out of my capacity, so I give up.
Thanks. We're already depending on babel (see
https://salsa.debian.org/chromium-team/chromium/-/commit/5a04d98bfa15dc4f96d84ce0f420e9eeed4184f7
), but there's currently a number of issues with the current state of
things. Because chromium depends on a bunch of unpackaged node
libraries, and it uses various node-based tools (tsc and rollup being
the obvious examples), we end up with a weird mix of newer and older
node libs. To make matters even more complicated, there isn't just one
set of node libraries and tools in the chromium source tree - they're
actually scattered throughout, and there's even multiple copies of many
of the libs. It's a mess! For example, here's a random node module I picked:
dilinger@7400:~/sid/chromium-98.0.4758.80$ find . -name parse5
./third_party/node/node_modules/parse5
./third_party/node/node_modules/polymer-css-build/node_modules/parse5
./third_party/node/node_modules/polymer-bundler/node_modules/parse5
./third_party/node/node_modules/polymer-analyzer/node_modules/parse5
./third_party/devtools-frontend/src/node_modules/parse5
./third_party/devtools-frontend/src/node_modules/eslint-plugin-lit-a11y/node_modules/eslint-plugin-lit/node_modules/parse5
./third_party/devtools-frontend/src/node_modules/dom5/node_modules/parse5
./third_party/devtools-frontend/src/node_modules/parse5-htmlparser2-tree-adapter/node_modules/parse5
./third_party/devtools-frontend/src/node_modules/@types/parse5
Are they even the same version? No, of course not:
dilinger@7400:~/sid/chromium-98.0.4758.80$ find . -name parse5 -exec
grep version '{}/package.json' \;
"version": "1.5.1",
"version": "4.0.0",
"version": "4.0.0",
"version": "4.0.0",
"version": "5.1.1",
"version": "6.0.1",
"version": "4.0.0",
"version": "6.0.1",
"version": "2.2.34",
I previously worked around this mess (as you can see in the above
commit) by depending on as much of the debian packages as possible, but
even that didn't work; for example, bullseye's tsc didn't work with the
remaining bundled modules, resulting in further workarounds:
https://salsa.debian.org/chromium-team/chromium/-/commit/568c497bac5e828fdf9718ced6a57d1110841fbc
. And random changes within the debian-packaged node libs are now
breaking it, as https://bugs.debian.org/1005466 shows.
I've finally give up and am just using ALL the bundled node packages:
https://salsa.debian.org/chromium-team/chromium/-/commit/a418d219f0217d6398a01c30035d35c42f7a76f1
It's not ideal, but at least with this we'll match all of the node stuff
with what upstream is testing, with the single exception of nodejs
itself (which we're still using from debian). The only other alternative
I can think of is to get all the node packages into debian, and they'd
also need to be backported to bullseye. I haven't looked into this yet,
but it might be necessary if upstream breaks compatibility with nodejs
12. So, uh, if anyone is bored and looking for some node packages to
maintain.... :)
Jonas Smedegaard
Feb 14, 2022, 5:00:04 AM2/14/22
to
Quoting Andres Salomon (2022-02-14 08:55:22)
of that paying attention to packaging a pile of Node.js modules.
It is also, however, a pain to maintain a pile of Node.js modules and
then on top of that paying attention to big packages struggling with
bundled Node.js modules.
Suggestion: Please consider filing RFP bugreports for each Node.js
module that you give up on unbundling. That is far more helpful towards
delegating the work than mentioning deep inside a mailinglist thread
without "help needed packaging Node.js modules" as subject.
A next step (independent, not necessarily by you) could then be to
user-tag RFP bugs tied to unbundling, to help prioritize those among the
many WNPP bugreports.
Kind regards,
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
> I've finally give up and am just using ALL the bundled node packages:
> https://salsa.debian.org/chromium-team/chromium/-/commit/a418d219f0217d6398a01c30035d35c42f7a76f1
>
> It's not ideal, but at least with this we'll match all of the node
> stuff with what upstream is testing, with the single exception of
> nodejs itself (which we're still using from debian). The only other
> alternative I can think of is to get all the node packages into
> debian, and they'd also need to be backported to bullseye. I haven't
> looked into this yet, but it might be necessary if upstream breaks
> compatibility with nodejs 12. So, uh, if anyone is bored and looking
> for some node packages to maintain.... :)
I fully recognize the pain of maintaining a big package and then on top
> https://salsa.debian.org/chromium-team/chromium/-/commit/a418d219f0217d6398a01c30035d35c42f7a76f1
>
> It's not ideal, but at least with this we'll match all of the node
> stuff with what upstream is testing, with the single exception of
> nodejs itself (which we're still using from debian). The only other
> alternative I can think of is to get all the node packages into
> debian, and they'd also need to be backported to bullseye. I haven't
> looked into this yet, but it might be necessary if upstream breaks
> compatibility with nodejs 12. So, uh, if anyone is bored and looking
> for some node packages to maintain.... :)
of that paying attention to packaging a pile of Node.js modules.
It is also, however, a pain to maintain a pile of Node.js modules and
then on top of that paying attention to big packages struggling with
bundled Node.js modules.
Suggestion: Please consider filing RFP bugreports for each Node.js
module that you give up on unbundling. That is far more helpful towards
delegating the work than mentioning deep inside a mailinglist thread
without "help needed packaging Node.js modules" as subject.
A next step (independent, not necessarily by you) could then be to
user-tag RFP bugs tied to unbundling, to help prioritize those among the
many WNPP bugreports.
Kind regards,
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
Vincent Bernat
Feb 14, 2022, 3:40:03 PM2/14/22
to
❦ 14 February 2022 10:56 +01, Jonas Smedegaard:
>> I've finally give up and am just using ALL the bundled node packages:
>> https://salsa.debian.org/chromium-team/chromium/-/commit/a418d219f0217d6398a01c30035d35c42f7a76f1
>>
>
>> It's not ideal, but at least with this we'll match all of the node
>> stuff with what upstream is testing, with the single exception of
>> nodejs itself (which we're still using from debian). The only other
>> alternative I can think of is to get all the node packages into
>> debian, and they'd also need to be backported to bullseye. I haven't
>> looked into this yet, but it might be necessary if upstream breaks
>> compatibility with nodejs 12. So, uh, if anyone is bored and looking
>> for some node packages to maintain.... :)
>
> I fully recognize the pain of maintaining a big package and then on top
> of that paying attention to packaging a pile of Node.js modules.
>
> It is also, however, a pain to maintain a pile of Node.js modules and
> then on top of that paying attention to big packages struggling with
> bundled Node.js modules.
>
> Suggestion: Please consider filing RFP bugreports for each Node.js
> module that you give up on unbundling. That is far more helpful towards
> delegating the work than mentioning deep inside a mailinglist thread
> without "help needed packaging Node.js modules" as subject.
>
> A next step (independent, not necessarily by you) could then be to
> user-tag RFP bugs tied to unbundling, to help prioritize those among the
> many WNPP bugreports.
Unbundling also means that each update may require waiting for many
dependencies, leaving users vulnerable in the meantime. Firefox has a
very good track record with updating both in unstable and in stable
thanks to glandium uploading new version the day after the release. I
don't know what the bundling state is, but even with such a good track
record, it sometimes lag a bit behind upstream due to dependencies.
Currently, Firefox 97 is waiting for a rust update and nothing seems to
go forward. Once someone will move forward, it seems we will have to
also wait a bit on the NEW queue due to the rust update (most of the
time, I think rust gets quickly approved in a day or two). I have myself
switched to the binaries provided by Mozilla. I'll switch back once
unstable is up-to-date again because I am confident this won't happen
often, but I suppose at some point, I will switch to the Flatpak, like I
did for Chromium.
My point is that packaging dependencies independently will just lead us
to difficult to package browsers with maintainers giving up.
--
Test programs at their boundary values.
>> I've finally give up and am just using ALL the bundled node packages:
>> https://salsa.debian.org/chromium-team/chromium/-/commit/a418d219f0217d6398a01c30035d35c42f7a76f1
>>
>
>> It's not ideal, but at least with this we'll match all of the node
>> stuff with what upstream is testing, with the single exception of
>> nodejs itself (which we're still using from debian). The only other
>> alternative I can think of is to get all the node packages into
>> debian, and they'd also need to be backported to bullseye. I haven't
>> looked into this yet, but it might be necessary if upstream breaks
>> compatibility with nodejs 12. So, uh, if anyone is bored and looking
>> for some node packages to maintain.... :)
>
> I fully recognize the pain of maintaining a big package and then on top
> of that paying attention to packaging a pile of Node.js modules.
>
> It is also, however, a pain to maintain a pile of Node.js modules and
> then on top of that paying attention to big packages struggling with
> bundled Node.js modules.
>
> Suggestion: Please consider filing RFP bugreports for each Node.js
> module that you give up on unbundling. That is far more helpful towards
> delegating the work than mentioning deep inside a mailinglist thread
> without "help needed packaging Node.js modules" as subject.
>
> A next step (independent, not necessarily by you) could then be to
> user-tag RFP bugs tied to unbundling, to help prioritize those among the
> many WNPP bugreports.
dependencies, leaving users vulnerable in the meantime. Firefox has a
very good track record with updating both in unstable and in stable
thanks to glandium uploading new version the day after the release. I
don't know what the bundling state is, but even with such a good track
record, it sometimes lag a bit behind upstream due to dependencies.
Currently, Firefox 97 is waiting for a rust update and nothing seems to
go forward. Once someone will move forward, it seems we will have to
also wait a bit on the NEW queue due to the rust update (most of the
time, I think rust gets quickly approved in a day or two). I have myself
switched to the binaries provided by Mozilla. I'll switch back once
unstable is up-to-date again because I am confident this won't happen
often, but I suppose at some point, I will switch to the Flatpak, like I
did for Chromium.
My point is that packaging dependencies independently will just lead us
to difficult to package browsers with maintainers giving up.
--
Test programs at their boundary values.
Jonas Smedegaard
Feb 14, 2022, 4:40:03 PM2/14/22
to
Quoting Vincent Bernat (2022-02-14 21:35:47)
Browsers are difficult to package for several reasons.
Availability of separately packaged dependencies is not one of them.
Use of separately packaged dependencies might be a reason, if not done
well.
I am obviously not suggesting to do lousy packaging work.
I am trying hard to read good faith into your last sentence above, but
have quite some difficulty reading as anything but you describing
unbundling as inevitably leading to disaster.
Maybe my point was unclear, so let me try again: When maintaining a
package with embedded code copies, then please if giving up on
unbundling at least file RFP bugreports so that others can help. Help
*you* the package maintainer, who has the final say on when and how such
separately packaged dependencies is used to *improve* your maintenance
(not make your work harder or drive you towards giving up).
Availability of separately packaged dependencies is not one of them.
Use of separately packaged dependencies might be a reason, if not done
well.
I am obviously not suggesting to do lousy packaging work.
I am trying hard to read good faith into your last sentence above, but
have quite some difficulty reading as anything but you describing
unbundling as inevitably leading to disaster.
Maybe my point was unclear, so let me try again: When maintaining a
package with embedded code copies, then please if giving up on
unbundling at least file RFP bugreports so that others can help. Help
*you* the package maintainer, who has the final say on when and how such
separately packaged dependencies is used to *improve* your maintenance
(not make your work harder or drive you towards giving up).
Vincent Bernat
Feb 14, 2022, 5:20:02 PM2/14/22
to
❦ 14 February 2022 22:39 +01, Jonas Smedegaard:
> I am trying hard to read good faith into your last sentence above, but
> have quite some difficulty reading as anything but you describing
> unbundling as inevitably leading to disaster.
That's how you should read it.
> Maybe my point was unclear, so let me try again: When maintaining a
> package with embedded code copies, then please if giving up on
> unbundling at least file RFP bugreports so that others can help. Help
> *you* the package maintainer, who has the final say on when and how such
> separately packaged dependencies is used to *improve* your maintenance
> (not make your work harder or drive you towards giving up).
The current state of Chromium is that it wasn't able to catch with
security updates for months (even before Bullseye release). Adding more
source-dependencies is a recipe to make it even more difficult to
provide timely updates.
As I don't maintain Chromium, my opinion has little weight. I am just
stating it to counter-balance the peer pressure on the subject.
--
Write clearly - don't sacrifice clarity for "efficiency".
> I am trying hard to read good faith into your last sentence above, but
> have quite some difficulty reading as anything but you describing
> unbundling as inevitably leading to disaster.
> Maybe my point was unclear, so let me try again: When maintaining a
> package with embedded code copies, then please if giving up on
> unbundling at least file RFP bugreports so that others can help. Help
> *you* the package maintainer, who has the final say on when and how such
> separately packaged dependencies is used to *improve* your maintenance
> (not make your work harder or drive you towards giving up).
security updates for months (even before Bullseye release). Adding more
source-dependencies is a recipe to make it even more difficult to
provide timely updates.
As I don't maintain Chromium, my opinion has little weight. I am just
stating it to counter-balance the peer pressure on the subject.
--
Write clearly - don't sacrifice clarity for "efficiency".
0 new messages