Package Details: librewolf 1:136.0.4_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: 169
Popularity: 15.91
First Submitted: 2019-06-14 18:41 (UTC)
Last Updated: 2025-03-27 22:42 (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

« First ‹ Previous 1 2 3 4 5 6 7 .. 33 Next › Last »

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

OdinVex commented on 2025-03-02 08:12 (UTC) (edited on 2025-03-02 08:46 (UTC) by OdinVex)

@lsf, Thank you, I'll test it when I can. I wish it were an environmental variable that we could set so editing wouldn't be needed every update but that's alright.

Edit: It worked, thank you very much.

lsf commented on 2025-03-02 08:06 (UTC)

disabling pgo by setting $_build_profiled to false should work properly now.

« First ‹ Previous 1 2 3 4 5 6 7 .. 33 Next › Last »