Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Mattia Rizzolo]

On Mon, Jan 10, 2022 at 02:21:48PM -0500, Andres Salomon wrote:
> On 1/10/22 05:01, Mattia Rizzolo wrote:
> > 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?)
> 
> 
> Thank you so much for testing! The sha256 that I have is
> cca093107bf6991b4777889012646455f8e520b446c9f27250653f98ed4bb7e0

Cool, this matches with the new tarball I produced.

Guess I'll restart a build with the stable branch now then.


BTW, my current build (from the v97 branch), just crashed on me.  Not
sure where, and I couldn't quickly reproduce it either; I was just
clicking ont he "extension bar", but I'm not even sure what I was
doing..  just saying :)

> I don't need a sponsor (I'm a developer), but thank you for the offer.

Ah!
Apologies!  I didn't look your name up, and I just assumed so from the
n...@debian.org address.  Well, happy then, less "work" for me :D

> Btw, hopefully Michael is just currently busy and is still interested in
> working on chromium?

I ralized that riku retaired formally last month (indeed, please drop
him from Uploaders, I also opened a bug (as MIA team) against chromium
last month).
About Micheal, that's unclear to me: he stated less than one year ago
that he would keep working on chromium, but he really is not answering
to anybody... so well, even if he is still interested, in a case as big
as chromium I think you really needs to show consideration and be at
least reachable.  Though it might just be my own opinion.

-- 
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  `-


signature.asc
Description: PGP signature

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 1/10/22 05:01, Mattia Rizzolo wrote:

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?)



Thank you so much for testing! The sha256 that I have is 
cca093107bf6991b4777889012646455f8e520b446c9f27250653f98ed4bb7e0


I don't need a sponsor (I'm a developer), but thank you for the offer.





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/.

I'm not going to worry about salsa team repo access it just yet; I want 
to get these uploaded (both sid and bullseye) first.


Btw, hopefully Michael is just currently busy and is still interested in 
working on chromium?

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Leandro Cunha]

Hi,

On Sat, Jan 1, 2022 at 3:39 PM Andres Salomon  wrote:
>
> On Thu, 23 Dec 2021 01:49:53 -0500
> Andres Salomon  wrote:
>
> > On 12/13/21 5:31 PM, Moritz Muehlenhoff wrote:
> > > On Sun, Dec 12, 2021 at 08:11:00PM -0500, Andres Salomon wrote:
> > >> On 12/5/21 6:41 AM, Moritz Mühlenhoff wrote:
> > >>> Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers:
> > >>> Exactly that.
> > >>>
> > >>> 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).
> > >> I started doing just that:
> > >> https://salsa.debian.org/dilinger/chromium (v96 and misc-fixes
> > >> branches).

I am replying to the email with the chromium. It seems ok and ready
for upload. Thank you for your excellent work!

-- 
Cheers,
Leandro Cunha
Debian Contributor and developer.

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Mattia Rizzolo]

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/.

-- 
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  `-


signature.asc
Description: PGP signature

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Mattia Rizzolo]

On Sun, Jan 09, 2022 at 12:56:28AM -0500, Andres Salomon wrote:
> 
> 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
> > 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.

I see.

Well, it took me longer than I would have liked, but I finally got a
build out of that v97 branch (commit
2c2685aee67a677c85dd752aea08a7e571312116).

This one looks fully functional, gmail is as reactive as it used to be
(u.U after a few days with v96 and that slowness, now it feels so much
better lol) in the past, and after ~15 minutes of random usage it hasn't
crashed on me yet! \o/


It also fixed a problem I had with v93 where document google sheets
would look totally blank... so double happy now!

-- 
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  `-


signature.asc
Description: PGP signature

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 1/9/22 19:06, Andres Salomon wrote:


On 1/9/22 02:27, Andres Salomon wrote:

On 1/9/22 00:56, Andres Salomon wrote:


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
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.




Here's (sid) binaries with symbol_level=0, if anyone would like to 
test them out: https://people.debian.org/~dilinger/chromium/.


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.

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 1/9/22 02:27, Andres Salomon wrote:

On 1/9/22 00:56, Andres Salomon wrote:


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
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.




Here's (sid) binaries with symbol_level=0, if anyone would like to test 
them out: https://people.debian.org/~dilinger/chromium/.

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 1/9/22 00:56, Andres Salomon wrote:


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
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.

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

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
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.

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Mattia Rizzolo]

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
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 :)

-- 
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  `-


signature.asc
Description: PGP signature

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Mattia Rizzolo]

