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.
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.
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.
Created attachment 222399 [details] Version 29.0.1: Patch against the ports tree
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.
testbuild on 12.2amd64 fails in poudriere, see: https://people.freebsd.org/~pi/logs/palemoon-122.txt
(In reply to Kurt Jaeger from comment #5) Adding USES=pkgconfig helps with that failure. Testbuild@work
(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.
(In reply to Kurt Jaeger from comment #7) Build fails on current-amd64: https://people.freebsd.org/~pi/logs/www__palemoon-140-1613240457.txt
(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.
(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.
(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.
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.
Created attachment 222461 [details] Version 29.0.1, -CURRENT build hopefully fixed
Testbuilds@work
Committed, thanks!
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
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
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.
Created attachment 223113 [details] Update to 29.1.0, using GCC 10
testbuilds@work
`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.
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.
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.
(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.
Forgot to add something: There is no need to comply with anything if we do not distribute binary packages with official branding.
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.
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)
> 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.
Created attachment 223856 [details] Update to 29.1.1
(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.
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.
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/.
I remember, old palemoon port used sndio backend and support was upstreamed. Is this backend still availble/can be restored?
Created attachment 225726 [details] 29.2.1 Update to 29.2.1 (minor). Release notes: https://www.palemoon.org/releasenotes.shtml
(In reply to Ivan from comment #33) I never tested that. You can try adding this line: ''' ac_add_options --enable-sndio ''' in 'files/dot.mozconfigure' and then building as usual. If you do it, please report.
(In reply to Olivier Certner from comment #35) Looks like it's works 1. OPTIONS_SINGLE_SOUND= ALSA PULSEAUDIO SNDIO 2. SNDIO_LIB_DEPENDS= libsndio.so:audio/sndio 3. .if ${PORT_OPTIONS:MSNDIO} ${ECHO_CMD} ac_add_options --enable-sndio >> ${DOT_MOZCONFIG} ${ECHO_CMD} ac_add_options --disable-pulseaudio >> ${DOT_MOZCONFIG} .endif It builds and I see sndio backend in about:support, youtube page is very slow though
testbuild newest patch with SNDIO is fine, testrun is fine as well.
Created attachment 226585 [details] 29.3.0 + SNDIO option Update to version 29.3.0 + integration of Ivan's changes for sndio.
Can I also add that I believe the Official branding also allows the use of the upstream's browser "Sync" facility which is a godsend for persons like myself who run multiple OSes on the (same/multiple) machine(s) - getting this port back into the system would return my FreeBSD web-browsing experience to be largely similar to that on GNU/Linux and Windows and for it to matter much less on which OS/machine I am working at the time...
(In reply to Olivier Certner from comment #38) Nice! Do you think we have any chances to land your work in port tree again?
(In reply to Ivan from comment #40) Hi Ivan, Short answer: Currently, I feel it is very much unlikely. But it may be possible to find a way upstream instead, with enough work (the amount of which I don't know; I hope they will be reasonable). Long answer: I was supposed to ask clarifications to upstream on licensing issues, as a blocker on portmgr@'s side. But the lack of clear communication from portmgr@ otherwise, and even more some mails by rene@ seems to indicate that they are not willing much anyway, since they are now saying that bundled libs are a problem, which I tried to challenge but without getting any response so far (not even a "never"). On upstream's side, they would like to be able to test the FreeBSD platform, and want to leverage their infrastructure for that. In effect, they want FreeBSD's build to be integrated in their system instead of a port (which is unlikely to be officially integrated). What I negociated with them is to tackle this before the end of the year, else, they threaten to drop FreeBSD completely. On my side, it's likely I'm not going to be able to work on it before November, but then I should have enough time (unless it's a nightmare; help might be wanted at this point; unless someone can work on it right now, while I can't). So the overall Palemoon's fate on FreeBSD is still uncertain, but there is reasonable hope. Regards.
Created attachment 227606 [details] 29.4.0.2 Update to version 29.4.0.2.
Release notes for 29.4.0.2: https://www.palemoon.org/releasenotes.shtml#v29.4.0.2
Olivier, thanks for your wonderful work. I have been using Palemoon for a long time, and it is very disappointing to see the continuing problems. Earlier I thought "upstream" was being difficult, but now it seems that the difficulties are closer to home. Even more disappointing. Would it help at all if interested Palemoon users would speak up? If so, what is the proper way to do it?
(In reply to Kostas Oikonomou from comment #44) Thanks Kostas. I'm as much as disappointed as you are, probably even more. Initially, I had (perhaps naively) thought that engaging with upstream would be the most difficult part (and indeed it's not without problems), so I would never have thought that portmgr@ would act in such a hostile way. It's true there are unfortunate precedents with Palemoon (based on misunderstandings never cleared because of upstream's aggressive stances), but they don't excuse bad mouthing, spreading FUD, being so resistant to change (even several others have pointed out problems and/or have strongly disagreed) and being so bad at communication. And don't get me start on the Python 2.7 (and then Tauthon) drama. All this in sheer violation of the CoC and portmgr@'s official charter. Besides all that, what happened on their side? Nothing visible, no communication again. It would be great if they could answer on BUNDLE_LIBS=yes (because I've already argued that this is a requirement for Palemoon), but I think chances are low they'll do it. portmgr@ more and more feels to me like a black hole, or /dev/null: Anything sent there seems to disappear without effect. I would love to answer your last two questions, but frankly I'm not sure about what to say. There were several people standing up on the Python 2.7/Tauthon issue, but this apparently lead to nothing except portmgr@ finally officially stating their initially vague and bogus policy (in the sense they don't hear users). There are some users of Palemoon showing up here, but is this going to make a difference? Just FYI, portmgr@ has been the assignee of this bug for a while now; I guess they receive a copy of every comment in this bug; yet, as you can see, nobody has publicly popped in despite of that. For now, I have no time in order to poke them again in private. The only actions I can think of, apart from writing comments in this bug, would be to post something on the ports@ mailing list, or in the forums, or hanging on IRC and trying to spark a discussion, or maybe contact them directly. I'm not sure which ones are appropriate, if any.
(In reply to Kostas Oikonomou from comment #44) Just in case this wasn't clear enough (because of the previous comment, where I briefly talked about the contention with portmgr@), there is currently anyway no other choice than to work with upstream now, since they have threatened to remove all BSD support at the end of the year (the other choice is a fork; I don't have the time nor the interest, but again, if others want to step in, be my guest). There is no point in rushing for a port as long as this is not solved. Once it is (hopefully), we can come back and push for the port (although, by then, there will be less incentives to do so, and only one advantage will probably remain: Better exposure to the general public).
Created attachment 228482 [details] 29.4.1 Update to 29.4.1. Release notes: https://www.palemoon.org/releasenotes.shtml#v29.4.1 Due to a conflict with a third-party over licensing, upsteam has removed public access to source repositories and now provides a full source archive on each release only.
Created attachment 229396 [details] 29.4.2 Update to 29.4.2. Release notes: https://www.palemoon.org/releasenotes.shtml#v29.4.2
I've had some issues building the 29.4.2. At minimum it looks like some file paths from the source dist changed. There's a subdirectory now.
(In reply to Bill Sorenson from comment #50) Hi, did you use the new ports patch above, or did you tweak an old version manually? Because, yes, several things changed after 29.4.0 (there is only a single archive now, instead of two; some paths changed, etc.). If you still have problems with the latest patch (which would be very strange, since this is typically the kind of error I would have seen when building), could you please be more specific and post the exact error?
I've check and my Makefile etc match the latest patch here. The first issue is the Makefile and distinfo expect the source tarball named palemoon-29.4.2-source.tar.xz but on the server it is actually palemoon-29.4.2.source.tar.xz. Once I've dealt with that I hit "=> SHA256 Checksum OK for MoonchildProductions/palemoon-29.4.2.source.tar.xz. ===> Missing license file for MPL20 in /usr/ports/www/palemoon/work/LICENSE *** Error code 1" Because the actual source path is ports/www/palemoon/work/palemoon-source
Yeah, some things changed in 29.4.2.1. http://archive.palemoon.org/source/ I'm afraid I can't get it to build on 14 though with USES+= compiler:gcc-c++11-lib - I can USE_GCC directly but the result is crashtastic. This seems a common problem on derivative browsers... buildable with GCC but unusable.
(In reply to Bill Sorenson from comment #52) Ok, so they just changed the filename, as well as the content, after I did the patch... I guess you had to overrode the checksum. I'll see that tomorrow. (In reply to tod.jackson from comment #53) Never tested on 14. Which error are you getting? USE_GCC alone won't work, code must be built and linked against libstdc++ (and GCC must be 10 at most, you can try 9 if in doubt). With Palemoon, I've always seen the *opposite* problem, namely, it could not build with clang++/LLVM initially. After I fixed that upstream, I couldn't prevent it to crash at run, much more investigation would have been needed and upstream was uncooperative on the matter. I've never had these problems with a GCC + libstdc++ build.
Testing now, the attached version does not have the rename problems in 29.4.2.1, so don't worry. Did these other guys try to upgrade too? IIRC it gets pretty far into the build before error, so will get back to you on that.
Ah, I had a cached distfile. They did rename it. >.>
palemoon/work/pmbuild/ipc/chromium/Unified_cpp_ipc_chromium1.cpp:11: 34:07.06 /usr/include/c++/v1/string: In member function 'void std::__1::basic_string<_CharT, _Traits, _Allocator>::reserve(std::__1::basic_string<_CharT, _Traits, _Allocator>::size_type) [with _CharT = short unsigned int; _Traits = base::string16_char_traits; _Allocator = std::__1::allocator<short unsigned int>]': 34:07.08 /usr/include/c++/v1/string:3359:1: error: inlining failed in call to 'always_inline' 'void std::__1::basic_string<_CharT, _Traits, _Allocator>::__shrink_or_extend(std::__1::basic_string<_CharT, _Traits, _Allocator>::size_type) [with _CharT = short unsigned int; _Traits = base::string16_char_traits; _Allocator = std::__1::allocator<short unsigned int>]': function body can be overwritten at link time 34:07.12 3359 | basic_string<_CharT, _Traits, _Allocator>::__shrink_or_extend(size_type __target_capacity) 34:07.12 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 34:07.13 /usr/include/c++/v1/string:3344:23: note: called from here 34:07.13 3344 | __shrink_or_extend(__target_capacity); 34:07.13 | ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~ I have not changed my CFLAGS
Created attachment 229589 [details] 29.4.2.1 Update to 29.4.2.1. Release notes: https://www.palemoon.org/releasenotes.shtml#v29.4.2.1 The update upstream is very minor. As reported above, the previous patch (for 29.4.2) is now unusable since upstream rebundled 29.4.2 but differently after I released it.
First, a note to correct what I said in comment #54: Palemoon has to be built with GCC (that was correct) but against LLVM/libc++ (and *not* libstdc++), this is the combination that I know is working and that I've been using. (In reply to tod.jackson from comment #57) The prefix /usr/include/c++ and the occurences of std::__1 seem to indicate the use of libc++ headers. And I think the phrasing of the error indicates the use of GCC. That's good. Now, for the error itself: "error: inlining failed in call to 'always_inline' ... __shrink_or_extend ... : function body can be overwritten at link time", I think it indicates that this function is somehow exported and thus another definition could be linked into the library/executable, which then would not match the inline one that is used in "reserve()" (and "shrink_to_fit()"). As to why this happens, for now I don't know. A diff with 12's source shows that this method is new. It is now in 13 as well, following the import of LLVM 12.0.1. Probably a bug there or in GCC. Which version of GCC are you using?
(In reply to Olivier Certner from comment #59) gcc10-10.3.0
^Triage: portmgr doesn't need to be the default assignee here. Request explicit feedback from portmgr regarding bundling dependencies. It it well-known that many ports forgo un-bundling dependencies, particularly those that are excruciatingly complex, bundle custom/tailored/patched dependency versions, or naturally vendor those dependencies for specific reasons where the ports versions are unsuitable or incompatible. @everyone If there are any remaining concerns or decisions to be made, please make those explicit such that we can request feedback from any necessary folks/teams as well @Reporter (Olivier) Could you please provide an update on the 'readiness' of the latest attachment, in particular with respect to, and confirming: - Latest upstream version - QA (poudriere) across all supported FreeBSD versions and tier-1 architecture - GCC remaining as build requirement (and why)
Hi Kubilay, Thanks for popping in. To first answer your questions: 1. The latest patch for 29.4.2.1 is indeed upstream's latest version. 2. QA: Makefile linted long ago, I've re-run portlint and I'll make a few minor fixes to the Makefile. As for builds, there have not been recent poudriere builds on FreeBSD infrastructure that I know of. Is it possible to request some? About tier-1 architectures, aarch64 is not supported. The port builds on amd64 and i386, but for the latter I don't think it is possible to build on a real i386 machine, an amd64 box with 32-bit libs is probably necessary (linking should take more than 4GB per ld process). Recently, I've only built on 12-STABLE myself. Very recent reports by users above indicate some failure on CURRENT, which is likely to manifest itself on 13-STABLE as well (after the last LLVM/clang update this summer). I have very little time currently, I plan to build on 13-STABLE myself soon, but if someone wants to help, he's welcome. 3. GCC is a mandatory requirement, because this is only what upstream supports and the only thing that currently works. Also, we'll lose official branding if we don't use it. At start, I tried to get Palemoon working with LLVM/clang++, but the produced binaries simply crashed, and light investigations did not reveal anything obvious. I don't precisely remember now, and I don't know the actual amount of work it would take. Anyway, I simply don't have the time currently and it's a priori unlikely that upstream will accept the eventual patches to build with LLVM/clang (when I brought the subject on the table months ago, I was very strongly told not to do it). As for bundled libs, I explained several times above why we cannot get away with ports dependencies (API changes notably). This is a hard requirement (I don't want/can't maintain a fork). There is also the licensing concern (long discussion above in this PR, in particular with bapt@). We can set RESTRICTED to solve it for now. In a discussion with upstream during summer, they stated they wanted most FreeBSD changes integrated into their codebase and build system, or they'll lose interest, and possibly remove all BSD-related compatibility code. So the long term fate of this port is mostly dependent on this process, which I probably won't start before end of this year. So, pushing a port before that appears to me as premature.
Created attachment 230118 [details] Update to 29.4.3. Release notes: https://www.palemoon.org/releasenotes.shtml#v29.4.3 (Didn't have time to do something about the broken build on CURRENT reported above yet. You might want to try building this new version, but should not expect miracles.)
BUNDLE_LIBS=1 seems to be an unused variable.
I'm a bit confused by the comment > We require GCC (see also GCC_DEFAULT below), but we need to make sure that there are no runtime dependencies to libstdc++, i.e., that libc++'s headers and libraries are used during compilation and link. It is a quite unusual combination when GCC uses libc++, why do we want this? I believe, this is what causes failures when building on CURRENT. Another small problem with the port is that you need .include <bsd.port.post.mk> at the end of Makefile instead of .include <bsd.port.mk>
I think, as Olivier puts it in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251117#c62, upstream mandate using a GCC compiler and also using (for the licence/permission to use the "Official" branding, except for particular {agreed?} exceptions necessary to build on a particular platform) their carefully curated own bundled versions of libraries - and everything must be linked to libc++ (as I understand it the C++ libraries that Clang - and thus FreeBSD uses by default) as things just go boom if some parts get linked with libstdc++ (which GCC uses by default) and others are linked to libc++ ...
Moin moin Feel free to add this port to the tree. portmgr@ does not see a reason to block it [1]. Please update the patch to match the current porters handbook's recommendations, and push it in. mfg Tobias (with hat portmgr) [1] of course, if the hoop-jumping demanded by upstream becomes too much, it will be removed again.
(In reply to Tobias C. Berner from comment #67) Hi, Current questions/problems before it is added to the tree, the first is for you: 1. This port depends on Python 2.7 to build (only). So is this now OK? Else it depends on Tauthon, which should be imported. Or it needs changes to build Python on the fly before launching the main build process. Has something been accepted/decided, and what? 2. Also, there seems to be a build problem on recent FreeBSD versions after the upgrade of LLVM/clang in base. If someone wants to launch an exp-run, it doesn't hurt, but I bet he'll stumble on the error reported above. Sorry if 2. isn't yet fixed due to lack of time on my part currently (and it may be hard to fix, I'll have to experiment). Thanks.
for the question 1, go on with python 2.7 from ports.
(In reply to Baptiste Daroussin from comment #69) Ok, noted. Thanks a lot for your help.
Created attachment 231756 [details] 29.4.3 + GCC/libc++ 13 compilation problem workaround After an upgrade to get clang/libc++ 13, and a couple of hours of investigation, I'm convinced this is a bug, probably in libc++ rather than GCC. This is going to require more investigations (bugs to open, discussions, etc.). Fortunately, in the meantime, I found a workaround (which, according to GCC's documentation, should not work...) as an additional patch included in the port (adding an 'inline' before an explicit template instantiation, for those interested). So please test and report. Thanks.
Hi Gleb, (In reply to Gleb Popov from comment #64) > BUNDLE_LIBS=1 seems to be an unused variable. It's a variable indicating that the ports produces shared libraries that must not actually be shared with other ports. See the porters handbook or Mk/bsd.port.mk. (In reply to Gleb Popov from comment #65) > It is a quite unusual combination when GCC uses libc++, why do we want this? I > believe, this is what causes failures when building on CURRENT. On old tests I did, executables produced with clang++ would simply crash at launch. Moreover, upstream does not support clang++ for compilation. So GCC is needed. On the other hand, linking to libc++ is required (using libstdc++ is fragile at best, because of dependency on 'harfbuzz' => 'graphite2', linking to libc++; in practice, this combination crashes). So there is no way out, short term at least. >Another small problem with the port is that you need > >.include <bsd.port.post.mk> > > at the end of Makefile instead of > > .include <bsd.port.mk> I've changed that in the new patch, although the old stanza seems to work as well. Thanks.
(In reply to Olivier Certner from comment #71) Bug already fixed upstream: https://reviews.llvm.org/rGae6ebd3af525c23c6216b76dd28a282790dce78f https://reviews.llvm.org/D115656 As for the workaround, it may also simply work without contradicting GCC's documentation if nothing uses the string16 type. Didn't check.
Created attachment 231786 [details] 29.4.4 Update to 29.4.4 Release notes: https://www.palemoon.org/releasenotes.shtml#v29.4.4 Had missed this release since it does not appear on their release engineering page (but it does on the releease notes one).
(In reply to Olivier Certner from comment #74) testbuild on 13.0amd @work
(In reply to Kurt Jaeger from comment #75) This build-failure happens: [...] echo export NM=\"/usr/local/bin/nm\" >> /wrkdirs/usr/ports/www/palemoon/work/palemoon-source/.mozconfig cd /wrkdirs/usr/ports/www/palemoon/work/palemoon-source && /usr/bin/env PATH=/usr/local/libexec/ccache:/wrkdirs/usr/ports/www/palemoon/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin ./mach configure ./mach: 18: Syntax error: newline unexpected (expecting ")")
(In reply to Kurt Jaeger from comment #76) Cause is misapplication of the diff, so I'll fix and restart.
Just to avoid duplicated efforts, I took the patch, applied some cosmetic changes and am currently running poud testport on 14-CURRENT.
(In reply to Gleb Popov from comment #78) I'm currently testbuilding in poudriere on 12.3amd64.
(In reply to Kurt Jaeger from comment #79) build log at https://people.freebsd.org/~pi/logs/palemoon-123.txt Fails with: 0:00.94 STOP! /wrkdirs/usr/ports/www/palemoon/work/palemoon-source/platform/old-configure.in has changed, and your configure is out of date. 0:00.94 Please rerun autoconf and re-configure your build directory. 0:00.94 To ignore this message, touch "/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/platform/configure", 0:00.94 but your build might not succeed. 0:00.94 gmake[4]: *** [Makefile:90: /wrkdirs/usr/ports/www/palemoon/work/palemoon-source/platform/configure] Error 1 0:00.94 gmake[3]: *** [/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/platform/config/rules.mk:493: default] Error 2 0:00.94 gmake[2]: *** [/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/client.mk:406: realbuild] Error 2 0:00.94 gmake[1]: *** [client.mk:164: build] Error 2 0:00.98 0 compiler warnings present. *** Error code 2
The build for 14-CURRENT finished successfully, but 12.3-RELEASE failed with different error: 0:00.27 gmake[4]: Entering directory '/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/pmbuild/palemoon/installer' 0:04.53 Executing /wrkdirs/usr/ports/www/palemoon/work/palemoon-source/pmbuild/dist/bin/xpcshell -g /wrkdirs/usr/ports/www/palemoon/work/palemoon-source/pmbuild/dist/bin/ -a /wrkdirs/usr/ports/www/palemoon/work/palemoon-source/pmbuild/dist/bin/ -f /wrkdirs/usr/ ports/www/palemoon/work/palemoon-source/platform/toolkit/mozapps/installer/precompile_cache.js -e precompile_startupcache("resource://gre/"); 0:04.90 Bootstrap allocator: malloc_init_hard stats: 0:04.90 Bootstrap allocator: 1184 bytes requested, 4096 allocated 0:05.15 too much recursion 0:05.21 Traceback (most recent call last): 0:05.22 File "/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/platform/toolkit/mozapps/installer/packager.py", line 423, in <module> 0:05.22 main() 0:05.22 File "/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/platform/toolkit/mozapps/installer/packager.py", line 417, in main 0:05.22 args.source, gre_path, base) 0:05.22 File "/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/platform/toolkit/mozapps/installer/packager.py", line 167, in precompile_cache 0:05.22 errors.fatal('Error while running startup cache precompilation') 0:05.22 File "/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/platform/python/mozbuild/mozpack/errors.py", line 103, in fatal 0:05.26 self._handle(self.FATAL, msg) 0:05.26 File "/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/platform/python/mozbuild/mozpack/errors.py", line 98, in _handle 0:05.26 raise ErrorMessage(msg) 0:05.26 mozpack.errors.ErrorMessage: Error: Error while running startup cache precompilation 0:05.27 gmake[4]: *** [/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/platform/toolkit/mozapps/installer/packager.mk:41: stage-package] Error 1 0:05.27 gmake[4]: Leaving directory '/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/pmbuild/palemoon/installer' 0:05.27 gmake[3]: *** [/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/platform/toolkit/mozapps/installer/packager.mk:92: make-package] Error 2 0:05.27 gmake[3]: Leaving directory '/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/pmbuild/palemoon/installer' 0:05.27 gmake[2]: *** [/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/platform/toolkit/mozapps/installer/packager-uxp.mk:14: make-archive] Error 2 0:05.27 gmake[2]: Leaving directory '/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/pmbuild/palemoon/installer' 0:05.28 gmake[1]: *** [/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/platform/../palemoon/build.mk:9: package] Error 2 0:05.28 gmake[1]: Leaving directory '/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/pmbuild' *** Error code 2
Sorry for the delay. I do not reproduce the errors you report on a recent 12.3-STABLE. (In reply to Kurt Jaeger from comment #80) I've never seen that error about old-configure.in having changed after the configure phase has been run (and the log seems to indicate that old-configure was refreshed from old-configure in directory platform/). On a successful build, I strangely have an empty platform/configure (although there is a configure.in) and platform/old-configure is in place and seems valid. Don't know much about poudriere, but could it be that it messes with the timestamp of files between build phases? Could you relaunch the build just to see if this was something transient (e.g., due to a race condition in the build)? (In reply to Gleb Popov from comment #81) Never seen this error either. Seems to be a JS stack overflow. On which architecture are you building? Is it 32-bit on amd64? Thanks.
(In reply to Olivier Certner from comment #82) It was amd64 too. Are you building using poudriere?
(In reply to Gleb Popov from comment #83) No, just using plain 'make' in the ports dir.
(In reply to Olivier Certner from comment #84) Would you mind building your port under poudriere jail? It is quite easy to setup and may help you to reproduce the problem.
(In reply to Gleb Popov from comment #83) Could it be that some resource limits are set too low by poudriere? In Kurt's build log, I see, e.g.: data seg size (kbytes, -d) 33554432 stack size (kbytes, -s) 524288 which are also my current settings. Do you have the same ones?
(In reply to Gleb Popov from comment #85) Going to do that.
(In reply to Gleb Popov from comment #85) I do not reproduce either problem in poudriere, building all packages from scratch from a fresh checkout of ports (main) on a 12.3-RELEASE userland in jails (as built by poudriere; host kernel is a recent 12.3-STABLE). (As a side note, this made me notice a problem when building using ccache, which I'm going to fix; a plain build without ccache works.) So not sure how to proceed from here. Do you have something unusual in your poudriere configuration? On my side, for this build, I did not have any 'make.conf' nor non-default port options. I only deactivated TMPFS and I'm building as non-root (in 'poudriere.conf').
(In reply to Olivier Certner from comment #88) Ok, let's commit this and see, if this problem would manifest itself on the package building cluster. Please, post the final version of the patch, that you want to get in, or let me know if the current one is fine to commit.
(In reply to Gleb Popov from comment #89) Ok. Let me try to fix the ccache problem and liaise with upstream to inform them we are going to produce packages (I'm short on time so did not proceed to fully integrating into their build system in January as initially promised, and delayed that to next April, so they might change their stance). Also, perhaps portmgr@ wants RESTRICTED set in any case? Thanks.
Upstream has plans to remove BSD-related-support. They've already dropped support for MacOS a few months ago, and are planning to proceed with the rest (the extent of which I don't know precisely). So they would like to be sure that the initial issues that prevented the port to go in are not going to pop again later before considering revising these plans. (In reply to Kubilay Kocak from comment #61) (In reply to Tobias C. Berner from comment #67) > It it well-known that many ports forgo un-bundling dependencies, > particularly those that are excruciatingly complex, bundle custom/tailored > patched dependency versions, or naturally vendor those dependencies for > specific reasons where the ports versions are unsuitable or incompatible. Is this officially backed-up by portmgr@? > portmgr@ does not see a reason to block it [1]. What did lead to this decision after so much time? Only the arguments presented here? Changes of plan from portmgr@ (regarding BUNDLE_LIBS, or something else)? Is this decision perennial? Sorry for being so procedural, but I need to now in order to avoid future problems and drama as much as possible, and because importing this probably makes no sense if upstream indeed drops BSD support.
(In reply to Olivier Certner from comment #91) That's fine to ask, and the reason its difficult to get a grasp of things is that its challenging to be entirely precise and entirely objective about the issue as it relates to 'what is the right thing to do'. With hard and fast rules this is easy, but there's multiple considerations here (and with other types of issues and questions) too, which are worth enumerating. Note that the perspective below is more 'lets try to eat our cake and eat it too as much as possible', or 'how much of the best of all worlds can we have', rather than 'this is the one rule for this exact situation with no exceptions'. The following are "desirable or relatively uncontroversial statements/attributes' that all trade of against each other", that different people and contexts value things differently, and over time. Keep that in mind. - We want users to have easy access to as much software in ports as possible - We want packages/ported software to be of high quality and maintained well - It takes contributor effort/time for all of this to occur. - It's 'nice' to bias action over stagnation, vs other tradeoffs. - We want this to take as little effort as possible, vs other tradeoffs - There are tradeoffs between bundled and unbundled dependencies - There's a defacto standard, not just to depend on port versions of dependencies, but unbundle them where they are bundled. Most stuff in the tree is 'of this form'. - There is 'variable' effort involved in unbundling dependencies depending on project, complexity, skill, etc. From trivial to 'excruciatingly complex'. - Some things in ports are not un-bundled because: * the effort required to do this is too high, or not worth it, OR * we cannot manage to stay up to date or at a high quality if we did that, OR * people just didn't do it, and we don't have a strict or enforced QA policy or capability or culture to require/demand it, OR * the ecosystem tends not to work that way (see nodejs, etc) On the last consideration, there's additionally: - should we 'deviate from upstream and community norms and conventions', OR - stay as close to upstream as possible, AND - why or why not? (there are tradeoffs here too), AND - how does this decision tradeoff against everything else? All of the above are not palemoon / this issue specific, and I've tried to stay away from 'opinions' (mine or otherwise). To answer your question, specifically, in my opinion: > What did lead to this decision after so much time? Only the arguments > presented here? - Any 'main' issues raised in this issue that might have *clearly* (rules) been reason block a port (license, branding, etc), have been sufficiently (if ambiguously) expressed and are not of *sufficient concern* or *remaining ambiguity* to warrant people wanting to be on the hook publicly for blocking it. Had portmgr not explicitly been asked for feedback, we may not be in the current position. The re-triage in comment 61 was *exactly* an attempt to 'demuddy the water', given the issues long history and very very verbose nature, which contributes substantially to stagnation generally, and bring the issue to a head explicitly. Either people were going to raise remaining issues, or it was going to move, one way or another. All of the above is the best context and detail I can provide. I hope its helpful. Last update is we're waiting on a patch and feedback from them is pending (maintainer feedback ?) This issue now needs: 1) A final and thoroughly QA'd patch (needs-patch) (needs-qa) 2) A final review after attachment here (needs-qa) 3) A committer to be committed Note 1: *Anyone* may provide (1) and (2). Note 2: *Any* interested committer may *at any time*, self assign the issue to coordinate its resolution. I suggest everyone focuses only on (1) and (2) at the present time.
(In reply to Olivier Certner from comment #91) Moin moin Time proved that we cannot get rid of python 2.7 in a timely manner, as it is most notably still required as build dependency for the other major web-browsers/-kits. As those are allowed to use python 2.7 *during build time*, so should a new port. Bundled libraries are bad, but again, the other web-browsers have plenty of precedent in that area. Aim to "remove what is possible, keep what is necessary". So those are not blockers anymore. As for upstreams history and as it seems their future plans, that is completely in their hands. mfg Tobias / portmgr
Hi, Unfortunately, I have bad news. Upstream and I have ceased "collaboration". Details on this development are available at the end. It is now practically certain that they'll remove FreeBSD compatibility code, maybe as soon as the next release (29.5). In any case, I advise users to start considering alternatives to this port now (which might be running the official Linux's version on Linux emulation, if that works; didn't test). I'm updating the patch so that official branding is disabled by default. Anybody can re-enable it for its own builds (they must just remain private). As a service to existing users, if and as long as new versions continue to build and work, I'll prepare patches for them. Including the port in its current form in the ports tree has become irrelevant. The browser should be rebranded and a new name devised before this can be considered again. If some people want to maintain a fork of Pale Moon's code base, first thing will be to assess what needs to be patched to make the code run again on FreeBSD once they have removed compatibility. The extent of this work is unclear to me, but given we have in the ports tree most of their third-party libraries, patches for them are likely to be reusable. I can provide minimal support for that in the form of what I've learned and done so far, FWIW. However, I don't plan to lead or even participate more than very occasionally to such an effort, since my own priorities have been shifting. I'm now much less interested in a customized GUI browsing experience than in modern web support, large scale security scrutiny and cooperative upstream development. Web compatibility has noticeably degraded in Pale Moon during the last year because lots of sites have been switching to WebComponents or some unsupported features of more recent ES standards. Upstream has been working on these during this time, so at least they may be back on track on this front, perhaps as soon as the next release. Unfortunately, as for genuine cooperation, they're still not cutting it. I would like to thank all people that supported this effort (and upstream does the same), and especially ports management's members and ports committers who have provided support and guidance. The effort was at times painful, but still rewarding in some parts. I'm sorry I could not make it work. Hopefully some of the people involved have learned a bit or two about communication, handling user requests or the tradeoffs involved in accepting a port in the ports tree. Regards. ----------- I resumed discussion with upstream at the time indicated in the comments above, i.e., after tcberner's comment about portmgr not blocking import anymore, my fix to the port's recent compilation problem and further discussion indicating that the port was in a good-enough shape to be included. The owner, Moonchild, said that it was a little late, since they were about to remove all BSD-specific code. He wanted to be 100% certain that Ports management would completely accept some Pale Moon's peculiarities, such as bundled libraries, and not just "tolerate" them, temporarily or not, before possibly revising its plans. That's why I asked some more questions here and relayed the answers (I thank again both tcberner@ and koobs@ for these). But apparently, they were not enough for him, he wanted an official stance for Pale Moon (that bundled libraries are OK), by fear of the port being arbitrarily removed later. At the same time, he started to exhibit paranoid behavior, first by questioning the timing of the possible inclusion in the ports tree (why would I and ports management "suddenly" make progress on this issue?). I thought he was saying that because I came with news just as he was about to remove BSD-specific code, which of course I didn't know. I did know about their intention to do it, but not about any precise execution plan. Moreover, I had sent a message around Christmas saying I was not able to work on including FreeBSD support into their own build system before the end of the year, as I had committed to initially. I never received any response, which I took to mean that they were too busy (working on web compatiblity, on a MPL license violation, etc.). But I was wrong about his fears: He was in fact thinking that we might have contacted him again after he had sidelined Matt A. Tobin because of divergences, taking advantage of the situation to solve a possible personal problem. Given some other comments he had made, I thought I could reason him and show him he was completely wrong and paranoid, but this proved to be a mistake. On my side, I stated I was prepared to commit to more work on Pale Moon and for 2 years, while I didn't have a precise work schedule for them for business reasons. Also, I wanted more reassurance that the collaboration could be perennial before engaging in this. In this respect, I voiced several concerns, especially asking up to which point he was actually backing or not Tobin in some of its violent reactions (because that actually jeopardizes the possibility to recruit co-maintainers or to find successors when I'm not here anymore, besides threatening our existing relationship), and what his take on 2018's drama with OpenBSD was after he pretended that fearing redistribution license's change on a whim was paranoia on our side (irrational behavior on their part had already happened and done a lot of damage). Finally, I also went on with detailing some possibilities technically and in terms of organization as we would work forward. Unfortunately, he could not cope with my message nor recognize any of their problematic behaviors. He mistook my own concerns as objections to its quality assurance's concerns, which they had nothing to do with. Finally, he did not respond to any of my detailed proposals, instead just saying that we had no more basis for collaboration. Which I totally agree with: If they are not able to even hear other's concerns (not even speaking about respecting them), to inform them on their actions and cannot recognize how they could harm perennial collaboration, then I refuse to invest more time in this project. I don't think they know what genuine collaboration really is (or perhaps I'm guessing too well what they actually mean by "collaboration"). All these were private messages, which I intend to keep private. I might reconsider if they insist on challenging my summary of events though.
Created attachment 232303 [details] 29.4.4, unofficial branding
Created attachment 232774 [details] 29.4.5 (unofficial branding by default) 29.4.5 So it seems we are "lucky", since this release exists only due to delays in 30 (in part due to Tobin's rage quit fallout). I don't expect there will be other ones in the 29.x series, and probably the next version 30 will have BSD compat code dropped. So don't forget to have a migration plan to some other browser.
Created attachment 232868 [details] 29.4.5.1 Performance fix update
I read the posts made at around 2728 March by Moonchild on the PM forum. He seems apologetic for Tobin's behavior. Is that an indication that maybe support for FreeBSD won't be removed?
Here is something from my IRC logs that may confirm the status of BSD in Pale Moon despite what Moonchild has been saying since I was kicked to the curb. It does not show me in the best light but it happens to be true. Mar 02 03:23:52 <Moonchild> NewTobinParadigm: I'm dropping FreeBSD on the floor. I'm really just done with it. Especially if the one that is supposed to liaise between a reluctant platform team and use is leveraging the OpenBSD BS that doesn't even apply to their platform or their team just to keep the opening to build the way they want anyway. Mar 02 03:24:29 <Moonchild> If you insist you can still talk to them and do stuff independently but I think that's a bad idea as well, if we can't even keep one line ourselves. Mar 02 04:49:46 <NewTobinParadigm> no i agree Mar 02 04:50:09 <NewTobinParadigm> but like i said in the PM.. we can put it in the drawer if someone else pops up Mar 02 04:50:27 <NewTobinParadigm> or maybe one of the shitter bsds comes to call Mar 02 04:51:36 <NewTobinParadigm> i just think IF we ever were to allow BSD in the future it needs to be done from the perspective of what is needed now not the compromises from 10-15 years ago hacked and rehacked and never properly tested by core mozilla Mar 02 04:55:11 <NewTobinParadigm> Moonchild Mar 02 04:55:36 <Moonchild> Yes i agree Mar 02 04:55:51 <Moonchild> and he clearly stated that he wasn't going to do that anyway somewhere in his essay Mar 02 04:55:56 <Moonchild> so fuck it. Mar 02 04:56:42 <NewTobinParadigm> it is amazing how he went all out on the anti-Tobinism all without me saying a word since last year Mar 02 04:56:53 <NewTobinParadigm> shattered his own illusion without a word from me Mar 02 04:57:09 <Moonchild> the overly long post really pissed me off, by the way. it's cleverly written, and clearly Olce is a good conversationalist, but I can't rhyme it with what's needed to cooperate Mar 02 04:57:50 <NewTobinParadigm> yeah but to me it was basically.. sun-glasses point by point with charmcitycrab pointlessness Mar 02 04:58:22 <Moonchild> if he can take a long time to compose what he did, he should also be willing to put in the legwork code-wise. unless that's actually not his forte in which case he can't do what he says he wants to Mar 02 04:58:41 <Moonchild> so there are so many approaches to it that all come to the same conclusion, and I'm just dropping it. period. Mar 02 04:58:52 <NewTobinParadigm> target operating systems need to be maintained by those familiar with it Mar 02 04:59:03 <Moonchild> exactly Mar 02 04:59:11 <Moonchild> and I was very clear that was needed Mar 02 04:59:40 <Moonchild> which resulted in a barf of sociopolitical BS and semi-covered attacks on all of us. Mar 02 04:59:54 <NewTobinParadigm> you made an absolutely good play by including my contributor roll with my community interaction stepback it encouraged him to not only question it but attack harder Mar 02 04:59:56 <NewTobinParadigm> masterful Mar 02 05:00:06 <NewTobinParadigm> role* Mar 02 05:00:21 <Moonchild> Like I said I was still probing to see. Mar 02 05:00:33 <NewTobinParadigm> Probe Complete.
(In reply to Matt A. Tobin from comment #99) A days prior as well.. Feb 25 07:41:42 <NewTobinParadigm> Moonchild: I am not at all willing to work with any BSD without a commitment from them to actually work with us. I also want to remove ALL BSD support from gre as it stands today and have THEM add BACK support in a more proper way ala SunOS.. The issues of Pale Moon branding is no longer my public consern but they shall not have any permission to use BinOC branding and associated applications. Put their fuckin money where their mouth is Feb 25 07:41:42 <NewTobinParadigm> and re-do freebsd support from the ground up or fuck off and die like the communists they are. Feb 25 07:42:45 <NewTobinParadigm> In my opinion, OlCe1 has already proven to not be a serious contender for this endeavor. Someone else must lead this charge. Someone who is reasonable. Feb 25 07:43:27 <Moonchild> Oh I agree. I'm just still probing to see what's going on. Feb 25 07:43:41 <NewTobinParadigm> i figured you would for the most part. Feb 25 07:43:57 <NewTobinParadigm> Just wanted to make sure there was a current crystallized statement from me. Feb 25 07:44:07 <Moonchild> And he himself said he's not sure whether all the BSD code paths are even necessary, so that aligns exactly with what you would want. Feb 25 07:44:29 <Moonchild> But I'm not pouring all that out in one go. I have to know details from them. Feb 25 07:45:00 <NewTobinParadigm> I believe they once were .. 15 years ago.. in general i think that is true and our plans to prefer XP_UNIX except where it is necessary to get more specific is a good one for our general stability and code clarity Feb 25 07:45:15 <Moonchild> Yup Feb 25 07:45:48 <NewTobinParadigm> take the Tobin Factor out of the equation and it rings of actually being fair and proper to all unixes I think Feb 25 07:45:48 <Moonchild> I'm just letting them know a compromise and BSD support in our tree is possible -- but haven't said anything about HOW that's going to be done. Feb 25 07:46:06 <NewTobinParadigm> except mac :P Feb 25 07:46:10 <NewTobinParadigm> which is fake-unix Feb 25 07:46:14 <Moonchild> Mac can fuck off Feb 25 07:46:17 <Moonchild> so can OpenBsd Feb 25 07:46:40 <Moonchild> i will ONLY support freeBSD because all the other ones have been excessively hostile Feb 25 07:47:01 <NewTobinParadigm> i'd be willing to facilitate openbsd if one person one user was man enough to do their best and not get railroaded by their bsdpeers Feb 25 07:47:01 <Moonchild> not in the least by keeping dragging in that one openBSD github issue -every-fucking-where-they-could Feb 25 07:47:07 <Moonchild> and that was unnecessary Feb 25 07:47:16 <Moonchild> No, OpenBSD can fuck off Feb 25 07:47:22 <Moonchild> I will not have it after that Feb 25 07:47:47 <Moonchild> and they are being special snowflakes anyway that will require a lot of extra complexity. just look at the code in our tree. Feb 25 07:47:54 <Moonchild> so no, it's not feasible Feb 25 07:48:08 <NewTobinParadigm> openbsd has some very strange oddities internal to them that freebsd doesn't Feb 25 07:48:10 <NewTobinParadigm> i do know that Feb 25 07:49:32 <NewTobinParadigm> it is such a shame that xp users have ruined the "xp" designation cause to me "xp" as cross platform is so important to me Feb 25 07:50:32 <athenian200> Yeah, I don't think we should support OpenBSD under any circumstances. Sorry I've not been paying much attention lately, been focused on the news a lot. Feb 25 07:50:55 <Moonchild> it's fine. Feb 25 07:51:09 <NewTobinParadigm> three core libs that must never be system imo for us is nspr nss and libpng the rest is negotiable as I see it though the bar for justification remains high Feb 25 07:51:28 <NewTobinParadigm> unless you can think of one Feb 25 07:51:32 <NewTobinParadigm> likely cairo as well Feb 25 07:51:46 <Moonchild> cairo was fucked over recently too Feb 25 07:51:52 <NewTobinParadigm> I remember Feb 25 07:52:12 <NewTobinParadigm> and it will never be solved because of the way Mozilla has bypassed fucked up code paths Feb 25 07:52:32 <Moonchild> exactly Feb 25 07:53:19 <NewTobinParadigm> luckily if freebsd gets their shit together they should be less anxious about the netscape libs.. cause since we got nss-gyp we can keep pace with esr at the very least.. they can't arguge with that and hold water
Created attachment 233707 [details] 29.4.6 Release notes: https://www.palemoon.org/releasenotes.shtml#v29.4.6
I'll try to testbuild.
(In reply to Kurt Jaeger from comment #102) https://people.freebsd.org/~pi/logs/palemoon-130.txt Testbuild with poudriere, fails very early with: cd /wrkdirs/usr/ports/www/palemoon/work/palemoon-source && /usr/bin/env PATH=/wrkdirs/usr/ports/www/palemoon/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin ./mach build 0:00.25 /usr/local/bin/gmake -f client.mk -s 0:00.87 Adding client.mk options from /wrkdirs/usr/ports/www/palemoon/work/palemoon-source/.mozconfig: 0:00.87 MOZ_OBJDIR=/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/pmbuild 0:00.87 OBJDIR=/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/pmbuild 0:00.87 FOUND_MOZCONFIG=/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/.mozconfig 0:00.88 Generating /wrkdirs/usr/ports/www/palemoon/work/palemoon-source/platform/configure 0:00.88 Generating /wrkdirs/usr/ports/www/palemoon/work/palemoon-source/platform/js/src/configure 0:00.94 STOP! /wrkdirs/usr/ports/www/palemoon/work/palemoon-source/platform/old-configure.in has changed, and your configure is out of date. 0:00.94 Please rerun autoconf and re-configure your build directory. 0:00.94 To ignore this message, touch "/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/platform/configure", 0:00.94 but your build might not succeed. 0:00.94 gmake[4]: *** [Makefile:90: /wrkdirs/usr/ports/www/palemoon/work/palemoon-source/platform/configure] Error 1 0:00.95 gmake[3]: *** [/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/platform/config/rules.mk:493: default] Error 2 0:00.95 gmake[2]: *** [/wrkdirs/usr/ports/www/palemoon/work/palemoon-source/client.mk:406: realbuild] Error 2 0:00.95 gmake[1]: *** [client.mk:164: build] Error 2 0:00.97 0 compiler warnings present.
(In reply to Kurt Jaeger from comment #103) Hi Kurt, The failure you're reporting is the same as that of comment #80 and, as I said (#82 and others), I've never been able to reproduce it, with or without poudriere. Anyway, thanks for having run this test. That said, I'm closing again the bug (and please leave it closed, unless you want to take over maintainership). I was just providing new versions as a courtesy for people that used the port in order to give them more time to migrate to some other browser (see comment #94). And I'm going to stop after this version, which I'm going to explain in a subsequent message. Regards.
(In reply to Matt A. Tobin from comment #99) (In reply to Matt A. Tobin from comment #100) Judging by the phrasing and the content, these extracts seem genuine. So it seems we have been visited by the one and only Matt A. Tobin. > Here is something from my IRC logs that may confirm the status of BSD in Pale > Moon despite what Moonchild has been saying since I was kicked to the curb. I'm sure Moonchild will appreciate that some of its private conversations are aired without its knowledge or consent. As for "kicked to the curb", he has publicly stated a very different point of view (basically, you've been the one that kicked yourself out through rage quit with a sprinkle of sabotage). But as we will see, I generally do not trust his point of view either now. And as a matter of fact, I don't care much about who started what or whose "fault" it is, and I'm certainly not going to cry over it. Nonetheless, I suppose I should thank you a little bit because you're confirming and even exceeding the impressions I already had that Moonchild's overall behavior is uninformed, disingenuous and deceptive, and more importantly, you're giving public proofs of that, so that he won't be able to hide behind excuses such as your own behavior or fake attempts at "cooperation" or bogus claims to wanting an open community. Perhaps this was your goal by reporting your logs after all. In which case you're going to be well served. > It does not show me in the best light but it happens to be true. Your naïveté is almost charming. You're so gifted to find the right words. Given all your outbursts and insults everywhere in the Pale Moon forums, tickets and pull requests, rest assured that no small logs like these can stain your already prominent reputation. Don't worry, I don't intend to feed the troll much more, and I'll soon leave you to your eructations. However, before that, I can't let these logs out with so many false statements, be they genuine misunderstandings or plain lies, because they give readers the impression that I'm mostly responsible for the cooperation failure when you (personally, and Moonchild above all) mostly are. > <NewTobinParadigm> Moonchild: I am not at all willing to work > with any BSD without a commitment from them to actually work > with us. This is exactly what I had been seeking from the start... except that I expected in exchange a commitment on your side as well... oh, not much, but at the very least no trying to discourage the effort and hoping to be fed with useful technical guidance for your codebase and build infrastructure. You did exactly the contrary, and in the rare cases where you (personally) tried to provide some technical insights, they turned out to be irrelevant or wrong *every single time*. Everyone can read for example just the start of the long forum thread (https://forum.palemoon.org/viewtopic.php?f=5&t=25625); I'll give some more examples below (if people want more, they can just take the list of links of comment #2 and start reading). Moonchild showed himself a little bit more willing, but more often than not his contributions turned out to be worthless. He didn't seem to know relatively basic things on the C preprocessor (such as the value of undefined tokens in tests). Another time, he suggested me to use Mozilla's C++ atomic templates (in C code...) and numerous times had difficulty to grasp what I was saying about clang (how it *is* compatible with GCC, and this is an explicit goal) and libc++ headers, mixing the two. Finally, he showed not to be aware of the runtime library dependencies of his own platform. Additionally, Moonchild seemed indifferent to your own conduct. At least, he didn't try to put me off initially. Later, I started to notice that he was more the guerilla type of guy, with frequent sarcasms and rhetorical questions implying he was skeptical on some things I was saying, as if I was trying to hide something. I initially found that odd, and it's only later that I understood this was in fact reflecting his own way of functioning, where he would not speak out and leave me in the dark about his intentions, apparently prospering on ambiguity. I came to this thought after what happened at start of https://repo.palemoon.org/MoonchildProductions/UXP/pulls/1778, where he was going to commit a rather trivial one-line change by me that didn't need specific Windows testing, but finally stopped when you popped up, gratuitously ranted and decided to force me to setup a Windows environment right now, although I did not have time at that moment. (Also, one of your puppets popped up saying the patch was incorrect... and was blatantly wrong. You then used this pretense not to test it. See the pattern?) In any case, in retrospect, my effort was doomed to fail also due to your very peculiar definition of a commitment. This means first and foremost for you having the opportunity to rant and (try to) control me, through pointing out perceived deficiencies which didn't exist or were very minor or through leaving me in the unknown. Moreover, it seems you expected that I would do things always your way and in the order you decided, undermining my own agenda of giving a quick and perennial access to another browser to FreeBSD users, simply because I did not intend to spend as much time as you do on this project (but I was prepared to invest more time, see below). I had already spent my initial share on figuring out how to make your jemalloc work, although that of FreeBSD works equally well for Pale Moon and is configured very similarly (yeah, there was a small risk to using it because of a hack to circumvent a limitation of your JS machinery (some high virtual addresses should not be used), but this I could have workarounded, if you had been more open to alternatives). > <NewTobinParadigm> I also want to remove ALL BSD support from > gre as it stands today and have THEM add BACK support in a more > proper way ala SunOS. I was never opposed to this idea, but rather opposed to be forced to cope with the fallout of a sudden, uncoordinated removal. What I wanted was instead incremental changes throughout, or at least temporary patches waiting for me to have more time to tackle the whole task correctly. But again, you (both of you) never seriously took into account my own constraints and views. > <NewTobinParadigm> In my opinion, OlCe1 has already proven to > not be a serious contender for this endeavor. Someone else must > lead this charge. Someone who is reasonable. I have my very own idea about who is reasonable and who is not. And people just have to look at the amount of bullshit you produced to see who's right. E.g., here: https://repo.palemoon.org/MoonchildProductions/UXP/pulls/1731 . But in reality, any other ticket or pull request will do as well, because this is your almost constant attitude. > <Moonchild> Oh I agree. I'm just still probing to see what's going on. > <Moonchild> And he himself said he's not sure whether all the BSD code paths are even necessary, so that aligns exactly with what you would want. > <Moonchild> But I'm not pouring all that out in one go. I have to know details from them. Another example of disingenuous behavior. > <NewTobinParadigm> I believe they once were .. 15 years ago.. in general i think that is true and our plans to prefer XP_UNIX except where it is necessary to get more specific is a good one for our general stability and code clarity > <Moonchild> Yup > <NewTobinParadigm> take the Tobin Factor out of the equation and it rings of actually being fair and proper to all unixes I think This was exactly what I proposed to Moonchild, and never received any feedback, except that, initially, he was insisting in highlighting the putative peculiarities of _his_ platform (as if it has been _so_ different from all the others, so unique; and it is, but only to some extent), and that the existing FreeBSD-specific code was here for a reason. I'm discovering here that in fact he was agreeing (or perhaps he changed his mind... again). > <Moonchild> I'm just letting them know a compromise and BSD support in our tree is possible -- but haven't said anything about HOW that's going to be done. To which I responded with ways to organize cooperation. Which you called "socio-political" bullshit below. > <NewTobinParadigm> except mac :P > <NewTobinParadigm> which is fake-unix > <Moonchild> Mac can fuck off > <Moonchild> so can OpenBsd > (snip) So Tobin is not the exclusive producer of insults... Amusingly, Moonchild has changed his mind once again (https://forum.palemoon.org/viewtopic.php?f=65&t=28174&p=226675#p226675). Another testimony to its great vision and leadership. But I wouldn't bet this can happen for OpenBSD... > <Moonchild> NewTobinParadigm: I'm dropping FreeBSD on the floor. I'm really just done with it. Especially if the one that is supposed to liaise between a reluctant platform team and use is leveraging the OpenBSD BS that doesn't even apply to their platform or their team just to keep the opening to build the way they want anyway. This is a complete misunderstandings of my last messages. Initially, I hadn't thought to bring the OpenBSD drama on the table because I suspected the topic could be inflammable (but boy, I underestimated how much it still appears to be). What happened is that I was almost prompted to by Moonchild himself, with some of its frequent rhetorical questions: > I think in that case I taste more than a little paranoia from the ports > manager/triager in that bugthread too when it is assumed I'll just > change the redist license on a whim and withdraw branding from any and > all because I woke up with a bad mood or something (regardless of the > fact that such a thing would be challenging to do, legally speaking -- > and I do dare say I've got a little more legal expertise than most > involved here). Think about that for a moment. Why would I do that? How > would that help the project and its users? You think I have no sense of > commitment or discipline and still be driving this project 10+ years > later? When I read those lines, I thought he could not be serious. This was clear proof that he had not learnt from the past. His failure to recognize his own behavior is a threat to any perennial collaboration, simply because he can mess things up at any moment without really noticing. So, yeah, at this point, I had to confront him. This had absolutely nothing to do with "building it their way". I showed multiple times that I was taking Moonchild's concerns seriously, although they were more often than not quite nebulous, so I had to ask questions to understand what his real motives were. And again, this had nothing to do with me citing the OpenBSD drama. > <NewTobinParadigm> or maybe one of the shitter bsds comes to call An admirable way to try to drag people in. > <NewTobinParadigm> i just think IF we ever were to allow BSD in the future it needs to be done from the perspective of what is needed now not the compromises from 10-15 years ago hacked and rehacked and never properly tested by core mozilla > <NewTobinParadigm> Moonchild > <Moonchild> Yes i agree > <Moonchild> and he clearly stated that he wasn't going to do that anyway somewhere in his essay > <Moonchild> so fuck it. Another occurence of Moonchild not been able to read to save his life... What I stated exactly is that I didn't know precisely the amount of work for this task. I never said I did not want to do it, on the contrary, I had already evoked almost exactly that (see above; Moonchild is contradicting himself). What was implicit in my answer (perhaps it should have been made explicit) was my reluctance of you removing all the support code at once according to your own agenda (and not taking into account mine), possibly leaving me in the wild and depriving users of new versions until I could fix the build again. > <NewTobinParadigm> it is amazing how he went all out on the anti-Tobinism all without me saying a word since last year > <NewTobinParadigm> shattered his own illusion without a word from me I have memory. You're the one living in illusion. It's never too late to wake up, even if there is plenty of evidence that it's likely going to be very hard for you to. > <Moonchild> the overly long post really pissed me off, by the way. it's cleverly written, and clearly Olce is a good conversationalist, but I can't rhyme it with what's needed to cooperate Unless I'm mistaken, I get to choose how I spend my time. We are talking about a few hours for the whole exchange and my main essay. Indeed, this was a non-negligible effort on my part. Sure I could have read code and done tests instead. But what would have been the point? What I was concerned about was whether the cooperation could be perennial or not. There was no way I was going to invest much more time into your platform without proper reassurance on that front. And that time spent on the discussion and on the essay proved to be well spent in this regard, although the outcome is sad. > <Moonchild> if he can take a long time to compose what he did, he should also be willing to put in the legwork code-wise. unless that's actually not his forte in which case he can't do what he says he wants to Again, you have a very small view of the world if you think your platform is that big... I've navigated into code bases orders of magnitudes greater than yours (yes, you read that correctly; ~100M to 1B lines). Another pretense it seems. > <Moonchild> so there are so many approaches to it that all come to the same conclusion, and I'm just dropping it. period. Seems clear. Until the next change of mind. > <NewTobinParadigm> target operating systems need to be maintained by those familiar with it > <Moonchild> exactly > <Moonchild> and I was very clear that was needed > <Moonchild> which resulted in a barf of sociopolitical BS and semi-covered attacks on all of us. Completely wrong again. You'll hardly find someone that familiar with FreeBSD. But yes, I'm not a committer, and I'm not on the ports manager team, so can't speak for them. In my essay, I went on with: - How we could work asynchronously, through the Pale Moon port, instead of the synchronous way you appear to wanted and I could not provide (and in your own repository, while being obstructive). - How ports management work in FreeBSD, with input (and citations) of ports management members and ports committers, so that you have a clear view of what you can expect a priori (because you actually lacked in this matter, understandably). - How I could help to overcome obstacles, as I had already done up to that point. - How I was prepared to keep maintainership of the port for at least 2 years, and dedicate some weeks full-time later this year, initially to clean-up the FreeBSD build in your codebase, but then for other useful tasks (which could have been revamping the FreeBSD port in your codebase). So, the only real feedback from you is "socio-political BS". So much for the consideration you have for others and their interests. "semi-covered attacks"? Nothing was covered or ambiguous, contrary to what you love to do. And the intent was not to attack, but rather to point out problems and see how you'd cope with them. > <NewTobinParadigm> you made an absolutely good play by including my contributor roll with my community interaction stepback it encouraged him to not only question it but attack harder > <NewTobinParadigm> masterful > <NewTobinParadigm> role* I've always considered that the blind praising the one-eyed is among the best laughs in life. > <NewTobinParadigm> Probe Complete. Indeed. To wrap up, you've been mostly agressive and unhelpful from the start, were absolutely unable to listen to most of my own concerns, to which you reacted as if I was attacking you. Additionally, it appears clearly that Moonchild is as much to blame as you, and probably more since he's the leader and showed himself to be passively deceptive, which is even more vicious. Traits, by the way, you may have yourself been the victim of. Farewell, petulant children!
(In reply to Kostas Oikonomou from comment #98) Hi Kostas, > He seems apologetic for Tobin's behavior. I suggest you read my previous comment first. Then, you'll understand why it will take a lot more than a small, single apology, for me to believe in what Moonchild is claiming. > Is that an indication that maybe support for FreeBSD won't be removed? I don't know, and Moonchild seems to change his mind a lot. In any case, it's not my concern anymore. I wish good luck to anybody that would try to maintain such a port despite upstream's behavior. I'm not going to update the FreeBSD port patch anymore, 29.4.6 is the last from me. With luck, you can change the version and the distfile checksum inside the patch and it may work, were Moonchild to release another version in the 29.4.x series (I don't know what his plans are; I don't think he said anything with regards to when the 30.x series will be ready, even on the forums; and of course nothing on whether FreeBSD-specific code will be dropped there, despite hinting to me that keeping it was so much annoying). Regards.
(In reply to Olivier Certner from comment #106) Olivier, thank you again for the tremendous amount of effort you've invested in this port. I respect your decision, and, again, as a user, I'm sorry this became such an ugly mess, instead of a fruitful (for all parties) cooperation.
This was not a private conversation though it did take place in a limited access channel on my IRC server. It isn't anything that wouldn't have been stated publicly in the main channel either. So there is no expectation of privacy and no consent is required. Regardless, if you want to further drag me through the mud for showing how deceptive Moonchild has been reviled to be either in months to me or now on the forum (or both) in response to this incident which its self has been a massive fraud of manipulated facts, events out of sequence, and outright fabrications and largely all hidden away now so only those who saw the headline and not the substance or circumstances of things can repeat a favorable misconception that is your choice. However, remember this: I have been rather consistent and even willing within well defined terms to proceed. Moonchild has publicly and flip-flopped and let you spin your wheels to justify his semi-privately stated decision by merely persisting. He had no intention of working with you from the start and damn surely not when you resurfaced. As a matter of public record, I had little problem with FreeBSD except the passive aggressive way they let the original OpenBSD issue seemingly go only to turn around months later quietly killing the port until you came along. Regardless, it seems that our collective goals and conditions were far more aligned than anything Moonchild said or did so my conclusion at the time may have been a touch premature. However, I have had a lot of time to reflect this year since the high school drama performance in December and especially since it was played out for real blind-sighting me and the total dedication I put in even when my father passed away in Feb. So I will only offer up my willingness to continue to expound truth of events even if it continues to highlight my own mistakes and past behavior simply because truth is really the only thing one has at the end. As I continue to forge my own path not encumbered by the bullshit from Pale Moon I do hope we will encounter each other again and have a more positive result. Matt A. Tobin Commanding Officer Binary Outcast
Alternative to Pale Moon: SeaMonkey I've recently switched to SeaMonkey, see https://www.seamonkey-project.org/. You can see the details on the above site, but, briefly, (1) SeaMonkey has the "classic" look that Pale Moon has/had, (2) it is based on the Firefox rendering engine, so compatibility with web sites is much better than PM's, (3) it also offers a built-in mail client based on Thunderbird, but again with a classic UI. The situation with plugins/extensions is not as good as with PM, but should improve. There is an unofficial port to FreeBSD, see https://forums.freebsd.org/threads/disaster-strikes-seamonkey-removed-from-ports-tree.71335/page-1. Interestingly, the port was removed from the tree for some of the same reasons that PM was removed *initially*. The good thing about the port is that it requires no changes at all to the code, it consists only of distinfo, pkg-desrc, and Makefile. The downside is that (currently) the port depends on python2.7, like PM. But if you've kept python2.7 around, building SeasMonkey is very simple.
Created attachment 243622 [details] A3, landscape A wide printout of this bug report. Some people may find this easier to speed-read. Unusually long quoted lines were problematic, so I wrapped some and then prefixed with quote characters. (Without this edition, which is normally impossible in Bugzilla, the fit to page required a terribly small font size.)
(In reply to Graham Perrin ◐ from comment #110) By the way, Palemoon has ended up supporting FreeBSD. See https://www.palemoon.org/download.shtml.
I hope they continue to do so and you guys can productively cooperate. Just be mindful. I, however, would at this point very much like to turn a positive eye to BSD my self but for the time being it is beyond my current means. Perhaps one day. Either way, I wish you all success on the FreeBSD side.
(In reply to Kostas Oikonomou from comment #111) Thanks, I found myself here only because <https://github.com/helloSystem/Utilities/issues/183#issuecomment-1647999562> a developer asked why the port wasn't building. <https://github.com/helloSystem/Utilities/issues/183#issuecomment-1651023110> drew attention to deletion, then (last week) <https://github.com/helloSystem/Utilities/issues/183#issuecomment-1656118464> attention to Pale Moon downloads.
(In reply to Graham Perrin ◐ from comment #113) Apropos that, the build on the PM website above is classified as an "unofficial build". It comes from https://dbsoft.org/whitestar-releasenotes.php, as far as I can tell. Maybe there is an opportunity here for reviving the port?
Pale Moon's classification at least when I was there of an unofficial build is basically just an expression of willingness to put a logo on it and if you should expect it to work and if you should blame us if it doesn't. Limited granted but simple to follow. Heh.. as if. You guys could likely turn unofficial into official if you expressed interest. Since I ain't there don't let that stop you guys if that is really what you want and they could use it right now. Reviving WhiteStar is pointless because for reasons I am not privy or particularly interested in the worst prospect for survival of a no-name project by fanatics is not gonna be on Apple Hardware but since that is what they have chosen to do and dbsoft is back in charge of it and seemingly doing a job Pale Moon users are happy with it kinda makes Whitestar redundant since it was only created because of past issues in collaboration. As I vaguely care to understand he is keeping whitestar around for testing and experimentation but not really as a mainline project except knowing him I am sure he would fall back if they fell out again. I hope these insights help.
After checking it looks like the FreeBSD port is using the Gold Beta branding. Blue is release. Red is Unstable/Testing and gold is Beta.. If it is using the gold branding it means it is a serious commitment by whomever is producing it (or should at least) and is while not as tested and deemed of the same quality as blue release branding it is not just unofficial and is more developed and has had more faith placed in it than merely experimental. That assumes Moonchild still places the same emphasis on branding AS quality as he did when I was enforcing it.
As this bug report was closed, long ago, I should encourage forward-looking discussion at: - the Pale Moon forum, <https://forum.palemoon.org/>. <https://forum.palemoon.org/search.php?keywords=FreeBSD>, and so on. ---- (In reply to Kostas Oikonomou from comment #114) > … classified as an "unofficial build". … Historically: 2023-01-24: > … finalizing official builds for Mac OS and FreeBSD. These are currently in > beta and can be downloaded from the Contributed Builds page. … 2023-02-01: > Contributed … FreeBSD: x86_64 builds by DBsoft. 2023-03-14: > … official mirrors … FreeBSD 64-bit (beta) … – one of three betas, at the time. 2023-05-16: > … also offer GTK2 builds for FreeBSD. … 2023-05-19, 2023-08-02: > … FreeBSD 64-bit GTK2 (beta), FreeBSD 64-bit GTK3 (beta) … 2023-08-08: > … FreeBSD 64-bit GTK2 (beta) (Legacy tree or later), > FreeBSD 64-bit GTK3 (beta) (Legacy tree or later) … Official betas. Points of reference, respectively: <https://www.palemoon.org/releasenotes.shtml> <https://web.archive.org/web/20230201045815/https://www.palemoon.org/contributed-builds.shtml> <https://web.archive.org/web/20230314212657/https://www.palemoon.org/download.shtml> <https://web.archive.org/web/20230519152006/https://www.palemoon.org/download.shtml> <https://web.archive.org/web/20230802014554/https://www.palemoon.org/download.shtml> <https://web.archive.org/web/20230808020141/https://www.palemoon.org/download.shtml> If you want points that are more accurate, or descriptive: - you know where to go ;-) I'm there.