Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Jonas Smedegaard]

Quoting Andres Salomon (2022-02-14 08:55:22)
> 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.


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

signature.asc
Description: signature

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 2/14/22 02:27, Pirate Praveen wrote:



2022, ഫെബ്രുവരി 13 9:36:11 PM IST, Roger Shimizu ൽ എഴുതി

On Sat, Feb 12, 2022 at 2:12 AM Andres Salomon  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.



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

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Pirate Praveen]

2022, ഫെബ്രുവരി 13 9:36:11 PM IST, Roger Shimizu ൽ എഴുതി
>On Sat, Feb 12, 2022 at 2:12 AM Andres Salomon  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.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Roger Shimizu]

On Sat, Feb 12, 2022 at 2:12 AM Andres Salomon  wrote:
>
> On 2/11/22 06:18, Roger Shimizu wrote:
>
> > Dear Andres,
> >
> > Thanks for your work for chromium!
> >
> > On Mon, Jan 3, 2022 at 7:33 PM Andres Salomon  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 
> >  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\nat 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 ()\nat 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,
>
>
>
> 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 

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 2/11/22 06:18, Roger Shimizu wrote:


Dear Andres,

Thanks for your work for chromium!

On Mon, Jan 3, 2022 at 7:33 PM Andres Salomon  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 
 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\nat 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 ()\nat 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,




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.



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 

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Roger Shimizu]

Dear Andres,

Thanks for your work for chromium!

On Mon, Jan 3, 2022 at 7:33 PM Andres Salomon  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 
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\nat 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 ()\nat 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

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

Re: 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?

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

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

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

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

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

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

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

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

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

Re: 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?

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

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

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

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

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

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

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

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

Re: 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" = 

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

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

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

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

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

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

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

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

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Paul Wise]

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:

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


signature.asc
Description: This is a digitally signed message part

Re: chromium: Update to version 94.0.4606.61 (security-fixes)

[Moritz Mühlenhoff]

Mattia Rizzolo  schrieb:
>
> --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=
> 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
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

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

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

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

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

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

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