[01:57] <bzoltan> robru: thanks, pitti is not online :( this autopkg tests are crazy. Their instability and flakiness hold us back bug time.
[02:53] <robru> bzoltan: don't forget you can ask qa to queue the silo anyway while pitti sorts out the autopkgtests
[02:55] <bzoltan> robru: I have asked jibel and rvr already. The silo is actually in the QA queue, becuase it was passing autopkgtests once... but I have added an other MR, rebuilt ...
[05:16] <robru> marcustomlinson: ping
[05:25] <marcustomlinson> robru: pong
[05:26] <robru> marcustomlinson: oh hey. I emailed you while I was waiting for your response ;-)
[05:29] <marcustomlinson> robru: oh oops. That's odd, Safari seems to think that's an email edit box and autofills it, I must have hit save at some point overwritting it
[05:29] <marcustomlinson> robru: k I've fixed it
[05:29] <robru> marcustomlinson: ok great, thanks
[05:30] <robru> marcustomlinson: just log out & back in at requests.ci-train.ubuntu.com for the change to take effect
[05:31] <marcustomlinson> robru: k done. do I have to rebuild anything?
[05:31] <robru> marcustomlinson: nah it's not that big a deal. just nice to be fixed for future builds.
[05:31] <marcustomlinson> ok cool, thanks
[05:33] <robru> marcustomlinson: thank you!
[07:07] <pstolowski> rvr, hello, silo 65 failed? what happened?
[07:24] <sil2100> Trevinho: hey! https://code.launchpad.net/~3v1n0/unity-settings-daemon/keep-cached-kbd-backlight-updated/+merge/294662 needs review
[07:27] <oSoMoN> bzoltan, trainguards: do you know what’s up with automated signoff tests that have been running for more than 24hrs on https://requests.ci-train.ubuntu.com/#/ticket/1511 ?
[07:27] <oSoMoN> and do we expect that silo to land any time soon?
[07:28] <robru> oSoMoN: the autopkgtests are broken, it needs to be retried by pitti
[07:29] <robru> oSoMoN: as for whether it lands, that's up to qa if you ask them nicely to verify it even without the autopkgtest pass
[07:29] <oSoMoN> robru, thanks! I’ll leave that to bzoltan as it’s his silo, I was just wondering as it’s blocking other browser landings
[07:30] <robru> oSoMoN: to clarify, I mean that the autopkgtest infrastructure itself is broken, it reports running in the excuses but if you click through to running.shtml it isn't listed there
[07:31] <oSoMoN> ah indeed
[07:31] <robru> which is why we need pitti, he's the guy in charge of that
[07:32] <robru> oSoMoN: yeah bzoltan poked about that some hours ago, I guess qa is aware and should be testing that, I'm not sure what their workload looks like though
[07:35] <bzoltan> oSoMoN: I have been complaining about that too
[07:37] <bzoltan> oSoMoN:  I was talking about it with rvr already on friday and tried to convince jibel too that it is not good idea to  block the UITK from entering the QA queue based on autopkgtests, because these tests are super unreliable.
[08:17] <oSoMoN> rvr, is silo 14 still blocked?
[08:29] <tsdgeos> kenvandine: pstolowski: rvr: fwiw found what makes the phoneStage tests unstable
[08:30] <tsdgeos> https://code.launchpad.net/~aacid/unity8/fix_unstable_phone_stage_tests/+merge/297294
[08:30] <pstolowski> tsdgeos, cool
[10:41] <robru> tsdgeos: ^^ transient lp issue, please try again
[12:34] <kenvandine> tsdgeos, awesome!
[12:40] <mardy> trainguards: is the failing of the automated signoff something that I should worry about? https://requests.ci-train.ubuntu.com/#/ticket/1532
[12:41] <robru> mardy: I dunno, are you wanting to qa that silo?
[12:50] <robru> mardy: yeah you should look at the excuses files, click through to the regressing autopkgtests and see if any of it is your fault
[12:54] <pstolowski> jibel, hello, do you know what was the reason for not approving silo 65? is rvr off today?
[12:56] <jibel> pstolowski, he is online
[12:56] <jibel> pstolowski, I see the card next in the queue in ready for testing
[12:56] <jibel> it'll probably land today
[12:57] <pstolowski> jibel, oh... right.. but it has a duplicated card in 'Failed' column too
[12:58] <pstolowski> alecu, ^
[12:58] <mardy> robru: thanks, I'll check
[12:59] <mardy> robru: so, the failures are in the autopkgtests of ubuntuone-credentials, which cannot be caused by this silo (we just modify the descriptions of the debian packages, no code changes)
[13:00] <mardy> robru: is it possible to ignore them and force the silo to proceed to the next step?
[13:00] <robru> mardy: ah ok, well tell qa that and they'll override so your silo goes in the queue
[13:01] <mardy> rvr: hi! Can you take care of this? ^ (silo https://requests.ci-train.ubuntu.com/#/ticket/1532 )
[13:01] <mardy> robru: thanks! Shouldn't you be sleeping, btw?
[13:01] <robru> mardy: sprinting in athens, 4PM here ;-)
[13:02] <mardy> robru: oh, just like here then :-) Enjoy the sunshine!
[13:02] <robru> mardy: it's pretty nice here! thanks!
[13:03] <dobey> huh
[13:03] <dobey> ah, flaky package installation
[13:37] <rvr> pstolowski: Yeah, the new card is in the Ready for testing lane, I moved the old card to failed
[13:38] <rvr> mardy: Checking
[13:40] <rvr> mardy: Why are the tests failing?
[13:41] <pstolowski> rvr, i see, ok. have you seen tsdgeos' message about a fix for flaky unity8 tests (which will land separately)>
[13:41] <pstolowski> ?
[13:41] <mardy> rvr: "16:03 < dobey> ah, flaky package installation"
[13:41] <mardy> rvr: the silo doesn't touch the code, only changes deb package descriptions
[13:41] <dobey> bluez having trouble installing it seems
[13:42] <rvr> pstolowski: Yes :)
[13:42] <pstolowski> cool
[13:42] <rvr> mardy: flaky package installation?? That's new to me :-/
[13:42] <dobey> it didn't even get as far as actually running the tests, because the deps failed to install
[13:43] <dobey> and the u1-creds autopkgtests is literally just "make sure it still builds"
[13:44] <mardy> dobey: but this seems another issue: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-023/xenial/amd64/u/ubuntuone-credentials/20160614_123117@/log.gz
[13:45] <rvr> mardy: In Xenial, FAIL!  : TestToken::testGetServerTimestampMuchEarlier() Compared values are not the same
[13:46] <mardy> dobey: from this page, in case you wonder where I picked that up from: https://requests.ci-train.ubuntu.com/static/britney/ticket-1532/landing-023-xenial/excuses.html
[13:46] <dobey> mardy: oh, i only looked at the armhf ones. yeah that is another issue.
[13:47] <mardy> rvr: anyway, believe me when I say that it cannot be caused by changing descriptions of deb packages :-)
[13:47] <dobey> maybe the python3 process got destroyed in the middle of the test or something
[13:49] <mardy> dobey: if that happens, wouldn't the next test functions fail too? or is it restarted for every test function?
[13:50] <dobey> mardy: i guess it's restarted for every test
[17:43] <jibel> bfiller, ^^  6 and 6 approved
[17:43] <jibel> 6 and 8*
[19:18] <oSoMoN> bzoltan, silo 14 approved, please publish!
[19:19] <oSoMoN> davmor2, thanks for testing it btw!
[19:19] <davmor2> oSoMoN: no worries :)
[19:24] <bfiller_> jibel: thanks
[19:50] <bzoltan> oSoMoN: I think we need a stronger licensed dude for publishing those packages
[19:50] <bzoltan> 2016-06-14 19:49:54,802 ERROR Publish failed: bzoltan not authorized to upload ubuntu-ui-toolkit due to packaging diff
[19:51] <bzoltan> kenvandine:  would you help me out please?
[20:08] <kenvandine> bzoltan, looking
[20:10] <bzoltan> kalikiana: thank you
[20:10] <kenvandine> bzoltan, looks good, publishing
[20:11] <bzoltan> kenvandine: \o/
[20:12] <kenvandine> done :)
[20:13] <oSoMoN> \☻/
[20:21] <lpotter_> is there a way to tell it which package to build first, i.e. second is dependent on first?
[20:22] <dobey> lpotter_: bump version of first package, and update build-depends in second to depend on at least the new version of the first
[20:22] <dobey> lpotter_: then it will be dep-wait until the first builds