palemoon: possible improvement

OPNA2608 commented 3 years ago

Tracking things I've noticed that can/should be improved about the Pale Moon package, because I keep forgetting about them otherwise. May add more things as I remember/notice them. Feel free to chime in if you have opinions about anything here, unlike FF the PM packaging is a solo task done by me :sweat_smile:.

Fix WebGL (broken for me) Done?

It used to work on my previous system (Nvidia GPU & nvidia), it's been broken ever since I switched to my new system (AMD GPU & amdgpu) & updated my system. This is specific to PM, FF still works.

The problem appears to be that the OpenGL driver is linked against GCC9 while PM is pinned to a GCC8 stdenv.

  palemoon = callPackage ../applications/networking/browsers/palemoon {
    # https://developer.palemoon.org/build/linux/
    stdenv = gcc8Stdenv;
  };

Trying to load the driver's library through PM causes an error with mesa. Looks \~ like this when launching palemoon from the terminal:

libGL error: MESA-LOADER: failed to open radeonsi […]
libGL error: failed to load driver: radeonsi
libGL error: MESA-LOADER: failed to open radeonsi […]
libGL error: failed to load driver: radeonsi
libGL error: MESA-LOADER: failed to open swrast […]
libGL error: failed to load driver: swrast

Dropping the stdenv override fixes WebGL support for me. Upstream would most likely prefer a compiler they've tested more thoroughly, but GCC9 will work too.

GCC versions 4.9, 5.x, 7.x, 8.x, 9.x or 10.x

GCC 6.x is not at all recommended and has been known to produce unstable binaries. It has been reported that Debian-based GCC 6.x seems to produce stable enough binaries. Your mileage will vary, of course.

GCC 9.x and 10.x are still considered experimental at this time, however, they have thus far produced stable binaries.

Reduce package size Done-ish

The current install process seems to install alot of SDK-related stuff, as mentioned in https://github.com/NixOS/nixpkgs/pull/115352#issuecomment-792350155. I think we can get rid of that, similar to how the FF derivation gets rid of it for now. I have doubts that anyone is using these SDK files but I can try moving them to a dev output without breaking the package. (Emphasis on try though)

https://github.com/NixOS/nixpkgs/blob/1c7f02b0b9f115ccbc122ce39ae99debc1af857a/pkgs/applications/networking/browsers/firefox/common.nix#L294-L296

Add branding & custom config option

The current hardcoded configuration should be fine for official branding. I asked the devs on their forum awhile ago and they said it looks fine to them. (I'll try to find that thread / response again and link it in a derivation comment for clarity on that matter, similar to FF does it)

That said, options to disable the official branding (maybe with user-supplied branding?) and use a custom .mozconfig build configuration could be useful for users interested in personal modifications. I was abit wary about this idea so far & considering to implement some logic to automatically disable the branding, but I think it wouldn't be our responsibility to enforce the branding's license anymore when the user themselves willingly changes the default build configuration we implement?

Plus, disabling the official branding would let us link against our system libraries instead of upstream's vendored ones, at our own responsibility. I seem to remember that even the de-branded icons etc are supplied with the expectation that we replace them? Definitely gonna look more into that before trying to add any --with-system-* options though :sweat_smile:!

I think all of that would be best implement by having a generic build expression, with palemoon (official branding) and newmoon (without) extending them with their package name, .mozconfig file, (custom branding?) etc.

Add binary package variant

Similar to FF. Add a palemoon-bin package - upstream's binary release patched & wrapped for Nixpkgs users. I had a private version of this at some point to debug something and I believe the required changes were limited to patchelfing the ELF interpreter to our non-FHS location and wrapping the binary so all of the required libraries are in its LD_LIBRARY_PATH / rpath. That should be fairly uncontroversial IMO, but I still want to ask upstream if that's fine to avoid any redistribution problems post-merge.

A -bin package could really help me with debugging a problem our from-source palemoon may be having. I'm unsure if it's anything specific to my package or something else yet, so having upstream's proved-good version for comparison would be a great help.

OPNA2608 commented 3 years ago

Fixed WebGL in #120930.
Reduced package size in #120930. We're deleting the SDK files for now, but we should ask upstream if they are of any use to e.g. plugin developers.

OPNA2608 commented 3 years ago

Should prolly also add requiredSystemFeatures = [ "big-parallel" ]; to the derivation. Takes >2½h on Hydra with just 2 cores:

150:37.24(B We know it took a while, but your build finally finished successfully!

stale[bot] commented 2 years ago

I marked this as stale due to inactivity. → More info

athas commented 1 year ago

Package dropped in #232571.

NixOS / nixpkgs