IRC logs for #cip for Thursday, 2020-12-03

*** rajm has joined #cip07:17
wensfyi I'm late on my cip-kernel-sec work this week08:30
*** masashi910 has joined #cip08:43
*** fujita has joined #cip08:45
*** pave1 has joined #cip08:54
masashi910#startmeeting CIP IRC weekly meeting09:00
brloggerMeeting started Thu Dec  3 09:00:01 2020 UTC and is due to finish in 60 minutes.  The chair is masashi910. Information about MeetBot at
brloggerUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.09:00
brloggerThe meeting name has been set to 'cip_irc_weekly_meeting'09:00
*** brlogger changes topic to " (Meeting topic: CIP IRC weekly meeting)"09:00
masashi910#topic rollcall09:00
*** brlogger changes topic to "rollcall (Meeting topic: CIP IRC weekly meeting)"09:00
masashi910please say hi if you're around09:00
masashi910Let's get started.09:00
masashi910#topic AI review09:01
*** brlogger changes topic to "AI review (Meeting topic: CIP IRC weekly meeting)"09:01
masashi9101. Combine root filesystem with kselftest binary - iwamatsu09:01
masashi910Iwamatsu-san, are you around?09:01
masashi910Let's come back when he arrives.09:02
masashi910Our AI is only this. So let's move on.09:02
masashi910#topic Kernel maintenance updates09:02
*** brlogger changes topic to "Kernel maintenance updates (Meeting topic: CIP IRC weekly meeting)"09:02
pave1I have reviewed 4.19.16109:02
*** hungtran has joined #cip09:02
wensI'm still midway through my report. We got quite a few disclosures / CVE assignments from Google.09:03
*** tpollard has joined #cip09:03
wensNine new issues, though all are fixed or have fixes queued up.09:03
masashi910pave1, wens: Thanks for your works. Wens-san, I am looking forward to your report. :)09:04
masashi910any other topics?09:04
masashi910#topic Kernel testing09:05
*** brlogger changes topic to "Kernel testing (Meeting topic: CIP IRC weekly meeting)"09:05
patersoncThe security has raised a point about bug tracking09:05
patersoncAm I right in thinking that we don't have a formalised system in place for tracking issues found in the CIP Kernel?09:06
masashi910pave1, wens: If you find any issues, are you directly sending emails to kernel mailing list?09:07
pave1masashi: Yes, that's the usual way to do it in kernel.09:07
patersoncSecurity working group: Do we need to track issues more formally?09:08
masashi910Pavel-san, thanks.09:08
pave1And as we have mainline-first policy, the bugs we have are in mainline, too...09:08
wensAFAIK for build breakage the bots just send emails to the list and the person that sent out the broken patch09:08
sudipiiuc, CIP kernel also has few backported drivers which are not in LTS, so for them you will need to test with mainline to verify the bug exists there09:09
yoshidak[m]patersonc: I think it's okay to reuse upstream tracks.09:10
masashi910Chris-san sent out the following email.09:12
patersoncI don't have anything else this week09:12
patersoncOh yea, I forgot about that. Thanks masashi910:09:13
masashi910So, currently such failures are disappeared?09:13
pave1It seems better now. Not sure what changed.09:13
pave1(But we really should not be doing full clones from gitlab. That is uncool.)09:14
patersoncpave1:  fetch depth is set to 1009:14
pave1patersonc: But that's still pulling whole tree, say 1GB for each test, right?09:15
patersoncI can't remember if it's just fetching a single branch or not09:16
pave1Even single branch of kernel is ~1GB, right?09:16
patersoncYea, but surely we need everything so we can compile the Kernel?09:17
pave1Yeah, but we should not really pull it from the gitlab.09:17
sudipjust for build testing fetch depth of 1 should be OK.09:18
patersoncI could include the CIP repo in the docker container, but then we'd need to include the entire repo, and we'd just be pulling a large container for every build job instead09:18
pave1patersonc: Well, it would be our infrastructure that would take the load, not gitlab's, so I believe that would be improvement.09:18
masashi910patersonc, pave1, sudip: if needed, shall we follow up this topic after the meeting?09:19
patersoncYes, but the docker containers are hosted in GitLab as well ;)09:19
patersoncmasashi910: Sure09:19
masashi910patersonc: Thanks for your works!09:19
masashi910Are there any other topics?09:19
masashi910#topic CIP Security09:20
*** brlogger changes topic to "CIP Security (Meeting topic: CIP IRC weekly meeting)"09:20
yoshidak[m]We received the report of the gap assessment for IEC 62443-4-2 from Exida today.09:20
yoshidak[m]The contract will be over at the end of this month, so we'll hold a meeting with Exida and have to ask queries about contents of that report in this month.09:21
yoshidak[m]In this year, we have to focus this work, so another work, i.e. identify the requirements of development process to other working groups, will be carried over to next year.09:21
yoshidak[m]BTW, regarding development process, we interviewed Chris to sort out the current environment of testing last week.09:22
yoshidak[m]Thank you Chris.09:22
yoshidak[m]That's all from me this week. thanks.09:22
masashi910yoshidak[m]: Thanks for your works!09:22
masashi910are there any queries?09:22
masashi910#topic AOB09:23
*** brlogger changes topic to "AOB (Meeting topic: CIP IRC weekly meeting)"09:23
masashi910Are there any business to discuss?09:23
masashi910If there are no topics, then, let's close the meeting.09:24
brloggerMeeting ended Thu Dec  3 09:24:05 2020 UTC.  Information about MeetBot at . (v 0.1.4)09:24
brloggerMinutes (text):
*** brlogger changes topic to "Civil Infrastructure Platform Project. Find the logs at"09:24
masashi910Thank you, and stay safe!09:24
wensThank you!09:24
sudipthanks masashi91009:24
pave1Thank you!09:24
ebardiecheers (late arrival)09:24
sudippave1: patersonc: This is the CI I run for Elisa and it just clones one branch with depth 1 -
patersoncsudip: I'll change the depth to 1. I think I just had it at 10 before so I could show the most recent log entries09:24
wensI will send out this week' cip-kernel-sec report momentarily09:25
pave1patersonc: Fetching last commit vs. fetching last 10 commits will not really make any difference, right?09:25
pave1Commits are fairly small.09:25
masashi910wens: Thanks, I am looking forward to it as I mentioned earlier. :)09:25
sudippave1: I think it might be some problem with gitlab for fetching. I had the same problem in my CI for some time and had to add retry09:26
pave1So... when I submit a kernel for testing, that means more than 10 fetchs of full copy of kernel from gitlab server, right?09:27
masashi910wens: Got it! Thanks!09:28
patersoncpave1: Yep. It's very inefficient. But it means we can parallelise our builds across our kubernetes cluster.09:29
pave1Well, I see how gitlab may dislike that.09:30
pave1It would be good to do the fetch once (and prefferably using previous tree as a base, so that only differences are transmitted)...09:31
pave1But I see it may not be simple.09:32
sudippave1: I just did two clones in my laptop, one with depth 1 and another depth 10. there was hardly any difference09:32
pave1sudip: Agreed, that makes little difference.09:33
pave1sudip: But if you do a "normal" clone, followed up by pull... having existing data already on disk helps a lot.09:34
patersoncI'll experiment with having the repo in the container. As you say, pulling just the last few updates is a lot quicker then pulling the whole tree. Hopefully it won't take ages to download the container to each pod09:38
pave1patersonc: If those containers are pulled from gitlab, that does not really help.09:39
patersoncMaybe the container download (using https?) would be quicker than the git/ssh pull?09:39
pave1patersonc: Is there chance to fetch the data from some place close to the works?09:40
pave1iow do we have suitable server we could use for that, without overloading gitlab?09:40
patersoncWe'd have to mirror the git repo on another git server. The issue would be keeping them in sync quick enough.09:41
pave1patersonc: I believe we should do that.09:41
pave1If keeping in sync is an issue... it should be easy to fetch from our server, then fetch from gitlab.09:42
patersoncWe'll have to experiment and see what works09:42
pave1That way only small delta would go from gitlab...09:42
pave1And yes, I'm afraid experiments are needed. Thanks!09:43
masashi910Thanks for your follow-up discussions! I logged the discussion. Thanks!09:45
*** samwilson_ has joined #cip09:46
*** hungtran has quit IRC09:50
*** fujita has quit IRC09:57
*** pave1 has quit IRC10:47
*** masashi910 has quit IRC11:13
*** monstr has joined #cip11:52
*** tpollard has quit IRC17:04
*** monstr has quit IRC17:56
*** samwilson_ has quit IRC18:00
*** toscalix has joined #cip19:28
*** toscalix has quit IRC19:30
*** toscalix has joined #cip19:34
*** samwilson_ has joined #cip20:23
*** toscalix has quit IRC21:44
*** samwilson_ has quit IRC21:57
*** rajm has quit IRC23:10

Generated by 2.15.3 by Marius Gedminas - find it at!