Related:
- 9fc5e7e473
- 593e11fd94
- 508ae42a0f
Since the last time I ran this script, the Repology API changed, so I had to
adapt the script used in the previous PR. The new API should be more robust, so
overall this is a positive (no more grepping the error messages for our relevant
data but just a nice json structure).
Here's the new script I used:
```sh
curl https://repology.org/api/v1/repository/nix_unstable/problems \
| jq -r '.[] | select(.type == "homepage_permanent_https_redirect") | .data | "s@\(.url)@\(.target)@"' \
| sort | uniq | tee script.sed
find -name '*.nix' | xargs -P4 -- sed -f script.sed -i
```
I will also add this script to `maintainers/scripts`.
There are a variety of additional scripts that are included with the
JRuby installation that use JRuby itself.
For instance the `bin/gem` had the following contents:
```bash
❯ cat /nix/store/kglkqf56ii83yl6yrgcaj5r3s9m2fzr0-jruby-9.2.13.0/bin/gem
load File.join(File.dirname(__FILE__), 'jgem')
```
This is clearly wrong. Patchshebangs was not picking up the fix as part
of stdenv because the patch is not a build input but the final output
itself.
We have to rely on substituteInPlace so that we get the correct version.
```bash
❯ cat /nix/store/k4fnrn0dcsh2wzw81217r0ywsspb468f-jruby-9.2.13.0/bin/gem
```
fixes c88f3adb17, which resulted in
qt 5.15 being used in pythonPackages, despite 5.14 being
declared, and adapts qutebrowser accordingly.
'callPackage { pkgs = pkgs // { … }; }' does not work, because
it does not take into account the recursive evaluation of nixpkgs:
`pkgs/development/interpreters/python/default.nix` calls
`pkgs/top-level/python-packages.nix` with `callPackage`.
Thus, even if the former gets passed the updated `pkgs`,
the latter always gets passed `pkgs.pkgs`.
For the change in the qt5 version to apply consistently, 'pkgs.extend'
must be used.
qutebrowser only used the right qt5 version (5.15) because all
pythonPackages used it anyway.
Optional setting of format == "pyproject", "egg" had been documented
in the manual, but they weren't listed in the function header for
``mk-python-derivation.nix``.
On darwin the compilation would fail with the following warning:
```
clang-7: error: argument unused during compilation: '-fno-strict-overflow' [-Werror,-Wunused-command-line-argument]
```
This error happens because the `-fno-strict-overflow` is passed to the compiler. To fix this, disable the `strictoverflow` hardening feature. Also see #39687.
ZHF: #97479
/cc roundup issues: #96821, #96828.
The diff upstream is fairly small, so let me trust Mike Pall on this.
Both versions get a pair of commits that seem to address the CVE
https://github.com/LuaJIT/LuaJIT/issues/603
and 2.1 additionally gets one other small commit.
The erlang `generic-builder` accepts a lot of arguments that would
affect the `configureFlags` passed to `mkDerivation`. Though all these
arguments would be without any effect if additionally `configureFlags`
is passed and not the empty list.
This change should make it easier to "compose" arbitrary erlang overrides.
