Chromium Flatpak package uses flatpak-spawn command for sandboxing
the child processes. The command comes from flatpak-xdg-utils, which is
presumably included in Flatpak runtimes. The command then calls Spawn
method of the portal.
The portal supports running commands in a clear environment when passed
FLATPAK_SPAWN_FLAGS_CLEAR_ENV flag. Unfortunately, that also clears PATH,
which is probably what prevents `flatpak` command itself from being found.
There is a relevant TODO note in the code:
https://github.com/flatpak/flatpak/blob/1.10.2/portal/flatpak-portal.c#L995-L999
For now, let’s hardcode the path to the binary.
The website generates a ZIP archive with fresh TTF files for each download,
which will have different “modified” field in the TTF metadata each time.
This makes `requireFile` useless as the ZIP file will not have a static hash.
Instead, let’s make user accept the license in Nix and download the file for them.
Then, we can post-process it and hopefully achieve a somewhat fixed output.
This is still not really reproducible since:
- the font can be updated (last update in 2015)
- the fonttools used by the server can be updated to one producing a different output
- the fonttools used by this package can be updated
- the fonttools might actually be non-deterministic
But hopefully these events are rare so it will be more stable than the ZIP produced by upstream,
which changes every time. When that happens, we can always just update it like we did before.
We do not need to worry about cache since the package is unfree.
I also added myself as a maintainer.
Nixpkgs hasn't supported grsecurity kernels since 2017, so unless
anybody is manually enabling the grsecurity feature to make these
small kernel tweaks this is dead code.
This means we don't actually support any "features" in the kernel
common-config any more, but I've left the argument there because it's
conceivable we could have some again in future.
