Package Details: palemoon 28.6.0.1-1

Git Clone URL: https://aur.archlinux.org/palemoon.git (read-only)
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: GPL, MPL, LGPL
Submitter: artiom
Maintainer: WorMzy
Last Packager: WorMzy
Votes: 121
Popularity: 1.684051
First Submitted: 2014-06-05 10:54
Last Updated: 2019-07-04 22:45

Latest Comments

« First ‹ Previous ... 6 7 8 9 10 11 12 13 14 15 16 ... Next › Last »

WorMzy commented on 2017-03-14 19:25

Do you get any errors? The uninitialized currentIsSelected messages are not the problem, but the NSModules order message looks suspicious.

The package builds fine in a clean chroot for me. I would recommend using clean chroots over yaourt (or even direct makepkg) in any case.

https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot

gofree commented on 2017-03-14 18:27

fails to build, can anybody try or advise? thnx

0:21.41 /tmp/yaourt-tmp-gofree/aur-palemoon/src/Pale-Moon/toolkit/xre/nsAppRunner.cpp: In member function ‘int XREMain::XRE_mainStartup(bool*)’:
0:21.41 Warning: -Wmaybe-uninitialized in /tmp/yaourt-tmp-gofree/aur-palemoon/src/Pale-Moon/toolkit/xre/nsAppRunner.cpp: ‘currentIsSelected’ may be used uninitialized in this function
0:21.41 /tmp/yaourt-tmp-gofree/aur-palemoon/src/Pale-Moon/toolkit/xre/nsAppRunner.cpp:2020:7: warning: ‘currentIsSelected’ may be used uninitialized in this function [-Wmaybe-uninitialized]
0:21.41 if (!currentIsSelected) {
0:21.41 ^
0:21.41 /tmp/yaourt-tmp-gofree/aur-palemoon/src/Pale-Moon/toolkit/xre/nsAppRunner.cpp:2016:12: note: ‘currentIsSelected’ was declared here
0:21.41 bool currentIsSelected;
0:21.41 ^
0:21.95 libtoolkit_xre.a.desc
0:21.98 libxul_s.a.desc
0:21.98 libxul.so
0:51.04 NSModules are not ordered appropriately
0:51.04 make[5]: *** [/tmp/yaourt-tmp-gofree/aur-palemoon/src/Pale-Moon/config/rules.mk:821: libxul.so] Error 1
0:51.04 make[5]: *** Deleting file 'libxul.so'
0:51.14 make[4]: *** [/tmp/yaourt-tmp-gofree/aur-palemoon/src/Pale-Moon/config/recurse.mk:74: toolkit/library/target] Error 2
0:51.14 make[3]: *** [/tmp/yaourt-tmp-gofree/aur-palemoon/src/Pale-Moon/config/recurse.mk:37: compile] Error 2
0:51.14 make[2]: *** [/tmp/yaourt-tmp-gofree/aur-palemoon/src/Pale-Moon/config/rules.mk:541: default] Error 2
0:51.15 make[1]: *** [/tmp/yaourt-tmp-gofree/aur-palemoon/src/Pale-Moon/client.mk:398: realbuild] Error 2
0:51.15 make: *** [client.mk:171: build] Error 2
0:51.18 243 compiler warnings present.

WorMzy commented on 2017-03-08 19:43

We have been building with gcc5 since ~April 2015, and I have never experienced instability with the core browser. I also haven't seen any such stability issues reported on the Arch Linux forums. A quick search of the Palemoon forums doesn't yeild any stability reports by Arch users either. I did follow a github topic about gcc5 stability, but that appeared to be caused by binaries built with bad mozconfigs on unstable/testing versions of debian, then run on stable versions of debian/ubuntu.

As gcc49 is EOL (as of August last year [1]), insisting that people use it over gcc5 is not a long term solution. As it stands, we currently use gcc5 because when Arch updated to gcc6, Palemoon didn't support it. Arch currently ships a gcc5 package, so we get that for free; if we were to switch to gcc49, users would need to compile that too, adding a lot of burden to them (palemoon already takes long enough to compile without having to compile the compiler too).

Cheers.

[1] https://gcc.gnu.org/ml/gcc-announce/2016/msg00002.html

mattatobin commented on 2017-03-08 17:23

Because it produces unstable builds?!

WorMzy commented on 2017-03-03 16:21

No. I have discussed the matter with Travis already. Users can build gcc49 and then make the necessary changes to the PKGBUILD and mozconfig if they wish to, but I see no discernable benefit for forcing all users to do this.

mattatobin commented on 2017-03-03 15:40

You do realize that you MUST use GCC 4.9 and nothing else for building.. Please make this change at once.

WorMzy commented on 2017-02-13 18:31

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

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

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

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 :)