Package Details: palemoon 1:31.0.0-2

Git Clone URL: (read-only, click to copy)
Package Base: palemoon
Description: Open source web browser based on Firefox focusing on efficiency.
Upstream URL:
Keywords: browser goanna web
Licenses: GPL, MPL, LGPL
Submitter: artiom
Maintainer: WorMzy
Last Packager: WorMzy
Votes: 139
Popularity: 0.91
First Submitted: 2014-06-05 10:54 (UTC)
Last Updated: 2022-05-10 12:20 (UTC)

Sources (3)

Pinned Comments

WorMzy commented on 2022-03-21 17:00 (UTC) (edited on 2022-03-25 16:27 (UTC) by WorMzy)

Please note that the 30.0.x release has been pulled while upstream deal with the fallout of the actions a disgruntled contributor. While there is nothing suggesting the 30.0.x releases are compromised in any way, the lead dev is understandably too busy performing damage control to support the 30.0.x release and is recommending people stick to 29.4.x for the time being.

More details at

WorMzy commented on 2021-03-02 16:19 (UTC) (edited on 2021-12-18 12:25 (UTC) by WorMzy)

The following key is used to sign source archives:


Import it into your keyring however you want.

Latest Comments

Bitals commented on 2022-05-03 14:42 (UTC)

Right, I was looking at the palemoon-dev repo, sorry.

WorMzy commented on 2022-05-03 14:37 (UTC)

@Bitals: Are you checking the right repository? Upstream switched to palemoon-dev for a while following the fallout of the v30 release, but they've since switched back to the Pale-Moon repo:

The commit used for the 29.4.6 release is signed by Moonchild with the aforementioned key.

Bitals commented on 2022-05-03 14:22 (UTC)

@WorMzy That unknown 26B40624BDBFD9F3 key may have something to do with version 29.4.6 not being listed at the Releases page in the repo? The last one I see at upstream right now is

 1 month ago

WorMzy commented on 2022-04-10 18:51 (UTC)

The key used to sign commit 44d7f4b8c3 was 40481E7B8FCF9CEC:

$ git -C src/palemoon-dev verify-commit 44d7f4b8c3
gpg: enabled debug flags: memstat
gpg: Signature made Mon 28 Mar 2022 14:59:31 BST
gpg:                using RSA key 3DAD8CD107197488D2A2A0BD40481E7B8FCF9CEC
gpg: Good signature from "Moonchild (RSA signing key) <>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 3DAD 8CD1 0719 7488 D2A2  A0BD 4048 1E7B 8FCF 9CEC
gpg: keydb: handles=3 locks=0 parse=0 get=3
gpg:        build=0 update=0 insert=0 delete=0
gpg:        reset=0 found=3 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=6 cached=6 good=6 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks

I don't think 26B40624BDBFD9F3 is used to sign release commits, but if it ever is, I'll add it to the validpgpkeys array.

saburouta commented on 2022-04-10 16:06 (UTC)

Should this public key be trusted? "3059E09144F56804F0FBF4E126B40624BDBFD9F3" I tried to follow related comments in the thread, but it looks like this shouldn't be the key for

WorMzy commented on 2022-03-21 17:00 (UTC) (edited on 2022-03-25 16:27 (UTC) by WorMzy)

Please note that the 30.0.x release has been pulled while upstream deal with the fallout of the actions a disgruntled contributor. While there is nothing suggesting the 30.0.x releases are compromised in any way, the lead dev is understandably too busy performing damage control to support the 30.0.x release and is recommending people stick to 29.4.x for the time being.

More details at

WorMzy commented on 2022-02-27 23:48 (UTC)

I can confirm that the package still builds fine in a clean chroot with the gcc10 package linked below. If you're still getting build failures, try cleaning your $srcdir (makepkg -C). Or use a clean chroot.

WorMzy commented on 2022-02-27 23:16 (UTC)

You can grab the last-packaged gcc10 package here:

Should still work fine. Hopefully someone will adopt gcc10 and upload to the AUR.

saburouta commented on 2022-02-27 22:06 (UTC)

@micwoj92 Thanks. I don't have high hopes that it will help, but I feel like I need to try this before I continue trying to troubleshoot other things.

micwoj92 commented on 2022-02-27 22:02 (UTC)

saburouta commented on 2022-02-27 21:57 (UTC)

@micwoj92 The communit/gcc-libs package links to missing sources. Is Arch Linux's git repo down or something? Is there a simple way to transform this url to get to the package's sources?

micwoj92 commented on 2022-02-27 21:55 (UTC)

There was gcc10 package in community repo so you could get PKGBUILD from there (git history).

saburouta commented on 2022-02-27 21:53 (UTC)

Is anyone else getting this error?

/palemoon/src/palemoon-source/palemoon/pmbuild/dist/system_wrappers/limits:3:15: fatal error: limits: No such file or directory

I've tried compiling with gcc 9, 10, and multilib-git. I would try rebuilding gcc10, but there's no AUR for that, and it's usually pretty difficult to fork one of the existing PKGBUILD versions for gcc.

WorMzy commented on 2021-12-26 18:23 (UTC)

Good catch, I've pushed an updated PKGBUILD removing that makedep, thanks.

barius commented on 2021-12-26 15:17 (UTC)

Correct me if I am wrong but since we now build from a source tarball, git is now a superfluous build-time dependency.

WorMzy commented on 2021-12-18 12:21 (UTC) (edited on 2021-12-18 12:21 (UTC) by WorMzy)

Good point, I'll update the pinned comment since we can't use signed commits any more.

Also, to clear up any confusion about the discrepancy in key IDs -- 7C9EDC0F13A4F15D is a subkey of 40481E7B8FCF9CEC. You need to import the primary key, which is trusted by makepkg due to it's inclusion in the validpgpkeys array.

micwoj92 commented on 2021-12-17 19:06 (UTC)

Read pinned comment. (but it needs to be updated a bit)

jahway603 commented on 2021-12-17 19:05 (UTC)

This package is failing install with the following error

==> Verifying source file signatures with gpg...
    palemoon-29.4.3.source.tar.xz ... FAILED (unknown public key 7C9EDC0F13A4F15D)
==> ERROR: One or more PGP signatures could not be verified!
error: failed to download sources for 'palemoon-29.4.3-1': 

WorMzy commented on 2021-12-15 11:06 (UTC)

Thanks for the heads up, seems they've also fixed https for the downloads. \o/

micwoj92 commented on 2021-12-14 12:19 (UTC)

It seems like the signatures have been uploaded on

andreas_baumann commented on 2021-11-27 12:48 (UTC)

Just for those compiling on Arch32: add LDFLAGS+="${LDFLAGS} -fuse-ld=bfd -Wl,--no-keep-memory" to build().

WorMzy commented on 2021-09-14 21:44 (UTC)

Yup, looks like they figured out that they'd packaged the wrong source. Muppets.

micwoj92 commented on 2021-09-14 19:26 (UTC) (edited on 2021-09-14 19:28 (UTC) by micwoj92)

Sums of source need update, seems like the tarball was changed.

WorMzy commented on 2021-09-14 11:58 (UTC)

Upstream appear to have thrown all their toys out of the pram (again), seemingly over some XP-supporting fork, and have taken their git development private. They now only offer unsigned source archives, the first of which, despite being called "palemoon-29.4.1-source.tar.xz" seems to contain the sources for v29.5.0a1. Use at your own risk.

micwoj92 commented on 2021-06-18 15:15 (UTC) (edited on 2021-06-18 15:23 (UTC) by micwoj92)

Great, so the merge requests have been accepted (without a valid reason). Anyway, I reuploaded gtk3 packages. I don't think GTK2 being EOL is valid reason.

micwoj92 commented on 2021-06-11 23:00 (UTC)

Also on AUR there are much more packages that use different gtk versions. I don't see how palemoon is different than any of these.

micwoj92 commented on 2021-06-11 22:58 (UTC)

I made these packages with 29.0.0 release (first one that upstream released gtk3 version). Now both are supported and gtk2 isn't going anywhere soon. WorMzy, maintainer of palemoon (gtk2 variant) said that he wants to use that for gtk2 version and I don't see problem with it. Look and linked comment and one after that.

ainola commented on 2021-06-11 22:36 (UTC)

Hi, micwoj92,

The request for deletion on this package (and palemoon-gtk3-bin) mention that GTK3 is now supported officially. I see that is reflected in recent release notes [1]. Is there any reason to keep these packages around?


WorMzy commented on 2021-06-11 13:17 (UTC)

If that's the case then that is a bug in yay, I won't modify the PKGBUILD to workaround it.

micwoj92 commented on 2021-06-11 13:16 (UTC)

That's problem with yay and not this package, also AUR helpers are not supported.

JuniorJPDJ commented on 2021-06-11 13:13 (UTC)

Please consider removing git sources and add tarballs from github pointing to tags/commits. It will remove not needed dep on git and fix some AUR helpers - eg. yay tries to rebuild palemoon on every new upstream commit.

WorMzy commented on 2021-06-10 16:17 (UTC)

If you want to use palemoon with gtk3, please use palemoon-gtk3 or palemoon-gtk3-bin, this package will continue to build using gtk2.

micwoj92 commented on 2021-06-09 23:49 (UTC)

Both are used.

yochananmarqos commented on 2021-06-09 23:44 (UTC)

It appears GTK3 is now used, please adjust accordingly.

micwoj92 commented on 2021-05-17 11:29 (UTC)

Pale Moon does not build with gcc 11, I will add build dependency on gcc9 (or gcc10 if it becomes available in aur) in next release, if you want to build it now, edit PKGBUILD manually.

micwoj92 commented on 2021-05-15 21:19 (UTC)

FYI build fails with gcc11 so it will need to be switched to gcc10 when it becomes available.

WorMzy commented on 2021-05-04 13:39 (UTC)

Done. Note it's disabled by default, so you'll need to enable it in about:config.

micwoj92 commented on 2021-05-04 03:01 (UTC)

Hello, could you enable av1 for this build? It is enabled in official binary. For some reason it's only mentioned in build instructions for Windows.

micwoj92 commented on 2021-04-27 16:38 (UTC)

Starting with Pale Moon 29.2.0, the browser no longer supports unmaintained legacy Firefox extensions that are not updated for/targeting Pale Moon directly. Please see the relevant announcement for details.

violog commented on 2021-04-21 11:08 (UTC)

I don't understand: this browser is positioned as fork of Firefox focused on performance. While in Firefox speedometer shows 19.4, in Pale Moon it shows 4.95. Why? I did it right in both tests: no other internet connections while surfing.

WorMzy commented on 2021-04-14 16:43 (UTC)

