07:31:39 <tsoome> andyf how far are we about switching to gcc 10?
09:45:25 <andyf> I think we could do it. OmniOS has already switched and the only thing that has showed up as a problem since is the boot cpuid thing you already fixed. There are probably other issues but we won't find them without switching.
09:45:51 <andyf> There's one issue I had marked as a pre-requisite, but having gone through it I don't think it is, let me dig it out
09:46:58 <andyf> illumos 14421 (fenix) is the master issue
09:47:00 <fenix> FEATURE 14421: use GCC 10 as default primary compiler (In Progress)
09:47:00 <fenix> ↳ https://www.illumos.org/issues/14421
09:47:23 <andyf> and illumos 14749 (fenix) is the last piece I was looking at
09:47:24 <fenix> FEATURE 14749: gcc10 build should use -ftoplevel-reorder (New)
09:47:24 <fenix> ↳ https://www.illumos.org/issues/14749
09:48:19 <andyf> The thing is that gcc10 does not strip unused static functions by default, unless you use -ftoplevel-reorder, and if you use that then you lose a load of global statics which are only read too (due to constant folding)
09:48:49 <andyf> So I played around with different optimisation options etc. but in the end I don't think we want to strip all of the static global variables
09:49:21 <andyf> We definitely should go through and remove the static qualifier from any which are supposed to be tunables anyway, but not as a blocker for switching to gcc10.
11:16:16 <danmcd> ping tsoome
11:17:41 <danmcd> Testing the upstream merge which includes 14970 seems to break nfs-server-in-a-zone for TWO of my three zones.
11:19:15 <danmcd> The workaround is to set mountd_remote_dump to true, which seems to cure the problem.
11:20:40 <tsoome> breaks how?
11:21:07 <danmcd> nfs/server goes into maintenance.
11:21:20 <danmcd> I see one possible problem that might be specific to SmartOS.  Diving into it now.
11:21:42 <tsoome> does it tell why it cant get online?
11:21:45 <danmcd> What's WEIRD is that ONE of my nfs-serving zones isn't affected when mountd_remote_dump is false.
11:21:46 <danmcd> No.
11:21:52 <danmcd> mountd just returns '1'.
11:22:33 <tsoome> ok, if you get name from hostname commands, does it resolve to ip?
11:24:18 <tsoome> this code does add 2 cases when we exit(1) -- from gethostname() and from getaddrinfo()
11:24:32 <danmcd> Hang on.
11:25:10 <danmcd> WOW! Okay, this might be operator error on my part.  Please hold...
11:25:38 <tsoome> we also do: syslog(LOG_ERR, "gethostname() failed"); and syslog(LOG_ERR, "getaddrinfo() failed");
11:26:53 <danmcd> Sonofabitch, that's it.
11:27:28 <danmcd> So my two failing ones were build2 and build3.  Their /etc/nodename values were build-2 and build-3, but those don't have DNS entries.
11:27:48 <danmcd> Fix the DNS, fix the problem. Alternatively I could have fixed /etc/nodename to be build2 and build3.
11:28:05 <danmcd> Okay, I think I'm set, and I've bonus-tested your new feature.  :)
11:28:16 <danmcd> (The one that worked already was "build" )
11:30:05 <tsoome> The background is that nfs related commands do rely on hostname having ip address -- see showmount(8) for example. Thats why I did add check for IP for hostname. Altho, maybe we should ignore failing getaddrinfo()...
11:30:28 <danmcd> I see them:
11:30:55 <danmcd>  /var/adm/messages:2022-09-22T11:10:47+00:00 smartos-build-3 mountd[11959]: [ID 115315 user.error] getaddrinfo() failed 
11:31:17 <danmcd> Okay, crisis averted, no need to seize up the release.  Thank you tsoome!
11:31:33 <tsoome> you are welcome
11:31:35 <danmcd> (I was looking for them in syslog not messages.)
11:52:26 <tsoome> it was nice from Delphix to write test for btree, but why bugs in it....
11:54:39 <tsoome> fortunately smatch did find those.
13:13:21 <yuripv> that could be turned into a template: "it was nice from <insert-name> to write <insert-product>, but why bugs in it" :D
13:31:29 <tsoome> :D
13:31:56 <tsoome> I hope it is not c++;)
13:42:06 <otis> or /* XXX: how this even work? */
14:02:33 <tsoome> It was working, just leaking a bit;)
14:08:32 <Woodstock> did anyone here ever run illumos with X on a thinkpad w530 with nvidia k2000m gpu?
15:20:47 <travisp> Woodstock: I successfully ran OpenIndiana on a Thinkpad T530, I can't recall the specific nvidia chip it has but might be able to check later today.
16:08:17 <pmooney> mini-survey: how many folks' build pipelines would be inconvenienced if mail_msg was instead named mail_msg.txt (to make for easier handling in webmail clients and the like)
16:10:25 <tsoome> pmooney does not matter for me:)
16:15:51 <Woodstock> .txt is fine
16:33:11 <danmcd> I'll have to look...  would appreciate a diff so I can test it on a branch build, however.
16:33:53 <danmcd> Looks like I'd need to change a line in smartos-live:
16:33:54 <danmcd> tools/build_illumos:    mail_msg=$PWD/log/$log_dir/mail_msg 
16:34:30 <danmcd> I'm generally in favor of mail_msg.txt, however, given Mail.app's historical munging of vanilla mail_msg.
16:37:10 <andyf> It's probably easier than getting people to set their MIME types properly when sending in RTI emails..
16:37:42 <andyf> There's tooling that would need adjusting in several places in OmniOS but it's all possible
16:51:46 <pmooney> andyf: that presumes a mail client which even lets you set the mime type
16:52:24 <danmcd> ^^^
16:52:28 <pmooney> (and one which heeds it on the receiving end)
16:52:33 <danmcd> Also ^^^
17:20:32 <rzezeski> I think mail_msg.txt would be nice, I think the last few times I sent an RTI I added .txt extension
17:24:21 <jclulow> If we're going to rename it, probably "summary.txt" would make more sense?
17:24:56 <jclulow> also we should do https://www.illumos.org/issues/14516
17:24:57 <fenix> → BUG 14516: build summary should have an explicit success/failure message (New)
17:27:28 <pmooney> what if the result is at the bottom?
17:27:34 <pmooney> (probably easier to implement)
17:27:43 <pmooney> rather than having to cat it again, I assume
17:41:46 <jclulow> We already do that for the full build time
17:41:55 <pmooney> mm, true
17:42:23 <jclulow> I think it being at the top is useful
17:42:30 <pmooney> I guess another question is: should it still be "sending" email
17:42:49 <jclulow> ha ha
17:42:52 <jclulow> Probably not
17:42:53 <pmooney> as someone who has "mail<cr>d<cr>" in muscle memory
17:43:02 <jclulow> no mailx? :D
17:43:30 <jclulow> But yes, it seems somewhat anachronistic to send mail by default
17:44:40 <pmooney> well, I guess that's flag-controlled
17:45:04 <pmooney> time to PR a change to the defaults shipped by omnios, haha
17:57:48 <gitomat> [illumos-gate] 14485 bhyve needs better cpuid control -- Patrick Mooney <pmooney⊙pc>
18:21:00 <rzezeski> I like all these ideas
18:49:35 <dangergrrl> mail is often unimplemented by the local admin these days when all the world is a firewall
18:50:37 <dangergrrl> I have nginx working but i use dyndns so no way to get email on my domains and i am savvy enough to own some
18:51:27 <dangergrrl> gigabit fiber is $65 here with random IP addresses and $300 for a /24
18:54:15 <dangergrrl> so i have a great connection but my servers need dynamic ip, i can't afford static... perhaps a dynamic ip redirector should be part of core?
18:55:18 <dangergrrl> and sorry but it's time for project pitchfork
18:56:11 <dangergrrl> at any rate i strongly prefer illumos for a server, my raspi running linux is ok but...
18:56:19 <gitomat> [illumos-gate] 14997 unnecessary jmp in desctbls_asm.s -- Dan Cross <cross⊙oc>
19:02:12 <jclulow> pmooney: The thing with the flag is, will we still generate the mail_msg if we're not mailing?
19:02:20 <jclulow> That's why I have never tried turning it off haha
19:02:47 <pmooney> jclulow: it appears that the flag only controls sending of the mail, not generation of the mail_msg
19:02:55 <jclulow> ah good
19:03:07 <pmooney> indeed
19:05:54 <dangergrrl> why would you not have a mailer configured even if mailto:root is effectively /dev/null?
19:06:27 <dangergrrl> i wish to understand your reasoning
19:06:34 <jclulow> There is really no reason to have a mailer running at all if you are not intending to send mail or read mail
19:06:51 <dangergrrl> uhm, it's traditional?
19:07:10 <jclulow> If you go back far enough, panicking instead of returning EIO is traditional
19:07:27 <dangergrrl> mailto:root is for stuff you would rather ignore oif lazy :)
19:07:31 <dangergrrl> indeed
19:08:09 <jclulow> But sendmail is a security and configuration nightmare, and the better mailers are all similarly complex -- except for the ones that basically just use a smarthost unconditionally, but then for those, you need a smarthost
19:08:38 <jclulow> It's really hard to send SMTP mail in 2022 without a bunch of ongoing work
19:08:51 <dangergrrl> sendmail is indeed a nightmare, i usually use whatever is the current smail3 derivative
19:09:17 <jclulow> The only thing on the system that routinely sends mail is cron, and we could instead provide an option to write that into a tree of log files and then there would be no requirement
19:09:22 <dangergrrl> sorry, listening to ilatian/german musik
19:09:54 <dangergrrl> ilatian, is that a new word, it's mo-Do
19:10:50 <dangergrrl> who actually reads log files?
19:11:02 <dangergrrl> i know you should
19:11:11 <dangergrrl> but who does in 2022?
19:11:29 <dangergrrl> our unix boxes are mostly toys by now
19:11:54 <dangergrrl> please send me a deprecating answer
19:12:00 <jclulow> I read them when something breaks
19:13:22 <dangergrrl> i call here when something breaks and usually someone like danmcd has it fixed in under 30 minutes :) thanks danmcd 
19:13:48 <dangergrrl> i try to fix it myself but you guys are too cool to let me
19:14:10 <dangergrrl> and yes you are supposed to chuckle at that
19:15:09 <dangergrrl> someone even taught me to use the kernel debugger which could seriously use some symbolic features
19:15:39 <jclulow> It has symbolic features, it just doesn't have source-level debugging features
19:15:49 <dangergrrl> i can read assembly but random 64 bit addresses are odd'
19:16:18 <dangergrrl> jclulow i am not insulting
19:16:44 <dangergrrl> i should be able to fix it
19:16:45 <jclulow> Most of the addresses you see probably don't _have_ a symbol
19:17:15 <jclulow> They're often the address of a stack frame or something from kmem_alloc() etc
19:18:55 <dangergrrl> i have not seen that much JIT but i digress
19:36:59 <dangergrrl> anyway i don't understand at all how you get away with such few locking structures
19:37:15 <dangergrrl> and i must rest for q5h
19:37:51 <dangergrrl> i am old and we had to lock every object before use
19:50:22 <tsoome> anyone recently run zfs-tests?
19:54:12 <tsoome> my attempt is stuck with zfs hung due to testpool with faulted device or somesuch. time to trigger panic and get dump....
20:01:06 <danmcd> I've run some, but on SmartOS so there are ones that get skipped that might not get skipped in upstream illumos, etc. etc.
20:08:17 <tsoome> understandable.
20:10:04 <danmcd> Which test is hanging for you tsoome?
20:10:54 <tsoome> last one in log was setting the gzip levels, but I'll try to get some bits out from dump once I get the update done:)
20:12:05 <rzezeski> > It has symbolic features, it just doesn't have source-level debugging features
20:12:13 <rzezeski> jclulow: what if Robert reads this while on the plane?
20:12:36 <jclulow> Fortunately he is I think watching a movie and trying to sleep
20:12:42 <rzezeski> Robert you enjoy to have a peaceful vacation :)
20:16:53 <danmcd> I hope he isn't reading this on a plane!
20:19:19 <danmcd> What does the last line in your log say?  I can see how it corresponds to my didn't-panic run (and determine if it's one that got disabled or not).
20:21:05 <rzezeski> This is why I used this full name, hopefully he doesn't alert on that, haha
21:26:34 <dangergrrl> you know drobbins (funtoo) stopped trusting zfs like 2 years ago... :)
21:27:14 <dangergrrl> there was a data loss bug iirc and as if btrfs is better
21:28:21 <dangergrrl> and it could have been the linux porting team's fault so who knows, stuff breaks
21:29:27 <dangergrrl> 00000000
21:29:45 <dangergrrl> oops
21:29:59 <dangergrrl> now you know my client uses insecure passwords
23:39:48 <jbk> nice.. wasn't too bad to add mDNS support to smbd (right now just advertising _smb._tcp)
23:40:31 <jbk> now to deal with shares..
23:45:53 <travisp> Woodstock: my T530 has a different GPU: NVS 5400M though FWIW it works well on OI