OpenBSD & Pale Moon: coordinating patches and officially branded package?

Talk about code development, features, specific bugzilla bugs, enhancements, patches, and other highly technical things.

Moderator: satrow

Forum rules
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific referenced Bugzilla bugs, mercurial, etc.

This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Most "bug reports" do not belong in this board and should initially be posted in Community Support or other relevant support boards.

Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
ibara
New to the forum
New to the forum
Posts: 1
Joined: Sun, 04 Feb 2018, 22:26

OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread postby ibara » Sun, 04 Feb 2018, 23:16

Hi --

It goes without saying that I'm new here, so if this is the wrong place for this, please move to a better place.

I have the latest Pale Moon running on OpenBSD (see: https://twitter.com/__briancallahan/sta ... 9210661888).

There are a couple of patches I had to make to get it working. Mostly related to building with clang-5.0.1 (the default compiler on OpenBSD)--but I will say that I've been using Pale Moon as my only browser for a few days now for everything from webmail to YouTube and Twitch.tv, and haven't experienced any issues or problems. So my first question is what is the easiest way to coordinate patches? Is it the GitHub? Or is there another way?

Browsing the website, I noticed that in order to distribute officially branded binaries requires approval. Which is perfectly fine and I understand why. I think it would be mutually beneficial to offer an officially branded Pale Moon browser through the OpenBSD package system. How would we go about making sure I can do that? I'm also an OpenBSD developer, so I would be the one maintaining any such package. I've already had a number of OpenBSD users express interest in using Pale Moon and are eagerly anticipating an official package.

Thanks!

User avatar
SpockFan02
Lunatic
Lunatic
Posts: 460
Joined: Sun, 24 Sep 2017, 16:35

Re: OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread postby SpockFan02 » Mon, 05 Feb 2018, 05:14

Yeah, you should probably open an issue or issues on GitHub (https://github.com/MoonchildProductions/Pale-Moon) and tag the relevant issue in any pull requests you make. If you're fixing problems caused by building with Clang, I'm excited, because it's also the default compiler on current versions of macOS. :D

tuxman
Fanatic
Fanatic
Posts: 167
Joined: Mon, 17 Sep 2012, 16:39
Location: Germany

Re: OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread postby tuxman » Mon, 05 Feb 2018, 20:11

Well done, you killed Pale Moon on OpenBSD:
https://github.com/jasperla/openbsd-wip/issues/86

Continue your good work.
[ OpenDownload² for SeaMonkey, Firefox and Pale Moon :: QFO for SeaMonkey and Thunderbird :: ymarks bookmarks sync for Firefox, Chrome, Opera and Vivaldi ]

User avatar
Sajadi
Keeps coming back
Keeps coming back
Posts: 944
Joined: Fri, 19 Apr 2013, 00:46

Re: OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread postby Sajadi » Mon, 05 Feb 2018, 20:35

That was an indeed counterproductive escalation sadly... :eh:

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 22407
Joined: Sun, 28 Aug 2011, 17:27
Location: 58.5°N 15.5°E
Contact:

Re: OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread postby Moonchild » Mon, 05 Feb 2018, 20:57

tuxman wrote:Well done, you killed Pale Moon on OpenBSD:

Well done, you have completely not understood what happened or who "killed" it.

"Our way or the highway" doesn't fly when you're enabling official branding (including trademarks and branding you don't have rights to) as if it was public domain. And then demanding the IP rights holder to come in as the only accepted valid voice in the matter while things are clearly stated in the source AND redist license is exactly what makes such a thing escalate.
Then they still had the option to either make the changes to adhere to the license OR not use official branding but New Moon instead, and instead chose to just remove it from the portage tree.

So who "killed" it? Not us.

If anyone wants officially branded Pale Moon on *BSD, I suggest you submit a proper portage addition that adheres to the license for official branding exceptions OR work with me to get an agreement on different build configuration if deviant build rules are desired that make it not comply with normally-accepted porting practices for packages.
Alternatively, add it with unofficial branding or fork it with different branding altogether for BSD and apply whatever patches are needed and whatever unwise build configuration you think works "best" for "your" OS.
Last edited by Moonchild on Mon, 05 Feb 2018, 21:04, edited 3 times in total.
Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne

tuxman
Fanatic
Fanatic
Posts: 167
Joined: Mon, 17 Sep 2012, 16:39
Location: Germany

Re: OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread postby tuxman » Mon, 05 Feb 2018, 21:04

That was not meant to be an attack, Moonchild. :)
I understand the contradiction between OpenBSD's "no non-free software" and Pale Moon's "no modifications" approaches. It will be ... interesting to see what happens now.

I, for one, don't care about the branding, I could live with a New Moon or QuuxBrowser or whatever.
[ OpenDownload² for SeaMonkey, Firefox and Pale Moon :: QFO for SeaMonkey and Thunderbird :: ymarks bookmarks sync for Firefox, Chrome, Opera and Vivaldi ]

User avatar
Isengrim
Astronaut
Astronaut
Posts: 539
Joined: Tue, 08 Sep 2015, 22:54
Location: 127.0.0.1
Contact:

Re: OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread postby Isengrim » Mon, 05 Feb 2018, 21:25

Moonchild wrote:...OR work with me to get an agreement on different build configuration if deviant build rules are desired that make it not comply with normally-accepted porting practices for packages.
Alternatively, add it with unofficial branding or fork it with different branding altogether for BSD and apply whatever patches are needed and whatever unwise build configuration you think works "best" for "your" OS.

Do you think they would have been more willing to cooperate had these options had been presented earlier in the discussion?
Linux Mint 18.3 Cinnamon (64-bit)
Windows 7 (64-bit) (Sometimes)
Windows 10 build 1803 (64-bit) (Sometimes)
We are our choices.

User avatar
Thehandyman1957
Board Warrior
Board Warrior
Posts: 1686
Joined: Tue, 19 May 2015, 02:26
Location: Arizona U.S.

Re: OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread postby Thehandyman1957 » Wed, 07 Feb 2018, 03:13

Sadly, after reading that whole debacle I find more than ever some folk who cannot handle any sort
of "Do it right" response even when it's clearly explained why. Could it have been handled better? Perhaps.

But the fact is, it's not their creation and they don't have any right to abuse or change anything that could and
would have come back to bite not only them but Moonchild and the team themselves.

The reaction of the ibara was at the least, snobish and childish and thus continued the hard edged attitude that
continued throughout.

What I find most amazing is that not one of the people that commented and decided that they would never ever use
PM again, stopped to even think about how ridiculous their reaction even was. They were in the wrong, They were told to correct
the problem or stop. Instead of seeing their error and correcting the issue they decided it was better to crucify the messenger and
the project and rant against the idea of rules to the point of daring the use of force. :wtf:

This "free at any cost, I will do what I want with your software" is a cancer in the minds of a lot of people these days.
And sadly, it goes way beyond software. This, rules be dammed entitlement mind set is a rot to society. :thumbdown:

The fact is, if this was their reaction to something as simple as this, how much different would it have been down the road? :think:
“It is difficult to get a man to understand something,
when his salary depends on him not understanding it. Upton Sinclair” ;) "

Alex12
New to the forum
New to the forum
Posts: 2
Joined: Wed, 07 Feb 2018, 21:03

Re: OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread postby Alex12 » Wed, 07 Feb 2018, 21:19

Good afternoon. This section is about OpenBSD but I came from another resource: https://forums.freebsd.org/threads/59110/page-4
After reading https://lists.freebsd.org/pipermail/fre ... 12455.html and OpenBSD issue I was very disappointed by this attitude to your clients (I'm one of Pale Moon users on TrueOS/FreeBSD workstation) and especially to those who are involved in the Pale Moon development (yes, peoples who spends hours of their lives and portes your browser to additional platforms, making the lives of other users more happy - participating in the development of your product).
I am shocked by your unwillingness to make official support for the Pale Moon for xBSD platform (a small user base, I agree). You could at least just help make the port better. Instead, you kill this endeavor. Except for the use of BSD, I widely use Linux and Windows in my work. However, I decided not to use Pale Moon on any OSes. I hope that someday I'll see official support on the BSD and the desire to make your project more accessible. Good luck!

User avatar
New Tobin Paradigm
Knows the dark side
Knows the dark side
Posts: 4762
Joined: Tue, 09 Oct 2012, 19:37

Re: OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread postby New Tobin Paradigm » Thu, 08 Feb 2018, 03:33

I like how you didn't link or cite anything I said to the FreeBSD people only to show their opening email..

Here is the full story with FreeBSD as far as my interactions are concerned because mailing lists can be hard to follow.

Mark Felder wrote:Dear Matt,

After your recent harassment of OpenBSD (https://github.com/jasperla/openbsd-wip/issues/86) I decided to investigate our own packaging of Palemoon. As expected, we are also building against system libraries. You can review our build log here:

http://beefy6.nyi.freebsd.org/data/103a ... 27.7.2.log

Adding configure options from /wrkdirs/usr/ports/www/palemoon/work/Pale-Moon-27.7.2_Release/.mozconfig
--enable-application=browser
--enable-official-branding
--enable-devtools
--enable-jemalloc
--enable-jemalloc-lib
--prefix=/usr/local
--enable-jemalloc
--with-system-libevent
--enable-system-ffi
--with-system-graphite2
--with-system-harfbuzz
--enable-system-hunspell
--with-system-icu
--with-intl-api
--with-system-jpeg=/usr/local
--with-system-nspr
--with-system-nss
--with-system-png=/usr/local
--enable-system-pixman
--enable-system-sqlite
--with-system-libvpx
--enable-chrome-format=omni
--enable-default-toolkit=cairo-gtk2
--enable-update-channel=release
--disable-updater
--enable-pie
--with-pthreads
--enable-extensions=default
--with-system-zlib
--with-system-bz2
--enable-optimize
--enable-startup-notification
--disable-gstreamer
--enable-gconf
--disable-libproxy
--enable-alsa
--enable-pulseaudio
--disable-rust
--disable-debug
--disable-debug-symbols
--enable-release
--disable-dtrace
--enable-profiling
--disable-tests
--disable-strip
--disable-install-strip


Would you like us to delete our port of it now? I can arrange for that if you insist on not having proper ports of your software. At this point it might be easier to just add a clause to your license that prohibits non-Linux platforms.

Let me know what you think.


Cheers,


Matt A. Tobin wrote:Greentings,

It would be awesome if you could build it closer to our official build configuration. Something more akin to http://developer.palemoon.org/Developer_Guide:Build_Instructions/Pale_Moon/Linux#head:Mozconfig_Files

Patches to anywhere in the codebase to accommodate our in-tree code for BSD systems to get a positive build is totally permitted. If that means libvpx or nss needs an in-tree patch then that is totally fine.

In fact, if you do the patches in such a way as it won't interfere with other platforms via proper ifdef we would gladly accept them up the line. We were close to having this in the past but the contributor would not make clean patches that didn't fundamentally bust other platforms and we had to back it all out.

We do want to work with platforms and projects but we also don't want our rights to be trampled on any more than you would want yours to be. Frankly, we didn't want the OpenBSD people to remove the port either but that was their decision to escalate a situation beyond reason over a couple of perhaps poor phrasing choices.

The Mozilla Public License is clear in its provisions and grants and protections for covered code. The Pale Moon Redistribution License actually extends rights and permissions beyond what the MPL allows but has its own conditions that need to be met. None of these are insane or out of line and are there so that users of the software know they are getting what the name and logo claim it to be.

However, given all that if you guys are going to follow suit and not going to follow point 8 of the Redist License you ask under point 10 for special permission to use trademarked branding and perhaps find a happy medium between which libs are absolutely required to satisfy the Pale Moon feature set and what ones can get by with using system libs.

The decision is yours. Please make it a good one.


Mark Felder wrote:[ I do not speak on behalf of the project ]

Two problems:

1) You're not the upstream for any of these codebases: sqlite, nspr, nss, png, icu... As such there will be no effort made to submit you patches. You are welcome to retrieve our patches from the FreeBSD ports tree and apply them to your codebase if you so choose. Many man hours were spent adjusting these projects to work with FreeBSD's expectations; spending more to appease your private forks of these projects is unconscionable.

2) Shared system libraries exist for a reason and we intend to use them.

