Bug 251117

Summary: [NEW PORT] www/palemoon: Open-source web browser
Product: Ports & Packages Reporter: Olivier Certner <olivier.freebsd>
Component: Individual Port(s)Assignee: Port Management Team <portmgr>
Status: In Progress ---    
Severity: Affects Some People CC: Lena, instructionset, kevans, pi
Priority: ---    
Version: Latest   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
New port
none
Version 29.0.1: Patch against the ports tree
none
Version 29.0.1, -CURRENT build hopefully fixed
none
Update to 29.1.0, using GCC 10
none
Update to 29.1.1
olivier.freebsd: maintainer-approval+
Update to 29.2.0 olivier.freebsd: maintainer-approval+

Description Olivier Certner 2020-11-13 22:04:57 UTC
Created attachment 219655 [details]
New port

Hi,

Here is a port of most of Pale Moon code with unofficial branding.

This port depends on the new Tauthon port I submitted here: bug #251019

Even when this dependency is imported, please *do not import the patch yet*. I'm in the process of liaising with upstream in order to verify that there is no branding or redistribution problems with the submitted port. I'll post a comment giving the go when the process finishes (the patch may need to be modified before reaching this point).

Small description: "Open-source web browser mostly using Pale Moon(TM) code"

The build needs some specific versions of GCC (executables crash with base clang on 12). GCC 9 was chosen since it is our current default and is (almost) officially endorsed upstream (and stability seems perfect so far). So USE_GCC is set, but then LDFLAGS and CXXFLAGS are appended to in order that g++ links to (base) libc++ (static link against libgcc.a). This is necessary since linking against libstdc++ while one of the dependencies is linked to libc++ causes a crash for this codebase. Also, gcc is removed from RUN_DEPENDS. See the comments in the Makefile (see also bug #211154).

Apart from jemalloc, all bundled libraries are used in preference to our versions in the ports tree. This is by design, and not bad by principle, and personally I won't dispute this precise case. See https://forum.palemoon.org/viewtopic.php?f=5&t=23706 for upstream's rationale.

So please wait until I confirm that the patch is final before importing into the tree. (And, obviously, please advise if you think the current Makefile is doing things wrong.)

Regards.
Comment 1 Olivier Certner 2020-11-20 17:00:28 UTC
The port could be effectively imported without problems, as it is not using official branding.

However, I'm trying to come closer to enabling it technically (not sure if activating it would be desirable).

Going also to clarify if there are more unofficial branding downsides, and how annoying they are.

So please wait while I'm resolving this.
Comment 2 Olivier Certner 2021-02-12 22:48:04 UTC
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.
Comment 3 Olivier Certner 2021-02-12 22:49:03 UTC
Created attachment 222399 [details]
Version 29.0.1: Patch against the ports tree
Comment 4 Kurt Jaeger freebsd_committer 2021-02-13 14:40:10 UTC
portlint -AC reports this:

WARN: Makefile: [26]: possible direct use of command "autoconf213" found. Use ${AUTOCONF} instead and set according USE_AUTOTOOLS=<tool> macro
WARN: Makefile: [53]: Setting a specific version for USE_GCC should only be done as a last resort.  Unless you have confirmed this port does not build with later versions of GCC, please use USE_GCC=9+.
FATAL: Makefile: the last line of Makefile has to be .include <bsd.port(.post).mk> (or .endif in the case of a conditional)
FATAL: Makefile: extra item "UXP_VERSION" placed in the PORTNAME section.
WARN: Makefile: Consider defining LICENSE.
WARN: Makefile: "ONLY_FOR_ARCHS" has to appear earlier.
WARN: Makefile: "ONLY_FOR_ARCHS_REASON" has to appear earlier.
WARN: Makefile: "LIB_DEPENDS" has to appear earlier.
WARN: Makefile: "BUILD_DEPENDS" has to appear earlier.
WARN: Makefile: "USES" has to appear earlier.
WARN: Makefile: seems to have unnecessary blank lines at the last part.
WARN: /home/pi/m/www/palemoon/files/patch-platform_config_gcc-stl-wrapper.template.h: patch was not generated using ``make makepatch''.  It is recommended to use ``make makepatch'' when you need to [re-]generate a patch to ensure proper patch format.
WARN: /home/pi/m/www/palemoon/files/patch-platform_gfx_harfbuzz_src_hb-blob.cc: patch was not generated using ``make makepatch''.  It is recommended to use ``make makepatch'' when you need to [re-]generate a patch to ensure proper patch format.
WARN: /home/pi/m/www/palemoon/files/patch-platform_memory_mozjemalloc_jemalloc.c: patch was not generated using ``make makepatch''.  It is recommended to use ``make makepatch'' when you need to [re-]generate a patch to ensure proper patch format.
WARN: /home/pi/m/www/palemoon/files/patch-platform_python_mozbuild_mozbuild_configure___init__.py: patch was not generated using ``make makepatch''.  It is recommended to use ``make makepatch'' when you need to [re-]generate a patch to ensure proper patch format.
WARN: /home/pi/m/www/palemoon/files/patch-platform_python_mozbuild_mozbuild_frontend_sandbox.py: patch was not generated using ``make makepatch''.  It is recommended to use ``make makepatch'' when you need to [re-]generate a patch to ensure proper patch format.
WARN: /home/pi/m/www/palemoon/files/patch-platform_python_virtualenv_site.py: patch was not generated using ``make makepatch''.  It is recommended to use ``make makepatch'' when you need to [re-]generate a patch to ensure proper patch format.
WARN: /home/pi/m/www/palemoon/files/patch-platform_python_virtualenv_virtualenv.py: patch was not generated using ``make makepatch''.  It is recommended to use ``make makepatch'' when you need to [re-]generate a patch to ensure proper patch format.
2 fatal errors and 16 warnings found.
Comment 5 Kurt Jaeger freebsd_committer 2021-02-13 14:40:44 UTC
testbuild on 12.2amd64 fails in poudriere, see:

https://people.freebsd.org/~pi/logs/palemoon-122.txt
Comment 6 Kurt Jaeger freebsd_committer 2021-02-13 18:02:18 UTC
(In reply to Kurt Jaeger from comment #5)
Adding

USES=pkgconfig

helps with that failure. Testbuild@work
Comment 7 Kurt Jaeger freebsd_committer 2021-02-13 18:21:48 UTC
(In reply to Kurt Jaeger from comment #6)
Build on 12.2amd64 was fine. Testbuilds on current, current-i386, 13.0 and 11.4 @ work.
Comment 8 Kurt Jaeger freebsd_committer 2021-02-13 19:43:50 UTC
(In reply to Kurt Jaeger from comment #7)
Build fails on current-amd64:

https://people.freebsd.org/~pi/logs/www__palemoon-140-1613240457.txt
Comment 9 Olivier Certner 2021-02-13 21:52:30 UTC
(In reply to Kurt Jaeger from comment #4)

Hi,

Thanks for taking this.

Yes, I know about these warnings. Most of them seem moot to me: They describe situations for which what I did is exactly what is intented. E.g., USE_GCC mentions 9, because I want this precise version and no other (and, in particular, more recent ones).

For the order of the different Makefile's statement, I mostly followed the guidelines, but found that for some reason, IIRC, no order makes all warnings disappear (I remember suspecting some bug in portlint). And some of the suggested changes are clearly semantically wrong, such as moving UXP_VERSION elsewhere: I want it to be adjacent to DISTVERSION as a clear reminder that it must be changed in sync with it. Also, there is the required include at the end, but it is followed by some manipulation of RUN_DEPENDS that must be done after it (see bug #211154).

If you insist, I could regenerate the patches using 'make makepatch'.

If you know of whatever way to remove some warnings, or you have advices on the Makefile, given what I've said, I'm all ears.
Comment 10 Olivier Certner 2021-02-13 21:56:53 UTC
(In reply to Kurt Jaeger from comment #8)

Did not test against CURRENT indeed. Never seen such kind of failure yet with this codebase. I'll have to reproduce it to understand what's going on.
Comment 11 Olivier Certner 2021-02-13 21:59:25 UTC
(In reply to Olivier Certner from comment #9)

There has been progress in bug #211154, apparently USE_GCC now has a build option! I'll see if I can indeed use it, and possibly make changes to the Makefile (removing one of the FATAL reported by portlint). Next Monday.
Comment 12 Olivier Certner 2021-02-15 11:45:26 UTC
Attaching a new patch, superseding the previous one.

Changes:
1. I've fixed all FAILURE and almost all WARNINGS from `portlint -AC`. The ordering "bug" was really due to putting UXP_VERSION in the PORTNAME block. I've moved it later in the file, putting a big warning near DISTVERSION, just to be able to fix the ordering, although as said this is impractical for me.
2. I should have fixed the build failure on CURRENT. I did not reproduce the problem directly (setting up a CURRENT environment would take more time) but careful examination of the logs and failing code strongly indicates that the problem is caused by the 'sed' failure seen in the logs. I've added a patch for the regexp that should make it work. The observed failure however should not happen, and is probably some sed/regex bug in -CURRENT.

Could you please test building again?

In case the build still fails with same error, could you attach the content of files:
- work/pale-moon/pmbuild/js/src/config.status
- work/pale-moon/pmbuild/js/src/config.log

Thanks.
Comment 13 Olivier Certner 2021-02-15 11:46:07 UTC
Created attachment 222461 [details]
Version 29.0.1, -CURRENT build hopefully fixed
Comment 14 Kurt Jaeger freebsd_committer 2021-02-15 12:23:37 UTC
Testbuilds@work
Comment 15 Kurt Jaeger freebsd_committer 2021-02-15 19:19:35 UTC
Committed, thanks!
Comment 16 commit-hook freebsd_committer 2021-02-15 19:20:20 UTC
A commit references this bug:

Author: pi
Date: Mon Feb 15 19:19:25 UTC 2021
New revision: 565330
URL: https://svnweb.freebsd.org/changeset/ports/565330

Log:
  New port: www/palemoon

  Pale Moon(TM) 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.

  Some of the main features:
  - Based on the Unified XUL Platform (UXP) containing our own optimized layout
    and rendering engine (Goanna).
  - Safe: Forked from mature Mozilla code and regularly updated with the latest
    security patches.
  - Secure: Additional security features and security-aware development
  - Zero ads; no telemetry, spyware or data gathering
  - Familiar, efficient, fully customizable interface

  WWW: https://www.palemoon.org/

  PR:		251117
  Submitted by:	Olivier Certner <olivier.freebsd@free.fr>

Changes:
  head/MOVED
  head/www/Makefile
  head/www/palemoon/
  head/www/palemoon/Makefile
  head/www/palemoon/distinfo
  head/www/palemoon/files/
  head/www/palemoon/files/dot.mozconfig
  head/www/palemoon/files/patch-platform_config_gcc-stl-wrapper.template.h
  head/www/palemoon/files/patch-platform_gfx_harfbuzz_src_hb-blob.cc
  head/www/palemoon/files/patch-platform_memory_mozjemalloc_jemalloc.c
  head/www/palemoon/files/patch-platform_old-configure.in
  head/www/palemoon/files/patch-platform_python_mozbuild_mozbuild_configure_____init____.py
  head/www/palemoon/files/patch-platform_python_mozbuild_mozbuild_frontend_sandbox.py
  head/www/palemoon/files/patch-platform_python_virtualenv_site.py
  head/www/palemoon/files/patch-platform_python_virtualenv_virtualenv.py
  head/www/palemoon/pkg-descr
  head/www/palemoon/pkg-plist
Comment 17 Kurt Jaeger freebsd_committer 2021-02-15 19:22:28 UTC
Please note: it fails to build on 13.0@r368817 from 2020-12-19. Build-log at:

https://people.freebsd.org/~pi/logs/www__palemoon-curi-1613391767.txt
Comment 18 Olivier Certner 2021-03-09 10:37:58 UTC
Re-opening this as the port was deleted a few hours after being committed and this bug closed.

It seems that there are ongoing discussions in portmgr@ about how to deal with the ports that still need Python 2.7 to build (Pale Moon is not the only one; other bigger ones do, such as Chromium). And also on how to have build-only dependencies, or something close to it.

In the meantime, I'll be regularly updating the diff here. For those that are using it locally, please report failures, and successes not already reported, this would help greatly.

Thanks.
Comment 19 Olivier Certner 2021-03-09 10:45:39 UTC
Created attachment 223113 [details]
Update to 29.1.0, using GCC 10
Comment 20 Kurt Jaeger freebsd_committer 2021-03-09 18:46:22 UTC
testbuilds@work
Comment 21 Lena 2021-03-27 05:57:17 UTC
`make` not in poudriere fails "memory exhausted" at final linking on 11.4 i386 PAE with 8G RAM and 5G swap running nothing else for a night:

...
780:02.44     INPUT("../../modules/zlib/src/uncompr.o")
780:02.44     INPUT("../../modules/zlib/src/zutil.o")
780:02.44     INPUT("StaticXULComponentsEnd/StaticXULComponentsEnd.o")
780:02.44
780:02.44 /usr/local/bin/ld: failed to set dynamic section sizes: memory exhausted
780:02.44 collect2: error: ld returned 1 exit status
780:02.44 gmake[7]: *** [/usr/ports/www/palemoon/work/uxp/config/rules.mk:773: libxul.so] Error 1

~ # pkg which /usr/local/bin/ld
/usr/local/bin/ld was installed by package binutils-2.33.1_4,1

After that I got the same error when rebooted in single user mode,
mount -a
swapon -a
bash
cd /usr/ports/www/palemoon
SHELL=/usr/local/bin/bash make

Please make i386 packages from the testing poudriere available for download.
Thank you.
Comment 22 Kurt Jaeger freebsd_committer 2021-03-29 19:13:34 UTC
Please decide if it's appropriate to commit this port.

It has the same use as chromium, so there should be no reason not to allow it.
Comment 23 Baptiste Daroussin freebsd_committer 2021-03-30 12:59:05 UTC
TL;DR we need to be reinsurred

Beside the python situation, there are things that would need to be clarified for sure before any introduction in the portstree:

Palemoon has a history behind like: https://github.com/jasperla/openbsd-wip/issues/86 and we also have a policy of unbundling as much as possible libraries because it makes it easier to track and apply security fixes to the ports or to adapt to our situation (compile time options or other customisations).

While we can find example in the ports tree of ports that bundles their own libraries, it should be justified if not this is a bug where the committer and/or maintainer has not paid enough attention.

Plus we may adapt the port based framework changes in the futur: adapt to toolchain evolution etc, having to seek for upstream approval for every adaptation is not really something we do expect to do.

If we were to accept this port in the ports tree, we might either seek for legal advice or have a confirmation we are free to do the above from upstream.

To be fully honest on my personal side I don't even understand completely the license statement which is at best blurry https://www.palemoon.org/redist.shtml

In the past some drama happened already because of ports with lack of clarity on the legal side.
Comment 24 Olivier Certner 2021-03-30 15:27:55 UTC
(In reply to Baptiste Daroussin from comment #23)

> Palemoon has a history behind like:
> https://github.com/jasperla/openbsd-wip/issues/86

Surely it has history, some of it being caused by each "side" wanting to be in control and not taking into account the constraints of the other party, and some  (most?) because of difficult characters. I don't think any of this is unsurmountable if people don't jump to their guns at the slightest occasion. Because, as you'll see, real legalese can be handled without much fuss.

> and we also have a policy of unbundling as much as possible libraries
> because it makes it easier to track and apply security fixes to the
> ports or to adapt to our situation (compile time options or other
> customisations).
> While we can find example in the ports tree of ports that bundles
> their own libraries, it should be justified if not this is a bug
> where the committer and/or maintainer has not paid enough attention.

It is deliberate on upstream's and my side, and fully justified here:
https://forum.palemoon.org/viewtopic.php?f=5&t=23706
I really recommend that you read it entirely. Very short executive summary (there are many more arguments in the full text): For projects with lots of dependencies, it's impossible to do any reasonable quality control when dependencies can be changed at will. Blindly applying security fixes to dependencies does more harm than good more often than not.

Personally, I'll add that upstream updates these dependencies regularly (such as NSS and NSPR). They maintain their own version for some of them (including NSS and NSPR now), merging in the upstream changes they want. So, time passing, it'll probably be harder to try to substitute their implementations with upstream ones. And again, they strongly discourage doing that.

> Plus we may adapt the port based framework changes in the futur: adapt to
> toolchain evolution etc, having to seek for upstream approval for every
> adaptation is not really something we do expect to do.

We don't need upstream approval, as long as the changes made to the build system and environment are absolutely necessary to build on FreeBSD, provided we want to keep official branding, which is beneficial (see the discussion below).

That said, it would really be best not to change the compiler explicitly specified in the Makefile without testing and seeing what upstream is doing (they issue recommendations). The current update requires some recent GCC (but not 11 yet), so I chose 10. I don't think it can happen that GCC 10 will be phased-out of the ports tree before the port is updated to use a newer version... clang 8 could not produce working executables. Did not try with more recent versions (and upstream strongly discourages using clang at the moment).

The only hard requirement is that substituting the dependencies they provide with versions in the ports tree is explicitly forbidden by default to have/keep official branding (but we are allowed to provide that if controlled by user options and not the default choices).

For changes required because of infrastructure or toolchain evolution, there are in reality no restrictions. We don't even need to seek explicit approval for these (we just have to be able to justify what has been done, if we are asked to at some point).

The overall goal is to make sure that the browser's quality doesn't degrade by going down paths not tested upstream, as much as possible.

Do you have more specific concerns in mind? I'll try to answer them immediately if I can, or liaise with upstream to check.

> If we were to accept this port in the ports tree, we might either seek
> for legal advice or have a confirmation we are free to do the above from
> upstream.
> To be fully honest on my personal side I don't even understand
> completely the license statement which is at best blurry
> https://www.palemoon.org/redist.shtml

I've clarified that a few months ago with upstream. There are two options:

1. We seek official branding: Then we have to comply with a few things, as I've just exposed. The big advantages are: We don't have to rebrand and there are no compatibility configurations to import (unbranded version doesn't have them). We are still free to make changes required to adapt to the platform, without seeking approval (unless we have a doubt). The only drawback that I see is that upstream could legally withdraw this authorization at will. But Moonchild (owner and main author) has been pretty reasonable so far with me, despite the occasional tension because of "history" (and other guys chiming in). If authorization is ever revoked, it would be easy for portmgr@ to comply, by just removing the port. So we are not trapped. The second option below would also still be available.

2. We provide our own branding. The advantage here is that we are absolutely free to build as we want, with as many system or ports libraries as we want, etc. And nobody can stop us legally. But this is not as big as it may seem: Things are not going to be magically fixed (such as clang build), and they are clearly best done upstream. Worse, substituting libraries may take a lot of time, and is likely to become an ongoing pain (not sure I would commit to that personally). A new branding must be provided (and a new name as well) in a "reasonable timeframe" (weeks, maybe months may be acceptable); I don't have the time for that personally, we would have to find someone to do the relevant artwork (shouldn't be long though). Some facilities of Pale Moon's official site may not be accessible anymore. And there will be no user support from upstream. Upstream may still accept patches, but may also lose interest.

That's why I took the pain of doing 1 so far, because I think it to be much more beneficial for everybody. I see 2 really as a last resort.
Comment 25 Olivier Certner 2021-03-30 15:34:26 UTC
Forgot to add something: There is no need to comply with anything if we do not distribute binary packages with official branding.
Comment 26 Olivier Certner 2021-03-30 15:37:56 UTC
Another way of saying that: Use of RESTRICTED would lift any "redistribution" restrictions (since we would not be redistributing binaries).

The drawback here is that Pale Moon is very heavy to build (except on beefy machines).

That would be another way out of 1. if official branding is no more allowed.
Comment 27 Baptiste Daroussin freebsd_committer 2021-03-31 11:47:01 UTC
Yes I understand the motivation behind palemoon, I do not personnally agree with it got the same arguments with other giant projects, bundle libraries are problematique for projects like us, because it has been often the case that we need to patch a wildly used library because their upstream was not aware of how make a really portable version for freebsd (performance, security or any other specific area), but then the bundle take eons to get this patch again.

As I said I trust you and the discussion you had with upstream, the problem is project wise, so at best if it hits the tree it should be as RESTRICTED as you explained, still I am uncomfortable with the history and we would probably need legal consel here. It happended already in the past that there was agreement in the past with an upstream which later turned into a drama, the project should at best keep a trace of that agreement (usually a mail to portmgr is how we kept the trace in the past)
Comment 28 Olivier Certner 2021-04-06 10:20:34 UTC
> I do not personnally agree with it got the same arguments with other
> giant projects, bundle libraries are problematique for projects like us
> (snip)
> but then the bundle take eons to get this patch again.

I understand that as well. But, as said, they have imported and customly modified several dependencies, so, just dropping in the upstream's vanilla code in replacement is probably not going to work anymore. And they take security seriously, with releases done every other month, plus hotfixes when necessary, so I doubt critical security issues won't be handled very quickly.

> As I said I trust you and the discussion you had with upstream,
> the problem is project wise, so at best if it hits the tree it should be
> as RESTRICTED as you explained

The only problem I see with distributing packages is if at some point we are asked to withdraw them. In which case, it is obviously simpler not to distribute them in the first place, although this is the most radical option. I don't know if packages built by the project are copied by downstream projects or mirrors that are not under our control, and if we could be held responsible for that (I really doubt it).

> still I am uncomfortable with the history and we would probably need
> legal consel here.

Getting legal advice would straighten things indeed. I just don't think things are particularly complex (even if they are unfortunately much more than for usual open-source projects), and we have indisputable ways out (if we ever get legal advice, it would be interesting that they confirm this point).

> It happended already in the past that there was
> agreement in the past with an upstream which later turned into a drama

The risk is that, as said, they unilaterally withdraw the permission to distribute binaries and trademarked artwork. But we know that in advance, so can prepare for it. And in this event, we have a very simple immediate workaround: Turn off official branding in the port, which amounts to commenting exactly two lines. This then gives time to establish a new brand.

> the project should at best keep a trace of that agreement (usually a
> mail to portmgr is how we kept the trace in the past)

So, if I understand correctly, you would like a mail to portmgr@ from upstream where they state that our port is OK (I don't think the port files themselves fall under their redistribution license at all; I'll ask for a written confirmation) and that the redistribution license allows us to redistribute pre-built binary packages (which is most probably not needed if RESTRICTED is used, but anyway). In addition, I'll ask for confirmation of the interpretations I wrote above.

Is that OK? Do you see something else to ask? I'll then engage with upstream on the matter.

Thanks.
Comment 29 Olivier Certner 2021-04-06 13:36:44 UTC
Created attachment 223856 [details]
Update to 29.1.1
Comment 30 Olivier Certner 2021-04-06 13:41:28 UTC
(In reply to Olivier Certner from comment #28)

Two corrections to my previous mail.

> releases done every other month

Regular releases are done every month (and hotfixes as security issues require).

> commenting exactly two lines

That's true for the artwork. Unfortunately, we would have to change the name as well, so rename the port, and make other modifications to get rid of 'palemoon'. I can prepare a separate version of the port with these modifications in advance, just in case.
Comment 31 Bill Sorenson 2021-04-06 21:28:34 UTC
I'm just a user here so take my thoughts for what they are. 

I totally agree with @bapt on preferring unbundled libraries wherever possible, but in a case like Palemoon where the upstream has specific requirements and the maintainer has done all the work getting fixes upstreamed and maintaining things such that the "official build" more or less works perfectly fine and things are documented properly, etc, I think it should be allowed in ports. 

Of course the legal issues are another matter. And I'm not in a position to comment too much on that, but it seems like the risks are relatively low since the port could be marked restricted and the packages could be removed from the repo if required, although bapt would certainly know best how much of a headache that would really be in practice. 

I personally mostly use Chromium on FreeBSD, but I find it pretty valuable to have some escape-valve options for browsers around in the event there are issues with Chromium or mainline proper Firefox which have been known to happen from time to time. There is a dearth of browser options on every platform, but particularly on the BSDs.  

I've been building the port here regularly as it has been updated, and done testing on my workstation currently running 13.0-RC5 and have been pleased with the work that has been done. I think it is fantastic.
Comment 32 Olivier Certner 2021-04-29 08:51:08 UTC
Created attachment 224522 [details]
Update to 29.2.0

Update to 29.2.0.

Note that this version doesn't support old plugins for Firefox not ported to Pale-Moon anymore. There are lots of "native" plugins available at https://addons.palemoon.org/.