#ubuntu-uds-client-1 2013-03-05
* udsbotu changed the topic of #ubuntu-uds-client-1 to: Track: Client | Refactor and clean up platform api | Url: http://summit.ubuntu.com/uds-1303/meeting/21608/client-1303-refactor-p
<rsalveti> is etherpad crashing for others as well? cannot even use it here
<rsalveti> keeps reloading itself from time to time
<rsalveti> seb128: are you the one responsible for sending the invites?
<lool> in theory you would see a link on the meeting's page
<lool> http://summit.ubuntu.com/uds-1303/meeting/21608/client-1303-refactor-platform-api/
<lool> video stream is up
<cjohnston> if you are required, and there is a video appearing on the meeting page, refresh and you will see the link to join
<seb128> rsalveti, the system does to the people marked as required on the blueprint
<lool> rsalveti, seb128: some static
<cjohnston> Not required on the blueprint. Required in Summit... participation essential != required
<doanac_> rsalveti: we meet again.
<lool> rsalveti: yes
<lool> rsalveti: you're coming through fine
<rsalveti> seb128: cool, just saw it
<Saviq|UDS> rsalveti: yes
<lool> there's some background static though
<lool> better now
<lool> just hearing typing noises  :-)
<Saviq|UDS> ChickenCutlass, rsalveti, seb128, tvoss use "Lower Third" from hangout tools
<lool> rsalveti: remove hl=fr from URL
<Saviq|UDS> to show names and IRC nicks
<rickspencer3> hi gents
<mfisch> misspelled disaster
<thomi> I love the flags :)
 * Trevinho|uds agrees
<lool> kids  :-)
<awe_> +1 on  the flags as well.  Kinda like the Olympics
<awe_> tvoss, you're mic is kinda low...
<awe_> tvoss, yes
<seb128> awe_, want to join us?
<awe_> seb128, sure
<awe_> seb128, although I don't have a lot to contribute...
<seb128> awe_, your call
<seb128> I msged you the url
<awe_> k
<Saviq|UDS> ChickenCutlass: and TV!
<kgunn> ChanServ: so would that be like omx level?
<kgunn> ChickenCutlass: so would that be like omx level?
<dbarth> so ChickenCutlass, you plan on keeping that API definition and binding that to the parts of Gnome or else we have on the desktop?
<ChickenCutlass> Saviq|UDS: right
<dbarth> asking you, as i don't see tvoss logged in here
<lool> I'll ping him to join when he's done introducing
<achiang> ChickenCutlass: fyi, there is ~8 second delay between the hangout and the youtube stream. not sure if that has already been mentioned
<achiang> lool: ^^
<dbarth> if that's in scope?
<seb128> dbarth, want to join the hangout?
<dbarth> yeah
<dbarth> let me eplain ;)
<dbarth> i was wondering if you want to keep the same API for apps, but bind that to what runs on a more traditional x86 PC (as opposed to a mobile device)
<thomi> Having the platform API avaialable on the desktop will certainly help us with autopilot...
<dbarth> same API, ie the Ubuntu Touch API you defined
<awe_> how close does the API adhere to Android's HAL, and do we plan on re-factoring this to be less Android specific?
<dbarth> but the runtime is either hosted on android, and then gradually is migrated to our middleware, and how much of the gnome heritage (no offense here) we have on the desktop
<rsalveti> awe_: guess it depends on the api scope we want to cover with it
<Saviq|UDS> rsalveti: in the location example, would geoclue live below Ubuntu Platform API, on top of it, or completely in parallel?
<rsalveti> Saviq|UDS: in this example I'd expect geoclue to be below ubuntu platform api
<rsalveti> as the platform api would be the entry point
<ChickenCutlass> Saviq|UDS: rsalveti  yes below
<Saviq|UDS> cool
<lool> rsalveti: exactly the point I was making for geoclue with tvoss last Friday; thanks for bringing it up  :-)
<lool> I feel MIR might be another case of this
<rsalveti> lool: yeah
<kgunn> ChickenCutlass: so the api's are convenience, but for example a client app could stil use geoclue directly?
<Saviq|UDS> tvoss: could (again, in the location example), geoclue be simply part of the Ubuntu Platform API?
<ChickenCutlass> kgunn: sure nothing stopping a developer from using it directly
<kgunn> Saviq|UDS: i agree with you, no need to wrap an api if it exists on the platforms we care about
<kgunn> Saviq|UDS: same as what tvoss just said about opengles & openmax
<Saviq|UDS> tvoss: I'm afraid of adding another glue layer that would only mean that your app will only run on Ubuntu
<Saviq|UDS> at least where there are well-defined alternatives
<seb128> server error, sorry
<mfisch> hangout crash for anyone else?
<nuclearbob> yep
<Trevinho|uds> back
<nuclearbob> me too
<rsalveti> yeah, if the host goes down, it stops the transmission
<dbarth> tvoss: to clarify, by platform API, do you mean: the adaptation layer for Ubuntu Touch in 3 months, or the set of APIs that Ubuntu 14.04 will provide to applications in 1 year?
<tvoss> dbarth, both
<dbarth> a diagram may help also represent what the discussion is about, and what it is /not/ about
<dbarth> ok, ChickenCutlass, yes that clarifies, so 14.04 APIs for apps, right?
 * lool keeps an eye on the clock
<TheMuso> So... If the platform API wrapped Mir, we wouldn't be writing a backend for Gtk to work with Mir, we would be writing a backend for Gtk to work with the platform API?
<TheMuso> As an example...
<dbarth> so there should be 2 parts in the API:
<Saviq|UDS> there's no question, we need that
<dbarth> access to supported services
<dbarth> and helpers to adapt to form factors
<dbarth> ok
<udsbotu> uds-client-1: 5 minutes left in this session!
<dbarth> would that help to surface that as WIP on http://developer.ubuntu.com/resources/platform/api/ ?
<udsbotu> uds-client-1: 4 minutes left in this session!
<udsbotu> uds-client-1: 3 minutes left in this session!
<udsbotu> uds-client-1: 2 minutes left in this session!
<TheMuso> Agreed re mailing list.
<alex_abreu> +1 for new mailing list
<pitti_uds> we could at least start with u-devel@, to raise some attention to this
<Saviq|UDS> +1
<udsbotu> uds-client-1: This session has ended.
* udsbotu changed the topic of #ubuntu-uds-client-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1303/client-1/ - http://ubottu.com/uds-logs/%23ubuntu-uds-client-1.log
<thomi>  \o/
<Saviq|UDS> o/
<dbarth> well done; interesting
* udsbotu changed the topic of #ubuntu-uds-client-1 to: Track: Client | Porting Ubuntu Touch preview to raring | Url: http://summit.ubuntu.com/uds-1303/meeting/21606/client-1303-ubuntu-tou
<lool> rsalveti: I'm participation essential in both the hw accelerated video decode / rendering and in the porting touch images to raring sessions (I might have marked myself essential there); would you want me to jump between the two, or would you feel I'm more important in one or the other?
<Mirv> rsalveti: are you in talks with stskeeps already btw regarding libhybris?
<rsalveti> Mirv: yes
<Mirv> rsalveti: ok, great
<rsalveti> lool: I can cover the porting touch images, feel free to start at the hw accelerated video decode session
<lool> rsalveti: there's a lead for the hw acceleration session though?  I am not prepared to *lead* it  :-)
<cyphermox> xnox: no point worrying about how ofono is handled, me and stgraber are following the package pretty closely in Ubuntu and Debian
<cyphermox> unless of course you think that's reason for concern ;D
<rsalveti> lool: there is, jhodapp is leading it
<lool> cool
<rsalveti> well, we got a bunch of new code for ofono
<rsalveti> we need to coordinate the upstream work here
<cyphermox> rsalveti: yeah, but still
<rsalveti> + distro
<cyphermox> yes
<cyphermox> we can do this for you I guess
<cyphermox> or you may want to just push your patches directly upstream
<rsalveti> hm, no hangout link still
<cyphermox> assuming you wrote them you'd be credited either way
<rsalveti> yeah, we need to first try to push it upstream, but we also want/need it available at the distro
<tvoss> rsalveti, want me in the hw decode session?
<rsalveti> lets talk at the session
<rsalveti> tvoss: yes, please
<tvoss> rsalveti, any link, yet?
<rsalveti> seb128: do you have the link for this session already?
<cyphermox> rsalveti: that's all fine, what I mean is not a huge need to discuss. if the patches aren't pure crack nobody will object to carrying them as distro patch and/ upstreaming
<tsdgeos> is video up?
<mterry_> seb128, Hmm, where is the link to participate?
<tsdgeos> can't see it yet
<lool> tvoss.clone().join_track("#client-1").clone().join_track("#client-2").clone().join_track("#appdev-1").clone().join_track("#appdev-2")
<cyphermox> tsdgeos: doesn't seem to be
<tvoss> lool, ?
<cyphermox> hehehe
<xnox> cyphermox: are you going to be in the session? =)
<xnox> cyphermox: i was just worried that stgraber is double booked ;-)
<cyphermox> xnox: wasn't especially feeling the need to be
<lool> tvoss: I want 4 clones of you to have one of you in each session in each track  :-)
<xnox> cyphermox: ok. good.
<tvoss> lool, ;)
<cyphermox> then sure, I can jump in, just need the link
<tvoss> lool, I feel abused now, or better my chromosomes
<lool> you should feel proud!
<cyphermox> but I'm happy to leave my place, my contribution is unlikely to be very important
<tsdgeos> we has videos
<cyphermox> hmm I see a Didier
<robru> didrocks, such a fancy name badge you had there!
<kenvandine> didrocks, can you invite me to the hangout?
<didrocks> robru: isn't it? :)
<seb128> who needs the hangout link?
<seb128> (should be in the summit?)
<mterry_> looks like you have enough, I'll just lurk
<ogra_> same here
<cyphermox> +1
<cyphermox> I think I'm subscribed to the list already
<seb128> cyphermox, seems like you could have input for the ofono packaging stuff?
<cyphermox> trying to join
<ogra_> how about rolling back to the good old hotplug scripts for that
<ogra_> (if its only one device)
<ogra_> (instead of udev)
<didrocks> kenvandine: aren't you WI more for our session? the one at 6:15PM?
<kenvandine> oh.. maybe so :)
<boiko> seb128: I think it is actually "rild" instead of "reald"
<boiko> rsalveti: right? ^
<didrocks> kenvandine: feel free to move those there :)
<seb128> boiko, thanks
<cyphermox> my lower third is reversed, right?
<kenvandine> mirror image
<mterry_> cyphermox, that's normal
<cyphermox> oh ok
<didrocks> the hangout API is doing that, your image you are seeing on the low part is reversed
<ogra_> as long as it doesnt add pimples ... who cares :)
<didrocks> ogra_: it's for pointing people in fact
<didrocks> so that when you point to the right
<didrocks> your hand is at the right
<mterry_> didrocks, that's adorable
<ogra_> ah, nice
* udsbotu changed the topic of #ubuntu-uds-client-1 to: Track: Client | Porting Ubuntu Touch preview to raring | Url: http://summit.ubuntu.com/uds-1303/meeting/21606/client-1303-ubuntu-touch-porting/
<cyphermox> seb128: I took a note of the p2p0 patch before the session, was already aware of that one
<seb128> cyphermox, I saw, thanks
<cyphermox> thanks for taking notes!
<seb128> np ;-)
<robru> who is running the vacuum cleaner? seriously guys?
* udsbotu changed the topic of #ubuntu-uds-client-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1303/client-1/ - http://ubottu.com/uds-logs/%23ubuntu-uds-client-1.log
<gema_uds> is the video working?
<gema_uds> oh, still 15 mins to go
* udsbotu changed the topic of #ubuntu-uds-client-1 to: Track: Client | Delivering touch apps to raring | Url: http://summit.ubuntu.com/uds-1303/meeting/21609/client-1303-delivering-touch-apps-to-raring/
<balloons> we see your smile didrocks
 * ogra_ will be a tad late, sorry 
