#ubuntu-uds-client-2 2013-03-05
* udsbotu changed the topic of #ubuntu-uds-client-2 to: Track: Client | Completing HUD 2.0 | Url: http://summit.ubuntu.com/uds-1303/meeting/21624/client-1303-hud-20/
<jasoncwarner> hi everyone. I just updated the hangout instructions for those joining via hangout. if you have the link, let me know if things are working. I'll start the broadcast at the top of the hour (6 minutes)
<tedg> https://blueprints.launchpad.net/hud/+spec/hud-20-client-base-libs
<Satoris> Let's just use troff markup. It is the standard way, after all.
<sladen> the "magic" noise-cancellation is all done with dual microphones
<sladen> and differientals
<sladen> put what in Multiverse?
<tsdgeos> julius i think
<tedg> sladen, Yes, julius is in multiverse, and we'd have to put hud-listen-julius
<pete-woods> https://launchpad.net/~pete-woods/+archive/sphinx/+packages
<pete-woods> http://www.voxforge.org/home/read
<tedg> http://www.voxforge.org/home/read
<tedg> https://blueprints.launchpad.net/hud/+spec/hud-20-voice
<tedg> https://blueprints.launchpad.net/hud/+spec/hud-20-service
<tedg> https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-hud-2-ui
<tsdgeos> my interwebs is running crazy
<tsdgeos> 1sec lag
<pete-woods> that's better than my normal ping :p
<udsbotu> uds-client-2: 5 minutes left in this session!
<udsbotu> uds-client-2: 4 minutes left in this session!
<udsbotu> uds-client-2: 3 minutes left in this session!
<udsbotu> uds-client-2: 2 minutes left in this session!
<udsbotu> uds-client-2: This session has ended.
<jasoncwarner> 10 minutes left
* 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
<jasoncwarner> actually, done :/
* udsbotu changed the topic of #ubuntu-uds-client-2 to: Track: Client | HW Accelerated Video Decode and Rendering support | Url: http://summit.ubuntu.com/uds-1303/meeting/21689/client-1303-hw-video-d
<jasoncwarner> Hi everyone. Session starts in 2 minutes.
<jasoncwarner> session is live...
<jasoncwarner> have about 45 minutes
<jasoncwarner> feel free to ask questions
<lool> may I get the hangout URL?
 * bryce waves
<tsimpson_> the link for the video/eitherpad is in the topic
<Lockyz> Waves
<lool> http://summit.ubuntu.com/uds-1303/meeting/21689/client-1303-hw-video-decode-rendering-support/
<lool> (topic has a truncated URL it seems)
<slomo> jhodapp: considering your constraints it is definitely a good idea to continue to use stagefright for accessing the device codecs (for the reasons you mentioned)... however writing a gstreamer plugin around stagefright is absolutely no problem, we're doing that (very similar) in the gstreamer sdk on android (just using a layer on top of stagefright, the java mediacodec api)
<lool> is the GStreamer Android SDK what you get from building as described on http://docs.gstreamer.com/display/GstSDK/Installing+for+Android+development ?
<slomo> lool: yes
<lool> jhodapp: slomo works on GStreamer upstream ^ in case you want to shoot questions
<lool> (hey slomo!)
 * lool hugs slomo 
