[00:09] <kgunn> robru: you around ? could i get a silo for line 90 ?
[00:09] <kgunn> it's a quick fix for the edge demo/intro on unity8 which seems to have broke since image 109
[00:10] <kgunn> ok i gotta go eat...bbiab hopefully to build
[00:16] <olli> you guys keep rocking...
[00:17] <robru> kgunn: rtm 5. Best to ping trainguards, pinging individuals doesn't scale when I'm on vacation, or off sick
[00:23] <cwayne> robru: howre you, what happened to your ribs?! (/me just read the topic)
[00:26] <robru> cwayne: apparently I'm 80 years old, because i literately just fell over and broke my ribs. It was ridiculous
[00:26] <robru> cwayne: I'm recovering best i can, thanks
[00:32] <cwayne> robru: can't really judge here, im 26 and already have arthritis, so apparently i'm also 80 :)
[00:35] <robru> cwayne: yikes, sorry to hear that
[00:36] <popey> another report on the list that #94 is badly broken
[00:40] <cwayne> robru: meh, could be worse :)  glad to hear you're recovering well
[00:46] <popey> https://bugs.launchpad.net/ubuntu/+source/qtmir/+bug/1382278
[00:46] <ubot5> Ubuntu bug 1382278 in unity8 (Ubuntu) "Image #94 on mako/flo fails to start - mir crash" [Undecided,New]
[00:46] <popey> if there's some "list" that needs to be on it
[00:46] <popey> #94 is busted
[00:53] <popey> robru: ^
[00:57] <popey> actually, Mirv bug 1382278 will need looking at in the morning
[00:57] <ubot5> bug 1382278 in unity8 (Ubuntu) "Image #94 on mako / #88 on flo fails to start - mir crash" [Undecided,New] https://launchpad.net/bugs/1382278
[01:47] <elopio> trainguards: anybody around to build the silo 5?
[01:48] <elopio> I could test it, but I'm not sure what are the parameters required for the build.
[01:49] <robru> elopio: typically build job doesn't require any parameters in the default case
[01:49] <robru> elopio: which silo 5?
[01:50] <elopio> robru: ubuntu-rtm/lannding-005. The recent one with the fix by Saviq.
[01:54] <robru> elopio: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-005-1-build/76/console OK started a build for you. Yes in this case the build job didn't require any parameters. The parameters are only for edge cases, for a first silo build it doesn't need any
[01:54] <elopio> robru: thank you.
[01:55] <robru> elopio: you're welcome!
[02:09] <imgbot> === trainguards: IMAGE 290 building (started: 20141017 02:10) ===
[02:21] <kgunn> thanks guys
[02:31] <popey> cihelp in the morning can someone look at why https://code.launchpad.net/~dinko-metalac/sudoku-app/fix-1366007/+merge/238533 that is spamming from jenkins?
[02:31] <fginther> popey, I'll look now
[02:32] <plars> wow
[02:32] <popey> yay
[02:32] <popey> thanks
[02:33] <fginther> popey, there's a bzr lock on the branch, I should be able to break it and end this madness
[02:34] <popey> thank you.
[02:34]  * popey goes to sleep knowing the best people are on the case
[02:35] <plars> fginther: how did that cause this? It looks like the job to update the MP only ran once
[02:47] <bzoltan> elopio:  the UITK failures came between #106 -> #107
[03:09] <imgbot> === trainguards: RTM IMAGE 113 building (started: 20141017 03:10) ===
[03:10] <bzoltan> elopio: fginther: Here are my logs -> http://people.canonical.com/~bzoltan/UITK-AP-FAILURES-106-107/
[03:10] <elopio> hey bzoltan
[03:10] <bzoltan> elopio: fginther: Here is the diff between 106 and 107 -> http://people.canonical.com/~ogra/touch-image-stats/rtm/107.changes
[03:10] <elopio> sorry I haven't been able to help you
[03:11] <elopio> still testing z.Z
[03:11] <bzoltan> elopio: fginther: one might think that the UITK is to blame because it landed on #107 ... but I have tested the exact same UITK on 106 and it is not failing as on 107
[03:12] <bzoltan> elopio:  no worries dude... I am just pushing this problem to the queue :)
[03:14] <elopio> bzoltan: what I've been seeing during this testing is that at random points, the screen freezes.
[03:14] <elopio> I have also seen media-hub consuming all CPU. And some people have been seing unity8 being killed by oom.
[03:15] <bzoltan> elopio: the 107 introduced new qtmir-android and unity8
[03:15] <elopio> bzoltan: usually, when we see random errors, it's because we are excercising the device too much and it stops listening to swipes and clicks.
[03:15] <bzoltan> elopio:  wow... that sounds strange
[03:16] <elopio> bzoltan: it would be useful to look in the results for crashes
[03:16] <bzoltan> elopio: my tests are pretty clear ... 4 tests 2 with 106 and 2 with 107 ... with the same latest UITK ... 1-2 faulres vs 66-67 failures... befoew 106 there was no problem and since 107 we have problems
[03:17] <bzoltan> elopio:  now I am cornering my suspects... I will test on 106 with the display server from 107
[03:17] <elopio> and something we were thinking with ToyKeeper was to collect information of CPU and memory usage during runs.
[03:18] <bzoltan> elopio:  that would be fairy easy
[03:18] <ToyKeeper> Well, if one process consistently uses > 95% CPU for ... > 30 seconds, perhaps, it's probably an issue.
[03:18] <elopio> bzoltan: as the toolkit has the biggest suite, it is sadly the one that puts more pressure on the system.
[03:19] <bzoltan> elopio: pressure in what sense?
[03:19] <ToyKeeper> I saw a few processes explode but not crash, and cause other processes to get OOM-killed or otherwise fail.
[03:19] <elopio> bzoltan: if lrt have a mean time to failure of less than 5 minutes, it's clear that a suite that takes 40 minutes to run will cause many crashes.
[03:19] <bzoltan> elopio:  I see
[03:19] <ToyKeeper> ("explode" as in excessive memory use or a dead-end CPU busy loop)
[03:21] <bzoltan> elopio: the UITK tests do not take longer than 30 minutes
[03:24] <elopio> bzoltan: well, that's still a lot more than the mean time to failure. We are not touching a lot of things that the lrt tests touch, like scopes and multimedia.
[03:24] <elopio> but still we need to increase the mean time to failure.
[03:24] <ToyKeeper> FWIW, I wasn't thinking of monitoring CPU/mem load during regular autopilot tests...  mostly just during LRT.
[03:24] <elopio> ToyKeeper: on bug #1382307
[03:24] <ubot5> bug 1382307 in indicator-messages (Ubuntu) "reply to SMS (via indicator) fails silently if no default SIM is set" [Undecided,New] https://launchpad.net/bugs/1382307
[03:24] <elopio> I get a dialog asking me to choose a sim
[03:24] <ToyKeeper> elopio: Huh, interesting.
[03:25] <ToyKeeper> I should re-test that.
[03:25] <elopio> ToyKeeper: any chance you tried to send a single word without pressing space?
[03:25] <ToyKeeper> elopio: I tried to send "Boooooooooooog.", and it auto-corrected to "Bookkeeping." as I hit "send", and I think it then tried to send.
[03:26] <elopio> ToyKeeper: yes, weird. When I tried to send "Test" without pressing space and then the send button was not enabled.
[03:27] <elopio> and when I clicked the disabled button, it was closed. It seems it silently succeeded.
[03:27] <ToyKeeper> elopio: I think the '.' will work too, not just space.
[03:27] <elopio> ToyKeeper: yes, I'm not sure why I got the dialog. I had the sim on the second slot.
[03:28] <ToyKeeper> elopio: I've got both my SIMs in the krillin, and simply hadn't set one as default yet for SMS.  But I think perhaps I should re-test to confirm.
[03:32] <cwayne> ToyKeeper: elopio: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1369737 ?
[03:32] <ubot5> Ubuntu bug 1369737 in ubuntu-settings-components (Ubuntu) "Send button does not enable until you press spacebar" [Critical,In progress]
[03:34] <ToyKeeper> I tried it later after setting a default SIM (again just one word followed by a period), and it worked.
[03:38] <ToyKeeper> elopio: Fresh after flashing, it does indeed ask me to select a SIM.  I wonder what happened last time.
[03:39] <ToyKeeper> elopio: If I manage to reproduce it, I'll update the bug accordingly.  For now, it's ... mysterious.
[03:41] <kgunn> ToyKeeper: elopio if you guys are still on, silo5 looks good - fixes the edge demo and the AP tests all pass
[03:41] <ToyKeeper> kgunn: ... and I think 113 is currently building from cron with no changes.  :(
[03:41] <kgunn> dang it...missed that boat
[03:42] <elopio> cwayne: yes, what we are trying to figure out is why the dialog to choose the sim didn't appear.
[03:42] <elopio> ToyKeeper: ok, thanks.
[03:42] <ToyKeeper> cwayne: I haven't been able to reproduce what I saw...  marked the bug as invalid until I can find a way to trigger it.
[03:43] <cwayne> ah, sorry :)
[03:44] <ToyKeeper> elopio: It could be something else entirely...  like, after testing last night and thinking a message had been lost, my android phone received a SMS about 6 hours later while I was asleep...  not sure what caused the delay.
[03:45] <elopio> kgunn: I can confirm the silo and give the QA green light to get it in the next image.
[03:45] <elopio> but let me finish the maps tests, because I keep getting distracted.
[03:46] <kgunn> :)
[03:46] <kgunn> distracted ? it's like 4am there or something
[03:47] <kgunn> i'll keep doing a little exploratory manual testing as well...
[03:49] <elopio> kgunn: nah, it's 10 pm.
[03:59] <Mirv> morning
[03:59] <imgbot> === trainguards: IMAGE 290 DONE (finished: 20141017 04:00) ===
[03:59] <imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/290.changes ===
[04:03] <Mirv> popey: ah, Mir bug, not a bug for me (or in me)
[04:05] <Mirv> oh, but it's on mako, maybe for me after all. I first read flo only. /me flashes
[04:13]  * ToyKeeper -> lunch, or something approximating it
[04:19] <imgbot> === trainguards: RTM IMAGE 113 DONE (finished: 20141017 04:20) ===
[04:19] <imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/113.changes ===
[04:29] <bzoltan> elopio:  the unity8 is clearer. It is not the troublemaker in #107 ... Now my top suspect... the mir
[04:29] <bzoltan> Hello Mirv
[04:29] <Mirv> hi bzoltan
[04:31] <Mirv> bzoltan: the qtmir change in #107 added reading of localized app names from .desktop files
[04:32] <Mirv> popey: yes, mako seems busted also after OTA upgrade to #95
[04:34] <bzoltan> Mirv: and something made the UITK to fail ~67 tests -> http://people.canonical.com/~bzoltan/UITK-AP-FAILURES-106-107/
[04:38] <Mirv> bzoltan: yeah, but this is newer, this problem. your #107 problem is interesting if it's indeed not unity8 like you said.
[04:39] <Mirv> since the qtmir change would sound like innocent and not affecting English usage
[04:45] <bzoltan> Mirv:  I am checking these  http://people.canonical.com/~ogra/touch-image-stats/rtm/107.changes
[05:13] <Mirv> argh, I just can't get mako to bootloader menu since it's playing for me the red lights of dead play and only (barely) accepting the charger
[06:25] <elopio> trainguards: rtm silo 5 ready to be published.
[06:33] <abeato> trainguards, could I get a silo for gst-plugins? Line 39 of the spreadsheet
[06:34] <Mirv> elopio: thanks!
[06:34] <Mirv> elopio: do you know what has been agreed, that is supposed to be going in?
[06:36] <Mirv> abeato: rtm-012
[06:36] <elopio> Mirv: I think nobody has been around to make that decission.
[06:36] <abeato> Mirv, awesome, thanks
[06:36] <elopio> Mirv: but it wouldn't hurt to make a new version for it to be ready to test it in case they decide it should go, right?
[06:41] <Mirv> elopio: you're talking about 005 still? I mean, was it agreed to go in?
[06:42] <Mirv> but at least it's surely good to have silos tested and ready to go
[06:42] <popey> Mirv: yeah, not a bug in or for you, but figured you'd be first online so if people needed poking you'd be around ☻
[06:45] <Mirv> popey: right!
[06:49] <Mirv> I've been trying to kick this mako alive after it lost the battery, and it finally did. bootstrap flash did not help, I'm retracing a couple of crashes in case they'd help something.
[06:54] <elopio> Mirv: yes, I'm talking about silo 5. The bug still doesn't have a tag to see if it goes for 10/17 or not. I've just send an email with what we found today.
[06:54] <elopio> somebody should reply with priorities for them.
[07:02] <Mirv> thanks elopio
[07:07] <Mirv> local retracing seems somehow broken for all of my crashes, so letting them off towards LP
[07:15] <Mirv> not sure if I could connect to wifi from command line, but I'm just using USB networking
[07:42] <dbarth> morning guys
[07:43] <dbarth> i have a problem with silo 20 which took a bad libmir dependency
[07:43] <dbarth> it seems to be a recurring pb for the online-accounts package
[07:44] <dbarth> last time cjwatson made silo configuration changes to the silo
[07:45] <dbarth> can you advise on what i should do to get this silo to build properly? just rebuild (?) ask for that same configuration change? or make a change in our packaging for example?
[08:03] <Mirv> dbarth: which bad mir dependency you're seeing? the same problem as previous time shouldn't be there as mir is the same version as in utopic
=== tvoss|food is now known as tvoss
[08:05] <ogra_> popey, Mirv, i updated bug 1382278
[08:05] <ubot5> bug 1382278 in unity8 (Ubuntu) "Image #94 on mako / #88 on flo fails to start - mir crash" [Undecided,Confirmed] https://launchpad.net/bugs/1382278
[08:08] <Mirv> ogra_: popey: updated my notes too, I've already tried reverting libhybris, media-hub and qmenumodel but those don't seem to help
[08:09] <Mirv> oh, actually I didn't do media-hub correctly, trying again
[08:12] <bzoltan> ogra_:  The qtmir-android qtdeclarative5-qtmir-plugin in the #107 makes the 66 UITK AP tests fail
[08:14] <ogra_> bzoltan, filed a bug already ?
[08:14] <bzoltan> ogra_:  not yet, I just got the results...
[08:15] <ogra_> thanks for tracking that down !
[08:15] <ogra_> good work :)
[08:16] <dbarth> Mirv: yes a libmirclient8; maybe i will rebuild cause i got it will it was in transit
[08:16] <bzoltan> ogra_:  Should I file the bug here -> https://bugs.launchpad.net/qtmir
[08:16] <ogra_> bzoltan, yeah
[08:17] <bzoltan> ogra_:  OK, I collect my logs and file it
[08:18] <Mirv> popey: ogra_: ok correcting my mistake of reinstalling just the same version of media-hub, I can confirm that reverting media-hub (only) fixes mako
[08:19] <ogra_> Mirv, oh ... not even hybris ?
[08:20] <Mirv> ogra_: no, I upgraded it back and it still works
[08:20] <ogra_> wow
[08:20] <Mirv> the media-hub however seems like the one that tries to use new android interface (via hybris)
[08:20] <popey> ahh
[08:21] <Mirv> "Make use of MediaRecorderObserver interface"
[08:21] <ogra_> oh right
[08:21] <ogra_> well i think a simple upload of the android package with the changes is needed
[08:22] <Mirv> yes
[08:24] <bzoltan> ogra_: Mirv: https://bugs.launchpad.net/qtmir/+bug/1382414
[08:24] <ubot5> Ubuntu bug 1382414 in QtMir "New qtmir makes UITK AP tests fail" [Undecided,New]
[08:31]  * ogra_ wonders if sil2100 will get up in time for the meeting 
[08:31] <ogra_> (perhaps not :) )
=== vrruiz_ is now known as rvr
[09:10] <ogra_> that looks pretty landed to me
[09:10] <ogra_> and rmadison agrees :)
[09:10]  * ogra_ kicks an image
[09:11] <Mirv> \o/
[09:14] <imgbot> === trainguards: RTM IMAGE 114 building (started: 20141017 09:15) ===
[09:47]  * asac goes 113
[09:47] <ogra_> 113 is sweet
[09:48] <ogra_> (114 will be even better)
[09:48] <asac> will we promote that?
[09:48] <ogra_> 114 ?
[09:48] <ogra_> hopefully
[09:48] <asac> either
[09:48] <asac> ok
[09:48] <asac> whats coming in 114?
[09:48] <ogra_> not either
[09:48] <ogra_> see my mail :)
[09:48] <ogra_> (to phablet@)
[09:48] <ogra_> 114 has a fix for the broken edges intro
[09:49] <asac> oh thats broken?
[09:49]  * asac should do that intro regularly
[09:49] <ogra_> sadly mako and flo are completely broekn in both ... they will need a 115 ince rsalveti is up
[09:49] <ogra_> *once
[09:49] <asac> I wonder if we should make the intro available as an app so folks that did miss or didnt get it can retry etc.
[09:49] <ogra_> we have a phablet-config command  to en/disable it
[09:49] <asac> ogra_: 114 is completely broken on mako?
[09:50] <asac> 113 too?
[09:50] <ogra_> asac, yes, and flo (see my mail)
[09:50] <asac> ok, well let me read email in a bit then
[09:50] <ogra_> back to 112
[09:50] <ogra_> a media-hub fix landed that needed a device tarball change
[09:50] <asac> guess we dont want to promote iuf mako is really broken
[09:50] <ogra_> that change is only in the krillin tarball
[09:50] <asac> ah ok
[09:51] <asac> but the change needed is already in thge code base?
[09:51] <ogra_> no, we ant to wait til rsalveti shows up and can do an android upload into rtm
[09:51] <ogra_> and then roll 115 ....
[09:51] <ogra_> but we might promote 114 for krillin inbetween
[09:51] <asac> sure dont want to do it without rsalvetu. just wondered if it was a sync problem
[09:51] <asac> guess we can check once 115 is there
[09:51] <ogra_> kind of
[09:51] <asac> right
[09:51] <asac> coordination problem
[09:52] <ogra_> its a sync problem on the git level :)
[09:52] <asac> oh... interesting
[09:52] <asac> weonder how we do that at all
[09:52] <ogra_> the oofficial android images simply didnt get ti yet
[09:52] <asac> keepinhg our android code bases insync
[09:52] <asac> that is
[09:52] <ogra_> usually we land first in the official android tree, then port over to krillin
[09:52] <ogra_> this one change was the other way round
[09:53] <asac> right. guess folks were ambitious to ge3t it into krillin
[09:53] <asac> greed
[09:53] <ogra_> to fix krillin quickly
[09:53] <asac> hehe
[09:53] <ogra_> the pressure was a lot higher in wed :)
[09:53] <ogra_> *on
[09:54] <ogra_> 113 already looks very very good though ... i hope victor gives his go for 114 then ...
[09:54] <ogra_> (and i wonder if/when sil2100 will show up :) )
[09:55] <ogra_> seems he worked with Saviq on the edges fix last night, they were both up til 2am
[09:55] <ogra_> (and sil was up he night before til 4am (or later, thats when i went to bed))
[10:03] <sil2100> ...
[10:03] <Mirv> sil2100: morning! :)
[10:03] <sil2100> I overslept, no idea why the alarm didn't wake me up
[10:03] <Mirv> sil2100: it's just good for you...
[10:03] <sil2100> First time that happened
[10:03] <brendand> sil2100, probably because you were shattered
[10:04] <sil2100> ogra_, Mirv: anything happened on the meeting? ;)
[10:07] <Mirv> sil2100: we received a "go" for 005 from victor, and discussed the mako issue
[10:07] <sil2100> Mirv: is 005 the fix for the swipe tutorial?
[10:07] <Mirv> 005 fixed the edges intro. mako needs android upload but it can be manually fixed by reverting media-hub to previous version.
[10:07] <Mirv> sil2100: that
[10:07] <sil2100> Excellent o/
[10:08] <Mirv> #114 with it should be built within 30 mins or so (started 1h ago)
[10:08] <sil2100> Yay, thanks everyone!
[10:08]  * sil2100 feels really stupid about oversleeping
[10:08] <sil2100> I blame my phone
[10:09] <nik90> sil2100: may be the alarm rang, but you didn't hear it in your deep sleep. :P ?
[10:09]  * nik90 always pop out when there is an conversation about alarms ;)
[10:09] <sil2100> No, I think my phone died due to low battery power, hmmm
[10:09] <Mirv> nik90: /hilight alarm ? :)
[10:09] <sil2100> hah
[10:09] <nik90> sil2100: ah...that's ain't my fault :)
[10:09] <sil2100> ;)
[10:10] <popey> is it possible to set a custom ringtone yet? or is that not done?
[10:10] <nik90> Mirv: lol..I didn't do that until now,, but that sounds better than keep an eye on this channel
[10:10] <popey> i.e. an ogg file I have on my phone.
[10:10] <sil2100> Oh gosh, so Saviq actually did the fix at that hour?!
[10:12] <sil2100> ogra_, Mirv, john-mcaleely: so the plan is to roll out a new device tarball for all the other platforms after this image finishes?
[10:14] <sil2100> I think we might want to open up the gates after this image is finished then
[10:16] <ogra_> sil2100, morning !
[10:16] <ogra_> sil2100, we cant just "roll" another device tarball
[10:16] <ogra_> that needs rsalveti ... and an upload of the android package
[10:17] <sil2100> hm, right, we don't have a new device tarball right now to roll out
[10:17] <ogra_> sil2100, i think we should wait with opening the gates til that is in
[10:18] <ogra_> sil2100, but 114 could be promoted if victorp signs it off
[10:18] <sil2100> brendand: how many people do we have from QA today?
[10:19] <ogra_> sil2100, we also decided 114 doesnt need a full test run ... the change is a 1 liner thats easy to verify
[10:19] <sil2100> ogra_: do we need QA to sign-off the delta in this agreenment, or does Victor want to take it as it is?
[10:19] <sil2100> That makes sense
[10:19] <ogra_> right, we want a delta check ... and some dogfooding
[10:19] <ogra_> and then talk to victor again
[10:20] <ogra_> ... get his sing-off and promote krillin ...
[10:21] <sil2100> You mean, only promoting for krillin?
[10:21] <ogra_> yes
[10:21] <ogra_> and promote 115 afterwards for the other arches
[10:21] <sil2100> Ok, makes sense, but I guess I'll have to wait for the official announcement once we have all promoted
[10:21] <ogra_> (which i why i said we need to keep the gates still locked)
[10:21] <sil2100> No need to promote something broken
[10:22] <bzoltan> ogra_: sil2100: Do you think it would be acceptabe from the QA point of view if I run my 9h tests on #106 image and not on the #107+ what are all busted for UITK tests?
[10:22] <bzoltan> brendand: ^
[10:22] <sil2100> bzoltan: I think I saw some discussions here regarding UITK being a bit brokenish, but do you know maybe why UITK tests are busted on the newer images?
[10:23] <bzoltan> sil2100:  No, the UITK is not broken, not even brokenish... simple the new mir broke the UITK tests
[10:23] <bzoltan> sil2100: https://bugs.launchpad.net/qtmir/+bug/1382414
[10:23] <ubot5> Ubuntu bug 1382414 in QtMir "New qtmir makes UITK AP tests fail" [Undecided,New]
[10:25] <sil2100> This is a very tricky situation - I leave the decision in QA's hands, but we really need to get someone from qtmir team working on it then
[10:26] <sil2100> Maybe add a section in their test plan to at least run some sub-set of your UITK tests during release
[10:26] <brendand> sil2100, just me really
[10:26] <bzoltan> sil2100:  that was my first thought too
[10:26] <brendand> sil2100, well rhuddie and vrruiz are around as well
[10:27] <sil2100> ricmm, camako: can you guys maybe find someone to take a look at LP: #1382414 ?
[10:27] <ubot5> Launchpad bug 1382414 in QtMir "New qtmir makes UITK AP tests fail" [Undecided,New] https://launchpad.net/bugs/1382414
[10:27] <sil2100> brendand: ACK, ok, so even with the gates opened we'll have rather a slow day for releases anyway :)
[10:28] <sil2100> brendand: you guys busy with iso testing still??
[10:28] <sil2100> (- one ?)
[10:28] <brendand> sil2100, iso?
[10:29] <bzoltan> brendand:  my question is that which one you prefer: (1) I run UITK silo13 validation against #107+ and see 67 failures or (2)on #106 where everything is as normal?
[10:29] <ogra_> brendand, desktop RC
[10:29] <brendand> ogra_, yeah but why would i be doing that :)
[10:29] <jibel> sil2100, almost all the team is traveling today or will be really soon
[10:29] <ogra_> no idea, tell me :)
[10:29] <imgbot> === trainguards: RTM IMAGE 114 DONE (finished: 20141017 10:30) ===
[10:29] <sil2100> jibel: ACK
[10:30] <sil2100> Yay!
[10:30] <ogra_> hey
[10:30] <imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/114.changes ===
[10:30] <ogra_> ah
[10:30] <jibel> sil2100, and next week davmor2 and omer will help me with the release of utopic
[10:30] <sil2100> Now for a QA sign-off on that and to Victor we go
[10:30]  * ogra_ just wanted to complain aboutteh missing changelog
[10:30] <sil2100> We like changelogs like these
[10:30] <ogra_> yeah
[10:30] <brendand> ok time for a smoke test
[10:31]  * ogra_ OTAs
[10:31] <ricmm> mzanetti: hey ^ can you take a look at 1382414
[10:31] <ricmm> looks like the desktop file reader changes
[10:32] <ogra_> ricmm, do you knwo if rsalveti will be around today ? (i cant remember him saying anything ... i know sergio is in the air)
[10:35] <sil2100> As we can't really revert media-hub right now, at least not without introducing a regression
[10:35] <ogra_> yeah
[10:35] <ogra_> 114 looks fine here after OTA
[10:35]  * sil2100 checks the changelog for the last upload
[10:36] <sil2100> I'm flashing with the u-d-f
[10:36] <ogra_> sil2100, well, we dont miss bits in media-hub ... media-hub makes uses of the changes in the device tarball
[10:38] <sil2100> Right, so looking at the changelog we might be able to revert it temporarily as a last resort, but we basically get rid of a pretty good fix
[10:38] <sil2100> And the fix itself is not at fault here
[10:38] <ogra_> yeah, and it will cause chaos
[10:38] <ogra_> lets rather wait ... it isnt like people cant push fixes to silos :)
[10:38] <ogra_> or that we are low on silos
[10:39] <ogra_> (we just dont release then yet)
[10:39] <ogra_> *them
[10:40] <nik90> will the promotion happen on mako as well since it looks like 114 might be promoted?
[10:40] <ricmm> ogra_: he should be around
[10:40] <ogra_> no, mako is obviously broekn
[10:41] <ricmm> what hppened to media-hub ?
[10:41] <sil2100> nik90: we need to wait for one thing before we promote for mako
[10:41] <nik90> ah the boot issues
[10:41] <ogra_> which is what tthe discussion above is about
[10:41] <sil2100> nik90: we basically need a new android upload and device bits
[10:41] <ogra_> ricmm, the devlice tarball changes didnt land in mako or flo ...
[10:41] <ogra_> ricmm, so both dont boot anymore
[10:41] <nik90> ah ok
[10:41] <ricmm> ah you landed silo 005
[10:41] <ricmm> lol
[10:41] <ogra_> right
[10:41] <ricmm> did you land that today? or last night when salveti was on
[10:41] <ogra_> which is fine on krillin :)
[10:42] <ogra_> last night
[10:42] <ricmm> yea there was no android source pkg pushed in there
[10:42] <ogra_> i think nobody thought about the android package
[10:42] <ricmm> the patch lnded to phablet git
[10:42] <ogra_> due to the krillin pressure
[10:42] <ricmm> if you are able to build an android package, you cn do it
[10:42] <ogra_> i dont know if it automatically checks out during build ... i fear not
[10:43] <ricmm> no, you have to build it manually
[10:43] <ricmm> afaik
[10:43] <ogra_> and i dont have a phablet tree here ... til that is checked out he will be up
[10:43] <ricmm> I need to run to the bank as I have an appointment but I'll be back in a bit
[10:43] <ricmm> maybe I can help
[10:43] <ogra_> cool
[10:43] <sil2100> ricmm: thanks!
[10:43] <sil2100> Anyway 114 looking good here
[10:44] <ogra_> yeah
[10:44] <ogra_> really good
[10:44] <brendand> ogra_, sil2100 - we *might* have a problem
[10:44] <ogra_> !
[10:44] <ogra_> stop finding them !
[10:45] <ogra_> brendand, with the fix or did you find something new ?
[10:45] <sil2100> brendand: wha's happening?
[10:46] <sil2100> Ah the suspence
[10:46] <sil2100> ;)
[10:46] <ogra_> heh
[10:47] <brendand> sil2100, sorry my wife called me just after typing that :)
[10:47] <ogra_> you make that up, right ?
[10:47] <ogra_> :P
[10:48] <ogra_> you just want to raise the excitement :)
[10:48] <brendand> sil2100, i need 5 more minutes to double check what i found
[10:48] <sil2100> brendand: but is that a problem with the fix itself, or something completely new that we didn't see before?
[10:48] <ogra_> 4:30 ...
[10:49] <ogra_> (we seem to have some improvement for the fix from dednick )
[10:50] <sil2100> hm?
[10:50] <ogra_> he pinged me after we landed the silo
[10:51] <ogra_> saying he has some improvements
[10:51] <brendand> ogra_, i think the new fix doesn't work well
[10:51] <ogra_> dednick, ^^^
[10:51] <ogra_> where is your change ?
[10:51] <brendand> ogra_, as in - worse than it was before
[10:51] <ogra_> uuuh
[10:51] <brendand> and i'm a bit annoyed at elopio now
[10:51] <ogra_> why did elopio sign it off thn
[10:51] <ogra_> *then
[10:51] <brendand> because if i confirm this then he obviously didn't test it right
[10:52] <brendand> so i'm hoping it was a fluke
[10:52] <sil2100> ACK
[10:52] <ogra_> tsdgeos, ^^^do you know wehere dednick's improvement is ?
[10:52] <dednick> havent pushed yet
[10:54] <ogra_> brendand, are you doing a full day today ?
[10:54] <brendand> ogra_, yeah
[10:54] <ogra_> cool
[10:54] <brendand> ogra_, but not longer
[10:54] <ogra_> heh
[10:54] <brendand> ogra_, 5:30 sharp finish
[10:54] <ogra_> 5:30 ? portland time ?
[10:54] <ogra_> :P
[10:54] <brendand> phew it was a fluke
[10:54] <brendand> breaths in
[10:55] <sil2100> Phew
[10:55] <ogra_> oh man
[10:55] <brendand> but still it seems there might be some flaky behaviour there
[10:55] <ogra_> at least now i'm fully awake :)
[10:55] <brendand> basically i pulled down the indicator and it was stuck
[10:55] <ogra_> brendand, right, we can land dednick's improvement in 115
[10:55] <brendand> would not go back up
[10:55] <brendand> this time it didn't happen
[10:55] <ogra_> (if that fixes it indeed)
[10:56] <sil2100> ogra_: is there a landing for that?
[10:56] <ogra_> no
[10:56] <ogra_> see above :)
[10:56] <ogra_> not pushed yet
[10:56] <brendand> ogra_, let's promote after lunch if i don't find anything further
[10:57] <ogra_> brendand, tell victor and asac :)
[10:57] <ogra_> i think the final decision should be in tehir hands
[10:57] <ogra_> (i agree though)
[10:58] <Mirv> phew
[10:59] <sil2100> The indicator drop down works reliably on my device at least
[10:59] <ogra_> sil2100, in the edge intro ?
[11:02] <bzoltan> what? we got a promotable image?
[11:03] <sil2100> bzoltan: we *might*, yes, waiting for management decision
[11:04] <bzoltan> fingers crossed
[11:14] <asac> ogra_: sil2100: can we technically promote just one device without stgraber?
[11:15] <ogra_> yes
[11:16] <brendand> bzoltan, i didn't answer your question sorry
[11:17] <bzoltan> brendand:  no worries.. I started to test against #114
[11:17] <brendand> bzoltan, if you need to land the fix for https://bugs.launchpad.net/bugs/1368492 then we could make an exception, but we'd be much more comfortable if your tests were working again
[11:17] <ubot5> Ubuntu bug 1368492 in ubuntu-ui-toolkit (Ubuntu) "crash opening image file" [Critical,In progress]
[11:17] <brendand> bzoltan, you need to get them working again asap anyway
[11:18] <bzoltan> brendand:  https://bugs.launchpad.net/qtmir/+bug/1382414
[11:18] <ubot5> Ubuntu bug 1382414 in QtMir "New qtmir makes UITK AP tests fail" [Undecided,New]
[11:18] <bzoltan> brendand:  I am a victim here...
[11:18] <brendand> bzoltan, no-one around to help you with that?
[11:18] <bzoltan> brendand:  the qtmir landed on #107 broke the UITK tests
[11:19] <Mirv> brendand: peo
[11:19] <Mirv> ple have been pinged
[11:19] <brendand> people?
[11:19] <brendand> ok
[11:20] <brendand> sil2100, agggh - i might need to take back what i said... so frustrating
[11:21] <brendand> sil2100, sorry
[11:21] <bzoltan> ogra_: sil2100: brendand: Mirv: the reason why I run ~800 tests and all available app's AP tests before each UITK release is to ensure that the UITK does not break the apps or the AP tests of the apps... because they all depend on UITK. I would recommend the same QA measure for other components with similar dependencies on them.
[11:21] <tvoss> trainguards, can I get a silo for line 54?
[11:22] <brendand> bzoltan, well yes i hope that if peoples tests are failing they are fixing them
[11:22] <Mirv> mzanetti was last pinged on that issue, but not sure if he's travelling
[11:22] <brendand> Mirv, i guess he is - i saw he arrived today on the spreadsheet
[11:23] <ogra_> what is he doing on that spreadsheet ?
[11:23] <bzoltan> brendand: it is not that simple... I would say that if your release breaks the tests of other projects then you are expected to react. The same way my team was and is fixing app tests sometimes.
[11:23]  * ogra_ would have flown direct to washington instead
[11:23] <tvoss> ogra_, alter ...
[11:23] <tvoss> :)
[11:23] <brendand> sil2100, the bug might depend on the indicator you drag down
[11:23] <pete-woods> just checking, is there any chance of silo assignment (for genuine critical bug) today?
[11:24] <brendand> or not
[11:24] <ogra_> tvoss, hehe
[11:24] <Mirv> tvoss: rtm-006
[11:24] <tvoss> Mirv, utopic silo wouldbe good actually :)
[11:24] <Mirv> tvoss: utopic is in final freeze...
[11:24] <tvoss> Mirv, ah okay
[11:24] <tvoss> Mirv, with that, I can just reuse rtm 4
[11:25] <Mirv> since midnight
[11:25] <tvoss> Mirv, could you trigger a build of rtm 4? not sure I can easily do it
[11:25] <Mirv> https://wiki.ubuntu.com/FinalFreeze
[11:25] <tvoss> lool, ^
[11:25] <Mirv> tvoss: oh sorry, right, not rtm-006 but 006 :)
[11:25] <tvoss> Mirv, now I'm confused
[11:25] <tvoss> :)
[11:26] <Mirv> tvoss: I mean, 54 is utopic line so it got utopic silo as well - 006. but of course, probably not to be landed to utopic.
[11:26] <Mirv> "release critical bugs, security critical bugs, exceptional circumstances"
[11:27] <Mirv> ogra_: do you know if we'd still land things to utopic until ~release day or not?
[11:27] <Mirv> tvoss: we can try with your line 54 of course and see if it still gets auto-accepted :)
[11:27] <ogra_> Mirv, i think sil2100 wanted to hold back utopic too (for touch)
[11:27] <tvoss> Mirv, ack
[11:28] <Mirv> ogra_: right, so sil2100 is our barrier, not the fact that 14.10 is being released :)
[11:28] <Mirv> I think on Tuesday utopic uploads will need to stop anyhow
[11:29] <Mirv> I'll call 15.04 now "viper", the first on https://wiki.ubuntu.com/DevelopmentCodeNames#A15.04
[11:29] <Mirv> v-series is so boring
=== renato is now known as Guest37257
[11:33] <Laney> argh
[11:34] <Laney> someone help me upload to an RTM silo with dput-ng
[11:34] <ogra_> sudo apt-get install dput
[11:34] <ogra_> :P
[11:34] <Mirv> Laney: ^ :)
[11:34]  * ogra_ never used -ng
[11:34] <Laney> never
[11:35] <Mirv> I was about to say something along those lines too
[11:35] <Laney> not since I accidentally uploaded to the wrong release
[11:35] <Laney> ok, no help here, I'll go figure it out
[11:35] <Mirv> I added default_host_main = notspecified after I accidentally uploaded something to the main archives (before I had rights to do so), and I'll only comment it out when I really want to upload something to archives
[11:36] <Laney> It was in Debian and I had sbuild -d unstable instead of experimental
[11:36] <ogra_> Laney, wouldnt have happened if debian used silos ;)
[11:37] <Mirv> Debian would surely love google docs spreadsheet for package management
[11:38] <lool> :-)
[11:38] <Laney> ok, now we're trolling, really going to find out for myself
[11:38] <lool> Laney: dput ppa:ci-train-ppa-service/ubuntu-rtm/landing-004 worked for me
[11:38] <lool> but I think I commented out some checks
[11:40] <Laney> it's trying to append /ubuntu/
[11:40] <ogra_> Laney, but its FRIDAY !
[11:40] <Laney> /ubuntu
[11:40] <ogra_> we are supposed to troll, no ?
[11:40] <lool> problem is that I didnt take time to note down what I had patched
[11:40] <lool> I have /etc/dput.d/profiles/ppa.json: http://paste.ubuntu.com/8578672/
[11:40] <lool> recently editied
=== boiko__ is now known as boiko
[11:42] <lool> ok, I edited /usr/lib/python2.7/dist-packages/dput/hooks/distro_info_checks.py
[11:43] <lool> Laney: http://paste.ubuntu.com/8578686/
[11:44] <lool> I know, classy
[11:44] <Laney> nice
[11:44] <Laney> I did something like that, yeah, having problems with the incoming path
[11:44] <Laney> Launchpad failed to process the upload path '~ci-train-ppa-service/ubuntu-rtm/landing-012/ubuntu':
[11:45] <lool> Laney: I pasted my ppa.json above, uploaded worked for me with above dput invocation yesterday
[11:45] <Laney> Could not find suite 'ubuntu'.
[11:45] <Laney> it's the same as mine
[11:45] <Laney> blerg
[11:45] <lool> can't tell why, mine says: 2014-10-15 20:42:07,529 - dput[62836]: uploader.invoke_dput - Uploading lxc-android-config using ftp to ppa (host: ppa.launchpad.net; directory: ~ci-train-ppa-service/ubuntu-rtm/landing-004)
[11:46] <lool> no /ubuntu at the end
[11:47] <lool> Laney: maybe check your .changes has Distribution: 14.09
[11:47] <Laney> sure does
[11:47] <Laney> what about your /etc/dput.d/profiles/ubuntu.json?
[11:48] <lool> it's from july, I didn't touch it, http://paste.ubuntu.com/8578695/
[11:49] <lool> /etc/dput.d/metas/ubuntu.json has http://paste.ubuntu.com/8578703/
[11:49] <Laney> hmm ok
[11:51] <lool> trainguards, I understand custom tarball has landed, would you mind updating line 46 to say so?
[11:51] <sil2100> lool: ah! Right, doing
[11:53] <lool> is it worth staging utopic updates in utopic-proposed for post-release SRUs?
[11:53] <lool> (trying to figure out how we land stuff in trunks in the next couple of weeks)
[11:56] <lool> trainguards, line 41 (location-service sync to rtm to pickup fixed gps provider): I've changed "sync:ubuntu,utopic location-service lxc-android-config" to "lxc-android-config sync:6 location-service", is that correct? mind reconfiguring
[11:56] <lool> I dont want to add lxc-android-config to the utopic silo as it would require using a version higher than the one in utopic which has unwanted changes
[11:56] <sil2100> lool: uh, I was just assigning that before you changed
[11:57] <lool> sil2100: rtm silo 4? sorry
[11:57] <lool> sil2100: was trying to fix it, I can revert
[11:57] <sil2100> lool: no no, it's fine, let me think about this
[11:58] <lool> sil2100: so right now I think we want to combine a manually created lxc-android-config with a cherry-pick just for rtm and a location-service binary from an utopic silo -- that wont actually go in utopic
[11:58] <sil2100> lool: ah, ok, then we need to do it differently
[11:58] <sil2100> lool: let me prepare the line
[12:02] <sil2100> lool: ok, so, I prepared the line in such a way that CI Train will understand, but there is a small 'but'
[12:02] <lool> sil2100: I prefer small buts
[12:02] <sil2100> lool: whenever you want to sync packages with the build job, you need to list the package name you want to sync in the list to rebuild, i.e. the location-service
[12:02] <sil2100> ;)
[12:03] <lool> ok
[12:03] <sil2100> lool: lxc-android-config you can just upload directly to the PPA and then run watch-only
[12:03] <lool> it's there already
[12:03] <lool> and cant go in the other PPA anyway
[12:03] <sil2100> Ok, then I suppose it should be ok with that, just remember to not do any builds without any parameters in the list
[12:04] <lool> ok
[12:04] <lool> tvoss: ^ fyi
[12:07] <lool> tvoss: binaries ready
[12:07] <tvoss> lool, in rtm 4, or utopic 6?
[12:08] <lool> utopic 6
[12:08] <tvoss> lool, ppc64el falied, looks flaky
[12:09] <Mirv> tvoss: so, I've tested that non-seeded utopic uploads still go in, so when/if something is allowed to go in by sil2100, we can still land to utopic (until ~Tuesday)
[12:09] <lool> tvoss: binaries installed; testing now
[12:09] <Mirv> "tested", ie. released qt creator plugin
[12:11] <tvoss> lool, ack
[12:11] <lool> tvoss: I'm getting some errors in HERE webapp, but it eventually works
[12:12] <lool> this is espoo only
[12:12] <tvoss> lool, ack
[12:12] <tvoss> lool, a test seems to be flaky, let me try to address that
[12:12] <lool> google maps webapp worked fine and square; openstreetmap webapp didn't
[12:12] <lool> testing browser now
[12:14] <lool> in browser, I could get here to work too with similar errors; google shows correct location, but no dot
[12:15] <olli> gm
[12:15] <olli> sil2100, how is 114 coming along
[12:15] <lool> and bing works
[12:15] <lool> tvoss: so that's a really huge improvement over what we had; trying GPS now
[12:15] <tvoss> lool, in here, hitting the button on the bottom left while it's gray is supposed to give an error
[12:15] <tvoss> I read through the javascript
[12:18] <lool> tvoss: bad news, I can't get a GPS fix
[12:18] <tvoss> lool, mind checking /data/misc
[12:18] <tvoss> lool, are you outside?
[12:19] <tvoss> lool, how would you know that you have a gps fix?
[12:19] <tvoss> lool, just asking :)
[12:20] <lool> tvoss: I usually get a GPS fix reliably when standing on my balcony for <1mn
[12:20] <Mirv> I go to espoo today...
[12:20] <lool> I put the phone in a relatively open place
[12:20] <lool> it's a bit cloudy, but it's been worse
[12:21] <tvoss> lool, okay, let me recheck
[12:23] <lool> tvoss: oh wait
[12:23] <lool> tvoss: stupid me
[12:23] <lool> tvoss: I need to change the location-service flags in lxc-android-config
[12:24] <tvoss> lool, ack
[12:24] <lool> tvoss: do we still want the sleep 10?
[12:25] <tvoss> lool, let's try without
[12:26] <lool> tvoss: how do you start the gps provider?
[12:26] <lool> tvoss: we need to add an upstart job for it
[12:27] <tvoss> lool, I did not split it out, yet
[12:27] <tvoss> lool, let's keep that for after this landing
[12:27] <tvoss> lool, one by one :)
[12:27] <lool> tvoss: ah then I'm confused; am I supposed to update the flags then?
[12:27] <tvoss> lool, nope
[12:27] <lool> tvoss: ok, then it doesn't work right now
[12:27] <tvoss> lool, if you already have the gps provider in the config again
[12:27] <lool> I do
[12:27] <ogra_> === IMAGE Krillin 14.09 #5 Promoted ===
[12:27] <tvoss> lool, rechecking here
[12:28] <ogra_> sil2100, asac ^^
[12:28] <tvoss> lool, could you check /data/misc, please?
[12:28] <olli> ogra_, which image is that
[12:28] <lool> tvoss: hmm something is wrong, I think I have the wrong lxc-android-config
[12:28] <olli> 114?
[12:28] <lool> tvoss: need to reinstall it
[12:30] <ogra_> olli, yep
[12:30] <olli> ogra_, all tested and stuff?
[12:30] <olli> awesome
[12:30] <ogra_> yeah
[12:30] <olli> nice to be waking up to something like that
[12:30] <ogra_> and coordinated with victor and asac
[12:30] <sil2100> Yep
[12:30] <olli> thanks everyone
[12:30] <ogra_> 114 is a beauty !
[12:31] <sil2100> olli: we'll have another promotion once the mako/flo bits are fixed
[12:31]  * sil2100 is really happy about 114 too
[12:31] <olli> nice
[12:31] <ogra_> right, the hectic of krillin sadly broke the rest
[12:31] <ogra_> just one missing merge though
[12:31] <ogra_> (the the rrespective other device tarballs)
[12:33] <lool> tvoss: everything works  \o/
[12:33] <kgunn> ogra_: sil2100 we're ok now?
[12:34] <tvoss> lool, same here :)
[12:34] <lool> tvoss: webapps, web browser, osmtouch -- with gps fix
[12:34] <tvoss> lool, yup
[12:34]  * kgunn read a bunch of scroll back
[12:34] <lool> that's on krillin
[12:34] <ogra_> kgunn, seems dednick has some improvement, but we went ahead with what we had
[12:34] <kgunn> ogra_: yeah, was wondering if there was another hold up to get a more "professional" fix :)
[12:34] <ogra_> kgunn, so *we* are good, your team might still want to sort some code out later though
[12:34] <lool> tvoss: building silo 4 to pick up silo 6's packages
[12:34] <Mirv> promotion \o/
[12:34] <ogra_> :D
[12:34] <tvoss> lool, just pointing out that I see some test flakiness
[12:35] <lool> tvoss: ah hold on, some ftbfses there
[12:35] <lool> tvoss: right
[12:35] <tvoss> lool, yup
[12:35] <tvoss> lool, on it
[12:35] <lool> ok
[12:36] <sergiusens> Mirv: sil2100 seb128 hey rtm silo 17 shouldn't be needed with what was landed yesterday in rtm silo 8; feel free to double check
[12:36] <sergiusens> but if it's to address LP: #1378941 ... then that's already in
[12:36] <ubot5> Launchpad bug 1378941 in indicator-transfer (Ubuntu RTM) "Unity 8 crashes when downloading zip albums from 7digital" [Critical,Fix released] https://launchpad.net/bugs/1378941
[12:37] <Mirv> seb128 can double-check and free the silo
[12:38] <Mirv> (or mark the line as "please remove")
[12:48] <dbarth> Mirv: hey, is there a place where i can find the mediahub packages to revert to?
[12:50] <dbarth> lool: are there fixes you need applied to our packages?
[12:51] <lool> dbarth: you mean web stack? nope
[12:52] <lool> dbarth: FYI I'm hitting an unimplemented code path fairly often; I dont know whether that's planned for oxide, but it does trigger warnings regularly
[12:57] <dbarth> lool: which warnings?
[12:59] <Mirv> dbarth: I posted the instructions to the mailing list.
[12:59] <Mirv> (ubuntu-phone)
[13:00] <lool> dbarth: I'm trying to grab them, sorry, had been distracted
[13:02] <lool> dbarth: [1017/123311:ERROR:oxide_access_token_store.cc(30)] Not implemented reached in virtual void oxide::AccessTokenStore::LoadAccessTokens(const LoadAccessTokensCallbackType&)^M
[13:02] <dbarth> Mirv: oops, seeing them now; thanks
[13:02] <lool> dbarth: I'm getting this in webapps and webbrowser
[13:02] <lool> dbarth: things seem to work though, I dont know what that implies
[13:03] <dbarth> lool: ok
=== karni is now known as karni-lunch
[13:33] <seb128> sergiusens, Mirv, thanks, silo cleaned
[14:27] <Laney> lool: turned out that it was because it was parsing /etc/dput.cf ...
[14:30] <brendand> pstolowski, if you're around, i'm trying to land silo 003 again, but it only seems to fix half the problem described in https://launchpad.net/bugs/1380588
[14:30] <ubot5> Ubuntu bug 1380588 in unity-scopes-api (Ubuntu RTM) "Results blank after reboot when scope is signed in to OA" [Critical,In progress]
[14:31] <brendand> pstolowski, actually maybe i'm asking the wrong person - seems you aren't on the list of landers
[14:31] <brendand> thostr_, ^
[14:34] <pstolowski> brendand, unfortunately marcus who created the fix isn't around anymore (he starts his travel to the sprint) and i'm not familiar enough with this area to look into it
[14:34] <brendand> pstolowski, yeah that's ok
=== karni-lunch is now known as karni
[14:51] <asac> ogra_: sil2100: what is the version of promoted 114 image?
[14:52] <sil2100> asac: #5 in the 14.09 channel for krillin
[14:53] <ogra_> asac, what he said
[15:07] <dbarth> sil2100: that mako fix, is there a silo we can take it from?
[15:08] <dbarth> i would like to confirm that the regression i saw with OA trust prompts (on mako) is due to that
[15:15] <sil2100> dbarth: not really... as it's an issue with device and android bits missing
[15:15] <sil2100> dbarth: for now the only safe way is to just revert media-hub
[15:22] <dbarth> sil2100: right, i did that, but now i'm seeing regressions in trust prompts, ie none of the online accounts or trust store prompts seem to work properly
[15:23] <dbarth> anyway, i can wait or switch back to utopic on that device, that's ok
[15:28] <pmcgowan> rsalveti, any idea why dbarth is seeing that regression? ^^
[15:28] <ogra_> the online accounts regression ?
[15:29] <pmcgowan> ogra_, yes
[15:29] <dbarth> on mako rtm (#96), the trust prompts for OA they suddenly start a whole OA "app"
[15:29] <dbarth> and i don't see prompts either for the location service
[15:29] <ogra_> tvoss, ^^^^ any idea ?
[15:30] <ogra_> location only prompts once per app
[15:30] <ogra_> if you ever allowed it it keeps that setting
[15:30] <dbarth> hmm, true; i should clear the DB
[15:32] <ogra_> rsalveti, ^^ stop using booleans !
[15:32]  * rsalveti trying
[15:32] <ogra_> :)
[15:32] <rsalveti> failed again
[15:32] <rsalveti> wtf
[15:33] <rsalveti> sil2100: need your help :-)
[15:33] <rsalveti> https://ci-train.ubuntu.com/job/ubuntu-landing-008-2-publish/41/console
[15:37] <tvoss> ogra_, no idea :) fixed?
[15:37] <ogra_> lol
[15:37] <ogra_> TGIF
[15:37] <dbarth> tvoss: somehow
[15:37] <dbarth> tvoss: i see the prompts, once i wipe trust.db
[15:37] <dbarth> tvoss: but if i toggle permission from USS
[15:37] <tvoss> dbarth, okay, that is expected
[15:38] <dbarth> the app still gets access, as the location service seems to cache the permission
[15:38] <dbarth> ie, trust.db contains a series of 0, 1, 0, 1 when i toggle the switch
[15:39] <dbarth> but ubuntu-location-service-trust-stored.log says that's a cached request
[15:39] <tvoss> dbarth, ah, that's interesting. you only delete the most recent one I would guess
[15:39] <dbarth> i remove the trust.db file alltogether
[15:39] <dbarth> but didn't restart the service
[15:39] <dbarth> if that forces it into a fallback mode (my db was killed, so i run on cache ?)
[15:39] <Ursinha> sil2100: I think a bug might have been introduced in citrain/publisher.py by r780
[15:40] <Ursinha> sil2100: https://ci-train.ubuntu.com/job/ubuntu-landing-008-2-publish/42/console
[15:41] <Ursinha> citrain/publisher.py L246, silo_state.is_publishing is a property and it's being called
[15:44] <bfiller> robru, sil2100: I need a silo for line 55 please
[15:46] <Ursinha> sil2100, robru: https://code.launchpad.net/~ursinha/cupstream2distro/fix-is-publishing-being-called/+merge/238738
[15:47] <Ursinha> ridiculous fix, prepared that as it's probably easier to get the fix in production sooner via MP (automated ways, etc)
[15:53] <ogra_> sil2100, android landed, firing off a build
[15:53] <kenvandine> woot
[15:58] <nik90> yay
[15:59] <imgbot> === trainguards: RTM IMAGE 115 building (started: 20141017 16:00) ===
[16:00] <sil2100> Ursinha: hey ;)
[16:01] <sil2100> Ursinha: ah, crap!
[16:01] <sil2100> Right, damn, such a stupid mistake
[16:01] <sil2100> rsalveti: this will be fix as soon as it gets merged
[16:01] <sil2100> Should be any inute now
[16:01] <sil2100> *minute
[16:05] <rsalveti> sil2100: no worries, I decided to just go ahead and manually copy to the archive
=== karni is now known as karni-eod
[16:11] <bfiller> sil2100: actually scratch last request, need a silo for line 48 which is the same request that has been there for some days
[16:12] <rsalveti> sil2100: I don't think appending ~rtm will solve the issue you described in the email
[16:13] <rsalveti> the issue is one thing, identifying the issue is another different thing
[16:13] <rsalveti> the issue can still happen
[16:13] <elopio> ping kgunn: can you plesae take a look at https://bugs.launchpad.net/qtmir/+bug/1382414 ?
[16:13] <ubot5> Ubuntu bug 1382414 in QtMir "New qtmir makes UITK AP tests fail" [Undecided,New]
[16:15] <kgunn> elopio: ack, likely won't get much love until monday
[16:16] <Ursinha> sil2100: just to clarify, what I called ridiculous was having one MP for such a small change, not the problem itself :)
[16:17] <elopio> kgunn: yes, I supposed that :) I don't think bzoltan's planning a release today anyway. But maybe during the sprint we can talk about ways for mir to not break higher level tests.
[16:17] <elopio> It would be perfect if we make the toolkit tests autopkgtests, so they run as a reverse dep when mir lands, but we are a little far from that.
[16:17] <elopio> so the alternative for now (I think) would be to run the toolkit tests as part of the mir release test plan. At least a subset.
[16:19] <kgunn> elopio: i would trade having to do that if others ran the unity8 AP test also :)
[16:25] <elopio> kgunn: the sdk does run unity8 tests. So who else would you like to run them? We can certainly add that to their test plan.
[16:25] <brendand> ogra_, saw what you mean now
[16:26] <ogra_> brendand, cool
[16:27] <brendand> ogra_, bug # yet?
[16:27] <ogra_> nope, didnt file it yet
[16:28] <brendand> ogra_, usually when i reboot the phone i go and do something else - not looking at the screen :)
[16:28] <brendand> ogra_, i'll file you a bug
[16:29] <brendand> ogra_, or actually maybe rhuddie filed one since he mentioned seeing it
[16:29] <ogra_> right, thats why i asked :)
[16:37] <sil2100> bfiller: sure! Assigning
[16:42] <bfiller> sil2100: thanks
[16:58] <kgunn_> elopio: is the uitk AP faililng on rtm or utopic ? or both ?
[16:58] <kgunn_> hard to keep up with image #'s
[17:00] <elopio> kgunn_: they are failing on their MPs, so I think on both.
[17:00] <elopio> but haven't run the tests myself this week.
[17:00] <kgunn_> elopio: ta...hmm...ok, so very few things changed on qtmir -rtm
[17:02] <kgunn_> hmm....this looks like the only commit that might effect those tests
[17:02] <kgunn_> http://bazaar.launchpad.net/~mir-team/qtmir/rtm-14.09/revision/268
[17:04] <elopio> kgunn_: there was something from the qml cache that made all the other tests fail too, right? I think I heard about it, but I've lost touch with automation.
[17:04] <elopio> plars: ^ ?
[17:05] <kgunn_> i didn't catch all the details either
[17:05] <plars> elopio: rtm on mako fails to come up right now, is that what you're referring to?
[17:06] <plars> elopio: there's a new image building now that I think is supposed to fix it
[17:06] <elopio> plars: no, I'm wondering if you remember about a fix to make the autopilot tests pass after the qml cache was introduced.
[17:07] <plars> elopio: no, I'm not familiar with that, when was this?
[17:08] <elopio> I'm not sure. I'm having a brain overload.
[17:09] <elopio> ricmm or brendand: I think I saw a silo for qml cache that broke autopilot tests. Do you know about it? Or am I in a mistake?
[17:09] <kgunn_> hmmm....so how the hell did this get into qtmir/rtm
[17:09] <kgunn_> https://code.launchpad.net/~ricmm/qtmir/clean-cache-on-failed/+merge/238077
[17:09] <kgunn_> it's not approved
[17:10]  * kgunn_ is confused
[17:19] <imgbot> === trainguards: RTM IMAGE 115 DONE (finished: 20141017 17:20) ===
[17:19] <imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/115.changes ===
[17:20] <sil2100> \o/
[17:20] <sil2100> Can we get anyone with a mako confirming if this works? ^
[17:21] <nik90> does this need QA to promote considering that its krillin counterpart was heavily tested?
[17:21] <sil2100> elopio: do you have a mako with ubuntu-rtm installed on it?
[17:21] <sil2100> nik90: we just need someone to do a quick dogfooding run, making sure it works and nothing is obviously busted
[17:21] <sil2100> So I would say around 15 minutes of play time on it
[17:21] <nik90> cool
[17:25] <sil2100> elopio: ^ :)
[17:26]  * ogra_ only has an ubuntu mako :(
[17:36] <elopio> sil2100: I can flash it.
[17:37] <elopio> I'll just need some time to disassemble it because I think I've put the volume buttons backwards, and it's stuck on the previous wrong image.
[17:42] <nik90>  elopio how do you remove the volume buttons in the first place ;)
[17:42] <nik90> s/do/did
[17:43] <elopio> nik90: first, you have to break your screen.
[17:43] <nik90> lol
[17:49] <elopio> I'm not sure what's wrong with my buttons, but it's now flahsing.
[17:49] <elopio> sil2100: image #97, is that right?
[17:49] <sil2100> hmmmm
[17:50] <sil2100> elopio: I think yes
[17:53] <pmcgowan> sil2100, have we opened up landings yet?
[17:53] <pmcgowan> or is that pending 115
[17:56] <bzoltan> elopio:  correct, UITK release is not scheduled for today. My last tests are stil running anyway
[17:57] <ogra_> pmcgowan, we need to see that 115 at least boots
[17:57] <pmcgowan> ogra_, I can update if you promise it does
[17:58] <ogra_> cant promise that ... rsalveti can :)
[17:58] <kenvandine> it boots on my krillin :)
[17:58] <jhodapp> sil2100, I'd like to land rtm silo 16, can we do that yet?
[18:00] <sil2100> Once we get confirmation that 115 works, we open up the gates :)
[18:01] <ogra_> kenvandine, lol, how did you make the mako image boot on your krillin ?
[18:01] <ogra_> :)
[18:02] <kenvandine> ogra_, i've got skillz :)
[18:02] <ogra_> LOL
[18:04] <elopio> for now, it's just showing the google logo.
[18:04] <elopio> spinning ubuntu logo now...
[18:04] <ogra_> \o/
[18:05] <elopio> and the wizard
[18:05] <ogra_> thats enough ... :)
[18:05] <ogra_> right, session starts ... that was broken
[18:06] <elopio> and I fixed my volume buttons \o/
[18:06] <elopio> tomorrow I'll try to fix the roof myself.
[18:07] <ogra_> geez !
[18:07] <kenvandine> :)
[18:07]  * ogra_ recommends buckets :)
[18:07] <ogra_> as a fallback
[18:07] <kenvandine> and towels
[18:08] <ogra_> towels ++
[18:08] <elopio> :)
[18:08] <elopio> I'll be prepared with a couple of band-aids.
[18:20] <sil2100> ogra_: I think this means we promote, right? :)
[18:22] <sil2100> ogra_: ...right? :)
[18:23] <kenvandine> sil2100, this is getting exciting!
[18:25] <nik90> sil2100, ogra_ : let's go :) ...
[18:25]  * nik90 checks his phone for update
[18:34]  * sil2100 looks at ogra_ 
[18:41] <ogra_> oops, sorry
[18:43] <ogra_> promotion running
[18:43] <sil2100> \o/
[18:43] <sil2100> Thank you everyone!
[18:44] <kenvandine> woot
[18:44] <kenvandine> so landings are open?
[18:45] <ogra_> sil2100, did anyone check the emulator ?
[18:45] <sil2100> ugh
[18:45] <sil2100> No
[18:45] <kenvandine> oh my :-D
=== sil2100 changed the topic of #ubuntu-ci-eng to: Need a silo? Ping train support: trainguards | Need help with something else? Ping vanguard: cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: robru broke 3 ribs
[18:46] <kenvandine> wow... robru broke 3 ribs!
[18:46] <ogra_> yeah
[18:46] <ogra_> thats why he wont come :(
[18:47] <kenvandine> poor robru!
[18:50] <robru> kenvandine: thanks. Zero stars, would not recommend
[18:51] <cyphermox> yeah, dude, get better :)
[18:55] <sil2100> I go to the cinema now, be back later o/
[18:58] <ogra_> === Image #5 promoted for mako (from 97) #4 for generic and generic_x86 (from 91) ===
[19:01] <cwayne> ogra_: :D
[19:17] <pmcgowan> ogra_, yay so are we landing again
[19:29] <ricmm> elopio: hey, have you actually confirmed this as breaking autopilot tests for UITK ?
[19:29] <ricmm> and by confirmed I mean tried the version after and before
[19:30] <ricmm> I thought the breakage was introduced with 15-rtm0
[19:32] <ricmm> kgunn_: same question for you
[19:32] <kenvandine> humm... how do we sync packages from rtm to utopic now?
[19:32] <kenvandine> without the ~rtm in the version?
[19:32] <kenvandine> robru, ^^
[19:36] <robru> kenvandine: i don't think that's possible, the code was only ever written with utopic->rtm in mind. The default binary copy doesn't change versions.
[19:36] <kenvandine> i told it to rebuild
[19:36] <kenvandine> it now appends the ~rtm on rtm landings
[19:37] <robru> kenvandine: that is to say, I'm not aware of any code that will strip ~rtm from the version, only add it. sil2100 made some changes there recently
[19:38] <dobey> robru: oh, ouch! (just read about the ribs)
[19:39] <ricmm> bzoltan: are you there?
[19:39] <robru> dobey: thanks
[19:39] <robru> kenvandine: is it really a problem for the utopic version to say ~rtm in it? I think that's fine as it will indicate it's a sync from rtm
[19:39] <kenvandine> bfiller, have you synced anything from rtm to utopic since the ~rtm got added again?
[19:40] <kenvandine> i guess :)
[19:40] <robru> kenvandine: i recommend binary copies where possible, now that we super those
[19:40] <robru> Support those
[19:42] <ricmm> kgunn_: elopio I'm only asking because the bug says that UITK tested ok with RTM 106
[19:43] <ricmm> which contains the MR you are pointing as culprit
[19:45] <elopio> ricmm: bzoltan was doing the testing. And maybe kgunn_ got the wrong changelog. Next week we will have to dig deeper.
[19:46] <ricmm> I was trying to look at the uitk branches
[19:46] <ricmm> but theres about 1000 of them, with staging and so on
[19:46] <ricmm> elopio: what branch exactly is failing and what landing does it refer to?
[19:46] <ricmm> I can maybe try it before monday
[19:46] <ricmm> if you are not going to
[19:48] <rsalveti> sil2100: ogra_: is mako ok again?
[19:48] <rsalveti> will flash
[19:50] <bfiller> kenvandine: there is a flag to disable that ~rtm thing I think
[19:50] <bfiller> kenvandine: or it might be disabled by default now
[19:50] <kenvandine> it was disabled by default
[19:50] <kenvandine> but it just got switched again
[19:50] <kenvandine> and it says to get permission from the landing team to check it
[19:51] <kenvandine> so i'm just trying to get a feel for the best way to handle it now
[19:52] <elopio> ricmm: I'm not going to work on it before next week.
[19:52] <elopio> ricmm: here are the results by bzoltan: http://people.canonical.com/~bzoltan/UITK-AP-FAILURES-106-107/
[19:52] <elopio> https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1381165 has a link to a list of failed MPs.
[19:52] <ubot5> Ubuntu bug 1381165 in Ubuntu UI Toolkit "A lot of AP tests randomly fail" [Critical,Confirmed]
[19:53] <elopio> I would say that bzoltan was running trunk. But I'm not sure about that.
[20:55] <ogra_> rsalveti, yeah