[02:04] <imgbot> [03:19] <imgbot> [03:19] <imgbot> [05:58] <didrocks> hey Mirv, did you note all those "preparing packages"
[05:58] <didrocks> on the spreadsheet?
[06:06] <Mirv> didrocks: uh, no, I just looked at the color it seems and I didn't notice that that's indeed unusual. looking.
[06:07] <didrocks> Mirv: I pinged #webops
[06:07] <didrocks> Mirv: too many preparing packages to be realistic and no jobs running in jenkins
[06:09] <Mirv> I see that
[06:10] <didrocks> Mirv: so yeah, please next time, as you are the first look in the morning if nothing is weird to your eyes :p
[06:11] <Mirv> sure, it seems I'd need a bigger cup of coffee on Monday morning to spot that
[06:11] <Mirv> seems obvious now
[06:13] <didrocks> Mirv: I wonder if jenkins can help trapping failed job
[06:31] <circ-user-RdXpi> imgbot, status 280 manta
[06:32] <imgbot> Image 280 test results on manta - Total: 655, Pass: 633, Crashes: 3, Rate: 94.4%
[07:11] <popey> Mirv: didrocks someone mentioned on the weekend that jenkins was out of disk space...
[07:11] <didrocks> popey: yeah, saw that and dealt with. Thanks!
[07:11] <popey> ok
[07:12] <popey> my #279 mako is warm and I can't adb shell into it
[07:14] <didrocks> argh
[07:16] <popey> Apr  7 06:37:00 ubuntu-phablet kernel: [37664.128759] init: powerd main process
[07:16] <popey> (5715) killed by KILL signal
[07:16] <popey> Apr  7 06:37:00 ubuntu-phablet kernel: [37664.128820] init: powerd main process
[07:16] <Mirv> popey: yep, fixed now
[07:16] <popey> ended, respawning
[07:17] <Mirv> so what is nowadays The way to update device? every time --bootstrap --wipe ?
[07:17] <popey> neither if you just want to update
[07:17] <popey> "adb shell system-image-cli" is sufficient
[07:17] <popey> or "ubuntu-device-flash --channel=trusty-proposed"
[07:17] <Mirv> popey: what were the ways not to use that caused the old kernel/initrd to be used?
[07:18] <popey> uh. pass
[07:18] <Mirv> that was briefly mentioned by ogra on Friday
[07:18] <Mirv> popey: :)
[07:19] <Mirv> I somehow got the impression that OTA might be better than system-image-cli, but all in all I'm just confused with OTA / system-image-cli / ubuntu-device-flash (+ options)
[07:19] <popey> OTA _is_ s-i-c
[07:19] <Mirv> ok, good, one less option then. and of course OTA should be the way that works for everyone, otherwise we've a problem.
[07:19] <popey> ya
[07:20] <popey> you can use system settings -> update of course
[07:20] <popey> if you can touch the device, and the screen isn't off
[07:22] <popey> bug 1303621
[07:24] <didrocks> popey: no issue on 280 here with OTA update
[07:26] <popey> leave it on for 16 hours ☻
[07:27] <didrocks> popey: ahah, can be, but doesn't seem to be worse for now than usual
[07:30] <popey> bug 1303623
[07:31] <didrocks> popey: no crash file while unity8 is crashing? are you sure?
[07:31] <popey> ya
[07:31] <popey> unity crashed, lost all apps contexts
[07:35] <popey> bug 1303627 also
[07:36]  * didrocks smells a long meeting
[07:37] <sil2100> o/
[07:37] <didrocks> hey sil2100, good week-end?
[07:37] <sil2100> didrocks: hey! Yes, a bit sleep-depriving though - how about yours? :)
[07:38] <didrocks> sil2100: was good, enjoyed some video games + resting
[07:43] <sil2100> Oh, I see we seem to be having normal smoketesting results \o/ ?
[07:51] <didrocks> sil2100: well, the day started with full disk on prodstack
[07:51] <didrocks> sil2100: and it seems popey is getting quite a lot of new issues
[07:52] <sil2100> didrocks: full disk? On prodstack? How much disk space do we have there then :/ ?
[07:53] <didrocks> sil2100: issues when they setup the backup disk apparently
[08:02] <psivaa> didrocks: Just to let you know that the results on mako will be a little late today. With 280, there was an incident where the device dint come up during a reboot
[08:02] <psivaa> and i had to use another device to get going
[08:02] <didrocks> psivaa: yeah, I saw your email, thanks for looking it up! :)
[08:03] <psivaa> :)
[08:03] <didrocks> psivaa: it means, on the failures, we won't get the crash files though, so maybe, we will have to rerun them?
[08:03] <veebers> sil2100, MacSlow, didrocks: Hi guys, could I get a silo for line 44?
[08:04] <sil2100> veebers: looking
[08:04] <veebers> d'oh. sorry MacSlow
[08:04] <psivaa> didrocks: i could rerun them, we have some crashes in http://ci.ubuntu.com/smokeng/trusty/touch/mako/20140407%20%3F/7600/ but with a wrong build id
[08:04] <veebers> sil2100: awesome, thanks
[08:04] <sil2100> veebers: ok, we're a bit low on silos, but I guess we can spare one for your landing :) Let me assign
[08:04] <psivaa> didrocks: i'll let the rest of the tests run first and if we dont have the needed crashes, i'll rerun them
[08:04] <didrocks> psivaa: yeah, sounds like a good plan
[08:05] <didrocks> veebers: weird to merge a WIP branch without any approval?
[08:05] <Mirv> veebers: :D (to mac_slow ping)
[08:06] <veebers> didrocks: It's been approved before but backed out due to tests having issues. We're hoping to double the silo ppa as a testing stage before it get's merged properly
[08:06] <didrocks> veebers: hum, staging? silos or not for staging
[08:06] <didrocks> veebers: remember that last request was staged for 3 weeks
[08:06] <didrocks> without any rebuild or nothing
[08:07] <didrocks> are we expecting the same with this one?
[08:08] <veebers> didrocks: aye right, the last one was due to image issues where we couldn't test and other bugs that weren't autopilot related but seemed it
[08:08] <veebers> didrocks: I would hope that it won't take that long.
[08:09] <didrocks> veebers: ok, you should know that when we are low in silo, we will start flushing things that didn't change in less than X days
[08:09] <veebers> didrocks: perhaps I can get a ppa that uses an actual armhf builder as qemu segfaults building libautopilot-qt (the tests)
[08:09] <didrocks> X ~ 4 work days sounds right
[08:09] <didrocks> veebers: that's something to ask webops for
[08:11] <veebers> didrocks: hmm ok. Well the plan is that the tests get fixed (using the ppa) and we can proceed and approve from there.
[08:11] <veebers> didrocks: could we have the silo for now, and if silos get low in ~4 days and we haven't had any luck we release it back into the pool?
[08:12] <veebers> (as the intention is to actually release)
[08:12] <didrocks> veebers: ensure that's it's not staged long. QA has 3 silos as of now and be a good citizen as we have a lot of landings and low silo number
[08:12] <didrocks> veebers: yeah, doing that
[08:12] <didrocks> the 3 weeks "stuck AP" was really not a good example to reproduce
[08:12] <didrocks> I hope it won't
[08:12] <veebers> didrocks: awesome thanks.
[08:12] <didrocks> yw
[08:13] <veebers> didrocks: right, but as I mentioned it wasn;'s AP's fault
[08:13] <ogra_> popey, so i tried to port all my webapps to the new api .... works fine for running a single app, but if i run more than one they all die over time ... every new started one then starts to replace the running one
[08:13] <didrocks> veebers: what prevented your team to run all tests manually?
[08:13] <didrocks> veebers: as we did here
[08:13] <didrocks> everyday, for every images
[08:13] <didrocks> as a backup
[08:13] <ogra_> and unity crashes all the time :/
[08:13] <didrocks> Saviq: hey, multiple new crashers report ^
[08:13] <didrocks> please grab a .crash file
[08:14] <ogra_> also the applications scope is often completely empty
[08:15] <didrocks> nice, already 5 regressions mentionned today :/
[08:15] <didrocks> please gather all that in bug reports
[08:15] <didrocks> so that we can start triaging or it will be all lost
[08:15] <ogra_> yeah, i havent yet
[08:16] <ogra_> for the webapps i'm not sure if i didnt do something wrong ... i used a similar manifest, desktop and json file to the G+ app, probably thats not the right setup
[08:16] <veebers> didrocks: if we knew how long the outage was to be we would have, but we were hopeful that it wouldn't take that long. (plus we have a couple of devices between us, and trying to simultaneously get other stuff sorted too). In hindsight I guess we could have, but wasn't the plan at the time
[08:16] <didrocks> veebers: should have been communicated to us I guess
[08:16] <veebers> didrocks: I understand that silos are a finite resource though, and we don't intend to hold this one for ages
[08:16] <didrocks> thanks
[08:17] <didrocks> veebers: and yeah, we do test manually the image, even if it's not our work and we have finite resource in term of times
[08:17] <didrocks> but we do what has to be done
[08:17] <didrocks> will appreciate other teams as well :)
[08:17] <veebers> didrocks: right, next time we'll make sure. Feel free to let us know if you have any other concerns etc. too
[08:17] <didrocks> so that not everything get infinitely stuck
[08:17] <didrocks> ok
[08:17] <didrocks> veebers: I did multiple times to your manager FYI
[08:18] <veebers> didrocks: ack, I'll follow up
[08:18] <popey> ogra_: yeah, just reproduced
[08:18] <popey> i had ~6 webapps open now I only see one
[08:19] <ogra_> yeah :(
[08:19] <Saviq> didrocks, the things popey reported had no .crash files, where else should I look?
[08:19] <ogra_> ok, then it is at least not my apps
[08:19] <didrocks> Saviq: yeah, that's what I told to him, I think ogra_ will provide you one
[08:19]  * ogra_ will upload them to the store then
[08:19] <didrocks> ogra_: can you quickly send the crash file you should have got?
[08:19] <ogra_> if there is a .crash file its on the other phone, i can check after the meeting
[08:19] <didrocks> Saviq: I'm really puzzled by popey getting a crash without a crash file
[08:20] <veebers> didrocks: sweet, I'm building now. Cheers
[08:20] <popey> [  905.125316] type=1400 audit(1396858647.502:218): apparmor="DENIED" operation="open" parent=1780 profile="com.popey.untappd_untappd_0.2" name="/run/user/32011/pulse/" pid=4021 comm="webapp-containe" requested_mask="r" denied_mask="r" fsuid=32011 ouid=32011
[08:20] <popey> lots of that
[08:20] <didrocks> ogra_: can you beforehand? not sure we should have Saviq pending on us
[08:20] <popey> so maybe I need better perms.. dunno why that would kill the others
[08:20] <ogra_> popey, mine are all apparmor clean .... they still crash
[08:20] <didrocks> Saviq: ah, seems I have unity8 stuck now
[08:21] <didrocks> let me see
[08:21]  * sil2100 still upgrades
[08:21] <popey> ogra_: its only one of mine that apparmor denies
[08:21] <ogra_> oh, right, getting stuck when swiping is another problem
[08:22]  * popey goes to get coffee for a long meeting
[08:22] <didrocks> popey: double your coffee you plan to I guess…
[08:28] <ogra_> Mirv, people.canonical.com/~ogra/_usr_bin_unity8.32011.crash
[08:29] <didrocks> Saviq: ^
[08:29] <ogra_> oops
[08:29] <ogra_> sorry
[08:29] <Mirv> ogra_: you want me to retrace it or..?
[08:30] <ogra_> Mirv, nope, ignore it ... mixed you up with Saviq ...
[08:30] <Mirv> ok, just double-checked
[08:33] <didrocks> popey: we are eagerly waiting on you!
[08:33] <ogra_> first you tell him to make twice the coffee and now you complain !
[08:33] <popey> sorry, had to re-auth G+_
[08:42] <Mirv> ogra_: just noticed a small detail, the ophono-phonesim-autostart you asked about on Friday is not installed on my device, but this ofono-phonesim-autostart is :) so in theory it's there and AP:s without SIM should probably pass.
[08:44] <Saviq> ogra_, please, pretty please, apport-cli crash files before sending them up...
[08:48] <asac> test1234
[08:48] <asac> hehe
[08:48] <ogra_> failed
[08:48] <ogra_> :P
[08:48] <asac> now try where that might be my password :P
[08:48] <asac> lol
[08:49]  * ogra_ goes and steals all your bicoins with the walle password :P
[08:49] <ogra_> *wallet
[08:49] <asac> lol
[08:50] <asac> "You have successfull changed your password to test12345" :)
[08:50] <ogra_> heh
[08:54] <mandel> fginther, morning! did the branch build correctly? (the udm one that was always failing in arm nodes with some etra load on them)
[08:54] <ogra_> W/Adreno-ES20( 2074): <core_glReadPixels:212>: GL_INVALID_OPERATION
[08:54] <ogra_> W/Adreno-EGLSUB( 2074): <CacheInvalidateHandle:243>: PMEM_INV_CACHES undefined
[08:54] <ogra_> popey, ^^^^
[08:55] <Saviq> ogra_, ok so... .crash truncated
[08:55] <veebers> didrocks: hey, out of curiosity what do you use to run all the ap tests locally/manually? Might come in handy next time :-) Is it the same/similar to the dashboard jenkins job (or our gatekeeper)?
[08:55] <ogra_>  /system/bin/logcat -d ...
[08:55] <popey> ogra_: where's that from?
[08:55] <ogra_> i see a lot of that
[08:58] <ogra_> Saviq, yeah apport-cli also tells me its an invalid crash file :/
[08:59] <ogra_> hmm, no, now it seems to work
[09:00] <Saviq> ogra_, you will still only get ??s everywhere, at least if the .crash file I downloaded is the same
[09:01] <ogra_> well, lets see if apport os better at uploading than scp
[09:01] <ogra_> *is
[09:06] <ogra_> Saviq, bug 1303666
[09:07] <Saviq> ogra_, did that actually upload the .crash file?
[09:07] <ogra_> hmm,, doesnt look like :(
[09:09] <Saviq> asac, did you see the comment to your unity8 test fix? str(bytes) is b"foo", not foo
[09:09] <Saviq> asac, you need to actually decode it into a string
[09:09] <Mirv> seb128: landing-004 ready for clean
[09:09] <seb128> Mirv, thanks
[09:10] <didrocks> veebers: I think Mirv and sil2100 have a script for that
[09:10] <veebers> didrocks: ah coolio, I'll hit them up. Cheers
[09:11] <didrocks> yw!
[09:11] <veebers> Mirv, sil2100: Hey what do you use to run all the AP tests locally/manually? Is it similar to what the dashboard/gatekeeper uses?
[09:17] <didrocks> sil2100: mind opening a bug with all reference in the dialer-app flaky test?
[09:17] <didrocks> sil2100: same for unity8?
[09:17] <sil2100> didrocks: sure, doing
[09:17] <didrocks> Saviq: btw, you did see the unity8 AP test failure on the dashboard?
[09:17] <sil2100> Let me start with dialer ;)
[09:21] <asac> Saviq: interesting... not sure if python3 is sane tbh :P
[09:21] <asac> Saviq: bzr diff -c 822 | pastebinit
[09:21] <asac> http://paste.ubuntu.com/7216238/
[09:21] <didrocks> Saviq: so, sorry dude, but you will 4 blockers on your list (bug #1300326, bug #1300302 , new AP test failure, new unity8 crasher)
[09:22] <didrocks> for both last one, we'll open some bugs
[09:22] <Mirv> veebers: I think it differs a bit from person to person. I'm using something like this http://pastebin.ubuntu.com/7184268/ although right last week it started to have problems running dialer/messaging AP:s
[09:22] <didrocks> Saviq: your team is working on priority to unblock those, right?
[09:23] <asac> Saviq: updated MP
[09:26] <Saviq> didrocks, most of my team are on a sprint here
[09:26] <didrocks> Saviq: meaning, sprinting to unblock the blockers? :)
[09:28] <popey> ogra_: didrocks bug 1303676
[09:28]  * ogra_ confirms 
[09:28] <didrocks> popey: thanks!
[09:29] <didrocks> sil2100: that's one you need to poke upstream about
[09:29] <sil2100> didrocks: noting!
[09:30] <Saviq> didrocks, so, "dead area" Albert is on, "locks up with grey tint", Zanetti was working on, but he's here now, I'll get an update, "random crash" not retraceable / reprodicuble yet, ap test asac was looking into
[09:30] <didrocks> Saviq: perfect, thanks!
[09:30] <Saviq> asac, is str(foo, encoding) compatible with py2.7, though?
[09:31] <didrocks> sil2100: links for the AP failures?
[09:35] <asac> Saviq: oh didnt know we need to support both
[09:35] <sil2100> didrocks: dialer-app: https://bugs.launchpad.net/dialer-app/+bug/1303681
[09:36] <Saviq> asac, we still are, yeah
[09:36] <sil2100> didrocks: finishing filling out for unity8
[09:36] <asac> Saviq: check_output is throwing exception/error in case you get an errorcode, right?
[09:36] <Saviq> asac, yes
[09:37] <Saviq> not sure we switched to py3 everywhere in the infrastructure - if we did, then maybe we can drop py2.7 compatibility at some point in the near future indeed
[09:38] <asac> well, if there are compatible ways, why not
[09:38] <asac> repushed
[09:38] <sil2100> didrocks: https://bugs.launchpad.net/unity8/+bug/1303685
[09:38] <asac> if thats not it, its easier if you just do it :P
[09:38] <didrocks> sil2100: thanks!
[09:39]  * didrocks just waits on ogra_'s bug report for the unity8 crasher :)
[09:39] <sil2100> asac: are you looking into that one ^ ?
[09:39] <sil2100> asac: should I assign you to it? ;)
[09:39] <ogra_> didrocks, the crash file is corrupt ... read the backlog
[09:39] <didrocks> ogra_: hum, as I really can't reproduce your crash, can you try to increase the timeout?
[09:40] <didrocks> and make it crash again?
[09:40] <didrocks> as you can get it easily
[09:40] <ogra_> didrocks, well, i think its the same as poey sees
[09:40] <didrocks> ogra_: but popey didn't get any crash file :/
[09:41] <ogra_> just that i end up with half a crash file :P
[09:41] <didrocks> ogra_: yeah, so maybe it's taking a very long time to collect it
[09:41] <didrocks> hence the "increase the kill timeout in the upstart job"
[09:41] <didrocks> like to 300s
[09:41] <didrocks> and make it crash and see if the new crash file is better
[09:41] <didrocks> ogra_: I have 17 apps opened, I'm switching between scopes like crazy and it's robust here
[09:42] <ogra_> well, i dont know how to "make it crash" :P
[09:42] <ogra_> but yeah, i can increase the timeout
[09:42] <didrocks> oh, I thought you mention that it was really easy for you to get a crash
[09:42]  * ogra_ is super unhappy having to do that on his production phone ... it has never been writable :((((
[09:42] <ogra_> didrocks, to get it crash ... not to produce a crash file
[09:43] <ogra_> it doesnt do that every time (probably one out of ten and i only had it crash like 5 times yesterday for example)
[09:43] <didrocks> weird…
[09:43] <didrocks> maybe heavy webapps
[09:43] <didrocks> and so OOM killer
[09:44] <ogra_> no OOM killer in the logs
[09:44] <ogra_> and no, they arent heavy
[09:44] <ogra_> just a few news sites with a handfull of jpegs and a lot of text
[09:44] <ogra_> (no video or audio embedded or any heavy things)
[09:54] <sil2100> didrocks, davmor2: so, the oxide grooveshark issue will be fixed soon - a new oxide with the problem fixed is already in -proposed and there is a landing prepared for the webbrowser-related changes in CITrain, which I will try to assign a silo to
[09:54] <davmor2> sil2100: sounds about right
[09:54] <didrocks> sil2100: ah, so we need webbrowser fixes as well?
[09:54] <didrocks> the oxide change itself is not enough?
[09:55] <sil2100> didrocks: from what dbarth mentioned, webbrowser needs to switch to oxide 1.0, and that's what the landing is about
[09:55] <sil2100> So I guess some mods need to be done
[09:56] <didrocks> ok
[09:58] <davmor2> and didrocks blags my head by sending me to the image that had the broken no scopes visible image damn you didrocks /me shakes fist in the air
[09:58] <didrocks> sil2100: did you get any news on the other one?
[09:58] <didrocks> davmor2: ahah :p
[09:58] <didrocks> davmor2: sorry, forgot that
[09:59] <didrocks> davmor2: so yeah, image +1 ;)
[09:59] <didrocks> or -1 rather
[09:59] <didrocks> for old scopes
[09:59] <davmor2> didrocks: you're not alone falshing 258 now :)
[09:59] <dbarth> i'm also checking if that one contained the grooveshark fix
[09:59] <didrocks> davmor2: :p
[09:59] <sil2100> didrocks: they're looking at it still
[09:59] <davmor2> didrocks: old scopes are fine testing new scopes now
[09:59] <didrocks> davmor2: ah, ok ;)
[10:00] <sil2100> ;)
[10:00] <davmor2> didrocks: when I say fine I mean the home scope is crashy as hell but works :)
[10:00] <didrocks> davmor2: yeah, got you!
[10:00] <vila> imgbot: status 280 mako
[10:00] <imgbot> Image 280 for mako has not finished the tests, status is: Running
[10:00] <popey> sil2100:  do we have a slot for https://code.launchpad.net/~renatofilho/qtorganizer5-eds/tz-support/+merge/213714 ?
[10:01] <davmor2> didrocks: I'd forgotten just how often unity8 crashed on the home scope when you had a lot of music :)
[10:01] <didrocks> heh
[10:02] <sil2100> popey: it's landed already from what I see
[10:02] <didrocks> sil2100: davmor2: popey can you ensure that everything we set as blockers are set to high/critical at least on one component?
[10:02] <popey> sil2100: which image?
[10:02] <didrocks> so that we don't end up in useless discussion :)
[10:02] <popey> didrocks: where is the blocker list?
[10:02] <popey> other than your emails
[10:02] <didrocks> popey: it's the emails only AFAIK
[10:02] <popey> ah
[10:03] <davmor2> didrocks: Yeap
[10:03] <popey> i thought there might be some central doc with it in
[10:03] <didrocks> popey: I'm unsure QA is maintaining one
[10:03] <davmor2> maybe
[10:03] <sil2100> popey: 278 should be it?
[10:03] <davmor2> didrocks: if by QA you mean me for my benefit
[10:04] <didrocks> davmor2: I don't know TBH, you are dogfooding, you shouldn't have to maintain that list IMHO
[10:04] <didrocks> just interact with it
[10:04] <sil2100> dbarth: so, I removed oxide-qt from the silo config, since oxide-qt the 'required version' is already in -proposed
[10:05] <sil2100> dbarth: so we don't need it being uploaded again
[10:05] <dbarth> sil2100: yup
[10:05] <davmor2> didrocks: it's there so when I get asked what the blockers are I can quickly scan through it, I'm not being very good at keeping up to date though as it seems to be only for me and I can open the mail instead :)
[10:05] <sil2100> dbarth: anyway, silo assigned
[10:05] <dbarth> sil2100: no neeed to build oxide
[10:05] <sil2100> :)
[10:05] <dbarth> sil2100: cool
[10:11] <sil2100> dbarth: did you also take a look at the bug I mentioned?
[10:14] <davmor2> Morning all by the way :)
[10:16] <didrocks> sil2100: mind looking at why we are blockin on camer-app?
[10:16] <didrocks> camera-app
[10:16] <didrocks> https://ci-train.ubuntu.com/job/landing-013-1-build/6/console
[10:20] <sil2100> didrocks: looking
[10:23] <sil2100> didrocks: yeah, so it seems there is a FTBFS on libusermetrics, and camera-app dep-waits on that new version
[10:23] <sil2100> didrocks: and I guess dep-waiting might result in a 'building' into eternity, right?
[10:23] <didrocks> sil2100: ok, maybe kill the job then and change the status?
[10:23] <sil2100> didrocks: I'll poke the lander anyway
[10:23] <didrocks> sil2100: yep
[10:24] <sil2100> Yes :)
[10:24] <dbarth> sil2100: silo 011 good to go
[10:25] <sil2100> dbarth: o/ Thanks
[10:27] <didrocks> ogra_:  https://launchpad.net/bugs/1303676 do you have a crash file handy for dbarth?
[10:28] <ogra_> didrocks, no
[10:28] <ogra_> there are no crash files
[10:28] <didrocks> ok, and dbarth can't reproduce the issue?
[10:28] <ogra_> cant he ?
[10:28] <ogra_> it is easy to reproduce
[10:29] <cjwatson> looks like that libusermetrics FTBFS is pointing out an ABI break
[10:29] <cjwatson> so I hope people don't just blindly update the symbols :)
[10:31] <ogra_> didrocks, it always happens all the time here after a while of using apps that use the new API
[10:31] <ogra_> you just need to use them for a while ...
[10:36] <popey> ogra_: didrocks bug 1303721
[10:37] <didrocks> popey: I guess the tests are overriding properties
[10:38] <didrocks> which I'm not totally surprised about
[10:39] <didrocks> ogra_: they don't die in bug #1303676, they are replaced
[10:40] <ogra_> didrocks, sure, might be
[10:40] <didrocks> dbarth: FYI ^
[10:40] <ogra_> didrocks, but what is leaving me with a grey unusable window for the remianing one then ?
[10:40] <didrocks> ogra_: unsure, maybe a webapp which can't start
[10:40] <ogra_> something definitely crashes too
[10:40] <didrocks> ogra_: dbarth: updating title
[10:41] <ogra_> didrocks, theyse are all running and properly working apps
[10:41] <didrocks> ogra_: well, without crash file, hard to ask/put on priority list
[10:41] <ogra_> they run for a while once that happens
[10:41] <ogra_> and its is reproducable easily on both phones here (well, as far as i can reproduce with the broken display on the second)
[10:41] <ogra_> didrocks, for me that makes the phone unusable ... i only use webapps
[10:42] <ogra_> and the oldAPI works just fine
[10:42] <didrocks> ogra_: yeah, but you can't provide simple step to reproduce, seems upstream are waiting on the bug report
[10:42] <didrocks> if no end moves, nothing will change
[10:42] <ogra_> huh ?!?
[10:42] <didrocks> ogra_: see last comment
[10:42] <ogra_> start 6 webapps that use the new api ... popey listed a few
[10:42] <ogra_> use them for 2 minutes
[10:42] <ogra_> see everything die
[10:43] <dbarth> ogra_: ok, will do right now
[10:43] <dbarth> i'm done with the rest of my tests
[10:43] <didrocks> ok, let's see
[10:43] <ogra_> it might take longer before it happens the first time
[10:43] <ogra_> but from then on it happens constantly
[10:43] <ogra_> once it started it only replaces the last app
[10:43] <ogra_> before it happens i can switch between them for a while
[10:44] <didrocks> thostr_: hey, I think you saw bug #1302801, do you think it will be fixed soon?
[10:44] <dbarth> ogra_: which image is that btw?
[10:44] <ogra_> it feels like the container doesnt properly work with the lifecycle management ... works for a while and then falls back to replace only
[10:44] <dbarth> ogra_: ie, did it start from a particular imag eversion ?
[10:44] <ogra_> dbarth, any image from the weekend and today
[10:45] <dbarth> hmm,so i need to update first
[10:45] <dbarth> ogra_: and from what i can see inthe bug report, it's a mix of old a new webapps
[10:45] <ogra_> i only started porting my apps to the new API on the weekend so i cant say how it behaved before
[10:45] <ogra_> nope
[10:45] <dbarth> ie, not all of them use oxide
[10:45] <ogra_> only new ones
[10:45] <dbarth> ah
[10:45] <dbarth> bbc and all got ported?
[10:45] <ogra_> i explicitly started only new ones
[10:46] <dbarth> ok, that's important
[10:46] <ogra_> oh, thats popey's set of apps :)
[10:46] <popey> :D
[10:46] <ogra_> the ones i attached app logs for are all ported
[10:46] <popey> all the ones I listed are webapp-container
[10:46] <popey> i made sure
[10:46] <ogra_> popey, but are they using the 14.04 api ?
[10:47] <popey> how do you mean?
[10:47] <ogra_> in your manifest
[10:47] <popey> http://paste.ubuntu.com/7216487/
[10:47] <popey> looks like it ☻
[10:48] <popey> ignore oggcamp13, thats not published
[10:48] <popey> I bumped them all when oxide landed
[10:48] <ogra_> mine use the same manifest changes the G+ app used, have all been updated to webapp-container in the .desktop and adjusted json files for apparmor
[10:48] <ogra_> right, same here
[10:50] <ogra_> dbarth, another thing i noticed is that --webappUrlPatterns does not seem to be respected at all anymore with the new webapps-container
[10:50] <ogra_> popey, ^^^
[10:50] <bzoltan> ogra_: didrocks: is there any news about the environment settings when autopilot tests are run? I still see that for example the 'phablet-test-run -p gallery-app-autopilot gallery_app' starts the app with the wrong gridunit.
[10:50] <ogra_> external links always open inside the app
[10:51] <didrocks> bzoltan: do you have a bug report with it?
[10:51] <dbarth> ogra_: it's not, it's a limitation of oxide
[10:51] <ogra_> dbarth, aha
[10:51] <dbarth> ogra_: we have a branch for that, and the new 1.0 is hre to let us plug into the new api
[10:51] <dbarth> to do that url containment
[10:51] <dbarth> ogra_: do you see memory issues or similar in the logs?
[10:51] <bzoltan> didrocks:  No. First I would like to know if it is not something I do wrong. Have you seen it?
[10:51] <ogra_> bzoltan, do you have a /home/phablet/.display-mir file around ?
[10:52] <didrocks> bzoltan: as you are the only one reproducing that and even the dashboard is working, it's hard without any further info to know what was the cause
[10:52] <ogra_> right, i woder if the --wipe didnt clean his home
[10:52] <bzoltan> ogra_: there is no such file
[10:52] <didrocks> ogra_: we still rely on the file? wasn't the check removed since we drop SF support?
[10:52] <ogra_> bzoltan, good then
[10:53] <ogra_> didrocks, we dont rely on it ... would it have been there it would indicate a bug ... and might have pointed to something still using it somehow
[10:53] <didrocks> ogra_: I still have it
[10:53] <ogra_> thats why i asked
[10:53] <bzoltan> didrocks: I am not sure yet if it is effecting the tests... I wonder if anybody has run recently any autopilot tests manually, like I do
[10:53] <didrocks> for isntance
[10:53] <ogra_> didrocks, right
[10:53] <didrocks> bzoltan: we did
[10:53] <ogra_> it should be a no-op
[10:53] <didrocks> bzoltan: see the landing mailing list
[10:54] <ogra_> (but it is possible something was missed, thats why i asked)
[10:54] <didrocks> bzoltan: so I guess a bug report will be the only way and ask if other sees it as well, but right now, you are the only one into that situation, I'm afraid
[10:54] <popey> rsalveti: is https://code.launchpad.net/~thomas-voss/platform-api/hw-alarms-api/+merge/210592 on your list to review? Please can it be?
[10:55] <davmor2> didrocks: right so the phone on 256 works fine on 258 no images so it is the new scopes again by the look of it
[10:55] <didrocks> davmor2: ok, is it a blocker in your opinion?
[10:56] <ogra_> 256 ?
[10:56]  * ogra_ hopes davmor2 means 276
[10:57] <didrocks> ogra_: no 256
[10:57] <didrocks> as we discussed this morning
[10:57] <ogra_> ugh
[10:57] <davmor2> didrocks: no stuff works just no images but I'm sure as pat discovered it, it will be known and worked on, I'll check if pat filed a bug first before I do :)
[10:57] <didrocks> davmor2: ok, keep me posted if you set it on the blocker list (and keep thostr_ aware as well)
[10:58] <thostr_> didrocks: yes, saw that one. a fix will take a while but question is if we need a fix or just remove that setting. this is a policy question as well...
[10:58] <didrocks> thostr_: are you moving that discussion then?
[10:58] <thostr_> didrocks: davmor2: can we not list the privacy thing as a blocker for now?
[10:58] <didrocks> thostr_: well, for now, we have a regression
[10:58] <didrocks> like, old scopes -> we have a settings working
[10:58] <thostr_> didrocks: got the question back to cparrino
[10:58] <didrocks> now, it doesn't
[10:59] <didrocks> and let user thinking it's working
[10:59] <thostr_> didrocks: but old and new scopes are fundamentally different in that regard
[10:59] <didrocks> thostr_: I wonder then why (if this was known), removing the settings wasn't coordinated with the system settings team?
[11:00] <thostr_> didrocks: old scopes just fired queries into universe without user noticing, now, user does queries scopes more explicitely
[11:00] <ogra_> didrocks, nothing is replaced per-se in bug 1303676 ... only the last one is constantly replacin, before the apps crash
[11:00] <didrocks> thostr_: can you reach up a conclusion by end of the day?
[11:00] <thostr_> didrocks: I forgot about it... but I want to get guidance from guys higher up the chain
[11:00] <didrocks> thostr_: we are close to the finale image and if seb128's team needs to remove the settings, they need to know asap
[11:01] <didrocks> ogra_: I don't have the same experiment, but I may be wrong, just feel free to update the bug :/
[11:01] <didrocks> ogra_: experience*
[11:01] <seb128> didrocks, did we got another feature dropped without anyone talking to us about the settings impact?
[11:01] <didrocks> seb128: exactly
[11:01] <seb128> "great"
[11:01] <thostr_> seb128: didrocks: slowly here...
[11:02] <thostr_> seb128: didrocks: let me first confirm with others what we want to have / need in that regard
[11:02] <didrocks> thostr_: keep us posted then, the blocker will either being the system-settings to remove the settings
[11:02] <didrocks> or the fix to come
[11:02] <thostr_> didrocks: yes
[11:03] <seb128> thostr_, thanks, just a fyi, the design is on https://wiki.ubuntu.com/SecurityAndPrivacySettings#Dash_search
[11:03] <seb128> thostr_, could you get the design updated if the change is confirmed/wanteD?
[11:03] <thostr_> seb128: yes, i'll
[11:03] <seb128> thanks
[11:04] <kgunn> Mirv: hey, am i gonna get a silo :) ?
[11:06] <davmor2> thostr_: this test was on the images in the scopes not appearing if you are on 3g :)  the issue regarding privacy is a blocker, if you however make the decision to drop the setting may I recommend that you update the bug and that way we can consider that the fix and unblock for now though that is by and far not the only blocker :)
[11:06] <Mirv> sil2100: ^ what did we discuss about Mir again? there's a cherry-pick fix for one u8 crasher included
[11:07] <davmor2> thostr_: so there is time for the discussion and decision to be made :)
[11:07] <sil2100> Mirv: the final decision was to have a talk with kgunn and decide if there are any important landings
[11:07] <sil2100> And assessing the risk
[11:07] <sil2100> kgunn: hi! How risky is that landing? Is it mostly bug-fixes?
[11:07] <Mirv> sil2100: yeah, now we talk :)
[11:08] <sil2100> kgunn: and what crashers are we talking about? Some blocker-ones? ;)
[11:08] <Mirv> sil2100: I think the bug #1256360 is the one that only (?) happens during testing
[11:11] <didrocks> ogra_: thanks for the clearer bug title!
[11:11] <ogra_> heh
[11:12] <thostr_> didrocks: davmor2: seb128: just commented on https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1302801
[11:14] <didrocks> thostr_: are you driving up to reach to a conclusion on your 2 options? It's a blocker and will need to be resolved before we can promote an image
[11:15] <thostr_> didrocks: this is not broken since last friday... it's long unfortunately, but that should also mean we should be able to promote one, no?
[11:15] <didrocks> thostr_: no, it's not in latest promoted image
[11:15] <didrocks> thostr_: so it's a regression from that stand points
[11:15] <didrocks> thostr_: and people who disable the switch will think it's not getting online results
[11:15] <didrocks> when it will
[11:16] <didrocks> so, if next image is going to be the last one we promote, we ship with a broken settings
[11:16] <didrocks> clearly a blocker IMHO
[11:16] <kgunn_> Mirv: sil2100 yeah, so that mir is mostly bug fixes, low risk...but more than just that one particular bug fix
[11:16] <thostr_> didrocks: ok, the maybe option c
[11:17] <ogra_> we wont promote until the Qt events bug is fixed anyway ... which seems to have come to a stall (at least i dont see any more discussion about it and there was no conclusion either)
[11:17] <ogra_> so you should have time to find a fx
[11:17] <didrocks> thostr_: c?
[11:18] <sil2100> Mirv: let's maybe try assigning a silo then ;)
[11:18] <didrocks> ogra_: I'm unsure we won't promote until the Qt events bug is fixed
[11:18] <thostr_> didrocks: implement half of option 2) to not regress for now (today/tomorrow) and try to find best optoin in meantime
[11:18] <ogra_> didrocks, oh ?
[11:18] <didrocks> ogra_: it's up to QA to decice that
[11:18] <didrocks> decide*
[11:18] <didrocks> thostr_: sounds good to me
[11:18] <seb128> thostr_, the handling of those privacy options is a sensitive topic, in any case I suggest we handle things careful to not create the impression that we want to spy on users/remove their freedom to optout of sending things online
[11:18] <ogra_> well, the conditions didnt change
[11:19] <seb128> didrocks, ^
[11:19] <didrocks> seb128: agreed, didn't say it, but I had that in mind
[11:19] <thostr_> seb128: exactly, that's why I invited other people to comment on it
[11:19] <didrocks> thostr_: but fixing and then discussing for now sounds like the safest path
[11:22] <popey> cihelp: trying to build reminders-app-click in jenkins, it fails with "ERROR: Failed to clean the workspace
[11:22] <popey> http://s-jenkins:8080/job/reminders-app-click/5/console
[11:24] <Mirv> sil2100: sounds like a plan
[11:25] <Mirv> kgunn: landing-005
[11:26] <Mirv> I had to ignore conflicts because of the greeter split sio
[11:26] <Mirv> silo
[11:26] <sil2100> Mirv: thanks o/
[11:28] <kgunn> ta! Mirv
[11:31] <psivaa> popey: http://s-jenkins:8080/job/reminders-app-click/6/console appears happy now. had to manually clean the workspace. a reboot could have messed up the permissions
[11:31] <popey> great, thanks psivaa
[11:31] <psivaa> yw :)
[11:35] <psivaa> didrocks: mako runs with 280 has completed. with no more new failures other than one in unity8 and dialer each
[11:36] <didrocks> psivaa: excellent, no other crashers?
[11:37] <psivaa> didrocks: no more than the usual 3
[11:37] <didrocks> ok, thanks
[11:38] <davmor2> seb128, didrocks: man images are still auto-downloaded on 3g even when the device says internet only arrrgggghhhh
[11:38] <seb128> 3g is internet?
[11:38] <davmor2> wi-fi only even
[11:38] <seb128> or you mean wifi?
[11:39] <seb128> k, well the settings didn't change in that regard afaik, is that a known issue with the service?
[11:40] <davmor2> seb128: I filed a bug and iirc it was decided that the system-image-cli were never asked to implement it so it was meant to be a settings team job and settings said it the other way :)
[11:40] <seb128> ?
[11:40] <seb128> first time I read about that
[11:41] <ogra_> davmor2, did you notice that the UI goes empty if you swipe upwards while watching the download a few times ?
[11:41] <Laney> That would be a strange thing to say because system-image automatically starts downloads when you ask it to check for updates
[11:41] <davmor2> seb128: I think the settings team were under the impression that system-image-cli was implementing it and I think barry said nope we weren't doing that
[11:41] <seb128> but no, it's not a settings team job, we are using a dbus interface that is provided by the service
[11:42] <seb128> davmor2, dunno about -cli
[11:42] <seb128> but https://wiki.ubuntu.com/ImageBasedUpgrades/Client
[11:42] <seb128> SetSetting(key, value)
[11:42] <seb128> auto_download - A tri-state (currently) value indicating whether downloads should normally proceed automatically if an update is available or not. The value is the string representation of the following integer values.
[11:42] <seb128> 0 - Never download automatically (i.e. an explicit DownloadUpdate() call is required to start the download)
[11:42] <seb128> 1 - Only auto-download if the device is connected via wifi (the default)
[11:42] <seb128> 2 - Always download the update automatically
[11:42] <seb128>  
[11:42] <seb128> davmor2, ^ we use that documented interface for the service
[11:43] <davmor2> seb128: okay is there a way I can check what setting I have?  I'm wondering if the right setting has been mislabelled
[11:44] <seb128> davmor2, GetSetting("auto_download") on that dbus interface
[11:44] <bzoltan> didrocks: against what I should file that bug and who to assign?
[11:45] <didrocks> bzoltan: I have no idea, maybe ask on the mailing list?
[11:46] <bzoltan> didrocks: ask who? Sorry for my corporate mind .. I prefer to to talk to real people :) This is a shell issue... and it came last week -> http://pastebin.ubuntu.com/7216658/
[11:46] <didrocks> bzoltan: well, I don't know. I'm not the QA dispatcher either
[11:46] <bzoltan> didrocks: I know.. sorry
[11:47] <didrocks> so start with owners of phablet-test-tools?
[11:47] <didrocks> like sergio
[11:47] <didrocks> I don't think I need to centralize all local issues in addition to image ones
[11:49] <seb128> bzoltan, hey, you have some silos that seem ready for testing/landing, can you do that? ;-)
[11:49]  * seb128 waits for available silos for desktop iteams
[11:49] <seb128> items
[11:50] <ogra_> iTeams ... new apps SW
[11:50] <bzoltan> seb128: I need Cimi to say OK for that silo as it contains unity9 bits too
[11:50] <ogra_> from apple :)
[11:50] <seb128> lol
[11:50] <seb128> bzoltan, https://code.launchpad.net/~bzoltan/qtcreator-plugin-ubuntu/unity-scope-tool/+merge/213665 ?!
[11:50] <seb128> bzoltan, that seems a 1 liner to control
[11:50] <ogra_> we switch to unity9 right before release ?
[11:50] <ogra_> thats brave :P
[11:51] <bzoltan> seb128: I am paranoid :)
[11:51] <bzoltan> ogra_: yes, and unity10 is the 14.04 target
[11:51] <sil2100> seb128: we should have a silo spare in some moments ;)
[11:51] <seb128> bzoltan, well, that depends fix for qtcreator-plugin-ubuntu seems safe
[11:51] <thostr_> seb128: just had a discussion with asac about the privacy flag: we think it's best to just disable it for now (until we get more feedback)
[11:52] <seb128> thostr_, can you open a bug on https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+filebug about that/asking for the design to be updated?
[11:52] <bzoltan> seb128:  ehh.. sorry it is a differnt landing
[11:53] <seb128> thostr_, I'm declining any responsability on whatever the online reactions are going to be to the "disable the privacy option"
[11:54] <sil2100> didrocks: hmmm, do you know by any chance why the m&c for silo 11 would fail saying that the package is still in -proposed while rmadison says it's in the release archive?
[11:54] <didrocks> sil2100: I need to check I guess
[11:55] <thostr_> seb128: ack
[11:55] <didrocks> thostr_: we are going to get flack for it…
[11:55] <didrocks> asac: ^
[11:55] <didrocks> is this validated by design/legal?
[11:55] <sil2100> ;/
[11:55] <bzoltan> seb128: that silo is good to go
[11:55] <asac> didrocks: i am checking with folks
[11:55] <asac> didrocks: note that there is no "search all scopes" search form anymore
[11:56] <seb128> bzoltan, thanks
[11:56] <asac> but that you can only search in one scope
[11:56] <seb128> sil2100, ^ silo 16 is good to land
[11:56] <sil2100> seb128: excellent!
[11:57] <didrocks> sil2100: oh I know
[11:57] <didrocks> one sec
[11:57] <sil2100> seb128: huh...
[11:57] <seb128> sil2100, ?
[11:58] <sil2100> seb128, bzoltan: but the PPA is empty - what were you guys testing in silo 16?
[11:58] <sil2100> No package has been built, the build job was not executed as well
[11:58] <seb128> sil2100, oh, sorry, I didn't check details, I'm just looking at the summary table to find to free silos
[11:58] <sil2100> Ah ;)
[11:58] <sil2100> bzoltan: ^
[11:58] <seb128> sil2100, seems like we should run the build job then!
[11:58] <didrocks> sil2100: mind retrying?
[11:59] <sil2100> seb128: yes, and actually do the testing! ;)
[11:59] <sil2100> didrocks: ok, thanks - what was wrong?
[11:59] <didrocks> sil2100: my change to take into account -updates
[11:59] <didrocks> mixed "or" and "and" with using "not"
[11:59] <sil2100> bzoltan: ok, so, can you build packages from the silo and test the package that has been generated in the PPA then?
[12:02] <popey> asac: swipe left to scopes, hit search, type "Motl" - see http://popey.com/~alan/phablet/device-2014-04-07-130150.png - how can it know that without sending that data somewhere?
[12:02] <popey> Note: I did not explicitly select a scope.
[12:03] <asac> thostr_: ^
[12:03] <asac> wdyt?
[12:03] <popey> i can see the traffic in ~/.cache/upstart/smart-scopes-proxy.log !
[12:03] <thostr_> popey: well, you selected the scope scope
[12:04] <popey> 12:55:54 < asac> didrocks: note that there is no "search all scopes" search form anymore
[12:04] <popey> thats patently not true.
[12:04] <jdstrand> that untappd denial> it just needs the 'audio' policy group
[12:04] <popey> it just has a different name.
[12:04] <popey> jdstrand: done ☻
[12:04] <asac> popey: i thougth we had a scope where you can search for scopes
[12:04] <asac> that one is online
[12:04] <jdstrand> ok
[12:04] <thostr_> popey: there is a difference if you search for scopes or search within scopes
[12:04] <popey> not from a privacy point of view. The fact is I sent "mot" over the wire.
[12:04] <thostr_> popey: previously, you search ended somewhere on the planet without you as user knowing
[12:05] <popey> how does it not now?
[12:05] <asac> howveer, I think we might need to do something on supporting the search context better through design
[12:05] <popey> i swiped left and typed "Mot"
[12:05] <ogra_> davmor2, popey http://people.canonical.com/~ogra/empty-scopes-shot.png
[12:05] <thostr_> popey: you don't get an result back
[12:05] <ogra_> i see that after closing a webapp with "Quit" from the hud
[12:05] <asac> thostr_: he got auto corrected terms back
[12:05] <thostr_> popey: it's true that you still query our server, but nothing else
[12:05] <popey> thostr_: the i did get results
[12:05] <popey> right, that will be a problem.
[12:06] <thostr_> popey: but, you don't send the query anywhere to any 3rd party
[12:06] <popey> yes, it does
[12:07] <popey> I just typed "bett" in mine and get image results for Bette Midler, that image came from a 3rd party
[12:07] <popey> {"result": {"subtitle": "Betty Marion White is an American actress, comedian, presenter, singer, author, and television personality.", "title": "Betty White", "cat_id": "related searches", "uri": "http://en.wikipedia.org/wiki/Betty_White", "preview_info": {"type": "wikipedia"}, "dnd_uri": "http://en.wikipedia.org/wiki/Betty_White", "mascot": "http://upload.wikimedia.org/wikipedia/commons/thumb/1/1d/Betty_White_2010.jpg/96px-Betty_White_2010.jpg"}}
[12:07] <thostr_> popey: wikipedia and weather are the only exceptions
[12:08] <thostr_> popey: the big problem in former times was: you typed "term" in your home scopes
[12:08] <thostr_> and your query was fired to anybody in the world
[12:08] <popey> that was _one_ of the issues.
[12:09] <popey> What controls the exception that wikipedia and weather has?
[12:09] <thostr_> this is us
[12:11] <asac> thostr_: couldnt we hook up this setting to not search wikipedia?
[12:11] <asac> or would have have ignored that setting in the past too for wiki and weather?
[12:12] <thostr_> we can patch all our scopes to listen to that setting
[12:12] <thostr_> but eventually we cannot enforce this for trusted scopes
[12:14] <thostr_> we can patch all our scopes for now until we get some more guidance
[12:15] <ogra_> ++
[12:16] <ogra_> the privacy stuff is pretty critical to press etc ... we should better have it more conservative if inn doubt
[12:17] <cwayne_> do you guys have any idea what's up with ubuntu-touch-customization-hooks?  I think it was supposed to have been autolanding, but it looks like lp:u-t-c-h and lp:ubuntu/u-t-c-h are out of sync
[12:18] <bzoltan> sergiusens: Mirv: https://bugs.launchpad.net/ubuntu/+source/phablet-tools/+bug/1303774
[12:19] <seb128> sil2100, Mirv: we are up to 4 silos, can I get some?
[12:19] <sergiusens> bzoltan: fwiw, I would consider that an image bug as the grids unit px is supposed to be set by that
[12:19] <sil2100> seb128: sure!
[12:20] <sil2100> seb128: doing :)
[12:20] <seb128> thanks
[12:20] <davmor2> ogra_: yeap related to popeys bug on where the bottom of the screen thinks it is
[12:20] <bzoltan> sergiusens: I agree... but I could not find anybody for that. ogra_ and didrocks say that they have never seen it. Mirv and I got it... I wonder if you have seen this problem.
[12:20] <davmor2> ogra_: at least I'm assuming it is
[12:21] <ogra_> davmor2, ok
[12:21] <davmor2> ogra_: https://bugs.launchpad.net/bugs/1300302
[12:21] <davmor2> ogra_: if it is reproducible please add steps
[12:21] <sergiusens> bzoltan: I shoved it to ogra_ and set it to affect lxc-android-config
[12:21] <sergiusens> ;-)
[12:22] <ogra_> davmor2, not constantly reproducable ... but i get it more often when stopping apps via the hud quit function
[12:22] <ogra_> sergiusens, huh ?
[12:22] <sergiusens> ogra_: some bug about env vars
[12:22] <ogra_> sergiusens, yes
[12:22] <Mirv> sergiusens: ogra_: note that the bug only happens when eg. phablet-test-run dialer_app, not when executing the app on phone normally
[12:22] <ogra_> sergiusens, why would lxc-android-config have anythin to do with it
[12:23] <sergiusens> Mirv: only for legacy apps?
[12:24] <sergiusens> ogra_: well it's not phablet test run for sure; it's an env thing; and slangasek added the "correct" adb shell cli command; which probably means the environment is not imported correctly
[12:24] <ogra_> this is a an env setting you get by bashrc
[12:24] <ogra_> root@ubuntu-phablet:~# grep PX /home/phablet/.bashrc
[12:24] <ogra_> export GRID_UNIT_PX=18
[12:24] <sergiusens> ogra_: might be livecdrootfs
[12:24] <ogra_> (which gets put in place by ubuntu-touch-session)
[12:24] <sergiusens> right; wrong target :-)
[12:24] <ogra_> i would assume the bashrc isnt properly parsed
[12:24] <Mirv> yep, it's there but somehow does not work with phablet-test-run
[12:24] <ogra_> (unless Mirv or bzoltan can confrim there is no PX entry)
[12:25] <ogra_> so this is clearly phablet-tools or adbd not parsing bashrc
[12:26] <cjwatson> I think slangasek switched to sh, which would mean bashrc isn't loaded?
[12:26] <bzoltan> ogra_: sergiusens: the export GRID_UNIT_PX=18 is there of course
[12:26] <ogra_> right
[12:26] <ogra_> so its the parsing of that file that is broken
[12:26] <sergiusens> bzoltan: ogra_? http://paste.ubuntu.com/7216811/
[12:26] <bzoltan> ogra_: sergiusens: I guess it is related to the shell changes... because QtCreator's remote app deployment were hit by this too.. and there we needed to adjust too
[12:26] <sergiusens> ogra_: phablet-tools doesn't parse anything; and shouldn't
[12:26] <ogra_> sergiusens, hmm, i think slangasek chenged the command in phablet-tools
[12:27] <ogra_> sergiusens, to sh -c
[12:27] <sil2100> seb128: regarding silo 15 - should I reject this landing, or maybe you want to re-use this landing for the fixed version?
[12:27] <cjwatson> so sh -c => bash -c?
[12:27] <sergiusens> ogra_: right, you get nothing back with sh
[12:27] <ogra_> that wouldnt parse bashrc
[12:27] <ogra_> yeah, its another chell
[12:27] <ogra_> *shell
[12:27] <seb128> sil2100, I'm waiting for tedg to be up and to do the one line fix, please keep the silo
[12:27] <cjwatson> it sounds like that's all you need to fix it
[12:27] <ogra_> right
[12:28] <cjwatson> it'll be slower again, but there you go
[12:28] <ogra_> yeah, speed doesnt really matter here
[12:30] <sergiusens> ogra_: so revert steve's changes?
[12:31] <ogra_> for the places where we need bashrc parsed yeah
[12:31] <sergiusens> ogra_: sh/dash reads $HOME/.profile, can't we add those env vars there?
[12:31] <sil2100> seb128: ok
[12:31] <ogra_> sergiusens, try it ... if thats enough, yes we can
[12:32] <ogra_> sergiusens, or even better, parse the $device.conf file from the session manager
[12:32] <ogra_> so we dont need the values hardcoded in there
[12:33] <sergiusens> ogra_: http://paste.ubuntu.com/7216832/
[12:33] <sergiusens> so it works
[12:33] <ogra_> oh, intresting
[12:34] <cwayne_> josepht, any idea what's up with ubuntu-touch-customization-hooks?  I think it was supposed to have been autolanding, but it looks like lp:u-t-c-h and lp:ubuntu/u-t-c-h are out of sync
[12:34] <ogra_> why does it not end up in the test then
[12:34] <sergiusens> ogra_: well the manpage for dash said it should read ~/.profile; I would expect as much to be true
[12:34] <bzoltan> ogra_: sergiusens: since when this sh vs bash is there?
[12:34] <josepht> cwayne_: looking now
[12:34] <sergiusens> bzoltan: a week or so
[12:35] <cwayne_> josepht, thanks
[12:35] <ogra_> bzoltan, since last week
[12:35] <davmor2> cwayne_: they hate you, it's just that simple ;)
[12:35] <bzoltan> sergiusens:  and since than who has recognized that _NO_ autopilot test shows correct UI?
[12:35] <cjwatson> sergiusens: please don't revert them, just sh -c => bash -c ?
[12:35] <ogra_> bzoltan, thats why i asked you if you are on the recebt phablet-tools last week when we talked about it
[12:35] <cjwatson> that should be all you need, rather than going back to the extra login shell business
[12:35] <sergiusens> cjwatson: but that's exactly what steve changed
[12:35] <bzoltan> ogra_: I was and I am
[12:35] <sergiusens> the other way around
[12:35] <cwayne_> davmor2, haha, probably :)
[12:35] <ogra_> right
[12:35] <cjwatson> sergiusens: he did more than that
[12:36] <sergiusens> bzoltan: I don't look at tests when they run
[12:36] <cjwatson> sergiusens: there was the shell change, and *also* the login-shell-to-not change
[12:36] <sergiusens> cjwatson: right; I'll make that change s/sh/bash/
[12:36] <bzoltan> sergiusens: it is good that we have a fix
[12:37] <mandel> vila, a propose solution for the timeout issues in the PS CI bot => http://bazaar.launchpad.net/~mandel/ubuntu-download-manager/udm-shared-libs/view/head:/ubuntu-download-manager-test-lib/ubuntu/download_manager/tests/base_testcase.h#L43
[12:37] <cjwatson> sergiusens: (but certainly if it's possible to fix without going back to bash, that's even better)
[12:37] <mandel> vila, I'm hoping it will fix all the issues by waiting for ever
[12:37] <sergiusens> cjwatson: should be; we just need to make ~/.profile read up the envvars
[12:38] <ogra_> yeah
[12:38] <ogra_> a shell snippet in profile.d should help
[12:38] <ogra_> there was a reason why i kept it in bashrc when porting the other bits to snippets ...
[12:39] <ogra_> ... but i cant remember it anymore
[12:40] <seb128> bzoltan, silo 016 is built/ready to be tested (it's the depends change mentioned earlier)
[12:41] <sergiusens> ogra_: bzoltan I'll have a fix soon
[12:41] <bzoltan> sergiusens: Thank you!
[12:42] <bzoltan> sergiusens:  I will demo the Ubuntu on Nexus with the autopilot testing mechanism next week :) it would be shame to show a non functioning setup :D
[12:43] <josepht> cwayne_: those autolandings are going through ci-train now, right?
[12:43] <ogra_> bzoltan, just present image 250 with the old phablet-tools then :P
[12:44] <bzoltan> ogra_:  I do dist-upgrade every morning and flash the device like 5-8 times a day :)
[12:44]  * ogra_ wasnt serious :) 
[12:44]  * bzoltan neither
[12:45] <bzoltan> ogra_: it is cool that this problem got fixed :) that is what counts
[12:46] <ogra_> yeah
[12:46] <vila> mandel|lunch: ack
[12:46] <cwayne_> josepht, im not sure u-t-c-h was ever setup for ci-train to be honest
[12:48] <sergiusens> ogra_: https://code.launchpad.net/~sergiusens/ubuntu-touch-session/dash_dot_profile/+merge/214523
[12:48] <sergiusens> works for me fwiw
[12:48] <ogra_> sergiusens, how about we do the whole parsing from the profile.d snippet
[12:48] <ogra_> and rip it out of the session startup
[12:49] <ogra_> that will speed up the session startup too
[12:49] <sergiusens> ogra_: ok; is that livecdrootfs?
[12:49] <ogra_> (since it will only be run on shell login )
[12:49] <ogra_> sergiusens, nope, a few lines up
[12:50] <ogra_> # override defaults by sourcing /etc/ubuntu-touch-session.d/$device.conf
[12:50] <ogra_> device=$(getprop ro.product.device)
[12:50] <ogra_> [ -e /etc/ubuntu-touch-session.d/$device.conf ] && . /etc/ubuntu-touch-session.d/$device.conf
[12:50] <josepht> cwayne_: I'll track it down and let you know
[12:50] <ogra_> oh, crap, we cant
[12:50] <ogra_> sergiusens, ignore that
[12:50] <sergiusens> ogra_: not easily, no
[12:51] <cwayne_> josepht, awesome, thank you
[12:51] <ogra_> i guess that code costs us a second of the boot time
[12:51] <sergiusens> fwiw, I prefer this instead of going back to bash
[12:52]  * ogra_ puts it on his list for "think over"
[12:52] <ogra_> sergiusens, yeah, its fine
[12:52] <sergiusens> ogra_: I'll get a silo for this
[12:52] <ogra_> getting the value is the more costly piece here
[12:52] <ogra_> running gretprop ... then read a file etc etc
[12:52] <ogra_> (and writing to one)
[12:54] <sergiusens> ogra_: can I get your stamp on that to run the silo?
[12:54] <ogra_> yup
[12:54] <ogra_> done
[12:54] <sergiusens> ogra_: yeah; we probably need to getprop once and save it somewhere where we can access from memory
[12:55] <sergiusens> sil2100: hey, can I get a silo for l49 please?
[12:55] <ogra_> i need to measure if getprop is faster than reding from a file
[12:55] <ogra_> but yeah, storing it somewhere on the first session startup and never having to run it again would be preferable to "run it on every session startup"
[12:56] <josepht> didrocks: should ubuntu-touch-customization-hooks be landing via ci-train now?
[12:56] <sergiusens> ogra_: come to think of it; iirc getprop loads everything into memory; need to recheck the property code
[12:56] <sil2100> sergiusens: is this a fix for some blocker? We're low on silos right now so I need to assess the importance
[12:56] <ogra_> sergiusens, then we should dump it into a persistent property on the first run of ubuntu-touch-session ... and read it from there ... only do the writing and reading once
[12:57] <sergiusens> sil2100: it's for a critical bug
[12:57] <sil2100> sergiusens: ACK
[12:57] <sil2100> Let me assign then
[12:58] <sergiusens> thanks
[13:00] <nuclearbob> o/
[13:01] <nuclearbob> whoops
[13:13] <fginther> josepht, cwayne_, ubuntu-touch-customization-hooks is in the ci-train list (Line 89) https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdC05a2ZQSmgwU2NFYnJQOE9qMDRYa3c&usp=drive_web#gid=1
[13:15] <cwayne_> fginther, hm, maybe it hasn't been pushed to since citrain started, would that make sense?
[13:16] <fginther> cwayne_, yes, in fact the last trunk update was in Oct 2013, well before ci-train started on this project
[13:17] <cwayne_> makes sense
[13:17] <cwayne_> fginther, is there any way to trigger it without a new push?
[13:20] <fginther> cwayne_, this probably just needs to have a landing scheduled, please work with the ci-train support listed in the channel topic.
[13:21] <cwayne_> sil2100, hiya ^ any chance we can get a landing scheduled for ubuntu-touch-customization-hooks?
[13:30] <rsalveti> morning
[13:31] <rsalveti> popey: ricmm is the responsible now to get the alarm MRs in place
[13:35] <popey> morning rsalveti, thanks
[13:36] <sil2100> cwayne_: let me look, sorry, I had lunch
[13:38] <seb128> sil2100, cwayne_: can you please give slots to those who are waiting for longer firsT?
[13:40] <sil2100> seb128: sure, sergio got a silo since he had a priority landing - I'm tryign to assign stuff but we're anyway low on silos still
[13:44] <seb128> bzoltan, can you test you silo 016 ?
[13:44] <seb128> mhr3, your silo 008 seems like reading for landing?
[13:45] <bzoltan> seb128: sure
[13:45] <seb128> sil2100, maybe you can claime back the silos that fail to build and give them a slot again later once they sort their build issues?
[13:45] <seb128> bzoltan, thanks
[13:45] <mhr3> seb128, yep
[13:45] <seb128> mhr3, thanks
[13:55] <sergiusens> bzoltan: can you give https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=35 a quick test to see if it fixes your issues?
[13:56] <bzoltan> sergiusens: sure
[13:56] <stgraber> heya, we have a click bugfix release if someone can spare us a silo
[13:57] <sil2100> stgraber: hi! We're really low on silos now sadly, so you'll have to wait a little bit ;)
[13:57] <sil2100> I'm working on making more
[13:58] <sergiusens> stgraber: I should free one soonish
[13:59]  * ogra_ thinks starting to deal with vats might be a valuable thing in here  
[14:00] <davmor2> ogra_, popey: I think I have steps to reproduce the missing app icons issue.  If you open a top app in the installed section they are all there on closure.  If you open one of the bottom apps in the installed section ie scroll down to it then you get the missing app icons \o/ winner
[14:01] <popey> davmor2: define "top" and "bottom"?
[14:01] <ogra_> ah, thats why i get it so often
[14:01] <ogra_> popey, expand ... if you have to scroll it is a "bottom app"
[14:02] <popey> ah
[14:02] <didrocks> josepht: yeah, everything should
[14:03] <josepht> didrocks: okay, thanks
[14:03] <popey> davmor2: yup http://popey.com/~alan/phablet/device-2014-04-07-150301.png
[14:03] <didrocks> yw!
[14:03] <ogra_> popey, oh, wow, i only get it after i close the last app
[14:03] <davmor2> popey: \o/ winner I'll add steps to the bug
[14:04] <popey> i just opened two apps, one from top, one from bottom
[14:04]  * ogra_ never has something in "recent"
[14:04] <popey> then switched to app scope
[14:06] <ogra_> hmm, i cant reproduce it at all on my flo with 277 on it
[14:07]  * ogra_ upgrades to 280
[14:10] <popey> ogra_: i cant reproduce on flo either
[14:10] <popey> on 280
[14:10] <ogra_> flo has other issues intrestingly
[14:10] <ogra_> close an app with the hud
[14:11] <ogra_> you get a faded out scope back
[14:12] <seb128> sil2100, silo 016 seems good to publish this time ;-)
[14:12] <sil2100> \o/
[14:12] <sil2100> I love the 'ready to publish' sentence
[14:12] <sil2100> ;)
[14:14]  * didrocks put an unexpected joke?
[14:14] <sil2100> No no, I just love the sound of that
[14:14] <sil2100> Especially when we're low on silos
[14:14] <sil2100> ;)
[14:15] <didrocks> heh
[14:16] <sil2100> didrocks: packaging ACK needed! Looks sane right now: https://ci-train.ubuntu.com/job/landing-016-2-publish/2/artifact/packaging_changes_qtcreator-plugin-ubuntu_3.0.1+14.04.20140407-0ubuntu1.diff
[14:16] <bzoltan> sergiusens:  I had installed the ubuntu-touch-session from that PPA, rebooted and now the test apps look fine. thanks
[14:17] <sergiusens> bzoltan: awesome; will get it landed ASAP
[14:17] <sergiusens> ogra_: can you publish https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=35 ?
[14:18] <didrocks> sil2100: +1
[14:18] <sil2100> didrocks: thanks!
[14:19] <didrocks> yw
[14:21] <bzoltan> sil2100:  both my silos are good to land
[14:22] <sil2100> bzoltan: thanks, already published both of them some moments ago ;)
[14:22] <bzoltan> sil2100: your kvik
[14:22] <bzoltan> :D
[14:23] <didrocks> bzoltan: sil2100 published faster than you typing, didn't you know that? :p
[14:24] <bzoltan> didrocks:  I do it with a 9m old boy in my left hand ;)
[14:24] <didrocks> bzoltan: ahah, you are raising the bar!
[14:25] <sil2100> No no, he's raising a son!
[14:25] <sil2100> :D
[14:25] <sergiusens> rsalveti: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=35 can you publish?
[14:25] <bzoltan> didrocks:  no :) i just try to do two things at the same time ... and I suck ass in both :D
[14:26] <didrocks> heh
[14:32] <rsalveti> sergiusens: do we need the vars in both .bashrc and .profile?
[14:32] <sergiusens> rsalveti: yes
[14:33] <rsalveti> why?
[14:33] <sergiusens> rsalveti: oh, not yes for the env
[14:33] <sergiusens> rsalveti: just yes for bash and dash
[14:33] <rsalveti> sergiusens: right, but isn't just .profile enough for both?
[14:33] <ogra_> rsalveti, i want to move that to a profile.d snippet instead
[14:34] <ogra_> and have the session manager use a different (less costly) way
[14:34] <rsalveti> yeah, if we can remove those things from bashrc it would be greate
[14:34] <rsalveti> *great
[14:34] <ogra_> right
[14:34] <ogra_> sergiusens solution is a good quick fix
[14:34] <dbarth> sil2100: o/ can i haz a new silo on line 50?
[14:34] <rsalveti> just want to know if .profile is also not enough for bash
[14:34] <ogra_> but long term i want to eleminate such code from the session startup
[14:34] <ogra_> rsalveti, it is
[14:35] <ogra_> unless the user creates a ~/.bash_profile ... then it wont be read at all
[14:35] <sergiusens> rsalveti: we used to have issues iirc with .profile and bash
[14:35] <rsalveti> if so, then I guess we could remove them from .bashrc
[14:35] <sil2100> dbarth: o/ sorry, we're low on silos, so you will have to wait a bit probably...
[14:35] <ogra_> sergiusens, .bashrc is read by .profile
[14:35] <ogra_> have a look at the .profile file ;)
[14:36] <sergiusens> ogra_: bashrc is read by profile, but what does bash read? If it's bashrc, then it won't work
[14:36] <ogra_> try it ?
[14:36] <rsalveti> yeah :-)
[14:36] <sergiusens> we had this env issue before reason for using the sudo instead of su thing
[14:37] <ogra_> phablet@ubuntu-phablet:~$ env|grep PX
[14:37] <ogra_> GRID_UNIT_PX=18
[14:37] <ogra_> after moving the vars to .profile
[14:38] <rsalveti> it's just easier to clean this up later on if we have it only in one place
[14:38] <dbarth> sil2100: ok, understood; but note that those are desktop bug fixes, so we're a bit in a hurry there
[14:40] <sergiusens> ogra_: yeah, tested just now; updating the MR
[14:43] <sergiusens> rsalveti: https://code.launchpad.net/~sergiusens/ubuntu-touch-session/dash_dot_profile/+merge/214523 check it now
[14:44] <rsalveti> bzoltan: mind testing this guy again ^?
[14:45] <sergiusens> rsalveti: needs to be rebuilt
[14:45] <sergiusens> rsalveti: which is happening now
[14:45] <davmor2> didrocks, ogra_: BOLLOCKS was there a recent update to NM?
[14:45] <sergiusens> rsalveti: although I don't believe he needs to test it again
[14:45] <cyphermox> no
[14:45] <rsalveti> well, would just be good for him to test it
[14:45] <cyphermox> dv
[14:45] <cyphermox> davmor2: no
[14:45] <didrocks> sil2100: we have some silos with "ready to build packages"
[14:45] <rsalveti> but I'm testing it as well
[14:45] <didrocks> sil2100: so I propose we flush them out with a comment
[14:46] <davmor2> cyphermox: I have no wifi available after a bootstrap
[14:46] <ogra_> davmor2, didnt oyu have that with flo recently as well ?
[14:46] <davmor2> ogra_: no
[14:46] <ogra_> i wonder if you need to blame your AP
[14:46]  * ogra_ thought you pinged on friday about that 
[14:47] <davmor2> ogra_: no there are about 4-6 show up normally there is nothing
[14:49] <sil2100> didrocks: k
[14:49] <sil2100> didrocks: already flushed one like that though
[14:50] <didrocks> sil2100: always add a comment
[14:50] <davmor2> cyphermox: do you know when the last NM update was I'm wondering if I haven't hit it prior to this because I have been OTA with all the data in place
[14:50] <didrocks> sil2100: if they didn't care to build…
[14:51] <cyphermox> davmor2: march 06
[14:51] <bzoltan> rsalveti: sergiusens: no worries
[14:55] <davmor2> cyphermox, ogra_, didrocks: http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-04-07-155336.png  and http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-04-07-155510.png this is what I mean by no wifi
[14:55] <ogra_> sergiusens, i cant publish silos
[14:56] <ogra_> (sorry, just noticed the ping)
[14:56] <didrocks> ogra_: hum
[14:56] <bfiller> sil2100: hi, can you reconfigure silo9 as I just added a new project to it (address-book-app)
[14:56] <didrocks> ogra_: why can't you?
[14:57] <sil2100> bfiller: sure
[14:57] <didrocks> ogra_: you are a core-dev, right?
[14:57] <ogra_> didrocks, well, last time i tried i had no permissions
[14:57] <bfiller> sil2100: thnks
[14:57] <bfiller> thanks
[14:57] <sergiusens> rsalveti: remember to --wipe or delete the last 3 lines of .bashrc
[14:57] <didrocks> ogra_: are you sure?
[14:57] <ogra_> didrocks, admittedly that was short after the bootcamp ... ages ago
[14:57] <didrocks> ogra_: no core-devs reported any issue
[14:58] <ogra_> i get an openid error
[14:58] <ogra_> and then end up with this in my url bar: https://job/landing-017-2-publish/build?delay=0sec
[14:59] <ogra_> (when i click the publish button)
[14:59] <sil2100> didrocks: packaging ACK needed! https://ci-train.ubuntu.com/job/landing-004-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity-webapps-qml_0.1+14.04.20140407-0ubuntu1.diff <- the 1.0 bump we mentioned in the morning
[14:59] <rsalveti> sergiusens: sure, flashing latest and will check
[14:59] <sil2100> This will basically fix the blocker \o/
[14:59] <didrocks> ogra_: you have the same bug that ev and webops are investigating
[15:00] <didrocks> ogra_: I guess getting your error would be interesting though
[15:00] <didrocks> Saviq: do you have your RT# handy about the empty url bar?
[15:00] <ogra_> aha, a second time it properly pushed me to the 2fa page
[15:00] <Saviq> didrocks, PM
[15:00] <didrocks> ogra_: yeah, seems to be a random issue since we moved to prodstack
[15:00] <ogra_> but the redirect afterwards is the same broken link
[15:01] <didrocks> ogra_: try to reclick from the spreadsheet
[15:01] <didrocks> now that you are logged in
[15:03] <didrocks> "Prep silo for file-based infographics"
[15:03] <didrocks> Saviq: if needed, can we flush that one? (the comment is still right?)
[15:04] <Saviq> didrocks, yes
[15:04] <ogra_> after the meeting ... i just changed machines :P
[15:04] <sil2100> didrocks: there's already one silo being cleared
[15:04] <davmor2> ogra_: log out, stand on one leg, now stand on your head, now drink a martini, now look at the glass, now look at the man, now look at the glass, now look at the man, the man is on a horse when this when this happens login and it works flawlessly everytime ;)
[15:04] <sil2100> didrocks: it's still cleaning the PPA though
[15:04] <didrocks> sil2100: maybe do saviq's one
[15:04] <didrocks> sil2100: so that we can get latest 2 requests in
[15:05] <Saviq> it *was* one of mine :P
[15:05] <slangasek> ogra_, cjwatson: ok, if we really need to pull in environment variables from .bashrc (ugh), then you can s/sh/bash/... but in that case we should also make the 'bash -c' be 'bash -cl' and skip having sudo run a login shell first
[15:05] <ogra_> davmor2, i'll cut everything from that except the martini
[15:05] <didrocks> Saviq: thanks man, and sorry :p
[15:05] <slangasek> so we only run one bash instead of two
[15:05] <davmor2> ogra_: haha
[15:05] <Saviq> didrocks, ;)
[15:05] <sil2100> didrocks: if you have a moment, take a look at the ACK ;)
[15:05] <Saviq> didrocks, we knew what we signed up for
[15:05] <ogra_> slangasek, .profile is sourced fine in both shells
[15:05] <sil2100> didrocks: in the meantime, I'll rip another silo from Saviq's hands, nyahahah
[15:06] <slangasek> ogra_: are you moving the content to .profile, then?  That works too
[15:06] <didrocks> sil2100: \o/
[15:06] <ogra_> slangasek, long term i plan to push all that costly code into a profile.d script ... i just dont have the time atm
[15:06] <ogra_> slangasek, yeah, thats what sergiusens change does
[15:06] <ogra_> as a quick fix
[15:06] <didrocks> sil2100: liboxideqt-qmlplugin is in universe, right?
[15:06]  * didrocks checks oxide-qt
[15:07] <didrocks> it's in universe as well
[15:07] <didrocks> sil2100: do we have the MIR?
[15:08] <sil2100> Ah, crap, I was so thinking 'yeah, oxide is used by default' that I didn't check where oxide is located, crap
[15:08] <davmor2> cyphermox: okay so I rebooted and now I have wifi
[15:08] <sil2100> Let me find that
[15:08] <didrocks> sil2100: don't believe, check man :/
[15:08] <sil2100> https://bugs.launchpad.net/ubuntu/+source/oxide-qt/+bug/1293681
[15:08] <didrocks> sil2100: it's not oxide but oxide-qt
[15:08] <didrocks> ok, so we can
[15:09] <didrocks> sil2100: please publish, but we'll need someone moving the bins to main
[15:09] <sil2100> I know that there was a MIR, since I already checked last time, but still... I completely forgot about this
[15:09] <sil2100> didrocks: ok, thanks!
[15:10] <didrocks> cjwatson: I'm pre-promoting oxide-qt now ^
[15:10] <didrocks> (even if the dep pulling it is just publishing in proposed now)
[15:10] <didrocks> so that we don't forget about it
[15:14] <didrocks> hum, that's wierd
[15:14] <didrocks> liboxideqt-qmlplugin 1.0.0~bzr475-0ubuntu1 in trusty amd64: main/libs/extra/100% -> main
[15:14] <didrocks> liboxideqt-qmlplugin 1.0.0~bzr475-0ubuntu1 in trusty amd64: universe/libs/extra/100% -> main
[15:14] <didrocks> and same for all archs/bins
[15:14] <didrocks> rmadison still reports universe though
[15:14] <didrocks> cjwatson: any idea, is that a temp thing, like something running the command at the same time? ^
[15:14] <rsalveti> sergiusens: tested, seems fine with .profile
[15:15] <rsalveti> sergiusens: ping me once you want it to land
[15:15] <didrocks> sil2100: so +1
[15:16] <didrocks> sil2100: and please assign last 2 requests then :)
[15:16] <sil2100> didrocks: ACK ;)
[15:21] <sil2100> didrocks: webbrowser is still not migrated properly from another silo, so I won't be able to assign for line 50
[15:21] <sil2100> dbarth: ^
[15:21] <sil2100> didrocks: and I don't want to ignoreconflicts again ;)
[15:21] <didrocks> sil2100: agreed
[15:25] <didrocks> sergiusens: can you try in the future putting better description for the landing please?
[15:25] <sergiusens> didrocks: for which one?
[15:25] <didrocks> sil2100: Mirv: robru: cyphermox: please don't assign silos with bad description :)
[15:25] <didrocks> sergiusens: line 49 "ubuntu-touch-session"
[15:25] <didrocks> sergiusens: line 30 "usensord"
[15:26] <sil2100> didrocks: ACKish
[15:26] <sil2100> ;)
[15:26] <sergiusens> didrocks: ah; I added descriptions to usensord once upon a time and was asked to add project names instead
[15:26] <cyphermox> moo?
[15:26] <didrocks> sergiusens: hum, who asked you that?
[15:26] <sergiusens> didrocks: do you want all the commit messages? robru
[15:26] <didrocks> sergiusens: better to get descriptions, we can infer the components from MP and sources
[15:27] <didrocks> robru: please stop giving your own rules :/
[15:27] <sergiusens> didrocks: well the description can be inferred as well
[15:27] <didrocks> and confuse people
[15:27] <didrocks> sergiusens: well, we don't want to open each MP to see what changed
[15:27] <sergiusens> but I'm fine
[15:27] <didrocks> sergiusens: basically what's the user/devel-impact of the change
[15:27] <didrocks> so not all commits
[15:27] <sergiusens> didrocks: peopl tend to add a bunch of MRs after anyways and the description go stale
[15:28] <sergiusens> that's fine
[15:28] <sergiusens> impact
[15:28] <didrocks> sergiusens: yeah, we need to get better at that and get good description
[15:28] <didrocks> sergiusens: I envision it in generating the reports from an image change from it
[15:28] <sergiusens> didrocks: oh, but we put so much effort into the commit messages already :-)
[15:29] <didrocks> sergiusens: not sure all commit messages are relevant to the public
[15:32] <sil2100> Uh, meeting!
[15:32] <didrocks> popey: coming? (if you can)
[15:37] <didrocks> jdstrand: FYI (we are discussing that in the meeting right now), but bug #1301341 is set at a blocker
[15:48] <ogra_> didrocks, you suggested i should try again now that i'm logged in
[15:48] <ogra_> when i do that, i end up in an indicator-appnemu landing
[15:49] <ogra_> instead of the ubuntu-touch-session one
[15:49] <didrocks> hum
[15:49] <didrocks> so
[15:50] <didrocks> tell me what link you are clicking on exactly
[15:50] <ogra_> i have the landing-17 sheet open in front of me
[15:50] <cjwatson> didrocks: err, not sure, but it does seem to have been temporary in practice so probably don't need to worry
[15:50] <ogra_> i click the publish button
[15:50] <ogra_> that expands a url
[15:50] <ogra_> https://ci-train.ubuntu.com//job/landing-017-2-publish/build?delay=0sec
[15:50] <didrocks> that sounds about right
[15:50] <ogra_> i click on it and land in some build thats owned by seb128
[15:51] <didrocks> grrr, I had the same wrong redirect
[15:51] <ogra_> at least thats what the build history tells me on the left
[15:51] <didrocks> ev: that should really be worked on by the webops team ^
[15:51] <ogra_> its the magnetic seb128 :)
[15:51] <didrocks> ogra_: how owned by seb128?
[15:51] <ogra_> he intercepts all redirects ;)
[15:51] <seb128> ogra_, it's an hint, you need to do work for me!
[15:51] <didrocks> ogra_: oh, don't care about the build history :p
[15:51] <jdstrand> didrocks: hey, was in a meeting. that meeting coincidentally was the oxide weekly meeting where we talked about that bug
[15:52] <didrocks> jdstrand: excellent! So, that's on track?
[15:52] <didrocks> ogra_: build history is just "who last did click on that one and what was published into that silo"
[15:52] <jdstrand> didrocks: dbarth and chrisccoulson can give more details, but it is the highest priority and we know how to make it work. Chris is trying to figure out the best way to make it happen
[15:52] <ogra_> didrocks, oh, ok
[15:52] <didrocks> ogra_: so yeah, just click on build, don't fear :)
[15:52] <ogra_> didrocks, so it is seb128 trying to confuse us by clicking on things
[15:52] <ogra_> ok
[15:52] <jdstrand> it has to do with proprietary codes in the build
[15:53] <didrocks> jdstrand: great, I'll just put your name as EM owner as we usually do
[15:53] <didrocks> jdstrand: just to know you are the one tracking it
[15:53] <didrocks> ogra_: yeah, he's a cliker :p
[15:53] <ogra_> heh
[15:53] <ogra_> ah, that looks better
[15:53] <jdstrand> didrocks: well, I am problem not the point of contact for that (I just happen to know), but ok
[15:54] <didrocks> ogra_: so, success! :)
[15:54] <ogra_> yeah, seems it built something
[15:54] <didrocks> jdstrand: seems that management wants a manager assigned, as it seems Chris has to do some work, you are volounteered :p
[15:54] <dbarth> didrocks: in a nutshell oxide needs to build twice, the 2nd time for the codecs that are missing to support grooveshark
[15:54] <didrocks> dbarth: yeah, that's what I got talking to chris
[15:56] <dbarth> ok
[15:57] <sil2100> Ah, k
[15:58] <robru> didrocks, sil2100: just saw the calendar. why did the meeting happen 30 minutes early?
[15:58] <ogra_> robru, for people wanting to listen to silbs
[15:58] <didrocks> robru: it's written in the description :)
[15:58] <ogra_> read your mails :P
[16:00] <robru> ogra_, I just woke up, I usually start my day with this meeting even before reading mails. so now I find the meeting has vanished...
[16:01] <ogra_> so you can listen to your boss, isnt that great ?
[16:01] <ogra_> :P
[16:05] <ev> didrocks: filing an RT for this now
[16:06] <didrocks> ev: we do have one FYI
[16:06] <ev> oh right :)
[16:07] <sergiusens> cyphermox: can you reconfigure silo 19 for me please?
[16:07] <sergiusens> robru: ^^
[16:07] <cyphermox> sure, just a second
[16:08] <sergiusens> thanks
[16:09] <cyphermox> sergiusens: did you add a MP or something?
[16:09] <sergiusens> cyphermox: yeah, that's why I asked you; the u-d-m one that mandel wanted
[16:09] <cyphermox> wasn't it already covered?
[16:09] <sergiusens> cyphermox: that fixes the unnamed download; it wasn't; u-d-m wasn't in the original req
[16:10] <cyphermox> zug zug
[16:10] <cyphermox> in progress
[16:11] <cyphermox> done
[16:12] <sergiusens> ty
[16:15] <rsalveti> popey: if OOM related, you should see messages like:
[16:15] <rsalveti> Apr  7 16:10:57 ubuntu-phablet kernel: [ 1414.550000] select 837 (polkitd), adj 0, size 552, to kill
[16:15] <rsalveti> Apr  7 16:10:57 ubuntu-phablet kernel: [ 1414.550000] send sigkill to 837 (polkitd), adj 0, size 552
[16:18] <popey> thanks rsalveti
[16:27] <cyphermox> sergiusens: you're the phonedations citrain expert; could you file in the spreadsheet to do a landing for https://code.launchpad.net/~mathieu-tl/mtp/0.0.3-logging-inotify/+merge/213681 ?
[16:29] <sergiusens> lol; ok
[16:29] <cyphermox> didrocks: what do I need to do to get mtp past the security check to board the train? :)
[16:29] <cyphermox> aside from coming up with a test plan
[16:29] <didrocks> cyphermox: nothing special, have a wiki testing plan and that's it :)
[16:30] <cyphermox> cool
[16:30] <didrocks> cyphermox: if it's a branch, it should just build with bzr bd
[16:30] <cyphermox> yeah, it does afaik
[16:30] <cyphermox> and it will be able to merge back into lp:mtp?
[16:31] <didrocks> cyphermox: oh, right, just ensure ps-jenkins has acess to it
[16:31] <didrocks> access*
[16:31] <cyphermox> well, I think it does, it was already in cu2d before
[16:31] <sergiusens> rsalveti: want to review https://code.launchpad.net/~mathieu-tl/mtp/0.0.3-logging-inotify/+merge/213681 ?
[16:31] <didrocks> cyphermox: so you are all good, if it was in cu2d, maybe change for "in citrain: yes"
[16:33] <didrocks> (in the bootcamp spreadsheet)
[16:34] <cyphermox> well, it doesn't have the test plan yet :)
[16:42] <ev> rsalveti: I vaguely recall you saying you have some experience with firmware debug cables in android. Is this right? We're looking at using the uart on the stereo port on mako as a way of being able to reboot a wedged device. Do you know if this is remotely possible?
[16:43] <ev> rsalveti: https://blog.accuvant.com/jduckandryan/building-a-nexus-4-uart-debug-cable/ for reference
[16:45] <rsalveti> ev: yeah, I built one myself a while ago (should be working fine still)
[16:45] <sil2100> Ok, need to drive home
[16:45] <sil2100> brb
[16:46] <ev> rsalveti: I will pay good money for this cable
[16:46] <rsalveti> ev: if you get a console via serial, you should at least be able to reboot the phone
[16:46] <sil2100> I mean, bbl
[16:46] <ev> rsalveti: that's the missing part for me - how?
[16:46] <rsalveti> ev: it's easy to build one
[16:46] <ev> ^ plars, cprov
[16:46] <rsalveti> we'd just need a getty on that serial port specifically
[16:46] <rsalveti> let me give that a shot
[16:47] <plars> ev: cool, I may build one then
[16:47] <ev> rsalveti: and then what, "reboot" in minicom
[16:47] <ev> ?
[16:47] <ev> rsalveti: cheers
[16:47] <rsalveti> ev: basically, yes
[16:47] <plars> ev: I assumed if the device was locked up, not much we could do over serial though
[16:47] <plars> worth a try
[16:47] <plars> ev: the ftdi breakout seems like the most expensive part
[16:49] <rsalveti> yeah
[16:50] <ogra_> didrocks, oh, another landing meeting ?
[16:50] <didrocks> ogra_: hum?
[16:50]  * didrocks didn't get any email
[16:50] <ogra_> i just got a gcal notification
[16:50] <didrocks> ogra_: isn't an old crufty deleted one?
[16:51] <ogra_> dunno, evo popped up a window in my face
[16:51] <ogra_> it is usually in sync with gcal
[16:51] <didrocks> ogra_: I didn't see anything in the UE calendar
[16:53] <ogra_> ok, might be my evo misbehaving
[16:55] <rsalveti> ev: plars: http://paste.ubuntu.com/7217860/ is enough to get a shell
[16:55] <ev> hero
[16:55] <ev> thanks
[16:55] <plars> rsalveti: awesome
[16:56] <cyphermox> didrocks: robru: back in a few minutes; need to go elect the next chief clown of the province.
[16:56] <robru> cyphermox, that's MISTER chief clown to you, bozo!
[16:56] <cyphermox> ahah
[16:57] <didrocks> cyphermox: you mention clown but don't live in Toronto, that doesn't map :p
[16:58] <cyphermox> didrocks: come now, you don't follow Quebec politics? it's in french too
[16:58] <didrocks> cyphermox: I have enough to follow/cry about France's one :p
[16:58] <cyphermox> ahah
[16:58] <cyphermox> we'll drink to that next time
[16:58] <cyphermox> bbl
[16:58] <didrocks> cyphermox: enjoy!
[16:59] <cyphermox> hey, at least it means the first "real" motorcycle drive of the year
[16:59] <rsalveti> sergiusens: quite big to review, add it to the 'to review' list :-)
[16:59] <sergiusens> cyphermox: ^^
[17:05] <cprov> plars, ev: the cable trick is simply to set the MIC line high (3V) and cope 3v3 to 1v8 lines to a usb/serial converter. How many cables will we need ?
[17:43] <cyphermox> rsalveti: sergiusens: the to-review list?
[17:43] <cyphermox> ideally it would be best to get this out of the way quickly, it's small
[18:29]  * robru -> lunch
[19:10] <dbarth> robru: o/ could i get a silo for line 50? (desktop fixes)
[19:10] <davmor2> popey, ToyKeeper, balloons: I've updated the testing spreadsheet where applicable from Yellow to red where there are blockers.
[19:12] <cwayne> robru, any chance I could get ubuntu-touch-customization-hooks landed? it was changed like 6 months ago and never made it into the image somehow...
[19:13] <robru> cwayne, so what, nobody ever requested a silo for it?
[19:13] <robru> dbarth, mmmm, line 50 conflicts with silo 3 AND 4 :-/
[19:14] <cwayne> robru, i think it was last changed months before silos existed, so im not sure how it never made it in before that
[19:14] <cwayne> but yeah, for sure nobody requested a silo for it :)
[19:14] <robru> huh
[19:15] <robru> cwayne, indeed last release was september
[19:15] <dbarth> robru: uh
[19:15] <cwayne> yeah, the guy that was working on it left around then, could be why
[19:15] <dbarth> robru: right, but 4 is tested and migrating, and 3 is a parallel change
[19:16] <robru> dbarth, yes but if I assign a silo for that, it means it just needs to be rebuilt once the other two finally do land
[19:17] <popey> davmor2: k
[19:17] <robru> cwayne, ok, so that latest commit on trunk (the unreleased one) it looks quite simple. is it tested / can you assure me that it won't break anything? ;-)
[19:18] <cwayne> robru, i've pbuilt it and installed it on my mako to be sure :)
[19:18] <robru> cwayne, great!
[19:18] <robru> cwayne, ok, I'll rush that one through
[19:18] <dbarth> robru: that's fine, we're ok to make a rebuild
[19:18] <robru> dbarth, ok
[19:18] <cwayne> robru, thank you, i really appreciate it :)
[19:19] <robru> cwayne, in future, make sure to add requests to the spreadsheet and they'll be released in a more timely fashion ;-)
[19:19] <robru> cwayne, I mean "you're welcome" ;-)
[19:19] <robru> dbarth, ok you got silo 8
[19:19] <cwayne> robru, oh geeze, which spreadsheet? is it still the landing pipeline one?
[19:19]  * cwayne hasn't gotten something landed in quite some time, didn't mean to break protocol :)
[19:20] <robru> cwayne, sorry, no, citrain has a special spreadsheet here: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=sharing&pli=1#gid=0
[19:20] <robru> cwayne, whoever is your manager should know more about it for future landings.
[19:20] <dbarth> robru: thx
[19:20] <robru> dbarth, you're welcome
[19:26] <fginther> popey, regarding the reminders-app bug https://bugs.launchpad.net/reminders-app/+bug/1302287
[19:26] <fginther> popey, was there also a bug with building the click package itself?  I see that it took a few builds before https://jenkins.qa.ubuntu.com/job/reminders-app-click/6/ was successful
[19:28] <popey> fginther: i tried to build it to test and it barfed due to some problem on the builder, which elopio cleared up
[19:31] <fginther> popey, ok. now were you able to install com.ubuntu.reminders_0.4.98_armhf.click and get it to work?
[19:32] <fginther> popey, I installed it and get a nice white screen
[19:37] <popey> no
[19:37] <popey> installed and it fails to start
[19:37] <popey> hence the bug report ☻
[19:46] <fginther> popey, thanks.
[19:50] <bfiller> robru: silo-1 ready to land
[19:51] <robru> bfiller, thanks
[20:07] <popey> heh
[20:09] <ToyKeeper> I wonder if that could explain the issue with the screen getting stuck on after a call.
[20:12] <popey> rsalveti: is it worth having a cron job to dump out ps aux -www  periodically?
[20:12] <popey> as a hack..
[20:13] <rsalveti> not sure if by default, but guess we could have a test for that
[20:13] <rsalveti> but I believe that would be the easiest way for you to find who is the culprit in here
[20:35] <robru> cwayne, ok, I got touch-customization-hooks released, but I can't merge the release commit back because jenkins isn't in the right team. do you have the ability to add ~ps-jenkins to !savilerow-team?
[20:45] <cwayne> robru, let me see
[20:49] <cwayne> robru, it said it's already a member, just assuming AK got to it before me :)
[20:58] <robru> cwayne, looks good now, thanks
[21:12] <cwayne> fginther, ping -- got that shenanigans savilerow failure to delete symlinks business again
[21:12] <fginther> cwayne, looking
[21:22] <fginther> cwayne, try it now
[21:43] <veebers> Hi guys, I'm seeing a proxy error for jenkins.qa.ubuntu.com is this a known issue? (https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty-autopilot/97)
[21:44] <fginther> veebers, no, that's not a known issue
[21:45] <fginther> veebers, hmm, try again now
[21:46] <veebers> fginther: awesome, works for me know :-)
[22:17] <cwayne> fginther, seems to build now, thanks!
[22:18] <fginther> cwayne, glad to hear it, I've added some cleanup code, hopefully the next one will just work
[22:49] <robru> boiko, got you silo 1
[22:58] <boiko> robru: thanks
[22:58] <robru> boiko, you're welcome