=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
[08:28] <oSoMoN> Saviq, Mirv: ever seen regressions similar to those at http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#webbrowser-app (qmluitests.sh failing at the dh_auto_configure phase, Checking for module 'unity-shell-application=14')?
[08:28] <oSoMoN> Mirv, and would re-running those tests make them pass (i.e. was it a transient failure)?
[08:29] <Mirv> oSoMoN: not familiar, maybe there's a real unity8 FTBFS in yakkety at the moment?
[08:29] <Saviq> oSoMoN, Mirv, needs a re-run with --all-proposed
[08:30] <Saviq> because that's old unity8 trying to test with new unity-api
[08:30] <Mirv> no such switch in that UI
[08:30] <Saviq> Mirv, oSoMoN, no - need to ask pitti for that atm
[08:30] <Saviq> unless Mirv you got access to snakefruit https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests
[08:34] <oSoMoN> Mirv, in the meantime, would you mind merging https://requests.ci-train.ubuntu.com/#/ticket/1387 on my behalf? this will allow rebuilding other webbrowser-app silos
[08:40]  * Saviq thinks we should ignore britney results for yakkety for now
[08:41] <Mirv> sorry, on hangout
[08:41] <Mirv> Saviq: no snakefruit
[08:42] <Mirv> oSoMoN: ok
[08:42] <oSoMoN> thanks
[08:42] <Mirv> there might be yakkety Qt build problem now anyway because qtchooser got autosynced 3h ago... I uploaded new qtbase 30mins ago
[08:43] <Saviq> pstolowski, ↑↑ Mirv's already on it
[08:43] <pstolowski> Saviq, great, thanks
=== vrruiz_ is now known as rvr
[08:44] <Saviq> jibel, I think we need to ignore yakkety britney results for a few days, wdyt?
[08:47] <jibel> Saviq, for which packages?
[08:48] <Saviq> jibel, well, for one, unity8 won't pass for anyone in yakkety until a new unity8 goes into the release pocket
[08:51] <jibel> Saviq, okay then, it seems we don't have a choice
[08:52] <Saviq> jibel, https://requests.ci-train.ubuntu.com/#/silo/58 is failed because it's uninstallable on yakkety https://requests.ci-train.ubuntu.com/static/britney/yakkety/landing-058/excuses.html until http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-shell releases, and that one is waiting for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-api
[08:57] <Saviq> jibel, so yeah, I'd be obliged if you made silo 58 QA Ready - it's only failed because of the dependency chain
[09:09] <Mirv> sil2100: so in short they moved a couple of files from qtbase-opensource-src and qt4-x11 to qtchooser. so now absolutely about everything trying to install Qt 5 or Qt 4 fails due to conflicts since only qtchooser was updated in Ubuntu...
[09:09] <Mirv> new qtbase https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.5.1+dfsg-17ubuntu1 and qt4-x11 are building in archives https://launchpad.net/ubuntu/+source/qt4-x11/4:4.8.7+dfsg-5ubuntu5
[09:09] <sil2100> :|
[09:16] <jin_> davmor2: buddy, thank you
[09:16] <jin_> davmor2: I know the ticket is under testing by you
[09:16] <jin_> davmor2: anything please let me know, cool!
[09:16] <davmor2> jin_: yeap I took it as I knew what it was about :)
[09:16] <davmor2> jin_: will do
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== alex-abreu is now known as alex-abreu|off
[10:25] <Saviq> sil2100, can you please ♻ http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-api - it's failed because of Qt being uninstallable but that should be good again now https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.5.1+dfsg-17ubuntu1
[10:26] <Saviq> hmm or not yet
[10:26] <Saviq> need to wait for the arm builds to complete
[10:46] <sil2100> Saviq: oh, ok
[10:48] <Saviq> sil2100, you could rerun them now - amd64 and i386 of qt is published now
[11:24] <Mirv> Qt always surprises like today. You start with a plan in the morning and then it gets completely thrown out in favor of something that needs to be done first :)
[11:25] <Mirv> on the plus side I managed do to necessary SIM card roulette with my secondary operator and can now officially devote my krilling for development while the necessary SIMs are in my turbo
[11:25] <pstolowski> Mirv, any idea about libubuntu-location-service-dev in Y? https://launchpadlibrarian.net/261192027/buildlog_ubuntu-yakkety-s390x.unity-scopes-shell_0.5.7+16.10.20160523.2-0ubuntu1_BUILDING.txt.gz
[11:33] <Saviq> pstolowski, at least x86 installs build-dep for u-s-shell fine now
[11:33] <Saviq> pstolowski, so I'd say that's temporary
[11:36] <Mirv> pstolowski: tested in container, I don't see problem installing it even with yakkety-proposed
[11:37] <Saviq> Mirv, could be a temporary s390x issue
[11:38] <Saviq> sil2100, did you ♻ http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-api after all?
[11:38] <Mirv> Saviq: oh, s390x, yes I don't have container for s390x :)
[11:39] <Mirv> Saviq: pstolowski: uh oh it's waiting for s390x platform-api https://launchpad.net/ubuntu/+source/location-service/3.0.0+16.04.20160405-0ubuntu4/+build/9658051
[11:39] <sil2100> Saviq: now I did, didn't see your last message ;)
[11:39] <Mirv> but why, err, it's even trying https://launchpad.net/ubuntu/+source/platform-api/3.0.1+16.10.20160523-0ubuntu1
[11:40] <Saviq> Mirv, but papi is waiting for location-service...
[11:40] <Saviq> https://launchpad.net/ubuntu/+source/platform-api/3.0.1+16.10.20160523-0ubuntu1/+build/9791743
[11:40] <Saviq> sounds like a circular build dep :-S
[11:41] <Mirv> lol
[11:41] <Mirv> sil2100: ^
[11:41]  * sil2100 stopped caring about yakkety after being so busy with vivid and xenial
[11:41] <Mirv> oh, what a mess, with the Qt thrown into it too
[11:41] <sil2100> uh oh
[11:42] <sil2100> Ok, just kidding, will look into that later
[11:42] <Mirv> sil2100: I can feel you :)
[11:42] <Saviq> sil2100, thanks, let's see if that completes - we needed a --all-proposed before, not sure if that sticks
[11:43] <Mirv> Saviq: well the platform-api FTBFS also in general on all archs, so it would not even help if there wasn't a circular dependency to location...
[11:43] <Mirv> https://launchpad.net/ubuntu/+source/unity-scopes-shell/0.5.7+16.04.20160505-0ubuntu2
[11:43] <Saviq> Mirv, https://launchpad.net/ubuntu/+source/platform-api/3.0.1+16.10.20160523-0ubuntu1 hmm?
[11:44] <Mirv> Saviq: oh right sorry I meant the scopes ftbfs
[11:44] <Saviq> right, that's new
[11:44] <Mirv> "scope-uri.cpp:35:46: error: ‘vector’ does not name a type" etc
[11:45]  * Saviq pings api folk
[11:49] <pstolowski> Mirv, on it
[11:50] <pstolowski> Mirv, ok to add the fix to existing silo?
[11:53] <Saviq> pstolowski, depending on the fix we could maybe skip QA and unblock things quicker
[11:53] <pstolowski> Saviq, ack
[12:06] <Mirv> pstolowski: sure
[12:06] <Mirv> whatever suites best
[12:07] <pstolowski> Mirv, Saviq her eyou go https://code.launchpad.net/~stolowski/unity-scopes-shell/fix-yakkety-ftbfs/+merge/295459 , build here in Y chroot
[12:07] <pstolowski> Mirv, it's a trivial fix.. so yeah let's land directly
[12:08] <Saviq> ok /me pops a silo
[12:08] <pstolowski> k
[12:09] <Saviq> jibel, agreed ↑↑ can skip QA?
[12:09] <Saviq> it's just new gcc being stricter with includes
[12:11] <kenvandine> anyone know why xenial packages are going to the unapproved queue instead of the overlay PPA?
[12:12] <jibel> Saviq, +1
[12:27] <Saviq> kenvandine, because you didn't trio-ify your silo?
[12:28] <Saviq> kenvandine, if you had a vivid+xenial silo, it will be a SRU since last week
[12:28] <kenvandine> ah... i had read that
[12:29] <kenvandine> but didn't catch the part about it being an SRU
[12:29] <abeato> sil2100, hey, tarballs generated in the usual places: http://people.canonical.com/~abeato/avila/ubuntu/device_frieza-20160523.0.tar.xz and http://people.canonical.com/~abeato/avila/cooler/ubuntu/device_cooler-20160523.0.tar.xz
[12:29] <kenvandine> i manually copied it to yakkety
[12:36] <Mirv> kenvandine: what I've done with the remaining dual silos is copy-package the built packages manually to overlay and then the xenial package without binaries to yakkety
[12:37] <kenvandine> Mirv, that's what i did
[12:37] <kenvandine> i just hadn't realized the xenial build would be an SRU, must have missed that part
[12:37] <kenvandine> Mirv, i took care of it :)
[12:37] <kenvandine> thx
[12:41] <Mirv> kenvandine: oh right and you'll need manual merge reportedly
[12:44] <kenvandine> Mirv, done :)
[12:45] <kenvandine> ugh... yakkety fails to build because of depends
[12:50] <Mirv> kenvandine: yes, qtchooser autosynced from Debian in the morning since it doesn't have Ubuntu changes. I've had a "couple" of pings related to that :) I think your armhf might just have missed the publishing of qtbase armhf https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.5.1+dfsg-17ubuntu1
[12:50] <Mirv> it moved files around so everything Qt 5 or Qt 4 broke
[12:51] <Mirv> because of conflicting files when installing build deps
[12:53] <kenvandine> Mirv, ah...
[12:53] <kenvandine> Mirv, so if i wait a bit and retry i might be good?
[12:53] <Saviq> Mirv, kenvandine, it's still not in proposed for armhf indeed
[12:53] <Saviq>  libqt5core5a | 5.5.1+dfsg-16ubuntu11  | yakkety-proposed | armhf
[12:53] <Saviq>  libqt5core5a | 5.5.1+dfsg-17ubuntu1   | yakkety-proposed | amd64, arm64, i386, powerpc, ppc64el, s390x
[12:56] <Mirv> kenvandine: yes
=== _salem is now known as salem_
[13:18] <Mirv> publisher seems slowish, the armhf is still not published while the build was finished >1h ago
[13:30] <rvr> kdub: ping
[13:30] <kdub> hello rvr
[13:30] <rvr> kdub: Hi
[13:30] <rvr> kdub: I'm testing silo 69
[13:31] <rvr> kdub: There is a problem in frieza. When I launch a X11 app on desktop mode, it only starts when I click the window to set it to full screen mode.
[13:31] <rvr> It only happens with the silo installed
[13:32] <kdub> rvr, thanks, sounds like something to fix
[13:33] <jhodapp> sil2100, ping
[13:33] <rvr> kdub: I am failing the silo. Ping me the silo is ready for QA again.
[13:33] <kdub> rvr, sure
[13:33] <Saviq> kenvandine, Mirv libqt5core5a | 5.5.1+dfsg-17ubuntu1   | yakkety-proposed | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
[13:34] <kenvandine> Saviq, thx!
[13:34] <Saviq> mterry, can you please retry this build https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-077/+build/9792770
[13:34] <mterry> Saviq, done
[13:37] <Mirv> Saviq: \o/
[13:37] <Saviq> mterry, thanks, that will get us just a bit closer to unblocking things (currently waiting to see results from a unity8 --all-proposed run in excuses, should make all the unity8 reds out)
[13:37] <Saviq> s/out/go away/
=== chihchun is now known as chihchun_afk
[14:04]  * Saviq cries a little
[14:32] <Trevinho> sil2100: hey, since we're stuck in landing unity in yakkety because a s390x build-dep (upstart is  not built there), can we just proceed with a forced landing and then we'll remove unity7 from that arch at all?
[14:32] <Trevinho> robru: (maybe) too ^
[14:40] <sil2100> Trevinho: hey! We could consider force-merging that if needed, but from what I heard foundations wanted to have unity7 available on the s390x just-in-case
[14:40] <sil2100> But it was a few weeks ago when I heard this
[14:40] <Trevinho> sil2100: we were discussing this in -devel with seb128 and pitti, and they agree on removing it
[14:42] <Saviq> trainguards, help please https://requests.ci-train.ubuntu.com/#/ticket/1450 ?
[14:43] <tedg> Saviq: Not sure, but is it because your s390 buildx are depwait?
[14:43] <Saviq> tedg, it was always depwait on s390x
[14:44] <tedg> Ah, okay.
[14:44]  * tedg will be curious to see what that error is
[14:44] <sil2100> hmm
[14:44] <Saviq> it's as if something uploaded to yakkety that the train didn't expect?
[14:45] <Saviq> but it would've complained when building, wouldn't it
[14:45] <Saviq> I could IGNORE_VERSIONDESTINATION
[14:46] <Saviq> just not sure I wanna without understanding what the issue is
[14:46] <sil2100> Strange, I don't see any uploads
[14:46] <sil2100> Let me just check the queue real quick
[14:47] <sil2100> No, nothing, hm
[14:48] <sil2100> I guess let's ignore dest version, since this seems to be not an issue
[14:48] <Saviq> sil2100, will publish with ↑↑ then
[14:48] <sil2100> I suppose it's the train getting confused
[14:48] <sil2100> Saviq: ACK
[14:49] <Saviq> success
[14:49] <Saviq> oh well
[14:57] <robru> Saviq: sil2100: tedg: manual upload: https://launchpad.net/ubuntu/+source/unity-scopes-shell/0.5.7+16.04.20160505-0ubuntu2
[14:57] <Saviq> robru, yeah, but shouldn't the train complain when it was building?
[14:57] <Saviq> robru, that upload is from last week, and that silo was only created a few hours ago
[14:58] <robru> Saviq: yeah, it should, hm
[15:00] <robru> Saviq: anyway that upload is not on trunk, so that's definitely what it was complaining about.
[15:00] <Saviq> robru, ack
[15:01] <dobey> Saviq: doesn't matter how old a manual upload is, if nobody ever noticed and merged the changes back to trunk
[15:01] <Saviq> dobey, sure, I just meant that I would've "expected" that error if the upload happened between build and publish
[15:02] <robru> sil2100: I'm not sure where you were looking that you didn't see your own upload and realize that's what it was complaining about
[15:02] <Saviq> so basically the train should've complained when building (as it usually did in that case) that there's a version in Ubuntu that isn't in trunk
[15:02] <Saviq> robru, is it looking at proposed?
[15:02] <robru> Saviq: yes
[15:03] <robru> Saviq: yeah I'll have to look why it didn't complain during build, but the publish check is correct
[15:03] <dobey> it never complains during build
[15:04] <robru> dobey: no there's definitely a "dest version missing from changelog"check that fails, which is why there's a force option.
[15:04] <dobey> the source packages build and upload to the PPA just fine. but then when a build fails, or the builds are completed, the status will say something about dest version missing from trunk, iirc
[15:06] <dobey> at least, that's my experience
[15:07] <sil2100> robru: but it was there when the silo got built, so it's not an unexpected upload IMO
[15:07] <sil2100> robru: unexpected upload for me is a situation when you built a silo and then someone uploaded
[15:07] <robru> sil2100: well your wrong.
[15:07] <sil2100> robru: in this case, the silo was assigned today, and built today
[15:08] <sil2100> Probably, I don't give a fuck
[15:08] <dobey> any upload that happened outside the silo is an "unexpected upload" i would think
[15:08] <robru> sil2100: and the build did not include the last upload in proposed
[15:08] <robru> Yes
[15:13] <Saviq> robru, it could mention which upload was unexpected, would be easier to grok what's wrong
[15:13] <robru> Saviq: file a bug please
[15:18] <Saviq> will do
[15:37] <Saviq> grr grr how long before it shows up in proposed :/
[15:49] <robru> Saviq: 29 minutes ago
[15:53] <Saviq> robru, where?
[15:53] <Saviq> now it's there
[15:54] <robru> Yeah
[16:07] <Saviq> gaah
[16:07] <Saviq> Mirv,  qdbus : Depends: qtchooser (>= 55-gc9562a1-1~) but it is not going to be installed
[16:08] <Saviq>  qtchooser : Breaks: libqtcore4 (< 4:4.8.7+dfsg-7~) but 4:4.8.7+dfsg-5ubuntu5 is to be installed
[16:23] <Mirv> Saviq: yep, qt4 is not fixed yet, including qdbus (vs qdbus-qt5)
[16:24] <Mirv> Saviq: so this is the real deal for Qt 4 users https://launchpad.net/ubuntu/+source/qt4-x11/4:4.8.7+dfsg-7ubuntu1
[16:24] <Mirv> shouldn't everything be ported to Qt 5 already though, Qt 4 reached end of support in December :)
[16:52] <dobey> mterry, sil2100, kenvandine: can someone restart this test please? https://autopkgtest.ubuntu.com/request.cgi?release=vivid&arch=amd64&package=unity8&trigger=pay-service%2F15.10%2B15.04.20160520-0ubuntu1&ppa=ci-train-ppa-service%2Fstable-phone-overlay&ppa=ci-train-ppa-service%2Flanding-056
[16:53] <sil2100> dobey: on it
[16:53] <dobey> thanks
[16:53] <sil2100> hm, I get an error
[16:53] <sil2100> Oh, ok
[16:53] <sil2100> Now it's good
[16:55] <dobey> great, thanks
[16:55] <dobey> oh good, at least autopkgtests queue isn't completely insane any more
[16:56] <dobey> i wonder how much longer the molasses migration of yakkety is going to take
[17:48] <sil2100> Mirv: looking into why platform-api is not migrating from -proposed right now... looks like the dependency chain somewhere seems to lead to qtchooser
[17:49] <sil2100> Mirv: it's just a first look of mine, but it looks like it's not any of our actual newly pushed touch stuff, just the Qt madness you mentioned earlier
[17:56] <jhodapp> sil2100, does this require an SRU? https://requests.ci-train.ubuntu.com/#/ticket/1436
[17:56] <sil2100> jhodapp: let me take a look
[17:57] <sil2100> hmm, I guess it could but, considering that all our touch packages for xenial are in the xenial-overlay anyway, I guess that would be the best place to start
[17:58] <sil2100> jhodapp: just in case, wouldn't this change be good to land to all 3 series?
[17:59] <sil2100> jhodapp: like, it looks like it would work on vivid as well
[17:59] <sil2100> jhodapp: you wouldn't have to create a separate xenial trunk then, just include it in a normal triple landing silo
[17:59] <sil2100> jhodapp: that way the same change would be in xenial and also in the latest devel series, so yakkety
[18:00] <jhodapp> sil2100, it will merge the package change for all 3 (merged into trunk for qtubuntu-media) but it wouldn't only copy over the package for xenial
[18:01] <sil2100> Wouldn't it be better to keep all distros in sync?
[18:01] <jhodapp> sil2100, but it fails to compile on vivid and yakkety
[18:01] <sil2100> hm
[18:01] <jhodapp> for arm64
[18:01] <jhodapp> no platform-api packages for arm64 on those
[18:01] <sil2100> Well, it was always failing for arm64 on vivid, right?
[18:01] <jhodapp> yup
[18:01] <sil2100> So releasing this change would have no effect
[18:02] <sil2100> But at least all 3 would be in sync
[18:02] <jhodapp> so just keep it triple landing then?
[18:02] <sil2100> Yeah, I would say that's the best option, we don't want to get confused by different versions on different serieses
[18:02] <davmor2> sil2100: ha you foolish mortal ;)
[18:02] <jhodapp> sil2100, cool, I'll do that and then hand over to QA
[18:02] <jhodapp> davmor2, does your team have an arm64 device to test on?
[18:02] <sil2100> jhodapp: thanks! It should be basically a no-op for QA so not much trouble
[18:03] <jhodapp> yeah
[18:03] <davmor2> sil2100: I have every faith in jhodapp ability to break the universe in new and interesting ways ;)
[18:03] <davmor2> jhodapp: nope
[18:03] <jhodapp> davmor2, thanks for believing in me!
[18:03] <sil2100> ;)
[18:03] <jhodapp> davmor2, alright
=== boiko_ is now known as boiko
[19:39] <Mirv> sil2100: ok. Qt should be fixed now but all migration is now intertwined so lots of autopkgtest kicking would probably needed. I'm on my Meizu now so I won't check at this hour but I will in the morning.
[19:45] <sil2100> Mirv: thanks!
[19:45] <sil2100> Excellent :)
=== rpadovani_ is now known as rpadovani