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

#sugar-meeting, 2011-06-05

 « Previous day | Index | Today | Next day »     Channels | Search | Join

All times shown according to UTC.

Time Nick Message
02:41 satellit_remote has quit IRC
03:17 cjl_afk has quit IRC
07:02 meeting <meeting!~sugaroid@jita.sugarlabs.org> has joined #sugar-meeting
07:07 tch <tch!~tch@190.23.85.180> has joined #sugar-meeting
07:31 yama <yama!~yama@124-169-16-96.dyn.iinet.net.au> has joined #sugar-meeting
07:31 yama has quit IRC
07:31 yama <yama!~yama@ubuntu/member/yama> has joined #sugar-meeting
07:32 alsroot has quit IRC
07:33 yama` has quit IRC
08:22 tch has quit IRC
10:10 alsroot <alsroot!~alsroot@94.137.229.183> has joined #sugar-meeting
10:10 alsroot has quit IRC
10:10 alsroot <alsroot!~alsroot@pdpc/supporter/active/antilopa-gnu> has joined #sugar-meeting
10:39 lucian <lucian!~lucian@78-86-217-168.zone2.bethere.co.uk> has joined #sugar-meeting
11:05 lucian has quit IRC
11:39 lucian <lucian!~lucian@78-86-217-168.zone2.bethere.co.uk> has joined #sugar-meeting
13:56 lucian has quit IRC
14:00 lucian <lucian!~lucian@78-86-217-168.zone2.bethere.co.uk> has joined #sugar-meeting
14:35 lucian_ <lucian_!~lucian@78-86-217-168.zone2.bethere.co.uk> has joined #sugar-meeting
14:36 lucian has quit IRC
14:36 lucian_ is now known as lucian
14:48 silbe <silbe!~silbe@twin.sascha.silbe.org> has joined #sugar-meeting
14:51 cjb <cjb!~cjb@173-166-109-250-newengland​.hfc.comcastbusiness.net> has joined #sugar-meeting
15:18 garycmartin <garycmartin!~garycmart@92.26.182.175> has joined #sugar-meeting
15:20 silbe garycmartin: hi!
15:20 garycmartin silbe: Hi, just reading your NM email :)
15:21 silbe: you want to try and discuss this today (design meeting)?
15:21 silbe garycmartin: nice. Let me know what you think of it. Nobody else has joined yet, so I guess the meeting won't happen...
15:21 garycmartin silbe: we are early (I think).
15:23 silbe: Hmm did we have last weeks meeting later than usual I wonder.
15:23 is loosing track of time ;)
15:25 silbe garycmartin: ah, the wiki page is giving the wrong time. It says 15 UTC, but we started 16 UTC last week and agreed to go for the same time today.
15:25 garycmartin silbe: yes that may well be the confusion, we did the last meeting at 16:00UTC (35min from now) as that was good for Christian.
15:28 silbe: apologies, I did update the wiki page after last weeks meeting but forgot about the time slide to change.
15:28 silbe garycmartin: no problem; just glad it wasn't in the opposite direction.
15:40 garycmartin silbe: sent quick email reminder (and corrected the time on the wiki)
15:41 silbe garycmartin: thx!
15:53 garycmartin silbe: have some questions re email, but will wait incase folks show up in 10min.
15:53 silbe garycmartin: ok
15:55 garycmartin silbe: but as a heads up so you can think of a good answer. In the email I'm not really following the term "connection" very well. A ap with multiple possible connections? Is this just extra possible VPN tunnels or something?
16:00 silbe garycmartin: the most important part is different authentication credentials, sometimes even different methods for authentication (WPA-PSK vs. 802.1x for example).
16:01 garycmartin on his 3rd read through of your email ;)
16:02 silbe hides. The wording must have been awful.
16:04 but at least even the NM API specification authors apparently couldn't agree on a single set of terms. There are "settings" and "active connections" (as D-Bus objects), but sometimes a "connection" path is passed as an argument, most likely meaning a "setting", not an "active connection". :-/
16:04 cjl_afk <cjl_afk!~chatzilla@c-98-204-202-184.hsd1.md.comcast.net> has joined #sugar-meeting
16:06 garycmartin silbe: No it's good, but very deep, many topics.
16:07 silbe ok. Glad I didn't include the Ad-hoc stuff after all.
16:07 garycmartin lol
16:12 silbe: Hmm, no other takers yet today it seams. Should we just talk things over a little?
16:12 s/seams/seems
16:14 silbe garycmartin: let's wait another two minutes and start then. Not that I expect anyone else to join within those two minutes...
16:14 garycmartin sure.
16:14 goes to make a cup of tea brb
16:17 back
16:17 silbe ok, let's start then
16:17 garycmartin #startmeeting
16:17 meeting Meeting started Sun Jun  5 16:17:34 2011 UTC. The chair is garycmartin. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:17 Useful Commands: #action #agreed #help #info #idea #link #topic #endmeeting
16:18 garycmartin Just so we have an easy log for other to look through :)
16:18 silbe +1
16:18 garycmartin silbe: Can I fire some general questions your way?
16:20 #topic Neighbourhood design changes related to new NetworkManager api
16:20 silbe garycmartin: go ahead
16:21 garycmartin #info discussing Saschas email today Subject: [DESIGN] NetworkManager / Neighborhood design changes
16:22 silbe #link http://lists.sugarlabs.org/arc[…]-June/031679.html
16:23 garycmartin silbe: OK, so lots of details in your email. First thought, are we trying to allow multiple network connections at a single time (e.g. cabled ethernet connection while simultaneously connected to an AP)?
16:24 silbe garycmartin: if NM allows it, we do - both with the current and the new design.
16:24 and in fact it does allow it - plugging in an ethernet cable will activate the wired connection in parallel with the wireless one, but take away the default route from it
16:25 garycmartin silbe: I know networking stacks can support all kinds/quantities of connections, but the Sugar UI does not allow it (for very sane reasons of buddy visibility)
16:27 silbe garycmartin: that's something we'll need to work on in the long term, independent of network connectivity. Even the automatic changes between Salut (link-local) and Jabber (school server) can be very confusing.
16:29 garycmartin silbe: the UI design complexity goes through the roof if we try and support multiple simultaneous networks. Multiple connected APs in you device frame? What use would that be to activity collaboration they have no way of directing traffic to a specific network.
16:30 silbe garycmartin: what I didn't include in the current mail either is support for "sharing" the internet connection with others, which will create a special ad-hoc connection that others can join and use for internet connectivity. Dextrose already supports this, but I'd like to discuss the design at a later time. There are enough topics to discuss for today.
16:32 garycmartin: don't conflate connectivity with collaboration. The latter requires the former, but that's about it.
16:32 garycmartin silbe: "sharing" a network connection to others has good specific real world uses, I agree that's worth exposing to a Sugar user.
16:33 silbe garycmartin: The purpose of NetworkManager is to manage all this complexity. We only need to provide a UI for it.
16:33 garycmartin silbe: We should only expose what is useful to Sugar users.
16:33 silbe garycmartin: NM should know when it's OK to have two connections active in parallel and when it should take down the existing one if another one is activated.
16:35 garycmartin silbe: you have a requirement listed as "Ability to activate a specific connection if multiple connections are available for a device / access point"
16:35 silbe garycmartin: it's pretty normal on my laptops to have two connections active: a wireless and a wired one. I can unplug the cable and still continue to use the network. When I sit down and need more bandwidth, I plug in the cable again.
16:35 garycmartin: ah, maybe that one is phrased confusingly
16:36 garycmartin: What I meant was that if there are different settings for the same SSID, the user can choose which one to use right now.
16:38 garycmartin: The reason we need this at all is that there are a lot of APs that come preconfigured with the *same* SSID. If I use my XO at two different houses (e.g. at my family and at a friends), the SSID will be the same but the credentials won't match.
16:39 garycmartin silbe: so if one AP allows WPA and WEP authentication at the same time, and the user has logged in with both at some point in the past, they get to chose which of the two to use when they click the AP icon next time to connect?
16:40 silbe garycmartin: if they explicitly added a second setting for the same SSID, then yes, they can choose between the two.
16:41 garycmartin silbe: so are we not using the BSSID internally for uniqueness, so that even if two APs are named with the same SSID they are distinct in the UI (separate AP icons even if they have the same name)?
16:43 silbe garycmartin: we don't do that in the UI because the purpose of having an SSID is to allow roaming (between multiple APs, i.e. between differen BSSIDs)
16:44 garycmartin silbe: yep, fair point.
16:44 silbe garycmartin: good point, though - we should only list connections with a matching BSSID if it's fixed.
16:46 garycmartin silbe: 'only list connections with a matching BSSID if it's fixed' so that's not the example you game above right (where you have an AP at home called "foobar" and an AP at work also called "foobar" but each with different authentication details)?
16:47 s/game/gave/
16:52 silbe garycmartin: if the user chose to restrict each of the two connections to the respective BSSID, Sugar will only show a single connection at each place and auto-activation will work fine.
16:53 garycmartin: if the user chose to leave roaming enabled, the connection(s) will show at both places
16:56 garycmartin silbe: So.. If I click an AP icon with an SSID "foobar" and I have already authenticated with an SSID "foobar" (and it doesn't have authentication details for it's BSSID), it should first try the stored authentication details (attempt at roaming), if that fails *and* the BSSID is different, it should prompt the user to enter new authentication details (new connection stored against the unique BSSID). If it failes *and* the BSSID is the same the
16:56 is an error (the AP may have had it's authentication details changed) and the user needs to be prompted to enter new authentication details for it.
16:56 silbe garycmartin: I hope nobody sets up a multi-AP network (i.e. one with roaming) using the default SSID. Unfortunately experience shows that someone in charge will be stupid enough to do that, so we need to cope with that (since the user can't do anything about it). :-/
16:57 garycmartin silbe: OK let me try another req you note (just to get some coverage).
16:58 #topic Ability to prevent automatic reconnections for a device (either via using the Disconnect() call for the device or disabling the entire hardware class); preferably happens by default
16:59 silbe garycmartin: we might do that (prompt the user to configure a new connection if the credentials and the BSSID mismatch). So far I would have went for the simpler route of letting it just fail as usual. The user can then add the new connection manually.
17:00 garycmartin: that's something we already do. I remember that not doing so was a PITA in the past.
17:01 cjl_afk is now known as cjl
17:01 garycmartin silbe: This one has a clear/neat UI exposure to my eye. The palette for an AP should have an entry for something like "Forget this favourite network", the credentials could then be removed so NM doesn't try to reconnect.
17:02 silbe garycmartin: this would be nice to have as well, but is a different issue.
17:02 garycmartin silbe: currently there's that CP hack for deleting all credentials.
17:03 silbe garycmartin: what I meant is the ability to tell NM to stop all automatic connection attempts
17:04 garycmartin silbe: So you meant to tell NM don't use any AP, or don't use any Ethernet?
17:05 silbe garycmartin: exactly. At least not until manually instructed otherwise.
17:05 garycmartin silbe: isn't that covered by your next req "Easy access to powering down a device class"?
17:06 silbe garycmartin: it can be covered by that, but can also just work the way it currently does (i.e. choosing Disconnect will stop all automatic connection attempts)
17:07 garycmartin: https://bugs.sugarlabs.org/ticket/1802
17:09 garycmartin: if we agree about the need to expose rfkill / disable wifi/wwan/wimax in the Frame, we don't need to worry about the "stop all automatic connection attempts" one.
17:09 garycmartin silbe: so that is fixed now? Mesh still auto-connects if you disconnect from it I thoungh.
17:10 s/thoungh/thought
17:10 silbe garycmartin: hmm, maybe. TBH I planned to "accidentally" drop mesh support. ;)
17:10 garycmartin ;)
17:11 silbe Dextrose has been disabling it for a while and I'm not aware of anyone using it (with Sugar). Ad-hoc networks are the better solution for now.
17:13 a country-wide mesh composed of laptops sounds cool, but in practice I doubt it'll work anytime soon. Hybrid solutions with local APs that mesh between themselves seem to work fine, but those don't run Sugar.
17:13 the APs don't run Sugar I mean
17:13 garycmartin re "rfkill / disable wifi/wwan/wimax in the Frame" that would be OK I think as long as there is only one device icon for each. So no two AP device icons because you want to have connections to both at once ;)
17:15 silbe garycmartin: the Frame would show one icon per physical device (plus maybe one for additional ad-hoc networks, but let's discuss that next time). If you happen to have two wifi adapters, it would show both.
17:16 garycmartin silbe: re "rfkill / disable wifi/wwan/wimax in the Frame" the UI complication might be how do you obviously re-enable it. Right now we seem to have something similar (not sure of the technicalities) set in the CP Network module.
17:18 silbe garycmartin: My assumption was that NM still advertises the wireless device; we just can't use it. So we'd continue to show the Frame device icon, turning "Disable wireless networking" into "Enable wireless networking".
17:18 garycmartin perhaps a disabled device stays in the frame with an uncoloured white icon and a palette to re-activate.
17:18 silbe garycmartin: I should check that assumption, though.
17:18 garycmartin OK.
17:18 silbe: next?
17:19 silbe check, Frame device stays on "nmcli nm wifi off".
17:19 garycmartin #topic Ability to restrict a connection to a single AP (BSSID)
17:19 silbe with NM 0.8 that is - I don't run NM 0.9 yet (for obvious reasons)
17:19 CanoeBerry has quit IRC
17:20 garycmartin Is this something for a deployment to control what networks laptops are connected to, or something you see for regular users?
17:20 silbe garycmartin: there's two reasons for this. One is the use case mentioned above where the SSID is the same for different networks.
17:21 garycmartin: the other reason is that allowing roaming causes periodic scans for APs that a) drain power and b) have a performance impact.
17:24 garycmartin silbe: So roaming is on by default?
17:24 (at the moment)
17:26 silbe garycmartin: it's enabled by default and we don't expose a way to disable it, yep.
17:26 or to phrase it better: we don't support disabling it.
17:28 garycmartin silbe: so if we get to make our own custom authentication dialogue this time, this could be something like a check box when entering the credentials, "disable roaming for this network", or perhaps "only connect to this BSSID". Sorry for the horrible wording but you get the idea I hope?
17:28 silbe garycmartin: that's about how I imagined it to work, yup. Just an additional checkbox on the credentials dialog.
17:29 garycmartin OK, reasonable with some word smithing.
17:30 silbe: Let me skip your 'Nice to have', I think I had an automatic solution for that one up above, maybe?
17:32 (using the BSSID to look for credentials after SSID credentials fail)
17:33 (and prompting for new credentials if the BSSID is unknown)
17:33 silbe garycmartin: it would be wireless-specific (we need the same ability for modems etc.) and I'm not sure whether it'd work in all cases in practice. But people can still use nm-connection-editor, so it's not that important.
17:34 garycmartin OK. next topic :)
17:34 #topic Suggested design changes
17:38 silbe: "AP palette" can we not avoid needing to list extra connections for the same SSID (and avoid needing to manually add another). By using some of the above SSID/BSSID tricks? So the user just clicks the AP icon and in the background it tries credentials for the BSSID if it has them and  then tries SSID if it has them, and then prompts for credentials automatically?
17:39 silbe garycmartin: as mentioned above, we unfortunately can't rely on BSSID-locking to be sufficient.
17:40 garycmartin silbe: you mean in the case of modems?
17:42 silbe garycmartin: no. Imagine the school using a set of APs with default SSID and roaming, and some other party using the same AP with the same default SSID. You'll want roaming to be enabled for the first network, but there are still two different networks that need different settings.
17:44 I refuse to think about two different schools both using the setup as outlined above. ;)
17:45 garycmartin: however we still have the option of keeping the UI the same for the up-to-one-connection case and also exposing the additional complexity if there really are several connections configured for the same AP.
17:45 garycmartin trying to get his head around it.
17:46 silbe s/also/only
17:47 garycmartin: it'll make your head hurt. The problem is that SSIDs are supposed to be unique to a network, but in practice aren't.
17:48 things are slowly getting better as AP vendors have realised their mistake and start shipping with a random part in the SSID, but it's just a four-digit hex number, so given the number of AP sales there's still a good chance you'll encounter a different network that has the same SSID. :-/
17:49 garycmartin silbe: can there be a number of credentials stored for the same SSID and just have NM work it's way through, and prompt for yet more credentials if they all fail. With the credential dialogue having the  "disable roaming for this network", or "only connect to this BSSID" check box as mentioned above?
17:59 thinking a tick box with "Allow roaming for this network" is the best wording I can think of so far. The question is should it default to on or off ;)
18:02 silbe garycmartin: it might be possible to hack that on the Sugar side (something I'd like to avoid - I'd rather get *rid* of existing custom code like for the ad-hoc networks). While we're covering most cases now, it's not really generic. The question is whether we should trade the genericity for slightly (IMO) reduced UI complexity. Remember that we only need to increase UI complexity for those cases that are complex in reality.
18:06 garycmartin silbe: can we automatically detect that complexity and only expose new controls in such cases? Even just adding palette menu entries for manual options drastically increases user cognitive load.
18:07 silbe garycmartin: "Allow roaming for this network" sounds good. The default should probably be ticked as that's what we've done so far. Unticking it will prevent connectivity if roaming is available, while ticking it will "only" improve battery life and network performance.
18:07 garycmartin Sounds, sensible.
18:08 silbe garycmartin: we can simply choose not to add the option for adding new connections, or maybe make it dependent on a Control Panel setting.
18:09 garycmartin: something like the "Expert user mode" or "Show advanced settings" option that some applications have
18:09 "Allow complex network configurations"
18:10 garycmartin silbe: Hmmm, not a fan, often the rocky road to UI nightmare land ;)
18:11 silbe garycmartin: fair point. OTOH I fear we're trading "no ceiling" for "low floor".
18:12 though TBH I wouldn't aim for "no ceiling" w.r.t. to offering in-Sugar connection editing anyways. Just the ability to use whatever connection got configured some other way.
18:12 garycmartin silbe: also a fair point, but if we just hide stuff in expert mode, we likely don't make the effort to solve the hard problems of making it work for "low floor"
18:13 silbe: You ok for time? Shall we move onto next?
18:14 silbe garycmartin: I don't think it's worth the effort to make it lower floor. We're dealing with misconfigurations; the right (but not always possible) solution is to educate the operators.
18:15 garycmartin: sure, as long as it's still fine with you. The sooner we cover all of it and agree on a design the better.
18:16 garycmartin #topic Wireless device palette
18:20 silbe: "Connect to hidden network" option is all good for me. Given that we will always need to show a wireless device icon in the frame so the UI for hidden SSIDs can be accessed. I think the AP icon only shows in device frame when you first connect to one (think it's worked differently, and with different bugs in the past – remember a time when there were duplicates you couldn't get rid of with empty palettes)?
18:22 silbe garycmartin: not sure I understand. The wireless device icon should always be shown in the Frame. If we're neither connected nor trying to connect, it's just a light-grey circle on the dark-grey Frame background.
18:23 garycmartin: it also currently has an empty palette in that state. Something we should fix in the process.
18:24 The primary palette should contain some indication that it's a wireless device.
18:25 garycmartin silbe: Ah maybe the empty palette it what I'm thinking of, I'll check on a current XO-1 os21 build just to make sure later.
18:25 silbe: +1
18:26 silbe: For "Disable all wireless devices" option is this actually for powering down the HW, or just to have NM ignore it. Just wondering how this relates to the current CP network/power settings (e.g. would we plan to drop the CP settings and 'move' the concept to the device frame icon).
18:31 silbe garycmartin: It should power down the device, but at least for NM 0.8 it does not yet. I've seen rfkill mentioned together with NM 0.9, so it might already be implemented. Or we might need to tweak something on the kernel side to make it work on XOs; I don't know yet.
18:35 garycmartin silbe: OK. Hmmm, so if I set the current CP Network module to turn off wireless radio power, the frame wireless icon should vanish (goes to try)?
18:36 lucian has quit IRC
18:37 silbe garycmartin: good question; I'll check
18:37 garycmartin silbe: grey circle, with a blank empty palette.
18:38 silbe garycmartin: yup :)
18:38 note that it doesn't actually power down the device either
18:39 garycmartin hmmm, unfortunately when you pop radio power back on again, it goes into a mesh search first. My AP still isn't showing in neighbourhood....
18:39 silbe so it's probably the same functionality that I'd like to expose in the Frame
18:39 lucian <lucian!~lucian@78-86-217-168.zone2.bethere.co.uk> has joined #sugar-meeting
18:40 garycmartin ....and there it is (AP), unfortunately the mesh cycle has completed and the XO is now on Mesh 1.
18:40 silbe garycmartin: one of the reasons I'd like to a) get rid of mesh support entirely and b) move the ad-hoc auto-connection code to NetworkManager.
18:41 garycmartin ...using the mesh disconnect item from the frame device makes the frame mesh icon vanish! Interesting ;)
18:41 silbe hu?
18:41 sounds like a bug
18:41 what version of Sugar is this?
18:42 not that I care too much ;)
18:43 garycmartin yep. Ok after a delay the mesh device icon has now re-appeared (should never have gone away). And the AP device icon is now coloured as per my network, but not connected, oh joy.
18:43 I'm testing on an XO-1 with os21, reports Sugar as 0.92.1
18:44 silbe interesting. so maybe some of the recent weirdness wasn't my NM support refactor attempts...
18:45 garycmartin Mesh is now in a cycle where the mesh device icon appears, pulses for a bit, and then vanishes again (always trying to connect to Mesh Network 1 and none of the others).
18:46 goes to click his AP icon to see if it'll manually re-connect there.
18:46 silbe garycmartin: if you can reliably reproduce a situation where the device icon in the Frame and NetworkManager get out of sync, please file a ticket, including output of nm-tool and full syslogs (/var/log/messages on Fedora I guess).
18:46 garycmartin: same with any other weirdness of course
18:46 garycmartin :)
18:47 Connected fine to my AP when I clicked, no more mesh device attempts appearing in the Frame.
18:48 OK, back on topic.
18:48 silbe I'd like us to reengineer most parts of the NM client code for 0.94 (it's been "extended" one too many times), but we still need to support 0.92...
18:48 ok, let's discuss future design again.
18:49 garycmartin silbe: for "GSM = Modem device palette (frame)" I've only seen screenshots of the current GSM support and the CP settings module, and have no devices I could test with anyway. As I remember there is only one page of configuration settings, so if you have two separate GSM modems with different configuration needs and/or different mobile operator connection details (more likely), you currently need to re-edit the settings each time you switch.
18:51 silbe garycmartin: that's my understanding as well and I don't have any device to test with yet either
18:53 garycmartin Hmmm. It's beginning to dawn on me that we may want to use the CP as the UI/location for many of these new dialogues/credential input pages. I'm remembering how Eben was often mentioning how he wanted things like device frame icons to link to specific CP modules.
18:54 silbe Makes sense.
18:56 this will be "fun" to implement ;)
18:56 garycmartin always seemed a sound idea, and perhaps raising a CP AP module, (or Modem module) directly for might be the way to implement the extra UI needs.
19:00 silbe garycmartin: we could show a generic connection list in the CP; if we trigger adding a new configuration (for an as-of-yet unknown AP) we simply pre-fill the SSID.
19:01 garycmartin: not clear on the complete design yet (esp. adding / editing connections), but I'm sure we'll come up with something workable.
19:01 garycmartin: just for reference, you could take a look at nm-connection-editor.
19:04 garycmartin has quit IRC
19:10 garycmartin <garycmartin!~garycmart@78.150.254.219> has joined #sugar-meeting
19:10 garycmartin silbe: sorry network fell over I think.
19:11 silbe: Well I think I'll need to wrap up now anyway – hopefully the logs will help clarify some points and get the ball rolling (need more folks eye balls before making any real decisions).
19:13 silbe: I'll reply to your email later and link to the meeting logs here, hopefully will get some more feedback offline.
19:14 silbe garycmartin: ok, thanks! Should we try to do some summary already so the others only need to chime in whether they have better ideas?
19:15 (re-reading what you wrote I guess the answer is "no, not yet")
19:16 garycmartin silbe: What would be good to pull together is a page with screen shots of the current related UIs so we are all on the same page as where we are now and where we want to be.
19:18 silbe: I'll try to write more in email reply than just a link to the meeting logs, so folks have an idea where our discussion went.
19:19 silbe garycmartin: ok, I'll try to collect some screenshots. Maybe tch or m_anish can do the ones for the GSM device...
19:19 garycmartin silbe: OK have to go, thanks for helping explain your email details!
19:19 silbe garycmartin: looking forward to your mail.
19:19 garycmartin #endmeeting
19:19 meeting Meeting ended Sun Jun  5 19:19:48 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot. (v 0.1.4)
19:19 Minutes: http://meeting.sugarlabs.org/s[…]-05T16:17:34.html
19:19 Log:     http://meeting.sugarlabs.org/s[…]11-06-05T16:17:34
19:20 silbe garycmartin: thanks for joining the meeting & have a nice evening!
19:20 garycmartin silbe: Thanks you too. BTW think there are some screenshots kicking about the wiki (but not sure how current they are now).
19:21 garycmartin has quit IRC
20:00 silbe has quit IRC
20:20 lucian has quit IRC
20:22 lucian <lucian!~lucian@78-86-217-168.zone2.bethere.co.uk> has joined #sugar-meeting
22:03 yama has quit IRC
22:09 yama <yama!~yama@124-168-21-248.dyn.iinet.net.au> has joined #sugar-meeting
22:09 yama has quit IRC
22:09 yama <yama!~yama@ubuntu/member/yama> has joined #sugar-meeting
22:31 dirakx1 <dirakx1!~dirakx1@190.156.115.38> has joined #sugar-meeting
22:31 RafaelOrtiz has quit IRC
23:24 tch <tch!~tch@190.23.85.180> has joined #sugar-meeting

 « Previous day | Index | Today | Next day »     Channels | Search | Join

Powered by ilbot/Modified.
Webmaster