| === tvoss|eod is now known as tvoss | ||
| === tvoss is now known as tvoss|food | ||
| === rsalveti_ is now known as rsalveti | ||
| === tvoss|food is now known as tvoss | ||
| === udsbotu changed the topic of #ubuntu-uds-client-2 to: Track: Client | Printing Stack with Mobile in Mind | Url: http://summit.ubuntu.com/uds-1303/meeting/21685/client-1303-printing-stack-with-mobile-in-mind/ | ||
| jasoncwarner | hi everyone. session will start in 3 minutes | 13:58 |
|---|---|---|
| tkamppeter | Can someone invite me into the hangout? | 13:59 |
| pitti_uds | hm, the video isn't on yet, is it? | 14:00 |
| pitti_uds | I see "starts in a few moments" | 14:00 |
| jasoncwarner | tkamppeter: see orther IRC channel, I pasted you the link | 14:01 |
| jasoncwarner | we still have space free on the hangout if anyone else is interested in joining | 14:01 |
| pitti_uds | meh @ video, reloading the page throws me out of IRC | 14:03 |
| pitti_uds | I don't see things to discuss/think about, is there anything to deliberate on while you guys are setting up the video? | 14:05 |
| tkamppeter | pitti_uds, link for the hangout: https://plus.google.com/hangouts/_/39beb4c0269f04a0f04e218d605e9d67718e3993?authuser=0&hl=en | 14:07 |
| jasoncwarner | just starting now folks! | 14:07 |
| pitti_uds | tkamppeter: tried, but "hangout ended due to a server error" | 14:07 |
| pitti_uds | retrying | 14:08 |
| pitti_uds | same error | 14:08 |
| * pitti_uds reloads page to see the live stream | 14:08 | |
| pitti_uds | ok, no live stream, no hangout | 14:09 |
| larsu | pitti_uds: :( | 14:09 |
| pitti_uds | I might have missed an answer during reconnect, any question/problem we can think about while you are setting up? | 14:09 |
| pitti_uds | oh, perhaps I'm not marked as required for this session | 14:09 |
| pitti_uds | (whatever that means, but I heard it's a prerequisite) | 14:10 |
| tsdgeos_uds_ | is this live? I'm getting "This live event will begin in a few minutes" | 14:10 |
| ssweeny | IIRC the track lead has to invite folks into the hangouts | 14:11 |
| pitti_uds | ok, I see Till live now | 14:11 |
| tsdgeos_uds_ | same here | 14:11 |
| * tsdgeos_uds_ raises hand as poppler maintainer | 14:29 | |
| pitti_uds | tsdgeos_uds_: probably best if you just put your question here (or join the hangout), we'll poke tkamppeter to pick it up | 14:29 |
| tsdgeos_uds_ | pitti_uds: not a question, i'm just saying i'm around | 14:30 |
| jasoncwarner | tsdgeos_uds_: did you want to join the session? | 14:33 |
| tsdgeos_uds_ | jasoncwarner: i'm listening, not much to say | 14:34 |
| ritz | systemd in theory allows for on demand startup | 14:34 |
| tsdgeos_uds_ | tsdgeos_uds_: besides i think i could join the session, if i press the share icon in the youtube video there's a "hangout" button | 14:34 |
| ritz | using socket activation | 14:35 |
| tsdgeos_uds_ | jasoncwarner: ↑↑ that obviously for you not for me :D | 14:35 |
| tsdgeos_uds_ | no i don't have a question :D | 14:35 |
| pitti_uds | tsdgeos_uds_: ack :) | 14:36 |
| jasoncwarner | tsdgeos_uds_: https://plus.google.com/hangouts/_/39beb4c0269f04a0f04e218d605e9d67718e3993?authuser=0&hl=en | 14:36 |
| tsdgeos_uds_ | ok, joining | 14:36 |
| pitti_uds | ritz: yeah :) but I don't think we'll get that anytime soon | 14:36 |
| ritz | pitti_uds were we not trying this with upstart ? | 14:37 |
| ritz | on demand service | 14:37 |
| ritz | via dbus | 14:37 |
| pitti_uds | ritz: if it can do it somehow, that'd be great of coures | 14:37 |
| seb128 | ritz, dbus activation != socket activation | 14:37 |
| pitti_uds | ritz: but that only covers d-bus activation if you try to talk to cups over dbus, not the unix socket | 14:38 |
| pitti_uds | which is the main way to talk to cups really | 14:38 |
| pitti_uds | on dbus there's only job notification AFAIK | 14:38 |
| kyleN | QUESTION: would this phone printing stack involve a different set of pkgs than used on desktop, and if so, how would that be managed: a different seed/depends? | 14:38 |
| ritz | not very familiar with upstart | 14:39 |
| pitti_uds | kyleN: just fewer seeds presumably; we already have the split in quantal | 14:39 |
| kyleN | ack | 14:40 |
| tedg | tsdgeos_uds_, Asking in #inkscape to see if I can find some color folks. | 14:43 |
| tsdgeos_uds_ | tedg: tx | 14:43 |
| tedg | The other problem we have is that Mir doesn't have a color management story yet. | 14:45 |
| tedg | So we might be able to punt a bit on color management. | 14:45 |
| tedg | I just want to point out that I'm excited about having a real printing stack on a mobile device. Hate not having it on Android. This really could be a practical differentiator. | 14:46 |
| tedg | tsdgeos_uds_, I was sent this: http://www.oyranos.org/wiki/index.php?title=Test_Images#PDF | 14:47 |
| tedg | larsu, Can you add a work item for design to help with the dialog? jnicktait | 14:49 |
| tedg | larsu, pitti_uds, it wouldn't be an issue if you guys would stop using a stupid size like A4! US Letter! ;-) | 14:50 |
| larsu | tedg: done. thanks | 14:54 |
| === udsbotu changed the topic of #ubuntu-uds-client-2 to: Track: Client | Discuss and plan our webkit maintenance strategy | Url: http://summit.ubuntu.com/uds-1303/meeting/21647/client-1303-webkit-maintenance/ | ||
| mdeslaur | helloww | 14:56 |
| qengho | Hi hi | 15:01 |
| qengho | = chad miller | 15:01 |
| jasoncwarner_UDS | hi everyone... | 15:01 |
| jasoncwarner_UDS | session will begin in a minute | 15:01 |
| mdeslaur | does anyone want to participate on hangout? | 15:01 |
| jasoncwarner_UDS | someone is having mic probs | 15:02 |
| jasoncwarner_UDS | qengho , you seem like you would like to hangout ;) | 15:02 |
| qengho | jasoncwarner_UDS: Yes, I do. | 15:02 |
| mdeslaur | showing up on hangout doesn't automatically mean you get work items | 15:02 |
| mdeslaur | :) | 15:02 |
| qengho | mdeslaur: In fact, if one can't talk, one is more likely to just be assigned them. :) | 15:03 |
| jdstrand | you know, I only use this like 10 times a week | 15:03 |
| mdeslaur | We are currently experiencing technical difficulties. Your call is important to us. Please stay on the line. | 15:03 |
| xnox | What's the hangout url? | 15:03 |
| xnox | ok. | 15:04 |
| jasoncwarner_UDS | xnox and qengho https://plus.google.com/hangouts/_/87858bba77dc51229f080c9df9b930418b03173a?authuser=0&hl=en | 15:04 |
| xnox | jasoncwarner_UDS: hehe and everyone joins now =) | 15:04 |
| * Laney will actually | 15:04 | |
| jdstrand | \o/ | 15:06 |
| jdstrand | mdeslaur: everything is in the etherpad | 15:06 |
| Laney | NOISE | 15:10 |
| xnox | Laney: ok. | 15:11 |
| Laney | :-) | 15:11 |
| mardy | mdeslaur: they did it already | 15:12 |
| mardy | mdeslaur: it's qt5 only now | 15:12 |
| jdstrand | mdeslaur: I have a proposal in etherad | 15:14 |
| jdstrand | etherpad | 15:14 |
| * jdstrand has no volume controls at all | 15:15 | |
| * jdstrand shakes fist at computer | 15:16 | |
| qengho | Yes, we heard something. | 15:17 |
| qengho | Perfect. | 15:17 |
| qengho | Are you running Skype also? | 15:17 |
| Laney | jdstrand: you might need http://blog.didrocks.fr/post/Getting-sound-working-during-a-hangout-in-raring | 15:18 |
| tkamppeter | kyleN, the phone printing stack does not inviolve different packages, I will simply split binary packages to allow the desired small-footprint stack. | 15:18 |
| vrruiz | If neither KDE and Gnome have resources to keep backporting patches, why do you think Ubuntu will? :-/ | 15:20 |
| mdeslaur | vrruiz: if we're going to use a webkit engine in our sdk and our browser, we have no choice | 15:23 |
| mardy | why not base on QtWebkit, since it's the one most relevant for our developers? | 15:24 |
| mdeslaur | mardy: nobody is backporting security features to qtwebkit | 15:24 |
| mdeslaur | I suspect we'll be using the qtwebkit bindings though | 15:25 |
| mardy | mdeslaur: I mean, you would :-) | 15:25 |
| mdeslaur | s/features/fixes/ | 15:25 |
| mdeslaur | yes, we could possibly be the ones maintaining qtwebkit | 15:25 |
| mdeslaur | we're not implying we wouldn't be doing this upstream | 15:26 |
| qengho | I like jdstrand's proposal, pulling from APPL and our maintainence of minor patches atop them. | 15:26 |
| vrruiz | mdeslaur: But AFAIK, one of your arguments to need a webkit engine is that other projects have resource problems. Isn't easier to collaborate with them? | 15:26 |
| mardy | xnox raised a valid point, backporting the bindings might not be a small effort; that's why basing on QtWebKit would reduce this effort a bit | 15:27 |
| mdeslaur | vrruiz: sure, if upstream projects are ready to completely freeze the API, no problem | 15:27 |
| xnox | There are other companies that will be using QtWebkit on the mobile-like platforms. | 15:35 |
| xnox | Would be nice to share the cost of webkit maintenance. | 15:36 |
| vrruiz | Blackberry is using Qt in BB 10 | 15:36 |
| mardy | convince Opera to use QtWebKit ;-) | 15:37 |
| alex_abreu | mardy, ahah | 15:37 |
| mdeslaur | xnox: +1 | 15:38 |
| vrruiz | mardy: Aren't they actually using Chromium? | 15:39 |
| mardy | vrruiz: yes, they are | 15:40 |
| mardy | mdeslaur: especially with WebKit2, things are changing a lot | 15:41 |
| mardy | mdeslaur: on the bright side, it seems that Qt bindings are using more and more the C bindings | 15:42 |
| mardy | jdstrand: it's in continuous development | 15:42 |
| alex_abreu | jdstrand, I think so yeah | 15:42 |
| mardy | (that's not to say that's unstable) | 15:42 |
| qengho | 10 seconds + thinking + typing delay. | 15:42 |
| Mirv | WK2 is used on 2011 Nokia N9, quite stable and nice (no doubt was a lot of work back then) | 15:43 |
| qengho | jasoncwarner_UDS: FWIW, the Lower Third hangout app on the left is indeed dead, and it's | 15:44 |
| Laney | it will be interesting to know if apple are making API changes that will make the rebasing difficult | 15:44 |
| qengho | moved into the Hangout Toolbox app. | 15:44 |
| Laney | what excellent timing | 15:44 |
| chrisccoulson | heh | 15:44 |
| vrruiz | bye | 15:44 |
| jdstrand | Laney: we're that good :) | 15:45 |
| mdeslaur | Laney: possibly...I don't think they care too much about breaking stuff that may impact other bindings then their own | 15:45 |
| chrisccoulson | right, back to debugging jit code ;) | 15:45 |
| qengho | chrisccoulson: Ugh. Still? | 15:45 |
| Laney | indeed | 15:45 |
| === udsbotu changed the topic of #ubuntu-uds-client-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1303/client-2/ - http://ubottu.com/uds-logs/%23ubuntu-uds-client-2.log | ||
| qengho | chrisccoulson: How can I help? | 15:45 |
| chrisccoulson | qengho, yeah, i've located the exact instruction where it all goes wrong, but just trying to figure out what the jit is actually doing | 15:46 |
| chrisccoulson | which is interesting ;) | 15:46 |
| alex_abreu | chrisccoulson, ff on arm? | 15:46 |
| chrisccoulson | alex_abreu, no, chromium | 15:46 |
| chrisccoulson | ff works fine on arm btw ;) | 15:46 |
| alex_abreu | chrisccoulson, oh interesting ... any lp bug on that? | 15:46 |
| qengho | chrisccoulson: I remember some mention of a security bug WRT the JIT and memory contexts. I wonder if it's related. | 15:47 |
| chrisccoulson | alex_abreu, not yet | 15:47 |
| chrisccoulson | qengho, ah, interesting | 15:47 |
| lool | tvoss: bah geoclue conflicts with update process session; I'll go to update process, but can join geoclue mid-way if that's helpful | 15:47 |
| Laney | the jit is disabled on the webkitgtk arm build due to bug | 15:48 |
| Laney | buh | 15:48 |
| Laney | due to https://bugs.webkit.org/show_bug.cgi?id=85076 | 15:48 |
| udsbotu | bugs.webkit.org bug 85076 in JavaScriptCore "ARM JIT causes segmentation fault on javascript-heavy pages" [Normal,Unconfirmed] - Assigned to webkit-unassigned@lists.webkit.org | 15:48 |
| chrisccoulson | Laney, this is v8 though ;) | 15:48 |
| chrisccoulson | (not JSC) | 15:48 |
| tvoss | lool, cool, thank you | 15:49 |
| Laney | fair enough | 15:49 |
| === udsbotu changed the topic of #ubuntu-uds-client-2 to: Track: Client | Location Service - Geoclue vs whole cloth | Url: http://summit.ubuntu.com/uds-1303/meeting/21614/client-1303-location-service/ | ||
| alex_abreu | chrisccoulson, any st/dissasembly? is it something GC related? | 15:51 |
| chrisccoulson | alex_abreu, no, it's not GC related | 15:51 |
| jasoncwarner_UDS | session will start in 3 minutes | 15:57 |
| jasoncwarner_UDS | hi folks...have spots open for those interested in joining the hangout | 16:01 |
| jasoncwarner_UDS | https://plus.google.com/hangouts/_/0ec0ef5db83f0a1952bc68dfb0337d646e9d288d?authuser=0&hl=en | 16:01 |
| cyphermox | I'm familiar with geoclue | 16:11 |
| cyphermox | mkay | 16:12 |
| cyphermox | I mean, rather than rewriting lots of stuff, let's fix and provide fixes upstream | 16:13 |
| desrt | cyphermox: is there a chance we could assume control of the existing project? | 16:14 |
| cyphermox | possibly I don't know | 16:14 |
| cyphermox | last I checked it didn't seem super active | 16:15 |
| cyphermox | but then again, maybe it also largely works and that's why it's not being a flurry of commits | 16:15 |
| desrt | who is the last maintainer-type person? | 16:15 |
| larsu | the description of the session says it's pretty much dead | 16:15 |
| Cheesehead | IIRC, the old maintainer offered it for adoption, no takers | 16:15 |
| desrt | so let's adopt it? | 16:15 |
| desrt | Cheesehead: got a citation for that? | 16:16 |
| xnox | We can cache apt data and fake it / provide that those core packages are available. | 16:16 |
| cyphermox | hadess might have been the last maintainer? | 16:16 |
| Cheesehead | desrt: Sorry, old memory. Perhaps an old mailing list. | 16:16 |
| larsu | daniel was in contact with the last maintainer | 16:16 |
| cyphermox | so my point was that we can definitely improve on any things that don't work when they already have most of what we need, rather than rewriting a whole lot of stuff from scratch and running into the same issues the original project probably ran into many times | 16:17 |
| cyphermox | whether that means adopting the project or whatever else is fine | 16:18 |
| cyphermox | larsu: could you add lower third? | 16:18 |
| cyphermox | tvoss: ^ | 16:18 |
| larsu | lower third? | 16:18 |
| Mirv | larsu: hangout toolbox app, installable from the left bar | 16:19 |
| Mirv | larsu: only works in chromium though | 16:19 |
| tvoss | cyphermox, I tried, but it's shown on the upper tird :) | 16:19 |
| cyphermox | tvoss: oh, so it is! | 16:19 |
| cyphermox | I briefly saw it | 16:19 |
| tvoss | cyphermox, weird though | 16:20 |
| cyphermox | yes, totally agree it can / needs to be improved | 16:20 |
| desrt | 11:19 < hadess> desrt, by a newer version, i have some apis scribbled on pieces of paper (notes on my computer) | 16:21 |
| desrt | 11:19 < hadess> desrt, less moving parts, stuff that works | 16:21 |
| desrt | 11:19 <@desrt> hadess: canonical wants to do the same | 16:21 |
| desrt | 11:20 < hadess> desrt, satabdi has been working on ip geolocation, and (rev)geocoding in geocode-glib | 16:21 |
| desrt | 11:20 <@desrt> hadess: so do you plan to torch the current codebase? | 16:21 |
| desrt | 11:20 <@desrt> hadess: and what is your timeline? | 16:21 |
| desrt | 11:20 < hadess> desrt, yep, it's pretty clear it's not usable | 16:21 |
| desrt | 11:20 < hadess> desrt, timeline is "when i have time" | 16:21 |
| desrt | FYI | 16:21 |
| desrt | looks like the reason upstream is dead is because upstream thinks that the current codebase is not worth it | 16:21 |
| cyphermox | tvoss: that's a good point | 16:21 |
| desrt | 11:21 < hadess> (it's been pushed back at least 2 cycles already because of no time) | 16:22 |
| cyphermox | tvoss: I'm curious if we can't write a test suite for what we have right now, and spend less time than rewriting all; then refactor, fix tests, etc... you know how it goes ;) | 16:22 |
| cyphermox | esp. for a project relatively as isolated/self contained as geoclue | 16:23 |
| cyphermox | it *is* a complex decision on that end, though, definitely | 16:23 |
| cyphermox | yeah | 16:23 |
| cyphermox | basically, very rough tests to check the exisitng impl, refactor, make the tests good, refactor, repeat | 16:24 |
| cyphermox | at least making sure we don't introduce regressions | 16:24 |
| cyphermox | interesting | 16:25 |
| cyphermox | I've coded a bit with the geoclue stuff and the code... was... ugly/messy I guess, so don't take my intervention as saying "no we should absolutely not do a rewrite" | 16:25 |
| desrt | there is going to be a rewrite one way or another, it seems | 16:26 |
| cyphermox | desrt: in terms of majorly overhauling the code base, yeah ;) | 16:26 |
| desrt | imho we should try to share the component, though | 16:26 |
| cyphermox | so there already is code... | 16:26 |
| desrt | from a practical standpoint, writing it in c++ for Qt is a good way to ensure that we're the only ones who will ever use it | 16:27 |
| cyphermox | desrt: can you pull hadess here? | 16:27 |
| desrt | i tried. he's not interested :) | 16:27 |
| cyphermox | his input may be useful | 16:27 |
| cyphermox | oh ;) | 16:27 |
| * desrt tries again | 16:27 | |
| cyphermox | we can help with the "lack of time" | 16:28 |
| desrt | indeed | 16:28 |
| desrt | he has notes on the new design... i asked if he could publish them somewhere | 16:28 |
| desrt | hadess: hey. welcome. | 16:28 |
| cyphermox | assuming we can spend time writing the code from the api he designs | 16:28 |
| hadess | desrt, they're more "nice to haves" | 16:28 |
| cyphermox | hey hadess, thanks for coming | 16:28 |
| cyphermox | tvoss: +1 | 16:28 |
| tvoss | hadess, hey, thx for being with us | 16:29 |
| hadess | desrt, including things that aren't currently possible, such as authorisation and sandboxing | 16:29 |
| jasoncwarner_UDS | hadess: want to join the session? | 16:29 |
| jasoncwarner_UDS | desrt as well? | 16:29 |
| jasoncwarner_UDS | https://plus.google.com/hangouts/_/0ec0ef5db83f0a1952bc68dfb0337d646e9d288d?authuser=0&hl=en | 16:29 |
| desrt | jasoncwarner_UDS: i don't have the google hangout plugin, nor h264 video support :( | 16:29 |
| hadess | no thanks | 16:30 |
| jasoncwarner_UDS | desrt: what year is it where you live? ;) | 16:30 |
| cyphermox | haha | 16:30 |
| jasoncwarner_UDS | hadess: no worries | 16:30 |
| jasoncwarner_UDS | thanks for joining the irc | 16:30 |
| desrt | hadess: so part of why you're stalled is missing infra from other places too? | 16:30 |
| desrt | or would it be possible to push ahead on the new design without these things in place, keeping in mind that we want to add support later? | 16:31 |
| hadess | desrt, i think it would be almost impossible to retrofit | 16:31 |
| desrt | right. we're talking rewrite already | 16:31 |
| desrt | but if canonical is already thinking of doing a rewrite, we may as well pool resources | 16:31 |
| cyphermox | I have some interest in location services for wifi stuff .. for instance getting proper updates of regulatory domains, as it has been planned for a long while | 16:31 |
| cyphermox | do we need much of that provider description? | 16:33 |
| hadess | the target is 1) ip geocoding (code is in geocode-glib) 2) wifi geocoding (code will be in geocode-glib) 3) gps through cellular | 16:33 |
| cyphermox | hadess: cool | 16:33 |
| hadess | if canonical want to help, adding support for more modems in ModemManager, and adding support for GPS-A is probably much harder than writing a shim on top of all that | 16:34 |
| cyphermox | hadess: do you mean you're writing GPS-A support? | 16:35 |
| hadess | cyphermox, no, that somebody should | 16:35 |
| cyphermox | ack | 16:35 |
| cyphermox | I think there's some of it in progress | 16:36 |
| desrt | hadess: what's the plan for how the data gets from modemmanager to apps? | 16:36 |
| cyphermox | desrt: modem location support is provided via a dbus interface from MM | 16:36 |
| hadess | desrt, a small dbus service, the api is pretty much that of core location | 16:36 |
| desrt | hadess: and this does the wifi/ip-based ones as well? | 16:37 |
| hadess | desrt, it would, yes | 16:37 |
| desrt | so this is the to-be-written | 16:37 |
| hadess | desrt, "give me my location" and it would choose the way to access it based on accuracy required | 16:37 |
| hadess | yeah | 16:37 |
| cyphermox | yeah | 16:37 |
| desrt | the main difference here is that it's just one simple process instead of a gaggle of providers | 16:38 |
| hadess | yes, and without support for stand-alone gpses either | 16:38 |
| desrt | tragic :p | 16:38 |
| cyphermox | omg | 16:38 |
| desrt | hadess: then your concern moves to how to prevent unworthy apps from hitting this dbus interface | 16:39 |
| desrt | i assume it's meant to be a system service | 16:39 |
| cyphermox | totally agree, syncing with hadess, comparing requirements/plans | 16:44 |
| hadess | desrt, i don't think it needs to be a system service | 16:46 |
| desrt | hadess: so any user would have to be able to read data out of modemmanager then | 16:47 |
| desrt | ditto things like wifi AP mac addresses (that's how wifi-based geocode works, right?)? | 16:48 |
| hadess | desrt, the way things work right now, yes, but that's the same trying to configure your wwan broadband right now | 16:48 |
| desrt | hadess: almost starts to seem like we don't need a service at all, then? | 16:49 |
| hadess | it doesn't need to run as a system service, but if it runs as a session service, it needs to be special | 16:49 |
| desrt | why not just have a library do the work in app context? | 16:49 |
| dcbw | do we consider location infromation privileged? | 16:49 |
| desrt | dcbw: yes. we ought to. | 16:49 |
| dcbw | eg, how do we gate access to it? | 16:49 |
| hadess | desrt, because that would make it impossible to sandbox | 16:49 |
| dcbw | in that case, normal users shouldn't be able to ask ModemManager for location info | 16:49 |
| desrt | dcbw: this goes to the larger sandboxing question | 16:49 |
| desrt | hadess: you could sandbox at the mechanism level | 16:50 |
| desrt | hadess: no access to modemmanager data, for example | 16:50 |
| dcbw | we already have PolicyKit support for location stuff in MM | 16:50 |
| dcbw | we just don't turn it on by default | 16:50 |
| dcbw | but that's not really a model we want these days | 16:50 |
| desrt | that's why i thought you wanted to make it a system service.... then only root-owned processes (or whatever it runs as) get access to MM | 16:50 |
| dcbw | it should be remembered on a per-app basis instead of a global PK dialog | 16:50 |
| hadess | desrt, a separate service would also take care of power management | 16:50 |
| desrt | interesting. | 16:51 |
| hadess | desrt, no point calling doing network calls if you have a good enough data from the modem for another app for example | 16:51 |
| desrt | who is the one on the canonical side who has time to work on this? | 16:52 |
| larsu | desrt: looks like daniel | 16:54 |
| === udsbotu changed the topic of #ubuntu-uds-client-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1303/client-2/ - http://ubottu.com/uds-logs/%23ubuntu-uds-client-2.log | ||
| === udsbotu changed the topic of #ubuntu-uds-client-2 to: Track: Client | Converged network stack | Url: http://summit.ubuntu.com/uds-1303/meeting/21673/client-1303-converged-network-stack/ | ||
| qwebirc105673 | Hi everyone, session will start in about 6 minutes. | 18:08 |
| lool | session starting in 4 mn | 18:11 |
| zyga-uds | hey everyone | 18:13 |
| zyga-uds | lool: could you announce when the session goes live please | 18:15 |
| awe_ | zyga-uds, it's live now | 18:15 |
| roadmr | zyga-uds: it is, reload, reload | 18:15 |
| asb_asb_asb | sucky youtube widget | 18:16 |
| rsalveti | lool: awe_: can we dynamically request NM to rescan for aps? | 18:16 |
| dcbw | rsalveti: already present | 18:16 |
| rsalveti | awesome | 18:16 |
| dcbw | rsalveti: there's a Scan method in 0.9.8 | 18:16 |
| zyga-uds | QUESTION: will the converged stack affect testing or certification performed on non-touch/mobile systems | 18:16 |
| dcbw | anyone got a hangout link for the chat? | 18:18 |
| pitti_uds | NM is 3.9 MB RSS, even dhclient is 3.0 | 18:18 |
| pitti_uds | that doesn't seem terribly much? | 18:18 |
| asb_asb_asb | pitti_uds: nm-applet is the real hog | 18:18 |
| dcbw | root 1371 0.0 0.0 205176 3020 pts/0 S+ 06:47 0:00 sudo src/.libs/NetworkManager --no-daemon | 18:18 |
| cyphermox | aye | 18:19 |
| dcbw | dcbw 1191 0.0 0.5 710736 19464 ? Sl 06:46 0:08 nm-applet | 18:19 |
| zyga-uds | vUDS needs a conflict resoultion protocol for the speakers to agree upon to minimize collision lag | 18:19 |
| dcbw | nobody's denying that nm-applet needs a diet:) | 18:19 |
| cyphermox | I also mentioned I'd look at how we can reduce both | 18:19 |
| qwebirc105673 | dcbw: want to join the hangout? https://plus.google.com/hangouts/_/e852387d7e4db65b443695b981fc9ad4431aaed1?authuser=0&hl=en | 18:19 |
| awe_ | pitti_uds, it's not... it was just one criteria that we wanted to measure | 18:19 |
| asb_asb_asb | 14.4mb as shown by ps_mem.py | 18:19 |
| dcbw | thanks | 18:19 |
| pitti_uds | awe_: right, thanks | 18:19 |
| pitti_uds | agreed about nm-applet | 18:19 |
| roadmr | does modem-manager handle... oh never mind, it'll go away | 18:19 |
| awe_ | hey dcbw...long time! | 18:20 |
| qwebirc105673 | pitti_uds: if you want to join the hangout as well, feel free! | 18:20 |
| zyga-uds | modemmanager is a pain -- it opens all tty devices checking if that's a modem, that can be a problem on a phone that may have stuff like gps on a tty | 18:20 |
| zyga-uds | lool: ^^ | 18:20 |
| ogra_ | dcbw, your typing steals the video focus | 18:20 |
| dcbw | awe_: yo :) | 18:20 |
| pitti_uds | hey dcbw, thanks for showing up | 18:20 |
| ogra_ | dcbw, better mute if you dont speak | 18:20 |
| pitti_uds | qwebirc105673: not enough to contribute, I'm afraid | 18:20 |
| rsalveti | zyga-uds: but I'd say that's more of a bug | 18:20 |
| rsalveti | it is indeed annoying | 18:20 |
| zyga-uds | rsalveti: no, it has to try otherwise it'd require some manifests to idenitify modems, right? | 18:21 |
| dcbw | ogra_: yeah, muted already | 18:21 |
| ogra_ | :) | 18:21 |
| zyga-uds | rsalveti: it's a problem whenever you have a serial port showing, up, mm will try talking to it | 18:21 |
| rsalveti | right, that's why I said it'd be more of a bug for me | 18:21 |
| rsalveti | because I don't think this is the desired behavior | 18:21 |
| dcbw | we did just add ModemManager1 support, so that's a good patch to look at | 18:21 |
| rsalveti | it breaks everyone that needs to use serial based devices | 18:22 |
| dcbw | that basically adds a completely new MM backend | 18:22 |
| zyga-uds | rsalveti: I don't see a fix for that that would not break modem support for virtually everyone | 18:22 |
| zyga-uds | rsalveti: even if you only look at 3G modems | 18:22 |
| zyga-uds | rsalveti: I agree on that | 18:22 |
| zyga-uds | rsalveti: one thing I tried to do to fix that | 18:22 |
| zyga-uds | rsalveti: is to blacklist certain ttys in udev rules | 18:22 |
| zyga-uds | rsalveti: and I got that to work for my development boards and generic serial-usb dongles | 18:22 |
| zyga-uds | rsalveti: if you want I can share that | 18:23 |
| zyga-uds | rsalveti: there's a similar problem with random usb devices being probed by mtp client to see if they are a storage device | 18:23 |
| zyga-uds | rsalveti: that crashes bootloaders for me | 18:23 |
| rsalveti | zyga-uds: I think we have a bug opened for that | 18:24 |
| rsalveti | let me try to find it | 18:24 |
| zyga-uds | rsalveti: cool, I'm interested in fixing that | 18:24 |
| zyga-uds | rsalveti: in the end the rules for mtp and modem manager need patching | 18:24 |
| zyga-uds | rsalveti: then the system is generic enough to have per-package rules that blacklist a device | 18:24 |
| cyphermox | zyga-uds: rsalveti: there's some stuff changing on that level, but can we keep it around what is being discussed on the hangout to not get all mixed up | 18:24 |
| zyga-uds | ok | 18:24 |
| cyphermox | you're obviously welcome to bring things up, ping me if you feel your questions are being ignored | 18:25 |
| ChickenCutlass | awe_: we also want rild support | 18:25 |
| zyga-uds | cyphermox: no, I guess those are implementation bugs/details | 18:26 |
| victorp_ | if it doesnt have voice support it wont | 18:26 |
| rsalveti | zyga-uds: yeah, need to take a better look at that, but I know we have a bug :-) | 18:26 |
| victorp_ | pass cert | 18:26 |
| cyphermox | doubtful that ofono was any more certified though... holtmann do you know? | 18:26 |
| awe_ | ChickenCutlass, I'll get there | 18:26 |
| holtmann | We went throughout GCF certification with oFono. | 18:26 |
| holtmann | You guys need to think about SIM Toolkit support. | 18:26 |
| victorp_ | cyphermox: it has been certified for GCF | 18:26 |
| cyphermox | ack | 18:26 |
| holtmann | That is the first thing that is going to be asked. | 18:26 |
| cyphermox | thanks | 18:26 |
| zyga-uds | lool: do we consider a situation where the vendor might replace the telephony stack, is that something they do on android today? | 18:27 |
| cyphermox | stgraber: esp. leverage all the work we've done and simplify convergence | 18:27 |
| victorp_ | stgraber: that sounds good | 18:28 |
| lool | zyga-uds: they'd have to pass certification again | 18:28 |
| cyphermox | ah, yes the caps bits | 18:28 |
| victorp_ | zyga-uds: they do that today , yes | 18:28 |
| cyphermox | awe_: I'm preparing MM1 on a PPA | 18:28 |
| cyphermox | https://launchpad.net/~network-manager/+archive/modemmanager-next (incomplete) | 18:29 |
| victorp_ | does modem manager work with rild? | 18:29 |
| victorp_ | awe ^ | 18:29 |
| awe_ | no | 18:29 |
| dcbw | no, it doesn't | 18:29 |
| dcbw | a rild connector would be nice to have | 18:29 |
| zyga-uds | victorp_: I wonder how that changes our side, if they switch from vanilla android to say, qualcomm android telephony, does that change the interface as seen from the system? | 18:29 |
| victorp_ | zyga-uds: probably not | 18:29 |
| awe_ | victorp_, voice support @ the high-level API is the big missing piece | 18:29 |
| victorp_ | as they would have to change RIL | 18:29 |
| holtmann | Guhttps://git.kernel.org/cgit/network/ofono/ofono.git/tree/doc/certification.txt | 18:29 |
| awe_ | if this was added to mm, we could add rild support to mm | 18:30 |
| holtmann | https://git.kernel.org/cgit/network/ofono/ofono.git/tree/doc/usat-certification-status.txt | 18:30 |
| cyphermox | holtmann: thanks | 18:30 |
| rsalveti | zyga-uds: they can replace the implementation, but the interface would be the same | 18:30 |
| awe_ | but it's fairly large piece of code that's missing | 18:30 |
| holtmann | ConnMan comes with a built-in DHCP client. | 18:31 |
| awe_ | holtmann, hey dude... long time | 18:31 |
| victorp_ | awe_: and crucial | 18:31 |
| ogra_ | he is hiding :) | 18:31 |
| holtmann | ConnMan has its own DHCP client and server. | 18:31 |
| cyphermox | holtmann: yeah, we mean how hard could it be to make it use an external client again? | 18:31 |
| awe_ | holtmann, that's what we're talking about... there's some concern about the builtin dhcp client | 18:31 |
| holtmann | It is by magnitudes faster than external clients. | 18:31 |
| holtmann | See my presentation at LinuxCon Vancouver a few years ago. | 18:31 |
| victorp_ | awe_: not sure is in the scope of this session but will be nice to talk about SIP support | 18:31 |
| * awe_ screams | 18:32 | |
| lool | holtmann: would it be possible to implement this in dhclient? | 18:32 |
| lool | holtmann: we wouldn't want to have to support 2 DHCP clients | 18:32 |
| holtmann | ConnMan DHCP had a 80% speed increase in corporate or public networks. | 18:33 |
| holtmann | The internal DHCP client in ConnMan also reduces the memory footprint. | 18:33 |
| cyphermox | holtmann: due to the arp tricks? | 18:33 |
| holtmann | As I said, the numbers where in my LinuxCon talks. | 18:33 |
| holtmann | No ARP tricks. We never needed it. | 18:33 |
| lool | holtmann: indeed, we did notice a big memory difference | 18:34 |
| Wellark | QUESTION: could holtmann join the onair discussion? :) | 18:34 |
| victorp_ | lool: Is DHCP really a key discussion point here? | 18:34 |
| ogra_ | Wellark, he is talking | 18:34 |
| Wellark | oh, right. great! :) | 18:34 |
| ogra_ | (if i'm not getting the voice wrong) | 18:34 |
| cyphermox | ogra_: nah | 18:34 |
| ChickenCutlass | lool: awe_ can we talk about 3g data connections and more relevant topics | 18:34 |
| cyphermox | this is dan | 18:34 |
| ogra_ | oh | 18:34 |
| lool | ChickenCutlass: didn't we cover that with ofono already? | 18:34 |
| stgraber | ogra_: dcbw is talking | 18:34 |
| lool | ChickenCutlass: and modemmanager | 18:34 |
| ogra_ | they both turned off tehir cam now :) | 18:34 |
| awe_ | ChickenCutlass, we have talked about 3g | 18:34 |
| lool | yeah | 18:35 |
| * ogra_ thought he heard marcel talk before | 18:35 | |
| ChickenCutlass | awe_: we did? I thought it was voice | 18:35 |
| ChickenCutlass | ok | 18:35 |
| lool | victorp_: DHCP speed for end-users and supporting 2 DHCP clients seemed relevant | 18:35 |
| victorp_ | I agree with ChickenCutlass I dont see how this is so relevant | 18:35 |
| victorp_ | lool: really? over not have a phone stack? | 18:35 |
| holtmann | Honestly our DHCP client never had issues with the full DHCP discover procedure. | 18:35 |
| ChickenCutlass | lool: awe_ please talk about support for RILD | 18:35 |
| victorp_ | oks I will go back to read my emails ;) | 18:35 |
| cyphermox | it's relevant when we get to convergence | 18:36 |
| holtmann | It is just that fast. | 18:36 |
| lool | link to the security review is in the pad | 18:36 |
| victorp_ | seems like inside baseball to moe | 18:36 |
| lool | ChickenCutlass: yes, it's on the list | 18:36 |
| roadmr | do you have gpg keys set up? | 18:36 |
| roadmr | sorry | 18:36 |
| lool | ChickenCutlass: in fact it's next on the list as we already covered dhclient w/ connman | 18:37 |
| pitti_uds | mdeslaur: don't we already do this by default for NM as well? | 18:37 |
| holtmann | It is the same hardware. People are sharing the hardware. | 18:37 |
| pitti_uds | mdeslaur: i. e. defaulting to system-wide connections? (and it totally makes sense IMHO) | 18:37 |
| holtmann | Pre-shared keys are pre-shared in the first place. | 18:37 |
| chiluk | it may cause issues in corporate environments as well where the corporation wants to control access to the corporate network/VPN but still allow the user to connect to their home networks | 18:38 |
| holtmann | Enterprise WiFi is per user. | 18:38 |
| holtmann | Same as VPN. | 18:38 |
| dcbw | holtmann: there's a use-case with shared laptops for example, even with PSK that we've heard about | 18:38 |
| holtmann | Same as WISPr. | 18:38 |
| pitti_uds | yeah, by-user wifi connections are a nuisance and really just wrong | 18:38 |
| lool | victorp_: it's a bunch of topics, not just a single one; this is converged network stack, not just phone stack | 18:38 |
| cyphermox | +1 | 18:38 |
| dcbw | in one case, a Uni shares laptops between students and doesn't want their home wifi PSKs available to the othe ruser | 18:38 |
| pitti_uds | 3G and vpn are certainly more per-user, yes | 18:38 |
| dcbw | with 802.1x/wpa enterprise, you may want a machine-wide *connection*, but user-specific passwords | 18:39 |
| holtmann | ConnMan has PolicyKit support as well. Just nobody wrote the policy files. | 18:39 |
| dcbw | so an admin can deploy the same configuraiton on a bunch of machines, but each user has their own password | 18:39 |
| mdeslaur | pitti_uds: yes, we default to system connections, but a lot of wifi connections need to be by user | 18:39 |
| mdeslaur | pitti_uds: for example WPA Enterprise, where users have their own passwords, and their own certificates | 18:39 |
| pitti_uds | so that makes sense if you have a sequential multi-user machine, not "multiple sessions in parallel" | 18:40 |
| pitti_uds | (thinking guest session, etc.) | 18:40 |
| mdeslaur | pitti_uds: a lot of corporate environments pre-configure system wireless connections, which the user doesn't have rights to change, but then allow per-user connections for travelling | 18:40 |
| mdeslaur | pitti_uds: yes, not concurrent access, multiple users on the same device | 18:40 |
| pitti_uds | ack | 18:41 |
| mdeslaur | pitti_uds: ie: parental lock on a tablet is an example | 18:41 |
| mdeslaur | requiring fine-grained policykit support | 18:41 |
| victorp_ | holtmann: what did you mean by "SIM Toolkit support" | 18:42 |
| mdeslaur | holtmann: enterprise wifi is per user? | 18:43 |
| dcbw | http://en.wikipedia.org/wiki/SIM_Application_Toolkit | 18:43 |
| holtmann | Yes. Enterprise WIFi, VPN and WISPr is per user. | 18:43 |
| cyphermox | mdeslaur: oh yeah | 18:43 |
| cyphermox | much enterprise needs your user name, password, or your own certificate | 18:43 |
| victorp_ | dcbw: thanks. holtmann seemed to imply that conman had better support for it, but wouldnt that be lower down the stack? | 18:44 |
| mdeslaur | I mean, "enterprise wifi is per user in connman"? | 18:44 |
| pitti_uds | mem usage> lool, do you actually mean NM (daemon) or nm-applet? | 18:44 |
| awe_ | victorp_, better support for what? | 18:44 |
| lool | pitti_uds: all together | 18:44 |
| victorp_ | SIM Toolkit support | 18:44 |
| ogra_ | awe_, SIM toolkit | 18:44 |
| lool | pitti_uds: but nm-applet is going away | 18:44 |
| victorp_ | awe ^ | 18:45 |
| dcbw | victorp_: STK is an ofono/MM level thing | 18:45 |
| dcbw | MM doesn't have support for STK yet | 18:45 |
| awe_ | that's ofono | 18:45 |
| holtmann | The Nest.com thermostat guys are running ConnMan in their device and they have very crazy memory limits. | 18:45 |
| dcbw | ofono does | 18:45 |
| lool | we can cover it | 18:45 |
| cyphermox | pitti_uds: we mean more the daemon | 18:45 |
| cyphermox | but we can certainly improve on the applet | 18:45 |
| victorp_ | dcbw: I guess that was my point, thanks for confirming | 18:45 |
| holtmann | SIM Toolkit is a lot of work btw. I took as 12 month with 6 people to implement it inside oFono. | 18:46 |
| holtmann | s/as/us/ | 18:46 |
| holtmann | ConnMan can do both, dynamic and builtin plugins. | 18:47 |
| mdeslaur | holtmann: could you confirm that ConnMan supports enterprise wifi and vpn _per user_? | 18:48 |
| holtmann | So ConnMan includes DHCP client + server, DNS resolver, DNS proxy, DNS server, WISPr HTTP client. | 18:48 |
| holtmann | Including all the Tethering handling. | 18:48 |
| cyphermox | aye | 18:48 |
| holtmann | So need for external programs like dhclient, dnsmasq, iptables callouts etc. | 18:49 |
| holtmann | ConnMan has an agent concept. So VPN, WiFi and WISPr credentials are ask to the user. | 18:49 |
| holtmann | Similar to BlueZ. | 18:49 |
| mdeslaur | holtmann: ask the user, but then they're stored centrally, no? | 18:49 |
| dcbw | as does NM | 18:49 |
| holtmann | No. The user can decide where to store them. | 18:50 |
| cyphermox | awe_: +1 | 18:50 |
| holtmann | Actually SIM Toolkit is high level only. The modem plugin only needs to have a transport. | 18:50 |
| holtmann | The SIM Toolkit parsing and message parsing is done inside the oFono core. | 18:51 |
| awe_ | holtmann, thanks for the correction... | 18:51 |
| holtmann | The modem plugin/driver has to send the raw PDU. Same as with SMS. | 18:51 |
| holtmann | Only PDU transport needs to implemented. | 18:51 |
| awe_ | I've been meaning to ping you, since we recently open-sourced everything | 18:51 |
| holtmann | Hah. Nice. Have a link? | 18:52 |
| awe_ | thanks for the clarification | 18:52 |
| awe_ | to the code? | 18:52 |
| ogra_ | voting ! | 18:52 |
| awe_ | yea, hold on a sec | 18:52 |
| ogra_ | :) | 18:52 |
| asb_asb_asb | come on connman | 18:52 |
| holtmann | Yes, link to the code. | 18:52 |
| rsalveti | and not using ofono would mean also rewriting the layers the telephony-app depends | 18:52 |
| holtmann | SIM Toolkit parsing and message building is 6 people for 12 month that you need to redo. | 18:53 |
| awe_ | holtmann, https://code.launchpad.net/ubuntu-touch-preview | 18:53 |
| dcbw | well, the code got sucked into MM and the transport was implemented natively I suppose :) | 18:54 |
| awe_ | https://code.launchpad.net/~phablet-team/phablet-extras/ofono | 18:54 |
| cyphermox | that said, I'm starting to take over more and more the maintainership of connman on Debian and Ubuntu | 18:54 |
| dcbw | well, *unless* :) | 18:54 |
| cyphermox | so I want to make it a first class citizen on Ubuntu for those who want to use it | 18:54 |
| ogra_ | scared by sexiness ... | 18:54 |
| awe_ | holtmann, fyi... the RIL code was added directly to the bzr tree | 18:54 |
| cyphermox | asb_asb_asb: ^^ | 18:55 |
| dcbw | well, somebody needs to define "sexy" in this context :) | 18:55 |
| awe_ | we have plans to split out the plugin code, and submit the gril layer as a patch | 18:55 |
| jdstrand | lool: I echo mdeslaur's comments. if the dhclient slowness is an issue, perhaps using connmann's dhcp client with networkmanager would make sense | 18:55 |
| rsalveti | we will still clean it up and prepare for upstreaming | 18:55 |
| cyphermox | jdstrand: yes | 18:55 |
| jdstrand | lool: that's just otoh | 18:55 |
| awe_ | ( gril is the equivalent of gatchat, gisi layers ) | 18:55 |
| awe_ | ( and based on them ) | 18:55 |
| holtmann | Hah. | 18:55 |
| cyphermox | we've been thinking about that; seeing how we can split that code out and whether we could use it with NM | 18:55 |
| jdstrand | cool | 18:55 |
| awe_ | holtmann, fyi... I recently tried to sign up for the ofono mailing list...and got no auto-response | 18:56 |
| holtmann | With QMI support we never bothered and when for drivers/qmimodem/qmi.[ch] directly. | 18:56 |
| holtmann | gatchat is a bit different since the AT modem is a different beast. | 18:56 |
| holtmann | Send the patches to the mailing list for review if you get a chance. | 18:56 |
| cyphermox | jdstrand: perhaps I'll circle back to you, and talk to holtmann more about how we could ship those separately, if possible | 18:57 |
| rsalveti | we'll be working on that now that mwc is done :-) | 18:57 |
| cyphermox | I'm sure we'd at least be happy with getting a more "transparent" upstream for a dhcp client | 18:57 |
| awe_ | holtmann, sure... there's some cleanup needed, and I'm sure y | 18:57 |
| asb_asb_asb | could someone tell me more about chewie? | 18:57 |
| awe_ | y'all will have plenty of review comments for us | 18:57 |
| jdstrand | cyphermox: sure. we don't really care-- both seem supportable and if it offers a real benefit for mobile, I think it is worth considering | 18:58 |
| cyphermox | holtmann: how do you feel about having a way to split the dhcp code from connman into a library or something that we could reuse elsewhere? | 18:58 |
| holtmann | There has been talks about it. | 18:58 |
| cyphermox | cool | 18:58 |
| gema_ | lool: i am impressed on how quickly you can talk! | 18:59 |
| holtmann | The only reason why it has not yet been done, because it tightly integrated. Since we also do the DHCP server side. | 18:59 |
| lool | gema_: probably too fast for people to understand me with french accent | 18:59 |
| ogra_ | gema_, i'm impressed how quickly you can understand :) | 18:59 |
| cyphermox | holtmann: ok | 18:59 |
| cyphermox | well, to split it up I'd split up server as well somehow | 18:59 |
| gema_ | ogra_: who says I am understanding him? :P | 18:59 |
| ogra_ | lol | 18:59 |
| gema_ | just kidding | 18:59 |
| ogra_ | hahaha | 19:00 |
| rsalveti | lool is unstoppable, a machine | 19:00 |
| cyphermox | indeed | 19:01 |
| sarnold | thanks | 19:01 |
| awe_ | ;D | 19:01 |
| === udsbotu changed the topic of #ubuntu-uds-client-2 to: Track: Client | Autopilot for mobile devices planning | Url: http://summit.ubuntu.com/uds-1303/meeting/21632/client-1303-autopilot-mobile/ | ||
| rsalveti | great session, thanks all for joining in | 19:01 |
| rsalveti | dcbw: thanks for finding time to participate | 19:01 |
| dcbw | np | 19:02 |
| thomi | who's got the hangout link? | 19:03 |
| thomi | oh, nvm | 19:03 |
| gema_ | jason, I guess | 19:04 |
| gema_ | areyou guys streaming already? | 19:04 |
| cjohnston | no | 19:04 |
| tsdgeos_uds | is this broadcasting? | 19:05 |
| cjohnston | not yet | 19:05 |
| cjohnston | thomi: who created the hangout | 19:05 |
| mmrazik | btw. if somebody wants to join the hangout ping me | 19:06 |
| jasoncwarner_UDS | hi folks...we should be live now | 19:06 |
| jasoncwarner_UDS | gema_: streaming now, yes | 19:07 |
| tsdgeos_uds | yep | 19:07 |
| cjohnston | it is | 19:07 |
| gema_ | yep | 19:07 |
| gema_ | I see the guitars | 19:07 |
| elopio | hello. | 19:07 |
| MacSlow | hey vrruiz | 19:08 |
| vrruiz | Hi MacSlow | 19:08 |
| cgoldberg | o/ | 19:09 |
| tedg | thomi, How long do we expect Surface Flinger to exist? | 19:14 |
| tedg | thomi, It seems like it's kinda temporary, so not worth spending too much time on. | 19:15 |
| mmrazik | tedg: if I understand correctly we don't know ATM | 19:15 |
| mmrazik | tedg: I believe thats what was just discussed -- just keep surfaceflinger stuff we have ATM and replace that eventually | 19:15 |
| tedg | mmrazik, I though there was A Plan (tm) | 19:15 |
| tedg | tvoss, ^ | 19:15 |
| tedg | Or perhaps kgunn ^ | 19:15 |
| kgunn | tedg: its part of the mir plan | 19:16 |
| kgunn | imo | 19:16 |
| kgunn | does that make sense? | 19:17 |
| tedg | kgunn, No :-) | 19:17 |
| kgunn | good | 19:17 |
| kgunn | :) | 19:17 |
| tedg | kgunn, Is it worth supporting SurfaceFlinger in the test frameworks? | 19:17 |
| tedg | kgunn, Or should they just start jumping to Mir. | 19:17 |
| kgunn | tedg: if by "support surffling" | 19:18 |
| kgunn | you mean an integration test where surffling is in the stack | 19:18 |
| tedg | Have a backend for Auto Pilot for it | 19:18 |
| kgunn | the test shouldnt know | 19:18 |
| kgunn | if you mean to actually test surffling ...no | 19:18 |
| kgunn | waste of time | 19:18 |
| tedg | Yeah, it should be testing Unity on SF | 19:19 |
| MacSlow | thomi, QUESTION: I wonder what the ideal requirements autopilot would want to see in "NotifyOSD NG" for autopilot-testing notifications? Do you perhaps have a wishlist for this? | 19:19 |
| mmrazik | MacSlow: what is notifyOSD NG? a QML/Qt version of notifyOSD | 19:20 |
| kgunn | tedg: our honest target is to have unity on mir may-ish | 19:20 |
| kgunn | and mir should be "off" surffling on the phone platform by then as well | 19:20 |
| MacSlow | mmrazik, sorry... my bad... NotifyOSD NG (Next Generation)... it's the Qt/QML rewrite of NotifyOSD in a multi-form-factor world | 19:20 |
| tedg | kgunn, Cool, that makes sense. | 19:21 |
| tedg | mmrazik, thomi, ^ Unity on Mir May-ish | 19:21 |
| MacSlow | mmrazik, yes... | 19:21 |
| tedg | Then Surface Flinger can go back to Android :-) | 19:21 |
| MacSlow | thomi, mmrazik: I remember you suggested expose some state via DBus? | 19:21 |
| balloons | are the best practices recorded somewhere in the docs? If not, let's put them in there for app authors | 19:22 |
| balloons | small and sweet of course :-) but it's an honest question | 19:22 |
| tsdgeos_uds | mzanetti: i was wondering the other day while adding objectNames, that it makes the software use more memory "for nothing" | 19:22 |
| cjohnston | no wiki! | 19:23 |
| tsdgeos_uds | mzanetti: should we care about that extra few bytes of memory used? | 19:23 |
| MacSlow | mmrazik, thomi: so just the unique object-names mzanetti mentioned... ok | 19:24 |
| gema_ | not on mobiles xD | 19:24 |
| mmrazik | MacSlow: there is an workitem to document any best practices in the autopilot doc | 19:24 |
| cgoldberg | +1 for testability over mem optimization :) | 19:24 |
| MacSlow | mmrazik, thanks | 19:24 |
| tedg | Is there a way we could "build" the program and remove those? | 19:24 |
| vila | tedg: +1 was about to ask | 19:25 |
| mzanetti | MacSlow: feel free to ping me anytime for more detailed discussions about notifyOSD | 19:25 |
| roadmr | sort of like "stripping" the object names when publishing a production build | 19:25 |
| tedg | No reason to waste on systems that won't be doing testing. | 19:25 |
| gema_ | tedg: we should start thinking of dev versions vs released versions | 19:25 |
| MacSlow | mzanetti, I will... thanks | 19:25 |
| mzanetti | MacSlow: right now I don't know the architecture of notifyOSD | 19:25 |
| cgoldberg | then are those builds not testable once stripped? | 19:25 |
| mzanetti | MacSlow: so not too much I can say yet | 19:25 |
| roadmr | otherwise decision on which objects you're never going to test and need no names will eat useful brain cycles I think :/ | 19:25 |
| MacSlow | mzanetti, I'll toss you an email | 19:25 |
| tedg | cgoldberg, Not as testable, yes. | 19:26 |
| mzanetti | MacSlow: ok | 19:26 |
| balloons | thomi, haha.. message received | 19:26 |
| gema_ | mmrazik: +1 | 19:26 |
| cjohnston | balloons: you could try to get the autopilot test writers to help contribute to docs since they are already familiar with autopilot | 19:26 |
| roadmr | you want to keep memory consumption under control, so it has to be measured first, that'd rock | 19:27 |
| balloons | I owe thomi my tutorials to the docs | 19:27 |
| balloons | and of course, the further work should hit the docs too | 19:27 |
| cgoldberg | bet it's neglible | 19:27 |
| vila | you can put a lot of names into the space taken by a bitmap... | 19:27 |
| elopio | thomi: runner capabilities, like selenium? | 19:29 |
| vila | thomi: has been solved elsewhere | 19:29 |
| thomi | elopio: vila: I know | 19:29 |
| vila | thomi: keyworsd include fixtures, required features, feature flags | 19:29 |
| vila | thomi: +1 on testresources ;) | 19:29 |
| gema_ | more tests! | 19:30 |
| balloons | those who have used the tool.. time to speak up :-) | 19:30 |
| elopio | thomi: one problem we are having is that our test has to start the browser, do something there, and then get back to the website. | 19:30 |
| balloons | or talk about why you haven't.. (tho you should, it rocks) | 19:30 |
| elopio | so, webdriver integration? Probably needed for webapps testing too. | 19:30 |
| thomi | selenium backend - someone should write one! | 19:31 |
| thomi | ;) | 19:31 |
| vila | sleeps are bad | 19:31 |
| alesage | selenium yayz! | 19:31 |
| tsdgeos_uds_ | mmrazik: not a feature, but there is the "trick" that I found the other day and mzanetti confirmed, Apparently if you have an Item that inherits from another and adds no properties you can't really query for its type, you have to query for the parent item type | 19:31 |
| balloons | elopio, so really your saying your testing your backend desktop tool AND your browser extensions code at the same time | 19:31 |
| tsdgeos_uds_ | yeah and the recursive search! | 19:32 |
| balloons | so testing multiple things at the same time doesn't work so well? | 19:32 |
| balloons | +1 for search!! | 19:32 |
| elopio | balloons: that's the current user flow. | 19:32 |
| elopio | balloons: open the music lens, click a song, the browser will be opened. Buy the song, and get it on your desktop. | 19:32 |
| elopio | it's ugly and temporary, but that's what we have. | 19:33 |
| balloons | elopio, I would say simply, don't feel the need to test things you don't have to test persay | 19:33 |
| cjohnston | update the docs etc to say its being depricated | 19:35 |
| balloons | but in your case, so much is desktop related, shortcuts might not be possible.. for instance, normally I'd suggest not automating a browser if your not testing it.. but you are :-) | 19:35 |
| vila | as in being able to subscribe to a signal ? | 19:35 |
| vila | mzanetti: as in being able to subscribe to a signal ? | 19:35 |
| tsdgeos_uds_ | mzanetti: yeah if you need to watch for signals let's use qmltestrunner | 19:35 |
| cjohnston | I can't spell deprecated | 19:35 |
| mzanetti | vila: yes | 19:35 |
| gema_ | x) | 19:35 |
| vila | mzanetti: Please keep it ! | 19:35 |
| mzanetti | vila: whats the reason? | 19:35 |
| vila | mzanetti: that's the alternative to putting sleeps all over the place | 19:35 |
| elopio | balloons: we are trying hard to avoid it :) | 19:36 |
| mzanetti | vila: no, it isn't | 19:36 |
| mzanetti | vila: use assertThat(object.state, Eventually(Equals(someValue))) | 19:36 |
| mmrazik | that needs to go to the best practices | 19:36 |
| balloons | ^^ | 19:36 |
| vila | yeah, polling is implemented with sleeps... | 19:36 |
| mmrazik | :) | 19:37 |
| vila | that's still worse than being awaken when a specific event happen | 19:37 |
| mzanetti | hehe... actually true... | 19:37 |
| alesage | for the record http://unity.ubuntu.com/autopilot/tutorial/good_tests.html | 19:37 |
| elopio | something to add for the wishlist, so I won't forget later: I want the vis to highlight the component I click in the three. Just like accersicer does. | 19:38 |
| elopio | s/three/tree | 19:38 |
| alesage | elopio or like selenium IDE, e.g. :) | 19:39 |
| vila | mzanetti: in a nutshell, IMHO, using sleep or Eventually is the same, it's brittle | 19:39 |
| vila | indeed :) | 19:39 |
| mmrazik | elopio: would you mind creating a but against autopilot in launchpad? | 19:40 |
| balloons | elopio, vice versa would be even more fun eh.. hover or click part of the app, and get the tree :-) | 19:40 |
| mmrazik | in general -- everybody feel free to add bugs to the project even though they are features | 19:40 |
| elopio | alesage: or both. I like this sessions of requesting cool things I have no idea how to implement :) | 19:40 |
| elopio | mmrazik: will do. | 19:40 |
| vila | thomi: so my hope was that signals was a way to get a direct sync from the app | 19:41 |
| vila | better matching between the test expectations and the ap behavior | 19:41 |
| vila | better matching between the test expectations and the app behavior | 19:42 |
| cjohnston | the end of uds! | 19:46 |
| roadmr | nooo :( | 19:46 |
| gema_ | is there a closing plenary? | 19:46 |
| vila | the beginning of beer ? | 19:47 |
| mmrazik | gema_: don't think so | 19:47 |
| gema_ | ok | 19:47 |
| elopio | vila: yay. I'm in. It's only 2 pm here. | 19:47 |
| vila | elopio: :-D | 19:47 |
| tsdgeos_uds_ | thomi: mzanetti: yeah, unfortunate, just write it down somewhere | 19:48 |
| elopio | I just want to say thank you. | 19:48 |
| elopio | it's been a long way for us, first ldtp, mago, xpresser, sikuli. | 19:48 |
| elopio | now it's finally working with autopilot. | 19:48 |
| gema_ | we know where you are (evil laugh) | 19:49 |
| gema_ | thanks! | 19:49 |
| cgoldberg | thanks! | 19:49 |
| * tsdgeos_uds_ waves | 19:49 | |
| * thomi waves | 19:49 | |
| balloons | thanks everyone | 19:49 |
| gema_ | so... karaoke | 19:49 |
| nuclearbob | yep, I'll get it started shortly | 19:49 |
| vila | thanks to all | 19:50 |
| jfunk_ | +1 on the thanks | 19:50 |
| nuclearbob | https://plus.google.com/hangouts/_/0642ce7b16924e43f9afedf1b84235badd690f22?authuser=0&hl=en | 19:54 |
| === udsbotu changed the topic of #ubuntu-uds-client-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1303/client-2/ - http://ubottu.com/uds-logs/%23ubuntu-uds-client-2.log | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!