=== evanwang is now known as evanwang-afk
=== tyhicks` is now known as tyhicks
=== evanwang-afk is now known as evanwang
[09:31] <Mirv> jibel_: want to have a meeting or not?
[09:31] <jibel_> Mirv, do we need one?
=== jibel_ is now known as jibel
[09:32] <Mirv> jibel: not from my side, but me and Dave are here if you have something on mind
[09:33] <jibel> Mirv, nothing from me
[09:34] <davmor2> jibel: no worries
[09:37] <alf__> trainguards: Hi! Question: Can the CI train handle projects that useg LP git branches instead of bzr?
[09:38] <robru> alf__: no
[09:39] <alf__> robru: Thanks. Are there plans to add such a feature?
[09:39] <robru> alf__: yes
[09:40] <alf__> robru: Any ETA (just a very rough approximation will do, a few weeks/month, a year)?
[09:43] <robru> alf__: 6 months i guess? I'm working on a major fundamental re architecture that will (among other things) modularize the bzr code so that git code can even be written. Then git is the next thing after that
[09:44] <alf__> robru: thanks
[09:45] <robru> alf__: you're welcome
[13:17] <jgdx> trainguards: what's the dependency wait in silo 6? It complains the dep qml-module-qtsysteminfo (>= 5.0) can't be satisfied, but it's in my xenial.
[13:23] <Mirv> jgdx: the qtsystems has a "~" in the version number after "5.0", "~" means in debian versioning speak "lower than" (since the module has not been released by upstream but is a git snapshot. TL; DR; make it (>= 5.0~)
[13:24] <jgdx> Mirv, oh, ok. Thanks
[14:31] <jhodapp> Mirv, how should we handle this silo situation...silo 53 has the back port of the QtMultimedia audio_role changes that are only for vivid+overlay landing. I need to land a qtubuntu-media change for both vivid and xenial +overlay. I can't build my change in a separate silo without the QtMultimedia back port, but I can't place my qtubuntu-media change into silo 53 because I need to dual land.
[14:37] <Mirv> jhodapp: let's make 053 dual landing, even though qtmultimedia xenial doesn't need changes
[14:37] <jhodapp> Mirv, ok that's what I thought as well, good to get that confirmed
[14:38] <Mirv> jhodapp: it's now dual landing, I'll take care of xenial qtmm no change rebuilds
[14:38] <Mirv> any MP:s should build normally there now
[14:39] <jhodapp> Mirv, awesome thank you
[14:41] <Mirv> jhodapp: note that you ran Build job but there are no MP:s in there so it did not do anything
[14:42] <jhodapp> Mirv, oh hmm, my page must have been stale then
[14:42] <jhodapp> it showed an MP
[14:43] <jhodapp> Mirv, ok updated, thanks
=== Saviq_ is now known as Saviq
[15:38] <bregma> trainguards, I'm seeing the automated signoff fail for my silo, but the failure is unrelated to my package in any way, what's the procedure to resolve this?
[15:57] <Mirv> bregma: get someone with upload rights to the packages in question (main -> core-dev) to click the retest buttons on the excuses page for the failing tets
[15:57] <Mirv> and/or investigate why it's failing and file a bug of flaky test
=== jdstrand_ is now known as jdstrand
=== alan_g is now known as alan_g|EOD
=== ljp is now known as lpotter
=== nuclearbob is now known as nuclearbob_afk
[21:33] <veebers> Hi robru, a couple of questions. I have an autopilot release I would like to do that would also sync the release between V & X, will it cause any issues if I merge the changelog diff into release trunk to get it to build (or is it possible to force it to ignore that and build anyway)
[21:49] <robru> veebers: I'm pretty sure committing the changelog directly to trunk is what I told you to do last time we spoke? what changed/
[21:51] <veebers> robru: ah no you're right sorry, I had it in my mind what we discussed last time wouldn't work, but only part of what we discussed wouldn't work. Sorry :-P
[21:51] <robru> veebers: no worries