09:00:02 <masashi910> #startmeeting CIP IRC weekly meeting
09:00:02 <brlogger`> Meeting started Thu Mar 12 09:00:02 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:02 <brlogger`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:02 <brlogger`> The meeting name has been set to 'cip_irc_weekly_meeting'
09:00:08 <masashi910> #topic rollcall
09:00:15 <pave1> hi
09:00:17 <masashi910> please say hi if you're around
09:00:18 <iwamatsu> hi
09:00:21 <wens> hi
09:00:21 <patersonc> hi
09:00:22 <fujita3> hi
09:00:39 <masashi910> #topic AI review
09:00:51 <masashi910> 1. Combine root filesystem with kselftest binary - Iwamatsu-san
09:01:04 <iwamatsu> No  update
09:01:15 <masashi910> iwamatsu: Noted. Thanks.
09:01:18 <masashi910> 2. Assign the owner of "CIP kernel config" - masashi910
09:01:27 <masashi910> At the team call on Feb. 27, I temporarily assigned this to Ben-san.
09:01:43 <masashi910> Ben-san, are you around?
09:02:08 <masashi910> Let me skip this.
09:02:17 <masashi910> 3. Refine statistics figures of Kernel Team contributions to upstream (LTS) - masashi910
09:02:27 <masashi910> Done. The updated statistics is the following:
09:02:34 <masashi910> https://docs.google.com/presentation/d/1FpE8lbaVE9ndId4Qo0mkVPppwlEM-bMGcpKeYdb3n2g/edit?usp=sharing
09:02:41 <masashi910> I think the CIP kernel team activities to contribute LTS is great!
09:03:00 <masashi910> 4. Strengthen sustainable process to backport patches from Mainline/LTS - TBD
09:03:08 <masashi910> 4-1. Workflow for identifying important fixes, backporting, and reviewing them
09:03:09 <masashi910> 4-2. Prepare the tools to be used for this workflow
09:03:09 <masashi910> 4-3. Get practice in backporting patches
09:03:16 <masashi910> An owner of this is not assigned yet, so someone should pick this up..
09:03:30 <masashi910> Can Kernel Maintainers pick them up?
09:03:54 <patersonc> o/
09:04:31 <masashi910> iwamatsu, pave1: What do you think of it?
09:04:32 <patersonc> wrt to the Kernel team contribution to LTS, is there any value in mentioning the testing of stable-rc and related bug finding that is going on?
09:04:40 <kazu> hi
09:04:47 <yoshidak[m]> hi
09:05:16 <pave1> masashi910: I can do the backporting part, I guess. Backporting is not that hard, it is just time-consuming...
09:05:27 <masashi910> patersonc: I think that is a great value, and worth mentioning that.
09:06:18 <masashi910> pave1: Thanks. You mean 4-3?
09:06:41 <pave1> masashi910: I don't foresee great improvements with practice. It just ... stays time consuming...
09:06:48 <pave1> masashi910: Yes, that would be 4-3.
09:06:58 <iwamatsu> backports can be done by everyone
09:07:43 <wens> about 4-2, we should probably ask what existing tools are available to current stable maintainers, or at least how the existing stable-queue works
09:07:43 <pave1> iwamatsu: agreed. And they may need to be done by everyone if there's significant ammount of patches to be backported.
09:08:38 <masashi910> wens: Thanks for your comments. Sasha, and Greg?
09:09:12 <wens> masashi910: mostly Greg I believe :)
09:09:43 <masashi910> wens: I see. Then, let us work on this offline. Thanks for your comment.
09:09:44 <wens> Sasha has a set of tools which are more related to 4-1, but the results vary a lot :|
09:10:22 <pave1> I don't believe we want to use Sasha's tools.
09:10:39 <punit> Having a clear criteria for what should be backported may help reduce the effort required
09:10:57 <pave1> Actually I believe easiest way to tell a bad patch is .... to grep for his name :-(.
09:11:08 <wens> based on my limited experience with stable, it's more up to the patch submitter and various subsystem maintainers to spot relevant patches
09:11:25 <pave1> But we do _not_ need to spot patches this way.
09:11:44 <pave1> Even in the unlikely case we'll have to maintain, say, 4.19...
09:11:54 <pave1> ...there will be stable team maintaining, say, 5.5.
09:12:13 <pave1> So we don't need to identify patches ourselves, we can just watch 5.5 stable queue.
09:13:02 <patersonc> Wouldn't that approach miss things that were fixed in mainline between 4.19 and 5.5?
09:13:03 <pave1> Decide if the patches are worth applying/backporting, and push those to 4.19.
09:13:08 <punit> Overtime the table queue will keep moving forward. Won't we miss patches then?
09:13:23 <punit> *stable
09:13:26 <patersonc> punit: Good point
09:13:36 <pave1> patersonc: No, it will not miss anything.
09:14:11 <masashi910> Thanks for all your comments. Let me think how we can work on 4. in general.
09:14:19 <wens> the other stable branches would be maintained after 4.19 is EOL-ed, even though just by a few years
09:14:28 <masashi910> Will come back in the future IRC meeting.
09:14:41 <pave1> We are now at 4.19.109, and 5.5.9... Fixes done in mainline between 4.19 and 5.5 are already expected to be in -stable at this point.
09:15:01 <wens> understanding how stable-queue works would help with this as well
09:15:32 <pave1> maybe we should steal time on one of those Zoom meetings for this.
09:16:13 <masashi910> All your comments are very valuable! Thanks all!
09:16:20 <masashi910> Let me move to next.
09:16:27 <masashi910> 5. Upload a guideline for reference hardware platform addition - masashi910
09:16:36 <masashi910> I will work on the draft, and ask the team for review. The draft will be coming around June.
09:16:37 <masashi910> Till then, probably I don't have much to report.
09:16:50 <masashi910> #topic kernel maintenance updates
09:17:31 <wens> three new CVEs this week, one is fixed in all relevant branches, one needs backporting to all stable branches, one is being worked on by Ubuntu kernel team
09:17:50 <iwamatsu> I reviewed 4.4.215 and 4.4.216
09:17:53 <pave1> I did reviews on 4.19.108 and .109.
09:18:00 <wens> "net: ipv6_stub: use ip6_dst_lookup_flow instead of ip6_dst_lookup" is the one that needs backporting
09:18:47 <wens> related information shows that it affects certain protocols over IPv6, which as a result don't get encrypted with IPSec
09:18:58 <pave1> I started creating 4.19-cip-rt, but hit problems on de0-nano target, and then the testing infrastructure seemed to break down completely.
09:20:55 <pave1> wens: Ok, let me take a look at "net: ipv6_stub: use ip6_dst_lookup_flow instead of ip6_dst_lookup"
09:21:08 <masashi910> pave1: Bikram-san sent a mail "Both de0-nano and IPC227E targets are up and running. I have monitored for test jobs on it and those completed successfully. "
09:21:17 <patersonc> pave1: Yea sorry about that. There have been some big connection problems at lab-cip-mentor
09:21:36 <masashi910> pave1: Do you think it fixed the issues.
09:22:11 <pave1> masashi910: Yes, I'll need to look again, I guess it should work now.
09:22:39 <masashi910> wens, iwamatsu, pave1: Thanks for your works!
09:22:48 <masashi910> any other topics?
09:22:54 <pave1> patersonc: I'd like to talk about testing some more, but perhaps that can wait to your part or after the meeting.
09:22:55 <masashi910> 3
09:22:58 <masashi910> 2
09:22:59 <wens> as for stable patches
09:23:00 <masashi910> 1
09:23:14 <masashi910> wens: Please go ahead
09:23:31 <patersonc> pave1: Sure
09:23:48 <wens> mostly just driver fixes this week. there are a few that fix NULL pointer stuff or races, but those are at the tip of the mailing list
09:24:06 <wens> I should look into improving my tooling more
09:24:24 <wens> that's it for now
09:24:31 <masashi910> wens: Thanks for your report!
09:24:40 <masashi910> So, let me move to next.
09:24:41 <masashi910> #topic Kernel testing
09:24:48 <masashi910> patersonc: the floor is yours
09:24:57 <patersonc> Thanks
09:25:02 <patersonc> I'm currently investigating an issue where multi_v7_defconfig isn't booting on the RZ/G1M platform with 4.19-stable.
09:25:11 <patersonc> As reported by Pavel there are still some Internet connection issues with lab-cip-mentor. I still haven't got around to moving the cloud storage nearer, which may help, sorry.
09:25:15 <patersonc> Mentor are also investigating the issue locally.
09:25:26 <patersonc> That's about it for updates this week. Any discussion points/queries?
09:25:33 <pave1> Yes.
09:25:43 <masashi910> patersonc: Thanks for your works!
09:25:52 <pave1> Currently we have like four states on gitlab.
09:25:56 <masashi910> Does anybody have any queries?
09:26:15 <pave1> "waiting for target", "running on target", "test passed", "test failed".
09:26:27 <patersonc> Yep
09:27:00 <pave1> Would it be possible to further distinguish between "bootloader was okay and then test failed" and "for some reason we did not even get to bootloader prompt"?
09:27:38 <pave1> Because... if target fails to boot it is not really much I can do to debug it...
09:27:39 <patersonc> Generally the cause of an "Incomplete" test is show at the top of the log.
09:27:42 <patersonc> E.g. https://lava.ciplatform.org/scheduler/job/12433
09:28:17 <pave1> The "Job error: auto-login-action timed out after 243 seconds"?
09:28:23 <patersonc> yes
09:28:36 <patersonc> Looking at the log here u-boot says it's started the Kernel but there is no output
09:29:04 <patersonc> Compared to this one: https://lava.ciplatform.org/scheduler/job/12405
09:29:09 <pave1> Ok, I can try to look into it further.
09:29:18 <pave1> But it would be really great to get different icon on the gitlab :-).
09:29:24 <patersonc> Where the issue is with the lab, and it says "infrastructure error"
09:29:45 <patersonc> Yea, I'm not sure there are many more options for GitLab yet.
09:29:48 <pave1> Currently it is like "okay" or "failed", I'd like "we don't know" icon if we hit infrastructure errors etc.
09:30:07 <patersonc> Maybe I can get better feedback in the GitLab job logs to make it clear what the failure is
09:30:24 <pave1> Let's discuss this on the mailinglist after the next round of testing...
09:30:25 <patersonc> I'll create a ticket to see what we can do
09:30:28 <patersonc> Thanks pavek
09:30:34 <masashi910> pave1, patersonc: Thanks for your discussion!
09:30:45 <masashi910> Then let me move to next.
09:31:13 <masashi910> #topic CIP Core
09:31:21 <kazu> hello
09:31:22 <patersonc> pave1: The other option is to look at the email logs sent to the cip-testing-results ML
09:31:46 <kazu> 1. Evaluation of security functions (by security WG) using CIP Core generic is on-going
09:32:03 <kazu> 2. Works to enabl SW update in CIP Core (tiny) on-going
09:32:28 <kazu> 3. Planning to use CIP Core generic userland for kenrel testing. Making the uploaded images (on S3) ready enough for that.
09:32:53 <kazu> That's all from me. Sorry that i was not able to attend the last IRC...
09:33:02 <masashi910> kazu: thank you
09:33:13 <masashi910> Does anybody have any queries?
09:33:28 <masashi910> 3
09:33:31 <masashi910> 2
09:33:34 <masashi910> 1
09:33:36 <masashi910> #topic Software update
09:33:48 <masashi910> == Quote from Suzuki-san =
09:33:53 <masashi910> I'm trying to test deby with meta-swupdate integrated by Hieu-san.
09:33:58 <masashi910> See the gitlab issue for more detail: https://gitlab.com/cip-project/cip-core/deby/-/issues/8
09:34:03 <masashi910> ====
09:34:09 <masashi910> any other topics?
09:34:18 <masashi910> 3
09:34:20 <masashi910> 2
09:34:23 <masashi910> 1
09:34:24 <masashi910> #topic Security WG update
09:34:32 <masashi910> Since this week, Yoshida-san is going to report the status of Security WG.
09:34:37 <masashi910> Yoshida-san, the floor is yours
09:34:41 <yoshidak[m]> Hi
09:34:50 <yoshidak[m]> The security working group has proceeded privately since the almost contents of discussion is according to the payed specification, but we can share discussion contents from now because we finish investigate about the spec.
09:35:06 <yoshidak[m]> In the near future, we'll update wiki as well so please wait a moment.
09:35:23 <yoshidak[m]> === this week's report ===
09:35:27 <yoshidak[m]> We plan to hold the meeting w/ Exida tonight.
09:35:36 <yoshidak[m]> At first, we need to get the cost quotation to get approve the budget, so we'll listen the content of the assessment and discuss the scope of the assessment.
09:35:45 <yoshidak[m]> The assessment won't start soon, but I report the progress sequentialy.
09:35:50 <yoshidak[m]> That's all from me this week.
09:35:57 <masashi910> Yoshida-san, thank you
09:36:13 <masashi910> Are there any queries?
09:36:27 <masashi910> 3
09:36:28 <pave1> Actually, yes.
09:36:38 <masashi910> pave1: Please go ahead
09:36:55 <pave1> Do we have some kind of list of what kind of attacks do we consider relevant?
09:37:25 <yoshidak[m]> not yet
09:37:48 <pave1> Ok, it would be good to collect that in future.
09:37:54 <yoshidak[m]> but, during the assessment, we will create the attack lists we suppose to.
09:38:04 <yoshidak[m]> pave1: Yes.
09:38:21 <pave1> Because some attacks that are relevant on the mobile phone (for example) may not be relevant with industrial systems.
09:39:07 <masashi910> pave1: Thanks for your query and comment!
09:39:44 <masashi910> yoshidak[m]: Looking forward to hearing further progresses in the future!
09:40:04 <masashi910> Any other queries?
09:40:15 <masashi910> 3
09:40:22 <masashi910> 2
09:40:25 <masashi910> 1
09:40:27 <masashi910> #topic AOB
09:40:35 <masashi910> 1. Summer Time
09:40:40 <masashi910> US summer time started on March 8. CEST starts on March 29.
09:40:52 <masashi910> This IRC meeting starts at UTC (GMT) 09:00.
09:41:07 <masashi910> This is just information.
09:41:14 <masashi910> Are there any business matters to discuss?
09:41:28 <masashi910> 3
09:41:31 <masashi910> 2
09:41:34 <masashi910> 1
09:41:36 <patersonc> So the meeting sill stick to 0900 GMT? So 0800 BST?
09:41:37 <masashi910> #endmeeting