<tedg> "You can remove it" /me didn't realize we could remove France, looking into it.
<balloons> tedg, lol
<Laney> I don't hear any noise coming from ken
<pitti_uds> same here, kenvandine sounds fine
<gema_uds> sounds good to me too
<greyback> didrocks: want an SDK person there?
<didrocks> greyback: I just ping zoltan
<didrocks> greyback: do you know if he's around?
<didrocks> greyback: otherwise, feel free to come :)
<greyback> didrocks: ok. He was an hour ago
<mterry> Sorry everyone for my goofy face icon.  Something is wrong with my webcam and google
<kenvandine> tedg, i'm already assigning work items to you :)
<pitti_uds> j'aime comme didrocks dit "Robert"
<cyphermox> hrm.. oops
<gema_uds> you can get someone else
<gema_uds> I think you can have 15
<cyphermox> my video is breaking up right?
<balloons> u actually get 15 now didrocks
<BigWhale> Greetings all
<Laney> cyphermox: tes
<Laney> yes
<cyphermox> grr
<cyphermox> I'll reconnect
<ricmm> https://docs.google.com/spreadsheet/ccc?key=0AtlKERhVPP5ydFlPa0lpbWpKQ2tiX045S055WHp0S2c&usp=sharing#gid=0
<cyphermox> angry fruit salad :)
<ogra_> hmm, i dont seem to be able to join the hangout (i dont have a join link) can anyone PM it to me ?
<cyphermox> didrocks:  ogra_: I can give you my place?
<cjohnston> ogra_: you arent required
<gema_uds> he should be able to join
<ogra_> cyphermox, we should be capÃ¼able of having 15 ppl in
<cyphermox> ok
<ogra_> i just dont get the link above the window
<gema_uds> cjohnston: when you say those things it sounds confusing, he is definitely required
<cjohnston> gema_uds: According to summit he is not required.
<ogra_> would be nice is someone could PM it to me
<gema_uds> cjohnston: ack
<cyphermox> ogra_: just a second
<ogra_> i am definitely marked essential
<ogra_> didrocks, and i checked in advance
<gema_uds> ogra_: essential is not required
<cjohnston> ogra_: essential in launchpad means nothing
<ogra_> oh
<gema_uds> the track leads can mark you required
<ogra_> heh
<balloons> lol..
<gema_uds> cjohnston: I told you this would be confusing x)
<gema_uds> cjohnston: we need a how to !
<cjohnston> gema_uds: its been blogged and emailed
<slangasek> so what are the goals here for running on the desktop?
<slangasek> do we actually care about running x86 builds of apps on the desktop?  or is what we care about really to be able to run arm builds of apps under emulation?
<ogra_> slangasek, x86
<ogra_> making the apps work across the board
<slangasek> ogra_: why is that what we care about (right now)?
<robru> slangasek, isn't that the whole point of our convergence story? phone apps should run on the desktop as full-fledged desktop apps.
<ogra_> well, its getting the new desktop in :)
<slangasek> robru: this session isn't about convergence though, it's about getting the software from the Ubuntu Touch preview into raring
<seb128> didrocks, ^
<robru> slangasek, I must be confused then. What does "into raring" mean if not "running on the desktop"?
<seb128> didrocks, might be worth adressing in the session
<ogra_> robru, packaged
<slangasek> *convergence* implies having one set of interfaces across all devices... but that's clearly not what is being proposed here
<pitti_uds> robru: into the Ubuntu archive, so that we can build images with our standard tools, and maintain them properly as packages, I take it?
<slangasek> robru: packaged, in the Ubuntu archive for raring, with raring as the focal point for development iteration and with us able to build images from it
 * thomi is working on it
<slangasek> so we can build official Ubuntu armhf touch images
<pitti_uds> and also cover them on library transitions, security updates, britney, autopkgtest, and the like
<slangasek> but if we start worrying now about android services... I don't think we're going to get anywhere in the next 2 months
<mmrazik> didrocks: but wouldn't it be actually better to test stuff like phone-app on a real phone?
<slangasek> feel free to pull me into the hangout if you want :)
<matzipan_> slangasek: from what I understand it is one single code base compiled to be running on both architectures and capable of taking the shape of all the form factors/
<mmrazik> I'm not sure how many people will be using phone-app on desktop (seems to be at least a less likely option)
<gema_uds> invite him
<gema_uds> he can join
<gema_uds> no limit of 10
<mzanetti> mmrazik: UfA
<gema_uds> 15
<mmrazik> mzanetti: I see
<matzipan_> mmrazik: it would be interesting to see something like that
<mmrazik> mzanetti, didrocks: but still... I assume the number of users using phone app on a phone is going to be higher
<mzanetti> mmrazik: yes
<mmrazik> it would be IMHO better to run this daily testing on a phone
<mzanetti> mmrazik: I always wanted the real hardware. But you are aware of the issues we still have with that
<mmrazik> even though its going to be more difficult
<mmrazik> mzanetti: ack... talking about ideal world
<Wellark> well, at least we need the SDK and other libraries in the shape that the apps can be developed and tested on the desktop
<matzipan_> Wellark: would they be running in an arm emulator? or will they be compiled for your pc ?
<mmrazik> matzipan_: right now we have been running the tests on a real desktop with X
<ogra_> there is another session for emulators etc next hour
<mmrazik> as tedg mentioned they are just qt apps and qt has the right backends..
<ogra_> "ubuntu sdk tools"
<Wellark> matzipan_: IMO there should be no reason to run ARM emulation when developing 3rd party applications
<matzipan_> i am guessing "touch apps" does not include touch screen laptops?
<ogra_> it will
<ogra_> in 14.04
<matzipan_> oh, at the point of the "grand unification" ? :D
<ogra_> currently we are defining the road towards that
<slangasek> matzipan_: well, touch-screen laptops aren't the focus of any work over the next months
<slangasek> the focus is all on smaller touch screens
<Wellark> tedg: we need the new hud to get libhud so that we can land the integration between SDK and libhud-qml
<tedg> Wellark, Yup, but even if the hud-service was in a different package they'd be okay.
<ogra_> its a simple naming transition, no ?
<Wellark> well, as long we figure out the build dependencies so that libhud can be installed
<Wellark> how about the the broken unity packages in phablet ppa? those are for quantal, but is there something that has to be addressed on the raring side? or do the raring unity packages contain the changes already?
<tedg> We need some sort of authentication on these country flags.
<pitti_uds> tedg: says the man who doesn't use a country flag :)
<ogra_> haha
<tedg> pitti_uds, I did.  You supporter of the illegal occupation of Texas!
<ogra_> how the heck do i get that in the first place ?
<pitti_uds> (yeah, I know that there are many Texan people who'd disagree)
 * ogra_ doesnt even have a shiny name tag
<pitti_uds> ogra_: hangout tools, "lower third", enable your name and set your country
<robru> didrocks, don't forget to assign some easy stuff for me ;-)
<slangasek> tedg: as I'm eligible to apply for Czech citizenship provided I can fill out the form successfully, I feel entitled
 * tedg doesn't want to be in kenvandine's "stack of friends"
<tedg> slangasek, Hah!
<kenvandine> tedg, you are!
<mmrazik> didrocks: there should be some tests for the demo app with all the components
<mmrazik> didrocks: should be good for release testing
<cjwatson> "eligible to apply for citizenship" - is there pre-authentication before you can get the forms? :)
<ogra_> heh
<mmrazik> didrocks: if not there should not be much work to make them good for release testing
<mzanetti> mmrazik: good point actually... maybe we should autopilot the demo app
<mmrazik> mzanetti: we are autopiloting it
<mmrazik> mzanetti: or at least it was the plan
<mmrazik> not 100% sure where exactly it is
<mzanetti> oh.. haven't seen that so far. but great if there is something
<slangasek> cjwatson: heh, no
<mmrazik> mzanetti: jp was certainly working on it at some point of time
<vrruiz_> willcooke is not here, but I am :)
<thomi> does kenvandine sound like a Dalek to anyone else?
<mzanetti> thomi: yes...
<tedg> thomi, A Dalek that runs on beer!
<slangasek> thomi: that has always been my impression
<thomi> ok, as long as it's not just me
<ogra_> even without flicking a finger over his lips !
<thomi> hah
<slangasek> ah no, kenvandine isn't a dalek, he's apparently Rush Limbaugh
<kenvandine> hehe
 * mterry investigates his camera