3) It will be beyond tedious to track down which vulnerabilities your browser is shipping. A CVE in nss or sqlite3 will not show up automatically for Palemoon in the results of our "pkg audit" tool unless someone has the ambition to peek into your codebase and see which extra copy of those libraries are being used.

Building with your libraries is the wrong way to ship this software for our users.

Do we need to disable your branding only or also stop using the name? If both, we will likely remove the port and suggest users upgrade to www/waterfox if they want an alternative to Firefox.


Matt A. Tobin wrote:Alright, if that is the case, then yeah you can just disable branding. If you run into troubles, i can help on this.. Or if you wanna come up with new branding I can also help with this.

Peace.


Mark Felder wrote:Ok I will start working on this.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225717

Thanks


And that is ALL that happened with FreeBSD and me us all of us.. Anything else is just them.. Same goes with OpenBSD everything me us everyone happened in the GitHub issue on the ports-dev repo..

Judge for your self but despite the FreeBSD person being obviously initially defensive and a little passive aggressive and slightly under false impressions.. It was handled at LEAST best it could be and know what? FreeBSD followed licenses even if it ended up with switching officially trademarked branding off.. OpenBSD threw a babybitch fit from the START and have basically spurred a war of disinformation in their little community and a couple of spammers to come and harass us.

Now everyone who knows me knows sometimes I don't always pick the best phrasing but with rare exception I don't try and intentionally to piss people off. There is no denying now that I could have switched a few words around added a few more "pleases" to my opening post over on GitHub.. But I didn't, however, I still don't think the response I got from OpenBSD was anywhere near on the same level as what I initially directed them to do to comply with the Pale Moon Redistribution License and YEAH it was a very fact over form opening post.. But was it the end of the world situation it evolved into? I don't think so..

