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

[Vincent Bernat]

 ❦ 14 February 2022 22:39 +01, Jonas Smedegaard:

> I am trying hard to read good faith into your last sentence above, but 
> have quite some difficulty reading as anything but you describing 
> unbundling as inevitably leading to disaster.

That's how you should read it.

> Maybe my point was unclear, so let me try again: When maintaining a 
> package with embedded code copies, then please if giving up on 
> unbundling at least file RFP bugreports so that others can help.  Help 
> *you* the package maintainer, who has the final say on when and how such 
> separately packaged dependencies is used to *improve* your maintenance 
> (not make your work harder or drive you towards giving up).

The current state of Chromium is that it wasn't able to catch with
security updates for months (even before Bullseye release). Adding more
source-dependencies is a recipe to make it even more difficult to
provide timely updates.

As I don't maintain Chromium, my opinion has little weight. I am just
stating it to counter-balance the peer pressure on the subject.
-- 
Write clearly - don't sacrifice clarity for "efficiency".
- The Elements of Programming Style (Kernighan & Plauger)

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

[Jonas Smedegaard]

Quoting Vincent Bernat (2022-02-14 21:35:47)
>  ❦ 14 February 2022 10:56 +01, Jonas Smedegaard:
> 
> >> I've finally give up and am just using ALL the bundled node 
> >> packages: 
> >> https://salsa.debian.org/chromium-team/chromium/-/commit/a418d219f0217d6398a01c30035d35c42f7a76f1
> >> 
> >
> >> It's not ideal, but at least with this we'll match all of the node 
> >> stuff with what upstream is testing, with the single exception of 
> >> nodejs itself (which we're still using from debian). The only other 
> >> alternative I can think of is to get all the node packages into 
> >> debian, and they'd also need to be backported to bullseye. I 
> >> haven't looked into this yet, but it might be necessary if upstream 
> >> breaks compatibility with nodejs 12. So, uh, if anyone is bored and 
> >> looking for some node packages to maintain :)
> >
> > I fully recognize the pain of maintaining a big package and then on 
> > top of that paying attention to packaging a pile of Node.js modules.
> >
> > It is also, however, a pain to maintain a pile of Node.js modules 
> > and then on top of that paying attention to big packages struggling 
> > with bundled Node.js modules.
> >
> > Suggestion: Please consider filing RFP bugreports for each Node.js 
> > module that you give up on unbundling.  That is far more helpful 
> > towards delegating the work than mentioning deep inside a 
> > mailinglist thread without "help needed packaging Node.js modules" 
> > as subject.
> >
> > A next step (independent, not necessarily by you) could then be to 
> > user-tag RFP bugs tied to unbundling, to help prioritize those among 
> > the many WNPP bugreports.
> 
> Unbundling also means that each update may require waiting for many 
> dependencies, leaving users vulnerable in the meantime. Firefox has a 
> very good track record with updating both in unstable and in stable 
> thanks to glandium uploading new version the day after the release. I 
> don't know what the bundling state is, but even with such a good track 
> record, it sometimes lag a bit behind upstream due to dependencies. 
> Currently, Firefox 97 is waiting for a rust update and nothing seems 
> to go forward. Once someone will move forward, it seems we will have 
> to also wait a bit on the NEW queue due to the rust update (most of 
> the time, I think rust gets quickly approved in a day or two). I have 
> myself switched to the binaries provided by Mozilla. I'll switch back 
> once unstable is up-to-date again because I am confident this won't 
> happen often, but I suppose at some point, I will switch to the 
> Flatpak, like I did for Chromium.
> 
> My point is that packaging dependencies independently will just lead 
> us to difficult to package browsers with maintainers giving up.

Browsers are difficult to package for several reasons.

Availability of separately packaged dependencies is not one of them.

Use of separately packaged dependencies might be a reason, if not done 
well.

I am obviously not suggesting to do lousy packaging work.

I am trying hard to read good faith into your last sentence above, but 
have quite some difficulty reading as anything but you describing 
unbundling as inevitably leading to disaster.

Maybe my point was unclear, so let me try again: When maintaining a 
package with embedded code copies, then please if giving up on 
unbundling at least file RFP bugreports so that others can help.  Help 
*you* the package maintainer, who has the final say on when and how such 
separately packaged dependencies is used to *improve* your maintenance 
(not make your work harder or drive you towards giving up).


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

[Vincent Bernat]

 ❦ 14 February 2022 10:56 +01, Jonas Smedegaard:

