00:39:55 <gitomat> [illumos-gate] 14972 some diskinfo error messages run into the next line -- Joshua M. Clulow <josh⊙so>
02:27:03 <jbk> gah.. if only more system daemons linked against libumem by default
02:34:38 <jclulow> they could!
03:33:53 <jbk> yes.. then i would have saved myself more time than I care to admit on my own bug :)
06:08:17 <yuripv> andyf: hi, did you see similiar issues with pkg server on bloody? https://pastebin.com/S7ptyFiC
06:09:01 <yuripv> looks like it's not happy with cherrypy (whatever that is), but i can't find related package (?)
11:12:20 <andyf> That rings a faint bell.. I would try running this small test script to check that cherrypy is loading properly (and it might throw out a message about the real problem)
11:12:23 <andyf> https://github.com/omniosorg/omnios-build/blob/r151042/build/python310/cherrypy/test
11:13:43 <andyf> Knowing cherrypy, they could have added yet another jaraco.* dependency...
11:15:44 <yuripv> ModuleNotFoundError: No module named 'cherrypy'
11:16:03 <yuripv> looking through history, it now ships with pkg itself, so i need to tell python somehow about it?
11:19:09 <andyf> Ah yes, sorry, try https://paste.ec/paste/4Uaz2s8u#kcUCbucCwAbPwunzq8+J8qQmyKXF-MNCVO+j/inoptk
11:23:15 <yuripv> now it's not happy with pkg_resources: ModuleNotFoundError: No module named 'pkg_resources'
11:23:36 <yuripv> this is likely the real error here? i see that cherrypy returns "unknown" as version
11:23:59 <yuripv> (which breaks pkg.depotd check)
11:24:14 <andyf> yes, that's probably the real issue. I wonder where that comes from (pkg_resources) - it sounds built in
11:25:19 <andyf> part of setuptools-310 - is that installed?
11:25:24 <andyf> Could be a missing dependency in pkg here
11:26:01 <yuripv> installing (it wasn't)
11:26:35 <solitario> w/39
11:26:40 <yuripv> yay, that fixed it, thanks!
11:27:16 <andyf> Great, I'll get it added as a dependency for pkg, and find out why it was not automatically detected
16:43:57 <gitomat> [illumos-gate] 14992 dead code in desctbls.c -- Dan Cross <cross⊙oc>
17:55:24 <jclulow> tsoome, andyf: Unfortunately I had to make https://code.illumos.org/c/illumos-gate/+/2355 more complex, when you get a moment to have a look
17:55:25 <fenix> → CODE REVIEW 2355: 14978 ZFS autoexpand property should work for root pools (NEW) | https://www.illumos.org/issues/14978
18:57:45 <tsoome> jclulow aye, I already did read it, just wanted to get back to it a bit later:)
19:00:06 <jclulow> Thanks!
19:08:21 <tsoome> Basically the point is, we prepare zfe_mod to have valid device names beforehand?
19:09:52 <andyf> jclulow - I'll take a look
19:15:04 <tsoome> External Bug is nice;) /me likes
19:18:40 <andyf> jclulow - so the pool import kicks off the autoexpand task, and that sends a DLE sysevent for all of the VDEVs, and now the sysevent handler does a refresh before re-opening the pool and calling vdev_online().. did I get that about right?
19:21:14 <andyf> (and TIL that pools with autoexpand get opened twice during import..)
19:26:04 <jclulow> Yes the DLE event is always handled by the module in syseventd today 
19:26:23 <jclulow> And now we're doing the refresh that "zpool status" does
19:28:19 <andyf> Thanks, makes sense
19:54:09 <tsoome> right. of course you get white space noise while preparing the RTI mail.