[00:14] <ajalkane> So apparently autopilot 1.4 is needed to run FileManagers autopilot tests. What is the best way to get that version on Ubuntu 13.10? Saucy provides autopilot 1.3
[00:18] <veebers> ajalkane: Hi, for 1.4 on Saucy you'll need to use a ppa. Right now we're in the middle of reorganizing our ppas to be better, but for right now you can use ppa:autopilot/experimental. Tomorrow or so, if you can wait that long, we'll be releasing to ppa:autopilot/1.4
[00:20] <ajalkane> veebers: thank you, that's excellent
[00:38] <ajalkane> Ah well, I probably best wait for ppa:autopilot/1.4. Using the experimental ppa I got unmet dependencies
[04:56] <KathyReid> hi there, I have a problem updating my Nexus 4 to version 121
[04:57] <KathyReid> every time it downloads and I click 'Apply and restart' it fails with 'no file was downloaded
[04:57] <KathyReid> What should I try?
[04:59] <mhall119> KathyReid: are you letting the phone sit between downloading and hitting that button?
[05:00] <mhall119> I noticed on my Nexus 4 that it can lose the download file if the phone suspends after downloading
[05:00] <KathyReid> mhall19: not sure what you mean by sit?
[05:00] <mhall119> on my Nexus 7 that is, not my 4
[05:00] <KathyReid> aaah suspending
[05:00] <KathyReid> good question
[05:00] <KathyReid> It's taking round 30 mins to download
[05:00] <KathyReid> my internet sucks
[05:01] <mhall119> yeah, I think it has something to do with it downloading to a temp location or something, then when the system-settings app is suspended (when the phone is suspended) the temp files are removed
[05:01] <mhall119> KathyReid: if it's easier, you can phablet-flash from an Ubuntu desktop
[05:01] <KathyReid> mhall119: that might be easier
[05:02] <KathyReid> I'm running 13.04 here
[05:02] <KathyReid> might phablet-flash it. It would be easier
[05:02] <mhall119> as long as you *don't* use -b, it shouldn't delete any user data on the phone
[05:03] <mhall119> you can use --channel trusty and --revision 121 to force the exact image to use
[05:04] <KathyReid> it's throway
[05:05] <KathyReid> I have all my Android stuff backed up on my 'live' Nexus 4
[05:05] <KathyReid> (I have 2 - one KitKat, one for playing with Touch)
[05:05] <KathyReid> phablet-flash ing as we speak
[05:05] <KathyReid> getting 17kbps down from wherever the image is :S
[05:09] <KathyReid> mhall119: thanks heaps for your advice. Much appreciated.
[05:11] <cwayne> mhall119, do we have a bug in for that?
[05:14] <mhall119> cwayne: I never filed one, no
[05:14] <mhall119> shame on me
[05:14] <mhall119> I'll try to re-create it on the next stable release
[05:19] <KathyReid> cwayne: also happy to try replicating
[05:49] <Mirv> barry: Qt 5.2 -> https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2
[07:57] <dholbach> good morning
[09:21] <fr33r1d3> What is th best place to learn making apps for Ubuntu Touch?  developer.ubuntu.com have like... 1 tutorial... Any more?
[09:23] <ogra_> fr33r1d3, there is an #ubuntu-app-devel IRC channel
[09:23] <fr33r1d3> ok, cool. will check it out.
[09:23] <ogra_> and there is a G+ circle where people filed tutorials etc
[09:44] <fr33r1d3> Ubuntu Touch support for Nexus 4 will continue?
[09:44] <ogra_> yes
[09:44] <ogra_> and the new nexus 7
[09:45]  * Laney looks at his old one ...
[09:45] <didrocks> Laney: you look sadly? ;)
[09:47] <Laney> could put android back on it :P
[09:47] <ogra_> didrocks, you dont ?
[09:47] <ogra_> didrocks, we will stop providing images (no matter how broken or unsupported) which means you cant use the HW as development device anymore
[09:49] <seb128> ogra_, it means you can start using the device though! (by putting android on it :p)
[09:49] <seb128> ok ok ok, -> [ ]
[09:49] <seb128> ;-)
[09:49] <ogra_> didrocks, after asac's decision i went from four dev devices i have to one, i cant do anthing with my private N4 because i use it for dogfooding, that means i have to do development and testing on the new N7 i have
[09:49] <ogra_> seb128, heh
[09:49]  * ogra_ checks if it's friday already
[09:49] <Laney> he has three spare fridays from the holidays
[09:49] <seb128> indeed!
[09:50] <seb128> and I'm just using like 15 minutes at the time
[09:50] <ogra_> didrocks, for me that means a massive slowdown, i would at lest like to have images available for development, even if they are not supported
[09:50] <ogra_> lol
[09:50] <seb128> what are the chance we get community maintained build for it?
[09:50] <didrocks> ogra_: still can be a nice build machine
[09:50] <seb128> though I've to admit things never worked great on the n7
[09:51] <didrocks> as seb128 told, that never worked greatly to be useful enough
[09:51] <seb128> sounds was not working for a while, Mir being slow and buggy
[09:51] <didrocks> hence the "no sadness"
[09:51] <ogra_> didrocks, how ? i cant install a new image anymore
[09:51] <didrocks> ogra_: the ubuntu desktop one, as we did in the past?
[09:51] <ogra_> seb128, yeah, i dont mind, i still would like to be able to test click packages on it quickly, or do a build or whatnot
[09:52] <ogra_> didrocks, i have about 20 machines where i can do normal ubuntu arm builds ... i want to have the readonly image to be able to test stuff in context etc
[09:52] <didrocks> ogra_: you do, I don't ;)
[09:53] <didrocks> it's my only arm builder which isn't the N4
[09:53] <Laney> I also feel bad if there are people who purchased their own on our previous advice
[09:53] <didrocks> Laney: agreed on that one
[09:53] <ogra_> yeah, thats seriously bad ... everyone shoulld have two deviaces at least
[09:53] <ogra_> and yes, we kind of let the community people down here :/
[09:54] <seb128> what are the chance we get a community maintainer build for it?
[09:55] <ogra_> seb128, not bad perhaps ... but you will have to dig out the zip from xda-developers, do manual installs etc etc
[09:55] <ogra_> and wont get OTA upgrades
[09:56] <ogra_> we still dont have any infrastructure for ports in place that would provide either
[09:56] <seb128> right...
[09:57]  * ogra_ knows that personally he will have a massive slowdown in writing fixes for the plumbig layer with that decision,, simply because i'm restricted to one device for doing work now 
[10:18] <asac> ogra_: till end of month maguro is still great
[10:18] <ogra_> asac, i dont care if it is great, but we are effectively taking away development devices
[10:19] <ogra_> today i can test a proposed image while i develop a new feature on another device and do a low level fix in the system on even another one, all on proper touch images
[10:20] <ogra_> i dont care if the two i dont use for testing are supported
[10:20] <ogra_> in the future i will have exactly one device to do all these three tasks on
[10:20] <ogra_> that will massively slow me down
[10:21] <ogra_> thats why i wouold like us to go on building images ... we dont need to support them or give them any love as long as they are flashable and adb works
[10:22] <pitti> hm, do we have any app which actually uses QAccelerometer?
[10:22] <ogra_> isnt the orientation done by the accelerometer sensor too ?
[10:22] <pitti> I'm writing tests for it, and it seems neither its readingChanged() signal is ever called, nor are its .reading() values ever updated
[10:23] <pitti> ogra_: yes, but wired internally
[10:23] <ogra_> oh, right
[10:23] <ogra_> well, but you should be able to get physical events from through the API it nontheless
[10:23] <ogra_> if not, thts surely a bug
[10:23] <pitti> I've been chasing why my readingChanged slot never gets updated (as I'm a Qt newbie), but it seems it's not due to my connect and slot, but as it's never been called in the first place
[10:24] <ogra_> tvoss, ^^
[10:25] <pitti> ok, I'll track it down
[10:30] <pitti> ah, it's internally wired through a queued connection, so that needs a main loop
[10:59] <davmor2> Morning all
[11:01] <tvoss> pitti, hey there
[11:01] <pitti> hey tvoss
[11:02] <dpm> morning sil2100! Do you know in which image will the Evernote account plugin land?
[11:03] <tvoss> pitti, hey there, I get test failures with the platform-api in http://pastebin.ubuntu.com/6749837/
[11:04] <pitti> qemu: Unsupported syscall: 257
[11:04] <pitti> eek
[11:04] <pitti> tvoss: is that an emulated arm qemu instance?
[11:04] <tvoss> pitti, that's an armhf schroot
[11:04] <pitti> ah, yes
[11:04] <sil2100> dpm: morning! It's in the archive now and I think didrocks wanted to seed it now for touch, but not sure if t's in already
[11:05] <ogra_> tvoss, pitti, that shouldnt do any harm though
[11:05] <pitti> tvoss: that means that system emulator qemu doesn't support timer_create(), but that's what the emulated sensors use
[11:05]  * ogra_ would have to look up which syscall it is, but it is definitely nothing that could cause breakage 
[11:05] <pitti> but that's the stanard POSIX timer
[11:05] <didrocks> dpm: it will be in the next one
[11:05] <didrocks> dpm: so you can publish the click apps if needed
[11:05] <dpm> awesome, thanks sil2100 and didrocks!
[11:05] <pitti> so if that doesn't work, I don't know what else it should use
[11:05] <tvoss> pitti, I wonder how we pass CI if that is a general problem
[11:06] <pitti> tvoss: I thought MPs run on real iron, not in emulated qemu
[11:06] <tvoss> pitti, hmmm ...
[11:06] <ogra_> bug 1042388
[11:06] <pitti> we've seen lots of bugs in qemu (when running tests during arm PPA builds, for example)
[11:06] <tvoss> pitti, how can I then build an armhf package locally?
[11:07] <pitti> tvoss: "sudo apt-get build-dep platform-api", apt-get -b platform-api ?
[11:07] <pitti> i. e. exactly like on a desktop
[11:07] <tvoss> pitti, hmmm, that will run the package tests and those are failing here
[11:07] <pitti> or bzr branch lp:platform-api, and cmake . && make -j4
[11:07] <tvoss> pitti, sure :)
[11:07] <pitti> tvoss: that's how I did it, anyway
[11:08] <pitti> tvoss: you mean platform-api's tests are failing on current phone builds?
[11:08] <pitti> I can look into that
[11:08] <tvoss> pitti, so I'm trying to build a platform-api branch with your tests in an armhf schroot with dpkg-buildpackage
[11:09] <pitti> anything which gives me a break from this (*$#($#* Qt signal/slots in qtubuntu-sensors is a welcomed break :)
[11:09] <tvoss> pitti, that executes the test suite which fails
[11:09] <pitti> tvoss: right, see above, qemu doesn't support that
[11:09] <pitti> tvoss: the emulated sensors need posix timers
[11:09] <pitti> but it works fine on real iron
[11:09] <pitti> (both arm and x86)
[11:10] <tvoss> pitti, okay, I will disable the tests then for local purposes. Should we have a CMake option for that?
[11:10] <pitti> tvoss: DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage [...]
[11:10] <tvoss> hah :)
[11:10] <pitti> tvoss: that's the standard way of not running tests for a package build
[11:11] <pitti> FYI:
[11:11] <pitti> override_dh_auto_test:
[11:11] <pitti> ifeq (, $(findstring nocheck, $(DEB_BUILD_OPTIONS)))
[11:11] <pitti>         cd obj-* && ctest --verbose
[11:11] <pitti> endif
[11:11] <pitti> ^ from debian/rules
[11:11] <ogra_> pitti, tvoss just pull the fix from the git tree (in tteh bug i posted above)
[11:11] <ogra_> https://bugs.launchpad.net/qemu/+bug/1042388/comments/15
[11:12] <pitti> oh, nice!
[12:05] <dpm> hey Saviq, a quick question: at a glance, would you know which of these indicator-* links on this page are relevant for translating the phone interface? https://translations.launchpad.net/ubuntu/trusty/+lang/ca - or if it's easier, which ones are not relevant?
[12:06] <dpm> I'm preparing a call for translations to point people to those which are more interesting for the phone
[12:06] <pitti> ogra_, tvoss|lunch: FYI, building qemu with these two patches here, then trying platform-api with them
[12:06] <tvoss|lunch> pitti, great, thank you
[12:06] <pitti> this seems to hit more users
[12:07] <pitti> tvoss: and FTR, building documentation under qemu emulation sucks :)
[12:08] <tvoss> pitti, it does, indeed.
[12:09] <Saviq> dpm, -bluetooth, -datetime, -power, -sound, -network, -location, -messages
[12:09] <Saviq> dpm, ps aux | grep indicator on your phone ;)
[12:09] <dpm> Saviq, ah, nice, thanks :)
[12:11] <dpm> Saviq, would you happen to know as well which scopes are relevant for Unity 8 translations? On that same list in LP I know we're using unity-scope-home, but I'm not sure which other unity-scope-* and unity-lens-* ones are relevant
[12:13] <Saviq> dpm, -mediascanner and -click
[12:14] <dpm> Saviq, ah, exactly those which are not translatable, well spotted :)
[12:25] <pitti> tvoss: hm, trying to build platform-api has been stuck on "Generating member index..." for 25 minutes now.. does it take that long for you as well, or did qemu get stuck for me?
[12:26] <pitti> it's not even using CPU any more
[12:26]  * pitti kills it
[12:26] <tvoss> pitti, qemu got stuck
[12:26] <sergiusens> pitti, it's dead
[12:26] <tvoss> pitti, we should switch DOT_NUM_THREADS in doc/Doxyfile.in to 1
[12:26] <tvoss> pitti, that solves the issue
[12:26] <pitti> ok, /me tries again
[12:26] <sergiusens> isn't platform api cross buildable yet?
[12:27] <pitti> certainly not running its tests
[12:27] <pitti> tvoss: I want to replicate the failure before I try with the fixed qemu
[12:27] <sergiusens> build on device
[12:27]  * sergiusens uses a chromebook just for building
[12:27] <ogra_> same here ... and a sabrelite
[12:27] <pitti> sergiusens: well, I usually do
[12:27] <tvoss> pitti, yup
[12:28] <pitti> sergiusens: the point is that I want to test a qemu fix for posix_timers, which the platform-api test suite uses :)
[12:28] <pitti> so I do want to try that one in an armhf schroot
[12:28] <pitti> in fact I just created one, I usually just do stuff right on the G4
[12:28] <pitti> so much faster
[12:28] <sergiusens> nice
[12:28] <pitti> tvoss: http://people.canonical.com/~pitti/tmp/qemu-posix-timers/ in case you want to try yourself
[12:29] <tvoss> pitti, cool, will get to it after I have finished building some packages
[12:29] <pitti> tvoss: I will test it, it was just an FYI
[12:29]  * pitti toddles off for lunch while it's building
[12:29] <tvoss> pitti, enjoy :)
[12:31] <pitti> but, FTR: whoever made it so easy to build an armhf schroot (mk-sbuild --arch=armhf trusty --type=file): KUDOS!
[12:31] <pitti> xnox: ^ could have been you? :-)
[12:37] <ogra_> pitti, heh, that was a several year long process :)
[12:57] <cwayne> pitti, hi, so i ended up following what you did for timedated for hostnamed to allow us to write to /etc/hostname and /etc/machine-info, any chance of a MR?
[12:57] <cwayne> https://code.launchpad.net/~cwayne18/livecd-rootfs/machine-info-writable/+merge/201542 and https://code.launchpad.net/~cwayne18/ubuntu/trusty/systemd/symlink-support-hostnamed/+merge/201540
[12:58] <vthompson> Hey all, would anyone be able to test out a branch the sudoku-app has to introduce user metrics to the welcome screen? I tried testing on my device, but I haven't had any luck. You'll probably want to "Show Hint" until the game completes. Branch: https://code.launchpad.net/~dinko-metalac/sudoku-app/usermetrics
[12:59] <cwayne> cyphermox, ^ (the MR's I promised you)
[13:06] <cyphermox> cwayne: cool, thanks!
[13:06] <pitti> cwayne: looking
[13:08] <pitti> tvoss: hm, not sufficient yet :(
[13:08] <pitti> 1: TestSensor ERROR: Failed to create timer: Invalid argument
[13:09] <tvoss> pitti, hmmm ...
[13:09] <cwayne> cyphermox, i added /etc/hostname in as writable, because honestly, it almost seems like a bug that everything has the hostname 'ubuntu-phablet' (at least it's certainly obnoxious if you're using more than one device and forget which one is connected :P)
[13:09] <cyphermox> cwayne: agree.
[13:11] <cwayne> cyphermox, so this way, we could even make an upstart job to set hostname to device-name if we wanted to :)
[13:15] <pitti> cwayne: reviewed; srsly, this is sheer madness
[13:15] <pitti> we are getting ourselves deeper and deeper into that swamp of "we break /etc/" hacks

[13:15] <cwayne> pitti, :/ yeah
[13:16] <pitti> cwayne: do you want systemd uploaded right now?
[13:16] <cwayne> i'm happy to try another way to fix it (although I have no idea how we'd go about doing it)
[13:17] <ogra_> write an upstart job that touches /userdata/.writable_image on every boot :P
[13:17] <vthompson> dpm, mhall119, popey, would any of you be able to test out a branch Dinko has for the sudoku-app to introduce user metrics to the welcome screen? I tried testing on my device, but I haven't had any luck. You'll probably want to "Show Hint" until the game completes to increment the counter. Branch: https://code.launchpad.net/~dinko-metalac/sudoku-app/usermetrics
[13:17] <cwayne> pitti, don't we need to do a landing ask and all that jazz first?
[13:17] <pitti> cwayne: there isn't really -- it's pretty much a design problem ATM
[13:17] <Saviq> ricmm_, does enter on the OSK work in the terminal app?
[13:17] <Saviq> ricmm_, +for you
[13:17] <pitti> cwayne: ah, ok; please go ahead with that the
[13:18] <pitti> n
[13:18] <ogra_> Saviq, oh, was that supposed to be fixed ?
[13:18] <Saviq> ogra_, dunno?
[13:18] <ogra_> (hasnt worked for 6 weeks or so)
[13:18] <pitti> cwayne: please prod me when you want me to upload then
[13:18] <cwayne> pitti, yeah, the only other thing i could think of is either a hack upstart job, or a patch to bluez (which cyphermox -1'd), so i guess this will have to do
[13:18] <Saviq> ogra_, ouch
[13:18] <cwayne> pitti, will do, thanks a lot!
[13:18] <ogra_> yeah
[13:19] <Saviq> ogra_, we need to up the priority on that - it seems to break apps that don't have a "Go" button for a text entry
[13:19] <ogra_> oh
[13:19] <cyphermox> cwayne: pitti: the nice solution would be a proper overlay on /etc
[13:19] <pitti> cyphermox: right
[13:19] <ogra_> popey, ^^^iirc you had opened the bug for this
[13:19] <cyphermox> pitti: can't we do that? or are we missing kernel magic for that?
[13:20] <ogra_> cyphermox, a) performance issues ... b) no oevrlay support in any mainline or android kernels c) performance issues
[13:20] <cyphermox> ogra_: boo
[13:20] <ogra_> :)
[13:21] <cyphermox> for /etc/, it's going to get to be really important
[13:21] <pitti> cyphermox: right, our kernels don't support it
[13:21] <cyphermox> that, or just make all of /etc/ writable.
[13:21] <ogra_> we would have taken that path if it would have been easy
[13:21] <pitti> as a fallback we could just keep /etc/ readable as $deity intended to, and copy changed files to an upgraded system image after installation
[13:22] <ogra_> which would make the upgrade process slower
[13:22] <pitti> ogra_: well, the current system is far, far away from "easy", too
[13:22] <cyphermox> ogra_: there aren't thousands of files in /etc
[13:22] <ogra_> pitti, agreed
[13:22] <pitti> we keep falling into holes and bugs
[13:22] <cyphermox> yeah
[13:22] <ogra_> well, ask stgraber, he had his reasons for picking that path
[13:23] <ogra_> it is his brainchild after all
[13:23] <pitti> well, TBH, it was the easiest way back then for design, but we didn't see all the bad consequences
[13:24] <ogra_> we will likely drop the loop mount stuff at some point
[13:24] <ogra_> and move to actual partitions
[13:24] <pitti> that's unrelated, though?
[13:24] <ogra_> in that course it might be appropriate to also introduce other ways of making stuff writable
[13:25] <ogra_> since there will bbe a lot of stuff rewritten anyway
[13:25] <cwayne> well we have two ways now: either add it to /etc/system-image/writable-paths
[13:25] <cwayne> or put it in /etc/writable
[13:25] <pitti> the former doesn't work for files, only for directories
[13:25] <pitti> we should never ever put files there
[13:26] <ogra_> the point is that by 14.10 we need to have found a way thats also appropriate for desktops ...
[13:26] <cwayne> ah, i see
[13:26] <ogra_> in which you will actually have 1000s of files in /etc
[13:26] <pitti> $ time find /etc | wc -l
[13:26] <ogra_> and make system-image upgrades slow as hell worst case
[13:26] <pitti> 2947
[13:26] <pitti> real0m0.037s
[13:26] <pitti> hardly a big deal
[13:27] <pitti> this is already stat()ing every file, so comparing timestamps for "newer than our base image" won't add more to that
[13:27] <ogra_> well, cpp will be slower, but yeah, marginal
[13:27] <ogra_> *cp
[13:27] <popey> vthompson: ogra_ sure
[13:27] <cyphermox> you'd only cp a fraction of those
[13:28] <ogra_> popey, err, i was referring to Saviq's "no enter key in terminal"
[13:28] <popey> that too ☻
[13:28] <ogra_> well, convince stgraber
[13:28] <ogra_> :)
[13:28] <ogra_> and the security team
[13:28] <sergiusens> vthompson, if you installed the same click version where the apparmor manifest changed (usermetrics addition) , they won't be reprocessed
[13:29] <davmor2> ogra_: won't the system on desktop have a mad mix of deb based stuff and  click though? In which case the image based updated probably won't be best as we found out already when you add a deb package and the deb.db gets renewed :)
[13:29] <popey> Saviq: bug 1257791
[13:29] <popey> Saviq:/35
[13:29] <popey> bah
[13:30] <ogra_> davmor2, well, we havent designed the desktop case yet ... and most likely wont even start with that before 14.10
[13:30] <cwayne> didrocks, hey, i just added a landing ask for systemd, do I need to wait around or can I just have it uploaded?
[13:30] <ogra_> davmor2, but as i understood we will want the same system setup ...
[13:30] <sergiusens> davmor2, you'd have a read only image I suppose, so no deb install
[13:31] <ogra_> i assume there will go some work into improving the writable mode for people that actually want debs ...
[13:31] <ogra_> and otoh there will be a lot debs for apps that might get re-packaged to click
[13:32]  * ogra_ looks forward to the first libreoffice click package :D
[13:32] <popey> and the increased data plan to download it
[13:32] <ogra_> dont use data plans on desktops :P
[13:32] <davmor2> popey: there is an increase on unlimited wow
[13:32] <popey> Saviq: if you have some input on that bug I'd appreciate it!
[13:33] <davmor2> ogra_: depends if your desktop is your phone plugged into a monitor :P
[13:34] <ogra_> now who woulld do such crazy stuff !
[13:35] <davmor2> ogra_: Microsoft......Umm no not them.......Androi......No not google...........Wait I know Us :)
[13:35] <ogra_> :D
[13:39] <dpm> hi vthompson, I'll try to give it a go, but probably not until this evening.
[13:46] <krabappel2548> Does anyone know if Canonical is planning to shift to cm-11.0 device trees for porting?
[13:46] <ogra_> krabappel2548, there is work going on to port to AOSP 4.4 atm ...
[13:47] <krabappel2548> ogra_: ok, I have an Xperia Z1 and I get a lot of compiling errors
[13:47] <krabappel2548> since there is no cm-10.1 device tree for Z1
[13:47] <krabappel2548> and not a lot of Snapdragon 800 support in Ubuntu repos maybe
[13:47] <ogra_> right, the kitkat port should fix that
[13:48] <ogra_> should be ready soon (iirc there are still some hybris issues to be fixed)
[13:50] <krabappel2548> ogra_: ok, thanks for the heads up
[13:59] <barry> Mirv: thanks, i eventually stumbled on that ;)
[14:01] <JamesTait> ogra_, hi! Can you point me at the best person to speak to about click package categorisation in the dash?
[14:04] <ogra_> JamesTait, hmm, there are several bits involved ... on the store side you need categories first ... that would be beuno i think ... for the click lens you would need a UI that supports them, not ure who works on this ... dobey perhaps ...
[14:04] <JamesTait> ogra_, it's the UI part I'm most interested in, I'm working on the store side and have a question. :)
[14:05] <ogra_> well, looking at the unity-scope-click changelogs it seems dobey does the most commits there
[14:05] <dobey> are you talking about categories or filters?
[14:06] <JamesTait> dobey, yes. :-P
[14:06] <dobey> "More Suggestions" and "Installed" are categories, "Games" and "Sound & Video" are filters
[14:07] <JamesTait> dobey, so from what I can see, we want to be presenting the Departments as filters in the dash.
[14:07] <dobey> right
[14:07] <dobey> afaik, the dash has no filters support yet
[14:07] <dobey> so that's not a scope issue (we can't give the dash something it doesn't support)
[14:07] <JamesTait> dobey, I'm looking at http://software-center.ubuntu.com/api/2.0/applications/en/ubuntu/click/ as my source.
[14:08] <dobey> JamesTait: that's the MyApps stuff, which is not used by the scope. we only get data from search.apps.u.c
[14:09] <dobey> (well, and rnr now, but that's totally separate from this)
[14:09] <JamesTait> dobey, right... apparently that's coming up RSN, though, which is why I've been asked to work on it.  We import the data from that URL and index it in such a way that it can be consumed via search.apps.u.c
[14:09] <dobey> right
[14:10] <didrocks> cwayne: you can get it uploaded, I just acked it. just run the unity8 AP tests + dogfooding (see Landing plan number 390)
[14:11] <JamesTait> dobey, AIUI we need to present the department from that feed as filters in the dash, so users can drill down to find apps.  I need to know if we're intending to allow multiple departments to be selected.
[14:13] <dobey> JamesTait: afaik yes. but i think that's irrelevant to the server. we'd just get departments: ['x', 'y', 'z'] from the server, and that would be in the existing results. if the dash is going to force a new search, that would be really bad architecturally.
[14:13] <dobey> JamesTait: but i'm not working on that bit. that's all in the dash
[14:14] <cwayne> didrocks, awesome, thanks! running unity8 tests now
[14:14] <dobey> JamesTait: in the scope we'll just parse the results and send them to the dash. the server should support having multiple departments specified as a search qualifier regardless, i think
[14:15] <JamesTait> dobey, ack, thanks. :)
[14:15] <didrocks> cwayne: do not hesitate to update the spreadsheet as the landing proceeds (like INPROPOSED, INARCHIVE)
[14:15] <cwayne> didrocks, ack, will do, thanks
[14:16] <didrocks> yw!
[14:16] <cwayne> er pitti ^ do I need to add the livecd-rootfs change too? or does that go through a different process?
[14:17] <pitti> cwayne: it should both be in the same landing ask; upload-wise it's the same process
[14:18] <cwayne> pitti, ok, thanks, doing the AP tests now, will let you know :)
[14:20] <barry> Mirv: do you have an eta for when the 5.2 packages will land in the archive?
[14:28] <mterry> ogra_, you ask in your review of my dbus-screen-fix branch: "should the patch be dropped from the session mir?"   Do you mean, we should drop the dbus code from unity-mir or something else?
[14:28] <ogra_> mterry, no, thats exactly what i meant
[14:29] <ogra_> feels like duplication
[14:29] <mterry> ogra_, we should drop it, but only after we turn on nested mode.  It's not harmful to have it in there in the mean time
[14:29] <ogra_> right
[14:29] <ogra_> that was just meant as a reminder ... drop the old cruft :)
[14:29] <mterry> ogra_, OK, thanks for testing on maguro for me!  So nested mode is +1 on that device.  I'll top approve that branch and wait for libhybris
[14:30] <ogra_> yeah, either rsalveti or ricmm_ are now on duty
[14:45] <shiggitay> hey all
[14:53] <rsalveti> ogra_: yup, will get that done now
[14:53] <rsalveti> let me flash my grouper and remove the dust out of it
[14:53]  * ogra_ hugs rsalveti 
[14:53] <ogra_> lol
[14:56] <sergiusens> ogra_, I have grouper too
[14:56] <ogra_> tvoss, there is another pp lifecycle thing i was wondering about btw ...
[14:56] <ogra_> *app lifecycle
[14:57] <tvoss> ogra_, shoot
[14:57] <ogra_> tvoss, i noticed that apps usually immediately stop if they get backgrounded ... i personally often have the case that i start a few webapps in succession ... would be nice if we kept them running for a few secs so they can load in bg
[14:58] <tvoss> ogra_, that's something we have to tune then, but our app lifecycle allows for that. My proposal is to get to that later, when we have tuned the memory values and such
[14:58] <ogra_> i.e. allow them to completely load even if they are not foregrounded before stopping them
[14:58] <ogra_> yeah, surely not important right now
[14:59] <ogra_> just something that always bothers me after a reboot
[14:59] <tvoss> ogra_, at any rate, the "grace" period will be fixed
[14:59] <tvoss> ogra_, let's file a bug against unity-mir then
[14:59] <ogra_> (i have a bunch of apps i cionstantly run ... having to wait til app by app is loaded is actualy time consuming and makes it feel un-snappy)
[14:59] <ogra_> yep
[15:00] <rsalveti> I thought it was already waiting 3 or 5 seconds
[15:00] <tvoss> ogra_, perhaps we can tag them with "tuning"?
[15:00] <rsalveti> maybe that's not enough
[15:00] <ogra_> (session saving would also rock btw ... but i guess thats a 15.xx task)
[15:00] <ogra_> rsalveti, definitely isnt
[15:00] <ogra_> at least if you run several webapps
[15:00] <tvoss> rsalveti, right, we already grant a grace period, yes, but that would need to be fine tuned
[15:01] <ogra_> rsalveti, i think it shuould rather talk to the app "wait for loaded signal or so" than to be a fixed time
[15:01] <tvoss> ogra_, what do you think about the "tuning" tag?
[15:01] <cwayne> bfiller, is the gallery-app-to-click transition on track for this week?
[15:01] <tvoss> ogra_, that would give apps a way to escape the lifecycle trap ... won't happen
[15:01] <ogra_> tvoss, sounds good ... if we dont have any other optimization tag yet at least
[15:02] <tvoss> ogra_, we do not assume the app to be cooperative or behaving correctly, and thus a fixed grace period
[15:02] <bfiller> cwayne: hopefully, waiting on some changes needed in the content-hub to support click
[15:03] <shiggitay> so with the news that Canonical putting most Nexus devices on hold, does that mean that the N5 attempts are gonna be on hold as well?
[15:03] <ogra_> shiggitay, only that some community devs will have to pick it up
[15:03] <shiggitay> yeah
[15:03] <shiggitay> that's what I was thinking too
[15:03] <shiggitay> are any such devs im here? xD
[15:03] <shiggitay> in*
[15:03] <sergiusens> bfiller, I think I saw an MR for the content hub already from kenvandine
[15:04] <FuLgOrE> hello. could anybody please explain to me, why and what on Ubuntu Touch will be read-only and what are the pro's and con's of making it rw? Can I use apt-get on Ubuntu Touch?
[15:04] <bfiller> sergiusens: ack, need to test that today
[15:04] <Laney> what's up with this qtmultimedia-opensourc-src-touch package?
[15:04] <sergiusens> bfiller, did you see my email btw?
[15:04] <Laney> I think it being at 5.1 vs the normal one at 5.0.2 is meaning I can't build telephony-service on the device
[15:05] <FuLgOrE> shiggitay: I also have a Nexus 5 and I'm waiting for an Ubuntu Touch image :D
[15:05] <ogra_> FuLgOrE, the image based updates we provide actually use a binary diff between two readonly images (which makes the updates extremely small and about 10x faster than with apt) ... this requires that the system that gets diffed is readonly so all users have the same diff
[15:05] <cwayne> shiggitay, i saw someone in the community working on a port earlier, and once we get it based on 4.4 aosp, it *should* be pretty trivial
[15:05] <shiggitay> cwayne, yeah I think I know which dev it was
[15:06] <shiggitay> rsalveti I think
[15:06] <ogra_> FuLgOrE, making the image writable means you cant use that mechanism reliably anymore ... you can install debs then, but it will likely break at some point (size limits etc)
[15:06] <barry> Mirv: there are lots of build failures in that ppa unfortunately, many of which i'm seeing locally too.  e.g. i cannot get a good build of address-book-app :(  http://tinyurl.com/mtzlknf   Any suggestions?
[15:06] <bfiller> sergiusens: yes, just haven't had a chance to get back to it
[15:07] <FuLgOrE> ogra_: that sounds interesting. How about updates? Would I get updates when the image is rw over apt-get?
[15:08] <ogra_> no
[15:08] <FuLgOrE> ogra_: sorry for these kind of questions, I'm just a user :)
[15:08] <ogra_> you can do apt updates, but only to a certain point
[15:08] <ogra_> FuLgOrE, perfectly valid questions, no worries :)
[15:09] <ogra_> dpkg uses hardlinks when it unpacks debs ... hardlinks do not work across partitions so you will find packages that are not installable ...
[15:09] <ogra_> then there is a size limit due to the fact that we use loop mounted images, you will at some point run out of space for the apt package cache
[15:10] <FuLgOrE> how big is the loop image actually?
[15:10] <ogra_> the readwrite mode is more something for devs that know they will re-flash at some point
[15:10] <ogra_> i wouldnt recommed to expect to use it constantly
[15:11] <ogra_> root@ubuntu-phablet:/# df -h |grep loop0
[15:11] <ogra_> /dev/loop0                    2.0G  1.2G  673M  64% /
[15:11] <FuLgOrE> hmm I see
[15:11] <FuLgOrE> thanks
[15:12] <FuLgOrE> so if I would change the size of the loop device, I wouldn't get the small standart updates but I would be able to use apt-get with more space?
[15:13] <ogra_> yes
[15:13] <FuLgOrE> I guess only a small part of the system is ro. so with "dpkg uses hardlinks and they don't work across partitions" you mean, that if I would have, let's say /dev/loop and /dev/sda, it wouldn't work for a long time?
[15:14] <ogra_> with the exception of the hardlink issue
[15:14] <ogra_> root@ubuntu-phablet:/# mount |wc -l
[15:14] <ogra_> 65
[15:14] <ogra_> well, there are a lot of mountpoints that span across partitions
[15:15] <FuLgOrE> ok, I think I start to understand a bit :)
[15:15] <ogra_> while the ro part is made writable with the option you can set, it doesnt changethe overall design ... the rw mounted bits are still there
[15:16] <FuLgOrE> sure. And I think it is a clever idea with the small updates
[15:17] <FuLgOrE> I just hope it don't makes me feel "locked away"
[15:17] <ogra_> it is essential for people upgrading via a 3G dataplan :)
[15:17] <shiggitay> I think rsalveti had pretty much completed the 4.4 AOSP HAL... correct me if I'm wrong...
[15:17] <FuLgOrE> sure
[15:17] <rsalveti> shiggitay: most of it yeah, got the first image for mako, working on the others now
[15:18] <shiggitay> rsalveti, cool
[15:18] <shiggitay> I still offer my services lol to test for hammerhead (N5) when ready
[15:19] <rsalveti> sure, will need that later this week for sure
[15:19] <FuLgOrE> so would it be still possible to integrate some packages from source code?
[15:19] <FuLgOrE> -packages+programs
[15:19] <ogra_> FuLgOrE, well, the package format for touch is click ... not deb
[15:19] <ogra_> we only use debs to assemble the system
[15:20] <ogra_> but not beyond this point
[15:20] <FuLgOrE> I mean is it possible to use something like make, make install? :)
[15:20] <ogra_> so if you write a program you would pick the click format for your stuff
[15:20] <ogra_> sure
[15:20] <ogra_> in writable mode
[15:21] <FuLgOrE> and the click package is qml or html5, right?
[15:21] <ogra_> (make would always work)
[15:22] <ogra_> (make install would depend on the fact if you use writable paths for your stuff ... in which case i would personally rather go with a click package)
[15:22] <FuLgOrE> I would like the possibility to install some terminal things which are not standart-smartphone things :D
[15:22] <FuLgOrE> just for playing around
[15:22] <ogra_> the click package can contain everything ... but yeah, the typical language for apps in ubuntu touch is C++ or QML, javascript and HTMML5
[15:23] <ogra_> sure, but they come as debs and need writable mode
[15:23] <ogra_> i personally often install htop for example when debugging stuff
[15:23] <ogra_> and i know of people that have run mutt and irssi in the terminal app
[15:24] <FuLgOrE> and if you want to switch back, you have to flash the loop image again, right?
[15:24] <ogra_> right
[15:25] <FuLgOrE> is it possible to umount the loop device and simply copy it via bash script or something like that (from phone to phone)? :D
[15:25] <ogra_> there are surely ways
[15:26] <FuLgOrE> sounds very nice. thank you for so many information!
[15:26] <ogra_> :)
[15:27] <ogra_> sergiusens, do we have an overview of what events the upstart-android bridge already sends/understands ?
[15:27] <ogra_> (or are there simply none yet)
[15:29] <sergiusens> ogra_, it sends all property changes
[15:29] <ogra_> hmm
[15:29] <sergiusens> ogra_, so on boot you will get all properties, even the ones created before the bridge was up
[15:29] <ogra_> right
[15:30] <FuLgOrE> no I just need the patience to wait for a community N5 image :D ... is there a list which terminal commands/programs work on ubuntu touch ootb?
[15:30] <FuLgOrE> *now
[15:30] <annerajb> rsalveti, any update on the 4.4 framework?
[15:30] <ogra_> i'm looking at the lxc-android-config job and was wondering if i could rip out most of it, but that means i need a reliable event from the container
[15:31] <sergiusens> ogra_, to know if it's "up"?
[15:31] <ogra_> FuLgOrE, its a normal minimal ubuntu so all terminal commands you know from your desktop should work
[15:31] <ogra_> sergiusens, yeah, i want to drop the awful loop
[15:31]  * sergiusens looks for loop
[15:31] <dpm_> hi cwayne, just sent the call for translations - http://davidplanella.org/make-ubuntu-speak-your-language/
[15:32] <FuLgOrE> ogra_: great :) that's what makes me crazy on android, nothing works :D
[15:32] <sergiusens> ogra_, why not split that into two jobs and use the file bridge?
[15:32] <ogra_> iirc inotify doesnt work on /proc
[15:32] <ogra_> or some such
[15:33] <sergiusens> meh
[15:33] <ogra_> i remember i tried that in the past
[15:33] <ogra_> anyway, in my "kill the sleep" quest thats my first stop gap
[15:33] <ogra_> and i would like to have it fully controlled by events instead of looking at files etc
[15:34] <cwayne> dpm_, thanks!
[15:34] <ogra_> but if the android bridge cant tell me if a property was set before already thats probably not the way to go
[15:34] <sergiusens> ogra_, you should be mostly fine, all services on android trigger property changes
[15:34] <ogra_> k
[15:34] <cwayne> dpm_, although it still looks like address-book-app isn't even setup for translations
[15:35] <ogra_> i'll experiment a bit
[15:35] <sergiusens> ogra_, although.... they are set to 'running' 'on start' and not 'on started'
[15:35] <ogra_> yeah
[15:35] <dpm_> cwayne, oh, who's maintaining that?
[15:35] <ogra_> that will produce races again :/
[15:36] <cwayne> dpm_, not sure.. salem_ ^ are you maintaining address-book-app?
[15:36] <sergiusens> ogra_, we should be able to tweak the android side to change that for the services we really care about
[15:36] <salem_> cwayne, no, I think renato_  is.
[15:37] <cwayne> renato_, hey, it looks like address-book-app isn't setup for translations on lp?
[15:37] <ogra_> sergiusens, yeah, mainly ueventd i guess ... but thats something rsalveti cared about with the file in proc
[15:37] <sergiusens> cwayne, dpm_ it's renato_, but if you decide for translations, make the CMakefiles click friendly
[15:37] <ogra_> (sensors etc too ... but we dont handle them atm)
[15:37] <sergiusens> ogra_, let me look at the sensorservice code for a bit
[15:38] <ogra_> would be good to hook that into usensord later
[15:38] <renato_> cwayne, the address-book-app has the rules to translation already
[15:38] <renato_> I am not sure how to integrate it with lp
[15:40] <rsalveti> ogra_: sergiusens: yeah, to be safe it'd be nice to extend the android side to tell when something is indeed "done" or running for real :-)
[15:40] <sergiusens> ogra_, I can actually improve the usensord startup; would like to have it in first without optimizations and then iterate
[15:40] <ogra_> rsalveti, right
[15:40] <ogra_> sergiusens, yeah, no hurry with that one
[15:40] <sergiusens> rsalveti, we would need to use a new property to change any values as it might break android ;-)
[15:40] <cwayne> dpm_, do you know how to integrate it with lp? ^
[15:40] <rsalveti> sergiusens: yeah, not sure yet
[15:41] <ogra_> tedg, uuuh, your UTF-8 is clearly broken
[15:41] <tedg> ogra_, Yeah, I saw that :-/
[15:41]  * ogra_ just got mail with lots of funny chars 
[15:42] <tedg> Think I fixed it... not sure.  Have to wait for next time.
[15:42] <ogra_> :)
[15:42]  * tedg should start posting on random MRs :-)
[15:42] <ogra_> lol
[15:42] <ogra_> tæst
[15:43] <tedg> I got a compose key for Christmas… loving it.
[15:43] <tedg> I can now talk to tvoss: Hi Mr. Voß
[15:50] <sil2100> mmcc: hello!
[15:50] <sil2100> mmcc: we noted that unity-scope-click trunk is failing to build in our daily-build PPA, do you know anything about that?
[15:50] <dpm> cwayne, yeah, I can do the LP integration
[15:51] <sil2100> mmcc: e.g. https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5456833
[15:54] <cwayne> dpm, thank you!  those system-apps are where we're lacking the most atm, namely dialer, address-book, and messaging
[16:12] <dobey> sil2100: weird
[16:13] <sil2100> dobey, mmcc: filled in a bug: https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1269056
[16:13] <Laney> oh for the love of
[16:13] <Laney> where can I get at logs for telephony-service?
[16:25] <dpm> cwayne, yep. For dialer and messaging we're all set in LP, they might need a pot template update. For messaging I'll have a chat with the developer to add i18n support
[16:25] <dpm> sorry, I meant for address-book
[16:25] <Laney> boiko: ^?
[16:26] <cwayne> dpm, according to renato_ (the dev), it is setup, just not in LP
[16:26] <renato_> dpm, what do you need?
[16:27] <dpm> renato_, cwayne, a thanks let me have a look at the code
[16:27] <tvoss> tedg, hey there :)
[16:27] <renato_> dpm, there is a MR already
[16:27] <renato_> https://code.launchpad.net/~amanzi-team/address-book-app/address-book-app-pot/+merge/188549
[16:28] <renato_> just need a approval
[16:28] <renato_> let me update this
[16:28] <dpm> renato_, I just need the .pot file to be present in the po/ folder. Let me have a look at the MP
[16:30] <dpm> renato_, so I think if you could take care of that comment in the MP, we should be good to go
[16:30] <dpm> thanks
[16:30] <renato_> it is fixed already
[16:32] <renato_> dpm, ^
[16:50] <boiko> ricmm_: Saviq: have you seen this problem already:  https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1267624 ?
[16:55] <tedg> kenvandine, This is invalid now, right?  https://code.launchpad.net/~ted/content-hub/ual2/+merge/198044
[16:56] <kenvandine> oh, yeah
[16:56] <tedg> K, rejecting
[16:56] <kenvandine> thx
[16:59] <MyExHatesMeButMy> kenvandine,  hows the address-book-app  intergration of google and vcard going ?
[17:00] <kenvandine> MyExHatesMeButMy, not sure, that isn't something i'm working on
[17:00] <MyExHatesMeButMy> womp womp womp  wrong person.  I feel silly lol
[17:00] <kenvandine> no worries :)
[17:01] <MyExHatesMeButMy> kenvandine,  you are friends guy right ?
[17:01] <kenvandine> yeah
[17:01] <Laney> your friend and mine: it's keeeeeeeeeeeeeeeen vandine!
[17:01] <MyExHatesMeButMy> any news on the google plus moments going ?
[17:01] <kenvandine> :)
[17:01] <MyExHatesMeButMy> lol Laney
[17:01] <kenvandine> MyExHatesMeButMy, nope... still no API :/
[17:02] <MyExHatesMeButMy> kenvandine,  are you going to use moments with the google plus api ?
[17:02] <MyExHatesMeButMy> to post that is
[17:02] <kenvandine> moments?
[17:02] <MyExHatesMeButMy> how to write to google plus ^^
[17:02] <MyExHatesMeButMy> moments are how to write/post to google plus
[17:03] <kenvandine> is that a read/write API?
[17:03] <MyExHatesMeButMy> kenvandine,  https://developers.google.com/+/api/latest/moments
[17:03] <kenvandine> never heard of it
[17:03] <MyExHatesMeButMy> it is part of the google plus api
[17:06] <tedg> Wow, we should just upload all your ZG data to Google+.
[17:06] <kenvandine> tedg :)
[17:12] <bfiller> tedg, tvoss : do we have an alarm/timer service (or plans for one)? nik90 trying to set alarms via the clock app and I advised about using the service to fire the alarms on behalf of the ap
[17:12] <tvoss> bfiller, I don't know, tedg or charles might know best
[17:13] <nik90> tedg: also for timer and stopwatch use cases
[17:13] <tedg> bfiller, Yup, datetime does it.  There's a disconnect between the API and service.  It's scheduled for this month, I think that charles is getting to it today or tomorrow-ish.
[17:13] <tvoss> nik90, we will likely not allow that for generic timers. If an app could do that, it could escape our lifecycle policies
[17:14] <bfiller> tedg: so what API would the clock app use to set the timer?
[17:14] <tedg> (of course, it's a bug and investigation, not sure when he'll be done with it)
[17:15] <tedg> bfiller, The Alarms API, http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.Alarm/
[17:15] <MyExHatesMeButMy> tvoss,  do you know why Ubuntu Location Services slots are not connecting. and why it takes forever to work.
[17:15] <bfiller> tedg: nice, thanks, nik90 ^^^
[17:15] <tvoss> nik90, for stopwatch I don't see why you would need to hand over to a service
[17:15] <tvoss> nik90, if the app is restarted, you would have to sync to the system clock anyway, right?
[17:15] <MyExHatesMeButMy> tvoss,  like it takes 20 minutes for the service to connect
[17:15] <nik90> tedg: use the Alarms service for the clock app timer as well?
[17:15] <tvoss> nik90, for stopwatch I don't see why you would need to hand over to a service
[17:15] <tvoss> nik90, if the app is restarted, you would have to sync to the system clock anyway, right?
[17:15] <nik90> tvoss: yup and that's what It does at the moment
[17:16] <tvoss> nik90, that's fine
[17:16] <tvoss> nik90, the stopwatch does not need to inform the user, right?
[17:16] <nik90> tvoss: nope
[17:16] <tedg> nik90, Sure, I mean, we don't care when the event happens.  It's just a notification and a link back to the app.
[17:16] <bfiller> nik90: which use case do you need this for? setting a timer from the clock app right?
[17:16] <tedg> nik90, It could be 15 min from now or 4 days.
[17:17] <nik90> bfiller: that's right...the current discussion is about setting a timer from the clock app
[17:17] <bfiller> nik90: right so we'd need the alarms service for this, tvoss do you agree?
[17:18] <tvoss> bfiller, for the case of the timer: yes
[17:18] <nik90> bfiller: the thing with the alarms service is that at the moment it only triggers a snap decision. However in the case of a timer, wouldn't you want an audio notification which keeps ringing until the user turns it off?
[17:19] <tvoss> bfiller, I can think about weird situations with timers that only take 15 seconds, but as long as we have a notification and the app is only invoked on user interaction, I'm happy
[17:19] <tedg> nik90, I think we need to add sounds to that API.
[17:19] <tedg> Wait, sorry, it's already there.
[17:19] <tedg> Perhaps we just need to add a key for sound repeating.
[17:19] <bfiller> tedg, nik90 : yes I agree should be part of the api, seems the right place to put it
[17:20] <bfiller> tvoss: ack
[17:20] <tedg> http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.Alarm/#sound-prop
[17:21] <nik90> alrite, to summarise all this, the clock app will use the alarms service for timer and alarms to let the system trigger the notification appropriately.
[17:21] <bfiller> nik90: yes
[17:21] <nik90> My one concern is that the alarm page currently lists all alarms in the alarm manager provided by the API. So if I create a timer and add it to the alarm service, it will incorrectly be listed in the alarms page as an alarm
[17:22] <nik90> so I am guessing we might need to add a "type" property to avoid that I suppose?
[17:22] <tedg> nik90, I'd register two different URLs, and then filter based on that in your UI.  There'll need to be two anyway as you probably want to start at different pages in the app.
[17:23] <MyExHatesMeButMy> tvoss,  this is the error that I keep on getting know any work arounds ?  QObject::connect: No such slot QGeoPositionInfoSourceUbuntu::updateTimeout()
[17:23] <bfiller> nik90: you mean so that your app only shows alarms that it has set and not all the other system alarms?
[17:23] <tvoss> MyExHatesMeButMy, that's not an error, that's just a printf from the location provider
[17:23] <nik90> bfiller: no no ..it lists all the alarms saved in EDS through the alarms API.
[17:23] <tvoss> MyExHatesMeButMy, are you experiencing any issues?
[17:24] <MyExHatesMeButMy> tvoss,  yes GPS is not working it takes like 20 minutes for it to work
[17:24] <nik90> bfiller: however since the plan is to registers timers as alarms using the alarms API, wouldn't it appear in the alarm page incorrectly
[17:24] <tvoss> MyExHatesMeButMy, sure, that's expected. We only consider the raw gps sensor at this point, and a cold start can take that long if satellity visibility is bad
[17:24] <MyExHatesMeButMy> tvoss,  I have to keep my app open for like 20 minutes before the GPS kicks in and starts to work
[17:24] <tvoss> MyExHatesMeButMy, see my note before
[17:25] <MyExHatesMeButMy> tvoss,  why ?
[17:25] <MyExHatesMeButMy> why = We only consider the raw gps sensor at this point,
[17:25] <tvoss> MyExHatesMeButMy, that's just the way gps works, see http://en.wikipedia.org/wiki/Time_to_first_fix
[17:25] <tvoss> MyExHatesMeButMy, we are working on adding assisted gps support. Until then, we only provide raw gps readings
[17:26] <MyExHatesMeButMy> tvoss,  what is it tht meegoo or symbian did because that works right out the bat so to say. just trying to learn here
[17:26] <MyExHatesMeButMy> thanks for your time by the way tvoss  I know that you are busy
[17:27] <bfiller> nik90: I think you are right, maybe tedg's suggesting would work
[17:28] <popey> MyExHatesMeButMy: I mentioned this yesterday, we don't have AGPS yet
[17:28] <tvoss> MyExHatesMeButMy, that's also assisted gps, the gps chipset talks to a so-called SUPL server to download ephimeris and almanac data over a fast network connection instead of downloading it from the satellites. For that to work, the gps chipset needs an initial position estimate which is most often calculated from visible wifis and visible radio cells/towers
[17:28] <nik90> bfiller, tedg: +1
[17:28] <MyExHatesMeButMy> popey,  I know I am just trying to learn about "Why this is happening "  that is it
[17:29] <nik90> bfiller: but to the update the UI in the clock app itself to indicate that the timer is runing, I will be using a QML Timer like now.
[17:29] <MyExHatesMeButMy> tvoss,  cool I understand now
[17:30] <MyExHatesMeButMy> tvoss,  with  AGPS this will still work with qtlocation ?  and will be inside or Ubuntu Location Service ?
[17:30] <nik90> bfiller: so when the timer ends, you will one indication in the clock app ui that the timer is complete and a snap decision triggered by the system.
[17:30] <MyExHatesMeButMy> tvoss,  or new classes ?
[17:30] <bfiller> nik90: makes sense
[17:31] <tvoss> MyExHatesMeButMy, yup, it's completely transparent to apps, if you start using qtlocation now, and once we land agps support, you don't have to change anything and will just be provided with faster fixes
[17:31] <tvoss> MyExHatesMeButMy, and yes, the changes will be made in the location service
[17:31] <MyExHatesMeButMy> cool
[17:32] <MyExHatesMeButMy> tvoss, Is there blueprints/work flow ect  for this << last question
[17:32] <tvoss> MyExHatesMeButMy, I would need to dig that up, there once was one, but it might be out of date
[17:33] <MyExHatesMeButMy> thanks
[17:34] <tvoss> MyExHatesMeButMy, yw :)
[18:07] <kenvandine> MyExHatesMeButMy, that moments API isn't useful for creating a G+ app or adding it to friends
[18:08] <kenvandine> it only lets you list, insert and remove moments created by the app
[18:08] <kenvandine> so you wouldn't be able to see your feed for example
[18:08] <MyExHatesMeButMy> kenvandine,  what do you mean by see your feed ?
[18:09] <kenvandine> for example, in the g+ android app you see a stream of everything from people in your circles
[18:09] <kenvandine> the moments api only gives you access to moments created by that app
[18:10] <kenvandine> there is also the activities api, which is more like what we want but it isn't really useful
[18:10] <kenvandine> because you get a stream of activities for each user
[18:10] <MyExHatesMeButMy> kenvandine,  maybe you are looking for just get ?
[18:10] <kenvandine> but there is no api for getting a list of people in your circles
[18:10] <MyExHatesMeButMy> for that there is other things like People and what not
[18:11] <kenvandine> you can't get the people in your circles though
[18:11] <kenvandine> you need that list in order to construct anything meaningful
[18:12] <kenvandine> google has left out the most critical piece of the api, which prevents someone from creating a real g+ client
[18:12] <MyExHatesMeButMy> kenvandine,  I am not that good with the api yet but Let me look into it I think that you are going to have to use contacts dev but let me look into it
[18:12] <kenvandine> it's been reverse engineered... but i wouldn't be willing to maintain any code using that
[18:13] <kenvandine> google has intentionally left that out, and have stated they have no plans on adding it
[18:13] <kenvandine> contacts isn't the same as circles
[18:13] <MyExHatesMeButMy> kenvandine,  https://developers.google.com/+/domains/api/circles/list
[18:14] <kenvandine> that does look interesting
[18:15] <MyExHatesMeButMy> kenvandine, :P
[18:15] <kenvandine> i wonder when this was added...
[18:16] <kenvandine> i haven't looked in a while... but after hearing dozens of times that they wouldn't add it... i gave up :)
[18:17] <MyExHatesMeButMy> kenvandine,  a while ago BTW i have a QNetworkrequest that buildsQAbstractListModels for most of it
[18:17] <MyExHatesMeButMy> now sure how  that would work for libdee though
[18:18] <MyExHatesMeButMy> kenvandine,  friends uses dee ?
[18:18] <kenvandine> yup
[18:19] <kenvandine> there is dee-qt
[18:19] <kenvandine> MyExHatesMeButMy, where's your code?
[18:20] <MyExHatesMeButMy> on my computer
[18:22] <dobey> can you actaully read things on g+ that aren't public now, through the api?
[18:23] <kenvandine> dobey, in the past you could if you know the id of the person
[18:23] <kenvandine> authenticated of course
[18:23] <MyExHatesMeButMy> dobey,  you could read for a long time
[18:23] <kenvandine> the problem was you couldn't get a list of people in your circles
[18:23] <MyExHatesMeButMy> kenvandine,  correct I use oauth2
[18:23] <kenvandine> so you could really only get content you posted yourself :)
[18:23] <MyExHatesMeButMy> because I dont know how to use Ubuntu's implementation so I wrote my own
[18:24] <kenvandine> ages ago they stated they had no plans on adding that
[18:24] <kenvandine> you should use the google accounts plugin :)
[18:24] <MyExHatesMeButMy> How to get access key and refresh key ect ? kenvandine
[18:25] <kenvandine> http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.OnlineAccounts/
[18:25] <kenvandine> there are C and C++ APIs too
[18:26] <MyExHatesMeButMy> cool is threre also different scopes(google ones) that they are using for say email openid plus.google.com/me ect
[18:26] <MyExHatesMeButMy> kenvandine,  I wrote one
[18:27] <MyExHatesMeButMy> kenvandine,  https://code.launchpad.net/~josephjamesmills/+junk/OAuth_Playground
[18:27] <MyExHatesMeButMy> see how you can set clientid and seceret and scopes and what not from  QML
[18:27] <MyExHatesMeButMy> now sure if that is a good idea lol
[18:29] <MyExHatesMeButMy> kenvandine,  example http://paste.ubuntu.com/6751843/
[18:30] <MyExHatesMeButMy> not sure Why I put a property in there of runOauth . must have been testing stuff
[18:32] <MyExHatesMeButMy> kenvandine,  for the models and what not I just ported this and exposed to QML for models and what not.  https://code.google.com/p/qt-google-plus/
[18:37] <dineshweb> hi all. is it possible that we can install ubunt on htc viva devices?
[18:40] <annerajb> dineshweb, is there cyanogenmod for that device?
[18:41] <dineshweb> let me check...
[18:45] <kalikiana> dobey: your example was very helpful to get started on the UbuntuOne API. though I discovered a somewhat tricky bug https://bugs.launchpad.net/ubuntuone-credentials/+bug/1269097
[18:48] <dobey> kalikiana: it doesn't disable it
[18:48] <kalikiana> it does. I can't even see qml syntax errors
[18:49] <dobey> kalikiana: nope. it's just dumping them to a file ~/.cache/ubuntuone/log/authentication.log
[18:50] <dobey> kalikiana: but i marked your bug as a dup of the pre-existing report
[18:51] <kalikiana> dobey: they end up there in addition to console if I use U1_DEBUG=1 - if not they're completely dropped
[18:53] <dobey> kalikiana: qml is using debug() for errors?
[18:59] <kalikiana> dobey: I'm not sure what's used for syntax errors, but they are disabled the same as qWarn, qDebug and console.log → interestingly qWarn is not even visible with U1_DEBUG=1
[19:00] <kalikiana> dobey: maybe syntax uses qWarn because I cannot see syntax errors either with U1_DEBUG
[19:03] <kalikiana> hmm found the QML errors in the .log file
[19:06] <kalikiana> Commented on the bug. Gotta go
[19:38] <dobey> how does one mark API as deprecated in qt/c++?
[20:41] <tedg> kenvandine, So why are you using g_strdup_printf() instead of just g_strdup()?
[20:42] <tedg> kenvandine, Also the symbols file needs to be the 0replaceme thing for the release scripts.
[20:49] <kenvandine> oh silly me... in one place i was building the string so g_strdup_printf made sense
[20:49] <ajalkane> is ppa:autopilot/1,4 available for saucy now?
[20:49] <kenvandine> tedg, i'll fix that
[20:52] <kenvandine> tedg, pushed
[20:54] <tedg> kenvandine, Cool, thanks!
[20:54] <nik90> ajalkane: looking at https://launchpad.net/~autopilot/+archive/ppa?field.series_filter=saucy, it seems there is autopilot 1.4 for saucy. However autopilot-qt is still at 1.3.
[20:54] <nik90> tedg: replied to your MP comments
[20:55] <ajalkane> nik90: hmm... and no doubt the qt module is needed for Qt apps
[20:56] <nik90> ajalkane: yup :/
[20:56] <nik90> ajalkane: although why dont you add the autopilot 1.4 experimental PPA for saucy
[20:56] <nik90> that's what I have on my 13.10 system
[20:56] <ajalkane> nik90: I had dependency problems when I tried upgrade
[20:57] <thomi> there's a dependency issue for saucy. veebers is the person to hassle for that :)
[20:57] <thomi> otherwise... consider upgrading to trusty maybe? :)
[20:57] <nik90> ajalkane: yeah I noticed that it kept back autopilot-desktop
[20:57] <nik90> ajalkane: but I just left it like that for a long time :)
[20:57] <ajalkane> I can upgrade to trusty, but I'd rather stay on stable if I have a choice
[20:58] <nik90> thomi: what ajalkane said ^^
[20:58] <ajalkane> nik90: I had more hairy dependency problems
[20:58] <ahayzen> nik90, i heard the autopilot 1.4 fix is in the works for saucy
[20:58] <nik90> ahayzen: oh that's nice
[20:58] <veebers> ajalkane: hi, I intend to get that sorted today (the saucy dep issue)
[20:59] <ahayzen> nik90, thts wht i think balloons said ... i just run it on device anyway
[20:59] <ajalkane> veebers: alright great... is that the 1.4 ppa or experimental where it'll be available?
[21:00] <balloons> veebers is the man for the ap 1.4 + saucy goodness :-)
[21:00] <nik90> ahayzen: hey btw, can you verify if running autoremove on your system results in http://paste.ubuntu.com/6752555/
[21:00] <veebers> ajalkane: experimental will be trunk, 1.4 will be the release candidate (lp:autopilot/1.4)
[21:00] <ajalkane> ok, I'll try again 1.4 after tomorrow. Good luck :P
[21:01] <nik90> veebers: oh I have been running the experimental until now on saucy. May be I should move to the autopilot/1.4 ppa for safety measures
[21:01] <ahayzen> nik90, http://pastebin.ubuntu.com/6752567/
[21:02] <nik90> ahayzen: so it is removing the cordova plugin cordova-ubuntu-2.8-dev qtcreator-plugin-ubuntu-cordova-common
[21:02] <veebers> nik90: the 1.4 ppa is only recent, the idea being the releases reside in the relevant ppas and experimental is trunk
[21:02] <ahayzen> nik90, yep it wants to :)...at least not the ubuntu-sdk anymore
[21:11] <nik90> tedg: can I top approve your MP? Anything to add?
[21:14] <tedg> nik90, Nope, that works for me!
[21:19] <sergiusens> veebers, hey, is my MR doing alright? :-)
[21:24] <jdstrand> xnox: hey-- I just regenerated my emulator, but it keeps hanging. the wiki says to keep trying-- how many times is typical to have to retry?
[21:31] <veebers> sergiusens: heh, sorry have been delayed as other things. I'm just in the process of approving it. Sorry for the delay :-)
[21:32] <sergiusens> np
[21:33] <sergiusens> the landing to trunk is a week away; but it's the second time I create this MR ;-)
[21:39] <cowbuff> hei, probaly a noob questin.. but is it posible to install it on galaxy note 3 ?
[21:51] <cwayne> cyphermox: ping
[21:53] <cwayne> cyphermox: there's a question on the systemd MR questioning what the benefit is of going that route rather than the simple hciconfig upstart job we were considering before (quite a fair point imho), could you shed some light on why having hostnamectl working properly is beneficial?
[21:53] <cwayne> https://code.launchpad.net/~cwayne18/ubuntu/trusty/systemd/symlink-support-hostnamed/+merge/201540/comments/469490 ^
[22:10] <cyphermox> cwayne: thanks, I commented
[22:11] <cwayne> cyphermox: thanks, i figured you'd have a lot more info than I do :)
[22:26] <tedg> thomi, This GIR support looks good to me, but it's hard to tell without programming against it.  Can you take a look?  https://code.launchpad.net/~ted/upstart-app-launch/gir-support/+merge/201681
[22:26] <thomi> tedg: sure thing - it'll probably be this afternoon, but I'll email you before my EOD
[22:27] <tedg> thomi, I'm on vacation by your EOD, so take your time :-)
[22:27] <thomi> heh, ok - for how long for?
[22:27] <tedg> thomi, Next week.  I guess your Wed.
[22:27] <thomi> tedg: OK. who else can I talk to to get this merged & released while you're away?
[22:27] <tedg> thomi, You can talk to charles
[22:28] <thomi> tedg: ok, awesome - thanks for your help
[22:28] <tedg> NP
[23:17] <KathyReid> Morning everyone
[23:17] <KathyReid> I was chatting with mhall119 yesterday and he explained a bug I think there is in touch
[23:18] <KathyReid> when you download an update and then click Install and Restart it fails with 'failed to download a file'
[23:18] <KathyReid> So, I reflashed my Nexus 4
[23:18] <KathyReid> but it wanted to update to version 121 again over the air
[23:18] <KathyReid> and the same problem occurred
[23:18] <KathyReid> is there a) a workaround for this or b) another way to update to version 121?
[23:33] <a_muva_> KathyReid: try adb shell; sudo apt-get update; sudo apt-get dist-upgrade
[23:35] <cwayne> KathyReid: noo, dont do that
[23:35] <cwayne> doing apt updates could work, but it will break the upgrade path, and is generally considered not good to do
[23:36] <a_muva_> works for me
[23:38] <popey> I'd use system-image-cli
[23:38] <popey> adb shell system-image-cli --channel trusty -b 0
[23:39] <KathyReid> will that get me to version 121?
[23:39] <popey> yes
[23:40] <popey> or you can do it from your pc
[23:40] <popey> phablet-flash ubuntu-system --channel=trusty
[23:40] <popey> well, both commands should be run from your ubuntu pc
[23:44] <KathyReid> that's the command I used yesterday to flash the Nexus 4
[23:44] <KathyReid> then after flashing, when I checked for updates, it wanted to upgrade to version 121
[23:45] <KathyReid> a 310mb download later, and the install failed
[23:45] <KathyReid> so I'd rather not try that again
[23:45] <popey> odd, 121 is the latest
[23:45] <KathyReid> is there a switch I can use to force it to flash with 121?
[23:45] <popey> KathyReid: what does this return:- "adb shell system-image-cli -i"
[23:45] <popey> (it should tell you the version your phone is running)
[23:45] <KathyReid> popey: checking now
[23:46] <popey> http://paste.ubuntu.com/6753337/
[23:46] <popey> thats what I get
[23:48] <KathyReid> http://paste.ubuntu.com/6753342/
[23:48] <KathyReid> looks like version 78 :(
[23:49] <KathyReid> ah something is clearly not right with flashing it from the trusty channel
[23:49] <KathyReid> I will try again
[23:49] <popey> are you certain you used the command I mentioned?
[23:50] <popey> 78 is probably saucy, not trusty
[23:50] <KathyReid> (big thanks popey for that -i switch to find out which version it's running)
[23:50] <popey> np
[23:50] <popey> https://wiki.ubuntu.com/Touch/Install#Further_Examples
[23:50] <popey> that page is handy
[23:50]  * KathyReid bookmarks that page
[23:51] <popey> but yeah, "phablet-flash ubuntu-system --channel=trusty" would be my recommendation
[23:51]  * popey goes to bed.. good luck!
[23:54] <KathyReid> popey: thx heaps