12:01:00 <pave1> #startmeeting CIP IRC weekly meeting
12:01:00 <collab-meetbot`> Meeting started Thu Jul 14 12:01:00 2022 UTC and is due to finish in 60 minutes.  The chair is pave1. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:01:00 <collab-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:01:00 <collab-meetbot`> The meeting name has been set to 'cip_irc_weekly_meeting'
12:01:27 <pave1> Hi! And say hi if you are around.
12:01:33 <uli> hello
12:01:35 <masami> hi
12:01:43 <alicef> hi
12:01:44 <flo2> Hi!
12:02:28 <pave1> Hello, Florian. Nice to meet you!
12:03:16 <pave1> I'd like iwamatsu and patersonc...
12:04:44 <alicef> oh right, maybe wait some more time ?
12:05:06 <alicef> jki is not here today ?
12:05:34 <alicef> hello patersonc[m] iwamatsu
12:06:06 <pave1> jki said he may not be able to make it.
12:06:22 <alicef> I see. thanks for chairing today
12:06:27 <pave1> :-)
12:06:38 <alicef> :D
12:06:52 <pave1> Let's start.
12:06:59 <pave1> #topic AI review
12:07:03 <alicef> yeah
12:07:08 <pave1> 1. Resolve/ignore failures of KernelCI on 4.4-cip - alicefm
12:07:25 <alicef> I replay to your mail. I hope you have see it :)
12:07:34 <alicef> replayed
12:07:48 <alicef> I see flo2 replay
12:07:57 <pave1> Yes. I also seen flo2 starting to work on that.
12:08:13 <flo2> jki asked me to have a look.
12:08:19 <alicef> yes, unfortunatly kernelci is just keeping 28days of logs
12:08:28 <alicef> and that is 4TB
12:08:46 <flo2> No active working yet, but starting to get in touch with kernelci and the build/test configuration
12:09:21 <pave1> alicef: Yes, that's one of the problems. I wonder if having logs per-project would make sense? I don't believe we produce that much of logs.
12:09:52 <pave1> flo2: Thank you.
12:10:14 <alicef> pave1: we can make some change in the cleaning logs script specifically for CIP
12:10:15 <pave1> flo2: For the record, lot of kernelci messages can be found in cip-dev mailing list logs.
12:11:09 <alicef> pave1: how much time would make sense?
12:11:33 <flo2> Could someone ACK that it should be possible to trigger cip builds (on staging) by pushing to the kernelci repository by opening a merge request?
12:12:09 <alicef> flo2: merge request to what kernelci repository?
12:12:16 <pave1> alicef: We'd need like 3 months, I'm afraid. We are moving quite slowly.
12:12:18 <alicef> kernelci-core ?
12:12:32 <flo2> Yes, I think it was kernelci-core...
12:12:44 <alicef> flo2: yes that's correct
12:13:15 <pave1> flo2: I think I can trigger build by doing push to test tree. Also -st-rc is currently ahead of -st, I guess I can use that to trigger build.
12:13:21 <pave1> flo2: Should I/
12:13:22 <pave1> ?
12:13:58 <alicef> pave1: As I wrote in the mail, yes you can trigger rebuild on your test tree.
12:14:54 <alicef> pave1: I will look about giving 3 months of logs
12:14:58 <flo2> At least one recent build (that is expected to fail) would help to check which tests we should exclude for now
12:15:45 <alicef> to cip builds on linux.kernelci.org
12:16:23 <alicef> flo2: I have triggered the test, it takes sometime for the results as I triggered it on every laboratory
12:17:24 <pave1> flo2: I have updated 4.4.y-cip. That should do the trick.
12:17:30 <pave1> 3
12:17:32 <flo2> Thanks!
12:17:37 <alicef> pave1: could you open a issue on kernelci-core about the logs or I should do by myself? both is not problem
12:17:46 <alicef> just for keeping track of it
12:17:56 <pave1> alicef: Please do.
12:18:02 <alicef> ok
12:18:09 <pave1> Thank you!
12:18:16 <pave1> 3
12:18:17 <pave1> 2
12:18:19 <pave1> 1
12:18:23 <alicef> pave1: anything other about this?
12:18:52 <pave1> I guess flo2 is looking into that, so I'm happy :-).
12:18:53 <alicef> flo2: here is last cip 4.4 build https://staging.kernelci.org/job/cip/branch/linux-4.4.y-cip/
12:18:59 <alicef> builded now
12:19:19 <pave1> 2. Check cip devices on kernelci old pull request - patersonc
12:19:30 <pave1> Patrsonc is not around here. Skip?
12:19:45 <alicef> patersonc[m]
12:19:59 <alicef> I think patersonc is not pinging patersonc[m]
12:20:29 <alicef> usually tab should autocomplete the name
12:20:44 <alicef> but depend from your client
12:21:14 <alicef> :)
12:21:16 <pave1> I'm not sure how pinging is supposed to work, but it seems he is not here. I don't think my client supports that.
12:21:33 <pave1> 3. Update https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/cipreferencehardware - iwamatsu-san
12:22:24 <pave1> iwamatsu does not seem to be here, either.
12:22:28 <pave1> Anything else?
12:22:46 <alicef> not from me.
12:22:50 <pave1> 3
12:23:03 <pave1> 2
12:23:08 <pave1> 1
12:23:10 <alicef> I think we are only in 3 today
12:23:32 <alicef> 5 sorry
12:23:38 <pave1> #topic Kernel maintenance updates
12:23:42 <pave1> 5 is the right number.
12:24:06 <alicef> we already discussed on the AI of 4.4
12:24:17 <pave1> I'm reviewing 5.10.130/131 and did some work moving 4.4 forward.
12:24:19 <alicef> I discussed with kernelci about your issues
12:24:25 <uli> reviewed 4.4 backports, now reviewing 5.10.131
12:24:27 <masami> There was 8 new CVEs and 8 updated CVEs.
12:24:36 <masami> Luckly, Retbleed's CVSS score isn't high.
12:26:34 <pave1> masami: retbleed is currently being reviewed as part of 5.10.131 ... AFAICT. There's also something called straight-line-speculation, mixed in to make it more fun.
12:26:58 <pave1> uli: Thanks!
12:27:08 <uli> np
12:27:29 <masami> pavel: such bugs are so bad :(
12:27:32 <pave1> I'll be on holidays, likely w/o internet next week.
12:29:14 <pave1> masami: Yes. Basically advantage of x86 is that it is backward compatible. Except that it is not compatible if you care about security.
12:29:47 <pave1> masami: People should really avoid out-of-order CPUs when security is needed.
12:30:26 <masami> pavel: that's true.
12:30:33 <alicef> is also really expensive to mitigate retbleed
12:31:02 <alicef> in term of overhead
12:31:34 <alicef> between 14% and 39% overhead
12:31:45 <pave1> Hmm. 14%..39% :-(. Fortunately kernel is usually smart part of total workload.
12:32:07 <pave1> Otoh this probably affects more than kernel. Fun.
12:32:15 <alicef> it also involve changes to 68 files ...
12:32:53 <pave1> At some point we'll boot qemu on bare metal, just to emulate bug-free CPU :-).
12:32:55 <alicef> that's a big backporting
12:33:59 <pave1> And backporting may be easy compared to testing a) it still works and b) it really fixes the problem.
12:34:20 <pave1> Anything else here?
12:34:25 <pave1> 3
12:34:39 <pave1> 2
12:34:47 <pave1> 1
12:35:00 <pave1> #topic Kernel testing
12:35:07 <pave1> alicef> we already discussed on the AI of 4.4
12:35:12 <pave1> alicef> I discussed with kernelci about your issues
12:35:15 <pave1> Thank you!
12:35:18 <pave1> Anything else?
12:35:26 <alicef> yes sorry I miss read maintainenance with testing
12:35:35 <alicef> and started to write
12:35:50 <pave1> Yes, it took me few seconds but I figured it out :-).
12:35:56 <pave1> 3
12:35:57 <uli> i only figured that out now :)
12:36:01 <pave1> 2
12:36:08 <pave1> 1
12:36:09 <alicef> I disscussed your issues with kernelci and will figure it out
12:37:34 <pave1> Thank you. I'm still not sure our testing needs are good fit for kernelci, but as long as gitlab testing works, additional testing should not hurt.
12:38:07 <pave1> 3
12:38:10 <pave1> 2
12:38:13 <pave1> 1
12:38:21 <pave1> #topic AOB
12:38:25 <alicef> why you think we are not good fit for kernelci?
12:39:16 <pave1> With 4.4 backports, I basically apply a patch and need to see if it builds etc.
12:40:15 <pave1> (For automatically-applied patches, I simply apply whole batch, but for manual backports, I see enough errors that batching does not make sense).
12:40:40 <pave1> So it is ... say 15 minutes backporting, submit for a test, fix it up for next one, submit for a test.
12:40:59 <pave1> That's quite a high load and I need the results quite fast.
12:42:49 <alicef> currently KernelCI is building CIP for many boards and configurations, that could be blocklisted.
12:43:51 <alicef> Also KernelCI is currently working on many changes for new KernelCI tools.
12:45:06 <alicef> and creating a new version of KernelCI
12:45:54 <alicef> I understand that gitlab is more fast currently but is also testing in few boards
12:46:14 <alicef> fewer
12:46:30 <pave1> I guess we should let flo2 do the work, then we can time how long it takes kernelCI to do the tests and if it is suitable replacement for gitlab testing.
12:47:05 <pave1> Yes, gitlab runs on fewer boards, and also (AFAIK) we pay for builders so it is okay if we use it a lot.
12:47:45 <alicef> your developer branch for kernelci is too slow?
12:48:13 <pave1> I have not really timed it yet, but I assume it will not be 15 minutes?
12:48:18 <alicef> maybe we can make many blocks on your developer branch and enable only few boards for having results faster
12:48:33 <alicef> if that is better for you
12:48:54 <pave1> That may make sense if we want to replace gitlab at some point.
12:49:31 <alicef> I doubt that paying gitlab give you the same bords that KernelCI is using for building (I could be wrong)
12:50:47 <pave1> I don't really know. I guess we can discuss after flo2 makes the results useful.
12:50:59 <alicef> pave1: sure
12:51:05 <pave1> Anything else?
12:51:37 <pave1> 5
12:51:39 <pave1> 4
12:52:02 <pave1> 3
12:52:02 <pave1> 2
12:52:03 <pave1> 1
12:52:12 <pave1> #endmeeting