[01:27] i'm sorry if I'm posting an old question: i have tried many ways to install ubuntu-touch on nexus 7 3G (Tilapia), but forever failed. Any hints ? === LarrySteeze|Away is now known as LarrySteeze === SirCmpwn_ is now known as SirCmpwn === duflu_ is now known as duflu [02:42] plars, ping [02:42] cwayne: hi [02:42] looks like touch_custom hasn't been running? [02:42] cwayne: let me take a look [02:44] cwayne: oh, strangeness [02:44] cwayne: it didn't even get to the first subjob, so there was nothing to fail [02:44] cwayne: give me a moment, I should be able to kick it [02:46] cwayne: ok, it's running now [02:46] plars, great, thanks! === chihchun_afk is now known as chihchun === ricardodrosales is now known as ricdros === mbm is now known as [mbm] === vying is now known as Guest59676 [06:06] Saviq: I reopened the gsettings-qt bug, it still fails similarly with the new qtdeclarative snapshot so not sure what's up [07:06] Saviq, good morning [07:11] Saviq, switching unity-mir over to cmake I stumbled across http://pastebin.ubuntu.com/6719287/ [07:11] Saviq, where do these files originate from? [07:32] Wow, haptic! :D [08:04] timppa, weird, isn'it? :) [08:04] Saviq, https://code.launchpad.net/~thomas-voss/unity-mir/switch-to-cmake [08:04] tvoss, thanks [08:05] Saviq, hang on, need to resubmit and set the prerequisite branch [08:05] tvoss, yeah, I can see it's not MP'd [08:06] Saviq, should be good now [08:13] tsdgeos, we really need to stop copying the .cmake files everywhere :? [08:13] Saviq: which .cmake files? [08:14] tsdgeos, basically everything that we have in lp:unity8 in cmake/modules [08:14] ah [08:14] yes [08:14] tsdgeos, maybe except Plugins.cmake and QmlTest.cmake [08:14] but I see no reason why we shouldn't share those as well [08:14] tsdgeos, and it was meant to be tvoss ;) [08:15] that's the hard stuff :D [08:15] tsdgeos, sorry for dragging you into this ;D [08:15] ok [08:15] Saviq, sure, I can factor that out into a common project. Do you want to block on this? [08:15] fwiw in the thing "that is not called kde5" there's a module with all these kind of files [08:15] tsdgeos, but thanks for your apt and unending support :D [08:15] tvoss, well, it's blocked on tests for the prerequisite branch already ;) [08:16] Saviq, sure, but we have a chicken-and-egg problem here :) I do not make the test coverage any worse, even in the prerequisite branch [08:16] tvoss, and yeah, that would reduce the diff by half or so, so I'd rather see that extracted first [08:16] tvoss, yeah, why did you make it a prerequisite anyway? ;) [08:16] good morning [08:17] hi dholbach [08:17] hey Saviq [08:17] Saviq, well, the prerequisite branch pulls in some additional dependencies [08:17] Saviq, but I can inverse that relationship [08:18] tvoss, maybe that'd be best inded [08:18] +e [08:20] didrocks, 4 years today, congratz you old goat! ;D [08:22] Saviq: ahah, thanks a lot! is it linkedin that suggested that or we have a secret calendar? ;) [08:22] ah, just got my answer ;) [08:22] didrocks, indeed :D [08:22] I remember, it's that week we packaged Unity for the first time ever [08:23] and did a respin of ubuntu with it, just a small preview [08:23] (it was just a launcher at the time) [08:23] sprinting in Paris [08:23] was fun ;) [08:24] ah, as well, it's the day Rick understood how pleasant parisian waiters can be… ;) [08:26] :) === zbenjamin_ is now known as zbenjamin [08:46] Saviq, any thoughts on these two files? http://pastebin.ubuntu.com/6719287/ [08:47] tvoss, wtym? those come from unity-api, being included as source in projects implementing those interfaces, why? [08:48] Saviq, hmmmm, wouldn't it make more sense if unity-mir carried those interfaces? [08:49] tvoss, the idea was, if you remember, to have a common place for shell-facing interfaces (being unity-api), so that we have them disconnected from any particular implementation [08:50] Saviq, ah .. okay, I misread unity-api as unity [09:07] Saviq, https://code.launchpad.net/~thomas-voss/unity-mir/switch-to-cmake-take-2/+merge/200967 [09:09] tvoss, cheers, will try and get a review today [09:27] cjwatson: Hey [09:27] cjwatson: so it seems what was feared about qt 5 is what is happening [09:27] cjwatson: that is, the proposed plan is to rename the qt5 binary package but keep the SONAME the same [09:28] cjwatson: I am not aware of a technical solution to ship two versions of the same SONAME with different ABIs on the same root, so either we change the SONAME or revert the ABI change and break compat with Debian and other Linuxes and upstream, or we introduce chroots [09:29] cjwatson: do you know of other options? [09:29] cjwatson: Debian #731261 has the background [09:29] Debian bug 731261 in release.debian.org "transition: Qt5 switching qreal == double for all platforms" [Normal,Open] http://bugs.debian.org/731261 === Tachyon`` is now known as Tachyon` [10:43] lool: we could ship the .so in a private library directory and have anything that needs compatibility use LD_LIBRARY_PATH [10:43] a chroot would be significantly (and in my view unnecessarily) more heavyweight [10:59] mpt, hey, I think that we said in Oakland that Serial/IMEI should be hidden on a config which doesn't have those infos (rather than being displayed as N/A as currently done/specified in https://wiki.ubuntu.com/AboutThisDevice#Phone) [11:00] mpt, is that right? can you update the wiki to reflect that (do you want a bug report as a reminder)? [11:02] Morning all [11:02] ogra_: haptic feedback but only partial which makes it weird :) === davmor2_ is now known as davmor2 [11:03] oh, i havent upgraded today [11:04] ogra_: 119 [11:04] yes [11:04] ogra_: also I thought if you enabled /userdata/.writable_image that it should update as it was in developer mode or am I wrong? [11:05] should not even [11:06] it should still update [11:06] (and will revert any changes you made to the ro part) [11:08] ogra_: that's okay then is there a difference between rw mode and developer mode then? [11:08] nope [11:09] not to my knowledge [11:09] ogra_: oh okay, I don't know why I was under the impression that you couldn't updarte then [11:11] ogra_: eh.. if you enable writable_image mode it does break updates [11:12] ogra_, popey: no it doesn't [11:12] popey, how so ? [11:12] by updates we're talking about OTA system settings updates right? [11:12] popey: I upgrade to 119 [11:12] it still replaces the readonly images [11:12] how are you updating? [11:12] ogra_: I still have htop installed on the phone [11:13] then it didnt update [11:13] popey: over the air this morning [11:13] ergo updates broke [11:13] popey, they didnt [11:13] if davmor2 has vibration the upgrade got applied [11:13] hm [11:13] popey: but I got haptic feedback which I didn't have before [11:14] i had writable_image on last week and did an OTA update and it didnt update even though I did it multiple times [11:14] root@ubuntu-phablet:/# system-image-cli -i [11:14] current build number: 119 [11:14] device name: maguro [11:14] channel: devel-proposed [11:14] alias: trusty-proposed [11:14] last update: 2014-01-09 09:17:54 [11:14] version version: 119 [11:14] version ubuntu: 20140109 [11:14] Error: Ubuntu bug 20140109 could not be found [11:14] i rm'ed the file and restarted and then updates worked again [11:14] version device: 20140107.1 [11:14] davmor2, dpkg -l htop [11:14] ;) [11:14] i was always under the impression that making it writable makes updates no longer work, did that change or has that never been the case? [11:15] * ogra_ bets you dont have it installed ... despite the binary being there in some writable space [11:15] root@ubuntu-phablet:/# dpkg -l htop [11:15] dpkg-query: no packages found matching htop okay weird [11:15] popey, making it writable will break stuff once you upgrade [11:15] like resetting the package db [11:15] ogra_: so htop runs but isn't installed what [11:15] the binary is installed === chihchun is now known as chihchun_afk [11:16] or for complex packages that install stuff in multiple locations i the ro area they need it will cause breakage [11:22] okay I think I get it now, so htop was installed, but the packagedb got replaced so as far as the system is concerned it isn't installed. So in order to get back to a sane system I would need to do a phablet-flash right? [11:23] or [11:23] adb shell rm /userdata/.writable_image [11:23] adb shell system-image-cli --build 0 [11:23] do that [11:37] asac, tvoss ... http://paste.ubuntu.com/6720246/ [11:37] seems we use oom_adj on the ubuntu side but also have lowmemorykiller enabled without configuring it at all (beyond the kernel defaults) === _salem is now known as salem_ [11:38] ogra_: cool :) [11:38] ogra_, yup, that's what I was referring to yesterday [11:38] i assume that might have some influence on our behavior [11:38] ogra_: i really believe someone just needs to go and tweak config values until things are nice :).... did you guys discuss this yesterday on the team meeting? [11:38] e.g. who will drive this in your team? [11:38] asac, no, thats my own little research from today :) [11:39] ogra_: no discussion on yesterdays standup? hmmm [11:39] i'll bring it up today [11:39] ogra_, we should start tuning minfree first, and then look into oom_adj banding [11:39] i mentioned it in the standup but we had no discussion [11:39] ogra_: thanks. thats what folks promissed me yesterday already ... [11:40] asac, I'm working on unity-mir right now to make this more testable [11:40] well, i wonder if we should touch oom_adj at all [11:40] :) [11:40] ogra_, I'm not sure either, min_free might well be enough [11:40] ogra_, but the shell and the OomController in there has to be aware of the settings, too [11:40] tvoss: from what i understand those values can be runtime tweaked without reboot? [11:40] asac, yup [11:40] seems android doesnt do that ... [11:40] right [11:40] currently we force the session to -10 with the lightdm setting [11:41] ogra_, right [11:41] asac, they can [11:41] you can just echo into the sysfs node [11:41] with that it feels easy to just play around with these values for a day; of course requires someone who knows which values can be tweaked and what they really do :) [11:41] so that disqualifies me :P [11:42] sadly thats about all documentation that exists about this thing [11:42] but guess its not that simple as we have to fix bugs in unity and elsewhere alongside [11:42] at least i cant find anything [11:42] ogra_, the android java source code provides some insight, too [11:42] as this was never really finished [11:42] yeah [11:42] but we'll need it for release [11:42] for sure [11:43] tvoss: maybe we could isolate the app lifecycle code baking by changing the heuristic to always kill all apps that go in background? [11:43] that will make app switching really slow i suppose [11:43] in this way we probably can work on fixing sdk/apps etc. while we somehow figure those memory pressure thresholds [11:44] as long as we have ram we should make use of it [11:44] asac, I think we hide more issues than we solve with that [11:44] sending sigstop has influence on latency [11:44] well, we can bake the app logic independent from the memopry pressyure thing [11:44] i wouldnt change it in the build [11:44] asac, so you want to force baking app logic by always killing them? [11:45] asac, or make it easily reproducible by devs? [11:45] baking app serialize/restore logic [11:45] make it easy to set such a mode [11:45] not by default of course [11:45] asac, I will take a look, but as a last resort, apps can be manually killed from the lens [11:45] right now i see that we have to understand those kernel parameters to get the right memory pressure behaviour that will automatically trigger kiling etc. [11:45] on top we have to ensure that killing and bringing back to life works [11:45] asac, sure [11:46] asac, and I agree that both are to a certain degree independent [11:46] yeah. just thinking out louad that we could already give a reproducible problem to app folks [11:46] while we figure the rest [11:46] asac, yup, we should hand over that information to the apps team and to the core apps devs [11:46] we need to find the right compromise imho [11:46] ogra_, sure, but that's only one part of the task as asac pointed out [11:47] yeah [11:49] tvoss: so what are the values you said need tweaking? [11:49] hmm, I assume that the pagesize on arm is 4kb? [11:49] asac, the min_free values in /sys/module/lowmemorykiller/parameters/minfree [11:50] asac, they represent thresholds of memory that are available and android oom killer kicks in if a threshold is reached [11:51] tvoss: what values do we have? [11:51] asac, 1536,2048,4096,16384 [11:51] in [# pages] [11:51] ogra posted: http://paste.ubuntu.com/6720246/ [11:52] tvoss: so 64M? [11:52] do our apps have oom_adj 12? [11:52] asac, the latter I'm checking right now [11:52] asac, I don't think so [11:53] tvoss: how can i see that value? [11:54] ah nevermind [11:54] asac, for a given process, you can just cat /proc/pid/oom_adj [11:54] found it in /proc [11:54] yup [11:54] asac, all of the session should inherit from the lightdm.conf value [11:54] and where is that set? [11:54] do we do that in upstart? [11:54] yes [11:54] see the last line of my paste [11:55] so child pids get the same as parents by default? [11:55] asac, yup [11:55] forked child processes do [11:55] ogra_: do you have an app running? do you get -10 for that? [11:55] asac, ogra_ be careful: lightdm sets oom_score_adj, which is _not_ oom_adj [11:55] hmm [11:55] ogra_: so what value do you get in /proc/$PID/ooem_adj ? [11:55] for an app [11:56] oom_adj is actually deprecated, oom_score_adj has got -1000 -> 1000 [11:56] (now the question is if everything is a fork here) [11:56] 10000? [11:56] root@ubuntu-phablet:/# cat /proc/$(pidof unity8)/oom_adj [11:56] 0 [11:56] ogra_: right. what about an app? [11:56] so that seems wrong [11:56] ogra_, you need to cat oom_score_adj [11:56] ogra_, nope, that's most likely correct [11:56] tvoss, ah, thanks [11:57] thats indeed -10 [11:57] lets see an app [11:57] root@ubuntu-phablet:/# cat /proc/2346/oom_score_adj [11:57] 1 [11:57] thats the file manager [11:58] thats correct too (apps should be higher than unity) [11:59] but what does the lowmemorykiller make out of that ? [11:59] ogra_, can you please cat oom_adj for the file manager? [12:00] asac, oh, btw, even though we didnt deeply discuss teh swap stuff in teh standup, we put app lifecycle on the sprint agenda as a high prio item [12:00] tvoss, 12 === pete-woods is now known as pete-woods|fight === pete-woods|fight is now known as pete-woods|away [12:01] ogra_, that's weird, it shouldn't have that value [12:02] ogra_, oom_score_adj is scaled linearly to oom_adj [12:02] ogra_: right. but i wanted to get an owner and see progress now, not end of month [12:02] tvoss, well [12:02] root@ubuntu-phablet:/# cat /sys/module/lowmemorykiller/parameters/adj [12:02] 0,1,6,12 [12:02] ogra_, that's the setup, not the actual values [12:02] there is 12 in the lowmemorykiller ... i guess that gets applied by default when an app starts [12:03] ogra_, I would be surprised if that was the case, let me add some debug output [12:03] tvoss: where are the actual values? [12:03] asac, of the individual processes? in /proc/pid/oom_adj and /proc/pid/oom_score_adj [12:04] so its 1 for apps. interesting [12:04] asac, oom_score_adj is 1 for apps, we have to look at oom_adj [12:05] and thats 12 [12:05] k [12:05] ogra_, and that I don't understand [12:05] so this means we should see apps getting killed if less than 65m is available, correct? [12:05] asac, correct [12:05] ogra_, oom_score_adj is scaled from -1000 to 1000 [12:05] are we able to observe/confirm that? [12:05] asac, from what ogra described yesterday: yes [12:06] so maybe changet that to something big (e.g. 150M) and see if at least the slowness goes away [12:06] ogra_, I saw a pastebin of the andorid oom killer kicking in yesterday, do you have that handy? [12:06] tvoss, aha ... webapps have totally different values [12:06] ogra_, yup, most likely because they are a process tree [12:06] ogra_, working on that, too [12:06] http://paste.ubuntu.com/6720377/ [12:07] ogra_: what do webapps have? [12:07] yeah [12:07] bump that [12:07] 0 and 1 [12:07] i believe they should be 15 [12:07] and 150M for 15 [12:07] hehe [12:07] tvoss: isnt unity supposed to change the adj value if the app is in foreground? [12:07] well, it should be the same as native apps [12:07] which is 12 currently [12:08] or how do we ensure that we dont kill foreground? [12:08] asac, sure [12:08] ogra_: is the webapp in the background? [12:08] no [12:08] asac, ogra_ https://code.launchpad.net/~thomas-voss/unity-mir/refactor-oom-score-adj-to-rely-on-process-cpp [12:08] ogra_: can you confirm that the value changes if you put it in background/foreground? [12:08] asac, ogra_ https://code.launchpad.net/~thomas-voss/unity-mir/refactor-process-group-operations-to-rely-on-process-cpp [12:08] root@ubuntu-phablet:/# cat /proc/2421/oom_score_adj [12:08] 800 [12:08] thats in the background [12:08] right [12:08] that makes sense [12:08] so change the 12 value to 150M [12:08] instead of 64M [12:09] and see if slowness goes away [12:09] thats what i would try :_) [12:09] right, let's scale up the biggest bucket and see what happens [12:09] filemanager gets 800 too in bg [12:09] apps shouldnt be 12 inn foreground i guess [12:09] tvoss: maybe add another bucket 100? [12:10] asac, I would first scale up the 12-bucket to 32768 [12:10] asac, pages, that is [12:10] tvoss: but that will apply to foreground apps :) [12:10] too [12:11] afaics [12:11] +12 vs -12 ? [12:11] :) [12:12] tvoss: how does this killer operate? does it always first the ones in a higher bucket first? [12:12] or is it randomly killing all that are beyond threshold regardless of the score? [12:13] asac, yup, it starts in the highest bucket and kills all process with oom_adj value of oom_adj value of respective bucket, or greater [12:13] tvoss, ok, using 32768 now ... opening the third webapp kills the first two that are open [12:14] thats worse than before [12:14] tvoss: so i think background apps should be in a higher bucket than the foreground ones [12:14] e.g. 12 is wrong for the foreground app [12:14] ogra_: sure it was 12? [12:14] e.g. the browser seems to be 0/1 [12:14] asac, i didnt touch oom, only the page value [12:15] ogra_: no... you said above that an app in foreground as a score of 12 [12:15] and background is 800 [12:15] with 16384 i can have 4 webapps and only after a while the first one dies [12:15] with 32768 the first two reliably die when i start the third one [12:15] ogra_, hang on ... opening the third webapp means that the first two are in background [12:16] yes [12:16] ogra_, but that's expected, isn't it? [12:16] xnox, hey, I tried cross-building mir just now, and cmake about boost missing, -dev:armhf are installed, though - have you seen this? [12:16] ogra_: but foreground doesnt die? [12:16] tvoss, not sure, since they are completely dead and it takes about a minute on maguro to recover [12:16] ogra_: as long as the foreground app doesnt get slower before the background is killed we are fine [12:16] (restart the app) [12:16] asac, foreground never died [12:16] ogra_, sure, but that's the other problem asac mentioned: fast startup and recovery [12:17] right. i want to ensure that the foreground app is not getting slowe before killing the backgrounds due to too scarce memory [12:17] asac, but having more apps open makes all bg apps die and they take way to long to recover when you flick through them [12:17] and then just make the recovery fast and furious [12:17] ogra_: so all get killed? [12:17] ogra_, but that's not solvable by the system in the general case [12:17] not just one? [12:17] asac, we should put apps in different buckets according to how long they have been stopped [12:18] asac, foreground was never a problam [12:18] thats not our issue [12:18] stuff randomly dieing in the bg and not recovering is [12:18] (and keeping a thumbnail and entry in the "flick list") [12:18] asac, with the value change all bg apps get killed if i start the third webapp [12:18] ogra_, not recovering is the real problem here [12:19] ogra_, dying in the background is expected behavior [12:19] tvoss: but why do we kill all? [12:19] tvoss, dieing to fast is the other imho [12:19] not one? [12:19] tvoss: maybe we need an order (e.g. 800 801 802)? [12:19] asac, we donnt set different oom values [12:19] asac, right, what I said before: the longer in background, the higher the value [12:19] so all apps with the same value *can* get killed [12:20] tvoss: but seems ogra is observing that we always kill all in background [12:20] asac, with the aggressive page setting: yes [12:20] which feels wrongish if true [12:20] tvoss: which setting is that? [12:20] asac, minfree [12:20] asac, yes, because they have the exact same value [12:20] its like a lottery which app gets killed atm [12:20] so how can we change the values so that it kills the background apps one by one [12:20] asac, if the kernel cannot get past the threshold with killing one app, it goes on and keeps on killing [12:20] we should use a counter [12:20] asac, unity has to do that [12:20] tvoss: but we start the apps... they still life [12:20] each app that gets started gets +1 more [12:21] then we start one more app and all the other get killed [12:21] ogra_, a counter is wrong, we have to sort the list of apps by time being put in background, and then assign values [12:21] otherwise we overflow [12:21] asac, ^ [12:21] and then have some intelligent mechanism to raise based on bg state [12:21] that feels odd... i would assume that kiling one or two apps should be enough unless ogra launches a super BIG app :) [12:21] asac, only three webapps atm [12:21] asac, look at the web runtime's ram requriements ;) those are big apps [12:21] tvoss: right. so we have to adjust the values like 801 802 803 [12:21] dynamically [12:21] but with the 32768 value set that tvoss proposed above [12:22] asac, right ... look at the mp's I pasted before [12:22] which makes everything more aggressive [12:22] ok fine [12:22] ogra_, right, which is too aggressive [12:22] ogra_: can you manually change a score to 802 [12:22] and see if its the only one killed [12:22] asac, it kills 12 or higher :) [12:22] then we are done and can grow the highest bucket pages [12:22] and have app folks work on it [12:22] hmm, it is hard to find the right webapp in the processlist :P [12:23] tvoss: so with your patch it will kill apps one by one starting with app longest in background? [12:23] asac, the worse part is the minute it takes to recover from being kileld though [12:24] ogra_: yes, someone from apps/sdk has to look at that [12:24] thats the bit that counts for the bad experience [12:24] feels odd that it takes a minute :) [12:24] sure [12:24] well, maguro is sloow [12:24] my guess is that that we dont leave enough cache mem [12:24] mako might be less bad ... but it still takes to long [12:24] but still 1 min is super long [12:24] and probably something obvious [12:25] and i dont see a way how we can get it to a usable speed if the app starts from zero [12:25] even on maguro [12:25] (which involved reading from disk) [12:25] asac, right, it's a series of multiple mp's to enable that [12:25] ogra_, all other platforms achieve that, though [12:25] *involves [12:25]