[07:20] good morning [07:20] Mirv, good morning [07:22] hi tvoss [07:23] Mirv, looking at the sheet, line 9 [07:23] Mirv, I don't understand the comment there [07:23] Mirv, could you explain to me what happened? [07:29] tvoss: it seems it has been published, but is stuck in -proposed for some reason [07:29] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#dbus-cpp [07:30] arm64 has failed to build, but it succeeded before: https://launchpad.net/ubuntu/+source/dbus-cpp/2.0.0+14.04.20140307-0ubuntu1 [07:30] seems to be the reason [07:30] https://launchpadlibrarian.net/168638213/buildlog_ubuntu-trusty-arm64.dbus-cpp_2.0.0%2B14.04.20140307-0ubuntu1_FAILEDTOBUILD.txt.gz [07:31] hmmm, that's weird [07:38] cjwatson, good morning [07:38] cjwatson, I get a build failure here https://launchpadlibrarian.net/168638213/buildlog_ubuntu-trusty-arm64.dbus-cpp_2.0.0%2B14.04.20140307-0ubuntu1_FAILEDTOBUILD.txt.gz [07:39] Mirv: hey, can you provide an url if you still have the same issue? [07:39] for the silo stuff [07:40] oh found the issue [07:40] * didrocks fixes [07:40] ah no [07:40] hum [07:41] didrocks: I haven't yet retried since I thought you'd take a glance first [07:41] Mirv: yeah, please give me a link [07:41] you didn't in your email [07:42] didrocks: it's in my last e-mail bu http://162.213.34.102/job/prepare-silo/421/console [07:42] Mirv: ah, ok, was still on the first one [07:42] thanks [07:42] yeah, weird that we have WARNING:root:Can't load configuration: No JSON object could be decoded [07:42] Mirv: I'll look in a few [07:42] yep, that one is weird [07:43] yeah, no hurry. I found 4 more packages not yet in landing PPA, and 3 of them are manual uploads which I'm doing now. [07:46] ok, we'll get that fixed [07:46] the logic seems good, so it's like it can't find the initiale configuraiton [07:46] I'll check with debug :) [07:46] (10 minutes) [07:58] Mirv: ah, interesting, the config file is empty [07:59] * didrocks restore and try [07:59] Mirv: did you have any failure previously on that silo? [08:00] Mirv: and after that, all work like expected. It would be interesting to know what lead in your silo to have that empty config file [08:02] Mirv: running http://162.213.34.102/job/prepare-silo/423/console btw [08:07] didrocks: the only thing I did was aborting build job, because of a ppc64el build that the system thought was building while it was not [08:08] didrocks: I got the error twice in the row and stopped at that. interesting. [08:08] Mirv: yeah, shouldn't happen [08:08] Mirv: tell me next time you see it, I'll be interested in fixing this bug [08:08] not sure, I try to always have transactional writes [08:08] sure, I will [08:08] thanks ;) [08:09] Mirv: on your question: please for those package, just disable them in daily release [08:09] + upstream merger and so on [08:09] (the 3 lines) [08:10] didrocks: ok, thanks, I'll disable those: dee-qt qtpowerd poppler-qml-plugin u1db-qt ubuntu-system-settings-online-accounts unity-scope-online-music click-update-manager clickmanager-plugin ubuntu-purhase-service [08:12] well, some of them already are, but anyhow [08:23] ok ;) [08:23] bug 1289804 [08:23] bug 1289804 in Ubuntu Music App "Music app consuming lots of memory on mako 226" [High,Triaged] https://launchpad.net/bugs/1289804 [08:23] seems we have a memory leak issue.. [08:23] (not just music-app) [08:23] popey: blocker in your opinion? [08:23] been there a while [08:24] but worse than it was in #194. [08:24] popey: they will tell you they will only look with 5.2 :p [08:24] we tested with 5.2 too.. [08:24] https://bugs.launchpad.net/music-app/+bug/1289804/comments/9 [08:24] Ubuntu bug 1289804 in Ubuntu Music App "Music app consuming lots of memory on mako 226" [High,Triaged] [08:25] popey: argh, ok [08:25] so no, not a blocker to #226 [08:25] it manifests itself in music because it's unconfined, you can get any app to eat ram by keeping it alive with taps [08:25] so it certainly needs examination [08:26] yep :) [08:26] hum [08:26] my phone was unusable after 20 hours of uptime and no usage ☻ [08:26] I received the notification for the team meeting [08:26] americans changed TZ [08:26] meaning the meeting is not set in UTC? [08:26] it moved here too [08:26] (the meeting moved) - it shows at 08:30 UTC [08:26] let me adjust the time again [08:27] probably the Ubuntu Engineering calendar is USA TZ [08:27] didrocks, you will have to adjust back on the 30th [08:27] ogra_: yep [08:27] popey: weird, the Tz set for it is "France" though [08:28] anyway, let's move them [08:28] and we'll move them back [08:28] oh, there is one everyday? [08:28] it's a separate one :p [08:28] ah no, phew [08:28] just long to refresh [08:28] no, they are separate [08:29] i moved some ☻ [08:29] ahah :) [08:29] the 6PM as well? [08:29] or they didn't move? [08:30] oof, I broke, let me fix [08:30] removing as well meetings during vUDS [08:31] ah yes [08:33] vUDS is so empty! [08:33] * didrocks scheduled last client meetings in seb128's track [08:33] hehe :) [08:40] didrocks: who 'owns' ubuntu-emulator? xnox? [08:40] popey: yeah, the biggest contributors are xnox/cjwatson/rsalvetti AFAIK [08:40] hm, ok [08:41] didrocks, good morning [08:41] Finally made it [08:42] Morning! [08:42] hey tvoss, morning [08:42] hey sil2100 :) [08:42] popey: anything we should be worried about? [08:42] saw a couple of people in -touch mention that their emulator wasn't starting. I tried this morning and I can't get it to build a working image either [08:42] just get a black screen [08:42] didrocks, sil2100 the dbus-cpp landing seems to be stuck in proposed due to arm64 not building. However, the compilation fails with the compiler complaining about -fstack-protector missing [08:43] didrocks, sil2100 the interesting bit is: I think I don't set that explicitly somehwere [08:43] trying again from clean. [08:44] tvoss: it's the distribution default [08:44] didrocks, that's interesting that it fails on arm64 then :) [08:44] didrocks, https://launchpadlibrarian.net/168638213/buildlog_ubuntu-trusty-arm64.dbus-cpp_2.0.0%2B14.04.20140307-0ubuntu1_FAILEDTOBUILD.txt.gz [08:44] tvoss: https://wiki.ubuntu.com/ToolChain/CompilerFlags [08:45] tvoss: I guess it's something to check with doko, I have no clue about arm64 if it's supposed to support stack-protector or not [08:45] tvoss: hmm, well, there was no way to test it beforehand on arm64, as I can't set up a arm64 chrrot even [08:45] and if so, why it's set [08:45] tvoss: strange thing - why didn't it fail for the previous dbus-cpp builds? [08:46] tvoss: and yeah, I confirm that you don't seem to do anything with the flags that can set it on that arch [08:46] (and so override potential defaults) [08:46] but you force 4.7 [08:46] and I'm unsure 4.7 has the right defaults for that arch, I guess doko only cares about 4.8 [08:46] tvoss: that can be a lead to discuss about it with him I think ^ [08:50] sil2100: previous version was built with 4.7 or 4.8? [08:54] hm, with 4.7 [08:54] didrocks: since the whole issue we had with location-service being 100% CPU was caused by the 4.7/4.8 incompatibility [08:54] sil2100: ok, weird then [08:55] I think tvoss has enough information to know where to look at anyway :) [08:55] tvoss: Morning. arm64 doesn't have stack-protector. Why are you forcing that, though, given that -fstack-protector is on by default in Ubuntu anyway? [08:55] So we pushed a force rebuild on 4.7 + the symbols hack [08:55] didrocks: emulator> not me [08:55] Strange anyways! [08:55] cjwatson, I'm *not* forcing it [08:55] cjwatson: I don't see it in his build flags though, but he's using gcc 4.7, do you think that disabling stack-protector can be missing on that versioN? [08:55] didrocks: It's explicitly on the command line [08:56] So it's not GCC's fault :) [08:56] Wonder if it's cmake [08:56] yeah, I'm looking into that direction [08:56] Or dpkg-buildflags [08:56] nothing special on the configure flags [08:56] I'd have thought dpkg-buildflags shouldn't have -fstack-protector on arm64 though [08:57] well, I guess all packages would fail otherwise… [08:59] that command line does look awfully like dpkg-buildflags though [09:00] yeah, followed by --param=ssp-buffer-size=4 and so on, with -g -O2 before… [09:01] Oh [09:01] dpkg (1.17.5ubuntu5) trusty; urgency=medium [09:01] * Allow -fstack-protector on arm64 now that GCC and glibc support it. [09:01] -- Adam Conrad Fri, 07 Mar 2014 18:47:57 +0800 [09:01] here we go [09:01] So gcc-4.8 supports it, but of course dbus-cpp is forcing gcc-4.7 [09:01] tvoss: you have your infos ^ [09:01] tvoss: export DEB_CXXFLAGS_MAINT_STRIP := -fstack-protector [09:02] well, conditional on arm64 [09:02] so, in debian/rules: [09:02] cjwatson, so that's in debian/rules? [09:02] ifeq (arm64,$(DEB_HOST_ARCH)) [09:02] export DEB_CXXFLAGS_MAINT_STRIP := -fstack-protector [09:02] endif [09:02] should do it [09:02] with a comment that this is because g++-4.7 doesn't have SSP, and it can go away if/when you move to 4.8 [09:04] didrocks,Mirv: the ppc64el build in question was a build *failure*, not so much "building" although that's how the job described it [09:04] cjwatson: something stripped out the status file, so it wasn't refreshed anymore. So don't take into account the status reported in that case [09:05] didrocks,Mirv: that was qttools-opensource-src, which we got building later [09:05] it was definitely not building at the time [09:05] or rather it was definitely failed at the time [09:05] cjwatson: I'm maybe out of context for that last ping, but the job was running or you were talking about the jenkins job iself? [09:05] itself* [09:06] cjwatson: I think since it started on Friday, it had not yet been build at all. the first failure of qttools was then on Saturday after copy-package https://launchpad.net/~ci-train-ppa-service/+archive/landing-006/+builds?build_text=qttools&build_state=all [09:06] I don't know the distinction [09:06] Mirv: it was dep-wait on qtdeclarative at the time - I checked [09:06] but on Friday (until Saturday) CI Train was under impression there was a build of ppc64el that was building [09:06] that's why I sent you a qtdeclarative porting branch [09:06] cjwatson: this is what I aborted originally http://162.213.34.102/job/landing-006-1-build/65/console [09:06] I was explicitly working on clearing up that job :) [09:06] cjwatson: aha, ok [09:07] from my point of view the ci-train job was entirely correct - I mean, regardless of fine distinctions, it'd have got stuck in proposed-migration due to the missing ppc64el build, so it was right to fix it [09:08] sil2100, pushed an update to https://code.launchpad.net/~thomas-voss/dbus-cpp/fix-race-and-add-tests [09:08] sil2100, can you trigger a rebuild? [09:09] tvoss: that should be before the include I guess [09:09] (and you can retrigger yourself normally, with ignore step and only set the component you want to rebuild with only rebuild) [09:10] you don't need sil2100 for that [09:10] tvoss: you can rebuild yourself :) [09:10] include> I don't know if it matters, but can't hurt to move it earlier [09:11] tvoss: just find the silo on the spreadsheet, press rebuild, log into jenkins (SSO) and press build [09:11] tvoss: maybe write to only 'rebuild' dbus-cpp [09:12] cjwatson: ah ok, I was under the impression it was looking for the definition in the env first and won't look at it again, but I just skimmed over the makefile for that, so you're probably more exact than I am. Thanks :) [09:12] didrocks: how do we handle cases when a silo is already in the 'releasing, stuck in proposed' state? [09:12] tvoss: wait a moment with that if anything [09:12] sil2100: just rebuild what's needed to be rebuilt and I think you will need the "ignore step" option [09:13] didrocks: ok [09:13] then, it will rebuild only that component, and track it [09:13] tvoss: let me help you in that then, I'll do this [09:13] (however, it will recollect all commits since latest version in the release pocket and upload with -v) [09:13] sil2100, ack [09:13] didrocks: this is one of those things where I'd have to read the GNU Make manual carefully, and it's not worth it :) [09:13] but that was only tested in labs, it's the first time in production :) [09:13] cjwatson: heh, indeed :) [09:14] didrocks: uuuu ;p Ok, let's try that then [09:15] didrocks: hmmm... I just noticed my mail, I probably missed something, but was todays landing meeting moved to an earlier hour? [09:16] sil2100: it was, weirdly (probably due to US dailylight saving switch) [09:16] sil2100: so I rescheduled at the correct time [09:16] My google calendar said 9:30 till 10, like one hour earlier than normally :o Did I miss it? [09:16] Ah [09:16] Ok ;) [09:16] sil2100: your google calender should have it updated? [09:17] didrocks: ah, right, calendar has the correct date, but I didn't get a confirmation of the change on e-mail, so I was a bit shocked [09:17] THanks ;) [09:18] yeah, I avoided to spam all of you [09:26] tvoss: let's wait for it to re-build [09:26] sil2100, ack [09:31] popey: coming? [09:32] omw [10:01] Mirv: given that we'll be waiting for arm64 to build everything, I would suggest blocking the set of packages in the Qt5.2 silo in proposed-migration [10:01] (once you push the button) [10:01] just to avoid accidents with partial promotions [10:03] didrocks: who should I poke https://bugs.launchpad.net/music-app/+bug/1289804 with? [10:03] Ubuntu bug 1289804 in Ubuntu Music App "Music app consuming lots of memory on mako 226" [High,Triaged] [10:03] popey: reboot worked for you? [10:03] yes didrocks [10:04] popey: ok, I don't have it either here in a fresh flashed image [10:04] worth keeping it in mind and see [10:04] will keep an eye out for it on future updates [10:04] thanks [10:04] popey: for bug #1289804, I would say let's start with upstream, so osomon/bfiller [10:04] cjwatson: ok, didrocks can probably set the block, at least if it turns out we enable the arm64 builds but then suddenly make a decision tomorrow or so about actually landing it [10:04] bug 1289804 in Ubuntu Music App "Music app consuming lots of memory on mako 226" [High,Triaged] https://launchpad.net/bugs/1289804 [10:05] arm64 is going to be interesting, starting with qtbase where doko told the arm64 patches can be dropped with 5.2, I hope it's so [10:06] davmor2: oh btw, can you dogfood image #229? We'll get it in our bag for promotion :) [10:06] Mirv: yeah, better to prepare it [10:06] Mirv: when is that meeting? Maybe I should come this time [10:07] didrocks: yeah no worries [10:07] didrocks: umm, I now see the meeting is no more this week, at least currently. it used to be 14:00 UTC [10:07] Mirv: interesting… [10:07] Mirv: wasn't moved to one hour later? (as many meeting due to US TZ change) [10:07] meetings* [10:08] didrocks: no, just not there. probably set to be daily "until we've probably shipped it" or so :) [10:08] Mirv: yeah ;) [10:08] the unity8 AP problem might have a fix now, since I rebuilt qtbase with a fix suggested from unity people [10:09] Mirv: tell me if you need anything, but I clearly think that we should continue on what was discussed Friday: only the expected AP failure [10:09] ok [10:09] weather app I think was already seen to be broken, probably needs fixes for 5.2 [10:09] expected == clock apps as from today [10:09] it'd be nice if gallery app could be tested somehow [10:09] and 2 weather apps ones [10:09] ah no, it's one on weather-app [10:10] Mirv: so, we expect only 1 clock AP test failure + 1 weather AP test failure [10:10] all the rest needs to be investigated [10:10] didrocks: I checked that online-acounts does have the revert in it [10:10] Mirv: the run from Friday? [10:10] AP test run? [10:11] (the code where we see it failing shouldn't be in the revert at all) [10:11] didrocks: hmm, actualy, it's a good question whether the AP run or the Friday's online-accounts rebuild was there first.. [10:11] didrocks: so that's probably then it [10:11] Mirv: ok, worth having a look anyway :) [10:12] didrocks: I originally btw thought that if 5.0 image can be promoted, it's good to land 5.2, but you think we continue at least for now seeking to do 100% smooth transition (where, nearer to it than current situation)? [10:12] I wonder if UI Freeze on Thursday poses a problem [10:12] Mirv: yeah, otherwise, we'll never recover and block everyone else not part of the transaction [10:13] Mirv: why? we have FFe for our components (and it doesn't change the UI) [10:13] true enough, nothing should change UI wise [10:13] Mirv: we can't ask blocking the whole distro again on pushing something not ready when we know it's not ready yet [10:13] that won't make it more "ready" [10:15] I don't think anyone is currently working on the 5.2 related AP problems, though, yet [10:15] that should change, of course [10:15] Mirv: that should have been the focus as well of the 5.2 meetings though [10:16] yeah [10:16] didrocks: the problem was that for most of the last week the AP runs were not working because of the adb/makodevice problems [10:16] now we've that one run finally [10:16] Mirv: which issue? [10:17] Mirv: something we don't have on ci.ubuntu.com? [10:17] didrocks: I mean the AP runs were not possible to do because of http://q-jenkins:8080/job/autopilot-release-gatekeeper/61/console [10:17] first the adb problems and then the connection to mako:s not working, elopio & his team were then onto it [10:18] Mirv: ok, so infra issues mostly? [10:18] didrocks: yes [10:18] Mirv: anyway, we discussed about the AP tests on Friday with elopio and asac as well agreed with me [10:18] Mirv: so I don't think that will come to a surprise [10:19] yeah. so trying to fix those should continue together with the DPR issue fix. [10:21] yep [10:24] sil2100, didrocks I'm kinda lost with the dbus-cpp landing now [10:25] tvoss: ok, wait, it finished building [10:25] didrocks,Mirv: landing-006 has arm64 now, so can you please copy everything in that PPA into itself? [10:25] tvoss: let's do a quick test-spin on a device if all is ok and then re-publish [10:26] (let me know if you need a canned command line) [10:26] Mirv: you are handling the copy? [10:26] sil2100, okay, I will give it a spin, too [10:26] sil2100, could you try it, too? [10:26] copy-package -p ci-train-ppa-service --ppa-name landing-006 -b [10:26] tvoss: sure, doing that now [10:27] sil2100, thanks [10:27] cihelp infrastructure problems running AP tests http://q-jenkins:8080/job/autopilot-release-gatekeeper/64/ - previous successful run on Friday [10:28] didrocks: ok, handling the copy [10:28] thanks :) [10:32] actually, I'll not copy everything, since not everything build-deps on the new Qt. so starting with Qt itself which is all set up good regarding dependencies [10:33] why the backup-landing1? [10:33] oh ye of little faith [10:35] cjwatson: too much to lose :) [10:35] you couldn't copy it back without generating at least some new builds anyway ... but ok [10:37] hmm, promoting takes loong with so many arches === pete-woods is now known as pete-woods-afk [10:38] actually, I will start by qtbase only because that's the one with the libqt5core5 -> libqt5core5a change [10:38] reasonable, yeah [10:38] wow [10:39] and so it begins [10:41] hmmm, what a nice bug I got! [10:43] sil2100: on the double promotion for fixing something stuck into proposed? It's possible as I only tested that case in lab :) [10:44] didrocks: no no, on 229 ;) I'll show a photo of that, it's just a funny thing, I guess it's just some layouting issue or something ;p [10:45] ah :) [10:46] grmpf ... [10:46] promotion of 226 on mako runs since 13min ... doesnt move ... [10:52] ogra_: still stuck? [10:52] yes [10:52] 29071 pts/1 S+ 16:12 /usr/bin/python /srv/system-image.ubuntu.com/bin/copy-image trusty-proposed trusty mako 226 -k [10:52] so, we'll need stgraber? [10:52] runs sine 16:12 [10:52] yes, i think so [10:52] seems copy-image also doesnt produce any logs [10:53] it just sits there (seems to be in running state though) [10:53] might just be rechecksumming or something [10:53] i see it updated the timestamp for the output dir though [10:53] 29071 pts/1 S+ 16:14 | \_ /usr/bin/python /srv/system-image.ubuntu.com/bin/copy-image trusty-proposed trusty mako 226 -k [10:53] 2963 pts/1 Rl+ 0:33 | \_ pxz -z -9 -c /tmp/tmpgcbAS5/output.tar [10:53] looking at more of the process tree helps :P [10:53] sigh ... we have 6 arches to promote [10:53] I'm sure it'll get there [10:53] that will take 1.5h now [10:54] xz compression just takes a while [10:54] yeah, but it used to be a matter of 1-2min before [10:54] then why will it take 1.5h now? [10:54] 1-2min * 6 != 1.5h [10:54] i guess that we havent promoted anything in rwo weeks might play a role for the diffing [10:54] cjwatson, it used to take 1-2min ... if it takes 15 per arch now it will take a small century :) [10:55] ah, it moved [10:55] does it matter for this particular run? :) [10:55] cjwatson: ok doesn't start too well https://launchpadlibrarian.net/168944721/buildlog_ubuntu-trusty-arm64.qtbase-opensource-src_5.2.1%2Bdfsg-1ubuntu6_FAILEDTOBUILD.txt.gz [10:55] not anymore, no ... i would have waited with starting it though ... since i have to go afk in 10min [10:55] the patches that were there with 5.0.2 were http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src/revision/140 [10:56] ogra_: it got through manta pretty quick, so *shrug* [10:56] oh, seems the other arches run faster [10:56] Mirv: so what thinks it needs to use -m64? [10:56] grr [10:56] http://paste.ubuntu.com/7067002/ [10:57] Mirv: oh right, easy [10:57] Mirv: http://paste.ubuntu.com/7067006/ [10:58] that's for arches where -m64 doesn't make sense [10:59] cjwatson: ok, and I don't see other similar things in debian/rules so I guess worth a rerun unless there's a test PPA to use [10:59] you used to have a separate if case for it, you just moved arm64 to the wrong place [11:00] http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src/view/140/debian/rules lines 69-72 [11:00] Morning all [11:00] Mirv: probably worth just rerunning in 006 [11:00] ok [11:02] ogra_, do you know how is the qt 5.2 thing going? [11:02] mandel, Mirv does ;) [11:03] mandel: https://bugs.launchpad.net/webbrowser-app/+bug/1207270 needs to be fixed and some AP tests are failing http://q-jenkins:8080/job/autopilot-release-gatekeeper/63/ [11:03] Ubuntu bug 1207270 in Ubuntu UI Toolkit "Font size too small in browser with Qt 5.1 / DPR rework" [Critical,In progress] [11:03] Mirv, thx [11:04] mandel, Mirv does ;) [11:04] oops [11:04] sorry [11:04] I do, I do [11:04] heh, EFOCUS [11:04] and that's why I've prevented 'up' binding in irssi, requiring ctrl-up [11:06] * ogra_ needs to go afk now for like 20min ... i'll check the promotion later ... looks like mako might need a re-run [11:06] Mirv, we need to fix that ogra_ bot, it has some weird stammer [11:07] heh [11:15] sil2100, ping [11:16] sil2100, any luck with the dbus-cpp packages? [11:16] sil2100, didrocks can I get a silo for line 34? [11:17] tvoss: unity-mir is part of the qt 5.2 landing [11:17] didrocks, oh okay [11:18] tvoss: still checking out - looks ok from the outside, but I still couldn't get location working yet [11:19] sil2100, location not working as in? [11:23] tvoss: can't force webbrowser to use location data after enabling it in the indicator [11:24] popey, davmor2: does location work properly for you on stock 229 ? [11:24] sil2100, the indicator is not fixed with my changes. Also: it might take 15 minutes to acquire a fix [11:24] sil2100: define "work" [11:26] popey: after enabling the indicator, does opening a webbrowser prompt you for allowing location on google maps and then it finally finds the GPS signal? [11:26] sil2100: i have _never_ had success in a browser finding location [11:26] sil2100: haven't tried it yet, ignore the indicator though it lies [11:27] tell you what is odd though [11:28] open browser, visit maps.google.com, kill browser, start again. [11:28] The first time you get mobile version of gmaps, second time you get desktop version [11:28] popey: because you click on the link for maps right [11:29] popey: -https:// always links to the mobile site, if you click on the link it the address bar it always goes to desktop [11:31] hmm, so promoting mako and generic failed ... re-running for these two [11:32] no [11:32] i didnt click any link [11:32] i opened browser [11:33] ugh, and flo too ... [11:33] * ogra_ sighs [11:34] sil2100: osmtouch has me pinpointed nicely so I assume gps is working [11:38] davmor2: osmtouch doesn't use gsm [11:38] *gps [11:39] popey: It's stops flashing the warning there is no gps and pinpoints you precisely when there is a fix and google maps works then too [11:41] popey: initially it doesn't I agree but then it tells you it isn't using gps and also tells you that the position is approximate [11:45] popey, didrocks, ogra_: screen has just frozen again, this time 2 apps open and I swiped to get back to the dash chasing up on #ubuntu-mir channel but not seeming to get a response yet, I'll carry on dogfooding on the n7 for a bit [11:45] davmor2: thanks [11:46] davmor2, make sure to back up syslog and the output of dmesg ... and probably also logcat [11:47] ogra_: thanks will do that now, the phone is working fine just not the screen [11:47] right [11:47] davmor2: Mar 10 11:47:38 ubuntu-phablet com.ubuntu.location[893]: SV status update: [#svs: 23] [11:47] i get 23 satellites in view and it still cant get a lock [11:47] syslog should show OOM if there is any OOM going on ... and logcat should show any graphics driver issues [11:48] popey: just checked top and there is no swap being used so it's not the issue you saw [11:48] it takes a long time to use swap [11:48]