00:52:40 Hey everyone, Robby Andrews here from MNX. I wanted to announce we are doing an office hours for TritonData Center over on Discord 00:52:47 This Thursday 11am PT/2pm ET. Here is the link to join our discord https://discord.gg/v4NwA3Hqay 00:53:48 Come and participate and hear what we're doing with Triton DataCenter and give suggestions and feedback 02:33:07 as usual, I've mailed ptribble already, but for anyone else who likes tidying up the man pages, some things you may consider: https://pastebin.com/jvjhrqf0 02:35:54 one of those might even be jbk's fault 02:36:43 though more likely it was whoever at Sun merged his ls(1) changes into the man page gate long long ago 17:46:40 I apologize for being totally spaced out about this. Do we still need Sun Studio bits for building illumos anymore? 17:48:01 Nope 17:48:21 Not us 17:52:26 A code review of some Triton stuff mentioned Studio and I was like, "huh?" It's vestigal I'm sure, but I wanted to check if, even post-libm, we didn't need something from there. 17:53:22 OmniOS hasn't shipped it for a long time. Once it was no longer required there was (as I understand it) no legal protection for shipping it. 17:53:32 or whatever word the lawyers used 17:57:23 We have it still in smartos-live, due to some ancient OS-xxx bug (yes 3-digits) about mysql needing it. I should ask an OG Joyeur about it. 17:58:20 I'd very much like to kill it for good:D 18:13:16 Here's what we actually ship from it: https://gist.github.com/danmcd/7a4feb7af79653e7caab5014ce321238 18:14:31 Those files are *optional* on OmniOS (in the pkg:/system/library/c++/sunpro package). 18:18:15 The runtime libraries are still shipped for people who need to run old binaries that they either can't or won't recompile 18:19:49 And that's likely why we have it living in smartos-live still. 18:24:09 (and what we do have in smartos-live is merely the libraries and one header file). 18:24:46 so just C++ runtime and demangler support, really. 18:29:53 Yeah, that was all we were using it for. Feel free to reach out if you need more what were these people thinking questions answered danmcd. 18:35:38 No doubt it's due to the "C++ doesn't do compiler-independent ABIs" problem. 18:36:18 Yeah, pretty much. 18:39:58 that was basically fixed in later C++ standards by Studio just adopting the g++ ABI's and libraries instead of rolling their own 18:40:30 but enough damage had been done by the older generations that binaries had been compiled for 18:40:41 [illumos-gate] 15389 zfs-tests zfs_allow_003_pos fails due to unexpected property inheritence -- Bill Sommerfeld 18:41:33 I forget the details offhand, but when we removed that package from OmniOS there were multiple complaints. People run a surprising amount of closed source legacy stuff. 18:41:48 Yeah, our own reading(s) got us to the same place everyone above did. Thanks! 18:41:58 @bahamat and I will figure out what to do from there. 20:24:26 danmcd: there is C++ runtime stuff for people who managed to use it (libC, libCrun) that you might want, and there are math-library tie-ins that might still work. I doubt either practically matters unless people are running 3rd party binaries. 20:24:49 or rather, I bet what the people using those things _really_ want is the s10 zone brand. 20:31:22 Yeah. 20:51:57 is there a reason I'm spacing on why sys/systm.h is so sloppy about `extern`? 21:14:08 I sure don't know Rich (sorry). 21:19:01 Presumably the standard legacy reasons any code with oldest copyright year 1984 hasn't been brought up to modern C best practices - nobody's gotten around to it yet? 21:22:07 well my next question was how strlcat got in there (as well as sunddi.h) 21:22:20 perhaps I should just stop wondering things that don't directly matter right now 21:26:23 next you'll be asking why they decided to leave the 'e' out of the filename just to save one character 21:27:11 danmcd: sun studio libs can be use for oracle jdk8 amd64 version as i know 21:27:45 richlowe: Well, part of the extern thing is people are inconsistent and people grumble when I try to be consistent (as it impacts #pragma redefine_extname). 21:28:03 And so a lot of folks just say it's extern by default so I can leave it off. 21:28:25 So I probably wouldn't think too hard on the why extern stuff for the most part (ignoring the C++ duplications there which are surprising). 21:28:31 alanc: yeah it wasn't me.. my ls change didn't include any diffs to ls(1) -- someone at sun added those 21:33:18 sommerfeld: so the full story, I was checking where strlcat(9f) actually was, and as the manual page says, sunddi.h. It turns out though it's also in sys/systm.h, along with a weird selection of string stuff. The extern question is because strlcat isn't, and strlcpy is, and it sure seems like they'd have come in together. It seemed at least possible there were reasons I'd missed 21:33:39 secondary to "why the heck did all this stuff get in here?" 21:39:10 you should have that in your hg history - I can see strlcat coming in as part of x86 newboot in 2007, and strlcpy later (in our case, post-closing) 21:39:49 git blame answers the call: ae115bc77f6fcde83175c75b4206dc2e50747966 for strlcat, b819cea2f73f98c5662230cc9affc8cc84f77fcf for strlcpy (as part of 5917 User-mode SMB server) 21:40:29 https://github.com/illumos/illumos-gate/blame/master/usr/src/uts/common/sys/systm.h#L437 21:40:36 my git blame is still showing a progress indicator. 21:40:42 ah, bill beat me 21:41:22 unfortunately, x86 dboot doesn't answer much except "because they did it". 21:41:34 the xen folks threw an awful lot of crud into that putback 21:41:51 yeah 21:42:00 Maybe related to 6477867 x86 KDI should belong in the kernel 21:43:18 jlevon: what did y'all do? :) 21:43:30 the C++ weirdness also came from there 21:43:35 which is even more surprising. 21:48:03 it's now #15393 (fenix?) 21:48:04 BUG 15393: sys/systm.h has an incongruous mix of string functions iff _KERNEL (New) 21:48:04 ↳ https://www.illumos.org/issues/15393 21:54:10 richlowe: lord knows 21:54:35 He's pretty quiet though 21:57:22 andyf in which repo do you host the arm cross compile stuff for packages? 22:40:45 They are built out of the same omnios-build repo as the x86 packages 22:41:16 and they are in a repository at https://pkg.omnios.org/bloody/braich 22:41:56 Are you building NSS at al at the moment? 22:42:15 No, but richlowe is in arm64-gate 22:42:27 it doesn't look pretty! 22:42:54 No, NSS anywhere looks pretty I see 22:43:35 hmm, that typo changed the sentence completely 22:43:36 right, it seems like it's a bear to cross compile. I gave up and took what hayashi did, I think maybe hayashi gave up and took what Solaris did long ago 22:44:19 Well, the make based system seems only partially supported, since nss is using gyp 22:44:20 if I were caring about things like that, I'd honestly look into adding the other build dependencies I ignored because low-reward, rather than fixing that build, right now. 22:44:39 that might just be dbus/hal/glib 22:54:08 but the big push, the big good thing advantage, is what people are doing to build that stuff into a tiny actual distribution, so the build can be pointed at a proper full adjunct. 22:54:37 and then only the more important, variable, pieces need special handling for a bit longer. 22:55:28 Who is doing that? 22:55:37 I'm hesitant to give up the ability to start from absolute 0, but it is definitely more trouble than it is worth in any longer term vision. 22:55:51 True 22:57:34 I haven't seen much coordination on ARM so I am wondering who is doing the tiny distribution 22:59:28 I'm no narc :) 23:00:17 An invite would suffice :) 23:08:47 remind me, I'm getting tests running over the aw thing at the moment. 23:09:11 ok 23:30:38 one day, I will conquer bhyve v. zpool autoexpand 23:30:43 apparently not today 23:31:23 richlowe: What happened? Just no expansion? 23:31:31 It too shall fall 23:31:46 uncorrectable I/O, ate/locked the pool, same old same old 23:32:52 jclulow: boot, zpool set autoexpand=on rpool, or zpool online -e rpool c1t0d0 23:33:07 jclulow: image is from your image-builder, image disk is 5G actual volume is 15 23:33:42 tried the old tricks of zpool list -v, etc, to get the cache up-to-date, reboot after we refound the disk to get the labels up-to-date, etc, no dice 23:36:21 richlowe: current bits? 23:36:36 that is somewhat surprising to be honest 23:37:26 I mean, it's with my aw-removal bits this time, but I would assume I didn't break it. 23:37:33 What disk backend? ahci, vioblk or nvme? 23:37:38 vioblk 23:37:51 https://www.illumos.org/issues/14022 should presumably have taken care of that 23:37:53 → BUG 14022: zpool online -e breaks access to pool (Closed) | https://code.illumos.org/c/illumos-gate/+/2004 23:37:59 jclulow: I thought so too 23:38:04 That should be working, even with the VM up and running 23:38:18 which is mostly how I use it 23:38:57 I thought so too, that's why I did it 23:39:15 I can try on stock bits, but not right now because I don't have any 23:39:58 there was also https://www.illumos.org/issues/14978 for which I did a fair bit of testing with a scenario hopefully similar to the one you're describing 23:39:59 → BUG 14978: ZFS autoexpand property should work for root pools (Closed) | https://code.illumos.org/c/illumos-gate/+/2355 23:40:01 I wonder wtf! 23:40:11 It's always possible I'm cursed. 23:40:33 haha 23:40:57 it's not bhyve, but that reminds me i need to RTI the fix for zpool online -e w/ vmware 23:41:15 I think you may be.. https://paste.ec/paste/FJAbUFpj#3kGtOFFG1KxevSyQ-V2kwjyOyZusWtAzG38S9OgFoeu 23:41:16 jclulow: if you have stock bits to give it a quick try, it'd probably help narrow it down? 23:41:17 that one though shouldn't cause any panics 23:41:55 ok, so my volsize isn't growing, I have an image in a 15G zvol that believes it's 6G 23:42:11 the zvol at every point is 15G 23:42:14 I wonder if it's having fatal I/O errors because it is over quota? 23:42:22 if that matters? 23:42:42 it's just efi_use_whole_disk() doesn't like what ESX does to the disk label when it grows a disk offline 23:43:26 richlowe: I would expect we would use the disk label at the front and not find the backup one at the back where we expect, but otherwise drive on 23:43:39 But who knows 23:43:51 right, and zpool knows the device underneath it is expandable 23:43:52 etc. 23:43:56 but doing the expansion chokes it 23:45:03 all I'm doing is image-buildering a disk dd'ing it onto the zvol, booting, trying to expand the pool to fill the backing store. 23:45:11 nothing out of this world 23:45:13 yeah 23:45:43 It might be worth trying the nvme backend, if you haven't already 23:45:48 I haven't, but I can 23:45:50 and stock bits 23:46:00 I just want to get at least some of this testing I've been trying to start all day actually done. 23:46:47 I have your two ld things running through a bulk build - should have results in the morning but I'm heading offline now. Good luck! 23:47:01 g'night 23:58:04 richlowe: hmm, I successfully expanded a VM's root pool recently (backed by zvol). Used online -e