12:03:17 <jki> #startmeeting CIP IRC weekly meeting
12:03:17 <collab-meetbot> Meeting started Thu Oct 13 12:03:17 2022 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:03:17 <collab-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:03:17 <collab-meetbot> The meeting name has been set to 'cip_irc_weekly_meeting'
12:03:25 <jki> #topic AI review
12:03:33 <jki> 1. Resolve/ignore failures of KernelCI on 4.4-cip - alicefm
12:03:43 <alicef> no news on this
12:03:58 <jki> 2. Add qemu-riscv to cip-kernel-config - patersonc
12:04:24 <patersonc[m]> Hello
12:04:29 <jki> ah, there you are
12:04:51 <patersonc[m]> Hello
12:05:04 <jki> yes, we can read you
12:05:20 <jki> we are at "Add qemu-riscv to cip-kernel-config - patersonc"
12:05:26 <patersonc[m]> I started experimenting with qemu-riscv in LAVA, but not defconfig added to cip-kernel-config yet
12:05:29 <patersonc[m]> martix bridge is being a bit slow for me today
12:05:34 <alicef> I don't think we need a AI for 1 I will just give updates on the testing meeting part when the kernelci 4.4 issues get updates
12:06:20 <patersonc> I've switched clients. Hopefully this works better.
12:06:25 <patersonc> w.r.t AI: I started experimenting with qemu-riscv in LAVA, but not defconfig added to cip-kernel-config yet
12:06:36 <jki> ok
12:07:09 <jki> regarding 1 then: is kernelci for 4.4-cip now usable for the maintainer?
12:07:40 <jki> or what do you mean with "we don't need an AI"?
12:09:36 <alicef> that we can discuss about it on the testing topic part of this meeting when there updates on 4.4-cip
12:09:54 <jki> ok
12:09:58 <jki> then move on
12:10:12 <jki> 3. Report retpoline situation and plans to TSC - jki
12:10:35 <jki> just to quickly inform you that I reported, asking for feedback, not yet receiving any negative one
12:10:49 <jki> but also no real "yeah, fully agree"
12:11:02 <jki> any other AIs?
12:11:17 <jki> 3
12:11:19 <jki> 2
12:11:21 <jki> 1
12:11:23 <pave1> I believe
12:11:32 <pave1> it will be ok.
12:11:41 <jki> I do so as well
12:11:51 <pave1> OTOH we might want to make it clear
12:12:07 <pave1> than not every hw issue can be worked around.
12:12:07 <jki> how to do that best in your opinion?
12:12:52 <jki> do we have the related fixes in a 5.10-cip release already?
12:13:09 <patersonc> Do we list the issues like retpoline that we haven't backported mitigations for? e.g. on the wiki?
12:13:35 <pave1> I assume e have it in 5.100, would have to check.
12:14:44 <jki> wiki would be good place for prominent non-fixes, otherwise our CVE tracker
12:15:02 <masami> patersonc: I like the idea.
12:15:13 <pave1> I'd suggest having a README in the source tree.
12:16:02 <pave1> This information may change with the sources, and wiki would answer uestion
12:16:31 <pave1> what is the status in HEAD, but not what was the status in this version.
12:18:01 <pave1> 'README.cip'?
12:18:29 <iwamatsu> +1 for README in source code. I think reasonable to manage of source code with the source code.
12:18:47 <patersonc> Agreed. With a link to the readme in the wiki?
12:19:02 <jki> sounds good to me as well
12:19:18 <alicef> me too
12:19:20 <jki> who will start with creating such a README first of all?
12:19:22 <pave1> I guess link is easy to do.
12:19:45 <jki> I would take over the "create the link" task then ;)
12:20:41 <pave1> Let me do it for 4.4-st.
12:21:16 <pave1> Hmm and let me decide the name, README.cip may not be suitable for 4.4-st.
12:21:53 <jki> we should find a name that is likely to remain collision-free
12:22:04 <pave1> README.st?
12:22:14 <jki> that is not very telling
12:22:25 <jki> and would not help for 4.19, would it?
12:22:56 <pave1> README.backports?
12:24:20 <jki> that sounds more like feature backports that bug-fix backports, but maybe only to me
12:25:25 <jki> do we really need the README in -st as well? in the CIP branches, a README.cip would be well placed and could explain even more
12:25:50 <pave1> We can make it KNOWN-BUGS. That will get attention :-).
12:25:55 <patersonc> It depends - if we _were_ to backport fixes for something like reptoline, would they hit -st? Or only -cip?
12:26:32 <patersonc> Although I guess the current LTS branches don't list everything they didn't backport from upstream...
12:26:55 <pave1> Backports should happen in -st, -cip is for additional features.
12:27:48 <jki> "UNFIXED-CVEs" :)
12:28:06 <pave1> Greg does not do that, true -- but their process is more open and we can do better.
12:28:29 <pave1> I'd avoid CVEs. I'd use it for regular bugs, too.
12:29:11 <pave1> Like we did not backport /dev/random rewrite. That does not have good CVE to reference.
12:29:19 <jki> ok, makes sense, but that would clearly limit the file to such a topic - fine with me as well
12:31:31 <pave1> ok.
12:31:49 * patersonc will be back in 2 mins
12:32:23 <jki> ok - anything else on this topic?
12:32:33 <jki> looks to me like we have a rough plan at least
12:33:32 <jki> 3
12:33:34 <jki> 2
12:33:36 <jki> 1
12:33:39 <jki> #topic Kernel maintenance updates
12:34:03 <uli> no reviews this week, looked into ldconfig crash on rz/five
12:34:56 <pave1> reviewing 5.10.148 and AUTOSEL patches.
12:34:57 <masami> This week reported 4 new CVEs and 1 updated CVEs. new CVEs are not critical issue.
12:35:01 <iwamatsu> I did not review for 5.10.y tree.
12:37:43 <jki> anything else here?
12:39:00 <jki> 3
12:39:02 <jki> 2
12:39:04 <jki> 1
12:39:15 <jki> #topic Kernel testing
12:39:37 <alicef> no news from me this time
12:39:51 <patersonc> I've added support to build risc-v in our GitLab CI setup. This MR needs to go through to enable builds: https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/merge_requests/32
12:40:17 <patersonc> I've also added GitLab CI support for our -st branch. See patch on cip-dev
12:40:46 <patersonc> I'm also debugging some remaining issues with our gitlab-runners
12:41:21 <pave1> ci support for -st. That would certainly make my life easier.
12:41:58 <patersonc> risc-v MR is targeting defconfig on 5.10-stable-rc and 5.10-cip. if everyone is happy with that I'll merge
12:42:16 <patersonc> Or we can hold off until we "officially" support risc-v
12:42:17 <pave1> It kind of ''does not belong there' because -st tree is upstream and this is -cip specific... but I guess we can do that.
12:42:45 <jki> well, what is missing for "official" support?
12:43:03 <patersonc> pave1: Yea, that's the reason I hesitated with st support
12:43:15 <iwamatsu> patersonc: I will review it if necessary.
12:43:19 <patersonc> jki: Nothing for building I guess. Testing needs work
12:44:52 <jki> ok
12:44:54 <alicef> we should enable -st also on kernelci
12:45:05 <patersonc> yea
12:46:42 <jki> any other testing topics?
12:47:07 <pave1> -st on kernelci -- we don't need it till 4.4 is clear of false-positives.
12:47:39 <pave1> I don't know how precious their cpu resources are...
12:47:49 <patersonc> jki: Nope
12:47:54 <jki> so AI #1 is still valid...`
12:48:32 <alicef> ?
12:49:29 <jki> AI 1 is about resolving false-positives for 4.4, at least 4.4-cip, in kernelci
12:50:45 <alicef> I see ok
12:51:43 <jki> alicef: can you help moving this forward, or does someone else need to look into that?
12:52:26 <alicef> I have no problem if someone can help out
12:53:22 <jki> I can ask Florian again
12:53:56 <alicef> ok
12:54:01 <jki> move on?
12:54:21 <alicef> yes
12:54:41 <jki> #topic AOB
12:54:51 <jki> I have one topic, more a reminder
12:55:20 <jki> I already mailed to the maintainers that we need to provide an effort estimate for next year
12:55:48 <jki> if (likely yes) and how much we need to ramp up the maintenance efforts
12:56:14 <jki> I need your input here, otherwise there will be no extra budget planned for now
12:57:03 <jki> rough estimates are fine
12:57:40 <pave1> I believe I sent a reply over email.
12:58:17 <jki> right, but maybe you can also help together with uli to answer the other half
12:59:07 <uli> i don't really have a good grasp on how much effort 4.4 is in total, i think pave1 needs to answer that
13:00:19 <jki> please, you two, "sit" together and try to figure this out
13:00:27 <jki> I can join if it may help :)
13:02:18 <pave1> Ok. I'd say it is low compared to the reviews, but it is maybe 4 times more work than doing releases on other branches.
13:02:49 <jki> 4*x = y
13:02:55 <pave1> And we have been lucky so far and only did very little backporting.
13:02:58 <jki> still two variables ;)
13:03:50 <pave1> Ok so... Id count 2 hours for 5.10-rt release.
13:04:57 <pave1> And maybe 2 hours a week for 4.4x maintainence.
13:05:48 <pave1> It is more like 16 hours every two months when the release cycle gets quiet.
13:06:13 <jki> uli: does this help to get a feeling? please share it with me once you got it. with same safety margine for raming up
13:07:01 <uli> yeah, i think that helps already
13:07:38 <pave1> What do we do with 4.4-rt?
13:08:30 <jki> was for me in the package, to free more time for you - or does it come with different variables?
13:09:46 <pave1> Ok works for me. So far I did not have to do any work there as there were no -rt speciic changes in 4.9-rt.
13:09:58 <pave1> So that's kind of terra incognita.
13:11:47 <jki> uli: works for you as well?
13:12:05 <uli> i think so
13:13:30 <jki> ok, great
13:13:53 <jki> anything else for today?
13:14:29 <jki> 3
13:14:31 <jki> 2
13:14:33 <jki> 1
13:14:35 <jki> #endmeeting