Still builds fine in a clean chroot here. Please upload a full build log (use makepkg's -L flag) to a pastebin.

Out of interest, why is g++ /sbin/g++ on your system? Why is /sbin on your PATH at all?

dreieck commented on 2021-04-14 14:15 (UTC)

Currently, build() fails for me with Failed to parse ccache stats output: secondary config (readonly) /etc/ccache.conf:

 1:48.55 /sbin/g++ -std=gnu++11 -o UnifiedBindings3.o -c -I/[...]/palemoon/src/pmbuild/dist/stl_wrappers -I/[...]/palemoon/src/pmbuild/dist/system_wrappers -include /[...]/palemoon/src/Pale-Moon/platform/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1 -DOS_POSIX=1 -DOS_LINUX=1 -DHAVE_SIDEBAR -DSTATIC_EXPORTABLE_JS_API -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -I/[...]/palemoon/src/Pale-Moon/platform/dom/bindings -I/[...]/palemoon/src/pmbuild/dom/bindings -I/[...]/palemoon/src/pmbuild/dist/include/mozilla/dom -I/[...]/palemoon/src/Pale-Moon/platform/dom/base -I/[...]/palemoon/src/Pale-Moon/platform/dom/canvas -I/[...]/palemoon/src/Pale-Moon/platform/dom/geolocation -I/[...]/palemoon/src/Pale-Moon/platform/dom/html -I/[...]/palemoon/src/Pale-Moon/platform/dom/indexedDB -I/[...]/palemoon/src/Pale-Moon/platform/dom/media/webaudio -I/[...]/palemoon/src/Pale-Moon/platform/dom/svg -I/[...]/palemoon/src/Pale-Moon/platform/dom/workers -I/[...]/palemoon/src/Pale-Moon/platform/dom/xbl -I/[...]/palemoon/src/Pale-Moon/platform/dom/xml -I/[...]/palemoon/src/Pale-Moon/platform/dom/xslt/base -I/[...]/palemoon/src/Pale-Moon/platform/dom/xslt/xpath -I/[...]/palemoon/src/Pale-Moon/platform/dom/xul -I/[...]/palemoon/src/Pale-Moon/platform/js/xpconnect/src -I/[...]/palemoon/src/Pale-Moon/platform/js/xpconnect/wrappers -I/[...]/palemoon/src/Pale-Moon/platform/layout/generic -I/[...]/palemoon/src/Pale-Moon/platform/layout/style -I/[...]/palemoon/src/Pale-Moon/platform/layout/xul/tree -I/[...]/palemoon/src/Pale-Moon/platform/media/mtransport -I/[...]/palemoon/src/Pale-Moon/platform/media/webrtc -I/[...]/palemoon/src/Pale-Moon/platform/media/webrtc/signaling/src/common/time_profiling -I/[...]/palemoon/src/Pale-Moon/platform/media/webrtc/signaling/src/peerconnection -I/[...]/palemoon/src/pmbuild/ipc/ipdl/_ipdlheaders -I/[...]/palemoon/src/Pale-Moon/platform/ipc/chromium/src -I/[...]/palemoon/src/Pale-Moon/platform/ipc/glue -I/[...]/palemoon/src/pmbuild/dist/include -I/[...]/palemoon/src/pmbuild/dist/include/nspr -I/[...]/palemoon/src/pmbuild/dist/include/nss -fPIC -DMOZILLA_CLIENT -include /[...]/palemoon/src/pmbuild/mozilla-config.h -MD -MP -MF .deps/UnifiedBindings3.o.pp -O2 -Wno-format-overflow -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++14-compat -Wc++1z-compat -Wimplicit-fallthrough -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=multistatement-macros -flifetime-dse=1 -g0 -march=x86-64 -mtune=native -O3 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fomit-frame-pointer -fPIC -fpermissive -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -msse2 -mfpmath=sse -pthread -pipe -g -O2 -w -fomit-frame-pointer -Wno-error=shadow /[...]/palemoon/src/pmbuild/dom/bindings/UnifiedBindings3.cpp
 1:48.55 make[5]: *** [/[...]/palemoon/src/Pale-Moon/platform/config/ UnifiedBindings3.o] Error 1
 2:02.48 libdom_media_mp3.a.desc
 2:09.14 libintl_lwbrk.a.desc
 2:09.68 libwidget_x11.a.desc
 2:21.20 libgfx_src.a.desc
 2:26.39 make[4]: *** [/[...]/palemoon/src/Pale-Moon/platform/config/ dom/bindings/target] Error 2
 2:26.39 make[4]: *** Waiting for unfinished jobs....
 2:28.38 libtoolkit_components_perfmonitoring.a.desc
 2:42.99 libdom_media_platforms_ffmpeg_libav55.a.desc
 6:19.72 libipc_ipdl.a.desc
 6:19.95 make[3]: *** [/[...]/palemoon/src/Pale-Moon/platform/config/ compile] Error 2
 6:19.95 make[2]: *** [/[...]/palemoon/src/Pale-Moon/platform/config/ default] Error 2
 6:19.95 make[1]: *** [/[...]/palemoon/src/Pale-Moon/ realbuild] Error 2
 6:19.95 make: *** [ build] Error 2
 6:19.99 0 compiler warnings present.
 6:20.05 Failed to parse ccache stats output: secondary config (readonly)         /etc/ccache.conf
 6:20.06 Notification center failed: Install the python dbus module to get a notification when the build finishes.

Note that I have not altered the PKGBUILD in any way, nor do I have ccache in my makeflags, $CC or $CXX.

It worked like this (using the PKGBUILD as is) previously.

WorMzy commented on 2021-03-07 15:01 (UTC)

@kingkingmax: I can't reproduce that here. It's possible it was a transient server-side problem. If you still have issues, contact upstream. AFAIK there's no source mirror since they took everything down from github.

kingkingmax commented on 2021-03-07 14:32 (UTC) (edited on 2021-03-07 14:36 (UTC) by kingkingmax)

I get 403 error. Anyway to bypass this error?

fatal: unable to access '': The requested URL returned error: 403

micwoj92 commented on 2021-03-02 16:20 (UTC)

Thank you for pinning!

WorMzy commented on 2021-03-02 16:19 (UTC) (edited on 2021-12-18 12:25 (UTC) by WorMzy)

The following key is used to sign source archives:


Import it into your keyring however you want.

micwoj92 commented on 2021-03-02 16:12 (UTC)

When do people learn that this is not package issue? Try importing with different keyserver. Or if that is so big issue for you then you can edit the pkgbuild or just use aur helper which can skip pgp checks such as pikaur.

keepitsimpleengr commented on 2021-03-02 16:08 (UTC) (edited on 2021-03-02 16:10 (UTC) by keepitsimpleengr)

(yay -Su)… :: PGP keys need importing:

-> 3059E09144F56804F0FBF4E126B40624BDBFD9F3, required by: palemoon

==> Import? [Y/n]

:: Importing keys with gpg...

gpg: keyserver receive failed: No name

problem importing keys

WorMzy commented on 2021-02-05 00:13 (UTC)

That commit id is the latest to the master branch, so I'd hazard a guess that the source array (specifically ?signed#commit=79ff7796e5) isn't being parsed correctly for some reason, effectively meaning you're building palemoon-git rather than the stable version. No idea why that's happening, but I'd guess either yaourt bug (it's ancient and abandoned, don't use it) or you have a reaaaaally old makepkg version kicking about.

micwoj92 commented on 2021-02-05 00:02 (UTC) (edited on 2021-02-05 00:03 (UTC) by micwoj92)

yaourt? Did you try just with

git clone
cd palemoon


jghodd commented on 2021-02-04 23:47 (UTC)

@WorMzy i'm getting a different commit

commit bf093ea79550c71889832eada5f6d7067574feec

not sure why though. i'm using a clean "yaourt -G palemoon" into a clean/new directory and PKGBUILD clearly shows _commit=79ff7796e5

WorMzy commented on 2021-02-04 23:35 (UTC) (edited on 2021-02-04 23:39 (UTC) by WorMzy)

Then you're checking out the wrong commit of the Pale-Moon repo somehow. What does git show -q from inside $srcdir/Pale-Moon show? Should show:

commit 79ff7796e598775f30e00ec251e5c094e31ebe94 (HEAD -> makepkg, tag: 29.0.0_Release, tag: 29.0.0_RC2, origin/release)
Author: Moonchild <>                    
Date:   Sat Jan 30 11:15:07 2021 +0000
    Update back-end branch pointer to UXP/release with BB fix.

(excuse formatting, using termux on phone)

jghodd commented on 2021-02-04 23:16 (UTC)

@WorMzy UXP/dom/html/HTMLMenuItemElement.cpp is correct, but Pale-Moon/platform/dom/html/HTMLMenuItemElement.cpp is incorrect.

jghodd commented on 2021-02-04 23:13 (UTC) (edited on 2021-02-04 23:14 (UTC) by jghodd)

@WorMzy I'm getting:

Submodule path 'platform': checked out 'e1daeef18312a0cb17eda6bed7f363d8748ed4a3'

...and that's with a clean directory to start.

WorMzy commented on 2021-02-04 23:03 (UTC)

What does prepare() say? Should read:

==> Starting prepare()...
Submodule 'platform' ( registered for path 'platform'
Cloning into '/build/palemoon/src/Pale-Moon/platform'...
Submodule path 'platform': checked out '304496d4ab61496a43d9d42cf8deb7811d772fe2'

jghodd commented on 2021-02-04 22:57 (UTC)

@micwoj92 are we getting the wrong UXP commit?

jghodd commented on 2021-02-04 22:49 (UTC)

@micwoj92 hm. yeah, i see that. and yet for some reason it's not.

should be:

NS_NewHTMLMenuItemElement(already_AddRefed<mozilla::dom::NodeInfo>&& aNodeInfo,
                          mozilla::dom::FromParser aFromParser) {
  if (mozilla::Preferences::GetBool("dom.menuitem.enabled")) {
    return new mozilla::dom::HTMLMenuItemElement(nodeInfo, aFromParser);
  } else {
    return new mozilla::dom::HTMLUnknownElement(nodeInfo);

but is still:

NS_NewHTMLMenuItemElement(already_AddRefed<mozilla::dom::NodeInfo>&& aNodeInfo,
                          mozilla::dom::FromParser aFromParser) {
  RefPtr<mozilla::dom::NodeInfo> nodeInfo(aNodeInfo);
  if (mozilla::Preferences::GetBool("dom.menuitem.enabled")) {
    return new mozilla::dom::HTMLMenuItemElement(nodeInfo.forget(), aFromParser);
  } else {
    return new mozilla::dom::HTMLUnknownElement(nodeInfo.forget());

micwoj92 commented on 2021-02-04 22:25 (UTC)

@jghodd that commit should be included

jghodd commented on 2021-02-04 22:11 (UTC)

Getting a build error in Pale-Moon/platform/dom/html/HTMLMenuItemElement.cpp

Here's the bug report which has been closed and fixed. PKGBUILD needs to be updated to a more recent commit to include this fix.

micwoj92 commented on 2021-02-02 22:33 (UTC)

Thanks, I've made it. Just copypaste, but replaced gtk2 with gtk3, AFAIK it still needs gtk2 to build but I am not sure if it's needed to run.

WorMzy commented on 2021-02-02 21:55 (UTC)

I have no interest in building palemoon with gtk3. Feel free to make a palemoon-gtk3 package though.

micwoj92 commented on 2021-02-02 19:46 (UTC)

So now that the official releases provide both gtk2 and gtk3 could this package use gtk3 and new palemoon-gtk2 be made? or maybe otherwise, this stays gtk2 and there is palemoon-gtk3?

haawda commented on 2020-12-22 16:26 (UTC)

WorMzy, I found that palemoon-bin has exactly the same behaviour, and it indeed seems a feature, not a bug. And it is old...


WorMzy commented on 2020-12-22 15:29 (UTC)

@haawda: I don't think plugin-container should be called by itself. It's called by the browser as required which presumably handles shared library access.

See for Firefox's description of plugin-container (I couldn't find an equivalent page on the palemoon site, but I doubt the functionality is that different)

@micwoj92: Feel free to do so locally, but I suspect duplicate packages that just uses a different source to the original would be removed from the AUR by TUs. Feel free to ask on the mailing list (aur-general) and/or IRC (#archlinux-aur on freenode) if you want to confirm.

Alternatively, maybe use palemoon-bin?

micwoj92 commented on 2020-12-21 18:56 (UTC)

That makes sense. I hope I am not the only one frequently deleting build directory of my aur helper. Do you think it is worth to make package that would be same just download the tarballs?

haawda commented on 2020-12-21 15:23 (UTC)

It is not an issue with palemoon itself, but running the plugin-container results in

# /usr/lib/palemoon/plugin-container
/usr/lib/palemoon/plugin-container: error while loading shared libraries: cannot open shared object file: No such file or directory

But I am not sure if there are circumstances where running this binary from command line is needed.

WorMzy commented on 2020-12-21 12:37 (UTC)

@haawda: what is the actual problem? is loaded for me:

$ strace palemoon |& grep libxul 
access("/usr/lib/palemoon/", R_OK) = 0
openat(AT_FDCWD, "/usr/lib/palemoon/", O_RDONLY) = 4
openat(AT_FDCWD, "/usr/lib/palemoon/", O_RDONLY|O_CLOEXEC) = 4

@micwoj92: Upstream release new versions semi-regularly (sometimes multiple releases per month). Although the initial clone may be substantial, every update after that will only include the upstream changes since the last time you pulled the repos, drastically reducing the amount of bandwidth consumed in the long run.

micwoj92 commented on 2020-12-20 01:36 (UTC)

Is there a reason why this does not download tarballs? This would greatly reduce download from 730+ to only about 200 MB.

haawda commented on 2020-12-19 12:31 (UTC)

There seem to be some issues with libraries not found. But they are there.

ldd /usr/lib/palemoon/plugin-container => not found

ldd /usr/lib/palemoon/ => not found => not found

ldd /usr/lib/palemoon/ => not found

ldd /usr/lib/palemoon/ => not found

ldd /usr/lib/palemoon/browser/components/ => not found

This output comes from the checkrebuild script included in the rebuild-detector package run wit -v option, but plain ldd tells the same.

zootboy commented on 2020-10-27 20:06 (UTC)

As always, you need to import GPG keys manually (and ideally verify them out-of-band). Make sure gpg is set up with a keyserver, then run this:

$ gpg --recv-key 40481E7B8FCF9CEC

keepitsimpleengr commented on 2020-10-27 19:59 (UTC)

So just now updating four palemoons on four systems and after 2 I get:

Pale-Moon git repo ... FAILED (unknown public key 40481E7B8FCF9CEC)Pale-Moon git repo ... FAILED (unknown public key 40481E7B8FCF9CEC)


WorMzy commented on 2020-10-27 15:06 (UTC)

Further note: Upstream have renamed the repositories again. If you previously modified your git clone configs to point to you will need to edit them again to point to

WorMzy commented on 2020-10-22 09:53 (UTC) (edited on 2020-10-27 15:03 (UTC) by WorMzy)

Note the repositories have moved to and, if you previously cloned the repos, you can update the URL in the config files (i.e. $SRCDEST/Pale-Moon/config and $SRCDEST/UXP/config) so you don't need to clone the full repo again.

WorMzy commented on 2020-10-22 09:50 (UTC)

Thanks for the heads up, update pushed.

smopro commented on 2020-10-22 07:15 (UTC)

@WorMzy change source links please

smopro commented on 2020-10-21 22:45 (UTC)

"hotfix" for pgp keys - gpg --keyserver --recv-keys 'key'

smopro commented on 2020-10-21 22:42 (UTC)

github repo is down - topic new repo is

wompa commented on 2020-10-11 03:38 (UTC)

@micwoj92 its doesnt build anyway because of that pgp key issue

micwoj92 commented on 2020-10-03 08:45 (UTC)

@pieraper44 this is not issue with this package

pieraper44 commented on 2020-10-03 00:46 (UTC)


pieraper44 commented on 2020-10-03 00:39 (UTC)

: PGP keys need importing: -> 3059E09144F56804F0FBF4E126B40624BDBFD9F3, required by: palemoon -> 3DAD8CD107197488D2A2A0BD40481E7B8FCF9CEC, required by: palemoon ==> Import? [Y/n] y :: Importing keys with gpg... gpg: keyserver receive failed: General error problem importing keys

thanks for the broken and useless package never using this browser again

WorMzy commented on 2020-09-29 19:11 (UTC)

Aye, I remembered immediately after pushing, but by then it was too late. Maybe next time!

micwoj92 commented on 2020-09-29 18:37 (UTC)

Woops, seems like you forgot to reset pkgrel xd

WorMzy commented on 2020-09-22 10:06 (UTC)

I wasn't aware there was an issue. I've pushed an update out which should fix it now.

zootboy commented on 2020-09-22 04:26 (UTC)

I encountered this and didn't know it wasn't intentional. I just went and updated the couple of extensions that I wanted with the pale moon GUID. (The big one for me was Cert Patrol, which seems to have a totally dead upstream).

Build mistake or not, it's probably a good idea to get the sources now for any extensions you find important, as they'll likely become harder and harder to find as the Great Firefox XUL Purge becomes more and more distant history.

PinkCathodeCat commented on 2020-09-22 01:06 (UTC)

Has this issue ( and been addressed in the build? Some of my extensions are disabled by 28.13 - (this is different to the warning that some Firefox extensions are not incompatible), and some of them were relatively important to me. Thanks!

ryan659 commented on 2020-07-15 19:13 (UTC)

I stand corrected it seems, odd. It really does seem to work here too without that (XFCE with vala-panel-appmenu). Maybe I was just a bit too over-zealous with packages when I was setting up. Either way, thanks for making me confirm!

WorMzy commented on 2020-07-14 20:37 (UTC)

ryan659: Seems to work without that on KDE. Could you (or someone else) confirm that it is needed on other app-menu-capable DEs that don't use vala-panel? I'm not opposed to adding the optdep, but if it's only for a single panel app, I feel the optdep should be coming from the panel's package rather than individual applications.

ryan659 commented on 2020-07-14 15:38 (UTC)

As of 28.11.0 appmenu-gtk-module is an optional depend for global menubar support (via vala-panel-appmenu for various DEs, or global menubar for KDE). Requires the setting ui.use_global_menubar set to true in the application though.

WorMzy commented on 2020-06-07 20:23 (UTC)

Whoops, yep. Thanks for letting me know, Jim243, I've pushed the updated now.

Jim243 commented on 2020-06-07 20:00 (UTC)

When I run makepkg, the validity check fails for Was a change to accidentally left out of the last commit?

WorMzy commented on 2020-06-06 21:58 (UTC)

Thanks for the heads up, barius.

It seems the precompiled palemoon-bin doesn't link against gconf, and gconf isn't listed as a required dependency in the Arch instructions at, so I've added that change in.

barius commented on 2020-06-05 22:37 (UTC)

FYI 28.10.0 compiles fine for me with gcc 10.1.0 in clean chroot

Not sure if relevant but I am also using 'ac_add_options --disable-gconf' in to avoid the dependency on gconf (deprecated since about a decade). I've been using that for every build for the last 6 months, since gconf moved to AUR.

Winux commented on 2020-05-24 12:40 (UTC) (edited on 2020-05-24 12:40 (UTC) by Winux)

Thanks @WorMzy! Now it is working!

tony.aln commented on 2020-05-24 12:39 (UTC)

Yeah @WorMzy, I totally agree, and the people in this project are great, for working towards newer compiler support and all the other accomplishments during the last almost 5 years in which I've been using this browser and following the project. And yeah, gcc8 is the best choice we've got for now. Have a nice weekend y'all.

WorMzy commented on 2020-05-24 11:26 (UTC)

I've changed the compiler to gcc8 for now. It's somewhat heartening that upstream is working on gcc10 compatibility instead of reverting to their previous stance of only supporting gcc4 (or some equally antiquated compiler). Maybe in a release or two modern gcc support will be there.

Winux commented on 2020-05-23 16:38 (UTC)

Hi, I'm having a problem iwith installing palemoon. I got a error while makeing the package. Here you can see a picture about the error:

Can you help me? thanks in advance

tony.aln commented on 2020-05-20 00:05 (UTC)

Well, good news! The devs have worked some fixes up so the codebase compiles with gcc10, as stated on the issue tracker on their repo [1]. I'm gonna wait with my 28.9.3 built with gcc9 for now. 1:

tony.aln commented on 2020-05-15 16:59 (UTC) (edited on 2020-05-15 17:11 (UTC) by tony.aln)

-flto=2 is not working since the change to gcc 10, the build gets busted before linking Normal flags should work but I'm gonna test to find out. Has anyone built this with gcc 10 yet? Edited twice for clarification on the data. Gonna get back here to tie the knot completely.

bruno commented on 2020-05-04 20:31 (UTC)

sorry for the inconvenience, you suspect well, my tmp repertory was too small to building. Building very well. thanks

WorMzy commented on 2020-05-04 12:33 (UTC)

I'd need to see the full makepkg output, in English (see this) to be sure, but I suspect you aren't building with a clean source tree. Try using makepkg -C to start the build with a clean $srcdir.

bruno commented on 2020-05-04 12:16 (UTC) (edited on 2020-05-04 12:18 (UTC) by bruno)

Hello, thanks for pale moon. Some errors, any idea please?

warning: Le clone a réussi, mais l'extraction a échoué.
Vous pouvez inspecter ce qui a été extrait avec 'git status'
et réessayer avec 'git restore --source=HEAD :/'

==> ERREUR : Échec lors de la création d’une copie de travail du dépôt UXP git
==> ERREUR : Makepkg n'a pas pu construire palemoon.

WorMzy commented on 2020-03-28 12:08 (UTC) (edited on 2020-03-28 12:10 (UTC) by WorMzy)

The build process checks out UXP at commit a731633d7b50e4ec88a1a4b54d578d1abb3c4b12:

==> Starting prepare()...
Submodule 'platform' ( registered for path 'platform'                       
Cloning into '/build/palemoon/src/Pale-Moon/platform'...
Submodule path 'platform': checked out 'a731633d7b50e4ec88a1a4b54d578d1abb3c4b12'

...which is what the submodule was configured as when was tagged. If that isn't correct, then it's an upstream problem you guys need to fix. ;)

mattatobin commented on 2020-03-28 11:14 (UTC) (edited on 2020-03-28 11:15 (UTC) by mattatobin)

I really hope you have this building with the right UXP commit point else you will have serious issues.

It might be better to request specific tarballs from github.

See the new Linux Build Instructions @

skyblue commented on 2019-11-12 03:05 (UTC)

Great browser -- really fast! It took a while to compile, but did so without any errors. I'm glad this is in the repository. :)

WorMzy commented on 2019-10-28 20:29 (UTC)

Thanks for pointing out the breakage, nazarianin. Package updated.

I've not bumped the pkgrel, as people who built the current version before glibc 2.30 hit [core] should continue to work fine, so there's little benefit for them to rebuild.

nazarianin commented on 2019-10-28 18:32 (UTC)

Hi. Can you add this patch for compile with newer glibc versions?

dreieck commented on 2019-08-06 20:34 (UTC)


The solution was to remove --strip-all from the LDFLAGS.

I added to the PKGBUILD:

export LDFLAGS="$(sed 's|,--strip-all||g' <<< "${LDFLAGS}")"

dreieck commented on 2019-08-06 12:18 (UTC) (edited on 2019-08-06 20:33 (UTC) by dreieck)

When trying to build, build fails for me with

110:19.04 libxul_s.a.desc
110:33.40 nm: no symbols
110:33.40 NSModules are not ordered appropriately
110:33.40 make[5]: *** [/tmp/palemoon/src/UXP/config/] Error 1
110:33.40 make[5]: *** Deleting file ''
110:33.43 make[4]: *** [/tmp/palemoon/src/UXP/config/ toolkit/library/target] Error 2
110:33.45 make[3]: *** [/tmp/palemoon/src/UXP/config/ compile] Error 2
110:33.48 make[2]: *** [/tmp/palemoon/src/UXP/config/ default] Error 2
110:33.50 make[1]: *** [/tmp/palemoon/src/UXP/ realbuild] Error 2
110:33.52 make: *** [ build] Error 2
110:33.55 499 compiler warnings present.
110:33.90 Failed to parse ccache stats output: stats updated                       Tue Aug  6 14:09:21 2019
==> ERROR: A failure occurred in build().

Just before starting the build, the *FLAGS-variables are:


-O3 -g0 -march=x86-64 -mtune=native -ftree-vectorize -pipe --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fomit-frame-pointer -Wl,-z,relro,-z,now -D_FORTIFY_SOURCE=2 -fPIC -fstack-protector


-O3 -g0 -march=x86-64 -mtune=native -ftree-vectorize -pipe --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fomit-frame-pointer -Wl,-z,relro,-z,now -D_FORTIFY_SOURCE=2 -fPIC -fstack-protector -fpermissive

CPPFLAGS (set in the PKGBUILD, not in /etc/makepkg.conf):

 -O2 -Wno-format-overflow



and build is executed with

python2 mach build -j1

Any idea what could be the problem here?

tony.aln commented on 2019-07-13 17:59 (UTC)

Thank you for the consideration. Of course, I will inform you if there are any issues.

WorMzy commented on 2019-07-09 11:48 (UTC)

Thanks for formatting. Is there anything else useful in the referenced log file and/or the system journal? Can you reproduce the problem with palemoon-bin?

I note you're using the intel video driver, if it's an option for your system, see if you can reproduce the problem with the modesetting driver.

syrenity commented on 2019-07-08 18:43 (UTC)

Formatted, worth saying there is a new glibc and lib32-glibs update, wonder if resolves the issue.

WorMzy commented on 2019-07-07 16:55 (UTC)

Thanks for investigating. I've successfully built with your proposed changes, and tested that the browser launches with this build. I'm happy to introduce this change the next time upstream makes a release, but if you're running your build and encounter any issues between then and now, please let me know.

tony.aln commented on 2019-07-07 15:37 (UTC) (edited on 2019-07-07 15:58 (UTC) by tony.aln)

I had some time to read and try some stuff. So, GCC 9's -Werror=format-overflow warning is being treated as an error and aborting the build. From gcc's online documentation (available at :

"Warn about calls to formatted input/output functions such as snprintf and vsnprintf that might result in output truncation. When the exact number of bytes written by a format directive cannot be determined at compile-time it is estimated based on heuristics that depend on the level argument and on optimization. While enabling optimization will in most cases improve the accuracy of the warning, it may also result in false positives. Except as noted otherwise, the option uses the same logic -Wformat-overflow."

Therefore, by enabling lto by using -flto=2(cpu thread number), gcc9 analyzed the code better, didn't give the warning nor need the fix and produced a space net change savings of about 10MiB in comparison with the same version without lto, performance benefits are not known (it feels faster but it may be just placebo, I have to see how to quantify and display the performance gains) and a negligible amount less of time to build, but used more ram to build. Without lto it's a warning and the warning can be disabled with -Wno-format-overflow in the CPPFLAGS variable in: PKGBUILD

like this: export CPPFLAGS="$CPPFLAGS -O2 -Wno-format-overflow"

and in the like this: ac_add_options --enable-optimize="-O2 -Wno-format-overflow"

The build progresses smoothly with gcc9 by just adding that and by commenting the gcc8 CC and CXX export lines at the beginning of mozconfig and removing gcc8 dependency from the PKGBUILD. Please, feel free to reproduce the fix provided and hopefully instate the needed changes so others can build with gcc9 smoothly as well. Enjoy. Edit1: fixed formatting Edit2: fixed space savings wording Edit3:fixes

WorMzy commented on 2019-07-05 09:25 (UTC)

Please use markdown to format your post, syrenity. Three backticks before and after the output should make it into a readable code block.

syrenity commented on 2019-07-04 22:43 (UTC) (edited on 2019-07-08 18:42 (UTC) by syrenity)

[  7931.122] (EE) Backtrace:
[  7931.122] (EE) 0: /usr/lib/Xorg (xorg_backtrace+0x4d) [0x55c7efcc30cd]
[  7931.122] (EE) 1: /usr/lib/Xorg (0x55c7efc12000+0xb1209) [0x55c7efcc3209]
[  7931.122] (EE) 2: /usr/lib/ (0x7f1fe5f85000+0x3a7e0) [0x7f1fe5fbf7e0]
[  7931.122] (EE) 3: /usr/lib/ (gsignal+0x145) [0x7f1fe5fbf755]
[  7931.122] (EE) 4: /usr/lib/ (abort+0x125) [0x7f1fe5faa851]
[  7931.122] (EE) 5: /usr/lib/ (0x7f1fe5f85000+0x7ca38) [0x7f1fe6001a38]
[  7931.122] (EE) 6: /usr/lib/ (0x7f1fe5f85000+0x8325a) [0x7f1fe600825a]
[  7931.122] (EE) 7: /usr/lib/ (0x7f1fe5f85000+0x84c5c) [0x7f1fe6009c5c]
[  7931.122] (EE) 8: /usr/lib/xorg/modules/drivers/ (0x7f1fe44df000+0x5992f) [0x7f1fe453892f]
[  7931.122] (EE) 9: /usr/lib/Xorg (0x55c7efc12000+0x12d3ae) [0x55c7efd3f3ae]
[  7931.122] (EE) 10: /usr/lib/Xorg (0x55c7efc12000+0xfd945) [0x55c7efd0f945]
[  7931.122] (EE) 11: /usr/lib/Xorg (0x55c7efc12000+0x10e275) [0x55c7efd20275]
[  7931.122] (EE) 12: /usr/lib/Xorg (0x55c7efc12000+0x15ceee) [0x55c7efd6eeee]
[  7931.122] (EE) 13: /usr/lib/Xorg (FreeResource+0xcd) [0x55c7efd6f18d]
[  7931.122] (EE) 14: /usr/lib/Xorg (0x55c7efc12000+0x17ab6e) [0x55c7efd8cb6e]
[  7931.122] (EE) 15: /usr/lib/Xorg (0x55c7efc12000+0x37fe8) [0x55c7efc49fe8]
[  7931.122] (EE) 16: /usr/lib/ (__libc_start_main+0xf3) [0x7f1fe5fabee3]
[  7931.122] (EE) 17: /usr/lib/Xorg (_start+0x2e) [0x55c7efc4a30e]
[  7931.122] (EE) 
[  7931.122] (EE) 
Fatal server error:
[  7931.122] (EE) Caught signal 6 (Aborted). Server aborting
[  7931.122] (EE) 
[  7931.122] (EE) 
Please consult the The X.Org Foundation support 
 for help. 
[  7931.122] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[  7931.122] (EE) 
[  7931.122] (II) AIGLX: Suspending AIGLX clients for VT switch
[  7932.335] (EE) Server terminated with error (1). Closing log file.

syrenity commented on 2019-07-04 22:40 (UTC)

Latest version randomly crashes X server on Dell XPS 15 (9570).

Had to stop using it for the meanwhile.

tony.aln commented on 2019-07-04 20:09 (UTC)

huh, I built them without any patches or weird flags, and I read that thread a while back too. What I did was remove ggc8 from the PKGBUILD and the mozconfig and voilà. That gentleman on the thread is the one which is building pale moon with gcc9 right now for fedora which I mentioned before. I'm gonna try on some boxes without -flto to see if I can succeed building it.

WorMzy commented on 2019-07-04 11:25 (UTC)

I got a build failure with gcc9 (the same build failure that upstream was aware of in March) which is why I've switched to gcc8 in the mozconfig.

I'd rather not include patches to make the package build with gcc9, as upstream get really arsey about that sort of thing, and it's not worth dealing with their antics. The best thing you can do is make noise on their bug tracker about it (but don't expect anything to change).

tony.aln commented on 2019-07-04 09:38 (UTC)

For the record, gcc9 is building Pale Moon nicely since version 28.5, although apparently is not endorsed (or supported) by the devs yet. PM is built with gcc9 for fedora (copr repo) with an official third-party build endorsed by Moonchild Productions. The patch to build it with gcc8 seems unnecessary, I wonder what happened... I have to warn that building PM with gcc9 uses a tad bit of RAM more... Well, I built with -flto enabled so that takes more RAM, disk space and additional time to build. At linking stages, it will place files in /tmp, which in arch is tmpfs. So if you don't have much ram to spare, I think it's best not to compile with flto because of the added ram usage. Maybe you could mount tmpfs in disk and slash part of ram usage. Make sure to have at least 12G of RAM on the build PC so it's not needed to change /tmp to disk.

WorMzy commented on 2019-06-05 17:09 (UTC)

Looks like you found the culprit, but if you still get build failures after fixing your space issue, post the new logs.

keepitsimpleengr commented on 2019-06-05 16:18 (UTC) (edited on 2019-06-05 16:30 (UTC) by keepitsimpleengr)



DEBUG: | /var/tmp/conftest.wrS_a1.c:8:1: fatal error: error closing /tmp/ccPfgeq6.s: No space left on device <- oops

WorMzy commented on 2019-06-05 15:41 (UTC)

Cannot reproduce. Please post the full build output and also upload /home/ljohnson/AUR/palemoon/src/pmbuild/config.log to a pastebin and link here.

keepitsimpleengr commented on 2019-06-05 14:57 (UTC)

Compile fail... 0:03.86 File "/home/ljohnson/AUR/palemoon/src/UXP/python/mozbuild/mozbuild/", line 203, in create 0:03.86 'Failed to create virtualenv: %s' % self.virtualenv_root) 0:03.86 Exception: Failed to create virtualenv: /home/ljohnson/AUR/palemoon/src/pmbuild/_virtualenv

WorMzy commented on 2019-03-28 08:48 (UTC) (edited on 2019-03-28 10:50 (UTC) by WorMzy)

Jerome's issue (in the linked, linked thread) was that he needed to rebuild freshplayerplugin-git as it was linked against an old version of ICU. See

Rebuild your freshplayer and see if you still get crashes.

jghodd commented on 2019-03-27 22:22 (UTC) (edited on 2019-03-27 23:08 (UTC) by jghodd)

@WorMzy yup. been there. done that.

Edit: palemoon is incompatible with freshplayerplugin. remove any incarnation of this package and palemoon runs.

WorMzy commented on 2019-03-27 19:33 (UTC)

If you suspect a bug in the palemoon code, then your best bet is to seek support from the palemoon devs. Since you can reproduce the crash with the palemoon-bin package, get them a stacktrace from that (they are unlikely to respond well to a crash report from an independent build, even if it is their code that's getting built).

jghodd commented on 2019-03-27 19:00 (UTC) (edited on 2019-03-27 19:07 (UTC) by jghodd)

@WorMzy I'm using the latest version of libxt - even downloaded the source from xorg and rebuilt it to make sure. same problem.

the output from pacman -Qkk libxt:

libxt: 340 total files, 0 altered files

i'll check the latest update and see if it changes anything. i have a debug build of palemoon to work with, but it still shows some optimizations even though as far as i could tell, all optimization was turned off via - so, i can't see all variable/parameter values when i run a backtrace in gdb.

this issue has apparently come up a number of times with palemoon. unfortunately, it appears that as soon as someone identifies libxt as the issue, all discussion in the relevant threads abruptly ends providing no solutions.

Edit: i wouldn;t assume there's something wrong with my system. it could be that i have the latest version of something installed that interacts badly with a bug in palemoon. because i maintain my own distro, i have to keep every package up to date, all the time.

WorMzy commented on 2019-03-26 18:52 (UTC) (edited on 2019-03-26 19:07 (UTC) by WorMzy)

No problems here (package built Mon 25 Feb 2019). Will try rebuilding, but since you have the same issue with the -bin package, I would guess there's an issue on your system.

pacman -Qkk libxt would be a good place to start checking.

EDIT: Rebuild completed with no change in behaviour.

jghodd commented on 2019-03-26 17:22 (UTC)

This version (28.4.0) crashes (SEGV) when loading - so does the binary package, btw.

WorMzy commented on 2019-02-25 14:29 (UTC)

Thanks for this flag. I am indeed Away From Keyboard, but I have my laptop with my ssh keys on it this time, so update pushed. :)

WorMzy commented on 2019-01-24 22:42 (UTC)

Thanks for the heads up, haawda. Update pushed.

haawda commented on 2019-01-24 21:50 (UTC) (edited on 2019-01-24 21:50 (UTC) by haawda)

Well, palemoon 28.3.0 obviously was quite shortliving, there now is 28.3.1. The "quick version bump"-Method applies here, too.

WorMzy commented on 2019-01-24 19:32 (UTC) (edited on 2019-01-24 19:32 (UTC) by WorMzy)

Sorry for the delay, I've pushed the update out now.

I fully expect the next PM release to be around the end of February, as that's when I go to Japan for two weeks. :P

EDIT: Thanks for confirming that in the interim, barius.

barius commented on 2019-01-20 01:47 (UTC)

Just to let you know, the "quick pkgver bump" approach worked perfectly for me (v 28.2.2 -> 28.3.0).

WorMzy commented on 2019-01-18 09:26 (UTC)

I'm starting to think these updates are timed to me being AFK... :o

I don't currently have access to my dev machine, but I'll update the package ASAP. For the impatient, I don't think there's anything build-breaking in the release notes, so this should be a quick pkgver bump. There is also the palemoon-bin package, which is already updated.

WorMzy commented on 2018-12-11 17:29 (UTC)

I'm AFK until next week, if I get chance I'll update the package before I get home, but otherwise it'll be updated on the 16th/17th.

lefsha commented on 2018-09-11 16:35 (UTC) (edited on 2018-09-11 16:36 (UTC) by lefsha)

Thanks WorMzy! It works now. It's possible, that I faced out of memory issue. Although no other issue with other programs has been recorded. To make it easier for compiler I have removed -pipe option.

WorMzy commented on 2018-08-29 10:12 (UTC)

The actual error in your build is:

Assembler messages:
end of file not at end of a line; newline inserted
Killed signal terminated program cc1plus
compilation terminated.

In the directory  /build/palemoon/src/pmbuild/layout/base
The following command failed to execute properly:
/usr/bin/g++ -std=gnu++11 -o Unified_cpp_layout_base2.o -c -I/build/palemoon/src/pmbuild/dist/stl_wrappers -I/build/palemoon/src/pmbuild/dist/system_wrappers -include /build/palemoon/src/UXP/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1 -DOS_POSIX=1 -DOS_LINUX=1 -DSTATIC_EXPORTABLE_JS_API -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -I/build/palemoon/src/UXP/layout/base -I/build/palemoon/src/pmbuild/layout/base -I/build/palemoon/src/pmbuild/ipc/ipdl/_ipdlheaders -I/build/palemoon/src/UXP/ipc/chromium/src -I/build/palemoon/src/UXP/ipc/glue -I/build/palemoon/src/UXP/layout/forms -I/build/palemoon/src/UXP/layout/generic -I/build/palemoon/src/UXP/layout/mathml -I/build/palemoon/src/UXP/layout/printing -I/build/palemoon/src/UXP/layout/style -I/build/palemoon/src/UXP/layout/svg -I/build/palemoon/src/UXP/layout/tables -I/build/palemoon/src/UXP/layout/xul -I/build/palemoon/src/UXP/layout/xul/tree -I/build/palemoon/src/UXP/docshell/base -I/build/palemoon/src/UXP/dom/base -I/build/palemoon/src/UXP/dom/html -I/build/palemoon/src/UXP/dom/svg -I/build/palemoon/src/UXP/dom/xbl -I/build/palemoon/src/UXP/view -I/build/palemoon/src/pmbuild/dist/include -I/build/palemoon/src/pmbuild/dist/include/nspr -I/build/palemoon/src/pmbuild/dist/include/nss -fPIC -DMOZILLA_CLIENT -include /build/palemoon/src/pmbuild/mozilla-config.h -MD -MP -MF .deps/Unified_cpp_layout_base2.o.pp -D_FORTIFY_SOURCE=2 -O2 -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++14-compat -Wc++1z-compat -Wimplicit-fallthrough -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -flifetime-dse=1 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -msse2 -mfpmath=sse -pthread -pipe -g -O2 -fomit-frame-pointer -I/build/palemoon/src/pmbuild/dist/include/cairo -Wno-error=shadow /build/palemoon/src/pmbuild/layout/base/Unified_cpp_layout_base2.cpp
Unified_cpp_layout_base2.o] Error 1
layout/base/target] Error 2
*** Waiting for unfinished jobs....

From what I've read, these messages are just a red herring though, and the actual cause is likely to be that you are running out of memory. How much RAM (+swap) do you have? Are you running any other memory-intensive processes at the same time as the compilation?

lefsha commented on 2018-08-26 09:20 (UTC)

WorMzy commented on 2018-08-25 10:12 (UTC)

Upload the entire build log to a pastebin and post it here?

lefsha commented on 2018-08-25 09:54 (UTC)

Received exact the same error in the clean chroot environment made with help of devtools and extra-x86_64-build. Again the previous version works well either way. Something has been broken inbeetween for sure.

WorMzy commented on 2018-08-19 11:49 (UTC)

Builds fine in a clean chroot, and there isn't enough information in your comment to diagnose the problem. All I can suggest is to use the default C{,XX}FLAGS. Of course, building in a clean-chroot is definitely preferable.

lefsha commented on 2018-08-18 20:29 (UTC)

Since last update unable to compile palemoon 28.0.0-2 anymore even with empty CFLAGS.

27:12.97 make[3]: [/tmp/yaourt-tmp-root/aur-palemoon/src/UXP/config/ compile] Error 2 27:12.97 make[2]: [/tmp/yaourt-tmp-root/aur-palemoon/src/UXP/config/ default] Error 2 27:12.97 make[1]: [/tmp/yaourt-tmp-root/aur-palemoon/src/UXP/ realbuild] Error 2 27:12.97 make: [ build] Error 2

WorMzy commented on 2018-08-17 21:07 (UTC)

Thanks for the heads up. Checking the palemoon "building for source" dev page [1] simply says that gcc 4.9 is the minimum required version, so I guess they've actually brought their code up-to-snuff for the latest compilers. I've tested that it builds, launches, and seems to work fine, but I don't use palemoon these days, so there may be stability issues when building with gcc 8 that I'm not hitting in my testing. Please let me know if you have stability issues (preferably before you inform upstream and they chuck all their toys out of their pram because someone dared to use a modern compiler...)


lefsha commented on 2018-08-17 19:53 (UTC) (edited on 2018-08-17 20:12 (UTC) by lefsha)

Have successfully built palemoon 28.0.0-1 with core/gcc 8.2.0-2 (base-devel) [installed] CFLAGS="-march=native -mtune=native -O3 -pipe -fstack-protector-strong -fno-plt" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" MAKEFLAGS="-j1" banned from Arch Forum, can't report there. Pls, consider to remove GCC5 dependency and may be report to upstream.

WorMzy commented on 2018-05-04 18:43 (UTC)

Hah, it's been in community/ before. I'm surprised to see it back now that it's EOL though. Looks like it's needed by cuda for now..

7314776 commented on 2018-05-04 18:38 (UTC) (edited on 2018-05-04 18:38 (UTC) by 7314776)

Grats gentlemen! gcc5 has now been pushed to community repo, so no need to have sexual relations with build trying to get it into your system, just install.


Мои поздравления! gcc5 теперь собирается в репозитории community, поэтому можно не ипаццо с его сборкой, а просто установить оттуда.

haawda commented on 2018-03-11 20:59 (UTC)

I was able to compile palemoon 27.8.1 with gcc4.9 (built using the AUR PKGBUILD) and this patch:

okabekudo commented on 2018-02-15 18:33 (UTC) (edited on 2018-02-15 18:35 (UTC) by okabekudo)

@WorMzy I'm not running anything else and I'm not compiling in a tmpfs either nor do I have a swap parition. But it worked a few weeks before.

WorMzy commented on 2018-02-15 17:38 (UTC)

Upstream recommends having more than 4GB of RAM, so you should have more than enough. Are you running any other memory-intensive programs while you're compiling? Are you compiling on a tmpfs? Do you have a swap file/partition? What is your swappiness set to? These are the sorts of things that you should answer in a forum support thread if you need help with this.

okabekudo commented on 2018-02-15 17:26 (UTC)

This uses all my 8gb of RAM resulting in a systemfreeze. Is this normal?

WorMzy commented on 2018-02-13 18:42 (UTC)

@ray731: If you're happy with untracked software floating around your system, sure. The advantage of an AUR package is that, once built, you can install/remove the package with pacman. If that isn't of interest to you, then by all means use upstream's tarballs.

ray731 commented on 2018-02-13 14:28 (UTC) (edited on 2018-02-13 14:29 (UTC) by ray731)

@WorMzy: yes, but palemoon-bin should be also installed. While the tarball should be just extracted to run palemoon. Isn't it simpler?

WorMzy commented on 2018-02-13 11:54 (UTC)

@ray731: yes, see the palemoon-bin package.

ray731 commented on 2018-02-13 11:52 (UTC)

As indicated on , you can also download Pale Moon for Linux as a bzipped tarball that can be extracted and run from any location on your system.

WorMzy commented on 2017-12-05 14:43 (UTC) (edited on 2017-12-05 14:47 (UTC) by WorMzy)

@jerome2016: I've had another look at the strace output, and I noticed this line: openat(AT_FDCWD, "/usr/lib/", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

I don't get that message when I run strace palemoon, so I have to assume something on your system is trying to pull it in. The icu package was updated in mid-November, so is your system completely up-to-date? (including any AUR packages which may need a rebuild due to the icu version bump).

Use lddd or findbrokenpkgs to identify any packages that might need a rebuild. Note that you will get false positives with either tool, so I prefer to run the former, then run

for pkg in $(pacman -Qqm); do
grep $pkg /tmp/lddd-script.*/possible-rebuilds.txt

to get a list of foreign packages which may need rebuilding.

WorMzy commented on 2017-12-05 13:33 (UTC) (edited on 2017-12-05 13:34 (UTC) by WorMzy)

@jerome2016: I haven't been able to reproduce this so far, but assuming you are the same user who created this topic, I recommend rebuilding with gcc5, instead of using gcc6. Aside from the glibc/C99_MATH bug below, I have never had any problems with the former.

jerome2016 commented on 2017-12-04 04:15 (UTC)

palemoon <br> [1] 20431 segmentation fault (core dumped) palemoon

Dialog Box for ask if need to check if palemoon is default web browser open, then GUI main window's open... then crash, segmentation fault.

from archlinux OS build on device intel i7 8 cores updated this day and rebooted after update (new linux kernel version: 4.14.3-1-ARCH Xorg UI server with xfce-4 desktop.

strace palemoon show that: --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xc8} ---

WorMzy commented on 2017-11-29 00:29 (UTC)

Unfortunately I am away on holiday until the 4th of December, so I am unable to update this package until then. It should be a simple pkgver bump though, so it's easy enough to update the PKGBUILD manually (for those who can't wait).

WorMzy commented on 2017-11-24 22:59 (UTC)

A notify daemon is not needed to build the package. If your build is really terminating because it can't create a notification file a bug report upstream and/or build in a clean chroot.

sph commented on 2017-11-18 09:56 (UTC) (edited on 2017-11-18 10:11 (UTC) by sph)

unable to build without a service providing org.frreedesktop.Notifications (eg. xfce4-notifyd), please add it as a dep 19:03.76 Notification center failed: The name org.freedesktop.Notifications was not provided by any .service files EDIT: and it has to be started, even. meh.

sekret commented on 2017-11-15 05:01 (UTC)

Ok, all is good now. @WorMzy it's as you described. Problem solved :-)

sekret commented on 2017-11-13 05:48 (UTC) (edited on 2017-11-13 05:49 (UTC) by sekret)

Interesting! I again tried to build palemoon with my old build of gcc5 from the AUR. Now it stopped at another point. 41:38.95 make[5]: *** [/build/palemoon/src/Pale-Moon/config/ Unified_cpp_dom_canvas0.o] Error 1 41:38.95 make[4]: *** [/build/palemoon/src/Pale-Moon/config/ dom/canvas/target] Error 2 41:38.95 make[4]: *** Waiting for unfinished jobs.... 41:38.95 Unified_cpp_dom_media3.o 41:40.16 In file included from /build/palemoon/src/pmbuild/dom/media/Unified_cpp_dom_media1.cpp:20:0: 41:40.16 /build/palemoon/src/Pale-Moon/dom/media/MP3Demuxer.cpp: At global scope: 41:40.16 Warning: -Wunused-variable in /build/palemoon/src/Pale-Moon/dom/media/MP3Demuxer.cpp: ‘mozilla::mp3::vbr_header::TYPE_STR’ defined but not used 41:40.16 /build/palemoon/src/Pale-Moon/dom/media/MP3Demuxer.cpp:893:20: warning: ‘mozilla::mp3::vbr_header::TYPE_STR’ defined but not used [-Wunused-variable] 41:40.16 static const char* TYPE_STR[3] = {"NONE", "XING", "VBRI"}; 41:40.16 ^ 41:58.92 libdom_media.a.desc 41:58.99 make[3]: *** [/build/palemoon/src/Pale-Moon/config/ compile] Error 2 41:58.99 make[2]: *** [/build/palemoon/src/Pale-Moon/config/ default] Error 2 41:58.99 make[1]: *** [/build/palemoon/src/Pale-Moon/ realbuild] Error 2 41:58.99 make: *** [ build] Error 2 41:59.02 114 compiler warnings present. 41:59.33 Notification center failed: Install the python dbus module to get a notification when the build finishes. ==> ERROR: A failure occurred in build(). Aborting... How can this be so random?!?! Ok I'll definitely rebuild gcc5 now while the machine is alone. Oh and: $ grep _GLIBCXX_USE_C99_MATH /usr/lib/gcc/x86_64-pc-linux-gnu/5.5.0/include/c++/x86_64-pc-linux-gnu/bits/c++config.h /* #undef _GLIBCXX_USE_C99_MATH */ #define _GLIBCXX_USE_C99_MATH_TR1 1

WorMzy commented on 2017-11-12 23:07 (UTC)

Thanks, runical. @sekret, that probably was the culprit (or at least part of the problem). Ignore the _TR1 varient, it is the '#undef _GLIBCXX_USE_C99_MATH' that causes the __builtin problem, and is possibly the cause of your build failure too. If the gcc5 rebuild had completed, you would (hopefully) have found that c++config.h now had '#define _GLIBCXX_USE_C99_MATH 1' instead, and the palemoon package builds again.

runical commented on 2017-11-12 21:25 (UTC)

I built GCC5 last Thursday (November 9th). The exact time being 12:35:53 CET. My processor: Intel(R) Core(TM) i5-4200M The build flags in my chroot are as standard as they come: CPPFLAGS="-D_FORTIFY_SOURCE=2" CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt" CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" _GLIBCXX_USE_C99_MATH is also defined. I don't know if the info was still needed, but here you go.

sekret commented on 2017-11-12 20:53 (UTC)

I had to abort the build, my system got unstable... Old machine ;-) But here's an info from the "old" gcc5, which causes palemoon to not build $ grep _GLIBCXX_USE_C99_MATH /usr/lib/gcc/x86_64-pc-linux-gnu/5.5.0/include/c++/x86_64-pc-linux-gnu/bits/c++config.h /* #undef _GLIBCXX_USE_C99_MATH */ #define _GLIBCXX_USE_C99_MATH_TR1 1 So this wasn't the culprit on my machine.

sekret commented on 2017-11-12 12:44 (UTC)

My old build of gcc5 was finished 31.10.2017 18:00. The rebuild runs right now, takes quite a while, because I have an old CPU $ grep "model name" /proc/cpuinfo model name : Intel(R) Core(TM)2 Duo CPU T5870 @ 2.00GHz model name : Intel(R) Core(TM)2 Duo CPU T5870 @ 2.00GHz

WorMzy commented on 2017-11-12 12:38 (UTC)

Recompiling gcc5 worked for me. \o/ I am now thoroughly confused. There was a rebuild of glibc on the 29th of October, which may have pulled in this commit [1], which sounds like it would have fixed the problem me and wolf were encountering. It seems that there are three different builds of gcc5, all slightly different depending on the environment they were built in. Wolf and me had one variant, which led to the __builtin build failures, sekret had one which led to the Unified_cpp_dom_canvas0.o build failure, and runical and fabertawe had one which led to a successful build. I strongly suspect glibc was responsible for the group one failures, I'm not sure about group two, and I'm going to assume group three builds were done after groups one and two. Comparing dates on our respective gcc5 packages may confirm this, but so long as the problem is resolved, I'm not going to expend too much effort investigating it. [1];a=commit;h=386e1c26ac473d6863133ab9cbe3bbda16c15816

fabertawe commented on 2017-11-12 11:29 (UTC)

I don't build in a clean chroot! CPU is an Intel i7 4790k, 'makepkg.conf' reads... CPPFLAGS="-D_FORTIFY_SOURCE=2" CFLAGS="-march=native -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt" CXXFLAGS="${CFLAGS}" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" 'c++config.h' (untouched by me) shows... #define _GLIBCXX_USE_C99_MATH 1

sekret commented on 2017-11-12 11:07 (UTC)

Me too, I recently switched my HD into another laptop, maybe it makes a difference if I build gcc with this CPU? I don't use custom build flags, so I can't imagine that's the reason, but well, I'll try and report back.

WorMzy commented on 2017-11-12 11:04 (UTC)

Okay, that's interesting. My clean chroot build also fails with gcc5.5, with the same errors as Wolf. It'd be interesting to see if we could identify what causes this build failure. Runical amd fabertawe, I'm guessing you don't modify c++config.h, so the bug report I suspected is probably a red herring (although that edit results in a successful build for me). Just as a sanity check, could you all check your gcc5 package's /usr/lib/gcc/x86_64-pc-linux-gnu/5.5.0/include/c++/x86_64-pc-linux-gnu/bits/c++config.h and see whether _GLIBCXX_USE_C99_MATH is defined (check around line #1346). Also, if you don't mind sharing what sort of CPU you use, and whether you use any custom C{,XX,PP}FLAGS, that might help. Either leave a comment here, ping me on irc (WorMzy@freenode), or drop me an email. Any help would be appreciated. @sekret: on closer inspection, your build failure is different to the ones me and wolf are (were?) experiencing. It's interesting to see three different outcomes from clean-chroot builds! I'm going to try rebuilding gcc5.5 again and see if palemoon builds with the new package.

sekret commented on 2017-11-12 09:17 (UTC)

I build in a clean chroot too and palemoon failed to build with gcc5 from the AUR.

runical commented on 2017-11-12 09:06 (UTC)

@fabertawe: I think this is his specific issue. GCC5 built just fine for me and the same goes for palemoon. I do build in a clean chroot though, so that removes a lot of the issues anyway.

fabertawe commented on 2017-11-11 13:19 (UTC)

I'm confused... Pale Moon builds for me with gcc5 5.5.0-2 from the AUR. Is it failing for everyone else or is wolf's a specific issue?

wolf commented on 2017-11-11 11:37 (UTC)

Can confirm 5.4 from works just fine, maybe you could add info about this (5.5 not working) into that pinned comment :)

WorMzy commented on 2017-11-09 22:22 (UTC)

Yes, unfortunately I haven't had time to do anything about this yet. If you want to help out, please check other packages which use gcc5 to build and see if they fail with the same errors when you use v5.5.0. Then see if they build successfully when you edit /usr/lib/gcc/x86_64-pc-linux-gnu/5.5.0/include/c++/x86_64-pc-linux-gnu/bits/c++config.h, changing line #1346 to read: #define _GLIBCXX_USE_C99_MATH 1 Alternatively, if you can find a way to override c++config.h on a case-by-case basis, that doesn't involve editing source code (upstream is getting arsey about from-source builds as it is [1]), that would be a big help. [1]

sekret commented on 2017-11-09 20:37 (UTC)

Trying to build palemoon 27.6.0-1 with gcc5 5.5.0-2 from the AUR still fails. [...] 39:00.72 make[5]: *** [/build/palemoon/src/Pale-Moon/config/ Unified_cpp_dom_canvas0.o] Error 1 39:00.72 make[4]: *** [/build/palemoon/src/Pale-Moon/config/ dom/canvas/target] Error 2 39:00.72 make[4]: *** Waiting for unfinished jobs.... 39:00.72 Unified_cpp_dom_media3.o 39:11.72 In file included from /build/palemoon/src/pmbuild/dom/media/Unified_cpp_dom_media1.cpp:20:0: 39:11.72 /build/palemoon/src/Pale-Moon/dom/media/MP3Demuxer.cpp: At global scope: 39:11.72 Warning: -Wunused-variable in /build/palemoon/src/Pale-Moon/dom/media/MP3Demuxer.cpp: ‘mozilla::mp3::vbr_header::TYPE_STR’ defined but not used 39:11.72 /build/palemoon/src/Pale-Moon/dom/media/MP3Demuxer.cpp:893:20: warning: ‘mozilla::mp3::vbr_header::TYPE_STR’ defined but not used [-Wunused-variable] 39:11.72 static const char* TYPE_STR[3] = {"NONE", "XING", "VBRI"}; 39:11.72 ^ 39:32.51 UnifiedBindings7.o 39:36.68 UnifiedBindings8.o 39:37.43 libdom_media.a.desc 39:37.55 UnifiedBindings9.o 40:29.59 StructuredClone.o 40:51.58 Unified_cpp_dom_bindings0.o 41:15.21 libdom_bindings.a.desc 41:15.26 make[3]: *** [/build/palemoon/src/Pale-Moon/config/ compile] Error 2 41:15.27 make[2]: *** [/build/palemoon/src/Pale-Moon/config/ default] Error 2 41:15.27 make[1]: *** [/build/palemoon/src/Pale-Moon/ realbuild] Error 2 41:15.27 make: *** [ build] Error 2 41:15.31 114 compiler warnings present. 41:15.82 Notification center failed: Install the python dbus module to get a notification when the build finishes. ==> ERROR: A failure occurred in build(). Aborting... I'll try with the old gcc5...

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

I think this is related to this bug: which is actually a bug in glibc 2.26 (gcc 5.4.0 has _GLIBCXX_USE_C99_MATH defined in c++config.h, so doesn't trigger it) Should be fixed in glibc 2.27, but since that's many months away (Feb 2018), I'll see if I can find time to find a workaround for the interim. This workaround may be prodding the gcc5 maintainer and seeing if they'd readd the _GLIBCXX_USE_C99_MATH definition to c++config.h until glibc 2.27 lands. \o/ Temporary workaround: use the old gcc 5.4.0 packages from the ALA

wolf commented on 2017-10-29 00:36 (UTC)

Cannot build with gcc5 from AUR, any help? 12:35.30 In file included from /build/palemoon/src/pmbuild/dom/canvas/Unified_cpp_dom_canvas0.cpp:11:0: 12:35.30 Warning: -Wunknown-pragmas in /build/palemoon/src/Pale-Moon/dom/canvas/CanvasRenderingContext2D.cpp: ignoring #pragma omp parallel 12:35.30 /build/palemoon/src/Pale-Moon/dom/canvas/CanvasRenderingContext2D.cpp:1635:0: warning: ignoring #pragma omp parallel [-Wunknown-pragmas] 12:35.30 #pragma omp parallel for 12:35.30 ^ 12:36.46 libembedding_components_printingui_ipc.a.desc 12:36.55 nsAppRunner.o 12:36.58 nsEmbedFunctions.o 12:38.41 UnifiedProtocols9.o 12:42.29 /build/palemoon/src/Pale-Moon/dom/canvas/CanvasRenderingContext2D.cpp: In function ‘bool mozilla::dom::ValidateRect(double&, double&, double&, double&)’: 12:42.29 /build/palemoon/src/Pale-Moon/dom/canvas/CanvasRenderingContext2D.cpp:2420:8: error: ‘__builtin_isfinite’ is not a member of ‘std’ 12:42.29 if (!std::isfinite((float)aX) | !std::isfinite((float)aY) | 12:42.29 ^

WorMzy commented on 2017-10-25 08:04 (UTC) (edited on 2017-11-12 12:41 (UTC) by WorMzy)

Alas, gcc5 has now been dropped from the official repos. However, you can still get the old package here: Note that that package is out of date, and the final version of gcc5 (5.5) is available on the AUR here: it is unlikely that you will need to build this package more than once, since it's no longer receiving updates. Also worth noting is that palemoon upstream /still/ reccomend the long defunct gcc49 over any modern compiler, if you want to use that you will need to modify the mozconfig file's CC and CXX flags as well as the PKGBUILD's makedepends array and md5sums.

WorMzy commented on 2017-10-03 08:24 (UTC)

Builds fine here. All I can recommend is that you ditch yaourt and build in a clean chroot.

simona commented on 2017-10-02 14:13 (UTC)

/tmp/yaourt-tmp-simona/aur-palemoon/src/pmbuild/dist/bin/ riferimento non definito a "icudt58_dat" 8:04.22 collect2: error: ld returned 1 exit status

WorMzy commented on 2017-09-27 15:00 (UTC)

m4 is part of base-devel, which you should have installed if you want to build AUR packages:

sekret commented on 2017-09-27 14:41 (UTC)

@fft, are you sure? I always build in a clean chroot and the package builds fine here, so there shouldn't be a missing dependency. Could you post the error?

fft commented on 2017-09-27 14:38 (UTC)

WorMzy, thank you for packaging. It seems, that need to add m4 to makedepends.

ondoho commented on 2017-09-20 17:42 (UTC)

nope, it didn't fix the issue at all. tried running palemoon from the terminal but there was no ouput at all. can anyone at least confirm this? btw, sorry forgot to mention, kernel is 4.9.50-1-lts x86_64, gpu is Intel HD Graphics 530

ondoho commented on 2017-09-18 06:15 (UTC)

after a system update, palemoon started glitching - when i opened another window on top of palemoon, sometimes even only when i switched desktops, palemoon's window would become blank, and palemoon unresponsive until i kill it. something to do with gpu accel no doubt. this went on for a couple of weeks and across at least one kernel upgrade - until i simply re-installed (recompiled) palemoon, now it's fine again. has this happened before? is there any way to deal with that through package management?

WorMzy commented on 2017-08-30 15:08 (UTC)

> enough memory/disk space seem to be available Your output suggests otherwise. You mention disk space, but it looks like you're building in /tmp which, on Arch, is a tmpfs by default. When building on tmpfs, you need to have enough free memory to handle the git repository, the checked out source code, the actual build process (including temporary files and compiler/linker processes), and the packaging. When the build fails, the compiler/linker processes get reaped and the memory they were using gets freed, so checking the free space of /tmp or the memory usage of the system after the build fails is not actually indicitive of the situation during the build. How big is your /tmp? Anything smaller than 5GB is unlikely to result in a successful build.

kzoli429 commented on 2017-08-30 14:27 (UTC)

Although enough memory/disk space seem to be available, building failed with: " ... {standard input}: Assembler messages: 2:14.21 {standard input}: Fatal error: can't close Unified_cpp_js_src4.o: No space left on device 2:14.23 In the directory /tmp/makepkg/palemoon/src/pmbuild/js/src 2:14.23 The following command failed to execute properly: 2:14.23 g++-5 -o Unified_cpp_js_src4.o -c -I../../dist/system_wrappers -include /tmp/makepkg/palemoon/src/Pale-Moon/config/gcc_hidden.h -DFFI_BUILDING -DEXPORT_JS_API -DJS_HAS_CTYPES -DDLL_PREFIX="lib" -DDLL_SUFFIX=".so" -DMOZ_GLUE_IN_PROGRAM -DAB_CD= -DNO_NSPR_10_SUPPORT -I/tmp/makepkg/palemoon/src/Pale-Moon/js/src -I. -Ictypes/libffi/include -I/tmp/makepkg/palemoon/src/Pale-Moon/intl/icu/source/common -I/tmp/makepkg/palemoon/src/Pale-Moon/intl/icu/source/i18n -I../../dist/include -I/tmp/makepkg/palemoon/src/pmbuild/dist/include/nspr -fPIC -D_FORTIFY_SOURCE=2 -O2 -DMOZILLA_CLIENT -include ../../js/src/js-confdefs.h -MD -MP -MF .deps/Unified_cpp_js_src4.o.pp -D_FORTIFY_SOURCE=2 -O2 -Wall -Wsign-compare -Wtype-limits -Wno-invalid-offsetof -Wcast-align -march=native -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -g -O2 -msse2 -mfpmath=sse -fomit-frame-pointer /tmp/makepkg/palemoon/src/pmbuild/js/src/Unified_cpp_js_src4.cpp 2:14.23 make[5]: *** [/tmp/makepkg/palemoon/src/Pale-Moon/config/ Unified_cpp_js_src4.o] Error 1 2:14.24 make[4]: *** [/tmp/makepkg/palemoon/src/Pale-Moon/config/ js/src/target] Error 2 2:14.24 make[3]: *** [/tmp/makepkg/palemoon/src/Pale-Moon/config/ compile] Error 2 2:14.24 make[2]: *** [/tmp/makepkg/palemoon/src/Pale-Moon/config/ default] Error 2 2:14.24 make[1]: *** [/tmp/makepkg/palemoon/src/Pale-Moon/ realbuild] Error 2 2:14.24 make: *** [ build] Error 2 2:14.27 262 compiler warnings present. 2:15.36 Failed to parse ccache stats output: cache hit rate 0.00 % ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build palemoon. ==> Restart building palemoon ? [y/N] "

WorMzy commented on 2017-08-23 20:09 (UTC)

Thanks for the heads up. :) The gcc5 drop shouldn't be too much of a problem. The current gcc5 package hasn't been touched in over a year, so there's probably not much risk in users installing it from the ALA once it disappears from the repos. Unfortunately I think it's unlikely that upstream will support/recommend a modern gcc any time soon. It doesn't look like that fix for 2.26 causes any problems for 2.25, so I'll push out a pkgrel bump adding it and the job limit change shortly.

AndyRTR commented on 2017-08-23 18:25 (UTC)

When building against new toolchain in testing the following fix is required: # fix build with glibc 2.26 sed -i "s:xlocale:locale:" Pale-Moon/intl/icu/source/i18n/digitlst.cpp And please drop the make job limitation in mozconfig. The build can finish much faster without that limit on a recent cpu. And be prepared: !

WorMzy commented on 2017-07-14 10:00 (UTC)

Looks like the new default CFLAGS (as of pacman 5.0.2-2) don't work with gcc5. I'm not sure if this should be reported as a bug (to Arch, not Palemoon), or if PKGBUILDs that still use gcc5 should work around the problem. Unfortunately I'm stuck in a datacenter all day today so I can't research/test/get a new PKGBUILD out for a few hours but you should be able to fix the problem in the time being by exporting the old CFLAGS (and probably CXXFLAGS and LDFLAGS for good measure) at the top of the build function in the PKGBUILD. e.g. build() { export CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong" export CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong" export LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro" ...

anton-tsyganenko commented on 2017-07-14 08:47 (UTC)

I'm getting an error when building it: 0:01.54 configure:3304: gcc-5 -o conftest -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -D_FORTIFY_SOURCE=2 -O2 -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now conftest.c 1>&5 0:01.54 gcc-5: error: unrecognized command line option '-fno-plt' 0:01.54 configure: failed program was: 0:01.54 0:01.54 #line 3299 "configure" 0:01.55 #include "confdefs.h" 0:01.55 0:01.55 main(){return(0);} 0:01.55 configure: error: installation or configuration problem: C compiler cannot create executables. 0:01.55 *** Fix above errors and then restart with\ 0:01.55 "/usr/bin/make -f build" 0:01.55 make[2]: *** [/tmp/yaourt-tmp-anton/aur-palemoon/src/Pale-Moon/ configure] Error 1 0:01.55 make[1]: *** [/tmp/yaourt-tmp-anton/aur-palemoon/src/Pale-Moon/ /tmp/yaourt-tmp-anton/aur-palemoon/src/pmbuild/Makefile] Error 2 0:01.55 make: *** [ build] Error 2 0:01.55 0 compiler warnings present. ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build palemoon.

WorMzy commented on 2017-06-24 13:31 (UTC)

No, I think you're right and I misinterpreted the announcement. The caveat at the bottom of the original announcement seems to still apply: "this currently has no impact on the Pale Moon browser. It will only become relevant if/when we move our Pale Moon application from our current Mozilla+Goanna 3 platform across to UXP in the future." Still, if you are still willing to be a co-maintainer, I'm happy to add you as one.

wolf commented on 2017-06-24 12:46 (UTC)

I'm not sure where you got the "in the near future" from it (but maybe me reading comprehension sucks), but if nobody else volunteers, I might as well do it since I have no plans to stop using palemoon at the moment. So I would need some AUR package anyway.

WorMzy commented on 2017-06-21 18:33 (UTC)

PSA: Looks like palemoon will be switching to gtk3 in the near future[1]. I have no intention of continuing to maintain this package once that happens. As such, if there is anyone who wants to step up as a co-maintainer, with the intention of taking over as full maintainer when gtk3 becomes default, please let me know in the comments or drop me an email. [1]

bruno commented on 2017-06-20 14:40 (UTC)

sorry, effectively, i'm running out of space on /tmp. it works fine ! sorry and thanks for your quick reply

WorMzy commented on 2017-06-20 11:26 (UTC)

Are you running out of space? Where are you attempting to build?

bruno commented on 2017-06-20 08:50 (UTC)

Hello, I have multples errors : error: unable to write file xulrunner/tools/redit/redit.cpp error: unable to write file ... etc ... ==> ERREUR : Échec lors de la création d’une copie de travail du dépot Pale-Moon git Abandon... ==> ERREUR : Makepkg n'a pas pu construire palemoon. thanks

WorMzy commented on 2017-04-19 10:20 (UTC)

Fair enough. I still wasn't able to reproduce the build failure with the extra packages. It's possible that you have a different version of java than the one I tried building with (openjdk 7), but java doesn't appear to be used during the build process anyway. The only thing that sticks out in a comparison of my logs and yours, is that I get a lot more warnings about there being no preprocessor directives. Have you modified your CPPFLAGS at all?

commented on 2017-04-19 08:03 (UTC)

Yes I know :) I've got a VM for playing, it was easier to run it there :) and it did build succesfully. I'm kinda confused. Will look in to my system a bit later.

WorMzy commented on 2017-04-18 19:43 (UTC)

In case you're not aware -- there's no need to create a VM for this, see

commented on 2017-04-18 18:48 (UTC)

I'm just trying in a clean archlinux VM installation. Takes a lot of time, I'll post the results. I had a success at some point with palemoon-git ( after more than couple failed builds ), but its wont build anymore again.

WorMzy commented on 2017-04-18 17:14 (UTC)

Cheers. Looking at your log, the only differences I can see are that you have doxygen, libxss, gconf, java and wget installed. Did you try building in a clean chroot as well, did that succeed? I'll see if I can reproduce the build failure and narrow down the culprit.

commented on 2017-04-18 16:40 (UTC)

WorMzy commented on 2017-04-06 17:36 (UTC) (edited on 2017-04-06 17:36 (UTC) by WorMzy)

Builds fine here in a clean chroot. Please post the full build log. (To a pastebin service, link here)

Larivact commented on 2017-04-05 18:29 (UTC)

Build fails because "Clobber required for gamepad disable (WebIDL change)".

sekret commented on 2017-03-30 09:17 (UTC)

FYI, I built palemoon 27.2.1-1 with gcc 6.3.1-2 to see how the browser behaves. I get very frequent crashes without any real reason. I block any content other than 1st party css and images by default, so no bad javascript or flash issues cause those crashes. This is not a bug report or anything, so no traces are attached. It's just a heads up for you guys: Don't build with gcc6, stick to gcc5 or if you want gcc4.

WorMzy commented on 2017-03-14 19:25 (UTC)

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.

commented on 2017-03-14 18:27 (UTC)

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 0:51.04 NSModules are not ordered appropriately 0:51.04 make[5]: *** [/tmp/yaourt-tmp-gofree/aur-palemoon/src/Pale-Moon/config/] Error 1 0:51.04 make[5]: *** Deleting file '' 0:51.14 make[4]: *** [/tmp/yaourt-tmp-gofree/aur-palemoon/src/Pale-Moon/config/ toolkit/library/target] Error 2 0:51.14 make[3]: *** [/tmp/yaourt-tmp-gofree/aur-palemoon/src/Pale-Moon/config/ compile] Error 2 0:51.14 make[2]: *** [/tmp/yaourt-tmp-gofree/aur-palemoon/src/Pale-Moon/config/ default] Error 2 0:51.15 make[1]: *** [/tmp/yaourt-tmp-gofree/aur-palemoon/src/Pale-Moon/ realbuild] Error 2 0:51.15 make: *** [ build] Error 2 0:51.18 243 compiler warnings present.

WorMzy commented on 2017-03-08 19:43 (UTC)

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]

mattatobin commented on 2017-03-08 17:23 (UTC)

Because it produces unstable builds?!

WorMzy commented on 2017-03-03 16:21 (UTC)

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 (UTC)

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 (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 Gstreamer wil be remove:

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:

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

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., 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/"?

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

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

prettyvanilla commented on 2016-08-07 21:31 (UTC)

It's not quite the same point in this case, as extra/firefox also still compiles against system libraries. (Besides, I don't believe the Arch Linux ideals of simplicity include *not* unbundling libraries if upstream's build system explicitly provides for building against system libs.) Anyway, it's not really a problem for me to just leave the respective options in on my local system if you decide to go with Matt's/Pale Moon's request.

WorMzy commented on 2016-08-07 15:51 (UTC)

It's the same point as using Arch's extra/firefox instead of downloading mozilla's precompiled firefox binaries from Of course, if you don't want to compile your own due to the perceived lack of benefit, you can always use palemoon-bin.

Arvedui commented on 2016-08-07 10:44 (UTC)

Where is the point in this package if it just replicates the binary distribution from upstream?

WorMzy commented on 2016-08-06 21:30 (UTC)

Hi Matt, that's not a problem. One of the main Arch Linux ideals is shipping software as close to what upstream recommends, so the more explicit recommendations on the dev wiki, the better! I was going to remove the system lib lines from my mozconfig for the next point release of PM, but I'll push it out shortly instead since you recommend against using them.

mattatobin commented on 2016-08-06 16:36 (UTC)

@wolf At this point we can say the current codebase SHOULD be good with GCC5 but GCC6 is simply not supported and won't be. Work on GCC6 support has shifted to the new milestone that will become Pale Moon 27. @WorMzy After some consideration, also not related to this GCC but general building.. We, Pale Moon, would prefer if you would go ahead and stop building with system libs period (beyond --with-phthreads). I want to start an initiative to standardize and sync package maintainers and our generic linux configuration. The intention is to keep packages maintained by .. package maintainers as close to our official generic linux package as possible to avoid any potential issues from different configuration and compiling quirks. Configuration and Compiling differences SHOULD be limited in scope to those absolutely required for a successful and operational build for the target platform and system but otherwise follow our official setup as closely as possible. Please see the (now being revised) Developer Wiki page for Building Pale Moon for Linux here: Mainly, the .mozconfig shouldn't need to diverge from our official one much if at all.

wolf commented on 2016-07-31 20:51 (UTC)

Nope, couldn't make it work with gcc6, so I returned to gcc5 for the moment. Ok, got a workaround, apparently it doesn't like something in my .bashrc. Sry for wasting your time, issue was on my end :)

WorMzy commented on 2016-07-31 20:26 (UTC)

I can't reproduce that here. Are you still building with gcc6? Any other mozconfig/PKGBUILD changes? Have you made any changes to your /etc/makepkg.conf? If there's nothing obvious causing this on your end, try building in a clean chroot [1] (I actually recommend doing this anyway, for all AUR/ABS packages). [1]

wolf commented on 2016-07-31 18:23 (UTC)

Cannot build, getting following error: ==> Making package: palemoon 26.3.3-3 (Sun Jul 31 19:49:06 CEST 2016) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Updating Pale-Moon git repo... Fetching origin -> Found ==> Validating source files with md5sums... Pale-Moon ... Skipped ... Passed ==> Extracting sources... -> Creating working copy of Pale-Moon git repo... Cloning into 'Pale-Moon'... done. Checking out files: 100% (80809/80809), done. Switched to a new branch 'makepkg' ==> Starting prepare()... ==> Starting build()... Creating global state directory from environment variable: /home/wolfie/archrepo/palemoon/src/mozbuild Please re-run mach. Next => 0:00.40 /usr/bin/make -f -s 0:00.59 *** missing separator. Stop. 0:00.63 0 compiler warnings present. ==> ERROR: A failure occurred in build(). Aborting...

0strodamus commented on 2016-07-29 18:07 (UTC)

Thanks for the palemoon info and for teaching me something I did not know about pacman's local database!

WorMzy commented on 2016-07-29 10:54 (UTC)

You're right about the deps, I've removed both nss and nspr from the array. I've not bumped the pkgrel though, as the compiled package is still the same and most people probably aren't too bothered by the extra 7MB of deps. Rebuild the package if you want to strip out those deps, or if you know what you're doing, modify pacman's database manually (/var/lib/pacman/local/palemoon-26.3.3-3/desc). The config options in question look to be disabled by default, but explicitly disabling them shouldn't cause any problems.

0strodamus commented on 2016-07-29 02:03 (UTC)

First off, thanks for uploading this package and keeping it updated. Should nspr be removed from the depends array with the --with-system-nspr option removed? I also see --enable-mobile-optimize, --enable-b2g-bt, --enable-b2g-camera, and --enable-b2g-ril in so I'll be leaving those disabled here just to be sure.

WorMzy commented on 2016-07-28 21:57 (UTC)

Thanks for the pointers, Matt, I'll implement the explicit changes you described shortly.

mattatobin commented on 2016-07-28 21:18 (UTC) (edited on 2016-07-28 21:26 (UTC) by mattatobin)

Greetings, My name is Matt A. Tobin and I am the Administrator and Coordinator of Secondary Services at the Pale Moon project.. Some recent forum posts have prompted me to reach out to the package maintainer for Pale Moon on Arch.. Your .mozconfig needs a little work to be brought up to how we build Pale Moon in general. Please change the following configure flags: ac_add_options --enable-safe-browsing to ac_add_options --disable-safe-browsing ac_add_options --disable-crashreporter no longer exists and can be removed ac_add_options --disable-metro no longer exists and can be removed ac_add_options --disable-maintenance-service no longer exists and can be removed ac_add_options --disable-windows-mobile-components hasn't existed for quite sometime and can be removed ac_add_options --disable-mobile-optimize hasn't existed for quite sometime and can be removed We require building the in-tree version of NSPR/NSS due to changes we have made to those modules and cannot ensure full compatibility with system versions from upstream. So please remove ac_add_options --with-system-nspr. In general we prefer in-tree libs vs system libs where possible for compatibility reasons. I also think the three b2g configure flags are disabled by default and can be removed. If the package maintainer has other questions or concerned he may contact us at our forum.

WorMzy commented on 2016-07-28 20:34 (UTC)

Thanks for pointing that out. It's something that was enabled in the mozconfig when I took over the package, and I've never had any reason to disable it. Shall be disabled shortly.

Wuzzy commented on 2016-07-28 20:03 (UTC)

I am using version 26.3.3-1 of this package. I noticed the “safebrowsing” feature is still in this package. You can check this by checking if browser.safebrowsing exists in about:config, or if in Preferences, Security tab there are 2 checkboxes for blocking websites. They should NOT be there. According to the Pale Moon developers, this feature should be gone but this feature is still in my version for some reason. Can you please investigate if there is something strange going on?

wolf commented on 2016-05-12 23:37 (UTC)

Yep, let's shift debate over there.

WorMzy commented on 2016-05-12 22:32 (UTC) (edited on 2016-05-12 22:32 (UTC) by WorMzy)

I've opened a thread on the Pale Moon forums with various logs. Feel free to take a look and participate in the thread, or make suggestions here or by email if you don't have a forum account. :) EDIT: Link:

wolf commented on 2016-05-12 04:24 (UTC) (edited on 2016-05-12 04:24 (UTC) by wolf)

To the best of my knowledge, `-flto=7` shouldn't have any success on any asserts.. Link time optimization shouldn't really affect if the program compiles or not. I can try it without the `-flto` just to make sure when I get from work, but I would be really surprised if it won't compile without it. Could you post the error you get during compilation here or to my email? Maybe I can help.

WorMzy commented on 2016-05-11 23:43 (UTC)

Thanks for the offer. I think you're on to something with the -flto flag you're using -- another PM user had similar success with LTO with gcc6: Unfortunately, I don't know what LTO is, and just adding -flto=7 to my *FLAGS didn't seem to make any difference on my system. I'm going to have to read up on LTO and see if I can't figure out why it seems to help in some cases. I'd quite like to drop the gcc5 dep asap.

wolf commented on 2016-05-11 20:52 (UTC) (edited on 2016-05-11 21:26 (UTC) by wolf)

Standard gcc from core/gcc: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl= --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 6.1.1 20160501 (GCC) PKGBUILD - only change was upaded md5sum of - only change was removing the `-5` suffix for CC and CXX makepkg.conf CFLAGS="-flto=7 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4" CXXFLAGS="-flto=7 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4" LDFLAGS="-flto=7 -Wl,-O1,--sort-common,--as-needed,-z,relro" MAKEFLAGS="-j7" [..] #-- Destination: specify a fixed directory where all packages will be placed PKGDEST=~/archrepo/packages #-- Source cache: specify a fixed directory where source files will be cached #SRCDEST=~/archrepo/sources #-- Source packages: specify a fixed directory where all src packages will be placed SRCPKGDEST=~/archrepo/srcpackages #-- Log files: specify a fixed directory where all log files will be placed #LOGDEST=/home/makepkglogs #-- Packager: name/email of the person or organization building packages PACKAGER="Wolf <>" #-- Specify a key to use for package signing GPGKEY="52C5A16E" Nothing else was changed afaik.

WorMzy commented on 2016-05-11 20:24 (UTC)

Interesting, I've not had any success with gcc6, on three different PCs. It aborts after 10 minutes or so complaining that MOZ_ASSERT needs to be declared. The gcc5 makedep is supposed to be a stopgap until I can figure out what's causing the build to fail with gcc6. Have you customized your makepkg.conf, PKGBUILD, or at all? (besides changing the CC and CXX declarations)

wolf commented on 2016-05-11 20:08 (UTC)

Why it needs gcc-5? I tried to compile it with current core/gcc (6.1.something) and it worked just fine.

WorMzy commented on 2016-04-09 10:38 (UTC)

Whoops. Thanks for pointing that out, djmattyg007. Fixed.

djmattyg007 commented on 2016-04-09 01:42 (UTC)

I flagged this package as out of date, but in actual fact it's just that the .SRCINFO file wasn't updated. This was very confusing.

WorMzy commented on 2016-04-06 14:54 (UTC)

Looks like valgrind is tripping the build up. As I understand it, valgrind is supposed to be disabled by default [1] unless explicitly enabled in mozconfig, but this doesn't appear to be the case. Build in a clean chroot [2] if you can, or try a build with 'ac_add_options --disable-valgrind' in, if you try the latter, and it works, please file a bug upstream. As an aside, I'd recommend not building palemoon in /tmp unless you have a really big /tmp (e.g. 15GB+) [1] [2]

Matalonder commented on 2016-04-06 12:23 (UTC)

Building palemoon 26.2.0-1 fails on two machines for me as of the time of this comment.

WorMzy commented on 2016-04-05 21:05 (UTC)

My bad, I forgot to commit the changes to Should be good to go now (although github looks to be down for maintenance here).

xF0E commented on 2016-04-05 20:53 (UTC)

==> Validating source files with md5sums... Pale-Moon ... Skipped ... FAILED

ilikenwf commented on 2016-03-05 22:37 (UTC)

It's really best to use the firejail, you just use the space in the path: noblacklist /home/asdf/.moonchild productions

WorMzy commented on 2016-02-15 12:40 (UTC)

I believe the firejail problem was resolved, but I've pinned the earlier comment on how to change the profile directory as it may be helpful for some people.

WorMzy commented on 2016-02-01 15:49 (UTC)

Mea culpa. I've "Downgraded" the PKGBUILD to 26.0.0. Those of you who still have 26.0.0 packages should probably downgrade unless you want to rebuild with the mozconfig+palemoon.desktop changes I made for 26.0.1.

agilbertson1977 commented on 2016-02-01 15:36 (UTC)

One of the developers of Pale Moon has asked me to drop a message here letting you know that there is a critical flaw in 26.0.1 and that this version should be withdrawn. 26.0.2 should be out in a few days. In the future, please wait for the official release announcement rather than relying on Github tags. If you have any questions, please stop by the Pale Moon forums or join us on IRC in #palemoon on Freenode.

ilikenwf commented on 2016-01-31 21:58 (UTC)

Very cool! I think the gtreamer flag is the most important, I got some advice on reddit that I've yet to deal with that suggests that many of the options I used were actually redundant:

WorMzy commented on 2016-01-31 18:50 (UTC)

Thanks, ilikenwf. I've made some changes. I've left jemalloc disabled, as it still seems to be recommended. I was hoping to have more time to test out the Cairo change, so I've not implemented that yet.

ilikenwf commented on 2016-01-30 03:30 (UTC) (edited on 2016-01-30 04:18 (UTC) by ilikenwf)

1. The jemalloc bug is fixed so you can enable jemalloc: 2. Below is my commented, working mozconfig. Your milage may vary, but it is an amalgamation of this build's default, the firefox default, and some other settings that are stragglers from my days of building other Mozillan applications. Feel free to take the good bits and add to this package (basically everything except for changing the home directory, and number of build threads?). 3. I highly suggest enabling the system libs [edit: even cairo - video seems ok to me, after testing - or at least, gets as frame-skippy with it as without it] My mozconfig :

ilikenwf commented on 2016-01-30 02:46 (UTC)

Re: firejail - "Just put the path in verbatim with the spaces and no type of quoting. The path parsing is not standard unix shell. This fooled me too until I accidentally tried without any quoting. Perhaps the profile man page needs a mention?"

WorMzy commented on 2016-01-29 21:13 (UTC)

Thanks, I'll update that at the next update. You might want to try and get it merged into the PaleMoon source tree though.

American_Jesus commented on 2016-01-29 18:15 (UTC)

consider updating the .desktop file more complete with quicklists

ilikenwf commented on 2016-01-29 18:11 (UTC)

That makes sense. I did add an issue just now: I also have some other suggestions, such as adding options to use system libs where possible. So far the only ones that seem to break are setting the default toolkit as cairo3-gtk, and using system nss. Once I have a build I'm happy with I'll at least pastebin the relevant parts of my mozconfig so others can use it if they so desire.

WorMzy commented on 2016-01-29 14:08 (UTC)

I won't make that change, because it would break compatibility with palemoon-bin and people would need to rename their existing profile directories. I'll consider pinning your comment once the next version of the aurweb goes live though, so people are aware of that option. The best thing to do would be to fix firejail. Spaces are a perfectly legal character in linux filenames, so not supporting paths with spaces in them is a bug imo. @acl, sorry, I thought I replied to your comment, but it doesn't look like I ever clicked submit. I had a bash at putting together a fossamail PKGBUILD, but I could never get it to build. From what I could work out, you needed to clone the Fossamail git tree, the PaleMoon git tree, the comm-central git project, and the mozilla-central git project, then organise them in a specific way (otherwise it would clone the entire projects during the build process).. the whole think was a mess, and I gave up on it (I don't even use fossamail). If you want to have a go at it yourself, here's what I made so far (I think I used thunderbird as a template):

