08:28:07 <nikolam> What's the actual point of 'naming' SmartOS releases? Not wanting to bike-hedding but naming itself seems silly a bit. Won't hurt if not used for anything important like folder names or referenced on web interfaces, like in debian/ubuntu and in some caes macos
08:32:52 <jperkin> historical, primarily for tagging issues in jira, each 26 run through the alphabet is a different theme
08:34:50 <neuroserve> why not?
09:00:23 <nikolam> :, it is silly plus who is gonna remember the silly names, ever. Maybe ok for marketing, nothing in system, like macos also have release names but except for marketing who needs remembering that. Always waste of time when trying to find out names vs release numbers. 
10:28:07 <jperkin> nobody needs to know anything about them, they aren't for public consumption
10:28:43 <jperkin> all users and customers need to know is uname -v and the tags for each service listed in /etc/motd
13:51:05 <neirac> nikolam uname -v is an option
13:55:37 <neirac> how do I generate a webrev? I tried running webrev but failed with https://termbin.com/diit 
14:22:20 <neirac> I was looking to resurrect SO_REUSEPORT, I have sync the code and seems to work for tcp, but for udp I'm getting bind address already in use, this is the current patch https://termbin.com/0oj8
14:24:27 <andyf> webrev seems to be working for me. In your output it looks like $GIT is empty somehow
14:25:34 <andyf> I generally just use gerrit these days. I have almost become used to it over reviewboard now.
14:28:26 <neirac> andyf oh ok, I won't waste more time in webrev then. I'm trying to add SO_REUSEPORT most of the work is already done but I'm failing udp testing maybe I missed to update more code on the udp side
14:33:11 <neirac> mostly the idea is to use unbound with SO_REUSEPORT it will improve performance AFAIK
16:20:28 <Woodstock> andyf: it seems I have to rm -rf ~/.omni and ~/omnios and start over completely get past the build errors. the first build after "omni setup ~/omnios" usually succeeds, subsequent rebuilds don't :-(
16:20:49 <Woodstock> oh, wrong channel. sorry.
17:27:52 <barfield> Sometimes when provisioning on current platforms joyent_20240111T002438Z specifically, bhyve's with large amounts of CPU and ram, ie: 32 vcpus and 192GB of RAM, provision with no errors but never boot. I have to login to the compute node and `vmadm reboot <UUID> -F` and then it will come online. Is anyone else seeing this?
17:28:15 <barfield> The GZ has no other workloads in this instance. 
17:29:03 <barfield> GZ has 48 cores, 256GB of ram, and 5TB of disk
17:29:53 <barfield> and now I need to backtrack a bit. because I `vmadm console <UUID>` the VM, saw the grub loader, but now it is just hanging on "Booting `Fedora Linux*`...so maybe it is in the VM
17:31:00 <barfield> VMM Memory               50339840            196640   75%
17:31:12 <barfield> Wondering if I need to reserve >25% for the GZ
17:31:20 <barfield> Intel 40GB Nics are in the mix
17:48:45 <barfield> pci_fbuf: munmap_memseg failed
17:48:50 <barfield> Found that in platform.log
17:49:25 <barfield> looks like video error meh
17:49:59 <barfield> okay disregard, its a linux issue. Boots with an older kernel