Web   ·   Wiki   ·   Activities   ·   Blog   ·   Lists   ·   Chat   ·   Meeting   ·   Bugs   ·   Git   ·   Translate   ·   Archive   ·   People   ·   Donate

#olpc-meeting, 2011-11-14

Index | Today     Channels | Search | Join

All times shown according to UTC.

Time Nick Message
21:06 meeting Meeting started Mon Nov 14 21:06:56 2011 UTC. The chair is Cerlyn. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:06 Useful Commands: #action #agreed #help #info #idea #link #topic #endmeeting
21:07 Cerlyn #meetingtopic OLPC 1.75 triage meeting 2011-11-14
21:07 #chair martin_xsa
21:07 meeting Current chairs: Cerlyn martin_xsa
21:07 cjb <cjb!~cjb@2001:4830:1171:0:224:d7ff:fe18:2a20> has joined #olpc-meeting
21:08 martin_xsa don't sit on me
21:08 dilinger <dilinger!~dilinger@lunge.queued.net> has joined #olpc-meeting
21:08 martin_xsa ok - agenda is to go quickly over dev.laptop.org/1.75
21:08 yama <yama!~yama@124-171-33-11.dyn.iinet.net.au> has joined #olpc-meeting
21:08 yama has quit IRC
21:08 yama <yama!~yama@ubuntu/member/yama> has joined #olpc-meeting
21:09 martin_xsa blockers and high pri items, and figure out if we need to file additional tasks
21:09 it's our chance to make sure we don't forget about stuff
21:10 so #10835 Implement power management code for MMP2
21:10 Quozl there's 115 tickets there, it will be hard not to forget about stuff.
21:10 martin_xsa from smithbone's email, it sounds like I could stop using wmb's branch
21:11 Cerlyn #topic blockers and high pri items
21:11 martin_xsa dilinger: does arm-3.0-wip s/r reasonably well?
21:11 smithbone martin_xsa: I hope so. I defer to dilinger's decision.
21:11 dilinger martin_xsa: i hope so. :)
21:11 smithbone The kernel he gave me ran on our bench on a 201 for 3+ days.
21:12 dilinger i tested a few variations on that kernel, but not that kernel exactly
21:12 martin_xsa ok, then I'll build from there.
21:12 dilinger regardless, i'm missing the point of testing the wmb branch
21:12 martin_xsa any further questions for marvell? or code we want released?
21:13 dilinger there are pending questions for marvell that they haven't answered yet (about the tlb flushes)
21:13 martin_xsa agreed - any questinos not asked yet? :-)
21:13 question_queue_flush()
21:14 dilinger not at the moment
21:14 i tested their exact sram code over the weekend
21:14 martin_xsa #10893 XO-1.75 - runin tests
21:14 dilinger on 2 machines, i reached 10,000 cycles
21:14 the other 2 machines crashed early on
21:14 martin_xsa dilinger: hmm, interesting, and that's what's in -wip, so we'll see more reports then.
21:15 right - moving on to #10893 XO-1.75 - runin tests
21:15 dilinger martin_xsa: nah, what's in -wip is different
21:15 -wip adds their TLB stuff, ignores some of their other changes, and keeps mitch's delays
21:16 martin_xsa ok - I'll trust you to pick the right mix
21:16 :-)
21:16 dilinger it's a.. how do you say.. work in progress? ;)
21:16 martin_xsa Quozl: for the runin tests, you have 0.16, does it include thermal?
21:17 Quozl martin_xsa: cforth sets up thermal watchdog.  openfirmware and linux do not dislodge the configuration.  olpc-runin-tests 0.16.0 provides support for CPU temperature logging and (thermal) excursion halt.
21:19 martin_xsa Quozl: right, so does 0.16 include the needed bits to talk to OFW (sdkit) and invoke the thermal tests?
21:19 Blaketh <Blaketh!nullidentd@c-69-138-76-250.hsd1.md.comcast.net> has joined #olpc-meeting
21:19 Quozl martin_xsa: runin has no part in thermal watchdog behaviour.  it is monitoring, and forcing a fail if temperature is above a characterised limit, but we have not characterised that limit yet, so it may be insensitive.
21:20 martin_xsa: olpc-runin-tests 0.16.0 provides support for CPU temperature logging and (thermal) excursion halt.  you asked how it is implemented.  it uses sdkit, which is a userland build of ofw, to read the temperature sensor, because the kernel hasn't got a driver for it yet.
21:20 martin_xsa: there is no invokation of thermal tests in ofw.
21:20 (there are no thermal tests in ofw).
21:21 martin_xsa Quozl: it's ok, I'm asking whether the task is done. Of course it is better to get the description right :-))
21:21 so it's reasonable to set this to "add to build" ?
21:21 Quozl martin_xsa: i lack a specification to check against, sorry.  all i'm going on is task list from quanta.
21:22 martin_xsa: no, it is not reasonable to set #10893 to add-to-build, because #10893 is a metaticket, but #10954 is add-to-build, and that's where temperature monitoring for kernel is tracked.
21:22 martin_xsa great, I hadn't seen 10954
21:24 right, and it is add to build. great.
21:25 thanks. I'll add it to the build ;-)
21:25 #11369 XO-1.75 USB stops working after suspend/resume --
21:25 I guess nobody is working on this one yet -- probably a good candidate after the core S/R is considered stable
21:25 dilinger i haven't looked at that in the past week
21:26 right
21:26 martin_xsa #11379 PS/2 mouse, keyboard wedged after suspend/resume cycle
21:26 pgf: I've downgraded to high this one since we have your workaround
21:27 are there good reasons to block on having the root-cause fix?
21:27 or a better fix?
21:27 pgf not currently.
21:27 Quozl does this prevent a user from typing ahead while the system is suspended?
21:28 pgf ?  you can't do that now.
21:28 in any case, there's a separate bug for first-keystroke-lost
21:29 martin_xsa #11401 ^
21:29 #11395 - Implement Linux Suspend/Resume on MMP2
21:30 already discussed
21:30 #11397 DCON freeze not working under X
21:30 Quozl really?  but this ticket covers X, VT, libertas as well.
21:31 martin_xsa jnettlet has pushed a patch to -wip, and a new dovefb rpm, they'll get into the next build
21:31 sets it to add-to-build
21:32 #11400 Date resets to 1970 each boot
21:32 that looks like a regression over earlier kernels
21:32 pgf it broke when we enabled the 2nd rtc, i think
21:33 there's a config option to tell the kernel which rtc to prefer.  we should try using that to select the external rtc.
21:33 martin_xsa cjb: do you think silbe's fix is the right one? we can add it to the defconfig
21:33 pgf: is rtc1 the external one?
21:33 pgf the internal rtc doesn't actually need to have the correct time.
21:33 it must be, since rtc0 is internal.  :-)
21:33 Quozl is the discovery order predictable?
21:33 dilinger pgf: hm.  is there a runtime option, or is that compile-time only?
21:33 pgf all i know about is the config option.
21:34 cjb martin_xsa: if it works, it's a good idea; it involves having one of the two RTCs not knowing what the time is
21:34 Quozl #10899, is the only design we have at the moment.
21:35 martin_xsa cjb: looks like the ext one remembers, so if rtc1 is reliably the external one, we're go.
21:35 cjb yes
21:36 Quozl test that it doesn't break rtcwake.
21:36 pgf it will, indeed, break rtcwake.
21:36 Quozl we need rtcwake, don't we?
21:36 martin_xsa pgf: what?
21:36 pgf we'll have select the correct device on the rtcwake commandline.
21:36 Quozl then we'll break runin.
21:36 pgf oh -- not if the alarming one is rtc0
21:37 Quozl is the discovery order predictable?
21:37 martin_xsa that's very interesting,  the kernel cmdline says CONFIG_RTC_HCTOSYS_DEVICE
21:37 pgf we may break hwclock.
21:37 dilinger can we have an init script determine which rtc has the correct time (assuming it'll never be 1970 again) and set the remaining RTC devices accordingly?
21:37 martin_xsa pgf: I think we _fix_ hwclock with this :-)
21:37 pgf okay, maybe.
21:38 martin_xsa dilinger: from everything I hear here, rtc0 has zero chance of being right
21:38 it gets powered off with the SoC
21:38 Quozl dilinger: thus trusting openfirmware never to init rtc0.
21:39 openfirmware does have code that uses rtc0 for alarms, but i don't know when it is called.
21:39 martin_xsa ok - sounds like the right fix, I'll apply it, and we'll see if anything breaks. if it does, we'll handle the breakage.
21:39 dilinger martin_xsa: that assumes rtc0 is always rtc0
21:40 martin_xsa but the CONFIG_ variable seems to imply that it'll DTRT and not mess with the alarm clock
21:40 Quozl it merely needs to be tested before being committed.  ;-}
21:40 martin_xsa dilinger: that's true -- Quozl, yes, I'll get that done. I'll test it over a few reboots, removing power along the way.
21:41 and testing rtcwake, etc
21:41 any interesting testing idea, add to ticket :-)
21:41 #11401 keystroke which causes resume is lost
21:42 dilinger i don't think the device ordering is in any ways guaranteed.  as it happens now, the platform device for rtc-mmp gets created early, but that won't necessarily happen when that code is upstream
21:42 pgf rtcwake has precious few clients, so if it needs a "-d rtc1" to work, that'd be okay.
21:42 martin_xsa dilinger: is that viable to name via udev? or am I on drugs?
21:43 CanoeBerry_ has quit IRC
21:43 Quozl i propose "rtc_volatile" for the internal one.  ;-)
21:43 martin_xsa can we fit spawn_from_hell in there too?
21:43 dilinger martin_xsa: yeah, i think udev should be able to control the name
21:44 pgf they have different names in the sysfs tree already
21:44 Quozl pgf: you said in #10899 that the one outside doesn't have alarms ... that's changed?
21:44 pgf no
21:44 not that i know of
21:44 Quozl pgf: does rtcwake use alarms?
21:44 pgf certainly
21:45 martin_xsa dilinger: tjem we have to sync the defconfig values with the udev values...
21:45 then
21:45 this will be a lot of fun
21:45 pgf this doesn't all have to be solved now.   if the order is consistent today, run with it.
21:46 if it changes when we upstream, we can deal then.
21:46 martin_xsa good point
21:46 erikos has left #olpc-meeting
21:46 martin_xsa in any case, I'll explore it a bit
21:46 Next! #11401 keystroke which causes resume is lost
21:46 pgf no progress
21:47 we have some ideas, but don't know if any of them will fly.
21:47 martin_xsa is this a blocker for this stage?
21:48 Quozl i don't know the blocker criteria.
21:48 pgf it's not a great user experience, as you'll find out when aggressive s/r comes to your laptop.
21:48 what's "this stage"?
21:48 martin_xsa current blocker criteria is: it blocks C2 runin
21:48 Quozl i don't know if quanta will whinge about it.
21:48 it does not block C2 runin.
21:48 pgf right
21:48 martin_xsa exactly -- Quanta, runin, tests on mfg line
21:49 Quozl it may cause Quanta's QA team to raise it because it is different, but not if we don't tell them.  ;-)
21:49 martin_xsa I'll demote it to high -- naturally it's a blocker to a shipping OS
21:49 pgf: we don't think it's got a hw component, right?
21:50 Quozl #11369 is not a blocker for C2 runin, since USB is not tested by runin.
21:50 pgf not specifically, no.   not any more than every other s/r related bug.
21:51 Quozl #11397 is not a blocker for C2 runin, since nobody is meant to watch the screen.
21:51 #11400 would impact C2 runin file datestamps, needs fixing, but the C2 runin tests would pass.
21:52 #11409 is not a blocker for C2 runin, since runin does not test headphone jack.
21:53 martin_xsa Quozl: quanta does look at the units during runin, and will report oddities #11397
21:55 cjb has quit IRC
21:55 martin_xsa and Quanta does test things and performs basic tests on machines after runin, so #11369 is certain to hold things up if we enable s/r in powerd
21:55 Quozl Of the "high" tickets, the following may impact C2 runin ... #11237, #11357, #11408, #11413, #11416, #11430 (if Quanta don't like it), #11438).
21:55 martin_xsa ok - we are going over them :-)
21:56 it's not the onlything we want to know
21:56 cjb <cjb!~cjb@2001:4830:1171:0:224:d7ff:fe18:2a20> has joined #olpc-meeting
21:57 martin_xsa pgf: thanks
21:57 I'll skip audio for now, saadia couldn't join the meeting
21:58 Cerlyn: you reported that #11196 some 1.75 touchpads "wander" in ebook mode
21:58 still happens a bit?
21:58 Cerlyn a bit but not much with local testing
21:58 and that's if you are moving something behind the touchpad in ebook mode
21:59 or moving the XO to effectively do the same
21:59 pgf that's significantly different than originally, right?  it used to wander as soon as you closed the screen against the keyboard.
21:59 martin_xsa ok - anyway, that one's on Quanta's side, and we have olpc-kbdshim masking it
22:00 pgf it's really a vendor acceptance issue.
22:00 Cerlyn pgf: I think that's environmental conditions or potentially sample dependent
22:00 martin_xsa I am not too worried about it, -- agreed with pgf
22:00 Next: #11237 Video driver hang on XO-1.75 os4
22:00 I agree with Quozl that's potentially a blocker
22:00 pgf martin_xsa: i just don't want quanta to say "not a problem" because we've worked around the problem in s/w.
22:01 martin_xsa pgf: absolutely -- we want the tp to be quiet so we don't wake up
22:01 pgf: if the vendor gives us a userland command to shut it up...
22:02 pgf martin_xsa: the already suggested flow-controlling the touchpad in h/w.
22:02 s/the/they
22:03 it's not out of the question, i guess.
22:03 martin_xsa pgf: but the window on hw changes is closed, unless we have things wired up so that we can do it?
22:03 pgf ps2 flow control is part of normal operation.  no physical h/w changes needed.
22:03 (i shouldn't have said "in h/w" above.)
22:04 (i meant "at the h/w level")
22:04 martin_xsa pgf: ah, so that'd be on the SP
22:04 Quozl: #11237 not a blocker, it triggers with an accelerated video option we aren't using now
22:04 pgf martin_xsa: or in the EC on the other laptops.  remember that they'll use that pad everywhere.
22:05 martin_xsa pgf: yep
22:05 cjb martin_xsa: are we shipping without any gpu acceleration, then?
22:06 martin_xsa cjb: you're parachuting into it :-)
22:06 cjb hm?
22:06 pgf the flow-control sol'n isn't as easy on the 1 and 1.5, because the EC doesn't have the "i'm an ebook" signal.
22:07 martin_xsa cjb: current criteria is for C2 build & runin, and  #11237 just doesn't meed the blocker crit
22:07 jon promises a fix soon, though
22:07 cjb: any progress on #11353 SD Card cannot detected in OS881? I did some basic tests...
22:08 cjb martin_xsa: does suspend/resume crash if UNSAFE_RESUME's off?
22:08 martin_xsa cjb: I didn't test /that/ :-)
22:09 Quozl pgf: i've just checked the current hardware call issues list, and there is no current entry for CL2 that covers #11196 wander, so please raise it with wad?
22:09 cjb martin_xsa: that would decide whether it's blocker.
22:10 martin_xsa cjb: it crashes
22:10 cjb ok
22:10 pgf Quozl: martin_xsa was driving that process with quanta and the vendor.  they were going to provide new firmware or somesuch.  i assume martin's still on top of it, and won't accept the new h/w until it passes our criteria.
22:10 martin_xsa cjb: last week you said you'd investigate -- any progress on that?
22:10 cjb martin_xsa: no, been too busy with XO-3
22:10 Quozl pgf: 'k.
22:11 martin_xsa pgf, Quozl - yep, it's in the quanta confcall topic
22:11 topic/task list
22:11 Quozl martin_xsa: i must have missed it, i just went through it.
22:12 cjb martin_xsa: what's your deadline for getting the blockers fixed?
22:12 Quozl (several closed items).
22:12 i used the tracking list dated 2011-11-10, you might have another one.
22:12 martin_xsa cjb: right now we're working towards C2 build, so blockers are defined as to whether they block C2
22:12 cjb right, I know
22:13 martin_xsa somethings are high pri just because they just are, and affect us beyond C2
22:13 Quozl now that i know the blocking criteria, things are clearer to me.  it's good.
22:13 martin_xsa I want to have the OS img for C2 1st of Dec, so closing date is Nov 30th
22:14 that's laid out in an email to techteam and devel, with titled 11.3.1 timeline or similar
22:15 cjb: I assume xo-3 is gonna keep you busy++
22:15 cjb Okay, thanks.  I'm ambivalent on whether to commit to this because Scott's currently blocked on me figuring webgl out.  At least there are two weeks rather than a couple of days for it, though.
22:15 (to fix the SD bug, whatever it is)
22:15 martin_xsa cjb: ok
22:16 understood
22:16 cjb thanks.  let's revisit next week, things should be less crazy then.
22:16 martin_xsa ok
22:16 next #11357 Boot freezing on third clock dot
22:17 as Quozl, this is a candidate blocker
22:17 Quozl i regularly see boot freezes on b1 and c1 units here, when i get to try linux.
22:17 martin_xsa yep- I see it lots too
22:18 Quozl they are either third-clock-dot or scsi_wait_scan.
22:18 pgf are you distinguishing between the two, or saying they're the same thing?
22:18 (i think the latter)
22:18 dilinger huh.  i don't think i've ever seen that
22:19 Cerlyn pgf: I believe they are the same thing; and technically the modprobe is blocked on something else and it may not be the module's fault
22:19 Quozl i don't know which is which, sometimes i'm looking at the screen, sometimes i'm not, sometimes i've booted from ok, sometimes i've got a USB to ethernet dongle involved, i just haven't fully diagnosed and separated out those symptoms, i was usually busy on some ofw errand.  ;-}
22:19 martin_xsa dilinger: do you build your psmouse into the kernel?
22:19 cjb I see it a lot on my C1, feel like I hadn't ever seen it pre-C1
22:19 dilinger martin_xsa: nope, i'm using the defconfig
22:20 martin_xsa dilinger: that must be a pain :-/
22:20 pgf dilinger: do you have modules present?
22:20 dilinger though i was using a non-modular kernel for the majority of my s/r testing, up until a few weeks ago.  so maybe that's why
22:21 martin_xsa: it's not too bad; since i've been working on the sram code non-stop, every rebuild only affects vmlinuz
22:21 martin_xsa maybe built-in psmouse changes the order of things just enough that we sidestep this one :-P
22:21 pbrobinson <pbrobinson!~pbrobinso@2001:41d0:2:923e::> has joined #olpc-meeting
22:23 martin_xsa I'll try to see if dsd has any more debugging ideas
22:23 Next #11359 Psmouse kernel panic on shutdown
22:25 This doesn't break runin, but is damn weird - maybe we're trying to talk to AVC touchpads too fast.
22:25 Quozl #11359, no impact to C2 runin phase, since the power button is not pressed twice.
22:25 Cerlyn pgf and further testing suggests it may also happen with S/R cycles
22:26 Quozl #11359, if it happens with suspend only with keyboard or mouse input, then it shouldn't be a concern for runin.
22:26 Cerlyn does not seem to be the most common S/R failure here though
22:27 martin_xsa 11359 is a symptom -- at shutdown time -- of failure to init AVC touchpads
22:28 pgf i wouldn't be surprised if it's gone from s/r, since i disabled mouse resets across s/r.
22:28 (pushed today)
22:28 martin_xsa there's ~4 bugs reporting the symptoms, root cause seems to be squarely in psmouse init process
22:28 ah, good point, maybe now we wiggle it less
22:29 Cerlyn 2 test kernels used for S/R testing have it; once with os10 on the first S/R cycle
22:29 at least in my S/R log library
22:29 martin_xsa let's run quickly over the remaining high bugs -- to see if we have candidates for blockers. Quozl identified a few
22:30 #11396 Implement Linux support for wake-on-lan on MMP2 -- this is waiting for S/R stability
22:31 #11399 [CL2]Press enter many times in write activity and system will hang up -- not a blocker but important -- I hope jnettlet tackles it soon
22:33 #11406 powerd needs to be ported to new "wakeup events queue" kernel backend -- not a blocker -- but important, can we separate out the kernel tasks?
22:33 pgf it's done.  modulo bug fixes.
22:34 martin_xsa pgf: oh! great
22:34 pgf and modulo missing parts, like libertas.
22:34 martin_xsa that's the recent string of commits on -wip?
22:34 pgf parly.  half were that, half were the OLS support.
22:34 martin_xsa yeah, that's what I meant
22:35 pgf also modulo getting it into a build, which i've failed miserably at today.   see mail.
22:35 martin_xsa for powerd?
22:36 ok - I'll look into it, also tmw morning, if you're not around on irc, I'll give you a step-by-step of my steps and rationale
22:36 and the img build will happen tmw anyway :-)
22:37 pgf i'm sure it's easy if one does it frequently.   i'd appreciate a step-by-step.
22:37 my officemates would appreciate me getting that help as well, i'm sure.
22:37 martin_xsa I don't do it frequently, but I've done it a few times... so it'll be very step by step.
22:37 :-)
22:40 updated 11408 to block S/R, and be a blocker too
22:40 same with #11413 XO-1.75 libertas crash on resume
22:42 actually, #11413 doesn't quite make it to a blocker
22:43 dilinger the libertas-crash-on-resume is high on my todo list, post-ram stabilization
22:43 martin_xsa excellent!
22:43 it is odd -- it only crashes if associated
22:44 dilinger if you leave NM running, even if you're not telling it to associate, it'll trigger the bug quickly
22:45 jnettlet <jnettlet!~jnettlet@> has joined #olpc-meeting
22:45 martin_xsa #11416 C1 XO 1.75s may not wake up due to RTC from suspend -- marked as blocker
22:46 #11430 mmp-camera output corrupt after suspend/resume -- hesitant about his one, it's important but won't delay C2 on it
22:46 jon corbet is working on it
22:47 dilinger has the not-wake-up-from-suspend issue happened since pgf's keyboard workaround went in?
22:49 Cerlyn when was that committed?
22:49 martin_xsa it's in os10
22:49 and any kernels we tested on top of os10
22:50 Cerlyn I don't think it's happened since
22:50 but I may have woken some up this morning
22:51 dilinger it may have been a timing problem that was fixed by pgf's commits, then.  the rtc alarm was firing, but due to keyboard/touchpad bugs the system was delayed in getting to sleep.. by the time the system had gone to sleep, the alarm had already fired
22:52 if anyone sees it with os10+, please update the bug w/ dmesg output or something
22:52 martin_xsa dilinger: yeah -- though that can still happen with very short rtcwake calls
22:53 pgf dilinger: good thought.  i can't say for sure that that's not what i've seen.
22:53 martin_xsa methink we should have a guard around rtcwake invokations, that ignores irequests to sleep shorter than a minimum time (that being a safe amount of time to down cleanly)
22:54 pgf the new kernel PM infra supposedly makes it possible to prevent the wakeup-happens-while-suspending race.
22:54 i haven't tried implementing it yet, but i'm working toward it.
22:54 martin_xsa: that won't help, if the system takes longer to get to sleep than just >< this much.
22:55 martin_xsa pgf: you mean new kernel pm infra we are not currently using?
22:56 dilinger martin_xsa: i know mitch was a fan of 2s alarms; i tried to get people to use 5s wakeup alarms.  i think 5s is a good amount of time; if we delay that long on the way down, something is definitely wrong
22:56 martin_xsa linux 3.1 or 3.2?
22:56 dilinger: sure, and as we debug the process, we'll get it shorter
22:56 pgf martin_xsa: i think our current kernel has the necessary support.
22:57 martin_xsa pgf: but we hit this issue quite a bit. if the kernel infra "prevents" this from happening...
22:57 maybe that word doesn't mean what the implementor of this infra thinks it means...
22:58 anyway, later on we'll know now long it takes us to quiesce our system
22:58 pgf martin_xsa: i just said "i haven't tried implementing it yet, but i'm working toward it."
22:58 martin_xsa ah, sorry, there's a way to wire it up. oops, sorry.
23:01 ok - reading down the trac list. I don't see anything that looks likely to block us towards C2
23:03 pgf, dilinger, smithbone, jnettlet, do you have items you'd like to make blockers or discuss?
23:03 and Quozl :-)
23:03 jnettlet nothing new nope.
23:04 smithbone martin_xsa: nope
23:04 pgf nope
23:05 martin_xsa great -- now all we have to do is fix all the bugs discussed beforen next monday.
23:05 meeting adjourned ;-)
23:05 meeting martin_xsa: Error: "adjourned" is not a valid command.
23:05 Cerlyn #endmeeting
23:05 meeting Meeting ended Mon Nov 14 23:05:25 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot. (v 0.1.4)
23:05 Minutes: http://meeting.sugarlabs.org/o[…]-14T21:06:56.html
23:05 Log:     http://meeting.sugarlabs.org/o[…]11-11-14T21:06:56

Index | Today     Channels | Search | Join

Powered by ilbot/Modified.