[04:35] <Mirv> jhodapp: pong
[10:23] <bzoltan> Mirv:  are you doing someting with that silo?
[10:30] <bzoltan> Mirv:  Ahh, I see your comment.
[10:55] <Mirv> bzoltan: that
[10:56] <Mirv> bzoltan: I'll click Approved again once it has built, although because of the yakkety s390x problem it's currently not going to QA queue automatically still
[10:56] <Mirv> there must be a boatload of people wanting to fix upstart s390x problem in yakkety
[10:57] <bzoltan> Mirv:  it did not fail last time I have built the silo... what changed since?
[10:58] <Mirv> bzoltan: it built fine this time too https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-029/+packages - but as you know, you had the yakkety excuses problem regarding the auto approval tests
[10:58] <Mirv> and that remains unless answering my suggestion on #otherchannel :)
[10:59] <bzoltan> Mirv:  i see, thanks... is there a way to land that silo anyway?
[10:59] <Mirv> bzoltan: by asking qa nicely to get it into their queue, yes. but then it won't migrate from yakkety-proposed to release pocket
[11:00] <Mirv> bzoltan: although that wouldn't be a new thing since the current UITK in yakkety-proposed isn't migrating either...
[11:00] <bzoltan> Mirv:  right
[11:00] <bzoltan> jibel:  would you please? Pretty please :)
[11:01] <Mirv> jibel: so bzoltan is asking QA Signoff Ready for https://requests.ci-train.ubuntu.com/#/ticket/1443 because of remaining yakkety problems that will be solved .. in time
[11:02] <Mirv> right now, as mentioned, no-one probably is jumping to fix upstart s390x
[11:03] <Mirv> well of course unless it's something really easy, there's unrelated upload just done
[11:03] <Mirv> anyway, with yakkety there will be some amount of unresolved issues that won't be immediately solved
[11:07] <jibel> Mirv, bzoltan done
[13:57] <mardy_> Mirv: our tests are failing in Xenial and Yakkety due to a mesa error: https://launchpadlibrarian.net/261581280/buildlog_ubuntu-yakkety-arm64.ubuntu-system-settings-online-accounts_0.7+16.10.20160525.1-0ubuntu1_BUILDING.txt.gz
[13:57] <mardy_> Mirv: any idea on what's wrong? They used to pass
[14:03] <Saviq> plars, krillin-07 seems gone https://unity8-jenkins.ubuntu.com/job/test-ppa-autopkgtest/171/label=phone-armhf,package=unity8,release=vivid+overlay,testname=autopilot.sh/console
[14:18] <plars> Saviq: weird, it's getting unauthorized
[14:18] <plars> Saviq: we should not still be seeing that
[14:18] <plars> Saviq: has something changed with the way you deploy it?
[14:20] <plars> Saviq: should be able to recover it, but I don't see how that can happen right now
[14:21] <plars> and none of the other devices seem to be in that state
[14:41] <Saviq> plars, no, nothing new
[14:42] <sil2100> pstolowski: hey! How far are you guys with silo silo 47?
[14:42] <plars> Saviq: I can try recovering it, but I'm not sure how it could have ended up in that state - or if your job runs recover from lifeboat, then it should also do the same
[14:42] <sil2100> pstolowski: I'm asking since I would like to back-port the arm64 enablement from yakkety and I wouldn't want to break your work
[14:43] <Saviq> plars, yeah that output is from recover, see 13:08:13
[14:43] <plars> let me try it here
[14:43] <pstolowski> sil2100, all built ok, looks ok & approved by me; waiting for autopkg tests to finish
[14:45] <sil2100> pstolowski: excellent, I see arm64 binaries are also built now so the change is included - thanks, we'll be waiting for this to land
[14:45] <sil2100> :)
[14:46] <pstolowski> sil2100, the previous run of autpkg tests on yakkety failed on unity8, probably a flaky test but need Saviq to confirm
[14:47] <Saviq> pstolowski, got link?
[14:47] <Saviq> ah 47
[14:47] <Saviq> hmm not sure if I can get back to that test
[14:48] <pstolowski> Saviq, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-ci-train-ppa-service-landing-047/yakkety/i386/u/unity8/20160524_215652@/log.gz
[14:50] <pstolowski> Saviq, FAIL!  : qmltestrunner::Wizard::test_passwdPasscode()
[14:51] <Saviq> pstolowski, ah yeah, that's fixed in the u8 released last night
[14:51] <Saviq> so the new run will be fine
[14:51] <pstolowski> cool
[14:54] <plars> Saviq: it seems to have recovered fine when I tried it - give it a try
[14:54] <Saviq> plars, ack, thanks
[15:02] <charles> kenvandine, wrt silo 50, be my guest
[15:07] <kenvandine> charles, someone already published it :)
[15:10] <Mirv> mardy_: arm64 Qt switched to OpenGL ES today (same as armhf), looks like fallout from that since you're using mesa software rendering instead of real hardware and maybe not too many people in the world are using arm64 mesa software rendering... you may need to skip the test on arm64 (and we should test on real accelerated hw)
[15:11] <Mirv> of course we don't have such phone hw either yet though :)
[15:14] <Mirv> mardy_: it might be useful to file against mesa about the issue anyhow
[15:16] <mardy_> Mirv: OK, I will
[15:16] <mardy_> Mirv: about disabling tests, what's the best way? set DEB_BUILD_OPTIONS=nocheck
[15:17] <mardy_> Mirv: set the env variable above at the beginning of debian/rules, depending on the value returned by dpkg-architecture?
[15:17] <Mirv> mardy_: see eg http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/debian/rules - lines 10,11,14,23,29
[15:19] <mardy_> Mirv: excellent, thanks!
[15:33] <pstolowski> sil2100, hmm silo 47 autopkg tests failed, but there are not regressions reported?
[15:54] <pstolowski> Mirv, hey, any idea about silo 47? ^
[15:58] <bschaefer> trainguards, hello. I need a silo for getting a ppa into vivid + overlay
[15:59] <bschaefer> its maliit-framework and maliit-inputcontext-gtk2/3
[15:59] <bschaefer> ppa: https://launchpad.net/~brandontschaefer/+archive/ubuntu/maliit
[15:59] <bschaefer> tested working on the phone
[16:02] <robru> bschaefer: hiya. I guess you need permissions to create the ticket?
[16:02] <bschaefer> robru, i ... think so, since it will require someone here to upload the ppa to the
[16:02]  * bschaefer looks
[16:03] <Mirv> pstolowski: vivid dependency problem, but I can't reach my computer to debug more properly right now (I'm outside spending the evening)
[16:03] <bschaefer> robru, i can create a new request
[16:03] <pstolowski> Mirv, ah..
[16:04] <robru> bschaefer: OK create the request and assign it, I'll copy the package over
[16:04] <Mirv> pstolowski: the arm64 enablement is done on xenial/yakkety so I can't really guess what would be causing a vivid problem... maybe that enablement related regardless, from some triple landing
[16:04] <robru> Just need some breakfast first, brb
[16:05] <bschaefer> robru, cool, (as do i!) (its being assigned now but taking for ever)
[16:06] <bschaefer> robru, https://requests.ci-train.ubuntu.com/#/ticket/1466
[16:06] <bschaefer> thanks!
[16:07] <pstolowski> robru, sil2100 can either of you help with silo 47 (see Mirv's comments above)?
[16:09] <Saviq> pstolowski, Mirv, on vivid: unity-scope-click/arm64 unsatisfiable Depends: ubuntu-sdk-libs
[16:09] <Saviq> Not considered
[16:09] <Saviq> pstolowski, you want uitk as a build dep to never build for arm64 if it's not available there
[16:10] <Saviq> pstolowski, in the mean time someone needs to delete your vivid arm64 binaries for this to go green
[16:10] <Saviq> *or* we need uitk to build for arm64 in vivid overlay
[16:11] <Saviq> oh hum
[16:11] <Saviq> what's ubuntu-sdk-libs? virtual?
[16:11] <Saviq> ah d'oh
[16:12] <Saviq> it's from ubuntu-touch-meta
[16:12] <robru> pstolowski: yeah, that ^
[16:13] <robru> bschaefer: ok, copied
[16:14] <Saviq> pstolowski, ok so to avoid this unity-scope-click needs to B-D on ubuntu-sdk-libs, so it's never built for arm64 unless that is available (and we need to discuss with archive people how to do this, it's been a problem a few times already)
[16:15] <pstolowski> Saviq, ok, preparing MP.. why didn't we see it before in vivid?
[16:15] <robru> Saviq: what do you need to know how to do? build-dep on something that has the correct arches sounds like the right solution to me
[16:16] <robru> pstolowski: because arm64 has only just been enabled for some packages, apparently
[16:16] <pstolowski> ah
[16:23] <bschaefer> robru, awesome thanks!
[16:23] <robru> bschaefer: you're welcome
[16:33] <dobey> robru: why doesn't someone just make the same change to ubuntu-touch-meta in vivid, that was made in yakkety/xenial?
[16:34] <robru> dobey: I have no idea. I guess we don't care about arm64 in vivid?
[16:34] <robru> which would make sense since we're trying to update to xenial
[16:35] <dobey> well, but we aren't updating all devices to xenial
[16:36] <robru> ungh
[16:38] <dobey> and the frameworks files in ubuntu-sdk-libs are a lie on xenial/yakkety anyway, because the ABI is broken
[16:38] <dobey> cest la vie
[16:49] <Mirv> Saviq: robru: so there is certainly some new vivid-overlay problem that needs to be fixed other than starting to undepend on ubuntu-sdk-libs
[16:50] <robru> Mirv: undepend? they were talking about adding a dep on that so it'll follow its arches
[16:50] <Mirv> I'd guess some arm64 enablement targeting xenial/yakkety was triple landed and somehow wonderously causes now a new vivid related problem simply regarding installing the touch packages
[16:51] <Mirv> robru: ah right sorry, now I finally could look into the problem so right this is I guess about pstolowski instead working on arm64 enablement and he has added a new dep on ubuntu-sdk-libs. ok that makes sense and you probably indeed already suggested the correct way to fix it.
[16:51] <Mirv> I just try to do things in haste when running from place to place but I'm glad it seems relatively clear to you at least :)
[16:53] <Mirv> if it seems hard to do vivid only exception for not depending on arm64 meta package, we may still enable ubuntu-sdk-libs for arm64 for these purposes (even though arm64 won't be enabled for real on vivid)
[16:53] <Mirv> ok I'll really go now, it's better to focus on these things during working hours
[16:56] <robru> Mirv: goodnight
[18:34] <rvr> Mirv: Hi
[18:35] <rvr> Mirv: Silo 9
[18:36] <rvr> Mirv: I killed the music app using the spread. Now, music app stucks after start.
[18:36] <rvr> Mirv: I have rebooted, but the application remains in the same state after starting it.
[18:37] <rvr> Mirv: Not sure whether it is related to the silo changes.
[18:37] <rvr> mzanetti: ^
[18:37] <rvr> This is the log of music app http://paste.ubuntu.com/16690390/
[18:45] <rvr> I manually removed the lock file, and the app works again
[18:45] <rvr> It's documented in the silo card
[18:46] <rvr> And yes, the silo packages are installed.
[18:47] <dobey> oh, well ubuntu-sdk-libs isn't installable on xenial arm64 either. yay
[18:48] <dobey> a bit surprised it does install in y
[20:17] <mzanetti> rvr, still here?
[20:17] <mzanetti> and still in that state?
[21:14] <dobey> robru: if britney has "old binaries left" listed for the silo autopkgtests, we need to someone to delete those binaries?
[21:14] <robru> dobey: yep, what silo?
[21:16] <dobey> robru: 47
[21:17] <dobey> robru: click scope arm64 binaries on xenial/vivid
[21:18] <robru> dobey: ok, deleted. will take 1-2 hours for britney to notice
[21:18] <dobey> an eternity by any other name
[21:20] <dobey> robru: thanks
[21:20] <robru> dobey: you're welcome!