13:00:59 <jki> #startmeeting CIP IRC weekly meeting
13:00:59 <collab-meetbot> Meeting started Thu Sep  4 13:00:59 2025 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:59 <collab-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:59 <collab-meetbot> The meeting name has been set to 'cip_irc_weekly_meeting'
13:01:06 <jki> #topic AI review
13:01:14 <jki> currently none recorded
13:01:24 <jki> 5
13:01:26 <jki> 4
13:01:28 <jki> 3
13:01:29 <jki> 2
13:01:31 <jki> 1
13:01:33 <jki> #topic Kernel maintenance updates
13:01:46 <uli> i released 4.4
13:01:54 <masami> This week reported 3 new CVEs and 103 updated CVEs.
13:02:15 <pave1> I'm doing reviews, 6.1.44 and .45.
13:02:54 <iwamatsu_> hello
13:03:21 <jki> hi! we are at maintenance updates already
13:04:01 <iwamatsu_> I reviewed 6.12.42 and 43,
13:04:50 <arisut> currently kernel upstream is releasing new kernel as we talk 5.15.191,5.10.242, 5.4.298
13:04:58 <arisut> fyi
13:06:42 <jki> any further updates?
13:07:26 <jki> 5
13:07:28 <jki> 4
13:07:29 <jki> 3
13:07:31 <jki> 2
13:07:32 <jki> 1
13:07:36 <jki> #topic Kernel release status
13:07:51 <jki> 4.4-rt is late IIRC
13:08:29 <pave1> Yep, sorry about that. I don't foresee problems, should do it on friday or over weekend.
13:09:20 <jki> perfect
13:09:44 <jki> anything else on this?
13:09:55 <jki> 5
13:09:57 <jki> 4
13:09:59 <jki> 3
13:10:00 <jki> 2
13:10:02 <jki> 1
13:10:03 <jki> #topic Kernel testing
13:10:05 <arisut> o/
13:10:26 <arisut> about release we have a way to mask problematic cip kernel ?
13:11:20 <pave1> Does that have anything to do with "currently upstream is releasing 5.4.298" announcement? :-)
13:11:32 <arisut> in the case that the kernel have build issues or similar
13:11:45 <arisut> just asking
13:12:18 <pave1> Not really, it may depend on severity.
13:12:37 <arisut> I see, thanks
13:14:20 <arisut> maybe could be useful to have something to indicate that a version have serious problems
13:14:20 <patersonc> On the testing side of things, we've got some really high load on the LAVA server which is causing some issues
13:15:03 <arisut> I talked with collabora about the issues and they are willing to share some filtering script
13:15:17 <arisut> problem is that we don't have root access to lava-cip servers
13:15:44 <patersonc> indeed
13:16:03 <arisut> :(
13:16:20 <arisut> another solution could be to ask LF to set cloudfare
13:16:30 <arisut> they already using it for kernel.org
13:16:58 <arisut> probably is the fastest solution as LF have already experience with that
13:17:08 <patersonc> Yea
13:17:20 <arisut> qq
13:17:28 <patersonc> I'll keep trying to narrow down the issue and talk to LF in tandem
13:17:32 <arisut> also broonie is using it for his lava server
13:17:57 <arisut> qq <- writing on the wrong keyboard lol
13:19:24 <jki> patersonc: no one reacted on your lava load issue yet, right?
13:19:45 <patersonc> Nope. ALthough Cybertrust lab admin said it wasn't them
13:19:55 <pave1> patersonc: https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/2021753921 I'm having more problems than usual with testing. Is that related / likely to get better on its own?
13:20:13 <jki> we cannot identify the source??
13:20:29 <jki> do all workers share the same token?
13:20:31 <arisut> collabora said is a know issue, there are some bots that are causing problems with lava
13:20:50 <jki> AI crawlers again, nothing authenticated?
13:21:15 <patersonc> It could just be web traffic, rather than api
13:21:43 <jki> can we close the web interface without affecting the API?
13:21:52 <arisut> without server access we can only suppose
13:21:53 <jki> at least temporarily
13:22:35 <jki> oh, that was the missing root access?!
13:22:46 <jki> who has then, LF admins?
13:22:48 <arisut> yes
13:22:59 <jki> -> LF ticket?
13:23:15 <patersonc> I've already got a discussion open with our usual LF IT contactr
13:23:21 <jki> ok
13:23:24 <arisut> patersonc, thanks !
13:24:48 <jki> guess we have to wait and see then...
13:25:02 <jki> other testing topics?
13:25:16 <patersonc> For now, kernel testing may take a hit. There are still some labs offline since I rebooted the LAVA master
13:25:48 <pave1> Ok. I'll hit retry few more times ;).
13:25:48 <arisut> I'm starting to add nfsrootfs build and x86 platforms
13:26:36 <jki> only one is offline right now, iwamatsu's
13:27:16 <jki> but several in "maintenance" state - is that what you mean?
13:27:31 <patersonc> Yea
13:27:38 <iwamatsu_> maybe other lab does not reconnect yet.
13:27:41 <patersonc> I put them all into maintenance until the lab owners reboot the labs
13:28:07 <patersonc> LAVA doesn't like it when the server reboots. The labs don't automatically start working again - they want a reboot too
13:28:36 <jki> did you inform all lab owners already?
13:28:45 <patersonc> Yes
13:29:04 <arisut> patersonc, beaglebone could boot with nfsrootfs https://lava.ciplatform.org/scheduler/job/1305458
13:29:32 <arisut> but we have still problems with r8a7743-iwg20d-q7 https://lava.ciplatform.org/scheduler/job/1305459
13:29:46 <patersonc> Thanks arisut
13:30:18 <arisut> maybe we could add some boot commands?
13:30:56 <arisut> I see there is a  extra_kernel_args: lsm=capability,landlock,yama,loadpin,safesetid,selinux,bpf on some nfs machine
13:31:23 <patersonc> I've never set those for the iwg20d boards before
13:31:31 <arisut> on the collabora boards
13:31:40 <arisut> maybe we need something similar
13:31:56 <arisut> I will investigate difference on the build
13:32:02 <patersonc> Thanks
13:32:25 <arisut> np
13:32:37 <iwamatsu> it can not boot with zImage
13:33:23 <patersonc> We need to work out why zimage isn't working
13:33:32 <iwamatsu> iwg20d need to use uImage with default bootloader
13:33:59 <patersonc> Arisut is there a way to get uimage out of kernelci?
13:34:01 <iwamatsu> meybe it depends on address of boot imge.
13:34:26 <arisut> patersonc, I doubt :/ will check
13:35:12 <patersonc> Thanks
13:35:37 <arisut> it cannot work with zimage or maybe it could work but is not tested ?
13:36:33 <patersonc> Maybe we just need to check the uboot command
13:36:39 <arisut> ok
13:37:21 <arisut> I will check about using uimage
13:37:44 <arisut> looks like we have a make target for uimage
13:37:54 <iwamatsu> I think the bootloader didn't support zImage...
13:38:18 <arisut> I hope that is still working on pipeline but looks like is not used anymore
13:38:58 <arisut> I will check how to make it throw uimage
13:39:05 <arisut> thanks
13:39:14 <patersonc> Thanks
13:39:21 <jki> patersonc: it's likely hopeless to wait for a denx lab reboot - just set it to active again and pray ;)
13:39:43 <patersonc> yea
13:40:01 <jki> Quirin set both our labs to active as well - works without rebooting
13:40:16 <jki> maybe that issue was with older lava
13:40:16 <pave1> jki: I can try to ask for reboot -- should I?
13:40:38 <jki> pavel: only if we see issues, I would say
13:40:41 <patersonc> jki: The issue is that the LAVA_DISPATCHER_IP variable doesn't get set. So NFS jobs will fail
13:40:43 <pave1> jki: ok.
13:43:37 <jki> patersonc: does not seem to be the case for our labs
13:46:03 <patersonc> okay
13:46:07 <patersonc> I'll keep an eye on it
13:46:30 <jki> yeah, just ping us
13:47:13 <jki> more testing topics?
13:47:32 <jki> 5
13:47:34 <jki> 4
13:47:36 <jki> 3
13:47:38 <jki> 2
13:47:40 <jki> 1
13:47:42 <jki> #topic AOB
13:48:48 <masami> I will be absent  next week
13:49:17 <patersonc> Same here
13:50:41 <jki> ok
13:50:52 <jki> anything else for today?
13:51:09 <jki> 5
13:51:11 <jki> 4
13:51:13 <jki> 3
13:51:14 <jki> 2
13:51:16 <jki> 1
13:51:19 <jki> #endmeeting