13:01:44 <jki> #startmeeting CIP IRC weekly meeting
13:01:44 <collab-meetbot`> Meeting started Thu Sep 26 13:01:44 2024 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:44 <collab-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:44 <collab-meetbot`> The meeting name has been set to 'cip_irc_weekly_meeting'
13:01:51 <jki> #topic AI review
13:01:57 <jki> - prepare blog entry on SLTS kernel state and challenges [Jan]
13:02:41 <jki> once again: not yet, I'm working on integrating the take-aways from last week
13:02:53 <jki> I don't have other AIs on my list
13:03:08 <jki> 5
13:03:10 <jki> 4
13:03:12 <jki> 3
13:03:13 <jki> 2
13:03:15 <jki> 1
13:03:18 <jki> #topic Kernel maintenance updates
13:03:27 <pave1> Reviews, 6.1.110, .111.
13:03:30 <uli> i reviewed 6.1.110
13:03:49 <iwamatsu__> I reviewed 6.1.109.
13:05:31 <jki> anything else?
13:05:35 <patersonc> Does discussing SLTS(?) 6.12 count as a maintenance topic? Sorry I wasn't there last week, were there any conclusions?
13:06:02 <jki> not yet an "update" topic :)
13:06:11 <patersonc> Okay :)
13:06:26 <jki> no decisions, just the intention to follow our tradition
13:06:34 <jki> if upstream does as well
13:06:55 <patersonc> That's good. I like a stable pattern
13:07:44 <jki> we can make the discussion more concrete once 6.12 is official LTS
13:08:22 <pave1> I guess it is expected that 6.12 will be official LTS, but we'll know for sure in 2 months...
13:08:36 <patersonc> Okay. But no major blockers expected from our side from taking on another SLTS?
13:08:55 <jki> we can discuss any already predictable effort increases
13:09:20 <jki> in fact, that question will arise sooner, e.g. for budget planning next year
13:10:02 <pave1> Actually, what we might want to do now is to start testing 6.12-rc... if that's simple
13:10:17 <pave1> To make sure 6.12 is released in good shape.
13:10:21 <jki> sure
13:10:27 <pave1> It will be more effort now but will save effort later.
13:10:48 <patersonc> Sounds good
13:11:05 <pave1> We should be able to build rt & non-rt parts from same tree, just with different .config.
13:11:40 <jki> but keep in mind that arm32 is not part of 6.12
13:11:54 <jki> we will have to decide what to do with it
13:12:02 <pave1> Hmm.
13:12:16 <jki> 4 patches, if I recall correctly
13:12:24 <pave1> We could either treat it as add-on patch - in similar way we carry renesas patches now.
13:12:40 <pave1> Or we may try to declare arm32-rt unsupported, and see if anyone notices :-).
13:12:44 <jki> well, we don't carry deviations only backparts, formally
13:12:51 <jki> with CI exceptions
13:12:56 <jki> no?
13:13:16 <pave1> You are right we normally enforce that.
13:13:35 <jki> if we are lucky, upstream accepts arm32-rt with 6.13 or so, then we could easily backport
13:13:40 <pave1> I assume eventually arm32-rt is merged to mainline, too, and at that point we are free to backport it.
13:13:41 <pave1> +1.
13:13:53 <patersonc> Has upstream dropped arm32 in 6.12? Or CIP won't support it?
13:14:05 <pave1> But if noone uses arm32-rt with 6.12, that would be easiest.
13:14:13 <jki> no, arm32 is alive
13:14:31 <jki> this is only about the rt bits for it not being part of 6.12 yet
13:14:46 <pave1> patersonc: Issue is -rt specific. -rt was merged to mainline only for other architectures, no arm32 at the moment.
13:14:53 <patersonc> Ahhh okay. Make sense - I think I would have heard it if it was the whole kernel :P
13:15:05 <jki> well, that is a valid question, if there are immediate 6.12-rt arm32 users
13:15:15 <jki> we may also postpone that topic for some time
13:15:42 <pave1> Postpone for now. I guess there'll be TSc-level "supported configs" and "reference configs" discussion
13:15:46 <pave1> where 6.12 is near?
13:15:47 <jki> rather than starting a cip-rt for arm32 only and later on being able to switch to regular rt due to backports
13:16:02 <jki> yep
13:16:07 <pave1> So arm32-rt is part of that discussion.
13:17:13 <jki> it is also still unclear if there will be a 6.12-rt-lts kernel from the RT project - maintainer is needed
13:17:21 <jki> anyway
13:17:54 <jki> anything else on 6.12 or maintenance?
13:18:30 <jki> 5
13:18:33 <jki> 4
13:18:34 <jki> 3
13:18:36 <jki> 2
13:18:38 <jki> 1
13:18:40 <jki> #topic Kernel release status
13:18:48 <jki> two kernels were late...
13:19:12 <iwamatsu__> for 6.1.y, I am preparing now.
13:19:30 <pave1> 4.4-rt is late, AFAICT. Sorry for that, should be doable soon.
13:20:15 <jki> ok, all in our hand then
13:20:51 <jki> then moving on...
13:20:53 <jki> 5
13:20:55 <jki> 4
13:20:57 <jki> 3
13:20:58 <jki> 2
13:21:00 <jki> 1
13:21:01 <jki> #topic Kernel testing
13:21:08 <patersonc> Hello
13:21:22 <patersonc> Firstly, I'm sorry I didn't make it last week last minute
13:21:33 <jki> no worries
13:21:44 <patersonc> If there are any items that were raised regarding testing let me know
13:21:59 <patersonc> I should be at OSS-J next month, so not too long to wait for a F2F
13:22:44 <patersonc> Regarding updates, there aren't many. I submitted a patch to change the isar-cip-core CI a bit
13:23:14 <patersonc> Denx lava lab is down atm, hopefully back soon
13:23:39 * jki needs to go through pending isar-cip-core patches...
13:24:02 <patersonc> I don't think I have anything else my side
13:25:09 <arisut> at plumbers presentation kci-dev got presented as new feature of KenrelCI
13:26:22 <patersonc> Great
13:26:34 <jki> ah, cool - missed that, unfortunately
13:26:40 <jki> too much was going on in parallel
13:26:46 <arisut> yes
13:26:56 <arisut> actually two presentation cited kci-dev
13:28:10 <arisut> one was Interacting with kernel test results https://lpc.events/event/18/contributions/1792/
13:28:51 <arisut> the other one was Meet the new KernelCI https://lpc.events/event/18/contributions/1739/
13:29:04 <arisut> in the link there is also the pdf of the presentation
13:30:07 <arisut> development is going on, but still many work to do
13:31:11 <patersonc> Thanks Arisu-san
13:31:13 <jki> indeed - testing seems to be an infinit space from here :)
13:31:50 <iwamatsu__> Can I ask other topic for testing?
13:32:35 <iwamatsu__> patersonc: I would like to ask about BBB test for 6.1.y-cip.
13:32:56 <patersonc> I need to check that
13:33:01 <iwamatsu__> Can I enable this by fixing the problem?
13:33:13 <iwamatsu__> https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master/trees/linux-6.1.y-cip.yml?ref_type=heads#L218
13:33:35 <patersonc> Sure
13:33:46 <patersonc> Originally it wasn't booting. Never got back to fix it - sorry
13:33:53 <patersonc> We should do though
13:35:00 <iwamatsu__> OK, I will do ti. Koguchi-san asked same thing (https://lore.kernel.org/cip-dev/OS3PR01MB642161E95C3634866218A284D76A2@OS3PR01MB6421.jpnprd01.prod.outlook.com/).
13:35:16 <patersonc> Thank you Iwamatsu-san!
13:35:41 <iwamatsu__> That's all from me.
13:35:53 <iwamatsu__> :-)
13:36:53 <jki> ok...
13:37:21 <jki> anything else?
13:38:04 <jki> 5
13:38:05 <jki> 4
13:38:08 <jki> 3
13:38:09 <jki> 2
13:38:11 <jki> 1
13:38:14 <jki> #topic AOB
13:38:22 <iwamatsu__> o/
13:38:27 <patersonc> o/
13:38:38 <jki> first one first :)
13:38:43 <iwamatsu__> I would like to check the contents of the Reference HW page.
13:38:53 <iwamatsu__> Will RZ/G1M and RZ/G2M be supported in SLTS 6.1.y and 6.1.y-rt?
13:39:00 <iwamatsu__> https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/cipreferencehardware
13:39:42 <patersonc> I believe so, yes
13:40:40 <patersonc> I'm not sure why that table is blank
13:41:06 <pave1> We have same issue with other targets.
13:41:08 <iwamatsu__> OKey..., Who should I check with for BBB and DE0?
13:41:37 <iwamatsu__> About SoCFPGA, I will ask Cybertrust.
13:42:32 <jki> DE0 should remain from our perspective
13:42:44 <iwamatsu__> Not SoCFPGA, zynqmp
13:43:05 <jki> BBB is likely still one of the most accessible 32-bit arm boards
13:44:35 <iwamatsu__> I think so.
13:45:07 <iwamatsu__> Can we decide here about DE0 and BBB?  Or do we ask with TSC?
13:46:12 <jki> if more effort is related to keeping those, we should carry it to TSC
13:46:25 <jki> is there?
13:46:54 <pave1> Not really on the development side.
13:48:04 <jki> then the ball is with the testing WG ;)
13:48:54 <iwamatsu__> Yes, we run CI those  boards as well.
13:49:46 <patersonc> So no extra work really, other than making sure they are all enabled and running
13:49:56 <patersonc> (see previous topic :D )
13:50:08 <jki> perfect, then let's keep them
13:50:19 <pave1> So ... who gets to update the wiki?
13:50:30 <iwamatsu__> I will update.
13:50:36 <jki> thanks!
13:50:44 <iwamatsu__> :-)
13:50:48 <jki> good, next topic?
13:50:53 <iwamatsu__> yes, please
13:51:00 <jki> patersonc: yours?
13:51:18 <patersonc> I had a query about compiler versions/maintenance
13:51:49 <patersonc> Is CIP just making use of Debian ELTS compilers for building/maintaining the kernel?
13:52:04 <patersonc> Is there a plan for when Debian support stops?
13:52:23 <jki> would be my expectation
13:52:45 <jki> we do that in isar-cip-core at least, not sure about all other CI pipelines, though
13:53:36 <jki> why asking? already troubles with other toolchains? or just worries about what may come?
13:54:16 <patersonc> No trouble, just an internal query
13:54:59 <patersonc> Is there a requirement to stick with the same GCC version for SLTS 4.4 for example, or are we/everyone expecting it to be okay to switch to newer versions over time?
13:55:49 <uli> i'm using gcc 12.2 to compile-test 4.4. the kernel builds, haven't tried if it actually works, though.
13:56:04 <pave1> So... there's some flexibility in gcc versions, but switching to "latest" would break stuff (or at least introduce ton of warnings), I'd be afraid.
13:56:14 <jki> we are flexible in practice, yes
13:56:15 <uli> there definitely are a lot of warnings :)
13:56:26 <jki> not that we committed to anything explicitly here, though
13:56:50 <pave1> If we want to switch gcc versions, I'd guess it would be good to keep them running parallel for half-a-year-or-so,
13:57:12 <patersonc> Do we need to define somewhere what we're basing our maintenance on? Should we all be using the same? Or is it better to be flexible/varied?
13:57:32 <jki> I would expect that we avoid requiring newer compilers for older kernels, only opt-in to enable them
13:57:33 <pave1> so that we would be able to tell "this is a kernel regression" vs. "this is problem caused by new gcc".
13:58:46 <jki> ok, I have a hard cut at the hour
13:59:15 <jki> I can check again if we have written something in our wiki already, just to be sure
13:59:20 <patersonc> Thanks
13:59:27 <jki> if not, we can discuss in the next TSC if to formalize this
13:59:29 <patersonc> There's no rush on this topic
13:59:31 <jki> and how then
13:59:53 <jki> I would skip my impressions from Plumbers, maybe next week
14:00:06 <jki> anything urgent left?
14:00:21 <jki> 5
14:00:22 <jki> 4
14:00:24 <jki> 3
14:00:25 <jki> 2
14:00:27 <jki> 1
14:00:28 <jki> #endmeeting