00:10:57 ping? 00:11:11 pong? 00:11:52 Thanks. Greetings from MacOS 14 (Sonoma). libera.chat didn't like my inbound connections for a small period of time. 00:12:13 it was the same for everyone, i guess 00:13:45 That makes me feel a bit better. 00:13:58 My bouncer crapped out on me for 7m, I couldn't figure out what was going on. 00:14:15 my connection stayed up but I saw a couple bursts of "... has quit (*.net *.split)" departures. 00:15:19 ^^^ I was probably a victim. 00:15:27 While trying to figure out why I couldn't connect I saw the DNS response change. 00:15:44 I don't know if that's part of their load balancing or someone did that to fix it. 00:15:56 (or fucked it up by changing it, then unfucked it by changing it back) 00:31:23 danmcd: I saw you leave at 20:00:29 your time in the second batch of departures (previous was 20:00:03 to 20:00:09 your time) 04:46:14 alanc ouch:) 04:52:18 alanc fortunately we do not have those variants other than in comments 05:11:00 oh good, seems I am not the only one prone to miss spelling variables from times to time 😅 09:09:25 I'm setting up for gerrit following the guide here: https://illumos.org/docs/contributing/gerrit/ 09:09:50 But when I try to get the Change-Id hooks with: 09:10:01 scp pilonsi⊙cio:hooks/commit-msg .git/hooks/ 09:10:21 It fails with subsystem request failed on channel 0 09:11:02 I can successfully connect through ssh otherwise 09:29:10 Try 'scp -O ...'? (I suspect the old vs new scp protocol mismatch.) 09:30:31 Yes that was it, thank you! 14:31:47 I have pushed my changes for 15839 to gerrit: https://code.illumos.org/c/illumos-gate/+/3052 14:31:48 → CODE REVIEW 3052: 15839 Erroneous newline in error message (NEW) | https://www.illumos.org/issues/15839 14:32:17 Though now I see I'm going over the max line width, and also it mentions that there is a merge conflict so I'll get to those 14:58:38 you can do something like x = "foo bar" " baz"; in C and the compiler will combine those segments for you 14:58:59 (the segments can even be on separate lines) 14:59:50 pilonsi - nice, that's good progress :) 15:00:08 In that case I'd probably put the entire string on the next line. I think it's useful to keep strings together to aid grep and so on. 15:00:23 (I know not everyone who contributes takes that approach) 15:06:08 Thanks! :) 15:06:30 I've noticed though that the same thing appears in several other prints in that file 15:06:42 Should we fix those too for consistency? 15:07:23 Like likes 1556 1557 15:07:51 There are other lines that do use the "foo"\n "bar" solution 15:08:12 Oh yes, I'd fix any others that try and use \ continuation. 15:08:14 * likes --> lines 15:08:54 I'd also look at what `git pbchk` reports as there might be some other things in that file worth fixing up. Some of the older code doesn't quite use the right style and so on, and we try and fix it up as we pass. 15:09:07 Nice, I'll get to it 15:09:29 It isn't mandatory to fix up code you aren't touching, but definitely worth doing if you can. 15:09:34 Should I add a comment to that issue and keep all changes to that, or add a new one and fix both in the same commit? 15:10:28 Same issue is fine. 15:58:19 When I run git pbchk 15:58:23 I get this: 15:58:25 usr/src/uts/common/io/kbtrans/kbtrans_streams.c: 1474: continuation should be indented 4 spaces 15:58:47 If I indeed indent the continuation by 4 spaces they go away 15:59:13 But in the other statements in the code, the continuation is indented 4 spaces starting from the indentation the 1st half already had 15:59:23 (Which I also think looks nicer) 15:59:31 an additional 4 spaces for a continuation line is what's required by the style checker. 15:59:54 additional to the indentation level of the line that is being continued, that is 16:00:11 It's tabs up to the level of the previous line, then four spaces. 16:00:48 Aah.. I see, I was doing all tabs, since i have them set to 2 spaces it matched nice 16:00:51 Thanks 16:01:36 But its worth mentioning that doing 2 tabs (4 spaces) from zero made the error go away 16:01:53 When the second line was indented less that the parent one 16:07:34 I've pushed the new fixes, it's no longer complaining 16:07:55 Should I ask in the mailing list for a review? 16:08:25 (btw, what's the difference between illumos-devel and illumos-advocates?) 16:08:38 Yes, that's the best way - illumos-dev 16:08:56 the advocates list is where you would send the patch for integration once you have enough reviewers and have tested etc. 16:09:12 "advocates" is the old name for what is now the "illumos core team" 16:10:31 https://illumos.org/docs/about/leadership/#core-team 16:43:18 andyf: thanks for the review! Now it's just doing the full nightly build, and asking in the advocates list right? (Do i have to be in the list, or can I just send an email directly?) 16:43:53 That's right, you can just send. 16:44:24 There are a few things to include in the email - the contribution guide should cover it - and you need to put testing notes in the issue. 16:44:53 Testing is shrink-to-fit though, so for something like this I would expect that a full nightly build and maybe running strings on the binary to check they look ok there would be enough. 16:45:05 (the advocates have the last word, but they're a friendly bunch) 16:47:24 It's usually good idea to let changes sit in review there for a while to give anyone who wants to look at it a chance, across time zones etc. 16:47:42 But that also depends on the size/complexity of the change. 16:52:21 That's ok for me! I'll leave it overnight 16:53:17 About the testing notes... With the issue you mean as a comment on the bugtracker? Or in the email I send to the advocates list? 16:53:56 And what do you mean by running strings? Inspecting the data section of the binary to get the strings? 16:54:11 A comment in the bug is best. 16:54:24 Yeah, we want the notes preserved there 16:54:40 Got it 16:55:42 Some folks also choose to transcribe the testing notes into the RTI email, but that's purely a preference thing vs "Testing notes are in the ticket(s)" 17:51:07 pilonsi - I meant inspect the strings in the final build via one means or another. For this change literally running the `strings` command against the old and new `/kernel/misc/amd64/kbtrans` is probably enough - it's just a smoke test. 19:55:23 defaulit 20:00:16 delaut was the better one 20:15:54 defalt 20:16:00 delfut 20:16:37 none of either of those in my tree;) 20:18:00 now, it is time to hunt for forgotten RTI's... 21:17:01 if I were hunting bugs, implicit-function-declaration still holds the most horrors 21:17:18 types? who needs them. 21:19:22 defalt as a function argument was presumably an attempt to avoid a keyword.. I definitely prefer the change to def_val tsoome 21:19:22 ou yes:) 21:19:52 yea, I figured that too 21:21:09 like C++ being klassy with a k 22:07:38 * nomad wonders exactly what 'def_val tsoome' would fall into.