Package Details: librewolf-bin 1:136.0.0_2-1

Git Clone URL: https://aur.archlinux.org/librewolf-bin.git (read-only, click to copy)
Package Base: librewolf-bin
Description: Community-maintained fork of Firefox, focused on privacy, security and freedom.
Upstream URL: https://librewolf-community.gitlab.io/
Keywords: browser web
Licenses: GPL, MPL, LGPL
Conflicts: librewolf
Provides: librewolf
Submitter: lsf
Maintainer: lsf
Last Packager: lsf
Votes: 449
Popularity: 37.04
First Submitted: 2019-06-16 13:12 (UTC)
Last Updated: 2025-03-06 09:04 (UTC)

Dependencies (16)

Required by (32)

Sources (7)

Pinned Comments

lsf commented on 2021-11-10 12:14 (UTC) (edited on 2023-04-17 07:18 (UTC) by lsf)

https://wiki.archlinux.org/title/Arch_User_Repository#Acquire_a_PGP_public_key_if_needed

gpg --keyserver hkp://keyserver.ubuntu.com --search-keys 031F7104E932F7BD7416E7F6D2845E1305D6E801

/edit: starting with 112.0-1, the binaries are signed with the maintainers shared key, so gpg --keyserver hkp://keyserver.ubuntu.com --search-keys 662E3CDD6FE329002D0CA5BB40339DD82B12EF16 should do the trick instead. I've also signed the key with the previously used key, so you have at least some guarantee that it's not a malicious attack :)

Latest Comments

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

marbens commented on 2025-03-06 02:51 (UTC)

I've opened another PR attempting to fix the versioning problems, that are caused by variable-place versioning.

marbens commented on 2025-03-05 14:31 (UTC) (edited on 2025-03-05 14:42 (UTC) by marbens)

If 136.0-2 releases right after 136.0-1, the 4-point solution will require an epoch bump (to 1 at the moment).

But if 136.0.1-1 or 137.0-1 releases right after 136.0-1, we can do the 4-point transition at the same time as the upstream firefox update and avoid using epoch.

BTW you can use an underscore instead of a period for the final version number point (librewolf patch number?), in the 4-point versioning, if you prefer how it looks.

I wasn't thinking about the versioning having a variable amount of points when I made that patch.

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

Hm. Crap.

…maybe I should've just left it as is (it's always still a possibility to use the pkgrel and go with something like 136.0-1.1, for example, if AUR/PKGBUILD only changes/rebuilds were required).

Going with 4 places always doesn't seem to "sit right" with me as well on the first glance, but I'll need to think about this for a bit.

Thanks a lot for noticing (and for making me aware of this, including a potential solution even)! :)

petris commented on 2025-03-05 13:53 (UTC)

I noticed the version number change to use an underscore, I assume in an effort to decouple the pkgrel from the librewolf version number. Unfortunately it appears this is going to cause some problems.

Lets assume that 136.0-2 is released, and then 136.0.1-1 after that, as librewolf regularly uses the third position as well. A quick test with vercmp shows that 136.0_2 is considered "newer" than 136.0.1_1. My assumption is that it just sees the _ as a separator just like ., and therefore what it's really seeing is 136.0.2 vs 136.0.1.1, which would be correct.

You could probably fix this by making the pkgver always use 4 places (3 for the version and 1 for the pkgrel), using the following as an example:

pkgver="136.0.0.1"
_releaserel="${pkgver##*.}" # Effectively gives you the last segment, resulting in "1".
_releaseverfull="${pkgver%.*}" # Effectively removes the last segment, resulting in "136.0.0"
_releasever="${_releaseverfull/.0}" # Removes ".0" from the end. For "136.0.0" this will result in "136.0" but for "136.0.1" won't do anything.

Then use the _releasever and _releaserel parameters for constructing the actual librewolf version.

daniel-kuehn commented on 2025-03-01 12:09 (UTC)

@AstroBarker Builds/installs fine with yay for me, it's an issue on your end and this package shouldn't be flagged out of date because of that.

daniel-kuehn commented on 2025-03-01 12:03 (UTC)

@FShip You should be able to manually download the GPG key from:

https://gpg.librewolf.net

Then import it with:

gpg --import librewolf.asc

FShip commented on 2025-03-01 09:29 (UTC) (edited on 2025-03-01 09:30 (UTC) by FShip)

Nothing I tried with the keys works: pacman-key --recv-keys has no effect, gpg --keyserver crashes with

gpg: error writing keyring '[keyboxd]': SQL library used incorrectly gpg: error reading '[stream]': SQL library used incorrectly

So how do I install the browser?

AstroBarker commented on 2025-02-28 00:55 (UTC) (edited on 2025-02-28 00:59 (UTC) by AstroBarker)

So what is the necessary update to the librewolf install docs to get this working? If the instructions on the main website are insufficient, as clearly indicated here, that needs to be addressed. Key server issues in the year/month of our lord Feb 2025?

marbens commented on 2025-02-25 22:11 (UTC) (edited on 2025-02-25 22:50 (UTC) by marbens)

You shouldn't use pkgrel for the upstream version, but instead use an underscore in pkgver.

Sources:

https://wiki.archlinux.org/title/PKGBUILD#pkgver

https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/thread/CQCUHVRFWW2AKUHO4M225KHWSUH7Z4OA

Also, here's a patch that you can apply with git am <filename>, that fixes this problem: https://pastebin.com/3jEcpFvd

Edit: I've also made this as a PR on Codeberg.

bluair commented on 2025-02-14 22:45 (UTC) (edited on 2025-02-14 22:48 (UTC) by bluair)

"Getting SIGNATURE NOT FOUND"

Installing with 'yay' works on my machine (Big Linux)...

$ yay -S librewolf-bin ........... " :: (1/1) Parsing SRCINFO: librewolf-bin gpg: error reading key: No public key :: PGP keys need importing: -> 662E3CDD6FE329002D0CA5BB40339DD82B12EF16, required by: librewolf-bin :: Import? [Y/n] y :: Importing keys with gpg... gpg: key 40339DD82B12EF16: public key "LibreWolf Maintainers gpg@librewolf.net" imported gpg: Total number processed: 1"

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