01:52:02 <gitomat> [illumos-gate] 16233 pcieadm readiness time reporting decoding -- Robert Mustacchi <rm⊙fo>
02:36:21 <gitomat> [illumos-gate] 7125 Provide execvpe -- Robert Mustacchi <rm⊙fo>
08:50:22 <CutieMelo> Which usb wifi dongle does illumos have support for? I have a realtek card and it obviously doesnt have drivers for it so I need an external one for my laptop
12:16:25 <tsoome> CutieMelo have no idea really, sorry.
12:24:23 <CutieMelo> okay
13:58:12 <antranigv> Hello! I will be giving an illumos talk today at a local event... if anyone can check my slides for mistakes, will be very happy :) https://antranigv.am/misc/OmniOS.pdf
13:58:28 <antranigv> I will also try to record the talk, altho it will probably be in Armenian, depending on the audience.
14:08:09 <ptribble> You could mention LibreOffice (ex-OpenOffice, ex-StarOffice) as another thing to have come, albeit indirectly, from Sun
14:55:43 <KungFuJesus> Any chance this can get attention again? https://www.illumos.org/issues/15024
14:55:45 <fenix> → BUG 15024: NFS can exhaust pool threads getting RPCSEC_GSS credentials (In Progress) | https://code.illumos.org/c/illumos-gate/+/2402
14:56:15 <KungFuJesus> we had this issue yet again today where the machine was basically non-responsive, with this error message: /usr/lib/nfs/nfsd[771]: [ID 791759 daemon.error] t_rcvrel(file descriptor 552/transport tcp) Resource temporarily unavailable
15:00:19 <jbk> hrm.. i bet matt forgot about it... i can ping him after this meeting
16:43:40 <rzezeski> oh, these thread names in prstat -L are fancy. I don't remember this. Is this new(ish)?
16:49:34 <jbk> 2018
16:50:00 <jbk> which for the illumos code base, could still qualify as 'new' (relatively speaking) :)
16:55:11 <paulf> https://github.com/illumos/illumos-gate/blame/master/usr/src/head/pthread.h#L250
16:55:35 <jbk> the whole change was started because someone (I think I remember who) was whining about how smartos didn't have it
16:56:13 <paulf> well it is _np
16:56:14 <rzezeski> honestly I probably just never ran things that used it, I was just watching the build with prstat -L and noticed it for some binaries. Not sure how useful it is but it looks cool.
16:56:59 <jbk> i can't recall which ones jlevon added, but for the bits I did, I tried to pick things where I thought it would be useful to be able to tell what was going on
16:57:34 <andyf> It's been useful for bhyve processes
16:57:48 <jlevon> rzezeski: whenever you have a number of otherwise identical worker threads it's very handy
16:58:12 <rzezeski> good to know
16:59:58 <jbk> rzezeski: similar motivation for ptree -g (whining)
17:23:46 <sommerfeld> hmm, ptree -g doesn't use the box characters for me as I use a hybrid locale (mix of C and C.UTF-8)
17:24:05 <sommerfeld> setlocale returns something like "C.UTF-8/C.UTF-8/C.UTF-8/C/C.UTF-8/C.UTF-8"
17:25:25 <sommerfeld> ptree.c should probably use LC_MESSAGES rather than LC_ALL ..
17:25:47 <sommerfeld> (I set LC_COLLATE=C because I don't like how LC_COLLATE=C.UTF-8 sorts things)
17:26:27 <rmustacc> MESSAGES doesn't feel right there, tbh.
17:26:50 <rmustacc> As I thought that was just about translation and not what you can accept, but hard to say.
17:30:01 <sommerfeld> Perhaps "if (p != NULL && (p[5] == '\0') || (p[5] == '/'))"
17:30:39 <sommerfeld> intent: if any locale component ends in UTF-8, we assume you can cope with UTF-8 output on stdout.
17:31:59 <sommerfeld> parens not right in the above but you get the idea
17:42:58 <sommerfeld> sqlite3 just sends the box characters if you say .mode box without doing any other checks.
18:01:36 <jbk> maaaybe LC_CTYPE since that determines (among other things) what is printable? I think LC_ALL was just the more conservative choice at the time
18:42:32 <rmustacc> jbk: Yeah, I guess if it's not printable we wouldn't want to. So maybe that's the least bad option.
18:52:22 <copec> tozhu left, but their NVMeoF vs NVMe/TCP vs iSCSI results made me think they hadn't tuned any TCP/IP settings under the Linux kernel
19:05:38 <tomww> is it possible to run a command with memory-limit? e.g. ctrun -o max-virtuelmem=1G thisprogram  ?
19:41:32 <ptribble> How about ulimit -v ?
19:42:10 <ptribble> (The snag there being that it applies to the current shell, so you can't set it too low or that gets killed off.)
19:48:36 <richlowe> we don't support rctl's to -o no
19:48:44 <richlowe> but supporting rctls like that somewhere sounds great
19:48:46 <richlowe> for contracts
19:54:52 <sommerfeld> I don't think we have virtual memory limits at contract/task/project scope - only zone and process scope if I'm reading correctly
19:55:23 <sommerfeld> I used to run firefox with a memory limit (ulimit) but then it went multiprocess and that became ineffective...
20:00:08 <antranigv> hmm... dmake: Warning: Command failed for target `pics/ctf_create.o'
20:00:15 <antranigv> I wonder if I missed something from the building docs
20:00:18 <antranigv> trying again
20:12:31 <richlowe> antranigv: the useful message is usually the one before the first instance of "*** Error code"
20:12:51 <richlowe> `less '+/Error code' log/latest/nightly.log` and then scroll up a bit :)
20:36:41 <tomww> thank you all!  At the moment I test smth like "unlimit -v 100000" 
20:38:59 <tomww> something like the ctrun with the usual resource controles from prctl/projects/... would be very neat. Doesn't need the workaround of defining projects and such. Just put in your script or crontab ctrun -o mem=1g thisprogram
20:40:46 <tomww> it could be wrapper that creates a random project on the fly and spawns the badly behaving program just into that context
20:58:38 <gitomat> [illumos-gate] 16246 ttymon: tty-mode line is not read when terminal name is set -- Toomas Soome <tsoome⊙mc>
21:00:23 <antranigv> Turn out here's the issue... dmake: Warning: Command failed for target `smatch.o'
21:00:33 <antranigv> but I have no idea where that target comes from
21:00:43 <antranigv> here's the log file if anyone's interested: http://build0.illumos.am/log/log.2024-02-08.20:54/nightly.log
21:01:35 <tsoome> this is the reason: sh: /usr/gcc/10/bin/gcc: not found [No such file or directory]
21:02:07 <antranigv> huh.....
21:02:19 <antranigv> I thought illumos-tools from OmniOS would download that automatically
21:02:23 <tsoome> if you are building in omnios, it is in /opt/gcc-10 
21:02:32 <antranigv> ahaaaaa
21:02:44 <tsoome> your env file is to blame
21:02:58 <tsoome> you need omnios-illumos 
21:03:24 <antranigv> I just copied the default one from illumos-gate... I'll go over the docs again, maybe I missed that step :))
21:05:27 <antranigv> for now I'll modify the illumos.sh file manually as much as I can, just to learn more about it.
21:06:14 <andyf> Yes, you need the file in /opt/onbld/env/omnios-illumos-gate or one of the ones from https://downloads.omnios.org/env/
21:06:54 <andyf> The one in gate is pretty much set up for OpenIndiana as far as I remember
21:07:22 <sommerfeld> It's close but not quite right for OpenIndiana
21:08:38 <sommerfeld> I have to set PKGVERS_BRANCH and several PERL_* variables.
21:09:57 <andyf> I should probably dust off https://illumos.org/rb/r/2360/
21:14:33 <sommerfeld> BTW, stumbled across a bit of an oddity in our terminal code which trips up Python.   https://github.com/illumos/illumos-gate/blame/0c4d3ec56b3e8f2f8bcc4dbe1eb32871e2663b39/usr/src/uts/common/io/ptem.c#L936-L943
21:14:54 <sommerfeld> you can't get the window size of a freshly created pty until you set it once.
21:15:05 <andyf> Ah, that rings a bell
21:15:06 <sommerfeld> and python refuses to set the window size until it gets it once.
21:15:59 <sommerfeld> I think the linked lines should just be purged.
21:16:23 <sommerfeld> (to be more precise, you get an EINVAL if all four dimensions are zero)
21:16:27 <andyf> https://github.com/citrus-it/omnios-build/blob/py312/build/python312/patches/test-termios.patch#L8
21:19:08 <sommerfeld> I fixed it with https://github.com/Bill-Sommerfeld/oi-userland/blob/py312/components/python/python-312/patches/50-termios-set-before-get.patch
21:19:57 <andyf> I prefer yours, and yes, those lines do look rodd.
21:20:00 <andyf> and odd too
21:44:41 <antranigv> how long does it take to make a full build... usually? I have a pretty modern system (24 cores, 46GB of RAM, AMD EPYC 77something)
21:50:56 <andyf> 53 minutes was the last one I did - that's both non-DEBUG and DEBUG, and using both shadow compilers.
21:51:18 <sommerfeld> I have a system with 4 cores/8 hyperthreads and 24G and it takes 2+ hours with shadow compilation and both DEBUG & non-DEBUG
21:51:25 <andyf> Looking at the build logs (mail_msg) that people submit along with changes to the https://illumos.topicbox.com/groups/advocates is quite useful
21:52:15 <tsoome> RTI builds are supposed to be debug+non-debug, on my system its about 50 minutes 
21:52:21 <andyf> https://illumos.topicbox.com/groups/advocates/T8d9606f42371bfff-M1c65df152818b4edf2e8abc6/16233-pcieadm-readiness-time-reporting-decoding was 24 minutes
21:53:30 <sommerfeld> I'm overdue for an upgrade :-)
22:00:46 <antranigv> ==== Total build time ==== real    0:35:00
22:01:04 <antranigv> Not sure if this was DEBUG or not... have to check the default env file...
22:01:53 <andyf> The mail_msg file under log/latest/ will have the details
22:02:18 <andyf> and show you which shadow compilers were used too
22:04:08 <antranigv> I should get a package dir... no? I don't have it
22:05:28 <andyf> unless there was a build error, yes, mail_msg will tell you
22:10:24 <antranigv> I see
22:10:30 <antranigv> I also see errors
22:21:41 <antranigv> ah... perl :))
22:22:55 <jbk> i really need to pick back up my 'theperlthe' branch
22:57:55 <gitomat> [illumos-gate] 16226 yacc: remove WSFMT macro -- Toomas Soome <tsoome⊙mc>
23:06:31 <antranigv> Now this is new for me. After running nightly.sh, I see that a large number of files are untracked (according to git status), is that normal or am I doing something wrong?
23:06:40 <antranigv> ah, I see, untracked... not modified
23:06:46 <sommerfeld> yes, that's normal
23:06:47 <antranigv> they are the generated files
23:07:39 <sommerfeld> most people set status.showUntrackedFiles=no 
23:53:25 <antranigv> So... it's done... can I just run software now or do I always need to use `onu` to install it?
23:57:19 <antranigv> according to onu, nope, I need to install in a BE. okay, when I guess I can mount the BE and... run it as a zone?
23:57:48 <rmustacc> In terms of running the software, depends what you modified.
23:58:05 <rmustacc> In general I don't recommend a zone based on a disjoint BE.
23:58:28 <rmustacc> Most things need to be in sync (e.g. libc / kernel and other private interfaces), but depends a lot on what you modified.
23:58:43 <rmustacc> If I just modified a single binary to fix something or library, I often cheat and lofs mount or similar.
23:58:46 <rmustacc> But it all depends on the specifics.