<robru> video cut out abruptly, was that actually the end?
<Laney> yeah
<tvoss> can someone ping me the hangout link?
<didrocks> robru: we told "thanks everyone" :)
<robru> didrocks, I think that part got cut off ;-)
<robru> didrocks, or maybe I was momentarily deaf ;-)
<didrocks> robru: that was just after "we'll assign everything to robru"
<didrocks> :p
<chicken_terrine> helo as talking video started??
* udsbotu changed the topic of #ubuntu-uds-client-1 to: Track: Client | Mir on the converged codebase | Url: http://summit.ubuntu.com/uds-1303/meeting/21680/client-1303-mir-converged/
<tvoss> didrocks, ping
<didrocks> hey tvoss
<tvoss> is the video running? google tells me they will be right back
<ptl> I understand that going too deep on this will not be productive, but will there be any mention of the discussion between the wayland developers and Canonical, where they said wayland does not suffer from any of the downsides quoted on the Mir page?
<ptl> I am talking of course about the article "Don't piss on Wayland", http://www.phoronix.com/scan.php?page=news_item&px=MTMxODA
<chicken_terrine> phoronix? trololol
<tsdgeos> where's the video?
<didrocks> tvoss: which session? the previous one just finished 5 minutes ago
<olafura> tsdgeos it's running on Mir :)
<tsdgeos> ah, starts in 2 min
<chicken_terrine> #burn
<kdub_> is there supposed to be a hangout somewhere?
<tsdgeos> didrocks: the mir one
<didrocks> yeah, not yet I guess :)
<alan_g> is there sound and/or video
<cjohnston> seb128: who is supposed to be starting this one?
<alf_> robert_ancell: I think we are still off air
<TheMuso> I guess nobody joined yet.
<robert_ancell> alf_, really?
<mmrazik> robert_ancell, alf_: yes
<Saviq|UDS> anyone have anything other than a "We'll be right back" video recorded?
<cjohnston> nope
<mmrazik> Saviq|UDS: no
<thomi> yes
<mmrazik> well... I have "This video is currently unavailable."
<thomi> I just refreshed, now I get a blank screen
<thomi> ...doh, and now the we'll be right back screen
<cjohnston> it looks like the wrong url was started
<Trevinho|UDS> thomi: well, yes you get the "registration" of the session
<ptl> and I have a 'An error occured. Please try again later."... will refresh
<balloons> same.. nothing..
<fisch246> you don't need to refresh
<fisch246> just click on "live"
<balloons> now it's a 5 min video, not livestream
<fisch246> if it's gray you're not live
<Saviq|UDS> fisch246: there is no "live" button
<fisch246> on the youtube player
<Saviq|UDS> fisch246: we basically get the usual YT player
<balloons> http://www.youtube.com/watch?feature=player_embedded&v=oQGyoQAVN6E
<seb128> http://youtu.be/w6HnJ3mgT9g
<fisch246> i have yet to get a basic yt player
<Saviq|UDS> balloons: yup, just a 5:31 video of "We'll be right back"
<mmrazik> seb128: that seems to work. thanks
<Wellark> the link from seb128 works
<thomi> seb128: cool, that link works for me
<fisch246> though i opted for html5 so the html5 player might have the option
<mmrazik> thomi: you are
<cjohnston> thomi: where is there a link from seb128
<mmrazik> tvoss: you are..
<seb128> http://youtu.be/w6HnJ3mgT9g
<netcurli> yes
<mmrazik> sorry thomi
<seb128> https://plus.google.com/hangouts/_/ff2785ffa15ca0508f8616284456489ebcb68966fb?authuser=0&hl=fr
<rickspencer3> I can see you guys on the new link
<robert_ancell> my intel X driver keeps crashing...
<Saviq> seb128, can you replace the summit's youtube link with the correct one?
<mmrazik> it will be probably just hard to find the recorded session
<cjohnston> ok, all
<cjohnston> I just updated the url in summit
<thomi> some home improvment?
<cjohnston> refrehs and the video should work
<cjohnston> refresh
<seb128> Saviq, done
<balloons> working now
<Saviq> seb128, yay!
<tsdgeos> refresh worked
<thomi> yup
<sbeattie> yes, workig
<sil-unwell> I have refreshed the page on summit, and I now see the hangout fine, yay!
<zyga-uds2> alf_: hey :)
<sil-unwell> (speakers: it might be quite cool to add Lower Third so your names are up, as it is for Thomas Voss)
<alf_> zyga-uds2: hi :)
<Wellark> sil-unwell: for some reason I could not get the toolbox working before, others might have the same problem
<robert_ancell> any questions on irc?
<tsdgeos> is someone at the dentist?
<kyleN> at the dentest
<cjohnston> please mute whoever that is
<rickspencer3> did someone join from a dentist office?
<thiagoandrade> How can i help the development of mir?
<zyga-uds2> QUESTION: what's the current state of mir and what's the roadmap for the next 3 months?
<sil-unwell> OK, well, obvious question: I've seen lots of people saying that our reasons for not using Wayland, as laid out on the wiki page, are something in between incompletely explained and actively maliciously wrong. Can you guys enlarge on the reasons?
<cjohnston> seb128: please mute whoever has all of that extra noise
<robert_ancell> cjohnston, it was me and I'm muted now
<seb128> cjohnston, I think that was robert
<cjohnston> ty robert_ancell
<seb128> who is leading...
<gema_uds> cjohnston: can you paste the link to the feed again?
<cjohnston> gema_uds: refresh and it should be there
<zyga-uds2> are you taking questions or running a planned discussion?
<Wellark> is the feed really this lagged.. :/
<dednick> http://www.youtube.com/watch?feature=player_embedded&v=w6HnJ3mgT9g#!
<gema_uds> found it!
<seb128> robert_ancell,hello?
<jdstrand> is there an agenda?
<cjohnston> maybe someone else can step up and take the lead?
<seb128> jdstrand, no, open questions I think
<jdstrand> ah
<robert_ancell> jdstrand, correct
<robert_ancell> zyga-uds2, see the blueprints for the roadmap
<robert_ancell> zyga-uds2, https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-converged
<sil-unwell> tvoss: not really :) What *were* the different requirements?
<zyga-uds2> robert_ancell: excellent, thanks
<robert_ancell> seb128, is that building noise still coming through
<ptl> QUESTION: will Mir be portable to other scenarios/distros or even other unices?
<seb128> robert_ancell, it was when I muted you, just unmute with the icon at the top when you talk and mute when you are done
<robert_ancell> seb128, ok
<seb128> robert_ancell, that's what I do anyway to avoid keyboard typing noises etc :p
<mmrazik> ptl: it is an opensource software
<mmrazik> so no reason why it shouldn't be portable. If there are portability issues (technical ones) then I assume that patches are welcome
<achiang> has anyone invited the wayland guys to this session? :)
<ptl> mmrazik: i know but my questions was more like "are there any specific Linux hooks or ubuntu dependencies that would prevent it to be easily ported?"
<kgunn> ptl no
<racarr> ptl: No, besides of course the graphics backend
<ptl> achiang: that was my first ever question, the wayland questions raised in phoronix... I even pasted the URL here
<racarr> but this is modular anyway (GBM, android)
<kgunn> ptl like racarr said
<alf_> ptl: The architecture is very modular at the source level, and probably will be pluggable at runtime
<kgunn> ptl you could get access to lots of hw platforms
<robert_ancell> ptl, but note that the primary requirement is to support unity, not to support generic shells
<kgunn> ptl using mir
<ptl> ok...
<petko10> do tell
<kgunn> ptl depending on how many backends get added :)
<olafura> kgunn you should mute you speaker, your typing getting through
<olafura> mic
<achiang> how much effort (SWAG) would it take to port a SF driver to Mir?
<achiang> tvoss: ^^
<achiang> correct
<robert_ancell> tvoss, repeat the question so it can be followed on youtube
<seb128> if you want people to join the live discussion just give them the hangout url
<balloons> QUESTION: do you see mir-specific graphics drivers being written / supported, or will the primary usecase be utilizing drivers for linux, android, etc
<tsdgeos> tvoss: but as far as i know we will still support X server inside MIR, how does that work regarding the "we use a much simpler driver model than X". Means X programs will be software renderer and not driver accelerated?
<victorp_> tvoss are you using mainly Khronos APIs
<victorp_> ?
<kgunn> balloons: should be opengl/gles if this is what you mean
<ondra> what happens if Google modifies heavily Surface Flinger and hw vendors will do same with drivers to support the change?
<victorp_> tvoss how can we optimise mir for different GPUs?
<alf_> ondra: We will create a new mir graphics backend (or adjust the existing one to handle all versions, depending on the change)
<tsdgeos> ok, tx
<gema_uds> QUESTION: How do you envisage we go about testing Mir?
<zyga-uds2> gema_uds: ^^ great question
<kgunn> ondra: really any hw vendor specifics on android
<kdub__>  ondra the api's we rely on are public, open source headers from google, so if they change them, we should be able to understand the changes
<kgunn> ondra: should be behind hwc hal
<victorp_> thanks tvoss
<victorp_> yes
<gema_uds> what about system wide testing?
<zyga-uds2> QUESTION: how does mir driver model (no support for proprietary drivers yet) affects hardware certification, does that automatically fail certification for everything that does not have free software drivers? (by 14.04 release)
<gema_uds> yeah, I am trying to figure out what the platform QA team should do
<balloons> ^^, me too
<ondra> alf_ Do we have plan to support additional hw features when introduced by surface flinger?
<pixelpapst> repeat the question please
<zyga-uds2> s/affects/affect/
<gema_uds> ok, we'll talk more then
<thomi> help us get mir support in autopilot :)
<balloons> QUESTION: do you have any tests in place now? unit tests perhaps?
<kgunn> ondra: we have a task for integrating android hwc hal as well
<bryyce_> balloons: yes there is a test suite with unit tests
<davmor2> Question: how will this run on Ubuntu chosen default virtual env kvm?  (don't know if it was covered already
<victorp_> QUESTION: we always get asked about benchmarking when talking to OEMs , do we have something we can share or will we?
<davmor2> )
<mmrazik> robert_ancell, tvoss: I assume we should make the jenkins jobs public. They have coverage metrics etc
<racarr> and with integration and acceptance tests
<pixelpapst> thank you
<alf_> ondra: we do not track surface flinger features per se, if it something we need and it's provided by drivers we will consider using it
<racarr> but only for mir as a unit itself
<mmrazik> balloons: so you could actually check what the real coverage is
<tvoss> mmrazik, +1
<racarr> not much full system integration
<balloons> excellent, I'll have a look, ty
<mmrazik> let me do it right now
<kgunn> ondra: conceivably you can always access a variety of hw vendor goodness for composition via hwc hal
<mmrazik> srry that I forgot about this
<petko10> QUESTION : Why was there no dialogue with the Wayland guys in the planning process (or so I read) ?
<zyga-uds2> QUESTION: (again) how does mir driver model (no support for proprietary drivers yet) affect hardware certification, does that automatically fail certification for everything that does not have free software drivers? (by 14.04 release)
<bryyce_> the piglit test suite is also relevant, for testing the mesa portion of the stack
<petko10>  I believe that everybody wants a fast , efficient and portable system . It just seems that that dialogue was avoided in order to have an in-house Ubuntu governed project,which is kind of FOSS unfriendly. Don't get me wrong - I appreciate your work , but that's the impression from the whole situation and news coverage,that needs to be cleared.
<ondra> alf_  My question is driven be evolution of surface flinger and seing how much they managed to accelerare by using hw composition layers.
<ondra> alf_ so how can we benefit from Surface Flinger evolution as much as we can
<kgunn> ondra: i would view that kind of evolution happening on a very slow scale
<pixelpapst> QUESTION: will Mir be able to speak the Wayland protocol at some point ?
<victorp_> that is great
<kgunn> ondra: think gles1.1 vs gles2.0
<achiang> ondra: want to repeat your question with QUESTION: ?
<ptl> petko10: you are talking about the phoronix article, right? Yes, I really think it needs a response... It has many worrying implications.
<zyga-uds2> thanks
<petko10> exactly , I'd be glad to get some clarification on that
<petko10> again - not to hold anyone accountable , just so there's no mist around it
<pixelpapst> OK, cool, thank you.
<robert_ancell> tvoss, repeat the question
<alf_> ondra: by taking advantage of the same driver features that surfaceflinger uses to implement similar functionality
<mmrazik> btw. some testing data from jenkins (will be available on jenkins.qa.ubuntu.com after a next commit to trunk): 362 tests executed; 75% lines covered by tests (a big gap is the examples/ directory accountable for ~13% of lines)
<petko10> well
<petko10> I'm trying to word it here
<kdub__> mmrazik: android has more than 362 tests :)
<mmrazik> kdub__: define android :)
<gema_uds> good coverage != good tests ;)
<ptl> For reference - I've already have given the article URL in the beginning of this hangout but let me paste it again: http://www.phoronix.com/scan.php?page=news_item&px=MTMxODA - it also claims that wayland does not have the given downsides
<mmrazik> kdub__: we have more tests for ubuntu touch obviously
<ondra> alf_ would it make more sense, to based mir than on SurfaceFlinger since we use same drivers, and just add features we are missing?
<kdub__> mmrazik: the android build of mir
<mmrazik> kdub__: oh... yeah... we need that in jenkins :-/
<kgunn> ondra: we have to converge at some point :)
<mmrazik> thomi: I think something where you can help ^^
<kgunn> ondra: think of mir as the convergence point
<alf_> ondra: we also support the free software drivers, so that wouldn't work
<gema_uds> can you make that analysis available for people to read?
<thomi> yeah - feel free to add a work item for me to help get that done after UDS
<ondra> alf_ new 4.2 surface flinger for example supports multi screen support and I see it as fast developing component, so using same drivers, but writing own solution carries some ricks
<thomi> gema_uds: it will be on the public ubuntu jenkins instance
<kdub__> ondra: as new driver features become available, we can add them in
<pixelpapst> QUESTION: could you point us to a list of your needs, so that they can hopefully be met by future iterations of the wayland protocol ?
<gema_uds> thomi: ok
<gema_uds> thomi: I was talking about the analysis where the reasons for not using weiland or any other option were weighted
<gema_uds> thomi: rather than the coverage, which I am also interested in
<cjohnston> QUESTION: I see a bunch of work items in the blueprint, which I assumed would be discussed in this session, but I guess this is a Q&A.. The work items though are very broad.. Is there going to be discussion on those work items, and drilling them down to something more specific than "Window Decoration"?
<thomi> gema_uds: oh, sorry - I misunderstood :)
<gema_uds> thomi: my fault :)
<davmor2> QUESTION:  What is the plans for power saving?  For example will a screen and led lighting be cut completely to save power when the timer is up for lock screen.
<pixelpapst> QUESTION: So the compositor<->shell plugin interface doesn't provide enought room for integration ?
<ondra> kdub_ I just see it as replication of code once written by Google. But understand your point
<gema_uds> davmor2: we are going to be developing power tests, we can sync up on those
<gema_uds> davmor2: any ideas on good use cases are very welcome
<alf_> davmor2: ...but mir itself is developed with power saving in mind, avoid redundant wake ups etc
<cjohnston> "over time the requirements will become clear" sounds like we don't know what problem we are trying to solve
<robert_ancell> https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-converged
<pixelpapst> QUESTION: the proposed time table until 14.04 seems very ambitious. What can a generic external developer do to help ?
<davmor2> gema_uds: I'm sure I can think of a few if I sit down and think long enough, finding the time might be another issue :)
<gema_uds> davmor2: if you stumble over any obvious one that you want covered at some point, just drop me an email ;)
<llstarks> is mir going to impair the ability of phones to boot desktop linux or run x11 apps? phones need an open-source ddx to do this since x11 binaries are rare from vendors.
<pixelpapst> yes, thank you
<davmor2> gema_uds: will do
<pixelpapst> will have a look at LP
<snwh> so will the development of releases post-13.04 start to transition over to mir?
<zyga-uds2> QUESTION: when can we expect mir to land in default ubuntu if rolling release happens?
<davmor2> QUESTION: has x forwarding been covered?  If not how will that happen?  If it has I'll catch it up on the video
<kyleN> Observation: removing the visual glitches from boot -> session transitions will be very nice
<snwh> thanks
<cjohnston> robert_ancell: that's normally what sessions during a UDS are for.. to drill down into the work items.. I understand what window decorations means, but we should be discussing how we are going to get there so that we have very specific work items on how to get there.
<zyga-uds2> I mean the default user will get them installed and used
<thiagoandrade> QUESTION: It was a little unclear to me. Will Mir be able to use existing Android graphics drivers?
<robert_ancell> kyleN, yes it will
<kdub__> thiagoandrade: yep! we can take whatever blobs come our way and pop them in
<davmor2> robert_ancell: Yes over ssh for example
<jderose> so why not just lower the support window on non-LTS releases, but keep doing 6 month releases?
<cjohnston> I understand that Mir was only announced yesterday, but now that it's out in the open, it needs to be worked on as if it's in the open..
<robert_ancell> thiagoandrade, yes
<robert_ancell> cjohnston, yes, we are open now
<cjohnston> robert_ancell: QUESTION: so if we aren't defining the requirements and such during UDS, when will we be defining them?
<sabdfl> hello folks
<kyleN> so combining the reuse of android drivers with a display manager that supports the specific use cases of Unity next on converged devices = reason for MIR, I think
<gema_uds> robert_ancell: the thing is , if we don't discuss those at UDS, you don't get any external feedback
<cjohnston> robert_ancell: what gema_uds said
<gema_uds> we could schedule another one tomorrow :)
<balloons> Could schedule another session to discuss then tomorrow
<cjohnston> 3 months is too long to wait to start drilling down the blueprints
<pixelpapst> QUESTION: so are the requirements for a system-compositor second class ?
<cjohnston> and if you want to get help from the outside, you have to be able to give people something to work on.
<victorp_> SUGGESTION - do you have a irc channel or email list that people can comment
<mmrazik> victorp_: #ubuntu-mir
<mmrazik> on freenode
<pixelpapst> ok, thank you
<TheMuso> victorp_: #ubuntu-mir on freenode for IRC.
<tvoss> victorp_, it's #ubuntu-mir
<petko10> Thanks for the anwsers ,and sorry for my scarse comments , I can't keep up with IRC/live talk. my COMMENT: I still hope there's room for talk with the Wayland guys , because the FOSS community depends on the project and Ubuntu moving away from it is kind of underwhelming
<victorp_> tvoss, so people should read the bps and hang out in #ubuntu-mir and talk to the team
<victorp_> UDS is not just for xmas ;)
<pixelpapst> cool
<thiagoandrade> QUESTION: I'm not familiar to Surface Flinger and one of the ideas of Mir is to upgrade the input system. How connected the input system will be to Mir and do you have plans to integrate it to Linux kernel?
<tvoss> victorp_, sure, would love to have the feedback
<pixelpapst> petko10: agree with your COMMENT
<thiagoandrade> Yes thank you
<seb128> http://summit.ubuntu.com/uds-1303/2013-03-06/display?
<Saviq> tvoss, do you see things like keyboard shortcut/gesture recognition living in Mir, or in some different layer?
<sabdfl> or just hop on IRC / conf call
<llstarks> sup seb128
<llstarks> whoa and here's sabdfl
<llstarks> awesome
<zyga-uds2> yes
<petko10> yes
<sabdfl> hello hello
<popey> tvoss: yes
<pixelpapst> yeah
<mmrazik> tvoss: yes, you are live
<thiagoandrade> yes
<ptl> yes
<petko10> you're live
<zyga-uds2> you are live so far ;)
<gema_uds> you are live
<ogra_> bah, all the good sessions were in the last slot today
<mmrazik> this lag is really bad
* udsbotu changed the topic of #ubuntu-uds-client-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1303/client-1/ - http://ubottu.com/uds-logs/%23ubuntu-uds-client-1.log
<balloons> this is the last session of the day and your live
<balloons> so, you could continue
<kgunn> balloons: thanks!
<cjohnston> yes
<balloons> could you walk through the blueprint and talk about the items, assign some work, talk about problems, and areas where others could help out
<robert_ancell> https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-phone-iteration-0
<balloons> not sure of everyone's availability persay, but worth giving a few mins to
<kyleN> input methods for supporting Asian scripts is currently handled at the X layer (I think) does MIR change this?
<tvoss> I will be back in 5
<cjohnston> I don't know that I need that
<robert_ancell> cjohnston, are you able to join the g+ conversation?
<ptl> earthquake?
<robert_ancell> I have builders next door
<llstarks> sabdfl, is canonical going to fork that flyby of mars? i know you guys have the money and talent to pull it of :)
<kyleN> QUESTION: input methods for handling Asian (and other scripts) is handled (I think) at the X level. for example ibus depends on x11. How will MIR support such input methods?
<seb128> url is https://plus.google.com/hangouts/_/ff2785ffa15ca0508f8616284456489ebcb68966fb?authuser=0
<kyleN> (I realize session is over, but what the heck ;)
<llstarks> the discussion was needed. mir's complaints about wayland are unfounded.
<pixelpapst> (sry AFK for now)
<kyleN> regarding my question above, I see that Input Methods (and Accessibility) are in fact the last item on the bprint whiteboard.
<zyga-uds2> put lp:mir on github, that might help for participation
<bryyce_> zyga-uds2: doubt it
<alf_> zyga-uds2: we can just use your bzr git bridge ;)
<zyga-uds2> alf_: no that works backwards
<zyga-uds2> alf_: as in using git on launchpad
<alf_> zyga-uds2: right, it should work great
<zyga-uds2> alf_: the point is github is where people are, not git vs bzr discussion
<alf_> zyga-uds2: ok, got it
<zyga-uds2> gema_uds: ++
<zyga-uds2> robert_ancell: if we could have discussed this earlier then I would have strongly urged us to have a story for certifying traditional hardware by 14.04
#ubuntu-uds-client-1 2013-03-06
* udsbotu changed the topic of #ubuntu-uds-client-1 to: Track: Client | Out-of-the-box experience for Ubuntu Phone | Url: http://summit.ubuntu.com/uds-1303/meeting/21604/client-1303-out-of-box-experience/
<tsdgeos_uds> is the out of the box experience session happenning?
<Mirv> tsdgeos_uds: it isn't in the schedule at the moment: http://summit.ubuntu.com/uds-1303/2013-03-06/
<tsdgeos_uds> yeah
<tsdgeos_uds> but it was like 30 min ago last time i checked :D
<Mirv> hmm..
<pete-woods> it seems to have disappeared..
<ricmm> it *just* disappeared
<ricmm> the session is cancelled
<ricmm> sorry guys
<tsdgeos_uds> okidoki
<tsdgeos_uds> back later then D:
* udsbotu changed the topic of #ubuntu-uds-client-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1303/client-1/ - http://ubottu.com/uds-logs/%23ubuntu-uds-client-1.log
* udsbotu changed the topic of #ubuntu-uds-client-1 to: Track: Client | Add app-model and -lifecycle to platform api | Url: http://summit.ubuntu.com/uds-1303/meeting/21613/client-1303-add-app-model-and-lifecycle-to-platform-api/
<tvoss> seb128, are you going to start the session?
<seb128> tvoss, yep, just finishing the previous one (I had to host the foundations one, slangasek was having hangout issues)
<tvoss> seb128, ack
<tedg> Let's go!
<tedg> Oh, sure
<tvoss> tedg, wanna join, we have got free places :)
<achiang> tvoss: can you send an invite to ondrej kubik?
<tvoss> achiang, at canonical.com?
<achiang> tvoss: one sec, trying to track him down ;)
<tvoss> achiang, yup
<achiang> ondra: to what email address shall tvoss send an invite to?
<tvoss> tedg, you coming?
<victorp_> \o/
<victorp_> rsalveti I am definetly rolling
<victorp_> downhill
<rsalveti> victorp_: haha
<victorp_> tvoss just dont do it in a public channel
<victorp_> TBOB
<achiang> 7 bits shall be sufficient!
<kyleN> POWER
<seb128> we have 2 tedg, scary
<tedg> seb128, yeah, chrome crashed :-(
<ricmm> and my network went down
<ricmm> and now I cant reach plus.google.com :(
<awe_> ted, telephony-app has the same problem...
<bfiller_> if hud fires a command to an app via the HUD and the app is suspended need a way to deliver the event to the app when it wakes up
<bfiller_> or somehow process it
<awe_> bfiller_, we need a concept of services
<awe_> provided by apps
<awe_> ondra is nailing it
<bfiller_> it's one solution
<awe_> bfiller_, we need the concept ( I'm not proposing a particular solution )
<victorp_> tvoss when is phase1 and phase2
<bfiller_> not sure how that helps with the hud example by having a background service
<awe_> bfiller_, like answering  a phone call
<awe_> bingo
<dbarth> tedg: what about serializing the last known command set before the app suspend?
<tedg> dbarth, Yeah, I'm less worried about getting the options, we cache that, I'm worried what happens if the user clicks on them.
<tedg> dbarth, They'd expect the app to respond somehow.
<kyleN> CURIOUS: are the high level usability requirements for this?
<zyga-uds_> hi
<dbarth> tedg: and that could be one reason to wake up the app, reply, go back to sleep; until the app really has to perform the action itself
<dbarth> ?
<kyleN> s_the_there_
<tedg> dbarth, Yeah, that would be an option, perhaps HUD manages app state?  Seems a bit heavy though.
<dbarth> tedg: ie, short helper "continuation"s, as opposed to long running tasks
<dbarth> HUD could rely on ad-hoc side APIs for that purpose; for ex. other mobile OSes have APIs for download tasks or VOIP calls
<achiang> tedg: no - iOS doesn't allow badly written apps
<dbarth> ie, specialized APIs to adjust to the general app lifecycle
<tedg> achiang, Well, sure.  I don't think we want that level of control.
<achiang> tedg: why not? i think we do
<achiang> tedg: this is my hot button
<tedg> achiang, Because it would suck on the desktop
<victorp_> tedg - it shouldnt suck anywhere
<victorp_> even on a 512MB phone
<achiang> tedg: i don't think that logically follows. if the system API is written well, then let the *system* figure out how to let apps behave differently (either on mobile or desktop)
<achiang> but *apps* don't get that privilege
<achiang> that leads to the Android mess
<tedg> achiang, Yes, but we need to be able to support the desktop use cases, which allow for background running of the apps.  So you want to be able to have YouTube running unfocused.
<tedg> That isn't directly related, but we need to do both.
<achiang> tedg: the platform API should be aware of form factor
<seb128> achiang, want to join the hangout?
<achiang> seb128: sure
<dbarth> lool: if the shell identifies clearly the focused app, then you can guide the kernel to be a lot more aggressive about swapping out apps
<tedg> achiang, Sure, but we shouldn't require the app to be aware of it (well, at this level)
<dbarth> lool: and for background activities, you can define things a lot more specifically; again to guide the kernel to swap out everything that is not registered with those background apps
<mfisch> you can solve the memory worries by making the lifecycle firm that suspended apps can be killed without warning
<dbarth> +1
<mfisch> apps going into suspend should clean up in case they never get resumed
<lool> dbarth: I think we're covering swap right now indeed
<joe-uds> what metrics will you use to measure resource usage?  Or, in other words, which resources are your highest priority; memory, power?
<victorp_> tedg doesnt that means that app can dump anything there and blow out the disk space?
<bfiller_> tedg: apps can do that now
<mfisch> does android limit how much space the apps have to store local state?
<dbarth> victorp_: we should expect the app manifest and container to constraint that
<victorp_> dbarth: ack
<dbarth> greedy apps being prevented from installing / running if the system doesn't have the resource budget
<victorp_> well we should stop them from running at all
<tedg> Yeah, we will have to limit caches for apps in general.
<mfisch> dbarth: does the system prevent them from running?
<mfisch> what if I have a device where I only want to run one app, but it's resource intensive?
<dbarth> i don't know ;) tvoss?
<victorp_> tedg - but the system should be the one doing that for the app
<mfisch> I think in Android, apps that use too much memory or disk are policed by users complaining about them
<mfisch> I just installed an android game that used 1.8G of disk
<rsalveti> the system will not block any apps
<rsalveti> it'll just kill them if needed
<awe_> ChickenCutlass, ask rsalveti about firefox
<mfisch> rsalveti: right
<dbarth> ChickenCutlass: :D
<victorp_> rsalveti, so if the hoggin app is the first one launched what happens to the next app that ones to run
<bfiller_> desktop is just another policy, done
<victorp_> QUESTION: tvoss, will we have application budgets depeding on the system for memory and other things?
<rsalveti> victorp_: once the hogging app is in background, the system will probably kill it
<victorp_> rsalveti: I dont hink we should allow that app even to start
<rsalveti> it's just hard to guess that before actually running the app
<rsalveti> we could have similar solution as low memory killer, or using cgroup to limit the application (cpu and memory wise)
<victorp_> rsalveti: I agree,, I gues I am saying regardless if the space is available
<rsalveti> but trying to guess and request the app to tell how much it'd use, doesn't seems too safe
<victorp_> you will have to run it to start with
<rsalveti> right
<kyleN> can't it be phone AND desktop? (docked)
<victorp_> achiang - not sure how the manual process with apple is more about design
<victorp_> kyleN yeap
<achiang> victorp_: they audit for API abuse
<awe_> ChickenCutlass, but it's how the platform API allows an application to do these things
<mfisch> win8 caps roaming app data (data that travels between devices and the cloud) at 100k
<mfisch> 50x the suggested limit here
<dbarth> kyleN: we could imagine that this extra desktop is a sort of specialized app, like U4A to Android
<dbarth> with lxc or a cgroup to prevent the desktop to crush the phone resrouces
<victorp_> ondra: but if you make it a % and the total is bigger (e.g. memory) then the rule is device specific
<dbarth> lool: can we have one to map the desktop / converged case with that model?
<victorp_> tvoss +!
<victorp_> +1
* udsbotu changed the topic of #ubuntu-uds-client-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1303/client-1/ - http://ubottu.com/uds-logs/%23ubuntu-uds-client-1.log
<dbarth> lool: which one do you call the follow-up session? the one on the update process?
<lool> dbarth: No, a separate session later after vUDS
<dbarth> achiang: they do a static audit for api calls afaik; but you can abuse that by crafting objc calls at runtime
<dbarth> ok
* udsbotu changed the topic of #ubuntu-uds-client-1 to: Track: Client | Update process for Ubuntu phones | Url: http://summit.ubuntu.com/uds-1303/meeting/21605/foundations-1303-single-image-update/
<achiang> dbarth: interesting. surely that gets detected later though... i mean sooner or later, the apple police find you ;)
<dbarth> yeah, they run faster than you'd think
<stgraber> seb128: can you send me the link to this hangout? (assuming you're the one running it)
<stgraber> seb128: nevermind, summit just gave it to me now
<seb128> stgraber, ok
<achiang> seb128: both ondra and i would like to be part of it too, please
 * ogra_ waves
<seb128> achiang, gave you the link
<mfisch> the french speakers are taking over!
<seb128> ogra_, want to join the hangout?
<achiang> seb128: thanks
<vibhav> seb128: me too!
<ogra_> seb128, yup
<swaveck> QUESTION: will "Mir" be updated automatically to current Ubuntu phone OS ?
<lool> ChickenCutlass: here
<seb128> swaveck, wrong session?
<seb128> swaveck, we do " Update process for Ubuntu phones, tablets "
<rsalveti> swaveck: not automatic from our current images I'd say
<cjohnston> please
<rsalveti> as we still need to do some more work at the android side of the image
<rsalveti> as ubuntu can't update the android part atm
<swaveck> thx, that's all I wanted to know
<ogra_> seb128, ?
<seb128> ogra_, I was wondering if you wanted to join the hangout
<seb128> ups
<ogra_> seb128, and i said yes :)
<mfisch> Except carriers won't be controlling the desktop like they will phoens
<seb128> ogra_, sorry, overlooked that
<vibhav> seb128: You forgot me too :)
 * slangasek waves
<sebsebseb> hi
<vibhav> slangasek: hey
<slangasek> sorry, I seem to be unable to join a hangout while I'm also running camera for another one, so I'll be IRC only
<seb128> vibhav, cf query
<seb128> slangasek, ok
<selena2013> greetings from Miami
<sebsebseb> selena2013: you followed me :d
<cjwatson> rsalveti: apt-clone
<pitti_> tedg: how is the "factory" and "current" image different?
<cjwatson> (Package manifest + delta)
<tedg> pitti_, The current could have updates.  factory + 1
<pitti_> tedg: I assume we have some kind of overlay anyway where packages can install themselves in?
<ogra_> cjwatson, join the hangout :)
<cjwatson> Need a break from being on camera :)
<ogra_> heh
<gema_> cjwatson: keep the camera off
<xnox> it's full as well isn't it?
<pitti_> tedg: ah, I thought we'd just create new images every month or so, and people download/install those
<slangasek> no
<cjwatson> Actually I forget to just what extent apt-clone shows a delta; it may only be for files modified in any given package
<mfisch> I dont think carriers will let you do monthly updates
<mfisch> too much testing for them
<xnox> You cannot rebase overlays effectively onto new image.
<mfisch> in the US anyway the carries have a lot of power
<rsalveti> cjohnston: sure, but that's not necessarily something we use by default
<pitti_> well, whichever cycle is appropriate
<rsalveti> cjohnston: sorry
<gema_> mfisch: carriers would decide what they update, I think
<rsalveti> cjwatson: ^ :-)
<ogra_> use nilfs2 :)
<mfisch> gema_: right
<cjwatson> rsalveti: We include it in some bug reports today
<seb128> lool, do you know if somebody is taking notes?
<gema_> mfisch: so it's up to them, not us
<mfisch> most android phones now seem to get 0 or 1 updates
<cjohnston> seb128: notes are being taken in the pad
<mfisch> over the whole life of the product
<pitti_> stgraber: why would it be COW, if we only update once a month?
<rsalveti> cjwatson: right, cool
<slangasek> so one of the notes in the etherpad is "let's ignore apps for now"
<cjwatson> And could certainly include it in more
<pitti_> stgraber: I thought more like "OS" == image, "apps" -> overlay?
<gema_> mfisch: I keep getting new versions of android every couple of months on my galaxy sIII
<seb128> cjohnston, by who?
<cjohnston> seb128: I see a couple of colors, I don't know who
<mfisch> gema_: my droid razr max is still 4.1
<slangasek> we can't ignore the problem of /var/lib/dpkg vis-Ã -vis full-image updates
<mfisch> gema_: some phones update more often than others, usually the flagship ones
<seb128> cjohnston, that doesn't mean somebody is assigned to take note or while assure everything is recorded
<gema_> mfisch: right
<cjwatson> slangasek: I think that was regarding sandboxing of apps
<cjwatson> And suchlike
<slangasek> cjwatson: yes, and some people are handwaving everything into the category of "apps"
<slangasek> and we need to not do that
<cjwatson> Granted
<slangasek> there are three features we want here, and AFAICS we can only have two
<slangasek> - ability to use apt
<ogra_> slangasek, i think they talk about the android rootfs
<ogra_> vs ubuntu userspace
<slangasek> - ability to do system image updates
<lool> seb128: there are some notes being taken in the pad at least
<lool> seb128: I'm taking some too
<seb128> me too
<lool> done so in most sessions today
<seb128> lool, let's assume we will manage to cover
<lool> :-)
<slangasek> ogra_: ok, I don't know why they're talking about an android rootfs, that wasn't what this session was set up for :)
<Wellark> QUESTION: for factory reset, would it be possible to use the flashing tools to do that? we would have a tool which has a simple button "Reset to Factory State" and the tool would simply reflash the phone with fresh image effectively doing factory reset. Naturally this would require the device vendor to provide their factory images for public
<slangasek> 3) avoiding the overhead of overlay
<ogra_> slangasek, the subtitle says "For phones and tablets, it  doesn't necessarily make sense to use apt to update the OS; a full-OS update may make more sense ..."
<slangasek> ogra_: yes, "the OS" isn't an *android* rootfs
<ogra_> its part of it
<pitti_> that's what I assumed -- we wouldn't use apt for the "base OS"
<cjwatson> You can do all three if you required apps to live in a separated filesystem segment and used different apt and dpkg dbs.  I'm not saying we'd want to but it's possible
<ogra_> right
<ogra_> unless you port it to android :)
<slangasek> ogra_: could you please steer the discussion in this direction?
<cjwatson> (Admittedly with some constraints enforced outside apt/dpkg)
<pitti_> if we do want to use apt, I retract my proposal of an overlay, of course
<mfisch> this is an important point
<slangasek> because it seems folks are not paying attention to IRC
<mfisch> we're used to being in control of updates...
<rsalveti> Wellark: but we'd need to store the factory image somehow
<cjwatson> pitti_: I think it's a mistake to discard apt from the design, given that we need to converge things on the desktop too
<slangasek> eh, oh; is ogra on the video either?
<slangasek> (seems not)
<Laney> he is
<mfisch> and operater gets to add their crapware
<seb128> he is
<ogra_> i am
<rsalveti> otherwise the user would need to download it, which is bad, as usually you want factory reset when something really bad happened
<cjwatson> Our remit is not simply to design something that works *only* for carrier-mediated systems
<slangasek> ah, there you are
<ogra_> but i dont want to interrupt the monologue
<slangasek> silly tiny videos
<ogra_> german flag :)
<pitti_> cjwatson: *nod*; so we should rather focus on making apt more efficient (delta debs, etc.) than rolling out full new OS images for upgrades?
<gema_> I don't think an apt model would work with phones / tablets due to the lack of control operators/carriers would have
<cjwatson> I'm not arguing against the system-image-update model
<Wellark> rsalveti: they can be downloaded. for example Nokia does provide firmware images for all their mobile phones over Internet and the service centers simply download those images when the consumer brings a device for reflash
<cjwatson> I'm just saying we should design such that it's something we can build without discarding apt on systems where it's usable
<cjwatson> IYSWIM
<seb128> slangasek, what points do you want to be made/in which direction want to move the direction?
<rsalveti> Wellark: right, but then it's a full flash/full factory reset
<pmcgowan> app update model is different, just not relevant here
<rsalveti> Wellark: but the phone still provide a way for the user for the system to go back to factory reset
<Wellark> well, they were talkig about factory reset before
<rsalveti> without erasing everything for all partitions, for example
<ogra_> pmcgowan, its the same package database
<cjwatson> Well
<cjwatson> Today
<pmcgowan> would not assume that
<ogra_> pmcgowan, unless there was something defined which isnt discussed at UDS
<gema_> why don't we store the factory image on a partition on the device to be able to restore?
<rsalveti> Wellark: guess we're talking about 2 models for factory reset here
<cjwatson> In order to do system image updates, it kind of has to be a separate db
<ogra_> cjwatson, right
<pmcgowan> ogra_: not discussed yet, needs more work
<slangasek> seb128: the problem that needs to be solved is how we can update the Ubuntu image without trashing any packages the user has installed
<rsalveti> one is one way the user could trigger at the device, and the other for a full clean flash
<slangasek> maybe we solve this by not allowing users to install any apps
<slangasek> s/apps/packages/
<slangasek> but then it's not very Ubuntu :)
<seb128> tedg, ^ what slangasek said
<pitti_> cjwatson: we could perhaps install "core os" dpkgs into the "core os" partition, and everything else into the apps overlay, so that you can use apt and new OS images at any time without duplicating the disk space?
<vibhav> 21:46 < pmcgowan> ogra_: not discussed yet, needs more work
<slangasek> well
<cjwatson> pitti_: that general principle
<vibhav> oops, sorry for the wrong hilight
<cjwatson> Ish
<ogra_> vibhav, yes, pings highlight for me on IRC
<slangasek> lool: but it's not "apps", it's *packages* that are the existing Ubuntu system
<vibhav> highlight, even
<dbarth> slangasek: the tools for ubuntu, the OS "toolkit" for developers, and ubuntu, the OS on end-user devices, may have different OS installer / updaters?
<pitti_> that's very similar to "daily dist-upgrade" vs. "daily ISOs" in fact
<slangasek> and there's no separation between the base system and "packages" today
<cjwatson> I do think we should finish off the debdelta work, but I don't think it's desperately related to this ...
<dbarth> with apt/dpkg still being what's used to construct images for client runtimes sans apt
<xnox> slangasek: sure, but the system os can ship fake equivs that provides everything that one gets from the base image, and then in apt world those will exist normally.
<pmcgowan> dbarth: right thats a possible model
<seb128> slangasek, seems like the "investigate" are about looking at replacing the apt/packaging model
<slangasek> dbarth: "may" have doesn't really address the design
<cjwatson> Who is talking?  Sorry, no lower-third there
<lool> slangasek: I don't understand the distinction between apps and packages point
<slangasek> which is what we should be using this session for
<lool> slangasek: I'm saying that we need a separation no matter what technology we pick
<lool> including if we use .debs
<dbarth> slangasek: make 'may' into a strict negation; a you have a clear cut design ;)
<lool> we will want some kind of user side root for his .debs separate from the system one
<slangasek> lool: so that needs to be designed
<lool> yes
<lool> but no matter how we design user installed apps, we will want a way to deploy factory system images and updates to system image
<seb128> slangasek, ok, back on topic ;-)
<ev> is dpkg really appropriate for a mobile platform? It's not atomic, for a start.
<asb_b_b> has anyone analysed what maemo did?
<ogra_> :)
<pgraner> ChickenCutlass, +100
<barry> yes, but what are the requirements for phone app updates that are not (or can't be) fulfilled by apt?
<slangasek> ChickenCutlass: it's not too many people, it's I'm in another hangout and I can't be in two simultaneously
<xnox> Laney: jump off =)
<ChickenCutlass> slangasek: ok
<asb_b_b> meamo was also deb-based for app installs at least (not sure about system updates)
<seb128> slangasek, use  a second account :p
<Laney> it's not full
<slangasek> seb128: I did, it doesn't help
<seb128> slangasek, weird
<sebsebseb> Yes good point there, a phone must just work, like a microwave!
<rsalveti> asb_b_b: and it's slow as hell :-)
<gema_> tedg: but you don't have the same amount of HW diversity on phones, as you'd have on desktops
<sebsebseb> consumers won't fix stuff etc
<stgraber> slangasek: we can probably invite your landline, that should work
<xnox> Laney: i see 10 faces.... =)
<ogra_> tedg, we just need to use a proper filesystem that supports snapshotting :)
<rsalveti> as dpkg/apt consumes a *lot* of io
<asb_b_b> rsalveti: this is true :)
<ev> I realise we have a lot tied to it already, but its problems are fairly large to carry to an entirely new platform.
<slangasek> stgraber: oh, good point
<tedg> ogra_, Yeah, FS snapshotting is a good answer
<Laney> 11
<stgraber> seb128: ^ can you invite slangasek's phone?
<cjwatson> apt-get update> could be considerably improved by pdiffs
 * ogra_ points to nilfs2
