Package Details: ferdium-bin 7.1.1-3

Git Clone URL: https://aur.archlinux.org/ferdium-bin.git (read-only, click to copy)
Package Base: ferdium-bin
Description: A messaging browser that allows you to combine your favorite messaging services into one application (binary release).
Upstream URL: https://ferdium.org
Licenses: Apache
Conflicts: ferdium, ferdium-beta, ferdium-beta-bin, ferdium-electron, ferdium-git, ferdium-nightly, ferdium-nightly-bin
Provides: ferdium
Submitter: cedricroijakkers
Maintainer: cedricroijakkers
Last Packager: cedricroijakkers
Votes: 41
Popularity: 0.72
First Submitted: 2022-04-22 10:05 (UTC)
Last Updated: 2026-01-09 13:29 (UTC)

Pinned Comments

cedricroijakkers commented on 2022-06-13 06:54 (UTC)

Note: This package follows the latest release package on the GitHub releases page of ferdium-app (https://github.com/ferdium/ferdium-app/releases). A tag in the git repo does not always mean a new binary release will be created. If you wish to follow the latest tag in git and build Ferdium yourself, use the AUR package ferdium instead.

Latest Comments

1 2 3 4 5 6 Next › Last »

cedricroijakkers commented on 2026-01-09 13:31 (UTC)

@davidszp: Good catch with the autostart file. I have just pushed a patch, that issue should be fixed now.

davidszp commented on 2026-01-09 11:02 (UTC)

Autostart creates broken desktop entry (system electron path issue)

Hi, thanks for maintaining this package! I ran into an issue with the autostart feature and did some digging - I believe it's patchable at the package level.

The Problem

When enabling "Launch on start" in Ferdium settings, it creates a broken autostart entry:

~/.config/autostart/electron.desktop

With contents: [Desktop Entry] Type=Application Version=1.0 Name=electron Comment=electronstartup script Exec=/usr/lib/electron37/electron StartupNotify=false Terminal=false

This launches the bare Electron welcome screen on boot instead of Ferdium.

Root Cause

Ferdium uses the auto-launch npm package, which calls process.execPath to determine the executable. With bundled Electron (upstream releases), this returns the Ferdium binary. With system Electron (this package), it returns /usr/lib/electron37/electron.

Proposed Fix

The auto-launch package allows overriding the path. In the extracted app, likely in node_modules/auto-launch/dist/index.js or wherever the AutoLaunch constructor is called, the path could be patched to explicitly use /usr/bin/ferdium.

Something like: sed -i 's|process.execPath|"/usr/bin/ferdium"|g' /opt/ferdium/node_modules/auto-launch/...

Or patch wherever Ferdium instantiates AutoLaunch to pass {path: '/usr/bin/ferdium'}.

Current Workaround

Disable autostart in Ferdium, then manually: cp /usr/share/applications/ferdium.desktop ~/.config/autostart/

Happy to help test if you'd like to try a patch. Cheers!

leny commented on 2025-12-29 21:07 (UTC) (edited on 2026-01-13 11:35 (UTC) by leny)

After latest update with electron37 it's unusable. Mattermost does not load (freezes when loading chats). A lot of:


gru 29 22:05:13 arch ferdium[11986]: Error sending from webFrameMain:  Error: Render frame was disposed before WebFrameMain could be accessed
gru 29 22:05:13 arch ferdium[11986]:     at s.send (node:electron/js2c/browser_init:2:94216)
gru 29 22:05:13 arch ferdium[11986]:     at b.send (node:electron/js2c/browser_init:2:78654)
gru 29 22:05:13 arch ferdium[11986]:     at node:electron/js2c/browser_init:2:102385
gru 29 22:05:13 arch ferdium[11986]:     at node:electron/js2c/browser_init:2:101558
gru 29 22:05:13 arch ferdium[11986]:     at Session.<anonymous> (node:electron/js2c/browser_init:2:107040)
gru 29 22:05:13 arch ferdium[11986]:     at Session.emit (node:events:519:28)

And also dumps core, which fills whole disk

gru 29 22:01:00 arch ferdium[8670]: thread '<unnamed>' panicked at ../../third_party/rust/chromium_crates_io/vendor/skrifa-v0_29/src/outline/glyf/hint/engine/outline.rs:650:12:
gru 29 22:01:00 arch ferdium[8670]: attempt to multiply with overflow
gru 29 22:01:00 arch ferdium[8670]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
gru 29 22:01:00 arch systemd-coredump[9826]: Process 8670 (electron) of user 1000 terminated abnormally with signal 6/ABRT, processing...
gru 29 22:01:51 arch drkonqi-coredump-processor[9829]: "/usr/lib/electron37/electron" 8670 "/var/lib/systemd/coredump/core.electron.1000.55a6a16291c64cc59d3c00c435d4b72d.8670.1767042060000000.zst"
gru 29 22:01:51 arch systemd[1270]: Started Launch DrKonqi for a systemd-coredump crash (PID 9829/UID 0).
gru 29 22:01:51 arch systemd[1]: drkonqi-coredump-processor@3-2-9826_9827-0.service: Deactivated successfully.
gru 29 22:01:51 arch drkonqi-coredump-launcher[11501]: Unable to find file for pid 8670 expected at "kcrash-metadata/electron.55a6a16291c64cc59d3c00c435d4b72d.8670.ini"
gru 29 22:01:51 arch drkonqi-coredump-launcher[11501]: Nothing handled the dump :O
gru 29 22:01:56 arch systemd-coredump[9797]: [🡕] Process 8693 (electron) of user 1000 dumped core.

                                             Stack trace of thread 8693:
                                             #0  0x00007efd4bc9890c n/a (n/a + 0x0)
                                             ELF object binary architecture: AMD x86-64
gru 29 22:02:30 arch systemd-coredump[12751]: Cannot store coredump of 12680 (electron): No space left on device
gru 29 22:02:30 arch systemd-coredump[12757]: Cannot store coredump of 12673 (electron): No space left on device
gru 29 22:02:30 arch systemd-coredump[12751]: [🡕] Process 12680 (electron) of user 1000 terminated abnormally without generating a coredump.

EDIT: Looks like the issue is with extra/electron37. Installed aur/electron37-bin and it works fine now.

aur/electron37-bin 37.10.3-1
extra/electron37 37.5.1-1

mistersmee commented on 2025-11-04 17:33 (UTC)

@cedricroijakkers, update the electron version to 37, upstream moved to it with 7.1.1.

To avoid this sort of mismatch, imo it would be better to link the dependency to just plain electron, instead of pinning it to a specific version, it is not as if electron has major breaking changes per every version, and I don't think that upstream has version specific code.

pqatsi commented on 2025-10-22 23:23 (UTC)

Hmmm, aparently needs to conflict with nodejs-lts-iron as example

pqatsi commented on 2025-10-22 23:16 (UTC)

Building ferdium-bin 7.1.0 leads to follow error:

CANNOT RUN WITH NODE 20.19.5 asar requires Node >=22.12.0.

Packages installed by this package are:

extra/asar 4.0.1-1 3,64 MiB 0,37 MiB extra/electron35 35.7.5-1 270,56 MiB 81,03 MiB

PhotonX commented on 2025-04-14 10:51 (UTC) (edited on 2025-04-14 10:52 (UTC) by PhotonX)

It looks like the issue is fixed in electron35. I just edited ferdium's starter script for now to use electron35. It will be overwritten on the next ferdium-bin update but I assume that this will change to electron35 anyway.

Thanks for your support!

cedricroijakkers commented on 2025-04-14 10:36 (UTC)

I would have found it unlikely to be ferdium itself, since it's electron that is responsible for the screen rendering etc. If you submit the issue to electron upstream, you should be able to reproduce it by just running the electron executable itself also: /usr/bin/electron34

PhotonX commented on 2025-04-14 10:33 (UTC)

Damn, it's indeed electron34. Sorry for the confusion. I'll try to downgrade it as far as possible to find the exact minor version where the issue started appearing.

cedricroijakkers commented on 2025-04-14 10:24 (UTC)

Technically that would be untested, but I honestly don't think you would run into a lot of issues, so if the combo 7.0.1 + electron33 works for you, I would use that for now.