<slomo> lool: hi :) i already talked to jim earlier :)
<lool> perfect  :)
<slomo> tvoss: gstreamer is not like openmax il, it's more like a combination of al and il
<tvoss> slomo, sure, I just wanted to point out that there is openmax and roughly map it to gstreamer
* udsbotu changed the topic of #ubuntu-uds-client-2 to: Track: Client | HW Accelerated Video Decode and Rendering support | Url: http://summit.ubuntu.com/uds-1303/meeting/21689/client-1303-hw-video-decode-rendering-support/
<ptl> How is the flip between software and hardware decoding? Is it automatic within the API, or through it?
<ptl> does gstreamer also deals with 3D/OpenGL?
<kgunn> ptl in mobile anyway...hwa is default, if its not present it falls back to sw
<slomo> ptl: short answer would be yes
<slomo> ptl: however you also can have full control over all that if you want to
<Ford_Prefect> So dalvik is definitely not going to be available? One concern was that libstagrfright can change any time Google feels like
<ptl> thanks
<jhodapp> slomo, can you describe for everyone a bit more about how Gstreamer SDK on Android works?
<Ford_Prefect> That might be a maintenance concern in the long term
<kgunn> ptl i know of at least one impl of gstreamer that TI did to get texture streamed video frames
<Ford_Prefect> (my question might make more sense in light of slomo's response)
<slomo> jhodapp: basically it's a gstreamer "distribution" for android, including plugins to access the device's codecs, including sinks for audio and video for android
<slomo> jhodapp: it just provides the normal gstreamer api to applications, and includes everything you need for using it on android
<Ford_Prefect> video: egl, audio: opensles, codecs: wraps the java MediaCodec API
<slomo> jhodapp: all the relevant code of it is also in gstreamer upstream. and you should be able to build upon many of these things (e.g. you could re-use the opensles audio sink, the egl/glesv2 video sink)
<slomo> for accessing the device's codecs you would need to write something yourself that wraps stagefright or something else
<slomo> because what we do is going throught he java layer (because that's the only public API on android that actually allows to access the codecs)
<slomo> tvoss: alternative: let gstreamer talk to your service, and let applications use gstreamer?
<tvoss> slomo, yup, that's what I'm trying to come down to
<slomo> tvoss: gstreamer is not like openmax il, it's not necessarily the lower layer directly on top of the hardware
<kgunn> bfiller: right Qt is just command
<tvoss> slomo, yup, so we would leverage gstreamer on the service side and on the app side
<slomo> tvoss: ack
<slomo> bfiller: note that qtmultimedia also has a gstreamer backend, which could make things easier for you
<willcooke> do we expect that, when speaking with content owners, the availability of a "known good" DRM'd video playback service (i.e. from Android) will make those conversations easier?
<tvoss> slomo, bfiller what api do we want to expose to html5/js? surely not qt?
<Ford_Prefect> For whoever's editing the whiteboard: you typically will not see audio from GSM on the CPU
<slomo> tvoss: the normal html5 media api?
<slomo> tvoss: are you planning to use webkit btw?
<Ford_Prefect> But the use-case is valid if you s/GSM/VoIP
<ptl> I see that stagefright is going to be supported for now, but how is going to be the long-term plan for not depending on it anymore? I mean, what are the migration paths and strategies?
<tvoss> slomo, @api, sure, but someone needs to implement it
<slomo> tvoss: well, use webkit and you're done ;) webkit has a very good gstreamer backend already that works fine on different platforms
<Ford_Prefect> I don't believe that audio codecs are typically h/w accelerated
<pmcgowan> agree
<rsalveti> not at android anymore
<slomo> yeah, they're definitely not on most socs
<rsalveti> afaik they are all using software decode now
<pmcgowan> tvoss: we should ensure whats working now with qtwebkit
<rsalveti> at least latest android versions
<tvoss> pmcgowan, sure, just curious
<slomo> tvoss, pmcgowan: yeah, qtwebkit is one of the webkit ports that works fine with gstreamer (the only other possible backend currently is qtmultimedia, which itself could also use gstreamer)
<lool> rsalveti: should I hop in the client-1 one?
<rsalveti> lool: client-1 is done
<lool> wow, good
<kgunn> lool: to be clear stagefright still there as well?
<slomo> lool: why wouldn't you expose gstreamer to apps though? i understand the reason for an abstraction (make it very simple for apps to do a few use cases), but what if someone wants to do something more complex you didn't consider?
<kgunn> lool: otherwise you loose known/good working drm plugins availalble on android
<slomo> kgunn: not having stagefright on android would be silly imho
<lool> kgunn: apparently stagefright is up for discussion on how we reuse it (listed as research)
<kgunn> slomo: agreeing w u
<lool> slomo: maybe there's a case to be made to have GStreamer as a high level API *and* a low level implementation
<pmcgowan> I assume we dont have access to source for the drm pieces, so could we use it?
<kgunn> http://developer.android.com/reference/android/drm/package-summary.html
<lool> slomo: the main reason I framed it that we didn't want to expose it is a result from a prior session where we wanted to hide the implementation
<kgunn> pmcgowan: ^
<lool> but then GStreamer is also pretty good at hiding the implementation
<slomo> lool: makes sense
<pmcgowan> kgunn: make sense to use the framework if we can
<slomo> tvoss: short answer would be yes, it could wrap around drm frameworks (and people do that)
<tvoss> slomo, interesting, that's good news. How do you account for restrictions where content is not allowed in ram?
<kgunn> pmcgowan: drm typically hw accel too...probably going to need to reuse (to be practical)
<slomo> tvoss: you could for example only pass some kind of "drm handle" through gstreamer... and code could then access that via drm framework specific API
<pmcgowan> do specific implementations use the framework, like a netflix client? assume so
<tvoss> slomo, ack, do you have some public example for that available?
<kgunn> pmcgowan: i believe so
<slomo> tvoss: we're talking about drm, do you expect people to make that open source ;)  however i could point you to some code that does something very similar (memory not directly accessible, only through another API)
<slomo> tvoss: you need the latter very often for hw accel video playback too
<tvoss> slomo, just curious :)
<slomo> tvoss: (detail: in gstreamer 0.10 you'll need something hackish for this, in 1.0 we added things to make this very clean to implement)
<ogra_> 0.10 is in universe (or on its way there at least)
<tvoss> ogra_, what about 1.0?
<ogra_> thats in since a while, ask Laney
<slomo> 1.0 is there too (fwiw, i'm doing the debian packages for gstreamer)
 * ogra_ is actually following the rolling release session, just jumping IRC channels on the side 
<slomo> jhodapp: don't focus too much on the gstreamer *SDK* part here, that's not very useful for you because it's only a gstreamer distribution and you'll have your own distribution
<jhodapp> slomo, good point
<slomo> jhodapp: for exposed API... imho there's a middle point between the two you have right now: plug what is available together in any possible way (and by that implementing new use cases, but not implementing new sources/sinks/filters)
<pmcgowan> oh heck
<rsalveti> pmcgowan: got some work items for you :-)
<pmcgowan> sure drm, great
<rsalveti> haha :-)
<lool> :-)
<Saviq|UDS> pmcgowan: it's not like it's the first time ;)
<pmcgowan> ha nope
<lool> tvoss: I think you'd want to lead the API question with me participating, ok with you?
<tvoss> lool, ack, sorry for being distracted
<Saviq|UDS> ubuntu-platform@?
<lool> jhodapp: have requested creation of ubuntu-platform@l.u.c already
<lool> Saviq|UDS: correct
<lool> for API discussions
<lool> (took that action in platform API session earlier)
* 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
<lool> jhodapp: are you copying back the pad notes into the bp?
<jhodapp> lool, yeah, I'll be doing that
<lool> thanks
<jhodapp> lool, and thanks for that creation request
<lool> np; thanks for leading an interesting session!
<rsalveti> thanks all
<jhodapp> lool, cool, glad you enjoyed it
<lool> it seems we have a ton of followup work and chats on this one  :)
<jhodapp> yes, it's an important and large topic
<jhodapp> can get quite complex too
<slomo> lool, jhodapp: so if you guys have any questions, feel free to talk to me... also including all parts of your work items list, that list looks very familiar ;)
<jhodapp> slomo, hehe, yes :)
<slomo> jhodapp, lool: do you have an irc channel for this too?
<jhodapp> slomo, we have the general ubuntu-touch one right now, but it may be a good idea to make a more specific one for media
<jhodapp> slomo, I'll let you know
<slomo> jhodapp: ok, thanks
<jhodapp> slomo, thanks for your participation in the session
<tvoss> slomo, yeah, thanks for being in the session
<lool> slomo: Might make sense to have one or not; not sure
<lool> would like to avoid fragmentation if we can
<lool> but then #ubuntu-touch is a bit busy
<lool> I'll defer to jhodapp to decide on this
<slomo> lool: ok, i'll just stay there for the time being then :)
<lool> that channel definitely going away after UDS  :-)
<jasoncwarner> Hi everyone. session starts in 1/2 hour.
* udsbotu changed the topic of #ubuntu-uds-client-2 to: Track: Client | Audio support with PulseAudio and AudioFlinger | Url: http://summit.ubuntu.com/uds-1303/meeting/21627/client-1303-sound-support-pulse-audioflinger/
<jasoncwarner> hi everyone...going to start here very soon!
<rsalveti> Ford_Prefect: hey!
<Ford_Prefect> o/ rsalveti
<jasoncwarner> if you have qustions, make sure you ping me on IRC to bring to my attention
<TheMuso> Urm, how do I unmute myself?
<TheMuso> i.e what am I looking for visually?
<TheMuso> SInce this is mostly inacccessible...
<diwic2> TheMuso, red icon upper right
<rsalveti> TheMuso: there's mic icon at the top, right after the hangout title
<zyga-uds> is the video rolling yet?
<nuclearbob> nope
<Saviq|UDS> rsalveti: can't hear you at all
<Saviq|UDS> rsalveti: audio is completely robot-like
<Saviq|UDS> anyone else?
<ptl> "This live event will begin in a few moments." - no image/audio
<ptl> Let me reload.
<diwic2> sounds like a lack of bandwidth problem
<nuclearbob> yeah
<Saviq|UDS> \o/
<ptl> I can hear ricardo now
<Ford_Prefect> ptl: should be rolling now
<lool> issues with audio in an audio stack session...
<Ford_Prefect> LD
<Ford_Prefect> :D
<ChickenCutlass> awe_: yes the data goes over binder
<lool> will we have an API for (re-)routing audio?
<lool> I guess we'll abstract away things like sound input/output
<lool> but there might be need to change e.g. how devices are routed
<zyga-uds> QUESTION: is that the direction we want to work towards for the long term? If so, does that affect any existing desktop apps as far as expsting the audio stack to work as it does on non-android kernel?
<ChickenCutlass> the problem with getting rid of audio flinger is the kernel drivers do not support them
<zyga-uds> s/expsting/expecting/
<ChickenCutlass> I mean the audio drivers do not support everything needed for alsa
<ptl> so isn't it a case of just improving the features of the given audio drivers?
<lool> other question (from hw decode session): how do we handle sync between audio and video?
<tanuk_> Is the hardware configuration written for HAL or AudioFlinger (afaik AudioFlinger works on top of HAL, but I don't know if AudioFlinger needs any hw-specific configuration)
<lool> I was thinking of e.g. you press the speaker output button, audio gets to the speaker
<lool> one needs to be able to do this from apps
<lool> or you are implementing a conferencing app and want to send audio either to the speaker, or to the headset
<lool> diwic: Do we have tests that we can use to validate whether drivers are good enough for pulseaudio?
<diwic2> lool: test suites are never complete, unfortunately
<lool> awe: rsalveti: Could one of you two relay the concerns from hw decoding support and sync issues that we need to support?
<lool> also, routing for voice (modem) stack
<lool> (I am jumping between video streams, so not necessarily following everything which is being said unfortunately)
<Saviq|UDS> QUESTION: what about bluetooth? is HFP not going through CPU either?
<rsalveti> lool: modem usually goes via modem directly
<rsalveti> and don't know if we'd have any issue with hw decode support, at least Ford_Prefect didn't have any issue when replacing audioflinger with pulseaudio
<rsalveti> as the media service will just end up using the audioflinger api, which will go via libpulse in this case
<ptl> replacing? I thought pulseaudio was running on top of audioflinger..
<rsalveti> in this case yes, not what Ford_Prefect did a while ago
<rsalveti> ptl: http://arunraghavan.net/2012/04/pulseaudio-on-android-part-2/
<lool> rsalveti: thanks
<ptl> ah, thanks
<ptl> brb, video stopped, will reload
<lool> rsalveti: so libubuntu-app-api -> libpulse -> pulseaudio -> libasound -> kernel drivers, and mediaservice -> libpulse -> pulseaudio -> libasound -> kernel drivers?
<Saviq|UDS> lool: or potentially s/libasound/HAL/
<lool> Saviq|UDS: quite a big difference!
<rsalveti> lool: do we want libubuntu-app-api for it as well?
<lool> rsalveti: I guess
<rsalveti> not something we discussed
<lool> rsalveti: another question related to libubuntu-app-api for it as well?
<lool> 19:47 < lool> rsalveti: I guess
<lool> ups
<lool> rsalveti: another question related to libubuntu-app-api that I've asked earlier is whether we want audio routing API for this
<lool> rsalveti: e.g. I want to switch audio output from headset to speaker or vice-versa
<lool> or I want to mute this or that
<lool> I should have joined the session early rather than trying to follow multiple sessions
<Saviq|UDS> lool: probably a topic for ubuntu-platform@
<lool> definitely
<lool> Saviq|UDS: good point though, might want to mention that we need to followup on platform APIs
<lool> I'm a bit worried that we will end up requiring a media service, and then pulseaudio looks weird in the picture
<Ford_Prefect> rsalveti: audio's broken up again :/
<Saviq|UDS> gone
<rsalveti> sorry
<Saviq|UDS> rsalveti: try disabling your cam
<rsalveti> Saviq|UDS: indeed
<Saviq|UDS> Ford_Prefect: is echo cancellation a special case?
<rsalveti> lool: it's fine to have both pulse and media service
<rsalveti> at android we have media service + audioflinger
<rsalveti> so we'd just be replacing the audioflinger part
<rsalveti> lool: it scares me that we also want an ubuntu platform api abstraction for audio :-)
<lool> right; I was kind of making a blob out of media service + audioflinger
<lool> shoudl be cleaer
<lool> rsalveti: me too, but I kind of understand where tvoss comes from to suggest this
<rsalveti> still :-)
<lool> rsalveti: On the other, I would be less confortable to commit to using libpulse as stable API instead of e.g. libasound2
<lool> at least we can do libasound2 -> libpulse -> whatever
<rsalveti> diwic: Ford_Prefect: thanks for joining in
<rsalveti> awe_: thanks for taking notes :-)
<Ford_Prefect> Happy to pitch in. :)
<awe_> rsalveti, anytime!
<rsalveti> sorry if I'm a bit slow today, not feeling so good
<lool> rsalveti: you got my ubuflu over the air
<Ford_Prefect> I certainly couldn't tell
<diwic> Ford_Prefect, yup thanks for joining. I'll need to investigate the UCM stuff, still feels a bit immature compared to just doing pulseaudio profiles
<rsalveti> lool: lol, yeah
<Ford_Prefect> In general, I'm usually around on IRC, so feel free to ping me if you hit any problems with Android integration or anything else
<rsalveti> cool
<Ford_Prefect> diwic: one advantage with doing UCM is testing with straight-up alsa becomes easier
<rsalveti> Ford_Prefect: we usually hang around at #ubuntu-touch
<diwic> Ford_Prefect, true
<Ford_Prefect> rsalveti: cool, I'm there now
<diwic> Ford_Prefect, do we even support hw mixer control through ucm? I mean, setting the mic gain e g.
* udsbotu changed the topic of #ubuntu-uds-client-2 to: Track: Client | Containers and host/client model for Android + Ubuntu | Url: http://summit.ubuntu.com/uds-1303/meeting/21626/client-1303-containers-host-client-ubuntu-android/
<Ford_Prefect> diwic: there is supposed to be API to say "use this mixer", but I don't think there's one to express a mixer hierarchy
<diwic> Ford_Prefect, moving to #pulseaudio
<Ford_Prefect> ack
<jasoncwarner__> hi everyone. session will start in 3 minutes
<lool> coming live
<lool> (soon)
<tedg> Faster!
<tedg> :-)
<jasoncwarner__> hi all...if you have quesitons, ping me here
<mdeslaur> \o
<lool> stgraber can't be there unfortunately (conflict)
<tedg> jasoncwarner__, Why does Android need to be in a container?
<tedg> Could we run the services without Android init?
<tedg> Benefit: Being able to apt-get upgrade a kernel :-)
<tedg> Seems like setting up different paths would be clearer.
<tedg> Won't we need to remove those features anyway?  Or patch them?
<tedg> We don't really want the system services writing somewhere odd.
<rsalveti> we can't patch binaries
<rsalveti> we'd need to abstract bionic calls
<tedg> We could use apparmor to rewrite the paths.
<rsalveti> right, but that's not specific to android, that changes depending on the device
<rsalveti> so we'd need device specific rules, which is a pain
<tedg> Sure, but it'd let us use the android services without a container.
<tedg> We could use something like /etc/$(servicename)
<tedg> awe_, I think you can upgrade the Android components as a single package.
<tedg> awe_, So then you could make the hybris versions match, in a single upgrade.
<rsalveti> tedg: sure, but we also want to avoid making more work for the porters
<tedg> rsalveti, Seems like it'd be easier as they'd just make one package, no?
<rsalveti> not necessarily, there might be device specific services as well
<tedg> rsalveti, Instead of figuring how to start up the Ubuntu side, etc.
<tedg> ChickenCutlass, I think if you're running in a container, you have to think of it as two OSes.
<tedg> ChickenCutlass, Especially with a PID namespace.
<tedg> A lot of command line tools people use for debugging.
<tedg> Also, with out /proc doesn't apport have problems?
<mfisch> They both get the event I think
<rsalveti> I'd expect so
<awe_> mfisch, that's my guess too.  Haven't had a chance to talk to anyone on the kernel team.  I plan on bringing this up during our kernel session tomorrow...
<tedg> ChickenCutlass, Don't we already have that with /opt/extras* ?
<ChickenCutlass> tedg: for apps you mean
<tedg> Yes
<ChickenCutlass> tedg: yes, but would need to force apps there
<tedg> ChickenCutlass, We already do, no?
<ChickenCutlass> we do
<mfisch> can you use bind mounts so that ubutnu apps don't have to change?
<mfisch> or change as much
<tedg> mfisch, We looked at that, but were told that the mount command is too slow.  Would actually effect startup time.
<mfisch> tedg: I'd love to have any data you have on that
<tedg> I think "One System" is easier -- Two is super confusing.
<tedg> mfisch, I believe that I was told that by mdeslaur
<tedg> I think the most sane solution to target short term is put Android in a container.
<mdeslaur> +
<tedg> Then we can pull it out if it makes sense.
<mdeslaur> +1
<tedg> But then it can be one package easily.  With a reasonable update.
<tedg> jasoncwarner__, It seems like we've now listed the options again, can you force a decision?  :-)
<tedg> Do we care about any of those devices?  I mean, having a port is not our goals.
<tedg> Our goals is to have a device of our own.
<rsalveti> tedg: can't be one package necessarily, it'd be one package per device
<tedg> Using someone else's is the same problem we've got on the desktop today.
<rsalveti> or one package for android + another package for device specifics
<tedg> rsalveti, Yes, I was thinking a "provides: android stuff" and then multiple packages could provide that.
<rsalveti> tedg: porting is kind of our goal
<rsalveti> we want people to use and work with it
<awe_> tedg, the problem is that it may not be technically possible
<rsalveti> that's why we created the porting effort
<rsalveti> let's not drop that
<tedg> awe_, We still need a decision for our plan from this session.
<awe_> tedg, we don't have enough information to make a decision today
<tedg> rsalveti, I think we should drop it if it at all puts at risk the possibility of having our own device that is great.
<awe_> If I was a betting man, I would bet against this being technically possible w/out alot of custom tweak to Android
<tedg> awe_, I find it hard to believe you're not a betting man ;-)
<tedg> I think we should say where we want to go and try to get there.  Then we can reevaluate.
<tedg> The problem is other people need to figure out if they have to work around all the BS in the Android container stuff.
<rsalveti> tedg: we're not putting anything at risk :-)
<rsalveti> we're trying to find a better solution, that's all
<mfisch> tedg: I (or a delegate) will probably investigate the mount time stuff and get back to you
<rsalveti> so let's just not break other devices or any porting effort
<ali1234> i think there's a misunderstanding here
<tedg> mfisch, Great, thanks!
<ali1234> lool is talking about eg extract_files.sh
<ali1234> the existing system doesn't use any files from the previous full android install
<ali1234> except during build
<tedg> That was me.
<lool> any question from here?
<tedg> Sure, but if we're looking at one service.
<tedg> It might easier to do a single path rewrite than a whole container.
<tedg> No questions.  No decisions to question.
<ogra_>  /dev as overlayfs !
<ogra_> :)
<xnox> 8) wtf?!
 * xnox is clearly missing context
