#ubuntu-uds-core-1 2013-11-19
<lool> asac: mind op-ing cjohnston?
<roadmr> hello!
<ogasawara> hi everyone :)
<ogasawara> I'm leading the Core 1 track
<zyga> hi
<ogasawara> are people here who will be participating in this first session?
<ogasawara> ie who needs the hangout url
<zyga> ogasawara: I think I will 
<ogasawara> zyga: https://plus.google.com/hangouts/_/72cpi1qqh03a30ophnekcd2si4?authuser=0&hl=en
<zyga> thanks
<sfeole> hey
<brendand> ogasawara, didn't sabdfl say we can join by clicking a button on the summit page? thanks for the link anyway
 * sergiusens wants a hangout link
<ogasawara> brendand: hrm, not that I'm aware
<rsalveti> sergiusens: https://plus.google.com/hangouts/_/72cpi1qqh03a30ophnekcd2si4?authuser=0&hl=en
<ara> sergiusens, https://plus.google.com/hangouts/_/72cpi1qqh03a30ophnekcd2si4?authuser=0&hl=en
<sergiusens> ty
<ogra_> moop
<asac> cjohnston: let me know iif its good
<brendand> i'll try that and if i can't then i'll join by the link
<zyga> ara: are you joining?
<brendand> once the session starts there is a big 'Join Hngout on Air' link
<brendand> (without the typo)
<ara> zyga, I am here, just not in the hangout :)
<asac> ChickenCutlass needs the HO url
<asac> L)
<ara> classic :)
<roadmr> https://plus.google.com/hangouts/_/72cpi1qqh03a30ophnekcd2si4?authuser=0&hl=en
<cwayne_> holy echo batman
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Touch hardware validation framework | Url: http://summit.ubuntu.com/uds-1311/meeting/22087/core-1311-touch-hardware-validation-framework/
<lool> what happens when one switches between apps with side stage?
<rsalveti> ChickenCutlass: https://docs.google.com/a/canonical.com/document/d/1ddNJTp7x9Jnra5akmpJkn-p7DBHp1S5APQ5ZiFM7zDY/edit#
<ChickenCutlass> rsalveti: great
<ogra_> that should really have been in the topic
<ChickenCutlass> right
<rsalveti> ogra_: it's in the blueprint
<rsalveti> the specification link
<ogra_> ah, k
<ara> sergiusens, let's add a work item for us to improve documentation on how to create new providers
<sergiusens> ara, sure
<spineau> such item already exists in the todo of https://blueprints.launchpad.net/checkbox/+spec/core-1311-checkbox-rebirth
<ogra_> ChickenCutlass, we have adbd in the initrd
<ChickenCutlass> ogra_: right ok
<ogra_> it starts automatically if it cant boot the rootfs
<ogra_> what we really need is a better proting guide and porting tools
<janimo> ogra_, +1 porting docs really need to be in better shape
<ogra_> janimo, i'd even say we should toolize as much as we can of the porting process
<janimo> ogra_, definitely
<ogra_> "run tool a, then tool b, then add these kernel patches and try to boot"
<rsalveti> +1 for both
<rsalveti> :-)
<zyga> ok, godo session!
<sergiusens> zyga, I'll be in touch (pun)
<zyga> sergiusens: so we should sync after UDS is done (or in some spot in between sessions)
<ogra_> /whois godo
<zyga> hehe
<ogra_> :)
<sergiusens> ogra_, don't be a peek
<zyga> sergiusens: I'll show you how to get started and how to play with this
<sergiusens> zyga, I guess I'll be more aware after the plainbox session :-)
<zyga> sergiusens: that will be more about packaging and transitions from checkbox-old
<zyga> sergiusens: setting things up and writing tests is _really_ easy and you won't be affected by that much
<zyga> sergiusens: (by the new packages that we push into ubuntu)
<sergiusens> zyga, yeah, the test writing part is going to be easy ;-)
<slangasek> ogasawara: so for the next hour, I need to be in this session - trade off rooms? :)
<ogasawara> slangasek: sure, works for me
<zyga> sergiusens: well the tests are interesting and hard, integrating them with plainbox is easy in comparison
<sergiusens> zyga, I have to agree :-)
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Ubuntu Touch bootsplash support from initrd to shell | Url: http://summit.ubuntu.com/uds-1311/meeting/22107/core-1311-early-boot-animation/
<slangasek> next session hangout: https://plus.google.com/hangouts/_/7acpjg77gbecup6lie1l78lut4
<cwayne_> in this session are we going to talk about the possibility of customized bootsplashes as well?
<cwayne_> i.e. for oem's
<zyga> sergiusens: join us in #checkbox though
<zyga> sergiusens: and get your test authors there too, we're going to help you all out
<zyga> ok, next session
<sergiusens> zyga, ack
<cwayne_> ogra_, i think it's an important piece of customization as well, OEM/Carriers might want to have their logo shown on boot...
<sergiusens> rsalveti, bootanim you mean?
<sergiusens> don't we need a mir guy here?
<sergiusens> rsalveti, I think alan_g was supposed to join
<slangasek> isn't that who joined the hangout a few minutes ago?
<slangasek> or do I have a phantom icon here?
<ogra_> no, thats him :)
<sergiusens> slangasek, that's him :-)
<sergiusens> ChickenCutlass, I didn't setup a session for that
<sergiusens> it was discussed last cycle, but it's still a work item
<ChickenCutlass> sergiusens: ok -- we can discuss it
<ogra_> sergiusens, you can take over my battery checking session
<ogra_> (on thu.)
<ogra_> seems we covered that bit already here
<sergiusens> ogra_,if you don't have more to discuss later; let's just get it ironed out today :-)
<ogra_> k
<sergiusens> rsalveti, yeah, would be good to have design here; just take the action to get me a name and I'll get the other stuff going
<cwayne_> can we be sure to keep customization in mind when designing this? i.e. have it look in XDG_DATA_DIRS or something so that we can override the boot animation in /custom
<sergiusens> cwayne_, the update part is in recovery though
<rsalveti> sergiusens: sure
<cwayne_> im saying just for the initial boot animation, not necessarily the update one
<sergiusens> cwayne_, oh; yeah, that's better :-)
<cwayne_> that's what i figured, i just wanted to make sure that it was part of the plan from the beginning :)
<cwayne_> figured it won't be hard
<rsalveti> yeah
<ogasawara> slangasek: switch back?  I figured you want to be in that Cgroup manager one
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-1/ - http://irclogs.ubuntu.com/2013/11/19/%23ubuntu-uds-core-1.html
<slangasek> ogasawara: yeah, happy to switch back
<ogasawara> slangasek: also, tomorrow at 19:05 is the "Planning the hardware enablement strategy for 14.04 LTS" which it looks like we both might want to attend.  do you have anyone else on your team who could lead the other "Ubuntu Touch for x86 emulator" session?
<xnox> hm, we have two emulator sessions, interesting (7pm on wednesday, 6pm on thursday)
<ogra_> one is x86 only
<ogra_> (or should be)
<ogra_> https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ubuntu-touch-for-x86
<ogra_> also a lot more thna just emulator stuff
<xnox> ogra_: yeah, i wonder if i'll be able to make the thursday session.
<xnox> ogra_: i might be on 3G connection.
<ogra_> should suffice for IRC at least
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Shipping plugins as Click packages | Url: http://summit.ubuntu.com/uds-1311/meeting/22115/core-1311-shipping-plugins-as-click/
<ogasawara> lool et al:  you still have a few mins, but when you're ready -> https://plus.google.com/hangouts/_/7acpjik1c25tdpu9cn9di3e6f4?authuser=0&hl=en
<lool> hey
<lool> ogasawara: thanks
<lool> jdstrand: https://plus.google.com/hangouts/_/7acpjik1c25tdpu9cn9di3e6f4?authuser=0&hl=en
<mdeslaur> am I needed in the fishbowl?
<jdstrand> thanks
<slangasek> ogasawara: yeah, bdmurray should have the access to run the other session tomorrow
<ogasawara> slangasek: awesome, thanks
<asac> o/
 * asac waits for stream
<ogasawara> rounding up the right people, give us all a sec
 * cwayne_ would like to add online accounts to the list of plugins we'd need in clicks
