We're seeing the same with anaconda webui - any invocation of node leads to segmentation fault - npm, npx... nothing works.
On Tue, May 2, 2023 at 11:28 AM Sandro Mani <manisandro@xxxxxxxxx> wrote:
_______________________________________________
On 02.05.23 11:24, Iñaki Ucar wrote:
On Tue, 4 Apr 2023 at 16:23, Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:On Tue, Apr 4, 2023 at 9:45 AM Sérgio Basto <sergio@xxxxxxxxxx> wrote:On Thu, 2023-03-16 at 11:19 -0400, Stephen Gallagher wrote:On Wed, Mar 15, 2023 at 1:16 PM Jerry James <loganjerry@xxxxxxxxx>...I found a problem related with yarnpkg rpm, the macro % __find_requires finds that yarn scripts uses and needs /usr/bin/node , which is added to the requires of rpm [1] and this makes yarnpkg pull nodejs (18) even when nodejs20 is installed . To avoid this rpm automatic requires, we may add to yarnpkg.spec [2] [2] %global __script_requires %{nil} [1] dnf repoquery yarnpkg --available --requires -q /usr/bin/bash /usr/bin/node /usr/bin/shI'm not sure what you think is a bug here? Do you think `yarnpkg` should use *any* nodejs version that's installed? The whole point of the way this is broken down is that we have a default version (18, in this case) with the option to install 16 and 20 in parallel, but you have to do extra work if you want to *use* those non-default versions (such as patching shebang lines).This is broken again in rawhide: $ dnf -qy install yarnpkg $ ll /usr/bin/node* lrwxrwxrwx. 1 root root 7 Apr 28 00:00 /usr/bin/node -> node-20 -rwxr-xr-x. 1 root root 28272 Apr 28 00:00 /usr/bin/node-20 lrwxrwxrwx. 1 root root 39 Mar 21 00:00 /usr/bin/nodejs-yarn -> ../lib/node_modules_19/yarn/bin/yarn.js If yarn should be pinned to a node version, please rebuild yarn when there's a major version change. And it would be nice if there's a mechanism to detect such a breakage. I.e. a nodejs(abi) version or something like that.AFAICS nodejs is generally broken in rawhide (both nodejs20 and nodejs18), i.e. just
$ node
> <type random chars and press backspace a couple of times>
Segmentation fault (core dumped)gdb:
Thread 3 "node" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff2ffe6c0 (LWP 1565850)]
0x00007ffff57db195 in v8::internal::compiler::SpecialRPONumberer::ComputeAndInsertSpecialRPO(v8::internal::compiler::BasicBlock*, v8::internal::compiler::BasicBlock*) () from /lib64/libnode.so.115
Sandro
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
Vladimír Slávik <vslavik@xxxxxxxxxx>
Software Engineer, Platform EngineeringRed Hat Czech, s.r.o.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue