| 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.net/ |
| Keywords: | browser web |
| Licenses: | MPL-2.0 |
| Conflicts: | librewolf |
| Provides: | librewolf |
| Submitter: | lsf |
| Maintainer: | lsf |
| Last Packager: | lsf |
| Votes: | 626 |
| Popularity: | 23.77 |
| First Submitted: | 2019-06-16 13:12 (UTC) |
| Last Updated: | 2026-05-13 07:44 (UTC) |
librewolf-bin stopped opening after update and when trying to reinstall the following error message appears:
libfakeroot internal error: payload not recognized!
Errors occurred and therefore no packages were updated. -> error installing: [/home/edson/.cache/yay/librewolf-bin/librewolf-bin-1:137.0.2_1-1-x86_64.pkg.tar.zst /home/edson/.cache/yay/librewolf-bin/librewolf-bin-debug-1:137.0.2_1-1-x86_64.pkg.tar.zst] - exit status 1
@zlima12 librewolf/arch#18
The upstream URL should be updated to https://librewolf.net.
@marbens @karolyi, my bad, it is working fine, my shortcut was pointing to the old appimage I was testing. Will delete my comment...
@spsf64, it works on my machine™
@marbens yes, that would not have been that big of a deal considering the upstream release cadence. epoch bumps are only supposed to be used for major versioning breakage (e.g. 5.7.2 gets reset to 1.0.0). Really, I think that it should get reset to zero/undefined in the case of this package, but as mentioned before that would require manual intervention from users that have updated to epoch 1.
@zlima12 How else would we have solved the problem? Skip 136.0-2?
I really don't think that an epoch bump was warranted here. There was no profound change in the upstream versioning system, and the versioning problem would have only lasted until 136.1 or 137 was released. Now, there is no way to undo the epoch change without manual intervention from the users that have already updated.
Pinned Comments
lsf commented on 2021-11-10 12:14 (UTC) (edited on 2026-05-07 09:38 (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 662E3CDD6FE329002D0CA5BB40339DD82B12EF16should 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 :)/edit: (2026-05-07): The upstream signing sub-key was rotated, and the
.tar.xztarballs will now be signed with a new subkey. The main key id (0x662E3CDD6FE329002D0CA5BB40339DD82B12EF16) remains unchanged though, so should you get an error during signature verification about a missing (sub)key, all that's required would be to refresh the key(s) viagpg --refresh-keys 662E3CDD6FE329002D0CA5BB40339DD82B12EF16.