In any case, I'd rather work and cooperate with FreeBSD than OpenBSD at this point.

Have a nice day!
Last edited by New Tobin Paradigm on Thu, 08 Feb 2018, 04:22, edited 5 times in total.
Image

== We got to install microwave ovens / Custom kitchen deliveries / We got to move these refrigerators / We got to move these color TVs ==
http://binaryoutcast.com/ | http://thereisonlyxul.org/

Alex12
New to the forum
New to the forum
Posts: 2
Joined: Wed, 07 Feb 2018, 21:03

Re: OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread postby Alex12 » Thu, 08 Feb 2018, 08:48

New Tobin Paradigm wrote:Here is the full story with FreeBSD as far as my interactions are concerned because mailing lists can be hard to follow.


I read this story, and it made me come here. I would like to be more clear. Since I'm also a developer, I understand your motivation - you do not want to be responsible for the code that you did not produce. A huge number of large projects, such as LibreOffice, Gnome3, KDE, firefox, chromium, VBOX, virt-manager, mythtv etc., has the "#ifdef FreeBSD ..." block in its code, and these corrections are sent by volunteers. And these projects are still called by their name. It's quite obvious that BSD (Mac OS X, Windows, etc.) are not the same systems, otherwise they will be called Linux. Somewhere there is no udev, here and there the epoll does not work, where LibreSSL is used instead of OpenSSL. I understand very well that you do not have the opportunity (resources and time) to check and write code for all platforms. And you are offered help. You want new users, but you are not ready to help yourself when you say: "If you made changes, you must rename the project."
You want to completely disengage from it. I would advise you to go to Vagrant-distribution, where you can build Pale Moon with specific compilers with certain optimization flags and, of course, with the libraries you have checked. I will not use "New Moon" in FreeBSD ports, since I can not cope with any problem on this forum. I can not write to the author of any plugin that his plugin does not work: "New Moon?" what kind of shit are you using ?! " So I think that the developers of OpenBSD in this regard did the right thing. For any problem with the "New Moon" you will send to the port manager, who will have to check this problem on the source code and act mediately, even if the problem is in the pale moon.