<tvoss_> lool, o/
<pmcgowan> cwayne_, +1
<zhangchao_UK> #ubuntu-uds-client-2
<kenvandine> online accounts plugins too
<dbarth> +1
<robruds_> lool: webapps!
<dbarth> robruds_: well, that's different i think
<cwayne_> we'd need this fixed i think for online-accounts: https://bugs.launchpad.net/ubuntu/+source/click/+bug/1245826
<udsbotu> Launchpad bug 1245826 in click (Ubuntu) "Allow applying a hook to multiple files" [Wishlist,Triaged]
<dbarth> ie, webapps may reuse the the container
<robruds_> dbarth: there will be some overlap between click webapps and click scopes/UOA accounts...
<robruds_> dbarth: the webapps are essentially just a browser plugin.
<ssweeny-uds> I'd like to see Friends plugins installable as click packages as well
<dbarth> whereas OA will need hooks
<lool> robruds_: these are already clickified!
<robruds_> lool: not in the desktop they're not!!!
<cwayne_> ssweeny-uds, what do you mean?
<robruds_> ssweeny-uds: that's probably a good idea
<cwayne_> what's a Friends plugin?
<ssweeny-uds> cwayne_: Friends (nee Gwibber). Only twitter and facebook plugins are installed on the phone
<dobey> cwayne_: presumably the online-accounts bits, and the friends-service plug-ins to parse the feeds
<robruds_> cwayne_: Friends plugins allow Friends to support new social media sites. They're basically just files within a python module
<cwayne_> ssweeny-uds, isn't that the same as online-account plugins?
<ssweeny-uds> cwayne_: no
<robruds_> cwayne_: highly correlated though
<cwayne_> ah, alright
<ssweeny-uds> cwayne_: o-a is auth. friends actually reads/writes to the streams
<cwayne_> ah
<cwayne_> ok
<cwayne_> i gotcha
<robruds_> cwayne_: friends plugins depend on o-a plugins 1:1, but they're implemented in different projects in different languages.
<cwayne_> robruds_, yeah, i understand now, thanks!
<cjwatson> cwayne_: Right, 1245826 is fairly straightforward and in my queue
<cjwatson> You'll have it for trusty
<cwayne_> wonderful, thank you
<cwayne_> cjwatson, will that include being able to pass entire dirs as well?
<cwayne_> a good example there is the qml-plugins dir for online-accounts
<cjwatson> I think you can do that right now
<cjwatson> You'll just get a symlink to the directory
<cwayne_> i tried and it complained that it was a directory..
<dbarth> cwayne_: what are you trying to do specifically?
<cjwatson> cwayne_: bug please
<cjwatson> (with details)
<cwayne_> cjwatson, ack, thanks
<cjwatson> we don't need to go into it here
<dbarth> we're discussing plans to have a hook to get new OA providers in click packages
<cwayne_> dbarth, make click hooks for online-accounts (well that's what i was doing)
<dbarth> ok
<dbarth> but then we feel that the plan is to use a special process, because we can't get that all automated for now
<tedg> lool, Location service will have to have a user space component to handle trust store anyway.
<tedg> lool, So there'll be user installed plugins as well.
<tvoss_> tedg, why is that?
<tvoss_> tedg, or do you refer to user space as in session?
<tedg> tvoss_, Yes, in the session.
<tedg> Sorry
<tedg> Wrong term :-)
<tvoss_> tedg, still: I don't see why a user would need to install a plugin to that specific location service
<tedg> tvoss_, A provider wants to charge $2 for the plugin.
<tedg> tvoss_, They want that to be per-user.
<tedg> tvoss_, Or perhaps Google wants you to login with your Google account to get data.
<tvoss_> tedg, hmmm ... google has got api keys to support that specific use-case for a reason I would think
<tvoss_> tedg, however, I do agree with per-user plugin installation in general
<tedg> tvoss_, Sure, theoretical example, not today.
 * tedg start using Foogle for theoretical services
<lool> is pad down for everyone or just me?
<ogra_> here too
<tedg> lool, Me aswell
<jdstrand> down for me too
 * ogra_ could imagine things like camera filters etc 
<ogra_> (as user plugins)
<tvoss_> lool, likewise
<tvoss_> lool, did you think about an app (say: foogle) wanting to install a complete, custom gstreamer pipeline
<tvoss_> lool, as opposed to only certain sinks or sources?
<lool> tvoss_: what do you mean wiht a pipeline?
<lool> like a plugin implementing a pipeline depending on elements?
<lool> a pipeline is usually a runtime object, not a plugin, but you can provide a factory object
<tvoss_> lool, yup, say a streaming media service having specific requirements for buffering or such things
<tvoss_> lool, yeah, that's what I'm referring to
<ogra_> android does that too ... i.e. mplayer or vlc for android have separate optimized codec packages
<tvoss_> lool, with that, apps can leverage existing service infrastructure in a more flexible way
<alecu> QUESTION: Do we really want app devels to be using weird codecs with little or no support for hardware accelerated decoding?
<ogra_> alecu, they can do that on other platforms
<alecu> ogra_: in other mobile platforms?
<ogra_> and if you ship i.e. some media player that makes use fo HW acceleration of the HW you actually want codecs for the specific device
<ogra_> yes, see what ii wrote above ... mplayer or vlc for android do that
<kenvandine> i've seen it on android
<ogra_> installing them will give you SW rendering by default
<ogra_> and you can boost them by installing the right codecs for your device
<ogra_> pad is back
<tvoss_> alecu, ogra_ the one thing we need to make sure is that installed codecs are "confined" to the app that installed them, avoiding the situation where installing an app destroys the default media experience
<tvoss_> lool, ^
 * ogra_ doesnt like that we solely talk about codecs
<ogra_> there are surely other plugins that would like to work close to the HW
<ogra_> i.e. imagine something that enhances the camera ...
<ogra_> (or any device in the phone/tablet actually ... camera filters that make use of HW directly just came to my mind first)
<alecu> ogra_: I agree that we need other examples besides codecs. I really don't think we should provide plugins if the only use case is providing plugins for vlc or mplayer
<alecu> ogra_: and
<alecu>  sorry
<ogra_> right ... i think there are a lot other opportunities ...
<ogra_> anything that might enhance the HW or driver directly
<lool> tvoss_: sorry, didn't follow everything and we moved on from codecs
<lool> tvoss_: codecs confined to the apps installing them >> right, apparently that's hard and might not be required, so we'd just have trusted codecs
<alecu> ogra_: regarding filters, that sounds like something that can be done with gpu shaders, I don't think it makes sense to let confined code running closer to hw drivers
<ogra_> alecu, well, i thought more about something like adding HDR support on the driver level etc
<alecu> ah, right
<alecu> ogra_: that
<alecu> sorry
<dobey> well, Qt provides plenty of APIs for doing stuff to imagesd
<ogra_> but camera only being an example here ... could be anything
<dobey> err, images
<ogra_> (equalizer talking directly to the audio driver ... )
<dobey> there's no reason someone couldn't write a "filter" for the camera app to add some weird effect, using qt
<ogra_> dobey, i mean enhancing the HW capabilities ...
<ogra_> or making use of specific ones we can not offer out of the box
<ogra_> HDR is nothing you can do in post processing
<alex-abreu> lool, there is a separate session sur desktop webapps as click on thursday
<ogra_> (or slow motion video (for which you need to raise the frame rate of the camera to get proper reults))
<dobey> ogra_: i'm not sure that's a general case issue though. it does make sense for a vendor to ship special filters or whatever that take advantage of hardware
<dobey> while other vendors might not ship it
<tedg> mdeslaur, Run an image compressor under valgrind.  See if any errors happen :-)
<ogra_> dobey, i dont care about vendors, my team is working on nexus images :)
<ogra_> (tell that to achiang :) )
<dbarth> lool: right
<dobey> ogra_: then put it in the stock image :)
<mdeslaur> tedg: yes, something like that
<ogra_> dobey, not if it bloats the stock image for all platforms
<tedg> lool, They're on the roadmap currently
<tedg> lool, The idea is that apps can provide custom data, and the visualizations for that data.
<tedg> beuno, No more database, now flat files
<dobey> ogra_: right, so it needs to be simple enough to add it. there's no reason an approved click package can't do something with hardware. it's just a matter of approval and writing the things that load plug-ins to do things right in the realm of ubuntu touch
<lool> tedg: https://plus.google.com/hangouts/_/72cpi1qqh03a30ophnekcd2si4?authuser=0&hl=en
<mdeslaur> tedg: we'll need to look at the confinement story around that
<ssweeny-uds> robruds_: can a friends plugin access data for an account other than the one it is called with?
<lool> tedg: is there a security design for this?
<jdstrand> yes
<tedg> mdeslaur, I'll forward you my proposal
<jdstrand> lool: no, not yet
 * mdeslaur cancels his email account
<jdstrand> tedg: can you send it to security@?
<ogra_> dobey, right, is that "approved click package" already defined ?
<tedg> jdstrand, Done
<jdstrand> thanks
<dobey> ogra_: i presume not since we're having the session to outline what we need, right now :)
<ogra_> dobey, right :)
<lool> any questions from IRC?
<lool> ogasawara: sorry forgot to warn you to stop the recording
<ogasawara> lool: no worries, I was following
<lool> great
<mdeslaur> thanks!
<pmcgowan> thanks
<cwayne_> thanks guys
<lool> tedg: Thanks for raising this visualization use case
<lool> this might actually be a real system wide plugin use case, since the greeter is for all users
<tedg> The visualizations are per-user.
<tedg> So I don't think it's system wide.
<cwayne_> it is called 'usermetrics' :)
<tedg> i.e. my fitbit data is just about me, and I might want it to look a particular way.
<ogasawara> ogra_: you've got time, but when you're ready -> https://plus.google.com/hangouts/_/7acpimlsp5j5angdmi9mtqd06s?authuser=0&hl=en
<lool> tedg: I mean there's only one greeter running
<lool> tedg: on e.g. the desktop
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Finish Ubuntu Touch developer mode including UI support | Url: http://summit.ubuntu.com/uds-1311/meeting/22106/core-1311-complete-developer-mode-integration/
<ogasawara> hrm, anyone else joining this next session?
 * ogra_ hopes so 
