 | NixOS JVM | 122 Members |
| 27 Servers |
| NixOS JVM | 122 Members |
| 27 Servers |
| Sender | Message | Time |
|---|---|---|
| 17 Jul 2025 | ||
 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 |
| emily | though in the presence of merge conflicts that doesn't work so great :) | 21:44:00 |
| Infinidoge 🏳️⚧️ | If flakes supported patches for inputs the world would be at peace | 21:44:20 |
| Infinidoge 🏳️⚧️ | But alas | 21:44:25 |
| Infinidoge 🏳️⚧️ | IFD | 21:44:26 |
| Infinidoge 🏳️⚧️ | I have hope for Fetch Tree, but only hope | 21:44:35 |
| emily | I don't think fetchTree changes anything there | 21:45:44 |
| Infinidoge 🏳️⚧️ | I think the ideal solution would be an out-of-tree repo exposing packages through flakes and an overlay, with a structure identical to how the packages would be in Nixpkgs, so they can be directly transferred in later | 21:45:47 |
| emily | honestly using the PR refs seems fine to me. I just, like, wouldn't deploy it in pros | 21:46:34 |
| emily | * | 21:46:39 |
| emily | but I wouldn't deploy an EA version in prod to begin with :) | 21:46:51 |