acl commented on 2015-10-29 19:43 (UTC)

@WorMzy, thanks for putting this package together, could you look into making a similar one for FossaMail? (Palemoon's counterpart to Thunderbird) I tried myself... but didn't manage to get a usable build. Should be a similar PKGBUILD, and as far as I gather it uses a build comand like this, with Palemoon compiled as a dependency on the mozilla subfolder: make -f build No problem if you can't, just thought I'd ask. Thanks, anyway :)

WorMzy commented on 2015-09-01 09:47 (UTC)

Thanks for sharing your research. I did have time to do some of my own, and stripped down the makedepends as much as I could. I've added the gstreamer plugins to the optdepends array, as you have suggested. As for pkg-config, that was unnecessary as it is a member of base-devel, a pre-requisite for building anything from the AUR, so I've removed it.

Axiomatic commented on 2015-08-31 18:03 (UTC)

The only gstreamer make depend should be gstreamer0.10-base. (Or possibly, just gst-plugins-base-libs Arch splits packages, and I cannot seem to follow what each provides. Sorry.) All of these are optional: gstreamer0.10-base-plugins , gstreamer0.10-bad-plugins , gstreamer0.10-good-plugins , gstreamer0.10-ugly-plugins What can be dropped is, iw (not sure where Pale Moon would ever use this in the first place), libnotify (I think this is optional, an related to a --enable something), libidl2 (Pale Moon does not use this as system dependent, pretty sure it is in the tree somewhere), and curl (I am not 100% sure this is not needed, but I have built Firefox without curl installed, so I assume the same with Pale Moon.) I am not sure about pkg-config, I do know it is used when searching for system libraries. (I will try building Pale Moon on a minimal Arch Linux install without pkg-config to see it it is needed. (And to fact check the other stuff I said.)) Technically speaking you could reduce the dependencies, to alsa-lib, GTK2, zip, and unzip, but you would loose support to WebM (which pulls yasm), and a lot of other web related /features/.

