32bit and gtk2 builds for Debian/Bookworm

[andyprough]

And let's not forget about my own little distribution project, which is the main reason for me to provide those gtk2 based palemoon builds in the first place:

https://wmlive.sourceforge.net

Absolutely! Yours should be the first 32-bit Debian-based distro we reach for. Also, what is your plan for providing gtk2 as Debian drops those packages prior to the Forky release in 2027?

[wmlive]

Also, what is your plan for providing gtk2 as Debian drops those packages prior to the Forky release in 2027?

There are no plans whatsoever as long as we are still in 2026, and i will start looking into the actual situation once Forky hopefully arrives in 2027.

It might possibly become necessary to provide suitably compiled gtk2 binaries for forky via the wmlive repo, although i'd prefer to avoid the extra work.

Maybe someone else suddenly appears who actually commits to keep maintaining gtk2 so we could just reuse that. Time will tell.

Since this all largely depends on chance circumstances not under our control, appropriate action will only be taken when the time arrives.

If sticking to gtk2 should reveal itself as being too effortful or time consuming, i'd supposedly just drop it in favour of gtk3.

[Basilisk-Dev]

I've been a little worried that if we intend to support GTK2 on current distros, then at some point we might need to vendor GTK2 into our repo. I haven't looked into it or opened a repo issue or anything, but it's something that I've had in my mind for a few weeks since I switched my desktop back to Linux.

[frostknight]

I've been a little worried that if we intend to support GTK2 on current distros, then at some point we might need to vendor GTK2 into our repo. I haven't looked into it or opened a repo issue or anything, but it's something that I've had in my mind for a few weeks since I switched my desktop back to Linux.

I wonder how much resources gtk2 uses compared to gtk3.

Probably not much different if i had to guess.

If nothing else though, having it available as source code in your repository might be wise for both you and moonchild.

Although whether its needed or not, I don't know.

[wmlive]

Packages for palemoon 34.2.0 compiled with gtk2 for amd64/arm64/i386 have been uploaded to https://wmlive.rumbero.org/repo/pool/main/p/palemoon/ .
Variants for bookworm are distinguishable by the subrelease version 0wmlive0, and those for trixie by the subrelease version 0wmlive1.

[Moonchild]

at some point we might need to vendor GTK2 into our repo.

We can't reasonably do that. If not for the technicalities of it, then for the legalities, as I think it would be licensed incompatibly with our licensing for the code base.
If it comes to that, then we'll unfortunately have to drop GTK2 support (and as a consequence, plugin support) on Linux.

[moonbat]

and as a consequence, plugin support

Why?

[athenian200]

Why?

Off-topic:
Essentially, every NPAPI plugin ever created for Linux was compiled against GTK2 (aside from some much older ones compiled against Motif). If we remove the GTK2 requirement for NPAPI on Linux, then plugins behave unpredictably:

1. They may crash the browser if they were compiled against GTK2 and the browser does not have GTK2 symbols available for it to hook into.

2. The plugin may fallback to Xlib or Motif (not ideal).

3. The plugin may just silently fail without telling users why.

4. The plugin may work, if it has no GUI and no user-facing controls, and thus wasn't compiled against GTK2, but this would be fairly rare.

We seem to safely handle the case where the browser's plugin component was built with GTK2 symbols available, but the system doesn't have it. In that case, plugins just reliably fail to work but in a way that doesn't crash anything, I think.

That's why I reluctantly implemented MOZ_DISABLE_NPAPI as an option a few years ago. People are already using it to build the browser on GTK3-only systems where GTK2 isn't available. The other thing that's worth mentioning is... on non-x86 architectures, especially newer ones, plugin support doesn't really do anything because NPAPI plugins were never built for those platforms to begin with.

