12:01:42 <jki> #startmeeting CIP IRC weekly meeting
12:01:42 <collab-meetbot`> Meeting started Thu Sep 24 12:01: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:01:42 <collab-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:01:42 <collab-meetbot`> The meeting name has been set to 'cip_irc_weekly_meeting'
12:01:46 <jki> #topic AI review
12:01:52 <jki> -none-
12:01:59 <jki> 5
12:02:01 <jki> 4
12:02:02 <jki> 3
12:02:04 <jki> 2
12:02:06 <jki> 1
12:02:09 <jki> #topic Kernel maintenance updates
12:02:27 <uli> i worked on 4.4
12:02:33 <pave1> I'm reviewing 6.12.111 and 4.4-st
12:02:35 <jki> "This week reported 603 new CVEs and 80 updated CVEs."
12:03:00 <iwamatsu> I reivewed 6.12.104, and I am reviewing 6.12.105.
12:03:32 <jki> patch number remains high, as it seems
12:04:17 <pave1> Yep. We are not at the beggining of cycle, so that was to be expected.
12:05:14 <jki> anything to add?
12:05:34 <jki> 5
12:05:36 <jki> 4
12:05:37 <jki> 3
12:05:38 <jki> 2
12:05:40 <jki> 1
12:05:42 <jki> #topic Kernel release status
12:05:53 <jki> 6.12 is late
12:06:02 <iwamatsu> For 6.12.y, sorry for the delay. I am currently working on it.
12:06:11 <jki> good
12:06:29 <iwamatsu> I am debugging test issues for qemu-arm.
12:06:43 <jki> 4.4 the same, I guess
12:06:56 <uli> yes
12:07:13 <jki> test issues: infrastructure or kernel?
12:07:38 <iwamatsu> infrastructure.
12:08:06 <iwamatsu> Virt machine does not support virtio based disk.
12:08:25 <jki> all runners, or only some?
12:09:08 <jki> ah, that's the same issue we discussed last week?
12:09:14 <iwamatsu> It reproduces in all environments.
12:09:18 <iwamatsu> yes.
12:10:03 <jki> locally working when invoking the images manually?
12:10:34 <jki> if not, I would look closer at the kernel configs
12:10:41 <iwamatsu> It doesn't work locally either.
12:10:42 <iwamatsu> I think we need to modify the contents of the job.
12:11:04 <iwamatsu> There is a problem with the options passed to QEMU.
12:11:07 <jki> virtio disks must work - we actually use them in isar-cip-core as well
12:11:27 <jki> but those are lava controlled IIUC
12:12:08 <iwamatsu> If there is a problem, "if=virtio" is being specified; this does not work correctly with qemu-arm.
12:12:50 <patersonc> The only thing that has changed recently on the LAVA side was the qemu version upgrade
12:13:05 <jki> that's indeed different to isar-cip-core'S script
12:13:21 <jki> if=none there, separate disk device
12:14:05 <iwamatsu> Yes, it works with that setting.
12:14:48 <jki> what is if=virtio instantiating? virtio-scsi? we use legacy virtio-blk in isar-cip-core
12:15:03 <jki> maybe just missing configs for that variant
12:15:23 <jki> but we can debug offline, drop me a note if you need support
12:16:08 <jki> regarding releases: next 4.4 is now, but also 4.4-rt soon
12:16:21 <jki> any other release issues?
12:16:44 <iwamatsu> It is likely virtio-blk.
12:16:54 <iwamatsu> jki: ok, thanks.
12:17:27 <jki> ok, then let's move on...
12:17:29 <pave1> I guess I'll wait for 4.4-cip to do -rt.
12:17:43 <jki> yep
12:18:01 <jki> 5
12:18:03 <jki> 4
12:18:05 <jki> 3
12:18:07 <jki> 2
12:18:08 <jki> 1
12:18:10 <jki> #topic Kernel testing
12:18:39 <arisut> no updates here
12:18:58 <patersonc> Sorry
12:19:08 <patersonc> I've been working on fixing some boots that were failing in kernelci
12:19:09 <arisut> someone had time to test kci-dev with mcp ? https://kernelci.org/blog/2026/09/12/talk-to-kernelci-kci-dev-now-speaks-mcp/
12:19:19 <patersonc> They have been upgrading all of the rootfs'
12:19:34 <arisut> working on fixing kernelci dashboard for kci-dev
12:19:49 <patersonc> I had a quick go with kci-dev mcp to help debug :)
12:20:03 <arisut> oh nice! how was ?
12:20:11 <patersonc> Worked well, thank you
12:20:20 <patersonc> I used the kernelci.org hosted server
12:20:20 <arisut> :)
12:20:29 <jki> I saw Uli mentioning lava in the context of llm tooling as well
12:21:02 <patersonc> LLMs can use lavacli quite successfully. There was talk of a LAVA MCP server being worked on as well
12:21:25 <uli> my concern was how that factors into what kind of hardware we need to run things
12:23:52 <jki> more on testing?
12:24:20 <jki> 5
12:24:22 <jki> 4
12:24:24 <jki> 3
12:24:26 <jki> 2
12:24:27 <jki> 1
12:24:30 <jki> #topic AOB
12:24:48 <jki> several points on my list
12:25:09 <jki> security.md - everyone already had a look?
12:25:45 <iwamatsu> I am reading it now.
12:25:52 <jki> one open point is the disclosure timeline section
12:26:11 <iwamatsu> I will reply by mail.
12:26:18 <jki> perfect
12:26:28 <uli> looks good to me
12:27:41 <jki> btw, timeline is not as hectic as I first thought: reporting obligations for stewards only start in 2027
12:27:57 <pave1> Good.
12:27:57 <jki> but we should still have this file in place a bit earlier ;)
12:28:24 <jki> before anyone from the upstream kernel complains about misrouted vulnerability reports
12:28:28 <pave1> I guess major question is "separate file" or "integrate it into kernel document".
12:28:46 <jki> yep, that as well, though more editorial
12:29:07 <jki> SECURITY.md would then just be a link
12:29:56 <jki> ok, more on that?
12:30:36 <jki> then llm: uli already shared a long update - any questions, additions?
12:31:04 <pave1> I believe we should stay with self-hosted solution, even if it may be more expensive short-term.
12:31:12 <pave1> I believe it will be better long-term.
12:31:45 <jki> do we need the own server also for more than running the model itself?
12:31:59 <jki> means, are there technically needs to have a gateway?
12:32:34 <jki> mid-term, I would really love to have at least experiments with alternative models or hostings, to base the way forward on data
12:32:50 <jki> plus, of course, concerns regarding independence
12:33:28 <uli> i'm going to rent a vast.ai instance with some serious hardware for the next review cycle, just to see how that goes
12:34:20 <patersonc> Fun
12:34:55 <jki> uli: do you need something to cover this via your contract?
12:35:29 <uli> i'll check how much that is going to cost first, for a one-off it might not be worth the effort
12:35:56 <jki> just let us know - it can take time, as you have seen ;)
12:35:58 <jki> but I guess all that could will also be a discussion point for the mini summit
12:36:31 <jki> you talk, uli, will perfectly set the stage, I guess :)
12:36:41 <uli> i hope so :)
12:36:59 <jki> regarding mini summit, topics so far
12:37:08 <jki> - next cip kernel
12:37:16 <jki> - effort increases
12:37:25 <jki> - more hands in 2027
12:37:41 <jki> anything else you want me to bring up?
12:38:20 <jki> uli, pavel, a rough forcast for 2027 would also be helpful when budget discussions start
12:38:36 <jki> does anything change in your rates or availability etc.
12:38:54 <pave1> I don't expect any changes.
12:39:15 <jki> I would then "just" add another engineering resource to the equation, details for general discussion
12:39:39 <jki> more topcis for the summit?
12:40:36 <jki> I'm asking today already due to my last AOB: I need someone to run the meeting next week
12:41:03 <pave1> we may want to discuss better ways to coordinate reviews
12:41:37 <iwamatsu> +1
12:41:46 <pave1> currently, if uli did backport for 4.4, for example, it would be reasonable to assume that
12:42:07 <pave1> the patch looks good for him, so perhaps I don't need to review it for 6.1... or review
12:42:23 <pave1> it as much for 6.1, but that would require some coordination point.
12:42:33 <jki> is that more a topic for a face-to-face sync, or also for the wider (mini summit / tsc) audience?
12:42:43 <pave1> face-to-face, I guess.
12:43:41 <jki> we can have a break-out lunch again, if you like
12:43:55 <jki> didn't check the agenda yet when that would be best
12:44:09 <jki> Tuesday, before the summit?
12:45:47 <jki> btw, is everyone here attending in person?
12:45:49 <uli> i would probably not be able to be there before it starts. bus arrives in florenc at 13:05...
12:46:00 <jki> ok
12:46:26 <jki> then maybe do that Wednesday or Thursday?
12:46:57 <iwamatsu> both ok to me
12:48:13 <jki> I will drop a proposal - or remind me if I forget :)
12:48:46 <jki> so, who could run this meeting next week?
12:48:56 <pave1> I can do that.
12:49:01 <jki> thanks, pavel!
12:49:19 <jki> <end-of-my-AOBs>
12:49:47 <pave1> </my-AOBs> :-)
12:50:25 <jki> anyone else anything?
12:51:01 <patersonc> What happened with the -rc topic on the end?
12:51:07 <patersonc> I forgot
12:52:10 <jki> not much, I suppose - don't recall either
12:52:33 <pave1> I don't think it is good match for the way we use git.
12:52:42 <pave1> We don't really put experimental patches in the trees.
12:52:53 <pave1> ...and already have way too many branches.
12:54:07 <patersonc> Fair enough
12:55:05 <jki> okay...
12:55:08 <patersonc> I guess one option would be to have a linux-cip-rc repo, split off like stable does it
12:55:19 <patersonc> But it's up to you guys
12:55:51 <jki> it both depends on whether it a) helps the maintainers and/or b) attracts more feedback/contribution
12:56:28 <pave1> a) is "I don't think so".
12:56:48 <pave1> b) is "I don't believe we have many people using our git branches".
12:56:51 <jki> ...and b) would need to be more concrete than "let's see"
12:57:33 <jki> I could ask that question at our mini summit - not expecting immediate feedback, though
12:58:05 <jki> but that was the other point for the mini summit I forgot: how to involve CIP kernel users more?
12:58:11 <jki> configs, testing etc.
12:58:17 <jki> noted
12:58:38 <patersonc> The main point for me was to have our testing run _before_ we make releases
12:58:54 <pave1> We are doing testing before we do releases.
12:59:03 <pave1> We are actually testing after each commit.
12:59:28 <pave1> (Or more precisely before each series is commited).
12:59:41 <jki> I need to run for the next meeting soon
12:59:52 <patersonc> only in gitlab CI though, not in KernelCI
13:00:09 <jki> and my irc client will not roam me, so I can't run already
13:00:30 <pave1> Yeah. Because the kernelCI was not usable last time we checked.
13:00:44 <pave1> That has nothing to do with branches;
13:01:00 <pave1> if we want better testing, it would be script that gets sha1 hash and then says either "ok" or "bad".
13:01:11 <patersonc> Not usable in what way?
13:01:49 <iwamatsu> If we want to run tests on a specific branch, we need to hook into branch updates.
13:02:22 <pave1> We would really want to be able to test before pushing the series.
13:02:43 <patersonc> That's what all the changes Arisu-san made to kci-dev allow us to do
13:02:59 <jki> ok, back
13:03:10 <jki> but I really need to leave
13:03:13 <patersonc> And kci-dev can then also be used to monitor the testing progress, if cmdline is preferred over the web dashboard
13:03:17 <patersonc> jki: ha
13:03:31 <pave1> If it works, I guess we should start using it, but I don't believe we need new branches for that.
13:03:33 <pave1> I need to go, too.
13:03:38 <jki> discussion for Prague as well?
13:03:44 <jki> then let's do that there :)
13:03:48 <jki> so ...
13:03:49 <pave1> I guess so :-)
13:03:53 <jki> 5
13:03:56 <jki> 4
13:03:57 <jki> 3
13:03:59 <jki> 2
13:04:01 <jki> 1
13:04:05 <jki> #endmeeting