Package Details: librewolf 134.0.2-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: 147
Popularity: 3.73
First Submitted: 2019-06-14 18:41 (UTC)
Last Updated: 2025-01-26 21:06 (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 .. 3 4 5 6 7 8 9 10 11 12 13 .. 29 Next › Last »

karolyi commented on 2023-04-20 15:26 (UTC)

@lsf, may I please inquire what CI you use to build the binaries? I need to set up my own patched compilation of librewolf.

lsf commented on 2023-04-17 07:27 (UTC)

@Luziferus: a somewhat late thanks for your info – that was indeed an issue and your solution would've fixed it, but before I got around to changing that, manjaro seemed to have updated to ffmpeg 6, too, so it solved itself :D

Luziferus666 commented on 2023-03-28 07:28 (UTC) (edited on 2023-03-28 07:28 (UTC) by Luziferus666)

@lsf you're right. I had no base-devel installed. Strange.

The _ffmpeg_ver issue is that it's 2:5.1.2-1 with two dots.

  • _ffmpeg_ver="${_ffmpeg_ver#*:}" removes the 2: and we result in 5.1.2-1
  • _ffmpeg_ver="${_ffmpeg_ver%.*}" removes the last .2-1 and we end up having 5.1 which is still not a number :)

I guess the version shall not go beyond two dots meaning calling _ffmpeg_ver="${_ffmpeg_ver%.*}" two times shall fix that long versions issue.

lsf commented on 2023-03-28 07:09 (UTC)

Both are odd errors:

  _ffmpeg_ver="${_ffmpeg_ver#*:}"
  _ffmpeg_ver="${_ffmpeg_ver%.*}"

should cut the string down to the major ffmpeg version number, and with that, -gt 5 should work. At least it did in my tests?

patch should come with https://archlinux.org/packages/core/any/base-devel/, which is more or less a requirement for building things from the AUR anyway, which is why it wouldn't be added as a dependency, as it's assumed installed at this point.

Still probably helpful should anyone else come upon those issues, so thanks for pointing out solutions :)

Luziferus666 commented on 2023-03-28 06:50 (UTC) (edited on 2023-03-28 06:55 (UTC) by Luziferus666)

The current latest version (111.0.1-1) build fails with these two issues in Manjaro Linux (kernel 6.2.7-2):

  • line 214 in PKGBUILD #if [ "${_ffmpeg_ver}" -gt 5 ]; then <- number expected
    • the evaluated command pacman -Qi ffmpeg | gawk '/Version/{print $3}' is not a number. it's a string. For current Manjaro version it's 2:5.1.2-1
    • quick fix: if your ffmpeg version is 5, feel free to remove the lines 214 to 220
    • if your ffmpeg version is 6 or above, remove only the lines 214 and 220
  • line 225: patch command not found
    • quick fix: install patch
    • this shall be actually put into dependencies I guess

Bitals commented on 2023-02-20 10:58 (UTC) 

08:27:54     0001-libwebrtc-screen-cast-sync.patch ... FAILED
08:27:54 ==> ERROR: One or more files did not pass the validity check!

Manually redownloaded it again, indeed an incorrect checksum.

OdinVex commented on 2023-02-13 14:01 (UTC)

@karolyi, Brand new up-to-date no-changes installations would fail. Already figured it out, see below or my previous post which had solution, too.

@eclairevoyant, I did use makepkg -si, still failed, I already found out what the issue was. Someone has assumed trust over one of the gpg keys not listed, or has removed trust. The key, though imported, wasn't trusted at all. The asc verification that happens automatically is what was failing due to trust issue. Added marginal trust, the package could be built. Tried on a brand-new VM of Manjaro after adding key and trusting it, works.

karolyi commented on 2023-02-13 10:12 (UTC)

@odinvex,

that is an error on your end. I build this package for myself every time (since I use the allow_dark_preference_with_rfp.patch), and aside from the recent build error that happened to everyone, it builds just fine.

Your best bet is to try and see if executing the same command as the PKGBUILD does, fails in a shell, and if yes, why.

eclairevoyant commented on 2023-02-13 05:44 (UTC) (edited on 2023-02-13 05:46 (UTC) by eclairevoyant)

No, if you use a helper you're on your own. We can only help if you use makepkg on Arch Linux (not some other distro). Please check the rules of the AUR.

pamac is also categorically broken, you'd better use a helper that at least supports clean chroots like paru or aurutils (read the man pages to learn how to set up a chroot with them).

OdinVex commented on 2023-02-13 05:25 (UTC)

@eclairevoyant, Of course someone uses an AUR helper to use the AUR...since AURs are not part of Arch's official support. pamac, in this case. I've managed to get it working despite the issues, keeping a script I threw together for future installs.

« First ‹ Previous 1 .. 3 4 5 6 7 8 9 10 11 12 13 .. 29 Next › Last »