On Fri, Jan 07, 2022 at 06:34:06AM -0300, Leandro Cunha wrote:
> > > I also haven't heard from anyone on the chromium team yet - should I
> > > add myself as an uploader and do a normal (non-NMU) upload? Do any of
> > > them care?
> >
> > Without hearing from them, adding yourself to Uploaders would be
> > inappropriate.
> 
> If there is no response from someone on the team and someone wants to continue
> the work, how is it done? I was thinking about it when I read this email.

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#non-maintainer-uploads-nmus
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging

Plus, I suppose, the technical committee has the power to enforce
maintainer changes (though I don't think this has been used in… at least
a decade?).

-- 
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  `-


signature.asc
Description: PGP signature

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Mattia Rizzolo]

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

Thank you, let's try with this.

I've just started the build! :)


Also thanks for handling the py2 thing, however you should be aware that
build-depending on python-is-python3 is also not allowed :3
(however I personally prefer that than to have to inject an old binary..)

-- 
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  `-


signature.asc
Description: PGP signature

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Leandro Cunha]

Hi,

>
> > I also haven't heard from anyone on the chromium team yet - should I
> > add myself as an uploader and do a normal (non-NMU) upload? Do any of
> > them care?
>
> Without hearing from them, adding yourself to Uploaders would be
> inappropriate.
>
> --
> regards,
> Mattia Rizzolo
>

If there is no response from someone on the team and someone wants to continue
the work, how is it done? I was thinking about it when I read this email.

-- 
Cheers,
Leandro Cunha

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

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, 
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

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Mattia Rizzolo]

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).

-- 
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  `-


signature.asc
Description: PGP signature

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

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?

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Mattia Rizzolo]

On Tue, Jan 04, 2022 at 06:46:46PM -0500, Andres Salomon wrote:
> On 1/4/22 15:15, Mattia Rizzolo wrote:
> > On Tue, Jan 04, 2022 at 02:50:20PM -0500, Andres Salomon 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.
> 
> Just took a look at fedora, arch, and ungoogle-chromium debian packaging.
> They're all setting is_official_build=true, which completely disables those
> DCHECKs. We should probably set it like that as well, although the
> dcheck_is_configurable=true thing that I added to the skip-a11y-checks
> branch should at least allow the DCHECKs to not be fatal - so there's no
> need to restart your build.


So, this one at least didn't crash on me as soon as I started.
Also, it looks like the saved passwords that went away came back, so I
reckon perhaps the local storage format changed in the upgrade, so v93
wasn't able to see them anymore, or something similar.

I suppose I'll see how it goes in the coming few days.


Thank you for your work!

-- 
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  `-


signature.asc
Description: PGP signature

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Leandro Cunha]

Version 97.0.4692.71 was released a few hours ago with an extensive
list of security holes that have been fixed.
In total, 37 as posted by Google with Chrome and Chromium Team.
Most medium and high severities.

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 1/4/22 15:15, Mattia Rizzolo wrote:

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 ^^


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.

build started...



Just took a look at fedora, arch, and ungoogle-chromium debian 
packaging. They're all setting is_official_build=true, which completely 
disables those DCHECKs. We should probably set it like that as well, 
although the dcheck_is_configurable=true thing that I added to the 
skip-a11y-checks branch should at least allow the DCHECKs to not be 
fatal - so there's no need to restart your build.

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Mattia Rizzolo]

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 ^^

> 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.

build started...

-- 
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  `-


signature.asc
Description: PGP signature

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 1/4/22 11:46, Mattia Rizzolo wrote:

[...]
[413:413:0104/174404.300230:FATAL:render_process_host_impl.cc(4227)] Check 
failed: host->GetBrowserContext() == browser_context (0x645f47d0 vs. 
0x658dcb30) 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.

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Mattia Rizzolo]

On Mon, Jan 03, 2022 at 01:47:15PM -0500, Andres Salomon wrote:
> Thanks for testing! Are you doing this under sid?

yes!

> 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.

I tried, but it still crashes:


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 
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:
.
Find the GDB manual and other documentation resources online at:
.

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 0x7fffc640 (LWP 4136687)]
[413:413: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)]
[413:413:0104/174403.959575:ERROR:system_network_context_manager.cc(681)]
 Cannot use V8 Proxy resolver in single process mode.
[413:413: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)]
[413:413:0104/174404.068078:ERROR:system_network_context_manager.cc(681)]
 Cannot use V8 Proxy resolver in single process mode.
[413:413:0104/174404.146112:ERROR:system_network_context_manager.cc(681)]
 Cannot use V8 Proxy resolver in single process mode.
[413:413:0104/174404.290066:ERROR:system_network_context_manager.cc(681)]
 Cannot use V8 Proxy resolver in single process mode.
[413:413:0104/174404.300230:FATAL:render_process_host_impl.cc(4227)] 
Check 

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

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/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).


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:   r9: 7fffbda69a50 r10: 0008 r11: 
0246
  r12: 01d0 r13: 55c6f8cc8480 r14: 55c6f8cc8490 r15: 
7fffbda6a508
   di: 0002  si: 7fffbda69a50  bp: 7fffbda69ca0  bx: 
7f7cb6875540
   dx:   ax:   cx: 7f7cbdfe6891  sp: 
7fffbda69a50
   ip: 7f7cbdfe6891 efl: 0246 cgf: 002b0033 erf: 

  trp:  msk:  cr2: 
[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

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Mattia Rizzolo]

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.


-- 
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  `-


