Building Palemoon for Mageia but branding concerns

[tarakbumba]

Hi. Thank you so much this awesome browser. I have a 15 yr. old 32 bit laptop with 2 GB ram. I'm using this machine with Mageia 7.1 installed. Unfortunately, per latest official announcement Pale Moon binaries ceased to exist for 32bit architecture. So, i need to build it for my self. Since this machine is very incapable of building Pale Moon, I setup an OpenSuse Build Service project aiming to build Pale Moon for Mageia. I adapted firefox-52.0 Mageia package to Pale Moon. It builds and works well. I have used applicable patches from Mageia Firefox package. But I have concerns over official branding. I've read https://www.palemoon.org/redist.shtml and I suppose I can only build Pale Moon without any patching. Am I right? Or am I allowed to patch Pale Moon, for example to use default system language? Also am I allowed to add rpm packages of language pack from official addons? I need assistance for these matters and any help appreciated.

P.S. I'm adding patches that I've used.

[New Tobin Paradigm]

None of those patches are acceptable as they materially change the browser. The second one MAY but likely isn't ok but the rest are a big no. Also, we cannot allow you to distribute language packs or change the language preference because there is too high of a risk of the browser busting.

Additionally, let me see your mozconfig.

[tarakbumba]

Thank you for clarification. Mozconfig is not a seperate file but embedded in rpm spec file. I'm posting that part between quote tags. Please note that Mageia prefers to stick with system libraries and such. Therefore distributing an application embedded with system libs aren't advisable. So, I tried to use system libs where possible.

Code: Select all

export MOZCONFIG=$PWD/.mozconfig
cat << EOF > $MOZCONFIG
mk_add_options AUTOCLOBBER=1
mk_add_options MOZ_MAKE_FLAGS=%{_smp_mflags}
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../obj
export BUILDING_RELEASE=1
export MC_OFFICIAL=1
export MOZILLA_OFFICIAL=1
export MC_PALEMOON=1

ac_add_options --host=%{_host}
ac_add_options --target=%{_target_platform}
ac_add_options --enable-optimize="%{optflags}"
ac_add_options --enable-optimize
ac_add_options --prefix="%{_prefix}"
ac_add_options --libdir="%{_libdir}"
ac_add_options --x-libraries="%{_libdir}"
ac_add_options --includedir="%{_includedir}"
ac_add_options --datadir="%{_datadir}"

# Enable stuff, especially build with system packages
ac_add_options --enable-application=palemoon
ac_add_options --enable-system-cairo
ac_add_options --enable-system-hunspell
ac_add_options --enable-alsa
ac_add_options --enable-pulseaudio
ac_add_options --enable-release
%if %gtk_3
ac_add_options --enable-default-toolkit=cairo-gtk3
%else
ac_add_options --enable-default-toolkit=cairo-gtk2
%endif
ac_add_options --enable-jemalloc
ac_add_options --enable-av1
ac_add_options --enable-strip
ac_add_options --enable-libproxy
ac_add_options --enable-phoenix-extensions
ac_add_options --enable-system-ffi
ac_add_options --enable-system-pixman
ac_add_options --enable-safe-browsing
ac_add_options --enable-extensions=default
ac_add_options --enable-startup-notification

ac_add_options --with-system-jpeg
ac_add_options --with-pthreads
ac_add_options --with-system-zlib
ac_add_options --with-system-bz2

# Disable unused features
ac_add_options --disable-debug
ac_add_options --disable-eme
ac_add_options --disable-gamepad
ac_add_options --disable-necko-wifi
ac_add_options --disable-tests
ac_add_options --disable-updater
ac_add_options --disable-webrtc

export MOZ_DATA_REPORTING=
export MOZILLA_OFFICIAL=
export MOZ_ADDON_SIGNING=
export MOZ_REQUIRE_SIGNING=
export MOZ_TELEMETRY_REPORTING=

EOF

[Moonchild]

No, you cannot use official branding for redistributing this.

[tarakbumba]

No, you cannot use official branding for redistributing this.

Even disabling all those patches? Does my mozconfig also have a problem? Do I have to use exact same mozconfig mentioned in Building Pale Moon: GNU Linux page?

