00:30:52 tsoome_: LANG=C.UTF-8.. LC_CTYPE="C.UTF-8" etc 00:33:08 tsoome_: as in, like this: https://0x0.st/XVcl.png 00:33:09 https://0x0.st/XVcU.png 00:33:18 you can see the unicode blocks showing up as M instead 04:51:30 I asked, because LC_* varaibles will override LANG. However, what does stty -a report? 07:00:35 tsoome_: https://0x0.st/XVmi.png 07:00:44 tsoome_: xterm on top, xfce4-terminal on bottom 07:02:23 Oh, interesting. It's not working in durdraw, but the characters work if I cat a unicode file 07:02:42 Hmm. Durdraw uses python curses 07:05:01 Yep. Must be something with how durdraw is using curses and/or python. https://0x0.st/XVmX.png 07:06:10 Hm. Does that need ncursesw as opposed to regular ncurses? 07:09:31 Hmm. Maybe. :) It shouldn't really, though I'm not sure what happens if you try to use wide characters in regular curses. durdraw will draw wide charaters, but isn't aware of them 07:09:43 the calls should be just to regular curses, through the python stdlib 07:09:59 but it is using some panels features that aren't in older curses versions 07:10:22 that said, I probably developed it against ncursesw 07:17:23 IndyJoenz thats output from gnu stty, what does /bin/stty show? 07:20:16 tsoome_: https://0x0.st/XVmq.png 07:21:05 ok, so terminal lines should pass data as expected... 07:22:39 we could also check that with dtrace but given stty output should be sufficient... 07:23:33 Yep, it needs ncursesw - just built a temporary copy for testing 07:23:49 ptribble: nice :) 07:26:15 Which means it would work in other distributions, which explicitly enable ncursesw, but Tribblix always starts with whatever upstream ships as defaults and only changes them when a problem shows up 07:26:45 Ahh. I was wondering why the system python build wasn't sufficient 07:29:26 I think python just looks for some curses library and isn't too bothered about the details 07:32:57 But anyway I'll switch ncurses to ncursesw and we'll see how much else I have to fix 07:35:39 there shouldn't be too much, I did the switch recently in pkgsrc, and most of that was mechanical to support NetBSD's native curses 07:37:05 What I meant was breakage without rebuilding, as the docs says that wide and non-wide aren't binary compatible 07:38:03 ah, that's a foreign concept to me ;) 13:52:07 [illumos-gate] 15279 lex: clang build error -- Toomas Soome 14:40:00 [illumos-gate] 16687 iasl: storing the address of local variable -- Toomas Soome 17:00:06 [illumos-gate] 16684 Solaris 10 zones and libproc broken by new parameter to fcntl -- Robert Mustacchi 17:13:02 btw, the thread starting at https://lists.gnu.org/archive/html/autoconf/2024-08/msg00006.html is about illumos ksh93 not playing nicely with GNU autoconf 17:29:01 Thanks alanc. It's reported on a pre illumos 13405 system so I expect current systems are okay but I'll offer to help them test if the OP doesn't volunteer. (fenix) 17:29:02 FEATURE 13405: ksh93 update to 2012-08-01 (Closed) 17:29:02 ↳ https://www.illumos.org/issues/13405 | https://code.illumos.org/c/illumos-gate/+/1176 17:49:02 Thanks for taking a look, Andy. 17:50:15 * alanc hangs head at USDT probes being called "Linux-specific" in https://www.openwall.com/lists/oss-security/2024/08/06/9 18:12:04 alanc: lol 18:12:20 I suppose that's how you know you've had a good idea, at least 19:28:13 if you combine both .Xr and .Lk in a SEE ALSO, it kind gets difficult to read. Do we have an idiomatic way to put a line break in to tidy things up? 19:35:01 I've used regular old `.sp`, but it feels weird in mdoc 19:56:07 .Pp ? 19:56:32 I think that's a full paragraph break, rather than just a newline? 20:00:17 https://mandoc.bsd.lv/mdoc/appendix/markup.html has some notes but it's hard to interpret. `.br` is mentioned 20:03:34 well, it works as well as `.sp`, and it was mentioned, so I'll do that. thanks!