13:03:33 <jki> #startmeeting CIP IRC weekly meeting
13:03:33 <collab-meetbot> Meeting started Thu Nov 21 13:03:33 2024 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:03:33 <collab-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:03:33 <collab-meetbot> The meeting name has been set to 'cip_irc_weekly_meeting'
13:03:37 <jki> #topic AI review
13:03:40 <jki> - prepare blog entry on SLTS kernel state and challenges [Jan]
13:03:59 <jki> sorry, got distracted again
13:04:08 <pave1> I got a link on that one on google, but was not able to open it.
13:04:17 <pave1> At some point, mailing version out would make sense :-).
13:04:24 <jki> ah, that was the announcement thing
13:04:33 <jki> let me check if I can fix
13:04:47 <jki> yes, I can also post that on that thread
13:04:57 <pave1> That would be easiest, thanks!
13:05:08 <jki> ok - other AIs are not recorded
13:05:14 <jki> 5
13:05:16 <jki> 4
13:05:17 <jki> 3
13:05:18 <jki> 2
13:05:19 <jki> 1
13:05:21 <jki> #topic Kernel maintenance updates
13:05:45 <pave1> I'm doing reviews,  4.4-st58, 6.1.117,118,119.
13:05:48 <masami> This week reported 93 new CVEs and 19 updated CVEs.
13:05:54 <uli_> i've been preparing 4.4
13:06:17 <iwamatsu__> I reviewed 6.1.117 , and I am reviewing 4.4-st58
13:06:23 <pave1> There's fun situation where -stable is reverting security fixes because they break functionality.
13:06:37 <pave1> I guess I'll need to investigate more and bring up popcorn :-).
13:07:12 <pave1> Example is 8456fd1db 811371 o: 6.1| Revert "Bluetooth: hci_core: Fix possible buffer overflow" .
13:07:38 <jki> huh, will that revert CVE states as well? :)
13:09:53 <jki> anything else?
13:10:50 <jki> 5
13:10:51 <jki> 4
13:10:52 <jki> 3
13:10:53 <jki> 2
13:10:55 <jki> 1
13:10:58 <jki> #topic Kernel release status
13:11:12 <jki> we have three late markers
13:11:22 <jki> 4.4 will come out soon?
13:11:28 <uli_> once the reviews are through
13:11:58 <uli_> it's a big release, lots of backports
13:12:01 <pave1> 5.10-rt: There's .226-rt out, but that's old one. .229-rt-rc1 is out there, so I suggest to wait till that's released.
13:12:16 <iwamatsu__> for 6.1.y-cip, I am preparing it.
13:12:52 <jki> ok, then things look more green next week
13:14:26 <jki> I still wonder, though, is stable rt should further fall behind if it is our best option to wait that often
13:15:34 <jki> anything else?
13:15:53 <pave1> I can do .226-rt based release, but that would be releasing old code.
13:16:16 <pave1> Maybe we should adjust our schedules for 4.19 / 5.10 rt to be less common.
13:16:18 <jki> yes, that why I'm questioning to wait
13:16:27 <jki> better become active and port forward
13:16:47 <pave1> ...or maybe admit that our releases are controlled by upstream ;-).
13:16:50 <jki> at least when it is as easy as Clark put it - in most cases
13:17:08 <jki> pavel: that will change anyway
13:17:27 <jki> for 4.19 soon
13:17:43 <jki> and then 5.10 and 6.1 as well
13:17:51 <pave1> Technially, forward porting rt changes to next stable is likely easy...
13:17:59 <jki> exactly
13:18:03 <pave1> Hmm, true, self-maintenance.
13:18:28 <jki> if the load explodes, we can still take measures
13:18:42 <pave1> But it would not get benefit of testing, and there could be fun if they decide to do something different.
13:18:53 <patersonc> Do we know how long the RT project plan to maintain the older kernels? For the whole LTS cycle?
13:19:01 <pave1> Anyway, in this case, I wait for .229-rt?
13:19:10 <pave1> patersonc: Yes, that's what happened in the past.
13:19:31 <jki> the RT project is not maintaining LTS, it's individual contributors
13:19:43 <jki> (backed by companies, though, in many cases)
13:20:28 <jki> the RT project supports LTS maintainer, and we could make use of that - specifically as member
13:21:00 <patersonc> Okay. I wondered if most of the upstreaming effort was done we could ask them to redirect membership money for the maintenance work?
13:21:23 <jki> we started to discusse this in the project, but there is no clear plan yet
13:21:37 <pave1> That's the discussion currently happening; there is an email asking members how to prioritize the work.
13:21:46 <jki> yep
13:23:17 <patersonc> Okay :)
13:24:40 <jki> anyhing else on this topic?
13:24:49 <jki> 5
13:24:51 <jki> 4
13:24:52 <jki> 3
13:24:54 <jki> 2
13:24:56 <jki> 1
13:24:58 <jki> #topic Kernel testing
13:25:31 <patersonc> I need to look into a couple of emails/requests sent this week - hopefully I'll get time later or tomorrow.
13:25:40 <patersonc> I've no exciting updates to share though - sorry
13:25:51 <pave1> bbb is acting up.
13:25:56 <pave1> Could someone take a look?
13:26:23 <jki> all bbb's or just in a specific lab?
13:26:37 <pave1> Plus it would be good to start testing 6.12.x. (Or probably we are already testing it and I just need a link).
13:26:58 <patersonc> Good point - I forgot about that. Thanks pave1
13:27:26 <iwamatsu__> one bbb on lab-cip-denx is not working now.
13:28:38 <pave1> iwamatsu: Is that why I need to hit 'retry' few times?
13:30:03 <jki> if it is only one bbb instance, poke the lab owner
13:31:14 <iwamatsu__> pave1: It seems that one BBB is offline. It seems that tests often fail in BBB.
13:31:22 <patersonc> The failures seem spread between multiple devices
13:31:34 <patersonc> Scroll down on https://lava.ciplatform.org/scheduler/device_type/beaglebone-black?dt_search=&dt_length=100#dt_ and look for incomplete
13:32:23 <patersonc> Failures seem to be for cip configs and for defconfig
13:32:34 <iwamatsu__> https://lava.ciplatform.org/scheduler/job/1224761#L546
13:32:34 <patersonc> But there are also passes for the same
13:32:57 <pave1> It fails on -stable-rc too, I just hit retry till I get a success...
13:33:51 <iwamatsu__> In most cases, the NFS mount has failed and has become a timeout..
13:34:11 <iwamatsu__> OK ,I will check it.
13:34:26 <jki> but if that happens in multiple labs and didn't happen (that often) in the past, it speaks more for a kernel regression
13:35:09 <patersonc> And if it was an NFS server issue we'd expect to see similar issues for other devices
13:35:13 <pave1> At least https://lava.ciplatform.org/scheduler/job/1224454 is zimage: bad magic, bootloader-commands timing out.
13:35:18 <pave1> Hard to blame kernel for that.
13:37:03 <patersonc> Indeed. And that's a healthcheck job
13:37:05 <jki> simple to test: run older kernels multiple time in the same lab and see if they fail as well now
13:37:27 <jki> if that healthcheck job is with an older kernel: done
13:37:38 <patersonc> iwamatsu__: Let's chat via IRC/email about this when you have time?
13:38:28 <iwamatsu__> Sure
13:38:36 <jki> good - thanks in advance to anyone doing the hard debugging :)
13:38:38 <pave1> jki: Bootloader claims zimage magic is wrong. It succeeds when repeated. That's before kernel was loaded. I believe kernel is not responsible.
13:38:53 <jki> pavel: ack
13:39:04 <jki> other testing topics?
13:40:37 <jki> 5
13:40:39 <jki> 4
13:40:40 <jki> 3
13:40:41 <jki> 2
13:40:42 <jki> 1
13:40:44 <jki> #topic AOB
13:41:03 <jki> already wrote: I will likely not be available next week
13:41:10 <jki> anyone able to pick up?
13:41:37 <iwamatsu__> I can takeover
13:41:45 <jki> thanks!
13:41:49 <iwamatsu__> :-)
13:41:58 <jki> other topics for today?
13:42:32 <jki> 5
13:42:34 <jki> 4
13:42:36 <jki> 3
13:42:38 <jki> 2
13:42:39 <jki> 1
13:42:42 <jki> #endmeeting