Package Details: librewolf 125.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: GPL, MPL, LGPL
Submitter: lsf
Maintainer: lsf
Last Packager: lsf
Votes: 121
Popularity: 2.36
First Submitted: 2019-06-14 18:41 (UTC)
Last Updated: 2024-04-24 16:48 (UTC)

Dependencies (39)

Sources (3)

Latest Comments

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

karolyi commented on 2024-04-25 15:24 (UTC)

My build bails out with an error (Package 'nss' has version '3.98', required version is '>= 3.99') which is valid since Manjaro only has 3.98 atm.

I guess I'll have to wait a bit until that gets updated.

xiota commented on 2024-04-25 14:43 (UTC)

@tyress Try building in a clean chroot.

Bitals commented on 2024-04-25 14:12 (UTC)

@tyress you probably just don't have enough RAM. Try with less threads, might help, but will obviously take longer.

tyress commented on 2024-04-25 13:05 (UTC)

Compiling this crashes my compositor, not sure why (is this a known issue?). Moved to tty and I'm getting a could not compile gkrust error.

Derson5 commented on 2024-04-22 15:31 (UTC)

There was new release https://codeberg.org/librewolf/source/releases/tag/125.0.1-1

lahwaacz commented on 2024-03-17 14:16 (UTC)

@OdinVex Then build in a chroot rather than building directly in your environment: https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot

OdinVex commented on 2024-03-17 13:25 (UTC)

Anyone else getting popup windows of a non-install template LibreWolf while compiling? Obviously a part of the "testing" of stuff, but I'd like to avoid that and assume tests are fine.

xiota commented on 2024-03-02 15:04 (UTC) (edited on 2024-03-02 15:07 (UTC) by xiota)

After the initial instrumented build, a python script is launched inside a nested X (or wayland) server (xvfb or xwayland-run) to run and profile the browser. If anything goes wrong, like the x server crashing, the profiling stage fails. Then the entire PGO process has to start over with the instrumented build.

The DRI/Zink problem is probably caused by missing access to acceleration hardware. LIBGL_ALWAYS_SOFTWARE=true forces software rendering. Since multiple people across multiple Firefox forks have been affected, forcing software rendering by default is worthwhile to prevent people from losing hours of time and wasted resources.

Also, pkgrel shouldn't be bumped for changes that don't affect the final package because people who already successfully built the package don't need to rebuild.

lsf commented on 2024-03-02 13:59 (UTC)

@lahwaacz: thanks. will fix it. sorry.

@xiota: do you have some good explanation / some more info about the background of this option and why it causes issues? (or if you felt like it, you could open an issue / PR on https://codeberg.org/librewolf/ right away, of course ;)

xiota commented on 2024-03-01 21:38 (UTC)

Enough people have had problems with DRI/zink across different Firefox forks that would be better to set by default LIBGL_ALWAYS_SOFTWARE=true. Profiling probably takes a little longer, but that's better than having it fail after 1/3 of the process (hours on some machines) and have to restart.