Also, this is a good comment:

Peter Jeremy peter at rulingia.com wrote:Most definitely. I notice that Palemoon claims to be "free software" and
links to https://www.gnu.org/philosophy/free-sw.html as a definition of "free
software". One of the "four essential freedoms" listed on that page is "The
freedom to distribute copies of your modified versions to others (freedom 3)"
- and it is precisely the exercise of that "freedom" that Matt A. Tobin is
objecting to.

User avatar
New Tobin Paradigm
Knows the dark side
Knows the dark side
Posts: 4762
Joined: Tue, 09 Oct 2012, 19:37

Re: OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread postby New Tobin Paradigm » Thu, 08 Feb 2018, 09:32

As I said before, If someone wants to apply the required fixes needed for the in-tree code for BSD it would be gladly accepted provided it is done in a cross-platform way.. Meaning the ifdefs so it doesn't bust other platforms. That way it can be compiled as intended for the target operating system.. That is what point 8 in the Redistribution License is ALL about..

But the FreeBSD/OpenBSD situation isn't about doing that.. it is about using system libs verses the libs we have in tree.. As mentioned, many of these libs must be at specific versions with specific capabilities including changed or added capabilities to our in-tree libs that are as much apart of the whole that makes up the final product as the javascript or layout engines.

Pale Moon as a product IS the Codebase.. the entire codebase and the branding as determined by the creators of the product. Point 8 allows for code changes that allow a positive build but do not result in a materially different product. Substituting in-tree libs for system libs, beyond the potential mismatch and subtle and hard to reconcile conflicts with the glue code, materially changes the nature of the end result. It's like baking a cake and using margarine, powdered eggs, and powdered milk instead of real butter, real eggs, and real milk.

