Created attachment 187909 [details]
A Firefox-fork which is popular with those people who chose Firefox for using the XUL extensions. For them, Pale Moon is just the way Firefox should be.
The porting is greatly simplified with the existing gecko supporting framework in ports. The software has the same requirements as a Firefox ~24. With this patch,
- bundled jemalloc3 is always required. We could patch the source and let it use system jemalloc, but that would only benefit FreeBSD 10.
- not patched to use system sndio or ogg. Since we are not using system jemalloc, it may further downgrade the memory stats if we use too much shared libraries.
- still sharing Makefile.options with www/firefox, although some options don't apply; INTEGER_SAMPLES display but have no effect. We could patch www/firefox/Makefile.options to hide this (in a separate issue, maybe).
- TEST doesn't work due to messy #include_nexts among libc++, libc, and stlport. I gave it up. After all, this browser is not eagerly adopting new technologies like Firefox, and my observation confirmed its stability.
This PR is filed in Pale Moon + Pentadactyl.
Created attachment 187945 [details]
patch (with devtools enabled)
May gecko@ allow making some changes w.r.t. Pale Moon in bsd.gecko.mk?
Created attachment 188062 [details]
updated to 27.6.1
Created attachment 188089 [details]
freebsd 12 WIP
Created attachment 188105 [details]
freebsd 12 WIP
Some patch contributed by https://twitter.com/loader
Created attachment 188106 [details]
freebsd 12 WIP
> +MAINTAINER= gecko@FreeBSD.org
> +USE_GECKO= gecko
I'm neither interested in maintaining nor familar with codebase of Gecko forks. Given Pale Moon engine is Goanna an independent port would be better. Upstream isn't friendly to Gecko contributors, anyway.
Created attachment 188190 [details]
I certainly don't know in which way you feel Mozilla is less unfriendly. I use software that works.
Passes on amd64 -current https://t.co/GpTQYjSGjo
Linker issue on AArch64 https://t.co/ZgTr8z86Ue
Can you adjust maintainer in pkg-message as well?
(In reply to lichray from comment #8)
> Linker issue on AArch64 https://t.co/ZgTr8z86Ue
> /usr/bin/ld: error: undefined symbol: nsXPTCStubBase::Stub3()
> >>> referenced by /wrkdirs/usr/ports/www/palemoon/work/Pale-Moon-27.6.1_Release/xpcom/reflect/xptcall/xptcall.cpp
> >>> ../../xpcom/reflect/xptcall/xptcall.o:(vtable for nsXPTCStubBase)
Try backporting https://bugzilla.mozilla.org/show_bug.cgi?id=1330119
Created attachment 188197 [details]
Thanks, Jan. loader@, can you give it a try?
can be fixed by backporting
(In reply to lichray from comment #1)
> May gecko@ allow making some changes w.r.t. Pale Moon in bsd.gecko.mk?
Depends on what you have in mind. Generic changes improving clarity should be fine, less so for stuff specific to Pale Moon.
(In reply to lichray from comment #10)
> Thanks, Jan. loader@, can you give it a try?
Actually, you can cross-compile the port:
# -x (native-xtools) before FreeBSD 12.0 requires /usr/src to match jail
$ svn checkout https://svn.freebsd.org/base/releng/11.1 /usr/src
$ poudriere jail -cxj 111aarch64 -a arm64.aarch64 -v 11.1-RELEASE
$ poudriere bulk -Ctj 111aarch64 www/palemoon
$ poudriere jail -cxj head-aarch64 -a arm64.aarch64 -v head -m svn+https
$ poudriere bulk -Ctj head-aarch64 www/palemoon
What is puzzling is how did it happen after ports r448278.
(In reply to lichray from comment #0)
> We could patch www/firefox/Makefile.options to hide this (in a separate issue, maybe).
Try OPTIONS_EXCLUDE for incompatible ones or those (like TEST) you don't plan to maintain.
A commit references this bug:
Date: Thu Nov 23 00:58:53 UTC 2017
New revision: 454738
www/palemoon: add new port
Submitted by: email@example.com
Tested by: loader, many on forums.freebsd.org
Pale Moon offers you a browsing experience in a browser completely built
from its own, independently developed source that has been forked off
from Firefox/Mozilla code a number of years ago, with carefully selected
features and optimizations to improve the browser's stability and user
experience, while offering full customization and a growing collection
of extensions and themes to make the browser truly your own.
o Support for many Firefox extensions
o Support for a growing number of Pale Moon exclusive extensions
o Secure: Additional security features and security-aware development
o Extensive and growing support for HTML5 and CSS3
Next package build starts at 01:00 UTC today. I've landed now, so you can get more feedback from users.
(In reply to Jan Beich from comment #15)
Thank you so much! I'll continue to poudriere it.
If tonight build for /latest set succeeds you can inspect build logs at:
or check via https://pkg-status.freebsd.org/
> # lldb -c palemoon.core /usr/local/bin/palemoon
> (lldb) target create "/usr/local/bin/palemoon" --core "palemoon.core"
> Core file '/root/palemoon.core' (aarch64) was loaded.
> (lldb) bt
> * thread #1, name = 'palemoon', stop reason = signal SIGSEGV
> * frame #0: 0x00000000403614d8 libthr.so.3`___lldb_unnamed_symbol83$$libthr.so.3 + 44
> frame #1: 0x0000fffffffff000
> frame #2: 0x0000000040178f58 ld-elf.so.1
> frame #3: 0x0000000040172c94 ld-elf.so.1
> frame #4: 0x0000000040170074 ld-elf.so.1
> frame #5: 0x0000000043766f18 libxul.so`_cairo_pattern_acquire_surface [inlined] _cairo_pattern_acquire_surface_for_gradient(pattern=<unavailable>, dst=<unavailable>, x=<unavailable>, y=<unavailable>, width=<unavailable>, height=<unavailable>, out=<unavailable>, attr=<unavailable>) at cairo-pattern.c:1527
Can you build gnu/lib/csu, lib/libc, lib/libthr and libexec/rtld-elf with debug symbols, so the stacktrace shows what ld-elf tries to do? I wonder if bundled jemalloc (3.6.0-204-gb4acf7300a4c) is too old for aarch64. Try removing --enable-jemalloc* from www/palemoon/Makefile.
Thanks jbeich@ for your help.
packages were compiled on Raspberry Pi 3
# uname -rmspKU
FreeBSD 12.0-CURRENT arm64 aarch64 1200053 1200053