<ogra_> sergiusens, ^^^ ?
<ogra_> or rsalveti
<sergiusens> ogra_, sorry got distracted with racy tests :-)
<sarnold> I'll be listening / watching
<ogra_> hmm
<sergiusens> ogra_, give me a min to join
<ogra_> seb wanted to send one settings app guy over too
<rsalveti> will join the qt ubuntu x kubuntu one instead
<ogra_> oh, indeed
<ogasawara> ogra_: joining soon?
<ogra_> ogasawara, if i get an url
<ogasawara> ogra_: https://plus.google.com/hangouts/_/7acpimlsp5j5angdmi9mtqd06s?authuser=0&hl=en
<seb128> ogra_, I can IRC participate (knowing I'm not listening to that stream because I'm in another session)
<t1mp> I think a single "developer mode" option that does all the magic would be fine :)
<t1mp> QUESTION: would enabling developer mode switch on writable mode?
<t1mp> enabling developer mode would have to install gcc and a bunch of stuff needed to compile apps right?
<t1mp> s/apps/plugins
<doanac`> QUESTION: do we want SSH over RNDIS?
<doanac`> or just wifi
<ogra_> doanac`, add it to the pad
<t1mp> ogra_: do you want to have the questions in the pad? Or we just ask them here? (prefixed with QUESTION:)
<t1mp> adb only works when connected via a usb cable right? Or am I wrong? ssh can be used over wifi.
<ogra_> right
<sergiusens> t1mp, i'll bring them up
<t1mp> sergiusens: ok, thanks.
<ssweeny-uds> there are shell options you can pass to make adb shell behave more sanely, and it could be useful to wrap those up in a phablet shell command
<pbass> QUESTION: is this bug relevant to the discussion? https://bugs.launchpad.net/ubuntu-system-image/+bug/1192577
<udsbotu> Launchpad bug 1192577 in Ubuntu system image "Support for switching to system builder mode ... and back!" [Wishlist,Triaged]
<cwayne_> ssweeny-uds, imho a phablet-shell command should be ssh so that its got the right environment
<cwayne_> like attached to upstart, etc
<ssweeny-uds> cwayne_: good point. ssh is probably the better option overall
<t1mp> QUESTION: Did you consider supporting the possibility to have two ubuntu installations on one phone? One (stable) could be used for daily use, the other can be in developer mode with a writable image for testing new stuff
<t1mp> ^so, dual booting between two ubuntu installs
<ogra_> t1mp, once we have dual boot (in 15.10 or so :P)
<t1mp> :)
<ogra_> dual boot is wanted, but not in focus this cycle
<sarnold> running out of space doesn't seem like a big problem to me -- someone who is prepared to hit a button that says "I know what I'm doing" doesn't necessarily need _that_ much hand-holding, right?
<ogra_> sarnold, well, the system gety unusable at some point
<ogra_> *gets
<t1mp> QUESTION: How do you install build tools to compile (for example) C++ without enabling writeable mode?
<ogra_> you cant
<t1mp> ok. Just checking that I am not doing something stupid
<ogra_> you dont ;)
<cjwatson> compiling on device was only ever a stopgap
<doanac`> the issue sergiusens mentioned makes CI work really hard
<sarnold> cjwatson: won't we want to offer compile-on-device as part of our converged story?
<cjwatson> sarnold: no, we want to offer cross-building
<sarnold> cjwatson: that might work for e.g. rovio and so forth, but kind of hard to sell to a village in pakistan or india or africa
<cjwatson> eh, surely for most cases we want to be presenting qml/etc.
<cjwatson> and are you really asserting that people in villages will be developing apps *entirely* on device, without even an editor on another computer?
<sarnold> sure, but if we're positioning a converged device as a realistic computing device rather than just a media consumption device, we ought not prematurely close doors like "compile on device"  :)
<sarnold> cjwatson: yes.
<cjwatson> if you have an editor somewhere else, you can do cross-building there too, and it will probably work better than compile-on-device
<cjwatson> well, in that case it will need to be substantially more writeable than we have right now
<sarnold> cjwatson: thousands of awesome and incredible apps were developed entirely that way on e.g. hp48 calculators in 32KB RAM.
<cjwatson> or we need to build a chroot to do the building
<t1mp> cjwatson: if the phone is supposed to be able to replace a PC eventually, then we want to develop 100% on a device (with keyboard and screen attached)
<t1mp> cjwatson: yeah.. why not run the dev environment in a chroot?
<sarnold> people may want to upgrade from their netbooks ;) hehe
<cjwatson> t1mp: sure, that's possible
<cjwatson> I no longer think of that as really "compile-on-device", because there isn't a separate device at that point, it's just your environment.  but meh, semantics
<t1mp> QUESTION: could you provide a chroot image (that can be installed as a click package?) that has everything enabled that is needed for developing? would that work?
<sergiusens> t1mp, there's a session for that I think
<sergiusens> t1mp, but it doesn't go the path you propose
<t1mp> sergiusens: which session?
<cjwatson> it makes a lot more sense IMO to build chroots on the fly
<cjwatson> shipping chroot images means shipping gobloads of data already mirrored etc. in other ways, which is futile
<sergiusens> t1mp, http://summit.ubuntu.com/uds-1311/meeting/21991/core-1311-cross-compilation/
<cjwatson> and a pain to keep up to date
<sarnold> yeah, <3 sbuild for keeping all that stuff transparent from me :)
<t1mp> sergiusens: I think that is for compiling touch/arm stuff on desktop/i386
<cjwatson> t1mp: it winds up looking much the same, or should
<sergiusens> t1mp, that's why I said, not the path you want
<cjwatson> native building is effectively a degenerate subcase of cross-building
<t1mp> sergiusens, cjwatson probably my requirements for developer mode are not those of a "standard" app developer. I need more stuff to build and test the UI toolkit on device
<cjwatson> extra build-dependencies are boringly easy
<t1mp> cjwatson: my "problem" is that every time after installing a new image, I need to enable write-mode and re-install all build-deps.
<t1mp> cjwatson: nothing complicated, but I need to wait more before I can compile my stuff
<cjwatson> t1mp: we need to fix things as necessary so you can cross-build
<cjwatson> that is the path for (at least) 14.04
<t1mp> ok
<cjwatson> (as laid out in more detail at the client sprint, and in a session later this week)
<t1mp> still building on device is cool :)
<cjwatson> cross-building is cooler (once it works)
<cjwatson> :-)
<t1mp> once you have a phone that is faster than your laptop it is not cooler anymore ;)
<cjwatson> let me know when you do
<t1mp> unless you cross-compile for i386 from your phone :)
<t1mp> cjwatson: okay :)
<ogra_> ogasawara, i think you can stop recording
<ogasawara> ogra_: thanks, will do
<sarnold> how are you guys going to get an ssh authorized_Keys onto the device?
<ogra_> sarnold, we didnt really cover ssh much, i guess by default we'll still go with passwords ... up to you to copy keys in place
<sarnold> ogra_: eww. passwords. :)
<ogra_> (the key negotiation in the notes was for adb)
<sarnold> ogra_: I'd rather not have a few hundred thousand phones walking around with password-based authentication open to all..
<ogra_> sarnold, why would they be open to all ?
<ogra_> ssh wont start by default unless you enable the dev mode, adb neither
<sarnold> ogra_: will turning on developer mode turn on sshd by default?
<ogra_> i think we should have a separate switch for that
<sarnold> that'd make me feel better; someone who turns on developer mode _and_ sshd is much more likely to configure keys than someone who just clicks a button "hey developer mode sounds fun"  :)
<doanac`> could we have phablet-flash copy your .pub key over during provisioning?
<ogra_> doanac`, sure
<sarnold> doanac`: keen
<ogra_> can someone add that to the notes ? :)
<rsalveti> ogra_: lxc-console -nandroid already works with phablet upstream
<ogra_> so i dont forget about it
<rsalveti> ogra_: will be part of my next upload
 * ogra_ hugs rsalveti 
<ogra_> Ursinha, tell him he rocks !
<rsalveti> haha
<ogra_> (and give him a kiss)
<Ursinha> :)
<sarnold> thanks ogra_ :)
<ogra_> thanks for the valuable questions !
<ogra_> :)
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-1/ - http://irclogs.ubuntu.com/2013/11/19/%23ubuntu-uds-core-1.html
#ubuntu-uds-core-1 2013-11-20
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-1/ - http://irclogs.ubuntu.com/2013/11/20/%23ubuntu-uds-core-1.html
<spineau> Hello
<ogasawara> spineau: hi, assuming you'll be in the hangout -> https://plus.google.com/hangouts/_/7ecpjuqe1doh2dm5butsstsudo?authuser=0&hl=en
<ogasawara> spineau: no hurry though
<zyga> hi
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | CheckBox (based on PlainBox) in 14.04 | Url: http://summit.ubuntu.com/uds-1311/meeting/21988/core-1311-checkbox-rebirth/
<ogasawara> ara: fyi https://plus.google.com/hangouts/_/7ecpjuqe1doh2dm5butsstsudo?authuser=0&hl=en
<ara> ogasawara, thanks
<sfeole> hi
<roadmr> hello! could someone please share the hangout link with me?
<sfeole> roadmr: according to the url above it's : https://plus.google.com/hangouts/_/7ecpjuqe1doh2dm5butsstsudo?authuser=0&hl=en
<spineau> https://docs.google.com/drawings/d/1PayxVkGOICZXlaaq1Cln0FcMW2LfiJOF-jTmIm6x79Q/edit?usp=sharing
<roadmr> sfeole: thanks!
<sfeole> roadmr: the url in above the video
<sfeole> :)
<spineau> https://plainbox.readthedocs.org/en/latest/author/index.html
<zyga> woot
<zyga> great session spineau
<roadmr> \o/
<ara> ogasawara, feel free to end the broadcast
<ara> spineau, thanks for the session!
<ogasawara> ara: yep, done.  thanks
<spineau> great session thanks everyone
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: App Development | System framework for apps | Url: http://summit.ubuntu.com/uds-1311/meeting/22111/core-1311-app-framework/
<cjwatson> Hangout URL?
<KaleoF> same question
<dbarth> lool: ping? if you're running the hg, can you make sure to send me the link and to zaspire as well for the cordova aspects
<KaleoF> anybody listening? :)
<dbarth> lool: and alex-abreu as well obviously
<cjwatson> Hello?  The hangout URL should just be pasted into channel
<cjwatson> Who's running this session?
<lool> ??
<cjwatson> ogasawara,slangasek: ^-
<cjwatson> ?
<KaleoF> nobody is running it it seems :)
<lool> pmcgowan: are you running it?
<ogasawara> yeek, is there a core 1 now, I thought we only had a core 2 session this slot
<slangasek> ogasawara: someone stuck a non-core session in our track
<lool> KaleoF: I'm happy to lead the discussion
<cjwatson> ogasawara: it's on the appdev track but overflowing into a core "room"
<pmcgowan> lool, sorry which?
<pmcgowan> I am on another call
<ogasawara> ah, my bad then
<lool> pmcgowan: System framework for apps
<slangasek> ogasawara: can you run it?  I have upstart roadmap right now
<lool> KaleoF: let's take it
<ogasawara> https://plus.google.com/hangouts/_/76cpiq0bih9a1oa0r2ojicncv4?authuser=0&hl=en
<pmcgowan> lool, oh, sorry please carry o without me, I just logged the bp
<ogasawara> slangasek: yep, firing up now
<lool> KaleoF: joining?
<lool> asac: joining?
<lool> cjwatson: you joining?
<cjwatson> yes, just cleaning up from firefighting
<lool> sergiusens: you want to join?
<KaleoF> https://plus.google.com/hangouts/_/76cpiq0bih9a1oa0r2ojicncv4?authuser=0&hl=en
 * ogra_ is listening in
 * ogra_ remembers that asac had an opinion aboout frameworks and support cycle too 
<sergiusens> ogra_, yeah, that's what lool is saying without giving names ;-)
<ogra_> ah
<ogra_> heh
 * ogra_ is getting distracted by IRC pings
<lool> sergiusens: I did name asac!
<ogra_> sorry
<lool> err I have lost the hangout
<lool> did I do anything wrong?
<ogra_> i still see you
<sergiusens> ogra_, he dropped off for a bit :-)
<ogra_> ah
<ogra_> lool, i think asac said he wanted to be able to support forever
 * ogra_ doesnt see how thats tecnically possible ... but i know that was the desire
<lool> ogra_: right, I passed that on into the hangout
<ogra_> k
<lool> but I expected, this is not an universally shared opinion
<ogra_> yeah
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Explore ways in which we can make package builds faster | Url: http://summit.ubuntu.com/uds-1311/meeting/21971/make-it-possible-to-build-cmake-packages-with-ninja/
<ogasawara> https://plus.google.com/hangouts/_/7ecpj4qupqkej6sm9o4gmh48eo?authuser=0&hl=en
<ogasawara> there doesn't appear to be a blueprint for this next session
<satoris> The link should be live, please join. :)
<lool> which packages is thi sabout?
<nuclearbob> yes
<satoris> Any.
<doko> -fuse-ld=gold
<lool> So isn't that solved by cross-compilation on x86?
<lool> (the slowness of ARM)
<jtaylor> dpkg-buildflags
<doko> jtaylor, ?
<jtaylor> DEB_MAINT_LDFLAGS_APPEND or something
<jtaylor> assumes the package supports overriding them of course
<jtaylor> but those are few extreme cases
<jtaylor> doesn't it also go over the alternatives system?
<jtaylor> hm no it doesn't
<doko> jtaylor, maybe change the dpkg-buildflags default for LDFLAGS
<doko> or upload a changed binutils to a ppa and use that one for test builds
<jtaylor> for package build that should only be relevant if ccache is also enabled, normally compilation dwarfs the time spent in make
<doko> DEB_BUILD_OPTIONS=parallel=8
<jtaylor> there are examples for parsing it in the policy
<jtaylor> you can share the cache between buildd
<jtaylor> its useful for the stable CI tests, where the compiler doe not change often
<jtaylor> not for ubuntu+1 main archivee builds
<doko> jtaylor, sure? at least it's something which currently is not supported
<jtaylor> the manpage states it as supported to share cache
<jtaylor> never tried it
<jtaylor> its even more significant if autoreconf is used, thats even slower than configure
<doko> sure, then just start multiple buildds on one machine
<jtaylor> documentation builds are also mostly single process
<jtaylor> e.g. all the python doc builds
<jtaylor> can'T load on buildds be used to get a statistic?
<jtaylor> if only one job is run per buildd
<satoris> ogasawara: feel free to close down the stream now. Thanks.
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-1/ - http://irclogs.ubuntu.com/2013/11/20/%23ubuntu-uds-core-1.html
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Kernel Topics 14.04 | Url: http://summit.ubuntu.com/uds-1311/meeting/21990/core-1311-kernel/
<ogasawara> for anyone interested https://plus.google.com/hangouts/_/7ecpj63sbfnc04m21g2t72g88k?authuser=0&hl=en
<sforshee> ogasawara: fyi I've already closed bug #1247784. It's already enabled in trusty, the bug was just complaining about it not being enabled in the mainline builds.
<udsbotu> Ubuntu bug 1247784 in linux (Debian) "please enable CONFIG_RT2800USB_RT3573 in kernel 3.12" [Unknown,New] https://launchpad.net/bugs/1247784
<ogasawara> sforshee: awesome, thanks
<ogasawara> for any late joiners -> https://plus.google.com/hangouts/_/7ecpj63sbfnc04m21g2t72g88k?authuser=0&hl=en
<dannf> +1 no gray area. that's not necessarily a +1 for either version though.
<ogasawara> https://wiki.ubuntu.com/KernelTeam/Specs/TrustyKernelDeltaReview
<dannf> just makes it easier for me to talk to partners by saying "use this versin" or "we will make a decision at this time"
<dannf> (where "this time" is a specific date/milestone)
<bunubunu> show
<smb> minus probably the pieces of imsm as you (just for me ) said
<jtaylor> will enabling transparent anonymous huge pages by default be considered for 14.04?
<jtaylor> currently its only madvise
<sforshee> ext4 should be able to mount ext[23], right?
<apw> sforshee, yeah hsould be, and that is the point of the request
<infinity> sforshee: I like this theory.
<cking> sforshee, we need to benchmark it and see how well it performs
<infinity> I have lots of ext3 and ext2 around so...
 * cking up to check it out
<arges-uds> keep up the good work everybody
<arges-uds> : )
<jtaylor> :(
<cking> it's a wrap
<apw> jtaylor, hey sorry your Q had scrolled off the top of my window, so we missed it.  feel free to come over to #ubuntu-kernel and make a case -- we don't stand on ceremony much
<ogasawara> jtaylor: yeek, sorry we missed that
<ogasawara> jtaylor: ogasawara@sharkbay:~/ubuntu-trusty/debian.master/config$ grep -rn "TRANSPARENT_HUGEPAGE" *
<ogasawara> config.common.ubuntu:2170:CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
<ogasawara> config.common.ubuntu:6143:CONFIG_TRANSPARENT_HUGEPAGE=y
<ogasawara> jtaylor: ^^ although I'm seeing that enabled in trusty
<jtaylor> < moving to -kernel
<janimo> slangasek, hi, who is setting up the next hangout?
<slangasek> janimo: bdmurray is
<slangasek> for core1
<janimo> thanks
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Ubuntu Touch for x86 emulator | Url: http://summit.ubuntu.com/uds-1311/meeting/22116/core-1311-ubuntu-touch-for-x86/
<rsalveti> hangout link?
 * ogra_ twiddles thumbs
<bdmurray> ocsOBsEp4
<rsalveti> bdmurray: ? :-)
<ogra_> secret language
<bdmurray> http://youtu.be/4-ocsOBsEp4
<ogra_> keeps the NSA out
<ogra_> :)
<tvoss_> slangasek, can you join the go session on the hangout?
<rsalveti> right, I want the hangout one :-)
<ogra_> yeah
<rsalveti> but thanks anyway
<slangasek> tvoss_: hum, I'm running a separate call
<tvoss_> slangasek, okay
<sergiusens> tvoss_, was the go session moved btw?
<tvoss_> sergiusens, nope
<cjwatson> the hangout URL isn't super-secret (unlike previous UDSes), should just be pasted here
<rsalveti> sergiusens: that's in client-2
<slangasek> tvoss_: if doko is around (i.e., not currently having network problems), he should be there
<ogra_> sergiusens, don't go ... stay !
<bdmurray> https://plus.google.com/hangouts/_/7acpja7ujvguc5nn4l8il5e2c4?authuser=0&hl=en <- this one then?
<sergiusens> rsalveti, yeah, I'm just sad I have a conflict with this one now :-)
<rsalveti> sergiusens: yeah :-(
<cjwatson> ah, perfect
<sergiusens> whereas I originally didn't see the conflict
<sergiusens> so I was thinking one of these sessions was moved
<cjwatson> (mind you I might just watch the youtube stream for now)
<ogra_> janimo, ...
<ogra_> janimo, your session ... join the hangout
<rsalveti> bdmurray: thanks
<bdmurray> yep, sorry about that
<victorp> rsalveti: is it just question of flicking a compile flag or is there a more deep reason for it
<victorp> i.e. x86 = desktop version and not optimise for mobile or something
<achiang> is the streaming youtube broken for anyone else?
<tsdgeos_uds> victorp: thing is, you can flip a switch and get either opengl or opengles, but not sure what you get is co-installable
<victorp> achiang:wfm
<achiang> (or just me :-/)
<sarnold> achiang: wfm
<tsdgeos_uds> victorp: speaking Qt-wise
<victorp> tsdgeos_uds:fair enough
<tvoss_> cjwatson, can you come to the go on the client side session?
<rsalveti> victorp: yeah, that's why we only have gl for desktop and gles for armhf, just because it was the easier to support it
<tsdgeos_uds> QUESTION can you guys confirm that, only GLES for Mir? somehow Gerry told me today that EGL+OpenGL should workt oo
<tsdgeos_uds> on the desktop
<xnox> yeah, a few projects use EGL api provided by OpenGL. (there are code tutorials online on how to do that)
<xnox> (we do want GLES on the virtualbox / goldfish-emulators because GLES is accelerated)
<alf_> tsdgeos_uds: Mir internally uses GLES2 for compositing etc, but clients are free to use either desktop GL or ES 1.0/2.0
<tsdgeos_uds> alf_: ah, thanks :-)
<victorp> janimo:do we know for sure that x86 android BSP provide GLES vs GL?
<janimo> victorp, not sure what the emulator target provdes
<janimo> AOSP 4.4 is GLES 2.0 by default, so I do not think plain GL is suppored
<ogra_> since the emulator runs android i would expect it to be GLES
<victorp> no one from AMD or Intel in the room? :)
<ogra_> victorp, well, the mobile intel CPUs use PVR ... which means largely the same as maguro
<ogra_> (galaxy nexus)
<victorp> ogra_:good point
<ogra_> (or pandaboard ...)
<ogra_> and i would expect the emulator to emulate something along these lines ... so we shold be safe
<achiang> so if android/x86 supports GLES... how does that relate to the open question about GL vs GLES backend for Qt?
<achiang> janimo: rsalveti ogra_ ^^
<ogra_> achiang, Qt on the desktop uses GL
<ogra_> achiang, so there is an assumption that x86 == GL
<achiang> ogra_: yes, i understand that
<achiang> ogra_: but we want Qt + x86 + android to use GLES
<achiang> right?
<janimo> achiang, it means QT on x86 has to build for LES not GL s it does now
<ogra_> achiang, while the assumption for Qt in touch is Qt == GLES
<ogra_> achiang, we need QT on all arches to use GLES
<achiang> vs Qt + x86 + desktop == GL
<ogra_> there is no distinction
<achiang> ogra_: ok, i missed the session yesterday. what did upstream say to that yesterday?
<ogra_> no idea
<achiang> or not upstream, but folks like scottK
<ogra_> i had a session i ran that conflicted
<xnox> we want qt with whichever GL that is accelerated.
<victorp> rsalveti:is there an impact on libhybris
<ogra_> achiang, well, no matter what ScottK said, there are vendors using Qt that will expect GL ... i.e. Skype as an example
<xnox> most of the time it is GLES on armhf, and GL on intel.
<xnox> but
<janimo> achiang, it seemed it will be possible to build two sets of binaries for GL and GLES on x86
<xnox> atom itel, virtualbox/android, goldfish/qemu are GLES accerated.
<achiang> janimo: oh! ok, that solves our problems then
<ogra_> right, we will have to maintain a fork
<victorp> janimo: I think that is another one that would be good to build it and see what happends
<ogra_> to have both
<sergiusens> janimo, mute yourself :-)
<xnox> it would be nice, if unity8 could use EGL with OpenGL, for convergence with desktop later on.
<victorp> ogra - ah
<sergiusens> your auto mute isn't working
<victorp> ogra_ you dont think that upstream would have an interest on have Qt running on x86 android in the future?
<ogra_> victorp, not with hybris
<xnox> victorp: they have that now. but it's compile time option.
<ogra_> hybris is considered a hack by most upstreams
<victorp> xnox:right, so not really a fork
<ogra_> victorp, no, but our maintenance burden
<victorp> ogra_: or you meant a fork for hybris?
<ogra_> victorp, we will need two sets of binaries
<xnox> victorp: right, ti's just at the moment we will have duplicate binary packages, e.g. qt-gl qt-gles, etc.
<victorp> xnox:ack
<achiang> xnox: can we get that with the same source package/
<achiang> ?
<ogra_> and we need to maintain the second set
<ogra_> achiang, yes
<sarnold> hybris -felt- like a hack when I MIR reviewed it. I'd love to be rid of it.
<xnox> achiang: should be possible. more maintainance burden, but yes.
<achiang> ogra_: xnox: in the archive, or in a PPA somewhere?
<xnox> victorp: achiang: but further down the line, it doesn't look like GLES is comming to desktop (but one vendor)
<victorp> sarnold , realistically , we are very far from that
<ogra_> sarnold, wont happen though :)
<xnox> achiang: only in the archive.
<ogra_> achiang, in the archive indeed
<achiang> xnox: ok, that works for me,thanks
<janimo> xnox, maybe less main burden if we do not want to apply all fixes to two sets of sourcs?
<xnox> victorp: achiang: so one day we will need unity8 on top of OpenGL for normal powerful desktops/laptops.
<ogra_> why would we put something we need tio support officially in a PPA
<victorp> ogra_:so we dont think linhybris will be a problem porting to x86
<ogra_> xnox, only if Mir supports that :)
<victorp> rsalveti ^^
<achiang> ogra_: well my question (about archive) was another way of asking, "is 2 binary packages an official solution"
<xnox> can people assign some people to make mir/unity8 work on top of EGL powered by OpenGL ?
<rsalveti> victorp: nops, should work (and afaik it was already tested with x86)
<xnox> delaying that work, will only bite us later.
<ogra_> xnox, how hard would it be to build the android package for x86 too ?
<xnox> ogra_: i'll try that today.
<xnox> ogra_: should be ok, unless something is not ported, then I'll come back with build failures.
<ogra_> k
<xnox> ogra_: rsalveti: package supports dynamically additional targets =)
<rsalveti> xnox: right
<achiang> ogra_: do we need a WI for actually publishing stuff on cdimage?
<xnox> (it autogenerates install files et.al.)
<ogra_> achiang, nahg
<xnox> rsalveti: oh yeah, i want to do this with kitkat only =)
<janimo> achiang, ogra_ we need WI for anything that has to be done imho
<rsalveti> xnox: yeah
<achiang> xnox: mmm... :-/
<asac> rsalveti: you are right i think on not investing on 4.2 for x86. we want to focus on armel and do the x86 when brining up 4.4. in january or so
<asac> armhf:)
<victorp> rsalveti:that sounds reasonable, I guess x86 android support must have come a long way from 4.2 :)
<rsalveti> victorp: yeah
<rsalveti> asac: yup
<xnox> rsalveti: ogra_: do we want x86-virtualbox, or x86-goldfish, or both?
<ogra_> asac, well, depends how you look at it, android *is* armel ;)
<ogra_> rootfs is armhf
<asac> xnox: i assume goldfish if thats the thing that gives us SIM card emulation etc. :L)
<xnox> asac: correct. goldfish is the same emulator as currently demoed used with armhf.
<asac> ogra_: yeah i know... didnt replace... just add :)
<asac> just kidding
<ogra_> :)
<asac> xnox: right. i believe we want that
<xnox> asac: virtualbox is known to be much faster (native speed)
<asac> if it comes for free then i dont mind. otherwise, lets first get the "right" thing done :)
<xnox> rsalveti: asac: goldfish/x86 supposedly can do kvm speed.
<xnox> but that's unknown.
<rsalveti> right
<xnox> ok,
<asac> afaik google feels its super fast now
<xnox> if virtualbox is removed, then goldfish only.
<asac> so i wont worry too much :)
<xnox> rsalveti: ogra_: by the way goldfish i386 kernel is in the linux-goldfish already.
<ogra_> neat
<xnox> ..
<xnox> wow =) if gles finally comming to desktop, than that's great! But i don't think that's available on the desktop already.
<ogra_> it should be
<rsalveti> xnox: cool
<xnox> rsalveti: hm, we are building "cm_goldfish-eng" at the moment, and there is no "cm_goldfish-x86-eng" target, only the google's "full-eng" / "full_x86-eng". So some enabled needs to be done.
<xnox> at adding the device tree.
<rsalveti> xnox: did you check 4.4?
<xnox> janimo: =)
<xnox> rsalveti: ah, not yet.
<xnox> rsalveti: do we want to move to android's "full-eng" / "full_x86-eng" builds then?
<rsalveti> xnox: probably
<janimo> xnox, it is full-eng I thik indeed
<xnox> rsalveti: the cm_goldfish target was easier at the time.
<xnox> rsalveti: janimo: in that case I'll need to look into switching to that one.
<xnox> (needs products tweaks, et. al.)
<ogra_> bdmurray, you can stop the recording
<ogra_> thanks :)
<bdmurray> yep
<xnox> janimo: rsalveti: yeah best to move to #ubuntu-touch.
<xnox> =)
<tsdgeos_uds> thanks for the session guys
<psusi> crap, did I miss it?
<tsdgeos_uds> rsalveti: lol the "i need to follow up with the qt folks" was cut :D
<psusi> did yuo discuss the CONFIG_EXT[23]=n?
<ogra_> psusi, it think thats not actually x86 emulator specific
<ogra_> bring it up tomorrow, there is a general emulator session iirc
<psusi> ogra: eh?  has nothing to do with emulation?
<tyhicks> psusi: you're an hour late
<ogra_> psusi, though i think we actually want to keep ext2 for performance reasons (the loop  mounted images are a lot faster with that)
<tyhicks> psusi: the kernel topics session was an hour ago
<ogra_> oh, kernel ...
<psusi> ohh shoot
<rsalveti> we're only using ext4 now
<ogra_> rsalveti, sure ?
<xnox> psusi: CONFIG_EXT[23]=n definatly wrong session =) this was emulator for ubuntu touch on x86 session.
 * ogra_ hasnt checked ... i thought the initrd still uses ext2 
<psusi> yea, I'm trying to get the ext2/3 drivers disabled in the kernel... ext4 driver will handle those filesystems instead and do a better job of it and give a smaller kernel
<rsalveti> ogra_: oh, talking about rootfs, sorry
<ogra_> yeah, we dont care about that kernel :)
<psusi> ;)
<ogra_> ours are all android based
<ogra_> (who cares about desktops nowadays :P )
<rsalveti> problem is using rw when you have an ext2 fs :-)
<ogra_> yeah
<psusi> damn daylight savings... never can remember if I'm -4 or -5
<tyhicks> psusi: here's what you're looking for: http://www.youtube.com/watch?v=SrMTosj1Ikg#t=972
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-1/ - http://irclogs.ubuntu.com/2013/11/20/%23ubuntu-uds-core-1.html
 * fabio slaps alex-abreu around a bit with a large trout
#ubuntu-uds-core-1 2013-11-21
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-1/ - http://irclogs.ubuntu.com/2013/11/21/%23ubuntu-uds-core-1.html
<JohnC> hola de que se trata esto?
<Neo31> Hello, does the meeting start at 18:05 UTC ?
<fginther> good [morning|afternoon|evening|night]
<fginther> cjohnston, do you know who is running this track?
<ogasawara> fginther: hi, https://plus.google.com/hangouts/_/76cpirvjdcq5ofrvqvkmkqslps?authuser=0&hl=en
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Upstream Merger 2.0 | Url: http://summit.ubuntu.com/uds-1311/meeting/21983/core-1311-upstream-merger-20/
<fginther> ogasawara, thanks!
<fginther> cjohnston, Ursinha, want to join the hangout?
<Ursinha> fginther, sure
<cjohnston> not sure I need to
<fginther> https://plus.google.com/hangouts/_/76cpirvjdcq5ofrvqvkmkqslps?authuser=0&hl=en
<Ursinha> cjohnston, worst case you won't say a thing :)
<fginther> Saviq, want to join the hangout? https://plus.google.com/hangouts/_/76cpirvjdcq5ofrvqvkmkqslps?authuser=0&hl=en
 * tedg puts on his asbestos suit, let's rock!  :-)
<dobey> tedg: heh
<fginther> tedg, dobey, either of you want to join the hangout?
<fginther> https://plus.google.com/hangouts/_/76cpirvjdcq5ofrvqvkmkqslps?authuser=0&hl=en
<fginther> anyone else ^
<dobey> i can i guess
<tedg> fginther, Sure
 * tedg does his hair
<Ursinha> haha
<fginther> https://plus.google.com/hangouts/_/76cpirvjdcq5ofrvqvkmkqslps?authuser=0&hl=en
<josepht> lower thirds please :)
<sergiusens> tedg, we did have ddebs for most of the manhattan stuff
<tedg> sergiusens, Yeah, I know, I just want to ensure it's a feature into the future.
<cwayne> what is the timeframe for these changes?
<cwayne> awesome, thanks
<dobey> no lower third with no camera :)
<dobey> josepht: ^^ just saw your comment
<sergiusens> I have lots of questions, but they don't seem in scope
<sergiusens> how is the emulator going to solve the ci problems?
<fginther> sergiusens, ask anyway :-)
<sergiusens> is click testing tied to the emulator?
<cwayne> there is still going to be *some* actual hw testing right?
<cwayne> or will that just be sergiusens's papi testing?
<sergiusens> Saviq, we actually don't do that for clicks either
<tedg> Saviq, I've always viewed QML as a cry for help, nice to hear you say so too!  ;-)
<sergiusens> cwayne, lol, I cannot not laugh when reading papi testing
<dobey> heh
<cwayne> sergiusens, lol i know, i love it
<mzanetti> :D
<cwayne> but is that testing going to be the only hw testing now?
<cwayne> i mean, we do need some level of hw testing obviously, but i see where it would make more sense for apps to be tested on emulators
<dobey> there really should be no reason to test on actual hardware, for things that don't talk directly to hardware; for mir it makes sense, for a unity scope, not so much
<mzanetti> Saviq: well, you could probably hook into the JS engine and check read/write access of public properties
<mzanetti> tedg: in qml _every_ line is "executed" at startup
<tedg> mzanetti, Okay, I've got some recommendations for speeding up startup then :-)
<mzanetti> tedg: you need to read it to know when to creat it
<mzanetti> so you need to read the file at least once. and that's what happening - at the startup
<cwayne> dobey, right, i'm +1 ont hat, but just making sure we will still have some baremetal testing, even if it is just for mir for example
<tedg> mzanetti, You need to read the file, but you don't need to create objects based on it or parse deeper than "oh, I'll need this someday"
<mzanetti> Sarvatt: but that you can count
<mzanetti> Saviq: ^ - but sure it's really not trivial
<Saviq> mzanetti, yeah, for bindings, we'd have to see whether all the branches were executed
<mzanetti> tedg: well, depending on how you write it, they are not created. but still interpreted
<doanac`> real h/w testing will continue. we just want to find a better balance between that and virtualized to increase scalability and reliability.
<cwayne> +1 on that
<cwayne> i'd +more-than-1 if i could :)
<tedg> mzanetti, Makes sense, so code coverage would be when objects are created, not interpreted.
<sergiusens> fginther, click packages require ubuntu touch
<mzanetti> tedg: I'm thinking more about "used" instead of "created". but yeah, something along those lines
<fginther> sergiusens, wouldn't that work on a touch emulator?
<Ursinha> sergiusens, join the hangout? :)
<sergiusens> fginther, I suggest you try to run the emulator on the cloud now that it's there ;-)
<dobey> sergiusens: can you add the lower third?
<sergiusens> dobey, sure, should be automatic :-)
<fginther> ogasawara, you can close the hangout now
<ogasawara> thanks, will do
<doanac`> thanks fginther
<fginther> thanks all!
<cwayne> thanks guys!
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Low battery handling during boot | Url: http://summit.ubuntu.com/uds-1311/meeting/22108/core-1311-low-battery-boot-mode/
<ogasawara> https://plus.google.com/hangouts/_/7ecpi1hhd2cgo0j1h4c242ik7k?authuser=0&hl=en
<ogra_> lool, want to be in the fishbowl ?
<ogasawara> apw, lool, rsalveti: ^^ fyi
<rsalveti> joining in
<ogra_> https://plus.google.com/hangouts/_/7ecpi1hhd2cgo0j1h4c242ik7k?authuser=0&hl=en
<ogra_> sforshee, intrested in being in the fishbowl ?
<ricmm> im interested
<ricmm> to not talk
<ogra_> heh
<sforshee> ogra_: I'll jump in if needed
<sforshee> ogra_: I'm a bit under the weather, so if I don't have anything to contribute then there's no reason to make everyone watch me blowing my nose ;-)
<lool> heya
<lool> which is that
<ogra_> https://plus.google.com/hangouts/_/7ecpi1hhd2cgo0j1h4c242ik7k?authuser=0&hl=en
<sforshee> rsalveti: you don't want powerd, if anything upower
<sforshee> rsalveti: but the battery information is in /sys/class/power_supply
<sforshee> ogra_: the kernel provides the abstraction: /sys/class/power_supply
<sforshee> though some logic is needed to figure out the right place to get the battery status
<sforshee> let me join
<cking> the reliability of the data can be platform specific though
<ogra_> ChickenCutlass, https://plus.google.com/hangouts/_/7ecpi1hhd2cgo0j1h4c242ik7k?authuser=0&hl=en
 * cking notes that a 1% charge could be a long time on some large batteries 
<cking> some devices, 1% may be a very short time, so it may be device specific, e.g. 5 mins? 10 mins? 20 seconds? ;-)
<ogra_> http://pad.ubuntu.com/uds-1311-core-1311-low-battery-boot-mode
<jodh> ogra_: /etc/init/friendly-recovery.conf
<jodh> ogra_: we just need to change /usr/share/initramfs-tools/init to pass the custom startup event see last line of that file.
<jodh> ogra_: last 2 lines :)
<jodh> ogra_: subvert the boot if battery is low (as above). When battery level > some threshold, "initctl emit startup" to resume normal boot.
<ogra_> yeah
<jodh> np! :)
<ogra_> ogasawara, you can stop the recording
<ogra_> and thanks all, for coming !"
<ogasawara> ogra_: thanks, done.
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-1/ - http://irclogs.ubuntu.com/2013/11/21/%23ubuntu-uds-core-1.html
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Ubuntu Touch Emulator | Url: http://summit.ubuntu.com/uds-1311/meeting/22113/core-1311-touch-emulator/
 * rsalveti waves
<rsalveti> https://plus.google.com/hangouts/_/76cpiorbncb4s4j02ib1noi6is?authuser=0&hl=en it seems
<rsalveti> http://pad.ubuntu.com/uds-1311-core-1311-touch-emulator
<rsalveti> pmcgowan: ^
<rsalveti> is zoltan around?
<pmcgowan> rsalveti, he is but cannot joing the HO
<alecu> hola!
<rsalveti> we need someone from CI
<rsalveti> plars: ^?
<dkessel> is there already some preview version of the emulator?
<rsalveti> dkessel: yup
<rsalveti> dkessel: https://lists.launchpad.net/ubuntu-phone/msg05195.html
<dkessel> rsalveti, ah, a normal package... nice :)
<bzoltan> rsalveti: I do not join to the hangout because I am still mute
<pmcgowan> bzoltan, ping me if I need to hop on the session
<bzoltan> pmcgowan:  OK
<bzoltan> Yes
<bzoltan> rsalveti:  Yes,
<bzoltan> rsalveti: Yes, you start the emlator and it works with the QtC out of box
<ogra_> bzoltan, oh, it does already ?
<ogra_> thats cool
<bzoltan> rsalveti:  The emulator is just an adb device
<ogra_> (and fast ... for two days)
<bzoltan> ALL
<ogra_> :)
<bzoltan> rsalveti:  we backport to PQRS
<bzoltan> packaging is cool
<ogra_> ++
<Neo31> packaging yes
<janimo> it's cool unless the target is fast moving :)
<bzoltan> at the SDK team we move fast ...
<bzoltan> rsalveti:  we need to fix the adb port forwarding and small things
<bzoltan> +1
<bzoltan> yes
<bzoltan> it is a single line
<ogra_> whats wrong with ssh ?
<bzoltan> ogra_:  QtC uses adb
<bzoltan> No
<bzoltan> I need to fix the QtC scripts
<bzoltan> Yes
<bzoltan> It is QtC side
<bzoltan> :D
<bzoltan> there is a delay
<bzoltan> sorry
<ogra_> are we ? i thought we grab the tarball from scimge
<ogra_> *cdimage
<bzoltan> rsalveti:  may I have a minimal rootsrap to use as a builder? We have click chroot as main target... but a fully emulated native builder would be cool as fallback
<ogra_> bzoltan, that will be slow as hell
<bzoltan> rsalveti: or an R&D enabled image
<bzoltan> ogra_:  it is not that slow ...
<ogra_> bzoltan, qemu only emulates a 400MHz single core
<bzoltan> ogra_: I just have built the UITK in the emulator
<sergiusens> bzoltan, did you try building on the emulator?
<sergiusens> and thats faster that a qemu chroot?
<bzoltan> sergiusens:  I did not _TRY_
<bzoltan> sergiusens:  I did :)
<ogra_> bzoltan, if you want a qemu-system based emulator to build in there are way better options
<bzoltan> ogra_:  I know ...
<ogra_> (we have a qemu highbank option afaik ... )
<bzoltan> ogra_: I need to talk to you about it
<ogra_> sure
<ogra_> :)
<fginther> plars, has emulator on a VM (cloud) been discussed?
<plars> fginther: not yet
<plars> fginther: should be possible I would think, but it may be awfully slow
<fginther> plars, sergiusens expressed some concerns other then slowness in a prior session
<plars> fginther: I was going to ask about it, since I know it's something we want to do :)
<fginther> thx
<Saviq> Ctrl+F12 to rotate
<Saviq> ChickenCutlass, rsalveti, sergiusens â
<ChickenCutlass> Saviq, nice
<ChickenCutlass> ok
<ogra_> wow
<ogra_> that works really nicely
<Saviq> ogra_, didn't rotate the browser for me, though
<ogra_> well, still booting here
<ogra_> but i can rotate while it boots :)
<ogra_> lol
<ogra_> and comes up sideways
<Saviq> ogra_, see! it emulates real life ;)
<MacSlow> ogra_, Saviq: true real-world case :)
<ogra_> heh
<rsalveti> Saviq: awesome, need to give it a try
<Saviq> rsalveti, so it just looks like the sensor does not give up the rotation change
<Saviq> rsalveti, so just more hw enablement
<rsalveti> Saviq: right
<ogra_> yeah, browser is sideways here
<rsalveti> should be easy to fix :-)
<ogra_> i guess we need some sensor hook-up
<jdstrand> QUESTION: can we look into a snapshot option? it doesn't have to be complicated-- use qcow2 disk and add --snapshot and --revert options to run-emulator. this will allow developers to easily revert to a pristine snapshot, which is highly useful for testing
<ogra_> poer button doesnt work either etc ... i guess thats similar
<ogra_> jdstrand, only if that ancient qemu supports that ... and we dont have qcow images atm
<jdstrand> ancient qemu should support snaphost, but if not you could also use backing store
<jdstrand> s/snaphost/snapshot/
<asac> so feels if we do real driver testing we need a maas cloud
<Saviq> FYI: more keyboard shortcuts http://developer.android.com/tools/help/emulator.html#KeyMapping
<asac> so we can provision on bare metal etc.
<asac> or can we share drivers across multiple VMs?
<ogra_> what do you mean by drivers exactly ?
<jdstrand> technically, it could be opt in-- you could use qemu-img to convert to qcow2 after downloading the image
<asac> if we have servers with GPUs :)
<ogra_> oh, yeah, the server definitely needs the GPU
<asac> we could run them on bare metal and use GL properly... otherwise i assumed we would just run against software mesa
<ogra_> most likely even running X
<asac> etc.
<asac> in virtual... but might be too slow
<ogra_> or xvfb ... not sure that provides GL
<asac> right. but our current machines ... namely otto etc. are always busted
<asac> because we do raw GPU testing
<ogra_> then we need a dedicated machine
<asac> so we need maas to automatically recover rather then alwys do manual maintenance
<jdstrand> image snapshotting doesn't have to be complicated btw. people can get super clever-- only really need snapshot and revert to snapshot
<ogra_> desktop class machine ...
<asac> desktop is where the test machines always hang
<asac> because of GPU crashes
<asac> -> e.g. that should be maas with automatically reflashing machines with a safe iamge
<ogra_> asac, right, it wouldnt put any load on the GPU
<ogra_> but it needs something at the desktop end to hand through the GL
<ogra_> so you need some X server/Xvfb etc running
<asac> sure. X would run etc.
<asac> if we want to use pass through... still needs to be maased etc.
<asac> IT WILL MESS UP TIMEOUTS :)
<jdstrand> ogra_: what version of qemu is it based on?
<asac> and we should fix those
<asac> hehe
<ogra_> jdstrand, dunno, but likely older than your grandma ...
<ogra_> rsalveti knwos i think
<ogra_> 0.9 or some such ?
<jdstrand> I was doing backing stores with qemu a *long* time ago
<asac> i think the emulator is well usable ... even though pretty slow. the problem i see is just how i can do gestures. can we mayb hook the buttons up to various gestures?
<asac> like the home button gets the swipe to home?
<ChickenCutlass> asac, yes, that would be good.
<asac> rsalveti: ChickenCutlass: ^^
<doanac`> do we have a ppa from the emulator or is it just packaged for trusty?
<ogra_> asac, the buttons should go away
<asac> oh already answered
<sergiusens> I thought we'd remove all buttons :-P
<ogra_> ++
<asac> ogra_: we can use different images... doing a swipe is not very easy with mouse
<ogra_> well, we should keep power and volume
<asac> and especially in slowness for now
<ogra_> asac, works for me ... you need to be patient :)
 * Saviq just started a unity8 autopilot run