You get something kinda close but it isn't the same thing.. It is something.. OTHER.. Then slapping the Pale Moon sticker on it and passing it off as something it kinda isn't is what the issue is. People are gonna consume that modified cake and it JUST isn't gonna be what they were expecting and then they will come to us about it. It may even taste HORRIBLE instead of off and guess who is blamed for that.. "This cake tastes horrible! Don't eat any of it".

That is what it boils down to. They want to distribute our cake but then want the ability to change that cake how they see fit but still use our sticker.

https://www.gnu.org/philosophy/free-sw.html wrote:Rules about how to package a modified version are acceptable, if they don't substantively limit your freedom to release modified versions, or your freedom to make and use modified versions privately. Thus, it is acceptable for the license to require that you change the name of the modified version, remove a logo, or identify your modifications as yours. As long as these requirements are not so burdensome that they effectively hamper you from releasing your changes, they are acceptable; you're already making other changes to the program, so you won't have trouble making a few more.


Wow.. People sure don't read what they cite..

Cave Johnson wrote:We're done here.
Last edited by New Tobin Paradigm on Thu, 08 Feb 2018, 09:42, edited 4 times in total.
Image

== We got to install microwave ovens / Custom kitchen deliveries / We got to move these refrigerators / We got to move these color TVs ==
http://binaryoutcast.com/ | http://thereisonlyxul.org/

User avatar
RJules3
Hobby Astronomer
Hobby Astronomer
Posts: 19
Joined: Mon, 15 Aug 2016, 05:17
Location: Germany

Re: OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread postby RJules3 » Sat, 10 Feb 2018, 09:14

New Tobin Paradigm wrote:...
People are gonna consume that modified cake and it JUST isn't gonna be what they were expecting and then they will come to us about it. It may even taste HORRIBLE instead of off and guess who is blamed for that.. "This cake tastes horrible! Don't eat any of it".

...

Cave Johnson wrote:We're done here.


Living on TrueOS (based on FreeBSD 12 CURRENT) for some time now I was very glad finding today a package of Pale Moon within the official package manager, installed it and I'm using it at this very moment. It is not the newest version but 27.6.2 64bit.
For me this cake tastes very yummy!

Is this discussion related to the package I am using now? Does this discussion mean, I will lose the just found package again soon?

