12:01:01 #startmeeting CIP IRC weekly meeting 12:01:01 Meeting started Thu Sep 3 12:01:01 2026 UTC and is due to finish in 60 minutes. The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:01:01 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 12:01:01 The meeting name has been set to 'cip_irc_weekly_meeting' 12:01:01 hi 12:01:06 #topic AI review 12:01:12 12:01:21 5 12:01:23 4 12:01:24 3 12:01:26 2 12:01:27 1 12:01:30 #topic Kernel maintenance updates 12:01:35 i've been working on 4.19 12:01:39 This week reported 136 new CVEs and 69 updated CVEs. 12:01:57 I was reviewing 6.12.106 and .108. 12:01:59 "I reviewed v6.12.97." (iwamatsu-san) 12:02:52 there were some single-fix stable release(s?) again - anything we need to worry about? 12:03:05 .107. I took a look, nothing for us. 12:03:12 in 5.10 one, then one that reverts the one, and then another one :) 12:03:50 release oscillations 12:04:07 so, no special actions needed, I hear 12:04:55 virtio_net_hdr. I actually may take another look, as I initially parsed as virtualization 12:05:02 only, and it may be broader. 12:05:24 remote? 12:05:38 But we probably do not use related functionality... so should be ok. 12:05:41 and virt is in scope for us 12:05:55 we surely use virtio-net e.g. 12:05:55 Not remote, afaict. Someone having access to tun/tap. 12:06:02 ok 12:06:19 Yeah, you probably should not allow KGB agents to use virtio-net :-). 12:06:31 So in scope, but I would not panic for this one. 12:07:17 anything else? 12:07:42 5 12:07:44 4 12:07:45 3 12:07:47 2 12:07:49 1 12:07:52 #topic Kernel release status 12:08:00 all on track 12:08:07 My notes say do 4.19-rt as soon as 4.19 is released. 12:08:12 but a few are upcoming 12:08:38 yeah, maybe you noticed that I added the version tag to the status report 12:09:12 can help identifying when rt and vanilla got out of sync due to delayed rt release 12:09:28 and that is I think what happened with last 4.19-rt 12:10:37 Basically we'll want to change 4.4 and 4.19 from "every two months" to "every other -cip release". 12:10:48 ...which should be same in ideal world, but... 12:11:17 there can always be special situation, we should just make sure to realign then 12:11:38 (y) 12:12:42 anything to add? 12:12:55 5 12:12:57 4 12:12:59 3 12:13:01 2 12:13:02 1 12:13:05 #topic Kernel testing 12:13:29 Thanks for the QEMU lava-docker MR jki 12:13:40 I assume this installs the version you need now? 12:14:02 kci-dev is improving the mcp extension and we are currently writing a document about this 12:14:03 it installs it, yes - but that is still as much as I checked 12:14:11 Okay 12:14:12 we are improving reports 12:14:20 Thanks arisut 12:14:41 We should probably start testing 7.2-stable 12:14:42 I also just got aware of patersonc PR on pipeline, will review it 12:14:51 In the LAVA world - the TI lab is still offline, sorry. Affected by holidays I believe 12:15:26 arisut: are there pipelines / workflows for the MCP already? 12:15:56 yes, but we have an unofficial mcp server that will be make public next week 12:16:16 ok. 12:16:17 also the documentation on pipelines/workflows 12:16:28 will be released next week 12:17:25 will be interesting to watch in use (or try out ourselves...?) 12:18:05 yes, would be interesting to have cip using it 12:18:23 I guess there is quite some potential for LLM-based triaging of LAVA results 12:18:45 yes 12:18:53 filtering out patterns, generating context-specific statistic etc 12:19:06 cool! 12:19:22 yes, that would be cool 12:20:19 more on testing? 12:20:25 I will ping you when is ready 12:20:31 TIA! 12:20:46 I think LAVA is also working on an MCP as well 12:22:21 5 12:22:23 3 12:22:25 4 12:22:27 2 12:22:29 1 12:22:31 #topic AOB 12:23:03 iwamatsu not here, he wanted to have a look at the review tooling 12:23:03 I got question about next -cip kernel. 12:23:16 yes... 12:23:22 Slowly we should put 7.4-cip on our radar. 12:24:04 And we should probably talk about -rc branches. 12:24:04 what would be concrete steps? 12:24:50 jki: Dunno. I guess "we are selecting next -cip" on TSC meeting. 12:25:11 And really start looking for what would be suitable longterm stable in a month or so? 12:25:30 that discussion will surely start, but we do not know the next version yet, formally 12:26:00 No, we don't. It is time for discussion, not for the results :-) 12:26:15 7.4 is not unlikely, but there is only a 7.3-rc1 now 12:26:39 Yep, simple maths also points to 7.4. 12:26:50 I believe we are sure we will not do 6.18-cip at this moment? 12:26:58 that is clear 12:27:03 Ok. 12:27:19 So likely "whatever next kernel is marked as longterm stable by Greg". 12:27:36 same procedure as every two years, yes 12:27:43 (y) 12:27:53 TSC will ask us what it will mean effort-wise 12:28:19 are we expecting changes, because of the new kernel or anything else? 12:28:27 that will likely be a topic in Prague 12:28:59 LLMs are causing problems. Flood of patches from unusual contributors. 12:29:13 the CIP project may grow next year, and that can be a chance to address topics that need more attention 12:29:21 Of course, it is not LLMs mistake, but.. 12:29:21 or scale up existing work 12:29:27 pave1: Upstream? Or on cip-dev? 12:29:39 upstream 12:29:49 Upstream. Likely uli has better numbers than me. 12:30:00 1300+ in the last month in 5.10, i didn't check how many are ai 12:30:30 that's 5x or so compared to last month 12:30:36 *previous month 12:30:38 Sure - mainline/stable is a bit nuts with LLM atm. I was just wondering if CIP had seen any direct patches 12:30:39 the risk of fragile "fixes" hitting stable is surely rising 12:31:08 ...so -- that. I see it in 6.12/6.1 reviews, too. 12:31:28 that's why we need to think about measures that may help CIP to stand this 12:31:56 "though AI at it" is not the only answer, but we will likely not be able to ignore that as well 12:32:15 that's why we are looking into this already 12:32:42 So stable maintainers are misusing LLms already, not sure "more LLMs" is the answer. 12:33:05 Other side effect is that fixes now hit 6.12 first, and 6.1/5.10 with some delay, causing duplicate reviews. 12:33:06 did anyone study already what RH is doing in https://hummingbird-project.io/? not kernel, but... 12:34:02 as I wrote, LLM will not be the only answer 12:34:18 I do expect more effort on the reviewing side, even with LLM support 12:34:41 so, if we think we need more hands on deck for that, I would request support 12:34:47 people or budget 12:35:19 I guess question is "is this new normal" or "is this temporary spike"? 12:35:52 my observation is that the number of patches has been rising the whole year. the current number is an extreme, but no idea how it will continue... 12:36:10 But I'd say more support may well be needed. 12:36:19 +1 12:36:26 given that there are more new - apparently AI-backed - first-time contributors, I expect not only a spike 12:36:54 than this is already a topic of us for the ETSC in Prague 12:37:17 it's likely resonating because there is such a strong interest in CIP because of the kernel 12:37:25 jki: one could hope that they run out of simple things to fix eventually, but it is hard to predict when that happens. 12:37:54 I don't think (or read?) that we are only talking about first-time fix contributors 12:38:48 jki: no, problem is total ammount of patches going in 12:39:01 besides more hands on the review and potentially backporting front, I would also stress again that we need eyes and hands on testing 12:39:40 yes. And I'd like to see work on reducing configurations, so we concentrate effort on stuff people actually use. 12:40:17 pavel: that will be tough, but please propose concrete areas 12:40:29 I rather expect the configs to grow further 12:40:57 with every new cip kernel and more advanced use cases on top 12:41:16 that said, there are surely still unneeded switches in our configs 12:41:25 but how to identify them? 12:42:27 jki: we could require each company to write explanation for each switch. 12:42:44 jki: they would likely make them realize they don't need the switch after all :-) 12:43:28 pavel: key problem is that each company is already complex in the chain where the configs come from 12:43:36 jki: we could start with switches that look suspicious. 12:43:43 and then there end-customer scenarios as well 12:44:21 yes, if someone like you could question concrete switches with significant impact, that is a starting point 12:44:24 jki: yeah, eventually it will lead to efforts on companies as well (and maybe even end users). 12:45:12 jki: I can try starting with something (when things got a bit quieter). 12:45:30 jki: Eventually someone "owning" the configs and having power to ask questions etc could be good. 12:46:11 we can try, but the easiest way of getting rid of things is when no one forward-ports a config to a newer kernel 12:47:01 while, at the same time, we also lose bits that are valid because users believe this forward porting is automatic... 12:47:13 jki: we may consider starting with minimal kernel for 7.4-cip, so people will need to explicitely ask for config additions. 12:47:31 that is too late 12:47:52 we then already started to ignore bits that are actually relevant 12:48:48 well, too late is relative, but we can't wait for a year or so, like it happened with some 6.12 bits 12:49:26 key is to get users more actively involve on configs, just not yet clear how to achieve that better 12:50:47 okay... more topics? 12:50:52 jki: Question is how to achieve that without major disruption. 12:51:44 pavel: continuously talking about it in public :) 12:52:01 no better idea right now... 12:52:30 maybe we could live-visualize the subsystems in scope? 12:53:01 better than only waiting for users to come back with "why did you ignore this CVE?" 12:53:59 Publicity is good. 12:55:17 We could do some kind of stunt like "one CONFIG option a week", speak up if you need that option. 12:55:35 no one is folling CIP at such a pace 12:55:51 they are all busy updating their products :D 12:56:53 so, any other topcis for today? 12:57:28 5 12:57:31 4 12:57:32 3 12:57:34 2 12:57:36 1 12:57:37 #endmeeting