<ogra_> xnox, i was commanting to the hahngout
<mfisch> where will the results of these investigations go?
<mfisch> a link to a doc from the blueprint would be ideal
<ogra_> enjoy the bar !!!
* 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
<lool> awe_: updated blueprint with notes and wis
<awe_> thanks lool!
#ubuntu-uds-client-2 2013-03-06
* 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
<tkamppeter> Can someone invite me into the hangout?
<pitti_uds> hm, the video isn't on yet, is it?
<pitti_uds> I see "starts in a few moments"
<jasoncwarner> tkamppeter: see orther IRC channel, I pasted you the link
<jasoncwarner> we still have space free on the hangout if anyone else is interested in joining
<pitti_uds> meh @ video, reloading the page throws me out of IRC
<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?
<tkamppeter> pitti_uds, link for the hangout: https://plus.google.com/hangouts/_/39beb4c0269f04a0f04e218d605e9d67718e3993?authuser=0&hl=en
<jasoncwarner> just starting now folks!
<pitti_uds> tkamppeter: tried, but "hangout ended due to a server error"
<pitti_uds> retrying
<pitti_uds> same error
 * pitti_uds reloads page to see the live stream
<pitti_uds> ok, no live stream, no hangout
<larsu> pitti_uds: :(
<pitti_uds> I might have missed an answer during reconnect, any question/problem we can think about while you are setting up?
<pitti_uds> oh, perhaps I'm not marked as required for this session
<pitti_uds> (whatever that means, but I heard it's a prerequisite)
<tsdgeos_uds_> is this live? I'm getting "This live event will begin in a few minutes"
<ssweeny> IIRC the track lead has to invite folks into the hangouts
<pitti_uds> ok, I see Till live now
<tsdgeos_uds_> same here
 * tsdgeos_uds_ raises hand as poppler maintainer
<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
<tsdgeos_uds_> pitti_uds: not a question, i'm just saying i'm around
<jasoncwarner> tsdgeos_uds_: did you want to join the session?
<tsdgeos_uds_> jasoncwarner: i'm listening, not much to say
<ritz> systemd in theory allows for on demand startup
<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
<ritz> using socket activation
<tsdgeos_uds_> jasoncwarner: ââ that obviously for you not for me :D
<tsdgeos_uds_> no i don't have a question :D
<pitti_uds> tsdgeos_uds_: ack :)
<jasoncwarner> tsdgeos_uds_: https://plus.google.com/hangouts/_/39beb4c0269f04a0f04e218d605e9d67718e3993?authuser=0&hl=en
<tsdgeos_uds_> ok, joining
<pitti_uds> ritz: yeah :) but I don't think we'll get that anytime soon
<ritz> pitti_uds were we not trying this with upstart ?
<ritz> on demand service
<ritz> via dbus
<pitti_uds> ritz: if it can do it somehow, that'd be great of coures
<seb128> ritz, dbus activation != socket activation
<pitti_uds> ritz: but that only covers d-bus activation if you try to talk to cups over dbus, not the unix socket
<pitti_uds> which is the main way to talk to cups really
<pitti_uds> on dbus there's only job notification AFAIK
<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?
<ritz> not very familiar with upstart
<pitti_uds> kyleN: just fewer seeds presumably; we already have the split in quantal
<kyleN> ack
<tedg> tsdgeos_uds_, Asking in #inkscape to see if I can find some color folks.
<tsdgeos_uds_> tedg: tx
<tedg> The other problem we have is that Mir doesn't have a color management story yet.
<tedg> So we might be able to punt a bit on color management.
<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.
<tedg> tsdgeos_uds_, I was sent this: http://www.oyranos.org/wiki/index.php?title=Test_Images#PDF
<tedg> larsu, Can you add a work item for design to help with the dialog?  jnicktait
<tedg> larsu, pitti_uds, it wouldn't be an issue if you guys would stop using a stupid size like A4!  US Letter!  ;-)
<larsu> tedg: done. thanks
* 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
<qengho> Hi hi
<qengho> = chad miller
<jasoncwarner_UDS> hi everyone...
<jasoncwarner_UDS> session will begin in a minute
<mdeslaur> does anyone want to participate on hangout?
<jasoncwarner_UDS> someone is having mic probs
<jasoncwarner_UDS> qengho , you seem like you would like to hangout ;)
<qengho> jasoncwarner_UDS: Yes, I do.
<mdeslaur> showing up on hangout doesn't automatically mean you get work items
<mdeslaur> :)
<qengho> mdeslaur: In fact, if one can't talk, one is more likely to just be assigned them.  :)
<jdstrand> you know, I only use this like 10 times a week
<mdeslaur> We are currently experiencing technical difficulties. Your call is important to us. Please stay on the line.
<xnox> What's the hangout url?
<xnox> ok.
<jasoncwarner_UDS> xnox and qengho https://plus.google.com/hangouts/_/87858bba77dc51229f080c9df9b930418b03173a?authuser=0&hl=en
<xnox> jasoncwarner_UDS: hehe and everyone joins now =)
 * Laney will actually
