10:54:45 hello all the OS/kernel developer, do you advice DISM on illumos related fork? (on x86_64 platform), I read some document that do not advice enable DISM for x86 platform, is it safe? 10:55:08 the postgres had DISM enable on omnios’s package 11:28:47 Hey all. any idea where I can find the EBNF of DTrace? 13:27:41 eBNF on Linux and DTrace on Illumos/Solaris, FreeBSD and macOS 13:27:58 DTrace is also available on Linux afaik but not much used 13:39:21 I think they mean the extended backus-naur form for the DTrace language, not eBPF 13:41:34 ah yes reading what I wanted to see not what was written 13:41:55 in that case no idea 13:42:10 as for the question I don't know the answer, but I'd look in the dtrace directories in illumos-gate for any .y files that you could convert to BNF 14:05:30 https://src.illumos.org/source/xref/illumos-gate/usr/src/lib/libdtrace/common/dt_grammar.y?r=8019f4e7 might be what you're looking for 14:48:42 Hi, all. I think, I find a bug on Illumos about pseudo-tty, it will convert tab character to spaces. 14:49:27 See: https://www.postgresql.org/message-id/MEYP282MB1669E2E11495A2DEAECE8736B6A7A%40MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM 15:12:37 There are two illumos build farm members, hake and pollock, which are showing green for regression tests at https://buildfarm.postgresql.org/cgi-bin/show_status.pl?member=pollock&member=hake&member=haddock - I wonder if the build flags are a bit different, or if that test is somehow excluded in the build farm (that would be a surprise, but I haven't checked) 16:27:20 The reproducer defines _XOPEN_SOURCE=600 but nothing else, which means it gets strict XPG4v2 behaviour 16:27:59 There's https://www.illumos.org/issues/12306 in which we prevent people stumbling into this by accident 16:28:00 → BUG 12306: XPG4v2 slave pty behaviour should generally be disabled (Closed) 16:30:30 Quick fix is to define __EXTENSIONS__ too 16:33:00 at some point, we should just make that the default... i would be shocked if our defaults have prevented more problems than they've caused at this point 16:33:47 * danmcd looks at XNET sockets and wonders why they aren't default... for that matter, the existence of libsocket and libnsl as distinct entities... 16:45:34 alanc, thanks for your input earlier - here's the signals diff for coreutils in case you want to have a look: https://github.com/uutils/coreutils/compare/main...bbarker:coreutils:illumos_sunos?expand=1 16:46:20 also a few other changes needed to get the coreutils project to build 16:48:33 welcome a review from others as well of course should anyone want to have a peak - i'll probably post a PR to the coreutils project later this evening 19:35:00 danmcd: we've been wanting to merge libsocket and libnsl into libc for years, both yurip and i have done different takes on it. There are symbol collisions and points of confusion. 19:35:50 I think what we each ended up doing was leaving problematic bits behind, but it didn't feel entirely complete (at least mine didn't) 19:36:31 we'd talked about a short term (already scary, it never is) solution of filtering the important symbols onto them out of libc, as things stand now 19:37:16 that is accept(3SOCKET) (or 3XNET) stays where it is, but libc gains a filter so it appears in libc also 19:37:42 obviously this all really requires the socket/xnet thing done first, or careful checks that 3xnet can still interpose fully and correctly 19:38:18 if I recall, nsl has less compat things to think about, but more direct symbol collisions 19:38:42 danmcd: with your understanding of our networking history, you'd be ideal to fix these things... 19:39:06 the best I can do is tell you about the link editor, and the makefiles involved. 20:04:51 Yeah... I know it's scary. It's why I haven't done it ever. Also, I'm trying to get back neck-deep into mlxcx. 20:14:45 The big thing that motivates me on this front is sendmsg() and recvmsg() which is VASTLY different between pre-xnet and xnet. 20:15:08 (Something about old SunOS 4 apps was why we never ripped off the band-aid.) 20:19:22 the xnet v. socket thing is most unfortunate because you can't build test that 20:19:29 unlike pulling libnsl or the old libsocket into libc 20:19:44 (though not all of libsocket into libc, because you have to check it doesn't break xnet...) 20:20:29 libnsl into libc should at least be smooth, if you pick the interfaces to come along and filter only those back out of libnsl, or filter them from libc onto libnsl (either way is an architectural mess, but it has to happen one way or the other) 20:43:03 In my perfect world I'd burn pre-xnet to the ground. I can see jperkin and others grinding their teeth over the sheer amount of recompilation (and `configure` testing) that'd need to get fixed, however. 21:02:01 jperkin is wonderful for recompilation testing, and has done so much for me and others, and deserves much more credit 21:02:13 the challenge is that it changes _behaviour_, we know things build, but will they work? 21:02:47 sorry, I'm getting the iconv cleanup ready for RTI and actually writing my research into the bug, or trying to 21:03:07 I kinda wish someone could confirm it for me, just because it seems so haphazard 21:03:36 "We need a mapping from one byte to another" ... "You know what does that? Keyboard maps!" 21:23:18 Ah, dos2unix! 21:25:13 I suppose the ARM port has to figure out if they want to change the man page to stop saying "non-i386" or change the behavior to use something more sane like $LC_CTYPE 21:26:21 also, "This command can be invoked from either DOS or SunOS." seems like a leftover from the old suni386 Merge environment 21:29:33 there is so much manual page work that will be necessary 21:29:34 so much