 | NixOS JVM | 121 Members |
| 27 Servers |
| NixOS JVM | 121 Members |
| 27 Servers |
| Sender | Message | Time |
|---|---|---|
| 17 Jul 2025 | ||
 msgilligan | I'm not sure how people would feel about using Java to do this, but it could definitely be made to work. | 19:43:52 |
 Infinidoge 🏳️⚧️ | We've been against Java updaters in the past, due to the annoyance in getting them running | 19:44:49 |
| Infinidoge 🏳️⚧️ | I believe there was previously a Java-based OpenJDK updater that later got replaced | 19:45:07 |
| Infinidoge 🏳️⚧️ |  Download image.png | 19:45:23 |
| Infinidoge 🏳️⚧️ | Also not a lot of Java files in Nixpkgs | 19:45:27 |
 emily | it was quite bad for bootstrapping | 19:47:26 |
| emily | (so I rewrote it in Python) | 19:47:34 |
| emily | in general Python or Bash are the lingua franca options for Nixpkgs tooling | 19:47:51 |
| Infinidoge 🏳️⚧️ | For what it's worth, Temurin has an updater in generate-sources.py which could be used as a model for Zulu | 19:49:15 |
| msgilligan | It looks nice! | 19:58:19 |
| msgilligan | Can we take a fresh look at the PR to add 25-ea to temurin-bin? I would be willing to work on this to get it -- or even a subset of it -- merged. | 20:34:55 |
| msgilligan | According to the schedule, today (2025/07/17) it should be in "Rampdown Phase Two", and on 2025/08/07 there will be an "Initial Release Candidate". GA is scheduled for 2025/09/16. So I think it should be stable enough for our purposes. And of course, if we find a bug we can report it upstream so it can get fixed sooner. | 20:40:23 |
| msgilligan | I have been using it (via various install mechanisms, including a WIP Nixpkgs PR) on both aarch64-darwin and aarch64-linux and it has been perfectly stable for my (admittedly limited) usage. | 20:43:04 |
| msgilligan | This is the PR to add temurin-bin 25-ea: https://github.com/NixOS/nixpkgs/pull/368598 | 20:51:22 |
| msgilligan | I see 368598 as having 4 logical groups (steps) of changes:
| 21:08:33 |
| msgilligan | What is the best thing I can do to move this forward? | 21:09:07 |
| emily | In reply to @msgilligan:matrix.orgI mean that the reason we didn't merge it already was because we had not decided whether we should include prereleases in-tree. we usually don't in general for software and I'm not sure how it would interact with our stability policy wrt stable backports of the cycle overlaps | 21:21:59 |
| emily | usually stuff like that is left to out of tree repos | 21:22:08 |
| msgilligan | But step 1 and 2 of the list of the above could me merged separately, I assume. | 21:26:46 |
| msgilligan | And, as far as making it available "out of tree", what would be the best way to do that? | 21:27:12 |
| emily | for sure for #1, it should probably get the token from the environment like other tooling for #2 I guess it depends on the complexity of the code change and whether we worry about EA versions being added accidentally - if we don't expect that we'd want to exercise the functionality in Nixpkgs | 21:28:11 |
| emily | In reply to @msgilligan:matrix.orgthe standard thing these days would be to make a flake. we could expose generic builders for the relevant packages that can be supplied arbitrary versions from Nixpkgs if it would make that task easier l | 21:28:58 |
| msgilligan | Would (or could) that flake be an "overlay"? It would be nice if I could add 25-EA and then have packages like Gradle and JBang be configured to use that JDK. That (or a similar mechanism) would also allow the build of 25 to get some testing. | 21:30:55 |
| emily | it can be, but you don't need an overlay to use out of tree packages either | 21:33:41 |
| msgilligan | I know that raboof created an "out of tree" solution here, but I don't know how to use it from a flake and it seems more like a very separate thing, not something this is a "preview" of something that will move to Nixpkgs. | 21:34:35 |
| msgilligan | I think the ideal way would be able to access the PRs branch directly and I've seen flakes that use both a stable and unstable release of Nixpkgs, so I think that approach should work. That would also make it easier to rebase and to adapt for new EA releases after the current EA becomes GA. | 21:37:41 |
| emily | yeah, that very much works | 21:43:06 |
| emily | you don't necessarily need two Nixpkgses since GitHub has magic refs that represent the state if the PR was merged | 21:43:45 |
| Infinidoge 🏳️⚧️ | The unfortunate thing with PR branches vs overlays or grabbing directly is that PR branches usually aren't kept up to date, and usually don't follow with a standard stable branch | 21:43:47 |
| Infinidoge 🏳️⚧️ | Oh good magic ref, that works | 21:43:58 |