New FreeBSD port

[New Tobin Paradigm]

It looks like a nettle that the PM developers are going to have to grasp and it seems that PM is going to need to have overhaul that tool chain - or get bogged down in accumulating technical debt. I haven't the foggiest idea how much work is involved in updating your tool-chain but please can you reassure us that it is in the TODO list somewhere?

Nope. There shall be no reassurance on this point here. You're very much screwed. I will not allow the build system to become yet another thing that relies on constant moving target dependencies in that way.

I would accept uncompromised compatibility with Tauthon without bustage of Python 2 but that is all.

IF we were to go far as Python 3 (or 4 if it happens to crop up in a few years) or the likes of newer autoconf we may as well replace the entire thing completely and that ain't gonna happen either.

Only exception may be an even older Mozilla build system before mozconfigure was added.

So if that blocks BSD Ports having a package then that is the way it shall be.

[Moonchild]

it seems that PM is going to need to have overhaul that tool chain - or get bogged down in accumulating technical debt. I haven't the foggiest idea how much work is involved in updating your tool-chain but please can you reassure us that it is in the TODO list somewhere?

I invite you to go back to my previous post and read it a few more times until you understand what I said there (and what Tobin re-iterated above in a different wording).
If FreeBSD maintainers refuse to give us the tools we need to build, then we simply can't target it. It doesn't matter what you have to do to satisfy the toolchain requirements; the matter of the fact is that for binary and official redistributions, specific build environments will have to be set up (and historically always have been). That can include manual installations of packages otherwise not supported in running systems of that O.S. (Heck, just look at what we do on Windows with a totally non-Windows unix-like environment to build in!). That isn't "technical debt" (nice buzzword!), rather it is having a complex multi-language build system that has been created over the course of more than a decade, and that simply can't be "updated" to a moving target version of various languages in use in the system that easily (or at all!).

So no, it's not on our TODO because there is no feasible target toolchain to aim for. There won't be any assurances to that effect either.

[drjohnnyfever]

For what it's worth I have been maintaining a FreeBSD ports branch with a newmoon/palemoon port based on the FreeBSD Bugzilla 251117, now upgraded to 29.1.0 and it has been working fine. I've only been testing on 12.2 but I'm going to start using 13.0 on my desktop and will be testing there as well. Obviously if FreeBSD ports doesn't get real tauthon support I'm going to have to limp along handling it myself then. To me it does seem like it would probably be desirable for the Palemoon project to try to eliminate the python 2 dependency long term, I know Tribblix is planning on removing python 2 at some point.

[Moonchild]

I'm not sure how often we have to repeat this like a broken record but "eliminating python 2" is not feasible. If that means the browser has to be built in a specialized environment that has Python 2 while regular running systems don't, then so be it. It's not like the end result has python in it so there's no issue with it being old, as long as it lets us build our tree in the (isolated) build environment. Does this mean it becomes more difficult for end-users to compile if the required build environment packages are not readily available? Most likely. Is that a problem? No, not really. End users can always use binaries that are built by others who have the required toolchain at their disposal.

[drjohnnyfever]

I understand python 2 isn't part of the delivered system, but it is an issue maintaining it on all the platforms everyone is going to want to build on. I personally don't mind having python 2 as a build-only dependency but after FreeBSD and Tribblix and Ubuntu and everyone else rip out Python 2 from the package repos it is going to become a maintenance burden making it build on FreeBSD 14.X, Ubuntu 22.X etc. There is zero effort by the python devs to make sure it builds on FreeBSD-New and Glibc-New as far as I know. I'm fairly sure FreeBSD isn't going to be the only platform where python 2 is going to cease being a standard package that is easily installable as a binary at some point in the near to medium-term future.

Believe me, I am not trying to tell you guys what to do. I am thankful for the Palemoon project and all the work you guys have put into it. You don't owe me anything. I am just explaining the issues *as I see them*. I'm attempting to be helpful. I want to try to help get FreeBSD as an officially supported platform. I'm even willing to try being a Tauthon maintainer for FreeBSD ports if it is helpful.

[New Tobin Paradigm]

If this is going to become a fight all of BSD will loose it. I am far more inclined to suggest we drop code-level support for an entire distro or target os over this python thing.

I am personally well beyond willing to deal with BSD situations and their harassing dim witted userbase with every shoe that drops and every tidbit of resistance from them on anything simply re-enforces that position.

However, as UXP Coordinator, I am willing to abide its existence and build potential as long as it does not become overly burdensome.

Basically, be greatful or be silent because I am not going to tolerate this sort of bullshit dragging on and on. You have been warned.

