Package Details: librewolf-bin 123.0-1

Git Clone URL: (read-only, click to copy)
Package Base: librewolf-bin
Description: Community-maintained fork of Firefox, focused on privacy, security and freedom.
Upstream URL:
Keywords: browser web
Licenses: GPL, MPL, LGPL
Conflicts: librewolf
Provides: librewolf
Submitter: lsf
Maintainer: lsf
Last Packager: lsf
Votes: 334
Popularity: 13.95
First Submitted: 2019-06-16 13:12 (UTC)
Last Updated: 2024-02-25 00:34 (UTC)

Dependencies (16)

Sources (7)

Pinned Comments

lsf commented on 2021-11-10 12:14 (UTC) (edited on 2023-04-17 07:18 (UTC) by lsf)

gpg --keyserver hkp:// --search-keys 031F7104E932F7BD7416E7F6D2845E1305D6E801

/edit: starting with 112.0-1, the binaries are signed with the maintainers shared key, so gpg --keyserver hkp:// --search-keys 662E3CDD6FE329002D0CA5BB40339DD82B12EF16 should 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 :)

Latest Comments

1 2 3 4 5 6 .. 15 Next › Last »

MithicSpirit commented on 2024-02-12 14:40 (UTC)

@necklace all AUR packages (and PKGBUILDs in general) implicitly makedepend on base-devel, which includes debugedit.

necklace commented on 2024-02-12 06:57 (UTC)

I got a

/usr/share/makepkg/tidy/ line 48: debugedit: command not found

So, maybe consider adding debugedit to makedepends.

preconiseencaust commented on 2024-02-05 16:04 (UTC)

cp: target '/tmp/makepkg makepkg/librewolf-bin/pkg/librewolf-bin/usr/lib/librewolf': No such file or directory

I've been having trouble installing this for a little while now. Am I doing something wrong here or is this a package issue?

cprin21 commented on 2023-12-20 15:37 (UTC)

I made an account for this. An account! PLEASE STOP FLAGGING PACKAGES OUT OF DATE WHEN THEY ARE NOT. As of 10:35 AM -5 GMT 20-12-23, version 120 is the current, up to date version of librewolf and librewolf-bin. Go complain to the actual devs on the Github about this, not the AUR. These are perfectly up to date until the actual Librewolf team releases 121.

heapifyman commented on 2023-11-24 09:14 (UTC)

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."

That's a bug in librewolf. A fixed version should appear soon (maybe today?):

You can downgrade to version 119.0.1 (which does not have the bug) in the meantime if you don't want to wait.

noman commented on 2023-11-24 08:49 (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!

danielkrajnik commented on 2023-11-22 11:09 (UTC)

Has anyone else also started getting SEC_ERROR_OCSP_MALFORMED_RESPONSE from all google sites on librewolf?

lsf commented on 2023-11-01 09:30 (UTC)

@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:

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? ;)

petris commented on 2023-10-31 14:17 (UTC)

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.

ron2138 commented on 2023-08-11 11:13 (UTC) (edited on 2023-08-11 11:14 (UTC) by ron2138)

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 Bugzilla, lkml, and lxc issue.