13:00:47 #startmeeting CIP IRC weekly meeting 13:00:47 Meeting started Thu Mar 24 13:00:47 2022 UTC and is due to finish in 60 minutes. The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:47 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:47 The meeting name has been set to 'cip_irc_weekly_meeting' 13:00:47 Meeting started Thu Mar 24 13:00:47 2022 UTC and is due to finish in 60 minutes. The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:47 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:47 The meeting name has been set to 'cip_irc_weekly_meeting' 13:00:51 hi all 13:00:55 hello 13:00:58 hi 13:00:59 Hello 13:00:59 hello 13:01:03 hi 13:05:06 ok, test crew still missing, but let's get started anyway 13:05:24 #topic AI review 13:05:34 1. Resolve/filter irrelevant failures of KernelCI for 4.4-cip - patersonc & alicefm 13:05:48 no one around to answer this, I assume 13:06:21 other AIs? 13:06:41 3 13:06:43 2 13:06:45 1 13:06:47 #topic Kernel maintenance updates 13:07:13 I have reviewed patches for 5.10.108. 13:07:15 reviewed 5.10.106 13:07:18 This week reported 8 new CVEs. 13:07:38 They are not so critical vulnerability. 13:07:50 I reviewed 5.10.108. 13:08:30 I did work on 4.4-stable branch. It should be up-to-date with 4.9.305, and I believe we should do a -cip release to get more eyes on it and test the process. 13:09:03 sounds good to me 13:10:19 I do believe we should trim down kernel configs. There's a lot of stuff that does not make sense because someone copied defconfig, and we have enabled it as modules. 13:10:52 how to approach that? 13:10:55 pave1: I also replied to your email, do you have any thoughts on the -st tree release tags? 13:11:59 jki: Dunno. Ask for explanation for things that look unneeded in the config, and disable option if explanation is not given? 13:12:35 jki: Other possibility would be to ask if we have tests to cover specific config option, and disable it if not. 13:13:42 I'm afraid the test coverage widely relies on kernelci & Co. 13:14:05 iwamatsu: I have added localversion-st to the -st tree. You probably want to remove that before releasing -cip. 13:14:06 what worked best so far was asking if certain switches could be dropped 13:15:05 jki: I'm pretty sure kernelci does not have the crazier options enabled. 13:16:00 make it concrete, then we can iterate over that 13:16:23 jki: But yes, we can continue asking. See the ...Disabling XEN in our configs (used by QEMU and Rene... thread on cip-members. 13:17:19 jki: I guess I'd like to get consensus that yes, we need configuration to be trimmed down, that it is okay to do and that we'll continue doing it. 13:17:54 I wouldn't disagree with that 13:18:23 I can add this as an item to present /remind folks of on our ext-TSC agenda 13:18:48 jki: Good :-). Can you state that on the members list? I don't feel comfortable arguing there. 13:19:26 pave1: Well, are you planning to tag the linux-4.4.y-st tree for release? For example linux-4.4.y-st-st5. 13:19:27 jki: But maybe ext-TSC agenta makes sense, too. 13:19:55 pavel: we can do both, but let's start with that meeting 13:20:04 jki: Ok, thanks! 13:20:32 iwamatsu: Yes, I guess I should do the tags, too. 13:20:58 iwamatsu: I propose tagging it as "v4.4-st5" ...? 13:21:50 Is my IRC broken? Or has this meeting stalled? 13:21:59 pave1: I got it. I think it will probably be such a tag. 13:22:18 Ok. Let me do tags in v4.4-stX form. 13:22:26 thank you! 13:22:43 patersonc[m]: i think it's your irc 13:22:57 Hi 13:23:13 Same here 13:23:17 (To be clear. I'll do v4.4-st5, not v4.4.302-st5, as .302 would just be repeated everywhere). 13:24:28 PatersonMatrix bridge is stalled 13:25:32 how would 4.4-cip be tagged, what numbers will be incremented there? 13:25:53 I guess I'll also do -st-next as doing development on -st branch is confusing. 13:26:24 jki: I thought it would be v4.4-cipX or v4.4.302-cipX. 13:27:16 can be risky to change the naming scheme 13:27:19 Or -st-rc? 13:27:31 so the second option might be safer 13:27:32 To follow the same convention as other cip branches 13:27:45 -st-rc works for me, too. 13:28:18 jki: Yes, I guess we can stay with v4.4.302-cipX. 13:29:22 hmm, what should we do with the CIP release tag? v4.4-st5-cip69? 13:29:52 iwamatsu: I'd just tag it as v4.4.302-cipX. 13:30:36 iwamatsu: If someone wants to know what -stX it is based on, it will be in git history. 13:31:21 continuity, also in naming 13:33:21 ok, further topics here? 13:33:41 If we want to release it, merge -st tree into -cip tree and set the tag to 4.4.302-cipX+1. is this correct understanding? 13:34:09 iwamatsu: Correct, AFAICT. 13:34:17 pave1: OK 13:34:48 (You'll need to delete localversion-st, so that we get correct version info). 13:35:29 Yes, I think so. 13:36:46 so... moving on in... 13:36:50 3 13:36:53 2 13:36:55 1 13:36:58 #topic Kernel testing 13:38:13 patersonc[m]: do we have news on the AI? 13:39:27 The pull request i sent about preempt rt as been updated and take over with Guillermo 13:40:15 With Gtucker pull request 13:40:23 alicef: what was that about? 13:41:09 Adding preempt rt test on KernelCI 13:41:24 Also for cip rt branches 13:41:32 ah, great 13:42:45 https://github.com/kernelci/kernelci-core/pull/1094 - right? 13:43:35 Yes that's it 13:44:40 how sophisticated are rt tests in kernelci already? 13:45:30 What do you mean by sophisticated? 13:46:21 what do they run, roughly, for how long? already recording latencies or "just" stability topics? 13:48:20 "it's fine if it boots" is surely not enough here ;) 13:50:12 They use rt-test and do some round of cyclic test 13:50:48 cyclictest measures event latency in Linux kernel by 13:50:48 measuring the amount of time that passes between when a timer 13:50:48 expires and when the thread which set the timer actually 13:50:48 runs. 13:51:03 yes, sure 13:51:21 but you need to run that longer than usual tests, you need to run stress in parallel 13:51:36 and we eventually also need an I/O loop test 13:51:48 cyclictest is kind of default for realtime testing, yes. 13:51:52 And it is a bit of art: 13:52:09 I'm asking as I could try to push that topic via some colleagues, looking into status quo and possible improvements 13:52:29 a) Not all systems are suitable; you'll get failures on many machines because firmware is broken. 13:52:43 b) You have to load system a bit, but not unrealistically so. 13:53:17 https://github.com/kernelci/kernelci-core/issues/474 13:53:25 "a bit" is relative to what you want to show - usually, you load a lot 13:53:37 Is the discussion about rt tests implementation 13:53:38 and vary that 13:54:50 jki: Well, you want to test basic functionality. You don't want to test OOM killer and serial console, for example. 13:55:32 pavel: if you want to test out numbers, you need to do more than that 13:55:46 We are adding what is used on mainline to cip 13:55:49 pavel: for basic stability tests, that is fine, yes 13:56:11 that is definitely a valuable start! 13:58:32 Maybe write in the KernelCI pr or open a new issue if there are suggestions 13:59:04 sure, will do - need an overview first 13:59:32 other testing topics? 14:00:09 Not that I know about. 14:00:37 then move on in 14:00:40 3 14:00:42 2 14:00:44 1 14:00:47 #topic AOB 14:01:08 I would need a substitute next Thursday (OOO) 14:02:58 I asked patersonc[m] if he can help out with the already opened KernelCI pr as I'm busy in this days. 14:04:47 If anyone is interested or want to help out this is the current KernelCI situation on cip https://github.com/orgs/kernelci/projects/11 14:06:15 jki: I guess I can send the email and operate the chatbot. 14:06:20 jki: Is anything else required? 14:06:48 pavel: that should be enough, TIA! 14:06:55 jki: No problem :-). 14:08:49 ok - anything else for today? 14:09:07 3 14:09:09 2 14:09:11 1 14:09:12 #endmeeting