<xnox> ogra_: filesystems that support snapshot do not support rebasing onto new snapshot.
<ogra_> xnox, well, for now we only want rollback
<xnox> ogra_: no. we want to upgrade to new snapshot. =))))
<mzanetti> Maemo was using apt. They at least seem to have solved the factory reset issue with it. Probably worth to have a look at.
<ogra_> xnox, as i understood we want to be able to roll back if an upgrade fails
<ogra_> xnox, since you cant fix it on a phone/tablet
<ssweeny> maemo updating was really slow
<ev> achiang: it also is built around a model where the applications share a filesystem namespace - presumably not the case here?
<asb_b_b> cjwatson: I've found pdiff to be pretty cpu intensive
<cjwatson> cpu/bandwidth tradeoff, true
<seb128> stgraber, slangasek: how do I do that? the invite doesn't take phone numbers?
<ogra_> xnox, though rolling forward to new snapshots woudl be cool :)
<cjwatson> pitti_: well, there's eatmydata et al
<achiang> ev: well it is the case today still (as we know), and we just don't know how to get from where we are today to the future
<tumbleweed> pdiffs also require significantnly more requests, if you are several pdiffs behind
<cjwatson> I have some background concerns about the reliability of LVM snapshotting ...
<slangasek> seb128: perhaps on-air doesn't allow phones
<xnox> tedg: sure, but it doesn't help to rebase onto new snapshot.
<isantop> What Filesystem is being used on the UTDP right now?
<seb128> sorry
<Wellark> the feed died!
<tsdgeos_uds> errr
<asb_b_b> arrrghhh, hangout is dead
<cjwatson> I've seen the odd mysterious problem with snapshots failing to remove in some undebuggable way
<jdstrand> bummer
<tsdgeos_uds> what happened?
<achiang> we are still here in the hangout
<kyleN> hangout died
<slangasek> seb128: wrong button ;-)
<xnox> hangout died.
<victorp_> ooooops
<cgregan_> refresh the page usually fixes it
<xnox> the host has quick!
<pgraner> yep hangout is dead
<cgregan_> yay
<kyleN> ok, youtube stream died
<xnox> the host has quit!
<kyleN> back
<asb_b_b> aaaand we're back
<tsdgeos_uds> it's back!
<cgregan_> back
<seb128> sorry, wrong click
<Saviq|UDS> ^^^ most useful IRC conversation _ever_:D
<seb128> slangasek, yeah, seems hangout (or google.fr) doesn't allow it
<ev> tedg, pitti_, others: would this not be solvable with a extremely simple package management system (just a zip, as achiang mentioned other platforms use) and filesystem namespace separated software?
<dbarth> seb128: hands off the keyboard
<slangasek> seb128: hangout allows it, but I checked here and I also don't have the to-POTS option for an on-air hangout.  Probably because someone being called has no option to accept the broadcast agreement
<xnox> ogra_: we do want to keep / /usr to be readonly.
<cjwatson> ev: we'd want to assemble the former from debs - redesigning our entire build process as well as designing the deployment process doesn't seem like a sensible use of resources
<kyleN> define a "system"
<seb128> slangasek, oh, works now
<seb128> slangasek, just did it
<slangasek> seb128: oh
<seb128> bah
<seb128> no
<pitti_> ev: yes, or even just two separate partitions for dpkg (this needs untangling /var/lib/dpkg/info, though)
<seb128> I've a 0â¬ credit
 * achiang would like to get a clear sense of the requirements and then solve backwards from there