signature.asc
Description: PGP signature

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Mattia Rizzolo]

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).


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.
BrowserRootView -> NonClientView -> OpaqueBrowserFrameView -> BrowserView -> 
TopContainerView -> BookmarkBarView -> BookmarkButton
#0 0x55c6ef3a2d79 (/usr/lib/chromium/chromium+0x824bd78)
#1 0x55c6ef2d2353 (/usr/lib/chromium/chromium+0x817b352)
#2 0x55c6ef2ed596 (/usr/lib/chromium/chromium+0x8196595)
#3 0x55c6ef2edffe (/usr/lib/chromium/chromium+0x8196ffd)
#4 0x55c6f1fd483a (/usr/lib/chromium/chromium+0xae7d839)
#5 0x55c6f1fc7e92 (/usr/lib/chromium/chromium+0xae70e91)
#6 0x55c6f1fcb985 (/usr/lib/chromium/chromium+0xae74984)
#7 0x55c6f1fcb7a8 (/usr/lib/chromium/chromium+0xae747a7)
#8 0x55c6f25a21bc (/usr/lib/chromium/chromium+0xb44b1bb)
#9 0x55c6f1fc86ec (/usr/lib/chromium/chromium+0xae716eb)
#10 0x55c6f1fcc72c (/usr/lib/chromium/chromium+0xae7572b)
#11 0x55c6f0a59f58 (/usr/lib/chromium/chromium+0x9902f57)
#12 0x55c6f05f0b71 (/usr/lib/chromium/chromium+0x9499b70)
#13 0x55c6f063ef56 (/usr/lib/chromium/chromium+0x94e7f55)
#14 0x55c6f063e891 (/usr/lib/chromium/chromium+0x94e7890)
#15 0x55c6f0704e02 (/usr/lib/chromium/chromium+0x95ade01)
#16 0x55c6f0705928 (/usr/lib/chromium/chromium+0x95ae927)
#17 0x55c6eeead34a (/usr/lib/chromium/chromium+0x7d56349)
#18 0x55c6ef3421cd (/usr/lib/chromium/chromium+0x81eb1cc)
#19 0x55c6ef3632d6 (/usr/lib/chromium/chromium+0x820c2d5)
#20 0x55c6ef362a88 (/usr/lib/chromium/chromium+0x820ba87)
#21 0x55c6ef363892 (/usr/lib/chromium/chromium+0x820c891)
#22 0x55c6ef2f655f (/usr/lib/chromium/chromium+0x819f55e)
#23 0x55c6ef363e28 (/usr/lib/chromium/chromium+0x820ce27)
#24 0x55c6ef322a15 (/usr/lib/chromium/chromium+0x81cba14)
#25 0x55c6ec2baa33 (/usr/lib/chromium/chromium+0x5163a32)
#26 0x55c6ec2bc9de (/usr/lib/chromium/chromium+0x51659dd)
#27 0x55c6ec2b7e32 (/usr/lib/chromium/chromium+0x5160e31)
#28 0x55c6eed79f7d (/usr/lib/chromium/chromium+0x7c22f7c)
#29 0x55c6eed798df (/usr/lib/chromium/chromium+0x7c228de)
#30 0x55c6eed7719a (/usr/lib/chromium/chromium+0x7c20199)
#31 0x55c6eed77a8b (/usr/lib/chromium/chromium+0x7c20a8a)
#32 0x55c6eaa10721 ChromeMain
#33 0x7f7cbdfd17ed __libc_start_main
#34 0x55c6eaa1052a _start
Task trace:
#0 0x55c6f0705676 (/usr/lib/chromium/chromium+0x95ae675)
#1 0x55c6ef58b1c0 (/usr/lib/chromium/chromium+0x84341bf)
#2 0x55c6ef5b62dc (/usr/lib/chromium/chromium+0x845f2db)
IPC message handler context: 0xB99CF134
Crash keys:
  "total-discardable-memory-allocated" = "8388608"
  "gpu-gl-renderer" = "Mesa Intel(R) HD Graphics 520 (SKL GT2)"
  "gpu-gl-vendor" = "Intel"
  "gpu-generation-intel" = "9"
  "gpu-vsver" = "4.60"
  "gpu-psver" = "4.60"
  "gpu-driver" = "21.2.6"
  "gpu-devid" = "0x1916"
  "gpu-venid" = "0x8086"
  "ui_scheduler_async_stack" = "0x55C6F0705676 0x55C6EF58B1C0"
  "extension-1" = "oboonakemofpalcgghocfoadofidjkkk"
  "num-extensions" = "1"
  "switch-12" = "--origin-trial-disabled-features=CaptureHandle"
  "switch-11" = "--enable-features=TabHoverCardImages"
  "io_scheduler_async_stack" = "0x55C6EF5B62DC 0x0"
  "variations" = 

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On Sun, 2 Jan 2022 15:32:28 -0500
Andres Salomon  wrote:

