[00:56] <michi> robru: What does “diff missing” mean
[00:56] <michi> ?
[00:57] <robru> michi: it means the diffs are missing :-P
[00:57] <michi> No kidding! :)
[00:58] <michi> What diffs? For what?
[00:58] <michi> I mean, all I did was hit “Build” after pushing a change.
[00:58] <robru> michi: it's the diffs between what's in the silo and whats in distro.
[00:58] <michi> I didn’t see this previously, which is why I’m asking.
[00:58] <michi> So, how does this happen?
[00:58] <michi> Sorry, this is a bit of a black box to me.
[00:59] <michi> Just wondering whether I should worry.
[00:59] <robru> michi: what's happening here is that there's a race condition in the script that updates the silo status. the build job deletes the diffs first then regenerates them at the end. the status update shouldn't be running when the build job is
[00:59] <michi> Aha.
[00:59] <michi> OK, fair enough. I guess it means I can safely ignore that message then.
[00:59] <robru> but the status updater started just before the build did, so it ran and was like "hey the diffs are gone'
[00:59] <robru> but it's ok because the buld job will regenerate them later
[00:59] <michi> Cool, thanks!
[00:59] <robru> michi: you can ignore it for now. if you hadn't just started a build you'd have to worry about it
[01:00] <michi> OK, no prob, thanks!
[01:00] <robru> michi: fixing that race condition is on my to-do list.
[01:00] <robru> yw
[01:00] <michi> Because you have hardly anything to do at the moment… :(
[01:00] <michi> Thanks again for your herculean effort yesterday!
[01:14] <robru> oh man, yeah, yesterday was nuts. every possible thing that could go wrong, did.
[01:14] <michi> Yes, I got that impression.
[01:14] <michi> Well, all is well again. The train is ticking over very nicely, and it’s really easy to use.
[01:15] <michi> Thanks for making a great tool. And one that was actually built with the needs of poor sods like myself in mind!
[01:15] <robru> michi: oh, you like it? thanks. some days I'm like "man this is crap"
[01:15] <robru> I guess it beats the spreadsheet ;-)
[01:15] <michi> No. I think this is a great example of how to get it right.
[01:15] <michi> I can throw a silo together in two minutes flat and it just works.
[01:16] <michi> that’s really nice.
[01:16] <robru> wow, cool
[01:16] <michi> And it’s easy to see what’s going on with the build, and upgrade the phone once things are done.
[01:16] <michi> I really like it.
[01:16] <robru> thanks dude, that's awesome
[01:16] <michi> My pleasure!
[01:17] <robru> just wait until we get rid of jenkins. then it'll be really streamlined! no more "assigning", you just click build and a PPA will be created automatically. I can't wait for that!
[01:17] <robru> that's a few months out yet though, lots of prerequisites to clean up first
[01:17] <michi> Would love to have that.
[01:17] <michi> I’m a little concerned about the proposal for us to create our own Jenkins builds.
[01:17] <michi> the instructions are awfully complicated.
[01:18] <michi> And copying and pasting a large script around hundreds of times is probably not a good thing.
[01:18] <robru> oh yeah, I was really surprised by that
[01:18] <michi> I think if we need to look after our own Jenkins jobs, we’ll need something more like citrain.
[01:18] <robru> I was thinking s-jenkins would be around forever.
[01:18] <michi> Where I can fill in a handful of fields and just press “Go".
[01:18] <robru> michi: yeah I'm hoping to make the train faster & easier so you don't need s-jenkins at all
[01:19] <michi> What we would need is essentially what s-jenkins does for us now though.
[01:19] <michi> Automatic build/test whenever I push a branch.
[01:19] <robru> hmmm, yeah auto build when a branch is pushed could be a bit trickier.
[01:19] <michi> If there is a manual step involved (however small) after a push to get the testing happening, the testing won’t happen most of the time.
[01:20] <michi> This is one strength of Jenkins.
[01:20] <michi> I just do an MP, and it gets built and tested automatically.
[01:20] <michi> I actually don’t mind Jenkins all that much.
[01:20] <michi> Sure, the UI sucks.
[01:20] <michi> And when something goes wrong with one of the builders, it’s hell for us.
[01:20] <michi> But, when Jenkins is working, it’s really nice to have.
[01:21] <michi> From where you sit, it’s an entirely different story, I’m sure.
[01:21] <robru> michi: yeah, I didn't used to mind jenkins, but the longer I am stuck maintaining one the more flaws I find in it and the more powerless I am to do anything about those flaws. train can't continue being a wrapper around jenkins for much longer
[01:21] <michi> I believe you.
[01:21] <michi> But, whatever the replacement, it has to be at least as automatic as Jenkins is now.
[01:21] <michi> Otherwise we’ll lose.
[01:22] <robru> michi: I think we're talking about two different jenkinses ;-)
[01:22] <michi> ?
[01:22] <robru> you're talking about s-jenkins which does the auto-testing of your merges
[01:22] <michi> Yes.
[01:22] <michi> OK, so you are using a different instance underneath the train?
[01:22] <robru> I'm talking about ci-train.ubuntu.com which is itself a jenkins, which I plan to get rid of and incorporate into bileto
[01:22] <michi> Ah
[01:23] <michi> Well, I don’t really care how the train does its thing, as long as it keeps moving :)
[01:23] <robru> yeah, having the train do auto-rebuilds would be a new feature that we could look into doing, but that's separate from what I'm talking about with "replacing jenkins"
[01:23] <michi> Right
[01:24] <robru> michi: but yeah, jenkins is holding us back in a lot of ways. for one it's preventing us from having unlimited silos. the main goal of getting rid of jenkins is to have unlimited silos. but it will also clean up a huge amount of smaller bugs that the train has hobbled through for years
[01:25] <michi> I didn’t know that it was Jenkins that limited the number of silos.
[01:25] <robru> michi: well, indirectly so
[01:26] <robru> michi: what happened was that the lp people made it possible for us to create ppas dynamically, which is amazing.
[01:26] <robru> michi: but in jenkins we have 4 jobs per ppa("silo") and we don't have a great way of generating those dynamically. basically jenkins needs to be restarted in order to see when new jobs are made. there's kind of a way around that but it's not great and blah blah blah so we're kind of stuck with this.
[01:27] <michi> urgh
[01:27] <robru> so if we get rid of jenkins, we don't need to "create jenkins jobs" for every new silo, and we gain a ton of flexibility
[01:27] <michi> Well, from what I’ve heard, you wouldn’t be the only one to see it go.
[01:28] <michi> only one to be happy to see it go.
[01:28] <robru> heh, yeah
[01:47] <michi> trainguards: Sorry for this...
[01:47] <michi> Would it be possible to delete the s390x packages in silo 26 to stop them from getting published?
[01:47] <michi> After some deliberation, we decided to not try and make the builds/tests succeed for s390x.
[01:49] <robru> michi: uh I'm not able to delete binaries, only sources
[01:49] <michi> Aargh.
[01:49] <robru> michi: if you're going to change something that prevents s390x from building you'll need to rebuild anyway.
[01:50] <robru> michi: because if you just delete s390x, then all that happens is it'll be rebuilt in proposed
[01:50] <michi> robru: After talking with jamesh, he pointed out this: https://lists.launchpad.net/ubuntu-phone/msg17189.html
[01:50] <michi> the problem is that we can’t really test with s390x, except in a silo.
[01:50] <jamesh> robru: the package has never been built in proposed
[01:50] <michi> If something breaks on us all of a sudden on that arch, we are toast.
[01:51] <jamesh> robru: michi had disabled some tests to get s390x to build in the silo, but we think it is better to leave things broken since it won't hide the problems should someone want to get this working on that platform
[01:52] <robru> jamesh: michi: right so just re-enable those tests, rebuild, make sure s390x is broken, then you're good to go
[01:52] <michi> robru: Cool, about to do that.
[01:52] <jamesh> robru: my fear was that there would still be an s390x binary package in the silo from the previous build with the tests disabled
[01:53] <jamesh> robru: or does that get ignored during publishing?
[01:53] <robru> jamesh: publishing only looks at the most recent silo contents
[01:53] <jamesh> robru: great.  That makes things easy
[01:54] <robru> jamesh: michi: thumbnailer does not have a s390x binary in xenial so publication will not block on that being failed.
[02:24] <robru> ok, off to the gym, back in ~2 hours
[04:18] <bzoltan_> robru:  is thre a way to just merge the branch and not to release to Xenial? Or how big problem is if the package stucks in the proposed pocket if the next release comes in a day a or two?
[04:20] <robru> bzoltan_: yeah having stuff in proposed isn't horrible. you can't just include your s390x fix in the same silo?
[04:33] <bzoltan_> robru:  QA does not like rebuilds after QA validation
[04:33] <bzoltan_> robru:  but let me try that... maybe QA will not be badly pissed
[04:36] <bzoltan_> robru:  I pushed a single line change to the landing branch ... It will take some time to build all arches, but it will be fine after that.
[04:43] <robru> bzoltan_: oh I didn't realize it had qa already. ok well if it builds you can publish it after that
[04:44] <bzoltan_> robru:  All right then :)
[04:44] <bzoltan_> robru:  I will still need a jedi's ack on the debian/ changes I guess
[04:45] <robru> right
[05:42] <bzoltan_> robru:  all good, but I am not authorized to publish the ubuntu-themes package from that silo60
[05:42] <bzoltan_> ERROR Publish failed: bzoltan not authorized to upload ubuntu-themes
[06:04] <Mirv> bzoltan_: there's uitk packaging change too so needs coredev
[06:16] <bzoltan_> Mirv: Do we have any of the coredevs active in this time?
[06:33] <Mirv> bzoltan_: not really, sometimes I've pinged RAOF but sil2100 should be here in 2h or so
[06:34] <Mirv> and I'd have the uitk rights if the last meeting had been held, but alas it was not
[09:06] <bzoltan_> Mirv:  have you seen sil2100 aready?
[09:18] <sil2100> bzoltan_, Mirv: what's up?
[09:18] <bzoltan_> sil2100:  I would like to publish the silo60 UITK
[09:18] <bzoltan_> sil2100:  and it has debian/ space changes
[09:19] <sil2100> Let me look at it between promotion preparations
[09:20] <Mirv> bzoltan_: yep, soon there. and btw great that the s390x issue was solved (weird that the same trick that fixed other archs didn't work there)
[09:21] <bzoltan_> Mirv:  This fix is a permanent one at least It is a nice and clean landing... I see the chance to spin off one more UITK before the weekend
[09:22] <sil2100> Mirv, bzoltan_: looking at the packaging diff now, but we'll need to get an ubuntu archive member reviewing it as well
[09:22] <bzoltan_> sil2100:  for me the Overlay PPA and the merge are the most critical
[09:23] <sil2100> hmmm
[09:24] <sil2100> Mirv: do you remember if anyone of us got 1.3.1742+16.04.20151209-0ubuntu1 reviewed by an archive admin when we landed it overlay-only?
[09:26] <sil2100> seb128: hey! Sorry to bother you once again with binNEW reviews - we have 2 packages (the base and its -gles equivalent) adding two new binary packages each
[09:26] <sil2100> seb128: diffs here https://ci-train.ubuntu.com/job/ubuntu-landing-060-2-publish/3/artifact/ubuntu-ui-toolkit_xenial_packaging_changes.diff and https://ci-train.ubuntu.com/job/ubuntu-landing-060-2-publish/3/artifact/ubuntu-ui-toolkit-gles_xenial_packaging_changes.diff
[09:27] <sil2100> seb128: could you take a look and give us a sign if it's good to publish with the new binary packages?
[09:30] <seb128> just had a look, the descriptions could be better "Ubuntu gestures library with SwipeArea" doesn't really explain well what that library is, what is "SwipeArea"?
[09:30] <seb128> that's not a blocker
[09:30] <seb128> also "libubuntugestures" should include the soname and be "libubuntugestures5"
[09:30] <seb128> that's a blocker
[09:30] <seb128> so please fix that before archive upload
[09:30] <seb128> bonus if you improve the description
[09:30] <seb128> otherwise looks fine
[09:31] <sil2100> seb128: ACK!
[09:31] <sil2100> bzoltan_: ^
[09:31] <bzoltan_> seb128: sil2100:  fantastic! Thank you gents.
[09:32] <Mirv> sil2100: I don't really remember that. I think maybe, but then again I may mistake it with another earlier landing. but all done now anyhow :)
[09:32] <bzoltan_> seb128:  the next landing will fix those issues
[09:32] <seb128> thanks
[09:32] <sil2100> bzoltan_, Mirv: if you could change and fix that, rebuilt and I guess no re-testing will be needed
[09:33] <sil2100> Since it's generally just a library package name change
[09:34] <bzoltan_> sil2100:  Let me look after it
[09:34]  * sil2100 goes back to his OTA-8.5 promotion hole
[09:34] <bzoltan_> zsombi:  the archive core devs require a better package description for the libubuntugestures package
[09:35] <bzoltan_> zsombi:  not here
[09:37] <sil2100> The biggest blocker is the library package name if anything ;)
[09:37] <sil2100> Description can be changed later
[09:37] <bzoltan_> sil2100:  so simple s/libubuntugestures/libubuntugestures5/ will do it?
[09:44] <bzoltan_> seb128: do you mean to simple change the package name to libubuntugestures5
[09:44] <bzoltan_> ?
[09:45] <seb128> bzoltan_, http://ubuntu-packaging-guide.readthedocs.org/en/latest/ubuntu-packaging-guide/libraries.html
[09:46] <seb128> bzoltan_, but yes, best practice is to use "libname<soname>" so when the abi/soname change the packages are co-installable which makes transitions easier
[09:48] <bzoltan_> seb128:  makes sense
[10:22] <Saviq> hmm hmm, where are the packages from https://requests.ci-train.ubuntu.com/#/ticket/725 ??
[10:24] <Saviq> trainguards ↑↑ did that get published at all? there are per-silo excuses now, but those are not visible in xenial excuses... are autopkgtests ran on silos now or something?
[10:25]  * Saviq happy if that's the case, but who can retrigger the failed test? :)
[10:26] <robru> Saviq: yes autopkgtests for silos were rolled out on Monday, i forgot to make a big announcement because there was a huge outage at the same time, and also it's a bug experimental as well
[10:26] <Saviq> robru, nice one, /me planned to do that in our Jenkaas, much happier if that's global
[10:26] <robru> Saviq: i know pitti can retry autopkgtests, I'm not sure who else though. New uploads will trigger new tests ;-)
[10:27] <Saviq> right, new uploads will also require manual re-tests and QA ;P
[10:27] <Saviq> robru, thing is, https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-021/excuses.html shows qtmir-gles regression, but http://autopkgtest.ubuntu.com/packages/q/qtmir-gles/xenial/amd64/ does not
[10:27] <sil2100> Not if it's a no-change rebuild! But seriously speaking, just poke pitti on -devel, maybe he can retry it for you for now
[10:28] <Saviq> jibel, can't you restart autopkgtests, too? /me hopes pitti's not our single point of failure ;)
[10:28] <robru> Saviq: oh yeah no, the autopkgtest.u.c site doesn't show the silo results at all. Click the "regression" link to see the full test run log
[10:29] <Saviq> robru, ok, the invalid links should be stripped, then, if possible :)
[10:29] <Saviq> same with version links pointing to void
[10:29] <robru> Saviq: what?
[10:29] <Saviq> robru, https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-021/excuses.html
[10:30] <robru> What broken links?
[10:30] <Saviq> robru, "amd64", "0.4.7+16.04.20151214.1-0ubuntu1"
[10:30] <Saviq> for qtmir-gles in this case
[10:31] <robru> Saviq: links work for me, not sure what you're seeing
[10:31] <Saviq> robru, v
[10:31] <Saviq> https://launchpad.net/ubuntu/+source/qtmir-gles/0.4.7+16.04.20151214.1-0ubuntu1
[10:32] <Saviq> that version is nowhere in ubuntu yet
[10:32] <Saviq> robru, and as you said, http://autopkgtest.ubuntu.com/packages/q/qtmir-gles/xenial/amd64/ does not show results for silo tests
[10:32] <Saviq> both are links out of silo excuses
[10:33] <robru> Saviq: hmm, you'll have to raise that with pitti, he maintains the code that generates that page.
[10:33] <Saviq> ok, not important enough :)
[10:35] <Saviq> robru, can you tell when are they ran? only before publishing or for all builds in silo?
[10:36] <Saviq> (/me only found first in mir QA-Granted silo)
[10:37] <robru> Saviq: currently they are only run if the qa state is "ready for qa" buy that will change soon, we're working out how to streamline the process a bit
[10:37] <robru> Saviq: oh hmmm if qa granted that means the excuses will stop updating ;-)
[10:38] <Saviq> robru, sneaky
[10:39]  * Saviq thought silo 21 was waiting for a +1 from autopkgtests, but will it ever get it, then?
[10:39] <robru> Saviq: yeah if it's in granted state the page will never update
[10:40] <robru> Saviq: ideally qa shouldn't grant before the tests are passing, this is what i mean by the process needing streamlining ;-)
[10:40] <Saviq> robru, agreed, ideally we shouldn't put "ready for QA" unless it's passing, chicken'n'egg! :)
[10:41] <Saviq> robru, all in all, best xmas gift ever! :)
[10:41] <robru> Saviq: yeah i need to invent a new state that means "lander approved, go for autopkgtests" and then it only promotes to ready if the tests pass
[10:41] <robru> Saviq: thanks! That was a huge project!
[10:42] <Saviq> and a surprise, too ;)
[10:54] <Mirv> I wonder what's up with my silo publishing to xenial
[10:54] <Mirv> https://ci-train.ubuntu.com/job/ubuntu-landing-025-2-publish/lastSuccessfulBuild/artifact/packagelist_rsync_ubuntu-landing-025/*view*/
[10:55] <Mirv> sil2100: did you have any visibility to what happens after ^ or would we need eg cj_watson?
[10:56] <sil2100> Mirv: hmm, sadly not, I don't think our copy2distro scripts have user-visible logs (I think)
[10:57] <sil2100> Strange that it would get rejected
[10:58] <Mirv> cjwatson: could you check the above ^ rsync, not found in any queue
[10:58] <Mirv> sil2100: well it's not rejected either, more like these /dev/null:s for some reason
[10:58] <sil2100> By rejected I mean rejected by the script too, but hmmm
[11:00] <cjwatson> it should have mailed whatever the address of the requesting bot is
[11:01] <Mirv> sil2100: did we still have anyone with access to the bot emails..
[11:05] <cjwatson> Odd, I'm not seeing any cicopy logs from today
[11:05] <cjwatson> Oh, I bet it's locked
[11:05]  * cjwatson clears the lock
[11:06] <cjwatson> Mirv: may work in a few minutes
[11:08] <Mirv> ok
[11:14] <cjwatson> Mirv: that seems to have sorted it out; the train should catch up in a bit
[11:14] <cjwatson> I removed /tmp/.cu2d.lock on snakefruit, which was stuck after the train incident last night
[11:22] <bzoltan_> sil2100:  The issues pointed out by seb128 are fixed in the silo60 UITK and the new build is all fine. Would you please publish the packages. I have no right to publish the ubuntu-theme
[11:24] <sil2100> bzoltan_: let me just grab my food and publish, since I'm done with OTA-8.5 now :)
[11:24] <bzoltan_> sil2100: are you? Congratulations for that!
[11:25] <seb128>  bzoltan_, small issue (not need to respin for that), usually the -dev depends on the lib (= ${binary:Version})
[11:26] <bzoltan_> seb128:  I will fix that for the next release (eta tomorrow). Thank you.
[11:26] <Saviq> trainguards, can we publish https://requests.ci-train.ubuntu.com/#/ticket/725 please? or is it waiting on something?
[11:29] <seb128> bzoltan_, thanks
[11:32] <Mirv> cjwatson: looks good, thanks! there were indeed another landing stuck  there too but they're now all in
[11:33] <Mirv> Saviq: a core-dev, so sil2100 could publish it
[11:33] <Mirv> I pinged RAOF earlier but he was probably already gone
[11:33] <cjwatson> Mirv: right, ubuntu-push too
[11:34] <Saviq> Mirv, ah, tx
[11:37] <seb128> xavigarcia, charles, could you look at bug #1502094 for indicator-sound? it's probably just changing gee-1.0 to gee-0.8  in the Makefile and debian/control, would be nice to have that done in one of the next landings if we can
[11:37] <sil2100> Saviq: on it in a minute, was a bit busy in the morning ;)
[11:37] <ubot5> bug 1502094 in unity-lens-files (Ubuntu) "libgee-0.8-dev should be used, libgee-dev will be removed from the archive" [High,In progress] https://launchpad.net/bugs/1502094
[11:37] <seb128> xavigarcia, charles, and yeah, the versionning is backward, 1.0 is old and 0.8 newer
[11:41] <xavigarcia> seb128: sure, I will take a look
[11:42] <seb128> xavigarcia, thanks
[11:42] <seb128> xavigarcia, it's probably trivial, https://code.launchpad.net/~seb128/unity-lens-files/use-gee-0.8/+merge/280696 is one example
[11:43] <xavigarcia> seb128: I see... I need to check the state of the repository, though, as we had a rolled back landing last month
[11:43] <xavigarcia> seb128: and it seems we are delaying some fixes in the sound indicator until a pulseaudio issue is fixed
[11:44] <seb128> k
[11:44] <seb128> well no hurry
[11:44] <seb128> that needs to be done for the LTS
[11:46] <xavigarcia> seb128: okay
[11:54] <sil2100> seb128: hey! Have time for another binNEW ;) ? This time quite trivial as it's a standard mir soversion bump: https://ci-train.ubuntu.com/job/ubuntu-landing-021-2-publish/1/artifact/mir_xenial_packaging_changes.diff
[11:54] <seb128> +1
[11:55] <seb128> (are we sure the .pc removed is not used?)
[11:56] <seb128> lunch now, bbiab
=== mzanetti_ is now known as mzanetti
[12:16] <kdub> trainguards, silo 21 is still undergoing testing, found an 11th hour bug... please don't publish just yet
[12:17] <sil2100> Saviq, Mirv: ^
[12:17] <sil2100> I wanted to publish but wanted one of the merges approved, and good thing it was unapproved as it wasn't ready for release ;)
[12:17] <sil2100> seb128: thanks! :)
[12:18] <Mirv> thanks kdub
[12:18] <kdub> I'm not sure how it went to QA granted yet, it was toggled to "QA needed" briefly, and then back to "QA required" a few minutes later when the bug was found
[12:23] <sil2100> We had a train derailment, maybe it got switched back then
=== alan_g is now known as alan_g|lunch
[13:45] <Saviq> sil2100, kdub, ack :(
=== alan_g|lunch is now known as alan_g
[14:13] <Saviq> "jenkins is preparing to shut down", should I not start jobs?
[14:14] <Saviq> or will they just get picked up when it's back up again?
[14:17] <jhodapp> sil2100, the release notes for OTA 8.5 don't mention background playlists in media-hub
[14:18] <sil2100> jhodapp: ah, right, we had to pull that in with the fixes, right?
[14:18] <jhodapp> sil2100, yes indeed
[14:36] <jhodapp> sil2100, can you please dput the qtmultimedia source pkg from ppa:jhodapp/ubuntu/ppa to silo 34 please?
[14:37] <sil2100> jhodapp: sure
[14:37] <jhodapp> ooh, double please :)
[14:37] <jhodapp> thanks
[14:38] <fginther> nerochiaro, the lp:camera-app/staging and lp:qtubuntu-camera/staging branches are now setup. Please let us know if there are any changes necessary
[14:40] <jhodapp> sil2100, let me know when I can do a watch only build on that silo
[14:41] <nerochiaro> fginther: where do i get the packages ?
[14:41] <sil2100> jhodapp: 5.4.1-1ubuntu19, right?
[14:42] <jhodapp> yes
[14:42] <sil2100> jhodapp: ah, we'll need the ~overlay1 appended, right? Can I do it, or do you keep normal versioning for the overlay?
[14:42] <Mirv> charles: you've held to this silo for two months, do you still need it or can it be abandoned to free up silos? https://requests.ci-train.ubuntu.com/#/ticket/507
[14:42] <jhodapp> sil2100, hmm, robru has never had to do that before
[14:43] <sil2100> Not sure what's the notation for qt packages
[14:43] <jhodapp> sil2100, pretty sure he just uploaded it as is
[14:43] <sil2100> Mirv: hey! You append ~overlay to qt packages released to the overlay? I don't think so, right?
[14:44] <Mirv> sil2100: usually nowadays yes, like the today's qtdeclarative was ~overlay2
[14:44] <sil2100> hm hmmm
[14:44] <Mirv> and same for qtbase + qtpim
[14:44] <sil2100> Ok, so let's do it here too
[14:44] <sil2100> jhodapp: no worries, taking care of it :)
[14:44] <Mirv> sil2100: here as in where?
[14:45] <jhodapp> sil2100, thanks!
[14:45] <jhodapp> Mirv, a new qtmultimedia upload from me
[14:45] <sil2100> Mirv: qtmultimedia-opensource-src
[14:45] <Mirv> sil2100: jhodapp: ah ok, yes, better there too
[14:45] <jhodapp> Mirv, and all of these changes are already upstreamed :)
[14:45] <sil2100> \o/ ;)
[14:46] <jhodapp> Mirv, would you be able to push the -gles package after sil2100 is done?
[14:46] <jhodapp> silo 34
[14:47] <Mirv> jhodapp: great! I hope all of them would be soon merged too in upstream so that we know they're happy with them
[14:47] <sil2100> jhodapp: ok, package pushed
[14:47] <Mirv> jhodapp: ok
[14:47] <jhodapp> Mirv, they already are happy with them, they just literally need to merge it
[14:47] <jhodapp> thanks sil2100
[14:51] <Mirv> jhodapp: I've bookmarked the following three at least: https://codereview.qt-project.org/#/c/138927/ + https://codereview.qt-project.org/#/c/142109/ + https://codereview.qt-project.org/#/c/142334/ all need formal code-review approval, after which you can also yourself click a button to try merging them to staging
[14:52] <Mirv> anyway, let's hope they're getting there soonish
[14:53] <jhodapp> Mirv, yes they're in Yoann's hands
[14:54] <Mirv> jhodapp: btw I'm not sure if you noticed but tsdgeos filed bug #1523407 - since Unity 8 is doing dual landings (=same code for vivid + xenial), they will need the code to be exactly as it is in upstream also for xenial before they can start utilizing features. so there's some work for January there, to make vivid even more identical upstream and then of course syncing up everything to xenial
[14:54] <ubot5> bug 1523407 in Canonical System Image "Playlist support in vivid+overlay and Xenial is different/non compatible" [High,Confirmed] https://launchpad.net/bugs/1523407
[14:55] <Mirv> and I think it was the comment #1 that they then agreed is the correct way, unlike what Albert wrote in the description :)
[14:55] <Mirv> otherwise xenial would need to lie about its version
[14:55] <jhodapp> Mirv, yes that's a story currently in progress for my team's current sprint
[14:55] <sil2100> jhodapp: yw!
[14:56] <Mirv> jhodapp: ok! anyway, uploading the gles now to the same silo
[14:56] <jhodapp> Mirv, thanks!
[14:56] <jhodapp> Mirv, we did the first steps already of syncing media-hub and gstreamer versions across vivid and xenial, next comes the higher level stuff like qtmultimedia and qtubuntu-media
[14:58] <fginther> nerochiaro, oh, let me fix that
[15:00] <Mirv> jhodapp: ok, I noticed the gstreamer ones. I think with time you could even move to dual landings (or even the next one could be such potentially).
[15:00] <Mirv> the teams that are doing those generally seem pretty happy with the less complexity
[15:01] <jhodapp> Mirv, yes indeed
[15:01] <jhodapp> Mirv, oh I really want to get there, it is a little annoying because we used to be told to just ignore wily landings
[15:01] <jhodapp> now it's the opposite
[15:36] <fginther> nerochiaro, I fixed the missing debs. I've retriggered the build for https://code.launchpad.net/~uriboni/camera-app/no-permissions-dialog/+merge/279260
[15:36] <nerochiaro> fginther: ok, so every MR that is submitted against these two branches will have packages rebuilt automatically and jenkins will post a note on the MR ?
[15:37] <fginther> nerochiaro, yes, that should all be working now
[15:37] <nerochiaro> fginther: thanks
[15:39] <jhodapp> jibel, does this bug only happen on arale or have you seen it on krillin as well? https://bugs.launchpad.net/ubuntu/+source/media-hub/+bug/1479036
[15:40] <ubot5> Ubuntu bug 1479036 in media-hub (Ubuntu RTM) "/usr/bin/media-hub-server:6:__gnu_cxx::__verbose_terminate_handler:__cxxabiv1::__terminate:std::terminate:__cxxabiv1::__cxa_throw:core::ubuntu::media::HashedKeyedPlayerStore::player_for_key" [Critical,Confirmed]
[16:19] <jibel> Mirv, why do we need silo 5 at all on the overlay? it has nothing to do with the phone, does it?
[16:29] <tvoss> trainguards, I would need a silo for https://requests.ci-train.ubuntu.com/#/ticket/793
[16:29] <tvoss> sil2100, Mirv ^
[16:29] <sil2100> On it!
[16:29]  * tvoss making sure the request is seen
[16:30] <Saviq> trainguards, what does "Diff missing" mean when in silo status for a set of packages?
[16:33] <seb128> can we get the ubuntu-ui-toolkit/ubuntu-themes silo force merged?
[16:33] <sil2100> Saviq: not sure what causes that to happen, but usually a DIFF_ONLY build should help in that case
[16:33] <seb128> I want to do another ubuntu-themes landing today before holidays and it's getting tight ... that one already migrated but I guess no way to force merge one component only?
[16:34] <seb128> uitk is still doing autopkgtests
[16:34] <Mirv> jibel: it's for people like kenvandine who run overlay on their desktop for development purposes.
[16:34] <sil2100> seb128: yeah, no standard way of doing that, safest bet is to merge everything
[16:34] <seb128> sil2100, can you do it?
[16:35] <sil2100> seb128: let me look into that
[16:35] <Saviq> sil2100, I think it might be a failed build job causing it
[16:36] <sil2100> seb128: hmm, I see it's landed, the changes should be merged?
[16:36] <sil2100> https://requests.ci-train.ubuntu.com/#/ticket/778 ?
[16:36] <Mirv> Saviq: train's diffs are not there. either run build job normally or with DIFF_ONLY for a no-op
[16:36] <Saviq> I just had a build with that bombed because of conflicts
[16:36] <Saviq> Mirv, ack
[16:38] <sil2100> seb128: hmm, interesting! The landing didn't have an ubuntu-theme merge in it
[16:38] <seb128> hum?
[16:38] <sil2100> seb128: or maybe it did but during the train outage it got nuked...
[16:38] <sil2100> seb128: it did have the ubuntu-theme package tho
[16:38] <seb128> so we need to manually merge?
[16:39] <seb128> https://code.launchpad.net/~ci-train-bot/ubuntu-themes/ubuntu-themes-ubuntu-xenial-landing-060
[16:39] <seb128> sil2100, ^
[16:39] <sil2100> I suppose we need to manually merge as the train obviously forgot about this merge completely
[16:39] <sil2100> A bzr push --overwrite is what the train usually does
[16:40] <seb128> k, I can do that that
[16:41] <sil2100> seb128: thanks! And sorry for this, I suspect the derailment to be the cause of this situation
[16:42] <renatu> trainguards, could you assign this silo for me? https://requests.ci-train.ubuntu.com/#/ticket/794
[16:42] <sil2100> renatu: assigning!
=== sil2100 changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? ping cihelp | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: CATASTROPHIC TRAIN FAILURE restored from stale backup, please do your best, I'm sorry. Please run "DIFF_ONLY" build job on your silos. Also, low on silos!
[16:45] <renatu> sil2100, thanks
[17:33] <jibel> bfiller, renatu silo 55 approved
[17:35] <bfiller> jibel: thanks
[17:37] <bfiller> jibel: looks like 45 landing as well, hope we don't have to rebuild 55 as 45 has address book as well?
[17:52] <bzoltan_> trainguards: I would like to ask for a silo  - https://requests.ci-train.ubuntu.com/#/ticket/796
[17:54] <bzoltan_> Mirv: sil2100: ^
=== alan_g is now known as alan_g|EOD
[18:14] <bzoltan_> Is here a trainguard at this hour?
[18:44] <Mirv> bzoltan_: all 60 are assigned right at the moment
[18:44] <Mirv> bzoltan_: I'll clean my qtdeclarative one since I follow up it anyway
[18:46] <Mirv> bzoltan_: ok you have silo
[18:47] <Mirv> bzoltan_: kicked a build too
[18:53] <bzoltan_> Mirv:  thank you!
[20:40] <dobey> trainguards: can i get a retry on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-041/+build/8448901 please?
[20:47] <robru> dobey: on it
[20:50] <dobey> robru: thanks
[20:50] <robru> dobey: yw