Pale Moon forum

So just FYI ... I've updated my Gentoo ebuild for 27.6.2, and it builds and works fine either on a 13.0 system profile, or on the new system-wide-PIE 17.0 profile, as long as it is built with gcc-6 (6.4.0 to be exact). If compiled with gcc-7, the build fails all over the place, terminates way early, and does not yield an executable.

gcc-7 is not considered stable by Gentoo yet, so this is just a heads-up.

Now this sounds promising!
Rebuilding everything for PIE on profile 17 broke VP9 support on my system somehow, I can no longer do 4k youtube videos with the unstable binary distribution of Pale Moon.
I'd like to be able to compile an instance of 27.6.2 on my machine with PIE support to test whether having ffmpeg compiled as PIE while running Pale Moon without PIE is the cause for my video playback regression. Is your ebuild publicly available?

smilr wrote:Rebuilding everything for PIE on profile 17 broke VP9 support on my system somehow, I can no longer do 4k youtube videos with the unstable binary distribution of Pale Moon.

Have you set the "pic" USE flag globally in make.conf? Yeah, I know it's a "local" USE flag, but if you execute
grep ":pic " /usr/portage/profiles/*.desc

...you'll see listings mentioning disable optimized assembly code that is not PIC friendly and several that mention (this is slower). Apparently, inline assembler code isn't always relocatable. I'll ask on the Gentoo forum if it's possible to hack the 17.0 profile to avoid forced PIE/pic/PIC builds.

@Unix Ronin:
Is your gentoo ebuild for 27.6.2 "non-SSE2 capable/SSE-only" and if so, what's the link from where to download it ?

@Walter Dnes:
You have a SSE-only binary made over at ftp://ftp.palemoon.org/SSE-Linux/ and I definitely prefer this over the main linux build (which requires cpu's to have SSE2 support) however since it's a binary, it's not compiled by the user and is thus unable to include the benefits of the flagging, ... present in Gentoo.

Is there a non-binary "script" (=ebuild) version for Gentoo of your latest version (27.6.2) -or at least a version as new as 27.6.0 ?

I found following version that I wanted to use since it appears to be "sse able" (so not requiring SSE2 support):
https://github.com/Bfgeshka/octopus/blo ... 6.0.ebuild

see the flags: +gtk2 -gtk3 -webrtc strip-binaries cpu_flags_x86_sse cpu_flags_x86_sse2
The cpu_flags_x86_sse seems to indicate to me that it is able to run on a non SSE2-able cpu (am I right in this ?).
I suppose this is a 32-bit version, that 64-bit cpu's will also be able to run ?

If it is possible to run on an non sse2-able cpu, I'll use this, if not I'll probably use your binary version.
Please provide some advice on this.

Is there also a 64-bit-only palemoon ebuild script for gentoo (I assume this doesn't require SSE2 anyway since SSE2 is x86-only) ?

Finally, it's weird that there is no palemoon package listed over at https://packages.gentoo.org/categories/www-client,
but that as a side note.

Peregrine wrote:@Unix Ronin:
Is your gentoo ebuild for 27.6.2 "non-SSE2 capable/SSE-only" and if so, what's the link from where to download it ?

@Walter Dnes:
You have a SSE-only binary made over at ftp://ftp.palemoon.org/SSE-Linux/ and I definitely prefer this over the main linux build (which requires cpu's to have SSE2 support) however since it's a binary, it's not compiled by the user and is thus unable to include the benefits of the flagging, ... present in Gentoo.

Is there a non-binary "script" (=ebuild) version for Gentoo of your latest version (27.6.2) -or at least a version as new as 27.6.0 ?

If I understand properly, I don't think that what you want will work. Pale Moon compiled on an up-to-date Gentoo will run on another machine with up-to-date Gentoo, assuming the cpu flags were set appropriately for the build. It will NOT run on linuxes using older libraries. An SSE-only machine is Pentium3-class. I assume you'll be running something like Puppy Linux on a Pentium3. I use a CentOS 6.5 chroot environment for the SSE-only contributed build. Building against older libraries allows it to run on systems with older libraries, as well as new libraries. My first attempts were with CentOS 7.0. Those builds did not run on some versions of Puppy Linux.

Actually, someone did manage to install Gentoo on a 486. https://linux.slashdot.org/story/18/01/07/228222/can-you-install-linux-on-a-1993-pc If you can install and run up-to-date Gentoo on the Pentium3, then you can compile on another Gentoo machine, and install on the Pentium3. The main worry is how much ram you have on the Pentium3. I'd recommend a lightweight Window Manager like ICEWM

Peregrine wrote:I found following version that I wanted to use since it appears to be "sse able" (so not requiring SSE2 support):
https://github.com/Bfgeshka/octopus/blo ... 6.0.ebuild

see the flags: +gtk2 -gtk3 -webrtc strip-binaries cpu_flags_x86_sse cpu_flags_x86_sse2
The cpu_flags_x86_sse seems to indicate to me that it is able to run on a non SSE2-able cpu (am I right in this ?).
I suppose this is a 32-bit version, that 64-bit cpu's will also be able to run ?

If it is possible to run on an non sse2-able cpu, I'll use this, if not I'll probably use your binary version.
Please provide some advice on this.

A quick look shows that the ebuild assumes that Pale Moon will be running on the machine that built it. Forget about building Pale Moon on a Pentium3. The ebuild will require some editing.

I have a custom build script that generates a tarball. I can send the script to you. "Installing" from the tarball is trivial.
"mkdir $HOME/pm" and extract the tarball to $HOME/pm. Then point your program launcher to "$HOME/pm/palemoon/palemoon". Updating consists of "rm -rf $HOME/pm/palemoon/" and installing from the updated tarball. This is usable if you only have one user. For multiple users install to "/usr/local/pm/" or "/opt/".

The tarball install process does not splatter libraries all over the place. So the "rm -rf $HOME/pm/palemoon" command deletes it completely.

Peregrine wrote:Is there also a 64-bit-only palemoon ebuild script for gentoo (I assume this doesn't require SSE2 anyway since SSE2 is x86-only) ?

I don't understand the question. If you build on a 64-bit Gentoo you get a 64-bit build; if you build on a 32-bit Gentoo, you get a 32-bit build.

Walter Dnes wrote: If I understand properly, I don't think that what you want will work. Pale Moon compiled on an up-to-date Gentoo will run on another machine with up-to-date Gentoo, assuming the cpu flags were set appropriately for the build. It will NOT run on linuxes using older libraries. An SSE-only machine is Pentium3-class. I assume you'll be running something like Puppy Linux on a Pentium3.

You assume I work on an SSE-only machine, and that I run a different linux with outdated libraries.
Actually, I work on a dualcore pentium 4 (32-bit), and mostly run windows xp (in the past I also used slitaz, but I ditched that a while ago since it's not mainstream enough and doesn't get updated much). The intent is to make a custom gentoo livecd that also has pale moon aboard (so similar to what I wanted to do for slitaz, but now for gentoo).
For the flags I intent to use to make the livecd , see https://github.com/ecocomputing/TAZ/blo ... ttings.txt
The libraries I intent to use will be up to date versions.

I guess I'll need to make the livecd first, and then make pale moon using the ebuild.

The idea will be to make the livecd (and with it the pale moon version I'll use thereon) as generic as possible, so able to run on a variety of x86 machines (with the sse class being the lowest cpu class that can be used)

If I use the https://github.com/Bfgeshka/octopus/blo ... 6.0.ebuild script, what exactly do I need to change on it ?

I copied it to https://github.com/ecocomputing/gentoo- ... 6.0.ebuild
if you have a github account, you can propose the changes needed via that page.

You mentioned wanting to make some tweaks versus my standard SSE contributed build. If you're going to be distributing Pale Moon on the liveCD, see http://www.palemoon.org/redist.shtml for terms and conditions. You have basically 2 options...

1. * comply with paragraphs 1-to-12, and you can use "official branding"
   * or go with paragraph 13; turn off official branding, and you can tweak it as much as you desire

If you have any further questions about the licence, PM Moonchild directly. To turn off official branding, change line 25 of the ebuild to

IUSE="-official-branding

I have a couple of other changes to suggest for the ebuild, and for your make.conf. While researching some stuff to answer your question, I stumbled over an optimization I wasn't aware of. I''l test it before getting back to you with the details.

If you do not use official configuration and choose to use something akin to Dnes's or anything else you MUST seek approval from Moonchild to use official branding.

Moonchild mentioned that "adopting system O flags which is dangerous if that's O3; nothing beyond O2 should ever be used on our tree)", so that needs to be checked in the Bfgeshka's build.

For the record, after receiving and reviewing details about the intended distribution, its reconfiguration and parallel offer of known-problematic extensions, official branding is not allowed in this case.
Thanks for opening a dialogue prior to publication to verify and ask for an individual agreement, but the intended setup is not acceptable as an official release.

Since this will be an unofficial release, as per paragraph 13 of the licence, it's probably off-topic here. I'll be communicating with Peregrine via PM about his customization questions.

Walter Dnes wrote:Since this will be an unofficial release, as per paragraph 13 of the licence, it's probably off-topic here.

Just to make sure people understand why it's a no: the reconfiguration of the browser touches many preferences and changes them to not recommended values, as well as even having a bunch in there that simply don't exist in pale Moon, so it's clear Peregrine wants the browser to behave significantly differently than our official releases with all attached issues for users of it, and doesn't actually know what they are doing with this bundle making those configuration changes. The result will be a browser that is at least half-crippled, and not something i agree having the official branding on -- and that is even BEFORE loading it up with a bunch of extensions that will cause issues like disconnect, noscript, and more.

Seriously, I'm all for you taking Pale Moon and making a derivative configured and shaped to what YOU think is what a browser should be, but don't ask for permission to use official branding if you aren't going to adhere to the balanced principles behind our official configuration. As i said just 5 minutes ago: put your heads together, come up with a name and logo/icon, and make it an official, branded fork of Pale Moon. Just do it. Brand it and publish it as your own.

If you need help navigating the branding files and what to change to make the build unique.. Let me know..

Just to clarify. I do my own customizations for personal use at home. I don't have the inclination or skills to launch a separate fork but I'm willing to share details of my tweaks with people who ask. On the other hand, I follow the party line when doing official builds. I know it sounds like "Jekyll and Hyde", but I have no problem with it.

• Dr. Jekyll ==> official builds
• Mr. Hyde ==> "Gentoo ricer" by night (but even I don't do "-O3")

Just throwing a simple idea if people want to use official branding. It should take care of reconfiguration of the browser, but will not fix issues arising because of unsupported compiler flags.

Build Pale Moon using standard/official instructions and package it as "palemoon". For browser reconfiguration, reate another package called "palemoon-enhancements-gentoo" and put all the recommended add-ons, plugins, search engines and custom preferences files in it. This way, a user can run vanilla Pale Moon or top it off with gentoo specific enhancements if desired. And of course, to keep their interests, Gentoo people can always mark "enhancement" package as a preferred/recommended package in their repos.

Can't really do package management like that with a LiveCD..

New Tobin Paradigm wrote:If you need help navigating the branding files and what to change to make the build unique.. Let me know..

No, I think I'll stick with the general unofficial branding (New Moon).

@adesh: I'm already going to use 2 packages in the way you suggested. This doesn't really matter as Tobin pointed out as I'm using a livecd, but it will make it easier to update the browser later, with subsequent releases of the livecd.