Pale Moon forum

There's no 32-bit unstable channel with binaries. Anyone interested would have to "roll their own". I have a few questions.

• According to http://www.palemoon.org/unstable/releasenotes.shtml "Pale Moon has been split off from the UXP platform repository and will be maintained as its own application". What is the URL to git clone?
• What is the suggested standard mozconconfig?
• Assuming that I build current unstable branch with the standard mozconfig, would bug reports be accepted?

Once I get the source code and mozconfig. I'll experiment trying to figure out the oldest CentOS version that builds Pale Moon. There will be CentOS 7.x community 32-bit versions until support for the 7 series expires in 2024. Another item I'll research will be how old of a linux distro can actually run Pale Moon 29.

Walter Dnes wrote: ↑

2020-03-11, 19:25

According to http://www.palemoon.org/unstable/releasenotes.shtml "Pale Moon has been split off from the UXP platform repository and will be maintained as its own application". What is the URL to git clone?

https://github.com/MoonchildProductions/Pale-Moon
After clone, do `git submodule init` and `git submodule update` and then run mach commands.

Walter Dnes wrote: ↑

2020-03-11, 19:25

What is the suggested standard mozconconfig?

Same as you were using earlier.

Walter Dnes wrote: ↑

2020-03-11, 19:25

Assuming that I build current unstable branch with the standard mozconfig, would bug reports be accepted?

Most likely yes, unless it is architecture specific.

There are no devtoolsets for 32bit centos 7 you have to use a specific centos 6 setup.. One I am not willing to share the secrets of.

Don't bother with this though because 32bit for linux is being retired in november.

Additionally, the unstable branding is not free-to-use. There is no current decision on applicablity to the redist license and failing that it falls to the MPL which grants you no rights to use the branding.

I personally think you are incompetent and should not be allowed to do this. Though, that is well known.

tl;dr go home dnes, you're not welcome here as far as I am conserned.

If you are on 32-bit Linux, you likely shouldn't be using the unstable channel to begin with. Want to be on the bleeding edge? Then please get yourself a proper system first. Otherwise just use -release like everyone else.
Please don't "roll your own" with the intent of distributing, either. As Tobin pointed out you can't use the unstable branding, I won't allow it; it's for official vendor use only.

Moonchild wrote: ↑

2020-03-12, 07:11

If you are on 32-bit Linux, you likely shouldn't be using the unstable channel to begin with. Want to be on the bleeding edge? Then please get yourself a proper system first. Otherwise just use -release like everyone else.

We've been told that there won't be a 32-bit release version of Pale Moon 29. I built it successfully yesterday in the same CentOS 6.10 (six point ten) chroot I use for my homebrew 28.8.4 version. 29 runs fine on an older distro that 28 runs on. It would be a shame to drop 32-bit support going from 28 to 29. Unlike the jarring jump from 27 to 28, it appears that any machine/distro combo that ran 28 can run 29.

I have 2 modern desktops with 8 gigs ram each Also a Dell from 2008, and an off-lease Lenovo Thinkpad, both with 3 gigs of ram. Yes, I could run 64-bit linux on the 3-gig machines, but that would imply a newer bulkier distro, with more bells and whistles, and useless 64-bit address pointers that use more space.

Moonchild wrote: ↑

2020-03-12, 07:11

Please don't "roll your own" with the intent of distributing, either. As Tobin pointed out you can't use the unstable branding, I won't allow it; it's for official vendor use only.

You don't have to worry about that. There's a significant difference between simply compiling a tarball versus properly managing/supporting a distro. I don't think I'm up to that task.

Who told you there won't be Linux 32 bit version of Pale Moon 29? There absolutely will be. Just not an official build from us after November but before that, yes there will be because it isn't November yet.

If 29.0 is stabilised and released by the end of the month, that'll be 7 months to Nov 2020. The 28.0.0 release was on 2018-08-16 http://www.palemoon.org/releasenotes-archived.shtml almost exactly 18 months ago. Assuming the 29 series lasts that long, there won't be an official 32-bit tarball for well over half the lifespan of the 29 series. If the Pale Moon team would commit to making an official 32-bit tarball available for the lifespan of the 29 series, this discussion would not be necessary.

The release of 32-bit Linux binary variants has everything to do with official support for Linux 32-bit by mainstream Linux vendors and nothing to do with our own development.
We won't make any commitment for the distribution of 32-bit binaries for the duration of any milestone as a result because we won't tie it to that.
You also seem to forget that our (especially milestone) releases aren't calendar-driven. The length of time any previous milestone was in use is in no way an indicator for any current milestone.

Let's agree to disagree. I'd prefer to end this thread now.

