Package Details: librewolf 1:136.0.0_2-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: 166
Popularity: 19.03
First Submitted: 2019-06-14 18:41 (UTC)
Last Updated: 2025-03-06 09:03 (UTC)

Sources (3)

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

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

CryogEnix commented on 2025-03-10 05:01 (UTC) (edited on 2025-03-10 16:50 (UTC) by CryogEnix)

@xiota Thanks—I already had SWAP in my fstab, just enabled zswap and disabled PGO.

You mean setting "mk_add_options MOZ_PARALLEL_BUILD=<value>" in the PKGBUILD, correct? I assume in "weaker build systems" section? (You've suggested something similar for icecat.)

UPDATE After setting the value to 4, I can report a significant change—it got to "Finished 'release' profile [optimized] target(s) in 24m 44s" as opposed to failing the build at 8-10 min. Still going...

At roughly 90 minutes, this appears several times, still during compilation tier... I think this is normal?:

"ld.lld: warning: Linking two modules of different target triples:'../../../../../<item>' is '<item>' whereas '../../../<item>' is '<item>'"

113 minutes in – it got to misc tier...

The package has been successfully built :)

xiota commented on 2025-03-10 00:31 (UTC) (edited on 2025-03-10 00:37 (UTC) by xiota)

@CryogEnix Easiest way to build this on your machine would be to disable PGO. The issue with policies.json should be resolved in the current version. Alternatively, you can use a prebuilt binary through aur/librewolf-bin.

PGO = profile guided optimization. It provides a 10-20% boost on benchmarks, but takes about 3x as long to build because there are three stages: initial build, profiling, and optimized build. The build system normally uses an appropriate number of cores based on available RAM. Approximately 1-1.5 GiB per core are required. Make sure swap and zswap are both enabled. You can reduce the number of cores by setting MOZ_PARALLEL_BUILD.

Linking libxul.so with LTO has been reported to use 30GiB, single threaded with a different Firefox fork.

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'

xiota commented on 2025-03-02 21:50 (UTC)

For anyone waiting for someone else to build first... I've successfully built 135.0.1_1-1 with PGO+wlheadless-run and with PGO disabled. Did not test with PGO+xvfb because rebuilds are time consuming and wayland is the future.

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

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