User avatar
New Tobin Paradigm
Knows the dark side
Knows the dark side
Posts: 4762
Joined: Tue, 09 Oct 2012, 19:37

Re: OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread postby New Tobin Paradigm » Sat, 10 Feb 2018, 12:00

FreeBSD has temporarily stopped distribution of their Ports package until they get it reconfigured then it will continue under unofficial or whatever other branding they decide on. However, we are not going to force them to rename an already established package name (The package not the application) since that would be very disruptive to users. In any case I wish them well.
Last edited by New Tobin Paradigm on Sat, 10 Feb 2018, 12:02, edited 2 times in total.
Image

== We got to install microwave ovens / Custom kitchen deliveries / We got to move these refrigerators / We got to move these color TVs ==
http://binaryoutcast.com/ | http://thereisonlyxul.org/

vingtzwanzig
Moonbather
Moonbather
Posts: 73
Joined: Thu, 20 Apr 2017, 21:25
Contact:

Re: OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread postby vingtzwanzig » Sat, 10 Feb 2018, 14:52

https://github.com/ibara
You know ibara is a computer student at a university in NY?
I just randomly checked that. Perhaps when you shout at some young guy you might expect an unexpected response. Probably it was just some private project of his to package Pale Moon for BSD.
:roll:
Mind you, I figured a long while ago that the best way to get a virtually bulletproof browser was to use the precompiled static linked genuine one, so I see the point about libs. I suppose that's not an option for the BSD world here though. And license terms are what they are.
I'm not using any BSD but thought that fact may have been overlooked. (As a Pale Moon user I shall boycott BSD by not using it for at least the rest of this week, probably longer :D )

User avatar
RJules3
Hobby Astronomer
Hobby Astronomer
Posts: 19
Joined: Mon, 15 Aug 2016, 05:17
Location: Germany

Re: OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread postby RJules3 » Sat, 10 Feb 2018, 15:20

Thank you for your quick response New Tobin Paradigm!

It doesn't sound very promising but I will enjoy Pale Moon on my TrueOS system as long as it lasts. :thumbup:

User avatar
New Tobin Paradigm
Knows the dark side
Knows the dark side
Posts: 4762
Joined: Tue, 09 Oct 2012, 19:37

Re: OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread postby New Tobin Paradigm » Sat, 10 Feb 2018, 16:05

@vingtzwanzig

There are a handful of packagers who do a great job working with us on building Pale Moon correctly for their target distros and users. Such as deu and his gentoo overlay, or Steve and his packages for all things remotely debian, and of course khronosschoty who creates a perfect slackbuild. They all work very hard to make sure that when you see the name Pale Moon you are getting the very best Pale Moon has to offer and those packages mentioned here and a couple others are every bit as legit as the generic binary Travis works so very hard to put out.

@RJules3

You are welcome.
Last edited by New Tobin Paradigm on Sat, 10 Feb 2018, 16:11, edited 10 times in total.
Image

== We got to install microwave ovens / Custom kitchen deliveries / We got to move these refrigerators / We got to move these color TVs ==
http://binaryoutcast.com/ | http://thereisonlyxul.org/

User avatar
gracious1
Keeps coming back
Keeps coming back
Posts: 840
Joined: Sun, 15 May 2016, 05:00
Location: muggy, muggy upstate NY

Re: OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread postby gracious1 » Sun, 11 Feb 2018, 00:19

vingtzwanzig wrote:You know ibara is a computer student at a university in NY?

Wow, at Renssalaer. That's a very good university.
Image“We look forward to the time when the Power of Love will replace the Love of Power. Then will our world know the blessings of peace.” ― Wm. Ewart Gladstone

miroR
Fanatic
Fanatic
Posts: 102
Joined: Tue, 31 May 2016, 19:22

Re: OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread postby miroR » Wed, 04 Apr 2018, 21:08

Pls. see my very fresh repo (since yesterday):
https://www.croatiafidelis.hr/foss/dev1miro/
and from the discussion at:
A Pale Moon repo for Devuan/Debian
viewtopic.php?f=37&t=18805
maybe it could suffice just the post most recent (at the time of this writing):
viewtopic.php?f=37&t=18805&p=138450#p138470
( if no reply for another while, the latest post will be my mozconfig that I will offer for approval, and that one will then be not anymore the last but the before last )

