| *** helmut has quit IRC | 06:04 | |
| *** helmut has joined #cip | 06:07 | |
| patersonc | iwamatsu: ping | 06:56 |
|---|---|---|
| *** toscalix has joined #cip | 08:01 | |
| *** tpollard has joined #cip | 08:33 | |
| *** masashi910 has joined #cip | 08:51 | |
| patersonc | Where are the minutes from last week's meeting? | 08:51 |
| *** masashi910 has quit IRC | 08:55 | |
| *** masashi910 has joined #cip | 08:56 | |
| *** iwamatsu_ has joined #cip | 08:58 | |
| *** suzuki26 has joined #cip | 08:59 | |
| szlin | #startmeeting CIP IRC weekly meeting | 09:00 |
| brlogger` | Meeting started Thu Oct 10 09:00:04 2019 UTC and is due to finish in 60 minutes. The chair is szlin. 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 | |
| szlin | #topic rollcall | 09:00 |
| *** brlogger` changes topic to "rollcall (Meeting topic: CIP IRC weekly meeting)" | 09:00 | |
| szlin | please say hi if you're around | 09:00 |
| *** kazu has joined #cip | 09:00 | |
| patersonc | hi | 09:00 |
| masashi910 | hi, this is kudo | 09:00 |
| *** pave11 has joined #cip | 09:00 | |
| kazu | hi | 09:00 |
| suzuki26 | hi | 09:00 |
| pave11 | hi | 09:00 |
| iwamatsu_ | hi | 09:00 |
| fujita[m] | hi | 09:00 |
| szlin | #topic AI review | 09:01 |
| *** brlogger` changes topic to "AI review (Meeting topic: CIP IRC weekly meeting)" | 09:01 | |
| szlin | 1. Provide the cases to cip-testing to build up the test environment - Iwamatsu-san | 09:01 |
| wens | hi | 09:01 |
| szlin | iwamatsu_: do you have any update on this topic? | 09:02 |
| iwamatsu_ | szlin: this does not finished yet, patersonc and I discuss about this yet. | 09:02 |
| szlin | iwamatsu_: thank you for the update. | 09:03 |
| szlin | 2. Test LTS (pre)releases directly – patersonc | 09:03 |
| patersonc | I haven't done anything on this topic this week. | 09:03 |
| szlin | patersonc: got it, thanks. | 09:04 |
| szlin | 3. Review the proposal from Kudo-san - Kernel team | 09:04 |
| szlin | masashi910: do you have any update on this topic? | 09:04 |
| masashi910 | I don't have updates, but I would like to get opinions. | 09:05 |
| masashi910 | There were mainly two comments at the TSC meeting. | 09:05 |
| masashi910 | The first one is to get Xilinx management and engineers involved. | 09:06 |
| masashi910 | The discussion already started thanks to Jan-san. So this is ok for now. | 09:06 |
| masashi910 | The second one is whether the target should be added as CIP reference platform. | 09:07 |
| masashi910 | There are pros and cons if we do so before Xilinx guys participation in CIP. | 09:08 |
| masashi910 | I would like to know kernel team's opinion on this. | 09:08 |
| patersonc | Can you link me to the board details please? | 09:09 |
| patersonc | Is the board a different arch etc. to our other reference platforms | 09:10 |
| patersonc | ? | 09:10 |
| masashi910 | patersonc: for example, how about this? https://www.digikey.jp/catalog/ja/partgroup/xilinx-zynq-ultrascale-mpsoc-zcu102-evaluation-kit/68042 | 09:12 |
| patersonc | Thanks masashi910 | 09:12 |
| masashi910 | The board is based on v8, and it has FPGA. | 09:12 |
| patersonc | So is it likely that Xilinx would join the CIP project as a member? Or are you proposing this board as a reference board from your company? | 09:14 |
| szlin | ok, let's discuss it after the meeting. | 09:14 |
| patersonc | szlin: Okay | 09:14 |
| szlin | Update the status first :-) | 09:14 |
| masashi910 | OK | 09:14 |
| szlin | masashi910: is that ok for you? | 09:14 |
| szlin | thanks | 09:14 |
| szlin | #topic Kernel maintenance updates | 09:14 |
| *** brlogger` changes topic to "Kernel maintenance updates (Meeting topic: CIP IRC weekly meeting)" | 09:14 | |
| pave11 | I have reviewed 4.19.77, 4.19.78. | 09:14 |
| szlin | I'm preparing the kernel team slide for ELCE 2019, and looking for presenter in CIP semi-summit. | 09:15 |
| szlin | pave11: thank you. | 09:15 |
| iwamatsu_ | szlin: I reviewed v4.4.194 and v4.4.196 | 09:15 |
| szlin | any other topics? | 09:16 |
| iwamatsu_ | And pave1 and I reviewed patches from Renesas. | 09:16 |
| szlin | iwamatsu_: thank you! | 09:16 |
| szlin | 3 | 09:16 |
| szlin | 2 | 09:16 |
| szlin | 1 | 09:16 |
| szlin | #topic Kernel testing | 09:16 |
| *** brlogger` changes topic to "Kernel testing (Meeting topic: CIP IRC weekly meeting)" | 09:16 | |
| patersonc | #info Iwamatsu-san has submitted a MR to add LTP tests to linux-cip-ci. It's not merged yet as we're just deciding the best approach. | 09:16 |
| patersonc | #link https://gitlab.com/cip-project/cip-testing/linux-cip-ci/merge_requests/24 | 09:17 |
| patersonc | #info A complete LTP test run takes about 3 hours per board, per config. So we need to reduce the amount of test cases (not ideal), or add more boards to the labs. | 09:17 |
| patersonc | #info We're also debating whether to change the GitLab pipeline setup so it doesn't wait for jobs to complete running - it just submits them. The plan being that we'd check CIP's KernelCI (setup in progress) for test results. | 09:17 |
| patersonc | Does anyone have any thoughts/comments on any of the above? (We can discuss after the other status updates if needed) | 09:17 |
| szlin | patersonc: thanks for the update | 09:18 |
| pave11 | 3 hours is bad... if we run it on every commit. | 09:18 |
| pave11 | but if we do full run say ... once a day? It should not be that bad. | 09:18 |
| pave11 | Or every saturday or something like that. | 09:18 |
| pave11 | (Can discuss later). | 09:18 |
| szlin | patersonc: feel free to list the topics that you want to discuss in ELCE f2f meeting | 09:18 |
| szlin | any other topics? | 09:19 |
| szlin | 3 | 09:19 |
| szlin | 2 | 09:19 |
| szlin | 1 | 09:19 |
| szlin | #topic CIP Core | 09:19 |
| *** brlogger` changes topic to "CIP Core (Meeting topic: CIP IRC weekly meeting)" | 09:19 | |
| patersonc | pave11: Yep. And that's just for 1 config. If a board has multiple configs it'll run multiple times. We could add 10x each reference board to the labs. But one of the test cases takes over an hour to run alone. Will discuss later. | 09:19 |
| kazu | I've moved PDP document to cip-pkglist git reo | 09:19 |
| kazu | https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc/pdp.md | 09:19 |
| kazu | Please review and give me comments or questions by the next TSC meeting | 09:19 |
| kazu | After the review, I'm planinng to start the initial proposal using the basic package (glibc?) | 09:20 |
| szlin | kazu: thank you for the update | 09:20 |
| kazu | Jan & I are preparing the slide for ELCE CIP Core | 09:20 |
| kazu | No other technical updates in this week... | 09:20 |
| szlin | any other topics? | 09:20 |
| szlin | 3 | 09:21 |
| szlin | 2 | 09:21 |
| szlin | 1 | 09:21 |
| szlin | #topic Software update | 09:21 |
| *** brlogger` changes topic to "Software update (Meeting topic: CIP IRC weekly meeting)" | 09:21 | |
| suzuki26 | I've integrated "signed update image" function that is supported by SWUpdate into my WG's ELCE demo. | 09:21 |
| suzuki26 | Now I'm trying to integrate "encrypted update image" function into the demo and preparing the slide for CIP Mini-summit. | 09:21 |
| suzuki26 | That's all from my side. | 09:21 |
| szlin | suzuki26: thank you for the update | 09:21 |
| szlin | any other topics? | 09:21 |
| szlin | 3 | 09:21 |
| szlin | 2 | 09:21 |
| szlin | 1 | 09:21 |
| szlin | #topic AOB | 09:22 |
| *** brlogger` changes topic to "AOB (Meeting topic: CIP IRC weekly meeting)" | 09:22 | |
| szlin | any other business? | 09:22 |
| patersonc | o/ | 09:22 |
| patersonc | Do you think 1h for the Kernel F2F meeting at ELC-E will be enough? | 09:22 |
| szlin | not sure, it depends on the agenda | 09:23 |
| patersonc | True | 09:23 |
| szlin | and we did it last time. | 09:23 |
| patersonc | It sounds like Neil is struggling to find us a room | 09:23 |
| szlin | I will contact him later. | 09:24 |
| szlin | iwamatsu_: pave11: would you like to share the kernel maintenance experience in CIP semi-summit? | 09:25 |
| pave11 | szlin: I'm not sure how interesting topic that is or what to talk about. | 09:25 |
| pave11 | szlin: I can certainly answer questions... | 09:25 |
| szlin | pave11: great, we can rethink the content. | 09:26 |
| szlin | any other topics? | 09:27 |
| szlin | 3 | 09:27 |
| szlin | 2 | 09:27 |
| szlin | 1 | 09:27 |
| szlin | #endmeeting | 09:27 |
| brlogger` | Meeting ended Thu Oct 10 09:27:25 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 09:27 |
| brlogger` | Minutes: https://irclogs.baserock.org/meetings/cip/2019/10/cip.2019-10-10-09.00.html | 09:27 |
| brlogger` | Minutes (text): https://irclogs.baserock.org/meetings/cip/2019/10/cip.2019-10-10-09.00.txt | 09:27 |
| brlogger` | Log: https://irclogs.baserock.org/meetings/cip/2019/10/cip.2019-10-10-09.00.log.html | 09:27 |
| *** brlogger` changes topic to "Civil Infrastructure Platform Project. Find the logs at https://irclogs.baserock.org/cip/" | 09:27 | |
| szlin | thank you all | 09:27 |
| kazu | Thank yo | 09:27 |
| pave11 | thank you! | 09:27 |
| iwamatsu_ | thank you | 09:27 |
| masashi910 | thank you! | 09:27 |
| fujita[m] | thank you! | 09:27 |
| suzuki26 | Thank you! | 09:27 |
| wens | thank you | 09:27 |
| szlin | regarding proposal from Kudo-san | 09:27 |
| szlin | pave11: iwamatsu_: do you have any opinion on that? | 09:28 |
| *** suzuki26 has left #cip | 09:28 | |
| masashi910 | szlin: maybe I will send an email to cip-dev asking for comments on that topic. | 09:28 |
| szlin | I've replied kudo-san via email that I think it will be great if we can add and test reference board | 09:28 |
| szlin | IIRC, pavel mentioned there's no known issue to accept patches from Cybertrust | 09:29 |
| pave11 | szlin: I believe that is management decision. If we have clean series of patches, we can apply them. | 09:29 |
| masashi910 | szlin: Yes thanks for your comments. | 09:29 |
| pave11 | (but we are far from having that series). | 09:29 |
| iwamatsu_ | szlin; sorry, i dont check kudo-san's mail, I will check this. | 09:29 |
| pave11 | If we have a board in the lab to test on, yes that would be good. | 09:30 |
| szlin | iwamatsu_: thank you. | 09:30 |
| szlin | pave11: yes, I don't see technical issue so far | 09:30 |
| pave11 | If we have actual support from Xilinx / Xilinx becomes member / etc... yep, that's great, too. | 09:30 |
| pave11 | But I believe it is management decision at this moment. | 09:30 |
| pave11 | And yes, there probably will be technical issues, too... | 09:31 |
| pave11 | ...we'll know once we see series of patches. | 09:31 |
| patersonc | Yes, getting an additional CIP member would be good for CIP | 09:31 |
| iwamatsu_ | I also use Xilinx devices personally. I'm interested it. | 09:31 |
| szlin | patersonc: :D | 09:31 |
| pave11 | There is work that should be done on Xilinx in the mainline, regardless of what CIP project decides. | 09:32 |
| pave11 | Drivers for basic support should move away from staging/ , for example. | 09:33 |
| masashi910 | pave11: yes, agree. | 09:34 |
| szlin | yes, upstream first. | 09:34 |
| masashi910 | So, from the view point of the kernel team, can I understand that there are no technical issues about adding MPSoC to the list of reference boards. But rather, it is the management decision. | 09:36 |
| fujita[m] | masashi910: Can we know what purpose Xilinx specific HWs are going to be used for? | 09:37 |
| masashi910 | fujita[m]: that depends on customers | 09:38 |
| fujita[m] | You mean, currently you have no customers? | 09:38 |
| masashi910 | fujita[m]: I mean it is confidential | 09:39 |
| pave11 | masashi910: I'm not sure what are requirements for reference boards. It may be that we need support first then we can list board as a reference. Again, management. | 09:39 |
| pave11 | masashi910: But it would be nice to have board available for testing while we are working on the patches :-). | 09:39 |
| fujita[m] | masashi910: Understood. Thanks. | 09:39 |
| masashi910 | pave11: yes, we are planning to contribute MPSoC board(s) to CIP test environment. | 09:40 |
| pave11 | Good :-). | 09:40 |
| szlin | masashi910: yes, you're right. | 09:41 |
| masashi910 | szlin: thanks fo your confrimation. | 09:41 |
| iwamatsu_ | masashi910: It may be a little different, We need to check the power control for board. | 09:42 |
| iwamatsu_ | For example, if we need to switch on when starting up, we may need to modify hardware. | 09:42 |
| masashi910 | iwamatsu_: you mean, in order to check power control capability, it should be treated as a reference platform? sorry I'm a bit confused. | 09:43 |
| iwamatsu_ | I think there is no problem as a reference platform. | 09:46 |
| fujita[m] | masashi910: In case the board starts just after power supplied without pussing any buttons, the board can be used on the Lab. | 09:46 |
| iwamatsu_ | But when registering with CI, we need to be check about power. | 09:46 |
| iwamatsu_ | fujita[m]: Yes, thanks. | 09:47 |
| masashi910 | iwamatsu_: I see. Your suggestion is relating to the topic to add to the test environment. Thanks. | 09:47 |
| masashi910 | fujita[m]: Thanks. | 09:47 |
| masashi910 | szlin: then, shall I come back to TSC about this topic if necessary? | 09:48 |
| fujita[m] | (It may hard for Cybertrust to convince managers without saying purposes... ;-)) | 09:49 |
| masashi910 | szlin: or shall we come back to this topic if requested? | 09:50 |
| szlin | masashi910: it depends on your decision. you can send clean patches directly or wait for Xilinux people. | 09:52 |
| masashi910 | fujita[m]: Cybertrust does not intend to add MPSoC to a reference list. | 09:52 |
| szlin | s/xilinux/Xilinx | 09:52 |
| masashi910 | szlin: we will try to send clean patches from mainline to cip | 09:53 |
| szlin | masashi910: so that you can send the patches directly without discussing in TSC | 09:55 |
| pave11 | szlin: Ok, does that mean that "management" decision is to proceed, and we can apply patches to -cip branches if they meet the technical requirements? | 09:56 |
| masashi910 | My understanding is that we need to send the clean ones regardless of MPSoC being listed as reference or not. Is it correct? | 09:56 |
| fujita[m] | send to LTS? | 09:57 |
| patersonc | LTS won't accept patches for board support | 09:59 |
| szlin | masashi910: yes. the referece board is nice to have, not essential. | 09:59 |
| masashi910 | szlin: I see. | 10:00 |
| szlin | LTS only accepts bug fixed (ideally | 10:00 |
| pave11 | afc | 10:02 |
| fujita[m] | So, the patches should send to the top of mainline. Is my understanding correct? | 10:02 |
| masashi910 | Thanks for all your comments! Anyway it may take a bit more time to prepare for the contribution. | 10:03 |
| szlin | fujita[m]: yes, upstream frist. | 10:03 |
| szlin | s/frist/first | 10:03 |
| fujita[m] | szlin: Thank you. Now it became clear for me. | 10:04 |
| masashi910 | When we are ready to contribute, I will let you know. | 10:05 |
| patersonc | Does anyone want to discuss testing? Specifically 1) Length of LTP tests, and 2) How we show test results in GitLab. | 10:06 |
| szlin | masashi910: sure, you can send patches to "cip-dev@lists.cip-project.org" directly | 10:06 |
| masashi910 | szlin: Thanks for your help! I really appreciated it. | 10:07 |
| szlin | masashi910: Anytime, feel free to ping me if you have any questions | 10:08 |
| szlin | patersonc: do you mean the list of test cases in LTP? | 10:09 |
| patersonc | Some tests take over an hour to run. How do we want to handle this? | 10:09 |
| patersonc | Are maintainers happy to wait for hours to see the results of the tests before they make releases? | 10:10 |
| szlin | I don't think so. | 10:10 |
| patersonc | Current test lengths for LTP tests: ltp-math-tests: 5m ltp-fs-tests: Over 65m ltp-syscalls-tests: 45m ltp-sched-tests: 5m ltp-open-posix-tests: Don’t know (not currently passing) ltp-ipc-tests: 10m ltp-cve-tests: 40m ltp-dio-tests: 6m ltp-timers-tests: 4m ltp-sched-tests: 5m | 10:10 |
| patersonc | We can add lots of boards, but the fs, syscall and cve tests till take a very long time. | 10:11 |
| fujita[m] | patersonc: Are rootfses mounted via NFS? | 10:12 |
| patersonc | Yes | 10:13 |
| fujita[m] | Umm, the time of fs may be able to reduce by using ramfs. But the others may difficult. | 10:14 |
| patersonc | Good point. Maybe the fs tests can be run on local storage as well. | 10:15 |
| szlin | Some tests are unnecessary for every time | 10:15 |
| patersonc | iwamatsu_: What do you think? | 10:16 |
| patersonc | Does anyone have an opinion about how we show tests in GitLab? | 10:22 |
| kazu | szlin patersonc The most effective idea I can think about at the moment is check which functions (fs, net, driver, etc.) are changed in the updates then automatically filter unrelated LTP test cases out from the target list | 10:23 |
| patersonc | Should we wait until tests are complete and show the results? Or just show that the test jobs were submitted okay, then rely on another location to show the test results? | 10:23 |
| patersonc | kazu: This could be an idea. But sometimes it may be hard to know what a change will affect. | 10:24 |
| pave11 | patersonc: Showing results as is is pretty nice... | 10:25 |
| pave11 | kazu: I don't think filtering testsuite according to patches is feasible or good idea. | 10:25 |
| fujita[m] | In my opinion, all tests have to be run when releasing new kernel | 10:26 |
| kazu | patersonc Yes, and I don't know if there are tools which already has such functionality... | 10:26 |
| pave11 | patersonc: Is it feasible to run whole testsuite at least once on each board, and share the failures if any? | 10:26 |
| patersonc | pave11: Yes, which is basically what we're doing now. Although individual test results aren't currently shown in GitLab, only if the overall test job succeeded or not. | 10:28 |
| pave11 | patersonc: Ok.. Are there any failures we should look into? | 10:29 |
| *** masashi910 has quit IRC | 10:39 | |
| patersonc | pave11: Iwamatsu-san is on the case | 10:45 |
| patersonc | I haven't started investigating the individual failures yet | 10:45 |
| patersonc | There are quite a few though, but a lot of them are probably meant to fail... | 10:45 |
| patersonc | e,g, there are 2 failed tests here: https://lava.ciplatform.org/results/5310/1_ltp-ipc-tests | 10:46 |
| patersonc | One here: https://lava.ciplatform.org/results/5307/1_ltp-cve-tests | 10:47 |
| patersonc | 68 fails here: https://lava.ciplatform.org/results/5305/1_ltp-syscalls-tests | 10:47 |
| patersonc | etc, | 10:47 |
| kazu | patersonc Regarding failed test cases, finally, do we need to keep all test cases PASS? | 10:48 |
| kazu | Several LTP test cases depend on specific kernel configuration, user land commands (e.g. depends on bash, missing options in busybox), user land settings (e.g. mounted fs), hardware resources (e.g. no enouch memory or disk spaces). | 10:48 |
| kazu | From CIP Core PoV, if we use CIP Core rootfs for kernel testing, does the rootfs need to satisfy all dependencies of LTP? | 10:49 |
| patersonc | kazu: Exactly. I'm not sure what tests "should" pass/fail. | 10:51 |
| fujita[m] | I believe not all test must pass. CIP must decide what tests should pass | 10:51 |
| patersonc | kazu: About CIP-Core, not it doesn't. Iwamatsu-san submitted a merge request | 10:52 |
| patersonc | https://gitlab.com/cip-project/cip-core/deby/merge_requests/2 | 10:52 |
| patersonc | I'm not sure what else needs to be done | 10:53 |
| kazu | patersonc Yeah, I'm confirming them, then apply ASAP | 10:54 |
| kazu | patersonc will keep discussion with him about the dependency issues in rootfs | 10:56 |
| pave11 | patersonc: Ok, thanks for pointers. | 10:59 |
| pave11 | patersonc: If there are some tests that work on some boards and fail on others, that's probably worth looking into. | 10:59 |
| kazu | fujita[m] Thank you for your opinion, I agree. The points which should be discussed may be how we decide them. | 11:00 |
| pave11 | patersonc: Also it would be worth investigating if test regressed within one series. | 11:01 |
| fujita[m] | kazu: Yes. This decision will affect our 10+ years support. We must decide carefully. | 11:02 |
| patersonc | pave11: Yes. When we know what should pass/fail, we can check for regressions etc. | 11:02 |
| patersonc | I'll get the infrastructure working, then we'll work out how to handle the results :) | 11:02 |
| pave11 | Thanks! Let us know if you find something interesting / suspect kernel problem. | 11:03 |
| patersonc | Sure | 11:03 |
| kazu | fujita[m] In Fuego http://www.fuegotest.org/, there is an activity to check dependencies (like above) of each LTP test case and skip the test (=CONF) if the dependencies are not satisfied. | 11:05 |
| fujita[m] | kazu: Interesting. I'll check it later. | 11:06 |
| patersonc | kazu: I think there is something similar with the linaro test-definition: https://github.com/Linaro/test-definitions/blob/master/automated/linux/ltp/skipfile-lkft.yaml | 11:06 |
| kazu | fujita[m] Also, as you know, LTP itself have dependency check function (CONF) in several test cases (not so many though) | 11:08 |
| fujita[m] | kazu: Ah, I should check details of LTP again. Thanks | 11:09 |
| kazu | patersonc Thank you for the link! I will check the details. I think there are similar other activities in multiple communities. | 11:10 |
| patersonc | FYI, we're using the linao test-definitions where possible | 11:11 |
| patersonc | No point in CIP doing the same elsewhere | 11:11 |
| fujita[m] | patersonc: +1 | 11:12 |
| kazu | One concern about such dependency check is regression after the test cases updated. I guess currently it depends on the maintainer and contributors... | 11:12 |
| kazu | patersonc I undersood, thanks | 11:15 |
| fujita[m] | It is difficult for us to consider whether to update test suites or not, too... | 11:16 |
| fujita[m] | Perhaps we should update. But we must check test case again... | 11:17 |
| kazu | fujita[m] yes, we often face the same issues in our development | 11:19 |
| fujita[m] | kazu: indeed | 11:20 |
| fujita[m] | kazu: Does the procedure adding packages to CIP core need test case proposal? | 11:21 |
| kazu | patersonc fujita[m] I should check more details of the current state of kernel testing especially about LTP. I'm glad if we can discuss more in ELCE. | 11:22 |
| *** robert__ has joined #cip | 11:23 | |
| fujita[m] | Unfortunately, I can't go to ELCE. I'll attend CIP meetings via zoom etc. if possible. | 11:24 |
| kazu | fujita[m] Currently, no plan about test cases. Do you mean they are like test cases executed by "make tests"? | 11:24 |
| kazu | fujita[m] I would like to setup, but not sure if the time slot matches your timezone... | 11:25 |
| fujita[m] | kazu: roughly saing, new functons always want tests, but the our process may be lacking steps for adding tests | 11:27 |
| fujita[m] | soory I have to leave. see you! | 11:29 |
| kazu | fujita[m] Agreed. Let's keep this discussion in ML or others! See you. | 11:30 |
| *** pave11 has quit IRC | 11:39 | |
| *** therisen has joined #cip | 12:09 | |
| *** kazu has quit IRC | 12:17 | |
| *** masashi910 has joined #cip | 13:03 | |
| *** robert__ has quit IRC | 13:58 | |
| *** rajm has joined #cip | 14:43 | |
| *** therisen has quit IRC | 15:15 | |
| *** tpollard has quit IRC | 15:47 | |
| *** iwamatsu_ has quit IRC | 20:23 | |
| *** rajm has quit IRC | 22:14 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!