>> I've finally give up and am just using ALL the bundled node packages: 
>> https://salsa.debian.org/chromium-team/chromium/-/commit/a418d219f0217d6398a01c30035d35c42f7a76f1
>> 
>
>> It's not ideal, but at least with this we'll match all of the node 
>> stuff with what upstream is testing, with the single exception of 
>> nodejs itself (which we're still using from debian). The only other 
>> alternative I can think of is to get all the node packages into 
>> debian, and they'd also need to be backported to bullseye. I haven't 
>> looked into this yet, but it might be necessary if upstream breaks 
>> compatibility with nodejs 12. So, uh, if anyone is bored and looking 
>> for some node packages to maintain :)
>
> I fully recognize the pain of maintaining a big package and then on top 
> of that paying attention to packaging a pile of Node.js modules.
>
> It is also, however, a pain to maintain a pile of Node.js modules and 
> then on top of that paying attention to big packages struggling with 
> bundled Node.js modules.
>
> Suggestion: Please consider filing RFP bugreports for each Node.js 
> module that you give up on unbundling.  That is far more helpful towards 
> delegating the work than mentioning deep inside a mailinglist thread 
> without "help needed packaging Node.js modules" as subject.
>
> A next step (independent, not necessarily by you) could then be to 
> user-tag RFP bugs tied to unbundling, to help prioritize those among the 
> many WNPP bugreports.

Unbundling also means that each update may require waiting for many
dependencies, leaving users vulnerable in the meantime. Firefox has a
very good track record with updating both in unstable and in stable
thanks to glandium uploading new version the day after the release. I
don't know what the bundling state is, but even with such a good track
record, it sometimes lag a bit behind upstream due to dependencies.
Currently, Firefox 97 is waiting for a rust update and nothing seems to
go forward. Once someone will move forward, it seems we will have to
also wait a bit on the NEW queue due to the rust update (most of the
time, I think rust gets quickly approved in a day or two). I have myself
switched to the binaries provided by Mozilla. I'll switch back once
unstable is up-to-date again because I am confident this won't happen
often, but I suppose at some point, I will switch to the Flatpak, like I
did for Chromium.

My point is that packaging dependencies independently will just lead us
to difficult to package browsers with maintainers giving up.
-- 
Test programs at their boundary values.
- The Elements of Programming Style (Kernighan & Plauger)

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)

[Simon McVittie]

On Mon, 14 Feb 2022 at 01:06:11 +0900, Roger Shimizu wrote:
> I also tried v98 based tree, and result is the same, same build error as 
> above.
> My conclusion is that buster cannot get chromiium major version
> updated easily (except flatpak way, of course).

buster's version of flatpak does not have features that Chromium needs,
so running Chromium as a Flatpak app on buster requires an updated flatpak
from buster-backports. If the security and release teams want this to
be possible, the only way that I think is realistic would be to take
the bullseye version of flatpak, as backported into buster-backports,
and copy it into buster via -proposed-updates or -security; that seems
like it will be lower-risk than backporting arbitrary subsets of flatpak
1.10.x into (our fork of) flatpak 1.2.x.

Chromium as a Flatpak app also requires access to unprivileged creation
of user namespaces, which buster kernels don't allow by default. The
bullseye version of bubblewrap enables this as part of the transition
path to bullseye, but the buster-backports version does not.

I could easily make the buster-backports version of bubblewrap enable
unprivileged creation of user namespaces, but that doesn't seem like a
"least astonishment" change for oldstable, so I'm not going to do that
unless the security/stable-release teams ask me to.

If we aren't willing to backport this sort of thing, which we have
not historically been, then "don't use oldstable for desktop machines"
seems like the only proportionate response - sorry, Flatpak can do a lot
to facilitate app updates, but it isn't magic.

smcv

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 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: Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Mattia Rizzolo]

On Tue, Dec 07, 2021 at 07:31:09PM +0100, Tomas Pospisek wrote:
> > Obviously I cannot promise anything here; I'm currently even more in the 
> > dark
> > than you. :-) But if there's a list of relevant bugs somewhere, I at least
> > have a place to try to understand the issues at hand.

The one bug I had in mind when I wrote my email was this:

https://bugs.chromium.org/p/chromium/issues/detail?id=1250231

However I saw in the past also some cases of a bug reported, few
versions later bug fixed, but actually the bug wasn't even touched, so
most likely somebody else noticed "internally" but never saw the bug
report.


Besides that, look at the stupidly long list of patches.  I consider it
fair to say that for most of them chromium upstream could just trivially
incorporate build flags or support our needs: none of those patches
change foundamental behaviour or so.

> PS: I have included Mattia Rizzolo, Michael Gilbert and the Debian Chromium
> Team directly in the recipients, to be sure they see this email. I do hope
> you all do not mind.

That's all fine with me (also, I'm subscribed to d-d@ (and d-release@),
but I'm not actually involved in the maintenance.

Rather, I'm adding here Michel Le Bihan who actually maintained chromium
in the past 8+ months, and I can only say that he did a great job,
despite the short time.

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

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

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