<jdstrand> \o/
<jdstrand> mdeslaur: everything is in the etherpad
<Laney> NOISE
<xnox> Laney: ok.
<Laney> :-)
<mardy> mdeslaur: they did it already
<mardy> mdeslaur: it's qt5 only now
<jdstrand> mdeslaur: I have a proposal in etherad
<jdstrand> etherpad
 * jdstrand has no volume controls at all
 * jdstrand shakes fist at computer
<qengho> Yes, we heard something.
<qengho> Perfect.
<qengho> Are you running Skype also?
<Laney> jdstrand: you might need http://blog.didrocks.fr/post/Getting-sound-working-during-a-hangout-in-raring
<tkamppeter> kyleN, the phone printing stack does not inviolve different packages, I will simply split binary packages to allow the desired small-footprint stack.
<vrruiz> If neither KDE and Gnome have resources to keep backporting patches, why do you think Ubuntu will? :-/
<mdeslaur> vrruiz: if we're going to use a webkit engine in our sdk and our browser, we have no choice
<mardy> why not base on QtWebkit, since it's the one most relevant for our developers?
<mdeslaur> mardy: nobody is backporting security features to qtwebkit
<mdeslaur> I suspect we'll be using the qtwebkit bindings though
<mardy> mdeslaur: I mean, you would :-)
<mdeslaur> s/features/fixes/
<mdeslaur> yes, we could possibly be the ones maintaining qtwebkit
<mdeslaur> we're not implying we wouldn't be doing this upstream
<qengho> I like jdstrand's proposal, pulling from APPL and our maintainence of minor patches atop them.
<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?
<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
<mdeslaur> vrruiz: sure, if upstream projects are ready to completely freeze the API, no problem
<xnox> There are other companies that will be using QtWebkit on the mobile-like platforms.
<xnox> Would be nice to share the cost of webkit maintenance.
<vrruiz> Blackberry is using Qt in BB 10
<mardy> convince Opera to use QtWebKit ;-)
<alex_abreu> mardy, ahah
<mdeslaur> xnox: +1
<vrruiz> mardy: Aren't they actually using Chromium?
<mardy> vrruiz: yes, they are
<mardy> mdeslaur: especially with WebKit2, things are changing a lot
<mardy> mdeslaur: on the bright side, it seems that Qt bindings are using more and more the C bindings
<mardy> jdstrand: it's in continuous development
<alex_abreu> jdstrand, I think so yeah
<mardy> (that's not to say that's unstable)
<qengho> 10 seconds + thinking + typing delay.
<Mirv> WK2 is used on 2011 Nokia N9, quite stable and nice (no doubt was a lot of work back then)
<qengho> jasoncwarner_UDS: FWIW, the Lower Third hangout app on the left is indeed dead, and it's
<Laney> it will be interesting to know if apple are making API changes that will make the rebasing difficult
<qengho> moved into the Hangout Toolbox app.
<Laney> what excellent timing
<chrisccoulson> heh
<vrruiz> bye
<jdstrand> Laney: we're that good :)
<mdeslaur> Laney: possibly...I don't think they care too much about breaking stuff that may impact other bindings then their own
<chrisccoulson> right, back to debugging jit code ;)
<qengho> chrisccoulson: Ugh.  Still?
<Laney> indeed
* 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?
<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
<chrisccoulson> which is interesting ;)
<alex_abreu> chrisccoulson, ff on arm?
<chrisccoulson> alex_abreu, no, chromium
<chrisccoulson> ff works fine on arm btw ;)
<alex_abreu> chrisccoulson, oh interesting ... any lp bug on that?
<qengho> chrisccoulson: I remember some mention of a security bug WRT the JIT and memory contexts. I wonder if it's related.
<chrisccoulson> alex_abreu, not yet
<chrisccoulson> qengho, ah, interesting
<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
<Laney> the jit is disabled on the webkitgtk arm build due to bug
<Laney> buh
<Laney> due to https://bugs.webkit.org/show_bug.cgi?id=85076
<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
<chrisccoulson> Laney, this is v8 though ;)
<chrisccoulson> (not JSC)
<tvoss> lool, cool, thank you
<Laney> fair enough
* 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?
<chrisccoulson> alex_abreu, no, it's not GC related
<jasoncwarner_UDS> session will start in 3 minutes
<jasoncwarner_UDS> hi folks...have spots open for those interested in joining the hangout
<jasoncwarner_UDS> https://plus.google.com/hangouts/_/0ec0ef5db83f0a1952bc68dfb0337d646e9d288d?authuser=0&hl=en
<cyphermox> I'm familiar with geoclue
<cyphermox> mkay
<cyphermox> I mean, rather than rewriting lots of stuff, let's fix and provide fixes upstream
<desrt> cyphermox: is there a chance we could assume control of the existing project?
<cyphermox> possibly I don't know
<cyphermox> last I checked it didn't seem super active
<cyphermox> but then again, maybe it also largely works and that's why it's not being a flurry of commits
<desrt> who is the last maintainer-type person?
<larsu> the description of the session says it's pretty much dead
<Cheesehead> IIRC, the old maintainer offered it for adoption, no takers
<desrt> so let's adopt it?
<desrt> Cheesehead: got a citation for that?
<xnox> We can cache apt data and fake it / provide that those core packages are available.
<cyphermox> hadess might have been the last maintainer?
<Cheesehead> desrt: Sorry, old memory. Perhaps an old mailing list.
<larsu> daniel was in contact with the last maintainer
<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
<cyphermox> whether that means adopting the project or whatever else is fine
<cyphermox> larsu: could you add lower third?
<cyphermox> tvoss: ^
<larsu> lower third?
<Mirv> larsu: hangout toolbox app, installable from the left bar
<Mirv> larsu: only works in chromium though
<tvoss> cyphermox, I tried, but it's shown on the upper tird :)
<cyphermox> tvoss: oh, so it is!
<cyphermox> I briefly saw it
<tvoss> cyphermox, weird though
<cyphermox> yes, totally agree it can / needs to be improved
<desrt> 11:19 < hadess> desrt, by a newer version, i have some apis scribbled on pieces of paper (notes on my computer)
<desrt> 11:19 < hadess> desrt, less moving parts, stuff that works
<desrt> 11:19 <@desrt> hadess: canonical wants to do the same
<desrt> 11:20 < hadess> desrt, satabdi has been working on ip geolocation, and (rev)geocoding in geocode-glib
<desrt> 11:20 <@desrt> hadess: so do you plan to torch the current codebase?
<desrt> 11:20 <@desrt> hadess: and what is your timeline?
<desrt> 11:20 < hadess> desrt, yep, it's pretty clear it's not usable
<desrt> 11:20 < hadess> desrt, timeline is "when i have time"
<desrt> FYI
<desrt> looks like the reason upstream is dead is because upstream thinks that the current codebase is not worth it
<cyphermox> tvoss: that's a good point
<desrt> 11:21 < hadess> (it's been pushed back at least 2 cycles already because of no time)
<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 ;)
<cyphermox> esp. for a project relatively as isolated/self contained as geoclue
<cyphermox> it *is* a complex decision on that end, though, definitely
<cyphermox> yeah
<cyphermox> basically, very rough tests to check the exisitng impl, refactor, make the tests good, refactor, repeat
<cyphermox> at least making sure we don't introduce regressions
<cyphermox> interesting
<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"
<desrt> there is going to be a rewrite one way or another, it seems
<cyphermox> desrt: in terms of majorly overhauling the code base, yeah ;)
<desrt> imho we should try to share the component, though
<cyphermox> so there already is code...
<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
<cyphermox> desrt: can you pull hadess here?
<desrt> i tried.  he's not interested :)
<cyphermox> his input may be useful
<cyphermox> oh ;)
 * desrt tries again
