| *** rajm has joined #cip | 07:17 | |
| wens | fyi I'm late on my cip-kernel-sec work this week | 08:30 |
|---|---|---|
| *** masashi910 has joined #cip | 08:43 | |
| *** fujita has joined #cip | 08:45 | |
| *** pave1 has joined #cip | 08:54 | |
| masashi910 | #startmeeting CIP IRC weekly meeting | 09:00 |
| brlogger | Meeting 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 http://wiki.debian.org/MeetBot. | 09:00 |
| brlogger | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 09:00 |
| brlogger | The 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 rollcall | 09:00 |
| *** brlogger changes topic to "rollcall (Meeting topic: CIP IRC weekly meeting)" | 09:00 | |
| masashi910 | please say hi if you're around | 09:00 |
| sudip | hi | 09:00 |
| pave1 | hi | 09:00 |
| wens | hi | 09:00 |
| patersonc | hi | 09:00 |
| masashi910 | Let's get started. | 09:00 |
| masashi910 | #topic AI review | 09:01 |
| *** brlogger changes topic to "AI review (Meeting topic: CIP IRC weekly meeting)" | 09:01 | |
| masashi910 | 1. Combine root filesystem with kselftest binary - iwamatsu | 09:01 |
| masashi910 | Iwamatsu-san, are you around? | 09:01 |
| masashi910 | Let's come back when he arrives. | 09:02 |
| masashi910 | Our AI is only this. So let's move on. | 09:02 |
| masashi910 | #topic Kernel maintenance updates | 09:02 |
| *** brlogger changes topic to "Kernel maintenance updates (Meeting topic: CIP IRC weekly meeting)" | 09:02 | |
| pave1 | I have reviewed 4.19.161 | 09:02 |
| *** hungtran has joined #cip | 09:02 | |
| wens | I'm still midway through my report. We got quite a few disclosures / CVE assignments from Google. | 09:03 |
| *** tpollard has joined #cip | 09:03 | |
| wens | Nine new issues, though all are fixed or have fixes queued up. | 09:03 |
| masashi910 | pave1, wens: Thanks for your works. Wens-san, I am looking forward to your report. :) | 09:04 |
| masashi910 | any other topics? | 09:04 |
| masashi910 | 3 | 09:05 |
| masashi910 | 2 | 09:05 |
| masashi910 | 1 | 09:05 |
| masashi910 | #topic Kernel testing | 09:05 |
| *** brlogger changes topic to "Kernel testing (Meeting topic: CIP IRC weekly meeting)" | 09:05 | |
| patersonc | Hello | 09:05 |
| patersonc | The security has raised a point about bug tracking | 09:05 |
| patersonc | Am I right in thinking that we don't have a formalised system in place for tracking issues found in the CIP Kernel? | 09:06 |
| masashi910 | pave1, wens: If you find any issues, are you directly sending emails to kernel mailing list? | 09:07 |
| pave1 | masashi: Yes, that's the usual way to do it in kernel. | 09:07 |
| patersonc | Security working group: Do we need to track issues more formally? | 09:08 |
| masashi910 | Pavel-san, thanks. | 09:08 |
| pave1 | And as we have mainline-first policy, the bugs we have are in mainline, too... | 09:08 |
| wens | AFAIK for build breakage the bots just send emails to the list and the person that sent out the broken patch | 09:08 |
| sudip | iiuc, 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 there | 09:09 |
| yoshidak[m] | patersonc: I think it's okay to reuse upstream tracks. | 09:10 |
| patersonc | Okay | 09:11 |
| masashi910 | Chris-san sent out the following email. | 09:12 |
| patersonc | I don't have anything else this week | 09:12 |
| masashi910 | https://lore.kernel.org/cip-dev/OSAPR01MB23853004B735A607C4BEE0C5B7F40@OSAPR01MB2385.jpnprd01.prod.outlook.com/ | 09:13 |
| patersonc | Oh yea, I forgot about that. Thanks masashi910: | 09:13 |
| masashi910 | So, currently such failures are disappeared? | 09:13 |
| pave1 | It 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 |
| masashi910 | Great! | 09:14 |
| patersonc | pave1: fetch depth is set to 10 | 09:14 |
| pave1 | patersonc: But that's still pulling whole tree, say 1GB for each test, right? | 09:15 |
| patersonc | I can't remember if it's just fetching a single branch or not | 09:16 |
| pave1 | Even single branch of kernel is ~1GB, right? | 09:16 |
| patersonc | Yea, but surely we need everything so we can compile the Kernel? | 09:17 |
| pave1 | Yeah, but we should not really pull it from the gitlab. | 09:17 |
| sudip | just for build testing fetch depth of 1 should be OK. | 09:18 |
| patersonc | I 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 instead | 09:18 |
| pave1 | patersonc: Well, it would be our infrastructure that would take the load, not gitlab's, so I believe that would be improvement. | 09:18 |
| masashi910 | patersonc, pave1, sudip: if needed, shall we follow up this topic after the meeting? | 09:19 |
| patersonc | Yes, but the docker containers are hosted in GitLab as well ;) | 09:19 |
| patersonc | masashi910: Sure | 09:19 |
| masashi910 | patersonc: Thanks for your works! | 09:19 |
| masashi910 | Are there any other topics? | 09:19 |
| masashi910 | 3 | 09:20 |
| masashi910 | 2 | 09:20 |
| masashi910 | 1 | 09:20 |
| masashi910 | #topic CIP Security | 09:20 |
| *** brlogger changes topic to "CIP Security (Meeting topic: CIP IRC weekly meeting)" | 09:20 | |
| yoshidak[m] | hello | 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 |
| masashi910 | yoshidak[m]: Thanks for your works! | 09:22 |
| masashi910 | are there any queries? | 09:22 |
| masashi910 | 3 | 09:23 |
| masashi910 | 2 | 09:23 |
| masashi910 | 1 | 09:23 |
| masashi910 | #topic AOB | 09:23 |
| *** brlogger changes topic to "AOB (Meeting topic: CIP IRC weekly meeting)" | 09:23 | |
| masashi910 | Are there any business to discuss? | 09:23 |
| masashi910 | If there are no topics, then, let's close the meeting. | 09:24 |
| masashi910 | #endmeeting | 09:24 |
| brlogger | Meeting ended Thu Dec 3 09:24:05 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 09:24 |
| brlogger | Minutes: https://irclogs.baserock.org/meetings/cip/2020/12/cip.2020-12-03-09.00.html | 09:24 |
| brlogger | Minutes (text): https://irclogs.baserock.org/meetings/cip/2020/12/cip.2020-12-03-09.00.txt | 09:24 |
| brlogger | Log: https://irclogs.baserock.org/meetings/cip/2020/12/cip.2020-12-03-09.00.log.html | 09:24 |
| *** brlogger changes topic to "Civil Infrastructure Platform Project. Find the logs at https://irclogs.baserock.org/cip/" | 09:24 | |
| masashi910 | Thank you, and stay safe! | 09:24 |
| wens | Thank you! | 09:24 |
| sudip | thanks masashi910 | 09:24 |
| yoshidak[m] | Thanks! | 09:24 |
| pave1 | Thank you! | 09:24 |
| ebardie | cheers (late arrival) | 09:24 |
| sudip | pave1: patersonc: This is the CI I run for Elisa and it just clones one branch with depth 1 - https://travis-ci.com/github/sudipm-mukherjee/linux-test/jobs/445595770#L170 | 09:24 |
| patersonc | sudip: I'll change the depth to 1. I think I just had it at 10 before so I could show the most recent log entries | 09:24 |
| wens | I will send out this week' cip-kernel-sec report momentarily | 09:25 |
| pave1 | patersonc: Fetching last commit vs. fetching last 10 commits will not really make any difference, right? | 09:25 |
| pave1 | Commits are fairly small. | 09:25 |
| patersonc | :) | 09:25 |
| masashi910 | wens: Thanks, I am looking forward to it as I mentioned earlier. :) | 09:25 |
| sudip | pave1: 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 retry | 09:26 |
| pave1 | So... when I submit a kernel for testing, that means more than 10 fetchs of full copy of kernel from gitlab server, right? | 09:27 |
| wens | masashi910: https://lore.kernel.org/cip-dev/CAGb2v65t+cryAJ+POQX74MH4st7pcf3X_WQohEWJ6j7bMVRQqg@mail.gmail.com/ | 09:27 |
| masashi910 | wens: Got it! Thanks! | 09:28 |
| patersonc | pave1: Yep. It's very inefficient. But it means we can parallelise our builds across our kubernetes cluster. | 09:29 |
| pave1 | Well, I see how gitlab may dislike that. | 09:30 |
| pave1 | It would be good to do the fetch once (and prefferably using previous tree as a base, so that only differences are transmitted)... | 09:31 |
| pave1 | But I see it may not be simple. | 09:32 |
| sudip | pave1: I just did two clones in my laptop, one with depth 1 and another depth 10. there was hardly any difference | 09:32 |
| pave1 | sudip: Agreed, that makes little difference. | 09:33 |
| pave1 | sudip: But if you do a "normal" clone, followed up by pull... having existing data already on disk helps a lot. | 09:34 |
| sudip | yes | 09:34 |
| patersonc | I'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 pod | 09:38 |
| pave1 | patersonc: If those containers are pulled from gitlab, that does not really help. | 09:39 |
| patersonc | Maybe the container download (using https?) would be quicker than the git/ssh pull? | 09:39 |
| pave1 | patersonc: Is there chance to fetch the data from some place close to the works? | 09:40 |
| pave1 | iow do we have suitable server we could use for that, without overloading gitlab? | 09:40 |
| patersonc | We'd have to mirror the git repo on another git server. The issue would be keeping them in sync quick enough. | 09:41 |
| pave1 | patersonc: I believe we should do that. | 09:41 |
| pave1 | If keeping in sync is an issue... it should be easy to fetch from our server, then fetch from gitlab. | 09:42 |
| patersonc | We'll have to experiment and see what works | 09:42 |
| pave1 | That way only small delta would go from gitlab... | 09:42 |
| pave1 | And yes, I'm afraid experiments are needed. Thanks! | 09:43 |
| masashi910 | Thanks for your follow-up discussions! I logged the discussion. Thanks! | 09:45 |
| *** samwilson_ has joined #cip | 09:46 | |
| *** hungtran has quit IRC | 09:50 | |
| *** fujita has quit IRC | 09:57 | |
| *** pave1 has quit IRC | 10:47 | |
| *** masashi910 has quit IRC | 11:13 | |
| *** monstr has joined #cip | 11:52 | |
| *** tpollard has quit IRC | 17:04 | |
| *** monstr has quit IRC | 17:56 | |
| *** samwilson_ has quit IRC | 18:00 | |
| *** toscalix has joined #cip | 19:28 | |
| *** toscalix has quit IRC | 19:30 | |
| *** toscalix has joined #cip | 19:34 | |
| *** samwilson_ has joined #cip | 20:23 | |
| *** toscalix has quit IRC | 21:44 | |
| *** samwilson_ has quit IRC | 21:57 | |
| *** rajm has quit IRC | 23:10 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!