[00:00] <silvarion> Leaving for today, thank you all and a late Happy New Year!!!
[00:33] <user82> will there be any ubuntu touch related action at ces this year?
[01:08] <thomi> charles: Are you around?
[02:04] <Jack> hello
[02:05] <Guest91875> is there anyone who can help me
[03:58] <singoc> h
[03:58] <singoc> hi
[06:52] <lucious77_> hi, anyone knows why in applications/installed section I can only see 9 apps? perhaps I should clean/flush some data? nexus 4
[08:00] <oSoMoN> good morning
[08:17] <dholbach> good morning
[08:18] <tvoss> mzanetti, ping
[08:18] <tvoss> dholbach, good morning :)
[08:19] <dholbach> hey tvoss
[08:19] <dholbach> how's life over there?
[08:19] <tvoss> dholbach, pretty good, thanks :) how about you?
[08:19] <dholbach> doing very well :)
[08:22] <pitti> dholbach, tvoss: guten Morgen, gesundes Neues!
[08:22] <dholbach> hey pitti - and the same to you :)
[08:23] <tvoss> pitti, Dir auch :)
[08:23] <tvoss> pitti, https://code.launchpad.net/~thomas-voss/qtubuntu-sensors/fix-accelerometer-and-orientation-sensor/+merge/200634
[08:24] <didrocks> gesundes Neues pitti, dholbach! :)
[08:24] <pitti> tvoss: ah, nice cleanup; that also drops the .symbols file (but still installs the lib, right?)
[08:25]  * dholbach hugs you all
[08:25] <pitti> hey didrocks, heureuse nouvelle année !
[08:25] <tvoss> pitti, it's not quite ready yet, will set it to in-progress
[08:25] <pitti> tvoss: that's a prereq for the cmake conversion?
[08:26] <tvoss> pitti, kind of :) I will fold the cmake transition in there. I just wanted to make sure we have a working baseline before we transition
[08:26] <tvoss> pitti, the lib is completely dropped and removed btw
[08:26] <pitti> neat
[08:26] <pitti> tvoss: so the platform-api sensor test branch hasn't been reviewed any more last year, I'll try to nag ricmm|sick once he's back
[08:26] <tvoss> pitti, ack
[08:30] <mzanetti> tvoss: pong
[08:53] <ubuntu-user> Hello world! How to install Ubuntu Touch to Sony Xperia E?
[09:01] <alf_> Hi! I am installing the latest touch image on a Nexus 10 (with Android 4.4.2). Installation seems to be complete, but I am prompted with "ROM may flash stock recovery on boot. Fix?" on the Nexus 10. Should I disable recovery flash, or is it this part of the installation process?
[09:16] <handydandy> has anybody successfully booted into Ubuntu touch on the e970 optimus G?
[09:22] <ubuntu-user> There are people who have successfully installed ubuntu touch os on Sony Xperia E? Tell me how.
[09:23] <ubuntu-user> Please!
[09:54] <chrisccoulson> if i call QGuiApplication::platformName() on ubuntu touch, what should I expect to get? (it's not going to be "xcb", is it?)
[10:09] <mandel> didrocks, I'm planning on adding a few new packages for ubuntu download manager related to the work of providing a client library, I would really appreciate if you can tell me, 1( is there ayone I have to talk to get them in universe. 2)take a look at the inline packging I've done (I'm not a packaging expert)
[10:09] <didrocks> mandel: is those new source packages or binary packages attached to an existing source package?
[10:10] <mandel> didrocks, new binary packages that are in the same tree
[10:11] <didrocks> mandel: ok, so for 1) it's just filing a new landing ask and I'll look at them (so 2)) once you will have filed it :)
[10:11] <didrocks> mandel: please just remind us in the landing ask that you included new binaries
[10:12] <mandel> didrocks, ok, I'll be adding them one by one to minimize the chance of breaking stuff, does that sound good?
[10:13] <didrocks> mandel: hum, if you have a transition to achieve, it's better to just add them all once ready
[10:15] <mandel> didrocks, ok, for me is the same because I have splitted the transition in several branches to minimize each of the reviews and tested them as independent units. I'm more concern of what is better for your side :)
[10:17] <didrocks> mandel: yeah, better to see the whole transition to ensure we don't miss anything for us :)
[10:17] <mandel> didrocks, ok, then I'll do that, thx for the info!
[10:17] <didrocks> yw! thanks for asking in advance :)
[10:44] <chrisccoulson> NM, I answered my own question in the end ;)
[11:01] <davmor2> Morning all
[11:02] <tvoss> pitti, refactored directory structure in https://code.launchpad.net/~thomas-voss/qtubuntu-sensors/fix-accelerometer-and-orientation-sensor/+merge/200634
[11:02] <tvoss> pitti, I will add the QtLocation plugin in there, too
[11:20] <user82> hi. any ubuntu touch related news this year at CES?
[11:21] <davmor2> user82: tune into CES and find out?
[11:24] <user82> davmor2, no real time for that. but is there a list which companies are present?
[11:25] <davmor2> user82: on the ces.org site I think
[11:26] <user82> ah found it. it was a little hidden
[11:26] <user82> nope, no canonical
[11:27] <ogra_> there are plenty canonical people running around there though ... just no booth
[13:23] <dholbach> tvoss, do you have any idea if anyone's looking at https://bugs.launchpad.net/platform-api/+bug/1261935?
[13:23] <tvoss> dholbach, there is a branch up that pitti did, iirc
[13:23] <dholbach> ah, it'd be great if that could be linked
[13:24] <pitti> ah, I wasn't aware of that bug
[13:25] <pitti> dholbach: I created https://code.launchpad.net/~pitti/platform-api/test-backend/+merge/198098 for adding a "simulated sensor" backend
[13:26] <dholbach> pitti, great
[13:26] <pitti> dholbach: updated the bug
[13:27] <dholbach> ricmm|sick, rsalveti: do you know who could take a look at https://code.launchpad.net/~bregma/qtubuntu/lp-1246851/+merge/198309?
[13:27]  * dholbach hugs pitti and tvoss
[13:27] <pitti> didrocks: can we please land autopilot-gtk? it's not on the actual touch images, but blocks ubiquity automated testing
[13:28] <rsalveti> dholbach: either ricmm|sick or loicm
[13:28] <dholbach> rsalveti, awesome, thanks
[13:28] <didrocks> pitti: sure, just put in the landing ask, but we have no-one able to land that right now (sil2100 isn't around, not sure why…), so the list is quite big. Tomorrow morning would be ok?
[13:29] <dholbach> loicm, ^ we were just talking about https://code.launchpad.net/~bregma/qtubuntu/lp-1246851/+merge/198309 and who could review it
[13:29] <pitti> didrocks: I still can't access the landing ask (which is why I was happier about using bugs)..
[13:29] <pitti> didrocks: yes, tomorrow is certainly sufficient
[13:29] <pitti> . o O { I could just dput the damn thing... }
[13:30] <didrocks> pitti: you should be :)
[13:30] <didrocks> pitti: able to add
[13:30] <didrocks> pitti: well, dput without running AP tests? ;)
[13:31] <pitti> didrocks: how do you mean? ap-gtk's AP tests are run during package builld
[13:31] <didrocks> pitti: you are lucky, it's not the case of all packages here ;)
[13:31] <pitti> didrocks: s/lucky/I did that work to ensure I don't break anything/ :-)
[13:31] <pitti> didrocks: it only changes a g_warning into a g_debug and adds a test case, i. e. no API changes or anything
[13:32] <pitti> didrocks: and the tests already ran in the MPs, too (for ARM coverage etc.)
[13:32] <didrocks> pitti: yeah, the thing is that if you dput, you have to merge back the changelog for further daily releases
[13:32] <asac> pitti: you can now access the landing pipeline
[13:33] <dholbach> charles, thanks a lot for merging the upstart-app-launch bits
[13:34] <pitti> didrocks, asac: so how does this work? I add myself to #235? is that FIFO, or can easy ones be fast-tracked?
[13:34] <didrocks> pitti: it's not FIFO is based on the comment and risk
[13:34] <didrocks> so it will be fast-tracket
[13:34] <didrocks> tracked*
[13:35] <asac> right. its a mix of reputation, risk etc. :)
[13:36] <pitti> didrocks: added; what should "status" be?
[13:36] <didrocks> pitti: you can add something like "ready to land" if it's all in trunk
[13:36] <loicm> dholbach: I'd prefer ricmm|sick to have a look at it since it's a packaging fix, not sure he's available though
[13:36] <pitti> didrocks: yes; is there ever a different case than "please upload current trunk"?
[13:36] <dholbach> loicm, ok, thanks
[13:37] <didrocks> pitti: yeah, people add it there even if it's not merged
[13:37] <asac> pitti: sometimes people try to land non-existant stuff, yes :)
[13:37] <didrocks> pitti: or even not tested
[13:37] <dholbach> charles, do you know if upstart-app-launch is scheduled to be landed on the image some time soon?
[13:37] <asac> land-my-dream-please
[13:37] <pitti> asac, didrocks: that doesn't sound useful
[13:37] <didrocks> pitti: it's clearly not…
[13:37] <pitti> asac, didrocks: anyway, thanks (and, FTR, ugh..)
[13:38] <asac> pitti: so one key reason why this spreadsheet is useful is taht its a clearing area where we work with the upstream folks to figure what they really need to land
[13:38] <asac> it might feel simple, but in practice if you are not a distro engineer it seems its not straight forward what it means to deliver a complete thing
[13:39] <asac> however, i think we succeeded in educating folks so those cases are less often now
[13:41] <didrocks> asac: for instance, if you look at the line just before yours, it's an example :p
[13:42] <didrocks> pitti: I meant for you ^
[13:43] <pitti> so that's to notify you that tvoss will soom propose his branch for merging, for early impact assessment?
[13:44] <pitti> that seems a bit overzealous from my POV, given that this doesn't need any coordination with other packages
[13:47] <didrocks> pitti: yeah, I don't think we need that information before the "it's ready" apart from the "very big impact change" (like incoming Mir)
[13:49] <asac> pitti: before getting too used to this old approach, check the mail and deck i sent to list earlier today :)
[13:50] <pitti> asac: to me, the old approach was to upload it :)
[13:50] <pitti> asac: ah, I followed the discussion with robru about moving to bugs in December, but I haven't seen your's from today
[13:50] <asac> you are getting old... thats the "ancient" approach :) ... lol
[13:59] <asac> tvoss: your "fix accelleration" branch is not ready for merging yet?
[14:00] <asac> or could we use that in theory as an example to play through the new landing appraoch?
[14:00] <tvoss> asac, we can land it
[14:00] <tvoss> pitti, I proposed it and Mirv already approved
[14:00] <tvoss> asac, ^
[14:00] <asac> didrocks: ^^ so we could try this one
[14:01] <asac> otherwise lets go for your trunk-cheat of system-settings.
[14:03] <didrocks> asac: well, qtubuntu-sensors has already something in
[14:04] <didrocks> trunk
[14:05] <tvoss> didrocks, ?
[14:05] <asac> didrocks: oh ic
[14:05] <didrocks> tvoss: trunk != package in distro
[14:05] <tvoss> didrocks, ah
[14:05] <asac> tvoss: we need something with trunk == distro ... for the sake of making an example
[14:05] <tvoss> asac, hmmm ...
[14:06] <Laney> translations make that hard
[14:07] <asac> didrocks: just the symbols commit?
[14:07] <asac> oh... seems tvoss merged his branch now
[14:07] <didrocks> asac: rev 41 and now 42
[14:07] <tvoss> asac, jenkins merged
[14:07] <Laney> otherwise: try ubuntu-wallpapers
[14:09] <didrocks> Laney: well, translations all over the place
[14:09] <didrocks> asac: automatic launchpad translations in trunk will be an issue I guess
[14:09] <Laney> yes, that's what I just said :-)
[14:09] <Laney> if you need really really equal it's tough
[14:09] <asac> didrocks: we probably want to work with fginther etc. to adjust the bot to only comment (and not merge)
[14:10] <asac> for the roll out
[14:10] <didrocks> asac: right, but that's not the translation thing :)
[14:10] <asac> didrocks: i dont understand the translation problem
[14:10] <didrocks> asac: well, look at system settings or ubuntu-wallpaper
[14:10] <asac> didrocks: does launchpad automatically commit directly to trunk?
[14:10] <didrocks> asac: yep
[14:11] <didrocks> in fact, you setup a branch for it to commit to (and take the translations)
[14:11]  * asac wonders who would want that :)
[14:11] <Laney> why wouldn't you?
[14:11] <asac> didrocks: right. so they could have a branch != trunk (like translation-submissions)
[14:11] <asac> Laney: dunno. you might not like the timing  :)
[14:11] <chrisccoulson> when is the qt5.2 stack likely to land in trusty?
[14:12] <dholbach> tvoss, seems like pitti's branch does not quite address bregma_'s problem: https://bugs.launchpad.net/platform-api/+bug/1261935
[14:12] <didrocks> asac: yeah, and so, the translation will never land
[14:12] <Laney> I can't really imagine translations getting in the way in reality
[14:12] <seb128> chrisccoulson, Mirv is working on it, they still have issue ... maybe ping him directly
[14:12] <asac> like you want to tag a release and suddenly your trunk gets flyushed with new stuff that invalidates part or all of your validation
[14:12] <chrisccoulson> seb128, thanks. Mirv? ^^ :)
[14:12] <seb128> asac, you really don't want to have to worry about translations, that's just the translators' job
[14:14] <didrocks> asac: the current system will just posptpone it until someone branch from trunk with a new branch anyway
[14:14] <didrocks> well current == new
[14:15] <asac> didrocks: i would think having translations auto submitted as MP might be the right answer
[14:15] <asac> but... :)
[14:15] <asac> let me know what you want to do
[14:16] <didrocks> asac: well, we can ignore it right now, it will just be "next time you land a branch based from trunk"
[14:16] <tvoss> dholbach, it solves the immediate problem, though.
[14:17] <tvoss> dholbach, I would propose that we open another bug that reads like: "Provide functional sensor backend for Desktop"
[14:17] <tvoss> bregma_, ^, fine with you?
[14:17] <dholbach> tvoss, bregma_: I'll leave you guys to it - I just wanted to bring it up as it was part of https://blueprints.launchpad.net/ubuntu/+spec/client-1404-unity8-on-desktop :)
[14:21] <bregma_> I already worked around the immediate problem and just opened the bug so the missing requirement did not get lost: if you want to repurpose the bug for something else and open a new one for the original problem, it's up to you
[14:23] <ricmm> dholbach: I'll review that one
[14:23] <ricmm> looks straightforward
[14:23]  * dholbach hugs ricmm
[14:23] <dholbach> thanks a bunch
[14:23] <dholbach> and happy new year :)
[14:33] <j-b> Any idea how to reset my N4 to factory after a fail install?
[14:49] <Zampson> Hey trying to sync contacts with syncevolution and I keep getting returned "transport problem: transport failed, retry period exceeded". Any thoughts?
[14:57] <Zampson> ok turns out I'm on a read-only image. Cancel that
[14:58] <ogra_> it should only write to the current users db
[14:58] <ogra_> (which is rw)
[14:59] <asac> didrocks: ok great if our system doesnt blow up because of accidential trnaslation landings
[14:59] <didrocks> asac: yeah, I have an idea even to represent it in the changelog
[14:59] <ogra_> we have accidential translations ?
[14:59] <didrocks> need to take a break and implement
[15:00] <asac> ogra_: yeah, seems that translations get auto injected by launchpad in trunks without peer/merge review
[15:01] <ogra_> injected ?
[15:01] <ogra_> i know they get extracted on package build
[15:02]  * ogra_ wasnt aware they also get injected
[15:05] <cwayne> mterry, ping, any update on welcome wizard? :)
[15:06] <cwayne> sforshee, ping, is powerd customizable in any way?
[15:06] <mterry> cwayne, not really.  A half-finished version has been very slowly being merged into system-settings trunk.  Cimi and I will continue working on it once it's in trunk.  Cimi, have you been working on any branches for it?
[15:07] <cwayne> mterry, ah, thanks.  still on track for 14.04?
[15:07] <mterry> cwayne, uh...  I hope so.
[15:08] <cwayne> me too
[15:08] <mterry> Cimi, how much time do you think you can allocate to wlecome wizard this cycle?
[15:08] <Cimi> mterry, as much as kgunn wants
[15:09] <kgunn> Cimi: mterry ...we're pretty close to done with "option2" as i recall ?
[15:09] <kgunn> i'd advocate landing that asap
[15:10] <sforshee> cwayne: I have an open merge request for controlling backlight stuff, but other than that not really
[15:12] <sforshee> cwayne: wait, are you thinking from a user preferences perspective or a porting perspective?
[15:12] <cwayne> sforshee, is that something that's on our roadmap at all?  the thinking here is a HW partner could come in and want different default settings/behaviors
[15:14] <sforshee> cwayne: well from the porting perspective there's a few things that powerd reads from an xml file that comes from android, so that specifies what device to use for the backlight, whether or not autobrightness is supported, the exact lux/brightness pairs for generating the autobrightness curve, and a few other things
[15:14] <mterry> Cimi, if you can spend time to close the wizard functionality gaps, it would be swell
[15:14] <mterry> Cimi, also
[15:14] <cwayne> sforshee, where does that xml file live?
[15:15] <mterry> Cimi, one thing that the current design doesn't take into account, but cwayne is really going to want is the ability to dynamically add pages into the flow (like OEMs can drop a qml file or two somewhere and have it be inserted).  We haven't worried about that too much yet, but maybe have that rattling around in your brain.  We'll need that eventually
[15:15] <sforshee> cwayne: for us in /usr/share/powerd/device_configs
[15:16] <sforshee> cwayne: the brightness control stuff is intended for unity to use to change user settings - {en,dis}able autobrightness, change brightness, stuff like that
[15:16] <mterry> ricmm, did that fixed libhybris ever land?
[15:16] <sforshee> cwayne: unity is supposed to take over the inactivity timeout from powerd, so that shouldn't need to be customizable within powerd
[15:16] <stgraber> rsalveti, xnox: does any of you plan on getting a new snapshot of android in the archive soonish? I pushed a dataloss fix 2-3 weeks ago that we probably want to pick up soonish.
[15:16] <stgraber> (the bug is basically that if you do a factory reset your whole system gets removed too)
[15:16] <sforshee> cwayne: those are the only things I can think of that would be configurable at all
[15:17] <cwayne> sforshee, what about stuff like default brightness, and time before screen turns itself off?
[15:17] <sforshee> cwayne: the former is in the xml file, the latter is what I meant when I said "inactivity timeout"
[15:18] <cwayne> sforshee, oops, i'd missed your last message, sorry about that
[15:19] <sforshee> cwayne: oops, the xml file doesn't say which device is the backlight, that's done via the HAL. It does specify the range of valid brightness values.
[15:20] <Cimi> mterry, I will to both
[15:20] <ricmm> mterry: I dont know
[15:20] <cwayne> sforshee, how invasive of a change would it be for powerd to take that from anywhere in XDG_DATA_DIRS instead of just /usr/share?
[15:20] <ricmm> rsalveti: did we ever get a umask patch in libhybris for shm access?
[15:21] <mterry> ricmm, did it land in trunk?
[15:21] <sforshee> cwayne: probably not too bad, but you'll need to talk to phonedations as they maintain powerd now
[15:21] <cwayne> pitti, hi, i seem to remember you setting up the /etc/writable stuff for all the timezone stuff, i'm looking to do something similar for /etc/machine-info (to set the pretty hostname to the adb device to get a sane default BT name), does this MR make sense? https://code.launchpad.net/~cwayne18/livecd-rootfs/machine-info-writable/+merge/200557
[15:21] <ricmm> mterry: just asked rsalveti, he will know better
[15:21] <cwayne> sforshee, ack, thanks for the pointer :)
[15:21] <ricmm> if not, we will land something asap
[15:21] <sforshee> cwayne: np
[15:23] <sforshee> cwayne: just to emphasize one point, powerd isn't using anything from the xml file that android doesn't also use, so any device which has been ported to android should already have an xml file that powerd can use
[15:26] <cwayne> sforshee, ah, that's a good point..
[15:30] <ricmm> dholbach: approved, will make sure it lands
[15:31] <dholbach> ricmm, that's awesome! :-D
[15:43] <xnox> stgraber: is current android de-bin-NEWed ? =)
[15:43] <xnox> stgraber: there is a package split in progress.
[15:46] <stgraber> xnox: ah, I'll take a look then
[15:48] <stgraber> xnox: accepted (though it's not a new git export so still won't have my fix...)
[15:52] <cwayne> dpm, hey, can we get a call to the community for those translations soon? :)
[15:52] <pitti> cwayne: what is /etc/machine-info? does that only exist on touch?
[15:52] <pitti> cwayne: oh, from hostnamed
[15:53] <cwayne> pitti, yeah, i'm not sure where else it's used, but its used by hostnamed to hold the PRETTY_HOSTNAME
[15:53] <xnox> stgraber: well all i cared about is deNEWing and this was a convenient way to trick you into doing it ;-) i'm not in touch with android package landing ETA. I was under impression that switch to 4.4 branches is eminent, but maybe that isn't the case and still "in-progress".
[15:54] <pitti> cwayne: did you test hostnamectl with that symlink? I had to patch timedated for the localtime symlinks
[15:54] <dpm> cwayne, now that I'm back, indeed! I'll put aside some time tomorrow morning to check everything out and put together a call for translations in the afternoon
[15:54] <cwayne> dpm, great!  i'll do another round of testing now that we've fixed a bunch of stuff since i last did it :)
[15:54] <cwayne> pitti, hm, i'll try it out now
[15:55] <pitti> cwayne: I followed up to the MP
[15:55] <dpm> cwayne, sounds great, thanks!
[15:58] <rsalveti> stgraber: we can upload a new package today if you need
[15:58] <rsalveti> we don't have anything pending, so feel free to grab the latest exported tarball
[16:00] <cwayne> pitti, thanks, seems it doesn't quite work, hadn't thought of that
[16:00] <pitti> cwayne: unfortunately this symlinking stuff is a ridiculous hack, to get along with the hack that readonly-root is :(
[16:01] <pitti> cwayne: ISTR that you need to change three places; hostnamed itself, then what you did for livecd-rootfs, and something else
[16:01] <cwayne> pitti, yeah, i was doing it this way to avoid having to patch too much stuff, perhaps i should just go a different way :)
[16:02] <pitti> cwayne: ah, I think the third was some  generic change to whatever provides teh "writable paths", so you don't need to touch that
[16:03] <cwayne> right, lxc-android-config
[16:03] <pitti> ah, that was it
[16:03] <cwayne> yeah.. do you happen to remember the change you did to timedated?
[16:04] <pitti> cwayne: I was thinking about http://launchpadlibrarian.net/151914519/lxc-android-config_0.103_0.104.diff.gz
[16:04] <pitti> cwayne: yes, they are in debian/patches/support-phablet-etc-writable.patch
[16:05] <pitti> cwayne: you can probably just copy&paste writable_filename() and use it in all places that access /etc/hostname-info
[16:05] <cwayne> yeah, i remember the lxc-android-config MP, i did it this way just to piggyback on that change :)
[16:05] <rsalveti> ricmm: no, afaik you were testing a better approach first
[16:06] <rsalveti> ricmm: if not, we can try to get something in place
[16:08] <ricmm> rsalveti: ok I dont have a better approach in mind atm, I'd say just umask down/up when creating that shm file
[16:20] <rsalveti> ricmm: kind of scary, but yeah
[17:11] <cwayne> is there an upstart job that runs only on first boot?
[17:15] <kenvandine> Saviq, you had marked bug 1241185 as fixed, but i'm not convinced that commit really fixed that bug
[17:15] <kenvandine> the bug was about not hard coding apps that get exceptions
[17:15] <Saviq> kenvandine, right, I did an automagic mark as the bot did mark it fix committed before
[17:15] <kenvandine> we should have a way to give panpipe a lifecycle exception
[17:16] <kenvandine> Saviq, so we still can't do that right?
[17:17] <m-b-o> balloons: ping
[17:17] <balloons> m-b-o, pong
[17:17] <Saviq> kenvandine, indeed we can't, and I'm not sure where such an exception should live, AFAIK we don't really want to give out such exceptions
[17:17] <Saviq> kenvandine, what's panpipe?
[17:17] <kenvandine> pandora app
[17:17] <kenvandine> so plays music
[17:17] <kenvandine> we should have a way for an app to request an exception
[17:17] <Saviq> kenvandine, right, for that ideally it would use the media service
[17:18] <Saviq> kenvandine, tvoss ↑↑ fight!
[17:18] <cwayne> seb128, is there any plans in system-settings to allow the user to change the bluetooth device name?
[17:18] <kenvandine> we just need some solution :)
[17:18]  * kenvandine re-opens bug... you guys can move it to another project if needed
[17:18] <j-b> \o/ Finally DualBooted
[17:18] <Saviq> kenvandine, so for music playback, if possible, it should use the (to be) media service
[17:18] <tvoss> j-b, hey here, sounds like success :)
[17:19] <seb128> cwayne, it's not in the design (https://wiki.ubuntu.com/Bluetooth#phone)
[17:19] <kenvandine> Saviq, is that something it could use now?
[17:19] <j-b> tvoss: I had encrypted my phone, so it was a complete mess
[17:19] <Saviq> kenvandine, not yet
[17:19] <cwayne> seb128, good enough for me, thanks
[17:19] <tvoss> kenvandine, nope
[17:19] <seb128> cwayne, yw
[17:19] <Saviq> kenvandine, but anyway - when it can't (DRM / ToS / whatever) that's what we don't have a solution for yet
[17:19] <kenvandine> tvoss, Saviq: can one of you comment on that bug explaining that?
[17:20] <tvoss> kenvandine, sure
[17:20] <kenvandine> just so the developer knows what the right solution is, even if it isn't doable now
[17:20] <Saviq> kenvandine, reopened it for unity-mir, can't for unity-mir (ubuntu)
[17:20] <kenvandine> he'll understand
[17:20] <kenvandine> Saviq, i did the ubuntu bug
[17:20] <Saviq> kenvandine, cheers
[17:20] <kenvandine> thx guys
[17:20] <m-b-o> balloons: do I have to need autopilot > 1.4 for testing?
[17:21] <Saviq> tvoss, on that note, you pang yesterday, and never followed up?
[17:21] <balloons> m-b-o, as a depends or ? Yes, ap 1.4
[17:21] <m-b-o> balloons: Cannot get it to run on saucy
[17:21] <tvoss> Saviq, hang on, quickly finishing the reply to the bug report
[17:21] <balloons> m-b-o, using autopilot 1.4x?
[17:22] <Saviq> tvoss, no worries, I'm EOD really anyway...
[17:22] <m-b-o> balloon: from the autopilot ppa, yes
[17:24] <m-b-o> balloons: by installing python-autopilot from ppa:autopilot/ppa there's a conflict
[17:24] <popey> kenvandine: we have about 5 music apps which could benefit from this. Way to go blazing a trail dude! :D
[17:25] <kenvandine> :)
[17:25] <m-b-o> balloons: wants libautopilot-qt (>= 1.4), but only 1.3+13.10.20130814bzr70saucy0 is available
[17:25] <kenvandine> i really want panpipe to be usable... pandora is something i used everyday on android... i really miss it now
[17:25] <kenvandine> it works great... until it suspends :)
[17:25] <kenvandine> so basically useless :)
[17:28] <cwayne> kenvandine, just write an autopilot test that loops around and clicks random stuff indefinitely so it doesn't suspend :P
[17:28] <kenvandine> haha
[17:30] <popey> or make the app shell out to "service stop powerd" ☻
[17:30] <popey> (don't do that)
[17:30] <balloons_> m-b-o, sorry timed out
[17:32] <m-b-o> balloons: libautopilot-qt >=1.4 is missing in saucy, when installing python-autopilot from the ppa
[17:34] <balloons_> m-b-o, kk, let me look
[17:34] <balloons_> m-b-o, indeed you are correct, heh
[17:36] <balloons> m-b-o, so anyways, let's just file a bug to get it fixed. if you need to get it corrected now, let me link you to the deb
[17:37] <balloons> http://mirrors.kernel.org/ubuntu/pool/universe/a/autopilot-qt/libautopilot-qt_1.4+14.04.20131106.1-0ubuntu1_amd64.deb
[17:37] <balloons> m-b-o, ^^
[17:41] <m-b-o> balloons: great, thank you! now it works again :)
[17:44] <m-b-o> balloons: https://bugs.launchpad.net/autopilot-qt/+bug/1266864
[18:07] <cwayne> cyphermox, hiya, any chance for a quick MR? https://code.launchpad.net/~cwayne18/ubuntu/trusty/bluetooth-touch/bluetooth-touch_lp1266859/+merge/200699
[18:15] <cyphermox> cwayne: thanks, testing now
[18:18] <heathbar> Hi Ubuntu-Touch Gurus... Where can I checkout the code for the system camera app?
[18:20] <cwayne> heathbar, bzr branch lp:camera-app
[18:28] <balloons> so, http://humpolec.ubuntu.com/latest/dualboot.sh is missing, and is referred to by https://wiki.ubuntu.com/Touch/DualBootInstallation
[18:29] <mhall119> kenvandine: ping Re: ContentHub
[18:33] <kenvandine> hey mhall119
[18:37] <mhall119> hey kenvandine, I was wondering if there would be a "capture from camera" option via ContentHub, rather than just picking an existing image from the Gallery
[18:40] <kenvandine> that would require the camera-app to add an export handler
[18:40] <kenvandine> so it's picker would really just be taking a picture and storing returning the image to the requesting app
[18:46] <mhall119> who's the main dev for camera-app?
[18:46] <rickspencer3> mhall119, probably ask bfiller_afk ;)
[18:46] <mhall119> kenvandine: and how do apps register themselves as handlers?
[18:46] <daker> heathbar: https://bazaar.launchpad.net/~phablet-team/camera-app/trunk/files
[18:47] <kenvandine> would need to implement an ImportExportHandler class
[18:47] <kenvandine> from libcontent-hub
[18:48] <kenvandine> mhall119, which provides a handle_export method and provides the picker, which would really just change what it does with the resulting image
[18:48] <mhall119> kenvandine: so, let's say I'm a 3rd party app developer writing a QML app that manages Foo content, how do I let other apps request a Foo from my app?
[18:48] <mhall119> all of that deployed via a click package
[18:49] <kenvandine> you'd implement the handler and add the json file to your click package
[18:49] <kenvandine> that the click hook would use to register the source
[18:50] <mhall119> can I implement the handler in QML/Javascript? and can I do everything from within my /opt/click.ubuntu.com/blah folder?
[18:50] <kenvandine> yes
[18:50] <mhall119> ah, there's a click hook, that's the part I was missing
[18:50] <mhall119> now, dare I ask, where is that click hook documented?
[18:50] <kenvandine> i thought it was on d.u.c :)
[18:51] <kenvandine> but i could be wrong
[18:51] <mhall119> not on http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Content/ that I see
[18:51] <kenvandine> you can look at this for an example: lp:~ken-vandine/+junk/hub-exporter
[18:52] <kenvandine> mhall119, ok, i'll make sure that gets added
[18:52] <mhall119> thanks kenvandine
[18:53] <mhall119> should also probably mention the content_exchange/content_exchange_source AppArmor policies that will be needed
[18:53] <kenvandine> indeed
[18:53] <kenvandine> mhall119, mind filing a bug?
[18:53]  * kenvandine is a bit involved in something atm, don't want to forget :)
[18:56] <mhall119> kenvandine: https://bugs.launchpad.net/content-hub/+bug/1266883
[18:56] <mhall119> thanks
[18:59] <kaimast> hey all. the link for the dual boot app installer script is dead: https://wiki.ubuntu.com/Touch/DualBootInstallation
[19:00] <kaimast> is there some other place I can get it?
[19:00] <mhall119> kenvandine: am I correct in understanding that all a QML app needs to do is the onExportRequested connection documented here: http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Content.ContentHub/
[19:00] <mhall119> populating the list<ContentItem> with the user's selection where you have // show content picker
[19:01] <kenvandine> yeah
[19:01] <mhall119> cool, having a meeting with the file-manager devs in a couple hours, going to try and get them to start implementing this
[19:02] <heathbar> Anyone know where I can find some example C++ code for capturing images from the camera hardware?
[19:11] <pmcgowan> heathbar, the camera-app
[19:12] <pmcgowan> using QCamera and QMultiMedia interfaces
[19:20] <annerajb> hello!
[19:23] <davmor2> ogra_: how do I go about disabling swap and I'll have a play with it on maguro tonight and tomorrow and report any issues
[19:24] <annerajb> have anybody been succesfull at porting cm-11.0 based devices to ubuntu touch? I started looking at the LG G2 but since it's based on cm-11.0 it's requiring things on newer repositories.
[19:41] <cwayne> cyphermox, hey sorry, had to disappear for a bit.. any luck with that MR?
[19:42] <cyphermox> cwayne: busy with something else, I'll get to it soon
[19:42] <cyphermox> looking quickly it seems fine though
[19:50] <mhall119> hurray for a new release!
[19:50] <cwayne> cyphermox, ah, no rush sorry :)
[20:10] <bfiller> pwd
[20:11] <bfiller> mhall119: choosing a picture directly from the camera will be supported but till post 14.04
[20:11] <mhall119> bfiller: ok, thanks
[20:12] <bfiller> mhall119: unless we free up someone to do it, so it's possible
[20:12] <mhall119> I don't think it's necessary enough for that, too much higher priority
[20:12] <mhall119> I just wanted to make sure it was on a roadmap
[20:13] <mhall119> I'd rather see the HUD icons working before this
[20:13] <mhall119> and calendar sync
[20:13] <mhall119> and alarms
[20:13] <mhall119> and and and...
[20:13] <mhall119> :)
[20:45] <nik90> xnox: ping
[20:54] <nik90> xnox: replied to your clock app bug report.
[20:54] <mhall119> beuno: ralsina_: when can we expect to have commercial apps support (uploading in myapps & purchasing in dash)?
[20:56] <mhall119> and also when might ratings and reviews become available?
[21:01] <xnox> nik90: thanks! will take a look in a second.
[21:02] <xnox> nik90: ok, I see. Let me talk to landing team about it.
[21:05] <nik90> xnox: I believe balloons already requested sergiusens to update the click package. So hopefully it should land soon enough.
[21:06] <xnox> nik90: oh, cool!
[21:06] <sergiusens> nik90, I got no req, but I can look into it
[21:07]  * balloons points sergiusens to the landing pipeline sheet, line 227 :p
[21:07] <beuno> mhall119, for the first one, we'll probably have a beta phase in Feb
[21:07] <sergiusens> balloons, lol, that sheet requires pings :-)
[21:07] <xnox> sergiusens: oh yeah, so clock-app click update is possibly blocking #1266841
[21:07] <nik90> sergiusens: yeah that would be nice. I don't the clock app click hasnt been updated for months.
[21:07] <beuno> mhall119, for R&R, it should be landing in the next few weeks
[21:08] <xnox> sergiusens: but i need to verify that I'm testing the right branches against the right clicks.
[21:08] <balloons> sergiusens, I thought we covered it.. lol.. we can blame me no worries
[21:08] <sergiusens> mup tell me what bug  #1266841 is
[21:09] <sergiusens> xnox, the click tests don't pull directly from trunk
[21:09] <xnox> nik90: hm. What's confusing is that on image 116 on mako, clock app has add_remove_world_location and it's passing http://ci.ubuntu.com/smokeng/trusty/touch/mako/116:20140107:20131223.2/5931/ubuntu-clock-app-autopilot/
[21:10] <xnox> nik90: and I believe i'm testing the same image in the emulator.
[21:10] <sergiusens> xnox, actually, that would be in response to nik90
[21:10] <xnox> sergiusens: i guess i need help from autopilot-jenkins-click-experts help, who would that be?
[21:10] <sergiusens> xnox, balloons, thomi, doanac and myself
[21:11] <nik90> sergiusens: what do you mean that click apps dont pull from trunk?
[21:11] <sergiusens> xnox, I can check the test on an emu instance here and see what the problem is
[21:11] <nik90> sergiusens: are you referring to the clock-app-test package?
[21:11] <sergiusens> nik90, no; the click package has some extensions in telling it where the orig repo is and the bzr revno to use
[21:11] <mhall119> beuno: if we get commercial apps for the showdown, can we use the beta phase to get them into the store?
[21:12] <sergiusens> nik90, so the only way this wouldn't work is if you overwrote trunk with something different
[21:13] <xnox> sergiusens: well, we could use the full revision id (~= git commit hash) instead of just numeric one.
[21:13] <xnox> sergiusens: that would catch if trunk got over-ridden
[21:13] <sergiusens> xnox, makes sense; I can make an improvement on that side
[21:15] <xnox> sergiusens: my test-runner is doing ~= phablet-click-test-setup --click com.ubuntu.clock; phablet-test-run ubuntu_clock_app. I hope that's the right way to do it.... to test like click for like testsuites.
[21:16] <sergiusens> xnox, yes; you have apparmor disabled I take it
[21:16] <nik90> sergiusens: on the note of click apps, when you pull in the latest trunk rev no, do you also change the click package version numbering automatically or should I do it on my end (in the json file)?
[21:16] <sergiusens> xnox, else all your tests would fail
[21:16] <sergiusens> nik90, automatic
[21:17] <nik90> sergiusens: alrite, then I dont need to worry about it.
[21:21] <xnox> sergiusens: apparmor is disabled, as a boot options & I still call the setup functions to do that click disable apparmor, disable edges demo, and "blind stab & unlock screen"
[21:23] <sergiusens> xnox, if you restart unity8 with testability; the unlocking is done automagically fwiw (I don't use it; but it is used in automation)
[21:23] <sergiusens> fginther, you use that already, right?
[21:23] <xnox> sergiusens: i get qmlscene t e s t a b i l i t y option unknown.....
[21:24] <xnox> sergiusens: is that supported by stock unity8 / qmlscene on the image?
[21:24] <sergiusens> you wnt so set-env QT_TESTABILITY=1; restart unity8
[21:25] <xnox> sergiusens: http://paste.ubuntu.com/6711344/
[21:25] <sergiusens> xnox, that's harmless regardless
[21:25] <sergiusens> Testability driver loaded. Wire protocol version is "1.4".
[21:25] <xnox> sergiusens: utils/target/unlock_screen.py:    os.system('echo "exec unity8 -testability" > ~/.config/upstart/unity8.override')
[21:26] <xnox> sergiusens: that's in lp:ubuntu-test-cases/touch... what/how/where are the test results as seen on ci.ubuntu.com are executed? full scripts / steps? I guess i want jenkins config for those jobs?
[21:27] <sergiusens> xnox, I have no idea wht lp:ubuntu-test-cases/touch is; might be something the new QA has created
[21:27] <sergiusens> veebers, can you provide guidance on how the lock screen for unity8 is supposed to be used?
[21:27] <fginther> sergiusens, yes, that looks like what upstream merger does
[21:28] <xnox> sergiusens: well, in https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-ubuntu-clock-app-autopilot/100/console it does branch lp:ubuntu-test-cases/touch at the very start and then goes on to do the rest.
[21:28] <fginther> sergiusens, xnox, lp:ubuntu-test-cases/touch is what drives the daily smoke tests
[21:28] <xnox> fginther: right, i guess i should go and verify which portions am I using and how it's executed in the smoke tests and find the differences.
[21:29] <xnox> fginther: is https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-ubuntu-clock-app-autopilot/100/console the easiest way to parse things?
[21:30] <sergiusens> xnox, look at the configure directly
[21:30] <xnox> fginther: or like, what's the contents of $ /bin/sh -xe /tmp/hudson726972573040675570.sh and how it's generated, from the top of https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-ubuntu-clock-app-autopilot/100/console
[21:30] <xnox> sergiusens: where is configure? and do I have magic access to see it?
[21:30] <veebers> sergiusens: I'm not sure I follow. Are you asking about the script that xnox mentioned?
[21:30] <fginther> xnox, I can pastebin the jenkins guts to youo
[21:30] <sergiusens> veebers, nvm, fginther just answered ;-)
[21:30] <veebers> sergiusens: sweet
[21:30] <xnox> fginther: i think i'm in some qa teams to see config bzr branches.
[21:31] <xnox> fginther: are those configs defined there?
[21:31] <xnox> fginther: the ~p-ps-q-team
[21:31] <fginther> xnox, the jobs are created by lp:ubuntu-test-cases/touch
[21:32] <fginther> xnox, here's what's in the jenkins bash script: http://paste.ubuntu.com/6711380/
[21:38] <xnox> fginther: thanks a lot! i'll modify my emulator hooks to do things via jenkins.sh script as well, so that certainly can explain a few differences in my test output.
[21:39] <fginther> xnox, there is also scripts/provision.sh which is intended to run as a one-time setup before running the tests
[21:40] <xnox> fginther: right, I forked that one into scripts/provision-emulator.sh as things are different
[21:40] <fginther> xnox, cool
[21:40] <xnox> fginther: i use snapshots, so each emulator boot is "first boot" as it's drives are rolled-back to pristine image, and thus no reboots required.
[21:40] <xnox> fginther: (actually, more correctly reboots of the emulator fail ;-) / not possible to do )
[21:41] <xnox> fginther: apart from that it's all about the same.
[21:41] <xnox> (similarly pre-test reboot, is roll-back snapshot + boot)
[21:41] <balloons> xnox, so I'm looking into the terminal bug, https://bugs.launchpad.net/ubuntu-terminal-app/+bug/1257791, and atm it appears things begin to break when we switch to libpinyin4. If this is indeed true, does anything stand out to you as the reason why?
[21:42] <xnox> balloons: define "not work" where / how? on the real device?
[21:43] <balloons> xnox, yes, on a real device. The terminal app doesn't see the keypress event at all
[21:43] <balloons> only for backspace and ente
[21:44] <xnox> balloons: honestly, i don't know. Talk to ubuntu-keyboard people / qt / security...
[21:44] <balloons> I'm just pinging you since I saw you did the work on pinyin4 is all..
[21:44] <balloons> and I think that *might* be the cause.. just asking if you would think it worthwhile to look into or not
[21:44] <balloons> it's hard to go back further because the older builds needs libpinyin2
[21:45] <balloons> if the port was boring, I'll assume it was something else
[21:46] <balloons> xnox, ^^
[21:54] <xnox> balloons: the port was boring, and was fully validated across all tests, ubuntu-keyboard and manual testing in multiple languages.
[21:55] <xnox> balloons: and pinyin is used for predicting chinese/etc. words ahead of typing the full thing. Certanly nothing to do with !asian languages, or generic things like "Enter"
[21:56] <xnox> balloons: libpinyin2 is no longer available in trusty... and that's for a long time now.
[21:57] <balloons> xnox, kk, just ruling things out ;-) Yes, I have a suspicion about this bug, but can't check on it because of pinyin2.. I'll have to try something sneaky. https://launchpad.net/bugs/1202694
[21:59] <xnox> balloons: i'm confused how/why/where you still use pinyin2... it's not available anywahre.
[21:59] <xnox> balloons: it's better to debug things, instead of trying to figure when something changed.
[21:59] <balloons> xnox, I'm saying the older builds use pinyin2 is all.. I tried a bit of debugging, but I'm not up to snuff.. My ideas fizzled
[22:00] <balloons> anyways, ty for the confirmation
[22:00] <xnox> balloons: my recommendation is to try it in the emulator.
[22:00] <balloons> oO.. hmm
[22:00] <xnox> balloons: if everything works in the emulator, you can be certain it's app-armor blocking you =)
[22:01] <xnox> balloons: if it fails in the emulator, at least you can then pass it on to any developer =)
[22:19] <sergiusens> balloons, nik90 this is what I get with the latest devel-proposed on maguro: http://pastebin.ubuntu.com/6711621/
[22:23] <xnox> sergiusens: is emulator sdcard pulling devel or devel-proposed....
[22:23]  * xnox goes to check
[22:23] <sergiusens> xnox, the stuff I built has channel selection
[22:23] <sergiusens> and pull devel-proposed by default
[22:23] <sergiusens> hopefully would be uploaded today
[22:24] <xnox> sergiusens: and then i'll need to rebase / integrate on top of that...
[22:30] <sergiusens> balloons, nik90 on rerunning I only get one fail, that seems to pass every now and then http://pastebin.ubuntu.com/6711661/
[22:31] <balloons> mm.. sadly no maguro for me
[22:31] <sergiusens> balloons, it seems that it's just a matter of slowness
[22:32] <balloons> right
[22:32] <sergiusens> balloons, I'll upload and send over to popey
[22:32] <popey> kk
[22:35] <sergiusens> popey, https://myapps.developer.ubuntu.com/dev/click-apps/121/
[22:35] <popey> sergiusens: approved
[22:37] <nik90> sergiusens, balloons, popey: thnx
[22:37] <popey> np
[23:34] <beuno> mhall119, depends on when the contest is  :)
[23:50] <stgraber> ogra_: oh, btw, I spent a couple of hours fixing some issues with one of my system-image branches and I know have something that should work for ports. I have an example of a working server at https://phablet.stgraber.org
[23:50] <stgraber> the branch still needs a bunch of tests to be written before I merge it but I'll try to get that done this week