[drjohnnyfever]

Not quite sure what I did to make everyone mad. I was just tossing out ideas. I'm not demanding anything, I'm attempting to and willing to try to help.

[Moonchild]

I'm attempting to and willing to try to help.

From where I sit it doesn't look like that. It looks like "willing to try to help*" where the * is a set of conditions that conflict with the way our software is built.
There is no necessity or requirement anywhere for our tree to build on every end user's machine. That is not part of our scope, never was and never will be. Once again, and for the last time repeating it: building this software will require specific environments to generate binaries, especially if O.S. maintainers are no longer providing the necessary build dependencies. It's quite possible that as a result it will become completely impossible to build on some target systems if the necessary tools are no longer available even in special environments, but that is not, in any way, our responsibility; nor is it our responsibility to be compatible with every conceivable target.

While we will consider reasonable requests for O.S. compatibility considerations, like accepting non-interfering patches to our tree to ensure code-level compatibility with targets, we will not up-end our entire build system just because someone decided they no longer want to have build dependencies available that we hard-require. A restrictive target O.S. will only have as an option to have a binary distribution built by a trusted contributor in that case. That is nothing new, and nothing out of the ordinary for FOSS.

[drjohnnyfever]

I literally said i have been building and running palemoon and it works fine and I'm going to be testing on FreeBSD 13.0. I mentioned that python 2 is a pain point and made no demands what so ever from you guys. I'm not sure where the animosity is coming from.

[New Tobin Paradigm]

I'm not sure where the animosity is coming from.

History and the pubic record. Maybe you should make yourself familiar with it and consider a different operating system.

[Moonchild]

I'm not sure where the animosity is coming from.

As far as I'm concerned there is no animosity here at all.
I think you might be mistaking not yielding to unreasonable requests as animosity.

[drjohnnyfever]

Okay sure. I'm not sure I was being a "harassing and dim witted" member of the BSD userbase though. That struck me as animosity. But if not, I'm willing to forget about it and have us all be friends here.

[moonbat]

I'm not sure I was being a "harassing and dim witted" member of the BSD userbase though.

That wasn't for you, historical interaction with the BSD userbase is more like it. There's old threads about this if you're interested.

[drjohnnyfever]

I'm not sure where the animosity is coming from.

History and the pubic record. Maybe you should make yourself familiar with it and consider a different operating system.

I use Linux and FreeBSD. On the Linux side I deal with assholes like Lennart Poettering and Greg Kroah-Hartman while on the BSD side I deal with nice people like Kirk McKusick and George Neville-Neil. So I'm probably not going to move away from FreeBSD any time soon. But I've taken your advice under all it's due consideration.

[New Tobin Paradigm]

What is wrong with Lennart Poettering.. He took both the audio stack and services system beyond 1979. Oh yeah, he is an asshole and hating him a popular bandwagon to jump on. Well let's see if you jump on another bandwagon or not.

[ron_1]

Off-topic:

What is wrong with Lennart Poettering..

systemd for one, and the way he handles reports of systemd bugs.

[jobbautista9]

Off-topic:
systemd for one, and the way he handles reports of systemd bugs.

Off-topic:
That, and the never-ending scope creep of systemd. To quote someone, if systemd is the solution, I want my problem back. I did by installing openrc+sysvinit instead, and I'm happy with it.

[OlCe1]

Some news:
1. 29.1.0 builds and works fine with GCC 10 on FreeBSD 12.2. I'm keeping the port updated in my own repositories.
2. There is some (private mostly at this point) discussion within FreeBSD's port management in order to find a solution for this kind of problems (Pale Moon is not the only big open-source project requesting Python 2.7 to build as of now; it may very well be the last in a year or two, though). And it seems an agreement will be found in the end. I've submitted several ideas and code to this end. But everybody has to understand this process is taking a bit of time, and until some official statements are made, we cannot be sure about the exact outcome. I hope this is resolved satisfactorily within a few weeks.

[OlCe1]

There has been several messages on the Python 2 issue, so I think I should make myself clear:

Please stop asking about Pale Moon's build system changes or migration in this thread.

Because:
1. Upstream's stand on this is already very clear.
2. Most people don't seem to know much (or anything at all) about this build system or/and have no experience of big software projects. So they fail to realize the amount of effort at stake here. And personally I find it perfectly reasonable that upstream prefers to work on more interesting or pressing real browsing issues than trying to revamp a build system that works, whatever its drawbacks.
3. This is arguably off-topic for this thread.

Thanks.

[New Tobin Paradigm]

Sane and thoughtful words. Thank you dude.