| 27 Dec 2024 |
raboof | hmm kinda it seems (e.g. https://www.oracle.com/java/technologies/java-se-support-roadmap.html) | 18:07:59 |
| 1 Jan 2025 |
| NixOS Moderation Botchanged room power levels. | 14:26:16 |
| linsui joined the room. | 16:10:49 |
linsui | I thought openjfx build has been fixed in https://github.com/NixOS/nixpkgs/pull/365724 but it still fails for jabref. https://hydra.nixos.org/build/282405302/nixlog/6 Is the webkit enabled openjfx not fixed? | 16:15:02 |
emily | that is plausible. probably needs patches backporting from upstream WebKit | 16:19:12 |
emily | (I don't feel too good about OpenJFX's ability to keep up with WebKit security fixes 😬) | 16:19:30 |
emily | https://github.com/openjdk/jfx23u/commit/fa41f904fc9e0034d3af4d7b4b4cc5d7ddde3300 | 16:21:34 |
emily | there's this which is not in the stable release version | 16:21:39 |
emily | may fix the build but also I'd be shocked if none of this diff is security-relevant as well 🫠| 16:21:52 |
emily | oh, joy… it looks like OpenJFX 21 might be out of security support | 16:25:39 |
emily | not clear actually | 16:26:19 |
emily | they seem to be behind on WebKit updates and https://jdk.java.net/javafx21/ has a scary notice | 16:26:36 |
emily | but https://gluonhq.com/products/javafx/ implies it's in LTS, but unclear if that's FOSS or just for paying customers :) | 16:27:05 |
emily | anyway, I would just try pulling upstream WebKit patches that haven't yet made the releases we package, for any broken OpenJFX+WebKits | 16:27:53 |
linsui | Thanks! | 16:34:47 |
emily | (by upstream WebKit patches I mean OpenJFX's rollups of WebKit changes, it may also be necessary to pull commits from WebKit itself but hopefully not) | 16:36:54 |
linsui | When updating jabref I encountered another problem. It added embeded postgresql. The packaged postgresql doesn't run on NixOS. I thought I should replace it with the postgresql in nixpkgs. Should I override mitmCache somehow? | 16:37:46 |
linsui | Or I should replace the jar in lib/? | 16:38:09 |
emily | I think you can patch the Gradle file to use a file dependency and just inject the path to our .jar | 16:39:24 |
emily | and then regenerate the mitm-cache | 16:39:28 |
linsui | Then I thought I need to add the patch into the FOD. I thought this is not necessary. | 16:45:39 |
emily | it'll change what dependencies Gradle calculates, so you can patch the Gradle file and then update the mitmCache JSON | 16:46:04 |
linsui | Does fetchDeps work with postPatch? | 16:46:42 |
linsui | So that the mitmCache package will be smaller? | 16:47:47 |
emily | it won't include the broken Postgres | 16:51:23 |
emily | not sure :/ | 16:51:48 |
emily | it uses some srcOnly stuff | 16:51:49 |
emily | it may be harmless to have the mitmCache entries though | 16:51:49 |
emily | I think patching the Gradle file is the correct way in any case | 16:51:50 |
linsui | Yep :) | 16:53:14 |