Pale Moon for Linux Ubuntu PPA

[Night Wing]

if there is a deb package for manual download I would rather use that one than the tar ball.

This is my preference also. This is why I will wait for the deb. If it never comes about, then I'll just keep using the "extract & run" method which doesn't install linux Pale Moon. Using gui windows, it is easy for me to make the PM launcher icons for the "extract & run" method.

[Moonchild]

We do have plans to offer automatic updates for Linux from within Pale Moon, but that will obviously be something that has to be disabled for these PPAs in that case (or any similar targeted source build).

Any such builds will have to provide their own updates through a different mechanism (the PPA itself would be such a mechanism). So it must be specifically configured to not include the updater:

Code: Select all

ac_add_options --disable-updater

And it also can't include --enable-update-packaging because that will automatically re-enable the updater

[SvenG]

We do have plans to offer automatic updates for Linux from within Pale Moon,

That would also make deb or rpm packages repacked from the official builds a bit problematic if "within Pale Moon" really means "within Pale Moon". Also having applications update themselves isn't really Linux. Purists, actually, consider everything that bypasses the native install ways as suspect, radicals doom everything that doesn't come through official repos. Having a popup or something to notify the user about the new version that can either start pminstaller (or a striped down updater) or open the download page would be enough and people can still decide what to do.

But, yes, for packages that are provided through other repos that should be disable, could lead to additional confusion.

[squarefractal]

We do have plans to offer automatic updates for Linux from within Pale Moon, but that will obviously be something that has to be disabled for these PPAs in that case (or any similar targeted source build).

The thing is that most users will have installed PM in a location not readable by others except root; and you wouldn't want people to run the browser as root...

[Moonchild]

The thing is that most users will have installed PM in a location not readable by others except root; and you wouldn't want people to run the browser as root...

Hmm.. I thought Linux had a way to elevate a process as well. If not, then it's a scratch.

[Moonchild]

That would also make deb or rpm packages repacked from the official builds a bit problematic if "within Pale Moon" really means "within Pale Moon".

Would it? ...

From a browser point of view it makes no difference what type of archive it was installed from. It'd be able to update itself just fine after initial installation.
Unless, of course, the problem is that the packages are indexed in a manager, and the manager doesn't know that the browser was updated -- I see your point in that case.

I guess it'd be better to keep Linux on either manual/installer or package manager update routines. Not ideal, but less problematic. It does mean that the package maintainers need to stay on the ball

[New Tobin Paradigm]

In all likelihood the installer/tarball version will gain the ability for the built-in internal updater to start getting updates so you won't have to run the installer and do it manually.

However, any system package versions should NEVER have that enabled.

[SvenG]

Unless, of course, the problem is that the packages are indexed in a manager, and the manager doesn't know that the browser was updated -- I see your point in that case.

You, got it fren! It would bypass the package management and that would make the deb/rpm/XXX packages pointless.

[trava90]

Last I knew the Firefox for Linux binaries available directly from Mozilla do use the internal updater. It is the distro package maintainers who disable the updater as mentioned above. Also, it is recommended to never have both the binary from Mozilla and the distro's Firefox package installed at the same time. When/if we get internal updates on Linux going, it would be no different. The offical binaries from us would use the internal updater, while distro packages such as the ones in the AUR, PPA, PCLinuxOS repo, etc. (if installed instead) would continue to use the system's package manager for updates.

[SvenG]

I think before we discuss the updater option any further (maybe in its own thread since it leads away from the PPA topic) someone should first present a few details on how it will or could be implemented. Maybe it is also possible to work around some issues. For a deb package it would be possible to run dpkg -l to evaluate the presence of Pale Moon in the package management, in case it is present, that could open the download instead of running a direct update. I am fairly sure something similar exists for rpm. That's where package management comes in handy, it should know everything.

I haven't used the Mozilla packages in ages, so I have no idea, how they are doing it.

By the way, I have searched a bit yesterday, and there are a couple of attempts and requests to get Pale Moon into distribution specific (official/community/user) repos. It's really sad that most of them do not try to work with us. I am fairly sure that it would be much easier if people would work together instead of cooking their own soup. If somebody made a build for one Debian based system it will not be that different for other Debian based systems, no need to reinvent the wheel over and over again for systems that differ only slightly.

[stevenpusser]

For what it's worth, we've been building Debian Wheezy and Jessie compatible deb packages for the MEPIS 12 and MX 15 repositories; I'm pretty sure they would be Ubuntu-compatible. I do have to extract the raw source .7z archive and fix the permissions before compressing the source back into an .orig.tar.xz file.

http://main.mepis-deb.org/mepiscr/testr ... /palemoon/
http://main.mepis-deb.org/mx/testrepo/p ... /palemoon/

(Building 25.6.0 right now, just takes quite a while on my laptop)

The debianization was just copied from the apparently now defunct PPA, so these packages are compiled from the source code, not just repackaged from the Palemoon binaries. We do debianize Mozilla's precompiled static Firefox, Thunderbird, and Seamonkey binaries, plus their language packs, if anyone wants to use that debianization as a template for packaging the Pale Moon binaries:

http://main.mepis-deb.org/mepiscr/repo/ ... f/firefox/

Just packaging the binaries takes about 1/1000 as long as building from source...

[SvenG]

For what it's worth, we've been building Debian Wheezy and Jessie compatible deb packages for the MEPIS 12 and MX 15 repositories; I'm pretty sure they would be Ubuntu-compatible.

http://main.mepis-deb.org/mepiscr/testr ... /palemoon/

This one installs on Trusty but it also seems to be lacking the Statusbar options. Marian had that iussue as well viewtopic.php?f=37&t=7886
And it also feels a bit odd, can't exactly say, what it is.

[stevenpusser]

