[01:46] <bfiller> kenvandine: I'm testing silo 35 and am really confused, I put my comments in the bug https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1390120
[02:10] <kenvandine> bfiller, i just replied to your comment
[02:11] <kenvandine> bfiller, we're only looking at the change between auto and manual, not about actually changing the time
[02:11] <bfiller> kenvandine: what is automatic supposed to do?
[02:11] <kenvandine> enables NTP
[02:11] <kenvandine> this systemd-shim does properly fix that, without it NTP isn't supported
[02:12] <kenvandine> but... it only really fixes it for devices that are read/write
[02:12] <bfiller> kenvandine: I'm not seeing the time update when switch to automatic though
[02:12] <bfiller> I have read/write
[02:12] <kenvandine> we need to figure out where the daemon sets the state and add it to the whitelist of writable paths
[02:12] <kenvandine> well that would be a different bug :)
[02:12] <kenvandine> i bet NTP doesn't change the clock immediately after enabling it
[02:13] <kenvandine> which would be a different bug
[02:13] <kenvandine> so besides that, we have 2 problems
[02:13] <bfiller> kenvandine: yeah, think there are a few bugs actually. Once I set my time manually I cannot change it back and have it persist across reboots
[02:13] <kenvandine> systemd-shim in wily and vivid doesn't support NTP
[02:13] <kenvandine> so changing auto/manual does nothing at all
[02:14] <kenvandine> my patch fixes that, so it does change the state
[02:14] <kenvandine> but we aren't letting the state persist
[02:14] <kenvandine> we need a fix in lxc-android-config for it to persist
[02:14] <kenvandine> but i haven't been able to figure out what path to add
[02:15] <bfiller> kenvandine: ok
[02:15] <bfiller> kenvandine: seems less critical than my clock now being stuck at Weds May 20th and not being able to chagne back :)
[02:15] <kenvandine> haha
[02:16] <bfiller> seriously I'm stuck
[02:16] <bfiller> it's bad
[02:16] <kenvandine> i tried pinging a couple people today to ask about the path... but couldn't figure it out
[02:16] <kenvandine> wow
[02:16] <kenvandine> that's bad
[02:17] <bfiller> once you actually change it manually you can never get the old time back. keeps it until you reboot then reverts to the changed time again
[02:17] <kenvandine> weird
[02:17] <bfiller> I'll file a bug
[02:17] <kenvandine> yeah
[02:17] <kenvandine> that's bad
[06:36] <thostr_> robru: regarding your comment for ci sheet line 66: have you expected just a two line diff?
[06:39] <robru> thostr_: well i was told it was a simple fix and then the diff came out 2mbs, so something's wrong there
[06:44] <thostr_> robru: 2mbs?
[06:45] <robru> thostr_: https://ci-train.ubuntu.com/job/ubuntu-landing-038-1-build/ it's right there. What are you looking at?
[07:02] <thostr_> robru: I was just looking add the MP
[07:02] <thostr_> Wellark: ^ why does the diff show all src files it seems including doc?
[07:03] <Wellark> thostr_: for which one?
[07:03] <thostr_> Wellark: https://ci-train.ubuntu.com/job/ubuntu-landing-038-1-build/
[07:03] <robru> thostr_: yeah so most likely they did a release to vivid and then never released to wily, so this diff includes a bunch of previous landings. Needs Wellark to confirm what's going on and verify ski contents. Could very well be a harmless sync but i can't be sure on my own
[07:04] <thostr_> robru: yes, we restructured stuff in between, so this explains
[07:04] <Wellark> robru: yep
[07:04] <Wellark> I will double check the diff
[07:06] <Wellark> robru: so yes. there was a langing
[07:06] <Wellark> where packages where built and released against vivid+overlay
[07:06] <Wellark> but source merged to 15.10 trunk
[07:07] <robru> Wellark: k. Just need you to smoke test the silo then Mirv can publish it to wily for you.
[07:07] <Wellark> so now, the wily diff (when looking deltas between packages) looks huge
[07:08] <Wellark> the repo diff is not huge
[07:08] <Wellark> except for the .po update
[07:08] <Wellark> which generates a lot of noise
[07:08] <Wellark> Mirv: --^
[07:09] <robru> Wellark: yeah, it's 2mbs of diff ;-) just want you to test it a bit to make sure nothing's gone wrong with such a huge diff
[07:12] <Wellark> robru: ok. everything OK. ;;; ship it ;;;
[07:12] <Wellark> :)
[07:13] <Wellark> the vivid overlay should look sane
[07:13] <Wellark> that was just wily missing a round of packages
[07:13] <Wellark> Mirv knows the details
[07:15] <Wellark> robru: may I already have the vivid silo while waiting for Mirv? :)
[07:17] <Wellark> oh, seems the spreasheet fixed it self
[07:21] <robru> Wellark: one sec
[07:24] <robru> Wellark: ok, silo 19 for vivid
[07:24] <Wellark> robru: <3
[07:24] <robru> Wellark: Mirv should be around soon if you need anything else, I'm out since it's half past midnight here ;-)
[07:34] <Wellark> robru: I could hug you
[07:34] <Wellark> but I don't know your IP
[07:34] <Wellark> <3
[07:36] <robru> Wellark: lol, you're welcome
[07:42] <Mirv> I've been around for 3h now :)
[07:42] <Mirv> sorry, just super focused on Qt syncing
[07:43] <Wellark> Mirv: I know you like to play around with your hobbies, but we have actually important stuff here to land
[07:43] <Mirv> :D
[07:43] <Wellark> Mirv: :P
[07:44] <Mirv> I see it was published in the end, so now only vivid overlay to go
[07:50] <sil2100> Phew...
[08:20] <Mirv> kenvandine: I think I maybe never replied, but there's now bug #1456886 open about the adt problem plus someone just forced most of the stuff in regardless of that
[09:02] <pedronis> trainguards: hi, question, I have a device-indepedent fix that may need to go in vivid overlay,  I have a mako, I'm a bit confused which channel I should use to test on? (also for the landing process)
[09:10] <sil2100> pedronis: hey! I know this can be a bit confusing ;)
[09:10] <sil2100> So, generally:
[09:11] <sil2100> For mako the best 'stable-overlay' channel is ubuntu-touch/rc-proposed/ubuntu, as this is the community channel, but nothing would happen if you would test it on ubuntu-touch/rc-proposed/bq-aquaris.en, as it also has mako images
[09:11] <sil2100> Both have the same rootfs but different custom tarballs
[09:12] <sil2100> If your fix is device independent, it shouldn't matter
[09:12] <sil2100> I think generally QA recommends using ubuntu-touch/rc-proposed/bq-aquaris.en as every change gets eventually released on krillin, and that's the place where krillins are flashed from
[09:12] <pedronis> thanks, bit confused because I don't see ubuntu-touch/rc-proposed/ubuntu in udf query
[09:13] <pedronis> anyway I can use the other one as you said
[09:13] <sil2100> huh
[09:13] <sil2100> Maybe slangasek didn't set it up yet? I'll check with him later
[09:13] <pedronis> ubuntu-device-flash query --device=mako --list-channels
[09:13] <sil2100> Use the ubuntu-touch/rc-proposed/bq-aquaris.en in this case
[09:13] <pedronis> yep, thanks
[09:52] <Wellark> Mirv: whoops
[09:53] <Wellark> I accidentally pushed lp:~unity-api-team/indicator-network/lp1456307_15.04 to trunk..
[09:53] <Mirv> Wellark: sounds like your merge skills need some finetuning
[09:54] <Mirv> I accidentally the whole trunk
[09:54] <Wellark> how do I revert this without breaking silo landing
[09:54] <Wellark> ?
[09:54] <Mirv> Wellark: bzr uncommit, bzr uncommit, bzr revert, bzr push --ovewrite (..while triplechecking you're not breaking anything _more_)
[09:55] <Mirv> Wellark: plus have a copy of current status etc in another dir
[09:55] <Wellark> Mirv: LP already considers the MP merged
[09:55] <Wellark> if I force push...
[09:56] <Mirv> well I guess you could manually mark the MP as not merged
[09:57] <Wellark> Mirv: where do I need the revert?
[09:57] <Wellark> I've uncommitted the revisions in the MP now
[09:57] <Wellark> so push --override to the trunk should do the trick, right?
[09:57] <Mirv> Wellark: I'd start with the currently mangled trunk and uncommit there, but if you think you get to the same status with your branch, yes go ahead
[09:58] <Mirv> bzr revert is just optional that gives you easier possibility to review how the branch looks without those newer commits
[09:59] <Wellark> Mirv: ok. let's try
[09:59] <Wellark> Mirv: https://imgflip.com/i/lqxxm
[09:59] <Mirv> :D
[10:01] <Wellark> ok. fingers crossed
[10:02] <Wellark> Mirv: ok. the build started
[10:13] <Mirv> looking good
[10:33] <dbarth_> hey there trainguards, can i get a binary copy of oxide for a silo request on line 71? thanks
[10:47] <Mirv> dbarth_: sure thing
[11:59]  * sil2100 off to prepare some lunch
[12:26] <Mirv> hmm, why has ppa-purge stopped working for me
[12:36] <Mirv> I guess because it hasn't, actually
[12:37] <Wellark> Mirv: line 67 ready to land
[12:38] <Wellark> but we need a QA Grand for it
[12:38] <Wellark> Mirv: the diff looks huge
[12:38] <Wellark> but that's the .po update
[12:38] <Wellark> https://ci-train.ubuntu.com/job/ubuntu-landing-019-1-build/lastSuccessfulBuild/artifact/indicator-network_content.diff
[12:47] <Mirv> Wellark: published
[12:49] <Mirv> sil2100: what do you think of landing uitk already landed to wily to vivid-overlay? it fixes all the wanted milestone bugs but also has a few other changes.
[12:49] <Wellark> Mirv: <3
[12:51] <bzoltan> Mirv: sil2100: changes like a dozen of bugfixes... including a super critical one... namingly the version separation
[12:51] <Wellark> Mirv, sil2100: any idea why the (Ubuntu RTM) bug did not get marked as Fix Released?
[12:51] <Wellark> https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1456307
[12:52] <Wellark> or are the updates run in delayed manner?
[12:52] <Mirv> Wellark: vivid-overlay is not rtm, it's vivid-overlay PPA. Launchpad currently does not understand the overlay as any sort of bug target. having that feature is one of the benefits of the ubuntu-rtm way of life.
[12:53] <Mirv> not sure of the plans, it'd be annoying to close every bug by hand
[12:54] <Wellark> Mirv: someone told me yesterday that citrain will close the bugs targeted to ubuntu rtm even if the landing happens to vivid+overlay
[12:54] <Wellark> sil2100: was it you? :)
[12:55] <bzoltan> Mirv: sil2100: I will have a meeting soon with bfiller and pmcgowan, so I will ask their opinion. I hope that the fear driven development is the past :) We have massive QA process on the UITK.
[12:55] <Mirv> Wellark: oh, that'd be good news! :)
[12:56] <cjwatson> Mirv: we handed over a launchpadlib script that you folks could run for this purpose.
[12:56] <Wellark> bzoltan: fear driven development is more interesting! https://imgflip.com/i/lqxxm
[12:57] <bzoltan> Wellark:  LOL :) nice one
[12:58] <sil2100> Wellark: not setup yet ;) It'll be released soon!
[12:58]  * sil2100 still didn't finish settin that up
[13:02] <Wellark> sil2100: oh, ok :)
[13:02] <Wellark> will close the bug manually then
[13:15] <jodh> jibel: Hi - ogra_ suggested I ping you about testing the fix for bug 1447756 (ci train spreadsheet row 61).
[13:16] <ogra_> jibel, testing that will be rather problematic for QA ... since you need an affected device
[13:17] <ogra_> jibel, i'd suggest leaving the testing of the fix to ondra (whio has an affected device) and you guys just do some regression testing to sign it off
[13:17] <ondra> ogra_ I gave phone back to Andy, so hard one to test
[13:18] <dobey> ev: ok, thanks
[13:19] <ogra_> ondra, well, it needs to be tested for vivid (afaik it was only tested with the wily silo yet) ... and Qa needs to sign it off somehow ...
[13:19] <ondra> ogra_ I can test on some devices in the office tomorrow
[13:20] <ogra_> ondra, good, you need to make that out with QA (jibel) though ... they are the ones sayinf yay or nay :)
[13:21] <ondra> ogra_ OK
[13:22] <abeato> sil2100, now that spreadsheet is (kind of ;) working again maybe you can remove line 22
[13:22] <sil2100> abeato: hah, sure ;)
[13:22] <abeato> sil2100, thanks
[13:23] <jodh> ondra: ogra_: jibel: pat has specified on the bug that "We ... need the fix to land by May 21".
[13:24] <ogra_> jodh, pat has no power if QA doesnt let it in :)
[13:25] <ogra_> they are the ones you need to convince :)
[13:25] <jodh> ogra_: understood, but do we know why the 21st is the key date here?
[13:25] <ogra_> next OTA landing lockdown i guess
[13:28] <jodh> ogra_: ondra: in prep for QA testing, does someone need to make the modified boot.img (which does not specify '--no-log' in /proc/cmdline) available?
[13:31] <dbarth> trainguards: we have validate oxide 1.7.8 in silo 038; do you prefer to land that via the silo, or get the update from the security team ppa?
[13:38] <sil2100> dbarth: did QA verify it as well?
[13:39] <dbarth> sil2100: not yet
[13:39] <dbarth> sil2100: apparently, it's safer / quicker to go with the silo
[13:39] <dbarth> sil2100: as the security update may be delayed (for other releases as well) to tomorrow
[13:40] <dbarth> sil2100: this way we can secure the vivid release for the image
[13:40] <sil2100> dbarth: I would go with the silo as well, since our silo has a higher pin priority basically
[13:55] <abeato> trainguards, could I get a silo for line 71 ?
[13:56] <sil2100> abeato: on it
[13:57] <sil2100> abeato: uh, sadly, still all ouot of silos
[13:57] <abeato> sil2100, ok
[14:21] <slangasek> sil2100: yes the last round of channel renames hasn't been done yet
[14:21] <slangasek> sil2100: I was waiting for fallout from the last round, apparently there's been none :)
[14:22] <sil2100> slangasek: all seems to be fine so far ;)
[14:22] <sil2100> I updated the developer channel page today even
[14:23] <sil2100> slangasek: could you create the /ubuntu channels then?
[14:23] <sil2100> I suppose those could be nice to have for non-krillin users, as currently they don't really have any solid channels to use
[14:29] <slangasek> sil2100: yes, I don't know that I'll get time to create them today though - and if we're doing the key rotation tomorrow I may not have time tomorrow either and I'm off on Friday and Monday.  So it might be next Tuesday before it gets done
[14:30] <sil2100> ACK, thanks :)
[14:31] <sil2100> jibel, davmor2: hey! Could you also prioritize the sign-off of silo 21?
[14:31] <sil2100> jibel, davmor2: it has a fix for the bootloop issues
[14:32] <davmor2> sil2100: no
[14:32] <davmor2> :D
[14:32] <sil2100> :|
[14:32] <sil2100> ;)
[14:41] <pedronis> trainguards: I added ralsina as a second lander to line 74. in case a silo gets free while I'm not around but he is
[14:44] <kenvandine> bzoltan, when can we get the upstart branch for uitk landed in wily?  it'll fix the adt tests and unblock the proposed migrations
[14:44] <kenvandine> https://code.launchpad.net/~canonical-platform-qa/ubuntu-ui-toolkit/upstart/+merge/259262
[14:44] <kenvandine> seb128, ^^  that's the fix that will unclog the plumbing for wily :)
[14:44] <bzoltan> kenvandine:  with the next landing yes
[14:45] <sil2100> pedronis: ok
[14:45] <kenvandine> bzoltan, eta?
[14:45] <bzoltan> kenvandine:  I am pushing the OTA4 landing right now ... so I can take it on Friday and hopefully it will land on Monday or on Tuesday. The UITK landing is a heavy process.. only the silo validation is an 18 hours job
[14:46] <kenvandine> it's just a missing depends... i miss the days of just using dput for simple packaging fixes :/
[14:47] <seb128> kenvandine, great
[14:48] <kenvandine> sort of... we'll have to wait nearly another week for the depends fix :/
[14:48] <kenvandine> Mirv had said they flushed the queue, but the excuses page still shows it's blocked
[14:49] <barry> sil2100: i am going to have a new version of system-image to go into the train to replace the existing one in wily landing 11.  i'm bumping the version number to -0ubuntu2.  should i just blow away the existing silo and create a new one?
[14:49] <sil2100> barry: let me see what's in 11
[14:49] <kenvandine> seb128, and the fix was proposed last week... anyway i'll stop complaining
[14:50] <dobey> trainguards: is the spreadsheet messed up again?
[14:50] <barry> dobey: it seems unresponsive
[14:51] <sil2100> dobey: it looks fine here so far, but maybe it started being broken again
[14:51] <sil2100> Let me check if I get an error notice in 5 minutes
[14:51] <sil2100> barry: so, we would need to merge silo 11 first I think
[14:51] <dobey> sil2100: i think row 50 is landed, but the status column doesn't show it as "Landed" with the green background
[14:51] <sil2100> barry: ah! Or maybe not, as you said you want to replace it completely
[14:52] <barry> sil2100: that version got stuck in promotion and it won't clear without the fixes i want to upload next
[14:52] <barry> sil2100: yep
[14:52] <sil2100> barry: ok, feel free to free it up then and re-do it from scratch
[14:52] <barry> sil2100: +1 thanks
[14:52] <sil2100> dobey: well, that's a known bug
[14:53] <dobey> oh
[14:53] <sil2100> dobey: the spreadsheet is too slow to notice releases to the overlay PPA and sometimes doesn't notice a silo landing
[14:53] <sil2100> I'll fix it up in a moment
[14:53] <barry> sil2100: sanity check: click Clean, enable ONLY_FREE_SILO and nothing else.  right?
[14:53] <sil2100> Not much we can do about that long term
[14:53] <sil2100> barry: yep :)
[14:53] <barry> sil2100: thanks!
[14:53] <dobey> sil2100: ah ok
[14:54] <dobey> charles, thostr_: ^^ see what sil2100 said about status in spreadsheet of things landing in vivid overlay re: i-power landing
[14:55] <sil2100> dobey: this will take a moment as I need to fill some additional info as well
[14:55]  * sil2100 sighs
[14:55] <sil2100> The spreadsheet needs to die
[14:56] <barry> sil2100: i think it already has several times :)
[14:56] <barry> maybe it's like a cat
[14:58] <dobey> sil2100: no worries. spreadsheet does need to die
[15:02] <sil2100> mzanetti: ping
[15:02] <sil2100> mzanetti: you saw that unity8 in silo 32 failed to build?
[15:03] <sil2100> mzanetti: I think you're missing a dependency... connectivity-qt1 is not found by cmake
[15:03] <mzanetti> sil2100, no... the dependency had a bug in the pkgconfig module
[15:03] <mzanetti> sil2100, should be fixed now. will trigger a rebuild
[15:04] <sil2100> ACK
[15:07] <oSoMoN> trainguards: can I have a silo for line 75, please?
[15:07] <sil2100> oSoMoN: hey! We're out of silos right now...
[15:07] <sil2100> mzanetti: does silo 3 have the fix in it?
[15:09] <mzanetti> sil2100, the problem is in connectivity-qt, not in unity
[15:09] <mzanetti> s/is/was/, apparently
[15:10] <sil2100> Ok, so it's safe to publish silo 3 then?
[15:10] <sil2100> hm, maybe I'll wait for the 32 to finish building
[15:13] <oSoMoN> sil2100, is there a waiting list for landing requests without a silo?
[15:13] <sil2100> The spreadsheet is the waiting list ;)
[15:14] <sil2100> There's a few of those already
[15:14] <sil2100> Silos shouldn't be limited
[15:28] <mzanetti> sil2100, ok. silo 3 seems to be building now. at least it succeeded for amd64. but still I'd say we wait for the complete build, just to be sure
[15:33] <sil2100> Sure
[15:33] <sil2100> Let's maybe change silo 3 back to not ready for ladning then
[15:34] <sil2100> Just so that we land both at the same time
[15:41] <oSoMoN_> sil2100, dbarth_ says silo15 can be recycled for line 75
[15:45] <sil2100> oSoMoN_: ok, will we land silo 15 later?
[15:46] <oSoMoN_> sil2100, the MR in it is not entirely ready to land yet, so we will request another silo at a later time
[15:46] <sil2100> oSoMoN_: ACK
[16:02] <mzanetti> sil2100, ok. finished building
[16:02] <sil2100> mzanetti: could you test if everything works on vivid? Then we can hand it over to QA for sign-off
[16:02] <mzanetti> sil2100, ack
[16:12] <bfiller> sil2100: can I have a silo for line 64 please?
[16:18] <sil2100> bfiller: sadly still no free silos ;/
[16:18] <sil2100> We might need to scan for any ones that we can free up
[16:19] <bfiller> sil2100: ok
[16:20] <sil2100> kgunn_: hey! When would silo 004 be ready for landing?
[16:22] <kgunn_> sil2100: so that's full shell rotation, we'd ideally want to land that post RC image
[16:22] <kgunn_> we did discuss potentially landing in wily asap, then sync'ing later to vivid+
[16:23] <sil2100> The silo is configured for wily right now so it potentially could
[16:23] <kgunn_> it's ultimately mzanetti's decision
[16:23]  * mzanetti reading
[16:23] <sil2100> ogra_: hey! You guys have silo 27 but didn't build it yet
[16:23] <kgunn_> sil2100: is there a problem with that silo hovering around ?
[16:23] <sil2100> ogra_: will that be used?
[16:24] <sil2100> kgunn_: well, normally not, we're just low on silos so I'm asking around ;)
[16:24] <ogra_> sil2100, not sure what that is, i only know about 16 for lxc-android-config
[16:24] <sil2100> ogra_: it's also lxc-android-config
[16:24] <ogra_> yes, i see that
[16:24] <sil2100> Bug #1454625 - Cannot send MMS for combined contexts when wifi is connected (spreadsheet row 61).
[16:25] <sil2100> Maybe it's abeato's landing
[16:25] <ogra_> same bug
[16:25] <ogra_> likely the wily sync
[16:25] <ogra_> building now
[16:25] <sil2100> Might be
[16:27] <mzanetti> sil2100, I think I'll land silo 4 to wily asap when 3 and 32 are out of the way
[16:28] <sil2100> Ah, right, hm, we'll have to land 3 first probably as it has a sync
[16:28] <sil2100> Right
[16:29] <mzanetti> yep
[16:32] <kenvandine> ogra_, sil2100: i have lxc-android-config in silo 25 now waiting for qa verification
[16:32] <kenvandine> silo 35 rather
[16:33] <kenvandine> ogra_, oh... and the same version is in silo 16
[16:33] <kenvandine> i really wish that used bzr branches...
[16:34] <kenvandine> ogra_, also for ota4... should we maybe combine those in one silo?
[16:35] <ogra_> kenvandine, 013 too
[16:36] <kenvandine> silo 13 won't be landing for ota4
[16:36] <ogra_> oh ?
[16:36] <kenvandine> i was just thinking combining the silos we need for ota4
[16:36] <ogra_> then tethering will regress
[16:36] <kenvandine> no, it's not really ready...
[16:36] <abeato> sil2100, ogra_ yes that's the sync
[16:36] <kenvandine> regress?
[16:37] <ogra_> yes
[16:37] <kenvandine> we never landed hotspot :)
[16:37] <ogra_> tethering
[16:37] <ogra_> not hotspot :)
[16:37] <kenvandine> oh that also has a fix for that?
[16:37] <ogra_> wired ...
[16:37] <ogra_> yes, the lxc-android-config package has it
[16:37] <kenvandine> i thought it was just the fix we needed for hotspot to work
[16:37] <ogra_> we combined both
[16:37] <kenvandine> ah
[16:38] <ogra_> probably should rip that apart again
[16:38] <ogra_> i wasnt aware hotspot would land
[16:38] <ogra_> *would not
[16:38] <kenvandine> since we don't have handy bzr branches to handle lxc-android-config o
[16:38] <kenvandine> i'd be in favor of combining all of the ones we need for ota4
[16:38] <ogra_> feel free to switch it :)
[16:39] <ogra_> long term i need to hand it to someone anyway with my new duties ...
[16:39] <ogra_> want to adopt it ? :)
[16:40] <kenvandine> NO
[16:40] <kenvandine> :)
[16:40] <ogra_> LOL
[16:40] <kenvandine> i spent a bunch of time trying to figure out who to ask about it :)
[16:40] <ogra_> you wouldnt have to anymore in that case :)
[16:40] <kenvandine> haha
[16:40] <kenvandine> that's ok...
[16:41] <ogra_> (and if you dig deep enough into the code, there is a pot of gold hidden underneath ... )
[16:41]  * kenvandine doesn't believe ogra_
[16:41]  * ogra_ tries everything :)
[16:41] <kenvandine> so we'd have to manually merge all these together... a mess
[16:41] <ogra_> i think all changes are in different files
[16:42] <kenvandine> maybe not to bad
[16:43] <kenvandine> ogra_, so i assume you aren't volunteering to do it?
[16:43] <kenvandine> :-D
[16:44] <ogra_> not 15min before EOD ... my GF would kill me if i did ... i can offer tomorrow morning though
[16:44] <kenvandine> i'll do it :)
[16:44] <ogra_> shouldnt be to hard i think
[16:44] <ogra_> changelog merging will be the most work i guess
[16:44] <kenvandine> i'll pull the changes from 13 and 16 and put them with mine in 35
[16:45] <ogra_> let me check 13 again in detail
[16:45] <ogra_> yeah, it only has the tethering fix there
[16:45] <ogra_> https://launchpadlibrarian.net/205346168/lxc-android-config_0.221_0.222.diff.gz
[16:46] <ogra_> trivial one liner
[16:46] <dobey> ev: were you testing by having jenkins do a rebuild on an existing MP?
[16:46] <ogra_> 16 is a bit more but in a different file ...
[16:47] <kenvandine> ogra_, oh, silo 16 is a wily landing
[16:47] <dobey> ev: or should i be bugging whoever is current vanguard? your message in my awaylog this morning was the last thing i'd heard re: coverage for unity-scope-click
[16:47] <ogra_> abeato, awe, can you do your testing of silo 27 (vivid MMS fix) with kenvandine's silo 35 instead ?
[16:47] <ogra_> kenvandine, it would have been a sync
[16:47] <ogra_> kenvandine, vivid definitely needs the fix
[16:50] <awe> ogra_, I have to defer to abeato on this one...
[16:50] <robru> alex-abreu: so https://code.launchpad.net/~abreu-alexandre/ubuntu-html5-theme/fix-page-actions/+merge/259515 has a new commit that you didn't build.
[16:50] <robru> alex-abreu: you need to rebuild the silo and re-test
[16:50] <alex-abreu> robru, oh sorry, I'll rebuilt & retest
[16:51] <robru> alex-abreu: thanks
[16:53] <kenvandine> ogra_, what's in silo 13 also removes two files that aren't mentioned in the changelog
[16:54] <kenvandine> lib/systemd/system/ofono.service.d/lxc-android-config.conf and lib/systemd/system/rild.service
[16:54] <ogra_> thats not 13, is it ?
[16:54] <kenvandine> yes
[16:54] <kenvandine> well, it's not there :)
[16:54] <kenvandine> and it is in 0.221 in the archive
[16:54] <kenvandine> there was two revisions uploaded to the silo 13 ppa
[16:54] <kenvandine> oh... wait
[16:55] <kenvandine> i bet that was added after
[16:55] <ogra_> https://launchpadlibrarian.net/205346168/lxc-android-config_0.221_0.222.diff.gz
[16:55] <ogra_> thats what the package details page in the PPA gives me
[16:55] <kenvandine> yeah, those are new
[16:55] <kenvandine> nevermind
[16:55] <kenvandine> yeah, but 0.221 was also uploaded to that ppa
[16:55] <kenvandine> didn't match what ended up in the overlay ppa
[16:55] <ogra_> not by me i think
[16:56] <kenvandine> rsalveti did the first one
[16:56] <kenvandine> the wpa supplicant fix
[16:57] <ogra_> ok. we only need the last one then
[16:59] <abeato> ogra_, which is the issue with the wily silo?
[17:00] <ogra_> abeato, kenvandine wants to merge all lxc-android-config landings because we have so many clashing landinhs of it
[17:00] <kenvandine> abeato, just for the vivid landing
[17:00] <abeato> ogra_, ok, that is fine for me
[17:01] <kenvandine> only trying to grab the changes needed for ota4
[17:01] <ogra_> you would just have to test his silo then
[17:01] <abeato> kenvandine, what I changed is a script called 03mmsproxy
[17:01] <ogra_> and drop 027
[17:01] <kenvandine> abeato, ok, i'll do that
[17:01] <kenvandine> abeato, i'll ping you to test it ok?
[17:02] <abeato> kenvandine, ok, but I am almost eod so please send me an e-mail
[17:02] <ogra_> trainguards, you can wipe silo 27, it will get merged into silo 35
[17:02] <robru> ogra_: thanks
[17:03] <abeato> kenvandine, in case you need it the new script is in comment #5 of bug #1454625
[17:06] <alan_g> sil2100: what need to be done to have mir-0.13.0 on wily?
[17:09] <pmcgowan> sil2100, added comment to bug #1447756 we should land it
[17:18] <sil2100> pmcgowan: I know, waiting for sign-off
[17:18] <pmcgowan> ok
[17:25] <fginther> dobey, regarding adding coverage for unity-scope-click, what is the right magic for generating coverage? The usual method of adding "-DCMAKE_BUILD_TYPE=coverage" and "make coverage-xml" isn't working
[17:26] <fginther> dobey, for example: http://s-jenkins.ubuntu-ci:8080/job/unity-scope-click-wily-amd64-ci/13/consoleText
[17:32] <dobey> fginther: i think it needs -DENABLE_COVERAGE=yes or something
[17:32] <dobey> kyrofa: ^^ is that how the cmake-extras thing works?
[17:34] <kyrofa> dobey, lower-case: -Denable_coverage=ON
[17:36] <kyrofa> fginther, ^^
[17:36] <kyrofa> fginther, check out the bottom of the HACKING file
[17:37] <dobey> kyrofa: is that specific to the scope, or is that what the cmake-extras module requires?
[17:37] <kyrofa> The `enable_coverage` variable is used within cmake-extras
[17:38] <fginther> kyrofa, thanks for clarifying
[17:42] <kyrofa> fginther, dobey: Note that my answer stands for cmake-extras in vivid, but I just took a look at cmake-extras trunk and it seems different
[17:42] <dobey> yeah i don't see that in wily
[17:43] <kyrofa> fginther, dobey: where they're using the coverage build type
[17:43] <fginther> kyrofa, so "-DCMAKE_BUILD_TYPE=coverage" ?
[17:43] <fginther> (which is what other projects use)
[17:44] <dobey> yeah
[17:44] <dobey> i think the click scope iswrong now
[17:44] <kyrofa> If it's using what I see here: http://bazaar.launchpad.net/~cmake-extras/cmake-extras/trunk/view/head:/EnableCoverageReport.cmake yeah. But dobey is right-- that will bust the scope
[17:45] <kyrofa> dobey, fginther well that sucks. We want to land the same, right?
[17:45] <sil2100> alex-abreu: hey, I'll ACK your landing (silo 26) but please fix in the next release the debian/control, as one of the dependencies has different ident than other entries
[17:45] <dobey> kyrofa: i'm digging deeper :)
[17:45] <fginther> kyrofa, the existing CI tools are setup for using CMAKE_BUILD_TYPE. if the unity-click-scope source is updated to use the same, it should just start working
[17:46] <fginther> kyrofa, dobey, as it's currently setup, the build is generating an empty coverage file using the CMAKE_BUILD_TYPE option
[17:46] <kyrofa> dobey, I'm checking to see if it's been updated on vivid
[17:46] <alex-abreu> sil2100, hey thx
[17:49] <kyrofa> dobey, what version is in wily?
[17:49] <kyrofa> I bet the newer one is in vivid overlay, huh?
[17:49] <dobey> well, vivid now and wily are the same now
[17:49] <dobey> for cmake-extras
[17:50] <kyrofa> dobey, vivid+overlay, or vivid stock?
[17:51] <sil2100> kgunn: hey! Since I don't see alan_g, there is an entry for the wily mir sync but we're lacking silos right now
[17:53] <dobey> kyrofa: overlay. of course
[17:54] <dobey> kyrofa: vivid == (vivid + overlay) for our purposes :)
[17:55]  * kyrofa starts using the overlay before anyone notices
[17:55] <kyrofa> dobey, I'll fix this
[17:57] <dobey> ah, i see. michi fixed that
[17:58] <kyrofa> dobey, in cmake-extras?
[17:58] <dobey> yes
[17:59] <dobey> was seeing where it changed
[18:13] <kgunn> sil2100: ack
[18:25] <mzanetti> sil2100, just FYI: 32 tested
[18:27] <sil2100> \o/
[18:28] <sil2100> Now just sign-off and we can land both
[18:28] <sil2100> I would wait with silo 3 too since in case QA finds something, you could then fix 3, sync to 32 and re-loop
[18:28] <sil2100> But since they already tested 3 I suppose all should be good :)
[18:30] <dobey> fginther: so is the coverage build enabled for lp:unity-scope-click MPs now? so when kyrofa makes an MP to fix this issue in our CMakeLists.txt, we should see an actual coverage report on jenkins when it builds the tests for that branch?
[18:36] <fginther> dobey, yes, it should be good to go. It may need to be tweaked, but it currently matches most other projects that collect coverage
[18:39] <dobey> fginther: ok, i think when kyrofa has a branch to fix the issue, we'll be good then. thanks
[18:39] <pmcgowan> sil2100, davmor2 is there any way to look at the QA trello board and know which landings were to vivid?
[18:42] <sil2100> pmcgowan: I think all of them are for vivid
[18:42] <sil2100> pmcgowan: normally they have that 'Vivid' tag on them
[19:04] <pmcgowan> sil2100, lots are wily, cant tell the diff anymore
[19:05] <pmcgowan> sil2100, maybe I am wrong
[19:05] <pmcgowan> but seems the green tag is "trunk" not really vivid since I see landings to wily not vivid
[19:07] <sil2100> We don't do sign-off for wily as far as I know
[19:07] <sil2100> At least hm, I don't think we agreed on that explicitly
[19:08] <pmcgowan> sil2100, so perhaps its just the auto merge and bug closing we lack, so I cant see whats happening
[19:09] <pmcgowan> sil2100, no these are wily silos it seems, and qa is approving them
[19:14] <sil2100> pmcgowan: well, from the silos currently in the queue and being tested all are for vivid
[19:15] <sil2100> But I need to go now - I'll make sure to check everything tomorrow and give you a sign if QA is doing something unexpected or not
[19:16] <pmcgowan> sil2100, thanks
[19:20] <kyrofa> dobey, https://code.launchpad.net/~kyrofa/unity-scope-click/1457170_update-cmake-extras/+merge/259671
[19:23] <dobey> kyrofa: cool. let's see what jenkins does with it. actually i guess we can get rid of the usage of enable_coverage completely here?
[19:24] <sil2100> o/
[19:27] <kyrofa> dobey, we could, but it would require more work. We don't need it on the call to cmake (i.e. -Denable_coverage), but the enable_coverage variable is used by all the tests so they can link to gcov (without using --coverage)
[19:27] <kyrofa> dobey, To get rid of it entirely we'd have to check the build type in each of those
[19:28] <dobey> kyrofa: but https://code.launchpad.net/~michihenning/cmake-extras/cmake-extras-coverage/+merge/258021 fixes that i think
[19:29] <kyrofa> dobey, Adding --coverage to tests means they will be instrumented as well. Not what we want... right?
[19:30] <kyrofa> dobey, but they DO need to link to gcov
[19:30] <kyrofa> dobey, (which --coverage ALSO does)
[19:30] <dobey> kyrofa: i'm not 100% sure what it means
[19:31] <dobey> kyrofa: i guess having the tests instrumented doesn't matter, because in the tests, all the code should definitely be called, so it should always be 100%, no?
[19:32] <kyrofa> dobey, seems odd to get a coverage report for one's tests...
[19:32] <dobey> kyrofa: well, if you have code in the tests that isn't being run, you know something is very wrong :)
[19:33] <kyrofa> dobey, haha! Although, doesn't unity-scope-click have disabled tests?
[19:34] <kyrofa> dobey, we may want to talk to michi and pete-woods about this
[19:34] <dobey> kyrofa: if so, then it will show us :)
[19:35] <kyrofa> dobey, because I think they do plan on fixing this
[19:36] <kyrofa> dobey, and all three of us hit this at the sprint
[19:36] <dobey> well, that cmake-extras branch is one that michi made, and it landed only last week, so i presume he resolved to do it that way for some reason
[19:37] <dobey> anyway, i think we should just do it that way, and if we decide it should be changed, then fix cmake-extras
[19:38] <kyrofa> dobey, alright, give me a few then
[19:39] <dobey> kyrofa: sure, waiting to see what jenkins does with the branch anyway :)
[19:40] <kyrofa> dobey, does it need to be approved though, before jenkins does anything?
[19:40] <kyrofa> dobey, or does it just pick it up?
[19:40] <dobey> no, it will pick it up
[20:01] <ToyKeeper> FWIW, QA is back online now.
[20:01] <kyrofa> dobey, done: https://code.launchpad.net/~kyrofa/unity-scope-click/1457170_update-cmake-extras/+merge/259671
[20:01] <davmor2> pmcgowan: sorry we were without internet hafl the day
[20:01] <davmor2> pmcgowan: I have no idea let me ask the guys who migh know]
[20:05] <davmor2> pmcgowan: jibel is in a discussion right now and will ping you after
[20:05] <pmcgowan> davmor2, thanks
[20:42] <robru> ok, there's only 2 silos free and 3 people requesting. who wants em badder than anybody else?
[20:42] <robru> charles: awe: ChrisTownsend ^
[20:43] <charles> robru, oh me me :)
[20:43] <charles> pick me, pick me!
[20:45] <ChrisTownsend> robru: What about folks further up the queue like say, bregma?:)
[20:45] <awe> me
[20:45] <robru> charles: you need mp urls not lp: branch shortnames
[20:45] <charles> robru, wups, fixing
[20:45] <awe> how we can we be short silos still?
[20:45] <robru> ChrisTownsend: i can't even
[20:46] <robru> awe: well, RTM died and now everybody who would have wanted an RTM silo now wants an ubuntu silo. so basically we increased the number of silos from 30 to 40, and then doubled the demand for the original 30 silos.
[20:46]  * awe wonders if silo-023 can be cleaned up?  cyphermox ^^
[20:46] <awe> it's not even for a phone landing
[20:46] <bregma> keep in mind the Trusty silo will probably take longer to clear because of the entire SRU process
[20:46] <cyphermox> ah, yes, it can, verification-failed anyway.
[20:46] <cyphermox> robru: ^^
[20:47] <robru> cyphermox: ok thanks
[20:47]  * awe hopes silos open up tomorrow too
[20:47] <robru> seb128: I'm freesing silo 1 because it sat in UNAPPROVED for a month and a half, and we're out of silos.
[20:47] <ChrisTownsend> robru: Right, mine is an SRU, so it'll tie up a silo for a while.
[20:49] <charles> robru, row 79 col F fixed
[20:49] <bfiller> robru: can I have a reconfigure on silo 29 please
[20:49] <robru> bfiller: one sec
[20:49] <robru> awe: what's going on on row 80? what package do you want synced?
[20:49] <awe> network-manager
[20:49] <awe> sorry for not making that clearer
[20:50] <awe> just update comments
[20:50] <robru> awe: I don't understand why you have an MP if you want the package synced. it's one or the other.
[20:51] <awe> we discussed this via email thread... I included the mp, as it's got test results in it
[20:51] <fginther> kalikiana, are the tests for lp:ubuntu-ui-toolkit/staging in better shape now? I see that the build-time tests are generally passing now
[20:52] <awe> I will manually merge; I didn't realize it'd be a problem to include it even though we're doing a copy
[20:52] <robru> charles: ok you got silo 1
[20:52] <charles> robru, thanks
[20:52] <awe> robru, should I remove it?
[20:52] <robru> charles: you're welcome
[20:52] <robru> awe: well if it's in the row there the train will see that and try to build a new package
[20:52] <awe> ok; I'll remove and mention in comments
[20:52] <robru> awe: ok
[20:53] <robru> awe: check 80G
[20:53] <robru> awe: and do you want that in the overlay ppa or is it really a vivid sru?
[20:54] <awe> overlay ppa
[20:55] <awe> did I get the target distro wrong then?
[20:56] <robru> awe: no there's just a separate field for that
[20:56] <robru> ChrisTownsend: ok you got silo 21, but please please please once it's published, lean on the SRU team hard to get it accepted into proposed asap, it's really not acceptable to have a silo languishing in UNAPPROVED for 2 months.
[20:57] <robru> which is apparently the norm for SRUs, not criticising you personally
[20:57] <ChrisTownsend> robru: Trust me, I know.:)
[20:57] <awe> robu, got it; updated
[20:57] <ChrisTownsend> robru: Thanks!
[20:57] <robru> ChrisTownsend: you're welcome
[20:57]  * awe doesn't miss the SRU process
[20:58] <ChrisTownsend> awe: ;-)
[20:58] <robru> awe: ok you got 23
[20:58] <bregma> if the SRU team didn't go around having families things would probably go quicker
[20:58] <robru> bregma: how selfish of them!
[20:59] <bregma> I know, right?
[20:59] <awe> thanks robru!
[20:59] <robru> awe: you're welcome
[20:59] <robru> bregma: you want a silo? or are you too close to EOD to make use of it?
[20:59] <awe> ChrisTownsend, I actually got asked about FISH the other day; hack, cough...
[20:59] <ChrisTownsend> awe: Oh gawd...
[21:00] <bregma> robru, both lines 62 and 76 are waiting for silos, but I could combine them into 1 if there's only 1 silo to give out
[21:00] <robru> bregma: there is in fact only one ;-)
[21:00] <bregma> they're not related, but it wouldn't hurt anything
[21:00] <camako> trainguards, ^^
[21:01] <robru> camako: party's over dude, you missed it.
[21:01] <camako> robru, no more silos?
[21:01] <charles> camako, bregma's clearing one a few lines up in scrollback
[21:01] <bregma> robru, I merged 62 into 76, so 62 can be deleted and 76 given a silo
[21:01] <robru> camako: there's only one free and bregma has dibs. I just freed 3 for 3 other people, I'll see if there's any others I can free
[21:02] <robru> bregma: great thanks
[21:02] <camako> robru, appreciate it :-)
[21:02] <bregma> will you delete line 62?  I don't want to be blamed for breaking the sheet
[21:02] <robru> bregma: yeah i can do it, no worries
[21:03] <bregma> I don;t even like to keep it open in my browser, just in case
[21:04] <robru> bregma: that's probably for the better ;-)
[21:04] <robru> bregma: oh there you go, 26
[21:05] <bregma> woo-hoo!  building....
[21:05]  * bregma is inappropriately excited
[21:06] <robru> barry: !!
[21:06] <robru> curses!
[21:07] <barry> robru: waaaaht?
[21:07] <robru> barry: your silo 11, it just landed, except the merge failed because the train doesn't have write access to ~ubuntu-managed-branches
[21:07] <robru> barry: so I'm gonna need you to merge that manually
[21:07] <barry> robru: i could have sworn that's how we used to do that
[21:08] <robru> barry: dunno, i suppose it's possible somebody removed the bot from the team but I'm not aware of it
[21:08] <barry> slangasek: do you know anything about this ^^
[21:08] <robru> barry: anyway, your branch is safe at lp:~ci-train-bot/ubuntu-system-image/system-image-ubuntu-wily-proposed, please push it to the right place yourself
[21:08] <robru> barry: meanwhile I need to free your silo because there's a crunch on
[21:09] <barry> robru: ok
[21:10] <barry> robru: that's fine.  i'd like to figure this out for next time though
[21:11] <robru> barry: yeah, two possible solutions, either have a branch somewhere else that is owned by a team that ci-train-bot is in, or get ci-train-bot added to ~ubuntu-managed-branches. Either way is equally good for the train, but one of those solutions has political implications of course.
[21:12] <robru> camako: ok you got silo 11
[21:13] <barry> robru: i think that's exactly what ~ubuntu-managed-branches is supposed to be for.  look at the team description on lp!
[21:13] <robru> barry: oh, hrm. I was thinking that was something else.
[21:14] <barry> robru: ~ps-jenkins is a member of that team, so i guess ~ci-train-bot should just be added, but maybe slangasek can weigh in on that
[21:14] <robru> barry: yeah that seems to be the case. we switched from using ~ps-jenkins to ~ci-train-bot back in december. I guess you didn't do a landing this way since before then
[21:15] <barry> robru: correct.  and it looks like s-i is the only code in the team
[21:15] <camako> robru thanks
[21:15] <robru> camako: you're welcome
[21:15] <barry> robru: i don't have perms to add the bot, so i'll email stgraber about it
[21:16] <robru> barry: just pinged him, he says it's done ;-)
[21:21] <barry> robru: \o/
[21:21] <barry> thanks
[21:21] <barry> anyway, manual merge is done
[21:24] <robru> barry: alright, sorry for the hassle
[21:24] <barry> robru: no worries.  glad it was easy to clear up.  landings may happen more quickly going forward
[21:30] <mzanetti> robru, hey, could you please publish silos 3/32. We're a bit in a hurry with another silo that's blocked on that
[21:31] <mzanetti> it's a sync-pair
[21:34] <robru> mzanetti: 32 is waiting on qa and 3 is not even marked as being ready for publishing.
[21:35] <mzanetti> robru, ah... sorry... I misread... thought QA had signed it off already
[21:35] <mzanetti> for 3 I'm sure it actually was QA signed off already
[21:36] <robru> mzanetti: if you think 3 is ready (eg if you tested it and you're satisfied), just mark it ready and I can publish
[21:36] <mzanetti> not sure what happened there
[21:36] <mzanetti> yeah. I tested both
[21:36] <robru> mzanetti: wily doesn't need qa. you just have to test it yourself
[21:36] <mzanetti> yeah. I think that's actually the problem... QA tested 3 and then realized that it's actually wily
[21:36] <mzanetti> so they removed it again
[21:36] <mzanetti> I'll clean up the mess
[21:37] <robru> mzanetti: oh weird, I dunno
[21:37] <robru> mzanetti: just set 39K to yes and 39I to N/a
[21:37] <robru> mzanetti: not sure why it says qa granted but tests not passing, that makes no sense
[22:31] <slangasek> robru, barry: hmm why is stgraber the only admin of ~ubuntu-managed-branches?
[22:31] <barry> slangasek: great question
[22:31] <slangasek> :)
[22:32] <slangasek> robru: did you figure out why the bot wasn't a member of that team?  Was it just because there hasn't been a landing since we switched bot accounts?
[22:32] <robru> slangasek: that is strange
[22:32] <robru> slangasek: yeah I think that's why, I can't see any other reason
[22:32] <barry> slangasek: yep that's why
[22:32] <slangasek> well, since you say that system-image was the only code in there, it may be that he was the admin because he was the system-image maintainer at the time
[22:32] <slangasek> ok
[22:32] <barry> slangasek: you and i at least should be admins
[22:32] <slangasek> so yeah, all a natural consequence of local decisions
[22:32] <slangasek> barry: indeed
[22:33] <barry> slangasek: can you make that happen?
[22:55] <dobey> fginther: so https://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-wily-amd64/8/ seems to have found the covearge.xml, but i don't see how to view the coverage report
[22:55] <slangasek> barry: apparently I can! ;)
[22:57] <barry> slangasek: :)