[06:50] <bzoltan> sil2100: I have one last failing test here -> https://requests.ci-train.ubuntu.com/static/britney/ticket-1511/vivid/excuses.html should pass after retry
[06:50] <sil2100> o/
[06:51] <sil2100> bzoltan: let me try re-running, internet here is terrible
[06:51] <bzoltan> sil2100: thank you
[06:51] <sil2100> bzoltan: ok, recycled (it seems), yw!
[07:37] <bzoltan> sil2100: Do you remember why Timo has suggested to do triple landing for the UITK. He must had some good reason.
[07:46] <sil2100> bzoltan: I guess it's because it's the default thing to do, per requirement
[07:47] <sil2100> bzoltan: do you have any other propositions? :)
[07:53] <bzoltan> sil2100:  i do not... I am happy with the tripple landing, because it gives me clear visibility on how the UITK builds on Yakketi. But QA are unhappy about the fact that i had to disable the unit tests on Yakketi. Qt is newer on Yakketi and because of this we have failing tests.
[07:55] <sil2100> Ah, eh... yeah, the biggest issue with triple landing everywhere is that you have to somehow support 3 distros at once, make sure they're all good
[07:55] <sil2100> bzoltan: did you guys disable only for yakkety? i.e. are those running for xenial/vivid still?
[07:57] <bzoltan> sil2100:  of course we have disabled it only for Yakketi. We do run all the tests on Vivid and on Xenial.
[07:58] <sil2100> bzoltan: ok, good - how many tests had to be disabled? All of them, or just parts?
[07:58] <sil2100> I could check that myself but the internet is so slow here ;)
[08:02] <bzoltan> sil2100:  I simple disabled all the unit tests on Yakketi.  Yakketi is not released, not an official target and there is no supported device out there with Yakketi. At this stage we are happy that UITK builds on Yakketi and I wish to keep my eyes on the Yakketi buildsű
[08:04] <sil2100> Yeah, I suppose it's feasible for now
[08:05] <sil2100> We just don't want to have the devel series without unit tests forever ;)
[08:14] <bzoltan> sil2100:  Yes, of course. But I hope the QA team will understand that it is not like "yeah, we have added some code what makes tests fail, so we disabled the tests". It is simple because the Qt is newer on Yakketi and we have to invest couple of weeks to investigate the reason and polish together the Qt and UITK.  It is exacty what we have done since 5.0 Qt many times. But the first step is to build the packages...
[08:23] <sil2100> bzoltan: yeah, I wouldn't directly block on that right now at least, as long as there's commitment to get it working soon (with a bug and assigmnent etc.)
[08:27] <bzoltan> sil2100: definetly there is commitment. This is the bug - https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1591908 And i will look after it once we are good with the OTA12
[08:27] <sil2100> bzoltan: excellent, good enough for me :)
[08:27] <sil2100> Thanks!
[09:55] <pstolowski> rvr, hey, there are a couple of autpkg failures in silo 65 for unity8 on xenial which look like flaky tests to me, they seem completely unrelated to my recent changes; unfortunately it seems Saviq's team is still recovering from the sprint, not sure if they are going to be online today to check & confirm
[09:57] <rvr> pstolowski: Ok
[11:29] <Trevinho> robru: it would be a nice addition, but will the auto-updating build page (jenkins style) page be back in the future?
[11:30] <robru> Trevinho: you mean live-streaming the log output?
[11:30] <Trevinho> robru: yeah
[11:30] <robru> Trevinho: yeah that is planned. I actually had one implementation already but I had to cut it at the last second because it was buggy
[11:30] <Trevinho> ah i see
[11:31] <robru> Trevinho: probably I'll implement git support before going back and making the logs stream.
[11:31] <Trevinho> yeah, that's definitely higher priority
[11:32] <Trevinho> robru: oh, just noticed a thing...
[11:33] <robru> Trevinho: yeah?
[11:33] <Trevinho> robru: I changed the commit message for a MP, and once I rebuilt the pkg, it did't get updated
[11:33] <Trevinho> robru: no, wait...
[11:33] <robru> Trevinho: is this another case of you running two builds really quickly back to back?
[11:34] <Trevinho> robru: no, I just was checking wrong build :-), sorry
[11:34] <robru> Trevinho: no worries.
[11:34] <robru> Trevinho: you can always check at https://code.launchpad.net/~ci-train-bot to see what the latest build committed.
[11:37] <Trevinho> robru: you might want to see this audit log, though https://requests.ci-train.ubuntu.com/#/ticket/1482#audit_log not sure you want to show the error in that way
[11:37] <robru> Trevinho: yeah there's a bug for that already, thanks
[11:45] <dbarth> rvr: i approved the branches in silo 39
[11:45] <rvr> dbarth: Great, thanks
[12:34] <cjwatson> robru: I might have accidentally got excited at the weekend and implemented 75% or so of bug/MP linking for git
[12:35] <robru> cjwatson: haha awesome
[12:35] <robru> cjwatson: in the MPs?
[12:35] <sil2100> \o/
[12:36] <cjwatson> yeah, the idea is that you can link bugs directly to MPs; in the bzr case that'll actually add a link to the source branch for compatibility etc., in the git case it'll store a link between the bug and the MP directly
[12:36] <robru> cjwatson: you'll have to send me some API overview for when I finally get a chance to start git support.
[12:36] <cjwatson> and git MPs will automatically scan the commits between target and source for LP: references in the commit messages like in changelogs
[12:36] <robru> oh snap
[12:36] <robru> nice
[12:37] <cjwatson> robru: once I land this I think you can just change merge.source_branch.linked_bugs to merge.linked_bugs and it'll work for both
[12:38] <robru> cjwatson: oh, amazing. thanks
[12:38] <cjwatson> robru: haven't got it up for review yet, I need to do the boring bits like tests and debugging the UI into existence :)
[12:38] <robru> cjwatson: boooooring!
[12:38]  * cjwatson is a naughty boy and doesn't tend to do TDD for complicated things
[12:38] <robru> cjwatson: I have a very sophisticated test suite called "end users"
[12:39] <cjwatson> oh, we have a very sophisticated test suite, I just don't always do the fancy thing where you exhibit a failing test first :)
[12:40] <robru> cjwatson: heh, yeah, me too.
[12:40] <sil2100> Testing is overrated, cowboying things direct-to-production is more like it
[12:40] <sil2100> Faith in our code is all we need!
[12:40] <cjwatson> anyway, 1400 lines of diff at the moment, so will probably turn into about three or four branches
[12:43] <robru> cjwatson: oh no way, whenever my branch goes over 1,000 lines I just get barry to review it. hehehe
[12:49] <cjwatson> robru: LP prefers <=800 lines per review where we can manage it
[12:50] <robru> cjwatson: well that seems sensible as long as you can divide your work into bite-size chunks
[14:10] <kenvandine> rvr, the autopkgtest failure for silo 22 is unity8, not related to this landing.  Can you get silo 22 in ready for QA please?
[14:25] <rvr> kenvandine: pstolowski: tsdgeos: I see there are common unity8 failures in silo 22 and in silo 65.
[14:26] <rvr> mzanetti: ping
[14:27] <kenvandine> rvr, yeah... not uncommon, lately it seems we see that on all of our settings landings
[14:28] <pstolowski> rvr, kenvandine according to tsdgeos these tests are not very stable.. and i suppose mzanetti is recovering from the sprint
[14:28] <tsdgeos> he's on holiday
[14:29] <pstolowski> ah ok
[14:29] <tsdgeos> will be bck ~wed ~thu afair
[14:29] <rvr> pstolowski: I was pinging him for silo 29, not related :D
[14:29] <rvr> But thanks
[14:29] <pstolowski> k :)
[14:36] <rvr> tsdgeos: Can you take a look to those recurring failing tests?
[14:37] <rvr> marcustomlinson: ping
[14:37] <marcustomlinson> rvr: pong
[14:38] <rvr> marcustomlinson: Hi. I'm testing silo 29
[14:38] <rvr> marcustomlinson: "add libertine-scope to the list of exceptions that can directly activate things"
[14:38] <marcustomlinson> rvr: I'm really sorry, I had to abandon that one
[14:38] <marcustomlinson> rvr: pstolowski landed that change in silo 1
[14:38] <rvr> marcustomlinson: Oh
[14:39] <marcustomlinson> rvr: I'm really sorry. That was a communication fail
[14:39] <rvr> Meh, we should update the trello bot to catch up with abandon silos
[14:39] <tsdgeos> rvr: doesn't look very recurring to me, at least the ones that pstolowski showed me before were not consistent on errors of amd64 vs intel
[14:39] <marcustomlinson> rvr: oh, it's not landed there yet. https://requests.ci-train.ubuntu.com/#/ticket/1515
[14:39] <rvr> tsdgeos: I see common failures in silo 65 and 22
[14:39] <tsdgeos> rvr: can you point me at the logs?
[14:40] <marcustomlinson> rvr: I guess pstolowski is still testing it
[14:40] <rvr> I had a reboot and lost my notes, let me check
[14:40] <rvr> marcustomlinson: Ok, no problem
[14:40] <kenvandine> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-022/xenial/amd64/u/unity8/20160610_204542@/log.gz
[14:40] <pstolowski> marcustomlinson, rvr silo 1 needs to wait for silo 65
[14:40] <pstolowski> so i'm not testing it yet
[14:40] <marcustomlinson> ok
[14:40] <kenvandine> tsdgeos, ^^
[14:40] <rvr> Yeah, search for XFAIL
[14:41] <kenvandine> tsdgeos, yakkety and vivid passed
[14:41] <tsdgeos> rvr: xfail is not a fail
[14:41] <rvr> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-065/xenial/amd64/u/unity8/20160613_091148@/log.gz
[14:41] <tsdgeos> rvr: you know that right?
[14:42] <rvr> tsdgeos: Argh :-/
[14:42] <tsdgeos> fail!
[14:42] <tsdgeos> is a failure
[14:42] <tsdgeos> xfail is expected fail
[14:42] <tsdgeos> and is good
[14:43] <kenvandine> FAIL!  : qmltestrunner::PhoneStage::test_selectAppFromSpread(App 3) property state
[14:43] <kenvandine>    Actual   (): 2
[14:43] <kenvandine>    Expected (): 1
[14:43] <kenvandine>    Loc: [/tmp/autopkgtest.eomPQZ/build.LIN/unity8-8.12+16.04.20160527/tests/qmltests/Stages/tst_PhoneStage.qml(113)]
[14:43] <rvr> tsdgeos: Yeah, sorry. Too much time doing manual tests :-(
[14:44] <kenvandine> that test has nothing to do with system-settings, for example
[14:44] <rvr> FAIL!  : qmltestrunner::PhoneStage::test_selectAppFromSpread(App 3)
[14:45] <kenvandine> so it shouldn't hold up a settings silo
[14:45] <rvr> That one is in 22 and 65
[14:46] <tsdgeos> kenvandine: i already said that
[14:46] <tsdgeos> i can say it again
[14:46] <tsdgeos> if it helps :D
[14:46] <kenvandine> sorry, i missed that part :)
[14:46] <tsdgeos> i told that to pstolowski this morning in a different hcannel
[14:46] <tsdgeos> not here
[14:49] <tsdgeos> i'm going to try to reproduce/stabilize it anyway
[14:49] <rvr> tsdgeos: Great, thanks
[14:52] <rvr> sil2100: Do you know which spell to use in order for a silo with a failed Automated Signoff to be set as QA Signoff Ready? jibel is not available today.
[14:57] <sil2100> rvr: hmmm, one moment, let me think
[14:58] <sil2100> (and check logs)
[15:04] <sil2100> rvr: which silo was that?
[15:05] <rvr> sil2100: 22 and 65
[15:07] <sil2100> Damn, can't find that log
[15:08] <sil2100> rvr: ok, I think I did it
[15:08] <sil2100> Not sure if that's the way to do it, for 22
[15:08] <kenvandine> sil2100, thanks!
[15:08] <sil2100> rvr: 22 is now 'Ready'
[15:08] <rvr> sil2100: Yeah, seems so
[15:08] <sil2100> rvr: what I did is: "I cleared the Lander signoff and then put it to Approved again, and then changed QA signoff"
[15:09] <sil2100> rvr: ^ ignore that 'Approved', a miss-click from my side
[15:09] <sil2100> rvr: try that for 65
[15:10] <rvr> sil2100: Hmm... the automated signoff is queued, so it may fail later
[15:10] <sil2100> Yeah, but the QA sign-off is set, it won't reset it
[15:10] <rvr> sil2100: But I think at least the card will appear
[15:10] <sil2100> (from what I know)
[15:10] <rvr> sil2100: Ah
[15:10] <sil2100> Anyway, I go EOD now since it's dinner time here
[15:11] <sil2100> (sprinting)
[15:48] <pstolowski> rvr, silo 65 still blocked on your dashboard?
[15:49] <rvr> pstolowski: Didn't receive a new card
[15:49] <rvr> Let me see now
[16:08] <pstolowski> rvr, thanks!
[17:46] <robru> rvr: sil: no you need to put "https://foo" into the manual downloads field then bileto releases control of the qa field and you can set it to whatever
[17:47] <dobey> robru: ^^ "PPA/bzr version mismatch" huh?
[17:48] <robru> dobey: did you just build? Usually that sorts itself out after 15 minutes
[17:48] <dobey> robru: yeah
[17:49] <robru> dobey: it means the ppa contents doesn't match what's it pushed to lp bzr, which could be indicative of a ppa upload failure, but it's racy
[17:50] <dobey> robru: right, that's why i'm confused. the PPA upload worked and is building, and the version number looks right to me :)
[17:51] <robru> dobey: so it'll fix itself on the next run, which is every 15 mins.
[17:51] <dobey> ok
[18:57] <bzoltan> robru:  that unity8 there here https://requests.ci-train.ubuntu.com/static/britney/ticket-1511/xenial/excuses.html seems to be running for aaaaages. Do you know somebody who could check if it is alive?
[18:59] <robru> bzoltan: if you click "test in progress" and grep for the silo name you can see
[19:00] <dobey> http://autopkgtest.ubuntu.com/running.shtml#pkg-unity8
[19:04] <robru> bzoltan: so it isn't running. Ping pitti