Arch Linux User Repository

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 https://forum.palemoon.org/viewtopic.php?f=1&t=28044

The following key is used to sign source archives:

40481E7B8FCF9CEC

Import it into your keyring however you want.

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

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

@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: https://repo.palemoon.org/MoonchildProductions/Pale-Moon/releases

The commit used for the 29.4.6 release is https://repo.palemoon.org/MoonchildProductions/Pale-Moon/commit/f694a76857ea2bcc13de94987ae925445d5d587d signed by Moonchild with the aforementioned key.

@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
29.4.5.1_Release
44d7f4b8c3 

The key used to sign commit 44d7f4b8c3 was 40481E7B8FCF9CEC: https://repo.palemoon.org/MoonchildProductions/palemoon-dev/commit/44d7f4b8c34dc50c1f54995a6ec0535e2f0549d1

$ 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) <moonchild@palemoon.org>" [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.

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

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 https://forum.palemoon.org/viewtopic.php?f=1&t=28044

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.

You can grab the last-packaged gcc10 package here: https://archive.archlinux.org/packages/g/gcc10/gcc10-1%3A10.3.0-2-x86_64.pkg.tar.zst

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

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

https://github.com/archlinux/svntogit-community/tree/9bd106b835a2197218e4bfce6f34644c7d04a937/gcc10

@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?

https://github.com/archlinux/svntogit-community/tree/packages/gcc10/trunk

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

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.

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

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

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.

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

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

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

It seems like the signatures have been uploaded on http://archive.palemoon.org/source/

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

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

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

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.

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.

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.

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.

https://aur.archlinux.org/packages/palemoon/?O=30&PP=10#comment-789447

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?

[1] https://www.palemoon.org/releasenotes.shtml

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

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

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.

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

Both are used.

It appears GTK3 is now used, please adjust accordingly.

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.

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

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

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.

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.

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.

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?

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/rules.mk:886: 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/recurse.mk:71: 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/recurse.mk:33: compile] Error 2
 6:19.95 make[2]: *** [/[...]/palemoon/src/Pale-Moon/platform/config/rules.mk:494: default] Error 2
 6:19.95 make[1]: *** [/[...]/palemoon/src/Pale-Moon/client.mk:406: realbuild] Error 2
 6:19.95 make: *** [client.mk:164: 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.

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

I get 403 error. Anyway to bypass this error?

fatal: unable to access 'https://repo.palemoon.org/MoonchildProductions/Pale-Moon/': The requested URL returned error: 403

Thank you for pinning!

The following key is used to sign source archives:

40481E7B8FCF9CEC

Import it into your keyring however you want.

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

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.

(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

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.

yaourt? Did you try just with

git clone https://aur.archlinux.org/palemoon.git
cd palemoon
makepkg

?

@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

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 <moonchild@palemoon.org>                    
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)

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

@WorMzy I'm getting:

Submodule path 'platform': checked out 'e1daeef18312a0cb17eda6bed7f363d8748ed4a3'

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

What does prepare() say? Should read:

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

@micwoj92 are we getting the wrong UXP commit?

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

should be:

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

nsGenericHTMLElement*
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());
  }
}

@jghodd that commit should be included

https://repo.palemoon.org/MoonchildProductions/Pale-Moon/commit/79ff7796e598775f30e00ec251e5c094e31ebe94

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.

https://repo.palemoon.org/MoonchildProductions/UXP/issues/1723

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.

https://aur.archlinux.org/packages/palemoon-gtk3/

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

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?

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

See https://forum.palemoon.org/viewtopic.php?t=11800

@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 https://support.mozilla.org/en-US/kb/what-is-plugin-container 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?

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?

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: libxul.so: 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.

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

$ strace palemoon |& grep libxul 
access("/usr/lib/palemoon/libxul.so", R_OK) = 0
openat(AT_FDCWD, "/usr/lib/palemoon/libxul.so", O_RDONLY) = 4
openat(AT_FDCWD, "/usr/lib/palemoon/libxul.so", 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.

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

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

ldd /usr/lib/palemoon/plugin-container

        libxul.so => not found

ldd /usr/lib/palemoon/libxul.so

        libmozsqlite3.so => not found
        liblgpllibs.so => not found

ldd /usr/lib/palemoon/libsoftokn3.so

        libmozsqlite3.so => not found

ldd /usr/lib/palemoon/libmozavcodec.so

        libmozavutil.so => not found

ldd /usr/lib/palemoon/browser/components/libbrowsercomps.so

        libxul.so => 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.

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

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)

