--FJqzFV9NFse93u4l
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Am Sun, Dec 05, 2021 at 10:53:56AM +0100 schrieb Paul Gevers:rves
The problem really is lack of maintenance. In my opinion, chromium dese=
[..]an active *team* to support it in Debian.
We'll not ship it in bookworm unless we see steady uploads
in unstable and we see security uploads in stable.
FWIW, as the person currently sponsoring the (few) uploads thatt happen,
I also approve of this.
I had some hopes for the current "team" (m)ilbert and Michel), but
gilbert's mail even started bouncing, and Micheal became less and less responsive :( - I understand it's a complicated package so yes, there
needs to be a real team: I also recommend you require an active (as
gilbert is not) DD in the team that actually maintains chromium (so not
me who just sponsor the uploads).
Could anyone who's using Chromium on Debian please create a page on wiki.debian.org which lists the alternative options to use a current
Chromium (Flatpak, ungoogled Chromium from elsewhere, snap, whatever
else there is)?
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. :(
Dear Andres,
Thanks for your work for chromium!
On Mon, Jan 3, 2022 at 7:33 PM Andres Salomon <dilinger@queued.net> wrote:
I tried to backport bullseye's v97 to buster, but error below occured.Unfortunately it needs a newer nodejs than what's in buster, so I'll goI sawAh, very helpful, thanks! I'll give buster a try (just created
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):
the 'v96-buster' branch). Between that and various backports, I think
we might be in good shape.
back to focusing on bullseye & sid for now. :(
I also tired the v96-buster branch from your salsa git repo, and got
similar error.
So this is the error you mentioned above that buster's nodejs package
is too old for chromium?
Is it possible to use embed nodejs to workaround this issue?
I also guess this might be related to incompatible between system's
nodejs and embed rollup binary.
Is it possible to add a patch to replace with system's rollup?
Error from buster-backports pbuilder for bullseye's chromium v97:
====
FAILED: gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.js
python3 ../../third_party/node/node.py ../../third_party/devtools-frontend/src/node_modules/rollup/dist/bin/rollup --silent --config ../../third_party/devtools-frontend/src/scripts/build/rollup.config.js --input gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.prebundle.js
--file gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.js
--configDCHECK
Traceback (most recent call last):
File "../../third_party/node/node.py", line 36, in <module>
RunNode(sys.argv[1:])
File "../../third_party/node/node.py", line 31, in RunNode
raise RuntimeError('%s failed: %s' % (cmd, stderr))
RuntimeError: ['/usr/bin/nodejs', '../../third_party/devtools-frontend/src/node_modules/rollup/dist/bin/rollup',
'--silent', '--config', '../../third_party/devtools-frontend/src/scripts/build/rollup.config.js', '--input', 'gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.prebundle.js',
'--file', 'gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.js',
'--configDCHECK'] failed: b'[!] (plugin minify-html-template-literals) TypeError: result.matchAll is not a function\ngen/third_party/devtools-frontend/src/front_end/panels/timeline/components/WebVitalsTimeline.js\nTypeError:
result.matchAll is not a function\n at Object.minifyHTML (/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/minify-html-literals/src/strategy.ts:145:41)\n
at Object.minifyHTML (/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/scripts/build/rollup.config.js:80:37)\n
at templates.forEach.template (/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/minify-html-literals/src/minifyHTMLLiterals.ts:322:24)\n
at Array.forEach (<anonymous>)\n at Object.minifyHTMLLiterals (/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/minify-html-literals/src/minifyHTMLLiterals.ts:297:13)\n
at Object.transform (/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/rollup-plugin-minify-html-template-literals/dist/index.js:15:47)\n
at Promise.resolve.then (/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/rollup/dist/shared/rollup.js:20218:25)\n\n'
====
Cheers,
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 <dilinger@queued.net> wrote:
I tried to backport bullseye's v97 to buster, but error below occured.Unfortunately it needs a newer nodejs than what's in buster, so I'll goI sawAh, very helpful, thanks! I'll give buster a try (just created
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):
the 'v96-buster' branch). Between that and various backports, I think
we might be in good shape.
back to focusing on bullseye & sid for now. :(
I also tired the v96-buster branch from your salsa git repo, and got similar error.
So this is the error you mentioned above that buster's nodejs package
is too old for chromium?
Is it possible to use embed nodejs to workaround this issue?
I also guess this might be related to incompatible between system's
nodejs and embed rollup binary.
Is it possible to add a patch to replace with system's rollup?
Error from buster-backports pbuilder for bullseye's chromium v97:
====
FAILED: gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.js
python3 ../../third_party/node/node.py ../../third_party/devtools-frontend/src/node_modules/rollup/dist/bin/rollup --silent --config ../../third_party/devtools-frontend/src/scripts/build/rollup.config.js --input gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.prebundle.js
--file gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.js
--configDCHECK
Traceback (most recent call last):
File "../../third_party/node/node.py", line 36, in <module>
RunNode(sys.argv[1:])
File "../../third_party/node/node.py", line 31, in RunNode
raise RuntimeError('%s failed: %s' % (cmd, stderr))
RuntimeError: ['/usr/bin/nodejs', '../../third_party/devtools-frontend/src/node_modules/rollup/dist/bin/rollup',
'--silent', '--config', '../../third_party/devtools-frontend/src/scripts/build/rollup.config.js', '--input', 'gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.prebundle.js',
'--file', 'gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.js',
'--configDCHECK'] failed: b'[!] (plugin minify-html-template-literals) TypeError: result.matchAll is not a function\ngen/third_party/devtools-frontend/src/front_end/panels/timeline/components/WebVitalsTimeline.js\nTypeError:
result.matchAll is not a function\n at Object.minifyHTML (/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/minify-html-literals/src/strategy.ts:145:41)\n
at Object.minifyHTML (/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/scripts/build/rollup.config.js:80:37)\n
at templates.forEach.template (/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/minify-html-literals/src/minifyHTMLLiterals.ts:322:24)\n
at Array.forEach (<anonymous>)\n at Object.minifyHTMLLiterals (/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/minify-html-literals/src/minifyHTMLLiterals.ts:297:13)\n
at Object.transform (/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/rollup-plugin-minify-html-template-literals/dist/index.js:15:47)\n
at Promise.resolve.then (/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/rollup/dist/shared/rollup.js:20218:25)\n\n'
====
Cheers,
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 testing this stuff.
It has chromium 98.
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).
2022, ഫെബ്രുവരി 13 9:36:11 PM IST, Roger Shimizu <rosh@debian.org>ൽ എഴുതി
On Sat, Feb 12, 2022 at 2:12 AM Andres Salomon <dilinger@queued.net> wrote: >>> Yes, that's the error. "String.matchAll is only available from Node.jsI think using babel (already packaged) to transpile the js to run on nodejs 10 could be another option.
12.0 onwards", according toThanks for your confirmation!
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.
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'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'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.
❦ 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.
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).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 42:27:58 |
| Calls: | 6,648 |
| Files: | 12,193 |
| Messages: | 5,329,573 |