> On Sun, 2 Jan 2022 20:15:01 +0100
> Moritz Muehlenhoff  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.  :(

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On Sun, 2 Jan 2022 20:15:01 +0100
Moritz Muehlenhoff  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.

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Mattia Rizzolo]

On Sat, Jan 01, 2022 at 01:23:09PM -0500, Andres Salomon wrote:
> > I've got 96.0.4664.110 building on both bullseye and sid

Trying it, I see it still build-depends on python-jinja2.  That package
is now gone, so it's not actually buildable in sid anymore.

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.

> > the v96 branch of https://salsa.debian.org/dilinger/chromium

FWIW, I'm trying to build it myself as well (after injecting an old
python-jinja2 and an old python-markupsafe).

> Alright, crashes are solved and the packages are now usable. After some
> cleanups (listing CVEs in changelogs,

This doesn't seem to be done as of the current tip of you v96 branch.

> merging/pushing a bunch of
> commits in my branch, possibly dropping strong stack protection from
> builds to silence warnings from older clang versions, and going through
> lintian errors/warnings), it should be ready to upload.

TBH, I don't think I am able to judge the appropriateness of most of
those changes...
Though I suspect I could close most of my eyes and upload it to
unstable: can't be much worse than what we have...

> How should I handle this? NMU to sid, let people try it out, and then
> deal with buster/bullseye? Upload everything all at once?

Procedure would be NMU to unstable first, IMHO.

> I also haven't heard from anyone on the chromium team yet - should I
> add myself as an uploader and do a normal (non-NMU) upload? Do any of
> them care?

Without hearing from them, adding yourself to Uploaders would be
inappropriate.

