| 18 Apr 2026 |
 Alice | well, we wouldn't think that that would be the job of the flake | 18:12:17 |
| Alice | but of the system, to see that flake says "i need a jdk, of openjdk variety, optionally with gtk" and go "yeah, we have openjdk, here you go" | 18:13:31 |
 samasaur | that's the kind of thing that nix explicitly tries to avoid, because doing that inevitably runs into obscure and hard to debug errors when the jdk provided by the system isn't compatible with the package for whatever reason | 18:14:59 |
| samasaur | the nix way to do what you're trying to do would be to have users of the flake override it to use a jdk that they know they're already using on their system | 18:16:43 |
 msgilligan | It seems like there could be some kind of preprocessing step that outputs a flake configuration that meets the requirement of a single JDK that satisfies dependencies of other packages. | 18:50:46 |
| samasaur | i mean you very well could define a flake output that needs to be passed a JDK | 18:51:16 |
| samasaur | it's just not the typical way things are done because then nix run, nix shell, etc. won't work | 18:51:48 |
| Alice | that's "true", but feels like, kind of a shit UX, tbqh | 18:52:09 |
| samasaur | you could also define it to optionally take a JDK and fall back to pkgs.openjdk if one isn't passed | 18:52:20 |
| samasaur | but there's an infinite number of cases like this where your dependencies are configured to build with dependencies of their own that you don't care about | 18:53:09 |
| samasaur | my recommendation would be not to bother, because a) normal gradle/openjdk will be cached on hydra and an overriden one will not; b) chances are users of your package will already have the normal (non overriden) openjdk in their nix store due to other packages; c) users who actually care about extracting every little bit of space can do the overriding themselves | 18:55:38 |
| samasaur | now if you are in a situation where you need to be this precise about dependencies due to disk usage, maybe you come to a different conclusion than i did | 18:56:53 |
| msgilligan | I wonder if something like this would help for these use-cases: https://www.socallinuxexpo.org/scale/22x/presentations/configurable-flakes | 19:04:59 |
| 19 Apr 2026 |
|  @rasmata:matrix.org joined the room. | 13:08:38 |
| @rasmata:matrix.org left the room. | 13:08:42 |
| 21 Apr 2026 |
 ortolanbunting3002 | Is there a good way to handle Linux binaries from dependencies managed via the gradle setup-hook? There are gradle plugins which download linux binaries, which don't work (Most likely because the ELF interpreter isn't set properly). Is there a way to make them work? I've thought of autoPatchelf, nix-ld or buildFHSEnv. But I'm not sure of how to integrate those with the build of a gradle application. | 07:32:16 |
 Benedikt Ritter (britter) | The short answer is: no
I've been running into the plugin when I tried to use the protobuf gradle plugin. It wraps protoc which it loads from maven central if I remember correctly. Or maybe it was a protoc plugin that was loaded separately from Maven Central.
Anyway, the issue with these things is that there's no unified way to point them to a directory for looking up natives. Some may have a system property, some may look at PATH, sometimes there's a Gradle plugin config...
So I wouldn't know how to solve this problem in a generic way.
I think what we would need is to be able to have drvs for all libs on maven central and then be able inject the build time dependencies on the nix level.
But thats a completely different and radical approach compared to the dependency FOD solution that we have right now.
| 08:17:19 |
| Benedikt Ritter (britter) | I solved my problem by putting everything into the env and using nix-ld. | 08:17:49 |
| ortolanbunting3002 | But you don't build using mkDerivation? | 08:18:33 |
| Benedikt Ritter (britter) | No, we don't. We gave up in the end: https://britter.dev/blog/2025/02/27/nix-java-enterprise/ | 09:06:23 |
| 26 Apr 2026 |
| Benedikt Ritter (britter) | RFC https://github.com/NixOS/nixpkgs/pull/513696 | 13:39:48 |
| 27 Apr 2026 |
|  Matt McHenry joined the room. | 22:34:14 |
| 28 Apr 2026 |
| Benedikt Ritter (britter) | Anybody? 👆🥲 | 05:50:38 |
 Infinidoge 🏳️⚧️ | Looking into it now! | 19:55:21 |
| Infinidoge 🏳️⚧️ | Reviewed and approved, if anyone here has experience with Maven and buildMavenPackage, please also review it | 19:59:41 |
| Infinidoge 🏳️⚧️ | (I haven't worked with buildMavenPackage, so would like another opinion) | 20:00:13 |
| 29 Apr 2026 |
| Benedikt Ritter (britter) | Thank you for the review. I agree about the formatting changes. I think this is caused by prettier being configured as a formatting source in my nvim none-ls setup and it seems to also format markdown files 😕 I need to disable this because it's causing problems everywhere I edit markdown or yaml files. | 12:36:45 |
| Benedikt Ritter (britter) | Infinidoge 🏳️⚧️: I wonder whether I should add to this PR updating all the packages that currently use rec. Each in a separate commit. That would at the same time prove that the code is working. | 14:27:43 |
| Infinidoge 🏳️⚧️ | Up to you! Though from my own experience, I caution making a PR too big, as it can make the changes hard to review and take longer to merge
Doing it all at once would ensure that it gets done along side, though | 18:38:12 |
| 30 Apr 2026 |
| Benedikt Ritter (britter) | I've reviewed the list of packages that depend on buildMavenPackage and devided to do that separately. | 12:21:23 |