[New Tobin Paradigm]

Pretty much.

[tarakbumba]

Thank you for clarification. Please look at this mozconfig; I hope this is ok.

Code: Select all

# Set GTK Version to 2 or 3
%if %gtk_3
_GTK_VERSION=3
%else
_GTK_VERSION=2
%endif

export MOZCONFIG=$PWD/.mozconfig
cat << EOF > $MOZCONFIG
mk_add_options AUTOCLOBBER=1
mk_add_options MOZ_MAKE_FLAGS=%{_smp_mflags}
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../obj

ac_add_options --host=%{_host}
ac_add_options --target=%{_target_platform}
ac_add_options --enable-optimize="%{optflags}"
ac_add_options --prefix="%{_prefix}"
ac_add_options --libdir="%{_libdir}"
ac_add_options --x-libraries="%{_libdir}"
ac_add_options --includedir="%{_includedir}"
ac_add_options --datadir="%{_datadir}"

# Standard build options for Pale Moon
ac_add_options --enable-application=palemoon
ac_add_options --enable-default-toolkit=cairo-gtk$_GTK_VERSION
ac_add_options --enable-jemalloc
ac_add_options --enable-strip
ac_add_options --enable-devtools
ac_add_options --disable-eme
ac_add_options --disable-webrtc
ac_add_options --disable-gamepad
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --disable-necko-wifi
ac_add_options --disable-updater
ac_add_options --with-pthreads

# Please see https://www.palemoon.org/redist.shtml for restrictions when using the official branding.
ac_add_options --enable-official-branding
export MOZILLA_OFFICIAL=1

# For versions after 28.12.0
ac_add_options --enable-phoenix-extensions

export MOZ_PKG_SPECIAL=gtk$_GTK_VERSION

EOF

[Moonchild]

Can you indicate what those variables are being filled with, e.g. ac_add_options --enable-optimize="%{optflags}" -- what will be in "optflags" there?

[tarakbumba]

Can you indicate what those variables are being filled with, e.g. ac_add_options --enable-optimize="%{optflags}" -- what will be in "optflags" there?

Of course. These are all Mageia's default rpm build macros, I' ll put here my commandline outputs, some may differ on different build machines you know, like arch or smp_mflags due to my laptop's 32 bit intel centrino due processor.

Code: Select all

[ 22:09 tarakbumba ~ ]$ rpm --eval %optflags
-O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables

Code: Select all

[ 22:12 tarakbumba ~ ]$ rpm --eval %{_smp_mflags}
-j2

I have export LDFLAGS="$(echo %{ldflags}),--no-keep-memory -Wl,--reduce-memory-overhead" line in my specfile because of building failures.

Code: Select all

[ 22:13 tarakbumba ~ ]$ rpm --eval %{ldflags}
 -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags

Code: Select all

[ 22:16 tarakbumba ~ ]$ rpm --eval %{_target_platform}
i586-mageia-linux-gnu

Code: Select all

[ 22:17 tarakbumba ~ ]$ rpm --eval %{_host}
i586-mageia-linux-gnu

Also; these are system wide predefined paths: %_datadir : /usr/share/ %prefix: /usr, %_libdir: /usr/lib/ or /usr/lib64 depending of build architecture, %_includedir: /usr/include/

[Moonchild]

Yeah that's what I was afraid of. That's not going to work for Pale Moon because it can't simply be built with system optimization flags "whatever they might be". We have pretty complex and fine-tuned logic to define the proper CXX and LD flags in tree, and what should be in mozconfig, if anything at all, should only be necessary specific flags needed for the build, not a full replacement of what system packages are built with (like in your case trying to compile in 2GB of ram needing those LD flags... which really isn't recommended for a positive build).
Pale Moon should be built with -O2 and sse2 optimization flags in mozconfig only, and the rest being determined by the build system. so you really do need to at least hard-code --enable-optimize to

Code: Select all

-O2 -msse2 -mfpmath=sse

and not forcing LDFLAGS if you can avoid it.

I'm not a Linux builder myself so I'm not entirely sure if substituting system variables for the other configuration flags is ok or not, but the compiler directives are definitely in need of being set hard.

[tarakbumba]

