Package Details: librewolf 1:150.0.3_1-1

Git Clone URL: https://aur.archlinux.org/librewolf.git (read-only, click to copy)
Package Base: librewolf
Description: Community-maintained fork of Firefox, focused on privacy, security and freedom.
Upstream URL: https://librewolf.net/
Keywords: browser web
Licenses: MPL-2.0
Submitter: lsf
Maintainer: lsf
Last Packager: lsf
Votes: 217
Popularity: 5.75
First Submitted: 2019-06-14 18:41 (UTC)
Last Updated: 2026-05-13 07:43 (UTC)

Sources (8)

Pinned Comments

lsf commented on 2025-01-01 21:28 (UTC)

Please refrain from abusing the flagging of a package as out of date for build issues. This is not what it is supposed to be used for.

I automatically get notified of comments to this package. I do not need to be notified of whatever build problems occur (whether they are an individual's problems or the actual package's problems) twice, and not via flagging it out of date.

Issues with this package can also be reported at https://codeberg.org/librewolf/issues/issues (as it is also maintained there, at https://codeberg.org/librewolf/arch, too).

Latest Comments

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

CryogEnix commented on 2025-03-09 23:49 (UTC) (edited on 2025-03-10 01:11 (UTC) by CryogEnix)

No matter what I do, I can't get past the instrumented build stage – I always run out of memory (journalctl: "Out of memory: Killed process 12576 (rustc)") It causes the build to stall for a while (can be 10min+), fail with: "error: could not compile 'firefox-on-glean (lib)'" "Caused by: process didn't exit successfully" [followed by a bunch of folders] and end in 4 "make[]: ***" errors and "23 compiler warnings" or simply hang until I forcibly poweroff the PC. Not to mention the number of deprecated items ("warning: 'deprecated pre-processor symbol'", "'gtk-key-snooper-removed' is deprecated" and "warning: 'gdk-color-parse' is deprecated", to name a few I could take note of) that appear. Unlike a previous user here from 2023, I don't use virtualization—NeWolf had roughly the same string of issues I have, only it doesn't seem to have anything to do with 'gkrust' specifically.

This happens even when logging out of desktop and into tty (only ~400 MiB used), with MAKEFLAGS="-j1" (setting this slightly improves compilation while commenting MAKEFLAGS does not help).

What is PGO and, if I disable it, how should I adjust the package for missing the policies.json, as suggested by OdinVex?... I'm beginning to wonder if I have the right hardware to compile something like a browser... (ô_ ô)

I do not use mold linker and have set "-march=native -02 -pipe" in CFLAGS along with "${CFLAGS}" in CXXFLAGS. I've also disabled "debug" and "lto" options in my makepkg.conf, though I believe the PKGBUILD should be overriding these anyway?

CARCH -- x86_64
CPU -- Intel i7-3630QM (8 cores) @3.400GHz
Memory -- 8GiB
Kernel -- 6.13.2-arch1-1
Manufacturer -- SAMSUNG ELECTRONICS CO

Cusith commented on 2025-03-04 14:27 (UTC)

Just to let you know that the current signing key is mentioned here https://librewolf.net/installation/fedora/ its: '662E3CDD6FE329002D0CA5BB40339DD82B12EF16'

OdinVex commented on 2025-03-02 09:15 (UTC)

@lsf, Paru sounds helpful, I'll check into it. There are several packages I'd love to not need to bother mirroring with patches and such. Thank you very much for that reference.

lsf commented on 2025-03-02 09:14 (UTC)

@OdinVex: that is a bit of a "downstream issue" though. Usage of AUR helpers is to varied to accommodate broadly. While some AUR helpers (like paru) would even allow persistend modifications (which would then be rebased on updates) to the PKGBUILDs, to give you a potential different approach to handle this.

OdinVex commented on 2025-03-02 09:11 (UTC)

@xiota, I've experienced otherwise setting variables this way. I'll stick to editmenu for LibreWolf until PGO stops breaking for me.

OdinVex commented on 2025-03-02 09:09 (UTC)

@lsf, Well aware, but that requires I manually intervene every time to set those variables since I simply want to yay -Syu. No, it does pollute every process started by the shell (using export to ensure sub-processes get the variable).

lsf commented on 2025-03-02 09:07 (UTC)

@OdinVex: you can declare those variables temporarily in your current shell session only, or, the way @xiota gave as examples, even solely for one command. Nowhere was it suggested to set those variables session-, user-, or system-wide.

OdinVex commented on 2025-03-02 08:48 (UTC)

@xiota, Those strings are far too generic to set via environmental variables, not to mention that pollutes every process now being loaded with an environmental variable that is only used during an pkg compile. It'd be a poor idea to try to use something like that for a single package. A system-wide variable to disable .NET spyware/call-home? Sure. But not this.

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