About the only way I can think of to "save" NPAPI on Linux is to use something like the old Pipelight project with Wine somehow to run the Windows version of the plugin on the Linux version of Pale Moon, and at that point you might just as well use the Windows version of Pale Moon in Wine (a configuration we don't officially support, by the way). There are a few projects that create their own NPAPI plugins that don't link against GTK2, and that might be another path forward, but it would require us adopting the exact same mentality with regard to NPAPI that we do with XUL extensions... that if it's not updated and maintained, you can't expect it to work, and I don't think that would go over well. Plus it would potentially confuse users of Windows where the old plugins would continue to work as normal, and they wouldn't see the need to stick with maintained NPAPI plugins over official versions. When people think NPAPI, they think of popular plugins that haven't been updated in years and will expect them to work if we claim support.

But anyway, my suggestion if you want to keep NPAPI on Linux is to revive and fork Pipelight, get it working with Pale Moon and some version of Wine, package it up so people can use it, and if needed submit patches so we can use that. Then, we can keep Linux NPAPI support in some form. But seriously, Linux NPAPI support is one of the forces keeping the GTK2 albatross tied around our necks. A lot of Linux users also prefer the way it looks aesthetically with some themes and will not be happy if it's dropped in favor of GTK3, especially given how GTK3 looks in our tree. Linux is a very frustrating platform with regards to how often APIs change and backwards incompatibilities combined with viral GPL licensing making maintaining older stuff untenable. Although I personally think it's not worth even considering dropping GTK2 unless we find something better than GTK3 to replace it with (GTK3 is already getting kind of old at this point). People don't like that version of the browser, and sometimes it really feels like the Windows version is moving forward while the Linux version is still stuck in 2017 with Firefox 52...

[Basilisk-Dev]

Off-topic:
I don't think we should drop GTK2 support or NPAPI even if Linux distros are dropping support for GTK2. More experienced users will always be able to compile their own GTK2 if they truly need the GTK2 UI or NPAPI plugins. Even then, when we inevitably in a few years have to switch to an RHEL9 based distro for builds, GTK2 is still available for that OS as well. Same with RHEL10.

The other thing that's worth mentioning is... on non-x86 architectures, especially newer ones, plugin support doesn't really do anything because NPAPI plugins were never built for those platforms to begin with.

It definitely does do things. I had to make a few small patches in UXP, but I am using a modified personal fork of the LightSpark Adobe Flash NPAPI plugin on LoongArch, an architecture which did not even exist until after NPAPI was deprecated. It does not require GTK 2 or 3 at all. It uses SDL2.

[athenian200]

Off-topic:
I don't think we should drop GTK2 support or NPAPI even if Linux distros are dropping support for GTK2. More experienced users will always be able to compile their own GTK2 if they truly need the GTK2 UI or NPAPI plugins. Even then, when we inevitably in a few years have to switch to an RHEL9 based distro for builds, GTK2 is still available for that OS as well. Same with RHEL10.

It definitely does do things. I had to make a few small patches in UXP, but I am using a modified personal fork of the LightSpark Adobe Flash NPAPI plugin on LoongArch, an architecture which did not even exist until after NPAPI was deprecated. It does not require GTK 2 or 3 at all. It uses SDL2.

Off-topic:
You make good points, Basilisk-Dev. Yeah, we would definitely keep NPAPI on non-Linux regardless (I think that's a settled question), but the RHEL10 support for GTK2 was kind of my concern here since I don't think they have GTK2 in the official repos. I was originally thinking of decoupling GTK2 from NPAPI at some point so that people don't have to disable it entirely to build on non-GTK2 systems, but a few years ago it seemed like there was no reason to do that given that all extant Linux NPAPI plugins were built against GTK2 and there were fears of user confusion if they tried to build NPAPI without GTK2 and most plugins were broken. LightSpark does seem like a good argument in favor of keeping NPAPI around on Linux. Granted, a non-GTK2 NPAPI build would support very few plugins, but it would still support some, as the protocol itself doesn't require it. Overall, I don't necessarily want to remove GTK2 (it really wouldn't simplify our code much because the GTK2 stuff is mostly off in its own directories), but I would prefer to minimize our dependency on it as much as possible, and maybe move official support to a different emphasis at some point because I don't think it will be easily accessible forever.

[Basilisk-Dev]

Off-topic:

but the RHEL10 support for GTK2 was kind of my concern here since I don't think they have GTK2 in the official repos.

It’s in EPEL on RHEL10

[frostknight]

Honestly, if it comes to it, leave gtk2 option in, but say:

"you are on your own"

Rather than rip it out entirely.

[wmlive]

Packages for palemoon 34.2.1 compiled with gtk2 for amd64/arm64/i386 have been uploaded to https://wmlive.rumbero.org/repo/pool/main/p/palemoon/ .
Variants for bookworm are distinguishable by the subrelease version 0wmlive0, and those for trixie by the subrelease version 0wmlive1.

[wmlive]

Packages for palemoon 34.2.2 compiled with gtk2 for amd64/arm64/i386 have been uploaded to https://wmlive.rumbero.org/repo/pool/main/p/palemoon/ .
Variants for bookworm are distinguishable by the subrelease version 0wmlive0, and those for trixie by the subrelease version 0wmlive1.