Yeah that's what I was afraid of. That's not going to work for Pale Moon because it can't simply be built with system optimization flags "whatever they might be". We have pretty complex and fine-tuned logic to define the proper CXX and LD flags in tree, and what should be in mozconfig, if anything at all, should only be necessary specific flags needed for the build, not a full replacement of what system packages are built with (like in your case trying to compile in 2GB of ram needing those LD flags... which really isn't recommended for a positive build).
Pale Moon should be built with -O2 and sse2 optimization flags in mozconfig only, and the rest being determined by the build system. so you really do need to at least hard-code --enable-optimize to

Code: Select all

-O2 -msse2 -mfpmath=sse

and not forcing LDFLAGS if you can avoid it.

I'm not a Linux builder myself so I'm not entirely sure if substituting system variables for the other configuration flags is ok or not, but the compiler directives are definitely in need of being set hard.

Thank you for replying. It's very hard to package Pale Moon with official branding. Is it necessary to use your optimization flags for official branding? Honestly, these conditions ruined my dream to import in Mageia official repositories one day. Anyways, this is a situation that accepting or leaving. I' ll surely want to package Pale Moon and obey these conditions in my OBS repository.

I have another question, if I create another package without official branding; is it ok for it to use Pale Moon sync? I suppose no but want to learn from you. Thank you both Moonchild and New Tobin Paradigm spend your precious time to assist me.

[Moonchild]

I'm sorry that you experience this as somehow being "difficult". The thing is if you want official branding then you have to supply the browser as intended by us. That means building it with known-good configuration and optimization, targeting the same O.S. and hardware level that has been tested and developed against.
If you don't do that then you are in effect giving something that is not Pale Moon to people. So it shouldn't be carrying the Pale Moon label in that case. That's all there is to it, and it's not unreasonable to request that something that is distributed with official branding on it to be built according to our guidelines.
You previously used the mainline binaries supplied by us -- you should not suddenly give people something significantly different now.

Of course if you create your own branding, then you can patch all you want and build any way you prefer for distribution.

As for Pale Moon Sync, that depends entirely on how many users will be using the unofficial client. If it's a significant volume then I'll have to ask for compensation somehow or ask that you run your own. While we do have some headroom on the sync server, it's not limitless and it's not free to run, so if the added traffic means we need to increase our server resources then that will have to be compensated in that case.

[tarakbumba]

I'm sorry that you experience this as somehow being "difficult". The thing is if you want official branding then you have to supply the browser as intended by us. That means building it with known-good configuration and optimization, targeting the same O.S. and hardware level that has been tested and developed against.
If you don't do that then you are in effect giving something that is not Pale Moon to people. So it shouldn't be carrying the Pale Moon label in that case. That's all there is to it, and it's not unreasonable to request that something that is distributed with official branding on it to be built according to our guidelines.
You previously used the mainline binaries supplied by us -- you should not suddenly give people something significantly different now.

Of course if you create your own branding, then you can patch all you want and build any way you prefer for distribution.

As for Pale Moon Sync, that depends entirely on how many users will be using the unofficial client. If it's a significant volume then I'll have to ask for compensation somehow or ask that you run your own. While we do have some headroom on the sync server, it's not limitless and it's not free to run, so if the added traffic means we need to increase our server resources then that will have to be compensated in that case.

I totally understand you. And you're right. If I were a developer like you, I surely wanted to what you want from others. When I was writing it's difficult to packaging with official branding I mean distros, like Mageia and Fedora, want packages to use stuff (like shared libraries) packaged and provided by distros themselves. Including built-in libraries which are also in distro seen as security risk and they don't allow it. Also distros have those build macros to ensure all packages build and work in all situations. Difficulty is this.

Regarding unofficial branding, I'm playing with it only to see effects of all Mageia patches. I asked for sync to whether I need to disable it or not. So, I decided to disable sync for my playground package. But I think that isn't a matter of this conversation.

Finally I packaged Pale Moon for Mageia with official branding and using your instructions and guidance. I stripped all patches and used mentioned optimization flags. Thank you again.

[Moonchild]

Including built-in libraries which are also in distro seen as security risk and they don't allow it.