-- 
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  `-


signature.asc
Description: PGP signature

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Moritz Muehlenhoff]

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):

I'd say if it works out without additional overhead, let's also update 
buster-security,
but it's also important not to overstretch the time/resources, so focusing on 
bullseye and
EOLing buster is also an option for sure.

Cheers,
Moritz

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 1/2/22 12:53 PM, Mattia Rizzolo wrote:

On Sat, Jan 01, 2022 at 01:23:09PM -0500, Andres Salomon wrote:

I've got 96.0.4664.110 building on both bullseye and sid

Trying it, I see it still build-depends on python-jinja2.  That package
is now gone, so it's not actually buildable in sid anymore.

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.



Sorry, I hadn't pushed the commits yet. I just did, but like I said I 
still need to clean 'em up.

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Moritz Muehlenhoff]

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

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On Thu, 23 Dec 2021 01:49:53 -0500
Andres Salomon  wrote:

> On 12/13/21 5:31 PM, Moritz Muehlenhoff wrote:
> > On Sun, Dec 12, 2021 at 08:11:00PM -0500, Andres Salomon wrote:  
> >> On 12/5/21 6:41 AM, Moritz Mühlenhoff wrote:  
> >>> Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers:
> >>> Exactly that.
> >>>
> >>> 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).  
> >> I started doing just that:
> >> https://salsa.debian.org/dilinger/chromium (v96 and misc-fixes
> >> branches).  
> > As a side note: If any of the system/* patches cause issues, feel
> > free to switch to the vendored copies. Vendoring in general is
> > frowned upon since it requires that a fix in a libraries spreads
> > out to all vendored copies, but for Chromium there's a steady
> > stream of Chromium-internal security issues anyway, so for all
> > practical purposes it doesn't make a difference if the Chromium
> > security releases also include a fix for a vendored lib like ICU.
> >
> > Cheers,
> >  Moritz  
> 
> 
> I've got 96.0.4664.110 building on both bullseye and sid, and am
> currently
> 
> debugging some crashes. The only thing I had to vendor was some nodejs
> 
> libraries, although it's very tempting to take a chainsaw through the 
> various
> 
> patches and re-vendor a bunch of other libraries as Jeff suggested.
> Still on
> 
> the v96 branch of https://salsa.debian.org/dilinger/chromium
> 


Alright, crashes are solved and the packages are now usable. After some
cleanups (listing CVEs in changelogs, merging/pushing a bunch of
commits in my branch, possibly dropping strong stack protection from
builds to silence warnings from older clang versions, and going through
lintian errors/warnings), it should be ready to upload.

How should I handle this? NMU to sid, let people try it out, and then
deal with buster/bullseye? Upload everything all at once? I'm also
going to try building for buster, unless the security team doesn't
think I should bother. That may involve vendoring some additional
libraries, so we don't have to carry a bunch of additional patches.

I also haven't heard from anyone on the chromium team yet - should I
add myself as an uploader and do a normal (non-NMU) upload? Do any of
them care?

Thanks,
Andres

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 12/13/21 5:31 PM, Moritz Muehlenhoff wrote:

On Sun, Dec 12, 2021 at 08:11:00PM -0500, Andres Salomon wrote:

On 12/5/21 6:41 AM, Moritz Mühlenhoff wrote:

Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers:
Exactly that.

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).

I started doing just that: https://salsa.debian.org/dilinger/chromium (v96
and misc-fixes branches).

As a side note: If any of the system/* patches cause issues, feel free to switch
to the vendored copies. Vendoring in general is frowned upon since it requires 
that
a fix in a libraries spreads out to all vendored copies, but for Chromium 
there's
a steady stream of Chromium-internal security issues anyway, so for all
practical purposes it doesn't make a difference if the Chromium security 
releases
also include a fix for a vendored lib like ICU.

Cheers,
 Moritz



I've got 96.0.4664.110 building on both bullseye and sid, and am currently

debugging some crashes. The only thing I had to vendor was some nodejs

libraries, although it's very tempting to take a chainsaw through the 
various


patches and re-vendor a bunch of other libraries as Jeff suggested. Still on

the v96 branch of https://salsa.debian.org/dilinger/chromium

Bug#995212: ungoogled-chromium? [was: Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)]

[Jeff Blake]

On Wed, 15 Dec 2021 21:08:28 +0100 Stephen Kitt  wrote:
> Hi Jeff,
> 
> On Tue, 14 Dec 2021 09:13:42 +, Jeff Blake  wrote:
> [...]
> > Inspector and convertutf are the worst offenders in terms of being
> > unnecessary and complex. The disable/catapult.patch could also be dropped,
> > since profiling might be desirable to some users.
> 
> convertutf at least is required for licensing reasons — it replaces code
> which is stripped from the upstream tarball because it’s not DFSG-free. See
> https://lintian.debian.org/tags/license-problem-convert-utf-code for details.
> 
> Regards,
> 
> Stephen


Hi Stephen,

That's a good point, however upstream Chromium currently requires version 69 of 
icu 
which only exists in Debian Experimental (via icu70). Stable and Unstable both 
have 
icu67 available.

I'm not sure what the solution would be. I suppose patching chromium to work 
with 
icu67, trying to get icu69/70 into unstable (and backporting this to 
stable/dropping 
chromium from stable) or even moving chromium to non-free would be among the 
options.


Best wishes,

Jeff

Bug#995212: ungoogled-chromium? [was: Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)]

[Stephen Kitt]

Hi Jeff,

On Tue, 14 Dec 2021 09:13:42 +, Jeff Blake  wrote:
[...]
> Inspector and convertutf are the worst offenders in terms of being
> unnecessary and complex. The disable/catapult.patch could also be dropped,
> since profiling might be desirable to some users.

convertutf at least is required for licensing reasons — it replaces code
which is stripped from the upstream tarball because it’s not DFSG-free. See
https://lintian.debian.org/tags/license-problem-convert-utf-code for details.

Regards,

Stephen


pgpjqbqVKwhVK.pgp
Description: OpenPGP digital signature

Bug#995212: ungoogled-chromium? [was: Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)]

[Jeff Blake]

On Tue, 7 Dec 2021 19:43:10 +0100 Tomas Pospisek  wrote:
> On 06.12.21 20:43, Noah Meyerhans wrote:
> > On Sun, Dec 05, 2021 at 07:58:17PM +0300, Dmitry Alexandrov wrote:
>  So what's happening with chromium in both sid and stable? I saw on 
>  d-release that it was removed from testing (#998676 and #998732), with a 
>   discussion about ending security support for it in stable.
> >>>
> >>> The problem really is lack of maintenance. In my opinion, chromium 
> >>> deserves an active *team* to support it in Debian.  <...>  The security 
> >>> team doesn't have the bandwidth to do it themselves, they need a team to 
> >>> help them.
> >>
> >> Sorry for a silly question, but whatʼs so wrong with the build done by 
> >> linuxmint.com [1], so Debian needs a whole team to duplicate their effort? 
> >>  Itʼs for Debian 10 (i. e. oldstable) as of now, but works fine at Sid in 
> >> my (limited) experience.
> >>
> > 
> > Well, you can start with the fact that the Mint chromium source packages
> > don't even include the chromium source, let alone the sources for all
> > the other things they build (NodeJS, and more).
> > 
> > The biggest difficulty, as far as I can tell from my look at Chromium
> > from several months ago, is that our patch set [1] needs a lot of
> > attention with every chromium release.  Mint doesn't apply any patches
> > at all to the source, at least none of any real complexity.
> > 
> > One lesson we may take from Mint, though, is that it's not worth trying
> > to patch Chromium as much as we'd like.  Anything that we can do to
> > simplify the Chromium packaging will help us keep the package
> > up-to-date, which in turn will help us keep our users safer.  In my
> > opinion, we should be pretty aggressive about dropping as many of the
> > Chromium patches as possible, even if that means we link against
> > bundled/vendored dependencies.
> > 
> > Legal/licensing considerations are still important and I don't know if
> > we actually *can* ship builds based on the bundled stuff.  But based on
> > the number of patches we have to disable various things [2] or build
> > against system dependencies [3], I can't help but think we'd have an
> > easier time keeping this package fresh if we could drop some of those.
> > 
> > noah
> > 
> > 1. 
> > https://salsa.debian.org/chromium-team/chromium/-/blob/master/debian/patches/series
> > 2. 
> > https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/disable
> > 3. 
> > https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/system
> 
> I'd also like to point out, that the ungoogled-chromium project has some 
> overlap in goals with Debian and it'd possibly be interessing to join 
> forces:
> 
> https://github.com/ungoogled-software/ungoogled-chromium-debian
> 
> (I have been running an ungoogled-chromium for a while (ca. a year 
> ago?), however at that time their chrome wasn't extremely stable so I 
> gave up again. Does anybody have experience using it recently?)
> *t
> 
> 
> 


I have recently forked the debian version of ungoogled chromium [1] [2] [3] to 
(amongst other reasons) re-incorporate many of the previous debian patches and 
features [4].

I haven't had any of the major problems which have blocked the main upstream 
version of it 
over the last couple of release, and the latest chromium version builds and 
runs on both 
unstable and stable.

Most of the debian patches aren't too much bother to update, and are mainly 
context changes. 
Many of them seem worth having, but several are problematic, and if anyone 
wants to make 
maintenance easier then the low hanging fruit to delete for enhanced 
maintainability is as 
follows.


## Plainly not a good idea
debianization/optimization.patch
system/use-desktop-gl-as-default.patch

## Too complex or not worth the trouble to maintain
fixes/inspector.patch
fixes/widevine-revision.patch
system/convertutf.patch

## GCC specific
fixes/gnu-as.patch
warnings/int-in-bool-context.patch
warnings/stringop-overflow.patch

# System lib replacements which are too changeable and/or incompatible between 
stable/unstable
bullseye/ffmpeg.patch
bullseye/icu-types.patch
system/clang-format.patch
system/ffmpeg.patch
system/harfbuzz.patch


Upstream is better placed to judge optimisation levels per build target, and 
all you'll 
achieve with a flat '-O2 everywhere' is a slower binary. With upstream bundled 
clang 
(discussed below) dpkg buildflags doesn't appear to be picked up by the build 
system anyway.

The desktop gl patch is questionable since it can be set as a runtime flag in 
the existing 
debian/etc/default-flags file.

Inspector and convertutf are the worst offenders in terms of being unnecessary 
and complex. 
The disable/catapult.patch could also be dropped, since profiling might be 
desirable to some 
users.

Using gcc to build chromium was dropped by debian ages ago and is not supported 
upstream, so 
I don't see the point in patching gcc-related build 

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Moritz Muehlenhoff]

On Sun, Dec 12, 2021 at 08:11:00PM -0500, Andres Salomon wrote:
> On 12/5/21 6:41 AM, Moritz Mühlenhoff wrote:
> > Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers:
> > Exactly that.
> > 
> > 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).
> 
> I started doing just that: https://salsa.debian.org/dilinger/chromium (v96
> and misc-fixes branches).

As a side note: If any of the system/* patches cause issues, feel free to switch
to the vendored copies. Vendoring in general is frowned upon since it requires 
that
a fix in a libraries spreads out to all vendored copies, but for Chromium 
there's
a steady stream of Chromium-internal security issues anyway, so for all
practical purposes it doesn't make a difference if the Chromium security 
releases
also include a fix for a vendored lib like ICU.

Cheers,
Moritz

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 12/5/21 6:41 AM, Moritz Mühlenhoff wrote:

Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers:
Exactly that.

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).


I started doing just that: https://salsa.debian.org/dilinger/chromium 
(v96 and misc-fixes branches).


Michel, it looks like upstream deprecated use_x11 and now relies on 
ozone; do you have the patches for your ozone-based packages somewhere?


I tried just setting use_ozone=true in debian/rules, but there's a whole 
bunch of BUILD.gn inclusion stuff that breaks. Would save me a lot of 
time if you've already made it work.


Thanks,

Andres

Bug#995212: ungoogled-chromium? [was: Re: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)]

[Tomas Pospisek]

On 06.12.21 20:43, Noah Meyerhans wrote:

On Sun, Dec 05, 2021 at 07:58:17PM +0300, Dmitry Alexandrov wrote:

So what's happening with chromium in both sid and stable? I saw on d-release 
that it was removed from testing (#998676 and #998732), with a  discussion 
about ending security support for it in stable.


The problem really is lack of maintenance. In my opinion, chromium deserves an active 
*team* to support it in Debian.  <...>  The security team doesn't have the 
bandwidth to do it themselves, they need a team to help them.


Sorry for a silly question, but whatʼs so wrong with the build done by 
linuxmint.com [1], so Debian needs a whole team to duplicate their effort?  
Itʼs for Debian 10 (i. e. oldstable) as of now, but works fine at Sid in my 
(limited) experience.



Well, you can start with the fact that the Mint chromium source packages
don't even include the chromium source, let alone the sources for all
the other things they build (NodeJS, and more).

The biggest difficulty, as far as I can tell from my look at Chromium
from several months ago, is that our patch set [1] needs a lot of
attention with every chromium release.  Mint doesn't apply any patches
at all to the source, at least none of any real complexity.

One lesson we may take from Mint, though, is that it's not worth trying
to patch Chromium as much as we'd like.  Anything that we can do to
simplify the Chromium packaging will help us keep the package
up-to-date, which in turn will help us keep our users safer.  In my
opinion, we should be pretty aggressive about dropping as many of the
Chromium patches as possible, even if that means we link against
bundled/vendored dependencies.

Legal/licensing considerations are still important and I don't know if
we actually *can* ship builds based on the bundled stuff.  But based on
the number of patches we have to disable various things [2] or build
against system dependencies [3], I can't help but think we'd have an
easier time keeping this package fresh if we could drop some of those.

noah

1. 
https://salsa.debian.org/chromium-team/chromium/-/blob/master/debian/patches/series
2. 
https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/disable
3. 
https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/system


I'd also like to point out, that the ungoogled-chromium project has some 
overlap in goals with Debian and it'd possibly be interessing to join 
forces:


https://github.com/ungoogled-software/ungoogled-chromium-debian

(I have been running an ungoogled-chromium for a while (ca. a year 
ago?), however at that time their chrome wasn't extremely stable so I 
gave up again. Does anybody have experience using it recently?)

*t

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Dmitry Alexandrov]

Noah Meyerhans  wrote:
> 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.

And let me ask another silly question: where can we actually see a CI log for a 
failed build?  buildd.d.o only features the latest successful one (for 93rd 
Chromium).


signature.asc
Description: PGP signature

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Dmitry Alexandrov]

Noah Meyerhans  wrote:
> On Sun, Dec 05, 2021 at 07:58:17PM +0300, Dmitry Alexandrov wrote:
>> >> So what's happening with chromium in both sid and stable? I saw on 
>> >> d-release that it was removed from testing (#998676 and #998732), with a  
>> >> discussion about ending security support for it in stable.
>> >
>> > The problem really is lack of maintenance. In my opinion, chromium 
>> > deserves an active *team* to support it in Debian.  <...>  The security 
>> > team doesn't have the bandwidth to do it themselves, they need a team to 
>> > help them.
>> 
>> Sorry for a silly question, but whatʼs so wrong with the build done by 
>> linuxmint.com [1], so Debian needs a whole team to duplicate their effort?  
>> Itʼs for Debian 10 (i. e. oldstable) as of now, but works fine at Sid in my 
>> (limited) experience.
>
> Well, you can start with the fact that the Mint chromium source packages 
> don't even include the chromium source,

If the fact is that their ad-hoc downloader does not generate orig tarball, I 
fail to see much trouble here.  They are using the same 
`chromium-browser-official` releases.

> let alone the sources for all the other things they build (NodeJS, and more).

Well, they actually do not build NodeJS, but use a blob from nodejs.org (just 
like Google does).

Nothing good, of course, but I hope itʼs not the case that Chromium build fails 
when NodeJS is actually built from sources that are supposed to correspond to 
that blob?  Or had nobody tried that?

If the latter, why?  Is there some policy, that mandates that preinstalled 
node(1) must be used?

> 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.

Indeed.  As a passer-by I really wonder why that path had been taken at all in 
the first place.  If Chromium devs are into hard-pinning dependencies, they 
presumably have good reasons to do that.

> Legal/licensing considerations are still important and I don't know if we 
> actually *can* ship builds based on the bundled stuff.

I cannot imagine how it can be illegal for Debian what is legal for Google or 
Flathub in this case.  Were there some prior discussions about that?


signature.asc
Description: PGP signature

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Mattia Rizzolo]

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).

-- 
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  `-


