[02:03] === trainguards: IMAGE 27 building (started: 20141120 02:05) === === chihchun is now known as chihchun_afk [03:28] === trainguards: IMAGE 27 DONE (finished: 20141120 03:30) === [03:28] === changelog: http://people.canonical.com/~ogra/touch-image-stats/27.changes === === chihchun_afk is now known as chihchun [05:25] morning [06:44] barry: hi! you've had vivid silo 004 in use for three weeks, is it abandoned and can it be freed? [06:46] lool: same ^ for your vivid silo 020, assigned 3 weeks ago, no actions for 2 weeks [06:46] I'm just checking the statuses as we are out of silos [06:47] bregma: could you consider testing the indicator-session trusty silo 023, or abandoning it? [06:52] bzoltan: you've had qtcreator-plugin-ubuntu in vivid silo 021 for two weeks, but it looks it should be abandoned? [06:53] Mirv: let me check... [06:54] Mirv: yes, that MR got merged together with the latest landing. Sorry. [06:54] bzoltan: ok, freeing up [06:59] AlbertA: I think you will need to rebase mir and rebuild - it seems bdmurray has pushed a no change rebuild to archives so the changelog in your branch is out-of-date and CI Train would complain: https://lists.canonical.com/archives/vivid-changes/2014-November/001800.html [08:01] good morning [08:01] justinmcp_: hi, i'm here [08:08] yay, sanity tests for 166 were really good \o/ [08:16] sil2100, yeah, but we have one toopblocker left [08:16] (see ricardos mail) [08:17] and the browser cache bug is also not so nice [08:41] ogra_: yeah... I actually asked oSoMoN a few days ago if the oxide fix is enough [08:43] sil2100, ogra_: talking about rsalveti’s comments on the bug? I’m looking into it [08:48] oSoMoN, which one now ? :) [08:49] bug 1391230 or bug 1394380 [08:49] bug 1391230 in pulseaudio (Ubuntu RTM) "[TOPBLOCKER] web audio, pulse runs at 6% and screen will not blank on idle" [Critical,Confirmed] https://launchpad.net/bugs/1391230 [08:49] bug 1394380 in lxc-android-config (Ubuntu RTM) "QML cache not regenerated correctly on image update" [Critical,Confirmed] https://launchpad.net/bugs/1394380 [08:52] I was talking about the first one [08:54] ogra_: how much does it take to re-generate the QML cache btw.? [08:54] sil2100, one start of the spp [08:54] *app [08:55] the cache is per app ... created on first start if it doesnt exist [08:55] re- the QML cache, I don’t understand how that could possibly affect the oxide upgrade, oxide is pure C++, there’s no QML to compile and cache… [08:55] Right, but it's not a time-consuming operation anyway I suppose [08:55] it speeds up the startup once it is in place, so the drawback of wiping it means the apps start a bit slower the first time after an updated [08:56] oSoMoN, the webbrowser is QML ... and a small piece of the container too [08:57] (and i'm not sure it is just QML in that cache ... ricmm ??) [08:57] ogra_, sure, but the issue reported by Bill about UA strings doesn’t make sense to me [08:57] well, i have seen it myself [08:57] ogra_: then I would personally give a +1 on your workaround until a proper solution is prepared, but anyway poke Pat and olli first [08:57] sadly i bluntly deleted all dirs that had any trace of browser or webapps in them on my phone [08:58] bill seems to have seen that and done it dir by dir [08:58] ogra_, sil2100, what's up [08:59] sil2100, i dont think it is a reason to re-spin ... so we can discuss it in the bug meeting [08:59] read backscroll, don't think I have all context [08:59] https://launchpad.net/bugs/1394380 [08:59] Launchpad bug 1394380 in lxc-android-config (Ubuntu RTM) "QML cache not regenerated correctly on image update" [Critical,Confirmed] [08:59] ogra_: that's for sure, I think this milestone should stay closed, but maybe next weeks [08:59] olli: so there's this bug that we noticed ^ [09:00] olli, after OTA some webapps and the browser behave weird (like serving the desktop variant of pages etc) ... until you wipe the QML cache for them [09:00] olli: ogra_ prepared a quick-fix that simply clears out the QML cache on every update [09:00] right, i think we should have a solution for the final image ... [09:00] olli: we don't think it's needed for this milestone, but we might consider adding this (or something better) for the next milestone [09:01] but rsalveti disagrees in the bug, i'd like his input first [09:01] right, there might be something better (though i would prefer the safe solution and just wipe everything to prevent future surprises) [09:02] ogra_, sil2100, let's try again, I am on ethernet now [09:02] * olli_ throws unfriendly words at the BF wifi [09:03] Let me copy-paste [09:03] you can pm that too [09:03] done [09:03] bah, to the wrong olli [09:03] hah ;) [09:04] better now :) [09:06] ok [09:06] so.. that bug seems to be triggered in updates only [09:07] yes [09:07] is there a way the upstart change can be applied via OTA [09:07] in a pre-hook or so [09:07] you mean before an OTA ? [09:07] no [09:07] it has to come in with a system upgrade [09:07] sure [09:07] will that be sufficient though [09:08] or does it have to be in GM [09:08] yes [09:08] oh, well [09:08] if we i.e. upgrade oxide or webapps after the GM it needs to be in place to prevent it [09:09] (and we dont know how/if it affects other apps, webapps are the only ones exposing something really visible) [09:11] ogra_, can't the update wipe the cache (once) while being installed? [09:12] well, the thing runs on every first boot after upgrade ... so yes, it runs when it is shipped [09:12] why would you want to do that only once ? [09:12] that defeats the whole purpose [09:13] you want this on every system-image upgrade [09:13] (which this upstart job will do) [09:13] "start on boot-hooks WHEN=new-version" [09:14] (new version points to the system-image, it will only run after an OTA happened) [09:21] psivaa, we seem to be missin results for one device in the krillin rtm smoketests [09:21] ogra_: yes, one device failed to provision with wifi, i've kicked the missed tests off [09:21] thx [09:28] jibel: in the meantime, are you continuuing the regression tests on #166? [09:28] sil2100, we do [09:28] jibel: excellent :) [09:28] Give us a sign if any serious issues emerge [09:33] popey: meeting! [09:34] sorry, network connection went funny === vrruiz_ is now known as rvr [09:45] robru: I'm assuming somebody dealt with that ubuntu-keyboard core-dev ack, since that URL is 404 now [09:48] cjwatson: yes, it was an universe package [09:50] psivaa: if you could give us a poke when the test results are all in it would be awesome [09:50] :) [09:51] sil2100: ack will do. they are roughly 1 hour and 30 mins away, but i'll ping to let you know [09:53] sil2100, the QA regression tests will take the whole day anyway ... no need to hurry :) [09:54] ogra_: ;) [10:26] sigh [10:26] i just had my session restart [10:39] sil2100: ogra_ the testing with 166 is complete, but hasn't synced to the dashboard yet [10:40] ok [10:43] can I get a silo for line 54? [10:44] ah, it moved :-P [10:54] ogra_: sil2100: one new failures that i can see is this in dialer: http://rtm-dashboard.ci.ubuntu.com/smokeng/utopic/touch_stable/krillin/166:20141119:20141119-db417fa/184/dialer_app/ [10:55] thanks ! [10:56] i guess we should let bfiller know [10:56] i looks like the app went away (dbus cnt find it anymore) but i see no .crash or anything [10:56] (unlike the constant camera-app crash we have on krillin) [11:01] psivaa: thanks! [11:11] np, there is no kernel logs for a minute from 20:31:04, roughly when this happened. not sure if there is any relevance [11:12] is there anything like zzzZZZZZZ in it perhaps [11:12] :D [11:13] :) [11:49] joke of the day:"I'll have a quick oxide-qt build" [11:50] Mirv: :D [11:52] lol [11:59] ogra_, sil2100, what's the plan now [11:59] I am trying to round up the team here for a quick call [11:59] we wait til QA finished the regression tests and publish [11:59] future plans need to be discussed then imho [11:59] publish with the topblocker still open [11:59] ? [12:00] sure [12:00] olli: we need to assess how much the leftover oxide issue is still top-priority [12:00] it is being actively worked on [12:00] olli: if it's not [12:00] so we can expect it to be fixed by next week i think [12:00] http://people.canonical.com/~jhm/barajas/master/device_krillin-20141119-f75a559.tar.xz [12:00] http://people.canonical.com/~jhm/barajas/master/device_krillin-20141119-f75a559.changes [12:00] it is also not a regression over our last promoted image [12:00] http://people.canonical.com/~jhm/barajas/master/device_krillin-testresults-20141119-f75a559.ods [12:00] olli: ...premature enter, but yeah: we can tackle it for next week's milestone I suppose [12:00] sil2100, ogra_ jibel ^ vivid krillin device tarball [12:01] olli: as rebuilding oxide can take ages [12:01] does that need QA signoff? [12:01] john-mcaleely, just go ahead [12:01] sil2100, so you are saying it's not feasible to fix it in this weeks build [12:01] john-mcaleely: hey! Not really ;) But if you want you can ask QA to help out [12:01] and then spot test [12:01] olli, we dont have a fix yet [12:01] sil2100, It's got a test pass from me. I'm happy to push it [12:01] you're short handed at the moment [12:02] olli, if we had we might be able to consider it ... but even then ... it isnt a regression, we had it in many former images and we are confident to get a fix before final [12:02] ogra_, to be clear - it's ok to push now (build machine wise) [12:02] olli: yeah... since if we have a fix and it requires an oxide rebuild (which is probable from what oSoMoN mentioned), then it would really push things behind [12:02] john-mcaleely: then you have a green light :) [12:02] john-mcaleely, sure [12:03] ogra_, sil2100 jibel done. new vivid tarball in the next build [12:03] (32?) [12:03] might be :) [12:03] * ogra_ didnt look at vivid for a while [12:04] sil2100, olli: it requires an oxide rebuild indeed, chrisccoulson is taking care of it as we speak. I’d like to mitigate to impact of the issue though: as pointed out by rsalveti in the bug, the issue is there only the first time after boot, subsequent uses of the browser won’t exhibit it [12:04] ogra_, sil2100, are you guys available for a quick HO right now [12:04] gimme 5 min [12:04] oSoMoN, ^ [12:04] k [12:05] olli, so maybe it doesn’t deserve to be an urgent topblocker anymore? [12:06] (I’m available for a quick HO if you need me) [12:06] john-mcaleely: thanks :) [12:06] oSoMoN: fact [12:07] oSoMoN, in my view it will still make an impact 100% of the time so we really need the fix but we can discuss [12:08] pmcgowan, indeed, it will always be an issue the first time the browser is launched after rebooting, I’m not denying that this needs to be fixed quickly (in fact the fix is ready), just saying that maybe we don’t want to delay the image validation and promotion any longer [12:08] pmcgowan: I just think we shouldn't delay this week's milestone but maybe include it in the one next week [12:09] pmcgowan, no doubt that we need it [12:09] pmcgowan, but there is no way it can make this milestone [12:09] well lets discuss, the curent image will not make gm [12:09] obviously not, but we''ll promote it [12:10] ogra_, there is no point [12:10] this isnt a regression [12:10] last milestone had this prob, and many before [12:10] so for the good of oour users we'll definitely promote it to get testin for the rest of the image [12:10] ogra_, this is applying the LT criteria [12:10] yes [12:11] I think we wanted to include the product team criteria as well for a promotion [12:11] only talking about this atm [12:11] ogra_, , sil2100, oSoMoN pmcgowan, victorp https://plus.google.com/hangouts/_/canonical.com/olli [12:11] *we* will promote it, *you* definitely should wait til there is a fix on the horizon [12:26] olli, reading that bu again from top to bottom i actually think having media-hub/pulse never go to sleep (which this bug causes) is as bad as keeping the display on, so we should try to get some fix from rsalveti as well if that is possible in time [12:26] *bug [12:26] else your phone will never sleep if there is a webapp backgrounded [12:30] olli, pmcgowan as per the discussion i turned bug 1394380 into a topblocker [12:30] bug 1394380 in lxc-android-config (Ubuntu RTM) "[TOPBLOCKER] QML cache not regenerated correctly on image update" [Critical,Confirmed] https://launchpad.net/bugs/1394380 [12:30] thx ogra_ [12:33] olli, ogra_: I'll put it on the list for the next milestone then [12:33] yep [12:33] what is the next milestone? [12:33] wave2, next week === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [13:03] olli, pmcgowan, sil2100: oxide 1.3.5 building at https://launchpad.net/~phablet-team/+archive/ubuntu/ppa/+sourcepub/4579784/+listing-archive-extra [13:11] sil2100, ^^ [13:11] o/ [13:13] ogra_: no free silos for vivid right now... [13:15] sil2100, thats fine ... vivid can land later [13:16] (they are diverted enough that i needed to create two different uploads anyway) [13:23] argh, i think i clicked "build" to fast ... the PPA didnt produce binaries yet [13:38] * ogra_ tries that again ... but now with binaries in place :P [13:51] ogra_: olli: right, it'll never to go deep sleep because, because pulse will stay up [13:51] right [13:51] I'm checking that now, should hopefully have a fix for next week iteration [13:54] rsalveti: o/ [14:14] ogra_: and regarding the qml cache thing, let's land your change if that indeed only runs after every flash/update [14:14] rsalveti, right [14:14] safety net :) [14:14] yeah [14:14] (it is already in silo2) [14:15] great [14:37] trainguards, can you republish vivid/25, marcustomlinson fixed the top approval. [14:37] tedg: ACK [14:37] sil2100: I need to sync a package from rtm to vivid, please see line 56, not sure I got the format right [14:37] bfiller: sure thing, let me take a look [14:38] sil2100: also, is there a script that can be run that compares rtm versions to vivid? I'm worried that some fixes may have only landed in rtm and not in ubuntu vivid (like qtorganizer5-eds) [14:39] bfiller, given you only care about stuff on the touch image, you could worst case pull both manifest files from cdimage.ubuntu.com and diff them ... [14:39] bfiller: ok, the format looks right, let me assign the silo - as for the second question, one time I prepared a list of approximate missing landings from both sides (rtm->vivid and vivid->rtm), but it's probably outdated now [14:40] It's actually generated from a diff between the manifests [14:40] I can regenerate that list later today and put somewhere [14:40] sil2100: that's great, thanks [14:41] bfiller: so, I see you already have a silo with qtorganizer5-eds for vivid (silo 15) [14:41] bfiller: it seems to be a normal merge-based silo - you want to have this sync assigned first though? [14:41] sil2100: yes, we can ignore that for now. having problems with that [14:41] ACK [14:42] bfiller: silo 11 assigned, it should sync the package from rtm when 'build' is pressed [14:43] tedg: I approved the packaging changes now and publishing [14:44] sil2100, Great, thanks! [14:44] marcustomlinson, ^ [14:44] sil2100: thanks :) [14:44] yw :) [14:45] sil2100: great [14:45] thanks [14:47] sil2100: I'm taking care of vivid silo 003 myself [14:47] cyphermox: ok, will try to keep my hands out of it :) [14:48] ;) [14:48] ugh, more snow :( [14:49] * sil2100 wants snow [14:50] I'm in a strange christmas-ish mood right now (which is strange, considering it's Nov still) - but I'm missing snow outside of my windows [14:52] * ogra_ is happy he doesnt have to turn th heating on yet ... [14:52] or to shovel snow [14:53] hah, yeah, the few downsides of having a house :) [14:53] As an apartment user I don't have much more work when snow is around [14:53] yeah [14:53] * cwayne1 is getting prepared for first snow as a homeowner [14:54] Just when wanting to use the car [14:54] Damn, 30 silos for ubuntu and all are occupied :o [14:55] you need to stock up ... to 60 :) [14:56] sil2100: it's not that I don't like snow, but it's cold in my office and I wasn't mentally prepared for the snow [15:33] cwayne1, which project should I use to report bugs for Grooveshark scope ? [15:34] om26er: ubuntu-rest-scopes === chihchun is now known as chihchun_afk [16:08] alan_g, I have some more info on the mir test failures you mentioned yesterday. The builds that were failing were all running on a newer instance with a 3.13.0-39-generic kernel instead of a 3.13.0-36-generic kernel [16:09] fginther: odd. Thanks for the update [16:32] trainguards: can I get a silo for line 58 please? Is for a qtmir build system switch [16:32] greyback: is that for vivid? [16:32] sil2100: yep [16:33] greyback: since currently we're still lacking silos... all are full [16:33] sil2100: ah ok [16:33] greyback: I'm waiting for some to empty up [16:33] no rush [16:33] Oh, ok, I see one is ready now [16:36] jibel: btw. do we have someone performing sanity testing for the 166 equivalent for mako? [16:38] sil2100, not yet. [16:39] gotta leave for now, I’ll be back online later tonight to handle the silo request for oxide 1.3.5 [16:58] hmmm... [16:59] I wonder if oSoMoN needs a silo for the oxide-qt landing already [16:59] As it's not set to Ready: 'Yes' [16:59] i guess it still builds [16:59] oh, thanks [16:59] greyback: I can't assign a silo for you now since I see silo 009 already has qtmir in it (new Mir release) [17:00] ogra_: we had some free silos finally :) [17:00] sil2100: ack === chihchun_afk is now known as chihchun [17:55] ogra_, olli: hey! I sent out an e-mail to you guys regarding the milestone update [17:55] k [17:59] * sil2100 needs to drive to the store now [17:59] See you tomorrow o/ === alan_g is now known as alan_g|EOD === chihchun is now known as chihchun_afk [19:52] trainguards: can someone review this: https://code.launchpad.net/~mir-team/ubuntu-seeds/use-new-Mir-metapackages/+merge/242408 [19:53] trainguards: and related question, can I include that branch in my mir release silo (009) so that upgrading does not result in [19:53] unable to boot a phone [19:53] AlbertA2: no, we definitely want upgrades to break phones ;-) [19:54] robru: :) in that case I'm ready then heh [19:54] AlbertA2: so that branch looks fine to me but you need a core dev for seed changes. I recommend ogra_, he does most of the seed changes I know of [19:57] robru: thanks! [19:57] AlbertA2: you're welcome [20:12] manual acking? [20:13] ricmm: it's ok [20:13] robru: ok [21:40] trainguards: hey, can I haz a silo for line 56, please [21:41] oSoMoN: rtm 3 [21:42] robru, thanks, would you mind doing the binary copy of oxide-qt from https://launchpad.net/~phablet-team/+archive/ubuntu/ppa ? [21:54] oSoMoN: sure one sec [21:55] oSoMoN: which one? the newest one has a lower version. confused [21:55] oh rtm ;-) [21:56] robru, sorry, I should have specified: 1.3.5-0ubuntu0.14.10.1~rtm [21:56] (I hadn’t noticed that there was a 1.4.0 test build in there) [21:56] oSoMoN: hm, not sure if this'll work, as it won't let me choose 14.09 as the series. [21:57] oSoMoN: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-003/+packages yeah the copy failed. [21:57] robru, why not? it worked yesterday when copying 1.3.4 from the ubuntu-mozilla-security PPA [21:57] oSoMoN: yeah that one you were copying from vivid to vivid. This is a copy from utopic to 14.09, the series don't match [21:58] oSoMoN: there's probably some other way to sync it but I don't know what it is. the web form on the ppa won't work [21:59] robru, I wasn’t referring to the vivid one, actually the 1.3.4 that landed in RTM yesterday was also binary-copied from that PPA (the copy was not done yesterday though, it was two days ago) [21:59] robru, wasn’t there a script that you guys use to perform this kind of copy, instead of going through the web form? [21:59] oSoMoN: who did that one for you? [22:00] robru, probably sil2100 [22:00] oSoMoN: I just use the web form. the only script I ever had for this kind of thing was the one that did source copies and mangled the series. [22:01] robru, I guess that at this point a source copy won’t hurt anyway, as I’m not gonna test it before tomorrow morning [22:01] oSoMoN: but will it fail to build due to running out of space? ;-) [22:01] robru, that PPA has 4GB of space, that should be enough [22:02] oSoMoN: if you're not building until tomorrow morning anyway, just check with sil at the start of your shift. he should be able to do it again [22:02] robru, I’d rather have it build tonight so that it’s ready for testing tomorrow morning at the start of my shift [22:02] oSoMoN: but binary copies are really fast, just minutes even. [22:03] and will tax the build farm less [22:03] robru, right [22:03] robru, ok, I’ll check with sil2100 tomorrow morning then, thanks for the help [22:03] oSoMoN: ok sorry I couldn't help, get sil to teach me the secret of cross-series binary copies ;-) [22:04] will do :)