<slangasek> ev: that doesn't help us with any of the existing packages that users may want to install
<seb128> they want money for it
<xnox> kyleN: ubuntu-minimal.
<ev> cjwatson: do we actually need it? All the software in the archive isn't going to run on this thing. It's an opportunity to make a clear break from a system that's built for an entirely different structure.
<slangasek> we have three choices here
<slangasek> - don't support full-image updates
<stgraber> seb128: US/Canada numbers are free
<slangasek> - don't support apt
<slangasek> - implement splitting the base OS from other packages on disk
<seb128> stgraber, slangasek: well, I added the number in there, not sure if that worked
<cjwatson> ev: The packages that go to make up the images are ones that we want to converge onto the desktop in due time, and we're going to want to build them as part of Ubuntu
<slangasek> and so far, I think we're talking in circles around this issue
<cjwatson> ev: It's not necessary to make a "clear break" for the build side of things
<cjwatson> Deployment, sure
<seb128> slangasek, got it?
<cjohnston> slangasek: do you have a personal account you could join with?
<tedg> slangasek, I think that the splitting is orthogonal
<slangasek> seb128: incoming
<lool> who is it on the phone?
<barry> to have a credible convergence story, the same mechanisms must work on both the phone and desktop, otherwise you've got the linux version of os x and ios
<lool> is it Steve?
<tedg> slangasek, We could split and even have different policies on each.
<ev> cjwatson: so take a deb and turn it into something that requires no client-side processing (on the server, of course)
<ev> ?
<cjwatson> ev: well, it's basically an image build isn't it
<ev> yeah
<cjwatson> ev: as you say except s/a deb/a pile of debs/
 * ev nods
