| 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-community.gitlab.io/ |
| Keywords: | browser web |
| Licenses: | GPL, MPL, LGPL |
| Conflicts: | librewolf |
| Provides: | librewolf |
| Submitter: | lsf |
| Maintainer: | lsf |
| Last Packager: | lsf |
| Votes: | 417 |
| Popularity: | 14.52 |
| First Submitted: | 2019-06-16 13:12 (UTC) |
| Last Updated: | 2025-01-26 21:57 (UTC) |
Newbie here. Been using librewolf for few months. When updated to 120.0-1, getting a new error when opening new windows saying "Firefox is already running, but is not responding. To use Firefox, you must first close the existing Firefox process, restart your device, or use a different profile." Searched for it online but didn,t got any useful info.
Tried reinstalling but the issue persists. Also deleted the .librewolf folder in /home when reinstalling. Please help!
Has anyone else also started getting SEC_ERROR_OCSP_MALFORMED_RESPONSE from all google sites on librewolf?
@petris: thanks for that comment!
It's a bit messy with LibreWolf for two reasons though: for one, the -X notation was introduced by LibreWolf more or less due to my bad influence ;) – and with the Arch releases "back then" being somewhat the "driving releases", too, they were always quite tightly coupled with LibreWolf itself; the upstream PKGBUILD nowadays is pretty much just a mirror of this one even: https://codeberg.org/librewolf/arch/src/branch/master/AUR/librewolf/PKGBUILD
We don't run a CI for Arch binary releases anymore though (and don't provide a repo anymore as well), so that rather tight coupling would probably not be necessary anymore indeed.
Where an alternative way would still get messy though is with Firefox' own versioning: you can have 119.0 and 119.0.1, 119.0.2 upstream releases, too (which LibreWolf follows), so 119.0.1 for 119.0-1 would clash with 119.0.1 (119.0.1-1), for example.
My approach thus for now has been, for simplicity's sake, to just stick with LibreWolf's own naming including the what-would-be-pkgrel-numbering, and adding an extra number (like Manjaro does sometimes, for example) for the rare cases (like: 119.0-1.1) where we'd have a separate Arch/AUR extra release. This usually shouldn't happen anymore very much, as we've streamlined the upstream source preprocessing a while back, so these releases deviate much less from one another, and Arch/AUR release handling still being a "first class" thing upstream anyway.
With all that said though: Would fixing that just be "nice to have, because it'd be cleaner, according to the PKGBUILD specs" (which would be totally valid, too), or would keeping it that way cause issues somewhere? (granted: while typing all this, I could've probably already changed it and tested it twice. Maybe I'm just reluctant to touch smoothly working things? ;)
I just wanted to note that it appears you're using the pkgrel field to indicate part of an upstream version number, however that's not what the pkgrel field is for. Per the PKGBUILD wiki:
The release number. This is usually a positive integer number that allows to differentiate between consecutive builds of the same version of a package. As fixes and additional features are added to the PKGBUILD that influence the resulting package, the pkgrel should be incremented by 1. When a new version of the software is released, this value must be reset to 1. In exceptional cases other formats can be found in use, such as major.minor.
Thus this should generally be 1 unless you need to rebuild a specific version for some reason, such as a change or fix in the PKGBUILD, bumping for dependent library versions like python, etc.
I know that the librewolf project is using -X to indicate some minor version, and that you can't use a dash in the actual package version, however you could always change this to something like 119.0.7 or 119.0r7 or similar. Note that according to vercmp, version XX > XXrX (119.0 is greater than 119.0r2 for instance), so if you go with the r version you'll want to wait until the next major release, otherwise the dot notation would work.
With 116.0.2-1, and probably with earlier versions too, I get
kernel: memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL, pid=538 'librewolf'. Can I assume it is already reported in the appropriate places, or should I report that? If so, where to? Isn't it a Firefox source code issue? The kernel message was already discussed a lot. For example, at Kernel.org Bugzilla, lkml, and lxc issue.
To fix icon issues in KDE Plasma Wayland, add the following symlink. The desktop file name needs to match the app-id Wayland property.
ln -srvf "$pkgdir/usr/share/applications/librewolf.desktop" "$pkgdir/usr/share/applications/LibreWolf.desktop"
rebuild-detector is complaining about librewolf-bin as of 2023-08-02. The reason is:
ldd /usr/lib/librewolf/gmp-clearkey/0.1/libclearkey.so
libmozsqlite3.so => not found
Hi, I installed librewolf-bin and the resulting /usr/lib/librewolf/librewolf.cfg file does not contain the defaultPref to load the librewolf.overrides.cfg file. I checked in the sources of the librewolf package and this is what I found and copied into my librewolf.cfg file to make the overrides work :
/** [CATEGORY] OVERRIDES
* allow settings to be overriden with a file placed in the right location
* https://librewolf.net/docs/settings/#where-do-i-find-my-librewolfoverridescfg
*/
let profile_directory;
if (profile_directory = getenv('USERPROFILE') || getenv('HOME')) {
defaultPref('autoadmin.global_config_url', `file://${profile_directory}/.librewolf/librewolf.overrides.cfg`);
}
This should be included in the default librewolf.cfg file that comes with package librewolf-bin.
Thanks.
It appears that the latest version 114.0.1-2 broke support for FIDO2 / webauthn?
There's an upstream issue in firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1836722
As a workaround one can set security.webauthn.ctap2 to false in about:config.
A fix seems to be planned for firefox 116
Pinned Comments
lsf commented on 2021-11-10 12:14 (UTC) (edited on 2023-04-17 07:18 (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 :)