13:03:05 #startmeeting CIP IRC weekly meeting 13:03:05 Meeting started Thu Jun 13 13:03:05 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:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:03:05 The meeting name has been set to 'cip_irc_weekly_meeting' 13:03:12 #topic AI review 13:03:17 - prepare blog entry on SLTS kernel state and challenges [Jan] 13:03:27 no news, unfortunately 13:03:55 I've nothing more recorded otherwise 13:04:09 5 13:04:10 4 13:04:11 3 13:04:12 2 13:04:14 1 13:04:15 #topic Kernel maintenance updates 13:04:26 I was reviewing 6.1.93. 13:04:31 i've been reviewing 6.1.93 13:04:32 This week reported 8 new CVEs and 4 updated CVEs. 13:04:46 I reviewed 6.1.93. 13:06:17 anything else? 13:06:47 8 CVEs sound like vacation phase 13:07:15 Yeah, we'll just get 196 next week :-). 13:07:34 5 13:07:36 4 13:07:38 3 13:07:40 2 13:07:41 1 13:07:44 #topic Kernel release status 13:07:52 4.4 is late 13:08:01 there were concerns about the quality of a patch 13:08:08 so pave1 suggested to wait for the 4.19 release 13:08:14 but that release hasn't come so far 13:08:23 i'm inclined to drop the patch and move on 13:08:29 Yeah. I don't believe we should be basing our releases on 4.19-rc. 13:08:47 which patch in particular? 13:08:52 x86/insn: Fix PUSH instruction in x86 instruction decoder opcode map 13:09:22 4.19.316-rc1 is out, so I expect 4.19.316 in few days. 13:09:22 stable doesn't have a schedule; we do 13:10:04 I mean -- there's not neccessarily anything wrong with the named patch, 13:10:18 but if it was not yet released in part of 4.19.x, we should not be releasing it. 13:11:02 that makes it impossible to relese anything on time 13:11:09 No, why? 13:11:13 i've been basing almost every release so far on an rc 13:11:20 Don't :-). 13:11:20 because the release doesn't happen when we need it 13:11:43 Just take patches from latest version than happen, and ignore anything newer. 13:12:08 that's an option 13:12:18 Patches that are not in in 4.19.x are straight from mainline, and untested. 13:12:18 but introduces quite some latency 13:12:41 They may be completely bogus, breaking build, etc. 13:12:52 Yes, I believe we should live with latency. 13:13:15 Mainline stuff gets applied to queue-4.19. Then -rc1 comes 13:13:26 people test that, and bad patches are dropped. Then we get 4.19.x 13:13:39 We should ignore everything before it gets to 4.19.x 13:13:53 ok, i can live with that. 13:14:25 unless it looks very critical - but that requires special handling anyway 13:14:45 Yep. 13:14:58 and when things do get very critical, we do get -stable releases, anyway. 13:15:28 i can do that from now on. 13:15:34 good 13:15:35 Thank you :-). 13:15:52 then 4.4 will come soon 13:15:57 yep. 13:15:58 With this one, 4.19.316 should happen around Monday, so it might be easy to just wait. 13:16:16 (And verify the patches are still there in the release). 13:16:32 Or we can stash them and reapply after the release. 13:16:56 i can wait until monday night, and if there isn't anything yet, i'll release base on .315 13:17:02 *based 13:17:41 good, moving on... 13:17:43 5 13:17:45 4 13:17:47 3 13:17:50 2 13:17:50 Works for me. "Sat, 15 Jun 2024 11:31:50 +0000." is the date Greg quoted for 4.19.316. 13:17:59 1 13:18:02 ok 13:18:13 #topic Kernel testing 13:18:35 no news afaik 13:18:39 jki: Are there any updates for the Siemens LAVA lab? 13:19:08 looks still down from last time I checked 13:19:23 nope, but our team was on a Retreat (partial excuse) 13:19:37 Okay 13:21:06 I'm not sure I have any news this week 13:21:36 anything else on testing? 13:22:04 5 13:22:06 4 13:22:08 3 13:22:09 2 13:22:11 1 13:22:14 #topic AOB 13:22:27 I'll be travelling for two weeks starting Jun 24. 13:22:38 I will be absent from the next meeting and the one after that. 13:22:50 ok 13:23:18 I will absent next meeting 13:23:39 There's Linux RT meeting at Jun 26; not sure if I can make it there. 13:23:51 I should be there 13:24:14 can wear both hats this time 13:24:34 Iwamatsu-san also has our hat :-). 13:25:10 yes :) 13:25:15 does that time slot fit you? 13:26:02 it is no problem. 13:26:09 ok, fine 13:26:56 something else: we discussed internally to look into the topic of mapping CVEs (via commits) on kernel configs 13:27:18 is anyone aware of preexisting public approaches? 13:29:02 seems not :) 13:29:12 So in git@gitlab.com:cip-project/cip-kernel/lts-commit-list.git 13:29:19 we have bin/commit.py. 13:29:38 That computes "relevant" for a commit based on source file list. 13:29:42 https://events.linuxfoundation.org/archive/2022/open-source-summit-japan/program/schedule/ 13:29:58 And we generate source file lists manually from our configs from time to time. 13:30:01 title "Config based CVE matching for 13:30:01 Linux kernel" 13:30:18 We use that for reviews. 13:30:20 found it - thanks! 13:30:49 koverage command in kmax repo looks helpful. https://github.com/paulgazz/kmax 13:32:47 I think it would be good for us to execute automated mapping (as far as possible) for incoming CVEs as well as config changes 13:33:18 we may have some time to try out something and then discuss further 13:35:27 ok - anything else? 13:36:14 5 13:36:16 4 13:36:17 3 13:36:19 2 13:36:20 1 13:36:22 #endmeeting