signature.asc
Description: PGP signature

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Paul Gevers]

Hi,

On 06-12-2021 20:43, Noah Meyerhans wrote:

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.


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?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Noah Meyerhans]

On Sun, Dec 05, 2021 at 07:58:17PM +0300, Dmitry Alexandrov wrote:
> >> So what's happening with chromium in both sid and stable? I saw on 
> >> d-release that it was removed from testing (#998676 and #998732), with a  
> >> discussion about ending security support for it in stable.
> >
> > The problem really is lack of maintenance. In my opinion, chromium deserves 
> > an active *team* to support it in Debian.  <...>  The security team doesn't 
> > have the bandwidth to do it themselves, they need a team to help them.
> 
> Sorry for a silly question, but whatʼs so wrong with the build done by 
> linuxmint.com [1], so Debian needs a whole team to duplicate their effort?  
> Itʼs for Debian 10 (i. e. oldstable) as of now, but works fine at Sid in my 
> (limited) experience.
> 

Well, you can start with the fact that the Mint chromium source packages
don't even include the chromium source, let alone the sources for all
the other things they build (NodeJS, and more).

The biggest difficulty, as far as I can tell from my look at Chromium
from several months ago, is that our patch set [1] needs a lot of
attention with every chromium release.  Mint doesn't apply any patches
at all to the source, at least none of any real complexity.

One lesson we may take from Mint, though, is that it's not worth trying
to patch Chromium as much as we'd like.  Anything that we can do to
simplify the Chromium packaging will help us keep the package
up-to-date, which in turn will help us keep our users safer.  In my
opinion, we should be pretty aggressive about dropping as many of the
Chromium patches as possible, even if that means we link against
bundled/vendored dependencies.

Legal/licensing considerations are still important and I don't know if
we actually *can* ship builds based on the bundled stuff.  But based on
the number of patches we have to disable various things [2] or build
against system dependencies [3], I can't help but think we'd have an
easier time keeping this package fresh if we could drop some of those.

noah

1. 
https://salsa.debian.org/chromium-team/chromium/-/blob/master/debian/patches/series
2. 
https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/disable
3. 
https://salsa.debian.org/chromium-team/chromium/-/tree/master/debian/patches/system

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Leandro Cunha]

