The previous releases of zlib were not sensitive to incorrect CRC
inputs with bits set above the low 32. Some programs were depended on
this behavior, including GraalVM. So this commit backports a patch from
`zlib` develop that brings back the old behavior. This will probably
be included in the next release of zlib.
Before:
```
$ rm -rf ~/.babashka
$ bb -e "(babashka.pods/load-pod 'clj-kondo/clj-kondo \"2022.05.31\")"
Downloading pod clj-kondo/clj-kondo (2022.05.31)
----- Error --------------------------------------------------------------------
Type: java.util.zip.ZipException
Message: invalid entry CRC (expected 0x269cdf2c but got 0x13b86fd8)
Location: <expr>:1:1
----- Context ------------------------------------------------------------------
1: (babashka.pods/load-pod 'clj-kondo/clj-kondo "2022.05.31")
^--- invalid entry CRC (expected 0x269cdf2c but got 0x13b86fd8)
----- Stack trace --------------------------------------------------------------
babashka.pods.impl.resolver/unzip - <built-in>
babashka.pods.impl.resolver/resolve/fn--30674 - <built-in>
clojure.core/mapv/fn--8535 - <built-in>
clojure.core.protocols/fn--8244 - <built-in>
clojure.core.protocols/fn--8204/G--8199--8213 - <built-in>
... (run with --debug to see elided elements)
babashka.pods.sci/load-pod/fn--30887 - <built-in>
babashka.pods.sci/load-pod - <built-in>
clojure.core/apply - <built-in>
babashka.impl.pods/load-pod - <built-in>
user - <expr>:1:1
```
After:
```
$ rm -rf ~/.babashka
$ ./result/bin/bb -e "(babashka.pods/load-pod 'clj-kondo/clj-kondo \"2022.05.31\")"
Downloading pod clj-kondo/clj-kondo (2022.05.31)
Successfully installed pod clj-kondo/clj-kondo (2022.05.31)
```
The issue should affect other programs using GraalVM, but this was the
test that I had at hand.
In #168816, we removed support for Python/Ruby/WASM to reduce the
support burden of GraalVM languages that, arguably, are not really being
used.
However, the way that `pkgs.graalvmCEPackages.mkGraal` function works
right now doesn't allow passing a custom sources file, that would allow
someone to compile GraalVM with the additional products (e.g.: Python).
This PR adds this possibility.
So if someone wants to create a custom graalvm11-ce derivation with
Python support, for example, they can do something like this:
```nix
let
graalvm11-ce-custom = pkgs.graalvmCEPackages.mkGraal {
config = {
x86_64-linux = {
products = [ "graalvm-ce" "python-installable-svm" ];
arch = "linux-amd64";
};
};
defaultVersion = "22.0.0.2";
javaVersion = "11";
platforms = "x86_64-linux";
sourcesPath = /home/someone/graalvm11-ce-sources.json;
};
in
{
environment.systemPackages = [ graalvm11-ce-custom ];
}
```
Those additional languages does not seem to really have much usage
(e.g.: none in nixpkgs). For example, Ruby is pretty much broken for all
environments for quite sometime already, however nobody seemed to border
enough to fix it. They also add a good amount of size to the derivation.
So let's remove them. It should be really easy if someone still cares
for them and want to add them back on their own system: just use the
`mkGraal` function (that we export) to generate their own version of
GraalVM with all extra features they want.
- Drop graalvm8 since it was removed by upstream
- Add update.sh script to make it easier to generate hashes for all
platforms
- Fix GraalPython, broken since #141825 (sorry)
- Small refactorings and fixes
Only adding support for graalvm11-ce. While there is a graalvm8 release
for aarch64-linux, it is missing some support (like wasm).
Also, it is not used anywhere on the nixpkgs, while graalvm11 is used by
multiple other packages (babashka, clj-kondo, clojure-lsp, etc.).
