Package Details: librewolf 1:142.0.1_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: 188
Popularity: 8.00
First Submitted: 2019-06-14 18:41 (UTC)
Last Updated: 2025-08-30 13:31 (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 .. 35 Next › Last »

karolyi commented on 2025-08-30 11:05 (UTC)

Hey,

there is a checksum error for librewolf-142.0.1-1.source.tar.gz:

==> Making package: librewolf 1:142.0.1_1-1 (Sat 30 Aug 2025 01:03:35 PM CEST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Downloading librewolf-142.0.1-1.source.tar.gz...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  963M  100  963M    0     0  88.9M      0  0:00:10  0:00:10 --:--:-- 97.7M
  -> Found librewolf.desktop
  -> Found default192x192.png
==> Validating source files with sha256sums...
    librewolf-142.0.1-1.source.tar.gz ... FAILED
    librewolf.desktop ... Passed
    default192x192.png ... Passed
==> ERROR: One or more files did not pass the validity check!

tea commented on 2025-08-04 04:50 (UTC)

Fails to build for me on 0:04.67 ERROR: Wasm C compiler target CPU (x86_64) does not match --wasm CPU (wasm32)

je-vv commented on 2025-07-08 21:51 (UTC) (edited on 2025-07-08 21:55 (UTC) by je-vv)

@xiota thanks for your comment. I got it right, just asked about it wrong, :) If I wanted to try PGO with xvfb, then I need both variables set to true, and what I did was just that:

  3 # run pgo build or not; with X(vfb) or wayland
  4 : ${_build_profiled:=true}
  5 : ${_build_profiled_xvfb:=true}

So all good, :)

@ToneyFox, PGO requires some sort of runtime environment to perform the [dynamic] profiling, see PGO. And those PGO depencies are chosen depending on:

if [[ "${_build_profiled}" == "true" ]]; then
  if [[ "${_build_profiled_xvfb}" == "true" ]]; then
    makedepends+=(
      xorg-server-xvfb
    )
  else
    makedepends+=(
      weston
      xorg-xwayland
      wlheadless-run # aur/xwayland-run-git
    )
  fi
fi

I found the PKGBUILD very useful, but needs manual intervention if you don't want the default. I didn't want to profile on top of wayland, so I chose the xvfb variable to true to profile on top of x11 stuff. Both false is also valid and there's no additional make dependency for PGO.

ToneyFox commented on 2025-07-08 17:49 (UTC)

Make dependencies are dependencies. XWayland is quite obviously not needed to build the package, not sure how anyone could believe it potentially is

xiota commented on 2025-07-08 17:35 (UTC)

xorg-xwayland is not a depends. It's a makedep that was required for profiling and not worth the time to test whether it's still strictly required.

ToneyFox commented on 2025-07-08 16:30 (UTC)

Why does this depend on XWayland? That should be optional

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?

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