[00:36] <robru> jhodapp: ^^ time to rebuild in case you missed that
[00:36] <robru> jhodapp: also maybe ask koza to join this chat room so he can see the notices
[00:36] <jhodapp> robru, yeah indeed, thanks
[00:37] <robru> jhodapp: you're welcome
[03:27] <bzoltan> robru: would you plese restart these flaky unity8 tests -> https://requests.ci-train.ubuntu.com/static/britney/ticket-1511/yakkety/excuses.htmlhttps://requests.ci-train.ubuntu.com/static/britney/ticket-1511/vivid/excuses.html
[03:28] <robru> bzoltan: sorry, you need somebody from #ubuntu-release
[03:28] <bzoltan> Saviq: these tests are more flaky then before. On xenial they are OK and they can be OK on Viviv and Yakketi too.
[03:28] <robru> bzoltan: or any core dev. I can't do it
[04:21] <bzoltan> robru: I see, thanks
[04:22] <bzoltan> jibel: I would like the QA team to take the silo14 in the queue - https://requests.ci-train.ubuntu.com/#/ticket/1511 The tests ar all fine. I think it is not a good idea to block the silos with the autopkg tests as 99% of the failures are caused bz flaky tests.
[04:23] <robru> bzoltan: britney tests other things than just autopkgtests so it's an important check to do, but fine to override on a case by case basis. saves QA a lot of time having to validate something that goes on to get stuck in -proposed.
[04:25] <bzoltan> robru: The same tests passed on the same silo a day before ... the same tests pass on amd64 and fail on i386... the same tests pass fail 1 out of 3 runs on xenial and 4 time sout 5 on vivid .. but totally inconsistently.
[04:26] <bzoltan> robru:  bad quality tests are waste of time to all.. to QA and to us too. These autopkg tests are known to be super flaky ... I would propose to make them a blocker for passing QA and not _ENTERING_ the QA queue.
[04:27] <bzoltan> robru:  Once a silo enters QA queue it usually spends two days before somebody picks up... that two days would be perfectly enough to click retry like five times and get a full green britney result
[04:27] <bzoltan> jibel: ^
[04:28] <bzoltan> We are loosing valuable time with this problem :(
[07:33] <jibel> bzoltan, flaky tests in unity8 were supposed to be fixed
[07:34] <jibel> Saviq, ^ https://requests.ci-train.ubuntu.com/static/britney/ticket-1511/vivid/excuses.html
[07:36] <jibel> bzoltan, someone from the unity8 team has to have a look first and understand why it's failing before forcing anything
[10:02] <bzoltan> jibel: what I propose is that we change the process and instead of waiting and waiting and waiting ... we start doing the QA validation and in the meantime we investigate the flakiness. It is flakiness for sure... a stable test does not randomly fail and pass
[10:03] <bzoltan> jibel: and i have been strugling with these britney flakinesses for long time.. it simple wastes time, lots of it. So I am not happy to be blocked by it.
[10:07] <jibel> bzoltan, and then waste time of manual testers if it's a real problem.
[10:08] <bzoltan> jibel: it is not a real problem... look at the excuses page. How it could be a real problem?
[10:09] <bzoltan> jibel:  look. Xenial - https://requests.ci-train.ubuntu.com/static/britney/ticket-1511/xenial/excuses.html
[10:09] <bzoltan> jibel:  full OK
[10:09] <jibel> bzoltan, I agree flaky tests are a problem and are usually caused by bad tests, code or infrastructure but in any case they must be analyzed and fixed.
[10:09] <bzoltan> jibel:  Yakketi - amd64 passes, i386 fails - https://requests.ci-train.ubuntu.com/static/britney/ticket-1511/yakkety/excuses.html
[10:10] <bzoltan> jibel: Yakketi gels!!! amd64 fails and i386 passes :D That does not make sense at all
[10:10] <jibel> I don't know if it makes sense or not, then environments are different
[10:10] <bzoltan> jibel:  on Vivid - amd64  passes, gles amd64 passes, gles i386 fails ... taddaa i386 fails - https://requests.ci-train.ubuntu.com/static/britney/ticket-1511/vivid/excuses.html
[10:11] <bzoltan> jibel:  I tell you, it does not make sense...
[10:11] <jibel> bzoltan, tell it to the unity8 team
[10:11] <bzoltan> jibel:  I do not suggest not to analyze and fix tem... I suggest not to block the UITK by this.
[10:11] <jibel> bzoltan, if they explain why it's failing and why it's a false positive, then I'm fine to force the silo and start testing
[10:12] <bzoltan> jibel: I have wasted a full day with asking people to restart those flaky tests.. sil2100 was kind and helping me out. Time is flowing ...
[10:14] <bzoltan> jibel:  I do wish to spin off one more UITK release before the freeze, but if I am blocked by flaky britney then it will not happen... so less fixes and improvements fo to OTA12. That is why I am proposing that  when it is  clearly a flaky test then do not block the silo from QA, block it from releasing. So we do check the flakiness... but do parallel work, so we do not waste time.
[10:26] <bzoltan> jibel:  the Unity8 team has a sprint in Montreal :( so they will not respond very soon and i doubt that their priority there is to fix flaky tests... also Mirv is out, so i do not even have anybody who could restart those tests.. except poor sil2100 who clearly not happy for strugling with flaky tests.
[10:58] <alf> trainguards: Hi! https://requests.ci-train.ubuntu.com/#/ticket/1487 failed "Automated signoff" but it's not clear to me why and if it is a real problem that needs to be solved on my side.
[10:59] <alf> trainguards: Will failing "Automated signoff" block it from being checked by QA?
[11:14] <alf> trainguards: ah, it now changed to "Approved"
[11:52] <Saviq> jibel, bzoltan, it's a bit of a constant effort, looking through http://autopkgtest.ubuntu.com/packages/u/unity8/ it does indeed look like we're doing well on that front, so we should look into the failure
[11:59] <jibel> Saviq, thanks, I know the effort you team's doing to keep them green to not just flag failures as flaky and discard the results.
[12:35] <mardy> trainguards: any idea why this is not landing? It was approved by QA about a week ago: https://requests.ci-train.ubuntu.com/#/ticket/1389
[12:39] <sil2100> mardy: uh
[12:39] <sil2100> mardy: looks like the autopkgtests are hanged or something
[12:39] <sil2100> mardy: we only see silos as publishable when they're tested both by QA nad britney
[12:39] <sil2100> Well, if QA approved it, I guess it's safe to land
[12:40] <mardy> sil2100: yeah, I went to see the excuses and began to suspect that it was hanging
[12:45] <sil2100> mardy: publishing now
[12:48] <dbarth> sil2100, mardy: thanks
[12:48] <dbarth> rvr too
[12:48] <rvr> dbarth: You're welcome :)
[12:50] <mardy> sil2100: thanks! And about the silo that we reconfigured for triple landing (https://requests.ci-train.ubuntu.com/#/ticket/1344) will landing be automatic or do we have to push some button?
[12:50] <sil2100> In the middle of button pressing now ;)
[12:58] <sil2100> seb128: hello! Sorry to bother you once again, but one landing adds 2 new binary packages (new account plugins for touch) - would need a binNEW sign-off: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-1344/2016-06-09_09:18:09/yakkety_account-plugins_packaging_changes.diff
[13:01] <seb128> sil2100, hey
[13:02] <seb128> sil2100, the binaries descriptions suck
[13:03] <seb128> sil2100, the long description is even inconsistent between the new binaries
[13:03] <seb128> it could also at least explain to what service it integrates to
[13:04] <seb128> sil2100, the -vk says it's for GNOME control center ... is that true?
[13:04] <seb128> that should at minimal be Unity Control Center
[13:04] <seb128> I doubt it integrates with goa
[13:17] <sil2100> hm
[13:18] <sil2100> Strange descriptions indeed
[13:18] <sil2100> dbarth, mardy: ^
[13:21] <mardy> sil2100, seb128: can I fix them in a new branch? these have been waiting for a month already...
[13:22] <sil2100> Have those been copy-pasted from somewhere or something?
[13:24] <seb128> mardy, yes, but get the branch up for review and the debs are good to go
[13:48] <mardy> sil2100: yes, I think all other plugins descriptions need changing
[13:49] <mardy> seb128: you didn't file a bug already, did you?
[13:49] <seb128> mardy, no
[13:49] <mardy> seb128: OK, I'll file one then
[13:50] <seb128> thanks
[13:52] <mardy> seb128: bug 1590786, branch coming soon
[13:52] <seb128> mardy, great
[13:55] <sil2100> Ok, publishing in that case, if there are no other issues for the binNEW :(
[13:55] <sil2100> *:)
[13:59] <seb128> sil2100, mardy, yeah, let's publish, doesn't make much sense to block on that but let's assure the descriptions get fixed in the next landing
[13:59] <sil2100> Publishing in progress
[13:59] <sil2100> seb128: thanks!
[13:59] <seb128> yw!
[13:59] <mardy> \o/
[14:08] <bzoltan> Saviq:  would you please retstart the failing tests  as start?
[14:08] <Saviq> bzoltan, I can't, mterry, can you please recycle https://requests.ci-train.ubuntu.com/#/ticket/1511 - I'm looking into the failures there
[14:08] <bzoltan> Saviq: mterry: thanks
[14:10] <bzoltan> jibel:  would you please take that silo on the QA queue? As you see there are very few core-devs with upload rights around in our timezine, so the retry cycle is really slow... i am not kidding, it is blocking the UITK big time.
[14:10] <mterry> bzoltan, Saviq: yakkety recycled.  xenity had no failures.  vivid says "You submitted an invalid request: Unknown release vivid"
[14:10] <Saviq> wha
[14:11] <Saviq> trainguards, know anything about ↑ when trying to restart britney runs?
[14:12] <sil2100> huh, I don't know much about these parts sadly, hope it's not related to the recent britney changes
[14:34] <Saviq> jibel, bzoltan, mterry bug #1590810 - that's one
[14:34] <Saviq> checking the second
[14:36] <mterry> Saviq, thanks
[14:42] <robru> Saviq: mterry: no idea re:"unknown release vivid", that's a question for pitti
[14:42] <Saviq> yeah, pung him too
[14:42] <robru> Great
[14:43] <robru> sil2100: what recent britney changes do you mean? The thing i announced about not running britney on already-approved silos wouldn't have any impact on the retrier script, that's unrelated.
[14:44] <sil2100> I thought so, don't know the code so don't know how things play with eachother
[15:35] <Saviq> jibel, bzoltan, I wasn't able to reproduce the other failure, with or without the UITK silo, will keep a look out
[15:35] <Saviq> both are restarted now in any case
[15:37] <rvr> marcustomlinson: ping
[16:03] <mzanetti> jibel, we've investigated why the unity8 tests are flaky in adt for silo 14. seems just raciness and we are working on fixes for it. it's not the uitk's fault. IMO you don't need to block silo 14 on that.
[16:03] <mzanetti> bzoltan, ^
[16:04] <jibel> mzanetti, thanks
[16:29] <mterry> bzoltan, Saviq: I just tried to restart the vivid unity8 failure again, on the off chance, and it worked this time
[16:35] <marcustomlinson> rvr: pong, sorry
[16:38] <rvr> marcustomlinson: Hi
[16:38] <rvr> marcustomlinson: I have to leave now, but I found some problems in silo 65
[16:38] <rvr> marcustomlinson: With arale, NearBy scope reboots the phone on first boot and location prompt
[16:39] <rvr> marcustomlinson: And also, the prompt doesn't show until I move to another scope
[16:39] <rvr> marcustomlinson: I don't get that in turbo
[16:39] <rvr> marcustomlinson: And I'm trying to confirm on krillin
[16:40] <marcustomlinson> rvr: oh damn. Ok, eod for me too. Thanks man, will look into this tomorrow
[16:41] <rvr> Ok
[16:42] <marcustomlinson> rvr: pretty sure you won't see it on krillin. Pawel and I tested thoroughly on krillin
[17:37] <Saviq> mterry, yeah, pitti fixed it
[17:39] <mterry> nice