Arch Linux User Repository

cherradiyacyn: Can you elaborate beyond "a config file"? That would let us see what's wrong specifically.

Hi, I use a config file to set "JetBrains Mono NL" as the default serif, sans-serif, monospace, and system-ui font of my system. all apps use that. except Turbowarp. (It actually did before the update).

My question : is that a ME issue ? or/and is there any advice ? Thanks.

Starlii10: It's fine since we stayed on the same major version of Electron.

Depending on how often you upgrade packages, you might see a warning about downgrading. Check what it says at the debug information section. If it's "E 42.3.0 -> 42.2.0" (where it starts with "E" and both numbers are 42 dot something), that's fine.

You can back up ~/.config/turbowarp-desktop (from memory - not on a Linux system right now to verify) if your backpack is important (maybe do that anyway)

Just to make sure, is it safe to open the latest update with the Electron changes? I would assume it is, but I don't really want to risk my backpack, so better safe than sorry.

I'm switching this package from using Arch's shared system copy of Electron to using the prebuilt Electron binaries from the TurboWarp release tarballs due to a series of issues, including two major regressions in the last month. Planning to reconsider in 1.17.0.

It appears that the Arch packaging of electron42 is broken and crashes if we try to display any popup/alert. I'll try to report that, but this isn't something we can fix ourselves. You do have some immediate options for workarounds:

• replace electron42 from official repos with electron42-bin from the AUR because the official Electron builds do not crash, or
• checkout to the previous commit to install 1.15.5 instead (note that we make no promises about backwards compatibility for data stored in places such as the backpack)
• use the Flatpak instead

This is now the second time in a month that using the official Arch packages for Electron have caused major regressions for us (the previous being upstream Electron shipping a breaking change in a minor version bump release, causing our extensions to stop working). I am reconsidering this approach.

As of 1.15.0, the package uses Electron 38 which uses Wayland by default. Usually, this causes no real issues, but we've received several reports of Wayland-only bugs in the last couple weeks. If you see weird behaviors or crashes, try starting with environment variable XDG_SESSION_TYPE=x11 or command-line argument --ozone-platform=x11 to make it use Xwayland as before. You can put either of those into a desktop file override to make it permanent.

thank u for your efforts in this one!

@0xmrtt This is very very late but the wayland segfault is fixed now

@0xmrtt That looks like an issue in Electron or your graphics drivers. Does electron20 open successfully?