12:00:42 <jki> #startmeeting CIP IRC weekly meeting
12:00:42 <collab-meetbot`> Meeting started Thu Sep 17 12:00:42 2026 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:42 <collab-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:42 <collab-meetbot`> The meeting name has been set to 'cip_irc_weekly_meeting'
12:00:49 <jki> #topic AI review
12:01:09 <jki> none (I had an AI, but it's already done)
12:01:18 <jki> 5
12:01:20 <jki> 4
12:01:22 <jki> 3
12:01:23 <jki> 2
12:01:25 <jki> 1
12:01:27 <jki> #topic Kernel maintenance updates
12:01:45 <masami> This week reported 706 new CVEs and 71 updated CVEs.
12:01:47 <pave1> I was doing reviews. 6.12.109, 110. .110 is huge.
12:02:20 <iwamatsu> I reviewed 6.12.102 and 103
12:03:54 <jki> sounds like it es getting harder and harder to keep up with that pace
12:04:03 <pave1> Yep :-(.
12:04:04 <jki> do we need more reviewers earlier?
12:04:20 <jki> topic for the CIP MiniSummit?
12:04:46 <jki> are there stats if our reviews also find more?
12:04:57 <jki> relatively or absolutely?
12:05:19 <pave1> I'd say so. And we need infrastructure to coordinate reviews better, as patches arrive for different versions at different times.
12:05:58 <jki> did you do any upfront coordination so far, or was that basically this slot here?
12:06:08 <pave1> No such stats :-(.
12:06:35 <pave1> We had git to coordinate with uli, but it did not work too well.
12:06:52 <patersonc> I saw that 7.2.6 had over 1800 patches, on an rc release on Sat morning. Not sure how that was ever expected to have a manual review before the release on Monday...
12:07:33 <jki> hmm...
12:07:53 <pave1> Ideally, we would track changes by their upstream id, with some support to flag how it was reviewed for different versions.
12:08:09 <jki> in git?
12:08:13 <jki> or where?
12:08:22 <pave1> ...and warnings if patch is actually different from what is in the upstream.
12:08:32 <pave1> ...and notes about LLM reviews and such.
12:08:51 <pave1> Dunno. Git is good for offline work, web interface would also make a sense.
12:09:43 <pave1> I guess we have CIP minisummit topic.
12:09:45 <jki> you need to operate it, so you should tell
12:10:02 <jki> but I will record that for discussions in Prague
12:10:16 <pave1> Someone needs to design and implement that, too :-).
12:10:32 <pave1> It might make sense to allow outside contributions, too.
12:10:43 <jki> also AI? :)
12:11:01 <iwamatsu> It is true that there are no good tools available right now.
12:11:45 <pave1> I guess this is a place where LLM would fit, yes.
12:12:24 <jki> would indeed be a nice chance for more contributors to the CIP kernel
12:12:40 <jki> but we need to be able to express requirements on it
12:12:45 <jki> good...
12:12:59 <pave1> And outside human contributors. (Or perhaps contributions from CIP members.)
12:12:59 <jki> more on maintenance?
12:13:10 <jki> sure
12:13:44 <jki> let's move on
12:13:46 <jki> 5
12:13:48 <jki> 4
12:13:50 <jki> 3
12:13:52 <jki> 2
12:13:53 <jki> 1
12:13:55 <jki> #topic Kernel release status
12:14:04 <jki> all green now - thanks pavel
12:14:30 <jki> upcoming releases: 4.4 and 6.12
12:14:40 <jki> (based on due dates)
12:14:46 <pave1> :-). 5.10-rt has very regular releases, which helps.
12:15:21 <jki> 5
12:15:23 <jki> 4
12:15:25 <jki> 3
12:15:27 <jki> 2
12:15:29 <jki> 1
12:15:31 <jki> #topic Kernel testing
12:15:59 <patersonc> Hi
12:16:14 <patersonc> Still seeing some issues with some qemu jobs in the stable-rc testing
12:16:50 <patersonc> Not got to the bottom of it yet
12:17:20 <pave1> Yep. I retried old -rt kernel, and it still failed, so I decided failures on new -rt kernels are spurious and released anyway.
12:19:29 <jki> qemu issues due to long delays caused by an overloaded host?
12:19:43 <jki> or functional, deterministic problems?
12:20:28 <patersonc> I doubt it's due to an overloaded host tbh
12:20:51 <patersonc> Seems to be a lava issue more than anything, but no idea why
12:20:53 <patersonc> e.g. https://lava.ciplatform.org/scheduler/job/1509187
12:21:30 <jki> "/lava-1509187/environment: No such file or directory" - infrastructure, no?
12:21:55 <jki> always on the same qemu device, or in the same lab?
12:23:04 <patersonc> I don't think it's a specific lab - but need to run more tests to work it out for sure
12:23:18 <iwamatsu> same issue has on siemens-muc https://lava.ciplatform.org/scheduler/job/1509925
12:23:25 <jki> mount: /lava-1509187: special device /dev/disk/by-uuid/b6a7ee8d-e0f5-46ba-9e18-286229ea2076 does not exist.
12:24:05 <jki> missing /dev/disk/...? missing kernel features? missing disk?
12:24:13 <jki> someone needs to try that out manually, I guess
12:25:04 <jki> but if older kernels failed the same way, config can likely be excluded
12:25:33 <patersonc> yea
12:25:44 <patersonc> Could be related to the qemu version upgrade we did recently
12:28:20 <jki> if it only popped up recently - could be
12:28:35 <jki> but the muc lab was not updated yet IIRC
12:29:29 <iwamatsu> It looks like a file system issue. ext2 might be the problem.
12:29:47 <iwamatsu> https://lava.ciplatform.org/scheduler/job/1509925#L1010
12:30:01 <jki> but it says it does not find the block device
12:30:34 <jki> not "unknown / unsupported fs"
12:31:08 <jki> the muc lab is definitely still old QEMU, just confirmed
12:31:43 <jki> but we might be missing that extra disk in the qemu command line - for whatever reason
12:31:50 <jki> that would also explain the missing blockdev
12:32:32 <jki> welllll - debug volunteers?
12:32:53 <iwamatsu> I see.
12:34:02 <jki> otherwise, ask the AI ;)
12:34:19 <jki> more on testing?
12:34:21 <arisut> About AI and testing this is the guide for using kci-dev with KernelCI mcp server https://kernelci.org/blog/2026/09/12/talk-to-kernelci-kci-dev-now-speaks-mcp/
12:35:46 <patersonc> Should git in nicely with some LLM driven regression testing :)
12:35:56 <jki> indeed
12:36:06 <jki> nice article, just distributed
12:37:04 <jki> we need someone with time to see if we can safe time this way, I guess ;)
12:38:28 <jki> more testing topics?
12:38:46 <jki> 5
12:38:48 <jki> 4
12:38:49 <jki> 3
12:38:51 <jki> 2
12:38:53 <jki> 1
12:38:55 <jki> #topic AOB
12:39:11 <jki> SECURITY.md - did you see my patch?
12:39:45 <jki> https://lore.kernel.org/cip-dev/a1cfc8d4-5fb7-4f75-9600-92ebd7dbbeda@siemens.com/
12:40:15 <jki> unless someone has a better idea, we likely need to place that into every active CIP kernel
12:40:41 <pave1> There already is Documentation/admin-guide/security-bugs.rst .
12:40:44 <jki> LF asked us
12:40:51 <jki> that is not CIP related
12:41:09 <jki> this is not the upstream kernel, it is the CIP kernel, and it is differently managed
12:41:14 <pave1> Yep, well, but we don't want to give our users two conflicting documents.
12:41:49 <jki> we could, of course, also augment that file, likely in addition
12:42:12 <jki> the kernel's file is very hard to find, at least for humans
12:42:30 <pave1> I'd say that for 6.12-cip, most security bugs will be in -stable, not in -cip code.
12:42:40 <iwamatsu> How about using a clear file name for the CIP document?
12:42:51 <jki> pavel: please read my text
12:43:03 <pave1> You can do ln -s Documentation/admin-guide/security-bugs.rst SECURITY.md
12:44:06 <jki> actually, I'm currently pointing to that security.rst already, but via kernel.org
12:44:34 <jki> so, we could replace it, and that link would still work
12:45:24 <jki> or we augment it with a sentence that repeats bits of what I wrote in "Security Context"
12:45:42 <jki> does that section make sense to you, BTW?
12:45:53 <jki> anything missing or unclear?
12:46:27 <jki> also the rest of that file - please re-read and comment on the patch
12:46:39 <pave1> Ok, lets do that over email?
12:48:01 <jki> fine for me
12:48:37 <jki> should just not take forever, reporting obligations are in place now
12:48:59 <jki> (for CIP with LF as steward)
12:49:08 <jki> good
12:49:09 <pave1> well... my first impression is not good.
12:49:29 <pave1> LF is not willing to list name or gpg key for the steward.
12:49:42 <pave1> That seems to be doing ... bare minimum, not a real security.
12:49:52 <jki> kernel list does not either
12:50:16 <jki> we don't have a shared GPG key for our list as well
12:50:36 <jki> and on gitlab (or github), the platform is always a reader
12:50:47 <pave1> I was under impression that security@kernel.org had key published, but I could be wrong.
12:51:04 <jki> I didn't find anything in their docs, but please check again
12:51:16 <jki> keys are tricky when you have multiple readers
12:51:45 <pave1> security is tricky.
12:52:00 <jki> of course
12:52:41 <jki> so - as uli is not here, no support on llm review topics possible
12:52:50 <jki> but anything new to share about that?
12:54:01 <jki> if not, any other topcis for today?
12:54:35 <jki> 5
12:54:36 <jki> 4
12:54:38 <jki> 3
12:54:40 <jki> 2
12:54:41 <jki> 1
12:54:42 <jki> #endmeeting