On 2022-11-24 14:18, Martin Jansa wrote:
On Thu, Nov 24, 2022 at 7:06 PM Randy MacLeod
<randy.macl...@windriver.com> wrote:
Add Armin to ensure he seems this once he recovers from US
Thanksgiving indulgences.
On 2022-11-24 12:05, Martin Jansa wrote:
I see this is now queued in kirkstone-next
https://git.openembedded.org/meta-openembedded/commit/?h=kirkstone-next&id=08b6b6846a84d9a0459f42d1d730c9ea1d50c43f
<https://urldefense.com/v3/__https://git.openembedded.org/meta-openembedded/commit/?h=kirkstone-next&id=08b6b6846a84d9a0459f42d1d730c9ea1d50c43f__;!!AjveYdw8EvQ!bcx80wmigop8Eoea7TohEOVlX1wPfDp0MAiO-8lZQDzv5nw5ai-FPfVsVaCxBstk-GtvN-eKnWtaUipHYjAMDDlyDWE$>
I see bunch of recipes failing since this upgrade landed in
master, mostly due to npm dependency resolution being more strict
now and builds failing with
npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
...
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken)
dependency resolution.
Can we please delay backporting to kirkstone and langdale a bit more?
Seconded!
What recipes encounters this bug?
I've seen it in ~10 recipes, but all are internal and not available in
any public layer. I've added --force to them as work around to see how
many other recipes will start failing now.
There is one more failing from public layer:
https://github.com/webosose/meta-webosose/blob/master/meta-webos/recipes-webos/localization-tool/localization-tool-native.bb
<https://urldefense.com/v3/__https://github.com/webosose/meta-webosose/blob/master/meta-webos/recipes-webos/localization-tool/localization-tool-native.bb__;!!AjveYdw8EvQ!fVXXP6WGpCWaykh_uWoklqQArJCJQ7A5_YHNHIuOJVZwFc536QpaNTNkS-6VpmURy5ZCL16s1QAAg5Wsei1dqCoqFPA$>
but that's different issue, caused by the sysroot_stage_all:append()
and new nodejs now installing node_gyp_bins with symlink to python3
causing:
ERROR: localization-tool-native-1.7.0-r7 do_populate_sysroot: sstate
found an absolute path symlink
/OE/work/x86_64-linux/localization-tool-native/1.7.0-r7/sysroot-destdir/OE/work/x86_64-linux/localization-tool-native/1.7.0-r7/recipe-sysroot-native/opt/js-loctool/node_modules/node-expat/build/node_gyp_bins/python3
pointing at /OE/hosttools/python3. Please replace this with a relative
link.
But I haven't narrowed it down yet to see which exact nodejs/npm
change caused this. And yes this recipe has other issues as well and
doesn't even use npm.bbclass nor npmsw:// fetcher.
And if others are seeing similar failures please share them here
as well.
The older nodejs was using npm@8.5.0, now its npm@8.19.2 more
details about this change in behavior from 8.6.0 in
https://github.com/npm/cli/issues/4998
<https://urldefense.com/v3/__https://github.com/npm/cli/issues/4998__;!!AjveYdw8EvQ!bcx80wmigop8Eoea7TohEOVlX1wPfDp0MAiO-8lZQDzv5nw5ai-FPfVsVaCxBstk-GtvN-eKnWtaUipHYjAMZmTsAyk$>
Someone in the linked issue thread said:
"We rolled back to Node v16.15.0, which has a working
version of npm 8.5.5."
Should we drop the 16.18.x update and stick with 16.15.1 for
kirkstone/langdale?
I don't mind keeping it in master, once I figure out how to fix it in
master I wouldn't mind it getting backported to kirkstone and langdale
as well.
This was just warning that this isn't just simple minor upgrade for
some and at least some longer delay would be useful.
For master, I'd like to update to 18, 19, or ideally 20 if it's
available before the end of M3.
Martin,
What version of node make sense to you for master?
I don't have strong opinion, we have a lot of ugly npm/nodejs recipes
in webOS which need to be re-worked first, independently on nodejs
version used.
Do you agree that we should leave master on 16.18.x and people
should fix their
'broken' npm dependencies?
Yes, from that npm bug it looks, that the old behavior was even worse
than the current clear failure and the --force as work around seems to
work reasonably well, so I don't mind keeping it in master and even
eventually backporting it to kirkstone a bit later.
How about 2 weeks later?
We need to either backport a patch or update to 16.18.1 to fix
CVE-2022-35255
$ git log --oneline -1 a54283a6387
a54283a638 crypto: fix weak randomness in WebCrypto keygen
$ git branch -a --contains a54283a6387
* v16.x
remotes/origin/backport-avoid-prototype-pollution
remotes/origin/v16.19.0-proposal
remotes/origin/v16.x
remotes/origin/v16.x-staging
$ git tag --contains a54283a6387
v16.17.1
v16.18.0
v16.18.1
My vote is to upgrade since people have had some time to fix their
dependencies.
../Randy
Cheers,
--
# Randy MacLeod
# Wind River Linux
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#100061):
https://lists.openembedded.org/g/openembedded-devel/message/100061
Mute This Topic: https://lists.openembedded.org/mt/95118333/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