<asac> so having a button to do a full left/right/up/down swipe
<asac> would be good for productivity
<ChickenCutlass> ogra_, asac the performance is good for me.
<ogra_> yeah, same here
<ChickenCutlass> need to wait until the system settles
<asac> if it is triggered by emulator
<Saviq> please let's not hook into unity
<asac> it should come from hardware as a swipe at best :)
<Saviq> or well, at most through autopilot
<Saviq> UInputError: "/dev/uinput" does not exist or is not a character device file
<Saviq> plars, â when trying to run autopilot tests
<ogra_> Saviq, autopilot wont be there for devs (for their brandnew app they test)
<Saviq> ogra_, ap is seeded
<ogra_> sure
<ogra_> but if you are $random_dev you want to get your app done
<asac> yeah maas is a CI engine topic to explore
<asac> e.g. how to provisionm good worker nodes for the emulator
<jdstrand> I'm curious now
<MacSlow> Question: Will there be (command-line) switches to select a specific device to emulate (N4, N10 etc)?
<ogra_> MacSlow, lol, no
<jdstrand> I think I'll play with something (ridiculously rough) to see if we can do backing stores or snapshots
<ogra_> MacSlow, it is completely based on the goldfish qemu emulator from google
<MacSlow> ogra_, ok
<ogra_> MacSlow, to get other device emu, you would have to write a complete qemu machine that emulates that device
<ogra_> MacSlow, currently we are limited to a single core 400MHz CPU with 512M ram
<Saviq> ogra_, probably depends on what MacSlow meant to select a device
<Saviq> ogra_, one of the more important things is the resolution, which obviously would be available
<ogra_> we will enable different screen resolutions
<ogra_> that was discussed
<ogra_> but we cant easily emulate another HW
<asac> rsalveti: ChickenCutlass: also we want landscape/portrait mode
<Saviq> yeah, not sure what else is different between devices
<asac> is that something the emulator need to support?
<ChickenCutlass> asac, yup, already covered that
<MacSlow> ogra_, Saviq: well mostly default orientation and resolution... CPU/GPU not so much atm
<asac> ah ok
<asac> thanks
<Saviq> asac, Ctrl+F12
<ChickenCutlass> asac, already does
<ogra_> MacSlow, that will be supported
<MacSlow> ogra_, ok
<asac> ok. nice on accell and orientation
<ogra_> rsalveti, that was mostly about resolutions
<asac> is someone from sdk in the sessionm?
<bzoltan> _YES_
<ogra_> asac, bzoltan is here
<ogra_> (all the time)
<ogra_> :)
<asac> well. you cant see that in hyoutube
<bzoltan> I am listening
<asac> if you dont have a pic :)
<ogra_> he isnt in the hangout
<asac> would be nice to hear what the sdk vision is
<asac> though
<asac> anyway :)
<asac> yeah ok
<bzoltan> I am here!
<ogra_> was discussed above
<bzoltan> :)
<ogra_> read the backlog
<bzoltan> asac: I am temporarily mute
<asac> ok sorry
<Saviq> there's prior art on QtCreator + emulator
<asac> hard to catch up on a video stream :)
<Saviq> for MeeGo at least
<asac> and then match the irc backlog
<asac> hehe
<Ursinha> lol
<ogra_> asac, yeah, the important stuff happened in the IRC channel anyway
<bzoltan> Saviq:  I know... I was working on it :)
<ogra_> ignore the guys on youtube :P
<Saviq> bzoltan, good!
<ogra_> they just fill the pad over there
<bzoltan> ogra_: they should join here and stop the crap there :)
<ogra_> yeah
<bzoltan> good stuff
<Saviq> o/
<ogra_> ++
<MacSlow> Question: Regarding autopilot... ap-test passing on real hardware, but failing on the emulator will be considered an autopilot-binding bug on the emulator, right?!
<bzoltan> MacSlow: nomen est omen :)
<ogra_> MacSlow, they will have to be researched
<Saviq> MacSlow, rather a bug in the test
<rsalveti> emulator will be the first target
<ogra_> we cant just blame the emulator, we have to look at the reasoning etc
<rsalveti> can't fail in the emulator
<MacSlow> Saviq, really?
<rsalveti> can fail in devices, but still be critical
<Saviq> MacSlow, if something would fail on the emulator, but pass on devices
<Saviq> MacSlow, means it wouldn't pass on a high-load device either
<jdstrand> ah
<Saviq> MacSlow, 'cause that would just be timing-related
<jdstrand> version 0.12.0
<ogra_> jdstrand, oh, that new !
<Saviq> MacSlow, so you'll need to make the test more robust
<jdstrand> external/qemu/Changelog
 * ogra_ expected older actually 
