Package Details: librewolf-bin 133.0.3-1

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: 407
Popularity: 10.84
First Submitted: 2019-06-16 13:12 (UTC)
Last Updated: 2024-12-15 09:43 (UTC)

Dependencies (16)

Required by (28)

Sources (7)

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

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 19 Next › Last »

ignxcy commented on 2024-04-13 10:23 (UTC)

Why is it marked out of date??

rehhouari commented on 2024-03-21 01:25 (UTC)

Why does this automatically set it as the default browser in KDE Plasma 6?

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/strip.sh: 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?):

https://codeberg.org/librewolf/issues/issues/1673#issuecomment-1347478

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

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 19 Next › Last »