<cyphermox> we can help with the "lack of time"
<desrt> indeed
<desrt> he has notes on the new design... i asked if he could publish them somewhere
<desrt> hadess: hey.  welcome.
<cyphermox> assuming we can spend time writing the code from the api he designs
<hadess> desrt, they're more "nice to haves"
<cyphermox> hey hadess, thanks for coming
<cyphermox> tvoss: +1
<tvoss> hadess, hey, thx for being with us
<hadess> desrt, including things that aren't currently possible, such as authorisation and sandboxing
<jasoncwarner_UDS> hadess: want to join the session?
<jasoncwarner_UDS> desrt as well?
<jasoncwarner_UDS> https://plus.google.com/hangouts/_/0ec0ef5db83f0a1952bc68dfb0337d646e9d288d?authuser=0&hl=en
<desrt> jasoncwarner_UDS: i don't have the google hangout plugin, nor h264 video support :(
<hadess> no thanks
<jasoncwarner_UDS> desrt: what year is it where you live? ;)
<cyphermox> haha
<jasoncwarner_UDS> hadess: no worries
<jasoncwarner_UDS> thanks for joining the irc
<desrt> hadess: so part of why you're stalled is missing infra from other places too?
<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?
<hadess> desrt, i think it would be almost impossible to retrofit
<desrt> right.  we're talking rewrite already
<desrt> but if canonical is already thinking of doing a rewrite, we may as well pool resources
<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
<cyphermox> do we need much of that provider description?
<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
<cyphermox> hadess: cool
<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
<cyphermox> hadess: do you mean you're writing GPS-A support?
<hadess> cyphermox, no, that somebody should
<cyphermox> ack
<cyphermox> I think there's some of it in progress
<desrt> hadess: what's the plan for how the data gets from modemmanager to apps?
<cyphermox> desrt: modem location support is provided via a dbus interface from MM
<hadess> desrt, a small dbus service, the api is pretty much that of core location
<desrt> hadess: and this does the wifi/ip-based ones as well?
<hadess> desrt, it would, yes
<desrt> so this is the to-be-written
<hadess> desrt, "give me my location" and it would choose the way to access it based on accuracy required
<hadess> yeah
<cyphermox> yeah
<desrt> the main difference here is that it's just one simple process instead of a gaggle of providers
<hadess> yes, and without support for stand-alone gpses either
<desrt> tragic :p
<cyphermox> omg
<desrt> hadess: then your concern moves to how to prevent unworthy apps from hitting this dbus interface
<desrt> i assume it's meant to be a system service
<cyphermox> totally agree, syncing with hadess, comparing requirements/plans
<hadess> desrt, i don't think it needs to be a system service
<desrt> hadess: so any user would have to be able to read data out of modemmanager then
<desrt> ditto things like wifi AP mac addresses (that's how wifi-based geocode works, right?)?
<hadess> desrt, the way things work right now, yes, but that's the same trying to configure your wwan broadband right now
<desrt> hadess: almost starts to seem like we don't need a service at all, then?
<hadess> it doesn't need to run as a system service, but if it runs as a session service, it needs to be special
<desrt> why not just have a library do the work in app context?
<dcbw> do we consider location infromation privileged?
<desrt> dcbw: yes.  we ought to.
<dcbw> eg, how do we gate access to it?
<hadess> desrt, because that would make it impossible to sandbox
<dcbw> in that case, normal users shouldn't be able to ask ModemManager for location info
<desrt> dcbw: this goes to the larger sandboxing question
<desrt> hadess: you could sandbox at the mechanism level
<desrt> hadess: no access to modemmanager data, for example
<dcbw> we already have PolicyKit support for location stuff in MM
<dcbw> we just don't turn it on by default
<dcbw> but that's not really a model we want these days
<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
<dcbw> it should be remembered on a per-app basis instead of a global PK dialog
<hadess> desrt, a separate service would also take care of power management
<desrt> interesting.
<hadess> desrt, no point calling doing network calls if you have a good enough data from the modem for another app for example
<desrt> who is the one on the canonical side who has time to work on this?
<larsu> desrt: looks like daniel
* 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.
<lool> session starting in 4 mn
<zyga-uds> hey everyone
<zyga-uds> lool: could you announce when the session goes live please
<awe_> zyga-uds, it's live now
<roadmr> zyga-uds: it is, reload, reload
<asb_asb_asb> sucky youtube widget
<rsalveti> lool: awe_: can we dynamically request NM to rescan for aps?
<dcbw> rsalveti: already present
<rsalveti> awesome
<dcbw> rsalveti: there's a Scan method in 0.9.8
<zyga-uds> QUESTION: will the converged stack affect testing or certification performed on non-touch/mobile systems
<dcbw> anyone got a hangout link for the chat?
<pitti_uds> NM is 3.9 MB RSS, even dhclient is 3.0
<pitti_uds> that doesn't seem terribly much?
<asb_asb_asb> pitti_uds: nm-applet is the real hog
<dcbw> root      1371  0.0  0.0 205176  3020 pts/0    S+   06:47   0:00 sudo src/.libs/NetworkManager --no-daemon
<cyphermox> aye
<dcbw> dcbw      1191  0.0  0.5 710736 19464 ?        Sl   06:46   0:08 nm-applet
<zyga-uds> vUDS needs a conflict resoultion protocol for the speakers to agree upon to minimize collision lag
<dcbw> nobody's denying that nm-applet needs a diet:)
<cyphermox> I also mentioned I'd look at how we can reduce both
<qwebirc105673> dcbw: want to join the hangout? https://plus.google.com/hangouts/_/e852387d7e4db65b443695b981fc9ad4431aaed1?authuser=0&hl=en
<awe_> pitti_uds, it's not... it was just one criteria that we wanted to measure
<asb_asb_asb> 14.4mb as shown by ps_mem.py
<dcbw> thanks
<pitti_uds> awe_: right, thanks
<pitti_uds> agreed about nm-applet
<roadmr> does modem-manager handle... oh never mind, it'll go away
<awe_> hey dcbw...long time!
<qwebirc105673> pitti_uds: if you want to join the hangout as well, feel free!
<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
<zyga-uds> lool: ^^
<ogra_> dcbw, your typing steals the video focus
<dcbw> awe_: yo :)
<pitti_uds> hey dcbw, thanks for showing up
<ogra_> dcbw, better mute if you dont speak
<pitti_uds> qwebirc105673: not enough to contribute, I'm afraid
<rsalveti> zyga-uds: but I'd say that's more of a bug
<rsalveti> it is indeed annoying
<zyga-uds> rsalveti: no, it has to try otherwise it'd require some manifests to idenitify modems, right?
<dcbw> ogra_: yeah, muted already
<ogra_> :)
<zyga-uds> rsalveti: it's a problem whenever you have a serial port showing, up, mm will try talking to it
<rsalveti> right, that's why I said it'd be more of a bug for me
<rsalveti> because I don't think this is the desired behavior
<dcbw> we did just add ModemManager1 support, so that's a good patch to look at
<rsalveti> it breaks everyone that needs to use serial based devices
<dcbw> that basically adds a completely new MM backend
<zyga-uds> rsalveti: I don't see a fix for that that would not break modem support for virtually everyone
<zyga-uds> rsalveti: even if you only look at 3G modems
<zyga-uds> rsalveti: I agree on that
<zyga-uds> rsalveti: one thing I tried to do to fix that
<zyga-uds> rsalveti: is to blacklist certain ttys in udev rules
<zyga-uds> rsalveti: and I got that to work for my development boards and generic serial-usb dongles
<zyga-uds> rsalveti: if you want I can share that
<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
<zyga-uds> rsalveti: that crashes bootloaders for me
<rsalveti> zyga-uds: I think we have a bug opened for that
<rsalveti> let me try to find it
<zyga-uds> rsalveti: cool, I'm interested in fixing that
<zyga-uds> rsalveti: in the end the rules for mtp and modem manager need patching
<zyga-uds> rsalveti: then the system is generic enough to have per-package rules that blacklist a device
<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
<zyga-uds> ok
<cyphermox> you're obviously welcome to bring things up, ping me if you feel your questions are being ignored
<ChickenCutlass> awe_: we also want rild support
<zyga-uds> cyphermox: no, I guess those are implementation bugs/details
<victorp_> if it doesnt have voice support it wont
<rsalveti> zyga-uds: yeah, need to take a better look at that, but I know we have a bug :-)
<victorp_> pass cert
<cyphermox> doubtful that ofono was any more certified though... holtmann do you know?
<awe_> ChickenCutlass, I'll get there
<holtmann> We went throughout GCF certification with oFono.
<holtmann> You guys need to think about SIM Toolkit support.
<victorp_> cyphermox: it has been certified for GCF
<cyphermox> ack
<holtmann> That is the first thing that is going to be asked.
<cyphermox> thanks
<zyga-uds> lool: do we consider a situation where the vendor might replace the telephony stack, is that something they do on android today?
<cyphermox> stgraber: esp. leverage all the work we've done and simplify convergence
<victorp_> stgraber: that sounds good
<lool> zyga-uds: they'd have to pass certification again
<cyphermox> ah, yes the caps bits
<victorp_> zyga-uds: they do that today , yes
<cyphermox> awe_: I'm preparing MM1 on a PPA
<cyphermox> https://launchpad.net/~network-manager/+archive/modemmanager-next (incomplete)
<victorp_> does modem manager work with rild?
<victorp_> awe ^
<awe_> no
<dcbw> no, it doesn't
<dcbw> a rild connector would be nice to have
<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?
<victorp_> zyga-uds: probably not
<awe_> victorp_, voice support @ the high-level API is the big missing piece
<victorp_> as they would have to change RIL
<holtmann> Guhttps://git.kernel.org/cgit/network/ofono/ofono.git/tree/doc/certification.txt
<awe_> if this was added to mm, we  could add rild support to mm
<holtmann> https://git.kernel.org/cgit/network/ofono/ofono.git/tree/doc/usat-certification-status.txt
<cyphermox> holtmann: thanks
<rsalveti> zyga-uds: they can replace the implementation, but the interface would be the same
<awe_> but it's fairly large piece of code that's missing
<holtmann> ConnMan comes with a built-in DHCP client.
<awe_> holtmann, hey dude... long time
<victorp_> awe_: and crucial
<ogra_> he is hiding :)
<holtmann> ConnMan has its own DHCP client and server.
<cyphermox> holtmann: yeah, we mean how hard could it be to make it use an external client again?
<awe_> holtmann, that's what we're talking about... there's some concern about the builtin dhcp client
<holtmann> It is by magnitudes faster than external clients.
<holtmann> See my presentation at LinuxCon Vancouver a few years ago.
<victorp_> awe_: not sure is in the scope of this session but will be nice to talk about SIP support
 * awe_  screams 