WorMzy commented on 2015-07-27 12:32 (UTC)

I haven't changed them since I took over maintenance of the package, but the makedeps could use a bit of pruning. In terms of actual dependencies though, this package is on-par with the binary package. Feel free to try building without the packages you mentioned if you like. If you could let me know your findings, that'd be a big help. I'll see if I can find the time to run my own checks.

commented on 2015-07-27 12:15 (UTC)

How come this package comes with so many dependencies compared to the binary package? I do understand some tools for compiling and such. But what about gstreamer, libnotify, unzip etc?

WorMzy commented on 2015-07-27 11:57 (UTC)

I can't make it any more up to date than the current version. ;)

WorMzy commented on 2015-06-23 07:02 (UTC)

No worries. :)

izahn commented on 2015-06-23 03:24 (UTC)

Accidentally clicked the "flag out of date" link, sorry! Couldn't find a way to "unflag"...

WorMzy commented on 2015-05-14 13:01 (UTC)

Looks like this should be fixed in the next release:

jaro3 commented on 2015-05-11 06:02 (UTC)

As a quick fix I adapted the package as palemoon-infinality based on

WorMzy commented on 2015-05-10 11:58 (UTC)

You can try disabling the skia graphics engine by adding 'ac_add_options --disable-skia' to, it builds then, and I haven't noticed any problems so far (fonts look a little more blurry, but I'm not sure if I'm just imaging that). The better option is to report this as a bug to the infinality dev(s).

