=== ljp is now known as lpotter
=== chihchun_afk is now known as chihchun
=== salem_ is now known as _salem
=== zsombi_ is now known as zsombi
[07:20] <Saviq> sil2100, morning, can copy https://requests.ci-train.ubuntu.com/#/ticket/1645 to snapshot please
[07:22] <sil2100> Saviq: ok, both OTA-12 and factory I suppose?
[07:22] <sil2100> On it
[07:23] <Saviq> sil2100, I suppose, yeah, thanks
[09:05] <Saviq> trainguards, hey, think we could finalize https://requests.ci-train.ubuntu.com/#/ticket/1645 ? it's stuck in proposed because of armhf queue, it passed on i386 and amd64 by now
[10:41] <oSoMoN> trainguards: why is my SRU silo (51) building against the stable-phone-overlay PPA ?
[10:51] <sil2100> oSoMoN: silos, by default, have a hard-dependency on the overlay
[10:52] <sil2100> oSoMoN: if this gets in your way then I can temporarily remove that dependency for you to rebuild
[10:52] <oSoMoN> sil2100, please do if you don’t mind, as the dependency on a newer ubuntu-ui-toolkit is preventing webbrowser-app from successfully building
[10:52] <sil2100> Ok, let me take a look at the silo
[10:54] <sil2100> oSoMoN: done, please rebuild :)
[10:54] <oSoMoN> sil2100, would it make sense for me to file a bug against bileto to request that PPAs assigned to SRU silos have the dependency on the stable-phone-overlay PPA removed?
[10:54] <sil2100> oSoMoN: I guess that would be a valid feature
[10:54] <oSoMoN> sil2100, thanks, I’ll file a bug then
[10:54] <sil2100> Wouldn't expect it to be implemented soon, since there's a lot of more pending tasks on robru's plate in bileto ;)
[10:57] <oSoMoN> https://bugs.launchpad.net/bileto/+bug/1600188
[10:57] <ubot5> Launchpad bug 1600188 in Bileto "PPA assigned for building a SRU should not have a dependency on the stable phone overlay" [Undecided,New]
=== _salem is now known as salem_
[12:53] <jhodapp> sil2100, ping
[12:53] <sil2100> jhodapp: pong
[12:53] <jhodapp> sil2100, hey, any idea why this silo keeps getting a dependency wait for qtubuntu-media on vivid and xenial (but not yakkety)? https://requests.ci-train.ubuntu.com/#/ticket/1533
[12:54] <jhodapp> sil2100, the newer media-hub version is in that silo that qtubuntu-media expects
[12:55] <sil2100> jhodapp: yeah, look at the dependency version: libmedia-hub-dev (>= 4.4.0+16.10.20160708-0ubuntu1)
[12:55] <sil2100> jhodapp: so the vivid and xenial versions depend on the version from yakkety (16.10 in the version number)
[12:56] <sil2100> jhodapp: you would need to bump the upstream version and depend on that then
[12:56] <sil2100> e.g. 4.4.1, and then do the dependency in the qtubuntu-media packages to >= 4.4.1
[12:57] <jhodapp> sil2100, hmm, ok I hadn't noticed that lpotter had used 16.10 in the version string
[12:57] <jhodapp> sil2100, ok makes sense now, I'll advise him further...thanks for taking a quick look
[12:58] <sil2100> jhodapp: yeah, if you need to depend on a specific version of a package that's generated by the CI Train then you need to only depend on the upstream part of the version
[12:58] <sil2100> Since anything past the first + sign is auto-generated and is per-distro
[12:58] <jhodapp> sil2100, yeah that makes total sense...I've wondered that actually
[12:58] <sil2100> So if there are API changes, an upstream version needs to be bumped
[12:59] <sil2100> :)
[12:59] <sil2100> yw!
[12:59] <jhodapp> right makes total sense
[12:59] <jhodapp> thanks
=== dpm is now known as dpm-bbiab
=== dpm-bbiab is now known as dpm
[15:41] <cjwatson> Good grief, x86 builder backlog.
[15:41]  * cjwatson hits some of them to try to mitigate it
=== chihchun is now known as chihchun_afk
[17:25] <alex_abreu> robru, ping
[17:26] <robru> alex_abreu: pong
[17:27] <alex_abreu> robru, have you heard of any issue w/ packagekit deps issues when building for Y ? https://requests.ci-train.ubuntu.com/#/ticket/1639
[17:29] <robru> alex_abreu: haven't heard anything
[17:30] <alex_abreu> robru, mmmh ok
[17:31] <robru> alex_abreu: error looks like you're just missing a dep on the package
[17:32] <alex_abreu> robru, yes but that is a package that just should work ... weird
[17:34] <robru> alex_abreu: I don't know anything about it specifically but it's possible that what was one package previously has been split into two in yakkety so now you need a new dep to bring in everything you used to get before.
[17:35] <alex_abreu> robru, yes my guess too
[17:42] <cjwatson> alex_abreu: yeah, well, doko merged new packagekit even after we explicitly and repeatedly said it needed to be blocked on click
[17:42] <cjwatson> so I have no idea how you're going to build click for yakkety now
[17:43] <cjwatson> given that my attempt to do the native dbus thing (which was afaics the only way out) was nacked
[17:44] <alex_abreu> cjwatson, argh I was afraid I would end up in a dead situation like that :/
[17:44] <cjwatson> alex_abreu: BTW, you still need to get rid of the click_stderr variable in that MP
[17:44] <alex_abreu> cjwatson, oh sorry I thought I did that ... will do now
[17:44] <cjwatson> you added the flag but the var is still there
[17:44] <alex_abreu> yes
[17:45] <alex_abreu> cjwatson, so do you have a summary of the packagekit situation?
[17:48] <cjwatson> alex_abreu: https://bugs.launchpad.net/ubuntu/+source/click/+bug/1470655 and https://code.launchpad.net/~unity-api-team/click/drop_packagekit/+merge/285225 cover it I guess
[17:48] <ubot5> Launchpad bug 1470655 in click (Ubuntu) "Update to PackageKit 1.0" [High,Triaged]
[17:49] <cjwatson> I suppose you could try merging the latter; I wasn't going to take responsibility for it because I don't agree with the direction, but it's no longer my responsibility, so :)
[19:34] <alex_abreu> cjwatson, would you mind approving https://code.launchpad.net/~unity-api-team/click/drop_packagekit/+merge/285225 ? just to have a stamp of approval since your disaprove might scare people ...
[19:35] <alex_abreu> cjwatson, and could we MR it to trunk instead of /devel?
[19:55] <cjwatson> alex_abreu: sorry, no - I won't stop you landing it but I want it on record that I don't agree with the direction.  If it makes people think about the reasons I gave then so much the better from my POV :)
[19:57] <cjwatson> alex_abreu: the way I normally managed click was to merge everything into lp:click/devel first and then land one big MP from that to lp:click using citrain
[20:01] <alex_abreu> cjwatson, understood thanks, ... I'll prob talk to you on Monday again about this, and send an email to all involved to sum up the situation
[23:25] <cjwatson> alex_abreu: I don't really know what else I have to contribute to the discussion beyond what I've already said, but sure
[23:42] <alex_abreu> cjwatson, well just to be sure, I'll put you in cc, just so that correct me if I quote you wrong :)
[23:42] <cjwatson> ok