« Previous day | Index | Today | Next day » Channels | Search | Join
All times shown according to UTC.
Time | Nick | Message |
---|---|---|
00:28 | cjl_afk is now known as cjl | |
00:50 | CanoeBerry <CanoeBerry!~CanoeBerr![]() |
|
01:12 | tch has quit IRC | |
01:22 | RafaelOrtiz has quit IRC | |
01:22 | RafaelOrtiz <RafaelOrtiz!~dirakx1![]() |
|
01:29 | tch <tch!~tch![]() |
|
01:45 | tch has left #sugar-meeting | |
04:31 | CanoeBerry has quit IRC | |
05:23 | CanoeBerry <CanoeBerry!~CanoeBerr![]() |
|
05:42 | RafaelOrtiz has quit IRC | |
05:42 | RafaelOrtiz <RafaelOrtiz!~dirakx1![]() |
|
06:23 | cjl has quit IRC | |
07:33 | yama has quit IRC | |
07:39 | yama <yama!~yama![]() |
|
07:39 | yama has quit IRC | |
07:39 | yama <yama!~yama![]() |
|
07:41 | tch <tch!~tch![]() |
|
09:05 | tch has left #sugar-meeting | |
10:52 | lucian <lucian!~lucian![]() |
|
11:04 | cjb has quit IRC | |
12:46 | yama | is the Dextrose meeting on soon? |
13:07 | http://wiki.sugarlabs.org/go/Dextrose/Meetings says that these meetings are on at Saturday at 14:00 GMT | |
13:07 | which is now | |
13:07 | is that incorrect? | |
13:07 | no wait, it's in an hour | |
13:16 | Google Calendar thinks GMT is London time :( | |
14:01 | silbe <silbe!~silbe![]() |
|
14:05 | yama | hi silbe |
14:05 | silbe | yama: hey! :) |
14:05 | yama | is the meeting on? |
14:06 | silbe | is there a meeting today / now-ish? I didn't see an announcement, but OTOH there was an announcement the last week but no meeting... |
14:06 | ok, so you don't know either... bernie, m_anish, dfarning_afk? | |
14:08 | yama | http://wiki.sugarlabs.org/go/Dextrose/Meetings says that these meetings are on at Saturday at 14:00 GMT |
14:08 | I assumed that was every week | |
14:08 | silbe | yama: they were until EduJam. We haven't had a single meeting since then :-/ |
14:08 | yama | I've been hanging out for the meeting... it's 12am here :/ |
14:12 | silbe | yama: don't stay up just for us... bernie asked about moving the meeting by one hour last week, so it could get 01:00 until it starts even if it happens at all. I'll make sure we take you into account when reconsidering the time. |
14:13 | yama | thanks silbe. Working with Sugar/OLPC people can be hard since most are on the other side of the world from me. |
14:13 | silbe | yama: I don't expect a productive meeting anyway; it's been too long since we last synced. |
14:14 | yama | I have a lot I need to talk about, as we plan our migration to Dextrose |
14:14 | silbe | yama: I'm quite glad I'm in the "middle". It's hard even for me at times. |
14:14 | yama | silbe: where are you based? |
14:16 | silbe | yama: If you like we can start chatting a bit. It would give us some idea of what we should discuss in more detail another time. We could also do a special meeting just for you (i.e. OLPC-AU). Might even be better than mixing it with our weekly coordination meeting. |
14:16 | yama: Germany | |
14:17 | yama | silbe: thanks, that sounds good. I' |
14:17 | silbe: I'll raise my main points | |
14:18 | an OLPC-AU meeting would be really good as well | |
14:18 | silbe | yama: what time and day would suit you? |
14:20 | yama | silbe: 00:30:00 to 13:00:00 UTC would be best |
14:20 | not sure how that crosses into your time | |
14:23 | silbe | yama: currently 02:30 - 15:00 local time, so the upper(?) end would be better. Those located in the Americas might prefer the first time, though. We'll figure something out. |
14:24 | yama | silbe: It's difficult finding a time that's sane for everyone :/ |
14:25 | silbe: but if you could let me know, that would be great. I have lots of availability this week. I just can't do 7 June (Australian EST). | |
14:26 | silbe: I'll e-mail through an agenda | |
14:26 | silbe | yama: It's impossible. Someone will always have to adjust. All we can do is try to reduce the number of people the time is bad for and / or do round-robin. |
14:27 | yama: Great! I'll follow up with the others to organise a meeting for you. | |
14:28 | yama | silbe: thanks! Let me know how you go. |
14:29 | silbe | yama: certainly |
14:32 | icarito_ <icarito_!~webchat![]() |
|
14:35 | icarito_ is now known as icarito | |
14:38 | icarito | silbe: hi I finally managed to try your xdg-desktop patch |
14:38 | :-) | |
14:39 | silbe: gave me lots of ideas | |
14:40 | silbe: i'm running sugar as my DE now | |
14:40 | and I *really* want Alt+Tab | |
14:40 | its my main blocker | |
14:40 | atm | |
14:41 | yama | Alt+Tab works on XOs |
14:41 | silbe | icarito: while I was ill I got notion (successor of ion3) to work with Sugar. Not well (yet), but the basic functions work. |
14:41 | yama | what's this patch? Sounds interesting |
14:41 | icarito | interesting |
14:42 | about xdg-desktop items I think a list view with an option to favorite apps into favorites view would be more logical | |
14:42 | about alt-tab here's something http://dev.laptop.org/ticket/10693 | |
14:44 | silbe: it does seem metacity is not the right wm | |
14:44 | the integration of non-sugar apps is not very nice | |
14:44 | silbe | icarito: the metacity bug got fixed upstream, IIRC dsd even got the fix included in OLPC builds now. I should do a new build so we can test. |
14:44 | icarito | ok so I'll try to update my metacity |
14:45 | silbe | yama: https://patchwork.sugarlabs.org/patch/717/ |
14:45 | yama: It's a proof-of-concept for starting non-Sugar (but XDG-compliant) applications from the Sugar Favourites View | |
14:46 | yama | silbe: we really need something like that :) |
14:47 | I've got activities created to run GNOME apps that we need (http://dev.laptop.org.au/issues/434 and http://dev.laptop.org.au/issues/430) | |
14:47 | silbe | icarito: There are several design options we could try. Separate list views for XDG + Sugar, but shared favourites layout, or separate list views and favourites layouts, or even list view and favourites layout shared between XDG and Sugar. |
14:48 | yama | silbe: but the activity loading screen remains in the background for a good one and a half minutes after the app loads |
14:48 | making it easier to run normal Linux apps properly would be brilliant | |
14:49 | silbe | yama: yeah, that's another item on my list (http://wiki.sugarlabs.org/go/User:Sascha_silbe) that I didn't get around to work on yet. |
14:49 | yama: https://bugs.sugarlabs.org/ticket/2434 | |
14:50 | yama | silbe: what do you think it would take to bring this to production? |
14:51 | silbe | BTW, re. cookie-licking: Anybody is invited to work on anything on that list. It's my vision of which direction I imagine Sugar to go near to medium term. There's much more on that list than I can personally work on. |
14:51 | yama | silbe: because maybe I can find a resource for it |
14:51 | (no promises, but possibly) | |
14:53 | silbe | yama: this particular ticket should be about a week of work, depending on how well the person already knows GTK, the XDG startup notification protocol and especially the Sugar Shell. The nice thing is that the client side is already done because GTK does it by default. |
14:54 | yama: maybe even just a couple of hours, but I tend to underestimate the amount of work required. | |
14:54 | yama | silbe: haha don't we all :) |
14:55 | silbe | yama: it's an epidemic :) |
14:55 | yama | silbe: from what I can tell, this is the main thing stopping standard Linux apps from running on Sugar |
14:56 | silbe: Would that be fair to say? I'm just trying to gauge the priority of this. | |
14:57 | silbe | yama: There's an entire scale of "running" inside Sugar. But without a working libsugarize, this particular one is at least an obvious annoyance. |
14:59 | yama: check out the Rainbow -> "legacy sessions" part of my list to get some idea on what else we could do to integrate non-Sugar applications into a Sugar workflow. | |
15:02 | yama | silbe: honestly I never really understood what Rainbow does (I did read the description at wiki.laptop.org). Why do we need it when normal Linux distros don't have it? |
15:02 | silbe | yama: Journal integration is a major step. Depending an the actual application, there's a variety of easy-enough things to do. Setting $HOME and zipping it up on exit / unzipping on resume would be a good start. |
15:04 | yama: Rainbow is an isolation shell. It restricts what each activity can do. It allows you to safely run potentially dangerous programs. They don't have to be malicious - genuine mistakes can clean out your entire $HOME. | |
15:05 | yama: Incidentally I use Rainbow only outside of Sugar: To run GUI browsers (with JavaScript enabled) or to run software I don't trust too well. | |
15:05 | yama | silbe: ok, so Rainbow sounds similar to what Android does |
15:05 | (in concept) | |
15:06 | silbe | yama: I don't really know what Android does, but I've seen some slides about Chromium that showed something similar to Rainbow. |
15:06 | yama | silbe: how much does Sugar actually use Rainbow? Does it need Bitfrost to be active? |
15:09 | silbe: I was thinking tch's and walter's work on mounting ~/Documents as a volume would be temporary measure to making Linux apps work with Sugar | |
15:10 | reduces pressure to implement object chooser in gtk | |
15:10 | silbe | yama: Unfortunately current versions of Sugar don't work with Rainbow. There are some technical issues (https://bugs.sugarlabs.org/que[…]mponent=Rainbow); some are trivial, others involve compromises and a moderate amount work (e.g. https://bugs.sugarlabs.org/ticket/2460). |
15:11 | yama: we also have datastore-fuse that works the other way, but nobody seems to be interested in it. | |
15:12 | yama | silbe: I didn't know about that. Do you have info? |
15:12 | silbe | yama: BTW: Bitfrost is the name of the specification; Rainbow is an implementation of some part of the spec. Some Python modules used for secure booting and anti-theft seem to be named bitfrost, too, which is causing some confusion. :-/ |
15:12 | yama: http://git.sugarlabs.org/datastore-fuse | |
15:14 | yama | silbe: datastore-fuse looks like a good idea! We use both Sugar and GNOME, and sharing data between them is a pain. |
15:14 | silbe | yama: it's not perfect, but with a total lack of feedback I just can't justify working on it. There are other important issues to work on that generate more responses. |
15:15 | yama | silbe: what would you recommendation to share files between Sugar and GNOME, and what do you think it'll take to bring it to production? |
15:16 | silbe: because maybe we're interested :) | |
15:18 | silbe | yama: Walters Documents-folder-in-Journal patch is a good interim measure. Easily understood, time to roll out into the field is bounded. datastore-fuse is the way to go medium to long term, but requires some effort till it works really well. |
15:18 | lucian has quit IRC | |
15:19 | silbe | yama: the disadvantage of the Documents-folder-in-Journal approach is that it only works from inside Sugar. |
15:19 | lucian <lucian!~lucian![]() |
|
15:19 | yama | silbe: which isn't necessarily a bad thing since we want to encourage people to use Sugar most of the time anyway :) |
15:20 | silbe | yama: good point. Though long-term I intend to blur the distinction between them anyway. |
15:22 | yama | silbe: yes that's better in the long run. Basically what I look for in solutions is 1) what can we do soon, and 2) what is the proper solution |
15:22 | silbe | yama: +2 (i.e. +1 on both) |
15:23 | yama | silbe: any idea on where Documents-folder-in-Journal is at? That was actually on my list of things to raise at the meeting. |
15:26 | silbe | yama: Walter posted it on sugar-devel. It didn't make it onto https://patchwork.sugarlabs.org/ because it a) was in an attachment and b) used the wrong MIME type (application/octet-stream). The Message-ID of the latest version is <BANLkTim3LApsbWPJ6n1gi326Je+02Yirxg![]() |
15:26 | Subject: Re: [Sugar-devel] [PATCH] adding $HOME/Documents to the volumes toolbar | |
15:28 | yama | silbe: found it, thank you |
15:28 | silbe | yama: yw |
15:29 | yama | silbe: that'll be in my list of things I want to talk about at our meeting. GNOME-Sugar compatibility is important to us. |
15:30 | silbe | yama: it's important to all of us. The interesting points are how important the individual pieces are and who's going to work on them. |
15:31 | yama | silbe: the impression I was getting was that GNOME isn't used or wanted much in the main deployments, so it wasn't getting attention |
15:31 | silbe | and some times which solution is better, of course :) |
15:32 | yama | silbe: GNOME isn't even part of DX2, but we'll need it if we start basing our OS on DX3 |
15:32 | silbe | yama: It's often used by the teachers, instead of Sugar. That's also something I hope to reduce by blurring the distinction. The teachers shouldn't have to use the Gnome GUI just to use some applications that are not sugarised. |
15:33 | cjl <cjl!~chatzilla![]() |
|
15:35 | silbe | yama: There are DX2 images both with and without Gnome, on both XO-1 and XO-1.5. The problem is that the additional parts of Gnome take up most of the free space on XO-1s. |
15:36 | yama | silbe: yes I saw those. They are listed as "unsupported", which had me worried |
15:37 | silbe | yama: So deployments that don't have XO-1.5s exclusively are in a tricky situation of either reducing the already rather sparse space on XO-1s even further or making the XO-1s second-class by not including Gnome on them. |
15:38 | yama: Gnome is unsupported because we don't have the resources to support it. It doesn't mean it doesn't work, just that we're focussing on supporting Sugar. | |
15:38 | yama | silbe: I think we might be a bit odd in that we're focusing on XO-1.5s. We have about 300MB space free on our XO-1 builds, which include GNOME. |
15:39 | silbe | yama: Especially since "Gnome" usually implies a lot of different applications. Sugar is "Gnome" is some sense, too, because we're building on the same libraries. |
15:41 | yama | silbe: understood. I'll have to discuss with AC what we can do to get that changed :) |
15:43 | silbe | yama: A good start would be to define some subset of "Gnome" that you're most interested in. |
15:44 | yama | silbe: fair enough. It is a gargantuan beast. |
15:44 | silbe | yama: There might even be different solutions depending on the subset. E.g. if it's just a few applications, sugarising them would be easier than supporting failure-recovery for a full Gnome session. |
15:46 | yama | silbe: Interesting point. Although in our case we need the desktop environment. We've been using that as a selling point for the older kids. |
15:48 | silbe | yama: I'd like to find out more about why they prefer Gnome over Sugar. Is it just marketing (Gnome for adults and Sugar for kids) or are there actual benefits? |
15:49 | yama | silbe: honestly, I think it's mainly marketing. But we're at the stage where removing GNOME would constitute a regression. So we're stuck with it now. |
15:51 | silbe | yama: ok, good - in the sense that I'm on the right track re. Sugar/Gnome integration, making them work better with each other. |
15:52 | yama | silbe: yes. For example, teachers have been interested in the Ooo4Kids activity (http://activities.sugarlabs.or[…]sugar/addon/4241). But it's not too useful because it can't access the journal. |
15:53 | silbe: with the Documents-folder-in-Journal patch, you could save to ~/Documents, and still access it in Sugar | |
15:54 | silbe | yama: because Ooo4Kids is specifically built for Sugar, adding Journal integration shouldn't be too hard. We don't need to rely on LD_PRELOAD hacks to do it. |
15:55 | yama: and as you point out, the Documents-folder-in-Journal patch is an acceptable interim measure. | |
15:55 | yama | silbe: how hard is it typically to add journal support to an app? |
15:55 | silbe: i.e. how much effort is required? | |
15:57 | silbe | yama: I can't tell because I never tried, but assuming the application already uses dbus and is well-behaved in general, it should only be a matter of replacing those parts of the code that use the GTK FileChooser and triggering auto-save on window-switching. |
15:58 | yama: A wild guess would be about a week again ;) | |
15:59 | yama: TBH I'm surprised it doesn't have Journal integration yet. Maybe we should ask them why, i.e. whether they tried and hit some issue. | |
16:01 | yama | silbe: I already did. It seems their focus for now is on cross-platform compatibility rather than optimisation for one platform. |
16:04 | silbe | yama: Sounds like they're only interested in the XO and consider it as a hardware platform that just happens to run some "weird" software. :-/ |
16:05 | yama | silbe: that might well be the case :S Maybe when they have more time they can come back and give it more love for Sugar. |
16:07 | silbe | yama: maybe they'd accept a patch if somebody else works on it. |
16:07 | wow, the source must be huge. It's still busy checking out... | |
16:08 | yama | silbe: I'm considering that. Although if Documents-folder-in-Journal does the trick we might leave it there. We can spend our resources on other concerns. |
16:09 | silbe | yama: agreed. |
16:09 | yama | silbe: OpenOffice and Firefox are the main apps in use in GNOME. |
16:10 | silbe: we recently had Browse fixed, so that's good | |
16:10 | silbe | yama: There's already a Firefox activity, BTW. |
16:11 | Not sure how well it is integrated and how well it works, though. | |
16:11 | yama | silbe: it's very old |
16:11 | silbe: looking forward to Surf | |
16:11 | silbe | oh, so it contains binary blobs? :-/ |
16:11 | yama | silbe: it's based on FF3.0 I think |
16:13 | silbe | yama: me too, but it's going to be a lot of work and so far the only person both compentent enough and willing to do the work is lucian... |
16:13 | lucian | tends to miss meetings ... |
16:14 | silbe | lucian: dfarning_afk, bernie and m_anish too it seems :-/ |
16:14 | yama | the main problem we've been dealing with lately is that the schools use automatic proxy configuration (a PAC/WPAD file), which require authentication. |
16:15 | lucian | silbe: btw, i finished uni, likely (unless i'll fail some exams) |
16:15 | yama | Sugar can't handle that since it uses http_proxy instead of networkmanager |
16:15 | lucian | i'm doing GSoC for parrot, but i should have time to do some Surf work |
16:15 | .pac is a bit of a pain in the ass, yes | |
16:16 | silbe | yama: at least if configured that way, Browse does support automatic configuration via WPAD. What exactly is the problem? |
16:16 | yama | that Browse works (since it gets the proxy from gconf), but other activities can't get online |
16:16 | browse 122 is fine now | |
16:16 | Sugar is not :( | |
16:17 | ^-- silbe | |
16:17 | silbe | yama: ah, I see. |
16:18 | yama | we've got a patch in our Sugar to write the gconf setting to http_proxy, but that doesn't work with pac files |
16:20 | silbe | yama: if the PAC isn't too complex, you could try interpreting it in a NetworkManager hook. |
16:21 | yama | silbe: I think there's a lot in there, and it prompts for a user name and password |
16:22 | silbe: I'm hoping that gets addressed as Sugar starts supporting NetworkManager 0.9 and gconf better | |
16:22 | silbe | yama: running a minimal proxy locally would help with changing locations while the laptop is powered up. Let applications connect to the local proxy and the proxy connect to the "outside" proxy. |
16:22 | yama | silbe: that's an interesting idea! |
16:23 | silbe | yama: This isn't something that NM 0.9 does differently AFAIK. And Sugar itself already uses gconf (almost) exclusively. |
16:24 | yama: what activities exactly are you having trouble with? I.e. which ones need internet access? | |
16:24 | yama | silbe: admittedly my experience with Sugar is with 0.84 :S |
16:25 | silbe: Software Update is the main one. Also Get Books, Read ETexts, etc. | |
16:25 | silbe | yama: IIRC we haven't changed much since 0.84 in that regard. Only 0.82 stored configuration in a custom format. |
16:26 | yama | silbe: does the latest sugar version still get its proxy from http_proxy? |
16:26 | silbe: even if it doesn't support pac files, it'd be nice if it got its proxy from gconf. | |
16:27 | silbe | yama: Software Update is something we should easily be able to add proxy support using the GConf settings to. Can you check if there's a ticket for that already and if there isn't file one, please? |
16:27 | yama: "Sugar" doesn't get its proxy from anywhere currently - if we happen to evaluate http_proxy, it happens inside some component we use, probably Python. | |
16:28 | yama | silbe: so there's no global setting for the whole environment? |
16:29 | silbe | yama: we don't provide a custom network library, so no, there's no global setting. |
16:29 | yama | silbe: http://bugs.sugarlabs.org/ticket/2821 - turns out I created it |
16:30 | silbe | yama: Browse is based on xulrunner (Mozilla) which in turn already uses the Gnome proxy settings by default: http://lists.sugarlabs.org/arc[…]nuary/029624.html |
16:31 | yama | silbe: yes I'm aware of that. What I didn't know is that there's no unified proxy setting for Sugar. |
16:32 | silbe | yama: thanks! Maybe m_anish can work on proxy support for the Software Updater, he's written the new one (not upstream yet). |
16:33 | yama: well, in a way there is: The Gnome GConf settings. Some parts of Sugar simply don't use them yet. ;) | |
16:36 | yama: I guess someone should investigate whether there's some Python binding for the Gnome libraries that implement the HTTP support (libsoap?) and if it's reasonably easy to use. If so, we could simply switch from the native Python modules to this Gnome library. | |
16:36 | lucian | silbe: that implies pygi |
16:37 | but i don't think switching to libsoap is necessarily a good idea | |
16:37 | i thought nm supported .pac, doesn't it | |
16:37 | silbe | lucian: so there's no old-style (e.g. SWIG-based) Python binding for libsoup (not libsoap, my bad)? |
16:38 | lucian | silbe: no generated bindings for libsoup, no |
16:38 | it's one of the reasons Surf has no cookie support | |
16:38 | silbe | lucian: any specific reason why not? |
16:38 | lucian | silbe: gnome people point to gobject-introspection |
16:39 | silbe | lucian: I meant why not to use it. So it lacks important features? |
16:39 | lucian | silbe: pygi? not anymore, afaik |
16:39 | but at the time, it was very deficient | |
16:39 | silbe | if so, adding explicit GConf support might be the better way. |
16:39 | lucian: no, libsoup I mean | |
16:40 | lucian | oh, reason not to use libsoup? it's not native python |
16:40 | an extra dependency, etc | |
16:40 | silbe | lucian: a dependency we've already been shipping for a long time |
16:40 | (except for the non-existing Python binding of course) | |
16:41 | lucian | i don't see an advantage over just reading proxy settings somewhere |
16:41 | python's urllib also looks for proxy settings somewhere, perhaps sugar's shell could make sure urllib finds them | |
16:41 | silbe | lucian: You're the expert, I trust you on this. So explicit support for GConf it is. |
16:42 | lucian | silbe: uh, i'm not an expert :) |
16:42 | silbe | lucian: that's the http_proxy setting mentioned above. The drawback of environment variables is that you can't change them (globally) at runtime. |
16:42 | lucian | i think python's urllib looks for http_proxy, and maybe gconf in gnome? don't know |
16:43 | silbe | lucian: in this case you are :) |
16:43 | lucian | i mean, activities need explicit proxy support anyway |
16:43 | it seems easier (and less complex) to read gconf settings and go on using python's libs | |
16:43 | silbe | lucian: the Python standard library doesn't have gconf support AFAIK, so it couldn't have support for using the Gnome proxy settings. |
16:43 | lucian | than to change everything to libsoup |
16:44 | silbe | lucian: for the existing activities, yes. But if libsoup were easy enough to use it wouldn't make a difference for new activities and we might get other benefits over time. |
16:45 | but that's something to consider once we actually live in a pygi world, not before. | |
16:45 | lucian | silbe: perhaps, i'm sceptical at this point. i should have a clearer opinion after i play with libsoup in Surf |
16:45 | yama | would this be useful? http://code.google.com/p/pacparser/ |
16:46 | silbe | lucian: looking forward to it, no matter what the result turns out to be. |
16:46 | lucian | so there's 1) read gconf proxy settings, use python libs. depends: gconf or 2) use libsoup. depends: gconf, pygi, libsoup |
16:48 | silbe: sugar-toolkit could monkey-patch urllib2 to change the default proxy handler http://docs.python.org/library[…]lib2.html#urllib2.ProxyHandler | |
16:48 | silbe | yama: sounds like it would be useful for the NetworkManager hook. It'd still have issues with the interactive credentials prompt, of course. |
16:48 | lucian | slightly evil, but it'd work transparently |
16:49 | silbe | lucian: interesting. We could provide an alternative ProxyHandler implementation that activities could use. |
16:49 | lucian | the problem with PAC is that the only real way to fully support it is to eval the JS in a browser |
16:49 | silbe: or that | |
16:49 | yama | how do non-browser applications behave when the come across a proxy that has an interactive credentials prompt? |
16:50 | lucian | yama: die gallantly, most of the time |
16:50 | yama | ugh I was afraid of that |
16:50 | lucian | i may be wrong. i'd be glad if i were |
16:50 | silbe | lucian: we've been bitten by silently changed "implementation details" (that I considered to be public API) in the past, so I'd be careful about doing the monkey-patching in sugar-toolkit. |
16:51 | lucian | silbe: yes, which is why i mentioned it's slightly evil |
16:51 | but providing a proxyhandler is a good idea, and pythonic too. requiring libsoup would surprise most python devs | |
16:53 | yama | ideally there should be a UI for entering the proxy too |
16:53 | because right now we're getting users to switch to gnome | |
16:53 | lucian | i thought networkmanager supported pac with a JS interpreter? or was that just a plan? |
16:53 | yama | just to enter the proxy, then they switch back |
16:54 | silbe | yama: depends on how they get their proxy settings in the first place. The Gnome GConf settings don't support interactive prompts. Most applications that support using PAC files are probably browsers and would show the prompt. I'm not sure how the prompts are done in the PAC, but I'd expect them not to be implemented in generic JavaScript software like for pacparser. |
16:54 | lucian | yama: i agree, that's a good fallback |
16:55 | silbe: the one i've seen was just JS, so needed eval | |
16:55 | but an expert opinion would help | |
16:55 | silbe | yama: you could ship a ControlPanel section. Just put the file into /usr/share/sugar/extensions/cpsection . |
16:56 | yama | silbe: is it that simple - just drop a file in the directory? Do you have any info on that? |
16:58 | silbe | yama: it's explicitly designed that way. The existing Control Panel sections all work that way. I was slightly wrong, though: You need to use a subdirectory, not a single file. |
16:59 | yama | silbe: could we (as a short-term fix) use it to launch gnome-network-properties? |
17:00 | right now I have that implemented as an activity launcher | |
17:00 | silbe | yama: I don't think so, no. But you could do an activity wrapper for it. |
17:01 | yama: long term I'd like to try replacing the Sugar Control Panel code with something based on the Gnome one. But that won't help you right now. | |
17:02 | yama | http://code.google.com/p/libproxy/ looks good |
17:04 | oh wait... "Because proxy authentication is protocol specific, it is outside the scope of this library. libproxy tells you WHICH proxy servers to try to use, not HOW to use them." | |
17:04 | but it looks really good for everything else | |
17:04 | lucian | yes, it does |
17:04 | perhaps nm should use it :) | |
17:05 | silbe | yama: it doesn't support interactive prompts either |
17:06 | if it weren't for the interactive prompt, the obvious solution would be to add GConf support to applications and activities and adding proxy settings support to NetworkManager... | |
17:08 | lucian | wishes we could just tell them to take their interactive prompts and stuff them where the sun don't shine :) |
17:08 | yama | I think the quote I provided above means that it's going to be basically impossible to support interactive prompts |
17:08 | lucian | sadly, lots of networks do it |
17:09 | yama | In the main school system we're working in, I convinced them to give us a normal proxy host to use for non-browser stuff |
17:09 | it's restricted in what it can access, but at least it works | |
17:09 | then we use the wpad file for browse and firefox | |
17:10 | silbe | yama: it's definitely problematic at best. You couldn't run background jobs (e.g. the yum updater) until after the user has entered the proxy credentials... |
17:10 | lucian | is there a reason they want authentication? |
17:10 | yama | lucian: I think they want to track what each child is looking at |
17:10 | icarito has quit IRC | |
17:10 | yama | lucian: and also provide different permissions to teachers, etc. |
17:10 | silbe | yama: you could sniff the credentials once using tcpdump and save them for later use. ;) |
17:11 | yama | hehe |
17:11 | silbe | yama: is that even legal? (privacy concerns) |
17:11 | yama | I think in practice, teachers will just use the same credentials for all XOS |
17:11 | lucian | yama: i guess telling them that's a little evil and very useless won't convince them to stop |
17:11 | yama | silbe: child protection is considered to be more important |
17:12 | lucian | but... that won't work |
17:12 | yama | silbe: better to stop them looking at porn or being subjected to online predators |
17:12 | lucian: maybe true, but that's not our decision :( | |
17:12 | silbe | yama: "protection" seems to be a subjective thing... :-/ |
17:12 | yama | silbe: indeed :S |
17:12 | lucian | true. even if they want to do that, there are better ways |
17:12 | they should use no proxy by default and do filtering | |
17:13 | if someone wants to remove the filtering, they need to use a proxy, with auth | |
17:13 | that way, they can't track individual children, but can still "protect" them | |
17:13 | silbe | yama: do they log the full traffic, not just the URLs? Otherwise I don't see how it'd help with "online predators"... |
17:13 | lucian | and teachers can look at porn all they want |
17:14 | yama | I have no idea what or how they're doing it |
17:14 | silbe | ok |
17:14 | yama | but the creepy part is that it's done by a third party |
17:14 | silbe | yama: !?! |
17:14 | lucian | wtf |
17:14 | yama | a company called Blue Coat |
17:15 | silbe | yama: so they're legal o |
17:15 | yama | they do the filtering for most of the schools in the country |
17:15 | silbe | yama: so they're legal "online predators"? |
17:15 | yama | I suppose so :( |
17:15 | lucian | my uni does it, and it's semi-legal. but they'd get sued out of existence if they outsourced it |
17:15 | yama | I'm not agreeing with it, but it is a reality that we have to work in |
17:16 | lucian | yama: indeed |
17:16 | silbe | yama: yup, we should get back on track. |
17:17 | lucian | yama: after auth in a browser, does the proxy work without auth? |
17:17 | silbe | yama: considering the time, is there anything left you'd like to discuss right now? |
17:18 | cjl | yama, Blue Coat is a pretty well known name in edge protection and WAN optimization. |
17:18 | yama | lucian: the wpad doesn't work without auth. I've got them to provide an alternate URL that we can use for http_proxy, but it has more restrictions on it. |
17:18 | RafaelOrtiz has quit IRC | |
17:19 | dirakx1 <dirakx1!~dirakx1![]() |
|
17:19 | yama | and that's in only one school system. I don't know how the others will go. Maybe they'll mandate the wpad only. |
17:19 | and they use blue coat too | |
17:20 | silbe: I think tch was working on getting WebDAV working? | |
17:21 | basically, we need a way for teachers to easily share files with their class | |
17:21 | we can probably ask the admins to activate WebDAV on their files servers | |
17:21 | dfarning_afk is now known as dfarning | |
17:22 | silbe | yama: we talked about it, yep. Not sure how far he got. We should add it to the agenda of the OLPC-AU / AC meeting. |
17:22 | yama | would be really nice if we could mount a WebDAV volume in Sugar |
17:23 | dirakx1 has quit IRC | |
17:24 | yama | silbe: will do |
17:24 | where do recent releases of Sugar store their network connections settings? | |
17:25 | are they still managed in its own file, or are they system settings? | |
17:25 | storing the connection as a system setting will allow sharing with GNOME | |
17:25 | silbe | yama: BTW, you could try something like fusedav or davfs2 in the meantime. It probably has the usual issues of network file systems (i.e. not coping too well with non-permanent connectivity) and performance wouldn't be perfect either, but it should work right now. |
17:26 | yama | silbe: martin langhoff suggested WebDAV because it deals better with intermittent connectivity. But nothing is perfect. |
17:27 | silbe | yama: Sugar 0.92+ is still based on NM 0.8 and using User Settings. Porting to NM 0.9 will require significant effort. It's also something I still need to write a mail about so we can discuss tomorrow during the Design Team meeting. To support hidden SSIDs and other non-trivial scenarios we need some design changes. |
17:27 | lucian | afaik WebDAV is a superset of http, so it's as stateless |
17:28 | silbe | yama: WebDAV itself does. Mounting WebDAV as a file system does not necessarily inherit these properties. |
17:28 | yama | silbe: ah, I think I raised the issue of hidden SSIDs at a previous meeting |
17:29 | our solution for now is to load nm-connection-editor, configure the connection, then tick the "Available to all users" box to make it a system connection. | |
17:31 | silbe | yama: does that work well enough for you? I do the same, but because of some Sugar internals it's problematic. I can't activate the connection using Sugar and if I get out of reach it pops up an authentication dialog. It never retries it got into that state; I have to use "nmcli nm sleep ; nmcli nm wake" to make it retry. |
17:31 | The next release of NM might at least fix the latter part (retrying the connection after some time). | |
17:33 | yama | silbe: I haven't seen that, but I haven't tested it too much (we don't talk about system connections to users yet) |
17:33 | silbe: are you saying that you've found system connections to be less reliable than user connections? | |
17:35 | silbe | yama: not in general, just in combination with Sugar - that's the first issue I mentioned. The others are the same for User Settings, but problematic because of the first one. |
17:36 | yama: if you try to activate a connection with Sugar, it will look up the connection in it's own User Settings service (using internal API). | |
17:36 | yama | silbe: what I do is clear the network connections cache in sugar-control-panel. It works better to connect in GNOME first, then set it to be a system setting, then move back to Sugar |
17:36 | silbe: ah, yes that's my experience also | |
17:37 | silbe | yama: this should all be fixed by the NM 0.9 port, but it's a lot of work (as would be fixing the issues individually). |
17:38 | yama | silbe: is there a target release/date for a Sugar version based on NM 0.9? |
17:38 | I understand it's a lot of work, so I don't mean to sound impatient | |
17:38 | silbe | I wanted to write up a draft for the internal architecture of the NM support (inside Sugar) for some time, but still haven't got around to do it. :-/ |
17:39 | yama | I know the feeling... so much to do |
17:40 | silbe | yama: I don't think it'll make 0.94 I'm afraid, we're too late in the release cycle for such major changes. But if somebody starts working on it soon, we can consider shipping it in DX-3. AIUI most deployments see DX-3 as a pre-release for DX-4 anyway. ;) |
17:41 | (i.e. it would be a custom Dextrose enhancement at first and be merged upstream for Sugar 0.96) | |
17:42 | yama | silbe: deployments aren't taking DX3 seriously? |
17:43 | silbe | yama: no, it's a timing issue. They're not upgrading more than once a year. |
17:43 | yama | silbe: yes, we are the same. We want to make our main releases yearly |
17:44 | silbe: and we want to release before school starts in January | |
17:44 | dfarning | silbe what are you using to refer to the Dec 2011 release? |
17:44 | silbe | dfarning: DX-4 |
17:45 | yama | oh I see |
17:45 | I was thinking DX-3 was the Dec release | |
17:45 | when is DX-3 due? | |
17:46 | silbe | yama: it's going to be in parallel with the next OLPC release (11.2.0 IIRC). Let me check the timeline... |
17:46 | dfarning | sible yama this is a communitcation issue. lets start referring to the release in December 2011 as DX12. which will be the 'official' name. |
17:47 | silbe | yama: current target date is July 18th 2011 |
17:47 | dfarning: ok. Sorry, forgot about that (we discussed it before). | |
17:47 | yama | okay DX12 it is |
17:47 | I'm still deciding what to call our release :S | |
17:48 | dfarning | yama it is confusing because from an upstream point of view silbe is syncing with olpc 's next reslease which for dx is a test release. |
17:49 | sorry about that, I'll get back out of your way so you can discuss real issues :( | |
17:50 | silbe | dfarning: you're not in the way. And thanks for reminding me - it would have increased the confusion if I had continued to call it DX-4 instead of DX-12. |
17:50 | yama | dfarning: no I agree, communications are important. Our current build is 10.1.3-au2, which I've found to be too unwieldy to communicate to teachers. |
17:51 | so our next release will have the year as its version number | |
17:52 | silbe | yama: OLPC is basically doing the same - except that they're using 2-digit year numbers, so everyone (well, me at least) confuses them with Fedora release numbers (that are currently in about the same ballpark)... |
17:55 | yama | version numbering is interesting marketing. I used the 10.1.3-au2 style because I wanted tech people to make the association with OLPC OS 10.1.3. But it's more important to be clear with the teachers. Tech people will understand that XO-AU OS 12 is based on Dextrose 12. |
17:56 | dfarning | yama +1 all teacher care about is something very simple like the year. |
17:58 | yama silbe whould you mind stepping back from technical stuff to talk about priorities and how to set them. | |
18:00 | yama | dfarning: did you have anything specific in mind? |
18:02 | we need to work out how to port our work over to DX | |
18:02 | that's something we'll be investigating | |
18:02 | we are also interested in contributing to the testing and QA | |
18:03 | dfarning | yama, I think AC has learned about as much as it can from PY so I would like to see if we can work more closely with AU to help us set our priorities. |
18:04 | yama | dfarning: working with existing network infrastructure is a big one |
18:04 | proxy servers, files servers, etc. | |
18:05 | most of our schools are part of a WAN, with its own resources | |
18:05 | I raised the point earlier about WebDAV | |
18:06 | making Sugar and GNOME work better would be great as well | |
18:06 | *work better with each other | |
18:06 | sharing files, settings, etc. | |
18:07 | on the testing side, our first phase of our testing framework project has just completed | |
18:08 | and we'd like to apply the next phase to Dextrose | |
18:08 | dfarning | let;s take this off list into an email. it seems like you have thought about it alot. |
18:09 | yama | sure |
18:09 | dfarning | sorry for inturpring your meeting :( |
18:10 | yama | No that's fine. It's 4am here so I really need some sleep. silbe and I discussed having a meeting to discuss our needs better. I can send an agenda. |
18:10 | dfarning | yama +1 |
18:11 | yama | dfarning: you might want to read over the backlog of my conversation with silbe and lucian, because it covers a lot of what I wanted to cover. |
18:11 | dfarning | I'll email you my plans -- I will. good night. |
18:12 | yama | okay let's exchange ideas by mail, then we can reconvene and discuss. |
18:12 | dfarning | yama +1 |
18:13 | yama | good night all :) |
18:14 | silbe | yama: good night! |
18:15 | dfarning | good night |
18:18 | RafaelOrtiz <RafaelOrtiz!~dirakx1![]() |
|
18:21 | tch <tch!~tch![]() |
|
18:22 | cjl is now known as cjl_afk | |
20:19 | tch has left #sugar-meeting | |
20:21 | lucian has quit IRC | |
20:21 | RafaelOrtiz has quit IRC | |
20:21 | RafaelOrtiz <RafaelOrtiz!~dirakx1![]() |
|
20:29 | dirakx1 <dirakx1!~dirakx1![]() |
|
20:29 | RafaelOrtiz has quit IRC | |
20:31 | lucian <lucian!~lucian![]() |
|
20:37 | dirakx1 has quit IRC | |
20:37 | RafaelOrtiz <RafaelOrtiz!~dirakx1![]() |
|
20:56 | silbe has quit IRC | |
20:57 | satellit__ <satellit__!~urk![]() |
|
21:05 | dfarning is now known as dfarning_afk | |
21:07 | satellit__ is now known as satellit_remote | |
22:00 | yama` <yama`!~yama![]() |
|
22:00 | yama` has quit IRC | |
22:00 | yama` <yama`!~yama![]() |
|
22:03 | yama has quit IRC | |
23:27 | lucian has quit IRC | |
23:29 | lucian <lucian!~lucian![]() |
|
23:43 | lucian has quit IRC |
« Previous day | Index | Today | Next day » Channels | Search | Join