13:05:23 <jki> #startmeeting CIP IRC weekly meeting
13:05:23 <collab-meetbot`> Meeting started Thu Jan 16 13:05:23 2025 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:05:23 <collab-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:05:23 <collab-meetbot`> The meeting name has been set to 'cip_irc_weekly_meeting'
13:05:23 <jki> #topic AI review
13:05:23 <jki> - prepare blog entry on SLTS kernel state and challenges [Jan]
13:06:01 <jki> ping
13:06:11 <jki> am I online again?
13:06:14 <pave1> Yup, we see you.
13:06:25 <jki> ok, what was last?
13:06:40 <iwamatsu__> AI review
13:06:52 <jki> good, resuming:
13:06:55 <jki> - prepare blog entry on SLTS kernel state and challenges [Jan]
13:07:02 <jki> done, finally, post is public
13:07:18 <jki> I have no other AIs recorded
13:07:30 <jki> 5
13:07:31 <jki> 4
13:07:33 <jki> 3
13:07:34 <jki> 2
13:07:36 <jki> 1
13:07:38 <jki> #topic Kernel maintenance updates
13:07:47 <pave1> I did some reviews, 6.1.120, .125.
13:07:49 <masami> This week reported 103 new CVEs and 26 updated CVEs.
13:07:51 <uli_> i'm reviewing 6.1.125
13:08:28 <iwamatsu__> I reviewed 6.1.123, 124. and reviewing .125.
13:09:37 <jki> anything else?
13:09:56 <jki> 5
13:09:58 <jki> 4
13:10:00 <jki> 3
13:10:02 <jki> 2
13:10:04 <jki> 1
13:10:07 <jki> #topic Kernel release status
13:10:15 <jki> all fine, except for 6.1-rt
13:10:37 <jki> pavel: any news on that front?
13:10:58 <pave1> Yep, I'd really like matching 6.1-rt to proceed.
13:11:25 <jki> last 6.1-rt was late last year - when might be the next?
13:12:15 <pave1> Let me take a look, but it is hard to guess, really.
13:12:57 <jki> aren't you part of their community and can ask that?
13:13:16 <pave1> Yes, I can try to push them.
13:14:03 <jki> good, thanks
13:14:17 <jki> anything else regarding releases?
13:14:37 <jki> 5
13:14:39 <jki> 4
13:14:40 <jki> 3
13:14:42 <jki> 2
13:14:43 <jki> 1
13:14:46 <jki> #topic Kernel testing
13:14:59 <patersonc> Hey
13:15:20 <patersonc> I finally got around to looking into the merged x86 configs for SWG
13:15:33 <patersonc> Got an MR created to start using it
13:15:47 <patersonc> Do we want to use it instead of the device specific configs? Or in addition?
13:16:25 <jki> the vision of the merged configs is to have one kernel per arch - if possible
13:16:53 <patersonc> Okay
13:17:08 <pave1> We are catching bugs we would not catch with just one config.
13:17:18 <pave1> But I'm not sure benefit is worth the effort.
13:17:47 <jki> we can't catch them all anyway, too many permutations
13:17:47 <pave1> It may be beneficial for -stable-rc testing.
13:18:18 <patersonc> So keep stable pipelines as-is? And CIP use the merged configs?
13:18:26 <jki> question is what kernelci could compensate
13:18:36 <iwamatsu__> I think it is necessary to listen to the opinions from the company that provides the reference HW.
13:18:49 <patersonc> True
13:18:56 <pave1> Keep them for compile-only testing if that's not too much effort.../
13:18:58 <pave1> ?
13:19:36 <patersonc> Could do, although the compiling is where most of the cost is
13:21:01 <pave1> Each build takes 4 minutes on a server. That should not be that costly...
13:21:20 <patersonc> Sure
13:21:22 <pave1> 0.02kWh :-)
13:22:50 <jki> ok, do we have plan then?
13:23:24 <patersonc> just about
13:23:57 <jki> anything else on testing?
13:23:59 <patersonc> I did see some boot issues with CIP 4.4 though: https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/1626448709
13:24:31 <patersonc> Specifically https://lava.ciplatform.org/scheduler/job/1238563 and https://lava.ciplatform.org/scheduler/job/1238564
13:25:18 <patersonc> All other CIP kernels were okay
13:25:43 <patersonc> Anyway, can be looked at later
13:25:46 <arisut> I'm probably going to release kci-dev 0.1.2 this week with the new `kci-dev results` command for getting kernelci information from a local checkout Linux repository
13:25:53 <jki> missing features in the .config?
13:25:55 <arisut> currently writing documentation
13:26:09 <patersonc> Thanks arisut
13:26:26 <pave1> https://lava.ciplatform.org/scheduler/job/1238563 -- nfs root mount failure.
13:27:00 <pave1> ...but I can't see eth0 in the log, so maybe we need to enable ethernet driver?
13:27:05 <arisut> This is the new release milestone if anyone is interested
13:27:55 <patersonc> Actually - we don't support those platforms in 4.4
13:28:01 <patersonc> I shouldn't even be testing them
13:28:03 <patersonc> Ignore me
13:28:10 <patersonc> Ref: https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/cipreferencehardware
13:28:11 <pave1> :-) That's likely easiest.
13:28:15 <arisut> Also the KernelCI api are still under development
13:28:45 <jki> arisut: as you may have seen, I stopped image deployment therefore
13:29:06 <arisut> thanks, I will restart when we have a stable api
13:29:30 <patersonc> Great
13:30:32 <jki> more testings topics?
13:30:46 <patersonc> Not from me
13:31:42 <jki> 5
13:31:44 <jki> 4
13:31:46 <jki> 3
13:31:48 <jki> 2
13:31:50 <jki> 1
13:31:53 <jki> #topic AOB
13:32:12 <pave1> I'll be travelling next week.
13:32:28 <jki> ok
13:33:16 <jki> I have one as well:
13:33:22 <jki> security contact for cip kernels
13:33:33 <jki> specifically but not only self-maintained ones
13:33:54 <jki> alternative to security@kernel.org
13:33:58 <pave1> Fun :-).
13:34:11 <jki> any suggestions, opinions etc.?
13:34:33 <pave1> Normally people expect secure communication on these with rather high requirements.
13:35:02 <jki> well, anything is better than no communication channel
13:35:15 <jki> well, anything but a public channel, obviously
13:35:34 <jki> can be individual email addresses
13:35:44 <pave1> In that case, me, you, uli + iwamatsu? :-) Lets hope it is never used...
13:35:51 <jki> for isar-cip-core, I've no proposed confidential issues
13:36:16 <jki> what would the kernel maintainers prefer?
13:36:23 <jki> and where should we document that?
13:36:42 <jki> (see SECURITY.md patch for isar-cip-core)
13:37:08 <pave1> If we have someone in security team with security set up already, it may be actually best to point initial communication at them.
13:37:49 <jki> I'm not aware of this, and I don't see this as first option at this stage
13:38:25 <jki> that person would likely just be the moderator
13:39:06 <pave1> Will we want to do GPG for that or not?
13:39:52 <jki> via email, this would be optimal
13:39:54 <pave1> If we are comfortable having an email address but not GPG key, feel free to point that at me.
13:40:17 <jki> if we go for issue tracking, the mechanisms are different
13:40:58 <jki> but we can still optmize that - I would like to have something at all first
13:41:17 <pave1> So -- alias somewhere at lf for a start?
13:41:47 <jki> private mailing list on lists.cip-project.org
13:42:17 <pave1> That precludes GPG in the future. But yes, would work for a start.
13:42:38 <jki> does security@kernel.org have a GPG key?
13:43:02 <jki> not finding anything in Documentation/process/security-bugs.rst
13:44:16 <jki> if we go for such a list, does the kernel WG want its own, or just security@lists.cip-project.org (covering isar-cip-core e.g. as well)?
13:45:11 <pave1> How much traffic do we expect there?
13:45:40 <pave1> I guess it will be email a year, so we could just use merged list...?
13:46:02 <jki> yes, if spam filters continue to work
13:46:21 <jki> then I would propose that to the TCP and also update my isar-cip-core proposal
13:46:40 <jki> there, I added me and Kazu as alternative contacts so far
13:46:53 <jki> anyway, topic for the next TSC as well
13:46:58 <pave1> Sounds good.
13:47:09 <jki> just wanted to gather opinions of kernel WG beforehand
13:47:29 <pave1> I was under impression there's expectation of channel with higher security, but it does not seem security@kernel.org is that one.
13:48:03 <pave1> Mailing list is good equivalent of security@kernel.org .
13:48:20 <jki> "This is a private list of security officers
13:48:20 <jki> who will help verify the bug report and develop and release a fix"
13:48:30 <jki> writes the kernel
13:48:43 <jki> ok - other businesses for today?
13:49:06 <jki> 5
13:49:08 <jki> 4
13:49:09 <jki> 3
13:49:12 <jki> 2
13:49:14 <jki> 1
13:49:15 <jki> #endmeeting