00:01:08 <tomww> but this is only half of the story. the gcc implementarion in SFE tried to every load gcc runtime from /usr/gcc-sfe/lib/<major.minor> and *not* from /usr/lib/
00:03:28 <tomww> every binary in SFE buil with gcc has set LINK_LIBGCC_SPEC and has RPATH=/usr/gcc-sfe/lib/<major.minor>:/usr/gcc-sfe/lib ... that way
00:03:28 <tomww> the binary ha more luck in loading a gcc-runtime that really works, has the ABI that is of the correct version
10:00:09 <EisNerd> was there a problem with vnics at some point?
10:00:35 <EisNerd> I can't get the traffic to the zone working
11:24:02 <tsoome> EisNerd vnic may depend on what physical is down there
11:52:52 <gitomat> [illumos-gate] 13254 SEGV due to misaligned stack in Unwind_RaiseException -- Andy Fiddaman <omnios⊙ccu>
12:48:53 <EisNerd> tsoome: it is inside a esxi vm
12:49:09 <EisNerd> but in a neighbour vm ovs works quite well
12:49:32 <EisNerd> but it is for lab experiments only
12:49:49 <EisNerd> I configured an internal L3
12:50:01 <EisNerd> so etherstub+ ip forward
12:53:49 <EisNerd> tsoome: what puzzled me, was that arp requests made it to the network but the replies weren't received, but also on the physical network
12:54:20 <EisNerd> and dhcp was also working, at least the zone received an IP by DHCP
12:55:49 <tsoome> e1000g or vxnet3?
14:30:37 <EisNerd> the latter
14:32:01 <EisNerd> vmxnet3
14:32:28 <EisNerd> damn oi seems to have no support for lx branded zones
15:17:18 <gitomat> [illumos-gate] 13205 tem: we can use colors 0-255 with 8-bit depth -- Toomas Soome <tsoome⊙mc>
15:29:36 <pmooney> danmcd: the most thorough answer to your question is likely: "*shrug*"
15:30:03 <pmooney> I'd put it on the same order as "Copyright (c)" vs "Copyright" tbh
15:30:21 <danmcd> That's fine.  "Inherited from Pluribus" is a fine answer, please say that on list so nobody else whines about it?
15:30:34 <danmcd> Oh, this is #illumos.  Good enoguh.
15:30:42 <danmcd> (Thought it was DM.)
15:31:39 <pmooney> inherited would be a little strong
15:31:47 <pmooney> we asked what pluribus wanted for copyright and then added it for them
15:31:50 <pmooney> so blame me, if you want
15:31:54 <pmooney> since it's almost certainly my doing
15:32:10 <danmcd> NP.
15:32:26 <danmcd> Didn't see mail until now either.
15:35:23 <jlevon> pmooney: but patrick, that copyright format is crucial!
15:35:36 <pmooney> haha
15:36:04 <pmooney> I am in the camp of folks who are driven a little nuts by "Copyright (c)"
15:36:32 * pmooney mutters something about a PIN number or ATM machine
15:36:55 <jlevon> Copyright (c) (©)
15:37:38 <pmooney> "All rites reversed"
15:38:20 <jbk> and with halloween so close
15:38:32 <jlevon> hail eris
15:39:02 <danmcd> I'm with pmooney on the (c).. ick.
17:07:11 <jbk> pmooney: think it'd be good to send out an email on the various illumos lists to let people know to avoid windows virtio 1.8.9 drivers?
17:08:43 <pmooney> 0.1.189, but yeah
17:10:22 <jbk> oh.. i was going off what michael typed for the version :)
17:20:44 <jbk> it looks like KVM never implemented TRIM on illumos, so i don't think it matters there..
17:53:25 <sjorge> New bhyve call?
17:53:33 <sjorge> Driver/TRIM wrt windows was discussed on the user call
17:53:59 <sjorge> my older version was fine, newish fine too,... so was the in between version deemed the issue with the disk corruption?
17:56:08 <sjorge> Ah yep, just pulled up the notes
18:00:54 <pmooney> It's not at all clear how they broke that intermediate version
18:01:20 <pmooney> They don't seem to do corresponding tags in the git repo, so it looks like you have to pull the sources down to figure out what they built that version from
18:04:01 <jbk> i'm typing up an email for smartos-discuss right now, and will send out a bit more of general one for illumos after that
18:04:33 <jbk> (the smartos one includes the minimum PI version where the bad interaction can occur)
18:04:38 <jbk> since we can pin that down
18:11:53 <pmooney> thanks
18:15:54 <toastersonerson> Oh if we just had a tool where we could tag source code with versions...
18:16:12 <jbk> control it even
18:16:13 <jbk> :P
18:18:56 <gitomat> [illumos-gate] 13244 bhyve PM timer should be movable -- Patrick Mooney <pmooney⊙pc>
18:19:19 <pmooney> it's _in_ a git repo
18:19:24 <pmooney> they just don't tag or branch for versions :-/
18:26:23 <sjorge> So... you guess based on build timestamp?
18:26:27 <sjorge> Or don't they have that either?
19:00:01 <neirac> are there some "official" powered by illumos gifs images? I saw that daveeddy had one on his site
19:02:36 <ptribble> https://illumos.org/docs/about/logo/
19:02:48 <danmcd> I have one I use on kebe.com
19:02:58 <danmcd> Oh, thanks ptribble
19:03:23 <neirac> ptribble, danmcd thanks!
20:20:45 <tsoome> you can also see one on boot:D
20:22:54 <tsoome> (unless distro has its own)
22:10:14 <gitomat> [illumos-gate] 13253 bhyve stumbles on APIC ICRLO -- Patrick Mooney <pmooney⊙pc>
22:23:13 <wiedi> https://bugs.python.org/issue42173 <- ticket to drop solaris support
22:32:01 <rmustacc> If having build bots and test runners is something they need, we can probalby help out there.
22:33:07 <rmustacc> though I see you already mentioned that.
22:33:15 <wiedi> I've actually offerd to host one, but one requirement is to have the test suite pass and it currently doesn't :/
22:33:54 <rmustacc> How much of it fails?
22:33:54 <wiedi> It's something in the async module and it just starts to eat ram until it fails
22:34:04 <rmustacc> Is that the only failing test?
22:34:28 <wiedi> There were a few others, but they might have been due to memory pressure from the async one
22:35:00 <rmustacc> OK. It sounds like we should try and mobilize some folks to help there. Not sure who else from the OI/Omni side might have some cycles.
22:36:55 <wiedi> I'll also try to run a current version again on the weekend and see what has changed since the last time
22:37:54 <rmustacc> Having a starting point for knowing what's broken would help.
22:38:12 <andyf> I have recently been working on 5.9 for omnios and I fixed a fair few tests.
22:38:17 <rmustacc> If we have that, then let's also go to the OI and Omni dev channels and ask for folks to help get that started.
22:38:22 <despair> > end of pyton
22:38:27 <despair> oh no
22:39:14 <rmustacc> I suspect if we can get the test suite clean and have build runners, folks generally will be helpful. So let's focus on that and go from there.
22:40:48 <LeftWing> andyf: Have you been pushing those fixes upstream, or maintaining them as patches locally?
22:41:01 <LeftWing> I suspect we have probably all held some projects like Python a bit at arms length
22:41:05 <ptribble> We have more usage (from their stats) than AIX, OpenBSD, or NetBSD, although I suspect this indicates that it's not a useful metric
22:41:29 <andyf> The're local patches for now. Python 3.9 will be going into omnios r151037 so I haven't started looking at upstreaming yet
22:41:37 <andyf> Most tests are passing, see https://github.com/citrus-it/omnios-build/blob/python39/build/python39/testsuite.log
22:41:57 <andyf> with the notable exclusions documented here
22:41:58 <andyf> https://github.com/citrus-it/omnios-build/blob/python39/build/python39/files/test.exclude
22:43:28 <andyf> the fact that we have different sendfile() semantics in regard to going past the end of the file is the source of quite a few tbh
22:44:44 <rmustacc> So which of those do we need to get working for them to be OK versus them OK with skipping?
22:44:53 <andyf> LeftWing - when I started bringing the patches forward for 3.9 though, I noticed that some of the old 3.7 patches had been upstreamed by Oracle
22:45:20 <andyf> rmustacc - That's the question. The tests do have quite a few platform exclusions around them
22:45:41 <andyf> and, for example, the passing of multiple SCM_RIGHTS messages in a single packet is not something we do
22:45:51 <rmustacc> OK. Well, it sounds like we should get some folks willing to help upstream patches and then in parallel we can work out the hosting thing.
22:45:51 <andyf> so that entire batch of tests needs skipping
22:46:16 <rmustacc> And on that thread it looks like some folks already offered to help host.
22:47:21 <rmustacc> LeftWing: Yeah. We should probably figure out who all we need to do better outreach to beyond python.
22:47:41 <rmustacc> I know you and pmooney have done a lot with Rust, ptribble with Java, etc.
22:51:08 <wiedi> andyf: cool, that looks pretty good
22:51:21 <andyf> We try to upstream and engage where possible from OmniOS, but haven't done anything with python
22:51:49 <andyf> The recent 3.9 work was the first time we started fresh instead of just brining Oracle's patches forward and as a result it's quite a lot cleaner
22:52:23 <rmustacc> That's good to hear.
23:11:53 <nbjoerg> does illumos have any hooks for running a script when addrconf assigns a new address?
23:15:19 <LeftWing> I am not sure about addrconf, but dhcpagent seems like it will run a program on changes (see the dhcpagent manual page)
23:18:53 <nbjoerg> hm. that seems to apply only when dhcpv6 is used (which I don't)
23:19:13 <nbjoerg> alternatively, a simple way to run a script on changing to the routing table would also work
23:24:51 <LeftWing> I don't believe there are any sysevents for IP address or routing changes today
23:25:02 <LeftWing> So syseventadm(1M) is no particular help here
23:25:20 <LeftWing> I suspect the easiest thing to do is have a program listen for routing socket messages
23:25:55 <LeftWing> RTM_NEWADDR and/or RTM_IFINFO are probably interesting; see route(7P)
23:26:09 <LeftWing> https://illumos.org/man/7P/route
23:27:34 <jbk> i wonder how nwam is doing it (I'm guessing it might want to do things when addresses change)..
23:29:24 <LeftWing> It uses routing sockets
23:29:49 <LeftWing> See also: cmd/cmd-inet/lib/nwamd/routing_events.c
23:30:10 <LeftWing> In particular, routing_events_v6()
23:30:35 <LeftWing> And nwamd_routing_events_init() for setup of the socket and the thread
23:32:22 <andyf> wiedi - thanks for bringing the python thing up. In a few weeks once python 3.9 is in omnios bloody, I'll be in a position to start upstreaming some of the local patches we carry and looking at the failing tests in more detail. If we can get the tests clean and get a test runner in the mix, and convince them to keep the Solaris/illumos support, we should be ok..
23:33:07 <andyf> The only thing is that I don't have much time, and don't really know that much about python
23:34:43 <andyf> and I imagine Oracle will want to keep the support there (@alanc?), with Solaris being supported out to 2034 or so last time I looked
23:35:00 <LeftWing> In the limit I expect we will want to distinguish ourselves
23:37:36 <andyf> Indeed
23:38:03 <alanc> andyf: yep, I responded to the originater of this proposal on twitter ( https://twitter.com/alanc/status/1321952853980778497 ) and passed the bug link on to our python maintainers (who are in timezones where it's the middle of the night right now)
23:42:56 <andyf> Thanks - I just added to that twitter thread too