:(

Further note: Upstream have renamed the repositories again. If you previously modified your git clone configs to point to https://repo.palemoon.org/MCP/... you will need to edit them again to point to https://repo.palemoon.org/MoonchildProductions/...

Note the repositories have moved to https://repo.palemoon.org/MoonchildProductions/Pale-Moon and https://repo.palemoon.org/MoonchildProductions/UXP, 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.

Thanks for the heads up, update pushed.

@WorMzy change source links please

"hotfix" for pgp keys - gpg --keyserver keys.gnupg.net --recv-keys 'key'

github repo is down - topic https://forum.palemoon.org/viewtopic.php?f=5&t=25461 new repo is https://repo.palemoon.org/MCP/Pale-Moon

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

@pieraper44 this is not issue with this package

bad

: 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

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

Woops, seems like you forgot to reset pkgrel xd

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

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.

Has this issue (https://www.reddit.com/r/palemoon/comments/imye21/before_anyone_comes_screeching_about_2813_for/ and https://forum.palemoon.org/viewtopic.php?f=40&t=25156) 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!

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!

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.

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.

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

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

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 http://developer.palemoon.org/build/linux/, so I've added that change in.

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

Thanks @WorMzy! Now it is working!

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.

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.

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: https://cdn.discordapp.com/attachments/345065713473421313/713777099126603796/unknown.png

Can you help me? thanks in advance

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: https://github.com/MoonchildProductions/UXP/issues/1531

-flto=2 is not working since the change to gcc 10, the build gets busted before linking libxul.so. 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.

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

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.

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
    Abandon…
==> ERREUR : Makepkg n'a pas pu construire palemoon.

The build process checks out UXP at commit a731633d7b50e4ec88a1a4b54d578d1abb3c4b12:

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

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

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 @ https://developer.palemoon.org/build/linux/

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

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.

Hi. Can you add this patch for compile with newer glibc versions? https://github.com/MoonchildProductions/UXP/commit/e31d79e8da99456247df84c2f99ba9083d46efe1

@dreieck:

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

I added to the PKGBUILD:

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

When trying to build, build fails for me with

[...]
110:19.04 libxul_s.a.desc
110:19.15 libxul.so
110:33.40 nm: libxul.so: no symbols
110:33.40 NSModules are not ordered appropriately
110:33.40 make[5]: *** [/tmp/palemoon/src/UXP/config/rules.mk:774: libxul.so] Error 1
110:33.40 make[5]: *** Deleting file 'libxul.so'
110:33.43 make[4]: *** [/tmp/palemoon/src/UXP/config/recurse.mk:71: toolkit/library/target] Error 2
110:33.45 make[3]: *** [/tmp/palemoon/src/UXP/config/recurse.mk:33: compile] Error 2
110:33.48 make[2]: *** [/tmp/palemoon/src/UXP/config/rules.mk:494: default] Error 2
110:33.50 make[1]: *** [/tmp/palemoon/src/UXP/client.mk:414: realbuild] Error 2
110:33.52 make: *** [client.mk:170: 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().
    Aborting...

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

CFLAGS:

-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

CXXFLAGS:

-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

LDFLAGS:

-Wl,-O1,-z,relro,-z,now,--strip-all,--as-needed,--relax,--sort-common,--hash-style=gnu,--enable-new-dtags

and build is executed with

python2 mach build -j1

Any idea what could be the problem here?

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

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.

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

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.

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 https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html) :

"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 mozconfig.in 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

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

[  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/libc.so.6 (0x7f1fe5f85000+0x3a7e0) [0x7f1fe5fbf7e0]
[  7931.122] (EE) 3: /usr/lib/libc.so.6 (gsignal+0x145) [0x7f1fe5fbf755]
[  7931.122] (EE) 4: /usr/lib/libc.so.6 (abort+0x125) [0x7f1fe5faa851]
[  7931.122] (EE) 5: /usr/lib/libc.so.6 (0x7f1fe5f85000+0x7ca38) [0x7f1fe6001a38]
[  7931.122] (EE) 6: /usr/lib/libc.so.6 (0x7f1fe5f85000+0x8325a) [0x7f1fe600825a]
[  7931.122] (EE) 7: /usr/lib/libc.so.6 (0x7f1fe5f85000+0x84c5c) [0x7f1fe6009c5c]
[  7931.122] (EE) 8: /usr/lib/xorg/modules/drivers/intel_drv.so (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.so.6 (__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 
         at http://wiki.x.org
 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.

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

Had to stop using it for the meanwhile.

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.

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

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.

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

@WorMzy

https://pastebin.com/V9A1xR18

https://pastebin.com/ex9gCdhn

Thanks

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

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.

Compile fail... 0:03.86 File "/home/ljohnson/AUR/palemoon/src/UXP/python/mozbuild/mozbuild/virtualenv.py", 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

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 https://aur.archlinux.org/packages/palemoon/?O=30&PP=10#comment-623566

Rebuild your freshplayer and see if you still get crashes.

@WorMzy yup. been there. done that.

https://forum.palemoon.org/viewtopic.php?f=37&t=21671&p=164063#p164063

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

https://forum.palemoon.org/viewtopic.php?t=17638

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

@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 mozconfig.in - 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.

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.

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

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

Thanks for the heads up, haawda. Update pushed.

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

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.

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

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.

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.

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.

The actual error in your build is:

Assembler messages:
end of file not at end of a line; newline inserted
.LVU
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?

https://nas.epistromo.com/s/KrHrDPRDwdCTHcJ

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

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.

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.

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

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/recurse.mk:33: compile] Error 2 27:12.97 make[2]: [/tmp/yaourt-tmp-root/aur-palemoon/src/UXP/config/rules.mk:503: default] Error 2 27:12.97 make[1]: [/tmp/yaourt-tmp-root/aur-palemoon/src/UXP/client.mk:414: realbuild] Error 2 27:12.97 make: [client.mk:170: build] Error 2

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

[1] http://developer.palemoon.org/Developer_Guide:Build_Instructions/Pale_Moon/Linux

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.

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

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, поэтому можно не ипаццо с его сборкой, а просто установить оттуда.

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

http://dpaste.com/3V76NDX

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

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.

https://developer.palemoon.org/Developer_Guide:Build_Instructions/Pale_Moon/Linux

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

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

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

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

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

@jerome2016: I've had another look at the strace output, and I noticed this line: openat(AT_FDCWD, "/usr/lib/libicuuc.so.59", 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
done

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

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

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