<xnox> cjwatson: sure, it's just like we don't need locally all the descriptions of all the apps - one can fetch it over the network if one wants new packages.
<slangasek> tedg: that's option 3, and currently we don't have it and there's no convergence on it, just handwaving
<slangasek> this is a completely separate question from third-party packages
<seb128> slangasek, did you try talking? didn't hear you yet
<TheMuso> I can hear phone activity...
<seb128> slangasek, \o/
<TheMuso> Or what sounds like something coming over a phone line.
<tedg> What if we have a package that represents "the image".  Basically something that hardcodes to the version of packages to a set of specific versions.
<tedg> If you change anything, you have to drop that package.
<tedg> If you have one, then we can download a zip that has debs to go to a different version.
<tedg> So we get a zip of debs.
<gema_> TheMuso: there is an echo on the video indeed
<cjwatson> Tying this to a developer mode sounds very sensible
<dbarth> chromeos does that, without packaging system though
<xnox> rsalveti: cjwatson: but that doesn't sound like convergence to me.
<ogra_> we plan to offer a terminal app ...
<ogra_> that means we give console access to users (kind of)
<pmcgowan> the operators will somewhat dictate what happens for a normal production system
<xnox> "sources"
<xnox> I want to do image updates from month-to-month on the desktop.
<xnox> I want my desktop & cloud do that as well.
<xnox> and do that in fast-path mode as well for cloud nodes for example.
<ogra_> i want my phone to do desktop and cloud !
<ogra_> in a converged world :)
<xnox> this is not _just_ for the phone
<ev> is the suggestion being made that we use apt/dpkg for all applications on this system, or just legacy applications from the ubuntu archive?
<dbarth> ogra_: your desktop could be an app, with a container hosting the regular apps and packages
<dbarth> like U4A, but for Ubuntu
<ogra_> dbarth, yes, but i want to be able to acces the phone app and its data from my desktop app for example
<ogra_> thats what i understand under convergence
<xnox> dbarth: interesting, as long as we can snapshot on top of base image.
<pmcgowan> you want one app actually
<dbarth> ogra_: that's an IPC, dbus or sometihng similar
<ogra_> pmcgowan, if i use a different better desktop suited app (gimp) i still want to access the phone data
<ogra_> which i created with a phione app
<xnox> "sanity check"
<ogra_> (touch-gimp)
<dbarth> ogra_: you use a mount bind, like with lxc
<ogra_> dbarth, my MOM wont be able to :)
<dbarth> ogra_: make another app for her to do that
<ogra_> she docks the phone and expects to access the same data and having the apps available
<ev> lool: ++;
<ogra_> and to be able to use more powerful apps on the same data
<dbarth> or do it automatically on a known shared directory
<dbarth> exchange zone
<cjwatson> Having user apps live in a separate (maybe sandboxed) apt/dpkg database would have the effect of making apt's handling of those very much faster; but again isn't necessarily a converged approach
<ogra_> thats not what i woudl call convergence
<bfiller_> another firm requirement is installing new apps on phablet from Ubuntu Software Center
<dbarth> we're just defining what convergence will mean for various compartments of the product
<cjwatson> achiang: To what extent is this required to be handled by package management on the device, as opposed to by static checking on the archive side?
<lool> why would we have the source of things done in postinst?
<achiang> cjwatson: i don't think it is a requirement to have it handled on the device
<lool> we could still check binaries to see whether they attempt to do something
<xnox> ogra_: slangasek: how would unionfs "rebase" onto new image?
<lool> but it seems really hard
<lool> I'd rather we design it in a way that apps don't have root when installing and are constrained to some file system hierarchy
<cjwatson> achiang: Because we do have lots of well-understood and extensible tools for checking packages, so we could enforce whatever constraints we wanted on apps on the server side
<cjwatson> e.g. no maintainer scripts except for vetted debhelper-produced fragments
<slangasek> lool: we need to do that, but that's a separate question
<cjwatson> (or no maintainer scripts at all if feasible)
<slangasek> out of scope for this session
<cjwatson> achiang: I'm asking this because I think that's lots easier and I'd like to use that possibility to trim the scope of the required client work
<dbarth> cjwatson: +1 that will preserve the goodnes built into packages, without the runtime overhead
<kyleN>  base os = ubuntu-minimal + ubuntu-standard?
<dbarth> less of an abrupt / risky change
<cjwatson> well, standard's pretty small, but bikeshed
<barry> look at ios.  base system updates are very heavyweight.  updating apps are lighterweight and happen all the time
<achiang> cjwatson: ah, i see your point now. thanks
<bfiller_> how does android handle all of this? can that be a model for us then adapted
<lool> base OS would include display server and unity
<ogra_> bfiller_, android isnt converged :)
<lool> bfiller_: android doesn't try to support 10000 apt-get installable packages
<lool> which is what people want to do here
<lool> I dont personally agree that's a goal for phone images
<ogra_> the prob isnt to find a way to upgrade phones and tablets, it is how to not trash the convergence :)
<lool> I don't think we want apt-get install on the phone
<seb128> lool, it's not the goal for the phone image
<seb128> it's the goal for the convergent desktop to still have the option to use Ubuntu packages
<cjwatson> tedg: I'd like to encapsulate as much as possible in debhelper fragments
<lool> Yes
<cjwatson> We're quite a long way there already
<Wellark> lool: the phone can be docked and you get a standard desktop
<seb128> lool, otherwise our "convergent 14.04 LTS" will have none of Ubuntu
<seb128> e.g no libreoffice
<tedg> cjwatson, Yeah, I was thinking just having a different divert helper for base vs. non-base.
<cjwatson> tedg: Because then we can do static checking without having to add a lot more code to the core package manager
<pitti_> lool: but our goals is not to do a "phone" OS, but something that works everywhere, so dropping apt-get install support ins't really an option IMHO
<tedg> cjwatson, Yeah, I'm just worried about things we, for instance, sync from debian that might not be checked.
<lool> I actually believe our model is flawed to scale to support more apps
<dbarth> guys, use lxc and put your converged desktop in it; you won't have to migrate all of your packages for 14.04; just the ones criticil to the phone os
<bfiller_> ogra_, lool : so maybe we need to think about adapting what we have
<tedg> cjwatson, Or if someone sets up a debian repo in their search path.
<cjwatson> tedg: Well, if the testing is manual that's kind of a failure :)
<seb128> lool, nobody wants to scale it
<cjwatson> tedg: If they do that surely they own the problem
<seb128> lool, I think what is wanted is to keep compat support for it to not loose the Ubuntu archive
<tedg> cjwatson, Heh, yes.  But a PPA is probably more typical.
<lool> I am open that we keep a way to have extra APT-installed apps in this or that chroot somewhere, but eventually moving to some new app format
<ogra_> bfiller_, we need to design it right from the ground up ... or invent an interim solution we'll throw away once real convergence happens
<seb128> lool, +1
<lool> (whether the new format is implemented with .deb or not doesn't matter)
<seb128> lool, right, new format is an orthogonal discussion
<cjwatson> ChickenCutlass: this is not quite as fixed as it looks
<lool> but I don't want the transitional requirements to affect our base design
<jdstrand> fyi, currenly the application isolation work will use a dh script to put stuff in /etc
<cjwatson> ChickenCutlass: separate dpkg database for apps + path filtering (which exists in dpkg)
<awe_> If you need an additional lib for an Android app, it goes to the app's sandbox... it's cannot be leveraged by other apps
<xnox> pitti_: but we can wrap dpkg with dpkg-filter to trim all the locations we don't like.
<ChickenCutlass> cjwatson: ok great
<barry> couldn't that be somewhat mitigated by better pre-processing and imposition of rules on debs?
<jdstrand> it doesn't strictly *have* to be etc, but worth noting
<mzanetti> Nokia had a check for every deb package ending up in the store that it only installs stuff to /opt/ except the .desktop file and icon
<lool> slangasek: Sorry, I dont feel able to followup on the overlay question
<cjwatson> man dpkg and grep for --path-exclude and --path-include
<lool> I am happy to follow the discussion though
<cjwatson> For the basic facility that you could use
<pitti_> xnox: well, we don't want to just cut out random files from ubuntu archive packages
<asb_b_b> anyone looked at Valeries Aurora's union mounts?
<greyback> QUESTION: sorry I'm late, I missed stuff, have alternative package formats been considered?
<cjwatson> It might be more sensible to use a container; I'm just saying there are possibilities
<pitti_> xnox: I think if we do any modification, they should apply to the "base OS" side, not to the "everything else" side
<xnox> pitti_: cutting out /home sounds like a good idea across the board =)
<ogra_> greyback, nope
<cjwatson> mzanetti: Yeah, that's exactly the kind of thing I'm suggesing
<cjohnston> seb128: 4 minutes left fwiw
<cjwatson> +T
<seb128> cjohnston, right
<pitti_> xnox: heh, yes :)
<zebaszp> I did join a little late, but did rsync/zsync get mentioned at any point? just curious
<pitti_> xnox: there's certainly a white list of alllowed toplevel dirs (/etc/, /lib/, /var, /usr, etc.)
<xnox> greyback: out of scope for this topic.
<stgraber> cjwatson: oh nice, I didn't know that was there already, that should make things much easier
<greyback> ogra_, xnox: why? Shouldn't we first decide if another package format is worth considering, before looking into solutions for the problems dpkg gives us?
<ogra_> greyback, apt and dpkg will always be used in your desktop ... i.e. if you dock the phone
<Wellark> pitti_: we could define the packager guidelines which dictate what is OK and what is not. Then we would check all the packages in the repository against these rules
<bfiller_> lool: +1 on that, base image updates in single file, new apps that will be installed in new packaging format or restricted deb format
<ogra_> greyback, we need a proper plan that covers both cases
<ogra_> else its throw away work
<pitti_> Wellark: for the "new apps", sure; but not for all packages that are already in Ubuntu
<bfiller_> or something like that for a phase 1
<rsalveti> bfiller_: problem is when we look from the convergence pov
<pitti_> Wellark: we already do that for the extras.ubuntu.com appdev bits
<dbarth> lool: you should list usecases to define the reqs
<lool> dbarth: they are in the pad
<zebaszp> I hate to repeat myself, but...I did join a little late, but did rsync/zsync get mentioned at any point? just curious
<achiang> how does maemo/meego solve this problem? what is their app sandbox model?
<greyback> ogra_: sure. But for me dpkg has disadvantages that are pretty major for a phablet
<lool> dbarth: "requirements" in the pad
<dbarth> lool: sorry, checking
<ogra_> bfiller_, that will do fine as an interim, but cant be the answer, so the question is how much will we invest in throw away work
<Wellark> pitti_: well, if the rules are sane (like, don't install to /home) then there probably would not be that many problematic packages
<achiang> zebaszp: not relevant to this discussion, imho
<xnox> slangasek: pitti_: yes we do need for factory reset.
<xnox> "full image" to flash.
<achiang> zebaszp: or maybe it is relevant
<ogra_> greyback, but thats what we have atm
<xnox> or when the delta between .1 and .5 is missing.
<achiang> zebaszp: but we haven't talked about it yet ;)
<zebaszp> achiang, it could be useful when it comes to downloading updates (or updated package lists)
<zebaszp> I think arch does it with pacman?
<greyback> ogra_: I know. I want to throw out new ideas. I seriously think dpkg is a poor choice for applications on a phablet, so I would like alternatives to be considered
<xnox> pitti_: as long as the next system image has those security updates.
<ev> woooooooooooo
<zebaszp> well, it's knida late now the sessin is out of time, but I just thought I'd throw it out there :P
<zebaszp> *session
* udsbotu changed the topic of #ubuntu-uds-client-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1303/client-1/ - http://ubottu.com/uds-logs/%23ubuntu-uds-client-1.log
<xnox> ev: join us in Turing =)
<xnox> ev: or are you not in bluefin?!
<ev> xnox: is that where you are?
<ev> okay
<ev> I'm here
<ev> on my way
<ogra_> greyback, but you still want convergence ... apps need to be usable in both, desktop and phone ... and data needs to be accessible for both, and you dont want a ton of different rootfses for each of the possible convergence cases
<xnox> lool: yeah, like updates for usb-creator sticks with persistance enabled.
<lool> yeah
<greyback> ogra_: so perhaps we can innovate on the desktop :)
<dbarth> lool: the pad thing is completely broken for me
<xnox> slangasek: stgraber: me!
<ogra_> greyback, so apt has to stay, even if there grows a new format specifically for phone
<jodh> slangasek: I'm interested!
<lool> dbarth: open in a separate window, that works much better most of the time
<xnox> slangasek: you have the usual three.
<lool> you need to go through SSO on pad.u.c
<slangasek> :-)
<dbarth> lool: but i'd suggest listing the actions that users, image builders or the system (as the install procesS) can do
<xnox> stgraber:  ^
<greyback> ogra_: I know. apt is great for the lower level system,  I'm fine with it. But for apps, something else could be good
<kyleN> excellent.
<dbarth> lool: and write down the steps for each case; the scope and reqs will appear more clearly
<xnox> greyback: that will be discussed separately.
<ogra_> greyback, but that something doesnt exist yet
<stgraber> xnox: ok, I added your name to the blueprint
<ogra_> greyback, we need to work from what we have right now and we need to cover the convergence in the plan
<slangasek> xnox, jodh: yep, happy to have you guys working with stgraber on it - the question was more directed at the folks who were working on the phablet, because they probably have background on different pieces of this puzzle
<slangasek> and we want to make sure we're getting their input
<ogra_> we will definitely grow that knowledge too with the move to raring
<ogra_> (we have to)
<greyback> ogra_: right. Convergence can go both ways though. I just want to float the idea.
<stgraber> slangasek: I'll write something down later this week/next and share with the foundations mailing-list + Alex and Loic, as pretty much all of foundations showed interest ;)
<slangasek> stgraber: wasn't it ChickenCutlass I heard speak up, not achiang?
<slangasek> (since I was audio only, I didn't see whose lips moved on the video :)
<stgraber> slangasek: hmm, I thought it was achiang but I'm not completely sure.
<stgraber> achiang, ChickenCutlass: ^
<achiang> stgraber: it was ChickenCutlass, but i'd like to be involved too
<ogra_> greyback, no disagreement that phone apps will have to be handled differently than your general desktop app :)
<stgraber> achiang: ok
<ogra_> greyback, but we need to solve the basic probs first before looking into app space
<greyback> ogra_: understood
<ogra_> else we need to redesign all that stuff in a year
<MacSlow> hey hikiko
<MacSlow> hikiko, do you know the link to the hangout for this session? Or anybody else?
<Laney> D
<Laney> oops
<selena2013> all sessions link are in your schedule page
 * thomi waves
