[01:46] 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 [01:46] Launchpad bug 1390120 in systemd-shim (Ubuntu) "Manually set time and date reverts to Automatically on restart (Ubuntu Phone)" [High,Confirmed] [02:10] bfiller, i just replied to your comment [02:11] bfiller, we're only looking at the change between auto and manual, not about actually changing the time [02:11] kenvandine: what is automatic supposed to do? [02:11] enables NTP [02:11] this systemd-shim does properly fix that, without it NTP isn't supported [02:12] but... it only really fixes it for devices that are read/write [02:12] kenvandine: I'm not seeing the time update when switch to automatic though [02:12] I have read/write [02:12] we need to figure out where the daemon sets the state and add it to the whitelist of writable paths [02:12] well that would be a different bug :) [02:12] i bet NTP doesn't change the clock immediately after enabling it [02:13] which would be a different bug [02:13] so besides that, we have 2 problems [02:13] 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] systemd-shim in wily and vivid doesn't support NTP [02:13] so changing auto/manual does nothing at all [02:14] my patch fixes that, so it does change the state [02:14] but we aren't letting the state persist [02:14] we need a fix in lxc-android-config for it to persist [02:14] but i haven't been able to figure out what path to add [02:15] kenvandine: ok [02:15] kenvandine: seems less critical than my clock now being stuck at Weds May 20th and not being able to chagne back :) [02:15] haha [02:16] seriously I'm stuck [02:16] it's bad [02:16] i tried pinging a couple people today to ask about the path... but couldn't figure it out [02:16] wow [02:16] that's bad [02:17] 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] weird [02:17] I'll file a bug [02:17] yeah [02:17] that's bad === salem_ is now known as _salem [06:36] robru: regarding your comment for ci sheet line 66: have you expected just a two line diff? [06:39] thostr_: well i was told it was a simple fix and then the diff came out 2mbs, so something's wrong there [06:44] robru: 2mbs? [06:45] thostr_: https://ci-train.ubuntu.com/job/ubuntu-landing-038-1-build/ it's right there. What are you looking at? [07:02] robru: I was just looking add the MP [07:02] Wellark: ^ why does the diff show all src files it seems including doc? [07:03] thostr_: for which one? [07:03] Wellark: https://ci-train.ubuntu.com/job/ubuntu-landing-038-1-build/ [07:03] 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] robru: yes, we restructured stuff in between, so this explains [07:04] robru: yep [07:04] I will double check the diff [07:06] robru: so yes. there was a langing [07:06] where packages where built and released against vivid+overlay [07:06] but source merged to 15.10 trunk [07:07] Wellark: k. Just need you to smoke test the silo then Mirv can publish it to wily for you. [07:07] so now, the wily diff (when looking deltas between packages) looks huge [07:08] the repo diff is not huge [07:08] except for the .po update [07:08] which generates a lot of noise [07:08] Mirv: --^ [07:09] 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] robru: ok. everything OK. ;;; ship it ;;; [07:12] :) [07:13] the vivid overlay should look sane [07:13] that was just wily missing a round of packages [07:13] Mirv knows the details [07:15] robru: may I already have the vivid silo while waiting for Mirv? :) [07:17] oh, seems the spreasheet fixed it self [07:21] Wellark: one sec [07:24] Wellark: ok, silo 19 for vivid [07:24] robru: <3 [07:24] Wellark: Mirv should be around soon if you need anything else, I'm out since it's half past midnight here ;-) [07:34] robru: I could hug you [07:34] but I don't know your IP [07:34] <3 [07:36] Wellark: lol, you're welcome [07:42] I've been around for 3h now :) [07:42] sorry, just super focused on Qt syncing [07:43] Mirv: I know you like to play around with your hobbies, but we have actually important stuff here to land [07:43] :D [07:43] Mirv: :P [07:44] I see it was published in the end, so now only vivid overlay to go [07:50] Phew... === oSoMoN_ is now known as oSoMoN === sil2100 changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: otto is broken for a while now and in process of being removed; Whole QA team in the US timezone this week; Low on silos [08:20] 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 [08:20] bug 1456886 in ubuntu-system-settings-online-accounts (Ubuntu) "u-s-s-o-a fails autopkgtest in proposed" [High,New] https://launchpad.net/bugs/1456886 [09:02] 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] pedronis: hey! I know this can be a bit confusing ;) [09:10] So, generally: [09:11] 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] Both have the same rootfs but different custom tarballs [09:12] If your fix is device independent, it shouldn't matter [09:12] 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] thanks, bit confused because I don't see ubuntu-touch/rc-proposed/ubuntu in udf query [09:13] anyway I can use the other one as you said [09:13] huh [09:13] Maybe slangasek didn't set it up yet? I'll check with him later [09:13] ubuntu-device-flash query --device=mako --list-channels [09:13] Use the ubuntu-touch/rc-proposed/bq-aquaris.en in this case [09:13] yep, thanks [09:52] Mirv: whoops [09:53] I accidentally pushed lp:~unity-api-team/indicator-network/lp1456307_15.04 to trunk.. [09:53] Wellark: sounds like your merge skills need some finetuning [09:54] I accidentally the whole trunk [09:54] how do I revert this without breaking silo landing [09:54] ? [09:54] Wellark: bzr uncommit, bzr uncommit, bzr revert, bzr push --ovewrite (..while triplechecking you're not breaking anything _more_) [09:55] Wellark: plus have a copy of current status etc in another dir [09:55] Mirv: LP already considers the MP merged [09:55] if I force push... [09:56] well I guess you could manually mark the MP as not merged [09:57] Mirv: where do I need the revert? [09:57] I've uncommitted the revisions in the MP now [09:57] so push --override to the trunk should do the trick, right? [09:57] 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] bzr revert is just optional that gives you easier possibility to review how the branch looks without those newer commits [09:59] Mirv: ok. let's try [09:59] Mirv: https://imgflip.com/i/lqxxm [09:59] :D [10:01] ok. fingers crossed [10:02] Mirv: ok. the build started [10:13] looking good [10:33] hey there trainguards, can i get a binary copy of oxide for a silo request on line 71? thanks [10:47] dbarth_: sure thing === oSoMoN__ is now known as oSoMoN [11:59] * sil2100 off to prepare some lunch === _salem is now known as salem_ === dbarth_ is now known as dbarth [12:26] hmm, why has ppa-purge stopped working for me [12:36] I guess because it hasn't, actually [12:37] Mirv: line 67 ready to land [12:38] but we need a QA Grand for it [12:38] Mirv: the diff looks huge [12:38] but that's the .po update [12:38] https://ci-train.ubuntu.com/job/ubuntu-landing-019-1-build/lastSuccessfulBuild/artifact/indicator-network_content.diff [12:47] Wellark: published [12:49] 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] Mirv: <3 [12:51] Mirv: sil2100: changes like a dozen of bugfixes... including a super critical one... namingly the version separation [12:51] Mirv, sil2100: any idea why the (Ubuntu RTM) bug did not get marked as Fix Released? [12:51] https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1456307 [12:51] Launchpad bug 1456307 in indicator-network (Ubuntu RTM) "pkg-config file name for connectivity-qt has changed" [Critical,In progress] [12:52] or are the updates run in delayed manner? [12:52] 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] not sure of the plans, it'd be annoying to close every bug by hand [12:54] 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] sil2100: was it you? :) [12:55] 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] Wellark: oh, that'd be good news! :) [12:56] Mirv: we handed over a launchpadlib script that you folks could run for this purpose. [12:56] bzoltan: fear driven development is more interesting! https://imgflip.com/i/lqxxm [12:57] Wellark: LOL :) nice one [12:58] Wellark: not setup yet ;) It'll be released soon! [12:58] * sil2100 still didn't finish settin that up [13:02] sil2100: oh, ok :) [13:02] will close the bug manually then [13:15] jibel: Hi - ogra_ suggested I ping you about testing the fix for bug 1447756 (ci train spreadsheet row 61). [13:15] bug 1447756 in Canonical System Image "segfault in log.c code causes phone reboot loops" [Critical,In progress] https://launchpad.net/bugs/1447756 [13:16] jibel, testing that will be rather problematic for QA ... since you need an affected device [13:17] 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] ogra_ I gave phone back to Andy, so hard one to test [13:18] ev: ok, thanks [13:19] 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] ogra_ I can test on some devices in the office tomorrow [13:20] ondra, good, you need to make that out with QA (jibel) though ... they are the ones sayinf yay or nay :) [13:21] ogra_ OK [13:22] sil2100, now that spreadsheet is (kind of ;) working again maybe you can remove line 22 [13:22] abeato: hah, sure ;) [13:22] sil2100, thanks [13:23] ondra: ogra_: jibel: pat has specified on the bug that "We ... need the fix to land by May 21". [13:24] jodh, pat has no power if QA doesnt let it in :) [13:25] they are the ones you need to convince :) [13:25] ogra_: understood, but do we know why the 21st is the key date here? [13:25] next OTA landing lockdown i guess [13:28] 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] 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] dbarth: did QA verify it as well? [13:39] sil2100: not yet [13:39] sil2100: apparently, it's safer / quicker to go with the silo [13:39] sil2100: as the security update may be delayed (for other releases as well) to tomorrow [13:40] sil2100: this way we can secure the vivid release for the image [13:40] dbarth: I would go with the silo as well, since our silo has a higher pin priority basically === vrruiz is now known as rvr [13:55] trainguards, could I get a silo for line 71 ? [13:56] abeato: on it [13:57] abeato: uh, sadly, still all ouot of silos [13:57] sil2100, ok [14:21] sil2100: yes the last round of channel renames hasn't been done yet [14:21] sil2100: I was waiting for fallout from the last round, apparently there's been none :) [14:22] slangasek: all seems to be fine so far ;) [14:22] I updated the developer channel page today even [14:23] slangasek: could you create the /ubuntu channels then? [14:23] 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] 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] ACK, thanks :) [14:31] jibel, davmor2: hey! Could you also prioritize the sign-off of silo 21? [14:31] jibel, davmor2: it has a fix for the bootloop issues [14:32] sil2100: no [14:32] :D [14:32] :| [14:32] ;) [14:41] 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] 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] https://code.launchpad.net/~canonical-platform-qa/ubuntu-ui-toolkit/upstart/+merge/259262 [14:44] seb128, ^^ that's the fix that will unclog the plumbing for wily :) [14:44] kenvandine: with the next landing yes [14:45] pedronis: ok [14:45] bzoltan, eta? [14:45] 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] it's just a missing depends... i miss the days of just using dput for simple packaging fixes :/ [14:47] kenvandine, great [14:48] sort of... we'll have to wait nearly another week for the depends fix :/ [14:48] Mirv had said they flushed the queue, but the excuses page still shows it's blocked [14:49] 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] barry: let me see what's in 11 [14:49] seb128, and the fix was proposed last week... anyway i'll stop complaining [14:50] trainguards: is the spreadsheet messed up again? [14:50] dobey: it seems unresponsive [14:51] dobey: it looks fine here so far, but maybe it started being broken again [14:51] Let me check if I get an error notice in 5 minutes [14:51] barry: so, we would need to merge silo 11 first I think [14:51] sil2100: i think row 50 is landed, but the status column doesn't show it as "Landed" with the green background [14:51] barry: ah! Or maybe not, as you said you want to replace it completely [14:52] sil2100: that version got stuck in promotion and it won't clear without the fixes i want to upload next [14:52] sil2100: yep [14:52] barry: ok, feel free to free it up then and re-do it from scratch [14:52] sil2100: +1 thanks [14:52] dobey: well, that's a known bug [14:53] oh [14:53] dobey: the spreadsheet is too slow to notice releases to the overlay PPA and sometimes doesn't notice a silo landing [14:53] I'll fix it up in a moment [14:53] sil2100: sanity check: click Clean, enable ONLY_FREE_SILO and nothing else. right? [14:53] Not much we can do about that long term [14:53] barry: yep :) [14:53] sil2100: thanks! [14:53] sil2100: ah ok [14:54] charles, thostr_: ^^ see what sil2100 said about status in spreadsheet of things landing in vivid overlay re: i-power landing [14:55] dobey: this will take a moment as I need to fill some additional info as well [14:55] * sil2100 sighs [14:55] The spreadsheet needs to die [14:56] sil2100: i think it already has several times :) [14:56] maybe it's like a cat [14:58] sil2100: no worries. spreadsheet does need to die [15:02] mzanetti: ping [15:02] mzanetti: you saw that unity8 in silo 32 failed to build? [15:03] mzanetti: I think you're missing a dependency... connectivity-qt1 is not found by cmake [15:03] sil2100, no... the dependency had a bug in the pkgconfig module [15:03] sil2100, should be fixed now. will trigger a rebuild [15:04] ACK === oSoMoN__ is now known as oSoMoN [15:07] trainguards: can I have a silo for line 75, please? [15:07] oSoMoN: hey! We're out of silos right now... [15:07] mzanetti: does silo 3 have the fix in it? [15:09] sil2100, the problem is in connectivity-qt, not in unity [15:09] s/is/was/, apparently [15:10] Ok, so it's safe to publish silo 3 then? [15:10] hm, maybe I'll wait for the 32 to finish building [15:13] sil2100, is there a waiting list for landing requests without a silo? [15:13] The spreadsheet is the waiting list ;) [15:14] There's a few of those already [15:14] Silos shouldn't be limited [15:28] 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] Sure [15:33] Let's maybe change silo 3 back to not ready for ladning then [15:34] Just so that we land both at the same time === salem_ is now known as _salem [15:41] sil2100, dbarth_ says silo15 can be recycled for line 75 [15:45] oSoMoN_: ok, will we land silo 15 later? [15:46] sil2100, the MR in it is not entirely ready to land yet, so we will request another silo at a later time [15:46] oSoMoN_: ACK [16:02] sil2100, ok. finished building [16:02] mzanetti: could you test if everything works on vivid? Then we can hand it over to QA for sign-off [16:02] sil2100, ack === chihchun is now known as chihchun_afk === _salem is now known as salem_ [16:12] sil2100: can I have a silo for line 64 please? [16:18] bfiller: sadly still no free silos ;/ [16:18] We might need to scan for any ones that we can free up [16:19] sil2100: ok [16:20] kgunn_: hey! When would silo 004 be ready for landing? [16:22] sil2100: so that's full shell rotation, we'd ideally want to land that post RC image [16:22] we did discuss potentially landing in wily asap, then sync'ing later to vivid+ [16:23] The silo is configured for wily right now so it potentially could [16:23] it's ultimately mzanetti's decision [16:23] * mzanetti reading [16:23] ogra_: hey! You guys have silo 27 but didn't build it yet [16:23] sil2100: is there a problem with that silo hovering around ? [16:23] ogra_: will that be used? [16:24] kgunn_: well, normally not, we're just low on silos so I'm asking around ;) [16:24] sil2100, not sure what that is, i only know about 16 for lxc-android-config [16:24] ogra_: it's also lxc-android-config [16:24] yes, i see that [16:24] Bug #1454625 - Cannot send MMS for combined contexts when wifi is connected (spreadsheet row 61). [16:24] bug 1454625 in network-manager (Ubuntu) "Cannot send MMS messages with combined contexts with WiFi connected" [High,In progress] https://launchpad.net/bugs/1454625 [16:25] Maybe it's abeato's landing [16:25] same bug === oSoMoN_ is now known as oSoMoN [16:25] likely the wily sync [16:25] building now [16:25] Might be [16:27] sil2100, I think I'll land silo 4 to wily asap when 3 and 32 are out of the way [16:28] Ah, right, hm, we'll have to land 3 first probably as it has a sync [16:28] Right [16:29] yep [16:32] ogra_, sil2100: i have lxc-android-config in silo 25 now waiting for qa verification [16:32] silo 35 rather [16:33] ogra_, oh... and the same version is in silo 16 [16:33] i really wish that used bzr branches... [16:34] ogra_, also for ota4... should we maybe combine those in one silo? [16:35] kenvandine, 013 too [16:36] silo 13 won't be landing for ota4 [16:36] oh ? [16:36] i was just thinking combining the silos we need for ota4 [16:36] then tethering will regress [16:36] no, it's not really ready... [16:36] sil2100, ogra_ yes that's the sync [16:36] regress? [16:37] yes [16:37] we never landed hotspot :) [16:37] tethering [16:37] not hotspot :) [16:37] oh that also has a fix for that? [16:37] wired ... [16:37] yes, the lxc-android-config package has it [16:37] i thought it was just the fix we needed for hotspot to work [16:37] we combined both [16:37] ah [16:38] probably should rip that apart again [16:38] i wasnt aware hotspot would land [16:38] *would not [16:38] since we don't have handy bzr branches to handle lxc-android-config o [16:38] i'd be in favor of combining all of the ones we need for ota4 [16:38] feel free to switch it :) [16:39] long term i need to hand it to someone anyway with my new duties ... [16:39] want to adopt it ? :) [16:40] NO [16:40] :) [16:40] LOL [16:40] i spent a bunch of time trying to figure out who to ask about it :) [16:40] you wouldnt have to anymore in that case :) [16:40] haha [16:40] that's ok... [16:41] (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] so we'd have to manually merge all these together... a mess [16:41] i think all changes are in different files [16:42] maybe not to bad [16:43] ogra_, so i assume you aren't volunteering to do it? [16:43] :-D [16:44] not 15min before EOD ... my GF would kill me if i did ... i can offer tomorrow morning though [16:44] i'll do it :) [16:44] shouldnt be to hard i think [16:44] changelog merging will be the most work i guess [16:44] i'll pull the changes from 13 and 16 and put them with mine in 35 [16:45] let me check 13 again in detail [16:45] yeah, it only has the tethering fix there [16:45] https://launchpadlibrarian.net/205346168/lxc-android-config_0.221_0.222.diff.gz [16:46] trivial one liner [16:46] ev: were you testing by having jenkins do a rebuild on an existing MP? [16:46] 16 is a bit more but in a different file ... [16:47] ogra_, oh, silo 16 is a wily landing [16:47] 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] abeato, awe, can you do your testing of silo 27 (vivid MMS fix) with kenvandine's silo 35 instead ? [16:47] kenvandine, it would have been a sync [16:47] kenvandine, vivid definitely needs the fix [16:50] ogra_, I have to defer to abeato on this one... [16:50] 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] alex-abreu: you need to rebuild the silo and re-test [16:50] robru, oh sorry, I'll rebuilt & retest [16:51] alex-abreu: thanks [16:53] ogra_, what's in silo 13 also removes two files that aren't mentioned in the changelog [16:54] lib/systemd/system/ofono.service.d/lxc-android-config.conf and lib/systemd/system/rild.service [16:54] thats not 13, is it ? [16:54] yes [16:54] well, it's not there :) [16:54] and it is in 0.221 in the archive [16:54] there was two revisions uploaded to the silo 13 ppa [16:54] oh... wait [16:55] i bet that was added after [16:55] https://launchpadlibrarian.net/205346168/lxc-android-config_0.221_0.222.diff.gz [16:55] thats what the package details page in the PPA gives me [16:55] yeah, those are new [16:55] nevermind [16:55] yeah, but 0.221 was also uploaded to that ppa [16:55] didn't match what ended up in the overlay ppa [16:55] not by me i think [16:56] rsalveti did the first one [16:56] the wpa supplicant fix [16:57] ok. we only need the last one then [16:59] ogra_, which is the issue with the wily silo? [17:00] abeato, kenvandine wants to merge all lxc-android-config landings because we have so many clashing landinhs of it [17:00] abeato, just for the vivid landing [17:00] ogra_, ok, that is fine for me [17:01] only trying to grab the changes needed for ota4 [17:01] you would just have to test his silo then [17:01] kenvandine, what I changed is a script called 03mmsproxy [17:01] and drop 027 [17:01] abeato, ok, i'll do that [17:01] abeato, i'll ping you to test it ok? [17:02] kenvandine, ok, but I am almost eod so please send me an e-mail [17:02] trainguards, you can wipe silo 27, it will get merged into silo 35 [17:02] ogra_: thanks [17:03] kenvandine, in case you need it the new script is in comment #5 of bug #1454625 [17:03] bug 1454625 in network-manager (Ubuntu) "Cannot send MMS messages with combined contexts with WiFi connected" [High,In progress] https://launchpad.net/bugs/1454625 === chihchun_afk is now known as chihchun [17:06] sil2100: what need to be done to have mir-0.13.0 on wily? [17:09] sil2100, added comment to bug #1447756 we should land it [17:09] bug 1447756 in Canonical System Image "segfault in log.c code causes phone reboot loops" [Critical,In progress] https://launchpad.net/bugs/1447756 [17:18] pmcgowan: I know, waiting for sign-off [17:18] ok [17:25] 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] dobey, for example: http://s-jenkins.ubuntu-ci:8080/job/unity-scope-click-wily-amd64-ci/13/consoleText [17:32] fginther: i think it needs -DENABLE_COVERAGE=yes or something [17:32] kyrofa: ^^ is that how the cmake-extras thing works? [17:34] dobey, lower-case: -Denable_coverage=ON [17:36] fginther, ^^ [17:36] fginther, check out the bottom of the HACKING file [17:37] kyrofa: is that specific to the scope, or is that what the cmake-extras module requires? [17:37] The `enable_coverage` variable is used within cmake-extras === chihchun is now known as chihchun_afk [17:38] kyrofa, thanks for clarifying [17:42]