| 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: | 407 |
| Popularity: | 10.84 |
| First Submitted: | 2019-06-16 13:12 (UTC) |
| Last Updated: | 2024-12-15 09:43 (UTC) |
Hi,
I'm using paru and i'm getting this failure:
==> Verifying source file signatures with gpg...
librewolf-88.0.1-1-x86_64.pkg.tar.zst ... FAILED (unknown public key 2954CC8585E27A3F)
==> ERROR: One or more PGP signatures could not be verified!
:: Packages failed to build: librewolf-bin-88.0.1-1
Thank you!
Thanks !
No worries. Considering nothing followed up from FabioLolix (neither here nor at some other packages where they commented on) I'll just keep on assuming that it was indeed a somewhat peculiar interpretation of "the rules".
Should all else fail, I could still do some convoluted "yeah, then I'll just put it in a "regular tarball" and build the package from there.
So yeah, I hope things can stay in the AUR – because that's where most people will look for packages in the Arch-Multiverse :)
(I've replied to the backup line on librewolf, btw :)
BTW, I hope you don't remove the package from AUR. The same goes for zoom for example... Pacman offered binary packages provided like that, without an Arch repo, are hard to keep track of and therefore to keep out to date. You might be willing to create a new public repo, but what about other packages? It's kind of hard on users pushing AUR maintainers to comply with that, :( And building a browser as big as Librewold takes way too much...
Hi @lsf, pelase do not remove:
backup=('usr/lib/librewolf/librewolf.cfg'
'usr/lib/librewolf/distribution/policies.json')
See, it's not the same when you just want overwrite some values, which is what including ~/.librewolf/librewolf.overrides.cfg at the end of /usr/lib/librewolf/librewolf.cfg is meant for, than for commenting out some configs from /usr/lib/librewolf/librewolf.cfg, to get the FF default behavior instead.
For example to get safe browsing back, as it works on FF, the best is just comment out the librewolf configs, instead of specifying URLs, and several string values and the like.
I hope you don't remove those backup lines ever, :)
Thanks a lot !
This is not yet out of date. FF88 might be released, but Librewolf has not been updated yet for Arch Edit: shortly after commenting the Arch builds were updated......thanks
Just in case: Considering that according to FabioLolix, this package might be against some rules: In the case of me actually having to remove it from the AUR, it's also provided in an external repo at https://privacyshark.zero-credibility.net/privacyshark/$arch.
The packages and the repo there are signed with the same key used for the official LibreWolf releases (and they're exactly the same package files).
Thanks for pointing that out – I must've skipped that point when it came to mentioning JAVA.
Anyway: it's not clear to me what exactly is meant by that. The whole phrase is: "Packages that use prebuilt deliverables, when the sources are available, must use the -bin suffix. An exception to this is with Java. The AUR should not contain the binary tarball created by makepkg, nor should it contain the filelist."
From how I understand it, it's more about things like adding the pkg.tar. to the AUR (as in commiting it to the AUR), and not about using a pkg.tar. from elsewhere as a source. So as long as it's a -bin package, everything should be alright.
Which would, to my mind, "make the most sense" – because why would this be any different than a binary packaged for anything else?; as long as I'm not pulling the pkg.tar. from the official upstream repos (or putting the pkg.tar. on the AUR which would fit better with the "should not contain the binary tarball.." part).
I might still be totally in the wrong here, but neither do I see what about my approach here is detrimental (except it being somewhat inelegant) to Arch / the AUR, nor am I certain it's meant the way you say.
So if you could help me out a bit further on that (by clarifying that it is indeed meant the way you say it is) or if you could provide me a somewhat more clearly phrased source / some statement somewhere, that would be great!
Again, not trying to be a pain here – just trying to see what's the best way to somehow get everyone happy on this ^^
From https://wiki.archlinux.org/index.php/AUR_submission_guidelines#Rules_of_submission
"The AUR should not contain the binary tarball created by makepkg"
If you want to help users create a repository, make a pinned post about it in the librewolf AURweb page and get it listed in the list of unofficial Arch repos
That would be news to me – but I might have missed that, so could you be so kind as to tell me where it says that? (couldn't find it by quickly looking at the guidelines in the wiki).
If that would truly be a problem, I would remove the package – although I'd hope that this could be avoided; considering that the AUR is "the first place" people will probably look for a package that's not in the upstream repos. The alternative would be just relying on external repos (like https://privacyshark.zero-credibility.net/), but those would have to be "discovered" first, or by doing something even more inelegant/hacky like taking a non-arch-specific prebuilt version (debian?) and trying to coerce it into an Arch package – which would probably lead to a bin-release of lesser quality.
/edit
Oh well, I could also have the CI on the other end of all this additionally spit out a version that's just a plain old tar.zst of the contents that would normally go into the pkg.tar.xz, if all else failed. That way it would be "compliant" while still providing an easy to use/find bin-release of it via the AUR. Not trying to be a pain here – I just want it to be easy to use even for those not wanting to build from source.
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 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 :)