| 27 Mar 2025 |
 Tomodachi94 (they/them) | * On the testing PRs bit, our CONTRIBUTING.md has some good advice: https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#how-to-review-pull-requests
As for testing prerelease branches, we have a system called Hydra which builds packages automatically once they're promoted (is that the right word?) to a channel. Here's some more information: https://wiki.nixos.org/wiki/Channel_branches | 04:27:34 |
 emily | In reply to @tomodachi94:matrix.org
(I'd be willing to vouch for you if you want to be put onto the Java team so you get pings for this kind of stuff; I'm probably not the only one who thinks you'd make a great addition) I mostly just don't have the time, I'm afraid :) | 12:18:30 |
| emily | I'm happy to try and take a look at stuff I'm pointed out, and do specific bits of work when they dovetail with other stuff I want to do, but if I try to track all the day to day Java stuff I'll just drop the ball on stuff more than I already do | 12:19:03 |
| emily | FWIW I don't think JDK patch updates need more testing than confirming build and maybe a brief perusal of advisories/release notes | 12:20:39 |
| emily | just needs someone keeping track of them (r-ryantm sometimes has issues and isn't always the fastest) and a committer who can allocate the time to merging them | 12:21:33 |
 raboof | Jup. While I think everyone wants to run newer JDKs, many libraries want to support running on JDK8, and the easiest way to achieve that is by building on JDK8 - building with a newer JDK than the target JDK only became reliable when targeting JDK9 onwards... | 14:15:38 |
| raboof | I wonder if it'd be easier to drop jdk11 than it'd be to drop jdk8 | 14:17:02 |
| raboof | no promises but feel free to request reviews from me on (especially already-maintainer-reviewed) Java PRs for merge | 14:19:06 |
| 30 Mar 2025 |
|  98765abc joined the room. | 02:13:21 |
| 1 Apr 2025 |
|  stroem - sourcegraph changed their display name from stroem - sourcegraph to stroem. | 09:41:46 |
| 5 Apr 2025 |
|  @gotha:matrix.org left the room. | 14:18:43 |
| 8 Apr 2025 |
| emily | samasaur: could you maybe take a look at https://hydra.nixos.org/build/294329205/nixlog/1 ? | 10:15:17 |
| emily | looks like it was caused by your PR | 10:16:30 |
 samasaur | ah i see it | 20:25:09 |
| samasaur | looks like it has already been fixed: https://github.com/NixOS/nixpkgs/commit/7a14f3c857ac979132b782e82b0f5979a833dcc3 | 20:25:14 |
| emily | yeah we were discussing it in #staging:nixos.org | 20:32:40 |
| samasaur | I'm not sure how that happened, I know I tested building these locally, and I can't really imagine how this bug would have been introduced when I rebased onto stagin | 20:32:51 |
| samasaur | * I'm not sure how that happened, I know I tested building these locally, and I can't really imagine how this bug would have been introduced when I rebased onto staging | 20:32:54 |
| samasaur | just checked and apparently the symlink was broken before my rebase too but the build was successful anyway? baffling | 20:55:46 |
| emily | oh, I think the symlink check was tweaked for Darwin this cycle | 20:59:24 |
| emily | something about how symlinks can have their own permissions in XNU | 20:59:31 |
| samasaur | ah gotcha | 21:02:33 |
| samasaur | i learned that recently, although permissions on the link itself don't seem to be consistently applied | 21:02:52 |
| samasaur | stat and cat are able to follow a link even after i chmod it to 000 and chown it to root, but readlink/realpath and ls/eza cannot | 21:03:06 |
| 9 Apr 2025 |
|  @silvio:booq.org left the room. | 07:41:09 |
| 19 Apr 2025 |
| Tomodachi94 (they/them) | Did we ever decide if the Java team has any blocking items for 25.05? | 02:15:00 |
 FliegendeWurst (@GPN23) | OpenJDK 23 is EOL now/soon, so that would be good to drop. Though OpenJDK 24 will also be EOL in the release cycle. Do we have a policy for non-LTS JDK versions on stable? | 07:58:37 |
| emily | it goes EOL like a month before the release goes out of support right? | 12:04:05 |
| emily | I think knownVulnerabilities would be the thing to do, but it's possible the next round of advisories will come after it goes out of support anyway. | 12:04:38 |
| emily | IMO we should just have a rolling openjdk_latest rather than per-version packages for non-LTS, but this has been discussed in here a bunch before and it seems some Java projects are both bleeding edge and incapable of keeping off EOL versions so there is some discontent about even not keeping around dead versions... | 12:05:56 |