Walter Dnes wrote: ↑

2020-03-13, 04:03

Let's agree to disagree. I'd prefer to end this thread now.

Thanks for making me feel like I just completely wasted my time responding to you...

This is not a situation where one can agree to disagree.

I had already laid out and submitted the roadmap for Linux binaries we produce and distribute and it will be followed regardless of the development cycle.

System packagers are however free to produce 32 bit packages if their distro still has a 32bit target but that is their affair not ours. Users who wish to roll their own for their own personal and not distributed use may also do so.

Be it 32bit or gtk2 or glibc or gcc minimum version the situation is the same. We do not want to arbitrarily bust the capability but also want to move forward and taper off targeting old and insecure systems and dependences.

As for you, my dear Dnes, you do not get to dictate or decide what and how we produce and distribute our products.

The decision has already been made. End of discussion.

Dismissed.

New Tobin Paradigm wrote: ↑

2020-03-13, 13:38

System packagers are however free to produce 32 bit packages if their distro still has a 32bit target but that is their affair not ours

Can Linux maintainers create their own binary builds of Pale Moon? I heard that the Pale Moon license forbids this. I have faced people's displeasure about this, by the way, about violation of the Mozilla's license.

New Tobin Paradigm wrote: ↑

2020-03-13, 13:38

Users who wish to roll their own for their own personal and not distributed use may also do so

Building a 32-bit browser still requires a 64-bit OS and a lot of RAM. So in some cases it may not be realistic.

UPD: I understood. Linux maintainers can build their own Pale Moon builds if the branding is removed. However, in fact, no one does this. Either they use the official binary copy, or compilation on the user side, as AUR Arch Linux.

Everything you need to know about branding and the limitations of building from source with official branding (which is allowed in certain situations) can be found in the redistribution license http://www.palemoon.org/redist.shtml -- please read it carefully.

Please note that providing a redistribution built from source on the user's machine when configuration is determined by a distribution must also adhere to sane build configurations if official branding is used (building on the end user's machine as instructed by a packaging/distribution system (like in Arch or Gentoo) is not a "way around" distributing wildly deviating build configurations with official branding; that's not permitted). Unstable branding is also vendor-official and protected the same way as release branding.
Bottom line: users can build their own configurations at their own risk, but Linux distros may not enable official branding in portage or user build systems by default unless they stick very close to our tested and official build configuration, at least not without clearing it with me/us. It's the only way we can have some semblance of "people getting what was intended/expected" when using something with the Pale Moon label on it.

FYI: several posts were removed and warnings issued. Behave, people.

Building a 32-bit browser still requires a 64-bit OS and a lot of RAM. So in some cases it may not be realistic.

Not really true if you're willing to limit the build to one thread and pass some flags to gcc to limit memory overhead during linking. Then builds can succeed on 4 GB 32-bit platforms, but they may take many hours in that case.

It may also just as easily fail because you are dangerously close to using up all your address space on 32-bit.
It may also fail in a subtle way that doesn't error out the build process but creates a browser that is unstable.

Bottom line: Please don't build on a 32-bit host. Cross-compiling works just fine and doesn't bear any of those risks.

stevepusser wrote: ↑

2020-10-29, 11:47

Building a 32-bit browser still requires a 64-bit OS and a lot of RAM. So in some cases it may not be realistic.

Not really true if you're willing to limit the build to one thread and pass some flags to gcc to limit memory overhead during linking. Then builds can succeed on 4 GB 32-bit platforms, but they may take many hours in that case.

i'm doing my private builds on x86 GNU/Linux system, with -j4. it is working fine, doesn't need any swap (i have swap turned off), and takes about 30-40 minutes to build on core 2 duo.

not that i recommend to do that, just wanted to tell that it's not that bad in 32-bit land (yet ;-).

Perhaps the situation with Pale Moon is not that bad as with the latest versions of Firefox, where I saw a warning about the inoperability of building on a 32 bit system (except maybe for unsupported artifact builds).
How realistic is it to build Pale Moon on Pentium 4 / 1472 MB RAM, Xubuntu Xenial 32 bit? The system partition has 10 GB of free space. I ask just out of curiosity, I'm unlikely to do this.
Applications compile pretty quickly. For example ffmpeg 40 minutes. cmake 1.5 hours. The only exception is GCC 10 (and also 8) took 11 hours to build. I've heard Firefox is comparable in speed.
Unfortunately, I had to sell a computer with an i5 processor. My brother has a Core 2 Duo with 2 GB RAM, Win7 x64.

Unfeasable.

artenaki wrote: ↑

2020-11-02, 01:01

How realistic is it to build Pale Moon on Pentium 4 / 1472 MB RAM