| ishark | 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 ? | 01:27 |
|---|---|---|
| === LarrySteeze|Away is now known as LarrySteeze | ||
| === SirCmpwn_ is now known as SirCmpwn | ||
| === duflu_ is now known as duflu | ||
| cwayne | plars, ping | 02:42 |
| plars | cwayne: hi | 02:42 |
| cwayne | looks like touch_custom hasn't been running? | 02:42 |
| plars | cwayne: let me take a look | 02:42 |
| plars | cwayne: oh, strangeness | 02:44 |
| plars | cwayne: it didn't even get to the first subjob, so there was nothing to fail | 02:44 |
| plars | cwayne: give me a moment, I should be able to kick it | 02:44 |
| plars | cwayne: ok, it's running now | 02:46 |
| cwayne | plars, great, thanks! | 02:46 |
| === 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 | ||
| Mirv | Saviq: I reopened the gsettings-qt bug, it still fails similarly with the new qtdeclarative snapshot so not sure what's up | 06:06 |
| tvoss | Saviq, good morning | 07:06 |
| tvoss | Saviq, switching unity-mir over to cmake I stumbled across http://pastebin.ubuntu.com/6719287/ | 07:11 |
| tvoss | Saviq, where do these files originate from? | 07:11 |
| timppa | Wow, haptic! :D | 07:32 |
| tvoss | timppa, weird, isn'it? :) | 08:04 |
| tvoss | Saviq, https://code.launchpad.net/~thomas-voss/unity-mir/switch-to-cmake | 08:04 |
| Saviq | tvoss, thanks | 08:04 |
| tvoss | Saviq, hang on, need to resubmit and set the prerequisite branch | 08:05 |
| Saviq | tvoss, yeah, I can see it's not MP'd | 08:05 |
| tvoss | Saviq, should be good now | 08:06 |
| Saviq | tsdgeos, we really need to stop copying the .cmake files everywhere :? | 08:13 |
| tsdgeos | Saviq: which .cmake files? | 08:13 |
| Saviq | tsdgeos, basically everything that we have in lp:unity8 in cmake/modules | 08:14 |
| tsdgeos | ah | 08:14 |
| tsdgeos | yes | 08:14 |
| Saviq | tsdgeos, maybe except Plugins.cmake and QmlTest.cmake | 08:14 |
| Saviq | but I see no reason why we shouldn't share those as well | 08:14 |
| Saviq | tsdgeos, and it was meant to be tvoss ;) | 08:14 |
| tsdgeos | that's the hard stuff :D | 08:15 |
| Saviq | tsdgeos, sorry for dragging you into this ;D | 08:15 |
| tsdgeos | ok | 08:15 |
| tvoss | Saviq, sure, I can factor that out into a common project. Do you want to block on this? | 08:15 |
| tsdgeos | fwiw in the thing "that is not called kde5" there's a module with all these kind of files | 08:15 |
| Saviq | tsdgeos, but thanks for your apt and unending support :D | 08:15 |
| Saviq | tvoss, well, it's blocked on tests for the prerequisite branch already ;) | 08:15 |
| tvoss | 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 |
| Saviq | tvoss, and yeah, that would reduce the diff by half or so, so I'd rather see that extracted first | 08:16 |
| Saviq | tvoss, yeah, why did you make it a prerequisite anyway? ;) | 08:16 |
| dholbach | good morning | 08:16 |
| Saviq | hi dholbach | 08:17 |
| dholbach | hey Saviq | 08:17 |
| tvoss | Saviq, well, the prerequisite branch pulls in some additional dependencies | 08:17 |
| tvoss | Saviq, but I can inverse that relationship | 08:17 |
| Saviq | tvoss, maybe that'd be best inded | 08:18 |
| Saviq | +e | 08:18 |
| Saviq | didrocks, 4 years today, congratz you old goat! ;D | 08:20 |
| didrocks | Saviq: ahah, thanks a lot! is it linkedin that suggested that or we have a secret calendar? ;) | 08:22 |
| didrocks | ah, just got my answer ;) | 08:22 |
| Saviq | didrocks, indeed :D | 08:22 |
| didrocks | I remember, it's that week we packaged Unity for the first time ever | 08:22 |
| didrocks | and did a respin of ubuntu with it, just a small preview | 08:23 |
| didrocks | (it was just a launcher at the time) | 08:23 |
| didrocks | sprinting in Paris | 08:23 |
| didrocks | was fun ;) | 08:23 |
| didrocks | ah, as well, it's the day Rick understood how pleasant parisian waiters can be… ;) | 08:24 |
| Saviq | :) | 08:26 |
| === zbenjamin_ is now known as zbenjamin | ||
| tvoss | Saviq, any thoughts on these two files? http://pastebin.ubuntu.com/6719287/ | 08:46 |
| Saviq | tvoss, wtym? those come from unity-api, being included as source in projects implementing those interfaces, why? | 08:47 |
| tvoss | Saviq, hmmmm, wouldn't it make more sense if unity-mir carried those interfaces? | 08:48 |
| Saviq | 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:49 |
| tvoss | Saviq, ah .. okay, I misread unity-api as unity | 08:50 |
| tvoss | Saviq, https://code.launchpad.net/~thomas-voss/unity-mir/switch-to-cmake-take-2/+merge/200967 | 09:07 |
| Saviq | tvoss, cheers, will try and get a review today | 09:09 |
| lool | cjwatson: Hey | 09:27 |
| lool | cjwatson: so it seems what was feared about qt 5 is what is happening | 09:27 |
| lool | cjwatson: that is, the proposed plan is to rename the qt5 binary package but keep the SONAME the same | 09:27 |
| lool | 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:28 |
| lool | cjwatson: do you know of other options? | 09:29 |
| lool | cjwatson: Debian #731261 has the background | 09:29 |
| ubot5 | Debian bug 731261 in release.debian.org "transition: Qt5 switching qreal == double for all platforms" [Normal,Open] http://bugs.debian.org/731261 | 09:29 |
| === Tachyon`` is now known as Tachyon` | ||
| cjwatson | lool: we could ship the .so in a private library directory and have anything that needs compatibility use LD_LIBRARY_PATH | 10:43 |
| cjwatson | a chroot would be significantly (and in my view unnecessarily) more heavyweight | 10:43 |
| seb128 | 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) | 10:59 |
| seb128 | mpt, is that right? can you update the wiki to reflect that (do you want a bug report as a reminder)? | 11:00 |
| davmor2_ | Morning all | 11:02 |
| davmor2_ | ogra_: haptic feedback but only partial which makes it weird :) | 11:02 |
| === davmor2_ is now known as davmor2 | ||
| ogra_ | oh, i havent upgraded today | 11:03 |
| davmor2 | ogra_: 119 | 11:04 |
| ogra_ | yes | 11:04 |
| davmor2 | 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:04 |
| davmor2 | should not even | 11:05 |
| ogra_ | it should still update | 11:06 |
| ogra_ | (and will revert any changes you made to the ro part) | 11:06 |
| davmor2 | ogra_: that's okay then is there a difference between rw mode and developer mode then? | 11:08 |
| ogra_ | nope | 11:08 |
| ogra_ | not to my knowledge | 11:09 |
| davmor2 | ogra_: oh okay, I don't know why I was under the impression that you couldn't updarte then | 11:09 |
| popey | ogra_: eh.. if you enable writable_image mode it does break updates | 11:11 |
| davmor2 | ogra_, popey: no it doesn't | 11:12 |
| ogra_ | popey, how so ? | 11:12 |
| popey | by updates we're talking about OTA system settings updates right? | 11:12 |
| davmor2 | popey: I upgrade to 119 | 11:12 |
| ogra_ | it still replaces the readonly images | 11:12 |
| popey | how are you updating? | 11:12 |
| davmor2 | ogra_: I still have htop installed on the phone | 11:12 |
| popey | then it didnt update | 11:13 |
| davmor2 | popey: over the air this morning | 11:13 |
| popey | ergo updates broke | 11:13 |
| ogra_ | popey, they didnt | 11:13 |
| ogra_ | if davmor2 has vibration the upgrade got applied | 11:13 |
| popey | hm | 11:13 |
| davmor2 | popey: but I got haptic feedback which I didn't have before | 11:13 |
| popey | 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 |
| davmor2 | root@ubuntu-phablet:/# system-image-cli -i | 11:14 |
| davmor2 | current build number: 119 | 11:14 |
| davmor2 | device name: maguro | 11:14 |
| davmor2 | channel: devel-proposed | 11:14 |
| davmor2 | alias: trusty-proposed | 11:14 |
| davmor2 | last update: 2014-01-09 09:17:54 | 11:14 |
| davmor2 | version version: 119 | 11:14 |
| davmor2 | version ubuntu: 20140109 | 11:14 |
| ubot5 | Error: Ubuntu bug 20140109 could not be found | 11:14 |
| popey | i rm'ed the file and restarted and then updates worked again | 11:14 |
| davmor2 | version device: 20140107.1 | 11:14 |
| ogra_ | davmor2, dpkg -l htop | 11:14 |
| ogra_ | ;) | 11:14 |
| popey | 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:14 |
| * ogra_ bets you dont have it installed ... despite the binary being there in some writable space | 11:15 | |
| davmor2 | root@ubuntu-phablet:/# dpkg -l htop | 11:15 |
| davmor2 | dpkg-query: no packages found matching htop okay weird | 11:15 |
| ogra_ | popey, making it writable will break stuff once you upgrade | 11:15 |
| ogra_ | like resetting the package db | 11:15 |
| davmor2 | ogra_: so htop runs but isn't installed what | 11:15 |
| popey | the binary is installed | 11:15 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | or for complex packages that install stuff in multiple locations i the ro area they need it will cause breakage | 11:16 |
| davmor2 | 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:22 |
| popey | or | 11:23 |
| popey | adb shell rm /userdata/.writable_image | 11:23 |
| popey | adb shell system-image-cli --build 0 | 11:23 |
| popey | do that | 11:23 |
| ogra_ | asac, tvoss ... http://paste.ubuntu.com/6720246/ | 11:37 |
| ogra_ | seems we use oom_adj on the ubuntu side but also have lowmemorykiller enabled without configuring it at all (beyond the kernel defaults) | 11:37 |
| === _salem is now known as salem_ | ||
| asac | ogra_: cool :) | 11:38 |
| tvoss | ogra_, yup, that's what I was referring to yesterday | 11:38 |
| ogra_ | i assume that might have some influence on our behavior | 11:38 |
| asac | 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 |
| asac | e.g. who will drive this in your team? | 11:38 |
| ogra_ | asac, no, thats my own little research from today :) | 11:38 |
| asac | ogra_: no discussion on yesterdays standup? hmmm | 11:39 |
| ogra_ | i'll bring it up today | 11:39 |
| tvoss | ogra_, we should start tuning minfree first, and then look into oom_adj banding | 11:39 |
| ogra_ | i mentioned it in the standup but we had no discussion | 11:39 |
| asac | ogra_: thanks. thats what folks promissed me yesterday already ... | 11:39 |
| tvoss | asac, I'm working on unity-mir right now to make this more testable | 11:40 |
| ogra_ | well, i wonder if we should touch oom_adj at all | 11:40 |
| asac | :) | 11:40 |
| tvoss | ogra_, I'm not sure either, min_free might well be enough | 11:40 |
| tvoss | ogra_, but the shell and the OomController in there has to be aware of the settings, too | 11:40 |
| asac | tvoss: from what i understand those values can be runtime tweaked without reboot? | 11:40 |
| tvoss | asac, yup | 11:40 |
| ogra_ | seems android doesnt do that ... | 11:40 |
| ogra_ | right | 11:40 |
| ogra_ | currently we force the session to -10 with the lightdm setting | 11:40 |
| tvoss | ogra_, right | 11:41 |
| ogra_ | asac, they can | 11:41 |
| ogra_ | you can just echo into the sysfs node | 11:41 |
| asac | 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 |
| asac | so that disqualifies me :P | 11:41 |
| ogra_ | sadly thats about all documentation that exists about this thing | 11:42 |
| asac | but guess its not that simple as we have to fix bugs in unity and elsewhere alongside | 11:42 |
| ogra_ | at least i cant find anything | 11:42 |
| tvoss | ogra_, the android java source code provides some insight, too | 11:42 |
| asac | as this was never really finished | 11:42 |
| ogra_ | yeah | 11:42 |
| ogra_ | but we'll need it for release | 11:42 |
| asac | for sure | 11:42 |
| asac | 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 |
| ogra_ | that will make app switching really slow i suppose | 11:43 |
| asac | in this way we probably can work on fixing sdk/apps etc. while we somehow figure those memory pressure thresholds | 11:43 |
| ogra_ | as long as we have ram we should make use of it | 11:44 |
| tvoss | asac, I think we hide more issues than we solve with that | 11:44 |
| ogra_ | sending sigstop has influence on latency | 11:44 |
| asac | well, we can bake the app logic independent from the memopry pressyure thing | 11:44 |
| asac | i wouldnt change it in the build | 11:44 |
| tvoss | asac, so you want to force baking app logic by always killing them? | 11:44 |
| tvoss | asac, or make it easily reproducible by devs? | 11:45 |
| asac | baking app serialize/restore logic | 11:45 |
| asac | make it easy to set such a mode | 11:45 |
| asac | not by default of course | 11:45 |
| tvoss | asac, I will take a look, but as a last resort, apps can be manually killed from the lens | 11:45 |
| asac | 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 |
| asac | on top we have to ensure that killing and bringing back to life works | 11:45 |
| tvoss | asac, sure | 11:45 |
| tvoss | asac, and I agree that both are to a certain degree independent | 11:46 |
| asac | yeah. just thinking out louad that we could already give a reproducible problem to app folks | 11:46 |
| asac | while we figure the rest | 11:46 |
| tvoss | asac, yup, we should hand over that information to the apps team and to the core apps devs | 11:46 |
| ogra_ | we need to find the right compromise imho | 11:46 |
| tvoss | ogra_, sure, but that's only one part of the task as asac pointed out | 11:46 |
| ogra_ | yeah | 11:47 |
| asac | tvoss: so what are the values you said need tweaking? | 11:49 |
| tvoss | hmm, I assume that the pagesize on arm is 4kb? | 11:49 |
| tvoss | asac, the min_free values in /sys/module/lowmemorykiller/parameters/minfree | 11:49 |
| tvoss | asac, they represent thresholds of memory that are available and android oom killer kicks in if a threshold is reached | 11:50 |
| asac | tvoss: what values do we have? | 11:51 |
| tvoss | asac, 1536,2048,4096,16384 | 11:51 |
| tvoss | in [# pages] | 11:51 |
| asac | ogra posted: http://paste.ubuntu.com/6720246/ | 11:51 |
| asac | tvoss: so 64M? | 11:52 |
| asac | do our apps have oom_adj 12? | 11:52 |
| tvoss | asac, the latter I'm checking right now | 11:52 |
| tvoss | asac, I don't think so | 11:52 |
| asac | tvoss: how can i see that value? | 11:53 |
| asac | ah nevermind | 11:54 |
| tvoss | asac, for a given process, you can just cat /proc/pid/oom_adj | 11:54 |
| asac | found it in /proc | 11:54 |
| tvoss | yup | 11:54 |
| ogra_ | asac, all of the session should inherit from the lightdm.conf value | 11:54 |
| asac | and where is that set? | 11:54 |
| asac | do we do that in upstart? | 11:54 |
| ogra_ | yes | 11:54 |
| ogra_ | see the last line of my paste | 11:54 |
| asac | so child pids get the same as parents by default? | 11:55 |
| tvoss | asac, yup | 11:55 |
| ogra_ | forked child processes do | 11:55 |
| asac | ogra_: do you have an app running? do you get -10 for that? | 11:55 |
| tvoss | asac, ogra_ be careful: lightdm sets oom_score_adj, which is _not_ oom_adj | 11:55 |
| asac | hmm | 11:55 |
| asac | ogra_: so what value do you get in /proc/$PID/ooem_adj ? | 11:55 |
| asac | for an app | 11:55 |
| tvoss | oom_adj is actually deprecated, oom_score_adj has got -1000 -> 1000 | 11:56 |
| ogra_ | (now the question is if everything is a fork here) | 11:56 |
| asac | 10000? | 11:56 |
| ogra_ | root@ubuntu-phablet:/# cat /proc/$(pidof unity8)/oom_adj | 11:56 |
| ogra_ | 0 | 11:56 |
| asac | ogra_: right. what about an app? | 11:56 |
| ogra_ | so that seems wrong | 11:56 |
| tvoss | ogra_, you need to cat oom_score_adj | 11:56 |
| tvoss | ogra_, nope, that's most likely correct | 11:56 |
| ogra_ | tvoss, ah, thanks | 11:56 |
| ogra_ | thats indeed -10 | 11:57 |
| ogra_ | lets see an app | 11:57 |
| ogra_ | root@ubuntu-phablet:/# cat /proc/2346/oom_score_adj | 11:57 |
| ogra_ | 1 | 11:57 |
| ogra_ | thats the file manager | 11:57 |
| ogra_ | thats correct too (apps should be higher than unity) | 11:58 |
| ogra_ | but what does the lowmemorykiller make out of that ? | 11:59 |
| tvoss | ogra_, can you please cat oom_adj for the file manager? | 11:59 |
| ogra_ | 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 |
| ogra_ | tvoss, 12 | 12:00 |
| === pete-woods is now known as pete-woods|fight | ||
| === pete-woods|fight is now known as pete-woods|away | ||
| tvoss | ogra_, that's weird, it shouldn't have that value | 12:01 |
| tvoss | ogra_, oom_score_adj is scaled linearly to oom_adj | 12:02 |
| asac | ogra_: right. but i wanted to get an owner and see progress now, not end of month | 12:02 |
| ogra_ | tvoss, well | 12:02 |
| ogra_ | root@ubuntu-phablet:/# cat /sys/module/lowmemorykiller/parameters/adj | 12:02 |
| ogra_ | 0,1,6,12 | 12:02 |
| tvoss | ogra_, that's the setup, not the actual values | 12:02 |
| ogra_ | there is 12 in the lowmemorykiller ... i guess that gets applied by default when an app starts | 12:02 |
| tvoss | ogra_, I would be surprised if that was the case, let me add some debug output | 12:03 |
| asac | tvoss: where are the actual values? | 12:03 |
| tvoss | asac, of the individual processes? in /proc/pid/oom_adj and /proc/pid/oom_score_adj | 12:03 |
| asac | so its 1 for apps. interesting | 12:04 |
| tvoss | asac, oom_score_adj is 1 for apps, we have to look at oom_adj | 12:04 |
| ogra_ | and thats 12 | 12:05 |
| asac | k | 12:05 |
| tvoss | ogra_, and that I don't understand | 12:05 |
| asac | so this means we should see apps getting killed if less than 65m is available, correct? | 12:05 |
| tvoss | asac, correct | 12:05 |
| tvoss | ogra_, oom_score_adj is scaled from -1000 to 1000 | 12:05 |
| asac | are we able to observe/confirm that? | 12:05 |
| tvoss | asac, from what ogra described yesterday: yes | 12:05 |
| asac | so maybe changet that to something big (e.g. 150M) and see if at least the slowness goes away | 12:06 |
| tvoss | ogra_, I saw a pastebin of the andorid oom killer kicking in yesterday, do you have that handy? | 12:06 |
| ogra_ | tvoss, aha ... webapps have totally different values | 12:06 |
| tvoss | ogra_, yup, most likely because they are a process tree | 12:06 |
| tvoss | ogra_, working on that, too | 12:06 |
| ogra_ | http://paste.ubuntu.com/6720377/ | 12:06 |
| asac | ogra_: what do webapps have? | 12:07 |
| asac | yeah | 12:07 |
| asac | bump that | 12:07 |
| ogra_ | 0 and 1 | 12:07 |
| asac | i believe they should be 15 | 12:07 |
| asac | and 150M for 15 | 12:07 |
| asac | hehe | 12:07 |
| asac | tvoss: isnt unity supposed to change the adj value if the app is in foreground? | 12:07 |
| ogra_ | well, it should be the same as native apps | 12:07 |
| ogra_ | which is 12 currently | 12:07 |
| asac | or how do we ensure that we dont kill foreground? | 12:08 |
| tvoss | asac, sure | 12:08 |
| asac | ogra_: is the webapp in the background? | 12:08 |
| ogra_ | no | 12:08 |
| tvoss | asac, ogra_ https://code.launchpad.net/~thomas-voss/unity-mir/refactor-oom-score-adj-to-rely-on-process-cpp | 12:08 |
| asac | ogra_: can you confirm that the value changes if you put it in background/foreground? | 12:08 |
| tvoss | asac, ogra_ https://code.launchpad.net/~thomas-voss/unity-mir/refactor-process-group-operations-to-rely-on-process-cpp | 12:08 |
| ogra_ | root@ubuntu-phablet:/# cat /proc/2421/oom_score_adj | 12:08 |
| ogra_ | 800 | 12:08 |
| ogra_ | thats in the background | 12:08 |
| asac | right | 12:08 |
| tvoss | that makes sense | 12:08 |
| asac | so change the 12 value to 150M | 12:08 |
| asac | instead of 64M | 12:08 |
| asac | and see if slowness goes away | 12:09 |
| asac | thats what i would try :_) | 12:09 |
| tvoss | right, let's scale up the biggest bucket and see what happens | 12:09 |
| ogra_ | filemanager gets 800 too in bg | 12:09 |
| asac | apps shouldnt be 12 inn foreground i guess | 12:09 |
| asac | tvoss: maybe add another bucket 100? | 12:09 |
| tvoss | asac, I would first scale up the 12-bucket to 32768 | 12:10 |
| tvoss | asac, pages, that is | 12:10 |
| asac | tvoss: but that will apply to foreground apps :) | 12:10 |
| asac | too | 12:10 |
| asac | afaics | 12:11 |
| ogra_ | +12 vs -12 ? | 12:11 |
| ogra_ | :) | 12:11 |
| asac | tvoss: how does this killer operate? does it always first the ones in a higher bucket first? | 12:12 |
| asac | or is it randomly killing all that are beyond threshold regardless of the score? | 12:12 |
| tvoss | 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 |
| ogra_ | tvoss, ok, using 32768 now ... opening the third webapp kills the first two that are open | 12:13 |
| ogra_ | thats worse than before | 12:14 |
| asac | tvoss: so i think background apps should be in a higher bucket than the foreground ones | 12:14 |
| asac | e.g. 12 is wrong for the foreground app | 12:14 |
| asac | ogra_: sure it was 12? | 12:14 |
| asac | e.g. the browser seems to be 0/1 | 12:14 |
| ogra_ | asac, i didnt touch oom, only the page value | 12:14 |
| asac | ogra_: no... you said above that an app in foreground as a score of 12 | 12:15 |
| asac | and background is 800 | 12:15 |
| ogra_ | with 16384 i can have 4 webapps and only after a while the first one dies | 12:15 |
| ogra_ | with 32768 the first two reliably die when i start the third one | 12:15 |
| tvoss | ogra_, hang on ... opening the third webapp means that the first two are in background | 12:15 |
| ogra_ | yes | 12:16 |
| tvoss | ogra_, but that's expected, isn't it? | 12:16 |
| Saviq | 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 |
| asac | ogra_: but foreground doesnt die? | 12:16 |
| ogra_ | tvoss, not sure, since they are completely dead and it takes about a minute on maguro to recover | 12:16 |
| asac | ogra_: as long as the foreground app doesnt get slower before the background is killed we are fine | 12:16 |
| ogra_ | (restart the app) | 12:16 |
| ogra_ | asac, foreground never died | 12:16 |
| tvoss | ogra_, sure, but that's the other problem asac mentioned: fast startup and recovery | 12:16 |
| asac | right. i want to ensure that the foreground app is not getting slowe before killing the backgrounds due to too scarce memory | 12:17 |
| ogra_ | 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 |
| asac | and then just make the recovery fast and furious | 12:17 |
| asac | ogra_: so all get killed? | 12:17 |
| tvoss | ogra_, but that's not solvable by the system in the general case | 12:17 |
| asac | not just one? | 12:17 |
| tvoss | asac, we should put apps in different buckets according to how long they have been stopped | 12:17 |
| ogra_ | asac, foreground was never a problam | 12:18 |
| ogra_ | thats not our issue | 12:18 |
| ogra_ | stuff randomly dieing in the bg and not recovering is | 12:18 |
| ogra_ | (and keeping a thumbnail and entry in the "flick list") | 12:18 |
| ogra_ | asac, with the value change all bg apps get killed if i start the third webapp | 12:18 |
| tvoss | ogra_, not recovering is the real problem here | 12:18 |
| tvoss | ogra_, dying in the background is expected behavior | 12:19 |
| asac | tvoss: but why do we kill all? | 12:19 |
| ogra_ | tvoss, dieing to fast is the other imho | 12:19 |
| asac | not one? | 12:19 |
| asac | tvoss: maybe we need an order (e.g. 800 801 802)? | 12:19 |
| ogra_ | asac, we donnt set different oom values | 12:19 |
| tvoss | asac, right, what I said before: the longer in background, the higher the value | 12:19 |
| ogra_ | so all apps with the same value *can* get killed | 12:19 |
| asac | tvoss: but seems ogra is observing that we always kill all in background | 12:20 |
| tvoss | asac, with the aggressive page setting: yes | 12:20 |
| asac | which feels wrongish if true | 12:20 |
| asac | tvoss: which setting is that? | 12:20 |
| tvoss | asac, minfree | 12:20 |
| ogra_ | asac, yes, because they have the exact same value | 12:20 |
| ogra_ | its like a lottery which app gets killed atm | 12:20 |
| asac | so how can we change the values so that it kills the background apps one by one | 12:20 |
| tvoss | asac, if the kernel cannot get past the threshold with killing one app, it goes on and keeps on killing | 12:20 |
| ogra_ | we should use a counter | 12:20 |
| tvoss | asac, unity has to do that | 12:20 |
| asac | tvoss: but we start the apps... they still life | 12:20 |
| ogra_ | each app that gets started gets +1 more | 12:20 |
| asac | then we start one more app and all the other get killed | 12:21 |
| tvoss | 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 |
| tvoss | otherwise we overflow | 12:21 |
| tvoss | asac, ^ | 12:21 |
| ogra_ | and then have some intelligent mechanism to raise based on bg state | 12:21 |
| asac | that feels odd... i would assume that kiling one or two apps should be enough unless ogra launches a super BIG app :) | 12:21 |
| ogra_ | asac, only three webapps atm | 12:21 |
| tvoss | asac, look at the web runtime's ram requriements ;) those are big apps | 12:21 |
| asac | tvoss: right. so we have to adjust the values like 801 802 803 | 12:21 |
| asac | dynamically | 12:21 |
| ogra_ | but with the 32768 value set that tvoss proposed above | 12:21 |
| tvoss | asac, right ... look at the mp's I pasted before | 12:22 |
| ogra_ | which makes everything more aggressive | 12:22 |
| asac | ok fine | 12:22 |
| tvoss | ogra_, right, which is too aggressive | 12:22 |
| asac | ogra_: can you manually change a score to 802 | 12:22 |
| asac | and see if its the only one killed | 12:22 |
| tvoss | asac, it kills 12 or higher :) | 12:22 |
| asac | then we are done and can grow the highest bucket pages | 12:22 |
| asac | and have app folks work on it | 12:22 |
| ogra_ | hmm, it is hard to find the right webapp in the processlist :P | 12:22 |
| asac | tvoss: so with your patch it will kill apps one by one starting with app longest in background? | 12:23 |
| ogra_ | asac, the worse part is the minute it takes to recover from being kileld though | 12:23 |
| asac | ogra_: yes, someone from apps/sdk has to look at that | 12:24 |
| ogra_ | thats the bit that counts for the bad experience | 12:24 |
| asac | feels odd that it takes a minute :) | 12:24 |
| asac | sure | 12:24 |
| ogra_ | well, maguro is sloow | 12:24 |
| asac | my guess is that that we dont leave enough cache mem | 12:24 |
| ogra_ | mako might be less bad ... but it still takes to long | 12:24 |
| asac | but still 1 min is super long | 12:24 |
| asac | and probably something obvious | 12:24 |
| ogra_ | and i dont see a way how we can get it to a usable speed if the app starts from zero | 12:25 |
| asac | even on maguro | 12:25 |
| ogra_ | (which involved reading from disk) | 12:25 |
| tvoss | asac, right, it's a series of multiple mp's to enable that | 12:25 |
| tvoss | ogra_, all other platforms achieve that, though | 12:25 |
| ogra_ | *involves | 12:25 |
| asac | lets not worry too much | 12:25 |
| tvoss | ogra_, and they serialize state to disk, not complete memory snapshots | 12:25 |
| tvoss | asac, correct | 12:25 |
| ogra_ | tvoss, do others actually wipe the app from ram completely ? | 12:26 |
| ogra_ | so that it needs to start from disk again ... at zero | 12:26 |
| tvoss | ogra_, sure, iOS is really aggressive in doing that. Their lifecycle is strict, too | 12:26 |
| tvoss | ogra_, and android does it, too | 12:26 |
| ogra_ | then they must have a really fast filesystem or something | 12:26 |
| asac | 1min is obviously bogus | 12:26 |
| asac | and sommething obvious is buggy there | 12:26 |
| asac | like a big sleep | 12:26 |
| asac | or something | 12:26 |
| asac | it doesnt take 1min to start the app for first time | 12:26 |
| asac | either | 12:26 |
| asac | (i hope :)) | 12:26 |
| tvoss | ogra_, they just are clever about the resurrection | 12:26 |
| asac | lets write instructionms how to reproduce the kill/restart behaviour | 12:26 |
| asac | and send a mail so that app/sdk folks can jump on this | 12:26 |
| ogra_ | or cache it somewhere so that you can speedier re-start than start | 12:27 |
| ogra_ | asac, it nearly does take 1min here with i.e. the n-tv webapp | 12:27 |
| asac | well. if we leave more cache available in mem by increasing the highest bucket like tvoss suggested | 12:27 |
| ogra_ | asac, it sits quite long on a white screen | 12:27 |
| asac | we probably might keep the binaries/code in mem and it will be faster | 12:27 |
| ogra_ | (on maguro that is) | 12:27 |
| asac | anyway. someone has to look where we loose the time .everthing else is just guessing | 12:27 |
| tvoss | asac, let's not get ahead of ourselves here | 12:27 |
| ogra_ | asac, there is research going on about app startup slowness in general ... that will surely help | 12:28 |
| ogra_ | but i think that wont be enough | 12:28 |
| tvoss | ogra_, for webapps, it's special though | 12:28 |
| ogra_ | sure | 12:29 |
| tvoss | ogra_, as it is multi-process: we surely could just display the UI even though the rendering process is not finished loading, yet | 12:29 |
| ogra_ | still, the apps are not in sync with the flicking gesture | 12:29 |
| asac | tvoss: is there a command that we could give to app devs to kill/resume apps? | 12:30 |
| tvoss | ogra_, well, maguro is not the best test bed for that | 12:30 |
| asac | i think that would help a lot ... just tell them to run that and make that fast as a first step | 12:30 |
| asac | fast/robust | 12:30 |
| tvoss | asac, I would propose to use the apps lense | 12:30 |
| ogra_ | and i dont see a way how we can get it fast enough to not behave badly (showing a white screen, or only the fade out animation for a while until the app started again) | 12:30 |
| asac | how? | 12:30 |
| tvoss | asac, long press on app, hit red small button | 12:30 |
| asac | tvoss: that quits the app | 12:30 |
| tvoss | asac, yup | 12:31 |
| asac | is that really the same? | 12:31 |
| tvoss | asac, it kills the app | 12:31 |
| asac | as in "identical codepath/behavioyur"? | 12:31 |
| asac | tvoss: but closing app doesnt serialize, does it? | 12:31 |
| ogra_ | tvoss, yeah | 12:31 |
| ogra_ | tvoss, something like the compizs "greyed out" thing | 12:31 |
| ogra_ | keep the thumbnail around even if the app is dead etc | 12:31 |
| ogra_ | show it greyed in the UI until the app is actually there to replace it again | 12:31 |
| tvoss | asac, I have to check | 12:31 |
| tvoss | ogra_, sure, that's the sort of cleverness we need to implement | 12:31 |
| ogra_ | well, its not cleverness | 12:32 |
| asac | i really think if we had a command that juust triggers the real code path for killing etc. it would be much easier to get traction | 12:32 |
| ogra_ | its a hack ... | 12:32 |
| ogra_ | like progressbars are ;) | 12:32 |
| asac | also easier to maybe integrate/automate in utah | 12:32 |
| asac | like a test that kills/resume the app etc. | 12:32 |
| ogra_ | but it will fix the user impatience | 12:32 |
| tvoss | ogra_, I wouldn't call that a hack ... but anyway | 12:33 |
| asac | well, thats what we do. we need to be as fast as possible and also lie a bit on UI side to not show whitescreen | 12:33 |
| ogra_ | tvoss, well, like rogressbars are hacks :) | 12:33 |
| ogra_ | to fill a time gap | 12:33 |
| asac | ogra_: its a valid UI mean to provide user feedback on longer running activities | 12:33 |
| tvoss | ogra_, what would be the solution? zero-time-data transfer ... unlikely to happen this century | 12:34 |
| tvoss | asac, @script: I will see what we can do | 12:34 |
| tvoss | asac, as an intermediate step: killing from the lens at least forces a clean restart | 12:34 |
| ogra_ | asac, its a UI hack to work around infrastructural slowness (with a 1TB internet connection you wont need progressbars) | 12:34 |
| tvoss | asac, if that is fast enough, resurrection with state should be faster, too | 12:34 |
| tvoss | ogra_, how do you deal with imperfect infrastructure then? if you don't want to hack something? | 12:35 |
| ogra_ | tvoss, indeed, its not a bad hack ... but after all its a hack to calm the user ;) | 12:36 |
| ogra_ | asac, longer running activities are infrastuctural bugs that hardware will fix at some point in time ;) | 12:36 |
| tvoss | ogra_, okay, with that argument: a whitescreen is fine for you ;) | 12:36 |
| tvoss | ogra_, just wait for faster hw ;) | 12:37 |
| ogra_ | tvoss, i dont say hacks are bad (look at my code :P ) | 12:37 |
| ogra_ | and progrressbars are sadly still a requirement to work around todays world ... that doesnt make them less of a hack imho :) | 12:37 |
| xnox | Saviq: let me try here, and check what's going on. | 12:38 |
| ogra_ | anyway, lets do something compiz like or similar for covering the delay the restart of the app takes | 12:38 |
| Saviq | xnox, I had to export BOOST_LIBRARYDIR, and set PKG_CONFIG_EXECUTABLE | 12:38 |
| Saviq | xnox, and that's as far as I've got... it has some funky use of the PkgConfig module :/ | 12:38 |
| davmor2 | tvoss: should haptic be on for the keyboard too? currently only seems to work on button presses for the scopes and in odd places in apps | 12:39 |
| xnox | Saviq: argh, yeah, that should not be necessary =( | 12:39 |
| tvoss | davmor2, you would have to check with the keyboard guys | 12:39 |
| ogra_ | davmor2, that most likely requires a kbd upload which didnt happen since yesterday | 12:39 |
| tvoss | davmor2, the qtubuntu sensors package only exposes the plugin | 12:39 |
| ogra_ | (even if there is code it wouldnt have landed yet) | 12:39 |
| xnox | Saviq: so a bug in cmake stuff probably, will look into fixing it. Mir did cross-compile with no packaging changes. | 12:39 |
| Saviq | xnox, ok thanks - I wonder if something changed in mir recently, too | 12:40 |
| xnox | Saviq: i'll work it out. | 12:40 |
| davmor2 | ogra_, tvoss: thanks seems odd that the haptic is everywhere but where you expect it to be :) but it does make it feel nicer :) | 12:40 |
| Saviq | xnox, do you know how long it should take for -dbgsym packages to reach ddebs.u.c? | 12:40 |
| Saviq | xnox, https://launchpad.net/ubuntu/+source/mir/0.1.3+14.04.20140108-0ubuntu1 got built 20h ago and the -dbgsym are still not there on ddebs | 12:41 |
| xnox | Saviq: as I far as I understand, it should be roughly same time as they hit archive.ubuntu.com. But check with pitti, he knows that system better. | 12:41 |
| Saviq | xnox, thanks, will do | 12:41 |
| ogra_ | tvoss, can we have different vibration for different things ? seems it is the same length etc for everything atm | 12:42 |
| ogra_ | tvoss, i would expect a keystroke on the kbd to give me a different (shorter) vibration than ... say... clicking an icon in the dash | 12:42 |
| === chihchun_afk is now known as chihchun | ||
| tvoss | ogra_, the plugin supports different vibration length .. so might be that some values need to be tuned | 12:46 |
| ogra_ | cool | 12:47 |
| ogra_ | as long that the low level is capable the rest is polish ... | 12:47 |
| === chihchun is now known as chihchun_afk | ||
| davmor2 | ogra_, tvoss: also I don't expected the power of the vibrations to be the same currently it feels like it is full on but that might be down to timing again | 12:47 |
| tvoss | davmor2, sure, let's see | 12:48 |
| lool | cjwatson: oh yeah, the directory with alternate libs is what I had in mind, not a full debootstrap or anything | 12:48 |
| lool | also needs to support dlopen and such though | 12:48 |
| lool | cjwatson: so do we want to fight the ABI compatibility battle on qt 5? I will check with slangasek too as he commented on the Debian transition, but it seems fairly intrusive, impacting a lot of packages | 12:49 |
| lool | cjwatson: the other question is what changes in click would be necessary | 12:49 |
| Saviq | pitti, hey, any idea why -dbgsyms for https://launchpad.net/ubuntu/+source/mir/0.1.3+14.04.20140108-0ubuntu1 didn't reach ddebs.u.c yet? | 12:50 |
| cjwatson | lool: I think slangasek is probably right, all things considered - change package name but not soname | 12:50 |
| cjwatson | lool: click shouldn't need to be changed, but the app launch code might | 12:50 |
| cjwatson | lool: is dlopen really an issue in practice? | 12:50 |
| cjwatson | for click packages? | 12:50 |
| lool | cjwatson: for qt modules | 12:51 |
| lool | cjwatson: qml modules and qt plugins | 12:51 |
| cjwatson | right | 12:51 |
| cjwatson | it's not trivial but I think it's tractable | 12:51 |
| lool | Hmm I guess I should setup something with SDK team to discuss | 12:52 |
| lool | Mirv: ^ | 12:52 |
| lool | to agree on launch code, directory layout for apps that want to support multiple runtimes and such | 12:53 |
| === pete-woods|away is now known as pete-woods | ||
| Saviq | mardy, somewhat hoping you're caring for the family and are not around, but: apparently my telepathy accounts are not "understood" by online-accounts any more (there's no icons, I can't seem to change the details, or add a new jabber account) | 13:06 |
| Saviq | mardy, any idea what might've caused that? | 13:07 |
| mardy | Saviq: babies are sleeping :-) | 13:07 |
| mardy | Saviq: you are talking about the desktop, right? | 13:07 |
| Saviq | mardy, yes | 13:07 |
| mardy | Saviq: it looks like the corresponding account-plugin-* package has been removed | 13:08 |
| mardy | Saviq: we should handle that more gracefully, agreed :-) | 13:08 |
| Saviq | mardy, what's the package name? | 13:08 |
| Saviq | ah, got them! | 13:09 |
| mardy | Saviq: every protocol has its own plugin. The one for jabber is account-plugin-jabber | 13:09 |
| Saviq | mardy, is there a meta-package that pulls it in (Recommends?)? | 13:10 |
| mpt | seb128, done. <https://wiki.ubuntu.com/AboutThisDevice?action=diff&rev2=19&rev1=18> | 13:10 |
| seb128 | mpt, thanks | 13:10 |
| mardy | Saviq: apt-cache rdepends account-plugin-jabber | 13:11 |
| mardy | Saviq: the Online Accounts plugin for telepathy-mission-controls pulls that in | 13:11 |
| nik90 | tvoss: ping | 13:11 |
| tvoss | nik90, pong | 13:11 |
| mardy | Saviq: but I didn't walk the dependency chain further :-) | 13:11 |
| Saviq | mardy, thanks, it's looking better already :) | 13:12 |
| nik90 | tvoss: I was told by popey that I should talk to you about waking/unlock the device when an alarm snap decision pops up. | 13:12 |
| nik90 | tvoss: the snap decision part is currently being worked, but that should only provide the notification part. | 13:13 |
| nik90 | tvoss: what would it take to add support to ensure that the device is unlocked/woken up when the notification is trigered? | 13:13 |
| tvoss | nik90, you mean from deep sleep? | 13:13 |
| nik90 | tvoss: if you mean deep sleep as the state when a user locks the phone then yes | 13:14 |
| tvoss | nik90, well, I meant even deeper :) but for the locked state: I would need to check back with design on that. On my list | 13:14 |
| === zequence_ is now known as zequence | ||
| nik90 | tvoss: my requirement would be quite similar to the use call of a user receiving a phone call. | 13:15 |
| nik90 | use case* | 13:15 |
| tvoss | nik90, right, understood. Both should use the same infrastructure. But just to make sure: It won't be the clock app triggering the snap decision | 13:16 |
| tvoss | nik90, but the alarm service doing that, correct? | 13:17 |
| nik90 | tvoss: that's correct. the alarm service (indicator date-time) is the one triggering the notification and not the clock app. | 13:17 |
| === alan_g is now known as alan_g|lunch | ||
| tvoss | nik90, okay, cool then. As I said: on my list, will come back to you asap | 13:18 |
| nik90 | tvoss: In that case, I will update my email regarding the alarms work items to keep track of this. Thnx | 13:19 |
| tvoss | nik90, yup, thank you | 13:20 |
| Mirv | lool: yes, bzoltan1 would definitely want to be part of the discussions | 13:20 |
| bzoltan1 | I am all here | 13:22 |
| lool | bzoltan1: this is about providing backwards compat with the apps | 13:23 |
| bzoltan1 | lool, cjwatson: we had a long discussion with Mirv about the 5.2 -5.0 Qt co-installation | 13:23 |
| bzoltan1 | lool: I am familiar with the topic | 13:23 |
| lool | seems we've lost the battle of backwards compat of qt 5; should have changed the SONAME or not break the ABI | 13:23 |
| lool | but it seems too late now | 13:23 |
| lool | so we need to plan for an alternative approach | 13:23 |
| lool | Mirv: Perhaps one thing you want to explore on the qt5 packaging front is how to provide an old-ABI qt 5 biuld | 13:24 |
| lool | Mirv: do you want to base it of qt 5.2? as a separate source package? or on top of qt 5.0 with a separate source package? | 13:24 |
| bzoltan1 | lool: What is important to understand is that creating co-installable Qt 5.0 and 5.2 on a known distro way would be a lengthy and expensive task.. Not impossible, but I would estimate it about 2-3 months work of a full time packaging/Qt expert | 13:26 |
| Mirv | lool: the problem is right now I'd like some 3rd party to look at that, since this Qt 5.2 trusty rebuilds alone are taking all my time (+ landing integration). if we'd really want old ABI also on trusty, I don't know how to do that without renaming all Qt packages and their conents and then a separate source packages * 20 for Qt 5.0 | 13:26 |
| Mirv | or then the completely different approaches of supporting old ABI aside from doing full system level packaging changes | 13:26 |
| Mirv | so in Debian there was now a single binary package rename which helps in this transition to Qt 5.2, but it does not help in co-installing different minor versions of Qt 5 | 13:27 |
| seeks | hey guys | 13:32 |
| === dandrader is now known as dandrader|afk | ||
| seeks | I have a problem, I try to restore android after failed ubuntu install so I want to restore my BACKUP with 'adb restore backup.ab' but I can unlock my device since I can't even boot it anymore. Any fix? | 13:35 |
| sergiusens | seeks, go to fastboot; run the factory reset script (get the factory image first and extract it); boot android; restore the backup once developer mode is reenabled | 13:36 |
| sergiusens | seeks, https://developers.google.com/android/nexus/images | 13:37 |
| seeks | thanks but I can't initiate fastboot | 13:38 |
| sergiusens | seeks, how so? | 13:39 |
| seeks | during the ubuntu install after asking me ''ROM may flash stock recovery on boot fix?' I chose no then it restarted with the google sign and since there is only the battery and it doesnt react to anything, can see id in adb devices though | 13:40 |
| seeks | I would like to try ubuntu anyway but since I can't boot I guess it is not going to work now | 13:40 |
| sergiusens | seeks, powerof, then power + vol up + vol down | 13:40 |
| seeks | ok | 13:40 |
| sergiusens | seeks, what device? | 13:40 |
| seeks | galaxy nexus | 13:41 |
| ogra_ | yeah | 13:41 |
| ogra_ | maguro needs battery remmoval | 13:42 |
| ogra_ | you need to pull it out and then boot without cable attached | 13:42 |
| ogra_ | else it goes into a weird "i'm still charging, la la la" state | 13:42 |
| seeks | ok it's stuck I guess, no powering doen only the battery sign charging even when not plugged in | 13:42 |
| seeks | ok NVM | 13:42 |
| seeks | I"ll do it now | 13:42 |
| pitti | http://ddebs.ubuntu.com/pool/main/m/mir/ | 13:43 |
| pitti | Saviq: they are here ^ | 13:43 |
| seeks | lol after battery removal and reboot Ubuntu is working | 13:44 |
| seeks | thx xxd | 13:44 |
| ogra_ | heh | 13:44 |
| Saviq | pitti, hmm not in http://ddebs.ubuntu.com/dists/trusty/main/binary-armhf/Packages for some reason? | 13:44 |
| pitti | Saviq: if they were only copied a few hours ago, index generation might not have caught up yet | 13:44 |
| pitti | hm, 22 hours ago | 13:45 |
| Saviq | pitti, yeah | 13:45 |
| pitti | Saviq: err, I do see them in that index | 13:47 |
| pitti | Package: libmirplatform-dbgsym | 13:47 |
| pitti | Version: 0.1.3+14.04.20140108-0ubuntu1 | 13:47 |
| Saviq | pitti, libmirserver12-dbgsym, though? | 13:47 |
| pitti | libmirserver12 | 0.1.3+14.04.20140108-0ubuntu1 | trusty/universe | amd64, armhf, i386 | 13:48 |
| pitti | it's in universe, whoever binNEWed it put it into the wrong component | 13:48 |
| pitti | and somehow there's no dbgsym for it | 13:49 |
| pitti | I mean, it's in http://ddebs.ubuntu.com/pool/main/m/mir/, not in /universe | 13:49 |
| * pitti fixes the component | 13:49 | |
| pitti | Saviq: ^ done; should catch up in a few hours; until then, grab the ddeb manually | 13:50 |
| === dandrader|afk is now known as dandrader | ||
| pitti | http://ddebs.ubuntu.com/pool/main/m/mir/libmirserver12-dbgsym_0.1.3+14.04.20140108-0ubuntu1_armhf.ddeb | 13:50 |
| Saviq | pitti, yeah, should've checked there before | 13:50 |
| Saviq | pitti, thanks | 13:50 |
| pitti | Saviq: it's even on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt | 13:51 |
| Saviq | pitti, anything to be done for that to not happen next time? | 13:52 |
| pitti | Saviq: usually archive admins fix the mismatches every now and then | 13:52 |
| pitti | Saviq: I suppose it wasn't actually binNEWed manually, as the copying from the PPA circumvents that | 13:53 |
| pitti | so, it could/should be fixed in that machinery | 13:53 |
| Saviq | pitti, ok, will just notify the landing team to make sure they're aware, then | 13:53 |
| Saviq | didrocks, Mirv ↑↑ | 13:53 |
| didrocks | pitti: yeah, binary copy is copying to universe | 13:55 |
| didrocks | pitti: and even if promoted in the proposed pocket, it's demoted in the release pcoket | 13:55 |
| didrocks | pocket* | 13:55 |
| didrocks | not due to cu2d unfortunately… | 13:55 |
| asac | lool: bzoltan1: so what will we do now about qt? | 13:59 |
| asac | can you give me a summary of what the agreed course of action is? | 14:00 |
| seb128 | how many packages do we have in the app store using compiled code that would be impacted by the ABI change? | 14:00 |
| seb128 | can't we just rebuild/migrate those automatically? | 14:00 |
| ogra_ | seb128, we dont build them, devs upload binary clicks to the store | 14:02 |
| seb128 | how many of those have compiled code? | 14:03 |
| seb128 | the ABI change probably doesn't impact on pure qml right? | 14:03 |
| asac | lool: bzoltan1: so first i think this was a mistake on our side to even ship it as float last release | 14:03 |
| asac | it was known that they wanted to fix this to be a double | 14:03 |
| ogra_ | seb128, popey or boiko might know ... | 14:03 |
| asac | with that, i believe we have to stay on float | 14:04 |
| ogra_ | err beuno ... sorry boiko | 14:04 |
| asac | unless we want to learn how to distribute two point releases of QT on our images | 14:04 |
| popey | ogra_: i dont | 14:04 |
| bzoltan1 | asac: what do you mean by float? | 14:04 |
| ogra_ | asac, that will break stuff like skype on the desktop | 14:04 |
| asac | ogra_: yeah. we wouldnt use the same name | 14:04 |
| davmor2 | when does the agps stuff land losing 15 minutes for an initial gps connection is losing it's charm now :) | 14:04 |
| beuno | what what? | 14:04 |
| asac | bzoltan1: qreal == double in the new world | 14:05 |
| asac | in old world it was float on arm | 14:05 |
| asac | which is super awful | 14:05 |
| asac | especially since i remember tryint to land it as double preemptively int he distro like 3 years ago :) | 14:05 |
| davmor2 | beuno: you are not an English aristocrat you can't pull off wearing the monocle | 14:05 |
| asac | ogra_: not sure about skype... they ship their own qt anyway | 14:05 |
| beuno | seb128, we can't/don't rebuild on the server | 14:05 |
| asac | but yeah. we woul dhave to use our own namespace | 14:05 |
| beuno | we do have some compiled apps | 14:06 |
| ogra_ | asac, well, there are more third party Qt apps | 14:06 |
| seb128 | asac, was 13.10 really a real-world-user product/supported? or can we just deal with doing an incompatible change once, with the understanding we can't do that again once we have real products out? | 14:06 |
| beuno | they declare a framework version, and if that's going to break, we need to introduce a new one | 14:06 |
| asac | so for us on touch the primary objective is to ensure binary compatibility for our apps | 14:06 |
| beuno | so we'd introduce 13.10.1 framework | 14:06 |
| beuno | which we're already figuring out the details on how to do | 14:07 |
| asac | seb128: its setting precedence that we need to be very careful about | 14:07 |
| asac | and take this opportunity to take measures that this never happens again if we say that we doing a one time break of our just-starting-to-grow application community | 14:07 |
| bzoltan1 | seb128: no it does not | 14:07 |
| ogra_ | seb128, well, it was a developer product to guarantee devs a stable base thats always compatible :P | 14:07 |
| dobey_ | beuno: 14.04 will have to declare a different framework anyway, just because there is new API. 13.10 might work on it, but anything using new API won't work on 13.10 | 14:08 |
| ogra_ | so they have something reliable non-moving to base their development on | 14:08 |
| beuno | yes, you can introduce 14.04 instead of 13.10.1 | 14:08 |
| === dobey_ is now known as dobey | ||
| beuno | the store will filter them out for users so things don't break for them | 14:08 |
| seb128 | ogra_, well, it seems like the choices are "stay forever on a buggy ABI | do a transition/incompatible change | spend lot of efforts on creating a stack for the old ABI for some users" | 14:09 |
| beuno | and this is a good opportunity to iron out this process | 14:09 |
| seb128 | ogra_, so it's a cost benefit, I would hate to be stucked forever on a wrong ABI just because we want to preserve a few apps from our first version | 14:09 |
| ogra_ | seb128, yeah, i#m happy i dont have to make that decision :P | 14:09 |
| didrocks | you should know that we already removed some API | 14:10 |
| dobey | we also need a way to get the framework version from the system | 14:10 |
| dobey | from any language, not just qt/qml | 14:10 |
| didrocks | was discussed last November and acked by pat | 14:10 |
| asac | but this has to end | 14:10 |
| asac | if we never stop doing it, we wont know if we even can do it | 14:11 |
| asac | so now the impact on our app ecosystem might be marginal | 14:11 |
| asac | but what happens if this happens 1 or two years ahead? will we have taken all the precautions | 14:11 |
| asac | that we dont have to kill those apps that use the APIs we dont like anbymore? | 14:11 |
| beuno | yes, lets please stop and iron out the proper process | 14:13 |
| didrocks | I agree, that was my argument, and I think Pat had to action to write clearly and document the breakage + a procedure | 14:13 |
| beuno | right | 14:13 |
| asac | thanks beuno :) | 14:13 |
| beuno | we've been discussing that | 14:13 |
| beuno | and working on how to support this seamlessly | 14:13 |
| beuno | here's an example on how it would work: https://lists.launchpad.net/ubuntu-appstore-developers/msg00650.html | 14:14 |
| seb128 | asac, beuno: well, we should sure not doing it again, it seems like an early day mistake | 14:14 |
| asac | seb128: thats a very simplistic/naive way to look at it | 14:14 |
| seb128 | asac, beuno: we know the proper solution, "create a stack of package for the old ABI", it's just a lot of work and the number of user/benefit seems not worth it atm | 14:15 |
| asac | seb128: we do mistakes now and we will do in future. also its not really a mistake, its something that happened outside our power | 14:15 |
| asac | so it can happy any time at any place in our stack | 14:15 |
| seb128 | asac, you can decide to spent 1 month of engineering time and get it done, but we have better thing to do atm | 14:15 |
| beuno | seb128, I see your point. The question is, wouldn't we get benefits from ironing out the process on migrating from framework versions, though? | 14:15 |
| asac | i haven't heard the complete stoory | 14:16 |
| === alan_g|lunch is now known as alan_g | ||
| beuno | especially now that it's low risk | 14:16 |
| asac | it surely is more than juust doing the packaging. the whole sdk/api versioning etc. | 14:16 |
| asac | needs to be looked at | 14:16 |
| seb128 | beuno, well, we know the process/we can sort that out without doing the actual work to rename/duplicate/upload/review 30 sources | 14:16 |
| asac | how do we ship an SDK that allows folks to build against two different qt ABIs ? | 14:16 |
| seb128 | asac, we are sort of screwed up there because Debian/upstream decided to change the ABI without the soname | 14:16 |
| seb128 | I hope it's a one time thing | 14:17 |
| seb128 | Debian is not going to do that again once qt5 has users for them | 14:17 |
| seb128 | it's price for being earlier users | 14:17 |
| asac | seb128: so it was a debian decision>? not even upstream>? | 14:17 |
| ogra_ | asac, it was an upstream decision | 14:18 |
| seb128 | upstream has a part in it for sure, not sure if we can talk to them about changing soname properly next time | 14:18 |
| ogra_ | debian just follows | 14:18 |
| asac | so i remember talking about this with qt management back in linaro | 14:18 |
| ogra_ | and in fact the ubuntu-arm team has some fault in it | 14:18 |
| seb128 | but the packaging situation is screwed because debian decided to do it "the easy way" because they don't have rdepends | 14:18 |
| asac | they siad that binary cross distro compatibility is something they would love to see | 14:18 |
| ogra_ | we whined to upstream about it for years ... | 14:18 |
| asac | but that they realized cant be the reality anyway | 14:19 |
| seb128 | well, usually Debian would rename their binaries at least in such cases | 14:19 |
| ogra_ | since there were bad patching times every time we opened a new cycle to get the QReal stuff right on arm | 14:19 |
| seb128 | my understanding is that didn't do it because they don't have rdepends for it atm | 14:19 |
| asac | ogra_: right. and while whining they clearly stated | 14:19 |
| lool | asac: I also consider it a valid option that we revert the ABI change but go to 5.2 | 14:19 |
| lool | asac: I find it completely silly from upstream to do this change on ARM 32-bits at this point | 14:19 |
| asac | that there is no intention to ewven shoot for cross distro compatiublity on ARM :_) | 14:19 |
| lool | they could have done it for ARM 64-bits, and everything would have been fine | 14:20 |
| asac | lool: i fully agree | 14:20 |
| asac | i think the binary compatibility is a myuth | 14:20 |
| asac | and if someone packages proprietary software he will surely first follow ubuntu | 14:20 |
| lool | now we face this dilemma of breaking compat across GNU/Linux distros and with upstream | 14:20 |
| asac | so we can really decide on our own what is best | 14:20 |
| lool | so IMO the options are to either revert the ABI change in 5.2, or add a mechanism to allow us to ship old ABIs | 14:20 |
| lool | the latter preserves compat with Debian and upstream | 14:21 |
| lool | and can be reused for latter changes | 14:21 |
| asac | lool: are we illing to put two qt versions in the image ? | 14:21 |
| lool | it means we can be lazy and focus on other things | 14:21 |
| asac | so, if the only choice is: 1. put two qt versions in, 2. backout change upstream | 14:21 |
| asac | what would we do? | 14:21 |
| lool | asac: I think it's doable, but it is /some/ work | 14:21 |
| pmcgowan | lool, I have another proposal I am considering | 14:21 |
| ogra_ | asac, ... until they do a major ABI bump ... | 14:22 |
| asac | ogra_: if we do a bump that is incomptable | 14:22 |
| asac | we will have to ship two versions anyway | 14:22 |
| asac | unless we declare the then existing app ecosystem redundant :) | 14:22 |
| lool | pmcgowan: I'm suspended to your lips | 14:22 |
| lool | or fingers rather | 14:22 |
| asac | pmcgowan: go ahead :) | 14:22 |
| ogra_ | asac, sure | 14:23 |
| * beuno watches as the conversation takes a weird turn | 14:23 | |
| pmcgowan | asac, lool lets this one time simply drop qt 5.0 | 14:23 |
| pmcgowan | where is the dependency? 12 apps? or is it more | 14:23 |
| ogra_ | asac, i was just re-caping what upstream said back then ... they didnt want to do it until the next major ABI bump ... which should theoretically have been 5.0 though | 14:23 |
| pmcgowan | this qt 5.2 abi issue is a one time thing, which makes sense | 14:24 |
| lool | pmcgowan: I find it's a pretty bad precedent | 14:24 |
| seb128 | pmcgowan, +1, that's what I was suggesting, we are not going to have the luxury to do that again but it seems stupid to spend so much efforts/doing something wrong for the futur just to preserve some 10 apps | 14:24 |
| lool | this is what we've been doing for years | 14:24 |
| pmcgowan | we are early enough in the cycle to do it this time, and not after 14.04 | 14:24 |
| seb128 | well, it's a cost/benefit thing | 14:24 |
| lool | but e.g. Android apps work for years after a release, and we can't even keep apps working for 6 months | 14:24 |
| beuno | I don't think it's for the 10 apps, I think it's to iron out the process of handling this properly | 14:24 |
| pmcgowan | also qt 5.2 qreal change is an excpetion | 14:24 |
| lool | beuno: exactly | 14:25 |
| pmcgowan | I find this is too costly and divergent to do this time | 14:25 |
| * beuno nods | 14:25 | |
| seb128 | beuno, ironing the process != doing all the work once defined | 14:25 |
| lool | Yes it's costly | 14:25 |
| beuno | right | 14:25 |
| lool | the cost comes from breaking the ABI | 14:25 |
| seb128 | well, there is also the issue that Debian decided to not rename | 14:25 |
| lool | but we value our app developers more than the costs incurred by a stable ABI commitment | 14:25 |
| seb128 | because they have no rdepends | 14:25 |
| seb128 | that's not going to happen again | 14:25 |
| beuno | so the cost/benefit balance needs a judgement call | 14:25 |
| seb128 | so the situation is unique in that regard | 14:25 |
| lool | seb128: Debian will break ABI again | 14:26 |
| lool | and agian | 14:26 |
| seb128 | and they will rename next time | 14:26 |
| lool | it's not unique | 14:26 |
| === rachelliu_ is now known as rachelliu | ||
| lool | the qreal transition might be | 14:26 |
| seb128 | because that's what they do when they have rdepends | 14:26 |
| pmcgowan | lool, I will have the current app set reviewed to see how many are effected and who the authors are | 14:26 |
| seb128 | lool, the "non renaming because no rdepends" is what is unique | 14:26 |
| lool | seb128: the thing is that Debian can reupload all the software in Debian | 14:26 |
| lool | and we can reupload everything in the Ubuntu archive | 14:26 |
| lool | but we cant reupload the app store's clicks | 14:26 |
| seb128 | lool, well, Debian would rename if the lib has users | 14:26 |
| lool | it's not about the renaming vs. not renaming | 14:27 |
| seb128 | so next time they are not going to handle it the same way | 14:27 |
| lool | Debian took a decision based on what's in the Debian archive | 14:27 |
| seb128 | well, that makes a difference on the "how do we ship 2 versions of qt in the archvie"' | 14:27 |
| lool | and Debian has control over the contents of the Debian archive | 14:27 |
| beuno | pmcgowan, FWIW, I don't think it matters how many apps it affects at this point, I wouldn't use that as a tool to decide. I think it's easy to hand-hold however many there are at this point | 14:27 |
| lool | if we break ABI now, we will break it again next cycle | 14:27 |
| beuno | for me it's about working out the proper transition now that it's cheap | 14:27 |
| lool | we will have the same discussion | 14:28 |
| lool | even if there are 10 times more apps | 14:28 |
| kenvandine | next cycle it will be much harder to deal with | 14:28 |
| beuno | (cheap to make mistakes in the transition) | 14:28 |
| davmor2 | popey: I thought I had alarms in the clock app saving the other day, today they don't seem to be showing up | 14:28 |
| pmcgowan | beuno, once I read all the posts and understood what the qt 5.2 breakage was about, it seemed to be quite an exception that caused us to be considering this | 14:28 |
| lool | what's exceptional in theory is that qt breaks ABI | 14:28 |
| pmcgowan | lool, I dont agree that making this decision sets any sort of precedent | 14:28 |
| lool | when we picked it because we thought it wouldn't | 14:28 |
| lool | but we knew e.g. qt 6 would break it | 14:29 |
| pmcgowan | again the specific case is unique | 14:29 |
| beuno | pmcgowan, right, I agree with that. This is more about there will be breakage each time in something different, as an exception each time, right? That's how this works | 14:29 |
| pmcgowan | gaining compatibility across OSes | 14:29 |
| asac | pmcgowan: so in general I am fine to explicitely declare something like this a one-time-never-happen again event once I am convinced. however, I am not really convinced we have gone deep enough that we are confident that we know what to do with similar things in future | 14:29 |
| lool | the situation is we told developers they could upload their apps to the appstore and the apps would work forever on Ubuntu Touch | 14:29 |
| beuno | I'm happy if yoiu say we can't afford to do the work now, as we'll delay other core feature of the OS | 14:29 |
| beuno | but we have to bite the bullet at some point | 14:29 |
| pmcgowan | lool is we said forever we definitely lied ;) | 14:29 |
| pmcgowan | beuno, thats really what I am saying | 14:30 |
| lool | and it's been < 3 months since the release! :-) | 14:30 |
| pmcgowan | look at how many engineers are thinking about the problem | 14:30 |
| lool | it's like saying we will delay the release this one time | 14:30 |
| lool | Ok we did it once :-) | 14:30 |
| ogra_ | pmcgowan, well, it was said in this channel about 6 months ago :) | 14:31 |
| ogra_ | so it must be true :P | 14:31 |
| pmcgowan | lool, upstreams one time decision causes us to make a similar one time decision, I just don't think this implies anything for the future | 14:31 |
| pmcgowan | ogra_, heh you have the log? | 14:31 |
| pmcgowan | anyway thats my two cents | 14:32 |
| lool | pmcgowan: difference is that if one of our upstreams makes a similar one time decision in each of our cycles, we're screwed | 14:32 |
| lool | unless we firewall them somehow | 14:32 |
| pmcgowan | lool, sure | 14:32 |
| ogra_ | pmcgowan, i bet i could find it if i invest the time :) | 14:32 |
| lool | I will gladly admit that the fact it hits qt makes it much worse than anything else | 14:32 |
| lool | due to the qml modules and such | 14:32 |
| pmcgowan | lool, but I bet no other upstream would cause us this much pain, qt is too fundamental | 14:32 |
| lool | perhaps libc would be worse, or moving away from linux but that's about it ;-) | 14:33 |
| pmcgowan | right! | 14:33 |
| lool | pmcgowan: but we will face other qt ABI changes I'm sure | 14:33 |
| lool | they will remove ABI | 14:33 |
| lool | we will also see a qt 6 | 14:33 |
| lool | there will be ABI regressions | 14:33 |
| kenvandine | lool, careful, you'll start a rumor that we'll rebase on bsd | 14:33 |
| pmcgowan | their stated policy is the same as what we intend, so ... | 14:33 |
| lool | kenvandine: ah crap, I had forgotten this was a public channel; we're doomed | 14:34 |
| kenvandine | haha | 14:34 |
| seb128 | lool, well, we are going to have to deal with ABI changes one day for sure, the question is just to know if the current situation required us to divert so much effort to deal with it now | 14:34 |
| lool | pmcgowan: you mean until they make exceptions to that policy? ;-) | 14:34 |
| kenvandine | i thought the expectation for click apps was it supported version 13.10 of the framework | 14:34 |
| asac | seb128: i am of the position that our just-starting-to-thrive app ecosystem | 14:34 |
| asac | is one of the most precious things we have | 14:34 |
| kenvandine | apps would need updating for 14.04 of the framework | 14:35 |
| pmcgowan | kenvandine, right, but we intended to support frameowrks for a longer period of time than 3 months | 14:35 |
| asac | so we should really do whatever it takes to deliver a flawless experience for them | 14:35 |
| seb128 | asac, I guess it's a call we can make, we just need to decide where we find the resources/what other work we drop then | 14:35 |
| kenvandine | pmcgowan, yes... so 13.10 might need a different version of qt | 14:35 |
| asac | we can defer doing it, but i dont sense that people really have the same attitude and would be willing to do it without questioning next time it happens | 14:36 |
| pmcgowan | I just dont see that implication | 14:36 |
| pmcgowan | Qt upstream was fixing a fundamental inconsistency | 14:36 |
| kenvandine | we wouldn't be able to do this when our app ecosystem is bigger | 14:36 |
| pmcgowan | it was the right thing for them, and for us ultimimately | 14:36 |
| cyphermox | weird, with no connection the ap tests fail because webbrowser complains about the network even though localhost should be there anyway | 14:37 |
| cyphermox | didrocks: ^ finishing up with webbrowser now... Mirv apparently released gallery earlier | 14:37 |
| didrocks | cyphermox: yeah, I asked him | 14:38 |
| didrocks | thanks | 14:38 |
| cyphermox | it was fine to release anyway | 14:38 |
| === shiggitay is now known as Shiggitay | ||
| Shiggitay | Sooo rumors say that UT for the Nexus 5 is coming around Late January/Early February... can anyone confirm or deny that? | 14:39 |
| asac | Shiggitay: thats a rumor. | 14:40 |
| Shiggitay | And will it be the 1.0 that's out for all the other Nexus family members? or something more that'll benefit the other devces as well? | 14:40 |
| Shiggitay | asac, oh? someone that had been porting UT for the N5 said that Canonical themselves made this announcement | 14:41 |
| ogra_ | Shiggitay, our kitkat based port will be ready by this time | 14:41 |
| asac | Shiggitay: i am about to send a mail giving a heads up on our engineering platform roadmap... however, got detoured for a moment. just leech on ubuntu-phone ML. info will go out soonish | 14:41 |
| ogra_ | but that doesnt mean we will start building for N5 (we might but not support it etc) | 14:41 |
| Shiggitay | ogra_, are you a canonical employee/rep? | 14:42 |
| asac | Shiggitay: summary is that we go for android 4.4 in the timeframe you mentioned, but we wont move our focus away from the N4 to the N5 | 14:42 |
| ogra_ | Shiggitay, i am, but asac makes the rules here :) | 14:42 |
| Shiggitay | heh | 14:42 |
| lool | asac, seb128: I think I'd be leaning towards keeping the old ABI | 14:42 |
| lool | it's not a lot of work | 14:43 |
| asac | Shiggitay: ogra is canonical, but I would encourage to not consider any statement anyone from IRC as an official position (regardless who says that :)) | 14:43 |
| lool | and we can transition as we see fit | 14:43 |
| seb128 | lool, "it's not a lot of work" ... if you say so ;-) | 14:43 |
| asac | everybody is just doing their best and try to be as transparent and accurate as possible here :) | 14:43 |
| ogra_ | Shiggitay, we will likely just start rolling N5 images alongside, but nobody will focus on fixing or specifically working on them | 14:43 |
| seb128 | lool, I don't even see how you can ship 2 ABIs with the same soname | 14:43 |
| lool | seb128: I mean, it's just reverting the qreal change | 14:43 |
| pmcgowan | lool, seb128 I think its worth considering | 14:43 |
| seb128 | oh, in that sense | 14:43 |
| seb128 | so making Ubuntu binary impactible with others ? | 14:44 |
| lool | seb128: the ABI change comes from a typedef change of qreal from float to double; one option is that we let Debian take this change but we dont | 14:44 |
| lool | seb128: right | 14:44 |
| Shiggitay | ogra_, with all due respect and all that, the n5 is prefect hardware for UT.... also wouldn't it work well with Convergence once 14.10 is out? | 14:44 |
| seb128 | I can't say I like that | 14:44 |
| Shiggitay | perfect* | 14:44 |
| seb128 | but it's an option for sure | 14:44 |
| pmcgowan | we need to weight the tradeoffs | 14:44 |
| asac | seb128: exactly. thats what i mean. we dont know what we would do if we couldnt afford to break ABI, so i would either just do it right this time or at least go far deeper exploring the implications of that then what was done here so far | 14:44 |
| lool | we'd be binary incompatible with upstream 5.2, Debian, other GNU/Linux but only on ARM; and we'd be binary compatible with 5.0 | 14:44 |
| lool | until, say, qt 6 | 14:44 |
| kevink1xwl | hello i would like ubunut touch in my xperia u | 14:44 |
| asac | so we know if there is anything we need to do now so we can react effectively in the likely or unlikely case that it happens again in some other form | 14:45 |
| Shiggitay | but ok I think I just read that there will be UT images released soon for the N5... that's good news. | 14:45 |
| ogra_ | Shiggitay, the N5 is great and all, but it is very costly to enable a new arch and actually make it rock ... | 14:45 |
| seb128 | lool, I fear that's going to create more issues over qt5 time than biting the bullet | 14:45 |
| asac | Shiggitay: i didnt say that :) | 14:45 |
| seb128 | we are locking ourself in a corner | 14:45 |
| lool | seb128: what issues does it create? | 14:45 |
| seb128 | and we are not going to be able to easily get out | 14:45 |
| ogra_ | Shiggitay, and no, convergence requires laptop grade HW ... specifically more ram and diskspace than the N5 had | 14:45 |
| ogra_ | *has | 14:45 |
| asac | Shiggitay: there wont be N5 builds coming for soon. | 14:45 |
| Shiggitay | ah | 14:45 |
| davmor2 | tvoss: is haptic only enabled on phones on the n7 it doesn't seem to be there :( | 14:45 |
| Shiggitay | ok | 14:45 |
| lool | at least it makes close to no packaging delta | 14:45 |
| seb128 | lool, it makes use incompatible with potential closed source binaries distributed by upstreams | 14:46 |
| lool | and it doesn't require a lot of time | 14:46 |
| tvoss | davmor2, the n7 does not have a vibrator as far as I know | 14:46 |
| pmcgowan | davmor2, I dont think n7 supports it | 14:46 |
| Shiggitay | ogra_, I'd just like to give UT a try... I have an N5 and I'd rather not have to get an N7 or 10 to try it out. | 14:46 |
| lool | seb128: things linked to qt but not built for Debian or Ubuntu specfically? | 14:46 |
| ogra_ | asac, we will likely enable them, just not care if they work (or integrate anything for them) | 14:46 |
| lool | I guess it could be e.g. skype | 14:46 |
| seb128 | lool, right | 14:46 |
| pmcgowan | hmm | 14:46 |
| seb128 | lool, that might be a small set today, but who knows in 3 years? | 14:46 |
| asac | ogra_: dont do that please. | 14:47 |
| ogra_ | asac, just enabling them is cheap ... then lets see if the community wants to care for fixing ;) | 14:47 |
| seb128 | we might still be stucked by that decision | 14:47 |
| asac | ogra_: both rsalveti and chicken confirmed we wont do that | 14:47 |
| davmor2 | tvoss, pmcgowan: that would do it then | 14:47 |
| ogra_ | asac, ok | 14:47 |
| asac | ogra_: we dont want to ship anything that isnt an example of the excellent work we are doing. if we have those builds out, people will look at them and will get a bad experience | 14:47 |
| ogra_ | asac, *i* wont do anything anyway ... would be ricardo (i would just publish the images) | 14:47 |
| Shiggitay | a perfect use of UT for me would be with these apps: Twitter, TuneIn Radio, something like MXPlayer or VLC, an iRC client, and a good web browser. That's my 'workflow' on Android and on iOS when I had it and it worked well | 14:47 |
| kevink1xwl | ))))))))))))))))))))))))))))))))) XPERIA U UBUNTU TOUCH ES POSIBLE? | 14:48 |
| asac | ogra_: good :) | 14:48 |
| asac | thanks | 14:48 |
| ogra_ | asac, lol ... then we need to drop grouper and manta *now* | 14:48 |
| asac | ogra_: yes. | 14:48 |
| asac | ogra_: thats in the announce mail | 14:48 |
| ogra_ | kevink1xwl, stop shouting please ... | 14:48 |
| pmcgowan | can we move manta to a community port? I really like mine | 14:48 |
| ogra_ | !devices | kevink1xwl | 14:48 |
| ubot5 | kevink1xwl: You can find the full list of devices, official images, community images, and works in progress at https://wiki.ubuntu.com/Touch/Devices | 14:48 |
| Shiggitay | ok fine.. instagram too | 14:48 |
| rsalveti | yeah, we should still publish the images, but as community ports | 14:48 |
| asac | we dont have a good way | 14:48 |
| kevink1xwl | THANK | 14:48 |
| ogra_ | kevink1xwl, if it is not on there you might to have to port it yourself | 14:48 |
| rsalveti | just not necessarily using the official channels | 14:48 |
| Shiggitay | ooh do that with the N5 port! | 14:48 |
| asac | rsalveti: fine with it if we have an official owner from community whose name we can attach | 14:49 |
| rsalveti | asac: right | 14:49 |
| ogra_ | asac, well, thats a chicken/egg thing | 14:49 |
| asac | so lets not do the builds, but rather offer community that they can work on them and come to us | 14:49 |
| ogra_ | if we provide crappy images people will step up | 14:49 |
| asac | havent seen that before | 14:49 |
| ogra_ | if we dont provide anything they wont | 14:49 |
| rsalveti | I just think we should provide at least the infra, as that's not a huge thing for us anyway | 14:50 |
| rsalveti | the build infra I mean | 14:50 |
| asac | we can offer the infra, but we shouldnt set the build up before someone owning the build | 14:50 |
| Shiggitay | in theory would an N5 build come out sooner if it gained more community support? | 14:50 |
| ogra_ | right | 14:50 |
| ogra_ | enabling another build is no work | 14:50 |
| ogra_ | (nearly) | 14:50 |
| ogra_ | as long as we dont commit to maintain it | 14:50 |
| rsalveti | right, just put that on your email as well, asking if someone wants to own it | 14:50 |
| asac | yeah. its a bit tricky though. if you want to own it you have to own the graphics stack as well | 14:51 |
| asac | so you need skillls (TM) :) | 14:51 |
| ogra_ | Shiggitay, if someone takes responsibility | 14:51 |
| ogra_ | asac, huh ? | 14:51 |
| rsalveti | well, we'll have support from the mir team as well | 14:51 |
| rsalveti | once we officially drop sf | 14:51 |
| ogra_ | asac, the Mir team will have to support it anyway ... as other community ports | 14:51 |
| Shiggitay | Someone was almost willing to release an alpha but they couldn't get the HWComposer or something like that working since apparently UT is based on Cyanogen Mod 10.2 or something? | 14:52 |
| ogra_ | if we decide that SF is gone, the Mir team support work will quadruple | 14:52 |
| asac | they can support and teach | 14:52 |
| asac | but not do | 14:52 |
| Shiggitay | That's when he said that you guys are gonna release something late Jan/Early Feb | 14:52 |
| ogra_ | N5 is just another one then | 14:52 |
| ogra_ | but surely nothing community can do easily without their help | 14:53 |
| Shiggitay | thus canceling his efforts to port FireFox OS | 14:53 |
| Shiggitay | instead | 14:53 |
| asac | Shiggitay: we will have android 4.4 support on N4 and N7 (razor() in that time frame... | 14:53 |
| asac | that should make it relatively easy for community or later us to also bring up N5 | 14:53 |
| === kirkland` is now known as kirkland | ||
| asac | but its not trivial to do, so we dont want to really tackle N5 until we need it for our short term engineering roadmap | 14:54 |
| rsalveti | yup, once the 4.4 port is done, it'll be really easy to support n5 | 14:54 |
| Shiggitay | o i c | 14:54 |
| ogra_ | as i said in the beginning :) | 14:54 |
| Shiggitay | so at the end of the month you'll be that much closer to getting stuff working on the N5? | 14:54 |
| mhall119 | Shiggitay: are you talking about Salvatore's porting effort? | 14:54 |
| Shiggitay | I dunno his XDA name | 14:54 |
| Shiggitay | hold on | 14:54 |
| rsalveti | Shiggitay: yup | 14:54 |
| rsalveti | working on it as we speak (4.4 porting) | 14:55 |
| Shiggitay | rsalveti, cool | 14:55 |
| mhall119 | https://plus.google.com/u/0/+SalvatoreFestaTech/posts/e1XVkG1VTFV | 14:55 |
| Shiggitay | if you need an alpha/beta tester @ rsalveti I can help | 14:55 |
| mhall119 | he's been working on a Nexus5 port for a little while now, but it stuck waiting on us to upgrade to 4.4 | 14:55 |
| Shiggitay | http://forum.xda-developers.com/showthread.php?t=2594874 | 14:56 |
| Shiggitay | that's the dude that canceled his port | 14:56 |
| rsalveti | Shiggitay: sure, will do :-) | 14:56 |
| Shiggitay | rsalveti, are you ValoXis ? | 14:57 |
| Shiggitay | on XDA | 14:57 |
| rsalveti | nops, rsalveti everywhere | 14:57 |
| Shiggitay | k but you're gonna port UT to the N5 once your kitkat port is done? | 14:58 |
| Shiggitay | and why port kitkat? it's already running just fine | 14:58 |
| rsalveti | I'll create the image, someone has to test it :-) | 14:58 |
| Shiggitay | not a developer.. .sorry... just trying to understand | 14:58 |
| rsalveti | we use the android hardware abstraction layer | 14:58 |
| Shiggitay | I'll test the image | 14:58 |
| rsalveti | and we're currently using the android hal from 4.2.2 | 14:58 |
| rsalveti | so that's why we need to forward port that in order to support newer devices, such as n5 | 14:59 |
| Shiggitay | ok so that's the pre-UT kernel layer or something? | 14:59 |
| ogra_ | it is the bit thtas needed to use the bianry drivers | 14:59 |
| rsalveti | we're booting directly on ubuntu, and then we start the core layer of android in a container | 14:59 |
| ogra_ | *binary | 14:59 |
| rsalveti | so we can use some core services and drivers | 14:59 |
| Shiggitay | Ahh | 14:59 |
| ogra_ | graphics, modem, sensors and video codecs | 15:00 |
| Shiggitay | so it's like having a minimal android system running solely for drivers, but the rest (UI etc) will be UT | 15:00 |
| ogra_ | right | 15:00 |
| Shiggitay | ok I think understand now | 15:00 |
| ogra_ | that way we can just use the existing android drivers | 15:00 |
| Shiggitay | yeah | 15:00 |
| Shiggitay | without having to port any to UT specifically, right? | 15:01 |
| === dandrader is now known as dandrader|lunch | ||
| ogra_ | well, there are many bits you couldnt just ports | 15:01 |
| ogra_ | *port | 15:01 |
| Shiggitay | basically emulating 4.4 with UT atop? | 15:01 |
| ogra_ | most of these drivers are nonfree ... and reverse engineering them would take years | 15:01 |
| Shiggitay | oh wow | 15:01 |
| ogra_ | (without any public specification docs etc) | 15:02 |
| Shiggitay | so in essence both OSes would be running at the same time, but really only the drivers would be accessed or something? | 15:02 |
| ogra_ | no, its not UT atop | 15:02 |
| ogra_ | its UT all the way ... and a container in which android gets started along the boot process | 15:02 |
| ogra_ | the ubuntu userspace talks to that container through a library | 15:02 |
| ogra_ | so everything that makes use of such a driver just talks to the driver as if it would be local ... but the lib redirects all this to the container | 15:03 |
| Shiggitay | ok so just so I understand your efforts... it boots into KitKat's HAL to laod up drivers, and then UT boots, calling upon that HAL that'll have booted? | 15:03 |
| === vying is now known as Guest13774 | ||
| ogra_ | no | 15:03 |
| ogra_ | it boots into ubuntu | 15:03 |
| ogra_ | ubuntu starts a container with kitkat drivers (and all the bits the driver needs) | 15:04 |
| Shiggitay | ok | 15:04 |
| ogra_ | and then ubuntu starts the UI which talks to the container | 15:04 |
| Shiggitay | what would happen if it was to boot up without the HAL? nothing right? | 15:04 |
| ogra_ | (but the userspace and UI think they talk to local ubuntu drivers) | 15:04 |
| Shiggitay | lol trickery | 15:05 |
| ogra_ | you wouldnt have graphics, modem, sensors and video playback | 15:05 |
| ogra_ | ti would boot to a adb shell in the ubuntu rootfs | 15:05 |
| ogra_ | (and a blank screen) | 15:05 |
| Shiggitay | ok so you could play with it via ADB? | 15:07 |
| Shiggitay | could you redirect the apps to load on an X Server or something on the client controling it/ | 15:07 |
| Shiggitay | ? | 15:07 |
| ogra_ | that would require other changes | 15:08 |
| ogra_ | the kernel is not set up in a way that you easily can run X | 15:08 |
| ogra_ | (well, on some devices it works, on most it doesnt) | 15:08 |
| Shiggitay | wow this project is more complex than I had originally though :) | 15:08 |
| ogra_ | (really depends on the kernel config) | 15:08 |
| Shiggitay | er thought* | 15:08 |
| ogra_ | and X wouldnt get you anywhere as the UI requires Mir | 15:09 |
| Shiggitay | ok | 15:09 |
| Shiggitay | I hope I'm not coming across as a troll or anything... I want to do anything I can to help this move along even I can't code for sh*t :) | 15:09 |
| ogra_ | you totally dont | 15:10 |
| Shiggitay | good :) | 15:10 |
| ogra_ | all valid questions | 15:10 |
| Shiggitay | cool | 15:10 |
| Saviq | pitti, question: I just retraced a .crash from my desktop locally (I've Qt 5.0 installed), but the retracer seems to have picked up Qt 5.2 packages from a PPA I had added to sources.list, is that expected? | 15:10 |
| Shiggitay | I appreciate your patience :) | 15:10 |
| ogra_ | :) | 15:10 |
| Saviq | added to the retracer sources.list, that is | 15:10 |
| pitti | Saviq: yes, it always takes the latest version from apt | 15:11 |
| pitti | Saviq: it's been on my long-term wishlist to make that more clever and try and install the versions from Dependencies.txt | 15:11 |
| pitti | Saviq: but never got to that | 15:11 |
| Shiggitay | ogra_, another question for you: Once the KK HAL is ported, how likely would an HP Touchpad UT port become? someone had a halfway working port, but he abandoned it for a sailfish based project. | 15:11 |
| Saviq | pitti, ok, was surprised, good to know, thanks | 15:11 |
| === oSoMoN_ is now known as oSoMoN | ||
| ogra_ | Shiggitay, well, depends who invests the time ... wouldnt be harder than porting to CM | 15:12 |
| ogra_ | (a lot easier in fact i think) | 15:12 |
| ogra_ | there is a link to the porting guide in the channel topic ... should give you a rough idea how much is involved | 15:13 |
| Shiggitay | Okay. I have an HPTP, but it's not powerful enough for me anymore. lol | 15:13 |
| Shiggitay | it'd be great if the "Nexus 8" aka LG GPad 8.3 was to get a UT port | 15:13 |
| Shiggitay | xD | 15:13 |
| Shiggitay | I'mma get one of those soon | 15:13 |
| ogra_ | well, the official focus from us will most likely be narrowed to one phone and one tablet for now | 15:14 |
| ogra_ | everything else has to be done by the community | 15:14 |
| Shiggitay | yeah | 15:15 |
| Shiggitay | so someone might indeed make a GPad port? | 15:15 |
| Shiggitay | in due time? | 15:15 |
| Shiggitay | I mean once the KK HAL base is ported to newer hardware won't porting UT itself be easier on any modern platform like the GPad 8.3? | 15:16 |
| ogra_ | just convine a community dev ... | 15:16 |
| ogra_ | or learn it yourself ;) | 15:16 |
| Shiggitay | I have no coding knowledge at all | 15:17 |
| ogra_ | well, its not hrd to learn obviously ... | 15:17 |
| ogra_ | (by just doing it ;) ) | 15:17 |
| Shiggitay | if someone was to help me then I guess sure | 15:17 |
| Shiggitay | am I right/wrong about what I said above? | 15:18 |
| cwayne | dpm_: hey, gave you edit rights to that doc | 15:18 |
| dpm_ | thanks cwayne :) | 15:18 |
| cwayne | dpm_: i'll go through and try to log some bugs today, as there's definitely some strings missing from the potfiles | 15:18 |
| cwayne | dpm_: i've also rigged together a quick script to get percentage translated + missing strings from the .po's if that's helpful :) | 15:19 |
| dpm_ | cwayne, ok, thanks. At first look, do you think they're translatable string missing from the apps, or from some other parts of the system? | 15:19 |
| cwayne | dpm_: almost entirely apps | 15:20 |
| dpm_ | cwayne, yeah, that's definitely helpful | 15:20 |
| dpm_ | ok | 15:20 |
| cwayne | dpm_: for example, dialer-app and messaging-app have almost 0 translations | 15:20 |
| cwayne | but most of the core click apps from the community (weather, calculator, et al) are actually quite well translated | 15:20 |
| victorp | jdstrand, ping | 15:22 |
| cwayne | dpm_: i'll try to get you a list of missing strings from that list of languages today | 15:25 |
| jdstrand | victorp: hey | 15:25 |
| Shiggitay | ogra_, :) | 15:26 |
| bambam_ | hi | 15:27 |
| victorp | jdstrand, thanks for your feedback, just looking into it now, quick q - is there are wiki with the details on read_path? | 15:27 |
| jdstrand | victorp: https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest | 15:29 |
| jdstrand | victorp: note, anything using read_path is "Red-flagged for manual review (use should actively be discouraged with updates made to policy groups and templates)" | 15:29 |
| victorp | jdstrand, sure, but as you said is more specific that fully unconfined | 15:30 |
| dpm_ | cool, thanks cwayne | 15:30 |
| jdstrand | yes. I'm just trying to communicate that read_path's use is discouraged | 15:30 |
| victorp | jdstrand, sure, not really any other option to readlogs though | 15:31 |
| jdstrand | well, we could make a policy group for it | 15:32 |
| mdeslaur | it would be better to add a policy group to read logs | 15:32 |
| mdeslaur | and make it reserved | 15:32 |
| jdstrand | mdeslaur: I'm jotting down stuff to discuss that and the other app that uses read_path | 15:32 |
| mdeslaur | jdstrand: cool | 15:32 |
| jdstrand | I think there are discussion points on them. we could do reserved, or we could do common with 'audit deny network' | 15:33 |
| victorp | the paths that I will be interested are /var/log/ and /home/phablet/.cache/upstart/ | 15:33 |
| jdstrand | anyway, don't need to discuss now | 15:33 |
| mdeslaur | jdstrand: interesting, yeah | 15:33 |
| victorp | jdstrand, what do you suggest I do? change the app to use read_path and send again or wait? | 15:33 |
| jdstrand | victorp: that's fine for now so long as you don't include the networking policy group | 15:34 |
| victorp | jdstrand, yes, that was a copy and paste errors | 15:34 |
| jdstrand | victorp: resend the app | 15:34 |
| victorp | I will remove that | 15:34 |
| jdstrand | you don't have to wait on this as we won't resolve it for a bit | 15:34 |
| * Shiggitay pokes rsalveti :P | 15:35 | |
| seb128 | hum | 15:37 |
| seb128 | should I be able to upgrade from saucy to trusty by using "system-image-cli -v -c trusty"? | 15:37 |
| victorp | jdstrand, ack | 15:37 |
| seb128 | that displayed some "Requesting group download" then | 15:37 |
| seb128 | "[systemimage] Jan 09 15:34:05 2014 (2357) Running group download reactor" | 15:37 |
| seb128 | but nothing seems to happen anymore | 15:37 |
| ogra_ | seb128, the download-manager doesnt give *any* output | 15:38 |
| ogra_ | just be patient | 15:38 |
| seb128 | ok | 15:38 |
| ogra_ | s-i-c calls it and then you have to wait ... | 15:39 |
| seb128 | FileNotFoundError: [Errno 2] No such file or directory: '/android/cache/recovery/ubuntu-2a9f86f374f287f87069095a16245b36afa2a204691dc1a3c5bff1b5e8ccbc93.tar.xz' | 15:41 |
| seb128 | shrug | 15:41 |
| ogra_ | ouch | 15:42 |
| * seb128 tries again | 15:42 | |
| seb128 | those updates are so unreliable :/ | 15:42 |
| * ogra_ stopped using the cmdline for that a while ago | 15:42 | |
| seb128 | ogra_, can I upgrade from saucy to trusty without the command line? | 15:43 |
| seb128 | from the device | 15:43 |
| seb128 | e.g without using the phablet tools | 15:43 |
| ogra_ | well, the above didnt indicate that you upgrade from saucy to trusty | 15:44 |
| ogra_ | and no, you cant | 15:44 |
| seb128 | above, being? | 15:44 |
| ogra_ | but your above command would be missing -b 0 | 15:44 |
| ogra_ | since you need to reset the version to 0 to force a full image download | 15:44 |
| seb128 | is that needed now that trusty's version is > saucy | 15:44 |
| seb128 | k | 15:44 |
| ogra_ | no, was always needed | 15:45 |
| ogra_ | if you are on trusty already you dont need it, but when switching channels you do | 15:46 |
| seb128 | ogra_, ok, thanks (that device is still on saucy, trying to upgrade) | 15:46 |
| === alan_g is now known as alan_g|tea | ||
| === gatox is now known as gatox_lunch | ||
| kenvandine | seb128, at one point i had and error like that, which was caused from being out of space | 15:50 |
| seb128 | kenvandine, hum, /dev/disk/by-partlabel/cache 552M 372M 181M 68% /android/cache | 15:51 |
| kenvandine | how big is the image it is downloading? | 15:51 |
| seb128 | how do I know? | 15:51 |
| kenvandine | i had a couple old images laying around there | 15:51 |
| kenvandine | dunno :) | 15:51 |
| kenvandine | so it wasn't writing the file to disk | 15:52 |
| kenvandine | i removed the old files then it worked | 15:52 |
| kenvandine | it was quite a while ago though | 15:52 |
| seb128 | I'm not even sure where to look | 15:53 |
| kenvandine | if that full image download is more than 181M, that's what's happening | 15:53 |
| seb128 | # du -ksh /android/cache | 15:53 |
| seb128 | 36K/android/cache | 15:53 |
| ogra_ | iirc system-image-cli will clear the space for you now | 15:53 |
| ogra_ | (in v2.0) | 15:54 |
| ogra_ | oh, but thats saucy ... | 15:54 |
| kenvandine | but if he's saucy | 15:54 |
| ogra_ | old crap :P | 15:54 |
| seb128 | where does it download? | 15:54 |
| ogra_ | to the cache dir | 15:54 |
| seb128 | # du -ksh /android/caches/cache | 15:54 |
| seb128 | 36K/android/cache | 15:54 |
| seb128 | no | 15:54 |
| kenvandine | seb128, i think it is /android/cache/recovery | 15:56 |
| seb128 | # du -ksh /android/cache/recovery/ | 15:56 |
| seb128 | 24K/android/cache/recovery/ | 15:56 |
| mterry_ | ogra_, heyo! So I've tested the nested branch against latest image on my mako. Do you have a maguro for testing? | 15:56 |
| ogra_ | ask barry then | 15:57 |
| ogra_ | i know it processes it from the cache dir | 15:57 |
| ogra_ | probably it downloads to tmp first | 15:57 |
| ogra_ | mterry_, i do, but didnt we wait for ricmm_ and the hybris fix ? | 15:57 |
| ogra_ | i havent heard anything yet | 15:58 |
| seb128 | stgraber, barry: do you know what's going on if on a saucy touch image I've "/android/cache" full in df but with no content if I use ls/du? | 15:59 |
| mterry_ | ogra_, yes... Though I think hybris was only needed for grouper. I think maguro will work with just the mir fix | 15:59 |
| ogra_ | ok, will test later today (got a bunch of meetings now) | 16:00 |
| barry | seb128: that's pretty weird! | 16:00 |
| kenvandine | barry, seb128's device is still saucy | 16:01 |
| kenvandine | he's trying to upgrade to trusty | 16:01 |
| kenvandine | so it's the old download manager | 16:01 |
| barry | ah | 16:01 |
| barry | seb128: `system-image-cli --version` says? | 16:02 |
| seb128 | system-image-cli 1.9.1 | 16:02 |
| barry | seb128: okay. in a meeting now. will circle back when that's done | 16:02 |
| seb128 | barry, upgrade fails because /android/cache is full, I'm just trying to figure out what to clean to make space | 16:02 |
| seb128 | barry, thanks | 16:02 |
| seb128 | it's some lxc magic I guess | 16:03 |
| ogra_ | seb128, not related to lxc | 16:03 |
| seb128 | /dev/disk/by-partlabel/cache 552M 552M 0 100% /android/cache | 16:03 |
| seb128 | /dev/disk/by-partlabel/cache 552M 552M 0 100% /var/lib/lxc/android/rootfs/cache | 16:03 |
| === greyback is now known as greyback|away | ||
| seb128 | but neither /android/cache or /var/lib/lxc/android/rootfs/cache have content if you ls them | 16:03 |
| ogra_ | nothing on the android side makes any use of cache | 16:03 |
| ogra_ | sounds like some of the initrd mount stuff failed ... did you try a reboot ? | 16:04 |
| seb128 | I'm rebooting | 16:04 |
| === alan_g|tea is now known as alan_g | ||
| seb128 | but when I started the upgrade that dir had 180M free | 16:04 |
| seb128 | so I guess things are working and it just didn't have enough space for the update | 16:04 |
| seb128 | I don't get the magic behind the directories though | 16:05 |
| seb128 | ok | 16:05 |
| seb128 | /dev/disk/by-partlabel/cache 552M 9.8M 542M 2% /android/cache | 16:05 |
| seb128 | let's try again | 16:05 |
| ogra_ | aha | 16:06 |
| kenvandine | seb128, so a reboot cleared that much? | 16:10 |
| seb128 | kenvandine, yes | 16:10 |
| seb128 | I guess it was in a tmpfs or somethign | 16:10 |
| kenvandine | seb128, quick update before it fills again :) | 16:12 |
| seb128 | kenvandine, ;-) | 16:12 |
| victorp | jdstrand, that didnt work as I am running ls to find files in doc | 16:33 |
| victorp | s /doc/folder/ | 16:33 |
| ogra_ | how do you run ls ? | 16:35 |
| ogra_ | you shouldnt even be able to access it | 16:35 |
| ogra_ | do you ship it in your click ? | 16:36 |
| victorp | ogra_, unconfined | 16:36 |
| jdstrand | victorp: right, cause you were unconfined you could shell out | 16:36 |
| ogra_ | ah ... | 16:36 |
| victorp | jdstrand, would QDir work? | 16:36 |
| jdstrand | victorp: since you were doing that, you presumably are using compiled code, so you can use Qt file operations to get your list | 16:36 |
| victorp | jdstrand, yeah I will try that | 16:37 |
| cwayne | sforshee: hey, so when you said that the configs in /usr/share/powerd/device_configs were from android, do you mean that's where we got them from originally, but now they're included in the powerd package? | 16:37 |
| jdstrand | I can't tell you how-- but yeah | 16:37 |
| cwayne | i thought you'd meant we get it from the android lxc container or something along those lines | 16:37 |
| ogra_ | jdstrand, hmm, would it work if i shipped busybox inside my click to get the common shell commands ? (just an academic questions out of curiosity) | 16:38 |
| === ricardodrosales is now known as ricdros | ||
| jdstrand | ogra_: you have execute perms on files in your install directory, so, in theory, yes | 16:38 |
| sforshee | cwayne: yes. There does need to be some plan for how a vendor would supply the file for their devices though, as we obviously aren't going to throw all of them into powerd. | 16:38 |
| cwayne | right | 16:39 |
| cwayne | sforshee: that's why i was asking about XDG_DATA_DIRS, as we have some dirs in the custom tarball that are in XDG_DATA_DIRS, so if we have powerd look there, we could theoretically just include that .xml into that vendor's custom tarball | 16:39 |
| ogra_ | jdstrand, heh, cool | 16:39 |
| === Rh0nda is now known as Rhonda | ||
| sforshee | cwayne: I'd suggest chatting with ChickenCutlass & co. about that | 16:43 |
| sforshee | I do wonder if the naming convention for the files might need to be improved in that case | 16:43 |
| cwayne | sforshee: sure thing, thanks | 16:43 |
| ChickenCutlass | cwayne, sure -- are you going to propose an MR | 16:43 |
| cwayne | ha | 16:43 |
| cwayne | ChickenCutlass: we'd need to get an actual plan first, that was just a quick idea that 'might work' | 16:44 |
| ChickenCutlass | cwayne, ok, lets talk about it | 16:44 |
| ChickenCutlass | cwayne, I know we need to do some work on settings as well. | 16:44 |
| cwayne | ChickenCutlass: right, a lot of the settings are taken care of now in the custom tarball by dconf/gsettings | 16:45 |
| sforshee | ChickenCutlass: I do have an open MRs from months ago to address backlight settings ;-) | 16:46 |
| ChickenCutlass | sfeole, really | 16:46 |
| ChickenCutlass | oops | 16:46 |
| ChickenCutlass | sforshee, sorry -- let me look | 16:46 |
| cwayne | if we get all the powerd settings into dconf then this might not be a particularly big issue tbh, but im not sure how realistic that is | 16:47 |
| sforshee | cwayne: dconf isn't going to work | 16:48 |
| sforshee | ChickenCutlass: https://code.launchpad.net/~sforshee/powerd/backlight-settings/+merge/187290 | 16:48 |
| barry | seb128: meeting over. ftr, even in 1.9.1, data files are downloaded to the cache directory, so that would be /android/cache/recovery by default. if that partition is too small, then yes, it'll fail. you could change that in /etc/system-image/client.ini but the problem is that when you reboot to recovery, it won't find the files it needs to do the update. so i think you're back to trying to figure out why that partition is out of | 16:48 |
| barry | space when there's nothing in it | 16:48 |
| cwayne | fair enough | 16:48 |
| sforshee | cwayne: it's something about dbus, powerd being a system-level service and not being able to use the session bus or something like that | 16:49 |
| sforshee | so for backlight I had made a dbus api with the idea that something in the shell would keep the settings and tell powerd about them | 16:50 |
| cwayne | hm, ok.. there's a system bus too isn't there? | 16:51 |
| sforshee | yeah but then the settings end up stored somewhere different and you end up with other badness | 16:51 |
| seb128 | barry, for whatever reason, after a reboot I've free space but the download service doesn't seem to download anything | 16:51 |
| sforshee | I don't know much about it, but it sounded like it was a bad idea for powerd to use dconf | 16:51 |
| barry | seb128: perhaps it thinks you're on the latest version already? system-image-cli --info will tell you what it thinks you're on and system-image-cli --dry-run will tell you what it wants to update you to | 16:52 |
| seb128 | [systemimage] Jan 09 16:51:58 2014 (2908) Running group download reactor | 16:53 |
| seb128 | [systemimage] Jan 09 16:51:59 2014 (2908) Group download reactor done | 16:53 |
| seb128 | [systemimage] Jan 09 16:51:59 2014 (2908) Upgrade path is 119 | 16:53 |
| seb128 | so I guess it's trying to update | 16:53 |
| cwayne | sforshee: sounds reasonable enough | 16:53 |
| barry | yep (was that --dry-run?) | 16:53 |
| seb128 | barry, no, I've been trying "system-image-cli -c trusty -b 0 -v" | 16:54 |
| === gatox_lunch is now known as gatox | ||
| seb128 | barry, or maybe it's downloading but in another place, the cache dir usage doesn't change anymore | 16:56 |
| seb128 | barry, I'm going to wait for a while and see what happens | 16:56 |
| barry | seb128: you *could* try with -vv to get really verbose output, but that at least would give you console output for progress coming from ubuntu-download-manager. when s-i requests a group download of the data files (after the upgrade path is calculated), it basically just has to wait until u-d-m tells it the downloads are finished. | 16:56 |
| seb128 | barry, where is u-d-m downloading? | 16:57 |
| seb128 | e.g where does it store the tmp files? | 16:57 |
| barry | seb128: it stores the data files directly in the /android/cache/recovery | 16:57 |
| seb128 | I don't have a such directory | 16:57 |
| barry | technically, the `cache_partition` setting in /etc/system-image/client.ini | 16:57 |
| barry | seb128: that's supposed to be a mounted recovery partition so that when recovery runs on reboot, it sees all the files it needs, including ubuntu_command which gets written as the very last thing | 16:58 |
| barry | seb128: so that seems like the root problem. the ubuntu side has to put the files in a directory that's mapped to a recovery side partition | 16:59 |
| seb128 | barry, something is weird with my device, I think it's going to be easier to whipe out and reinstall | 16:59 |
| barry | seb128: probably ;) | 16:59 |
| seb128 | barry, thanks for the help in any case ;-) | 16:59 |
| barry | seb128: sure thing! i've seen this once before, though i don't remember where. it seems like there are some cases where the recovery partition doesn't get mapped into the ubuntu side. perhaps stgraber has seen that or has thoughts on how that can occur | 17:00 |
| === greyback|away is now known as greyback | ||
| === Guest26569 is now known as Kyle | ||
| rtg | ogra_, rsalveti: does phablet-flash support the Nexus 7 (2013) model yet ? | 17:39 |
| rsalveti | rtg: nops, still working to get an image for it | 17:39 |
| rtg | rsalveti, ok. I've got a flo kernel about ready. | 17:39 |
| rsalveti | rtg: great, is that available somewhere? | 17:40 |
| rsalveti | will be useful for me soon | 17:40 |
| rtg | rsalveti, not yet, but it could be. I'd kind of like to test it first... | 17:40 |
| rsalveti | rtg: right, no worries, if you have the tree somewhere at least it would already be useful | 17:41 |
| rsalveti | rtg: would be nice if you could also rebase our kernel changes on top of the latest nexus 4 (mako) tree (4.4.2) | 17:41 |
| rtg | rsalveti, its in the trusty repo under the 'flo' branch. | 17:41 |
| rsalveti | rtg: great, thanks | 17:41 |
| rtg | rsalveti, I'll get mako on my todo list. | 17:42 |
| rsalveti | but don't push the mako changes to the archive until we got a working image for it | 17:42 |
| rsalveti | rtg: great, thanks | 17:42 |
| rtg | rsalveti, I'll upload everything to the c-k-t PPA and you can just pocket copy from there | 17:42 |
| rsalveti | rtg: great, that would be awesome | 17:43 |
| rtg | rsalveti, uploaded linux-flo - 3.4.0-0.2 to https://launchpad.net/~canonical-kernel-team. No guarantees on functionality. I started with flo_defconfig, then added Ubuntu packaging. | 17:57 |
| rsalveti | rtg: sure, no worries, I should be able to give it a try soon | 17:57 |
| rsalveti | and thanks | 17:57 |
| rtg | rsalveti, so where would I find the mako updates ? the cyanogenmod repo on phablet.ubuntu.com hasn't been updated in 6 months. | 17:59 |
| rsalveti | rtg: from the same aosp tree you used for flo | 17:59 |
| rtg | rsalveti, by golly, there _is_ a mko in there. | 17:59 |
| rtg | mako* | 17:59 |
| rsalveti | yeah, should be a different branch | 18:00 |
| rtg | kitkat-mr1 ? | 18:00 |
| rsalveti | rtg: should be | 18:00 |
| rtg | rsalveti, ack | 18:00 |
| === alan_g is now known as alan_g|EOD | ||
| === dandrader|lunch is now known as dandrader | ||
| kenvandine | the haptic feedback when switching tabs in the indicators is terribly annoying... | 19:02 |
| === josepht_ is now known as josepht | ||
| thomi | Saviq: did you get anywhere with calling close() on the touch device before creating a new one? | 19:13 |
| mhall119 | beuno: do you know what the click scope uses to order More Suggestions? | 19:30 |
| dobey | mhall119: the scope doesn't sort them, iirc. it's just the order we get from the server | 19:33 |
| mhall119 | dobey: ok, thanks | 19:33 |
| mhall119 | dobey: what project should I file a bug on that against? | 19:33 |
| dobey | mhall119: click-package-index is the project for the server side | 19:34 |
| mhall119 | not sure if a bug for sorting should go against the server or the scope | 19:34 |
| dobey | depends on the bug | 19:35 |
| barry | xnox: do you have some time to chat about emulator+autopilot? | 19:36 |
| xnox | barry: yeap =) | 19:36 |
| dobey | part of the problem i think, is that there's no way to do filtering yet in the dash | 19:36 |
| mhall119 | the bug will be "sort suggestions by some 'hotness' criteria" | 19:36 |
| xnox | barry: i have latest run results in, and it's 1h40m from juju bootstrap, to copying all the logs back to the host =))))) | 19:36 |
| dobey | mhall119: i think the default search is by either popularity or "newnewss" | 19:36 |
| dobey | err, newness | 19:36 |
| mhall119 | dobey: doesn't look like newness, both the first and last item are fairly recent | 19:37 |
| mhall119 | how would popularity be decided? # of downloads? | 19:37 |
| mhall119 | since R&R isn't active yet | 19:37 |
| dobey | mhall119: no idea. beuno or JamesTait would have to answer how sorting is decided on the server. | 19:41 |
| mhall119 | OMG! my phone vibrates! | 19:54 |
| cyphermox | yeah! :) | 19:55 |
| mhall119 | would be nice to have it vibrate on long-press though, not normal press, in the dash | 19:55 |
| mhall119 | wow, rotation seems much faster in this new build | 19:58 |
| davmor2 | mhall119: date last uploaded? | 20:02 |
| mhall119 | davmor2: maybe | 20:03 |
| davmor2 | mhall119: ie your app is appended to the end of the queue on update | 20:03 |
| mhall119 | davmor2: not ideal, still | 20:03 |
| davmor2 | mhall119: R&R should in theory turn it round very quickly | 20:03 |
| kaimast | what does vibrate? | 20:12 |
| nik90 | kaimast: when you press buttons and tabs it vibrates | 20:13 |
| nik90 | haptic feedback | 20:13 |
| nik90 | although when I press the toolbar button it doesnt vibrate | 20:14 |
| kaimast | guess it is just not supported on maguro | 20:14 |
| nik90 | kaimast: could be | 20:14 |
| kaimast | just updated. nothing vibrates for me | 20:14 |
| nik90 | image r119? | 20:15 |
| kaimast | do the nexus 4 and 5 still have the notification led? would love to use that on ubuntu touch too | 20:15 |
| kaimast | it could use the color from the background gradient | 20:15 |
| kaimast | nik90: yeah i think i updated to r119 | 20:15 |
| nik90 | kaimast: that could be misleading..the notification led color usually indicates a activity type like red->charging, blinking red->battery low etc.. | 20:17 |
| nik90 | I wouldnt want to change it to background gradient | 20:17 |
| kaimast | on android it does that | 20:17 |
| kaimast | green for whatsapp message, white for email, blue for skype message | 20:17 |
| kaimast | etc | 20:17 |
| kaimast | and can be also used to indicate charging (but that only works for me on cyanogenmod) | 20:18 |
| kaimast | its really awesome you look at your phone and directly know what happened | 20:18 |
| kaimast | (i have a galaxy nexus. maybe the behaviour changed) | 20:19 |
| nik90 | whatsapp does it, but it isn't really helpful since if you have multiple apps which change the behavior, the user wouldn't remember which light colors meant what | 20:20 |
| nik90 | it is better to assign categories to them like white->messages, green->charge complete, red->charging and so on | 20:21 |
| nik90 | I wouldn't give the freedom to apps to change them | 20:21 |
| nik90 | but again this is just my personal opinion | 20:21 |
| === dandrader is now known as dandrader|afk | ||
| kaimast | that would be cool too. but it is not supported at all currently, or is it? | 20:22 |
| mhall119 | I'd say blue for messages, since the message indicator turns blue | 20:26 |
| mterry_ | tedg, what is the relationship between indicator-messages and the notification server? Does i-m listen to notifications too or do apps tell i-m directly as well as emitting a notification? | 20:27 |
| tedg | mterry_, Apps tell both of us. | 20:34 |
| tedg | mterry_, Well, they give each different information. | 20:34 |
| === dandrader|afk is now known as dandrader | ||
| tedg | xnox, I love "in a mere 1h40m" -- fast is relative :-) | 20:39 |
| mterry_ | tedg, so with a split greeter, how do we envision i-m sharing its contents? | 20:40 |
| tedg | mterry_, i-m in the session -> account service schema -> i-m in greeter | 20:41 |
| mterry_ | tedg, that works mostly. But feeding back content seems awkward. Like answering an IM | 20:41 |
| mterry_ | tedg, I guess we could use AS for that too... | 20:41 |
| tedg | mterry_, No, we're not feeding back. There's no way to reply unless you unlock. | 20:41 |
| mterry_ | tedg, ah OK | 20:42 |
| mterry_ | tedg, is that work scoped under your team or am I doing that? | 20:42 |
| tedg | mterry_, Last I checked we're not putting the message as well, just the sender. | 20:42 |
| tedg | mterry_, Our team, I think it's assigned to charles | 20:42 |
| mterry_ | tedg, OK. Do you have a design mockup? | 20:42 |
| mterry_ | tedg, OK, awesome | 20:42 |
| * mterry_ hugs charles | 20:42 | |
| mterry_ | So that leaves notification sharing to me | 20:42 |
| tedg | mterry_, No :-( We have conversations, pushing for more design. | 20:42 |
| tedg | Is notification sharing a requirement? It seems like 90% of the time on the lock screen the screen is off anyway. | 20:43 |
| tedg | For messages having the envelope turn blue is probably all you need/want. | 20:43 |
| mterry_ | tedg, current thinking is that we'll use generic notification handling for phone calls | 20:44 |
| mterry_ | So we do it once for phone calls and then we can re-use for other notifications | 20:44 |
| tedg | If we don't run the telephony app in the greeter, then you'd have to enter your PIN to answer a call, no? | 20:45 |
| mterry_ | tedg, yes | 20:46 |
| mterry_ | That made sense to me at the time, but I suppose other phones don't do that... | 20:47 |
| tedg | So it seems we're going to have to have the app there, listening to ofono, and displaying it's own notifications. You don't want from the user session. | 20:47 |
| tedg | (at least for phone calls) | 20:47 |
| tedg | No, it's hard to enter your PIN/password quick enough before VM picks up. | 20:48 |
| sergiusens | tedg, that should happen on boot (PIN) | 20:49 |
| sergiusens | imo | 20:49 |
| mterry_ | tedg, right... I have code for that already actually. | 20:49 |
| tedg | sergiusens, SIM PIN, yes, login could be PIN locked as well. | 20:49 |
| mterry_ | sergiusens, this is user PIN not phone SIM PIN | 20:49 |
| sergiusens | mterry_, ah; then I take my comment back | 20:49 |
| sergiusens | although auth to answer is a stretch, do other OSes do that? | 20:50 |
| tedg | NO TAKE BACKS! ;-) | 20:50 |
| sergiusens | tedg, well my commen has a fundamental flaw; without entering the sim pin I don't think you can receive calls anyways :-P | 20:51 |
| sergiusens | comment | 20:51 |
| tedg | Heh | 20:51 |
| kaimast | is there any progress on the e-mail app? | 21:12 |
| dfgnndgk | Hello. Is there ethernet over usb dongle supported out of the box by Touch on Nexus 10? What is the current kernel? | 21:18 |
| xnox | tedg: well that's 9 instances ;-) | 21:18 |
| xnox | tedg: and without unity8, current testing on devices takes ~6h =) | 21:18 |
| xnox | tedg: so i'm good on the books ;-) | 21:18 |
| xnox | tedg: i want to be achieve << 30m however. | 21:19 |
| xnox | s/be// | 21:19 |
| tedg | xnox, As Einstein would say, it's all relative ;-) | 21:19 |
| xnox | =)))))))) | 21:19 |
| xnox | at 700Mhz emulated CPU it's awesome. | 21:19 |
| jdstrand | oh, haptic feedback :) | 21:20 |
| kenvandine | jdstrand, it's actually really bothering me! | 21:20 |
| * jdstrand launches another app to see it in action :) | 21:20 | |
| jdstrand | iirc, that is configurable on android | 21:21 |
| kenvandine | i was excited the first time i felt it... but now it seems like everything i do triggers it | 21:21 |
| jdstrand | will it be for us too? | 21:21 |
| kenvandine | i hope so... and also limit where we use it | 21:21 |
| jdstrand | yeah | 21:21 |
| kenvandine | most annoying for me is when changing tabs | 21:22 |
| kenvandine | flicking through the indicators in particular | 21:22 |
| jdstrand | oh, heh, I just noticed that | 21:22 |
| kenvandine | i've been cursing at my phone all day :) | 21:22 |
| jdstrand | yeah-- every flick and checkbox | 21:22 |
| jdstrand | well, it works :) | 21:22 |
| kenvandine | indeed, which is a nice step! | 21:23 |
| kenvandine | not to trim down usage to make it more meaningful | 21:23 |
| * jdstrand nods | 21:23 | |
| kenvandine | s/not/now/ | 21:23 |
| jdstrand | app launch seems reasonable so you know that something is happening | 21:23 |
| jdstrand | pulling a recent app from the bg, not so sure | 21:24 |
| kenvandine | yeah | 21:24 |
| jdstrand | anyhoo-- I'm sure there will be lots of feedback on the feedback | 21:24 |
| kenvandine | and things with immediate feedback, like a checkbox shouldn't | 21:24 |
| kenvandine | haha | 21:24 |
| kenvandine | yeah | 21:24 |
| * jdstrand wanted to somehow jok about 'feedback is welcome' but couldn't pull it off | 21:24 | |
| kenvandine | i'll look forward to seeing the feedback on feedback | 21:25 |
| kenvandine | :-p | 21:25 |
| jdstrand | :) | 21:25 |
| mhall119 | kenvandine: I'm filing bugs against unity8 with feedback on feedback | 21:26 |
| mhall119 | bug #1267592 | 21:27 |
| ubot5 | bug 1267592 in Unity 8 "Vibrate should happen on long-press, not normal activation" [Undecided,New] https://launchpad.net/bugs/1267592 | 21:27 |
| kenvandine | mhall119, feedback is welcome! | 21:27 |
| jdstrand | there you go! | 21:27 |
| mhall119 | you say that now ;) | 21:27 |
| jdstrand | that was what was missing-- the setup | 21:27 |
| kenvandine | jdstrand, i found a way to use your whit :) | 21:27 |
| jdstrand | mhall119 makes a good straight man | 21:27 |
| kenvandine | i can't even spell that ;) | 21:28 |
| mhall119 | kenvandine: can we have a shorter "tick" style feedback for the OSK? | 21:28 |
| mhall119 | jdstrand: that's what she said? | 21:28 |
| kenvandine | mhall119, don't ask me... i'm not actually in the know :) | 21:28 |
| jdstrand | ohh... | 21:28 |
| jdstrand | I won't be touching that | 21:28 |
| kenvandine | :) | 21:28 |
| jdstrand | ;) | 21:28 |
| mhall119 | that's what....nvm | 21:28 |
| * jdstrand hates haptic feedback on the keyboard. I hope that is easily configurable | 21:30 | |
| === salem_ is now known as _salem | ||
| mhall119 | kenvandine: FWIW, I also filed bugs to add vibration to incoming calls and messages | 21:31 |
| dobey | haptic feedback? you have a device that shocks your fingers with the keyboard? | 21:31 |
| jdstrand | dobey: its working on my mako with 119 | 21:32 |
| kenvandine | mhall119, i like that | 21:32 |
| popey | please can I shock mhall119 when I touch my keyboard | 21:32 |
| jdstrand | mhall119: oh yes, good idea | 21:32 |
| popey | where do I file a bug for that? | 21:32 |
| dobey | i mean, my thinkpad did that, but i don't think it was haptic feedback | 21:32 |
| jdstrand | oh, haha | 21:32 |
| mhall119 | no, bad popey | 21:34 |
| dobey | the google phones just vibrate right? the same vibration motor as when you get a call or sms or whatever? | 21:34 |
| mhall119 | dobey: I don't know if it's vibration or a "click" sound over the speaker | 21:34 |
| dobey | oh | 21:34 |
| * mhall119 doesn't have an Android device handy to test | 21:34 | |
| dobey | webos does a very subtle vibration when it spell-corrects a word | 21:35 |
| kenvandine | iirc, on android it is a shorter vibration | 21:35 |
| kenvandine | less jarring | 21:35 |
| dobey | right | 21:35 |
| === rickspencer3_ is now known as rickspencer3 | ||
| kenvandine | or maybe that is device specific, and this is just what the nexus 4 does | 21:36 |
| kenvandine | i've never run android on it | 21:36 |
| * dobey was just mocking the use of 'haptic' though | 21:36 | |
| kenvandine | dobey, i knew you were trolling | 21:36 |
| mhall119 | it was the correct use, wasn't it? | 21:37 |
| kenvandine | you're predictable :) | 21:37 |
| dobey | haptic on touch screens usually means that the keyboard keys would feel like a keybaord when you touch them. | 21:37 |
| rickspencer3 | dobey, I think that's a rather constrained usage of the term "haptic" | 21:38 |
| rickspencer3 | from a human factors perspective, the term is used much more broadly | 21:38 |
| mhall119 | dobey: wikipedia says you're wrong, and everbody knows wikipedia never lies | 21:39 |
| * mhall119 expects that after the next edit, wikipedia will say he's right | 21:40 | |
| * kenvandine watches dobey go edit wikipedia | 21:40 | |
| mhall119 | lol | 21:40 |
| mhall119 | oh, idea, before entering *any* online arguement, pre-emptively edit every relevant wikipedia article to coincide with your claims | 21:40 |
| kenvandine | :) | 21:41 |
| mhall119 | Fact: Upstart is both better tasting *and* less filling than SystemD, wikipedia confirms it | 21:41 |
| kenvandine | rofl | 21:42 |
| mhall119 | ok, back to bug filing | 21:43 |
| dobey | editing wikipedia is for nerds | 21:43 |
| kaimast | btw it is written "systemd" ;) | 21:47 |
| kaimast | if it is incorrectly spelled your argument is automatically invalid | 21:47 |
| mhall119 | upstart is far more flexible in that regard :) | 21:48 |
| dobey | it certainly is an apt name | 21:50 |
| kaimast | talking about upstart, I am still waiting for kenvandines approval for the friends upstart script | 21:51 |
| kenvandine | kaimast, i hadn't seen that | 21:53 |
| kenvandine | i'll look for it | 21:53 |
| kaimast | no problem. would be nice if we could merge all the open requests. I already have another branch that implements image previews and also add settings (that are saved/synced via ubuntu one) | 21:54 |
| mhall119 | careful kaimast, he might make you the new maintainer :) | 21:56 |
| mhall119 | Saviq: does the unity8 project still contain the welcome screen, or has that been broken out? | 21:57 |
| kenvandine | kaimast, responded | 21:59 |
| kenvandine | kaimast, i love the idea, but we should make it conditional to keep load low when the phone session starts | 22:00 |
| kaimast | okay thanks for the feedback | 22:00 |
| kenvandine | thanks for the branch! | 22:00 |
| kenvandine | i know i would want to enable it :) | 22:00 |
| mhall119 | who did the haptics work? | 22:28 |
| mhall119 | bfiller: ^^ | 22:29 |
| pmcgowan | mhall119, I think just long press is too restrictive, added design to the bug | 22:40 |
| mhall119 | thanks pmcgowan | 22:40 |
| mhall119 | feedback on my feedback feedback, ^^ jdstrand that's how it's done | 22:41 |
| jdstrand | heh | 22:53 |
| mhall119 | bzoltan: you don't happen to still be around, do you? | 22:58 |
| RobbyF | with this convergence plan moving forward will the desktop be using click packages as well? | 22:58 |
| mhall119 | RobbyF: yes | 22:58 |
| RobbyF | that will be the 'norm'? | 22:58 |
| mhall119 | yes | 22:58 |
| mhall119 | click packages are beneficial, whether convergence is at play or not | 22:59 |
| RobbyF | cool. will they be theme capable? | 22:59 |
| mhall119 | RobbyF: that's not click dependent, but yes SDK apps will be themeable (how much of that works right now I'm not sure) | 22:59 |
| mhall119 | or, are you asking if themes can be installed from click packages? | 23:00 |
| RobbyF | I suppose the first but the later sounds interesting as well. | 23:00 |
| RobbyF | are all click packages sandboxed/jailed then? | 23:01 |
| mhall119 | I believe the plan is to eventually support themes/wallpapers/icons/sounds/etc to be click packages, but that's going to require some additional work since they don't live in confinement | 23:01 |
| mhall119 | RobbyF: yes | 23:01 |
| mhall119 | well, they don't *have* to be, there's an "unconfined" security profile, but 3rd party apps in the store won't be able to use it | 23:02 |
| mhall119 | so there are "click package requirements" and "Ubuntu store requirements" | 23:02 |
| mhall119 | confinement being a store requirement | 23:02 |
| RobbyF | ubuntu store to replace ubuntu software centre? | 23:03 |
| mhall119 | same thing really, but "store" is shorter to type :) | 23:03 |
| RobbyF | kk lol | 23:03 |
| RobbyF | I'm looked around a bit but i still don't see an email client. perhaps I'v over looked it? | 23:04 |
| mhall119 | RobbyF: only the GMail webapp for now | 23:07 |
| RobbyF | settings > accounts> google - it appears it does nothing, (contacts, gmails, google plus, google maps) in regards to saving login information ect. Is this the correct behaviour right now? | 23:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!