| Git Clone URL: | https://aur.archlinux.org/librewolf-bin.git (read-only, click to copy) |
|---|---|
| Package Base: | librewolf-bin |
| Description: | Community-maintained fork of Firefox, focused on privacy, security and freedom. |
| Upstream URL: | https://librewolf.net/ |
| Keywords: | browser web |
| Licenses: | MPL-2.0 |
| Conflicts: | librewolf |
| Provides: | librewolf |
| Submitter: | lsf |
| Maintainer: | lsf |
| Last Packager: | lsf |
| Votes: | 644 |
| Popularity: | 19.83 |
| First Submitted: | 2019-06-16 13:12 (UTC) |
| Last Updated: | 2026-07-15 08:05 (UTC) |
I'm experiencing crashes in both LibreWolf 72 and 73 since updating other packages Friday. I'm not sure, but I'm thinking this may be related to the glibc update to 2.31.
The crashes happen when I try to open a .desktop file with LibreWolf or when I try to open an RSS feed entry from Liferea.
Update on 26 February 2020: this issue seems to have resolved itself in the meantime. It was likely some other Arch package that was generating problems.
Already noted, thanks to mwohah – will be fixed soon :)
the Exec= parameter in, the .desktop file points to the incorrect binary (/usr/lib/librewolf/firefox) instead of /bin/librewolf
Thanks for finding those wrong entries, I'll prepare a new release with a fixed file soon.
About your issue: /usr/share/applications should be the correct directory (it's an xdg-standard-directory, iirc).
You might try a (sudo) update-desktop-database, which should re-scan your .desktop files – I think this normally happens at the end of the package installation, too.
I tried placing that in my .local/share/applications folder, but it still didn't show up.
I did some tinkering with it and I think I figured out what the problem is: the file still mentions /usr/lib/librewolf/firefox at three locations instead of /usr/lib/librewolf/librewolf.
After changing that, it shows up properly in GNOME. I tried applying the same changes directly in /usr/share/applications/librewolf.desktop, but it didn't show up either, perhaps this is not a folder that GNOME scans?
Hm, that's odd.
Currently the librewolf-bin.desktop file is indeed not used, I'll probably remove it in the next version.
At the moment this package just uses a prebuilt binary built with the librewolf PKGBUILD, which already includes the librewolf.desktop file in the proper place.
At some later point this package might switch to using an 'upstream' binary, which is when it might be needed again.
But more the the point, or rather to your problem: Even though the '-bin' desktop file is not used, the regular one is, and at least on my system can be found in /usr/share/applications/librewolf.desktop (and LibreWolf appears in the (xfce-)menu). Could you check if it's there on your system as well?
It should be; on my system pacman -Qo /usr/share/applications/librewolf.desktop shows it as being installed by this package (/usr/share/applications/librewolf.desktop is owned by librewolf-bin 67.0.2-4).
Thanks for this package!
LibreWolf doesn't seem to show up in the applications menu on GNOME. I think the desktop file is being downloaded, but not installed anywhere, is that possible?
Pinned Comments
lsf commented on 2021-11-10 12:14 (UTC) (edited on 2026-05-07 09:38 (UTC) by lsf)
https://wiki.archlinux.org/title/Arch_User_Repository#Acquire_a_PGP_public_key_if_needed
gpg --keyserver hkp://keyserver.ubuntu.com --search-keys 031F7104E932F7BD7416E7F6D2845E1305D6E801/edit: starting with 112.0-1, the binaries are signed with the maintainers shared key, so
gpg --keyserver hkp://keyserver.ubuntu.com --search-keys 662E3CDD6FE329002D0CA5BB40339DD82B12EF16should do the trick instead. I've also signed the key with the previously used key, so you have at least some guarantee that it's not a malicious attack :)/edit: (2026-05-07): The upstream signing sub-key was rotated, and the
.tar.xztarballs will now be signed with a new subkey. The main key id (0x662E3CDD6FE329002D0CA5BB40339DD82B12EF16) remains unchanged though, so should you get an error during signature verification about a missing (sub)key, all that's required would be to refresh the key(s) viagpg --refresh-keys 662E3CDD6FE329002D0CA5BB40339DD82B12EF16.