<TheMuso> Morning indeed.
<TheMuso> Its too early for breakfast yet. :p
* udsbotu changed the topic of #ubuntu-uds-client-1 to: Track: Client | Unity ui converged for all form factors | Url: http://summit.ubuntu.com/uds-1303/meeting/21679/client-1303-unity-ui-converged/
<mhall119|uds> hello guys
<mhall119|uds> yes, we can all see you :)
<tsdgeos_uds> is the feed lagging for anyone else?
<tsdgeos_uds> or is it just me?
<Saviq> can't connect to the hangout at all :/
<mmrazik> tsdgeos_uds: its certainly for me
<bschaefer> mine has stopped
<mhall119|uds> did you guys stop the broadcast?
<tsdgeos_uds> i guess tvoss wanted to say something not polite :D
<TheMuso> Ok it wasn't just me then.
<ogra_> mhall119|uds, session starts at 15 past
<Saviq> yay
 * tsdgeos_uds goes grab some cookies
<TheMuso> Lookes like the hangout stopped.
<krabador> yes
<ogra_> The it hasnt started
<mhall119> ogra_: ok, everybody will need to manually refresh the page once you put the new broadcast URL in the Summit form
<j-johan-edwards> Seems a pretty immense topic for 45m...
<tvoss> tsdgeos_uds, nope, I wanted to say that I appreciate the input
<mhall119> j-johan-edwards: this won't be the last of the conversations about it
<tsdgeos_uds> tvoss: ok :-)
<MacSlow> Saviq, where is the hangout link?
<mhall119> if you are marked as a "Required" participant, you will have to refresh to see the hangout link
<tsdgeos_uds> are we there yet?
<tsdgeos_uds> can't see the feed
<mhall119> tsdgeos_uds: you will when they turn on broadcast
<tsdgeos_uds> "An error occurred"
<mhall119> unless you get an error, is what I meant :)
<mhall119> in which case, refresh
<j-johan-edwards> okay, I see the hangout
<Saviq> MacSlow, toolbox, no need for effects
<seb128> tsdgeos_uds, http://youtu.be/bp9Kh3WxJj0 should work?
<tsdgeos_uds> ok, had to refresh the page
<cgregan_> dropped but back up
<kgunn> https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-ui-iteration-0
<kgunn> blueprint for unity next ui
<seb128> Saviq, muted you, you have some background noise
<Saviq> seb128, sure, will do manual
<guestman> Question: I tried to build phablet-mods branch. Is this the branch that is used for testing ?
<Saviq> guestman, yes, there's a build script that _should_ get you somewhere, but we're fixing the build scripts as we speak
<guestman> thanks Saviq
<mhall119|uds> Saviq: can you repeat that on the video please? It'll help people watching later
<Saviq> guestman, for now we need a custom build of (lib)unity
<guestman> Question: will you all be porting dconf-qt like it was for unity 2d
<guestman> qt5 ^^
<Saviq> mhall119|uds, yeah, will do, at least as part of summarizing the work items
<quesh> didrocks: the name is Unity next or Unity next gen ?
<mhall119|uds> for the record, I volunteered to publish the docs, not write them :)
<guestman> Question: On that note will all the older stuff from unity 2d be ported so hat we can use all the libs from before ?
<guestman> s|hat|that
<isantop> Unity Next sounds cooler.
<guestman> dee dconf-qt
<Saviq> mhall119|uds, ;)
<guestman> bamf
<bschaefer> don't need bamf anymore, mir handles that
<mhall119|uds> yay for application-aware display server!
<bschaefer> \0/
<mhall119|uds> QUESTION: Do we have a list of what needs to be ported that we can provide to community hackers?
<guestman> Question: where  can one find the qt lib or whatever it is called.   Ubuntu.appliacations so that I can test out on apps ?  seems like it is needed for alot of apps to work
<mterry_> guestman: http://developer.ubuntu.com/get-started/gomobile/
<guestman> not there ^^
<mhall119|uds> is that something that the SDK team provides?
<mhall119|uds> mterry_: I don't think we have it there
<mterry_> Sorry, I guess I thought you meant the Ubuntu componentss
<guestman> gallarey uses it
<guestman> every app that I compile is calling for it in JS functions
<mhall119|uds> mterry_: yeah, we have some of them, but not Ubuntu.Applications specifically
<j-johan-edwards> Question: Can desktop Unity behavior start merging into lp:phablet, or does the "form-factor aware" codepath still need to be worked out?
<diwic> QUESTION: how are standard apps such as gnome-control-center, gnome-settings-deamon etc related to all of this? Will they be replaced by qt equivalents?
<j-johan-edwards> (sorry to add to questions)
<gusch> gallery works on desktop
<gusch> it only prints a warning about the Ubuntu.Applications
<mhall119|uds> diwic: that's probably out of scope for this session
<guestman> Question: is the formfactors going to live on glib? just like Unity ?
<mhall119|uds> Saviq: does the current codebase currently support different form-factors?
<mhall119|uds> like desktop unity has a feature to switch, even if the different ones aren't implemented
<guestman> glib ^^
<isantop> Form-factors
<bschaefer> netbook?
<robert_ancell> guestman, will get to that next
<mhall119|uds> I know you won't be able to focus on desktop form-factor, but is the switching functionality there for other people who want to do it?
<robert_ancell> guestman, I'm not sure what you mean though?
<guestman> no robert_ancell  I think that he is asking that
<selena2013> so a regular user will log in to his/her account on any device right ?
<diwic> QUESTION: so it sounds like you're going to make huge changes to the desktop UI after october, i e, quite shortly before the 14.04 LTS release. That sounds bad from a quality standpoint?
<mhall119|uds> Saviq: is there any ETA on when that design work/switching functionality might be done?
<mhall119|uds> thanks
<guestman> like com.caonical.unity
<ricmm> Saviq: tvoss robert_ancell: whats the plan for transitioning our current phone/tablet session to using a proper session manager for startup/shutdown that works across all devices?
<ricmm> didier and I had a doubt on that
<ricmm> tvoss: I can track that if you need hands ;)
<krabador> Question: with the new announced video server transition, and unity directly connected with it, what we can expect from unity on 13.10 ?
<ricmm> kgunn: yea I added it
<diwic> krabador, there is no 13.10
<krabador> diwic, oh, great.
<krabador> yes :)
<selena2013> any device one account sounds fine to me
<snwh> so the phone/tablet UI development will "trickle down" to the desktop?
<guestman> Question: I tried to build of androidx11 have any of you got it to work for virtual machines ?
<mhall119|uds> QUESTION: Will developers be able to run local builds in a nested window or VM?
<robert_ancell> guestman, that sounds out of scope for unity
<mzanetti> mhall119|uds: local builds of what?
<mhall119|uds> mzanetti: of Unity Next
<mhall119|uds> previosly running local builds of Unity 3D required replacing hte running shell
<mhall119|uds> \o/
<thomi> that's awesome.
<diwic> QUESTION: are the hw requirements different for current Unity (3d) and unity-next?
<thomi> Having a separate window might help us run autopilot tests as well
<mhall119|uds> tvoss: yeah, but keep it simple :)
<mzanetti> thomi: yeah
<thomi>  \o/
<tvoss> mhall119|uds, yup :)
<veebers> thomi: :-)
<j-johan-edwards> I don't see the problem, currently Mir does an job displaying random boxes and stripes in /dev/tty1
<j-johan-edwards> (excellent job)
<TheMuso> I guess this is more a Mir questino, will Mir support LLVM Pipe?
<bschaefer> So is the current list for what needs porting to QML: Switcher?
<diwic> thanks for all the answers so far :-)
<fugue88> On assuming a GPU---do you assume a 3D GPU, or would one with only 2D accel work?
<TheMuso> Doesn't need to be answered in the hangout.
<gusch> LLVM Pipe is a good question
<selena2013> will i be able to install ubuntu touch to a regular android device ?
<mhall119|uds> selena2013: you already can
<mhall119|uds> selena2013: https://wiki.ubuntu.com/Touch/Devices
<krabador> Question (joke): Now , with qt, unity develop will copy things from kde?
<mzanetti> krabador: KDE developers are here :D
<mhall119|uds> krabador: if we do, I'm sure they'll let you know
<krabador> yes, sure :)
<gusch> krabador: KDE is moving more and more stuff to Qt, that will likely picked up
<mhall119|uds> QUESTION: Do we have a doc with a roadmap/milestones/things to do next that we can follow along and get people to help with?
<snwh> bouncy ball!
<mhall119|uds> Question: Do we have specs from the design team for the things that need to be ported?
<guestman> Question: do you all have public meetings/forum ?
<MacSlow> guestman, #ubuntu-unity might be your best starting point...
<mhall119|uds> there is #ubuntu-mir now too
<MacSlow> guestman, and the public mailing-list
<mhr3> with unity in qml there'll be great support for customization, right? are we going to officially support that capability?
<dednick> mhr3: what customisation?
<mhr3> yea, also like replacing launcher with something else
<mhall119|uds> ok, we're almost out of time, are there any more work items that need to be put in the pad?
<gusch> Saviq: customization - selective acticate/deactivate certain lenses
<mhr3> no connection, disregard my nick :)
<TheMuso> I wouldn't want that customization to make sure carriers don't screw with the phone shell.
<TheMuso> s/carriers/phone vendors/
 * kenvandine agrees with TheMuso
