NixOS JVM | 118 Members | |
| 26 Servers |
| Sender | Message | Time |
|---|---|---|
| 16 Aug 2025 | ||
| msgilligan: it's not a defaulting in that sense. Something is broken with some ncurses bridge that comes with the rubygrapefruit library that is used by Gradle and cached in the user home. I was able to fix this by dropping my local Gradle caches. Then it worked for a few builds until it didn't 😏 I'd love to have this fixed but I don't even know where to start. | 09:42:03 | |
| Some more context: https://github.com/gradle/gradle/issues/32006 In need to collect all the different pieces of info I have about this issue and then create a new issue on nixpkgs, so we can start triaging. | 11:53:56 | |
| gradle cache is like dns | 11:56:12 | |
| Honestly, for me it has worked pretty reliably outside of NixOS. I think there's a lot of false information on the internet, where people got stuck with a problem, then tried a bunch of different things without a structured process and somewhere in the middle they ran gralde clean and deleted all cashes. Then when they get unstuck they claim "cleaning and deleting all cashes will fix your problems", which is not the case most of the time. In this particular case, I suspect that one of the jars from Gradle's native platform does something that doesn't work correctly on NixOS. Maybe it expects something to be in an FHS location, or something like that. Right now, I don't know how we would fix this, because we can't install a fixed version of that jar into the cache, because we don't know the cache location beforehands. | 15:06:37 | |
| But I'm speculating. I need some more time to dig deeper into this. Not sure when I'll get to it. | 15:07:05 | |
| I've approved this Gradle 9 PR and I'm hoping one of the maintainers can review it: https://github.com/NixOS/nixpkgs/pull/421047 | 16:41:04 | |
| ollijh has requested that we bump the default Gradle version to 9 as part of this PR, but to me this seems premature. I would think that the individual package maintainers should update individually and perhaps follow what the upstream packages are doing. And projects that use non-built-in plugins often need to wait for plugins to be updated. I tried bumping three packages selected arbitrarily and none of them worked. See https://github.com/NixOS/nixpkgs/pull/421047#issuecomment-3189716199 | 16:48:31 | |
| how long will 8 be in security support? | 16:50:20 | |
| Until Gradle 10 ships | 16:56:27 | |
| seems fine to ship as the default for 25.11 then | 16:59:20 | |
| we still have Gradle 7 though… | 16:59:35 | |
| which should not go into 25.11 | 16:59:38 | |
| You mean leave Gradle 8 as the default for 25.11? | 17:00:59 | |
| Looks like there's been progress on removing gradle_7: https://github.com/NixOS/nixpkgs/issues/358845 (It looks like | 18:57:34 | |
| 17 Aug 2025 | ||
| Need more reviewers to fix an issue with fetchMavenArtifact: https://github.com/NixOS/nixpkgs/pull/433975 | 04:14:48 | |
| * Need more reviewers to fix an issue of fetchMavenArtifact: https://github.com/NixOS/nixpkgs/pull/433975 | 04:14:58 | |
| * Need more reviewers for my PR that fixes an issue of fetchMavenArtifact: https://github.com/NixOS/nixpkgs/pull/433975 | 04:15:45 | |
| 18 Aug 2025 | ||
I think somehow searching for Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0. in all direct dependents on gradle and then updating those to gradle_8 would be more appropriate | 00:42:36 | |
| (Didn't someone say somewhere something about searching all Hydra logs is possible? If it is, that would be the best way to figure that out imo) | 00:43:20 | |
And we should also be reviewing all of our explicit usages of gradle_8 and updating where appropriate, but that's another tracking issue to be created once 7 is gone | 00:44:23 | |
| Here's an example of | 00:45:17 | |
| * Here's an example of me doing this: https://github.com/NixOS/nixpkgs/pull/359177 | 00:45:32 | |
| But it sounds like (if I understand emily correctly) there is consensus here (in this room) that we can merge Gradle 9 without changing the default or making changes to any packages that use Gradle. This means initially that use of Gradle 9 will be opt-in. And that we should remove Gradle 7 before 25.11, but Gradle 8 can remain the default for 25.11. Is this a fair summary? | 00:53:03 | |
| I think that's fine yes (but I agree w/ Tomodachi94 (they/them) that mass-bumping things early is the best way to avoid the pain of "we have three EOL versions packaged and it's totally unclear whether these packages actually need them". actually, I like not using versioned pins when you don't have to, because then it's clear what actually potentially needs work to bump, when it breaks) | 00:54:13 | |
| * But it sounds like (if I understand emily correctly) there is consensus here (in this room) that we can merge Gradle 9 without changing the default or making changes to any packages that use Gradle. This means initially that use of Gradle 9 will (initially) be opt-in. And that we should remove Gradle 7 before 25.11, but Gradle 8 can remain the default for 25.11. Is this a fair summary? | 00:54:29 | |
I'm fine with everything except for gradle_8 = gradle; in 25.11. I think we have enough time before the release (3 months) to sort out the breakages that would be caused, especially because it's a simple s/gradle/gradle_8/g in the locations where breakages occur | 00:55:20 | |
I'm fine with everything except for gradle_8 = gradle; in 25.11. I think we have enough time before the release (3 months) to sort out the breakages that would be caused, especially because the fix is a simple s/gradle/gradle_8/g in the locations where breakages occur | 00:55:35 | |
| Yeah, that's a reasonable position. | 00:56:21 | |
| The sensitivity of Gradle builds (and Gradle plugins) to version upgrades is perhaps Gradle's biggest flaw. (It's tied with the sensitivity of Gradle itself to JDK version bumps, but I think that might be betting better.) | 00:57:42 | |
| (Yes, I am volunteering to help with the Gradle 8 breakages🙂) | 00:57:51 | |