Package Details: palemoon 1:33.4.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: 141
Popularity: 0.131247
First Submitted: 2014-06-05 10:54 (UTC)
Last Updated: 2024-11-05 20:54 (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 .. 22 23 24 25 26 27 28 29 30 31 32 .. 38 Next › Last »

WorMzy commented on 2017-02-13 18:31 (UTC)

True, but Travis (Palemoon Linux dev) asked me to leave --enable-gstreamer in the mozconfig for the 27.1 release, and remove it for the 27.2 release. I'm not sure if there is a toggle in about:config which you can use to select your preference in the mean time.

alium commented on 2017-02-13 17:09 (UTC) (edited on 2017-02-13 17:19 (UTC) by alium)

palemoon 27.1.0 use now FFMPEG as backend for audio/video - please read release notes https://www.palemoon.org/releasenotes.shtml Gstreamer wil be remove: https://github.com/MoonchildProductions/Pale-Moon/commit/090b8adf6a62c007f4d5d91da73bf1f2b2873c1f

WorMzy commented on 2017-01-24 19:27 (UTC)

Where are you running the scripts from? The sources /should/ be stored there. So if you download the AUR snapshot for this package and extract it to ~/builds/palemoon, cd to that directory, and run 'sudo extra-x86_64-build', you will end up with a clean-chroot-built package and the palemoon git repository stored in ~/builds/palemoon/Pale-Moon. Note that this repository is "bare", not a "working copy", so may be causing some confusion. When you next run 'sudo extra-x86_64-build' from ~/builds/palemoon, this bare copy will be updated and a "working copy" will be cloned from it. This behaviour is the same as using makepkg directly, so if you have SRCDEST set anywhere, that might be affecting the behaviour. See also: http://www.saintsjd.com/2011/01/what-is-a-bare-git-repository/

wolf commented on 2017-01-24 19:02 (UTC)

So the devtool's chroot scripts should preserve sources? They don't, but I'll look into it, thanks for the tip. And thank you so much for the fix :)

WorMzy commented on 2017-01-24 18:35 (UTC)

I've pushed an update that includes the fix. I've not bumped the pkgrel because there is no need to rebuild for this change if you already have 27.0.3 installed.

WorMzy commented on 2017-01-24 15:22 (UTC) (edited on 2017-01-24 15:44 (UTC) by WorMzy)

The clean chroot scripts in devtools retain sources, likewise things that use devtools (like Graysky's clean-chroot-manager) will also retain them. If you're using some other chroot solution, then you'll need to check the documentation for that, but I'd find it strange if it removes sources post-build. As for 2) I actually reported this and it's fixed in the master branch, but I forgot to backport the fix to this package, will fix this when I get home. If you're feeling adventurous, the fix is quite simple, just apply the commit mentioned in this issue (via patch, or using sed) in prepare(): https://github.com/MoonchildProductions/Pale-Moon/issues/836 Edit: see the palemoon-beta package for an example of the fix.

wolf commented on 2017-01-24 14:28 (UTC)

1) afaik building in clean chroot throws away everything after it's done, so I'm redownloading the git repo each time 2) cannot build at the moment: http://pastebin.com/8drEifiK any tips for what's wrong? O:-)

runical commented on 2017-01-24 13:17 (UTC)

@WorMzy: No worries. This clears it up nicely. Your example is quite compelling, although I feel that downloading the tarball would be no real problem for me personally. On the other hand, the initial git clone isn't all that much bigger/slower on a decent connection, so that is no real problem either when keeping the sources. The main problem will be with people who get rid of their sources after the build (which is the case with many AUR helpers iirc). Anyway, I'd say do what you think best. The PKGBUILD is of high quality from what I can tell, so no further complaints here :-P

WorMzy commented on 2017-01-23 17:14 (UTC)

@runical, I didn't mean to imply that it was your personal objection, and I also phrased it badly to make it seem the objection was to using github at all. Sorry about that! My main reason for using git source over the tarballs is that palemoon frequently gets point releases to fix minor bugs/backout problematic patches, so if I was using tarballs, you'd need to download ~160MB tarballs every time. With the git source, you have an initial checkout of ~290MB (which is only 1.5x the size of a tarballs), and for any subsequent updates you just get the changes. So to compare tarballs to git in a real world example, PM 27.0.0 was tagged on 17th November 2016. It's tarball is 164MB. PM 27.0.1 was tagged nine days later. It's tarball is also 164MB. Six days later, PM 27.0.2 was tagged. Again, the tarball is 164MB. 13 days later, PM 27.0.3. I'll let you guess the size. So in 28 days, using tarballs, we would have downloaded 656MB. If someone started using the palemoon package on the day that it was updated to 27.0.0, they would've had the initial checkout of ~292MB. Using git diff as a rough estimate, the 27.0.1 update would have needed them to download 68KB. The 27.0.2 update would download 20K. 27.0.3 is 64K. So in 28 days, using git, we have downloaded ~292.152MB. I really, really don't want to switch to tarballs unless there is a very good reason for it.

runical commented on 2017-01-23 10:24 (UTC)

Wouldn't it though? By using the tarballs on GH, you will get an error when the tarball changes due to the checksum. The argument I made (by proxy, as it was Levente who made the argument) was against using tagged commits instead of the direct hash of said commit when using a git checkout as a tag can point to whatever commit you want. Using the tarball provided by GH does not suffer from this problem as the download is verified by the checksum and the tarball has to be rebuilt after changing the tag. I do see how you can take away that I'm against using GH now I reread my comments. Seems I wasn't clear in what I meant. Sorry about that :s Unless I'm misunderstanding though. Then feel free to correct me as it's been a while since that comment and I haven't actively thought about it since.

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