New to packaging. I'm trying to comply to be able to offer Pale Moon package for Devuan (and maybe some Debian folks might find interest to try it).
Moonchild wrote:[...]
Then they still had the option to either make the changes to adhere to the license OR not use official branding but New Moon instead, and instead chose to just remove it from the portage tree.

I don't want to lose support, New Moon does not apeal to me. I want to comply.

And I'm using this topic to try and:

If anyone wants officially branded Pale Moon on...

[in my case Devuan, not on BSD]
I suggest you submit a proper portage addition that adheres to the license for official branding exceptions OR work with me to get an agreement on different build configuration if deviant build rules are desired that make it not comply with normally-accepted porting practices for packages.

I don't have any --with-system-<this-or-that> which was the case in this BSD case, but my current mozconfig does depart a lot from the default.
I'm not an expert at all, but I did some packaging occasionally and with some reliability. Serving a real repo by Debian/Devuan policy is a first in my lifetime.

I have pretty clear concepts of possible deviations from the default in my mozconfig that I would like to do next, and my question is about those.

It's in that link, and it boils down, essentially, whether it is acceptable for Moonchild Productions to allow publishing Pale Moon package, and sources, with official branding, that would have all or most of the basic default options, but also these, I believe non-default options:

Code: Select all

ac_add_options --disable-dbus
ac_add_options --disable-pulseaudio

That's the core point that I need to ask.

New Tobin Paradigm wrote:@vingtzwanzig

There are a handful of packagers who do a great job working with us on building Pale Moon correctly for their target distros and users. Such as deu and his gentoo overlay,
I did use his overlay and his ebuilds a few times back some one and a half years ago... but I'm not on Gentoo since one year ago. Devuan I use now.
or Steve and his packages for all things remotely debian,

The thing here is the departure from systemd in Devuan, which is still remotely a debian Devuan distro, that's true of course.

And because of that departure (and SSL-key logging support in the browser) I have, for months now (
see: Building Pale Moon on Devuan fails
viewtopic.php?f=57&t=15751
) been building my own Pale Moon, and since yesterday started offering it to public.

IOW, while my builds are all based on Steve Pusser's work, I need those modifications, because his packages do not provide them... And not just me, but I'd believe most other Devuan users will like it better without pulseaudio and without dbus dependencies.

Yes there is great enthusiasm in Devuan for pure alsa, so no pulseaudio, as well as freedom from dbus.

Gentoo (and likely his, essentially, derivative Funtoo, and other derivatives) are currently I believe only distros that make it possible to run machines dbus free, e.g. without any of dbus programs, including libdbus and libgdbus libraries. I'd need to check, but I think it is close to complete purge of those...

Devuan is not completely dbus free (the libraries and not easily made redundant as in Gentoo), but is aspiring to become such...

So, would those --disable-dbus and --disable-pulseaudio in my next compilation for publishing in my repo void my permission to use:

Code: Select all

export MOZILLA_OFFICIAL=1
ac_add_options --enable-official-branding

would they void it?

My next mozconfig that I would like to try and build and publish will contain all from the link (and that is a paste):

http://developer.palemoon.org/Developer ... nfig_Files

Code: Select all

ac_add_options --enable-official-branding
export MOZILLA_OFFICIAL=1
 
mk_add_options MOZ_CO_PROJECT=browser
ac_add_options --enable-application=browser
 
mk_add_options MOZ_OBJDIR=/home/$USER/pmbuild/
 
ac_add_options --enable-optimize="-O2 -msse2 -mfpmath=sse"
ac_add_options --with-pthreads
 
ac_add_options --disable-installer
ac_add_options --disable-updater
 
ac_add_options --enable-release
ac_add_options --enable-devtools
ac_add_options --enable-jemalloc
ac_add_options --enable-shared-js
 
ac_add_options --enable-strip
 
ac_add_options --x-libraries=/usr/lib


Plus, I'd also include these lines:

