| 19 Sep 2025 |
 emily | the binaries are one thing since those are low-maintenance | 17:46:08 |
| emily | IIRC Debian already dropped 8 a while back | 17:46:10 |
| emily | it's not used by much in the tree. I think it is basically just old Minceraft versions that haven't had people patch them for newer Java already. which the binary would suffice fine for | 17:46:40 |
| emily | of course enterprises will probably pay to keep it alive until the sun goes out, but they're not paying Nixpkgs… | 17:47:09 |
 Ami | yeah, sorry, should've phrased it differently, didn't mean to imply all of that | 17:49:21 |
| emily | I'm just crabby about al lthe conditionals I ahd to add for 8 :P | 17:50:16 |
| emily | Minecraft folks should finish porting all the other versions so that nobody has use for it any more | 17:50:35 |
| Ami | enterprises insisting on sticking to a particular version should have that version be their problem entirely :p | 17:50:59 |
| Ami | as an archive enthusiast and old minecraft enjoyer it feels wrong that any maintenance would be required for old software, sometimes that feeling leaks out a bit too much | 17:54:17 |
 Infinidoge 🏳️⚧️ | If Java 8 gets dropped by Nixpkgs, I might bring a copy of it over to nix-minecraft for that reason, tbh | 17:55:19 |
 msgilligan | I made a repo with my hacked-together, proof-of-concept, incomplete nix-jdk-dashboard utility. It's basically a combination of Nix, BASH, and jq but it might be useful to someone. And if any of the Nix experts in here have any suggestions for improvement, I'd love to hear them. | 18:09:00 |
| msgilligan | Two major missing pieces are:
- It isn't able to figure out what JDKs are in Nixpgs automatically (it uses the
jdks.nix file)
- It is not pulling the latest releases of JDKs from upstream and showing which ones are behind.
| 18:10:19 |
| msgilligan | But the following command:
./nix-jdk-dashboard.sh master | jq '.packages
| to_entries
| map(select(.key | startswith("openjdk")))
| map(.value.version)'
| 18:10:45 |
| msgilligan | Produces the following output:
[
"21.0.8+9",
"11.0.27+6",
"17.0.16+8",
"21.0.8+9",
"24.0.2+12",
"8u462-b08"
]
| 18:11:21 |
| msgilligan | But I can manually compare to the versions in zulu or temurin in sdkman to see where we are behind. | 18:13:27 |
| msgilligan | * But I can manually compare to the versions in zulu or temurin in sdkman to see where we are behind. | 18:13:38 |
| msgilligan | * Produces the following output (for master):
[
"21.0.8+9",
"11.0.27+6",
"17.0.16+8",
"21.0.8+9",
"24.0.2+12",
"8u462-b08"
]
| 18:14:55 |
| msgilligan | * Produces the following output (for master on aarch64-darwin):
[
"21.0.8+9",
"11.0.27+6",
"17.0.16+8",
"21.0.8+9",
"24.0.2+12",
"8u462-b08"
]
| 18:16:16 |
| msgilligan | * Produces the following output (for master on aarch64-linux):
[
"21.0.8+9",
"11.0.27+6",
"17.0.16+8",
"21.0.8+9",
"24.0.2+12",
"8u462-b08"
]
| 18:17:36 |
| msgilligan | So that suggests that we are behind:
11.0.27 -> 11.0.28
| 18:19:49 |
| msgilligan | On master for aarch64-darwin, I get:
[
"21.0.8",
"11.0.24",
"17.0.12",
"21.0.8",
"24.0.2",
"8.0.422"
]
| 18:20:30 |
| msgilligan | So that suggests we are behind:
8.0.422 -> 8.0.462
11.0.24 -> 11.0.28
17.0.12 -> 17.0.16
But Darwin is using `zulu`, so these are Zulu updates that need to happen.
| 18:23:42 |
| msgilligan | * So that suggests we are behind:
8.0.422 -> 8.0.462
11.0.24 -> 11.0.28
17.0.12 -> 17.0.16
But Darwin is using zulu, so these are Zulu updates that need to happen.
| 18:24:36 |
| msgilligan | * So that suggests we are behind:
8.0.422 -> 8.0.462
11.0.24 -> 11.0.28
17.0.12 -> 17.0.16
But Darwin is using zulu, so these are Zulu updates that need to happen (and are currently on staging !)
| 19:39:21 |
 Tomodachi94 (they/them) | Starting work on removing consumers of Gradle7 by patching | 20:26:26 |
| Tomodachi94 (they/them) | If we want to remove Gradle7, we will need to either patch most of the Correttos or drop all except I think latest? | 21:51:14 |
| msgilligan | Who is maintaining Corretto and is it known why they want it in Nixpkgs? | 21:55:24 |
| Tomodachi94 (they/them) | There was a thread about it a few months ago. The reason iirc was because upstream uses that and enforced it through Grade | 22:37:36 |
| Tomodachi94 (they/them) | https://github.com/NixOS/nixpkgs/issues/313208#issuecomment-2467473454 | 22:38:59 |
| msgilligan | At the worst case you think they could patch that somehow. When I use Gradle toolchains to set a JvmVendor (usually Temurin) I allow overrides by putting the setting in gradle.properties which can easily be overridden with a -P on the Gradle command line. | 23:05:28 |
