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 .. 9 10 11 12 13 14 15 16 17 18 19 .. 37 Next › Last »

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.

lahwaacz commented on 2024-03-01 21:32 (UTC)

@lsf In the last commit you've put a comment in the middle of a "multi-line command", which breaks it into separate commands (the variables before the comment are not applied to the xvfb-run command).

lsf commented on 2024-03-01 16:27 (UTC)

Oh, I've totally missed that something didn't work right when I pushed the update. Very sorry about that! Should that happen again some day, please feel free to remind me more! (here, on codeberg, or matrix).

I'll get to it right away! :)

NaBoo commented on 2024-03-01 16:23 (UTC) (edited on 2024-03-01 16:24 (UTC) by NaBoo)

For those who don't want to wait :

diff --git a/PKGBUILD b/PKGBUILD
index 7bd69b3..586392b 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -2,8 +2,8 @@

 pkgname=librewolf
 _pkgname=LibreWolf
-pkgver=122.0.1
-pkgrel=2
+pkgver=123.0
+pkgrel=1
 pkgdesc="Community-maintained fork of Firefox, focused on privacy, security and freedom."
 url="https://librewolf.net/"
 arch=(x86_64 aarch64)
@@ -74,7 +74,7 @@ source=(
   "default192x192.png"
 )

-sha256sums=('0085bf14ce96c737d2944cfe89a9cccb243ba5935c38e9ff9c4197a11b1e2b40'
+sha256sums=('e3209efbddd0c0a79bc62cb9c5cc57b816816bf32a24e8e476e07879c2791314'
             '7d01d317b7db7416783febc18ee1237ade2ec86c1567e2c2dd628a94cbf2f25d'
             '959c94c68cab8d5a8cff185ddf4dca92e84c18dccc6dc7c8fe11c78549cdc2f1')

@@ -202,6 +202,8 @@ END

     LLVM_PROFDATA=llvm-profdata \
       JARLOG_FILE="$PWD/jarlog" \
+#     Uncomment the next line if you have an error while profiling ( thanks to mkli )
+#      LIBGL_ALWAYS_SOFTWARE=true \
       xvfb-run -s "-screen 0 1920x1080x24 -nolisten local" \
       ./mach python build/pgo/profileserver.py

karolyi commented on 2024-01-29 14:31 (UTC)

@Bitals, thanks for your input.

I'm not particurlarly fond of docker and k8s (I use docker at places because I have to), I can do the scripting part for myself. My question mainly was about an affordable service that offers such hardware to be provisioned on a time based lease, for the time of the build.

It's getting offtopic here though, I think, but thanks for the chime in anyways. I'll be on the lookout for such a provider.

Bitals commented on 2024-01-29 14:25 (UTC) (edited on 2024-01-29 14:25 (UTC) by Bitals)

@karolyi if you are looking for a lease only for the build time, I think you would have to either manually create a VPS each time you want to build or setup some form of dynamic worker provision with cloud docker/kubernetes engine and some form of a static job provisioner. My approach was to setup a Jenkins instance with dynamic docker builders, but that's with local hardware. Jenkins Docker agent tailored to building AUR packages can be found on my Github, but it's not "production ready" i.e. not all hardcode specific to my environment is eliminated and no documentation written yet, but it works pretty well for me.

karolyi commented on 2024-01-29 14:18 (UTC)

@mkli, thanks, it fixed my build too.

on a similar note, can anyone suggest a service that offers VM's with 16 CPUs and 64GB ram to build my librewolf with my patches?

Github only offers such a thing for organizations.

mkli commented on 2024-01-29 10:26 (UTC) (edited on 2024-01-29 10:26 (UTC) by mkli)

Building this package is failing for me during profiling with some errors about DRI3 support missing:

DRI3 not available
failed to load driver: zink
vulkan: No DRI3 support detected - required for presentation

Workaround which works for me is setting LIBGL_ALWAYS_SOFTWARE=true to xvfb-run:

--- a/PKGBUILD
+++ b/PKGBUILD
@@ -202,6 +202,7 @@

     LLVM_PROFDATA=llvm-profdata \
       JARLOG_FILE="$PWD/jarlog" \
+      LIBGL_ALWAYS_SOFTWARE=true \
       xvfb-run -s "-screen 0 1920x1080x24 -nolisten local" \
       ./mach python build/pgo/profileserver.py

Credit to Grogan for this solution: https://www.bitbenderforums.com/forums/showthread.php?90498-I-just-noticed-new-Firefox-released-today&p=584486#post584486

« First ‹ Previous 1 .. 9 10 11 12 13 14 15 16 17 18 19 .. 37 Next › Last »