[08:00] <Saviq> Mirv, morning... any idea where unity8 from https://requests.ci-train.ubuntu.com/#/ticket/1138 ended up on xenial? the silo was force-merged so that we could speed up other landings, but a few packages seem to have ended up in oblivion :(
[08:02] <Saviq> also, any idea about the "blanket FFe" we got before on touch components? is it still in effect or should we actually open up xenial overlay already?
[08:33] <jibel> Mirv, can you help vicamo with the publication of silo 70. The is a packaging change which I think need a ack from someone
[08:34] <jibel> there*
[08:47] <robru> Saviq: I'm not sure what happened specifically in that case, but anything force merged while a silo is in "UNAPPROVED queue" would wind up in oblivion, yes. force merging is only safe for packages in proposed pocket.
[08:48] <robru> Saviq: indeed http://paste.ubuntu.com/15485856/ the ones listed as "UNAPPROVED queue" are lost and you can blame kenvandine for force merging
[08:49] <Saviq> robru, yeah was worried that was what happened
[08:50] <robru> Saviq: best course of action I guess is to hurry up and finish the next silo and get it published, assuming it has all the same packages. if it doesn't, you'll need a new silo with null merges in order to get trunk released to xenial
[08:50] <Saviq> robru, can we not recover the packages in the silo and publish?
[08:50] <Saviq> undelete/copy to a new silo
[08:51] <Saviq> they're all there after all
[08:51] <robru> Saviq: yeah I suppose you can fish them out: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-013/+packages?field.name_filter=&field.status_filter=&field.series_filter=
[08:51] <Saviq> yup that was what I was thinking
[08:52] <robru> Saviq: probably easiest to get a core dev to just copy them directly to -proposed, less work than starting a new silo and copying to a new PPA and then publishing all over again
[08:52] <Saviq> robru, yup
[08:52] <Saviq> sil2100, morning!
[08:52] <Saviq> you awake yet? ;)
[08:52] <sil2100> Saviq: morning!
[08:59] <robru> sil2100: so the new source package build code is live and has had a dozen or so successful builds today, including GLES packages, so I don't expect you'll see too many surprises at this point. watch out for unity8, mediascanner2, unity-scopes-api and unity-scopes-shell, those ones will now require the branches I submitted to them already.
[08:59] <Saviq> sil2100, so... because we jumped the gun yesterday, some packages from silo 13 ended up in oblivion (UNAPPROVED queue, so never got into proposed)
[08:59] <Saviq> sil2100, http://pastebin.ubuntu.com/15485893/
[09:00] <Saviq> any chance you could fish them out from the PPA and into proposed?
[09:03] <sil2100> Saviq: let me take a look
[09:04] <sil2100> uh, unity8 landed in the UNAPPROVED queue?
[09:05] <Saviq> that's what the train said, yeah
[09:05] <Saviq> and then, because Ken force-merged it (because we had no idea it wasn't good until things are in proposed), they just went POOF
[09:06]  * Saviq thought UNAPPROVED is *in* proposed
[09:06] <sil2100> I thought things would be good as well - it doesn't see them as valid anymore?
[09:07] <sil2100> Since it should still be visible as a sync in UNAPPROVED, so in theory it should migrate to -proposed once someone pushes the button
[09:07] <Saviq> not sure where UNAPPROVED is, though
[09:09] <sil2100> cjwatson: hey! An archive-related question: we have a bunch of uploads that went to the UNAPPROVED queue (CI Train copy-package from a silo PPA) and then we got the silo freed (with the packages removed) - did the package removal cause any issues here, or are we still safe?
[09:12] <robru> sil2100: what? no. merging in UNAPPROVED has never been legit.
[09:13] <sil2100> robru: what's happening then?
[09:14] <robru> sil2100: Saviq: "pockets" are places where packages actually live, eg proposed pocket and release pocket. "queues" are like TODO lists "eventually copy this somewhere". if you delete a package from a PPA and it's just in UNAPPROVED queue, then when they go to copy it they find the source PPA is empty
[09:14] <Saviq> ah
[09:14] <sil2100> robru: deleted packages are still in the PPA, they don't disappear completely ever
[09:14] <sil2100> So LP is not able to find them just because of that?
[09:14] <Saviq> but the copy probably looks for one in Published state
[09:14] <sil2100> That's a bit sad
[09:15] <robru> sil2100: well however queues are managed they don't see deleted PPA packages. this was always the case. every time somebody force merges packages in UNAPPROVED eventually some archive person pings me (like months later) saying "hey what happened to this sync, the source disappeared"
[09:15] <Saviq> sil2100, maybe easiest to copy the deleteds to a new silo and publish once more?
[09:15] <robru> sil2100: this situation will only get worse as we move to ephemeral PPAs and delete the entire PPA rather than just delete packages from the PPA.
[09:16] <robru> eg the PPA will really be deleted and it won't be possible to just "copy the deleted package"
[09:16] <Saviq> so maybe force_merge should not allow that when copys are in a queue
[09:17] <Mirv> Saviq: jibel sorry, on holiday today
[09:17] <Saviq> Mirv, go away then ;P
[09:17] <robru> Saviq: well at one point all the train guards knew this, which is why we made it so that only train guards can force merge, I'm not sure why everybody forgot this recently.
[09:17] <jibel> Mirv, np sil2100 is on it. Enjoy your holidays
[09:17] <sil2100> Saviq: yeah, that's the plan I'm realising ;)
[09:18] <Saviq> robru, they probably forget every time a new release is open so no UNAPPROVED ;)
[09:19] <Saviq> sil2100, thanks
[09:20] <robru> Saviq: I guess. ken should have known this too. argh.
[09:20] <Saviq> robru, now I know :)
[09:22] <oSoMoN> Mirv, do you have rights to publish oxide-qt? silo 80 is ready to land
[09:23] <sil2100> oSoMoN: I'll be on it once I deal with this aftermath here
[09:24] <oSoMoN> sil2100, thanks
[09:24] <davidbarth> thanks indeed, it's ready and hopefully the last release for that ota
[09:28] <robru> sil2100: sounds like you have everything under control. goodnight!
[09:28] <om26er> dobey, Hi! What should I look out for in silo 66 ?
[09:31] <jibel> om26er, the U1 login page is blue and it shouldn't
[09:31] <jibel> I think that's the visible part of the buf
[09:31] <jibel> bug*
[09:32] <om26er> jibel, that rightly is Fast track
[09:33] <jibel> om26er, https://launchpadlibrarian.net/248086202/screenshot20160314_120118243.png is the bug
[09:34] <om26er> jibel, does 'Fast track' tag also means we don't need to go through the TestPlan or is it still required to run the test plan ?
[09:35] <jibel> om26er, run the part of the test plan affected by the change only, verify that the issue is fixed
[09:36] <morphis> sil2100: ping
[09:36] <Saviq> robru, the gles refactor in train is not yet in effect, is it?
[09:37] <sil2100> morphis: pong
[09:37] <morphis> sil2100: you talked with QA about https://requests.ci-train.ubuntu.com/#/ticket/1145 ?
[09:38] <sil2100> morphis: yes, they should be aware
[09:38] <morphis> sil2100: great, thanks
[09:38] <morphis> jibel, davmor2: any reason why I don't see https://requests.ci-train.ubuntu.com/#/ticket/1145 on the QA board yet?
[09:41] <davmor2> morphis: because we hate you ;) I can create a ticket but I think jibel can set it in the system so we get all the info from bileto
[09:42] <morphis> davmor2: that is the reason I see :-)
[09:42] <morphis> davmor2: more to come :-)
[09:43] <davmor2> morphis: no you only get one for ota10 final freeze and all that :P
[09:46] <morphis> davmor2: I am just development others take the decision what to push and what not :-D
[09:47]  * davmor2 makes note to block everything morphis lands in future :P
[09:47] <morphis> :-)
[09:54] <jibel> morphis, proposed migration failed with unsatisfiable deps
[09:54] <jibel> morphis, https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-028/excuses.html
[09:56] <morphis> jibel: yes, but that is just because vivid itself misses thigns and britney doesn't know about the overlay ppa properly (that is what sil2100 told me)
[09:56] <morphis> jibel: we ignore that execuse last time
[10:01] <jibel> morphis, ^
[10:03] <morphis> jibel: thanks!
[10:23] <sil2100> Saviq: did you get my earlier message?
[10:33] <robru> Saviq: the recent rollout did affect how gles are handled but you still need to supply null merges for gles packages. Only difference is the get-orig-source target is ignored & handled by train now
[10:33] <robru> (I'm totally not here tho)
[10:37] <robru> Saviq: the larger refactoring where gles is totally handled for you is caught up with some other big changes and will take a bit longer. For now, enjoy the faster build times ;-)
[10:38] <cjwatson> sil2100: Deleted packages are remembered forever to the extent that you can't ever reuse a version number in the same archive, but the actual files are garbage-collected after a short delay (a day or two?  I forget) after deletion
[10:38] <cjwatson> In an ideal world the copy request would hold a reference such that they aren't GCed
[10:39] <cjwatson> But it needs quite a lot of complex refactoring before that's possible, unfortunately
[10:45] <Saviq> sil2100, don't think I did
[10:45] <sil2100> Darn VPN issues
[10:45] <sil2100> 11:20 < sil2100> Saviq: I got preempted for a bit from your silo (emergency in the turbo
[10:45] <sil2100>                  world), but I'll get back to re-adding the remvoed packages once I can
[10:45] <Saviq> sil2100, nw, thanks
[10:45] <Saviq> I know what's the prio
[10:46] <sil2100> Saviq: I'm actually doing some copies in the background to silo 57 already
[10:47] <Saviq> tx
[11:38] <bzoltan> sil2100: Something is fishy here - https://launchpadlibrarian.net/249786544/buildlog_ubuntu-xenial-armhf.ubuntu-ui-toolkit_1.3.1908+16.04.20160324.2-0ubuntu1_BUILDING.txt.gz
[11:39] <bzoltan> sil2100: `dbus-test-runner --task gdb [...]` segfaults
[12:13] <sil2100> cjwatson: thanks - another quick question: the package publisher in LP, how much time does it actually need for a single package?
[12:13] <sil2100> Since I made a snapshot (so a lot of copies from one PPA to another) and I'm waiting for them to publish since over 30 minutes
[12:20] <cjwatson> sil2100: That's not a meaningful question, because it doesn't operate at the single-package level; it basically runs in a loop republishing all PPAs that have changed.  So it depends on other activity in the system.
[12:21] <cjwatson> sil2100: That said, it's spent the last hour or more working on nothing but your snapshot.
[12:22] <cjwatson> sil2100: Looks like it's maybe two-thirds of the way there or so?  I can only guess
[12:24] <cjwatson> You're asking for it to copy an awful lot of data around over the network, so it takes quite a while.
[12:24] <cjwatson> It's literally been streaming data out of the librarian for basically an hour.
[12:25] <sil2100> hah
[12:25] <sil2100> Thanks ;)
[12:25] <cjwatson> Then it will have to think for quite a while to generate the indexes.
[12:26] <cjwatson> Not sure how long that will take.
[12:55] <Saviq> sil2100, mterry's around now so we should be able to untangle the situation ourselves
[12:56] <mterry> Saviq: I don't have UNAPPROVED rights
[12:56] <popey> jibel: do you have someone assigned / planned to test dekko for OTA-10?
[12:56] <popey> jibel: I don't see a card in https://trello.com/b/AE3swczu/qa-testing-requests-for-questions-ping-ubuntu-qa-on-ubuntu-ci-eng
[12:56] <mterry> Saviq: I think that's release team?
[12:56] <mterry> Saviq: no.  archive admins
[12:57] <Saviq> mterry, as long as we start with putting the packages in the new PPA and publishing them, we can then start chasing them
[12:57] <sil2100> mterry, Saviq: no worries, I almost have all the packages in the PPA
[12:57] <sil2100> Will publish in a moment
[12:57] <Saviq> ktx
[12:57] <mterry> Saviq: oh wait, maybe I misunderstood.  I assumed the packages were sitting in the UNAPPROVED xenial queue.  You're talking like they're lost and we're doing archeology
[12:58] <Saviq> mterry, UNAPPROVED queue is just that - a queue, the packages can't sit there
[12:58] <Saviq> (I learned this morning)
[12:58] <Saviq> it's just a reference to packages that are to be copied
[12:58] <mterry> Saviq: well they can if the queue isn't processed right?
[12:59] <Saviq> mterry, they still need to remain in where *from* they are to be copied until they're copied
[12:59] <mterry> Saviq: oh....
[12:59] <Saviq> mterry, queues don't actually hold source packages
[12:59] <mterry> Saviq: so deleting the PPA was bad then.  I get it
[12:59] <Saviq> yup
[12:59] <mterry> Saviq: that's funny
[12:59] <sil2100> mterry, Saviq: all packages in silo 57 now
[12:59] <Saviq> coolz
[13:00] <cjwatson> sil2100: Oh, didn't actually take too long after I said that.
[13:00] <sil2100> cjwatson: indeed :)
[13:00] <cjwatson> mterry: It's basically a Launchpad bug, but a very difficult one to fix.
[13:01] <sil2100> cjwatson: waiting for a few others to get published that I had to copy afterwards
[13:01] <cjwatson> Saviq: Not even a proper reference; it just names the things to copy.  If it were a reference then this would be easily fixable.
[13:01] <Saviq> right, depends on the definition of a reference :)
[13:03] <jibel> popey, if there is no request there won't be any card on the board
[13:05] <chrisccoulson> Can I have a silo to land the fix for bug 1559428 ?
[13:11] <greyback_> trainguards: hey, what have I got wrong to cause this: https://ci-train.ubuntu.com/job/ubuntu-landing-013-0-status/9529/consoleFull
[13:11] <kenvandine> oh geez... i had no idea... if UNAPPROVED is just a reference what happens to packages that were dput?
[13:12] <kenvandine> Saviq, robru: sorry about that... i thought that was ok
[13:14] <Saviq> greyback_, that's likely the same issue - packages not published to xenial
[13:14] <Saviq> greyback_, but it shouldn't be fatal
[13:14] <sil2100> greyback_: eh, you got silo 13 huh?
[13:15] <greyback_> sil2100: yeah
[13:15] <greyback_> good luck 13, eh?
[13:15] <dobey> om26er: check for regressions and that the colors are correct
[13:15] <Saviq> right, that might be interesting :)
[13:15] <sil2100> greyback_: I suppose this will clear out once we get the packages re-published
[13:16] <dobey> oh i guess jibel answered
[13:16] <kenvandine> i didn't read all the scrollback, did someone figure out how to resurrect the packages?
[13:16] <om26er> dobey, approved that already
[13:16] <sil2100> Saviq: could you confirm https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-057 has all packages we need?
[13:16] <greyback_> sil2100: Saviq, ok thanks
[13:16] <Saviq> kenvandine, yeah, copied to silo 57 and publishing again
[13:16] <kenvandine> whew
[13:16] <dobey> om26er: yeah, just saw. thanks
[13:17] <Saviq> sil2100, UNAPPROVED queue (geonames/xenial, indicator-datetime/xenial, indicator-session/xenial, qtmir-gles/xenial, qtmir/xenial, qtubuntu-gles/xenial, qtubuntu/xenial, unity-api/xenial, unity8/xenial).
[13:17] <Saviq> so yeah, looks fine
[13:17] <Saviq> sil2100, but waiting to publish - you saturated LP with the snapshot ;)
[13:17] <sil2100> ...;)
[13:18] <sil2100> Yeah, sorry about that
[13:19] <Saviq> sil2100, btw, are we opening xenial overlay any time soon?
[13:19] <dobey> sil2100: can you publish/pkg ack silo 66?
[13:19] <sil2100> We could, that would be nice to discuss and decide for next week
[13:21] <cjwatson> kenvandine: unapproved is just a quasi-reference in the case of copies.  it's somewhat more concrete in the case of direct uploads.
[13:22] <kenvandine> cjwatson, noted... i didn't realize it was handled differently for copies
[13:28] <sil2100> dobey: will do, got preempted to turbo agian
[14:12] <Saviq> mterry, can you please publish https://requests.ci-train.ubuntu.com/#/ticket/1179 - the PPA seems published now
[14:12] <mterry> k
[14:12] <Saviq> sil2100, FYI ↑
[14:13] <mterry> Saviq: it says "UNAPPROVED queue"?  makes me think it already got published?
[14:13] <Saviq> mterry, well, I'm not sure what will happen - the packages were added to the queue, but then disappeared from the PPA
[14:14] <Saviq> it might be we'll actually need to no-change rebuild them, otherwise archive might reject since it's the same version
[14:14] <Saviq> mterry, or we ask someone with the powers to actually copy to proposed
[14:16] <mterry> seb and didier aren't around...  let me see who else to bother
[14:16] <sil2100> Just re-publish
[14:16] <mterry> ok
[14:16] <sil2100> We allow re-publishing sources from the same silo, the same should apply if it's from a different silo
[14:17] <mterry> done
[14:19] <sil2100> mterry: thanks!
[14:22] <Saviq> mterry, looks a bit no-op... https://ci-train.ubuntu.com/job/ubuntu-landing-057-2-publish/6/consoleFull
[14:23] <Saviq> ok so how do we now ask for these to be copied to proposed? we need FFe?
[14:25] <mterry> Saviq: well we got an FFe before...  that was before final freeze hit.  But I think we should be fine.  Just need to bug an archivee admin
[14:27] <Saviq> mterry, can you please take care of that?
[14:28] <mterry> Saviq: ok
[14:31] <cjwatson> Saviq: version checks don't apply to things in the queue FWIW
[14:31] <cjwatson> this may or may not be considered a feature
[14:35] <Saviq> :)
[14:47] <pstolowski_> sil2100, hey, any idea why this keeps failing https://launchpadlibrarian.net/249805433/buildlog_ubuntu-xenial-amd64.unity-scopes-shell_0.5.7+16.04.20160324.3-0ubuntu1_BUILDING.txt.gz ? note http://pastebin.ubuntu.com/15487628/
[15:33] <charles> hm
[15:33] <charles> indicator-display test failure, let's see what happened...
[15:49] <pstolowski_> cjwatson, hey, any idea about the issue I mentioned above (1h ago)?
[15:53] <pstolowski_> cjwatson, ah, i just noticed the comment from robru under this silo...
[15:54] <robru> pstolowski_: I'm not sure if my comment would result in that failure, but if you look at the diffs that were generated, your debian/control file is wrong because you're missng my branch
[15:54] <pstolowski_> robru, i've just added your MP to my silo, retrying
[15:59] <jibel> Kaleo, bfiller_ silo 30 approved
[16:00] <sil2100> jibel, davmor2: if you guys don't mind, let's skip today's LT meeting - all is clear I suppose nayway
[16:00] <bfiller_> jibel: I saw, thank you
[16:00] <jibel> sil2100, +1 to skip
[16:00] <davmor2> +1000 to skip it
[16:00] <cjwatson> pstolowski_: doesn't look especially exotic, you're missing a build-dep
[16:00] <cjwatson> (on cmake)
[16:01] <robru> pstolowski_: diffs look good with my branch in place, good luck with your build failure!
[16:03] <pstolowski_> cjwatson, i've cmake in build-deps (note, we have control.in and control is generated). it's most likely the pre-release-hook change from robru that's now needed
[16:03] <cjwatson> I guess
[16:04] <pstolowski_> yeah i think it looks good so far in the silo
[16:17] <charles> morphis, ondra, this is a bit of a tracer so I wouldn't be surprised if this one fails too
[16:18] <morphis> charles: aye
[16:44] <Saviq> robru, here's my approach https://code.launchpad.net/~unity-team/qtmir/inline-gles-quilt/+merge/290061
[16:47] <charles> well, ok then
[16:50] <Kaleo> jibel, thanks!
[17:00] <jhodapp> robru, so what's the process with britney for silo 53...it's been approved by everybody including QA, ready to land, but now qtubuntu-camera needs a rebuild because another qtubuntu-camera change landed first
[17:02] <robru> jhodapp: nothing to do with britney... You'll need to wait for the other silo to merge, rebuild qtubuntu-camera, resubmit to qa, and stop submitting conflicting silos to qa as it's a total waste of their time.
[17:03] <jhodapp> robru, well I had no way of knowing there was another qtubuntu-camera in another silo
[17:03] <jhodapp> robru, also, who's to say that I wasn't first? QA just completed theirs before my silo
[17:04] <jhodapp> robru, this process feels like it could be improved a bit is all I'm trying to say
[17:04] <robru> jhodapp: you should be coordinating this with other landers. Once upon a time the train wouldn't even allow you to have the same package in two silos, do i need to bring that back?
[17:04] <jhodapp> robru, I think a simple warning detecting the process would be useful, I don't think you need to make it mandatory
[17:05] <jhodapp> robru, I was coordinating with the owner of qtubuntu-camera
[17:06] <jhodapp> robru, that warning could be useful in these times when there's a higher potential for overlapping commits right before an OTA freezes
[17:07] <robru> jhodapp: I'm not sure what a good solution is, the thing is this is an inherent problem of vcs systems, not some train specific deficiency. You have to merge the other silo that was published first otherwise your publish will revert the other one
[17:08] <jhodapp> robru, right and that's why I think a warning or other type of way to present to someone who is creating a new request to the same project might be useful. Help them be aware of it. The main list of active silos is large and hard to read IMO so that info will be lost there.
[17:10] <robru> jhodapp: there used to be code to iterate over silos and detect conflicts and warn about them but it doesn't scale when you have so many silos, it was taking forever to run
[17:10] <jhodapp> robru, that would run when submitting a new silo request?
[17:10] <robru> jhodapp: at the time it ran during every build and added many minutes to the build process
[17:11] <jhodapp> robru, yeah, maybe it could run once on demand when someone requests a silo
[17:11] <robru> jhodapp: i think what we really need is some way to track it on the qa side, "this package cannot be qa'd again until the last one that got approved merges"
[17:12] <robru> jhodapp: that doesn't work because the set of packages in a silo isn't known at assign time. Also the concept of assignment is on the way out
[17:12] <jhodapp> robru, I don't think it has to be that heavy handed...in my case if I could simply know that there already is an existing landing request again qtubuntu-camera I'd know to go coordinate with that person
[17:13] <jhodapp> robru, ok how about run it right after assignment happens
[17:13] <robru> jhodapp: because packages can change over the life of a silo, it would need to be updated periodically
[17:13] <jhodapp> robru, that wouldn't matter how fast it is then, because how many people request a silo, get it assigned and then immediately want to land it
[17:13] <jhodapp> robru, so run it any time the package list changes
[17:14] <jhodapp> that'd be a perfect trigger
[17:14] <robru> jhodapp: please file a bug against lp:bileto and specifically mention that qa people are wasting time reviewing stuff that can't possibly land.
[17:15] <jhodapp> robru, will do man, thanks!
[17:15] <robru> You're welcome
[17:15] <jhodapp> robru, apologies if I came off annoyed to you, I was frustrated
[17:15] <robru> jhodapp: yeah sorry my first message was overly accusatory
[17:16] <jhodapp> robru, np, I'm interested in improving the process so that's why I ping you
[17:16] <robru> jhodapp: yeah there's lots of improvements to be had. I'm working on parallelizing builds now so they'll be even faster
[17:16] <jhodapp> that's awesome
[17:17] <robru> Wish I'd thought of it sooner!
[17:17] <jhodapp> incremental improvements :)
[17:17] <robru> Yep
[18:15] <jhodapp> robru, here's the bug I just filed: https://bugs.launchpad.net/bileto/+bug/1561673
[18:15] <jhodapp> robru, what do you think of that last paragraph idea?
[18:16] <jhodapp> robru, so basically that's a way to synchronize overlapped landings in a first-come-first-serve kind of way automatically
[18:17] <robru> jhodapp: yeah that's an interesting idea, as britney is already gating what goes to QA or not.
[18:17] <jhodapp> exactly
[18:17] <jhodapp> once the other silo has landed, then britney can be tried again
[18:17] <jhodapp> that could be automatic but doesn't have to be
[18:18] <robru> jhodapp: something to think about. britney wouldn't be able to store that state but we have a little wrapper script around britney that could do it...
[18:18] <jhodapp> oh awesome
[18:18] <jhodapp> robru, but that would at least make it impossible for two things that have the same package in it to show up on the QA board, and I'm sure they'd be happy with that
[18:30] <robru> yeah
[19:39] <camako> robru, the MP you added to silo 80, is it needed even though this is a test silo (not meant to be landed)?
[19:40] <robru> camako: yep, trust-store doesn't build right without it (the train changed, this brings trust-store up to speed with the train changes). particularly the vivid packages will be built wrong. it'll be needed in all trust-store silos until one of them eventually lands on trunk
[19:42] <camako> tvoss, ^
[19:44] <robru> camako: if you saw my 'ACTION REQUIRED' email on ubuntu-phone this week, trust-store is one of the affected packages.
[19:44] <tvoss> robru, please elaborate
[19:44] <camako> robru, ack I saw... It's just that this silo is not to land
[19:44] <robru> tvoss: https://lists.launchpad.net/ubuntu-phone/msg19015.html
[19:44] <robru> camako: doesn't matter... the package won't actually build correctly without it. the SONAME in vivid will be wrong
[19:45] <camako> robru, ok gotcha
[19:45] <camako> thanks for your quick action
[19:46] <robru> camako: you're welcome. I've been monitoring the train for affected packages because it's a tricky change.
[19:51] <robru> Saviq: you need my unity8 branch in https://requests.ci-train.ubuntu.com/#/ticket/1186 or you won't get translations updated
[20:10] <Saviq> robru, I know, that's ok, there's no translation changes there
[20:10] <Saviq> wanted to keep this silo as small as possible
[21:32] <salem_> trainguards: hi, can anybody trigger a rebuild of messaging-app/xenial/powerpc and ppc64el on silo 42?
[21:35] <robru> salem_: on it
[21:35] <salem_> robru, thanks
[21:38] <robru> salem_: you're welcome