<lool> holtmann: would it be possible to implement this in dhclient?
<lool> holtmann: we wouldn't want to have to support 2 DHCP clients
<holtmann> ConnMan DHCP had a 80% speed increase in corporate or public networks.
<holtmann> The internal DHCP client in ConnMan also reduces the memory footprint.
<cyphermox> holtmann: due to the arp tricks?
<holtmann> As I said, the numbers where in my LinuxCon talks.
<holtmann> No ARP tricks. We never needed it.
<lool> holtmann: indeed, we did notice a big memory difference
<Wellark> QUESTION: could holtmann join the onair discussion? :)
<victorp_> lool: Is DHCP really a key discussion point here?
<ogra_> Wellark, he is talking
<Wellark> oh, right. great! :)
<ogra_> (if i'm not getting the voice wrong)
<cyphermox> ogra_: nah
<ChickenCutlass> lool: awe_ can we talk about 3g data connections and more relevant topics
<cyphermox> this is dan
<ogra_> oh
<lool> ChickenCutlass: didn't we cover that with ofono already?
<stgraber> ogra_: dcbw is talking
<lool> ChickenCutlass: and modemmanager
<ogra_> they both turned off tehir cam now :)
<awe_> ChickenCutlass, we have talked about 3g
<lool> yeah
 * ogra_ thought he heard marcel talk before
