Package Details: librewolf 136.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: MPL-2.0
Submitter: lsf
Maintainer: lsf
Last Packager: lsf
Votes: 160
Popularity: 14.73
First Submitted: 2019-06-14 18:41 (UTC)
Last Updated: 2025-03-05 12:33 (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 .. 32 Next › Last »

Cusith commented on 2025-03-04 14:27 (UTC)

Just to let you know that the current signing key is mentioned here https://librewolf.net/installation/fedora/ its: '662E3CDD6FE329002D0CA5BB40339DD82B12EF16'

xiota commented on 2025-03-02 21:50 (UTC)

For anyone waiting for someone else to build first... I've successfully built 135.0.1_1-1 with PGO+wlheadless-run and with PGO disabled. Did not test with PGO+xvfb because rebuilds are time consuming and wayland is the future.

OdinVex commented on 2025-03-02 09:15 (UTC)

@lsf, Paru sounds helpful, I'll check into it. There are several packages I'd love to not need to bother mirroring with patches and such. Thank you very much for that reference.

lsf commented on 2025-03-02 09:14 (UTC)

@OdinVex: that is a bit of a "downstream issue" though. Usage of AUR helpers is to varied to accommodate broadly. While some AUR helpers (like paru) would even allow persistend modifications (which would then be rebased on updates) to the PKGBUILDs, to give you a potential different approach to handle this.

OdinVex commented on 2025-03-02 09:11 (UTC)

@xiota, I've experienced otherwise setting variables this way. I'll stick to editmenu for LibreWolf until PGO stops breaking for me.

OdinVex commented on 2025-03-02 09:09 (UTC)

@lsf, Well aware, but that requires I manually intervene every time to set those variables since I simply want to yay -Syu. No, it does pollute every process started by the shell (using export to ensure sub-processes get the variable).

lsf commented on 2025-03-02 09:07 (UTC)

@OdinVex: you can declare those variables temporarily in your current shell session only, or, the way @xiota gave as examples, even solely for one command. Nowhere was it suggested to set those variables session-, user-, or system-wide.

OdinVex commented on 2025-03-02 08:48 (UTC)

@xiota, Those strings are far too generic to set via environmental variables, not to mention that pollutes every process now being loaded with an environmental variable that is only used during an pkg compile. It'd be a poor idea to try to use something like that for a single package. A system-wide variable to disable .NET spyware/call-home? Sure. But not this.

xiota commented on 2025-03-02 08:25 (UTC)

@OdinVex It actually can be set in environment. The variables are declared so they are set only if not already defined.

: ${_build_profiled:=true}
: ${_build_profiled_xvfb:=false}

I have not reviewed entire PKGBUILD, but would expect the following to work:

_build_profiled=false makepkg -srCf     # to build without PGO
_build_profiled_xvfb=true makepkg -srCf # to use xvfb instead of wlheadless-run

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