Package Details: palemoon 1:33.4.0.1-1

Git Clone URL: https://aur.archlinux.org/palemoon.git (read-only, click to copy)
Package Base: palemoon
Description: Open source web browser based on Firefox focusing on efficiency.
Upstream URL: https://www.palemoon.org/
Keywords: browser goanna web
Licenses: MPL-2.0
Submitter: artiom
Maintainer: WorMzy
Last Packager: WorMzy
Votes: 142
Popularity: 0.27
First Submitted: 2014-06-05 10:54 (UTC)
Last Updated: 2024-10-09 21:58 (UTC)

Pinned Comments

WorMzy commented on 2021-03-02 16:19 (UTC) (edited on 2022-08-03 21:12 (UTC) by WorMzy)

The following key is used to sign release commits:

40481E7B8FCF9CEC

Import it into your keyring however you want.

https://wiki.archlinux.org/index.php/GnuPG#Import_a_public_key

Latest Comments

« First ‹ Previous 1 .. 23 24 25 26 27 28 29 30 31 32 33 .. 38 Next › Last »

WorMzy commented on 2017-01-21 12:08 (UTC)

You may. But this wouldn't deal with the potential for tag altering (which runical raised as an objection to using github as a source), so is this simply an objection to cloning the full repository the first time you build the package? If so, what do you object to about doing that?

auscompgeek commented on 2017-01-21 09:37 (UTC)

May I suggest using the tarballs that GitHub provides, rather than a git clone?

WorMzy commented on 2017-01-08 18:52 (UTC)

I think that's a pretty big "if". ;) Neither the firefox and chromium packages in extra/, for example, do this. So I am disinclined to add a file that may cause problems now, in the hopes that it prevents/works around other problems down the line.

sekret commented on 2017-01-08 18:42 (UTC)

True! But what if in some future there comes a package which depends on palemoon libs? Wouldn't it be good to be safe for the future, especially if it can be achieved with one tiny little file?

WorMzy commented on 2017-01-08 18:27 (UTC)

For what purpose? Palemoon knows where to find these libraries, and nothing else should be using them (particularly in the case of libraries provided by other packages, e.g. libnss3.so, provided by core/nss)

sekret commented on 2017-01-08 16:29 (UTC)

Could you please add a file which contains /usr/lib/palemoon to "$pkgdir/etc/ld.so.conf.d/palemoon.conf"?

runical commented on 2016-11-29 11:51 (UTC)

I recently cleared out all sources like this and the download was dreadfully slow, so I thought I'd ask. I rather deal with slight inconvenience if I know why it happens :-) The thread I was talking about is the TU-application of Baptiste Jonglez. Levente had some comments on his PKGBUILDs, including the tagging thing. Link: https://lists.archlinux.org/pipermail/aur-general/2016-November/032972.html The one I'm referring to is the last comment made. Levente and Eli then discuss a bit further. The main one to read is https://lists.archlinux.org/pipermail/aur-general/2016-November/032974.html.

WorMzy commented on 2016-11-28 23:35 (UTC)

I switched away from the 7z downloads about two years ago after getting frustrated with the slowness of them (see https://aur.archlinux.org/packages/palemoon/?comments=all#comment-476004 ). I got (and still get, tbh) the feeling that the palemoon team resent having to provide source code for other people to compile their own copies, preferring that people just use their own precompiled copies; so they don't make source archives available promptly, and when they do, they throttle the download speeds. With a git source hosted on github, the source code is always available, the tags are usually made several days before the release announcement, and although the initial clone may take a while, subsequent updates will take much less time than downloading complete versioned source archives. The only negative, as far as I see it, is that the git repository is significantly larger than any number of source archives, but disk storage space is cheap. I must've missed the git tag tampering discussion, can you link me to it?

runical commented on 2016-11-28 21:57 (UTC)

WorMzy, is there a reason why you use a git checkout instead of the provided source archive (the 7-zipped one)? The archive would be a lot quicker to download and (as recently discussed on the ML) protect from tampering with the tags in the git repo.

Arvedui commented on 2016-08-08 11:23 (UTC)

That is exactly my point. Bundling your own libs has exactly the same downsides as static linking, arch got rid of the later for a reason.

« First ‹ Previous 1 .. 23 24 25 26 27 28 29 30 31 32 33 .. 38 Next › Last »