[Tomas Pospisek]

On 07.12.21 19:14, Steinar H. Gunderson wrote:

On Tue, Dec 07, 2021 at 07:05:29PM +0100, Tomas Pospisek wrote:

So you being a DD and soon at work on Chromium the hope was that maybe you
could conduct some of upstream love to care about the world outside of
Google (?), here in particular Debian's effort to provide Chromium to its
users... to help that effort.


Obviously I cannot promise anything here; I'm currently even more in the dark
than you. :-) But if there's a list of relevant bugs somewhere, I at least
have a place to try to understand the issues at hand.


I think it'd be best if Debian's chromium maintainers (see the 
recipients of this email) would reply to this question, however if you 
go to chromium's BTS page [1] then all the bug reports that have a "↝" 
(a wavy arrow) have been forwarded upstream and - judging by the fact 
that the bugs are still open in the BTS - have probably not been dealt 
with upstream.

*t

[1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=chromium;dist=unstable

PS: I have included Mattia Rizzolo, Michael Gilbert and the Debian 
Chromium Team directly in the recipients, to be sure they see this 
email. I do hope you all do not mind.

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

[Steinar H. Gunderson]

On Tue, Dec 07, 2021 at 07:05:29PM +0100, Tomas Pospisek wrote:
> So you being a DD and soon at work on Chromium the hope was that maybe you
> could conduct some of upstream love to care about the world outside of
> Google (?), here in particular Debian's effort to provide Chromium to its
> users... to help that effort.

Hi,

Obviously I cannot promise anything here; I'm currently even more in the dark
than you. :-) But if there's a list of relevant bugs somewhere, I at least
have a place to try to understand the issues at hand.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

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

[Tomas Pospisek]

Hi Steinar,


On 07.12.21 10:07, Steinar H. Gunderson wrote:

On Tue, Dec 07, 2021 at 08:55:00AM +0100, Tomas Pospisek wrote:

I note that Steinar Gunderson [1] is now employed by Google to work on
Chrome, so maybe there could be hope talking to him?


It's right that I'm just joining the Chromium team, although probably not in
an area that is interesting to you (Style & Font). (And of course, I don't
really have a say in anything yet, and I don't know anyone yet :-) )
I don't have the context here; what specifically is it that you're interested
in getting fixed?


problem explanation starts at [1]. Let me try to summarize (those in the 
known please correct me):


* chromium in Debian is *way* behind upstream
  * many security issues that are fixed upstream but not in Debian
  * chromium maintenance team is too small wrt to maintenance load
  * Debian is carrying many patches
* Debian has reported bugs and patches upstream in the bug tracker
  * at least some build/build-options related
  * no feedback at all from upstream, issues persist
* upstream's perception and attention seems to be limited to
  internal bug tracker

So you being a DD and soon at work on Chromium the hope was that maybe 
you could conduct some of upstream love to care about the world outside 
of Google (?), here in particular Debian's effort to provide Chromium to 
its users... to help that effort.

*t

[1] https://lists.debian.org/debian-devel/2021/12/msg00079.html

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

[Steinar H. Gunderson]

On Tue, Dec 07, 2021 at 08:55:00AM +0100, Tomas Pospisek wrote:
> I note that Steinar Gunderson [1] is now employed by Google to work on
> Chrome, so maybe there could be hope talking to him?

Hi,

It's right that I'm just joining the Chromium team, although probably not in
an area that is interesting to you (Style & Font). (And of course, I don't
really have a say in anything yet, and I don't know anyone yet :-) )
I don't have the context here; what specifically is it that you're interested
in getting fixed?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

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

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

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

[Tomas Pospisek]

On 06.12.21 22:53, Mattia Rizzolo wrote:

On Mon, Dec 06, 2021 at 08:53:37PM +0100, Paul Gevers wrote:

I have good experience with some of my upstreams where they supported me by
adapting their build system to enable building without the bundled/vendored
dependencies. Has this been tried? Would it be worth pursuing?


It has been, yes.

I was looking when Micheal reported a few bugs (after my prodding) to
get a few build issues solved (actual FTBFS when building with specific
build flags).  Even those bug reports were completely ignored with no
answer whatsoever; the patches also ignored.

I'm led to believe the chromium team is not really playing with the
community at all, rather they are just following their internal bug
tracker instead.
Likewise, they are obviously not interested in supporting anything that
is not the official Google Chrome build (if it can even said they are
"supoprting" that).


I note that Steinar Gunderson [1] is now employed by Google to work on 
Chrome, so maybe there could be hope talking to him?

*t

[1] http://blog.sesse.net/blog/tech/2021-12-05-16-41_leaving_mysql.html

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

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

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

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

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)

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

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