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.63
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 .. 37 Next › Last »

xiota commented on 2025-07-08 00:57 (UTC)

_build_profiled controls whether package is built with PGO (profile guided optimization; 20% performance boost on benchmarks in exchange for 3x build time). If set to anything but "true", package will be built without PGO.

_build_profiled_xvfb controls whether the profiling environment is Xvfb or Weston. If anything but "true", Weston is used. I haven't seen any significant performance difference.

I'd use the default, unless profiling fails. Then try with Xvfb. If that still fails, try with PGO disabled.

je-vv commented on 2025-07-07 18:07 (UTC)

@lsf if using _build_profiled_xvfb:=true rather than _build_profiled:=true? does it mean Librewolf would only be optimized for X11? Meaning if one needs support for both, then one should have both variables in true? I built it fine on clean chroot (I don't even remember how long it took on the fastest box I have), but with the xvfb variable set to true and the other profiled variable set to false. I guess this means it's optimized just for X11, is that it?

I get what pgo build means (actually PGO), but I'm not clear if it means we can only optimize for GUI targets and not Librewolf independently of the target. Sorry if this has been answered before.

Thanks !

JBourne commented on 2025-06-09 19:52 (UTC) (edited on 2025-06-09 19:57 (UTC) by JBourne)

My issue appears to be a malformed call to rustc --create-name firefox_on_glean during the make process. An embed flag pasted as "-Cembed-bitcode=yes" instead of "-C embed-bitcode=yes" which results in a process kill. I confirmed by running the full command in the source directory after build failure. Any thoughts to correct this?

xiota commented on 2025-06-06 18:07 (UTC) (edited on 2025-06-06 18:25 (UTC) by xiota)

Successfully built this package a moment ago in a clean chroot.

Users with potential OOM issues... Try adding following to beginning of build() function:

# calculate core usage
local _mem=$(awk '/MemFree/ { print int($2/1024/1024) }' /proc/meminfo)
local _nproc=$(nproc)
local _cores=$((_mem < _nproc ? _mem - 1 : _nproc - 1))

printf '\nFree RAM: %s\nCores: %s\nUsing: %s\n\n' "$_mem" "$_nproc" "$_cores"
export MOZ_PARALLEL_BUILD=${_cores:-4}

@hugeblank That looks like a Rust + LTO type problem, but this package already has !lto in options array.

@skdoosh99 Those types of Gdk warnings are common across all GTK apps. They're most likely occurring during profiling. Probably they're safe to ignore. If they bother you enough, build with PGO disabled (but the browser will be slower).

hugeblank commented on 2025-06-06 15:01 (UTC)

Getting an error when attempting to build the latest version of this package:

20:01.41 ld.lld: error: ../../../x86_64-unknown-linux-gnu/release/libgkrust.a(gkrust_shared-94fd477d23bcf425.gkrust_shared.8315a087c548fc18-cgu.0.rcgu.o): Invalid record
20:01.43 clang++: error: linker command failed with exit code 1 (use -v to see invocation)
20:01.43 make[4]: *** [/home/hugeblank/.cache/paru/clone/librewolf/src/librewolf-139.0.1-1/config/rules.mk:539: ../../../dist/bin/libxul.so] Error 1
20:01.43 make[3]: *** [/home/hugeblank/.cache/paru/clone/librewolf/src/librewolf-139.0.1-1/config/recurse.mk:72: toolkit/library/build/target] Error 2
20:01.43 make[2]: *** [/home/hugeblank/.cache/paru/clone/librewolf/src/librewolf-139.0.1-1/config/recurse.mk:34: compile] Error 2
20:01.44 make[1]: *** [/home/hugeblank/.cache/paru/clone/librewolf/src/librewolf-139.0.1-1/config/rules.mk:359: default] Error 2
20:01.44 make: *** [client.mk:60: build] Error 2
20:01.64 W 203 compiler warnings present.
==> ERROR: A failure occurred in build().
    Aborting...
error: failed to build 'librewolf-1:139.0.1_1-1': 
error: packages failed to build: librewolf-1:139.0.1_1-1

skdoosh99 commented on 2025-06-02 03:17 (UTC)

Bit of a noobie on arch, got this message around 10 times during compiling, and just wanted to make sure it isnt an issue.

(librewolf:84743): Gdk-CRITICAL **: 22:04:18.280: gdk_seat_get_keyboard: assertion 'GDK_IS_SEAT (seat)' failed [Parent 84743, Main Thread] WARNING: gdk_seat_get_keyboard: assertion 'GDK_IS_SEAT (seat)' failed: 'glib warning', file /home/fynn/.cache/yay/librewolf/src/librewolf-139.0.1-1/toolkit/xre/nsSigHandlers.cpp:201

marbens commented on 2025-05-22 02:52 (UTC)

@AvidSeeker how much RAM do you have? I've had problems with RAM running out while building this. oomkiller might be killing the terminal, causing SIGHUP.

AvidSeeker commented on 2025-05-22 02:44 (UTC)

@xiota

Yes. Even with rm -rf ~/.cache/yay/librewolf.

Problem persists even after full system upgrade. That interrupt signal even closes the shell session. I had to log yay output into a file to catch this interrupt.

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