07:29:37 FYI: With our apologies for the delays, the manual and the HCL are back online; i.e., https://illumos.org/man and https://illumos.org/hcl 09:26:54 Hi. I have a documentation patch for memory(3c), but I have no idea where to send the patch. I've read https://illumos.org/docs/contributing/ and it points to create an account on issue tracker, but no mention where to submit the patch. 09:31:18 in general, once you have the account, you can post it to gerrit -- https://code.illumos.org (I hope the steps are documented). 09:31:46 Oh nice, thanks @tsoome! 09:32:15 of course, the problem with updates to manuals is pain with gerrit - it does not provide diffs for renrered text and such 09:32:20 rendered* 09:34:37 historically we have had webrev reviews as well (see /opt/onbld/bin/webrev), but that requires web server 09:35:45 and today we practically do not see webrev reviews even for manual page updates 09:37:08 interestingly, cr.illumos.org is still pinging:) 09:37:48 ah, and it is providing link to gerrit guide as well:) 09:46:20 the other steps for Gerrit reviews and RTI are described in the Code Review/Submitting A Patch sections of that docs page, though this is a good reminder to nudge folks about https://github.com/illumos/docs/pull/100 09:46:51 the docs changes aren't anything super fundamental but i think it helps some of the whys make a little more sense :) 09:47:31 IMO we should have something better for manuals, it is such an important part and is usually most annoying to review:D 09:47:46 well, unless its really small change ofc 09:48:46 yeah i basically assume right now you'd just want to pull the change and see how it looks locally to review and that's not the best... 09:51:08 whaaat, there is no zilstat. pity... 11:18:02 Hurray, the HCL is up again :). If anybody is interested, I asked whether Broadcom PEX 8747 is compatible with Illumos (specifically this card for NVMe SSDs: https://www.delock.com/produkt/90078/merkmale.html). I was able to test it today on the latest SmartOS release and format sees all four NVMes, so looks good! 11:18:31 Maybe somebody in charge of the HCL wants to add that? 11:24:13 .oO 5368709120 bytes (5 GiB) transferred in 7272,137029 secs (721 KiB/sec) 17:19:09 [illumos-gate] 16879 pkglint fails on openindiana with more unexpected /32 packages -- Bill Sommerfeld 20:23:01 [illumos-gate] 17202 unix needs memstr.c -- Toomas Soome 20:57:31 errm, is it just me or man -M switch is broken? 20:58:49 man appears to search system path and ignores path from -M (for me) 20:59:33 How are you using it? 21:00:14 I use it a bunch while developing manual pages in illumos and haven't had issues. 21:00:15 for example: man -M /code/illumos-gate/usr/src/man memory 21:00:55 there is small fix in memory.3c (we are missing const from memchr and memrchr) 21:01:31 That works for me on my system. 21:01:38 I modified a file in the clone. 21:01:53 And seems to be fine whether I use the absolute or relative path. 21:02:28 so it must be me 21:03:43 Just to confirm, it is /usr/bin/man? 21:06:06 yes, according to which... I'm double checking, it really does not seem to make sense... 21:06:58 are you sure you gave it the -M switch there, and didn't accidentally give it the manN directory? 21:08:58 sigh, got it. this vim in omnios is creating backup file with ~ at the end and man command is picking up 951: open64("/code/illumos-gate/usr/src/man/./man3c/memory.3c~", O_RDONLY) = 3 21:09:42 it treats memory.3c~ as memory(3C)? 21:09:47 not memory(3C~)? 21:09:56 eugh 21:09:59 yes, it seems so 21:10:07 it seems like another bug to me 21:10:11 but well... 21:11:09 this is the command and check: https://pastebin.com/FTAvnq7Z 21:14:30 and thanks! 21:15:35 So, here's what's going on. 21:15:40 reading the code in man.c's searchdir() I see why this is happening - when checking for a match, it's ignoring everything in the filename after the last '.', and returning the first match 21:15:48 The thing is we're not specifying a section. 21:15:55 Yeah, exactly. 21:16:11 This would be the same thing with same why you get section 1 before section 4/7 of the same thing. 21:16:19 If you did man -a you'd get all of them. 21:16:29 So in this case, man is doing what it kind of expects, but in a weird way. 21:16:40 If you said memory.3c then it wouldn't find that. 21:16:59 But the same would be true if you made man/man3c/memory.a man/man1/memory, etc. 21:18:08 ok, so the .sectionname suffix is just a decoration 21:18:44 Well... it's a bit of a hack. 21:19:09 If you don't specify -s to suggest a specific manual, man will always search all sections for something that matches. 21:19:26 And .3c~ matches ahead of .3c in this case. And without -a it stops after the first. 21:19:49 If you specify foo.3c then it does try to find a file named that in all sections, which it'll only find in 3c. 21:19:58 At least, IIRC. 21:21:11 I think the assumption toomas (and I, honestly) had was that the directory implied in the search and the extension had to match for man to care 21:21:14 at least its amusing way to shoot myself into the leg:D 21:21:25 that is, that manfoo/page.bar would never hit 21:21:46 more generally man(.*)/page.\1 21:21:54 Well, I think that would be an optimization that man could imply, but you are saying logically search for every file named foo in the path. 21:22:38 So it's just a simple for each path entry, for each section, is page present. But it would be reasonable for it to append something in that search. 21:22:57 so if I do `man -s 3c foo`, does man search for 'foo.3c' in the entire path, or man3c/foo.*? 21:23:20 or man3c/foo.3c 21:24:08 It just appears to search for foo.3c with upper/lower case logic. 21:24:56 I know it finds the right thing, but I haven't looked at how it does. 21:25:50 yeah, I'm just wondering how wrong my assumptions have been 21:26:19 it's not like I ever drop random files into my man path, and I have long configured editor files to go somewhere else because of similar disasters to this (though not this one) 21:26:37 I dunno. I mean, it'd be reasonable to me to have man only look for foo.X in it's looking in manX.