Bug 223597

Summary: New port: www/palemoon Open Source Goanna-based web browser
Product: Ports & Packages Reporter: lichray
Component: Individual Port(s)Assignee: Jan Beich <jbeich>
Status: Closed FIXED    
Severity: Affects Only Me CC: Lena, feld, gecko, loader
Priority: --- Flags: jbeich: maintainer-feedback+
Version: Latest   
Hardware: Any   
OS: Any   
Description Flags
patch (svn)
patch (with devtools enabled)
updated to 27.6.1
freebsd 12 WIP
freebsd 12 WIP
freebsd 12 WIP
change maintainer
attempt aarch64 none

Description lichray 2017-11-10 17:02:03 UTC
Created attachment 187909 [details]
patch (svn)

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.

Porting notes:

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.
Comment 1 lichray 2017-11-12 19:41:21 UTC
Created attachment 187945 [details]
patch (with devtools enabled)

May gecko@ allow making some changes w.r.t. Pale Moon in bsd.gecko.mk?
Comment 2 lichray 2017-11-17 01:23:54 UTC
Created attachment 188062 [details]
updated to 27.6.1
Comment 3 lichray 2017-11-18 07:29:26 UTC
Created attachment 188089 [details]
freebsd 12 WIP
Comment 4 lichray 2017-11-19 03:06:10 UTC
Created attachment 188105 [details]
freebsd 12 WIP

Some patch contributed by https://twitter.com/loader
Comment 5 lichray 2017-11-19 03:45:27 UTC
Created attachment 188106 [details]
freebsd 12 WIP
Comment 6 Jan Beich freebsd_committer 2017-11-22 07:22:01 UTC
> +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[1] to Gecko contributors, anyway.


[1] https://github.com/MoonchildProductions/Pale-Moon/pull/468
Comment 7 lichray 2017-11-22 07:51:18 UTC
Created attachment 188190 [details]
change maintainer

I certainly don't know in which way you feel Mozilla is less unfriendly.  I use software that works.
Comment 8 lichray 2017-11-22 16:01:23 UTC
Passes on amd64 -current https://t.co/GpTQYjSGjo
Linker issue on AArch64 https://t.co/ZgTr8z86Ue
Comment 9 Jan Beich freebsd_committer 2017-11-22 18:29:44 UTC
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
Comment 10 lichray 2017-11-22 19:03:17 UTC
Created attachment 188197 [details]
attempt aarch64

Thanks, Jan.  loader@, can you give it a try?
Comment 11 Jan Beich freebsd_committer 2017-11-22 20:34:18 UTC
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
Comment 12 Jan Beich freebsd_committer 2017-11-22 20:36:50 UTC
> https://forums.freebsd.org/threads/59110/#post-366220

What is puzzling is how did it happen after ports r448278.
Comment 13 Jan Beich freebsd_committer 2017-11-22 21:12:02 UTC
(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.
Comment 14 commit-hook freebsd_committer 2017-11-23 00:59:25 UTC
A commit references this bug:

Author: jbeich
Date: Thu Nov 23 00:58:53 UTC 2017
New revision: 454738
URL: https://svnweb.freebsd.org/changeset/ports/454738

  www/palemoon: add new port

  PR:		223597
  Submitted by:	lichray@gmail.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.

  Main features:

   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


Comment 15 Jan Beich freebsd_committer 2017-11-23 01:00:55 UTC
Next package build starts at 01:00 UTC today. I've landed now, so you can get more feedback from users.
Comment 16 lichray 2017-11-23 01:40:57 UTC
(In reply to Jan Beich from comment #15)

Thank you so much!  I'll continue to poudriere it.
Comment 18 Jan Beich freebsd_committer 2017-11-26 10:17:39 UTC
> https://people.freebsd.org/~loader/poudriere/aarch64/palemoon_sysvhm.txt
> # 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.
Comment 19 Fukang Chen freebsd_committer 2017-11-27 05:27:51 UTC
Thanks jbeich@ for your help.

packages were compiled on Raspberry Pi 3
# uname -rmspKU
FreeBSD 12.0-CURRENT arm64 aarch64 1200053 1200053
base: r325838
ports: r454220