I don't understand why people don't get that this is simply a wrong attitude when dealing with a frequently-updated application of the scope and complexity that Pale Moon has. If you want to be exact then actually what is included as built-in libraries isn't what is in the distro for each case where the library in the distro isn't built exactly to version and configuration that is expected by our surrounding code -- and we can't reasonably be expected to know exactly which libs match exactly and which don't on each and every release of every distro, so we have as policy that system libs aren't allowed for official branding to be used. Trying to force that because of "security" is also incorrect, see e.g. my explanatory entry in development discussion; you should read it. Maybe I should move it to the FAQ section.

[moonbat]

Firefox ran into the same issues with Debian, leading to rebranded variants like Ice Weasel.

A browser isn't some small tool that can be built using just any system library there is. @Moonchild maybe you should point this out also in the explanatory post, to show that it isn't something unique to Pale Moon and has been done before. Moving it to the FAQ section sounds like a good idea.

[Moonchild]

Firefox ran into the same issues with Debian, leading to rebranded variants like Ice Weasel.

Sorry but that's unrelated. did you even read the article you linked to?
Debian's spat was purely about wanting rights to a trademark and wanting it to be "free". Here, there's pressing technical reasons for denying the use of the trademark.

[moonbat]

Debian's spat was purely about wanting rights to a trademark and wanting it to be "free".

Reading the bug tracker thread linked from the wiki, it seems to be a similar case of Mozilla wanting approval over code changes they made for them to continue being allowed to use Firefox branding. To wit -

The key problem is that there is code, and a build switch, that
explicitly handles the official branding/logos vs. the generic
name/artwork, and the package maintainer has chosen to break this switch
by making the unofficial side of the switch also label itself as
Firefox. I don't understand the motivations here, since the changelog I
saw isn't visible (packages.debian.org is still being weird) but the
gist of it was "avoid using the official branding switch" which seems
like one of those "makes it harder to undo" steps since people actually
would have to change code instead of build options to not be bound by
those terms. If users don't build with the official branding, its
because they are not accepting the terms of using things bound up in
trademark law. Doing things this way implies that only the artwork is
part of the official branding, as opposed to the name as well.

I had to break the switch, because I need to call it Firefox, but I
can't include the official graphics.


I've confirmed that this isn't acceptable usage of the trademark. If
you are going to use the Firefox name, you must also use the rest of the
branding.

Why can't you just use the official branding switch, anyway?

Because it uses graphics which have a non-free copyright license.


This is not something where you are free to pick what parts you want to
use. Either use the trademarked logos and name together or don't. The
name is trademarked in the exact same way as the logo, so I fail to see
how you can argue that one is acceptable to use and the other is not.
Maybe there's a technicality, but the name is just as free as the logos...

[New Tobin Paradigm]

If an actual distro (the team not just one lone user) wanted to commit to extensive investment, testing, and quality assurance to be sure that Pale Moon is functoning perfectly on every level and otherwise identically from an end user perspective as a sort of collaborative partnership then maybe that could be a thing but that is so remotely unlikely.

No what we have is a situation where a user (attached to a distro or not) following distro policy of carte blanche on how to build something without regard to the extreme complixity and quirks that are inherent to a classical mozilla-style codebase with only vague surface testing if any at all. Along with indiscriminate customization patches.

As well meaning as the user or packager or distro may be without that kind of investment and assurance to back it up one must fallback to OUR policies if one wants to use our branding for redistribution of our product.

Simple as that.

[Moonchild]

If an actual distro (the team not just one lone user) wanted to commit to extensive investment, testing, and quality assurance to be sure that Pale Moon is functoning perfectly on every level and otherwise identically from an end user perspective as a sort of collaborative partnership then maybe that could be a thing

It would certainly be negotiable in that case!

As well meaning as the user or packager or distro may be without that kind of investment and assurance to back it up one must fallback to OUR policies if one wants to use our branding for redistribution of our product.

With a side note that if this is something that is built on the end-user's system using user-system-defined build/optimization options, then that is going to be pretty much an impossibility.

[Moonchild]

Moving it to the FAQ section sounds like a good idea.

Decided to write a new FAQ entry instead linking to it.
viewtopic.php?f=24&t=26031