Hi,

On Sun, Dec 5, 2021 at 6:57 AM Paul Gevers  wrote:
>
> 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

Chromium is a browser that would take some work and I see that DDs
are not interested in working on it (nor are those currently defined as
maintainers and co maintainers). :(
But, I agree with Paul.

-- 
Cheers,
Leandro Cunha

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Dmitry Alexandrov]

Paul Gevers  wrote:
> 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.
>
> The problem really is lack of maintenance. In my opinion, chromium deserves 
> an active *team* to support it in Debian.  <...>  The security team doesn't 
> have the bandwidth to do it themselves, they need a team to help them.

Sorry for a silly question, but whatʼs so wrong with the build done by 
linuxmint.com [1], so Debian needs a whole team to duplicate their effort?  
Itʼs for Debian 10 (i. e. oldstable) as of now, but works fine at Sid in my 
(limited) experience.

[1] http://packages.linuxmint.com/pool/upstream/c/chromium/


signature.asc
Description: PGP signature

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Mattia Rizzolo]

> 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.
[..]
> > 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).

-- 
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  `-


signature.asc
Description: PGP signature

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Moritz Mühlenhoff]

Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers:
> 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.

Exactly that.

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

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Paul Gevers]

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


OpenPGP_signature
Description: OpenPGP digital signature

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On Sun, 24 Oct 2021 15:06:50 -0400 Andres Salomon wrote:
> Stable (bullseye) still contains chromium 90, which has had many
> security issues. Testing & unstable contain 93, and stable should really
> be quickly updated via stable-security to at least chromium 93 (as its
> already been packaged and proven to build) or ideally 95 (the latest
> stable chromium release).
>
>
>


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.   :(

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

Stable (bullseye) still contains chromium 90, which has had many 
security issues. Testing & unstable contain 93, and stable should really 
be quickly updated via stable-security to at least chromium 93 (as its 
already been packaged and proven to build) or ideally 95 (the latest 
stable chromium release).