[08:02] <michi> #trainguards: anyone around?
[08:02] <sil2100> michi: yep!
[08:02] <michi> I would like access to the silo spreadsheet please
[08:02] <sil2100> What's up?
[08:02] <sil2100> Ah, ok :)
[08:02] <michi> Can you arrange that?
[08:03] <sil2100> Yes
[08:03] <dbarth_> hey guys
[08:03] <sil2100> On it now
[08:03] <michi> Awesome, thanks!
[08:03] <dbarth_> i have silo 001 blocked on a packaging ack
[08:03] <dbarth_> can someone take a look?
[08:04] <sil2100> michi: remember about our documentation here https://wiki.ubuntu.com/citrain/LandingProcess , you should have access now to everything needed
[08:04] <sil2100> dbarth_: hey! Let me look what packages those are
[08:06] <sil2100> hmmm, probably doesn't even need a packaging ACK, let me look
[08:07] <michi> sil2100: Thanks Lukasz!
[08:07] <michi> It’ll be the first time for me, so please be gentle :)
[08:14] <sil2100> dbarth_: yep, there's no ACK needed, some CI Train bug
[08:18] <dbarth_> sil2100: ah good, so it's passed now?
[08:18] <dbarth_> ah yep, cool; thanks
[09:01] <pete-woods> hmm, can't log into CI spreadsheet any more
[09:02] <pete-woods> wonder what's going on there
[09:03] <pete-woods> relaunch chrome -> fixed!
[09:04] <pstolowski> trainfuards hey, may i ask for reconfig of silo 5 & purging its ppa?
[09:04] <pstolowski> trainguards ^ :)
[09:04] <sil2100> pstolowski: sure :)
[09:05] <sil2100> One minute, phone
[09:18] <sil2100> pstolowski: reconfigured and indicator-network removed
[09:24] <pstolowski> sil2100, thanks!
[09:25] <mzanetti> sil2100, good morning. Can we publish this one? http://people.canonical.com/~platform/citrain_dashboard/#?q=ubuntu%2Flanding-026
[09:29] <sil2100> uhhh
[09:30] <sil2100> mzanetti: on it just now, but we seem to have a problem
[09:30] <mzanetti> ah ok. no worries
[09:30] <sil2100> https://code.launchpad.net/~dandrader/unity8/fixShellTests/+merge/262323 is in the list of merges and it's superseeded
[09:30] <mzanetti> oh ffs
[09:30] <mzanetti> I told him not to tpuch it
[09:31] <mzanetti> well, can we still merge the old one? he just added stuff on top of it
[09:31] <mzanetti> that other things can go in a new branch
[09:31] <mzanetti> sil2100, ^
[09:32] <sil2100> So, this branch is still valid?
[09:32] <mzanetti> yeah well. that branch has more commints on top of it now
[09:32] <mzanetti> the future ones need to go in too at some point
[09:32] <mzanetti> but they don't need to be included in this one
[09:33] <sil2100> By 'that branch' you mean the one that superseded this one, right?
[09:34] <sil2100> hm, I guess we might just release it as it is, it won't look nice though
[09:35] <mzanetti> if that's possible, would save a lot of work (given qa has already tested it)
[09:35] <sil2100> Ok then, let me override it - we don't have anything against things like that from our side, since we leave the branch management to upstreams
[09:35] <mzanetti> thanks
[09:35] <sil2100> So as long as you won't feel confused and make sure all will be ok later, then I can publish :)
[09:36]  * sil2100 sighs
[09:36] <sil2100> Ok, not sure if we can do anything without the risk of mass chaos
[09:36] <seb128> what's the issue?
[09:37] <seb128> why is that so problematic to override the warning?
[09:37] <sil2100> seb128: it's not about the warning, it's about LP entering in a strange state afterwards
[09:37] <seb128> get mzanetti to unflag the mr as superseeded and have it approved if needed
[09:37] <seb128> if your only issue is the status of the change
[09:38] <sil2100> seb128: the branch now has new commits that weren't built in the silo
[09:38] <seb128> get somebody to push --overwrite with the content of what was approved for the ppa
[09:38] <sil2100> seb128: so this means that once we land this, we can't mark the MR with the branch as 'merged', as it will not be true
[09:38] <seb128> then once it lands restore the new commits
[09:38] <mzanetti> seb128, how can I unflag it?
[09:38] <mzanetti> ah
[09:39] <seb128> mzanetti, good question, I guess you can delete the new one :p
[09:39] <seb128> but the mp also lists a conflict
[09:39] <seb128> unsure if that needs to be resolved...
[09:40] <mzanetti> that did work
[09:41] <seb128> mzanetti, you might also need to pull out revisions and push --overwrite since sil2100 said there were new commits since the ppa build
[09:41] <mzanetti> it does have conflicts indeed now... I wonder how tho... nothing has been merged to lp:unity8 since this silo was built
[09:41] <seb128> the branch itself got new commit according to Lucasz
[09:42] <mzanetti> yes
[09:42] <mzanetti> after it was built in the silo
[09:42] <seb128> that's wrong
[09:42] <sil2100> It might be caused by the new commits, we need to do something regarding that
[09:42] <seb128> try to restore the built version
[09:42] <mzanetti> afaiu, releasing it now would only include the commits that have been there at build-time
[09:42] <sil2100> mzanetti: yeah, you cannot push anything to a branch without rebuilding it
[09:42] <sil2100> mzanetti: yes, but if we release right now, the branch will be 'semi-landed' and LP will not be able to determine what happened
[09:43] <sil2100> As it won't be able to say: this branch is merged to trunk
[09:43] <sil2100> Since it's not, it's only partially merged
[09:43] <mzanetti> yeah... that's ok I guess
[09:43] <mzanetti> we need to resubmit a MP for the remaining commits
[09:43] <sil2100> We don't allow things like that as it introduces confusion, since you can land a branch two times, you loose history etc.
[09:43] <sil2100> What seb recommended:
[09:43] <mzanetti> ok. need to wait for daniel for that to revert it
[09:43] <sil2100> Branch the current version of the branch to a separate branch
[09:44] <mzanetti> yep, I know how... I just don't have write permissions to this branch
[09:44] <sil2100> Then, revert the original branch to the version you have built in the silo and do a bzr push --overwrite to the branch you MPd originally
[09:44] <sil2100> Ah
[09:44] <sil2100> uh
[09:44] <mzanetti> but Daniel should be here any minute
[09:45] <mzanetti> he's a morning guy. will come back to you when we cleaned up the mess
[09:45] <sil2100> mzanetti: thanks! Let's resolve it in such a way that a rebuild and retest will not be required ;p
[09:45] <sil2100> I suppose seb's idea would work best here
[09:45] <pete-woods> sil2100: if it was you who ran the publish for cmake-extras, the summary of the packaging changes is that we started using cmake to do the install, instead of raw debian packaging
[09:46] <pete-woods> as you need to put the scripts in a different directory, depending on the version of cmake
[09:46] <mzanetti> sil2100, yes, I agree
[09:53] <sil2100> pete-woods: yeah, looks good
[09:53] <pete-woods> :)
[09:59] <mzanetti> sil2100, Daniel just sent a mail that he won't show up today :(
[10:00] <mzanetti> oh wait... maybe I can reach him
[10:01] <seb128> re, sorry I dropped offline for a bit
[10:01] <seb128> sil2100, mzanetti: did you sort it out?
[10:02] <mzanetti> nearly there
[10:02] <sil2100> seb128: well, more or less, we're waiting for the branch owner to appear to do the bzr push
[10:04] <seb128> k
[10:08] <mzanetti> sil2100, should be good now, I hope
[10:08] <sil2100> \o/
[10:09] <sil2100> Yessss
[10:09] <sil2100> It's in
[10:09] <sil2100> o/
[10:09] <mzanetti> ta
[10:47] <ogra_> sil2100, oh, one think i forgot in todays meeting ... shouldnt we turn off the cron builds on weekends again (not sure why they are on, only the commented RTM line has that in crontab)
[10:49] <sil2100> ogra_: uh, they're enabled?
[10:50] <ogra_> yep, got an upgrade every day here :)
[10:52]  * sil2100 looks
[10:52] <sil2100> Strange indeed!
[10:56] <sil2100> ogra_: do you remember where slangasek said the crontabs are held in bzr?
[10:56] <ogra_> well, likely in the cdimage branch
[10:57] <ogra_> https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup
[10:59] <sil2100> hmmm
[12:24] <sil2100> Off to lunch o/
[12:33] <jibel> charles_, Hey, about silo 22, if an alarm is missing from the indicator after an upgrade to OTA4, then I install the silo and reboot, is the alarm supposed to be in the indicator?
[13:14] <rvr> boiko_: ping
[13:14] <boiko_> rvr: pong
[13:14] <rvr> boiko_: Hi! I'm testing silo 20. I have some doubts about this bug https://bugs.launchpad.net/ubuntu/+source/telephony-service/+bug/1462090
[13:15] <rvr> boiko_: When I write +421 2 xxx xx xxx, I get +421 2 / xxx xx xxx (with the slash). I have created a contact with that number.
[13:16] <boiko_> rvr: ok
[13:16] <boiko_> rvr: so, previously dialer-app would not allow you to call that number
[13:16] <rvr> boiko_: When the phone number is tapped, dialer app is opened
[13:17] <rvr> boiko_: Ok, I can call, thanks
[13:17] <rvr> boiko_: I'm approving the silo
[13:17] <boiko_> rvr: great! thanks a lot!
[13:19] <oSoMoN> trainguards: can I have a silo for line 75, please?
[13:26] <brendand> sil2100, is there a new vivid image in the works?
[13:29] <jibel> brendand, there was one this morning, do you need something that landed recently?
[13:30] <brendand> jibel, we have an issue when unity8 lands in the archive after the last image was built, it then fails to start (because it is installed in adt-run's tmp directory)
[13:32] <brendand> we should really try and see if we can fix it though i guess
[13:45] <rvr> sil2100: Is there a problem with silo 11? In the dashboard it says "Uncaught exception: ServerNotFoundError: Unable to find the server at launchpad.net"
[13:50] <sil2100> rvr: looks like an LP issue, let's see if it's transient
[13:54] <sil2100> brendand: I can build an image for you if needed, we don't have anything that we're waiting for
[13:54] <brendand> sil2100, if you could
[13:58] <sil2100> Ok, building an image
[13:58] <sil2100> I'll publish silo 13 in a bit, don't want to confuse the builder
[14:15] <cjwatson> sil2100: That error message isn't an LP error; it's a DNS error looking up launchpad.net, so more likely to be on the train's end
[14:19] <sil2100> cjwatson: righto
[14:20] <sil2100> rvr: the strangest thing about that silo is that I don't know what could have caused this error, I mean, no build happened
[14:20] <sil2100> hm, maybe it became dirty?
[14:20] <rvr> sil2100: PPA has packages
[14:21] <sil2100> Yeah, I know, it even is marked as ready for testing
[14:21] <sil2100> I ran a watch-only build
[14:37] <sil2100> Will publish all in a moment
[14:59] <dobey> cihelp: since silo builds and migration dep8 tests are run against proposed, should we not also have the ps-jenkins MP testing builds using proposed?
[15:04] <fginther> dobey, If silo builds are uring -proposed, there isn't much of a case for not using -proposed for the MP builds.
[15:04] <fginther> s/uring/using/
[15:05] <fginther> dobey, Historically, it's not used -proposed because it was believed to introduce an unnecessary risk of faulty packages
[15:05] <dobey> fginther: well, if something is broken in -proposed, currently one has to wait until the silo is built to discover it. having -proposed enabled for the MP builds will result in such issues being caught more quickly
[15:07] <dobey> fginther: i guess that makes sense for things that don't land in the archive, but for things going in the archive, and thus, via the proposed channel, it probably makes sense to have proposed enabled there. at least for the in-development releases of ubuntu
[15:07] <dobey> for vivid+overlay maybe it makes sense to not have proposed, but i think it makes more sens to have it for wily
[15:08] <fginther> dobey, It's most likely the case that the ci-train process changed the way things should be done, and the decision to not use proposed was never revisited.
[15:09] <fginther> dobey, I also can't say that this is the right answer for all projects, but I can see how this would benefit most.
[15:09] <fginther> dobey, I'll add this as something to look at more closely to see what all would need to be done
[15:10] <dobey> fginther: ok, thanks
[15:31] <AlbertA> trainguards: so landing-042 silo is stuck in migration...it seems the qtmir autopkg test failure has nothing to do with mir: https://jenkins.qa.ubuntu.com/job/wily-adt-qtmir/ARCH=amd64,label=adt/31/consoleFull
[15:31] <AlbertA> trainguards: "-- Installing: /tmp/adt-run.871nin/build.6ma/qtmir-0.4.5+15.10.20150611/debian/tmp2/usr/lib/qt5/plugins/platforms/libqpa-mirserver.so"
[15:31] <AlbertA> "dh_install: qtmir-desktop missing files (usr/lib/*/qt5/plugins/platforms/*), aborting"
[15:32] <AlbertA> a previous successful build install: https://jenkins.qa.ubuntu.com/job/wily-adt-qtmir/ARCH=amd64,label=adt/28/consoleFull
[15:33] <AlbertA> it install into: "-- Installing: /tmp/adt-run.UhYUjr/build.oEz/qtmir-0.4.5+15.10.20150611/debian/tmp2/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqpa-mirserver.so"
[15:33] <AlbertA> so it seems like it's a build environment change?
[15:34] <AlbertA> trainguards: so how do we proceed from here? Can mir be migrated? or does qtmir need to account for these build environment changes (i.e possibly not having the arch in the install lib path?)
[16:02] <sil2100> AlbertA: hmm, if the build env changed and now it causes issues, well, we cannot let it through just like that
[16:02] <sil2100> jibel, davmor2: teh meeting guys
[16:02] <sil2100> We can make it quick
[16:02] <davmor2> sil2100:  with you shortly
[16:03] <sil2100> AlbertA: I would say that if it was caused by a different upload, we need to get to the root cause - bigger changes that break packages should be coordinated with others
[16:03] <sil2100> Which might require mir to get some fixes in...
[16:04] <sil2100> What worries me tho that if it's only broken in wily, we might not be dual-landable anymore
[16:04] <sil2100> AlbertA: let me try looking into this in detail after the meeting
[16:04] <AlbertA> sil2100: ok ... they only thing I can see there affecting qtmir in such a way is cmake
[16:05] <AlbertA> the definition of CMAKE_INSTALL_LIB seems to now be usr/lib and used to be usr/ib/x86_64-linux-gnu
[16:06] <ogra_> sil2100, i can see your screen in the door behind you :)
[16:06] <AlbertA> sil2100: from the two logs shared above...one uses cmake 3.02 the newer one that fails seems to use cmake 3.2.2
[17:03] <robru> charles_: silo 13
[17:24] <sil2100> AlbertA: btw. could you maybe fill in a bug with all the details?
[17:24] <sil2100> AlbertA: you could fill it under cmake
[17:24] <sil2100> I guess we could then forward that to the uploaders as well
[17:27] <AlbertA> sil2100: so was that the issue?
[17:28] <AlbertA> sil2100: looks like mir migrated now...
[17:29] <AlbertA> sil2100: and the last qtmir autopkg run is fine using cmake 3.2.2....https://jenkins.qa.ubuntu.com/job/wily-adt-qtmir/ARCH=amd64,label=adt/32/consoleFull
[17:36] <dobey> trainguards: ^^ can i please get a silo. that unity-scope-click landing will unblock unity8 and some other things in proposed migration
[17:36] <robru> dobey: on it
[17:37] <robru> dobey: 41
[17:37] <dobey> thanks
[17:38]  * dobey waits for the dashboard to catch up
[17:39] <robru> you're welcome
[17:39] <sil2100> AlbertA: cmake was b0rken, but it got fixed with the latest upload
[17:41] <AlbertA> sil2100: oh ok...
[17:42] <sil2100> AlbertA: anyway, no bug is needed anymore ;)
[17:42] <AlbertA> sil2100: ack
[18:22] <robru> sil2100: slangasek: oh heh, just noticed my bug got a reply: https://bugs.launchpad.net/charms/+source/postgresql/+bug/1465863
[18:22] <slangasek> mmk :)
[18:52] <robru> slangasek: actually it just occurred to me that I might be able to fix this at the spec level, by forcing the storage relation to happen before the other relations. I emailed some mojo guys, will experiment with that in a bit
[18:52] <slangasek> ok
[18:55] <boiko> robru: sorry to ask again, but in which IRC channel should I go asking to check why a package is stuck in proposed pocket?
[18:55] <ogra_> boiko, #ubuntu-release usually
[18:56] <boiko> ogra_: nice! thanks
[18:56] <robru> Yep
[19:03] <jibel> charles_, ^ I couldn't reproduce the issue I found earlier and it worked 3 times with the silo. I approved it.
[19:10] <charles> jibel, thanks for the update
[19:19] <robru> bzoltan_: https://ci-train.ubuntu.com/job/ubuntu-landing-011-2-publish/59/console you need to rebuild silo 11, the MPs were updated without being rebuilt.