Update greenlet to 1.0.0.
meinheld declares a dependency to greenlet <0.5, but according to [1]
and [2], there are no API or ABI changes leading to greenlet-1.0.0, so
it seems reasonable to drop the strict requirement. This commit
uses substituteInPlace to patch setup.py since no upstream commit has
landed in the main branch yet.
Morehover, quoting [2]:
Prior to greenlet 1.0 there were no semantic meanings attached to
greenlet versions — API and ABI regularly changed from 0.4.x
to 0.4.x+1, so their current pin doesn't make much sense anyway.
nix-review reveals few broken packages that are also broken in master.
[1] https://github.com/mopemope/meinheld/pull/123
[2] https://github.com/benoitc/gunicorn/issues/2541#issuecomment-800353993
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.
sternenseemann