* Regenerated all patches for 1.4.2 and resolved
any conflicts.
* fix-test-paths.patch doesn't copy the whole locale archive
because we have C.UTF8 now.
* nixos/flatpak creates a Flatpak system helper user
Change introduced in 1.3.2.
Changes:
See https://github.com/flatpak/flatpak/releases/tag/1.3.1 through
1.4.2.
This improves what commit
e999def1 zlib: clean up static/shared distincion
described as "kind of a mess" and "confusing". And indeed it was confusing.
Now, the concept whether or not the .a file is moved to a split output
is controlled by a clean variable.
The defaults remain unchanged.
The new approach also finally cleanly allows building statically but NOT
using a split output, like all other autoconf-based projects in nixpkgs do
(using the `dontDisableStatic` setting).
That is important for overlays that want to enable static libs for all
packages in one go, without having to hand-patch idiosynchrasies like zlib
had until now.
Until now, if you wanted the .a in the main output, the only way was to go via
`static=false, shared=true` -- which made no sense, because you had to say
`static=false` even though you want a static lib. That is fixed now.
pyprof2calltree is hard-coded to pythonPackages and fails for Python 3 profile results. See #66511.
Since it can also be used as a library it makes sense to move it into pythonPackages.
* Tested the package build
- *NOT* tested the packages relying on capstone...
* Added `setupPyBuildFlags` to avoid the error
"ERROR: capstone-3.0.5.post1-py3-none-manylinux1_x86_64.whl is not a
supported wheel on this platform."
The shebang in the python stub template was incorrectly patched to
```
<store-path>/bin/env python
```
instead of
```
<store-path>/bin/python
```
The reason was that `patchShebangs` was called with `--replace` which is
an unknown argument.
```
patching script interpreter paths in src/main/java/com/google/devtools/build/lib/bazel/rules/python/python_stub_template.txt --replace /usr/bin/env python /nix/store/w7gsq8v86hni4ynaqgwwlnlny115ylng-python3-3.7.4/bin/python
find: unknown predicate `--replace'
```
Using `substituteInPlace` instead resolves that issue.
The wrong shebang caused failures of `py_binary` targets due to `python`
not being in `PATH` in certain circumstances.
Now that our MACOSX_DEPLOYMENT_TARGET is set to 10.12, we shouldn't be
hardcoding the platform at build time as 10.10. This change makes it
inherit the MACOSX_DEPLOYMENT_TARGET value.