Yeah...it may need to be built natively on Ubuntu to really work correctly. Though the quick 'n' easy fix would just be to package the existing prebuilt Palemoon binaries like we do for the MEPIS Firefox mozillabinaries, that way you get the easy install, the menu entries, adding it to the alternatives for x-www-browser, etc. automatically.

[SvenG]

Yeah...it may need to be built natively on Ubuntu to really work correctly.

Sure that the statusbar issue does not exist on your distro?

Though the quick 'n' easy fix would just be to package the existing prebuilt Palemoon binaries like we do for the MEPIS Firefox mozillabinaries, that way you get the easy install, the menu entries, adding it to the alternatives for x-www-browser, etc. automatically.

We have already checked that option, I used a2g's isomer script
https://github.com/access2godzilla/isomer
to convert the last two releases to deb packages and it works kinda nice. Just needs somebody who is willing and able to do that on a regular basis. I would be willing but I am not able to do it regularly. Still in the longer run a PPA would be nice for the Ubuntu/Mint market.

[stevenpusser]

Yeah...it may need to be built natively on Ubuntu to really work correctly.

Sure that the statusbar issue does not exist on your distro?

Yes, it does appear that statusbar problem does appear in our builds, in packages built with both gcc 4.7 and 4.9, so it's not due to that. The scaling problem in the referenced thread does not, though.

Our Firefox packages include a mechanism to pull the i386 and amd64 Mozilla binaries from the Mozilla binaries; it's the get-orig-source target in the debian/rules file, and it uses the debian/watch files. It's executed with

Code: Select all

debian/rules get-orig-source

(we use the same thing for the language packs, which sure beats manually downloading 100 of those!)

and you end up with the latest Firefox orig.tar.xz source package containing both sets of binaries, then the build process creates an appropriate deb file for each architecture. This could be adapted to work with Pale Moon.

[SvenG]

Yeah...it may need to be built natively on Ubuntu to really work correctly.

Sure that the statusbar issue does not exist on your distro?

Yes, it does appear that statusbar problem does appear in our builds,

In case you can't figure it out, it is best to ping Trav(a|is) about it.

Our Firefox packages include a mechanism to pull the i386 and amd64 Mozilla binaries from the Mozilla binaries; it's the get-orig-source target in the debian/rules file, and it uses the debian/watch files. It's executed with

Code: Select all

debian/rules get-orig-source

(we use the same thing for the language packs, which sure beats manually downloading 100 of those!)

and you end up with the latest Firefox orig.tar.xz source package containing both sets of binaries, then the build process creates an appropriate deb file for each architecture. This could be adapted to work with Pale Moon.

I have to admit, that sounds good but it's far beyond my current horizon of knowledge, so I need to do some reading. But if I got that right, it is an automated process which would be pretty cool. It's a bit unfortunate, that we do not (yet) have an expert on the Debian/Ubuntu field here.

[C1xLb]

Looking into the PPA again, this tutorial looks useful http://www.stellarium.org/wiki/index.php/Creating_a_Ubuntu_PPA_package.

It seems to suggest that once you've got the source and a few other bits copied and edited from steps 6 and 7, it looks pretty straightforward. It also appears that launchpad builds the deb files from source rather than needed to create a deb file locally and then upload it.

Interestingly, it looks like the original PM source tar file in the PPA is the PM source itself, without anything changed which might make getting this PPA going a little bit easier than first thought.

I'm planning to return to this later but I wonder if anyone else has any more thoughts or ideas?

[Moonchild]

Since there's obviously been some confusion about making PPAs of Pale Moon lately (specifically with user omitooshi), I'm hoping the following will clarify things:

1. Since there is a Linux variant of Pale Moon already, these official binaries take precedence over any PPA.
2. Because of (a), if you have a PPA build binaries and then offer those up for different flavors of Ubuntu, you can't have them with the official branding unless it's OKed by me. I don't usually make a big deal out of this, but you should at least run the build configuration and any preference or other changes by me and if good, then I will add you to the contributed builds page.
3. If you do build with official branding, do not arbitrarily reconfigure the browser! This is a no-go for official branding. If you want to make "your own configuration", then use unofficial or your own (significantly different) branding (name and graphics) on the PPA. This is nothing strange in Ubuntu-land, see also Iceweasel vs. Firefox.
4. This also means that if you plan to publish any binary for others, even test versions, you should never use --enable-official-branding on it unless it's OKed by me.
5. To clarify: even though the source code is released under a FOSS license, you obtain no rights to the included official branding. This is clearly stated in the licensing of the source and also gestured at in the Linux build instructions. This also means I stay in control of binaries carrying this official branding and you can't treat it as public domain. Pale Moon™ is a trademark under my control and you can't just use it for your own builds because it's included in the source. If I don't agree with the way you build the browser, you can't put the official branding on it.

I definitely welcome the efforts to create and maintain .deb packages and PPAs, but please do respect our wishes for some quality control and being able to provide a proper and as-intended experience to all users of the browser, regardless of OS or distro.

[C1xLb]

Since there's obviously been some confusion about making PPAs of Pale Moon lately (specifically with user omitooshi), I'm hoping the following will clarify things:

• This also means that if you plan to publish any binary for others, even test versions, you should never use --enable-official-branding on it unless it's OKed by me.

Sounds cool with me, if I get back to the PPA, I'll ask for permission!

[Thrawn]

Unless, of course, the problem is that the packages are indexed in a manager, and the manager doesn't know that the browser was updated -- I see your point in that case.

You, got it fren! It would bypass the package management and that would make the deb/rpm/XXX packages pointless.

This is the number one reason I'm still not using Pale Moon myself. Installing outside the package management system means you have to manually maintain it outside the package management system. Blech. That's so 2000s.