02:04:44 richlowe: it's a bit (ok, more than a bit) hacky, but what might work is you could make a copy of interface_check and remove this line: https://github.com/illumos/illumos-gate/blob/master/usr/src/tools/scripts/interface_check.pl#L292 02:05:09 that would produce the interface output that includes the SUNWprivate and ILLUMOSprivate symbols 02:05:16 (or should at least) 02:05:33 which might then work with interface_cmp 02:05:50 or something like that 02:06:29 (I think interface_cmp will complain if a symbol disappears in the 'new' workspace) 02:07:28 at least for libraries 09:57:39 I have an assortment of scripts from last time where I was comparing gcc7 and 10 for things like size and content of CTF sections, function sizes and symbol changes. Nothing exciting but I can help with comparisons too. 09:57:57 I am hopeful that the delta from 10 to 14 will be a bit easier than 7 to 10 was. 14:19:35 andyf: Be on the lookout for things in 3rd-party software whose `configure` -generated C programs stop compiling in gcc14. 14:20:06 We've been building most things with gcc14 for a while and been through that pain. We have checks in the build system now that catch most of it 14:20:12 We have caught some of this, and output-diff-inspection of illumos-extra builds has shown even more that plow-on-with-bad-results. (Most egregious, endian-checks that say "We're big endian!") 14:20:45 Got hit in SCCS last week where it decided that all of our types were size 0, and by extension that must mean we have a 64-bit time_t. 14:20:54 Some of it may be due to older versions of things we have in -extra for reasons of sweater-unrevelling-avoidance. 14:21:03 SCCS... yeah I saw that on the mailing list. 14:21:46 It's useful to compare config.log between gcc13 and 14 to spot the most obvious things. I'm sure there are still lurking issues but we switched over to 14 a few months back. 14:22:13 One of the benefits of having stable releases, anything under r52 was built with <14 14:24:06 This isn't robust, but it's helped us a lot - https://github.com/omniosorg/omnios-extra/commit/09302773aaebaf4d791581a77aed32cea2409784 18:19:55 hi! i'm wondering if folks might have some quick thoughts on docs - https://github.com/illumos/dev-guide/blob/master/integrating and https://github.com/illumos/docs/blob/master/docs/contributing/index.md both talk about contributing and mostly overlap but not quite entirely. my read is that "illumos Developer's Guide" is a little more "here's the facts" and illumos.org/docs is more like "here's how we 18:20:01 suggest you read things and useful advice and conventions". does that sound like i'm reading it right? or is it just "they're updated when people get to it and so they've just drifted a bit"? 18:20:05 whoops long message :) 18:23:26 (in particular both documents talk about RTI but i had a hard time figuring out exactly what is wanted in practice and how to arrive at it. "yes, you should actually amend the commit. no, there is no tool for formatting it. yes, the formatting is not how git typically wants it. yes, push that commit to gerrit." etc) 18:25:35 for the commit message, it should be lines of ' ' (if there's multiple related changes being integrated in one commit, there may be multiple lines -- one for each issue), followed by one or more 'Reviewed by: User ' 18:26:03 the big difference is IIRC, a lot of places use 'Reviewed-by:' instead of "Reviewed by" 18:26:17 so you'll want to amend your commit after you have your reviewers 18:26:25 to reflect that 18:26:49 running 'git pbchk' should tell you if anything's wrong 18:27:28 the only other potential thing is the gerrit id 18:27:37 [illumos-gate] 16922 i86pc: support AMD C-states -- iximeow 18:28:09 yeah, also we expect no blank line between the first line in a commit and subsequent description (e.g. it's not "summary + descriptions", the commit message is a free text field we're using differently) 18:28:38 i mostly want to know which place would be a better one to add this stuff, 'cause i found both along the way 18:28:46 yeah, no commentary in the commit -- i believe the reasoning is that it should be in redmine (issue tracker) 18:28:54 so just the summary 18:29:55 whoever approves your commit should take care of adding their 'Approved by:' line (since they'll be merging it for you) 18:30:34 I can't remember now (since I do it without thinking much about it)-- I git pbchk might complain about the gerrit id in the commit 18:30:41 it does yeah 18:30:52 just remove that line before submitting 18:32:14 I don't know for sure (so don't quote me on it :P), but I suspect there is an desire (but not the time to date) to eventually be able to do it all from gerrit -- i.e. advocates could give +1 which would allow it to merge w/ all the necessary tweaks to the commit message 18:32:37 (as it'd require some custom plugins to do all of that which means someone has to have the time to write them) 18:32:44 that's the sense i've gotten from talking with Andy and Patrick, but that there's work to do that 18:32:47 yeah 18:33:50 well. i'll do a PR to add some more explicit words against illumos.org/docs and figure out the book next 18:34:34 It'll definitely be good to get some updates there from your fresh perspective. Some of the things I suspect we don't have agreement on anyway, but this might shake some of those out. 18:35:08 I think jclulow will be able to give some direction on whether one of those guides is more current / intended to eventually replace the other. 18:36:06 The front page of https://illumos.org/ links to https://illumos.org/docs/contributing/ and I don't see the developers' guide mentioned any more. 18:36:32 Heh. except on the first part of that contributing guide. 18:36:36 :) 18:37:15 i believe rm has linked me to the developers' guide as well, but in the context of finding my way around the source tree 18:37:29 there's a lot of useful stuff there still for sure 19:42:11 andyf: I put a gcc-14 + arm64 together last night for testing, and the most surprising thing was autoconf checking things twice (at different levels, but together because parallel?) and getting _different answners_ 19:42:43 I think that might even be prior to using the gcc 14, just building it 19:43:38 checking for sysctl... yes 19:43:38 checking for sysctl... no 19:43:42 on literally adjacent lines 19:44:58 heisenberg's sysctl 19:47:11 if I remember the excerpt I showed someone yesterday, I have all combinations of yes/yes, no/no, yes/no, no/yes 19:47:16 quantum computing is there, now:) 19:49:54 it would be interesting to see sample of its test program:) 20:01:53 are the two "checking for sysctl" tests trying the same code? the relevant bit of config.log might be enlightening. 20:03:55 I would bet they are different :) 20:04:31 and due to parallel run, the order of output is different. 20:46:04 iximeow: The developer's guide is meant to be like a book you can read, and I would consider illumos.org/docs to be where we communicate policy 20:46:31 I have had Big Thoughts about that recently 20:46:40 I think it's 'cos of he lack of daylight 20:46:41 I agree it's a bit unfortunate that there's overlap, and we should definitely make sure they line up 20:47:59 I think there's extent to which we would like to be more concise on the docs site sometimes? 20:48:46 jclulow: my Big Thoughts were: I've been documenting something lately, and I dropped it into the illumos source tree for now, so that it's totally clear whether it's getting updated as it should. That seems like it might just be a pretty good thing? 20:49:06 we build /man/ out of src/man/, there's no reason we couldn't build books out of /books/ 20:49:13 ehhhhhh 20:49:17 Yes and? 20:49:40 and core know they're not drifting out of date if it has to get done in the same commit 20:49:53 one goes, "Where's the update to the documentation?" and not "Shit, I forgot about that" 6 months later 20:50:08 I feel like there's a lot of scope for docs work that doesn't need or require an RTI 20:50:31 I admit, I put a lot of faith in illumos' processes _actually_ shrinking to fit 20:51:05 I think part of having a different style of scrutiny over the docs stuff _is_ us shrinking to fit tbh 20:51:17 (by putting them elsewhere) 20:51:27 sure, I don't see why those too things are mutually dependent. 20:51:31 two, too 20:51:48 Mostly just squishy human social and psychological things probably 20:51:54 it also has the nominal advantage that you always have a copy of the docs that match your source tree 20:52:11 anyway, just a thing I got to thinking about because it goes dark too fucking early. 20:52:22 I think it's a good thing to think about for sure 20:52:32 I would also actually like us to _put more in the manual_ 20:52:42 yeah, that would be amazing. 20:52:44 The manual isn't just a reference of command line flags 20:52:52 section 7 could always use more prose 20:52:54 and to be honest, mandoc is not painful. 20:53:07 Right, it's actually pretty alright. 20:53:34 I remain envious of, e.g., https://man.openbsd.org/afterboot 20:54:53 that page is actually one of the ones that really showed me that the man pages can be useful to read rather than flags reference 20:56:22 We have some good stuff in https://illumos.org/man/7 20:57:03 e.g., https://illumos.org/man/7/byteorder 20:57:07 now I'm going to have to learn whether pandoc can convert this thing I'm doing into mandoc 20:57:25 TIL PDP-endian 20:57:36 Yeah, DEC have a lot to answer for 20:59:32 There are also a handful of good kernel ones in https://illumos.org/man/9 23:13:29 richlowe: i've actually wondered about some sort of alternate format that could be converted to mandoc w/ good fidelity since regardless of the truth, it's common enough people see mandoc and be like 'that's too confusing/complicated/etc' 23:13:55 like mandoc could still live in the tree, but if someone wanted to write then convert 23:14:29 and a lot (all I've seen so far) of the markdown->mandoc/roff converters don't do a good job tbh 23:14:36 since the semantics are different 23:15:00 e.g. how do you annotate 'foo' is a function argument in markdown in a way that'll get translated to 'Fa' 23:15:03 ? 23:15:17 (so is there something that could do that?) 23:15:30 like I cry a little everytime i have to read the smartos vmadm man page 23:15:54 (because the conversion from markdown is poor) 23:16:21 (at minimum it should be readable in an 80 column terminal without horizontal scrolling) 23:17:34 the problem is the only extant thing I can think of that'd work would be xml, which i'm not sure if it'd be any better/more attractive for people wanting to write man pages 23:42:12 jbk: I feel like mdoc is just not that complicated, and a good fit for documents in the UNIX ballpark, and if anything we should just write better documentation about how to get started with it etc 23:42:35 mdoc(7) is a great reference, but could probably use more introductory prose and guidance