Code: Select all

ac_add_options --disable-dbus
ac_add_options --disable-pulseaudio


and also:

Code: Select all

ac_add_options --enable-alsa


These I would like to include too (however, I could go without them, but may not have enough knowledge at this time about them and the alternatives, nor what the defaults would be if these are not included :-( ... ):

Code: Select all

ac_add_options --prefix=/usr
ac_add_options --enable-ffmpeg
ac_add_options --enable-fmp4
ac_add_options --enable-freetype
ac_add_options --enable-ogg
ac_add_options --enable-opus
ac_add_options --enable-png
ac_add_options --enable-svg
ac_add_options --enable-wave
ac_add_options --enable-webgl
ac_add_options --enable-webm


And in case it would prove necessary I would also include:

Code: Select all

ac_add_options --disable-precompiled-startupcache

but only if necessary.

I would really like to disable, if I may:

Code: Select all

ac_add_options --disable-safe-browsing

because (IIRC, that's google) it's more than anything an excuse for another bit in their mass surveillance, like most things google.

IIUC, would a mozconfig based on the above be acceptable to remain with official branding?
If not, what alternatives can you suggest?

Thank you for your kind consideration!
Last edited by miroR on Wed, 04 Apr 2018, 21:11, edited 1 time in total.

User avatar
SlySven
New to the forum
New to the forum
Posts: 2
Joined: Sat, 07 Jul 2018, 22:42

Re: OpenBSD & Pale Moon: coordinating patches and officially branded package?

Unread postby SlySven » Sun, 14 Oct 2018, 02:35

I am a fairly recent convert to PaleMoon since I could see the writing on the wall with FF switching off the old add-on XUL(?) system and driving itself towards being more Chromelike - except, if I wanted a webkit based Chrome-like browser I'd probably use, um, Chrome...

Anyhow my Windows and GNU/Linux systems are gradually being changed over to PM, and now I've also moving my FreeBSD Desktop/Development machine over to it (or rather the New Moon version). I came across this spat between PM and OpenBSD and as I see it this seems to be a case of the immovable object meeting the irresistible force!

Looking at https://en.wikipedia.org/wiki/Compariso ... ilosophies one can see that OpenBSD really emphasises security and auditing of its code-base and libraries - so PaleMoon's need to have it's own in-source possibly customised copies of what would be considered system libraries to meet its specific needs/functionality is going to be a point of strong contention; OpenBSD is going to want to build against the versions of the libraries that it has audited and know to be secure but those are not always going to be what PaleMoon wants to have available across the range of OSes that it is ported to. Conversely it may be that for performance reasons PM would like to compile with optimisations or options that are enough for it to work reasonably fast or efficiently but which have corner cases or minor vulnerabilities that are not likely to be encountered in reasonably normal situations but which OpenBSD holds to not be robust in every conceivable situation and which would impose a responsiveness hit were PaleMoon to work to accommodate them.

It is sad that this does seem to have led to the use of language that I would not personally call assertive between the two sides, the making of a demand rather than a firm request as the opening approach seems way too aggressive to me - I can see now that there are explicit terms and conditions related to branding the application as "The PaleMoon Browser" so you could be said to have the moral high ground but this could have been handled better - after all, who benefits from the current situation? OpenBSD doesn't and although PaleMoon has protected it's brand-integrity I guess it has missed out on linking up with a small number of user that include some people who are all-over making applications more secure and robust against malicious third-parties. As a user I can only see other browsers, {probably with non-Mozilla origins :twisted:}, standing to gain from this - oh and it is really un-great publicity for both OpenBSD and PaleMoon.

Just the 2 pence of a slightly (after all I am on FreeBSD not OpenBSD ;) ) disappointed user...

:thumbdown:

Also - to the previous poster - I am also moving away from a (Sys V init) Debian to Devuan on some of my Linux boxes - so I look forward to seeing your work come to fruition! :clap:
Last edited by SlySven on Sun, 14 Oct 2018, 02:42, edited 1 time in total.


Return to “Development (discussion)”

Who is online

Users browsing this forum: No registered users and 4 guests