Arch Linux User Repository

Confirming 3.3.0-2 with vendored electron works here (clean launch, session restored). Thanks for the quick turnaround. For the record: my 3.3.0-1 build from Jul 9 did end up with a generic electron dep (pacman -Qi showed Depends On: libsecret electron), so the detection did fail on at least one machine — but with vendored as default that's moot now.

Version 3.3.0-2 defaults to vendored electron since electron38 was dropped from the extra repo. Users who prefer system electron, read the PKGBUILD. (Hint: Change a variable before building.)

@roarch That analysis is entirely wrong. In future, please provide actual error messages or supporting evidence.

$ pacman -Qi tradingview | grep -E '^(Name|Version|Depends|Build)'
Name            : tradingview
Version         : 3.3.0-1
Depends On      : libsecret  electron38
Build Date      : Tue 14 Jul 2026 05:26:37 PM

Package (3.3.0-1) crashes on launch with "App has crashed due to problem with your system configuration" — reproducible on a fresh install, no custom flags needed.

Root cause: the Electron-version sniff in package() is broken:

local _electron_version=$(strings "$_pkgsrc/tradingview" | grep -Pom1 'Electron/\K[0-9]+')
depends+=("electron${_electron_version}")
...
exec electron${_electron_version} "${flags[@]}" "/usr/lib/$_pkgname/app.asar" "$@"

The Electron/NN string is no longer present in the current snap's tradingview binary (checked snap rev 72, pkgver 3.3.0), so _electron_version evaluates to empty. Both the dependency and the launcher's exec line silently fall back to plain electron — whatever generic version happens to be installed — instead of the version the snap actually needs.

That matters because the bundled native addon (app.asar.unpacked/native/tvdbridge.node) is built against a specific Node ABI and fails to load under any other Electron major, which is what produces the crash dialog. Confirmed via the snap's own bundled runtime (ELECTRON_RUN_AS_NODE=1 ./tradingview -e "console.log(process.versions)"):

"modules": "139",
"electron": "38.2.2",
"chrome": "140.0.7339.133"

i.e. snap rev 72 needs electron38, not whatever electron currently resolves to (currently electron43/ABI 148 in extra).

Suggested fix — make the detection resilient, e.g. pull the version from the bundled Chromium/Node ABI instead of a strings grep for a string format that's apparently been dropped:

local _electron_version=$(ELECTRON_RUN_AS_NODE=1 "$_pkgsrc/tradingview" -e 'process.stdout.write(process.versions.electron.split(".")[0])')

and ideally fail the build loudly ([[ -n "$_electron_version" ]] || { error "could not detect electron version"; return 1; }) instead of silently degrading to unpinned electron, so this doesn't regress again on the next snap revision.

Note electron38 has already rotated out of extra; electron38-bin in the AUR is a workable stopgap for anyone hitting this now.

Just want to mention version 2.7.2-1 works without problems on linux 6.12.61-1-MANJARO. Recent updates within the container appeared without problems (pinescript button now appears on the right margin for split-window edits to custom script code).

We have to move to a snap or flatpak solution unless someone knows how to solve for the glibc incompatibility.

It seems that the new version 2.14 cannot work on current Arch due to glibc incompatibility and its causing segmentation fault in LoggerService.

I am trying to see if there is a way to work around it and will update once I resolve.

a new package of tradingview has arrived. Please update it.

Had just created an AUR account to bring this up to latest - great to see that its being maintained!