[05:01] <Mirv> ok, addition to landing plan required it seems
[07:05] <Mirv> vila: hi. I'd have some autopilot errors for you - http://10.97.0.1:8080/job/autopilot-trusty-daily_release/label=autopilot-nvidia/476/console (eventually aborted by me) + http://10.97.0.1:8080/job/autopilot-trusty-daily_release/label=qa-intel-4000/476/console (a crash)
[07:06] <thomi> Mirv: the first one looks like unity hung or crashed to me
[07:09] <vila> Mirv: huh ? Not there yet nor fully awake but I think thomi knows better about autopilot ;)
[07:10] <thomi> those dbus timeout errors usually indicate that either the app under test crashed, or hung for a long time
[07:10] <thomi> or, i gues there's a bug in the dbus handling code inside unity
[07:11] <Mirv> thomi: vila: could you maybe grab .crash files and report them? the intel one has a clear segfault too.
[07:11] <vila> then may be autopilot shouldn't wait so long before declaring that the test has failed, the log hints that this was going on for like an hour before Mirv aborted it
[07:12] <Mirv> vila: yeah, those long hanging failures are one problem that would be nice to get resolved
[07:13] <Mirv> all in all I suspect unity7 is still a hard thing to trustworthily test, that's why I'm pointing these out.
[07:13] <thomi> vila: so the timeout is set by the dbus module - I may be able to change it, I'm not sure
[07:13] <thomi> an hour does seem excessive though
[08:30] <vila> Mirv: not a single maguro offline ? Is it because a trick was found to cure the flashing or is it only because less jobs were run ?
[08:30] <Mirv> vila: "I don't know what you're talking about" :)
[08:31] <Mirv> vila: I mean, I don't know about any of the phones in the lab, flashing or such
[08:32] <vila> Mirv: oh right, they are the ones used by upstream-merger
[08:34] <Mirv> vila: is there a doc about the phone setup/flashing etc? not that I'd already feel quite overloaded by information from different teams, but if I'd then learn some summary.
[08:34]  * Mirv the Desktop/SDK/CI/QA teamer
[08:34] <sil2100> ;)
[08:35] <didrocks> hey sil2100, Mirv!
[08:35] <sil2100> Morning didrocks !
[08:35] <didrocks> how are you?
[08:35] <Mirv> hey didrocks. I've been testing (and now publishing) libunity today, since robru's unity was blocked by it requiring that too. now hopefully we're really ready.
[08:36] <didrocks> Mirv: great! so autopilot will move to trusty and we can kick an image build?
[08:36] <sil2100> Mirv: libunity in release \o/
[08:37] <Mirv> didrocks: I'm holding my breath about that. let's see in a couple of minutes, but I've libxpathselect1.3 removed on my desktop successfully.
[08:37] <didrocks> ok :)
[08:37] <didrocks> sil2100:
[08:37] <didrocks> Chris Lee has a branch in the works that fix the ubuntu keyboard tests.
[08:37] <didrocks> Chris Gagnon has a branch that fixes the webbrowser-app.
[08:37] <didrocks> thomi posted that ^
[08:37] <didrocks> sil2100: did you already handled those or are they new branches?
[08:38] <Mirv> didrocks: I merged Chris' webbrowser AP1.4 fix and released it yesterday
[08:38] <sil2100> didrocks: about ubuntu-keyboard I know, as I got an e-mail about that, at least the keyboard one is relatively new to me as I got an e-mail about it 15 minutes ago
[08:39] <sil2100> Although the OSK branch is still 'work in progress'
[08:39] <sil2100> So nothing we can do here until work is finished I guess
[08:45] <Mirv> didrocks: arm64 unity build failing (complains about xpathselect not being available while it should be) may be blocking the transition now
[08:45] <sil2100> Mirv: a quick question since you might have already looked into this:
[08:46] <sil2100> Mirv: exactly what I wanted to ask about ;)
[08:46] <Mirv> sil2100: haha :)
[08:46] <sil2100> Mirv: since I just saw the arm64 build failure in the archive, strange
[08:46] <Mirv> xpathselect also for arm64 was compiled 21h ago, so it does not immediately make sense why 7h ago arm64 didn't have it available for unity building
[08:47] <sil2100> Right, it doesn't fit the 'time race' bug we had in the past with LP... but
[08:47] <sil2100> This doesn't necessarily mean that xpathselect is not available
[08:48] <sil2100> This usually means that some of libxpathselect's dependencies is not available for arm64
[08:48] <vila> Mirv: not, no doc that I know of, but various solutions are being investigated right now. I just didn't get any feedback about what happened during my night.
[08:48] <sil2100> So let's maybe check the deps of xpathselect and try to backtrack which package failed for arm64
[08:48] <sil2100> Mirv: ^
[08:49] <vila> Mirv: the summary so far is: more flashing means more failures. Either we find the root cause of the failures or we need to do less flashing (and there are ways to get pristine images on the phone without involving adb)
[08:50] <sil2100> Mirv: not too many deps I see sadly...
[08:50] <Mirv> sil2100: basically just libc etc
[08:52] <didrocks> Mirv: hum, I wonder why ken didn't follow the transition as planned :/
[08:53] <didrocks> yeah out of date on arm64: libunity-core-6.0-8, libunity-core-6.0-dev, unity, unity-services (from 7.1.2+13.10.20131014.1-0ubuntu1)
[08:53] <sil2100> didrocks: yes, since the arm64 build of unity in the archive failed
[08:54] <sil2100> didrocks: but we can't seem to find the reason, it cannot install libxpathselect1.4, but it's built and all it's dependencies are built as well
[08:54] <Mirv> didrocks: he didn't notice that unity while being the last piece of the chain also required libunity
[08:54] <didrocks> we can try rebuilding
[08:54] <didrocks> Mirv: what is requiring libunity btw?
[08:55] <Mirv> didrocks: unity itself has dependency on the newer version of libunity
[08:55] <didrocks> ah ok
[08:55] <Mirv> didrocks: rebuilding should be quick to try at least
[08:55] <didrocks> Mirv: I'm sad that nobody followed the migration before you woke up :/
[08:56] <didrocks> (build starting)
[08:56] <didrocks> and failed
[08:56] <sil2100> Ken had it all planned out, but from his analysis it seemed that the last missing piece was unity-autopilot
[08:56] <didrocks> I think someone would need to chdist
[08:56] <sil2100> I guess he didn't consider unity's deps here
[08:57] <didrocks> sil2100: yeah, but he was supposed to look at the transition to archive as well
[08:57] <didrocks> anyway
[08:57] <didrocks> so, anyone interested in chdisting?
[08:57]  * sil2100 googles up
[08:58] <Mirv> didrocks: I tried creating arm64 chroot but then with my skills ended up with qemu lacking arm64 support
[08:58] <Mirv> chdist, interesting
[08:58] <sil2100> Ah, I see it now, nice tool ;)
[09:01] <didrocks> Mirv: yeah, it's better to debug with it :)
[09:02]  * infinity fixes.
[09:02] <didrocks> infinity: what are you fixing? (the wrong dep?)
[09:03] <infinity> The deps are fine.
[09:03] <infinity> But libxpathselect1.4 was NEW and landed in universe.
[09:03] <Mirv> didrocks: weird, it gets them fine for arm64 using chdist
[09:03] <infinity> Promoted now.
[09:03] <Mirv> ah
[09:03] <didrocks> infinity: oh, ok, making sense. Thanks
[09:03] <sil2100> Ah
[09:03] <sil2100> \o/
[09:04] <Mirv> that's btw one of the things that would benefit from more verbose error output one way or another, ie the barrier between main and universe coming into play
[09:04] <didrocks> Mirv: well, universe isn't even known by the builder when building a main package
[09:04] <infinity> I can't really be more verbose about a package being unavailable to apt cause it, well, doesn't exist from my POV.
[09:05] <Mirv> didrocks: yep, so a check by builder to see if the missing piece would be available in universe
[09:05] <Mirv> but would be quite hackish to grep from the apt output and then check
[09:06] <infinity> Anyhow, in this cause, it's fundamentally a bug in how copies are done.
[09:06] <infinity> binary NEW for sources in main should default to main, but it doesn't for copies.
[09:06] <infinity> We'll fix it.  Just not today.
[09:07] <infinity> I'll retry that unity build after the next publisher run sort this out.
[09:07] <cjwatson> And the reason only arm64 failed is that it's the only one that builds in the primary archive - the others built in the PPA.
[09:07] <Mirv> thanks infinity
[09:07] <cjwatson> Once we have more reliable builder hardware we should be able to fix that.
[09:09] <infinity> The machine I'm testing right now is behaving well, so far.
[09:31] <sil2100> didrocks: coming, jus tneed to 're sign-in' ;/
[09:31] <didrocks> sil2100: ok
[09:31] <didrocks> ogra_: ?
[09:38] <popey> top - 09:38:39 up 2 days, 23:30,  1 user,  load average: 2.17, 3.49, 6.91
[09:38] <popey>  2066 phablet   20   0 1421716 1.092g    980 R  99.8 59.7 112:58.44 init
[09:38] <popey> "lol" upstart ☻
[09:41] <Mirv> arr, "The bug is not reproducible, so it is likely a hardware or OS problem." (unity arm64)
[09:41] <Mirv> infinity: ^
[09:42] <infinity> Mirv: Oh, meh.  I'll toss it at a better builder. :)
[09:42] <Mirv> ok :)
[09:42] <infinity> Done.
[09:42] <infinity> Hopefully, all our builders will be of the "better" variety in a month or three but, for now, it takes some babysitting.
[09:43] <infinity> I do keep an eye out (and I'm not alone in that).
[10:22]  * Mirv notes that autopilot transition just happened, maybe 5-10min until rmadison will be happy
[10:22] <Mirv> ogra_: ^
[10:24] <sil2100> \o/
[10:24] <sil2100> \o\
[10:24] <sil2100> /o/
[10:25] <Mirv> I checked unity autopilot ubuntu-ui-toolkit unity8 webbrowser-app gallery-app ubuntu-keyboard etc, all seem to be happening so all good
[10:25] <Mirv> ..after rmadison agrees, of course
[10:31]  * didrocks can't wait!
[10:38] <Mirv> interesting that amd64 is still not there, while other archs are (for unity for example)
[10:39] <ogra_> Mirv, watching it
[10:40] <cjwatson> Mirv: Looks like incorrect caching in madison-lite; I cleared it and it shows amd64 up-to-date now
[10:40]  * didrocks sees ogra_ has his hand on the image build trigger, ready as soon as rmadison answers
[10:40] <didrocks> :)
[10:40] <ogra_> for some value of "hand on" :)
[10:40] <Mirv> ogra_: rmadison agrees
[10:41]  * ogra_ has the chimney sweep in the house inspecting all heatings ... 
[10:42] <ogra_> ok, lets go then :)
[10:42]  * ogra_ pulls the trigger
[10:42] <ogra_> [10:42] <didrocks> \o/
[10:42] <didrocks> psivaa: the two "spoiling app tests" are disabled?
[10:43] <psivaa> didrocks: yes, they are :)
[10:43] <psivaa> will kick them off  once the others complete as expected
[10:44] <didrocks> excited!
[10:58] <Mirv> sil2100: was there a reason not to release mediaplayer-app btw, or just omitted? marked as DONE, but not PUBLISHED.
[10:58] <Mirv> (or is it click?)
[10:59] <sil2100> Mirv: no change was necessary
[10:59] <sil2100> Mirv: so no release was needed, the version in archive was OK, so I just put 'DONE'
[10:59] <Mirv> sil2100: ok, makes sense
[11:01] <Mirv> right, and it's mentioned in the pad too.
[11:01] <Mirv> ok, I can't find anything missing aside from known ones
[11:15]  * ogra_ wonders why rhis build takes so long
[11:16] <ogra_> well, seems to still run at least
[11:16] <didrocks> ogra_: because it's a good build, good thing takes time
[11:16] <ogra_> heh
[11:21] <ogra_> ah, finally, cdimage is done ...
[11:22] <popey> unfortuinately the crap things take time too ☻
[11:22] <ogra_> another 10-15min for system image now
[11:22] <didrocks> popey: tssss :p
[11:23] <dandrader> hi. does anybody know when are we going to get a new release of qtubuntu (or what's stopping CI machinery from doing one)
[11:35] <didrocks> dandrader: hey, basically the autopilot 1.4 transition (see the ubuntu-phone ML)
[11:36] <dandrader> ok, thanks
[11:43] <ogra_> [11:47]  * didrocks hopes to get good test results from psivaa :)
[11:48] <ogra_> bribe him properly and you might :)
[11:48] <psivaa> :)
[11:48]  * popey updates to 14
[11:50] <davmor2> I'm on 14 now lets see what breaks
[12:01]  * asac hopes for a good #14
[12:02]  * Mirv haz 14
[12:05] <Saviq> didrocks, we need to wait for #14 results to merge? #13 results are not good enough?
[12:07] <didrocks> Saviq: #13 don't contain AP 1.4 results
[12:08] <Saviq> didrocks, ok :|
[12:08] <didrocks> Saviq: I want AP 1.4 results and ensure you are 100% green on your component
[12:08] <didrocks> see mail on the phone ML
[12:08] <Saviq> didrocks, yeah I did, didn't know #13 didn't have ap 1.4
[12:08] <Saviq> or didn't understand at least
[12:08] <didrocks> Saviq: then, you can get your feedback to the QA team, that's why backward compatibility is needed to not block everything :)
[12:13] <psivaa> early signs of success with image 14
[12:14] <didrocks> phew!
[12:14] <didrocks> psivaa: for the 2 remaining tests, we may have a new indicator-network to install first
[12:15] <didrocks> which should fix the system settle idling
[12:15] <psivaa> didrocks: ack, do we already have that pkg?
[12:15] <didrocks> psivaa: not yet, coming from sil2100 once it's merged (under merge now)
[12:16] <psivaa> didrocks: ack
[12:30] <sil2100> didrocks: indicator-network change merged in \o/ Let me spin cu2d for that
[12:30] <didrocks> sil2100: wooow!
[12:32] <popey> on #14, webapps seem to take a very long time to load - more than 10 seconds
[13:23] <Saviq> didrocks, http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/14:20131107:20131031.1/4933/unity8-autopilot/ can we can we can we? ;D
[13:25] <sil2100> ;)
[13:26] <sil2100> popey: can you upgrade indicator-network to the one in daily-build and check if you can reproduce the non-idle bug?
[13:29] <popey> ok
[13:29] <popey> whats the ppa path?
[13:31] <lool> I guess ppa:ubuntu-unity/daily-build
[13:38] <Mirv> that, yes
[13:48] <fginther> morning
[13:56] <sil2100> Morning!
[13:57] <didrocks> Saviq: 100%, yes, please, go on! :)
[13:57] <didrocks> Saviq: don't break things :p
[13:57] <Saviq> shite
[13:58] <Saviq> ;P
[13:58] <didrocks> ;)
[14:00] <popey> lool: thanks, sorry, on a hangout
[14:01] <didrocks> psivaa: tests are progressing as excepted?
[14:01] <didrocks> (results looks good, but not so many of them)
[14:02] <psivaa> didrocks: yea the dash synch has added delays between 1300 and 1400 UTC
[14:02] <psivaa> will be more results at 1410
[14:02] <didrocks> great ;)
[14:02] <psivaa> :)
[14:06] <didrocks> sil2100: you can test yourself. I tested it anyway (see bug report)
[14:06] <didrocks> you can do it without SIM
[14:13] <psivaa> calendar app tests appear to regress with image 14, need to rerun after the full set gets completed
[14:17] <sil2100> didrocks: can I publish both indicator-network and ubuntu-keyboard if all is ok?
[14:18] <popey> sil2100: sorry, long hangout, do you still need me to test indicator-network?
[14:18] <sil2100> popey: no no, I actually put in a SIM card and tested it myself - then I learned from didrocks that a SIM-card wasn't even needed
[14:18] <popey> ah okay
[14:19] <sil2100> Should have read the description
[14:19] <sil2100> But you can test to make double-sure
[14:19] <popey> ok, will do now
[14:21] <sil2100> psivaa: do you want to test this package from the PPA now somehow or can I publish it to the archives?
[14:22] <sil2100> psivaa: the indicator-network one
[14:22] <didrocks> sil2100: please do!
[14:22] <psivaa> sil2100: the devices are still running the other tests, so may not be able to test right now
[14:23] <sil2100> psivaa, didrocks: ok, in the meantime then I'm publishing those two
[14:24] <popey> even with that new indicator-network, I still see it pop up to the top of top after stop/start of ofono
[14:24] <popey> not for long, not as intense
[14:27] <didrocks> popey: did you reboot after installing?
[14:28] <sil2100> popey: I tested it and didn't see it jump higher than 7%
[14:29] <popey> didrocks: ya
[14:29] <popey> twice, really low cpu usage
[14:29] <sil2100> popey: is 0.5.1+14.04.20131107-0ubuntu1 installed?
[14:29] <popey> so seems fixed
[14:29] <popey> i updated from that ppa
[14:31] <didrocks> greatness!
[14:36] <didrocks> sil2100: once in the archive, can we kick another image build with webbrowser-app and indicator-network?
[14:48] <sil2100> didrocks: yes, I'll poke ogra_ once all is in
[14:48] <didrocks> sil2100: thx!
[14:48] <ogra_> ++
[14:58] <didrocks> psivaa: all tests run?
[14:59] <didrocks> psivaa: I mean, only the 2 disabled for mako?
[14:59] <psivaa> didrocks: no, sdk and security are bing run and yes only them two are disabled in mako and maguro
[15:00] <didrocks> psivaa: ah, system idling on mako, indeed
[15:02] <psivaa> didrocks: there are yet, eventstat, memevent, smem tests that need to complete before i could kick off the messaging and dialer tests
[15:02] <didrocks> ok ;)
[15:02] <didrocks> psivaa: think about upgrading indicator-network before kick off messaging and dialer
[15:02] <cjwatson> cihelp: IIRC ev told us not to trigger rebuilds of things, but instead to mention them here so that the reasons could be investigated.  Could somebody see why https://code.launchpad.net/~cjwatson/ubuntu-keyboard/python-any/+merge/194310 hasn't been approved by ps-jenkins even though I set a commit message immediately after receiving its initial failure mail?
[15:02] <didrocks> let's hope we can get the result in ~1h, then, I'll send an email
[15:03] <psivaa> didrocks: ack, will do
[15:03] <didrocks> thanks!
[15:03] <fginther> cjwatson, looking
[15:03] <cjwatson> (ps-jenkins' message "if you want a jenkins rebuild you need to trigger it yourself" is now conflicting with what ev said at the client sprint, so ...)
[15:05] <fginther> cjwatson, jenkins already tested this revision, it's not going to automatically test it again. But it did leave the status as needs review due to the missing commit message.
[15:05] <cjwatson> Indeed.  What should I do?
[15:06] <fginther> cjohnston, the tests pass, you don't need a specific approval from jenkins to approve the MP
[15:06] <fginther> errr cjwatson  ^.  Just approve the MP if it's ready to go
[15:06] <cjwatson> OK, well I can't since I'm not in that project's owning team, but maybe I can track down Thomas
[15:07] <fginther> cjwatson, I can approve
[15:07] <cjwatson> I asked tmoenicke on #ubuntu-touch
[15:07] <fginther> ack
[15:08] <cjwatson> But if you're doing it I don't mind either :)
[15:08] <cjwatson> Thanks
[15:10] <kenvandine> so happy to see the trusty settings stack now does CI builds on armhf... so much easier to download debs to test during reviews :)
[15:11] <seb128> kenvandine, couldn't you get the debs from the ppa before?
[15:11] <kenvandine> no
[15:12] <kenvandine> not until after it was merged
[15:12] <seb128> why not?
[15:12] <seb128> oh, right
[15:12] <kenvandine> now you can download the artifacts and extract the debs
[15:12] <seb128> nice ;-)
[15:12]  * kenvandine is reviewing those big changes to ubuntu-system-settings-online-accounts
[15:35] <sil2100> ogra_: still waiting for webbrowser-app to pop up in the archive
[15:35] <sil2100> ogra_: will have to AFK for some time in a moment though...
[15:36] <ogra_> sil2100, i'll just start a build before the meeting starts
[15:39] <psivaa> plars: i had messaging and dialer jobs disabled since they were creating noise in systemsettle. will need to restart them now. are you planning to run any more tests before that
[15:39] <psivaa> ?
[15:40] <plars> psivaa: I just rekicked one on mako
[15:40] <plars> psivaa: filemanager - it might be done though
[15:40] <psivaa> plars: yea saw that, after that i mean
[15:40] <ogra_> filemanager looks pretty hopeless
[15:40] <plars> psivaa: yeah, should be done soon
[15:40] <plars> ogra_: yeah, it's flaky at the moment, I was trying to see if it would bounce back to fewer failures though
[15:41] <psivaa> plars: ack. i'll take a look at filemanager once dialer and messaging is done. probably due to fake home is not yet being available
[15:42] <plars> psivaa: it just finished - go for it
[15:42] <psivaa> plars: thanks :)
[15:59] <psivaa> didrocks: so dialer and messaging tests are running with updated indicator-network. so far so good
[16:01] <didrocks> psivaa: great!
[16:06] <didrocks> psivaa: do you know what's not shown in the dashboard and we have test results for?
[16:06] <didrocks> psivaa: I want to flush out that email now with the exact list if possible :)
[16:06] <psivaa> didrocks: terminal is missing
[16:06] <psivaa> i mean in mako, there are 8 tests missing..
[16:06] <didrocks> psivaa: ok, already on the list of not passing :)
[16:07] <didrocks> psivaa: anything else non green missing?
[16:08] <psivaa> didrocks: no
[16:08] <psivaa> didrocks: dialer and messaging are passing and they are those that are missing as of now from dashboard
[16:09] <didrocks> psivaa: perfect, so we have the whole list :)
[16:09] <psivaa> didrocks: yes
[16:09] <didrocks> excellent! psivaa: I'll list you as a helper for tomorrow if people have questions/thinks it's because of the infra. Ok?
[16:09] <didrocks> plars: you as well ^
[16:09] <psivaa> didrocks: ack
[16:10] <plars> sounds good
[16:11] <plars> didrocks: btw, I have a doctor appointment shortly, so I probably won't be a the standup today
[16:12] <didrocks> psivaa: plars: ok, the idea for tomorrow (as I won't be there) is: "let's go back to green"
[16:12] <ogra_> plars, i want to introduce a bootchart generation test into utah, can we sit down tomorrow and take a look where that fits best ?
[16:12] <didrocks> so asking to not merge anything that's not in that direction
[16:12] <ogra_> didrocks, but *everything* is in that direction :P
[16:13] <ogra_> (if you ask devs)
[16:13] <didrocks> ogra_: ahah, sure sure sure :)
[16:13] <plars> ogra_: sure, whenever you like
[16:13] <didrocks> ogra_: can I get some sugar with my coffee?
[16:23] <ogra_> [16:24] <ogra_> (webbbrowser-app is in)
[16:40] <elopio> didrocks: I don't understand why all the MPs I propose to the weather app say all the tests are passing, but on the dashboard there are three failing consistently.
[16:40] <elopio> cihelp, how can I have the same set of tests blocking the weather app merge proposals ?
[16:40] <didrocks> plars: can you help diagnosis that with elopio?
[16:40] <didrocks> elopio: as it's consistent, it's a real issue, indeed :)
[16:41] <doanac> elopio: i'll take a loop
[16:41]  * ogra_ watches doanac run in circles
[16:42] <didrocks> :)
[16:43] <elopio> :)
[16:44] <elopio> doanac: thanks. It will be easier to fix them if no more code is allowed to merge.
[16:44] <doanac> elopio: one potential difference. we run weather app as click-package in image testing.
[16:44] <doanac> not sure it does that when you do merges?
[16:45] <fginther> doanac, elopio, for merges, it uses debian package on an x86 desktop
[16:45] <didrocks> elopio: on bug #1248759, can you ping and work directly with the sdk team to get a fix?
[16:45] <didrocks> fginther: oh, you never test on device?
[16:45] <elopio> didrocks: I pinged timp, that's the toolbar dev.
[16:45] <didrocks> elopio: did you test in one device?
[16:45] <fginther> didrocks, not the community core apps, we can't
[16:46] <elopio> didrocks: I did early on the week. I'm on it now.
[16:46] <didrocks> fginther: ah ok
[16:46] <didrocks> elopio: yeah, better to confirm first :)
[16:46] <elopio> well, after walking the dog. bbs.
[16:47] <elopio> fginther: will that be possible in the future? run community tests on the devices?
[16:47] <elopio> or is it a policy not to do it?
[16:47] <fginther> elopio, the possibility opens up once with have an emulator
[16:47] <ogra_> elopio, there are many people working under high pressure on the emulator
[16:51] <didrocks> ogra_: sil2100: kenvandine: robru: around (we can maybe start the meeting a little bit earlier)?
[16:51] <ogra_> on my way
[16:51] <kenvandine> sure
[16:52] <kenvandine> just need to boot my laptop, just a minute
[16:52]  * didrocks wonders with what kenvandine is communicating :p
[16:52] <elopio> ok, that's good :)
[16:53] <elopio> well, having people under high pressure is not.
[16:53] <kenvandine> didrocks, my desktop, but no mic on the desktop
[16:54] <elopio> everybody working under pressure, go get a beer!
[16:55] <elopio> that's important to keep a high quality.
[17:05]  * vila misread elopio as saying he only drinks quality beer
[17:05] <vila> never get me less drunk to drink high quality beer...
[17:13] <elopio> vila: I only drink the second cheapest.
[17:14] <elopio> hey vila, you never replied about making a lightning talk about TDD. Are you interested?
[17:15] <vila> elopio: ha, I knew I forgot something... I can barely keep up with the most basic stuff :-/ Preparing a lightning talk... I prefer to decline
[17:16] <elopio> vila: ok, I don't know why I thought you had one ready. Anyway, if you have more time in a month or so, let me know and we'll schedule it.
[17:17] <vila> elopio: I had one in the works but never found the time to finish it, I still have many ideas floating around and... well I try to turn them into code first, I'm better at that than at slides ;)
[17:28] <ogra_> oh, totally forgot
[17:28] <ogra_> [17:34] <bfiller> plars: looking at failure of mediaplayer-app here: http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/14:20131107:20131031.1/4933/mediaplayer-app-autopilot/
[17:35] <bfiller> plars: looks like it's not using version of mediaplayer-app-autopilot found in daily build ppa. the one in the ppa works fine
[17:35] <plars> bfiller: it doesn't update if that's what you mean, it uses what was in the image
[17:36] <bfiller> plars: ok then I guess mediaplayer* needs to be promoted to the archive as it fixes the red tests under autopilot 1.4
[17:37] <bfiller> plars: need this version in archive mediaplayer-app-autopilot 0.20.5+14.04.20131106.1-0ubuntu1
[17:38] <plars> bfiller: my understanding was that all of those would happen when autopilot1.4 goes in
[17:38] <bfiller> plars: all the other apps already released with the 1.4 changes, not sure why this one wasn't
[17:40] <plars> bfiller: ah, you're right, we did go to ap1.4 already, I hadn't noticed in the changelogs I guess
[17:45] <plars> bfiller: looks like it's not even in proposed at this point
[17:46] <bfiller> plars: I let didier know and will add it to landing sheet
[17:46] <plars> ack
[19:31] <thomi> Hi guys - can someone tell me what happened to image 15? seems like half the tests are missing
[19:37] <plars> thomi: that would be because it just came out and the tests are about halfway through running
[19:37] <plars> :)
[19:37] <thomi> plars: oh, right
[19:38] <thomi> I didn't realise we published piecemeal
[19:38] <thomi> it'd be neat if there was a big red flashing banner that said "this run is still in progress" :)
[19:38] <thomi> you could use the <blink> tag :P
[19:38] <plars> thomi: there are plans to add something that shows jobs that are still in progress
[19:39] <plars> thomi: we could add an "under construction" icon just for you
[19:39] <thomi> yay!
[19:39] <thomi> an animated gif!
[19:40] <plars> one thing is a bit strange... maguro seems to be running faster than mako?!
[20:05] <plars> doanac: did you mention that you were having some issues with unlock_screen locally?
[20:05] <doanac> plars: haven't tried today, but they seemed to go away when I pulled in your powerd-cli change
[20:05] <plars> doanac: I'm getting autopilot errors from it now locally, but it seems to be running ok in today's image in the lab
[20:05] <plars> doanac: odd, let me try
[20:11] <plars> doanac: that didn't help here unfortunately... very strange
[20:11] <doanac> plars: i'm about to move up to todays image for testing. i'll let you know what I see at home
[20:11] <plars> autopilot.introspection.ProcessSearchError: Search criteria returned no results
[20:12] <plars> thomi: any chance the unlock screen tool might need some changes for ap 1.4? Seems strange that it now fails locally for me, but not in the lab
[20:12] <doanac> plars: i've seen that. it seemed to happen when i didn't have my powerd lock in place
[20:13] <plars> doanac: could be... even when I had the powerd bits running, it looked like maybe the screen had shut off
[20:13]  * plars watches a bit more carefully this time
[20:14] <sergiusens> plars, can you rerun the jenkins -ci job for https://code.launchpad.net/~vthompson/music-app/fix-shuffle-test/+merge/193722 ?
[20:15] <sergiusens> just want it to fail on the merge and reflect reality :-)
[20:16] <plars> sergiusens: sure, looking
[20:17] <sergiusens> plars, it's one more test for the music app; would work fine if it merged before the ap 1.4 change :-)
[20:42] <plars> sergiusens: ok, https://code.launchpad.net/~vthompson/music-app/fix-shuffle-test/+merge/193722 fails now
[20:42] <sergiusens> thanks
[21:24] <thomi> Hi guys - I wonder if someone could dig out some data for me: I'm interested to know how long the entire image test took before autopilot 1.4 (so, image 12 I guess) compared to after 1.4 (image 15).
[21:24] <thomi> is that information easy to get?
[21:48] <thomi> plars: I guess that's something you care about? ^^
[21:48] <plars> thomi: I could get some rough numbers for you at least
[21:48] <plars> give me a minute
[21:48] <thomi> plars: no ruch, I'm just curious
[21:49] <thomi> if I'm right, you should see a speed increase
[21:51] <plars> thomi: well, we might have seen a small one, but if we did, it's all gone in the latest image and then some
[21:51] <plars> thomi: looking at the entire run, the total time is really all over the place
[21:51] <plars> thomi: ranging from about 3.5 - 4.5 hours
[21:53] <plars> thomi: looking at some of the longer running tests, like webbrowser, it didn't seem to affect it much
[21:53] <plars> thomi: all around 14 min
[21:57] <thomi> plars: hmm, ok
[21:58] <thomi> plars: so in my tests, I see about a 30% reduction in test runtime, but maybe in your case that's a tiny fraction of the total runtime, and is lost in the noise
[22:01] <plars> thomi: wow, if you're seeing 30%, which test is that on?
[22:01] <thomi> plars: across the autopilot test suite
[22:01] <plars> thomi: have you tried benchmarking it with one of the touch apps on a real device?
[22:01] <thomi> plars: no, but I will :)
[22:02] <thomi> the thing that got faster is the test suite <-> app rount trip times
[22:02] <thomi> especially when doing searches with filters, which is something that "good" test suites do... so maybe the app test suites can be improved to take advantage of that speed boost
[22:02] <thomi> something to keep an eye on, anyway
[22:04] <plars> thomi: sounds good