12:01:29 <jki> #startmeeting CIP IRC weekly meeting 12:01:29 <collab-meetbot`> Meeting started Thu Feb 5 12:01:29 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:29 <collab-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 12:01:29 <collab-meetbot`> The meeting name has been set to 'cip_irc_weekly_meeting' 12:01:36 <jki> #topic AI review 12:01:41 <jki> empty 12:01:41 <iwamatsu__> hello 12:01:47 <jki> 5 12:01:49 <jki> 4 12:01:51 <jki> 3 12:01:52 <jki> 2 12:01:54 <jki> 1 12:01:56 <jki> #topic Kernel maintenance updates 12:02:07 <masami> This week reported 116 new CVEs and 16 updated CVEs. 12:02:10 <pave1> I was reviewing 6.12.67 and .68 12:02:46 <iwamatsu__> I reviewed 6.12.67 12:04:13 <jki> further topics? 12:04:42 <jki> 5 12:04:44 <jki> 4 12:04:45 <jki> 3 12:04:47 <jki> 2 12:04:49 <jki> 1 12:04:51 <jki> #topic Kernel release status 12:04:59 <pave1> 4.19-rt was released. 12:05:04 <jki> thanks! 12:05:14 <jki> nicely aligned again 12:05:43 <jki> news from 6.1-rt? 12:05:45 <pave1> Currently I'm working on 6.1-rt. -rt is done, but -rt-rebase is going to be a bit tricky 12:05:57 <pave1> and it will make next -rt-rebase tricky. 12:06:25 <jki> what is particularly tricky about it? 12:07:06 <pave1> So ... there's 6.1 -- stable -- rt -- cip 12:07:49 <pave1> We have cip on top of rt, but now cip and rt is on different stable kernels. 12:08:07 <pave1> So I'll need to invent a rt "release" and put cip on top of that. 12:08:29 <pave1> And next time I'll try to do 6.1-rt, tag will not exist. 12:08:52 <pave1> Fortunately -rt is easy and I can compare the trees, which should tell me if something went wrong. 12:09:22 <jki> maybe you can offer your rt work to stable-rt, and Clark will pick it up for a release? 12:09:29 <jki> would be nice anyway 12:10:04 <pave1> I assume he has scripts he can just follow. 12:10:42 <jki> anyway, the information that rebasing is straightforward may help that he actually starts this 12:11:08 <pave1> There should be no "real" work in the rebasing, but I need to document the steps for later use and not break something in the process. 12:11:13 <jki> in the end, we also want upstream stable-rt to proceed, at least as long as stable exists for 6.1 12:12:35 <pave1> Yes, stable-rt is good for us. 12:13:14 <jki> then continue to motivate them to release ;) 12:13:51 <pave1> Yeah, I'm not sure I'm right person for that :-) 12:15:00 <jki> is your branch somewhere visible already? Then I could use it to talk to Clark again 12:15:44 <pave1> I'm currently testing it at https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/2307585171 12:16:02 <jki> and the code is where? 12:16:31 <pave1> Let me get to successful tests before pushing it to -cip. 12:17:06 <jki> ok, just let me know 12:17:34 <pave1> Ok. I'll add some kind of tag when creating -rebase tree; that's what will be usefull for outside world, anyway. 12:17:56 <jki> ok, rest of the releases are on track - anything to add? 12:18:20 <jki> 5 12:18:22 <jki> 4 12:18:24 <jki> 3 12:18:25 <jki> 2 12:18:27 <jki> 1 12:18:29 <jki> #topic Kernel testing 12:19:04 <patersonc> The KernelCI PR adding beaglev-fire support was merged, but not pushed to production yet 12:19:05 <pave1> So... bbb is still acting up, as can be seen in https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/2307585171 12:19:15 <patersonc> Thanks Pavel 12:21:12 <pave1> (The other 3 failures -- should I just hit retry?) 12:21:59 <patersonc> Both of the ipc227e failures seem to be caused by the tests taking too long and it timing out 12:23:36 <patersonc> One took ages to boot. The other seemed to stop doing anything after the CVE tests were run 12:23:50 <jki> bbb: "bootserver=192.168.175.254, rootserver=192.168.0.2, rootpath=" and "VFS: Unable to mount root fs via NFS." 12:24:00 <jki> that empty rootpath looks suspicious 12:24:17 <jki> a non-empty one was passed via cmdline, though 12:24:39 <jki> who's operating this? 12:25:07 <patersonc> This bbb device doesn't seem happy for aany testing: https://lava.ciplatform.org/scheduler/device/beaglebone 12:25:29 <patersonc> Same/similar tests on another bbb seem okay: https://lava.ciplatform.org/scheduler/device/bbb-iwamatsu-01 12:25:47 <jki> is it always the one from our Prague lab? 12:26:11 <jki> then I will ping Pasquale on this 12:26:22 <patersonc> The device dictionary is missing "{% set extra_nfsroot_args = ',vers=3' + extra_nfsroot_args|default('') %}" 12:28:14 <patersonc> Hopefully that'll fix the bbb issue Pavel. We'll have to look at ipc test timeouts later 12:28:25 <jki> who can change that? 12:28:29 <patersonc> rzfive failure was random serial failure, fix with rerun 12:28:35 <jki> I informed Pasquale in any case 12:28:39 <patersonc> jki: Pasqaule 12:28:47 <jki> ok 12:29:17 <pave1> Ok, I'll hit rerun on everything -- I believe it will pass, so save the "bad" results if you want them. 12:29:54 <patersonc> okay 12:30:49 <jki> more on testing? 12:31:06 <arisut> working on kci-dev 12:31:28 <arisut> but no new updates 12:32:46 <patersonc> Nothing else from me 12:33:10 <jki> then let's move on 12:33:16 <jki> 5 12:33:18 <jki> 4 12:33:20 <jki> 3 12:33:22 <jki> 2 12:33:24 <jki> 1 12:33:26 <jki> #topic AOB 12:33:45 <pave1> I'll be travelling next week. 12:34:02 <jki> I have one topic: did we document feature / board support backporting rules anywhere? 12:34:14 <pave1> Hopefully with my notebook this time :-) 12:34:30 <jki> I scanned https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance for it but didn't find a lot 12:35:13 <jki> background: will have a call with a CIP-interested party on this particular topic tomorrow 12:35:53 <pave1> I am not sure if we have explicit rules somewheer 12:36:00 <pave1> AFAICT the rules are: 12:36:06 <patersonc> Isn't that what the "Suitable changes" section is? 12:36:48 <pave1> a) It must be in mainline, or mainline must have different fix for the same bug 12:37:02 <pave1> b) If it is in older-cip, it must be in all newer-cip trees 12:37:05 <jki> yeah, but board enabling is not really "bug" 12:38:04 <pave1> c) If it touches common code... well... we are more careful 12:38:33 <jki> maybe you (maintainers) could check the wiki again and maybe augment things a bit for the feature backporting topic 12:38:58 <jki> I already explained in an email that we do not accept complete subsys refactorings as backports 12:39:06 <jki> due to testability issues already 12:39:12 <pave1> yep. 12:39:35 <pave1> Basically we were going by "does this look ok" to now. 12:39:37 <jki> maybe you also remember some good examples from the past? 12:40:02 <jki> to give people an impression 12:40:12 <pave1> I really do not want to see "here's intrusive series, but it meets rules, so apply it". 12:40:21 <pave1> Oh and 12:40:34 <pave1> d) series should be less than 30 or so patches each. 12:40:49 <jki> putting a "CIP maintainers have last word" there is a rule to prevent that? 12:41:17 <pave1> Renesas is doing quite good job pushing the patches. There are numerous examples on the mailing list. 12:42:03 <jki> I also meant examples that may have required some adjustments, a second round 12:42:11 <pave1> Concretely "Biju Das" knows how to submit patches. 12:42:25 <pave1> There are not many of those. 12:42:32 <pave1> Ok, there's 12:42:47 <pave1> e) if it is applicable to -stable, it should go through -stable 12:43:21 <pave1> We asked for explanations when they touched common code. 12:44:03 <pave1> Recently MSTOP patches went up to v3, because we were trying to push them to drivers-only solution but that turned out to be too intrusive. 12:44:22 <pave1> And sometimes we get patches that don't work or are not signed-off or something. Fortunately not too common. 12:45:24 <jki> ok, will assembly my replies from this 12:45:41 <pave1> "If you are not modifying common code, you can expect about 20 patches a week being merged if they meet the criteria above" :-) 12:45:45 <jki> would still be nice to have a bit more written in the wiki 12:46:06 <jki> any other businesses for today? 12:47:07 <jki> 5 12:47:09 <jki> 4 12:47:10 <jki> 3 12:47:12 <jki> 2 12:47:14 <jki> 1 12:47:15 <jki> #endmeeting