Package Details: librewolf 123.0.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: GPL, MPL, LGPL
Submitter: lsf
Maintainer: lsf
Last Packager: lsf
Votes: 121
Popularity: 5.12
First Submitted: 2019-06-14 18:41 (UTC)
Last Updated: 2024-03-17 12:41 (UTC)

Dependencies (39)

Sources (3)

Latest Comments

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

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.

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.