<diwic> TheMuso, couldn't that also mean that you can override/revert the customizations done by the carriers, too?
<TheMuso> diwic: Urm, I doubt it.
<diwic> ok
<TheMuso> But I don't know for sure, I haven't known of anybody being able to get rid of a vendor's android skin without replacing the ROM.
<Saviq> TheMuso, well, it's open source, can't really protect from that, if they really want to
<mhall119|uds> kgunn: I was cleaning up the work items to make it easier to copy/paste into the blueprint
<krabador> Question: Will Unity development contribute in some way, to improve the experience for "non official" ubuntu touch devices?
<cjohnston> mzanetti: are the tests running some where right now?
<bschaefer> Hows multi monitor going to be handled with the new unity? (One thing in mind are the pointer barriers that X provides atm).
<TheMuso> Saviq: This is true, but not allowing easy customizatino will make it harder for them.
<Saviq> TheMuso, not necessarily better for the users ;)
<kgunn> mhall119: np :)
<TheMuso> Saviq: Yeah I know.
<Saviq> TheMuso, 'cause they will still customize it, just make a worse job of it
<TheMuso> There is a good and a bad side to it.
<Saviq> it's not like these customizations are driven by the developers actually implementing them
<nonamejam> any plans for qml and quickly
<mmrazik> didrocks: I don't think thats the case for current autopilot tests (sleeps)
<mhall119|uds> nonamejam: I started a re-write of Quickly, and I do want to support QML apps, yes
<mmrazik> didrocks: we are using the eventually stuff and that is polling in 1s intervals
 * thomi agrees
<mmrazik> up to 10 seconds and then timeouts
<dednick> QUESTION: where are the autopilot tests for UnityNext (if there are any currently?). I can't see any in the tsts folder.
<nonamejam> mhall119|uds: sweet
<mhall119|uds> nonamejam: for now, QtCreator does a good job of getting you started with a QML app
<tsdgeos_uds> dednick: tests folder
<thomi> dednick: there are none yet - come to the autopilot session up next maybe :)
<guestman> why not just add "Quickly" to qtcreator ?  with virtual machines and the templets that are there allready ?
<dednick> thomi: sure :) planning to
<tsdgeos_uds> dednick: http://bazaar.launchpad.net/~unity-team/unity/phablet/files/head:/tests/
<guestman> thanks all v.nice
<mhall119|uds> this was a good session
<mhall119|uds> thanks guys for watching IRC :)
<Saviq> http://developer.ubuntu.com/get-started/gomobile/
<ptl> thankssss
* udsbotu changed the topic of #ubuntu-uds-client-1 to: Track: Foundations | Migrate from ConsoleKit to logind | Url: http://summit.ubuntu.com/uds-1303/meeting/21646/foundations-1303-consolekit-logind-migration/
<quesh> thanks
<mhall119|uds> guestman: that was the plan, I just didn't have time to pull it off yet
<quesh> bye
<thomi> o/
<krabador> hi to you all
<dednick> tsdgeos_uds: ah. thanks. need to get latest.
<guestman> mhall119|uds:  you know how to get a hold of me
<tvoss> o/
<guestman> great session
<kenvandine> tvoss, you're my inspiration :-D
<tvoss> kenvandine, awesome :D
<didrocks> lovely ;)
<xnox> hello =)
<seb128> xnox, hey
<seb128> xnox, joining us? ;-)
<xnox> seb128: I am, cjwatson is as well =)
<pitti_uds> I can haz hangout link?
<seb128> youtube: http://youtu.be/VTlPLZfJDVc
<cjwatson> I'll sit and listen for a bit, might join the hangout later
<seb128> hangout: https://plus.google.com/hangouts/_/3dad298411e4a7119dbe80e5f1b917f6bfdad8d9?authuser=0&hl=fr
<xnox> pitti_uds: https://plus.google.com/hangouts/_/3dad298411e4a7119dbe80e5f1b917f6bfdad8d9?authuser=0&hl=de in german for you =)
<xnox> https://plus.google.com/hangouts/_/3dad298411e4a7119dbe80e5f1b917f6bfdad8d9?authuser=0&hl=en in english for the rest of us
 * xnox was confused about french G+ from seb128 last time around.
<didrocks> xnox: come on!
<didrocks> the interface is easy
<didrocks> and the language is lovely :)
<ogra_> scary people
<zyga-uds2> hi everyone
<cjwatson> glad to know somebody's accent is worse than mine :)
 * ogra_ goes back to the foundations room
<zyga-uds2> you are
<zyga-uds2> there are two leeters in the url ;)
<zyga-uds2> letters
 * slangasek waves
<seb128> slangasek, hey, coming?
<pitti_uds> hey slangasek
<slangasek> I'm stuck in a different hangout again as videographer
<slangasek> this is a silly limitation :)
<seb128> slangasek, want me to invite your phone again?
 * lool is watching
<seb128> lool, want to come? https://plus.google.com/hangouts/_/3dad298411e4a7119dbe80e5f1b917f6bfdad8d9?authuser=0&hl=fr
<lool> ok
 * zebaszp waits impatienly
<slangasek> seb128: sure
<cjwatson> slangasek: since I seem to have stable G+ now, I guess next time I can share the foundations load
<slangasek> cjwatson: next time I think we should figure out how to have a "virtual camera crew" that aren't on the hook for participating in sessions :)
<cjwatson> That too
<robert_ancell> stgraber, your background looks like you have some fake mountain scene background :)
<zyga-uds2> feed is broken
<diwic> oh no
<barry> uh oh
<dedalus> brb?
 * mdeslaur kicks hangouts
<zebaszp> oh noes!
<seb128> should be back on
<zyga-uds2> back
<dedalus> ah, there we go
<zebaszp> yay! back!
<diwic> back
<mdeslaur> s/hangouts/hangups/
<seb128> I hate to leave/rejoin to be able to invite a phone
<zyga-uds2> woot, cool feature
<zebaszp> QUESTION: what about the rest of systemd? <flamewar>
<seb128> zebaszp, going to ignore that one :p
<zebaszp> seb128, almost intended to be ignored, even though I'd like to see us migrate to systemd
<zebaszp> </flamewar>
<seb128> zebaszp, not going to happen anytime soon
<seb128> migrating all the init scripts is tons of work and we have lot to get done this cycle
<seb128> which doesn't include changing the init system for not visible user benefit
<zebaszp> seb128, gotcha; anyhow, I doubt the community will stop pushing for this to happen, but let's keep the chat in topic
<seb128> right, different discussion
<seb128> it might happen
<seb128> but the focus for this year is to get a working phone image out
<seb128> and systemd is not a blocker for that
<pitti_uds> jodh: muting you because of typing noise
<zebaszp> fingers crossed for 16.04 :P
<zyga-uds2> for the typists: mute yourself please
<jodh> pitti_uds: thanks - I've now muted myself too :)
<TheMuso> pulse does have support for logind/systemd.
<TheMuso> Pulse has src/modules/module-systemd-login.c, so yeah a module for logind.
<mdeslaur> of course he said it shouldn't :)
<zyga-uds2> QUESTION: do you guys see a loosesystemd source tree that mainitains all the plumbing bits that don't pull in systemd entirely to ensure we don't get into a forced transition later
<zyga-uds2> lool: ^^
<asb_asb_asb> udev can be built out of the systemd tree
<asb_asb_asb> I believe Debian has packages that do this
<zyga-uds2> asb_asb_asb: yes but that's just now, what if that's removed tomorrow
<zyga-uds2> asb_asb_asb: and I mean more than just udev
<zyga-uds2> pitti_uds: ^^ (see QUESTION above if you can)
<asb_asb_asb> zyga-uds2: I've seen no indication that would be the case. Though if so, I guess eudev
<asb_asb_asb> though eudev has got off to a rocky start
<xnox> asb_asb_asb: there are no plans to package nor use eudev at this time in Debian nor by extension in Ubuntu.
<asb_asb_asb> xnox: indeed, why would there be? I'm just saying in some scary world where upstream goes crazy, eudev would be the new upstream
<slangasek> console-kit-dae          /usr/sbin/console-kit-daemo      440  2094012      436
<slangasek> srsly?  what kind of VSS usage is that?
<xnox> zyga-uds2: at the time, slangasek split the tree and it's not based on loosesystemd at the moment.
<slangasek> I haven't split any trees here
<xnox> asb_asb_asb: upstream did not go crazy yet, but eudev already is not source compatible without bringing anything useful for us to integrate.
<xnox> zyga-uds2: slangasek: sorry. Did not split, but package it in a way that only some of it ends up in debs.
<zyga-uds> xnox: I know that's going on right now
<zyga-uds> xnox: I wonder if as long as we use upstart (and that's not changing so far) can we ride this wave of systemd components that still work for us
<zyga-uds> xnox: before having to have to take action to really support them standalone better
<xnox> well that's what we are discussing at the moment =))))))
<asb_asb_asb_> regarding devtmpfs doing most of the work right now, Funtoo is currently looking at moving completely to mdev+devtmpfs
<dbarth> stgraber: is the notion of "atconsole" fixed with lxc / udev setup you're describing?
<asb_asb_asb_> main thing you miss out on is libudev
<cjwatson> That's pretty significant for us
<asb_asb_asb_> cjwatson: of course :)
<stgraber> dbarth: I didn't recheck atconsole with logind, my hope was that it'd at least be different from what we had with consolekit
<cjwatson> Rather, critical
<dbarth> ok
<slangasek> http://paste.ubuntu.com/5591297/
<olafura_> QUESTION: Does logind fix the bug in console-kit of taking 4 GiB in virtual memory?
<cjwatson> (I don't know, but) not sure the virt size is all that important - its actual resident size is tiny
<cjwatson> well, by comparison :)
<olafura_> cjwatson but it must have some side effect
<cjwatson> why must it?
<cjwatson> virt size is a terrible measure of a process' actual memory footprint - PSS is better, see https://wiki.ubuntu.com/Nexus7/MeasuringMemoryUsage
<cjwatson> not that reducing it is a bad thing, it's just not something that's worth spending much time on :)
<stgraber> downside of vUDS, people can show up at your place at random...
<robert_ancell> stgraber, heh, I had builders next door yesterday
<olafura_> cjwatson duly noted ;)
<cjwatson> (e.g. mmaping a giant file will increase your process' virt size, but doesn't have any meaningful effect on system memory use)
<seb128> xnox, is there any way you can crosscheck the packages that already have logind support in your grepping?
<seb128> xnox, some support both
<xnox> seb128: sure. adding as an action for myself.
<seb128> xnox, thanks
<TheMuso> As above, pulse does. Once systemd is in main, we can start building the module for pulse.
<slangasek> cjwatson: right, so IIRC a lot of what's getting measured in consolekit's memory usage are a bunch of large, multi-megabyte anonymous mappings with *no* perms set on them (read, write, or execute)
<slangasek> cjwatson: so the kernel happily sweeps those under the rug
<lool> CK did come up in the memory optimization efforts
<lool> we suspected it oculd be optimized
<lool> but if it's being replaced, it doesn't really matter
<jdstrand> slangasek: fyi, I have the ability to grep the archive. if someone gives me what to look for, I can get it to you. I'm sure others can do it too
<slangasek> jdstrand: sounds like xnox has already done it via the Debian archive
<jdstrand> ok
* udsbotu changed the topic of #ubuntu-uds-client-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1303/client-1/ - http://ubottu.com/uds-logs/%23ubuntu-uds-client-1.log
<cjwatson> lool: Yeah, the 1.7M PSS is more of a concern
<cjwatson> slangasek: I'd be concerned about relying solely on the Debian archive; it's no longer the case, but the consolekit patch in openssh was an Ubuntu-specific patch for a long time
<slangasek> ah
<cjwatson> (It still kind of is, but it's in the Debian source package and conditionally configured)
<slangasek> xnox: ^^ can you tell jdstrand what to grep for?
<jdstrand> xnox: just whenever. it will take a while to generate the results
