[00:15] <plars> rsalveti: mediaplayer still crashing: http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4525/mediaplayer-app-autopilot/
[00:16] <rsalveti> plars: that's because we didn't yet merge https://code.launchpad.net/~robru/mediaplayer-app/fix-1231418/+merge/188502, to disable it
[00:16] <rsalveti> plars: scene selector is not supported at the current version, but the test is still there
[00:16] <sergiusens> fginther, hey, the message at the end of https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-maguro/1850/testReport/junit/mediaplayer_app.tests.test_player_with_video/TestPlayerWithVideo/test_scene_selector_visibility_with_touch_/ feels very strange
[00:17] <sergiusens> fginther, according to thomi 1.2 was last used on precise
[00:17] <thomi> fginther: it's *aaaaaages* old :)
[00:18] <sergiusens> a rerun proved it to be a casual thing, but still brings in some worries
[00:18] <plars> ah, ok
[00:19] <rsalveti> sergiusens: https://code.launchpad.net/~sergiusens/phablet-extras/qtmultimedia-touch-quick/+merge/188962 please only add quick for the mir case
[00:19] <rsalveti> sergiusens: there's another block bellow, mir: {
[00:20] <rsalveti> with a QT += opengl
[00:20] <rsalveti> add it there
[00:21] <sergiusens> rsalveti, rar, ack
[00:21] <sergiusens> rsalveti, switching channels are we?
[00:21] <rsalveti> sergiusens: just used the wrong one
[00:22] <rsalveti> as you were talking here
[00:22] <rsalveti> too tired as well haha
[00:22] <sergiusens> rsalveti, I'm everywhere :-P
[00:27] <sergiusens> rsalveti, being pushed
[00:27] <sergiusens> rsalveti, pushed
[00:31] <rsalveti> sergiusens: thanks
[00:31] <sergiusens> rsalveti, what's the equiv of bzr push --overwrite btw?
[00:31] <rsalveti> sergiusens: with git?
[00:31] <sergiusens> rsalveti, yeah
[00:31] <rsalveti> sergiusens: git push -f
[00:32] <sergiusens> rsalveti, ty sir
[00:58] <rsalveti> sergiusens: added your lxc-android-config change to https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=0
[00:59] <rsalveti> sergiusens: now to hope people can agree that this can land tomorrow
[01:01] <sergiusens> rsalveti, well it avoids races ;-) just add that ;-)
[01:04] <doanac> veebers: yeah. its a ro image where we enable developer-mode.
[01:04] <doanac> and then install the unity8-autopilot package
[01:04] <veebers> doanac: understood, cheers
[01:23] <fginther> thomi, ping
[01:23] <thomi> fginther: hey
[01:24] <fginther> thomi, regarding the 1.2 protocol issue sergiusens brought up. which side is using 1.2?
[01:24] <thomi> fginther: the backend driver - I guess libautopilot-qt
[01:25] <thomi> in fact, '1.2' means 'unversioned', since we only started versioning it in 1.3. AP assume that anything unversioned is '1.2'
[01:25] <fginther> thomi, thanks, I'll see if I can find any evidence along those lines
[02:04] <rsalveti> starting new build, which should include the regression fix for ringtone/sms notification sound
[04:02] <thomi> fginther: still awake?
[04:03] <thomi> is anyone here able to spin us a custom phablet image with new mir, unity-mir and platform-api?
[05:04] <rsalveti> ogra_: lool: 78 is looking good, it's expected to have at least one failed test with mediaplayer-app, as scene selector is not supported anymore
[05:05] <rsalveti> we have a pending MR to fix that: https://code.launchpad.net/~robru/mediaplayer-app/fix-1231418/+merge/188502
[05:41] <didrocks> Mirv: hey, how are you?
[05:41] <Mirv> didrocks: morning, fine, bit more normal day today
[05:41] <didrocks> heh ;)
[05:41] <Mirv> didrocks: ui toolkit is no good at the moment, I'm now testing the qtdeclarative separately
[05:42] <didrocks> Mirv: ah ok ;) good that you detected this!
[05:42] <didrocks> Mirv: can you please try to release all the rest that we can?
[05:42] <didrocks> (if sil2100 gave some instructions)
[05:42] <didrocks> I think we're going to publish the current image
[05:43] <Mirv> I haven't received anything from sil2100
[05:43] <didrocks> and he didn't write anything on the spreadsheet?
[05:43]  * didrocks checks
[05:44] <Mirv> to the libusermetrics that there's some AP tests problems he's having, on the unity-scope-home there isn't anything I think
[05:44] <didrocks> Mirv: can you look at libusermetrics? The tests will take 5 minutes I guess
[05:45] <Mirv> didrocks: yeah, I can stop this declarative testing for a bit and test it instead
[05:45] <didrocks> Mirv: thanks, just do in whatever order you want
[05:58] <jibel> on the dashboard, http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/ what does the build number mean?
[05:58] <jibel> for example 78:20131003:20131002.1
[05:58] <jibel> there are 2 build ids in the string
[05:58] <jibel> ..03 and ...02.1
[06:18] <didrocks> Mirv: once you are done with the current ones, let's discuss about the Mir thingy (give me a head's up)
[06:18] <didrocks> jibel: oh interesting, it was always the same ones repeated before
[06:19] <didrocks> jibel: TBH, I don't know :/
[06:21] <jibel> didrocks, sorry :) also sometimes people speak with image number (77,...) and sometimes in build number 20131003,... is there a way to know which correspond to what
[06:21] <didrocks> jibel: oh, for that one, sure
[06:21] <didrocks> jibel: so basically 20131003 is the ubuntu part
[06:21] <jibel> for example in media-info I can find the build id but don't know to which image number it corresponds
[06:22] <didrocks> (containing only the android bits)
[06:22] <didrocks> when you merge it to the android part (which can change even if you didn't rebuild any ubuntu part), you get the real "id" for the image
[06:23] <didrocks> which are those numbers, 76, 77…
[06:23] <didrocks> to find them, they are in front in the dashboard
[06:23] <didrocks> this is how you can spot them :)
[06:23] <didrocks> 78:20131003:20131002.1 -> image 79
[06:23] <didrocks> oupss
[06:23] <didrocks> 78:20131003:20131002.1 -> image 78
[06:24] <jibel> didrocks, so in summary, when plars sent a message with tests results for image 77, I must go to the dashboard to know that 77 is 02.1, correct?
[06:25] <didrocks> jibel: right, we should promote this number as well, it's the real uid for the image
[06:25] <jibel> thanks
[06:26] <didrocks> jibel: just be warned, you can have 2 images with 02.1
[06:26] <didrocks> like 77 and 78 can be 02.1
[06:26] <didrocks> if we just rebuild the android part
[06:26] <jibel> understood.
[06:29] <didrocks> jibel: so, we are going to have Mir fixes today
[06:29] <didrocks> we'll probably need the same round of testing than yesterday
[06:30] <jibel> didrocks, good, I'm continuing manual testing of MIR anyway
[06:30] <jibel> and found other issues, like pip not working for pinned app, and details like this
[06:31] <didrocks> jibel: well, if only we had some "details" to fix like that, I would be happy
[06:31]  * didrocks just locked his phone again
[06:32] <jibel> high CPU usage under MIR is a killer. unity8 never goes below 100%
[06:35] <didrocks> jibel: I put it as a showstopper yesterday but management disagreed
[06:44] <didrocks> Mirv: FYI, I just prepare (merging, updating config and kick a rebuild) to be ready for the new Mir stack
[06:46] <Mirv> didrocks: ok, thanks. still takes a bit of time before I'm ready for that.
[06:46] <didrocks> Mirv: yw! at least, it should be built by then, so less wait :)
[06:46] <didrocks> Mirv: as upstream don't merge the build-dep bump, everytime I'm doing that myself FYI
[06:47] <didrocks> (the upstream merger can't merge because the new Mir version isn't there)
[07:03] <sil2100> Morning!
[07:04] <sil2100> didrocks: why hud got marked as FAILED? I still see the sync request on the unapproved queue...
[07:04] <Mirv> didrocks: ok, could you sponsor lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src_5.0.2 ? all tests pass, and I also received separate testing from Chris Wayne / Matthew Fischer that they are very happy with its fix
[07:05] <didrocks> hey sil2100!
[07:06] <didrocks> sil2100: hum, but you told that some AP tests were failing, right?
[07:06] <didrocks> Mirv: \o/
[07:06] <sil2100> didrocks: yes, but it wasn't because of HUD - as I had the same problems and couldn't really get any solid results when using vanilla 75 ;)
[07:07] <sil2100> didrocks: all was ok on image 70 with the new hud
[07:07] <didrocks> sil2100: ah ok, please change the status then
[07:07] <sil2100> didrocks: I'll try to bisect as ogra_ advised what's wrong that 75 suddenly 'burps'
[07:08] <didrocks> Mirv: did you start on the home scope?
[07:08] <Mirv> didrocks: not yet
[07:08] <Mirv> didrocks: libusermetrics now in archive
[07:08] <didrocks> sil2100: look at the latest results, all is green, so you should just reflash with that one
[07:08] <didrocks> Mirv: \o/
[07:08] <didrocks> ok, so now that sil2100 is here, let's sum up
[07:08] <sil2100> Mirv, didrocks: wasn't robru supposed to do that?
[07:08] <Mirv> sil2100: it's marked to you only in the chart at least
[07:09] <sil2100> didrocks: reflashing then \o/
[07:09] <didrocks> sil2100: he was… apparently, he couldn't get his laptop working and so, he didn't process anything
[07:09] <robru> sil2100, i cannot access launchpad all day, so I can't install anything from PPAs, so I can't test anything before publishing. I emailed you about this.
[07:09] <sil2100> Mirv: hum, yesterday it was marked for robru, as I gave it to him since he didn't have any tasks
[07:09] <didrocks> Mirv: yeah, but I ask robru to coordinate with sil2100 on his end of day
[07:09] <didrocks> robru: is it better now btw?
[07:09] <Mirv> I could run the scope-home unity7 tests, although I need to switch to a different machine then for working (which is still ok, I've a spare one)
[07:09] <sil2100> robru: ah! Ok, didn't open my mail yet ;) ACK
[07:10] <Mirv> I've at least a known-good unity7 test machine here
[07:10] <didrocks> or you can't still access to LP?
[07:10] <didrocks> Mirv: great ;)
[07:10] <didrocks> so what I propose
[07:10] <didrocks> Mirv -> home scope
[07:10] <sil2100> Reflashing the device
[07:10] <didrocks> sil2100: apparently AP has some fixes, so worth another try
[07:10] <robru> didrocks, hum, no, still bad. I opened an RT for it, and I'll ping #is in the morning.
[07:10] <sil2100> didrocks: you mean the new AP?
[07:10] <didrocks> robru: ok, good luck
[07:11] <didrocks> sil2100: yeah, new AP /!\ look at your emails, I forwarded to you. There are 2 projects that needs some additional merging
[07:11] <didrocks> sil2100: ignore the toolkit one anyway (maybe it should just be merged), as Mirv tested, it's not a good shape
[07:11] <didrocks> Mirv: I think you pinged pustream btw about the sdk?
[07:11] <didrocks> and then, Mirv -> Mir once built
[07:12] <Mirv> didrocks: ok, home scope. sdk upstream knows about the issues, yes.
[07:12] <didrocks> Mirv: have you opened a bug? (some upstream wants paperwork to tack)
[07:13] <didrocks> track*
[07:13] <Mirv> didrocks: well hmm, it's more like 'it's all broken' (some mainview issue as indicated by zsombor), but yeah I'll file a bug as well
[07:13] <didrocks> Mirv: all? waow ;)
[07:14] <didrocks> ah, I guess sil2100 edited the wrong line
[07:14] <didrocks> the sdk "FAIL" one instead of the hud
[07:14]  * didrocks fixes
[07:14] <Mirv> didrocks: well the toolkit's own tests pass, but apps AP:s break quite badly
[07:15] <didrocks> interesting
[07:15] <didrocks> Mirv: anyway, thanks for spotting/testing carefully ;)
[07:19] <Mirv> sil2100: FYI for your AP problems, please make sure you wait after boot until the nautilus windows pops up for Nexus. at that point the connection breaks so if you started phablet-test-run before, it won't work. also note the home screen unlocking needed mentioned by ogra.
[07:19] <sil2100> :|
[07:19] <sil2100> Missed the rows it seems...
[07:20] <robru> didrocks, sil2100, Mirv: is powersaving still broken in desktop xorg? I remember that being broken ages ago but I just now noticed that my screen has been on all evening after many hours of inactivity...
[07:20] <sil2100> Mirv: I'm running it clean through SSH, so I'm always unlocked - and the tests were running, but suddenly after a while either unity8 or autopilot itself hangs up on dont-know-what and waits indefinitely
[07:20] <sil2100> Unable to being properly killed
[07:21] <didrocks> robru: hum, working here, would worth trying to kill g-s-d and get it restarted
[07:22] <Mirv> sil2100: you shouldn't run it through SSH but use phabllet-test-run
[07:22] <didrocks> yeah
[07:22] <didrocks> phablet-test-run is the way to go
[07:22] <didrocks> like phablet-test-run -p <app autopilot package name> -n <autopilot test>
[07:22] <didrocks> (/!\ -p should be before -n)
[07:23] <Mirv> I tend to run non-unity8 AP:s without -n, and unity8 with -n, seems to work
[07:23] <sil2100> Mirv: last time people told me not to use phablet-test-run for normal tests
[07:23] <didrocks> Mirv: yeah, I don't really know about the magic, I just know the infra always use -n from what I heard
[07:23] <sil2100> Damn, I think my Nexus got bricked?
[07:23] <didrocks> sil2100: reflash with --no-backup (will erase the whole config)
[07:24] <Mirv> sil2100: hmm, I've never heard that
[07:24] <sil2100> didrocks: I tried to use -n always, but most tests were failing then
[07:24] <didrocks> weird, not the case for me :/
[07:24] <Mirv> sil2100: phablet-flash ubuntu-system --channel devel-proposed -b
[07:24] <didrocks> Mirv: with --no-backup
[07:24] <sil2100> Mirv: will it work when it's stuck on the Google screen?
[07:24] <didrocks> ah, maybe that's -b
[07:24] <didrocks> sil2100: if you can adb shell, yeah
[07:25] <sil2100> Yeah, busybox
[07:25] <didrocks> ok, -b implies --no-backup
[07:25] <Mirv> didrocks: bootstrapping (-b) wipes out everything anyway, it's even more powerful than --no-backup
[07:25] <vila> sil2100: when stuck on the Google screen, the trick I use is to reboot in recovery mode. From there, phablet-flash find its way
[07:25] <didrocks> yep
[07:25] <sil2100> ERROR:phablet-flash:Unsupported device, autodetect fails device :o
[07:25] <sil2100> vila: will try that
[07:25] <jibel> why would you run app tests with -n, it stops unity8 and running apps without it is not the way users do
[07:26] <didrocks> sil2100: yeah, you need to specify -d mako then
[07:26] <jibel> sil2100, add -d <devicename>
[07:26] <didrocks> (IIRC, you have a mako)
[07:27] <vila> sil2100: and I don't even use -b nor --no-backup (it's hard enough to retype the contacts I forgot to transfer to the sim before cutting it into a nano sim that I haven't tried hacking to put it back in my other phone, sorry this parenthesized stuff is getting far longer than expected ;o)
[07:27] <didrocks> jibel: well, seems that upstream design AP tests without the shell running, and that's why you get more failures than the infra does
[07:27] <didrocks> vila: it's better to do run with --no-backup at least
[07:27] <didrocks> like you detect more issues
[07:27] <sil2100> vila: right now I only use it for testing purposes, so I only have the WiFi password on it - so I'll bootstrap it from 0 I guess
[07:27] <didrocks> like 4 images ago, all the crashes was due to having a fresh user
[07:28] <didrocks> so it's not the same testing without --no-backup
[07:28] <jibel> didrocks, you're not doing integration tests then
[07:28] <vila> didrocks: /me nods
[07:28] <didrocks> jibel: well, tell that to upstream :)
[07:28] <didrocks> jibel: I don't deny it at all, just telling what's the current situation
[07:28] <vila> didrocks: but it's a trade-off, I try to use it as my main phone
[07:28] <didrocks> I hope you can convince them ;)
[07:29] <didrocks> vila: yeah, but be aware that's not what we should do in that team as we need to ensure people flashing their device can at least having application starting :p
[07:29] <didrocks> which wasn't the case if you start fresh in that example
[07:29] <didrocks> jibel: do you know if anyone apart from lool can promote an image?
[07:30] <didrocks> (lool will be around later today)
[07:30] <vila> didrocks: understood, but I know some other people are testing this way, variety is important for testing too
[07:30] <jibel> didrocks, no idea
[07:30] <didrocks> vila: yeah, but we at least need some people testing it the "fresh way" as well
[07:30] <sil2100> didrocks: that's sad, since last time I heard they said they only used -n for the unity8 tests - didn't remember they did it for all of the tests ;) But I might have misunderstood?
[07:30] <didrocks> vila: I don't think we support migrations yet
[07:30] <didrocks> sil2100: well, that's what I heard, I didn't look at the utah code
[07:30] <didrocks> jibel: ok, we'll wait for him I guess
[07:31] <didrocks> sil2100: flashing working?
[07:31] <Mirv> didrocks: unity-scope-home seems to require newer libunity as well (libunity-protocol-private0)
[07:32] <Mirv> diff being http://bazaar.launchpad.net/~unity-team/libunity/trunk/revision/299
[07:32] <sil2100> didrocks: it seems to proceed this time, phew
[07:33] <Mirv> I don't see how the protocol-scope-discovery.vala change relates the the commit comment though
[07:33] <didrocks> Mirv: ok, feel free to test with it (but please do some unity7 testing a little bit more rigourusly then)
[07:34] <didrocks> hum, 7.1.1
[07:34] <didrocks> Mirv: don't we have 7.1.2 already?
[07:34] <didrocks> Mirv: let me look at the home scope code
[07:34] <Mirv> didrocks: yes, the actual package dependency is protocol-scope-discovery.vala
[07:34] <Mirv> I mean, >= 7.1.2+13.10.20131002.2
[07:35] <didrocks> Mirv: oh, you're right
[07:35] <didrocks> Mirv: ok, please try with both (and only those)
[07:35] <didrocks> just ensure we don't regress unity7 in particular :)
[07:36] <didrocks> sil2100: to prepare and test AP, should be stage one version in the ppa or you want to build trunk yourself?
[07:38] <sil2100> didrocks: I see some autopilot package in the daily-build PPA right now - it's not the trunk version that needs testing?
[07:40] <didrocks> sil2100: it's the trunk version we want to test (see the email I forwarded to you as well)
[07:40] <didrocks> + some additional fixes in some packages
[07:43]  * sil2100 wonders why the merges didn't get top-approved yet
[07:43] <didrocks> sil2100: I think that they are failing without the new AP
[07:43] <didrocks> so chicken and egg issue
[07:43] <didrocks> (or no backward compatibility)
[07:44] <sil2100> didrocks: I know, but even the autopilot branch didn't get top-approved, and CI only had success on it
[07:44] <didrocks> argh
[07:44] <didrocks> veebers: around, do you know why? ^
[07:45] <sil2100> veebers, thomi: ^? It's approved 2 times but not top-approved, I don't see a reason for that?
[07:45] <sil2100> https://code.launchpad.net/~veebers/autopilot/fixing_backend_being_none/+merge/188762
[07:46] <sil2100> didrocks: to test I would have to build this branch locally anyway
[07:47] <didrocks> sil2100: yeah, please do then, sorry for the additional work :/
[08:00] <xnox> rsalveti: lool: sorry for the noise, but yeah those changes are correct. (the target was not reliable & relies on internet access which fails on the buildds so I did back that out.)
[08:00] <xnox> git log, will clearly state that I did intentionally reverted.
[08:02] <sil2100> didrocks: will take a moment as my armhf building is not top-speed
[08:03] <didrocks> sil2100: hum, not sure you need to build on armhf
[08:03] <didrocks> sil2100: for autopilot at least
[08:03] <didrocks> they are all arch: all, no?
[08:03] <sil2100> No, autopilot-touch is any
[08:04] <didrocks> yeah, it's a mistake btw
[08:04] <didrocks> seems it's just a metapackage
[08:04] <sil2100> But it's finishing now ;)
[08:04] <didrocks> ah,but there is a dep
[08:04] <didrocks> anyway, ok ;)
[08:04] <didrocks> sil2100: so, I would say: try everything that doesn't need a patch
[08:04] <didrocks> if they pass, then, try the last 2 ones :)
[08:04] <didrocks> (I guess sdk and unity)
[08:17] <ogra_> didrocks, i'm partially around atm, in case you want to have 78 released (after manual call tests)
[08:18] <ogra_> (for the next hour or longer)
[08:18] <didrocks> ogra_: oh please please! :)
[08:18] <didrocks> ogra_: promote it!
[08:18] <didrocks> (I dogfooded it this morning)
[08:18] <ogra_> didrocks, did someone do call/sms tests ?
[08:19] <didrocks> I don't think about that one, popey around? ^
[08:19] <didrocks> ogra_: I don't have a sim card :/
[08:19] <ogra_> (incoming calls and sms, do they produce sound ?)
[08:19] <ogra_> right, so lets wait for popey to do one :)
[08:19] <popey> ya
[08:19] <didrocks> (yeah, they are supposed, the fix is in, so I guess it was tested)
[08:19] <didrocks> popey: hey!
[08:19] <popey> yo
[08:19] <ogra_> my maguro battery is dead :(
[08:19]  * seb128 click update (78), 100M to download, some people have been busy ;-)
[08:19] <didrocks> popey: so image 78, we just need the call/sms tests
[08:19] <popey> 09:18:38 < popey> Huzzah! Ringing and sms tones works in image 78
[08:19] <didrocks> \o/
[08:19] <popey> :D
[08:19] <seb128> ogra_, popey just said they do
[08:20] <popey> timing++
[08:20] <ogra_> ah, i didnt read the backlog
[08:20] <didrocks> ;)
[08:20] <didrocks> ogra_: well, it was at the same minute that we discussed it here
[08:20] <ogra_> should we just assume they do as well on maguro ?
[08:20] <didrocks> ogra_: I would assume TBH
[08:20]  * ogra_ thinks there was no HW specific issue
[08:20] <ogra_> right
[08:20] <ogra_> lwets release that thing :)
[08:20] <didrocks> yeah, it wasn't HW specific
[08:21] <didrocks> ogra_: \o/
[08:21]  * popey prepares a mail
[08:21] <didrocks> ogra_: then, now, enjoy your national holiday :)
[08:21] <popey> 78 is 20131003 right?
[08:21] <sil2100> \o/
[08:22] <popey> wow, was 70 really the last one we pushed?
[08:22] <popey> time flies
[08:22] <veebers> sil2100, didrocks: That's odd, I'm sure thomi said he had top approved this: https://code.launchpad.net/~veebers/autopilot/fixing_backend_being_none/+merge/188762
[08:23] <ogra_> done, give it a few minutes to promote and sync ...
[08:23] <sil2100> veebers: it seems he just double approved it instead! Let's top-approve it then ;)
[08:23] <veebers> sil2100, didrocks: Hmm, I think we got our lines crossed, he approved but not top approved :-\
[08:23] <ogra_> popey, right, 20131003/78
[08:23] <veebers> sil2100: sounds good to me :-)
[08:24] <veebers> it also looks like the merge here failed due to network/apt issues: https://code.launchpad.net/~veebers/unity/fixing_ap_tests_for_updated_autopilot/+merge/188969
[08:24] <sil2100> veebers: thanks for the branch btw.! I'm testing it right now, so far so good
[08:24] <veebers> sil2100: nw, awesome news
[08:24] <didrocks> popey: yeah, 2 days ago :)
[08:26] <popey> 81MB!
[08:26] <popey> Monster
[08:27] <didrocks> popey: quite easy (my fiber connection was just updated to 1Gb :p)
[08:29] <lool> didrocks: I'm here
[08:29] <lool> didrocks: you wanted to promote an image?
[08:29] <lool> I guess ogra_ did already
[08:30] <didrocks> lool: we just did it
[08:30] <didrocks> (like 9 minutes ago)
[08:30] <lool> cool
[08:30] <didrocks> sil2100: joining?
[08:31] <sil2100> Badum tsss
[08:31] <Laney> didn't get the /etc/writable fix?
[08:32] <seb128> hum, the ubuntu-download-manager is doing quite some syslog spamming
[08:35] <Laney> I guess maybe I need to flash with --no-backup
[08:41] <popey> http://popey.com/~alan/device-2013-10-03-094053.png
[08:41] <popey> "Apply update failed: No update has been downloaded"
[08:41]  * popey tries again
[08:42] <lool> ogra_: joining HO?
[08:42] <lool> vila: ?
[08:42] <popey> better that time
[08:43] <vila> lool: omw
[08:43] <lool> ogra_: oh sorry, forgot
[08:45] <Laney> no, it's still a file with --no-backup
[08:45] <popey> Mail sent.
[08:53] <sil2100> Damn, so far so good this new AP
[08:53] <sil2100> I re-ran notes-app and the test failures were gone, so I guess they were flacky
[08:58] <seb128> shrug, updates' "retry" seems not work
[08:58] <seb128> 3 times upgrade fails on network errors and that I need to reboot the device to try again
[08:59] <vila> seb128: while you're there, try changing your phone orientation and see the retry button covering... (can't remember the labels)
[09:00] <seb128> vila, bug #1229374
[09:00] <vila> seb128: thanks, subscribed
[09:00] <seb128> yw
[09:01] <seb128> I wonder why screen rotation stopped working on the n7
[09:01] <seb128> it used to work there
[09:01] <vila> seb128: can't remember seeing it working there
[09:02] <seb128> it was, when I enabled screen rotation in system settings, I first tested on my n7
[09:03] <vila> ha right, system settings is where I realized rotation was working, but that was on mako
[09:16] <sil2100> didrocks: all tests passed on my device - I even updated to the uitoolkit branch that veebers prepared, ran UI toolkit tests and it was green
[09:16] <sil2100> didrocks: but the AP branch didn't get yet merged in, now there was some connection/apt problem on amd64 during autolanding...
[09:16] <sil2100> didrocks: not sure what to do with the UI Toolkit one, since we don't want to release UI toolkit for now, right
[09:16] <sil2100> ?
[09:25] <lool> sil2100: awesome news on new AP  :-)
[09:26] <didrocks> sil2100: sorry, was discussing with lool
[09:26] <lool> sil2100: new UI toolkit >> right, I think we want the old UI toolkit to pass with the new autopilot
[09:26]  * didrocks backlog
[09:26]  * lool school and lunch 7
[09:26] <didrocks> sil2100: \o/
[09:26]  * lool school and lunch &
[09:26] <didrocks> sil2100: can we backport veeber's fix in the current ui toolkit package?
[09:27] <didrocks> maybe that would be a way :)
[09:27] <sil2100> didrocks: I'll check how bad is it with the old UI toolkit - if it's bad, I'll try backporting
[09:27] <sil2100> But I guess backporting might be needed ;)
[09:27] <didrocks> sil2100: yeah, so current package + this merge only
[09:27] <didrocks> let's cross fingers ;)
[09:32] <didrocks> Mirv: psivaa: jibel: Mir ready in the ppa
[09:32] <didrocks> so mir + unity-mir + platform-api (+ unity-system-compositor on desktop)
[09:33] <didrocks> I guess install iamge #79 and running those ^
[09:33] <psivaa> didrocks: ok, i was just getting http://pastebin.ubuntu.com/6187395/ but may be i am too early?
[09:33]  * didrocks tests on destkop meanwhile
[09:33] <didrocks> psivaa: they are at libmirserver5 now!
[09:33] <psivaa> didrocks: ack, will install that. thanks
[09:33] <didrocks> yw ;)
[09:33] <Laney> ABI addicts
[09:34] <sil2100> Wait, mirserver5 really?
[09:34] <didrocks> for real!
[09:35] <didrocks> sil2100: do you think we'll be able to publish autopilot before 12 UTC?
[09:35] <didrocks> sil2100: oh, we need to rebuild it in the ppa btw…
[09:36] <sil2100> didrocks: depends on if the merges will get in ;/ I can manually merge them in if needed, but since rebuilds will have to happen I somehow doubt targetting before-12
[09:36] <didrocks> sil2100: well, ok, let's try to rebuild autopilot meanwhile
[09:36] <didrocks> sil2100: is the unity patch in? we can rebuild it?
[09:37] <sil2100> didrocks: it's approved since 1 hour, but still not merged in - I guess CI is building it still
[09:38] <didrocks> sil2100: ok, let's rebuild autopilot for now
[09:38] <didrocks> sil2100: keep me posted on the sdk, I can't wait ;)
[09:38] <didrocks> nice that latest unity7 is fine as well under AP!
[09:38] <didrocks> sil2100: well, I think if we don't push unity7, it's not that a biggie anyway
[09:39] <didrocks> (as long as the patch is merged)
[09:40] <didrocks> sil2100: autopilot rebuilding
[09:43] <sil2100> \o/
[09:43] <sil2100> I cherry-picked the fix to ubuntu-ui-toolkit, I'll do a test-build too but anyway propose the change to the packaging branch
[09:49] <didrocks> excellent!
[09:52] <sil2100> didrocks: https://code.launchpad.net/~sil2100/ubuntu/saucy/ubuntu-ui-toolkit/manual_merge <- should I do a MR?
[09:52] <sil2100> And should I change it from UNRELEASED to saucy already?
[09:52] <sil2100> It's still building here
[09:52] <sil2100> Actually...
[09:52] <sil2100> Let me not waste time for building the armhf package
[09:52] <didrocks> sil2100: I think you don't need to merge that branch, do you?
[09:52] <didrocks> sil2100: you just need to merge the changelog back to the upstream branch
[09:53] <sil2100> I'll downgrade to old UI toolkit and just push that modified file directly and check if it works
[09:53] <didrocks> (once we upload manually)
[09:53] <didrocks> yeah ;)
[09:53] <didrocks> sil2100: hum, modified file?
[09:53] <didrocks> you mean, you push the diff?
[09:53] <Mirv> didrocks: ok!
[09:53] <didrocks> (as the file maybe contains more)
[09:54] <didrocks> Mirv: have you finished libunity + scope-home? (just looking at the unapproved queue)
[09:54] <sil2100> Yes, I actually meant the file, since I can use the manual_merge branch, and it's the UI toolkit in-archive-source with that diff applied ;) No worries, testing!
[09:56] <Mirv> didrocks: I needed to start a rerun of the Unity7 tests, some autopilot error happened. I'm testing it manually on another machine as well.
[09:57] <didrocks> ok
[10:00] <sil2100> didrocks: oh! I just now noticed the 'UTC' in 12 UTC
[10:01] <sil2100> didrocks: till 12 UTC I guess we'll make it ;)
[10:01] <didrocks> sil2100: ok ;)
[10:07] <ev> apw, infinity: the patch in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/882147 (inotify support in overlayfs) was determined to not cover some particularly important scenarios, right? Do either of you know if work is being done elsewhere to add this support?
[10:08] <Mirv> ok, now had a good run!
[10:09] <Mirv> publishing libunity + unity-scope-home.
[10:09] <apw> ev, i have some half baked patches which might cover 'most' of it, but they arn't ready to use, and i know of noone else doing anyting indeed.  plus it is definatly not clear you can close the gap entirely due to a semantic gap
[10:11] <ev> apw: could we say, "on overlayfs it works, but here are the drawbacks" with your patches? Without looking at them, some support is better than none
[10:11] <Mirv> didrocks: http://<IP_ADDRESS>:8080/view/cu2d/view/Saucy/view/Unity/job/cu2d-unity-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_libunity_7.1.2+13.10.20131003-0ubuntu1.diff
[10:11] <apw> ev, they are not in a state to apply to saucy and upload no
[10:11] <ev> and it would help us improve provisioning speed
[10:11] <Mirv> (packaging ack)
[10:11] <ev> apw: *nods*
[10:11] <didrocks> Mirv: yeah, sounds good (I approved it upstream in fact ;))
[10:12] <apw> ev, they last built against raring, and with all this touch work going on we haven't had the time to progress
[10:12] <Mirv> didrocks: ah, thanks
[10:12] <didrocks> Mirv: nice on libunity + scope-home \o/
[10:13] <ev> apw: so would it just be a matter of priority to get done in 14.04?
[10:14] <sil2100> didrocks: ran the tests 2 times, every time I got 1 failure, but each time a different one - so I guess it's a flacky test
[10:15] <sil2100> didrocks: so I think +1 for manually uploading that cherry-picked branch
[10:15] <didrocks> sil2100: ok, please do ping upstream about those, but don't block on that
[10:15] <didrocks> sil2100: yeah, let's do that \o/
[10:15] <sil2100> didrocks: should I modify that branch from UNRELEASED to saucy or will you do that when uploading :) ?
[10:15] <didrocks> sil2100: you do publish autopilot and give me a debdiff for the sdk + merge back the packaging branch upstream?
[10:15] <sil2100> didrocks: I'll then prepare a merge-back with the changelog
[10:15] <sil2100> didrocks: ACK
[10:15] <didrocks> sil2100: want to try to give me a debdiff?
[10:15] <didrocks> (so that it changes a little bit ;))
[10:15] <apw> ev, it would need to be a decision we could spend time on it yes
[10:18] <sil2100> didrocks: http://paste.ubuntu.com/6187531/ <- debdiff, taking care of autopilot
[10:18] <sil2100> didrocks: http://<IP_ADDRESS>:8080/view/cu2d/view/Saucy/view/QA/job/cu2d-qa-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_autopilot_1.3.1+13.10.20131003.1-0ubuntu1.diff ACKed? ;)
[10:19] <didrocks> sil2100: hum, do you know why this dpkg-dev, build-dep?
[10:20] <didrocks> "  Add missing dependency to python-autopilot-tests package.
[10:20] <didrocks> "
[10:20] <didrocks> doesn't really tell anything
[10:20] <didrocks> ah, they are running dpkg-query
[10:20] <didrocks> in their tests
[10:20] <didrocks> ok, then, +1
[10:22] <cjwatson> didrocks: Is it a versioned build-dependency?
[10:22] <didrocks> cjwatson: it's not a build-dep (was caught by the diff, but a dep on their -test package
[10:22] <cjwatson> Oh, runtime
[10:22] <cjwatson> But dpkg-query is in dpkg, not dpkg-dev
[10:22] <cjwatson> And dpkg is Essential
[10:23] <didrocks> oh indeed, I thought it was in dpkg-dev
[10:23] <didrocks> sil2100: ok, so let's fix that upstream, making a MP?
[10:23] <sil2100> didrocks: changing dpkg-dev to dpkg, yes? Or removing it completely?
[10:24] <didrocks> sil2100: removing as it's part of dpkg which is essential
[10:24] <didrocks> veebers: thomi: FYI ^
[10:24] <cjwatson> Where was the original commit for this change?
[10:24] <didrocks> 12:20:11 didrocks | "  Add missing dependency to python-autopilot-tests package.
[10:24] <didrocks> 12:20:11 didrocks | "
[10:24] <didrocks> cjwatson: ^
[10:24] <didrocks> not really helpful
[10:25] <cjwatson> x/usr/share/pyshared/autopilot/tests/functional/test_introspection_features.py:107:                    ["dpkg-architecture", "-qDEB_HOST_MULTIARCH"]).strip()
[10:25] <didrocks> dpkg-architecture
[10:25] <cjwatson> that would require dpkg-dev
[10:25] <didrocks> ok, that one
[10:25] <didrocks> so yeah
[10:25] <didrocks> sil2100: keep it for dpkg-architecture
[10:25]  * didrocks would like more helpful commit message (and ping to packagers first for packaging changes)
[10:27] <didrocks> sil2100: so, is there anything else on your list or you can help on the Mir force? ;)
[10:28] <didrocks> (nice work btw!)
[10:32] <sil2100> didrocks: I'll just push the branches, make sure stuff is merged and release thumbnailer quickly so that people can be happy
[10:34] <didrocks> sil2100: great!
[10:43] <didrocks> popey: it seems rick is seeing his sms messages getting deleted, do you see that with latest images?
[10:44] <popey> didrocks: deleted how?
[10:44] <popey> disappearing?
[10:44] <didrocks> popey: apparently yeah, but maybe there are just getting mixed when changing TZ
[10:45]  * popey sends a few
[10:46] <didrocks> popey: ok, in fact, it's just an order issue
[10:46] <didrocks> like if you change you TZ
[10:46] <didrocks> they appear in the past
[10:46] <didrocks> so before your latest ones
[10:46] <popey> ahhh
[10:46] <popey> will be more pronounced as he's changing fron UTC to UTC minus some hours?
[10:47] <didrocks> popey: yeah, if you try that and send a sms after switching to the past :)
[10:47] <popey> heh
[10:47] <didrocks> I guess the messages are stored with local time, but no TZ information
[10:48] <didrocks> popey: maybe ubuntu touch can decide that TZ are confusing and we deprecate that? ;)
[10:49] <popey> YES!
[10:49] <popey> Lets make everyone use UTC and remove all TZ features
[10:49] <didrocks> heh ;)
[10:50]  * didrocks regrets that online music search works (seeing what I have to endure right now and can't stop the music :p)
[10:53] <popey> :D
[10:55] <popey> whenever i take screenshots of the music app I always orchestrate them so my leas embarrassing songs are on the screen
[10:57] <davmor2> popey: yeah you just go for novelty tracks instead, Mr blobby, Postman pat, Agadoo :D
[10:58] <davmor2> popey: don't worry we all know you love beiber really
[11:00] <Mirv> didrocks: psivaa: ok my mir results in the chart. notes_app 1-2 failures depending on the run, not being able to run unity8 tests (the mock version doesn't come up). on the upside video/audio works, autopilot works at least partially, full cpu usage always seems gone.
[11:01] <didrocks> Mirv: waow, excellent news! you didn't test  on desktop, right?
[11:03] <psivaa> Mirv: didrocks: hmm not sure what i am doing wrong (on maguro) i have 20/23 notes app failures
[11:03] <psivaa> Mirv: i dont see much difference in the results to yesterday's run with mir enabled
[11:04]  * didrocks reboots, back shortly
[11:07] <Mirv> psivaa: for me the main difference in test runs is that yesterday nothing really happened on the device when running phablet-test-run, but now it really runs the tests
[11:07] <Mirv> psivaa: it might be worse on maguro, but 3 tests succeeding means something got run at least
[11:07] <psivaa> Mirv: ok, understand :)
[11:07] <didrocks> Mirv: +1 on the desktop side
[11:08] <Mirv> didrocks: yeah I just rebooted on the updated desktop as well
[11:08] <didrocks> Mirv: so, if you want to publish all of them, be my guest (didn't check packaging changes though) ;)
[11:08] <Mirv> didrocks: ok, I'll check if there are packaging changes. this is an improvement at least.
[11:08] <didrocks> yeah ;)
[11:09] <didrocks> psivaa: did you figure out why it's more an issue for you than Mirv?
[11:09] <didrocks> (as I rebooted, didn't follow the conversation)
[11:10] <Mirv> didrocks: maybe maguro is worse, but we concluded that at least something got run on maguro at least well, as opposed to yesterday when autopilot didn't work at all
[11:10] <Mirv> didrocks: http://<IP_ADDRESS>:8080/view/cu2d/view/Saucy/view/Platform/job/cu2d-platform-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_platform-api_0.19+13.10.20131003-0ubuntu1.diff
[11:10] <psivaa> didrocks: no.. but apparently Mirv has nearly same results. i was complaining that the pass rate did not improve to me with mir when compared to yesterday
[11:10] <Mirv> didrocks: http://<IP_ADDRESS>:8080/view/cu2d/view/Saucy/view/Mir/job/cu2d-mir-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_mir_0.0.13+13.10.20131003-0ubuntu1.diff
[11:10] <Mirv> didrocks: http://<IP_ADDRESS>:8080/view/cu2d/view/Saucy/view/Mir/job/cu2d-mir-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_unity-system-compositor_0.0.1+13.10.20131003.1-0ubuntu1.diff
[11:11] <Mirv> psivaa: so you did get 20/23 also yesterday?
[11:11] <didrocks> Mirv: +1 on all
[11:12] <psivaa> Mirv: i got 19/23 yesterday
[11:12] <Mirv> psivaa: ah ok, I just concluded yesterday that it all fails. maybe maguro improved less then.
[11:12] <Mirv> didrocks: finally, http://<IP_ADDRESS>:8080/view/cu2d/view/Saucy/view/Unity8/job/cu2d-unity8-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_unity-mir_0.1+13.10.20131003.1-0ubuntu1.diff
[11:13] <psivaa> Mirv: quite possible
[11:13] <psivaa> Mirv: I think the reason for AP failures is bug #1232054 , which has not been fixed i suppose
[11:13] <didrocks> Mirv: easy +1 as well :)
[11:14] <didrocks> psivaa: hum, this one was supposed to be fixed
[11:14] <didrocks> psivaa: but it was already in image 75
[11:15] <psivaa> didrocks: still says in 'In progress'
[11:15] <didrocks> psivaa: yeah, I think they just didn't reference it in the changelog, I updated it (we have it)
[11:15] <didrocks> psivaa: so not that one
[11:15] <didrocks> psivaa: you are going to publish the new results, like yesterday? (with Mirv's one)
[11:16] <psivaa> didrocks: you mean in the landing plan?
[11:17] <didrocks> psivaa: hum, no, yesterday, I saw a google doc
[11:17] <didrocks> with the test results
[11:17] <psivaa> didrocks: yes, i'll add my results to that one, google doc
[11:17] <didrocks> excellent, thanks!
[11:17] <didrocks> psivaa: so unity8 tests are not starting still?
[11:18] <psivaa> didrocks: left to the last.. still running.
[11:18] <Mirv> didrocks: ok published mir, unity-system-compositor, platform-api, unity-mir
[11:19] <didrocks> Mirv: \o/
[11:19] <Mirv> and "phew", I need to have a break
[11:19] <didrocks> ;)
[11:19] <didrocks> well deserved one!
[11:20] <didrocks> (and thumbnailer in, nice sil2100!)
[11:26] <ev> didrocks: Did lightdm get switched over to manual publication? Just going back through email missed while I was on holiday.
[11:27] <didrocks> ev: it's still manually uploaded, we didn't want to stage it in the ppa and decided to wait post V1 to change that
[11:27] <ev> okay, thanks!
[11:27] <didrocks> yw ;)
[12:00]  * didrocks out for some exercise
[12:04] <cjwatson> Mirv: I don't see the unity-lens-applications part of landing number 88 anywhere in the queue
[12:06] <cjwatson> accepted the rest
[12:09] <cjwatson> sil2100: landing number 74 (hud) - I don't quite understand column H, does that mean that this is/isn't OK to accept from unapproved?
[12:10] <cjwatson> ... never mind, somebody else already did.  certainly doesn't look like it should break tests!
[12:15] <kgunn> plars: ping
[12:15] <sil2100> cjwatson: no, it's ok to move it, as I had problems with running tests on my device then - but dogfooding and using earlier images made me publish it
[12:18] <kgunn> Mirv: thanks for the publishing work!
[12:33] <lool> == Building click-package stack ==
[12:33] <lool> this is to pickup a click-update-manager icon bugfix
[12:33] <lool> hmm why did it disappear from results
[12:34] <cjwatson> new mir stuff -> inarchive
[12:35] <cjwatson> new unity-scope-home / libunity -> inproposed, except for above question about whether there's still unity-lens-applications to come
[12:35] <cjwatson> qtdeclarative -> inproposed though building, dunno if you want to annotate that separately
[12:36] <cjwatson> and hud debug changes -> inproposed
[12:37] <Mirv> cjwatson: right, the applications part wasn't released yet. thanls for the rst
[12:38] <cjwatson> want to note that in the landing plan somehow?
[12:38] <cjwatson> if we have to have this thing it probably ought to be correct :)
[12:41] <Mirv> cjwatson: yeah, done, we discussed the home scope and its libunity dependency so much that the small apps lens got sidetracked..
[12:43] <cjwatson> Mirv: OK - it's not inarchive yet though
[12:44] <cjwatson> it's waiting for autopkgtests according to http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[12:44] <cjwatson> check rmadison before setting to inarchive, otherwise people may think they can run image builds and pick up your change
[12:44] <Mirv> cjwatson: yeah, I just checked also that still in proposed
[12:44] <psivaa> jibel: jfunk: is there a reason why the mir testing results for image 78 is removed from https://docs.google.com/a/canonical.com/document/d/1b-X9tN2Q9c_5r39XzA-Ppebbjuin5zVf9SkAGMcdp9Q/edit#
[12:45] <cjwatson> hud is publishing to release at the moment
[12:47] <jibel> psivaa, interesting, I don't know who did that. I'll find who and get them back
[12:47] <psivaa> jibel: i think from rev history it was jfunk :)
[12:47] <jibel> psivaa, ah, is has been moved to the top of the doc
[12:47] <jfunk> sorry guys
[12:48] <jfunk> I am reporting to the UE Leads and have a bit of OCD with these type of things
[12:48] <jibel> jfunk, np, it's easier to read this way
[12:48] <psivaa> jibel: jfunk: ahh my bad too.. sorry
[12:50] <fginther> morning
[13:05] <ralsina> lool: landing ask row 74 is already landed
[13:10] <lool> ralsina: thanks, cleared
[13:14] <lool> didrocks: tested new system-image, seems ok but with some glitches
[13:14] <lool> didrocks: 2 secs
[13:17] <lool> didrocks: alright, hinted system-image + lxc-android-config in
[13:19] <lool> didrocks: so for system-image what I got was: 1) first I saw 100% progress briefly, 2) then I saw 0% progress almost immediately, 3) then it stayed on 0% for a while, but I don't have super good wifi here, moved closer to the AP, 4) after 20 seconds or so, download started, I got progress update, 5) at the end got install & restart
[13:19] <didrocks> lool: for 1) are you sure it was 100% or indeterminate?
[13:19] <lool> didrocks: it said 100%
[13:20] <didrocks> hum, the only thing I can see is that the daemon send UpdateProgress(100, noeta)
[13:20] <lool> possibly
[13:20] <lool> didrocks: are there logs?
[13:20] <didrocks> lool: I think when doing an update, logging the system dbus can be interesting
[13:20] <didrocks> I don't think there are logs on the UI side
[13:20] <lool> didrocks: you could also have some logging on the UI side
[13:20] <lool> right
[13:21] <lool> I fear that logging all dbus traffic or even just download progress updates might be too much
[13:21] <didrocks> lool: system bus should be ok, there isn't so much
[13:21] <lool> we could log everything except progress messages which are not zero and not 100
[13:22] <plars> kgunn: hi
[13:22] <didrocks> yeah, a little bit late for that, but I agree
[13:23] <didrocks> lool: so, are you going to block system-image for next image?
[13:23] <didrocks> or do you still want it?
[13:23] <didrocks> plars: nice to see a so green dashboard! (thanks for all the retrials on flacky tests)
[13:24] <plars> didrocks: that wasn't me on 78, that image came in the midnight hours for me, if anyone retried that it was probably psivaa
[13:24] <plars> didrocks: I saw though, the results looked really good
[13:24] <lool> didrocks: I want it
[13:24] <lool> didrocks: I unblocked it
[13:24] <didrocks> psivaa: nice! :)
[13:24] <lool> didrocks: it's strictly better than what we have
[13:24] <lool> and we're landing 95% of features
[13:24] <plars> psivaa: were there lots of retries needed, or did things mostly just work?
[13:24] <didrocks> lool: ok, do you tihnk you want more? everything is nearly here for us, so I would love to see an image kicked soon
[13:25] <lool> didrocks: can confirm url-dispatcher in a sec
[13:25] <kgunn> plars: hey, sorry...keep getting interupts :)
[13:25] <psivaa> plars: didrocks: i only reran mediaplayer tests once in both mako and maguro.. both passed on the retry
[13:25] <didrocks> Mirv: missing app lens, wdym?
[13:25] <didrocks> Mirv: oh, you missed that one?
[13:25] <plars> psivaa: wow, that's not bad
[13:25] <lool> didrocks: oh what do you think of the click-update-manager icon and the tests in the click-package stack?
[13:25] <kgunn> plars: anyway, thomi was helping w/ enabling AP testing on mir
[13:26] <psivaa> plars: the failures before that was due to a mediaplayer crash which did not happen on the retry.. on both devices
[13:26] <didrocks> lool: it's under testing right, do you have an ETA?
[13:26] <plars> kgunn: I believe we are still waiting on some autopilot pieces to land, aren't we?
[13:26] <lool> didrocks: 5 minutes of testing + upload dance
[13:26] <didrocks> plars: waow, not that bad then!
[13:26] <plars> didrocks: ? ^ I thought it was supposed to land yesterday but I didn't see a new package
[13:26] <didrocks> lool: ok, let's get that one in, sound safe enough
[13:26] <kgunn> plars: yeah...they are in trunk but should be in image 79
[13:26] <plars> ok, great
[13:26] <didrocks> plars: kgunn: they are in the archive
[13:26] <didrocks> so definitively will be in 79
[13:27] <didrocks> psivaa: did you succeed in running the unity8 tests btw?
[13:27] <lool> hmmmhmmm UI not coming up
[13:27] <lool> lightdm start/running, process 1350
[13:27] <didrocks> lool: for click?
[13:27] <psivaa> didrocks: no.. 24/24 test failures  with mir enabled
[13:27] <didrocks> or whole phone?
[13:28] <lool> unity8 not coming up
[13:28] <didrocks> psivaa: ok, but at least, you see the tests starting?
[13:28] <lool> this is with SF
[13:28] <psivaa> didrocks: yea
[13:28] <didrocks> psivaa: unlinke yesterday when they even didn't start?
[13:28] <didrocks> ok ;)
[13:28] <didrocks> unlike*
[13:28] <didrocks> lool: what did you install?
[13:28] <plars> psivaa: was that with the new autopilot?
[13:28] <lool> didrocks: url-dispatcher
[13:29] <lool> I have the lxc-android-config stuff too
[13:29] <lool> but it booted the first time
[13:29] <didrocks> lool: retry a boot to see if something was flacky
[13:29] <lool> so I'm tempted to try a reboot
[13:29] <lool> didrocks: right
[13:29] <didrocks> plars: the fixes are in mir itself (not autopilot)
[13:29] <psivaa> plars:  1.3.1+13.10.20131003.1-0ubuntu1 is the autopilot-touch version
[13:29] <lool> ah crap, load was high, should have checked that first
[13:29] <lool> to late
[13:29] <plars> did for some reason I was thinking there was an update to autopilot needed too, maybe not
[13:30] <didrocks> plars: no, we did one, but unrelated :)
[13:30] <plars> ack
[13:30] <didrocks> the mir fixes are for AP
[13:30] <didrocks> but not in AP ;)
[13:30] <lool> I wonder if it's MTP with USB cable connected
[13:30] <lool>   675 system    20   0  7020 1580 1224 S  85.4  0.1   0:38.98 sensorservice
[13:31] <lool> ah fianlly came up
[13:31] <lool> didrocks: I wonder whether I was not patient enough
[13:31] <lool> boot is super slow these days
[13:32] <didrocks> lool: do you have a .crash file?
[13:32] <lool> tons
[13:32] <didrocks> lool: maybe something crashed and you had apport collecting
[13:32] <didrocks> ah :p
[13:32] <lool> _usr_bin_maliit-server.32011.crash _usr_bin_unity8.32011.crash _usr_lib_arm-linux-gnueabihf_hud_hud-service.32011.crash _usr_lib_arm-linux-gnueabihf_upstart-app-launch_zg-report-app.32011.crash
[13:32] <didrocks> waow
[13:32] <didrocks> nice strike!
[13:32] <lool> but only one is recent
[13:32] <lool> Hmm
[13:32] <lool> there is weird timing on some of them
[13:32] <lool> from this morning, despite having reflashed
[13:33] <lool> this one is definitely interesting: -rw-r----- 1 phablet whoopsie 12083112 Oct  3 13:27 _usr_bin_unity8.32011.crash
[13:33] <davmor2> lool: let me guess you have mir enabled
[13:33] <lool> oh indeed
[13:34] <lool> stupid me, forgot that this stayed across flashes
[13:34] <didrocks> sil2100: around?
[13:34] <sil2100> didrocks: yes!
[13:34] <lool> davmor2: yeah, that's why it was slow
[13:34] <davmor2> lool: the upstart-app-launch_zg only shows on mir
[13:34] <didrocks> sil2100: I think Mirv forgot unity-lens-application from request 88, mind doing it?
[13:34] <jibel> and maliit and hud crashes too
[13:34] <didrocks> sil2100: should be quite quick to test (on both desktop and touch)
[13:34] <didrocks> sil2100: just ensure that you have latest commit built in the ppa
[13:35] <davmor2> jibel: true although you can get maliit crashes on sf too
[13:35] <sil2100> didrocks: ACK!
[13:35] <didrocks> thanks sil2100 ;)
[13:35] <sil2100> didrocks: picking that up now
[13:36] <lool> didrocks: ok, tested a bunch of URLs: applications:///, music:///, http://, settings:///, and video:///
[13:36] <lool> didrocks: all good to go
[13:36] <didrocks> lool: excellent! :)
[13:36] <lool> pushing url-dispatcher
[13:36] <lool> alone
[13:36] <didrocks> lool: so then, you're on click, sil2100 on lens-apps
[13:36] <didrocks> and we're good for 79?
[13:37] <lool> didrocks:  hmm the build parameters seem different for misc stack
[13:38] <didrocks> sergiusens: rsalveti: if you want something to get in 79, it's now (we are testing/uploading the latest things before kicking the next image)
[13:38] <didrocks> lool: wdym? Maybe I missed a publish
[13:38]  * didrocks looks
[13:38] <lool> didrocks: like the new field to specify packages to act on isn't the same
[13:38] <didrocks> lool: uno secundo
[13:38] <didrocks> lool: ah, it seems with the list of deployement I missed one, one sec
[13:39] <didrocks> lool: are someone redeployed without pulling latest
[13:39] <didrocks> (which happens sometimes)
[13:39] <kgunn> hey Mirv just reading landing notes where you say the following....
[13:39] <kgunn> notes-app AP 1-2 failures depending on the run (notes_app.tests.test_delete.TestDelete.test_slide_to_delete_left+notes_app.tests.test_parts.TestFocus.test_parts_focus). managed to get the mako hanged once (adb shell not working).
[13:39] <kgunn> unity8 autopilot runs (with -n) seemingly not possible, the mockup unity8 doesn't come up
[13:39] <lool> didrocks: let's remind everyone to bzr pull latest cu2d later in the call
[13:39] <kgunn> Mirv: can you elaborate on the unity8 -n, seemingly not possible ?
[13:39] <didrocks> kgunn: yeah, didn't work for Mirv, seems to have worked (but all tests failed) for psivaa
[13:40] <didrocks> lool: yeah, let's do that
[13:40] <didrocks> lool: should be better now
[13:40] <lool> hmm why did cupstream2distro-config diverge with my branch
[13:40] <lool> I had pushed this stuff
[13:40] <didrocks> lool: but definitively, we need to autodeploy when pushing a branch
[13:40] <sergiusens> didrocks, is qtmultimedia-touch in?
[13:40] <kgunn> didrocks: Mirv is that b/c it needs apt-get install unity8-fake-env
[13:40] <didrocks> sergiusens: it's in
[13:40] <didrocks> sergiusens: since 78
[13:41] <sergiusens> didrocks, is the request rsalveti made last night in for the races for lxc-android-config?
[13:41] <didrocks> kgunn: ah, I don't know how he tested, I think he just installed the -autopilot package, that should pull the fake-env, right?
[13:41]  * didrocks looks
[13:41] <lool> == Publishing url-dispatcher (misc stack) ==
[13:41] <didrocks> sergiusens: lool pushed it but blocked it in proposed AFAIK
[13:41] <lool> sergiusens: that was the one in #77 I think
[13:42] <kgunn> didrocks: you are right...it _should_ when you install a suite..but good to double check
[13:42] <lool> didrocks: no that's another one, that's the boot script that I blocked and unblcoked
[13:42] <didrocks> ah ;)
[13:42] <psivaa> didrocks: kgunn: http://pastebin.ubuntu.com/6188183/ is what i get for unity8 with mir
[13:42] <didrocks> kgunn: it's a dep, so yeah, should be there
[13:42] <didrocks> (just checked)
[13:42] <sergiusens> lool, didrocks landing ask 95 if I'm reading that correctly
[13:43] <didrocks> sergiusens: no, this one was just "ok for you to upload" (with both tests that were provided)
[13:43] <lool> sergiusens: sorry, that's something else; I thought you meant the upstart-file thing from yesterday evening, but that was in android
[13:43] <lool> sergiusens: do you need lxc-android-config to be staged somewhere for testing, or are you good to test locally and upload?
[13:43] <sergiusens> lool, they are sort of connected
[13:44] <lool> didrocks: so the rev that I've lost in the -config was:
[13:44] <lool>   Add qtdeclarative5-usermetrics0.1, new dependency of camera-app (already in
[13:44] <lool>   Ubuntu), as this breaks media stack autopilot tests.
[13:44] <sergiusens> didrocks, I was never asked to provide any tests
[13:44] <lool> I'm pretty sure I had pushed it a day where you weren't around, like last week-end
[13:44] <didrocks> lool: I just pulled and push, didn't --overwrite
[13:44] <lool> but didn't deployed
[13:45] <lool> didrocks: no idea what happened then
[13:45] <lool> maybe my pushed failed and I didn't notice, but weird
[13:45] <sergiusens> lool, I already tested locally, I don't see how the risk is medium though
[13:45] <lool> sergiusens: just because it might break boot
[13:45] <didrocks> sergiusens: not providing tests, just testing on the scenarios we wrote
[13:45] <sergiusens> lool, currently, the system is deleting the socket that the upstart-local-bridge is creating
[13:45] <lool> sergiusens: you did the testing then, all good  :-)
[13:45] <didrocks> sergiusens: which seem to be impacted (it's a 10 minute test)
[13:45] <sil2100> didrocks: testing is fine both on unity7 and unity8, publishiiing!
[13:46] <lool> sergiusens: would you upload this like now so that it can make it to image?
[13:46] <didrocks> sergiusens: if you did it on your system, awesome, that's what we were waiting for ;)
[13:46] <didrocks> sil2100: sweet!
[13:46] <sergiusens> didrocks, so our team always tests an MR contrary to others
[13:46] <lool> sergiusens: I think I had added that testing note that this is the type of testing we would like to see, either from uploder or from us, to make sure we don't regress boot with the change
[13:46] <didrocks> sergiusens: I know that we can trust your team, now worry, we just write so that there is a common rule and no misunderstanding :)
[13:46] <didrocks> no*
[13:47] <sergiusens> lool, well I can test a r/w image
[13:47] <lool> sergiusens: if you think it's an important test, that's welcome
[13:47] <didrocks> that would be great ;)
[13:47] <sergiusens> lool, I see no point in it, but give me a second
[13:47] <lool> I think I had noted mako and maguro as boot tests
[13:47] <lool> but I don't particularly care in rw vs. ro boot tests
[13:48] <lool> didrocks:  qtdeclarative5-usermetrics0.1 is only in saucy, not head config
[13:48] <sergiusens> lool, well we can wait for rsalveti to confirm on mako
[13:48] <lool> didrocks:  do you try to keep these up-to-date?
[13:48] <didrocks> lool: better once we start diverging, yeah
[13:48] <lool> sergiusens: would you upload lxc-android-config right now
[13:49] <lool> sergiusens: it will be staged in proposed
[13:49] <lool> sergiusens: rsalveti and/or me can test it on mako from thre
[13:49] <sergiusens> lool, I can't really
[13:49] <lool> didrocks: would you mind adding it to head?
[13:49] <lool> sergiusens: ah how so?
[13:49] <lool> sergiusens: may I help?
[13:49] <sergiusens> lool, didrocks if there's another build today, we can wait for rsalveti
[13:49] <didrocks> lool: can do right
[13:49] <sergiusens> lool, I'm not a core dev
[13:49] <lool> sergiusens: gosh!
[13:49] <lool> sergiusens: where do I sign
[13:50] <sergiusens> lol
[13:50] <didrocks> sergiusens: later today or tomorrow morning, depends on the velocity and who will be around to trigger an image, but it's really as you wish, if you prefer waiting for rsalveti
[13:50] <rsalveti> morning
[13:50]  * rsalveti reading backlog
[13:51] <sergiusens> didrocks, I always ACK my MRs too ;-)
[13:51] <sergiusens> rsalveti, just lxc-android-config
[13:51] <sergiusens> rsalveti, with the race avoidance
[13:52] <didrocks> sergiusens: rsalveti: so, if all testing is good, please upload it now for being in 79
[13:53] <lool> sergiusens: uploaded
[13:53] <fginther> didrocks, mind if I backout autopilot from the PPA?
[13:53] <lool> fginther: we're interested in issues you have with it though
[13:53] <lool> fginther: cause it's supposedly working for us!
[13:53] <didrocks> fginther: why? this one should be fine
[13:53] <fginther> :-(
[13:53] <didrocks> fginther: we got everything passing and it's uploaded to the archive
[13:53] <lool> rsalveti: morning
[13:54] <fginther> didrocks, lool https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-vm-saucy/ builds 170 - 179
[13:54] <didrocks> fginther: does the sdk has the fix merged?
[13:54] <fginther> these are desktop runs
[13:54] <didrocks> sil2100: would know ^
[13:54] <fginther> ahh
[13:54] <didrocks> fginther: there was a branch (we backported the fix manually to distro) for the sdk
[13:55] <didrocks> fginther: but we couldn't get it merged
[13:55] <didrocks> one sec
[13:55] <didrocks> fginther:  [4] https://code.launchpad.net/~veebers/ubuntu-ui-toolkit/ap-test-fixes-for-updated-autopilot/+merge/188970
[13:55] <didrocks> you will need that one ^
[13:56] <fginther> didrocks, much thanks
[13:56] <didrocks> fginther: manually, on the phone, it pass
[13:57] <rsalveti> didrocks: lool: I want to land the seek related improvements as well, but guess that can wait for 80
[13:57] <rsalveti> as it'll take at least another ~2 hours
[13:57] <lool> rsalveti: yeah
[13:57] <didrocks> rsalveti: yeah, sounds better for 80 then, just upload the other one
[13:57] <lool> rsalveti: I've asked on the spreadsheet how we can see the bug / confirm the fix
[13:58] <psivaa> kgunn: Mirv might have mentioned the failure of launch_unity with with -n .. i also see that with http://pastebin.ubuntu.com/6188183/
[13:58] <lool> didrocks: updated spreadsheet; testing click packages
[13:58] <didrocks> grand!
[13:58] <rsalveti> lool: right, just seek before and after :-)
[13:58] <didrocks> rsalveti: it's going to fix the slowdown?
[13:58] <sil2100> didrocks, fginther: I guess this merge will get in once the new autopilot is available, so I think we can again approve this
[13:58] <Mirv> sil2100: didrocks: thanks, indeed I forgot apps part with all the home scope discussion. it seems to work as well, on both device (unity8 AP) and desktop (manual), plus it's a string change only so should be good.
[13:58] <fginther> sil2100, right, I just realized that, rerunning the test now that autopilot is there
[13:58] <rsalveti> lool: but you need to create the android image with latest hybris as we got a change in there as well
[13:58] <psivaa> kgunn: just making sure that i dont bring any confusion on 'worked but all 24 tests failed'
[13:58] <Mirv> sil2100: did you publish it yet?
[13:59] <rsalveti> didrocks: well, seek works after we publish those changes
[13:59] <rsalveti> currently it can easily lock down the mediaplayer-app if you seek
[13:59] <didrocks> rsalveti: oh? I did dream it was working for me? I remember trying it
[13:59] <didrocks> (but it was really laggy)
[13:59] <Mirv> kgunn: regarding phablet-test-run -n unity8, it seems that the unity8 is just closed (as should be) but the mock version of unity8 that autopilot should use does not come visible. I did not wait for the autopilot to error out.
[13:59] <rsalveti> right, it's currently laggy as well
[13:59] <fginther> sil2100, should have results in about 10 minutes
[13:59] <Mirv> kgunn: the unity8-fake-env is there, and it works without mir
[14:02] <lool> didrocks: not joining?
[14:02] <sil2100> fginther: awesome, thanks!
[14:02] <didrocks> lool: I guess I had the wrong link
[14:02] <sil2100> Mirv: u-l-a? Yes
[14:02] <sil2100> ;)
[14:02] <kgunn> Mirv: psivaa-afk thanks guys...yeah..i understood it correctly...interesting
[14:03] <didrocks> lool: do you have the link? I end up being alone
[14:03] <Mirv> sil2100: ok, thanks, cool! seeing it now in queue
[14:03] <lool> didrocks: see msg
[14:03] <sil2100> Mirv: np. :)
[14:04] <Mirv> cjwatson: so, unity-lens-applications now in the queue
[14:05] <kgunn> Mirv: building local is a nightmare...if i wanted to get one of my engineers on what you and psivaa-afk see....what's the best way to do that in advance of image 79 being available ?
[14:06] <didrocks> rsalveti: your change is in the version lool uploaded I guess (for req 95), the one blocked in proposed?
[14:06] <didrocks> kgunn: install image 78, turn in in write mode and apt-get update && apt-get install libmirserver5
[14:06] <rsalveti> didrocks: for lxc-android-config, yes
[14:06] <didrocks> then activate mir and be done :)
[14:06] <didrocks> excellent, so all in transit!
[14:07] <kgunn> didrocks: thanks for confirming...thot that was the answer
[14:07] <didrocks> yw
[14:07] <Mirv> kgunn: as didrocks described ^ reboot, wait for Nautilus window to pop up the mounted share (connection breaks at that moment, takes about 30s after unity8 is visible), run phalet-test-run -n unity8 (after also installing unity8-autopilot)
[14:08] <cjwatson> Mirv: looking
[14:09] <cjwatson> Mirv: accepted
[14:10] <fginther> sil2100, retest with the new autopilot worked. I've re-approved the MP.
[14:10] <Mirv> cjwatson: thanks!
[14:10] <fginther> didrocks, ^
[14:11] <didrocks> fginther: sweeeeeet \o/
[14:27]  * rsalveti pushing libhybris, will only be used after a respin of the android package
[14:27] <rsalveti> didrocks: lool: when are you guys starting next image?
[14:27] <lool> rsalveti: mind testing latest lxc-android-config from proposed on mako?
[14:27] <lool> boot testing that is
[14:27] <rsalveti> lool: sure
[14:27] <lool> rsalveti: in a few, pushing some remaining packags (click) and then waiting for in archive + building
[14:28] <didrocks> rsalveti: it's the last one we are waiting on, then once published in the release pocket, we kick the image (click should be in beforehand)
[14:34] <lool> finishing click tests
[14:37] <lool> click is good
[14:37] <lool> publishing
[14:37] <lool> didrocks: I need help to preNEW http://<IP_ADDRESS>:8080/job/cu2d-click-package-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_click-update-manager_0.1+13.10.20131003.1-0ubuntu1.diff
[14:38] <lool> didrocks: click-update-manager-autopilot
[14:38] <lool> didrocks: what do you do there, or who do I ping to preNEW it?
[14:38] <didrocks> lool: ok, looking
[14:38] <lool> didrocks: I review it and then just say it looks good?
[14:38] <didrocks> well, an archive admin, I'm doing it :)
[14:39] <didrocks> lool: for the operation to do, you have: https://wiki.ubuntu.com/DailyRelease/FAQ#Adding.2BAC8-removing_components_to_a_stack
[14:39] <lool> didrocks: what do I tell the archive admin?
[14:39] <didrocks> ah, it's a binary new
[14:39] <lool> yes
[14:40] <didrocks> well, normally, I just give a look (as if the sync was passing normal binary New)
[14:40] <didrocks> ah finally click-update-manager arch:all :p
[14:40] <lool> didrocks: I see the instrucitons in the FAQ actually
[14:40] <didrocks> lool: ok, using dh_python2, +1 from me
[14:41] <didrocks> lool: well, there are for source new
[14:41] <lool> didrocks: it seems I should be doing something in the -config though
[14:42] <didrocks> lool: hum, not for binary new, if there are AP tests, yeah, you should add them to the config if they can run on desktop
[14:42] <lool> == Publishing click-package stack ==
[14:42] <lool> ralsina: ^ FYI
[14:43] <lool> rsalveti: did the boot go ok?
[14:43] <rsalveti> lool: rebooting and will check
[14:44] <rsalveti> did a clean flash
[14:46] <rsalveti> lool: all fine +1
[14:46] <lool> cool, also rebooting here
[14:47] <lool> yep, came up
[14:47] <lool> unblocked
[14:47] <didrocks> sweet :)
[14:48] <lool> now waiting for click + lxc transitions to release + publisher
[14:49] <lool> so 5:30pm our time perhaps
[14:49] <didrocks> yeah
[14:49] <didrocks> (40 minutes for now for other in an insane timezone)
[14:49] <didrocks> from*
[14:51] <lool> didrocks: so how do we run the Mir tests on regular AP infrastructure?
[14:51] <lool> didrocks: I wonder if this is our last SF image
[14:51] <lool> maybe not
[14:53] <didrocks> lool: on the regular infra? that would be a plars or doanac's question. I think they just copy the same run, but add an adb shell touch /home/phablet/.display-mir before the reboot
[14:54] <lool> didrocks: I think that's what olli wanted right?
[14:54] <didrocks> yeah
[14:54] <didrocks> we'll discuss that in the meeting with plars I guess
[14:55] <plars> lool: I'm planning on setting that up once we have all the pieces needed in the image to make it work right
[14:55] <plars> lool: I'll set up a separate job for it
[14:55] <plars> didrocks: ^
[14:56] <didrocks> plars: so just adding the touch in the setup?
[14:56] <plars> didrocks: for that run, yes
[14:56] <didrocks> sounds good!
[14:56] <plars> didrocks: I don't think we want to turn it on as the default yet right (even in the tests)? So it'll just be a one-off job temporarily
[14:56] <lool> plars: what are the pieces?  the mir + AP fixes?
[14:56] <plars> lool: yes
[14:57] <lool> plars: FYI these should be all good now, albeit we're getting different patterns on whethre unity8 tests run or don't run from different folks
[14:57] <lool> plars: cool
[14:57] <lool> plars: so I think that would be good to have starting with the next build
[14:57] <lool> in a few
[14:58] <plars> lool: that's another thing I'm about to try
[14:58] <plars> lool: locally that is
[14:58] <lool> autopkgtest for click-update-manager 0.1+13.10.20131003.1-0ubuntu1: RUNNING (Jenkins: public, private)
[14:58] <lool> that blocks a couple of click updates from moving right now
[14:58] <lool> it seems to have passed
[15:07] <plars> doanac:
[15:07] <plars> raise click.AppArmorException("Could not find '%s'" % include)
[15:07] <plars> apparmor.click.AppArmorException: "Could not find '/usr/share/autopilot/apparmor/click.rules'"
[15:08] <doanac> plars: you sure you have the updated version?
[15:08] <plars> autopilot-touch:
[15:08] <plars>   Installed: 1.3.1+13.10.20131003.1-0ubuntu1
[15:09] <plars> /usr/share/autopilot/apparmor/click.rules seems to be there
[15:10] <doanac> plars: where did the excepction come from?
[15:10] <plars> oh wait
[15:10] <plars> doanac: it's /usr/share/autopilot-touch/apparmor/click.rules
[15:10] <plars> not /autopilot
[15:10] <doanac> plars: ah. thanks.
[15:10] <doanac> i'll update the mp
[15:11] <plars> doanac: I'll update it locally and retry
[15:11] <didrocks> plars: yeah, if we can run them in parallel until we turn it on by default (sorry didn't see your ping ;))
[15:19] <plars> doanac: ok with that change it works for me
[15:20] <plars> doanac: 5 passes on a click package test :)
[15:20] <plars> sergiusens: ^
[15:22] <sergiusens> plars, AWESOME!
[15:23] <plars> sergiusens: doanac has a mp to put in once 79 lands that should turn dropping-letters tests on at least
[15:23] <ralsina> lool: ack
[15:24] <ralsina> lool: I assume you can mark ask #115 as done then
[15:25] <doanac> plars: branch is updated, and I tested locally also
[15:25] <lool> lxc is in
[15:26] <lool> click-update-manager still in proposed
[15:26] <lool> but valid candidate
[15:27] <sergiusens> doanac, I was actually going to ask you if we should look at your branches again, going to review now
[15:31] <lool> it's in
[15:31] <lool> didrocks: kicking image
[15:31] <lool> ah no
[15:31] <lool> click-update-manager is not, weird
[15:31] <didrocks> right, not yet
[15:32] <lool> why did clickmanager-plugin transition though
[15:32] <lool> oh
[15:32] <lool> arch: all change
[15:33] <lool> cjwatson: hey
[15:33] <lool> cjwatson: can you help me understand whether the click-update-manager proposed transition is going ok?
[15:33] <lool> cjwatson: we switched it from arch: any to arch: all
[15:33] <lool> rmadison says:
[15:33] <lool> click-update-manager | 0.1+13.10.20131003.1-0ubuntu1 | saucy/universe | source, all
[15:33] <lool> click-update-manager | 0.1+13.10.20131003.1-0ubuntu1 | saucy-proposed/universe | all
[15:33] <lool> so it looks like it's actually in
[15:33] <lool> but with a copy in -proposed
[15:34] <lool> there's also an old entry:
[15:34] <lool> click-update-manager | 0.1+13.10.20130930.1-0ubuntu1 | saucy/universe | amd64, armhf
[15:34] <cjwatson> lool: That might need archive admin assistance, will check in a sec
[15:36] <cjwatson> lool: But you don't need to worry about it, it's cruft that's reported on and needs to be cleaned up for release, but shouldn't cause a practical problem
[15:37] <lool> ok
[15:37] <lool> didrocks: building an image
[15:37] <didrocks> \o/
[15:38] <plars> psivaa: you got the unity8 tests working with an update 77?
[15:38] <plars> psivaa: and mir enabled?
[15:39] <psivaa> plars: i tried it with 78, with updates.. but all 24 failed
[15:39] <plars> psivaa: I meant 78, sorry
[15:40] <plars> didrocks: so, I'm not having any luck getting things going with autopilot tests either. All the pieces should be there right now if I dist-upgrade though right?
[15:40] <psivaa> plars: yea with that, this is the result: http://pastebin.ubuntu.com/6188183/
[15:40] <didrocks> plars: yeah, if you dist-upgrade from the archive, you should be fine
[15:41] <plars> didrocks: not working it seems, works fine if I don't enable mir though
[15:41] <didrocks> weird, psivaa got it working (well failing rather :p)
[15:41] <plars> didrocks: no, he's seeing same as me
[15:42] <didrocks> ah, nice, so the tests are running?
[15:42] <didrocks> (but failing)
[15:42] <plars> didrocks: they don't seem to actually be working at all - I see nothing happening on my screen
[15:43] <didrocks> but psivaa saw the tests starting, didn't he?
[15:43]  * didrocks is now confused
[15:43] <plars> psivaa: were you trying this locally? could you see it actually doing something on the screen?
[15:43] <psivaa> didrocks: i did not see changes in the device.. sorry i dint know if that's what you meant
[15:44] <didrocks> so the tests don't even start?
[15:44] <didrocks> ok, let's see with the real infra
[15:46] <lool> it looks to me like it cant connect on dbus
[15:46] <plars> didrocks: there's no difference with how I'm running it here vs. how it would run in the lab
[15:46] <plars> didrocks: except that I've enabled mir
[15:46] <didrocks> plars: well, olli wanted to have a run in the "official infra"
[15:47] <ogra_> did you guys forget -n ?
[15:47] <didrocks> so let's get that ;)
[15:47] <plars> and updated the image of course, but it's the same scripts getting called the same way
[15:47] <plars> ogra_: no
[15:47] <ogra_> i dont see it stop unity8 in the paste above
[15:47] <plars> ogra_: I stopped it in mine
[15:47] <ogra_> manually ?
[15:48] <plars> ogra_: no, the scripts we run do that
[15:48] <ogra_> right, it usually prints "stopping unity8"
[15:48] <plars> even the unlocker doesn't seem to get through here...
[15:48] <plars> I'm trying friends app
[15:48] <plars> Setting up friends-app-autopilot (0.92.0+13.10.20131001.1-0ubuntu1) ...
[15:48] <plars> ----------------------------------------------------------------------
[15:48] <plars> Stopping Unity
[15:48] <plars> unity8 stop/waiting
[15:48] <plars> Unity stopped
[15:48] <plars> ----------------------------------------------------------------------
[15:48] <plars> Starting Unity with testability
[15:48] <plars> and that's as far as I get
[15:48] <ogra_> ok
[15:50] <plars> going to retry with just phablet-test-runner and manually unlocking
[15:51] <psivaa> plars: ogra_ didrocks: so i ran unity8 again. same results (24 failed) i did not see any change in the screen..
[15:52] <didrocks> ok, so it seems something didn't work at all
[15:52] <didrocks> kgunn: FYI ^
[15:52] <plars> ok, so the screen unlocker (which also restarts unity8 with -testability) doesn't seem to work in the ci infrastructure
[15:52] <didrocks> kgunn: so now all testimonials concurres
[15:52] <plars> but if I unlock  by hand, I can get other (non-unity8) tests to work
[15:52] <didrocks> plars: this is already a good news, can you try notes-app?
[15:52] <didrocks> this one was blocking before
[15:55] <plars> didrocks: one sec, need to restart. I was trying unity8 with just phablet-test-run and -n again - still nothing
[15:59] <robru> didrocks, bah! powersaving is still busted for me
[15:59] <robru> woke up to find both my screens had been on all night
[15:59] <didrocks> robru: did you talk to seb128 about it? he would maybe have an idea
[15:59] <plars> didrocks: the notes-app tests can run ok, but only if unlocked by hand - clearly things are going to go badly in the lab with this though
[15:59] <robru> didrocks, no, not yet
[15:59] <plars> didrocks: and unity8 plain won't work
[15:59] <plars> the tests that is
[15:59] <didrocks> plars: ok, thanks for confirming!
[16:00] <cjwatson> lool: either somebody else cleaned up click-update-manager or it sorted itself out
[16:00] <cjwatson> click-update-manager | 0.1+13.10.20131003.1-0ubuntu1 | saucy/universe | source, all
[16:00] <cjwatson> click-update-manager-autopilot | 0.1+13.10.20131003.1-0ubuntu1 | saucy/universe | all
[16:00] <cjwatson> It might just be that the copy and the removal spanned two publisher runs or something *shrug*
[16:01] <didrocks> robru: sil2100: plars: joining the HO?
[16:01] <robru> didrocks, meeting?
[16:01] <didrocks> yep ;)
[16:01] <robru> didrocks, i can't find the link
[16:01] <plars> didrocks: yes, I was just digging up my headphones :)
[16:01] <lool> cjwatson: indeed, thanks
[16:01] <didrocks> robru: https://plus.google.com/hangouts/_/a3ec8b9eafe13514725f4c495d40dbc56771c9ca
[16:09] <plars> doanac: did you go ahead and regenerate the jobs so that when 79 lands we'll pick up that new test?
[16:09] <kgunn> didrocks: plars...so this https://code.launchpad.net/~mterry/unity8/load-testability/+merge/188064
[16:09] <doanac> plars: no. i wanted to double check
[16:09] <kgunn> is in what was test and didn't work ?
[16:10] <plars> doanac: we should
[16:10] <doanac> i guess we can if you want though
[16:10] <doanac> plars: okay. i'll merge now
[16:10] <plars> kgunn: it looks like it might have something to do with restarting unity8
[16:11] <plars> kgunn: running phablet-test-run -n (for unity8) and you see unity8 go off, but never come back.
[16:11] <plars> kgunn: also, for all ap tests, we have a script that unlocks the screen and restarts unity8 in -testability mode. It doesn't seem to function now either
[16:12] <doanac> plars: change is pushed. do you want to re-generate? i haven't done it lately and don't want to cause harm
[16:12] <plars> doanac: sure, will do
[16:12] <kgunn> plars: is there a bug with these details ? (note...not complaining..i know its fresh)
[16:12] <plars> kgunn: not yet, this is just the first time trying to get it running with a preview of what should be in the next image
[16:13] <kgunn> plars: ok...i
[16:13] <kgunn> am going to alert the team on it
[16:14] <kgunn> might want to join #ubuntu-mir to listen in
[16:14] <plars> doanac: oops :) missing a template file for it
[16:16] <plars> doanac: adding
[16:18] <plars> doanac: https://code.launchpad.net/~pwlars/ubuntu-test-cases/dropping-letters-template/+merge/189125
[16:20] <doanac> plars: good catch.
[16:20] <doanac> +1
[16:21] <plars> doanac: sorry I didn't spot that in the review
[16:21] <plars> doanac: it's all pushed and regenerated now though
[16:21] <doanac> plars: my original branch had it, but i rebased for the merge today and missed that
[16:26] <lool> livefs image build finished
[16:26] <lool> 79 imported!
[16:27] <lool> didrocks: download was much snappier this time around
[16:27] <lool> the download progress actually seems to slow down download here, maybe just an impression though
[16:27] <didrocks> lool: you still got the 100% first thing?
[16:28] <lool> didrocks: it was too fast to tell for sure, but it seemed so
[16:28] <lool> olli: Image up
[16:28] <lool> kgunn: ^
[16:28] <didrocks> well, there is still a glitch to fix
[16:28] <didrocks> \o/
[16:28] <didrocks> plars: it's all yours now :)
[16:28] <didrocks> jfunk: FYI ^
[16:29] <plars> didrocks: the tests are already running, and I'm installing locally to try the mir stuff again - just in case there's some difference
[16:30] <didrocks> plars: let's cross fingers ;)
[16:31] <lool> didrocks: are you sending the update email tonight?
[16:31] <lool> or should I?
[16:31] <didrocks> lool: already done :)
[16:33] <lool> cool, thanks
[16:33]  * lool lifts the lxc-android-config block
[16:34]  * jfunk reads
[16:34] <didrocks> yw!
[16:34] <robru> didrocks, hmmm, launchpad seems to be loading ok *now*, but it was definitely not working earlier this morning. not sure if it'll stay fixed or if it's going to be intermittently broken...
[16:34] <didrocks> robru: maybe you can try on a stack like the webcred one?
[16:35] <didrocks> it's a small one, the window of breakage is smaller ;)
[16:35] <didrocks> lool: wdyt? ^
[16:35] <cjwatson> there's no LP maintenance or anything happening, at least not that would affect page loading ...
[16:35] <lool> didrocks: hmm ok
[16:35] <lool> robru: yeah, +1 on webcred
[16:35] <robru> cjwatson, yeah, i guess it's an issue with my ISP.
[16:35] <robru> ok, i'll take webcred
[16:36] <lool> bfiller: heya
[16:36] <cjwatson> (we've been hammering the hell out of the buildds, mind)
[16:36] <lool> bfiller: so we have a quieter time until tomorrow morning while we wait for SDK fixes or Mir updates; a bunch of apps are staged, as well as phone stack packages; would you want us to try to land them?
[16:36] <lool> bfiller: waiting for your green to land stacks: apps, phone
[16:36] <robru> didrocks, lool: which line is webcred in the landing plan? I don't see it
[16:37] <lool> robru: adding it
[16:37] <lool> robru: done
[16:37] <dobey> fginther: any idea why bzr seems to constantly be having trouble in the jenkins amd64 builds?
[16:37] <lool> robru: near the bottom
[16:37] <robru> lool, thanks
[16:37] <bfiller> lool: yes landing apps would be good, let me just double check some of them and get back to you shortly
[16:38] <lool> bfiller: this is what's currently staged in PPA: http://people.canonical.com/~platform/cu2d/results
[16:38] <fginther> dobey, a fix/workaround has been deployed, can you point me to a log to make this isn't something new?
[16:40] <dobey> https://jenkins.qa.ubuntu.com/job/unity-scope-click-saucy-amd64-ci/61/console
[16:49] <fginther> dobey, thanks for the link, that issue is addressed by the chnage that was deployed about 2 hours ago
[16:50] <dobey> fginther: ok. can you re-run that failed attempt, if you haven't already? :)
[16:50] <fginther> doanac, sure
[16:54] <ev> sorry about that, guys!
[16:55] <ev> I'll make sure I'm either using the laptop in Bluefin (wfm today) or Firefox next time
[16:55]  * fginther -> food
[16:55] <dobey> thanks
[16:55] <ev> so yeah, the Oakland Client Sprint is a higher level discussion.
[16:56] <ev> I suspect Alex will be touching on that more next week when he returns
[16:56] <ev> but don't worry about booking flights with but a few weeks to go, or missing Halloween :)
[16:58] <lool> plars: hey
[16:58] <lool> plars: so there is some dbus fixing going on
[16:58] <lool> plars: it relates to dbus not picking up env vars, and also some connection refused errors
[16:58] <elopio> hey people. When is dpkg-dev installed on the jenkins phones?
[16:58] <lool> plars: I suspect it might be related to some issues we were seeing
[16:58] <lool> plars: you might want to try applying the fix locally to see if it helps
[16:59] <plars> lool: yes!
[16:59] <lool> elopio: it should be pulled by package dependencies surely
[16:59] <plars> lool: where can I find it?
[16:59] <lool> right now in unapproved
[16:59] <plars> lool: is this for the mir issues?
[16:59] <lool> plars: https://launchpad.net/ubuntu/saucy/+queue?queue_state=1&queue_text=dbus
[16:59] <lool> plars: *maybe*
[17:00] <lool> plars: I dont understand what autopilot does to stop/start unity8
[17:00] <lool> but because it's a race even in user sessions, it is worth trying
[17:00] <lool> initctl stop unity8 + initctl start unity8
[17:00] <bfiller> lool: go to go on that list for apps and OSK. e
[17:00] <lool> so that might just be racy with dbus
[17:01] <lool> bfiller: so apps stack?
[17:01] <lool> bfiller: what about phone stack?
[17:01] <bfiller> lool: apps stack and telephony stack (whatever has dialer, messagin, telephony-service, etc..)
[17:02] <bfiller> lool: which stack is OSK in?
[17:03] <lool> bfiller: ubuntu-keyboard is in services
[17:03] <lool> with content-hub
[17:03] <lool> that might be a bit much
[17:03] <bfiller> lool: up to you, OSK ready from my perspective
[17:03] <lool> bfiller: what's your risk assessment for apps / phone / services stack?
[17:04] <bfiller> low
[17:04] <bfiller> fixes a ton of bugs
[17:04] <bfiller> low risk of regression
[17:04] <lool> ok
[17:04]  * bfiller famous last words :)
[17:06] <lool> bfiller: I know where to find you!  ;-)
[17:07] <lool> I think I might build another image just to pick up dbus later today
[17:11] <lool> plars: https://launchpadlibrarian.net/152322007/dbus_1.6.12-0ubuntu5_1.6.12-0ubuntu6.diff.gz
[17:13] <plars> doanac: correct me if I'm wrong, but it looks like the unity8 tests are now trying to run from /home/phablet/autopilot? is that as a result of the click provisioning stuff?
[17:13] <robru> Mirv, sil2100: http://<IP_ADDRESS>:8080/job/cu2d-webcred-saucy-1.1prepare-libaccounts-glib/55/console i don't understand why this is yellow? it says there's a diff between trunk and ubuntu src, but i just checked it and there's no diff. they're identical.
[17:14] <doanac> plars checking
[17:16] <doanac> plars: we've been running with /home/phablet/autopilot in the PYTHONPATH since revno 20
[17:16] <plars> doanac: right, but now there's a unity8 directory there
[17:16] <doanac> ah, yes. that would override things
[17:17] <doanac> plars: shouldn't it be the same code though?
[17:17] <plars> lool: let me work around this so that I'm sure I'm running the right thing, and try it once again without the changes, then I'll take a look
[17:17] <plars> doanac: unless someone has landed something since then - right?
[17:18] <doanac> plars: no - phablet-click-setup is pinned to a version
[17:18] <plars> looking
[17:18] <plars> doanac: ah, ok
[17:19] <lool> /home/phablet/autopilot error was always there
[17:19] <plars> lool: yeah, it should be gone now
[17:19] <lool> got to go, will pop by later
[17:19] <lool> to test initrd update and dbus and roll an image with these
[17:25] <rsalveti> lool: pushing the seek fixes now
[17:25] <rsalveti> lool: will bump android, want me to hold for that? or did you get all your init changes in already?
[17:34] <sergiusens> doanac, plars you just made me think of a potential problem with testing autopilot packages, those are also pinned to a version and we may not actually have the correct unity installed; and given that, since it's a deb, it may install a newer version of unity than what's on the image
[17:36] <plars> sergiusens: you mean pull a newer branch than what's installed?
[17:36] <plars> sergiusens: it does (as doanac says) look like it's checking the version of unity8 before pulling
[17:36] <sergiusens> plars, just to avoid confusions, keep phablet-click-test-setup out of the picture
[17:36] <plars> sergiusens: well, it's there for now
[17:37] <plars> sergiusens: we just added it a bit ago
[17:37] <sergiusens> plars, image is built with unity8-v1 and unity8-autopilot (with depends on v1); while image is building; unity8v2 is published and hence a new unity8-autopilot lands
[17:38] <sergiusens> plars, so when you do image testing and grab unity8-autopilot you will pull in unity8v2 (when the image originally had unity8v1)
[17:38] <plars> sergiusens: but in phablet-click-test-setup it looks like fetch_test_base calls get_package_version
[17:38] <sergiusens> plars, that's what I meant with keep the click stuff out of the picture
[17:38] <plars> sergiusens: oh, we don't ever apt-get update
[17:39] <sergiusens> plars, not even to install utah?
[17:39] <plars> sergiusens: we don't install utah
[17:39] <sergiusens> plars, great
[17:40] <sergiusens> plars, well that being said, you can't use what's provided by phablet-click-test-run to test anything but click
[17:40] <plars> sergiusens: it'll try to use it for testing unity8, does that cause a problem?
[17:40] <plars> sergiusens: should be the save branch version as what's installed in the package right?
[17:40] <sergiusens> plars, the unity8 and ui-toolkit autopilot packages have deps that wold need to be installed
[17:40] <plars> ah, right
[17:41] <sergiusens> plars, yeah, the test code is good, but all the deps aren't (unity8-fake-mock, python-mock and one more I forget)
[17:41] <sergiusens> python-gi
[17:42] <plars> doanac: hmm, so it seems we either need to do special handling for the ui-toolkit and unity8 tests, or we could just install those deps as part of the setup
[17:45] <rsalveti> lool: pushing
[17:57] <balloons> are we happy with me pushing fixes for https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1234544 now?
[18:02] <plars> unity8 is hitting some cpu spike again - this time after the run: https://jenkins.qa.ubuntu.com/job/saucy-touch_ro-mako-smoke-camera-app-autopilot/120/artifact/clientlogs/top_after.log/*view*/
[18:04] <plars> and a couple of unity8 failures, which may be related to what sergiusens mentioned earlier... need to investigate
[18:24] <doanac> plars: just got back from lunch.
[18:25] <doanac> aren't we already install the unity8 deps?
[18:25] <doanac> ie: NO_UNLOCK=1 PKGS="unity8-autopilot" prepare-autopilot-test.sh
[18:25] <plars> doanac: oh right
[18:26] <plars> so it should be ok I think
[18:55] <doanac> plars: you know the IP of ashes?
[18:55] <doanac> or retoaded or rfowler ^^^ ?
[18:55] <retoaded> <IP_ADDRESS>
[18:56] <doanac> retoaded: hmm. didn't seem like jenkins was running. could you add me as a local user to that system?
[19:30] <kgunn> plars: when you test are you on nexus4 or galaxy nexus ?
[19:37] <plars> kgunn: I was testing on a nexus4, but I have both
[19:38] <kgunn> thomi: ^
[19:40] <thomi> ok, so maybe there's a bug somewhere relating to the AP MT device, mir, and the GN
[19:41] <thomi> the unholy trinity of devices, display server, and test tools
[19:41] <kgunn> plars: it'd be interesting if you could test on galaxynexus...but if your super busy i understand
[19:42] <plars> kgunn: I will, at some point today
[19:45] <kgunn> plars: thanks dude!
[19:58] <thomi> plars: got a second?
[19:58] <plars> thomi: what's up?
[19:59] <thomi> plars: for the unity8 test suite, I suspect that powerd may be blanking the screen mid-way through the tests. To prevent this, I wonder if we should be running 'sudo powerd-cli active'
[19:59] <thomi> which will block, and will prevent powerd from blanking the screen while it's running
[20:00] <thomi> so I guess you'd either want to do that in a separate shell, or save the PID or whatever
[20:00] <plars> thomi: we can take a look, but at what point is it becoming unactive long enough to blank? aren't there always touch events firing off during the run?
[20:01] <thomi> plars: I think that, because unity8 takes a long time to shut down & start up, that's where the issue lies
[20:02] <thomi> we'd only need it for that test suite
[20:02] <plars> thomi: but isn't that just at the very beginning? I think the 2 failures we're seeing are later
[20:03] <thomi> oh ok
[20:03] <thomi> well, something to think about anyway. I haven't seen the failures myself, just hearing about them second hand
[20:04] <plars> thomi: http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4539/unity8-autopilot/
[20:04] <plars> thomi: it's the indicator tests
[20:05] <thomi> plars: oh, that's now what was described to me at all - I think we're talking about two totally different things
[20:05] <alesage> thomi, plars, I think those are obsolete, no?
[20:06] <thomi> that looks to me like someone is passing an integer as a parameter to the launch method
[20:06] <thomi> alesage: not AFAIK
[20:06] <plars> alesage: those are on the current image
[20:06] <alesage> hmpf
[20:18] <rsalveti> was planning on triggering a new image build in a few, anyone waiting something to land for the next image today still?
[20:18] <lool> balloons: Pushing fixes to ui-toolkit >> you mean to PPA?
[20:18] <lool> rsalveti: catching up a bit
[20:18] <balloons> lool, yes
[20:18] <rsalveti> lool: ok, let me know when we're able to trigger a new image
[20:19] <lool> balloons: yes, fixes to PPA very welcome
[20:19] <lool> balloons: if you could give a heads up to Mirv with the things you're fixing, that would be awesome
[20:19] <lool> rsalveti: there's a click regression that alecu reported
[20:19] <lool> in #79
[20:20] <rsalveti> lool: right, any plans to get the fix in?
[20:20] <rsalveti> I mean, do we have the fix already? :-)
[20:21] <ralsina> rsalveti, lool: that's not really a regression once the server-side fix is in
[20:21] <ralsina> which should be in hours (right beuno?)
[20:21] <ralsina> ok, beuno is not here :-)
[20:21] <lool> ralsina: ok, then we're good
[20:21] <lool> ralsina: why is it specific to #79?
[20:21] <lool> because we dropped noauth?
[20:21] <ralsina> lool: exactly
[20:22] <ralsina> we are using another feature of the server
[20:22] <lool> oh ok, you had to pass noauth for free packages, if you're logged in it doesn't work?
[20:22] <lool> alright
[20:22] <ralsina> and we all tested it with our own accounts which worked
[20:22] <ralsina> so, fixing the manual testing also
[20:23] <lool> rsalveti: so before you build an image, could we boot test latest android?
[20:23] <lool> it has an initramfs script change
[20:23] <lool> and it has the dbus fix
[20:23] <lool> I wouldn't want to lock folks out
[20:25] <rsalveti> lool: sure, can test locally
[20:25] <kgunn> plars: new priority queue...can you test on Nexus4 AP install-and-boot, sdk, security, default, click_image_tests
[20:25] <kgunn> olli: ^
[20:28] <kgunn> plars: and obviously provide some report back
[20:28] <plars> kgunn: will do, I need to go pick my kids up from school though in just a moment
[20:29] <plars> kgunn: install-and-boot is done (obviously) and has nothing to do with mir
[20:29] <kgunn> sure... plars ...me too
[20:29] <lool> hmm unity8 suicided
[20:29] <plars> kgunn: click_image_tests just checks that the click packages that are expected to be installed are actually installed
[20:29] <lool> system-settings was running, and bam
[20:29] <olli> plars, just want to make sure that the remaining AP test that has issues is u8-autopilot
[20:29] <lool> black screen
[20:29] <plars> kgunn: actually none of those are ui related at all
[20:29] <plars> kgunn: so, the results on the dashboard should be no different than what we see under mir
[20:29] <lool> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >' what():  Could not unblank display
[20:30] <kgunn> plars: willing to back that up with a paycheck ? :)
[20:30] <plars> kgunn: none of the tests in the list you just gave me use autopilot
[20:31] <kgunn> plars: for sure...just want to be sure we no breakie something
[20:31] <plars> kgunn: another interesting thing I'm seeing is that when I try to reboot with mir enabled, it doesn't seem to succeed the first time
[20:32] <kgunn> plars: in /home/phablet/.cache/upstart/unity8.log does it make reference to unblanking...or not being able to get a display ??
[20:34] <lool> rsalveti: rebooting to test too
[20:35] <plars> kgunn: well, I was about to kick off camera and gallery, but I will make my way back to that
[20:35] <rsalveti> lool: did you build a new android image?
[20:35] <lool> rsalveti: no, intended to combine your .deb's initrd with my device's boot.img
[20:36] <kgunn> olli: ^
[20:36] <rsalveti> lool: right, that should be enough to test the initrd image
[20:36] <rsalveti> *changes
[20:36] <kgunn> just pointing out we're redirecting plars to those tests we discussed
[20:39] <plars> kgunn: camera_app tests all pass with mir + manual unlock
[20:40] <kgunn> \o/ plars ...
[20:41] <lool> rsalveti: hmm which one should I take, saucy-android-ramdisk+mako.img or saucy-ramdisk+mako.img?
[20:42] <rsalveti> saucy-ramdisk+mako.img probably, the other one should be from android
[20:43] <olli> lool, ^ fyi
[20:44] <rsalveti> lool: boots fine here
[20:44] <lool> rsalveti: cool, did you test with dbus?
[20:45] <rsalveti> lool: checking that bug now, see if it was really fixed
[20:46] <lool> rsalveti: I'm not sure how to easily reproduce, but I definitely got some url-dispatcher crash files here in the past with dbus connection refused
[20:46] <lool> rsalveti: I just want to make sure session opens correctly with it
[20:46] <plars> kgunn: one failure on gallery
[20:46] <plars> MismatchError: After 10.0 seconds test on TextEditOnClick.text failed: u'Photos' != dbus.String(u'My Photo Album', variant_level=1)
[20:47] <plars> kgunn: could just be a flaky test - will rerun
[20:47] <lool> plars: do you have the mir test results up on reports.qa?
[20:47] <plars> kgunn: but I *really* have to go get my kids now
[20:47] <plars> lool: no, still not possible to run with mir
[20:47] <rsalveti> lool: right, had those crashes before as well
[20:47] <rsalveti> checking now
[20:47] <plars> lool: you have to unlock by hand
[20:47] <lool> plars: do we understand what it entails to do it with Mir?
[20:47] <plars> lool: not yet
[20:48] <plars> lool: the unity tests and the unlock script both restart unity8 with -testability though, could be the common factor
[20:48] <plars> lool: I have to run, but will be back in a bit and on/off most of the evening
[20:49] <plars> kgunn: I'll let you know how the second run of the gallery tests went when I get back
[20:49] <lool> eh we have dbus-x11 on the image
[20:49] <lool> rsalveti: rebooting with latest dbus packages here
[20:49] <lool> plars: ok
[20:51] <rsalveti> lool: seems fine after reboot
[20:51] <sergiusens> lool, I just saw the same issue, ran system settings and it even eventyally took out adb
[20:52] <lool> rsalveti: works well here too
[20:52] <lool> rsalveti: I can kick an image now if you like
[20:52] <rsalveti> lool: whatever you prefer :-)
[20:52] <lool> doing it  :-)
[20:53] <lool> I actually wanted this dbus fix tonight
[20:53] <lool> and to test that initrd change (didn't plan the hybris one, that's bonus!)
[20:53] <lool> rsalveti: running
[20:53] <lool> rsalveti: ~42 minutes
[20:53] <lool> sergiusens: ah!
[20:54] <lool> sergiusens: are you on SF?
[20:54] <lool> I guess this might be due to the Mir changes regressing SF, not sure whether it's worth fixing
[20:54] <sergiusens> lool, mir
[20:54] <lool> sergiusens: ok, then the good news is that it's not SF/Mir specific
[20:54] <lool> and the bad news is that it's a serious bug
[20:54] <lool> sergiusens: did you get a crash file?
[20:55] <rsalveti> lool: great, thanks
[20:55] <sergiusens> lool, I actually have a bunch of crashes
[20:56] <sergiusens> lool, none for the settings though, let me reproduce
[20:56] <lool> sergiusens: check if unity8 crashed though
[20:57] <lool> sergiusens: I personally look at timestamps in /var/crash
[20:57] <lool> ls -ltr /var/crash
[20:57] <sergiusens> lool, it did, but I've been using this for a week and it's an old crash
[20:58] <lool> ah right
[20:58] <sergiusens> lool, http://paste.ubuntu.com/6189839/
[20:58] <sergiusens> lool, the crashes I see aren't that nice though :-)
[20:58] <sergiusens> lool, those get autouploaded, right?
[20:58] <lool> sergiusens: no
[20:59] <lool> you have to touch s/.crash/.upload/
[20:59] <lool> e.g. touch /var/crash/usr_lib_arm-linux-gnueabihf_hud_hud-service.32011.upload
[20:59] <lool> then eventually it will be
[20:59] <lool> sergiusens: all your recent ones are scary   :-(
[20:59] <sergiusens> lool, ex`actly :-)
[21:00] <lool> sergiusens: we've just updated hud, we've just updated url-dispatcher
[21:00]  * sergiusens curses keyboa`rd
[21:01] <cwayne> sergiusens, i don't suppose we've bundled a bunch of fixes together recently have we? :)
[21:04] <balloons> fginther, re:ubuntu-app-devel thread.  I know it's late in the day and we're all scrambling, but I don't want our conversation to get lost. Do we need to bring it up with some more folks?
[21:08] <fginther> balloons, thinking about who to engage...
[21:12] <lool> sergiusens: what are the steps to trigger the crash when settings is running?
[21:12] <lool> I tried turning the screen off, and it dind't work
[21:14] <sergiusens> lool, go to the background settings
[21:15] <sergiusens> cwayne, I want to include two of doanac's MRs in there as well
[21:16] <fginther> balloons, let pick it up tomorrow morning
[21:17] <balloons> fginther, I'll send a mail to say you zoltan and asac?
[21:17] <balloons> else I will forget
[21:17] <balloons> :-)
[21:18] <fginther> balloons, sure
[21:19] <cwayne> sergiusens, makes sense, any ETA on it?
[21:20] <lool> thomi: are you looking at the autopilot changes to do the powerd dance and the unlocking on mir?  :-)
[21:22] <thomi> lool: no, plars seemed to indicate that it wasn't a problem. Besides, you can only use powerd-cli as root, so I think (for now, anyway) this is something that needs to happen on the CI side
[21:22] <sergiusens> lool, if you do that, you get terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
[21:22] <sergiusens> lool, I think seb128 knows about this though
[21:23] <lool> seb128: ^ is this something you ou know of?
[21:23] <lool> sergiusens: I tried the PPA version too, but unity8 crashed instead
[21:23] <thomi> lool: then again, if you can think of a solution, I'm happy to write the code :)
[21:23] <lool> thomi: what do you mean on the CI side?
[21:23] <lool> in the tests?
[21:23] <thomi> lool: No, I mean as part of the environment setup you guys could run 'powerd-cli active' as root
[21:24] <seb128> lool, sergiusens: knowing about what?
[21:24] <thomi> which prevents the screen from blanking while that command is running
[21:24] <lool> seb128: crash when opening background pane in settings
[21:24] <sergiusens> seb128, background changes with mir enabled
[21:24] <lool> thomi: do you know where the piece of code to unlock the screen lives?
[21:24] <lool> is that utah?
[21:25] <lool> thomi: and are there other AP issues that you know of on Mir outside of the unlock thing?
[21:25] <thomi> lool: there's this: https://bugs.launchpad.net/mir/+bug/1234956
[21:25] <thomi> lool: which means maguro runs will break right now
[21:25] <thomi> actually, plars should know about that
[21:26] <thomi> plars: probably no point doing your maguro test runs for kgunn, since we know it's not going to work
[21:28] <lool> thomi: thanks
[21:30] <seb128> lool, sergiusens: https://bugs.launchpad.net/bugs/1234733
[21:30] <seb128> lool, sergiusens: that seems like a toolkit/mir issue, e.g the image crossfading from the toolkit is making mir segfaulting
[21:30] <lool> seb128: yeah, that's what I was thinking too
[21:30] <sergiusens> seb128, seems it's a mir bug
[21:31] <lool> it could be the qtdeclarative update
[21:31] <lool> sergiusens: I get it on SF
[21:31] <sergiusens> lool, oh :-/
[21:31] <sergiusens> lool, what qtdeclarative update?
[21:31] <lool> rsalveti: image up
[21:31] <sergiusens> seb128, on the plus side, after rebooting I get my chosen wallpaper :-)
[21:32] <rsalveti> lool: great, thanks
[21:32] <seb128> sergiusens, ;-)
[21:32] <lool> seb128: http://people.canonical.com/~ogra/touch-image-stats/20131003.1.changes
[21:33] <seb128> sergiusens, ^
[21:33] <lool> seb128, sergiusens: I dont even get to chose
[21:33] <lool> just loading the background pane and it crashes here
[21:33] <seb128> lool, that's what the bug I pointed out describe
[21:34] <seb128> lool, the preview widget in the setting apps do the crossfading, I guess that's what mir doesn't like
[21:34] <seb128> lool, can you try the testcase from ken on the bug?
[21:35] <sergiusens> seb128, I'll give it a shot
[21:36] <lool> GRR
[21:36] <lool> why is the new ui-toolkit in the image
[21:44] <sergiusens> lool, seb128 this is what I get http://paste.ubuntu.com/6189974/
[21:44] <sergiusens> no crash
[21:46] <plars> thomi: ack
[21:48] <lool> seb128, sergiusens: The thing is that this ubuntu-ui-toolkit should NOT be in archive and hence in image
[21:48] <lool> it had regressions
[21:48] <lool> and it's likely causing these
[21:48] <seb128> :-(
[21:49] <lool> but it looks like a zombie job pushed it, I can't figure what has possibly uploaded it
[21:49] <seb128> lool, that manual workflow doesn't work, we should just use the normal proposed/blocks/review as the release team is doing for other flavors
[21:50] <lool> yes, I was about to add a block for this package
[21:51] <kgunn> plars: it would be super useful if you could document your testing findings here https://docs.google.com/a/canonical.com/document/d/1b-X9tN2Q9c_5r39XzA-Ppebbjuin5zVf9SkAGMcdp9Q/edit#
[21:51] <kgunn> its from the qa team...and i think your seeing results much better with the manual intervention
[21:53]  * sergiusens will avoid more opinions on the current process
[22:00] <plars> kgunn: I'll take a look with this image that just came out later tonight when I get back
[22:01] <plars> kgunn: until then, the automated tests are running (with surfaceflinger)
[22:01] <plars> kgunn: is anyone looking at the difference in responsiveness of mir vs. surfaceflinger?
[22:02] <lool> plars: hey
[22:02] <kgunn> plars: wrt responsiveness....we'd need data
[22:02] <plars> lool: hi
[22:03] <lool> plars: could we sync on the current Mir status
[22:03] <kgunn> plars: wrt testing... olli was really wanting us to have a (manually produced if required) aggregate view of all the data from what we would normally run on SF...but run no mir
[22:03] <plars> kgunn: I don't have hard data, just observation from manually unlocking the screen. Is there any way to rig a framerate counter or something?
[22:03] <olli> no/on
[22:03] <lool> plars: both on the status of running the Mir tests and the actual number of tests passing
[22:04] <lool> plars: also, where is the piece of code unlocking the screen that we need to fix?  :-)
[22:04] <plars> lool: I have to take my son to something in just a few min. but the basic status is that we can only run tests manually for right now because unlocking the screen doesn't seem to work with mir using the methods we used before
[22:04] <plars> lool: one sec
[22:05] <plars> lool: http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/files/head:/utils/target/ (see the unlock_screen stuff there)
[22:05] <lool> ok thanks
[22:10] <lool> thomi: so in lp:~ubuntu-test-case-dev/ubuntu-test-cases/touch there's the piece currently unlocking the screen under utils/target/unlock_screen.py; it's usingthe autopilot input.Touch stuff to unlock; would you know what breaks it on mako?
[22:10] <lool> with Mir
[22:12] <thomi> lool: should work fine with mir
[22:12] <thomi> on mako
[22:17] <lool> plars: are you testing on mako or maguro?
[22:17] <plars> lool: usually mako, but I have both
[22:18] <plars> lool: I really have to run now, will be back later
[22:18] <lool> see you
[22:21] <thomi> plars: just to clarify our earlier conversation regarding powerd-cli - that's reuired for mir, since, under mir, unity8 will nto start when the screen is blanked
[22:21] <thomi> plars: I realise I left that critical piece of information out of my earlier message
[22:21] <lool> ah
[22:22] <thomi> so yeah - if we see lots of failures trying to start the unity8 shell, you guys might want to shoehorn that powerd-cli command in somewhere
[22:30] <lool> thomi: I keep trying to start/stop unity8, it never comes up
[22:30] <lool> I'm holding a powerd-cli lock
[22:31] <lool> I do get a crash file though
[22:32] <thomi> lool: do you have  a stale /tmp/mir_socket?
[22:32] <thomi> lool: also, what does ~/.cache/upstart/unity8 say?
[22:32] <lool> thomi: how can I tell?
[22:33] <thomi> lool: with unity8 stopped, does that file exist?
[22:33] <lool> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >' what():  bind: Address already in use
[22:33] <thomi> lool: yeah, so check that unity8 isn't already running somewhere
[22:34] <thomi> and if it's not, rm /tmp/mir_socket
[22:34] <lool> that helped a bit
[22:34] <lool> start isn't stuck anymore
[22:34] <lool> but it's not starting either
[22:34] <thomi> lool: it takes a while
[22:35] <thomi> tail -f ~/.cache/upstart/unity8.log
[22:35] <lool> hmm perhaps I'm not patient enough
[22:35] <lool> it's indeed starting
[22:35] <lool> cool
[22:35] <lool> turning a11y on again
[22:36] <lool> starting again with a11y
[22:36] <lool> indeed, it started
[22:36] <thomi>  \o/
[22:36] <lool> now trying unlock
[22:37] <lool> and that worked too
[22:37] <lool> ok
[22:37] <lool> so a) add powerd-cli active,  b) rm mir_socket if it's stuck
[22:39] <lool> thomi: do you know about the bug id for unity8 not coping with screen blanking?
[22:40] <thomi> lool: no, sorry
[22:48] <lool> thomi: https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1235000
[22:48] <lool> kgunn: ^
[22:56] <thomi> hey guys - I've tracked down the mi-on-maguro problem
[22:57] <thomi> and the root of it is that "getprop ro.hardware" returns "tuna"
[22:57] <thomi> when it should return "maguro"
[22:57] <thomi> any ideas?
[23:00] <thomi> seems like it should be using ro.product.device
[23:06] <sergiusens> thomi, that is correct, you want to use what phablet-tools uses
[23:07] <sergiusens> thomi, ro.product.device
[23:07] <sergiusens> thomi, ah, didn't read the whole thing
[23:08] <sergiusens> thomi, also used across the system
[23:08] <lool> thomi, plars, doanac: https://code.launchpad.net/~lool/ubuntu-test-cases/powerd-lock/+merge/189191
[23:10] <thomi> sergiusens: cool - thanks
[23:10] <lool> doanac, plars: Going to bed now, but if you could test this patch and try to run AP tests with it on Mir, that would be great