WorMzy commented on 2015-05-10 11:32 (UTC)

Aha, I can reproduce this with freetype2-infinality-ultimate. Since it builds with Arch's stock freetype2, and freetype2-ubuntu, and the code it's failing to build hasn't been changed in a year [1], I think this is a problem with the infinality patchset. In the stock freetype2 and ubuntu's patchset, FT_Get_X11_Font_Format is defined in freetype2/ftxf86.h, but in infinality, it's defined in freetype2/ftfntfmt.h. I don't know if this is a recent change, but it breaks drop-in replacement which infinality is apparently supposed to maintain[2]. [1] [2]

veganvelociraptr commented on 2015-05-10 09:31 (UTC)

I can confirm the exact same problem as jaro3 has, both with 25.40 and 25.4.1. Removing "--enable-optimize" doesn't change anything. And yes, I also use the infinality fonts.

jaro3 commented on 2015-05-10 03:39 (UTC)

The same error remains there even if I set MAKEFLAGS="-j1" in makepkg.conf and make manually... My gcc is gcc-multilib 4.9.2-4 1:32.98 ../../gfx/skia/SkFontHost_FreeType.o: In function `SkFontHost::GetAdvancedTypefaceMetrics(unsigned int, SkAdvancedTypefaceMetrics::PerGlyphInfo, unsigned int const*, unsigned int)': 1:32.98 SkFontHost_FreeType.cpp:(.text._ZN10SkFontHost26GetAdvancedTypefaceMetricsEjN25SkAdvancedTypefaceMetrics12PerGlyphInfoEPKjj+0x11a): undefined reference to `FT_Get_X11_Font_Format' 1:32.98 collect2: error: ld returned 1 exit status 1:32.98 /usr/src/tmp/palemoon/src/Pale-Moon/config/ recipe for target '' failed 1:32.98 make[5]: *** [] Error 1 1:32.98 /usr/src/tmp/palemoon/src/Pale-Moon/config/makefiles/ recipe for target 'libs_tier_platform' failed 1:32.98 make[4]: *** [libs_tier_platform] Error 2 1:32.99 /usr/src/tmp/palemoon/src/Pale-Moon/config/ recipe for target 'tier_platform' failed 1:32.99 make[3]: *** [tier_platform] Error 2 1:32.99 /usr/src/tmp/palemoon/src/Pale-Moon/config/ recipe for target 'default' failed 1:32.99 make[2]: *** [default] Error 2 1:32.99 /usr/src/tmp/palemoon/src/Pale-Moon/ recipe for target 'realbuild' failed 1:32.99 make[1]: *** [realbuild] Error 2 1:32.99 recipe for target 'build' failed 1:32.99 make: *** [build] Error 2 1:33.02 608 compiler warnings present. ==> ERROR: A failure occurred in build(). Aborting...

