08:55:27 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. 08:56:31 So good news for this community is that JDK17 in recent-ish OpenIndiana (2024.04) and OmniOS (r151046) releases just sufficed. 08:58:42 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). 08:59:16 jperkin: OTOH, is there any chance pkgsrc would work to give me JDK/JRE17 on OpenBSD 6.5? :D 09:00:42 jimklimov: potentially, if the openbsd bits are merged into the adoptopenjdk stuff that freebsd/netbsd use 09:01:58 sorry, battleblow, not adoptopenjdk, it's hard to keep track of all this silly forks 09:03:39 :) 09:04:06 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 09:04:44 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 09:49:44 Hm, so I downloaded the tarball, bootstrapped it, updated PATH, went to sources and ran `bmake install` - right? 09:49:49 => 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 09:50:15 and likewise for 17 09:50: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 09:50:57 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 09:54:31 edit Makefile and add OpenBSD-*-* to ONLY_FOR_PLATFORM 09:55:30 ah hold on, it'll be in pkgsrc/mk/java-vm.mk 09:56:09 and FWIW ERROR: openjdk-bin-21.0.1 requires emulation that is not available for OpenBSD-6.5-x86_64 09:56:22 happy to take this to privmsg as it's definitely veering off-topic 09:56:46 or #pkgsrc 09:57:04 ah, right :D 09:57:50 well, started as an option discussed for illumos-based systems though.... and actually those discussions above reminded me of the option at all :) 19:28:40 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? 19:31:42 I don't think so, but it's been a long time 19:31:55 it should not (but keep backups handy:D) 19:32:08 i think you had to grow the MBR table, and also the slice in the label 19:34:42 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 19:35:16 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 19:35:45 my ancient memory is fdisk, then fmthard 19:35:57 somelike ptribble who deals with the past more comfortably might be a good person to ask 19:36:30 I have used this approach a lot and never had our fdisk causing problems 19:37:17 fdisk + format, that is. 19:37:23 it's the boot disk (in an old VM that's been upgraded a lot) 19:37:47 which is what gives me some pause from just yolo'ing it 19:38:04 with VM you can snapshot the disk 19:38:23 (assuming vmware) 19:39:51 good point.. 19:41:00 or, add new disk and clone to EFI label;) 19:53:28 jbk: i'm not sure fdisk won't clobber your vtoc, i recall it doing that 19:55:29 microsoft fdisk can do it 20:01:05 but even it... vtoc is in partition relative sector 1, if the partition type is correct, nothing should touch it... 20:05:59 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. 20:33:41 That would be my expectation as well (that fdisk does not touch the contents of the SOLARIS2-type partition)