[06:04] <Jef91> Where I can find a list of what current hardware support is like for Ubuntu touch on the NExus 4?
[06:24] <duflu> Jef91: Perhaps https://wiki.ubuntu.com/Touch/Devices
[06:26] <Jef91> duflu, for refernce it is here https://docs.google.com/spreadsheet/ccc?key=0ArLs7UPtu-hJdDZDNWliMmV1YUJ3Zk1pQlpDdGp4VFE&usp=sharing#gid=0
[08:09] <dholbach> good morning
[08:34] <sil2100> stgraber: hey! Do you know if your recent lxc upgrade could have caused the boot-up problems on touch devices by any chance?
[09:46] <markstar> Is Ubuntu not available for nexus 6 yet?
[09:51] <ogra_> not until someone does a port
[09:56] <markstar> Is a really big task o
[09:56] <markstar> Porting?
[10:02] <JamesTait> Good morning all; happy Friday, and happy Handwriting Day! :-D
[11:09] <GAM002> anyone here?
[11:09] <GAM002> i have a doubt
[11:10] <davmor2> GAM002: yes there are people here
[11:10] <GAM002> i am currently using ubundu 12.04 my internet is very slow so is which can help me save bandwidth? upgrading to 14.04 or downloading 14.04 and using it to ugrade and how much MB will the upgrade be?
[11:11] <GAM002> anyone?
[11:12] <davmor2> GAM002: Not sure I understand the question but the best place for things like that would be the #ubuntu irc channel this is a channel for touch development
[11:12] <GAM002> ook
[11:13] <GAM002> i ment how much MB will be needed to upgrade from ubuntu 12.04 to 14.04?
[11:13] <GAM002> and please share the ubuntu irc link please
[11:14] <GAM002> davmor2
[11:14] <GAM002> :
[11:15] <davmor2> GAM002: just type /join #ubuntu
[11:15] <GAM002> ok it worked thanks
[11:17] <sidharth> um hi
[11:17] <davmor2> sidharth: hello
[11:17] <sidharth> I have reached here after browsing a bit about contributing to ubuntu
[11:18] <sidharth> So I need some help on how to get started
[11:19] <davmor2> sidharth: started on what?
[11:19] <sidharth> Oh and this is my first time ever on an IRC.
[11:19] <sidharth> starting to work on ubuntu
[11:28] <mzanetti> hmm... does the current devel-proposed boot for you guys?
[11:28] <mzanetti> seems stuck here on my Nexus 4
[11:28] <Elleo> mzanetti: nope, image 74 is broken
[11:28] <mzanetti> ah. thanks
[11:40] <Elleo> mandel: heya; haven't fully finished testing the UDM stuff yet, but the data URIs with http:// URLs added to them raised a few red flags with me, so I dug into that deeper and it turns out to be a bug in the way oxide is passing data URIs to the webbrowser: https://bugs.launchpad.net/oxide/+bug/1413964
[11:41] <Elleo> mandel: I'm think it might be best to label the http:// stuff in that branch as a workaround for this bug for now, and then remove it once the oxide folks have time to fix things on their end (since I'm guessing that won't be able to happen for RTM)
[11:41] <Elleo> thinking*
[11:41] <Elleo> mandel: what're your thoughts?
[11:44] <mandel> Elleo, I did notice that was not correct and was not part of the uri format, the way I fixed it is by checking the contains ('data:') instead startswith and do a split on it.. is certainly a hack
[11:44] <mandel> Elleo, I can add a #HACK comment to make sure that we deal with it
[11:44] <Elleo> mandel: okay, cool
[11:45] <Elleo> mandel: yeah, just so long as we remember to remove it once oxide is doing the right thing I think it's okay
[11:45] <mandel> Elleo, I'll add udm to that bug, sounds good?
[11:45] <Elleo> mandel: yep
[11:46] <Elleo> mandel: as far as the code goes otherwise it all looks good to me, I'm just going to run through all the browser download tests to be safe, then I think we'll be good to go :)
[11:47] <mandel> Elleo, sweet, I have downloaded several images (thumbnails) and works as expected, what is nice is that it was fixed only in the udm service side so no need to rebuild anything
[11:48] <Elleo> mandel: yeah :)
[11:48] <mandel> Elleo, let me know your feedback and I'll request a silo etc..
[11:49] <Elleo> mandel: sure, should be done with browser/content-hub tests in a few minutes
[11:49] <mandel> superb
[11:57] <Elleo> mandel: all looks good, if you just update the branch with a comment about the underlying bug I'll go ahead and approve it :)
[11:57] <mandel> Elleo, ack
[11:59] <mandel> Elleo, pushed
[11:59] <mandel> rev 340
[12:01] <Elleo> mandel: great, approved :)
[12:08] <mardy> davmor2: hi! I'm trying to reproduce bug 1413655, and now the phone seems to be stuck on the Google logo
[12:09] <mardy> davmor2: did you also have to wait a long time?
[12:09] <davmor2> mardy: yeap
[12:09] <mardy> davmor2: OK, I'll just keep waiting then
[12:09] <davmor2> mardy: the apparmour profile it all to cock
[12:12] <Justcarakas> dholbach sorrt for the bad revieuw on your app, after closing it and reopening it it worked, but i cant update my rating
[12:12] <Justcarakas> *sorry
[12:13] <dholbach> Justcarakas, and I thought we were friends!
[12:13]  * dholbach storms out
[12:13] <dholbach> Justcarakas, interestingly enough... the same thing happened for popey
[12:13] <dholbach> dbarth, alexabreu: so it looks like for two folks, starting a webapp works only on the second time
[12:14] <Justcarakas> hehe, wel so it wasnt just me :D ps, you are likable
[12:14] <dholbach> dbarth, alexabreu: can you try to install "roll a dice" from the store and see if it works on the first launch?
[12:14] <dholbach> Justcarakas, thanks for the flowers :)
[12:51] <alexabreu> dholbach, trying
[12:52] <dbarth> dholbach: webapp, or html5 one?
[12:52] <dholbach> dbarth, html5
[12:52] <dbarth> ah
[12:52] <alexabreu> dholbach, ah this is not a webapp then
[12:52] <dholbach> sorry, yes, it's html5
[12:52] <dholbach> is this a known issue?
[12:53] <dbarth> not really; i've seen that in a silo, but that one had not landed since
[12:53] <dholbach> can you reproduce it thought?
[12:53] <dholbach> though
[12:53]  * dbarth installs roll a dice
[12:54] <alexabreu> dholbach, dholbach yes
[12:54] <alexabreu> dholbach, the first time I open it it spins, and does not ... but all subsequent tries work
[12:55] <dholbach> alexabreu, shall I file a bug about it?
[12:56] <dbarth> dholbach: yes, please
[12:56] <dbarth> alexabreu: reproducing on rtm or vivid ?
[12:56] <alexabreu> dbarth, rtm
[12:57] <dbarth> alexabreu: starts find on first try here on vivid
[12:57] <dbarth> fyi
[12:58] <dholbach> dbarth, alexabreu: https://bugs.launchpad.net/ubuntu-html5-theme/+bug/1413986
[12:58] <mardy> davmor2: it's still there at the Google prompt, it's about 1 hour now...
[12:58] <mardy> davmor2: was it *taht* long?
[12:59] <davmor2> mardy: ah crap sorry latest vivid image is broken see the phablet mailing list
[12:59] <alexabreu> dholbach, dbarth silo 13 might make it work
[12:59] <dbarth> what's the hang about?
[13:00] <ogra_> dbarth, lxc broke
[13:01] <davmor2> mardy: ^ sorry dude I forgot all about the broken image
[13:03] <mardy> davmor2: oops, you are right
[13:03] <dholbach> would it possible to have some very basic preliminary automated testing for -proposed images? like "does it boot"?
[13:04] <dholbach> I'm just wondering if that's possible because I've seen a couple of "warning: does not boot" messages on the phone list in the last weeks
[13:18] <rickspencer3> did I read that one of the proposed images last night/this morning was busted?
[13:21] <ogra_> yes
[13:21] <ogra_> vivd though
[13:51] <sergiusens> ogra_: do we have a root cause already?
[13:52] <sergiusens> dholbach: in general, people aren't supposed to be using -proposed, and ci does have tests running
[13:52] <ogra_> sergiusens, lxc it seems
[13:53] <sergiusens> dholbach: http://ci.ubuntu.com/smokeng/vivid/touch/
[13:53] <sergiusens> dholbach: people running proposed should always check the ci results before upgrading
[13:54] <sergiusens> if not we will have a quality gate for proposed called proposed-proposed :-P and then people will use that and so on and so forth :-)
[13:54] <ogra_> "people" should never run proposed
[13:54] <ogra_> developers should ... on development devices
[13:54] <sergiusens> ogra_: exactly
[13:55] <sergiusens> let me rephrase
[13:55] <sergiusens> consumers shouldn't run it; developers should (but also know how to get out of it easily)
[13:55] <ogra_> there is work going on to switch to a three channel model
[13:55] <ogra_> one daily, one with a weekly promotion ... one with monthly promotions
[13:55] <sergiusens> ogra_: I know where that is coming from :-)
[13:56] <ogra_> dogfooders should use the dsecond
[13:56] <ogra_> devs the first
[13:56] <ogra_> everyone else the last
[13:56] <ogra_> and even then it isnt guaranteed to be bugfree if you use the development release
[13:56] <sergiusens> ogra_: I like it that you are driving most of this
[13:56] <ogra_> since it is a development release :)
[13:56] <ogra_> :)
[13:57] <didrocks> or if the integration tests were reliable, you can have a step before the -proposed is published (and so, no-one is supposed to use that image until it's published to -proposed)
[13:57] <ogra_> well, slangasek is driving it more than me
[13:57] <ogra_> but i'm involved, yeah
[13:57] <ogra_> didrocks, well, i would like to have a channel where you can just quickly push a package with debug enabled
[13:58] <ogra_> so i wouldnt want proposed to be actually guarded
[13:58] <didrocks> ogra_: maybe the set of tests could be small, like "does it boot, can I do a phone call"
[13:58] <ogra_> that guarding should happen between proposed and the weekly channel instead
[13:58] <didrocks> ogra_: so, 10 minutes of tests, and then, "publishing to -proposed" is just a 1 min switch, changing symlinks
[13:59] <dholbach> sergiusens, I wasn't trying to blame anyone
[13:59] <didrocks> to ensure devs always have a working phone at least
[13:59] <dholbach> but I think it saves a lot of energy if we had something which tested a -proposed image for bootability
[13:59] <dholbach> as far as I'm concerned.. what a consumer should run is a different question :)
[13:59] <sergiusens> dholbach: oh, I know; I didn't take any blame :-P
[14:00] <sergiusens> dholbach: I was just trying to explain what's currently there
[14:00] <dholbach> sure
[14:00] <ogra_> right, we're all aware that what we have is suboptimal atm
[14:00] <ogra_> and all actual ressources go into rtm
[14:01] <dholbach> ok... do you think it would be hard to have a bootability check for -proposed images? :)
[14:01] <sergiusens> ogra_: that will change next month I hope
[14:01] <ogra_> dholbach, thats a question for CI ...
[14:01] <sergiusens> dholbach: it's not the bootability check, it's the ci infra that is the problem
[14:01] <sergiusens> dholbach: because they consume from that same channel to check tha
[14:01] <sergiusens> t
[14:01] <ogra_> you need free devices to run the test and a setup that actually runs it ... and that needs to be hooked into the build process
[14:01] <sergiusens> dholbach: so the solution is what ogra_ says, a third channel
[14:02] <dholbach> ok
[14:02] <ogra_> while there are build process/promotion process changes needed, these are the last bits, we first need working infra to hook into
[14:02] <sergiusens> dholbach: but given how hard it is to change the backend, this isn't a one day operation (why that is I don't have the answer for ;-) )
[14:03] <dholbach> ogra_, would it be possible to take the same image and boot it in kvm or something beforehand?
[14:04] <ogra_> that would tell you the x86 kvm image works, yeah
[14:04] <ogra_> but wont tell you much about the armhf $device one
[14:04] <dholbach> hum, right
[14:04] <ogra_> our emulation in touch is to far off from the actual devices
[14:10] <kenvandine> anyone know how to recover after upgrading to #82 from devel-proposed on krillin?
[14:11] <kenvandine> i flashed to #81, which seems to fail
[14:11] <kenvandine> doesn't even try booting
[14:13] <popey> kenvandine: can you use ubuntu-device-flash to go back to 81?
[14:13] <kenvandine> nope
[14:13] <kenvandine> that's what i did
[14:13] <popey> ubuntu-device-flash --channel=ubuntu-touch/ubuntu-rtm/14.09-proposed --revision=81
[14:13] <kenvandine> just get the warning screen that i have to use a PC to restore the phone
[14:13] <popey> like that?
[14:13] <popey> erk
[14:13] <popey> dunno, sorry.
[14:13] <kenvandine> :(
[14:14] <popey> might have to --wipe and lose stuff
[14:14] <kenvandine> yeah... can't do that right now
[14:14] <kenvandine> or don't want to
[14:14] <dholbach> popey, was bug 1413986 for you on vivid or rtm?
[14:14] <popey> dholbach: rtm
[14:14] <kenvandine> it's currently my daily driver... don't want to set it all up again right before the weekend
[14:14] <popey> kenvandine: fwiw, I rsync my entire home off the phone daily to another machine as a backup
[14:14] <kenvandine> must be a way to get it booting again
[14:15] <popey> you may be able to adb pull your home directory when in recovery mode
[14:15] <kenvandine> popey, do that restore all your accounts nicely?
[14:15] <popey> and wipe and put it back
[14:15] <popey> yeah.
[14:15] <popey> everything worth keeping is in /home
[14:15] <popey> and all my music is on an sd card.
[14:16] <dholbach> thanks popey
[14:17] <popey> so utopic
[14:21] <l3on> Hi .. I have a question about this slide: https://docs.google.com/presentation/d/1-OcIOjMSdiLI6JdBbuhobKkxdZRaaggeA-eSOoA5cnE/edit#slide=id.g3910e7ce9_2_31
[14:22] <l3on> can we assume that when we talk about "Android layer" in the image is the "Ubuntu middleware block" ?
[14:22] <sergiusens> kenvandine: krillin is your daily driver? On edge? :-P
[14:22] <kenvandine> sergiusens, yes... sad panda
[14:22] <kenvandine> sergiusens, but... i wanted to use it as much as possible
[14:23] <kenvandine> and...
[14:23] <sergiusens> kenvandine: so go into recovery and ...
[14:23] <kenvandine> voice calls suck on mako
[14:23] <l3on> or andoird part is in the HAL ?
[14:23] <sergiusens> kenvandine: really?
[14:23] <kenvandine> my wife feels like she's talking to a machine when i use it
[14:23] <kenvandine> yeah... pulseaudio bug i think
[14:24] <sergiusens> kenvandine: ok, in recovery tar up /data/system-data/ and /data/user-data/; that's all your data
[14:24] <popey> l3on: yes
[14:25] <sergiusens> kenvandine: --preserve-permissons and all that
[14:25] <popey> l3on: the android layer is the bit broken out on the right
[14:26] <l3on> popey, but .. there I read "Network Manager" .. I thought that part was only Ubuntu related, no the Android one ...
[14:27] <l3on> anyway .. I assume that the adroid layer is in "Ubuntu Middleware" block
[15:18] <dobey> mardy: hi. do you know how to force the permission denied error when accessing account credentials, on rtm, without signon-apparmor-extension?
[15:21] <mardy> dobey: some operations will fail if the ACL is empty, but now I'm not sure of which
[15:23] <mardy> dobey: if you don't care about messing up your accounts, you could run a "DELETE FROM ACL;" in ~/.config/signond/signon.db
[15:25] <dobey> alexabreu: ^^
[15:33] <dobey> oh doh
[15:33] <dobey> not alexabreu
[15:33] <dobey> alecu: ^^
[15:34] <alexabreu> :)
[15:34] <alecu> great
[15:38] <alecu> dobey: after deleting all the ACLs, pay-ui still works perfectly in rtm
[15:42] <dobey> mardy: ^^ any other ideas? alecu isn't confident about landing my branch in rtm, without being able to recrete the error there :-/
[15:48] <mardy> dbarth: the seed change for the apparmor extension, is it in a silo?
[15:50] <dobey> mardy: we're adding it back into rtm?
[15:50] <mardy> dobey: sure
[15:51] <mardy> dobey: if it's something siloable, it would be nice to land it together with your fix
[15:51] <mardy> dobey: if not, then I think that alecu should just verify that there are no regression with your changes, and maybe verify that they fix the issue when the extension is installed
[15:52] <dobey> i think it might not be available to install in rtm at the moment
[15:52] <dobey> but the exact same changes are already verified/landed in vivid
[15:52] <dobey> and it does fix it there
[15:52] <mardy> dobey: it should be also in rtm, afaik
[15:54] <dobey> oh, so it is
[15:56] <alecu> mardy: what's the name of that package?
[15:56] <dobey> signon-apparmor-extension
[15:56] <ted> popey, I've been delighted with your restraint. When I wrote the kickstarter scope I was afraid Ms. Popey was going to hunt me down. :-)
[15:56] <dobey> https://launchpad.net/ubuntu-rtm/+source/signon-apparmor-extension
[15:56] <dobey> alecu: ^^
[15:57] <popey> ted: there's a kickstarter scope? :)
[15:58] <kenvandine> popey, feeding the addiction?
[15:58] <popey> yeah :S
[15:58] <popey> have you seen the oatmeal kickstarter?
[15:58] <kenvandine> haha
[15:58] <kenvandine> no... no i haven't
[15:58]  * ted goes back into the bunker to hide from Ms. popey
[15:58] <popey> https://www.kickstarter.com/projects/elanlee/exploding-kittens
[15:58] <popey> its gone MAD
[15:58] <kenvandine> OMG
[15:58] <popey> you should totally back it
[15:59] <kenvandine> in 20 minutes...
[16:00] <alecu> dobey: ok, that one *is* available to be installed. But it's not installed on rtm/devel-proposed
[16:01] <dobey> alecu: right, it is not installed by default on rtm currently
[16:01] <alecu> ok, I'll try installing it, to see if explodes like a kitten
[16:05] <kenvandine> mandel, how do we run the test update server in your check-hash branch?
[16:06] <mandel> kenvandine, in the middle on a long meeting, I'll get back to you asap
[16:06] <mandel> sorry :-/
[16:06] <kenvandine> mandel, no worries
[16:10] <mhall119> has anyone else noticed the gallery showing videos as being on a different day from picture, when they are taken at the same time?
[16:23] <dbarth> mardy: nope; it's on ogra's radar
[16:23] <dbarth> mardy: i have a merge prop here https://code.launchpad.net/~dbarth/ubuntu-seeds/ubuntu-touch.utopic-signon-apparmor-extension/+merge/247315
[16:24] <ogra_> dbarth, after my last meeing (in ~1.5h) i'll prepare a PPA with the piled up seed changes
[16:32] <mandel> rsalveti, https://bugs.launchpad.net/ubuntu/+source/ubuntu-download-manager/+bug/1413584
[16:33] <ogra_> jodh, during a review of the user-session logs we just noticed that we seems to get gigantic logs from some apps ... is there any switch we could set to globally turn off logging for the upstart session ?
[16:35] <ted> ogra_, We could set console none for the application jobs… but it seems we want *some* logs, no?
[16:36] <pmcgowan> ogra_, we were just discussing https://bugs.launchpad.net/ubuntu/+source/logrotate/+bug/1385464
[16:36] <jodh> ogra_: coincidentally, I just mentioned this to pmcgowan... if someone could sync ./debian/user-conf/logrotate.conf from lp:ubuntu/upstart to the upstart package used on touch, you'll suddently find that ~/.cache/upstart/ shrinks a lot! (see bug https://bugs.launchpad.net/ubuntu/+source/logrotate/+bug/1385464)
[16:37] <ogra_> ted, why would we ... i think we would like some automation "app has crashed once, then switch on logging" ... for apps that behave we dont want to write more to disk than actually needed to have the app running
[16:37] <jodh> ogra_: pmcgowan: I had ~38M of log files and with the updated logrotate upstart job that dropped to 3.5M.
[16:37] <ogra_> joi have 563M
[16:38] <ogra_> jodh, ^^^
[16:38] <ogra_> the gzipped ones are all below 200k ...
[16:38] <ted> ogra_, I'm not sure that we can be fine grained to say "this app vs. that app" so it's kinda a global on/off for all apps.
[16:38] <jodh> ogra_: pmcgowan: it's still not clear _what_ is actually corrupting thte logrotate status file, but the latest ./debian/user-conf/logrotate.conf detects it and forces a logrotate.
[16:38] <ogra_> the unzipped ones that are actually in use go up to 80M
[16:38] <ogra_> ted, yeah, thats more "future thinking"
[16:39] <ogra_> jodh, when
[16:39] <ted> ogra_, I'm sure systemd has six options for it :-)
[16:39] <ogra_> jodh, my unity8 log for the current session is 80M
[16:39] <jodh> ogra_: wowzers! :)
[16:39] <ogra_> it prints a few lines for every gesture
[16:39] <ogra_> or touch ...
[16:40] <ted> Someone needs to port g_debug()'s disable/enable logic to qDebug()
[16:40] <kenvandine> mandel, ok, i installed your branch and updates work :)
[16:40] <jodh> ogra_: can't we get that toned down a bit? constant i/o like that???
[16:40] <ogra_> other session jobs look similar ... not *as* big ... rather in the 10-20M but still
[16:40] <kenvandine> mandel, but i'm not sure how to verify it did a check
[16:41] <mandel> kenvandine, exactly, I have t give you the instructions to make it fail and see the error, sorry, in the meeting
[16:41] <mandel> I'll write a comment in the mr
[16:41] <ogra_> jodh, thats another issue, indeed we shoudl tone that down, but i thing we shoudl generally turn off all logging on production devices
[16:41] <ogra_> *think
[16:41] <kenvandine> mandel, np, just letting you know where i'm at
[16:41] <kenvandine> Cimi, any progress on the wizard?
[16:41] <ted> ogra_, You should just switch to mint.
[16:41] <ogra_> lol
[16:41] <kenvandine> mint touch :)
[16:41] <ogra_> i would never do homebanking on mint !
[16:41] <ogra_> just syin ...
[16:42] <ogra_> *sayin
[16:42] <ogra_> :)
[16:42] <ted> ogra_, Stop saying that, you're going to get another set of articles written ;-)
[16:42] <ogra_> hahaha
[16:42] <jodh> ogra_: so can you confirm your logrotate status file is corrupt? (vi ~/.cache/logrotate/status, jump to the end and look for the control chars/nulls)
[16:43] <ogra_> yep, i see a lot of ^@
[16:43] <jodh> ogra_: yup - you're affected then :)
[16:44] <ogra_> jodh, but even with it working it will only kick in if i restart the session or an app, no ?
[16:44] <jodh> ogra_: a manual 'start logrotate' should force a recompress.
[16:44] <ogra_> ideally i would *never* do that
[16:44] <ogra_> unless i get an image uipgrade that forces a reboot
[16:45] <ted> pmcgowan, So my concern with turning all logging off would be that we *will* have access to those logs on automatically uploaded bug reports.
[16:45] <pmcgowan> ted, with a crash you mean
[16:45] <ted> pmcgowan, Correct
[16:46] <ogra_> jodh, no changes ot the file
[16:46] <ted> ogra_, I believe it also happens by cron, but wasn't happening because of the bad config.
[16:46] <pmcgowan> ted, then we need better smarts somehow
[16:47] <jodh> ogra_: yes, unless we arrange for the :sys:rotate-logs event to be emmitted regularly. I had proposed to rotate hourly way back when, but was shot down as we could then rotate useful logfile out of existence.
[16:47] <pmcgowan> ted, feel free to comment ont he bug
[16:47] <jodh> ogra_: there is also this awful hack (but it works :-): https://code.launchpad.net/~jamesodhunt/ubuntu/trusty/upstart/periodic-logrotate/+merge/202434
[16:47] <ogra_> phablet@ubuntu-phablet:~$ du -hcs .cache/upstart/
[16:47] <ogra_> 563M	.cache/upstart/
[16:47] <ogra_> phablet@ubuntu-phablet:~$ start logrotate
[16:47] <ogra_> logrotate stop/waiting
[16:47] <ogra_> phablet@ubuntu-phablet:~$ du -hcs .cache/upstart/
[16:47] <ogra_> 563M	.cache/upstart/
[16:47] <ogra_> no change
[16:48] <jodh> ogra_: try deleting the status file and re-running then.
[16:48] <ogra_> ok
[16:48] <ogra_> aha
[16:48] <ogra_> seems to do something, prompt didnt return
[16:55] <pmcgowan> ogra_, whats the verdict, I added rtm tasks to that logrotate bug
[16:55] <ogra_> phablet@ubuntu-phablet:~$ du -hcs .cache/upstart/
[16:55] <ogra_> 45M	.cache/upstart/
[16:55] <ogra_> a lot better now
[16:55] <ogra_> pmcgowan, we need to run logrotate daily ...
[16:55] <ogra_> there should be a cron job for this
[16:55] <ogra_> iirc
[16:56] <pmcgowan> ogra_, I thought we do but the corrupt file blocked it, or did I misunderstand
[16:56] <ogra_> while i personally would prefer to switch off logging completely to get rid of the IO it seems everyone is shocked when i suggest this
[16:56] <ogra_> pmcgowan, right
[16:57] <pmcgowan> ogra_, can you take that bug then?
[16:58] <ogra_> pmcgowan, if you can wait til snappy leaves me any time to work on phone bugs :)
[16:58] <pmcgowan> sounds like no :(
[16:58] <pmcgowan> rsalveti, ?
[16:58] <ogra_> well, i can take it, but i cant promise it will be fixed before final
[17:00] <pmcgowan> I think we should grab the fix, unless we dont think the files will get corrupted now
[17:00] <ogra_> yeah, better safe than sorry
[17:01] <kenvandine> i think we should only log when in developer mode
[17:01] <kenvandine> the logging for end user devices is useless
[17:02] <ted> kenvandine, It isn't useless when they're attached to crash reports.
[17:03] <ogra_> kenvandine, ++
[17:03] <kenvandine> i guess... but are we going to be able to do anything useful with the data in those crash reports?
[17:03] <ted> kenvandine, Fix bugs? :-)
[17:03] <kenvandine> ted, ideally :)
[17:03] <ogra_> ted, but they arent
[17:04] <ogra_> until we have such a feature they should be off
[17:04] <pmcgowan> the other issue is that generating the crash reports locks the phone up, users wont understand
[17:04] <kenvandine> yeah
[17:04] <kenvandine> as much as i would like automatic and useful crash reports
[17:04] <ogra_> we'll just plaster your screen with  popups like on the desktop
[17:04] <ted> ogra_, For applications, not yet, but for everything else it works great.
[17:04] <ogra_> :)
[17:04] <kenvandine> i think unless we are prepared to really manage that it isn't useful
[17:04] <ogra_> yeah
[17:04] <kenvandine> we need tooling and automation to mine the data
[17:05] <ogra_> totally with you on that
[17:05] <kenvandine> and identify items we should drill into
[17:05] <kenvandine> otherwise... it's going to just be noise
[17:05] <ogra_> planning that sounds liek a great topic for the next sprint
[17:05] <ted> I use it all the time...
[17:05] <kenvandine> indeed
[17:05] <ogra_> but til we have this we should turn it off
[17:05] <kenvandine> ted, i think you are the only one :)
[17:05] <kenvandine> i look at it from time to time too
[17:06] <kenvandine> but it's a bit overwhelming
[17:06] <ogra_> people that are debugging will actually knwo how to turn it on ... if not we should make sure to properly document it
[17:06] <kenvandine> and when you see a crash that looks common, it isn't trivial to look for patterns like which device, build, etc
[17:06] <kenvandine> so i think if developer mode is enabled, we log and file crash reports
[17:07] <ted> kenvandine, Haven't done that personally (hasn't been useful) but bdmurray can get you access to the DB.
[17:07] <ted> kenvandine, Folks have done reports like that.
[17:07] <ted> For instance you can now list by device image.
[17:07] <kenvandine> what i want is some robot to tell me what to look at :)
[17:07] <ted> kenvandine, Until we have that, we'll have to settle with managers ;-)
[17:08] <kenvandine> some intelligence that sees a pattern and raises awareness of common crashes
[17:08] <ted> Yeah, we don't get that with managers ;-)
[17:09] <ted> kenvandine, Last I talked to ev about this he was working on setting up an analytics system on the errors db. I think that got sidetracked though.
[17:10] <kenvandine> yeah
[17:10] <kenvandine> ev has some great ideas
[17:10] <ted> You should talk to your CI stakeholder :-)
[17:10] <kenvandine> and i really look forward to seeing this become useful
[17:10] <sergiusens> all I'm going to say is that if you use the phone, crash reports suck as they just block your device
[17:11] <ted> sergiusens, Crash reports on U8, or all?
[17:11] <sergiusens> ted: any crash report that is non recoverable
[17:11] <ted> Hopefully that is sufficiently rare?
[17:16] <sergiusens> ted: I don't know anymore, I disabled crash reports since they just kill my battery life
[17:17]  * sergiusens already requested for crash reports to be processed only when plugged
[17:17] <ogra_> well, i really like that we have statistics for crashes apps on errors.ubuntu.com
[17:18] <ogra_> if every developer would regulary check this page we would actually get benefit from the reports
[17:18] <ogra_> but since only very few people do that i think crash reports are moot atm
[17:21] <ted> ogra_, I guess the question would be how could we get more people checking them?
[17:21] <ogra_> ted, dunno, when did you check it last ?
[17:22] <ogra_> for me that was last year
[17:22] <ted> ogra_, For me it was the beginning of this week.
[17:22] <ogra_> its a personal habit ... not sure we can force people into usin it
[17:23] <ted> Force no, more visible, perhaps.
[17:23] <ogra_> yeah
[17:24] <ted> Or I guess make it part of the project management culture.
[17:24] <pmcgowan> ogra_, ted I asked for filtering by channel and device on that page
[17:24] <pmcgowan> right now its hard to sort it out
[17:24] <ogra_> i wanted to make it a daily task of the landing team a while ago ... but the landing team already has to check so many stats and error pages
[17:24] <ted> Report crashes per minute on each image.
[17:24] <ted> pmcgowan, I think that's there.
[17:24] <pmcgowan> wasnt
[17:25] <pmcgowan> you had to pick a specific image version
[17:26] <ted> pmcgowan, https://errors.ubuntu.com/?channel_name=ubuntu-touch/vivid-proposed&period=day
[17:26] <pmcgowan> ted, brian just added it!
[17:48] <rsalveti> pmcgowan: sorry, was on call, you mean fixing bug 1385464?
[17:49] <rsalveti> yeah, I still don't like much this amount of logs per apps
[17:53] <taiebot> kenvandine: i read that your voice call are terrible on Mako? it used to be the same for me i did not have the correct radio firmware https://lists.launchpad.net/ubuntu-phone/msg08514.html
[17:53] <kenvandine> oh... awesome
[18:00] <kenvandine> taiebot, indeed... my radio was outdated... updated, lets see if it's better
[18:01] <pmcgowan> kenvandine, how did you check its version?
[18:01] <pmcgowan> rsalveti, yes thanks
[18:01] <kenvandine> woot... fixed!
[18:02] <rsalveti> sure
[18:02] <kenvandine> pmcgowan, https://lists.launchpad.net/ubuntu-phone/msg08514.html
[18:02] <pmcgowan> I see
[18:02] <kenvandine> shows how
[18:02] <kenvandine> we should add that to the bug report :)
[18:03] <kenvandine> taiebot, i added that to bug 1318360
[18:04] <kenvandine> taiebot, thanks for the tip!
[18:04] <pmcgowan> kenvandine, I think I fixed this way back when
[18:14] <kenvandine> pmcgowan, it's been enough to make me live with edge on krillin for a while
[18:14] <kenvandine> got tired of my wife complaining that i sounded like charlie brown's teacher :)
[18:15] <pmcgowan> hah
[18:15] <kenvandine> i've been watching the bug report hoping someone would post a work around
[18:15] <kenvandine> never noticed it on the mailing list :)
[18:16] <pmcgowan> mandel, so your silo is ok to land without this fix https://bugs.launchpad.net/webbrowser-app/+bug/1413964
[18:27] <taiebot> kenvandine: Your wellcome
[18:28] <kenvandine> mandel, still busy?  i built check-hash in silo 7 and verified it doesn't regress
[18:28] <kenvandine> but still not sure how to verify it fails on a bad click
[18:34] <alecu> kenvandine: is that the sha512 branch? when testing the click scope branch for that we used to ask pindonga to set some package in the staging server to a wrong hash, and then tried installing it.
[18:34] <kenvandine> alecu, it is
[18:34] <kenvandine> alecu, i'd need to test the update though, so would need an old version installed already
[18:36] <kenvandine> alecu, any tips on testing from the staging server?   and if any of the clicks have a bad hash still?
[18:37] <pmcgowan> mandel, that should have ended in ?
[18:40] <alecu> kenvandine: the webservice urls in the click scope can be overridden with env vars; I hope it's the same for the updater. If so, instead of https://search.apps.ubuntu.com/api/v1
[18:40] <alecu> it should point to:
[18:40] <alecu> http://search.apps.staging.ubuntu.com/
[18:40] <alecu> about the hash and the apps, let's ask pindonga or matiasb
[18:41] <pindonga> alecu, let me think about this for a sec
[18:41] <pindonga> I know we did this once by modifying the hash on the server, but I also recall saying that wasn't a good idea
[18:41] <pindonga> we can't depend on the server to test client side behaviour (at least not in unit tests)
[18:41] <kenvandine> pindonga, if you can do that, and give me an older version of the click to install locally, i could test this
[18:42] <kenvandine> pindonga, yeah... this isn't ideal
[18:42] <kenvandine> just manual testing now
[18:42] <pindonga> why do you need to have the server give a bad hash?
[18:42] <pindonga> you're doing integration testing then?
[18:42] <kenvandine> mandel's branch includes a server to run for this... but not sure how to run that for a test on the device
[18:42] <pindonga> no unit ttests?
[18:42] <kenvandine> testing a branch from mandel, which adds verification of the hash for updates
[18:43] <pindonga> kenvandine, pls tell me which pkg available on staging (developer.staging.ubuntu.com) you're going to test this with
[18:43] <pindonga> and I can change the hash for that one
[18:43] <kenvandine> could you change gallery?
[18:44] <kenvandine> i have an old click of that already
[18:44] <pindonga> can't find any pkg named gallery
[18:44] <kenvandine> com.ubuntu.gallery
[18:44] <kenvandine> alecu, do you remember the env variable i need to override?
[18:45] <pindonga> kenvandine, that's not on the staging server
[18:45] <kenvandine> ok
[18:45] <kenvandine> could you pick anything and point me to a click for an older version to download?
[18:46] <pindonga> kenvandine, use this: https://developer.staging.ubuntu.com/dev/click-apps/ubuntu/132/
[18:46] <pindonga> can you see that page?
[18:46] <alecu> kenvandine: sorry, the Isp guys just arrived to check on my cable modem
[18:46] <pindonga> can you download the click form there?
[18:47] <alecu> kenvandine: not sure if it's the same environment variable for the updater
[18:47] <kenvandine> pindonga, no.. no perms
[18:47] <pindonga> kenvandine, alternatively, you can upload a click that you already have
[18:47] <pindonga> then we can change the hash of that click
[18:48] <pindonga> you'll have to make sure you did build the click yourself though
[18:48] <pindonga> otherwise it'll be rejected
[18:48] <kenvandine> that'll work
[18:48] <pindonga> let me know when you uploaded something
[18:48] <pindonga> and I'll change the hash
[18:50] <mandel> pmcgowan, excuse me?
[18:50] <pmcgowan> mandel, was wondering if your data uri support needed the browser fix or not
[18:51] <mandel> pmcgowan, I did a work around inside udm, the silo has been tested and set for QA to review
[18:51] <pmcgowan> mandel, awesome thanks
[18:51] <mandel> pmcgowan, so it is a matter of time atm, we will remove the hack when ever oxyde is fixed
[18:52] <pmcgowan> make sense
[19:02] <alecu> kenvandine: looking at ubuntu-system-settings/trunk/plugins/system-update/network/network.cpp, I see that there are two env vars that would need to be set:
[19:03] <alecu> #define URL_APPS "https://myapps.developer.ubuntu.com/dev/api/click-metadata/"
[19:03] <alecu> #define URL_PACKAGE "https://search.apps.ubuntu.com/api/v1/package/"
[19:03] <alecu> (the env vars have the same name as those defines)
[19:05] <kenvandine> pindonga, https://developer.staging.ubuntu.com/dev/click-apps/ubuntu/329/
[19:05] <alecu> kenvandine: you also need to log into a staging account in system settings first; let me find out what script was used for that.
[19:06] <kenvandine> alecu, thx
[19:06] <pindonga> kenvandine, ack, changing the hash
[19:07] <alecu> kenvandine: this is the script to point the click scope and online accounts to staging:  /usr/lib/*/pay-service/setup-staging.sh
[19:08] <alecu> kenvandine: after running that with phablet-shell, you need to go to online accounts, delete any u1 account you may have there, and login again.
[19:08] <pindonga> kenvandine, done... (changed the last char from f to g)
[19:08] <alecu> kenvandine: if you reboot, you need to run the script again.
[19:09] <alecu> kenvandine: finally, the servers to put in the env vars. One is: search.apps.staging.ubuntu.com
[19:09] <alecu> kenvandine: the other, I can't find it.
[19:09] <alecu> pindonga: do you know what's the staging server for this? https://myapps.developer.ubuntu.com/
[19:10] <pindonga> alecu, developer.staging.ubuntu.com
[19:10] <alecu> ah, great.
[19:10] <alecu> I still find the staging names of servers a bit braindamaging.
[19:11] <alecu> kenvandine: I think that should be all that's needed. Let me know if there's some other bit missing or not clear.
[19:14] <kenvandine> alecu, i'm guessing system-settings isn't honoring the env variable
[19:15] <kenvandine> i can find my package in the click scope
[19:15] <kenvandine> but system-settings isn't finding an update for it :/
[19:20] <alecu> kenvandine: weird! I see that Network::getUrlPackage() is getting the value from URL_PACKAGE
[19:20] <kenvandine> yeah, but that's in the define
[19:20] <alecu> kenvandine: what versions are installed / on the webservice?
[19:20] <kenvandine> it's not checking env
[19:21] <kenvandine> i don't think... haven't checked the code
[19:21] <alecu> kenvandine:     QString command = environment.value("URL_PACKAGE", QString(URL_PACKAGE));
[19:21] <kenvandine> i have version 0.1 installed and 0.2 on staging
[19:21] <kenvandine> oh..
[19:21] <kenvandine> weird then
[19:21] <kenvandine> i set it with:
[19:21] <alecu> kenvandine: in ubuntu-system-settings/trunk/plugins/system-update/network/network.cpp
[19:21] <kenvandine> initctl set-env --global URL_PACKAGE=https://search.apps.staging.ubuntu.com/api/v1/package/
[19:22] <kenvandine> and the scope finds it..
[19:22] <alecu> kenvandine: the scope seems to be using a different variable (that's set in the setup_staging.sh script)
[19:22] <kenvandine> ah
[19:22] <dobey> yes we don't use URL_PACKAGE
[19:24] <dobey> hmm, that should be changed in the code so it matches the click scope
[19:24] <dobey> at least until we get a single service where all the talk-to-the-store code lives
[19:24] <alecu> kenvandine: try adding those vars to that script, both in the initctl part, and also on the UpdateActivationEnvironment dbus call
[19:25] <kenvandine> URL_PACKAGE actually is
[19:25] <kenvandine> i'll add the other too
[19:26] <alecu> kenvandine: wait, it's called slightly different: URL_PACKAGE_INFO
[19:27] <dobey> meh, environment variables :-/
[19:27] <alecu> meh-ssy.
[19:27] <dobey> verry
[19:28] <kenvandine> oh... instead of URL_APPS?
[19:29] <kenvandine> oh i see
[19:30] <ot> need help installing ubuntu touch on ascer with w8.1
[19:33] <ot> it doest let me boot
[19:36] <kenvandine> alecu, pindonga: nevermind... looks like mandel updated the test plan :)
[19:36] <dobey> maybe we should add a splash screen to the sdk
[19:36] <dobey> it is so incredibly slow to start ;(
[19:37] <mandel> dobey, is the precompilation of the qml that is not cached
[19:37] <mandel> dobey, something that everyone completely ignored, we are working on it in the lower levels because is not a JIT bad a AOT compiler
[19:37] <mandel> in EVERY run
[19:37] <dobey> mandel: so it's poorly architected and not threaded? :)
[19:37] <mandel> kenvandine, did I?
[19:37] <bzoltan> dobey:  sorry I missed the context... what is slow?
[19:38] <kenvandine> mandel, oh... you didn't?
[19:38]  * bzoltan has highlight on "sdk"
[19:38] <kenvandine> there is instructions there for check-hash :)
[19:38] <kenvandine> and how to run the test server
[19:38] <mandel> dobey, no, it has nothing to do with poorly arch, is just that doing jits is hard
[19:38] <dobey> bzoltan: when i click the icon on my launcher, it takes about 10-15 seconds for the sdk window to actually show up
[19:38] <bzoltan> dobey:  how many click chroots do you have?
[19:38] <dobey> bzoltan: 3
[19:39] <dobey> having click chroots makes it slow?
[19:39] <mandel> kenvandine, oh, but I did not do it, a bullied diego to do it ;)
[19:39] <kenvandine> ah
[19:39] <bzoltan> dobey:  I have a fix just for thet... do you want to be a test user? :D
[19:39] <bzoltan> dobey: ppa:ubuntu-sdk-team/tools-development
[19:39] <dobey> i'm not sure. it's always scary when someone asks that with a :D
[19:40] <mandel> dobey, beter than with a O_o
[19:40] <bzoltan> dobey:  no need to worry :D I am just happy to find some candidates
[19:40] <dobey> bzoltan: is there a single .deb i need to install to test? or is it a bunch of debs?
[19:40] <bzoltan> dobey:  you can fall back to the SDK PPA any time by removing that ToolsDev PPA
[19:41] <bzoltan> dobey: technically it is one .deb
[19:41] <bzoltan> dobey: or maybe two
[19:41] <bzoltan> dobey:  just fetch the qtcreator-plugin-ubuntu[.*]deb packages
[19:42] <dobey> bzoltan: ok, i was just going to ask if the fix was in the plugin or qtc :)
[19:42] <bzoltan> dobey:  we have a brand new chroot agent mechanism what will speed up the start time from the second start
[19:42] <bzoltan> dobey:  I do not touch the QtC if it is possible... I would not even poke it with a stick ...
[19:45] <mandel> bzoltan, is that what ricmm worked on?
[19:46] <bzoltan> mandel: no
[19:46] <dobey> bzoltan: does seem a little bit faster
[19:47] <mandel> bzoltan, what is the diff then? (just curious)
[19:47] <dobey> although, the debian/changelog entry makes it seem like it would be slower
[19:47] <bzoltan> mandel: dobey: we have a chroot agent daemon what keeps the click chroots session active even if you quit the QtC.. so they are already mounted when you next time start the QtC
[19:49] <kenvandine> mandel, ok... well i approved your check-hash branch because it didn't cause any regressions but it looks like it needs a little fix
[19:49] <bzoltan> dobey:  making the SDK to start faster was a big target... Still not a rockstar, but getting there. It is not easy to deal with chroots
[19:49] <kenvandine> mandel, the UI doesn't seem to handle the error
[19:49] <kenvandine> sits at 100%
[19:49] <kenvandine> i see the error in the udm logs
[19:49] <mandel> kenvandine, oh! it is not grabbing the error, let me get that done for you, I must have missed it
[19:49] <kenvandine> mandel, can you look at that before we backport this to rtm?
[19:49] <bzoltan> dobey: I soon EOD, but please play with that release and drop me lines here if you find anything
[19:49] <mandel> kenvandine, dont approve it, on it
[19:49] <kenvandine> mandel, i already did :)
[19:49] <kenvandine> it didn't break anything :)
[19:50] <kenvandine> just fix it separately and we'll land it
[19:50] <mandel> kenvandine, on
[19:50] <mandel> ok*
[19:50] <kenvandine> it'll be perfect for rtm :)
[19:50] <dobey> bzoltan: i don't use it much. just a bit annoyingly slow when i do have to. go have an enjoyable and relaxing weekend instead. :)
[19:50] <kenvandine> mandel, just make your other branch a prereq
[19:50] <mandel> ack
[19:50] <mandel> kenvandine, will make sure it is done asap
[19:51]  * dobey is having more grievance with adt-run at the moment anyway
[19:51] <kenvandine> thx
[19:51] <bzoltan> dobey:  thanks :)
[19:51]  * mandel says that close to 9pm on a friday..
[19:56] <dubstar_04> i'm trying to play a video and i keep getting this error: Failed to start playback:  org.freedesktop.DBus.Error.NoReply: Did not receive a reply.
[20:31] <kenvandine> mandel, i'm assuming that fix will be QML only, i could easily test fixes locally since i have everything all setup to test that already
[20:31] <kenvandine> just let me know
[20:32] <mandel> kenvandine, is mainly connecting to the signal, finishing sdcard work atm.. sorry :-/
[20:32] <mandel> I need a clone
[20:32] <kenvandine> i could take a swing at it... just handling the download status right?
[20:34] <kenvandine> mandel, oh... i guess we need the DownloadTracker to emit errorFound
[20:34] <kenvandine> so it would be in the cpp
[20:34] <kenvandine> that slows things down
[20:34] <mandel> kenvandine, how come?
[20:34] <kenvandine> having to wait for builds ;)
[20:34] <kenvandine> or why that?
[20:35] <kenvandine> our DownloadTracker is what connects to udm
[20:35] <kenvandine> i don't think the udm status trickles down
[20:38] <mandel> kenvandine, I need to get a closer look, but the single error signal is enough
[20:38] <kenvandine> mandel, actually our DownloadTracker connects to Download::error
[20:38] <kenvandine> which should emit errorFound
[20:38] <mandel> kenvandine, correct
[20:38] <kenvandine> i'll take a quick look, that didn't work...
[20:38] <kenvandine> see if i can figure it out quickly while you're busy :)
[20:46] <kenvandine> mandel, maybe this is in udm... we get the processing signal from the Download, it shouldn't even try that if the hash check failed right?
[21:11] <kenvandine> mandel, sorry... i'll have to leave this to you... i really think the error signal isn't getting sent from udm
[21:11] <kenvandine> u-s-s log: http://pastebin.ubuntu.com/9840179/
[21:12] <kenvandine> udm log: http://pastebin.ubuntu.com/9840172/
[21:12] <kenvandine> mandel, hopefully those help when you have time
[21:48] <dubstar_04> can anyone help with video playback?
[21:58] <taiebot> has anyone ever reported the bug while when scrolling down the screens jump up. This happens on mako do not know if its due to screen sensitivity but this happens on any window scopes/ oxide/ etc..