jaro3 commented on 2015-05-10 02:53 (UTC)

I get the same error with 25.4.1 even if --enable-optimize commented out in mozconfig. Could this error be related to parallel build "-j 4" in makepkg.conf or to using the infinality fonts instead of the stock Arch fonts? Previous builds were running fine for me but the whole system was updated recently...

WorMzy commented on 2015-05-09 18:59 (UTC)

Is it failing at the exact same place? Also, was this with 25.4.0 or 25.4.1 (just uploaded an hour or so ago)? Does it build for you if you comment out the "--enable-optimize" line (#36) in mozconfig?

veganvelociraptr commented on 2015-05-09 16:57 (UTC)

I have the same problem as jaro3. Could it perhaps be because of a specific GCC version? In my case it's 4.9.2? I've not changed any build file, though I've set makepkg.conf to use ccache. But that has worked previously with PaleMoon 25.3.x.

WorMzy commented on 2015-05-09 12:33 (UTC)

I cant reproduce this, but it's not the first time I've seen the build fail at that point (although I've only seen it when building with clang, not gcc). Have you modified the build files, or your makepkg.conf? If the build consistently fails for you here, then you may want to switch to the palemoon-bin package, which should be updated for 25.4 soon.

jaro3 commented on 2015-05-09 08:25 (UTC)

Build fails with: 46:55.82 SkFontHost_FreeType.cpp:(.text._ZN10SkFontHost26GetAdvancedTypefaceMetricsEjN25SkAdvancedTypefaceMetrics12PerGlyphInfoEPKjj+0x11a): undefined reference to `FT_Get_X11_Font_Format' 46:55.82 collect2: error: ld returned 1 exit status 46:55.82 /usr/src/tmp/palemoon/src/Pale-Moon/config/ recipe for target '' failed 46:55.82 make[5]: *** [] Error 1 46:55.82 /usr/src/tmp/palemoon/src/Pale-Moon/config/makefiles/ recipe for target 'libs_tier_platform' failed 46:55.82 make[4]: *** [libs_tier_platform] Error 2 46:55.82 /usr/src/tmp/palemoon/src/Pale-Moon/config/ recipe for target 'tier_platform' failed 46:55.82 make[3]: *** [tier_platform] Error 2 46:55.82 /usr/src/tmp/palemoon/src/Pale-Moon/config/ recipe for target 'default' failed 46:55.82 make[2]: *** [default] Error 2 46:55.82 /usr/src/tmp/palemoon/src/Pale-Moon/ recipe for target 'realbuild' failed 46:55.82 make[1]: *** [realbuild] Error 2 46:55.82 recipe for target 'build' failed 46:55.82 make: *** [build] Error 2 46:55.86 604 compiler warnings present. ==> ERROR: A failure occurred in build(). Aborting...

WorMzy commented on 2015-05-07 19:36 (UTC)

I have also explicitly enabled the -02 optimize flag in, as -03 and other optimize flags have been causing problems recently. If you choose to override this flag, you may experience problems with Palemoon crashing or behaving erratically.

WorMzy commented on 2015-04-06 10:28 (UTC)

Please note that I'll be disabling jemalloc in the file when Palemoon is next updated. See for an explanation of why.

WorMzy commented on 2015-01-15 21:25 (UTC)

The only download for the sourcecode is currently a 7z file on Pale-Moon's ftp site. I'm hoping that the github repo gets update soon so I can implement the same thing I have going on in the palemoon-beta package (git source). In the meantime, please use the following (if you don't mind slooooooooooooow ftp downloads):

WorMzy commented on 2014-11-24 16:51 (UTC)

It's the cuddlefish file again.. md5sums updated. I'm not sure if this is github not providing static tarballs, or wolfbeast retagging the release. I'd guess the former. In any case, as previously mentioned, I'll be switching to git checkout with the next release, so any changes like this won't cause makepkg to balk (with the added benefit that people won't need to download a huge tarball after every update).

snarfies commented on 2014-11-24 03:00 (UTC)

==> Validating source files with md5sums... 25.1.0_Release.tar.gz ... FAILED palemoon.desktop ... Passed ... Passed ==> ERROR: One or more files did not pass the validity check! ==> ERROR: Makepkg was unable to build palemoon.

ThePacman commented on 2014-11-23 06:20 (UTC)

aphirst: You can run makepkg 2>&1 | tee makepkg.log That will create a text file at makepkg.log containing all the output of makepkg. (If you use 'script -c makepkg' instead of 'makepkg 2>&1 | tee', it will save the color codes as part of the log, which would not be good.)

WorMzy commented on 2014-11-15 13:53 (UTC)

That must be heart-breaking to encounter. Waiting an hour for it to compile successfully, but fail on the packaging with such a useless error message. :c I'm afraid that I do think your makepkg.conf modification is at (kinda) at fault here. The following bug report [1] suggests that it might be a problem with a specific processor instruction (AVX). A precursor to this bug report [2] suggests that this instruction set is enabled when running with -march=native. You could try adding --enable-optimize="-mno-avx" to the file and recompiling, but I can offer no guarantees that this will work. [1] [2]

aphirst commented on 2014-11-15 08:49 (UTC)

I tried to build this and it seemed to fail right at the end, after ~50m work. Initially I thought it was to do with doing it in tmpfs, so I did it again on my HDD with plenty of free space. Same problem. The tail end of the compilation process (my VTE only caches so much). Is it possible that any of my makepkg.conf settings are interfering? The only change I made was adding `-march=native`.

WorMzy commented on 2014-11-14 11:12 (UTC)

Thanks for the heads up, looks like git_refnames has been bumped again. As before, I have updated the md5sums, but not bumped the pkgrel. There's no need for people to rebuild because of the change. I may change the PKGBUILD to pull the tags from git for the next release, since the tarballs are apparently dynamic.

dicktater commented on 2014-11-14 04:55 (UTC)

Please update the PKGBUILD once you find out what's changed again with the github tarball. Thanks! 2014-11-13 palemoon 25.1.0-1 Validating source files with md5sums... 25.1.0_Release.tar.gz ... FAILED palemoon.desktop ... Passed ... Passed ==> ERROR: One or more files did not pass the validity check! ==> ERROR: Makepkg was unable to build palemoon.

WorMzy commented on 2014-10-20 13:46 (UTC)

Looks like there was only a minor change: diff -aur old/Pale-Moon-25.0.1_Release/addon-sdk/source/python-lib/cuddlefish/ new/Pale-Moon-25.0.1_Release/addon-sdk/source/python-lib/cuddlefish/ --- old/Pale-Moon-25.0.1_Release/addon-sdk/source/python-lib/cuddlefish/ 2014-10-13 23:51:35.000000000 +0100 +++ new/Pale-Moon-25.0.1_Release/addon-sdk/source/python-lib/cuddlefish/ 2014-10-13 23:51:35.000000000 +0100 @@ -9,7 +9,7 @@ # ( # these strings will be replaced by git during git-archive -git_refnames = " (tag: 25.0.1_Release, 25.0_RelBranch)" +git_refnames = " (tag: 25.0.1_Release)" git_full = "d981952fd1255581206e33e503afb378704da62d" I'll update the PKGBUILD, but I won't increment the pkgrel.

WorMzy commented on 2014-10-20 13:39 (UTC)

@hund: No worries, it happens. As it happens, it was quite lucky that you clicked it, as I hadn't subscribed to the comments, so I'd have missed erikwesselius' message otherwise. @erikwesselius: Looks like the github tarball changed for some reason. I'll update the PKGBUILD once I find out what's changed.

commented on 2014-10-20 11:18 (UTC)

I'm sawwy! I missed the "Vote for this package" link and pressed the "Flag this package as out of date" link instead. :( PS. Brilliant idea to have them so close together. DS.

zilvervos commented on 2014-10-20 07:33 (UTC)

Read an article about palemoon in the German Linux User magazin and wanted to try it out. But when trying to build from AUR I get this error: Validating source files with md5sums... 25.0.1_Release.tar.gz ... FAILED palemoon.desktop ... Passed ... Passed ==> ERROR: One or more files did not pass the validity check! ==> ERROR: Makepkg was unable to build palemoon. ==> Restart building palemoon ? [y/N] Trying again (which means that the 25.0.1_Release.tar.gz is downloaded again by the installer) didn't help. Same md5sum problem.

archuser474747 commented on 2014-09-12 06:20 (UTC)

No problems with HW acceleration here on my GTX570. Using 24.7.1 to 24.7.2.

magikfingerz commented on 2014-09-11 16:02 (UTC)

Compile and installation of version 24.7.2 went fine, all looks working stable, thanks! :)

Case commented on 2014-09-06 16:49 (UTC)

orifman: The same happens to me when I have HW acceleration enabled in Palemoon. As soon as I disable the HW acceleration, Palemoon runs fine. Using nVidia binary drivers, tried both stable and beta releases. Also happens with the palemoon-bin and palemoon-beta versions, but HW acceleration doesn't cause any problems with latest Firefox. It throws this error message before crashing: X_GLXVendorPrivate: GLXBadPixmap If I remember correctly, there was similar issue with Firefox some time ago. Something to do with nVidia changing certain OpenGL definitions or something.

orlfman commented on 2014-08-27 01:03 (UTC)

compile and installation went fine. but when i load up palemoon, after about 10 - 20 seconds it crashes with a segmentation fault.

archuser474747 commented on 2014-08-21 15:53 (UTC)

G'day aphirst. Compiling and packing ok here with an up to date system. Tried makepkg without yaourt?

aphirst commented on 2014-08-17 04:22 (UTC)

Building seemed to be successful, but then the packaging failed. End of build log:

graysky commented on 2014-06-23 19:57 (UTC)

Thank you for providing this package; you should edit the pkgdesc removing the 2nd sentence: pkgdesc="Open source web browser based on Firefox focusing on efficiency."

archuser474747 commented on 2014-06-20 09:43 (UTC)

24.6.2 is out.

cb474 commented on 2014-06-13 22:00 (UTC)

Okay, thanks artiom. I'll give it a try when I have a few hours to let the compilation process run. I appreciate your maintaining this package.

artiom commented on 2014-06-12 19:52 (UTC)

The source package is tricky to compile. I didn't succeed yet. On the palemoon forum my question is waiting for moderation.... So these are the reasons. But if you take this source and existing PKGBUILD you can try to compile it yourself.

cb474 commented on 2014-06-12 18:53 (UTC)

Is there a specific reason this package is not being updated to the latest release (24.6.0)? Or have you just not had time yet, artiom? Just wondering. Thanks.

artiom commented on 2014-06-10 08:49 (UTC)

I see nothing important in your logs. It was the same for me.

commented on 2014-06-06 21:04 (UTC)

I guess this is a mute point... config log build warnings pt 1,2,3

sumt commented on 2014-06-06 18:24 (UTC)

24.6 was released, There is a github repo too,

commented on 2014-06-06 17:22 (UTC)

Downloaded and did local makepkg (no changes to file) - should have done this first. Compile succeeded (updated kernal and not restarting maybe). Noticed warning messages go flying by on the console. Will try to trap and put to pastebin. Start up was painful as the previous session would cause crashes. journalctl -r ---- Jun 06 11:15:25 slim[714]: (pale moon:20384): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised Jun 06 11:15:25 slim[714]: (pale moon:20384): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised Jun 06 11:15:25 slim[714]: (pale moon:20384): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised Jun 06 11:15:25 slim[714]: (pale moon:20384): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised Jun 06 11:15:25 slim[714]: (process:20384): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed ----- Ended up dumping previous session and starting fresh. Error message above occurs at each startup. Pastebin to follow

artiom commented on 2014-06-06 09:03 (UTC)

Could you find an error in you screen/logs? This is just a recursive list of failed makefiles. Alternatively uncomment this line in #ac_add_options --disable-webrtc You need to recalculate md5sums after it as well.

commented on 2014-06-05 23:12 (UTC)

build failed for me. make[6]: Leaving directory '/var/cache/pacman/pkg/palemoon1097/palemoon/src/pmbuild/media/webrtc/trunk' /var/cache/pacman/pkg/palemoon1097/palemoon/src/config/makefiles/ recipe for target 'libs' failed make[5]: Leaving directory '/var/cache/pacman/pkg/palemoon1097/palemoon/src/pmbuild/media/webrtc' /var/cache/pacman/pkg/palemoon1097/palemoon/src/config/makefiles/ recipe for target 'libs_tier_platform' failed make[4]: Leaving directory '/var/cache/pacman/pkg/palemoon1097/palemoon/src/pmbuild' /var/cache/pacman/pkg/palemoon1097/palemoon/src/config/ recipe for target 'tier_platform' failed make[3]: Leaving directory '/var/cache/pacman/pkg/palemoon1097/palemoon/src/pmbuild' /var/cache/pacman/pkg/palemoon1097/palemoon/src/config/ recipe for target 'default' failed make[2]: Leaving directory '/var/cache/pacman/pkg/palemoon1097/palemoon/src/pmbuild' /var/cache/pacman/pkg/palemoon1097/palemoon/src/ recipe for target 'realbuild' failed make[1]: Leaving directory '/var/cache/pacman/pkg/palemoon1097/palemoon/src' recipe for target 'build' failed