This adds support for building firefox with the gtk wayland backend. It
should work on all the flavors that use >=gtk3. Using the wayland
still allows using the X11 backend.
It works, but this state is far from ideal: GNU guys update generated source
tarballs very infrequently. Ideally, src needs to be generated by running
makeicecat over firefox src. Will do later.
Firefox >=65 will depend on icu >=63. All the older firefox versions
(and derived packages) seem to work fine with this change.
Also the system path environment patch will fail to apply since there
was a trivial whitespace change in the source file. By adding `-l` to
patch we can avoid having to track two patches that do basically the
same. Having patchFlags per file without resorting to pre-/postPatch
would be nicer but there doesn't seem to be a facility for that right
now.
Misc cleanups, but mainly this:
Before:
- `version` could mean either Firefox or TorBrowser version,
- `configureFlags` was hacky.
Now:
- `ffversion` is Firefox version, `tbversion` is TorBrowser version,
- `configureFlags` is much less hacky.
Fixes#30285
Some things done:
- Add macOS frameworks needed
- Fix RUST_BINDGEN handling. We need to pass all of NIX_CFLAGS_COMPILE
to rust bindgen
- Add custom install phase for darwin
Since firefox 58.0.1 the google api key is now stored at an absolute
path ($TMPDIR/ga). Since variable expansion in `configureFlags` does not
really work (as expected) the build started failing when using the
legacy firefox build system. With the newer `./mach` based builds
firefox reads the configure flags from `.mozconfig` instead.
This commit moves the `with-google-api-keyfile=` setting into the
`preConfigure` phase where we can properly expand `$TMPDIR` into
whatever the path is.
As stated by Sylvestre Ledru (@sylvestre) on Nov 22, 2017 at
https://github.com/NixOS/nixpkgs/issues/31843#issuecomment-346372756 we
have permission to use the official firefox branding.
Fur purposes of documentation the statement of @sylvestre:
> As the person who did part of the work described in the LWN article
> and release manager working for Mozilla, I can confirm the statement
> that I made in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006
>
> @garbas shared with me the list of patches applied for the Nix package.
> As they are just for portability and tiny modifications, they don't
> alter the experience of the product. In parallel, Rok also shared the
> build options. They seem good (even if I cannot judge the quality of the
> packaging of the underlying dependencies like sqlite, png, etc).
> Therefor, as long as you keep the patch queue sane and you don't alter
> the experience of Firefox users, you won't have any issues using the
> official branding.
This reverts a part of commit 559433d0db.
The problem with removing those options completely is that without them
tor-browser's config differs from the official config (which may or may
not be a problem for fingerprinting).
Broken since #30143.
I can't say I understand why this combination is apparently unsupported.
i686-linux is a second-tier platform now, but firefox is still kept a
channel blocker...
