| 22 Sep 2025 |
 msgilligan | I guess you'll leave the tests on so all I have to do is nixpkgs-review pr 445032, right? | 19:24:28 |
 Benedikt Ritter (britter) | I updated the PR to pull the changed from your PR. Can you try again? | 19:26:59 |
| msgilligan | Running... | 19:29:07 |
| msgilligan | nixpkgs-review passes on both aarch64-darwin and aarch64-linux. The PR is also passing upstream CI:
https://github.com/Stirling-Tools/Stirling-PDF/pull/4477/checks | 19:42:50 |
| Benedikt Ritter (britter) | Thanks! | 19:44:06 |
| msgilligan | You're welcome! | 19:44:25 |
| msgilligan | I am benefitting so much from the Nix Gradle work you have done, that the balance is still heavily in your favor! | 19:45:32 |
| msgilligan | Merged upstream. | 19:57:49 |
|  @ihar.hrachyshka:matrix.org joined the room. | 23:35:23 |
| 23 Sep 2025 |
|  a-kenji changed their display name from a-kenji to kenji. | 10:38:30 |
| 24 Sep 2025 |
| msgilligan | I haven't had a chance to follow-up on this comment, but it looks promising: https://github.com/NixOS/nixpkgs/issues/412283#issuecomment-3325887652 | 04:50:15 |
| msgilligan |
With this workaround, JDK24 compiles correctly with JFX support.
| 04:50:36 |
 emily | looks like shipping the jlink thing would also fix it going by the linked release notes | 05:01:34 |
| msgilligan | I'm thinking we should encourage applications to pull in their JavaFX jars/modules separately from the JDK when possible (which I believe should be almost always) I haven't actually tested this yet, but hope to soon. JavaFX was designed to be independent of the JDK (though maybe now for a smaller range of versions) and having a little more flexibility here should make upgrades less painful. | 05:09:47 |
| emily | yes, please :) | 15:02:35 |
| emily | I hate the JFX entangled into the JDK build thing, as you know | 15:02:46 |
| emily | I think that one jlink PR to get rid of that looked pretty good in principle, I forget if I had any complaints about it | 15:03:10 |
| emily | if we can just make everything use it totally separately and kill off the combined build then that's wonderful though | 15:03:23 |
| emily | would simplify everything a fair bit | 15:03:30 |
| emily | we don't have too much in-tree that uses JFX | 15:03:56 |
| emily | double nice would be if we can split out the WebKit part of it rather than having that be a flag đŸ˜† | 15:04:19 |
| emily | (but don't know if their build system makes that viable) | 15:04:25 |
| msgilligan | Oh, yeah the modules approach should help with that, too. | 15:04:57 |
| emily | have you seen the Bazel 8 stuff btw? not sure if you have any care for Bazel | 15:06:22 |
| emily | but our Bazel packaging story is currently a mess and it seems like Bazel 8 might help with that… | 15:06:34 |
| msgilligan | I've been resisting Bazel for years. Maybe that's foolish? | 15:06:52 |
| msgilligan | If it works better with Nix than Maven or Gradle, that might be a selling point... | 15:07:38 |
| emily | worse, I think. | 15:07:45 |
| emily | Nix and Bazel have fairly similar views of the world in many ways, but they're just different enough, and just enough pushing into each other's turf, that the combination causes a bit of a headache. | 15:08:24 |
| msgilligan |
I hate the JFX entangled into the JDK build thing
I think this happening in the JFX ecosystem was mostly the result of JFX making a bad design decision that in some cases requires using the module path and apps not dealing with it well. Since a bundled JFX worked-around the problem, JDKs with bundled FX became popular. (I don't truly know the reasons why, but this is my theory)
Anyway, hopefully the JFX apps we have in Nixpkgs can move past this.
| 15:16:01 |
