[Bug 251117] [NEW PORT] www/palemoon: Open-source web browser

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Fri Feb 12 22:48:04 UTC 2021


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251117

--- Comment #2 from Olivier Certner <olivier.freebsd at free.fr> ---
Attaching a patch with the latest version with official branding enabled.

Official branding is granted in compliance with Pale Moon's redistribution
license (see https://www.palemoon.org/redist.shtml), point 8b, as explicitly
confirmed by the owner (Moonchild; see
https://forum.palemoon.org/viewtopic.php?f=5&t=25625 for the relevant
discussion on Pale Moon's forums), since build options were not modified beyond
what is necessary to get a stable build on FreeBSD. More precisely, upstream
insisted that their in-tree jemalloc be used instead of the system's one, but
agreed with the requirement to link against libc++ (since Pale Moon's platform
indirectly depends on libraries containing C++ code).

I had to go to the pain of making their in-tree jemalloc bootstrap on FreeBSD,
as well as modify the ad-hoc build system (inherited from an old version of
Mozilla's) to work with Tauthon, since Python 2.7 is EOL. Notwithstanding the
fact that the browser and its platform have to be built with GCC whereas the
C++ pieces have to be compiled and linked against libc++.

For the record, relevant issues and pull requests upstream:
- https://repo.palemoon.org/MoonchildProductions/UXP/issues/1699
- https://repo.palemoon.org/MoonchildProductions/UXP/pulls/1703
- https://repo.palemoon.org/MoonchildProductions/UXP/pulls/1706
- https://repo.palemoon.org/MoonchildProductions/UXP/issues/1729
- https://repo.palemoon.org/MoonchildProductions/UXP/issues/1730
- https://repo.palemoon.org/MoonchildProductions/UXP/pulls/1731
- https://repo.palemoon.org/MoonchildProductions/UXP/pulls/1736

Redistribution of binary packages is allowed as long as the default options are
not changed with respect to the current ones (if they must, then I would likely
have to check with upstream).

Any individual user using the port system is free to change the provided
options as he wishes before he builds and retain official branding as long as
he doesn't distribute his version. It can expect no support upstream if not
using the default build options. I'll try to provide some when necessary, but
prepared to be advised to just drop non-default options if for whatever reason
I can't.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-ports-bugs mailing list