<ChickenCutlass> awe_: we did? I thought it was voice
<ChickenCutlass> ok
<lool> victorp_: DHCP speed for end-users and supporting 2 DHCP clients seemed relevant
<victorp_> I agree with ChickenCutlass  I dont see how this is so relevant
<victorp_> lool: really? over not have a phone stack?
<holtmann> Honestly our DHCP client never had issues with the full DHCP discover procedure.
<ChickenCutlass> lool: awe_  please talk about support for RILD
<victorp_> oks I will go back to read my emails ;)
<cyphermox> it's relevant when we get to convergence
<holtmann> It is just that fast.
<lool> link to the security review is in the pad
<victorp_> seems like inside baseball to moe
<lool> ChickenCutlass: yes, it's on the list
<roadmr> do you have gpg keys set up?
<roadmr> sorry
<lool> ChickenCutlass: in fact it's next on the list as we already covered dhclient w/ connman
<pitti_uds> mdeslaur: don't we already do this by default for NM as well?
<holtmann> It is the same hardware. People are sharing the hardware.
<pitti_uds> mdeslaur: i. e. defaulting to system-wide connections? (and it totally makes sense IMHO)
<holtmann> Pre-shared keys are pre-shared in the first place.
<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
<holtmann> Enterprise WiFi is per user.
<holtmann> Same as VPN.
<dcbw> holtmann: there's a use-case with shared laptops for example,  even with PSK that we've heard about
<holtmann> Same as WISPr.
<pitti_uds> yeah, by-user wifi connections are a nuisance and really just wrong
<lool> victorp_: it's a bunch of topics, not just a single one; this is converged network stack, not just phone stack
<cyphermox> +1
<dcbw> in one case, a Uni shares laptops between students and doesn't want their home wifi PSKs available to the othe ruser
<pitti_uds> 3G and vpn are certainly more per-user, yes
<dcbw> with 802.1x/wpa enterprise, you may want a machine-wide *connection*, but user-specific passwords
<holtmann> ConnMan has PolicyKit support as well. Just nobody wrote the policy files.
<dcbw> so an admin can deploy the same configuraiton on a bunch of machines, but each user has their own password
<mdeslaur> pitti_uds: yes, we default to system connections, but a lot of wifi connections need to be by user
<mdeslaur> pitti_uds: for example WPA Enterprise, where users have their own passwords, and their own certificates
<pitti_uds> so that makes sense if you have a sequential multi-user machine, not "multiple sessions in parallel"
<pitti_uds> (thinking guest session, etc.)
<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
<mdeslaur> pitti_uds: yes, not concurrent access, multiple users on the same device
<pitti_uds> ack
<mdeslaur> pitti_uds: ie: parental lock on a tablet is an example
<mdeslaur> requiring fine-grained policykit support
<victorp_> holtmann: what did you mean by "SIM Toolkit support"
<mdeslaur> holtmann: enterprise wifi is per user?
<dcbw> http://en.wikipedia.org/wiki/SIM_Application_Toolkit
<holtmann> Yes. Enterprise WIFi, VPN and WISPr is per user.
<cyphermox> mdeslaur: oh yeah
<cyphermox> much enterprise needs your user name, password, or your own certificate
<victorp_> dcbw: thanks. holtmann  seemed to imply that conman had better support for it, but wouldnt that be lower down the stack?
<mdeslaur> I mean, "enterprise wifi is per user in connman"?
<pitti_uds> mem usage> lool, do you actually mean NM (daemon) or nm-applet?
<awe_> victorp_, better support for what?
<lool> pitti_uds: all together
<victorp_> SIM Toolkit support
<ogra_> awe_, SIM toolkit
<lool> pitti_uds: but nm-applet is going away
<victorp_> awe ^
<dcbw> victorp_: STK is an ofono/MM level thing
<dcbw> MM doesn't have support for STK yet
<awe_> that's ofono
<holtmann> The Nest.com thermostat guys are running ConnMan in their device and they have very crazy memory limits.
<dcbw> ofono does
<lool> we can cover it
<cyphermox> pitti_uds: we mean more the daemon
<cyphermox> but we can certainly improve on the applet
<victorp_> dcbw: I guess that was my point, thanks for confirming
<holtmann> SIM Toolkit is a lot of work btw. I took as 12 month with 6 people to implement it inside oFono.
<holtmann> s/as/us/
<holtmann> ConnMan can do both, dynamic and builtin plugins.
<mdeslaur> holtmann: could you confirm that ConnMan supports enterprise wifi and vpn _per user_?
<holtmann> So ConnMan includes DHCP client + server, DNS resolver, DNS proxy, DNS server, WISPr HTTP client.
<holtmann> Including all the Tethering handling.
<cyphermox> aye
<holtmann> So need for external programs like dhclient, dnsmasq, iptables callouts etc.
<holtmann> ConnMan has an agent concept. So VPN, WiFi and WISPr credentials are ask to the user.
<holtmann> Similar to BlueZ.
<mdeslaur> holtmann: ask the user, but then they're stored centrally, no?
<dcbw> as does NM
<holtmann> No. The user can decide where to store them.
<cyphermox> awe_: +1
<holtmann> Actually SIM Toolkit is high level only. The modem plugin only needs to have a transport.
<holtmann> The SIM Toolkit parsing and message parsing is done inside the oFono core.
<awe_> holtmann, thanks for the correction...
<holtmann> The modem plugin/driver has to send the raw PDU. Same as with SMS.
<holtmann> Only PDU transport needs to implemented.
<awe_> I've been meaning to ping you, since we recently open-sourced everything
<holtmann> Hah. Nice. Have a link?
<awe_> thanks for the clarification
<awe_> to the code?
<ogra_> voting !
<awe_> yea, hold on a sec
<ogra_> :)
<asb_asb_asb> come on connman
<holtmann> Yes, link to the code.
<rsalveti> and not using ofono would mean also rewriting the layers the telephony-app depends
<holtmann> SIM Toolkit parsing and message building is 6 people for 12 month that you need to redo.
<awe_> holtmann, https://code.launchpad.net/ubuntu-touch-preview
<dcbw> well, the code got sucked into MM and the transport was implemented natively I suppose :)
<awe_> https://code.launchpad.net/~phablet-team/phablet-extras/ofono
<cyphermox> that said, I'm starting to take over more and more the maintainership of connman on Debian and Ubuntu
<dcbw> well, *unless* :)
<cyphermox> so I want to make it a first class citizen on Ubuntu for those who want to use it
<ogra_> scared by sexiness ...
<awe_> holtmann, fyi... the RIL code was added directly to the bzr tree
<cyphermox> asb_asb_asb: ^^
<dcbw> well, somebody needs to define "sexy" in this context :)
<awe_> we have plans to split out the plugin code, and submit the gril layer as a patch
<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
<rsalveti> we will still clean it up and prepare for upstreaming
<cyphermox> jdstrand: yes
<jdstrand> lool: that's just otoh
<awe_> ( gril is the equivalent of gatchat, gisi layers )
<awe_> ( and based on them )
<holtmann> Hah.
<cyphermox> we've been thinking about that; seeing how we can split that code out and whether we could use it with NM
<jdstrand> cool
<awe_> holtmann, fyi... I recently tried to sign up for the ofono mailing list...and got no auto-response
<holtmann> With QMI support we never bothered and when for drivers/qmimodem/qmi.[ch] directly.
<holtmann> gatchat is a bit different since the AT modem is a different beast.
<holtmann> Send the patches to the mailing list for review if you get a chance.
<cyphermox> jdstrand: perhaps I'll circle back to you, and talk to holtmann more about how we could ship those separately, if possible
<rsalveti> we'll be working on that now that mwc is done :-)
<cyphermox> I'm sure we'd at least be happy with getting a more "transparent" upstream for a dhcp client
<awe_> holtmann, sure... there's some cleanup needed, and I'm sure y
<asb_asb_asb> could someone tell me more about chewie?
<awe_> y'all will have plenty of review comments for us
<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
<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?
<holtmann> There has been talks about it.
<cyphermox> cool
<gema_> lool: i am impressed on how quickly you can talk!
<holtmann> The only reason why it has not yet been done, because it tightly integrated. Since we also do the DHCP server side.
<lool> gema_: probably too fast for people to understand me with french accent
<ogra_> gema_, i'm impressed how quickly you can understand :)
<cyphermox> holtmann: ok
<cyphermox> well, to split it up I'd split up server as well somehow
<gema_> ogra_: who says I am understanding him? :P
<ogra_> lol
<gema_> just kidding
<ogra_> hahaha
<rsalveti> lool is unstoppable, a machine
<cyphermox> indeed
<sarnold> thanks
<awe_> ;D
* 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
<rsalveti> dcbw: thanks for finding time to participate
<dcbw> np
<thomi> who's got the hangout link?
<thomi> oh, nvm
<gema_> jason, I guess
<gema_> areyou guys streaming already?
<cjohnston> no
<tsdgeos_uds> is this broadcasting?
<cjohnston> not yet
<cjohnston> thomi: who created the hangout
<mmrazik> btw. if somebody wants to join the hangout ping me
<jasoncwarner_UDS> hi folks...we should be live now
<jasoncwarner_UDS> gema_: streaming now, yes
<tsdgeos_uds> yep
<cjohnston> it is
<gema_> yep
<gema_> I see the guitars
<elopio> hello.
<MacSlow> hey vrruiz
<vrruiz> Hi MacSlow
<cgoldberg> o/
<tedg> thomi, How long do we expect Surface Flinger to exist?
<tedg> thomi, It seems like it's kinda temporary, so not worth spending too much time on.
<mmrazik> tedg: if I understand correctly we don't know ATM
<mmrazik> tedg: I believe thats what was just discussed -- just keep surfaceflinger stuff we have ATM and replace that eventually
<tedg> mmrazik, I though there was A Plan (tm)
<tedg> tvoss, ^
<tedg> Or perhaps kgunn ^
<kgunn> tedg: its part of the mir plan
<kgunn> imo
<kgunn> does that make sense?
<tedg> kgunn, No :-)
<kgunn> good
<kgunn>  :)
<tedg> kgunn, Is it worth supporting SurfaceFlinger in the test frameworks?
<tedg> kgunn, Or should they just start jumping to Mir.
<kgunn> tedg: if by "support surffling"
<kgunn> you mean an integration test where surffling is in the stack
<tedg> Have a backend for Auto Pilot for it
<kgunn> the test shouldnt know
<kgunn> if you mean to actually test surffling ...no
<kgunn> waste of time
<tedg> Yeah, it should be testing Unity on SF
<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?
<mmrazik> MacSlow: what is notifyOSD NG? a QML/Qt version of notifyOSD
<kgunn> tedg: our honest target is to have unity on mir may-ish
<kgunn> and mir should be "off" surffling on the phone platform by then as well
<MacSlow> mmrazik, sorry... my bad... NotifyOSD NG (Next Generation)... it's the Qt/QML rewrite of NotifyOSD in a multi-form-factor world
<tedg> kgunn, Cool, that makes sense.
<tedg> mmrazik, thomi, ^ Unity on Mir May-ish
<MacSlow> mmrazik, yes...
<tedg> Then Surface Flinger can go back to Android :-)
<MacSlow> thomi, mmrazik: I remember you suggested expose some state via DBus?
<balloons> are the best practices recorded somewhere in the docs? If not, let's put them in there for app authors
<balloons> small and sweet of course :-) but it's an honest question
<tsdgeos_uds> mzanetti: i was wondering the other day while adding objectNames, that it makes the software use more memory "for nothing"
<cjohnston> no wiki!
<tsdgeos_uds> mzanetti: should we care about that extra few bytes of memory used?
<MacSlow> mmrazik, thomi: so just the unique object-names mzanetti mentioned... ok
<gema_> not on mobiles xD
<mmrazik> MacSlow: there is an workitem to document any best practices in the autopilot doc
<cgoldberg> +1 for testability over mem optimization :)
<MacSlow> mmrazik, thanks
<tedg> Is there a way we could "build" the program and remove those?
<vila> tedg: +1 was about to ask
<mzanetti> MacSlow: feel free to ping me anytime for more detailed discussions about notifyOSD
<roadmr> sort of like "stripping" the object names when publishing a production build
<tedg> No reason to waste on systems that won't be doing testing.
<gema_> tedg: we should start thinking of dev versions vs released versions
<MacSlow> mzanetti, I will... thanks
<mzanetti> MacSlow: right now I don't know the architecture of notifyOSD
<cgoldberg> then are those builds not testable once stripped?
<mzanetti> MacSlow: so not too much I can say yet
<roadmr> otherwise decision on which objects you're never going to test and need no names will eat useful brain cycles I think :/
<MacSlow> mzanetti, I'll toss you an email
<tedg> cgoldberg, Not as testable, yes.
<mzanetti> MacSlow: ok
<balloons> thomi, haha.. message received
<gema_> mmrazik: +1
<cjohnston> balloons: you could try to get the autopilot test writers to help contribute to docs since they are already familiar with autopilot
<roadmr> you want to keep memory consumption under control, so it has to be measured first, that'd rock
<balloons> I owe thomi my tutorials to the docs
<balloons> and of course, the further work should hit the docs too
<cgoldberg> bet it's neglible
<vila> you can put a lot of names into the space taken by a bitmap...
<elopio> thomi: runner capabilities, like selenium?
<vila> thomi: has been solved elsewhere
<thomi> elopio: vila: I know
<vila> thomi: keyworsd include fixtures, required features, feature flags
<vila> thomi: +1 on testresources ;)
<gema_> more tests!
<balloons> those who have used the tool.. time to speak up :-)
<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.
<balloons> or talk about why you haven't.. (tho you should, it rocks)
<elopio> so, webdriver integration? Probably needed for webapps testing too.
<thomi> selenium backend - someone should write one!
<thomi> ;)
<vila> sleeps are bad
<alesage> selenium yayz!
<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
<balloons> elopio, so really your saying your testing your backend desktop tool AND your browser extensions code at the same time
<tsdgeos_uds_> yeah and the recursive search!
<balloons> so testing multiple things at the same time doesn't work so well?
<balloons> +1 for search!!
<elopio> balloons: that's the current user flow.
<elopio> balloons: open the music lens, click a song, the browser will be opened. Buy the song, and get it on your desktop.
<elopio> it's ugly and temporary, but that's what we have.
<balloons> elopio, I would say simply, don't feel the need to test things you don't have to test persay
<cjohnston> update the docs etc to say its being depricated
<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 :-)
<vila> as in being able to subscribe to a signal ?
<vila> mzanetti: as in being able to subscribe to a signal ?
<tsdgeos_uds_> mzanetti: yeah if you need to watch for signals let's use qmltestrunner
<cjohnston> I can't spell deprecated
<mzanetti> vila: yes
<gema_> x)
<vila> mzanetti: Please keep it !
<mzanetti> vila: whats the reason?
<vila> mzanetti: that's the alternative to putting sleeps all over the place
<elopio> balloons: we are trying hard to avoid it :)
<mzanetti> vila: no, it isn't
<mzanetti> vila: use assertThat(object.state, Eventually(Equals(someValue)))
<mmrazik> that needs to go to the best practices
<balloons> ^^
<vila> yeah, polling is implemented with sleeps...
<mmrazik> :)
<vila> that's still worse than being awaken when a specific event happen
<mzanetti> hehe... actually true...
<alesage> for the record http://unity.ubuntu.com/autopilot/tutorial/good_tests.html
<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.
<elopio> s/three/tree
<alesage> elopio or like selenium IDE, e.g. :)
<vila> mzanetti: in a nutshell, IMHO, using sleep or Eventually is the same, it's brittle
<vila> indeed :)
<mmrazik> elopio: would you mind creating a but against autopilot in launchpad?
<balloons> elopio, vice versa would be even more fun eh.. hover or click part of the app, and get the tree :-)
<mmrazik> in general -- everybody feel free to add bugs to the project even though they are features
<elopio> alesage: or both. I like this sessions of requesting cool things I have no idea how to implement :)
<elopio> mmrazik: will do.
<vila> thomi: so my hope was that signals was a way to get a direct sync from the app
<vila> better matching between the test expectations and the ap behavior
<vila> better matching between the test expectations and the app behavior
<cjohnston> the end of uds!
<roadmr> nooo :(
<gema_> is there a closing plenary?
<vila> the beginning of beer ?
<mmrazik> gema_: don't think so
<gema_> ok
<elopio> vila: yay. I'm in. It's only 2 pm here.
<vila> elopio: :-D
<tsdgeos_uds_> thomi: mzanetti: yeah, unfortunate, just write it down somewhere
<elopio> I just want to say thank you.
<elopio> it's been a long way for us, first ldtp, mago, xpresser, sikuli.
<elopio> now it's finally working with autopilot.
<gema_> we know where you are (evil laugh)
<gema_> thanks!
<cgoldberg> thanks!
 * tsdgeos_uds_ waves
 * thomi waves
<balloons> thanks everyone
<gema_> so... karaoke
<nuclearbob> yep, I'll get it started shortly
<vila> thanks to all
<jfunk_> +1 on the thanks
<nuclearbob> https://plus.google.com/hangouts/_/0642ce7b16924e43f9afedf1b84235badd690f22?authuser=0&hl=en
* 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
