| 27 Mar 2025 |
 emily | while keeping the rest of your system on a newer rev | 00:46:15 |
 msgilligan | I just have to have two inputs in my flake? | 00:46:32 |
| emily | right | 00:46:35 |
| emily | being able to mix and match like that is part of why we generally err on the side of dropping stuff to ease maintainer burden | 00:46:55 |
| msgilligan | But I can't do that if I want to submit to Nixpkgs itself, right? | 00:47:19 |
| emily | it won't get updates to its dependencies, but the complex JIT engine is already the riskiest dependency in the tree anyway :) | 00:47:19 |
 Tomodachi94 (they/them) | Correct | 00:47:44 |
| msgilligan | This is why jextract had to be marked as broken, for example. | 00:48:28 |
| msgilligan | And a jextract-21 is practically useless because the features it relies on were "preview" and not final. Then when I updated to the latest jextract it generates code that requires JDK 23, so that forces anything that uses its output to JDK 23. | 00:50:01 |
| msgilligan | I would say jextract and jextract-21 should both be removed from 25.05 stable. And as soon as we get jextract 23, I would say we should remove jextract-21 from unstable. | 00:51:32 |
| emily | have they not even updated to 23 yet? 🫠 | 00:52:59 |
| emily | it's a little bizarre that the OpenJDK project can't keep up with their own release cycle :) | 00:53:16 |
| emily | I guess this is why people stick to LTSes | 00:53:27 |
| Tomodachi94 (they/them) | Off-topic: Lovely, Nixpkgs has a working Codespaces default now >:) | 00:54:10 |
| msgilligan | They have, and I've made a PR that works on aarch64-darwin but not aarch64-linux (thought that may be true of the upstream too) | 00:54:15 |
| Tomodachi94 (they/them) | (In theory; it's still setting itself up) | 00:54:30 |
| msgilligan | https://github.com/NixOS/nixpkgs/pull/384028 | 00:54:55 |
| msgilligan | There have also been some changes upstream and the PR should be updated and rebased (though they don't like they'll help with aarch64-linux) | 00:55:31 |
| Tomodachi94 (they/them) | (Everything works out of the box now! No more hacky workarounds needed) | 00:57:46 |
| msgilligan | Last week, I actually talked to someone from someone from Oracle who is responsible for jextract (at a JavaOne side event) and he admitted it needed some love.
I'm glad I haven't made it a direct dependency of my build. I just need to install it periodically and use it to generate Java source that I check in to the repository.
| 01:05:51 |
| msgilligan | He complained about the LLVM dependencies... | 01:07:03 |
| msgilligan | Hopefully things will stabilize around JDK 25 | 01:09:39 |
 Infinidoge 🏳️⚧️ | With regards to dropping JDK versions, unless they are actively a maintainability hazard, I would rather we keep as many versions as are reasonable | 01:18:17 |
| Infinidoge 🏳️⚧️ | The heuristic I propose is keeping JDK versions between LTS versions, and dropping only when the next LTS cycle begins | 01:18:42 |
| Infinidoge 🏳️⚧️ | (I talked with msgilligan about this at PlanetNix for a bit of extra context) | 01:19:46 |
| emily | as long as EOL ones are marked knownVulnerabilities there's no inherent problem, but frankly that is going to be a worse UX than using an old Nixpkgs rev in many ways | 01:21:49 |
| Infinidoge 🏳️⚧️ | Re: 25.05, I don't know of any notable blockers, meant to come here and ping everyone to ask but you beat me to the punch. Anything like gradle 9 would be nice to have but isn't necessary | 01:22:22 |
| Infinidoge 🏳️⚧️ | In reply to @emilazy:matrix.org
as long as EOL ones are marked knownVulnerabilities there's no inherent problem, but frankly that is going to be a worse UX than using an old Nixpkgs rev in many ways Isn't it just an allowInsure config? | 01:22:33 |
| emily | I am unconvinced that we need to have a greater proliferation of JDKs than e.g. Fedora which does the rolling package for non-LTS, though | 01:22:40 |
| emily | In reply to @infinidoge:inx.moe
Isn't it just an allowInsure config? and building OpenJDK yourself, yeah | 01:22:52 |
