FWIW, struggling with JDK17 updates for the NUT CI Jenkins farm too this week, especially with legacy builders that ensure NUT can build run wherever (including old machines that still have an electric pulse but long EOL in their HW/OS vendors' view). Making those into Jenkins-capable build agents is... an adventure.

So good news for this community is that JDK17 in recent-ish OpenIndiana (2024.04) and OmniOS (r151046) releases just sufficed.

The biggest struggle remaining is on OpenBSD 6.5 which just refuses to build anything from openjdk sources (knows of "bsd" but refuses to handle it, and m4 scripting is irky) or its own ports (aimed at a newer release by the time jdk17 was considered).

jperkin: OTOH, is there any chance pkgsrc would work to give me JDK/JRE17 on OpenBSD 6.5? :D

jimklimov: potentially, if the openbsd bits are merged into the adoptopenjdk stuff that freebsd/netbsd use

sorry, battleblow, not adoptopenjdk, it's hard to keep track of all this silly forks

:)

jimklimov: if you try then lang/openjdk17 is the one you probably want, lang/oracle-jdk* is, well, the "native" oracle ones, while I have pkgsrc-extra/openjdk* for the illumos ones

I think some people do still use the oracle ones on *BSD via the linux syscall emulation as I believe the native ports still lack some features

Hm, so I downloaded the tarball, bootstrapped it, updated PATH, went to sources and ran `bmake install` - right?

=> Returning to build of openjdk21-1.21.0.3.9 ERROR: This package is only available for these platforms: NetBSD-*-i386 NetBSD-*-x86_64 NetBSD-*-aarch64. ERROR: This package has set PKG_SKIP_REASON: ERROR: openjdk21-1.21.0.3.9 is not available for OpenBSD-6.5-x86_64

and likewise for 17

ERROR: This package is only available for these platforms: NetBSD-*-i386 NetBSD-*-x86_64 NetBSD-*-aarch64 NetBSD-*-earmv[67]hf. ERROR: This package has set PKG_SKIP_REASON: ERROR: openjdk17-1.17.0.11.9 is not available for OpenBSD-6.5-x86_64

and ERROR: This package has set PKG_SKIP_REASON: ERROR: oracle-jdk17-17.0.12 requires emulation that is not available for OpenBSD-6.5-x86_64 ERROR: oracle-jdk17-17.0.12 is not available for OpenBSD-6.5-x86_64

edit Makefile and add OpenBSD-*-* to ONLY_FOR_PLATFORM

ah hold on, it'll be in pkgsrc/mk/java-vm.mk

and FWIW ERROR: openjdk-bin-21.0.1 requires emulation that is not available for OpenBSD-6.5-x86_64

happy to take this to privmsg as it's definitely veering off-topic

or #pkgsrc

ah, right :D

well, started as an option discussed for illumos-based systems though.... and actually those discussions above reminded me of the option at all :)

hrm... I'm so used to just dealing with GPT disks I can't recall now -- I have a disk w/ the older MBR format (w/ a solaris-type partition in it)... if you use fdisk to delete/re-create the solaris2 partition (to grow it), will it clobber the label at the start of the partition?

I don't think so, but it's been a long time

it should not (but keep backups handy:D)

i think you had to grow the MBR table, and also the slice in the label

yeah.. my concern is using fdisk, your options are delete or create.. i suspect jsut create w/ the same starting cylinder, but larger size should preserve everything, but don't want to assume

i think it just writes it out at the end from what I can tell, and it doesn't look like it'd clobber the label at the start of the partition

my ancient memory is fdisk, then fmthard

somelike ptribble who deals with the past more comfortably might be a good person to ask

I have used this approach a lot and never had our fdisk causing problems

fdisk + format, that is.

it's the boot disk (in an old VM that's been upgraded a lot)

which is what gives me some pause from just yolo'ing it

with VM you can snapshot the disk

(assuming vmware)

good point..

or, add new disk and clone to EFI label;)

jbk: i'm not sure fdisk won't clobber your vtoc, i recall it doing that

microsoft fdisk can do it

but even it... vtoc is in partition relative sector 1, if the partition type is correct, nothing should touch it...

jbk: I believe richlowe & tsoome are correct - fdisk only writes MBR partition table, fmthard only writes solaris partition table, but you could verify this by code inspection and/or running truss fdisk on a scratch disk.

That would be my expectation as well (that fdisk does not touch the contents of the SOLARIS2-type partition)