<MacSlow> Saviq, ok... in that particular case (timing) I'd agree...
<ogra_> o would have put my bets on 0.8 or 0.9
<jdstrand> so, qemu-img still defaults to compat=0.10
<Saviq> MacSlow, any other reason - as ogra_ said, would need to be investigatesd
<Saviq> -s
<jdstrand> so I think we should be ok with at least backing store (which is usable)
<Saviq> MacSlow, but that should be really rare
<MacSlow> Saviq, I hope so
<rsalveti> jdstrand: cool
<MacSlow> I'm good
<Saviq> MacSlow, good thing is - Ubuntu in there doesn't even know it's running on an emulator
<jdstrand> so, let me play with this
<rsalveti> jdstrand: :D
<jdstrand> I can resurrect some old scripts and maybe hand them off
<Saviq> MacSlow, from our PoV it's just another device - albeit a slow one
<Saviq> summary time
<MacSlow> Saviq, ~4 times slower than a N10 I'd say
<jdstrand> oh, that was fast. /me found the scripts :)
<MacSlow> Saviq, ogra_: I'll give it a shot tomorrow
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-1/ - http://irclogs.ubuntu.com/2013/11/21/%23ubuntu-uds-core-1.html
#ubuntu-uds-core-1 2013-11-22
* ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-1/ - http://irclogs.ubuntu.com/2013/11/22/%23ubuntu-uds-core-1.html
<luatdolphin> hlep
<luatdolphin> object 12fd10c20115046dcd2fbe468a45e566f38ffbc9
<luatdolphin> type commit
<luatdolphin> tag v1.12.7
<luatdolphin> tagger Conley Owens <cco3@android.com> 1381959964 -0700
<luatdolphin> repo 1.12.7
<luatdolphin> gpg: WARNING: unsafe ownership on homedir `/home/luat/.repoconfig/gnupg'
<luatdolphin> gpg: Signature made Thá»© nÄm, 17 ThÃ¡ng mÆ°á»i NÄm 2013 04:46:04 using RSA key ID 692B382C
<luatdolphin> gpg: Can't check signature: public key not found
<luatdolphin> error: khÃ´ng thá» tháº©m tra tháº» `v1.12.7'
<luatdolphin> gpg: WARNING: unsafe ownership on homedir `/home/luat/.repoconfig/gnupg'
<luatdolphin> > gpg: Signature made Thá»© nÄm, 17 ThÃ¡ng mÆ°á»i NÄm 2013 04:46:04 using RSA key ID 692B382C
<luatdolphin> > gpg: Can't check signature: public key not found
<azeddinedje> hii
