[00:14] So apparently autopilot 1.4 is needed to run FileManagers autopilot tests. What is the best way to get that version on Ubuntu 13.10? Saucy provides autopilot 1.3 === Guest42571 is now known as annerajb [00:18] ajalkane: Hi, for 1.4 on Saucy you'll need to use a ppa. Right now we're in the middle of reorganizing our ppas to be better, but for right now you can use ppa:autopilot/experimental. Tomorrow or so, if you can wait that long, we'll be releasing to ppa:autopilot/1.4 [00:20] veebers: thank you, that's excellent [00:38] Ah well, I probably best wait for ppa:autopilot/1.4. Using the experimental ppa I got unmet dependencies === duflu_ is now known as duflu === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === icarusfactor is now known as factor [04:56] hi there, I have a problem updating my Nexus 4 to version 121 [04:57] every time it downloads and I click 'Apply and restart' it fails with 'no file was downloaded [04:57] What should I try? [04:59] KathyReid: are you letting the phone sit between downloading and hitting that button? [05:00] I noticed on my Nexus 4 that it can lose the download file if the phone suspends after downloading [05:00] mhall19: not sure what you mean by sit? [05:00] on my Nexus 7 that is, not my 4 [05:00] aaah suspending [05:00] good question [05:00] It's taking round 30 mins to download [05:00] my internet sucks [05:01] yeah, I think it has something to do with it downloading to a temp location or something, then when the system-settings app is suspended (when the phone is suspended) the temp files are removed [05:01] KathyReid: if it's easier, you can phablet-flash from an Ubuntu desktop [05:01] mhall119: that might be easier [05:02] I'm running 13.04 here [05:02] might phablet-flash it. It would be easier [05:02] as long as you *don't* use -b, it shouldn't delete any user data on the phone [05:03] you can use --channel trusty and --revision 121 to force the exact image to use [05:04] it's throway [05:05] I have all my Android stuff backed up on my 'live' Nexus 4 [05:05] (I have 2 - one KitKat, one for playing with Touch) [05:05] phablet-flash ing as we speak [05:05] getting 17kbps down from wherever the image is :S [05:09] mhall119: thanks heaps for your advice. Much appreciated. [05:11] mhall119, do we have a bug in for that? [05:14] cwayne: I never filed one, no [05:14] shame on me [05:14] I'll try to re-create it on the next stable release [05:19] cwayne: also happy to try replicating [05:49] barry: Qt 5.2 -> https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2 [07:57] good morning === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [09:21] What is th best place to learn making apps for Ubuntu Touch? developer.ubuntu.com have like... 1 tutorial... Any more? [09:23] fr33r1d3, there is an #ubuntu-app-devel IRC channel [09:23] ok, cool. will check it out. [09:23] and there is a G+ circle where people filed tutorials etc [09:44] Ubuntu Touch support for Nexus 4 will continue? [09:44] yes [09:44] and the new nexus 7 [09:45] * Laney looks at his old one ... [09:45] Laney: you look sadly? ;) [09:47] could put android back on it :P [09:47] didrocks, you dont ? [09:47] didrocks, we will stop providing images (no matter how broken or unsupported) which means you cant use the HW as development device anymore [09:49] ogra_, it means you can start using the device though! (by putting android on it :p) [09:49] ok ok ok, -> [ ] [09:49] ;-) [09:49] didrocks, after asac's decision i went from four dev devices i have to one, i cant do anthing with my private N4 because i use it for dogfooding, that means i have to do development and testing on the new N7 i have [09:49] seb128, heh [09:49] * ogra_ checks if it's friday already [09:49] he has three spare fridays from the holidays [09:49] indeed! [09:50] and I'm just using like 15 minutes at the time [09:50] didrocks, for me that means a massive slowdown, i would at lest like to have images available for development, even if they are not supported [09:50] lol [09:50] what are the chance we get community maintained build for it? [09:50] ogra_: still can be a nice build machine [09:50] though I've to admit things never worked great on the n7 [09:51] as seb128 told, that never worked greatly to be useful enough [09:51] sounds was not working for a while, Mir being slow and buggy [09:51] hence the "no sadness" [09:51] didrocks, how ? i cant install a new image anymore [09:51] ogra_: the ubuntu desktop one, as we did in the past? [09:51] seb128, yeah, i dont mind, i still would like to be able to test click packages on it quickly, or do a build or whatnot [09:52] didrocks, i have about 20 machines where i can do normal ubuntu arm builds ... i want to have the readonly image to be able to test stuff in context etc [09:52] ogra_: you do, I don't ;) [09:53] it's my only arm builder which isn't the N4 [09:53] I also feel bad if there are people who purchased their own on our previous advice [09:53] Laney: agreed on that one [09:53] yeah, thats seriously bad ... everyone shoulld have two deviaces at least [09:53] and yes, we kind of let the community people down here :/ [09:54] what are the chance we get a community maintainer build for it? [09:55] seb128, not bad perhaps ... but you will have to dig out the zip from xda-developers, do manual installs etc etc [09:55] and wont get OTA upgrades [09:56] we still dont have any infrastructure for ports in place that would provide either [09:56] right... [09:57] * ogra_ knows that personally he will have a massive slowdown in writing fixes for the plumbig layer with that decision,, simply because i'm restricted to one device for doing work now [10:18] ogra_: till end of month maguro is still great [10:18] asac, i dont care if it is great, but we are effectively taking away development devices [10:19] today i can test a proposed image while i develop a new feature on another device and do a low level fix in the system on even another one, all on proper touch images [10:20] i dont care if the two i dont use for testing are supported [10:20] in the future i will have exactly one device to do all these three tasks on [10:20] that will massively slow me down [10:21] thats why i wouold like us to go on building images ... we dont need to support them or give them any love as long as they are flashable and adb works [10:22] hm, do we have any app which actually uses QAccelerometer? [10:22] isnt the orientation done by the accelerometer sensor too ? [10:22] I'm writing tests for it, and it seems neither its readingChanged() signal is ever called, nor are its .reading() values ever updated [10:23] ogra_: yes, but wired internally [10:23] oh, right [10:23] well, but you should be able to get physical events from through the API it nontheless [10:23] if not, thts surely a bug [10:23] I've been chasing why my readingChanged slot never gets updated (as I'm a Qt newbie), but it seems it's not due to my connect and slot, but as it's never been called in the first place [10:24] tvoss, ^^ [10:25] ok, I'll track it down [10:30] ah, it's internally wired through a queued connection, so that needs a main loop [10:59] Morning all [11:01] pitti, hey there [11:01] hey tvoss [11:02] morning sil2100! Do you know in which image will the Evernote account plugin land? [11:03] pitti, hey there, I get test failures with the platform-api in http://pastebin.ubuntu.com/6749837/ [11:04] qemu: Unsupported syscall: 257 [11:04] eek [11:04] tvoss: is that an emulated arm qemu instance? [11:04] pitti, that's an armhf schroot [11:04] ah, yes [11:04] dpm: morning! It's in the archive now and I think didrocks wanted to seed it now for touch, but not sure if t's in already [11:05] tvoss, pitti, that shouldnt do any harm though [11:05] tvoss: that means that system emulator qemu doesn't support timer_create(), but that's what the emulated sensors use [11:05] * ogra_ would have to look up which syscall it is, but it is definitely nothing that could cause breakage [11:05] but that's the stanard POSIX timer [11:05] dpm: it will be in the next one [11:05] dpm: so you can publish the click apps if needed [11:05] awesome, thanks sil2100 and didrocks! [11:05] so if that doesn't work, I don't know what else it should use [11:05] pitti, I wonder how we pass CI if that is a general problem [11:06] tvoss: I thought MPs run on real iron, not in emulated qemu [11:06] pitti, hmmm ... [11:06] bug 1042388 [11:06] bug 1042388 in QEMU "qemu: Unsupported syscall: 257 (timer_create)" [Undecided,Confirmed] https://launchpad.net/bugs/1042388 [11:06] we've seen lots of bugs in qemu (when running tests during arm PPA builds, for example) [11:06] pitti, how can I then build an armhf package locally? [11:07] tvoss: "sudo apt-get build-dep platform-api", apt-get -b platform-api ? [11:07] i. e. exactly like on a desktop [11:07] pitti, hmmm, that will run the package tests and those are failing here [11:07] or bzr branch lp:platform-api, and cmake . && make -j4 [11:07] pitti, sure :) [11:07] tvoss: that's how I did it, anyway [11:08] tvoss: you mean platform-api's tests are failing on current phone builds? [11:08] I can look into that [11:08] pitti, so I'm trying to build a platform-api branch with your tests in an armhf schroot with dpkg-buildpackage [11:09] anything which gives me a break from this (*$#($#* Qt signal/slots in qtubuntu-sensors is a welcomed break :) [11:09] pitti, that executes the test suite which fails [11:09] tvoss: right, see above, qemu doesn't support that [11:09] tvoss: the emulated sensors need posix timers [11:09] but it works fine on real iron [11:09] (both arm and x86) [11:10] pitti, okay, I will disable the tests then for local purposes. Should we have a CMake option for that? [11:10] tvoss: DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage [...] [11:10] hah :) [11:10] tvoss: that's the standard way of not running tests for a package build [11:11] FYI: [11:11] override_dh_auto_test: [11:11] ifeq (, $(findstring nocheck, $(DEB_BUILD_OPTIONS))) [11:11] cd obj-* && ctest --verbose [11:11] endif [11:11] ^ from debian/rules [11:11] pitti, tvoss just pull the fix from the git tree (in tteh bug i posted above) [11:11] https://bugs.launchpad.net/qemu/+bug/1042388/comments/15 [11:11] Ubuntu bug 1042388 in QEMU "qemu: Unsupported syscall: 257 (timer_create)" [Undecided,Confirmed] [11:12] oh, nice! === tvoss is now known as tvoss|lunch === _salem is now known as salem_ === chihchun is now known as chihchun_afk [12:05] hey Saviq, a quick question: at a glance, would you know which of these indicator-* links on this page are relevant for translating the phone interface? https://translations.launchpad.net/ubuntu/trusty/+lang/ca - or if it's easier, which ones are not relevant? [12:06] I'm preparing a call for translations to point people to those which are more interesting for the phone [12:06] ogra_, tvoss|lunch: FYI, building qemu with these two patches here, then trying platform-api with them [12:06] pitti, great, thank you === tvoss|lunch is now known as tvoss [12:06] this seems to hit more users [12:07] tvoss: and FTR, building documentation under qemu emulation sucks :) [12:08] pitti, it does, indeed. [12:09] dpm, -bluetooth, -datetime, -power, -sound, -network, -location, -messages [12:09] dpm, ps aux | grep indicator on your phone ;) [12:09] Saviq, ah, nice, thanks :) [12:11] Saviq, would you happen to know as well which scopes are relevant for Unity 8 translations? On that same list in LP I know we're using unity-scope-home, but I'm not sure which other unity-scope-* and unity-lens-* ones are relevant [12:13] dpm, -mediascanner and -click === MacSlow is now known as MacSlow|lunch [12:14] Saviq, ah, exactly those which are not translatable, well spotted :) === alan_g is now known as alan_g|afk [12:25] tvoss: hm, trying to build platform-api has been stuck on "Generating member index..." for 25 minutes now.. does it take that long for you as well, or did qemu get stuck for me? [12:26] it's not even using CPU any more [12:26] * pitti kills it [12:26] pitti, qemu got stuck [12:26] pitti, it's dead [12:26] pitti, we should switch DOT_NUM_THREADS in doc/Doxyfile.in to 1 [12:26] pitti, that solves the issue [12:26] ok, /me tries again [12:26] isn't platform api cross buildable yet? [12:27] certainly not running its tests [12:27] tvoss: I want to replicate the failure before I try with the fixed qemu [12:27] build on device [12:27] * sergiusens uses a chromebook just for building [12:27] same here ... and a sabrelite [12:27] sergiusens: well, I usually do [12:27] pitti, yup [12:28] sergiusens: the point is that I want to test a qemu fix for posix_timers, which the platform-api test suite uses :) [12:28] so I do want to try that one in an armhf schroot [12:28] in fact I just created one, I usually just do stuff right on the G4 [12:28] so much faster [12:28] nice [12:28] tvoss: http://people.canonical.com/~pitti/tmp/qemu-posix-timers/ in case you want to try yourself [12:29] pitti, cool, will get to it after I have finished building some packages [12:29] tvoss: I will test it, it was just an FYI [12:29] * pitti toddles off for lunch while it's building [12:29] pitti, enjoy :) [12:31] but, FTR: whoever made it so easy to build an armhf schroot (mk-sbuild --arch=armhf trusty --type=file): KUDOS! [12:31] xnox: ^ could have been you? :-) [12:37] pitti, heh, that was a several year long process :) [12:57] pitti, hi, so i ended up following what you did for timedated for hostnamed to allow us to write to /etc/hostname and /etc/machine-info, any chance of a MR? [12:57] https://code.launchpad.net/~cwayne18/livecd-rootfs/machine-info-writable/+merge/201542 and https://code.launchpad.net/~cwayne18/ubuntu/trusty/systemd/symlink-support-hostnamed/+merge/201540 [12:58] Hey all, would anyone be able to test out a branch the sudoku-app has to introduce user metrics to the welcome screen? I tried testing on my device, but I haven't had any luck. You'll probably want to "Show Hint" until the game completes. Branch: https://code.launchpad.net/~dinko-metalac/sudoku-app/usermetrics [12:59] cyphermox, ^ (the MR's I promised you) [13:06] cwayne: cool, thanks! [13:06] cwayne: looking [13:08] tvoss: hm, not sufficient yet :( [13:08] 1: TestSensor ERROR: Failed to create timer: Invalid argument [13:09] pitti, hmmm ... [13:09] cyphermox, i added /etc/hostname in as writable, because honestly, it almost seems like a bug that everything has the hostname 'ubuntu-phablet' (at least it's certainly obnoxious if you're using more than one device and forget which one is connected :P) [13:09] cwayne: agree. [13:11] cyphermox, so this way, we could even make an upstart job to set hostname to device-name if we wanted to :) [13:15] cwayne: reviewed; srsly, this is sheer madness [13:15] we are getting ourselves deeper and deeper into that swamp of "we break /etc/" hacks [13:15] [13:15] pitti, :/ yeah [13:16] cwayne: do you want systemd uploaded right now? [13:16] i'm happy to try another way to fix it (although I have no idea how we'd go about doing it) [13:17] write an upstart job that touches /userdata/.writable_image on every boot :P [13:17] dpm, mhall119, popey, would any of you be able to test out a branch Dinko has for the sudoku-app to introduce user metrics to the welcome screen? I tried testing on my device, but I haven't had any luck. You'll probably want to "Show Hint" until the game completes to increment the counter. Branch: https://code.launchpad.net/~dinko-metalac/sudoku-app/usermetrics [13:17] pitti, don't we need to do a landing ask and all that jazz first? [13:17] cwayne: there isn't really -- it's pretty much a design problem ATM [13:17] ricmm_, does enter on the OSK work in the terminal app? [13:17] ricmm_, +for you [13:17] cwayne: ah, ok; please go ahead with that the [13:18] n [13:18] Saviq, oh, was that supposed to be fixed ? [13:18] ogra_, dunno? [13:18] (hasnt worked for 6 weeks or so) [13:18] cwayne: please prod me when you want me to upload then [13:18] pitti, yeah, the only other thing i could think of is either a hack upstart job, or a patch to bluez (which cyphermox -1'd), so i guess this will have to do [13:18] ogra_, ouch [13:18] pitti, will do, thanks a lot! [13:18] yeah [13:19] ogra_, we need to up the priority on that - it seems to break apps that don't have a "Go" button for a text entry [13:19] oh [13:19] cwayne: pitti: the nice solution would be a proper overlay on /etc [13:19] cyphermox: right [13:19] popey, ^^^iirc you had opened the bug for this [13:19] pitti: can't we do that? or are we missing kernel magic for that? [13:20] cyphermox, a) performance issues ... b) no oevrlay support in any mainline or android kernels c) performance issues [13:20] ogra_: boo [13:20] :) [13:21] for /etc/, it's going to get to be really important [13:21] cyphermox: right, our kernels don't support it [13:21] that, or just make all of /etc/ writable. [13:21] we would have taken that path if it would have been easy [13:21] as a fallback we could just keep /etc/ readable as $deity intended to, and copy changed files to an upgraded system image after installation [13:22] which would make the upgrade process slower [13:22] ogra_: well, the current system is far, far away from "easy", too [13:22] ogra_: there aren't thousands of files in /etc [13:22] pitti, agreed [13:22] we keep falling into holes and bugs [13:22] yeah [13:22] well, ask stgraber, he had his reasons for picking that path [13:23] it is his brainchild after all [13:23] well, TBH, it was the easiest way back then for design, but we didn't see all the bad consequences [13:24] we will likely drop the loop mount stuff at some point [13:24] and move to actual partitions [13:24] that's unrelated, though? [13:24] in that course it might be appropriate to also introduce other ways of making stuff writable [13:25] since there will bbe a lot of stuff rewritten anyway [13:25] well we have two ways now: either add it to /etc/system-image/writable-paths [13:25] or put it in /etc/writable [13:25] the former doesn't work for files, only for directories [13:25] we should never ever put files there [13:26] the point is that by 14.10 we need to have found a way thats also appropriate for desktops ... [13:26] ah, i see [13:26] in which you will actually have 1000s of files in /etc [13:26] $ time find /etc | wc -l [13:26] and make system-image upgrades slow as hell worst case [13:26] 2947 [13:26] real0m0.037s [13:26] hardly a big deal [13:27] this is already stat()ing every file, so comparing timestamps for "newer than our base image" won't add more to that === alan_g|afk is now known as alan_g [13:27] well, cpp will be slower, but yeah, marginal [13:27] *cp [13:27] vthompson: ogra_ sure [13:27] you'd only cp a fraction of those [13:28] popey, err, i was referring to Saviq's "no enter key in terminal" [13:28] that too ☻ [13:28] well, convince stgraber [13:28] :) [13:28] and the security team [13:28] vthompson, if you installed the same click version where the apparmor manifest changed (usermetrics addition) , they won't be reprocessed [13:29] ogra_: won't the system on desktop have a mad mix of deb based stuff and click though? In which case the image based updated probably won't be best as we found out already when you add a deb package and the deb.db gets renewed :) [13:29] Saviq: bug 1257791 [13:29] bug 1257791 in Ubuntu Terminal App "Enter and backspace broken in terminal" [Critical,Triaged] https://launchpad.net/bugs/1257791 [13:29] Saviq:/35 [13:29] bah [13:30] davmor2, well, we havent designed the desktop case yet ... and most likely wont even start with that before 14.10 [13:30] didrocks, hey, i just added a landing ask for systemd, do I need to wait around or can I just have it uploaded? [13:30] davmor2, but as i understood we will want the same system setup ... [13:30] davmor2, you'd have a read only image I suppose, so no deb install [13:31] i assume there will go some work into improving the writable mode for people that actually want debs ... [13:31] and otoh there will be a lot debs for apps that might get re-packaged to click [13:32] * ogra_ looks forward to the first libreoffice click package :D [13:32] and the increased data plan to download it [13:32] dont use data plans on desktops :P [13:32] popey: there is an increase on unlimited wow [13:32] Saviq: if you have some input on that bug I'd appreciate it! [13:33] ogra_: depends if your desktop is your phone plugged into a monitor :P [13:34] now who woulld do such crazy stuff ! [13:35] ogra_: Microsoft......Umm no not them.......Androi......No not google...........Wait I know Us :) [13:35] :D [13:39] hi vthompson, I'll try to give it a go, but probably not until this evening. === MacSlow|lunch is now known as MacSlow === cwayne_ is now known as cwayne [13:46] Does anyone know if Canonical is planning to shift to cm-11.0 device trees for porting? [13:46] krabappel2548, there is work going on to port to AOSP 4.4 atm ... [13:47] ogra_: ok, I have an Xperia Z1 and I get a lot of compiling errors [13:47] since there is no cm-10.1 device tree for Z1 [13:47] and not a lot of Snapdragon 800 support in Ubuntu repos maybe [13:47] right, the kitkat port should fix that [13:48] should be ready soon (iirc there are still some hybris issues to be fixed) [13:50] ogra_: ok, thanks for the heads up [13:59] Mirv: thanks, i eventually stumbled on that ;) [14:01] ogra_, hi! Can you point me at the best person to speak to about click package categorisation in the dash? [14:04] JamesTait, hmm, there are several bits involved ... on the store side you need categories first ... that would be beuno i think ... for the click lens you would need a UI that supports them, not ure who works on this ... dobey perhaps ... [14:04] ogra_, it's the UI part I'm most interested in, I'm working on the store side and have a question. :) [14:05] well, looking at the unity-scope-click changelogs it seems dobey does the most commits there [14:05] are you talking about categories or filters? [14:06] dobey, yes. :-P [14:06] "More Suggestions" and "Installed" are categories, "Games" and "Sound & Video" are filters === dandrader is now known as dandrader|lunch [14:07] dobey, so from what I can see, we want to be presenting the Departments as filters in the dash. [14:07] right [14:07] afaik, the dash has no filters support yet [14:07] so that's not a scope issue (we can't give the dash something it doesn't support) [14:07] dobey, I'm looking at http://software-center.ubuntu.com/api/2.0/applications/en/ubuntu/click/ as my source. [14:08] JamesTait: that's the MyApps stuff, which is not used by the scope. we only get data from search.apps.u.c [14:09] (well, and rnr now, but that's totally separate from this) [14:09] dobey, right... apparently that's coming up RSN, though, which is why I've been asked to work on it. We import the data from that URL and index it in such a way that it can be consumed via search.apps.u.c [14:09] right [14:10] cwayne: you can get it uploaded, I just acked it. just run the unity8 AP tests + dogfooding (see Landing plan number 390) [14:11] dobey, AIUI we need to present the department from that feed as filters in the dash, so users can drill down to find apps. I need to know if we're intending to allow multiple departments to be selected. [14:13] JamesTait: afaik yes. but i think that's irrelevant to the server. we'd just get departments: ['x', 'y', 'z'] from the server, and that would be in the existing results. if the dash is going to force a new search, that would be really bad architecturally. [14:13] JamesTait: but i'm not working on that bit. that's all in the dash [14:14] didrocks, awesome, thanks! running unity8 tests now [14:14] JamesTait: in the scope we'll just parse the results and send them to the dash. the server should support having multiple departments specified as a search qualifier regardless, i think [14:15] dobey, ack, thanks. :) [14:15] cwayne: do not hesitate to update the spreadsheet as the landing proceeds (like INPROPOSED, INARCHIVE) [14:15] didrocks, ack, will do, thanks [14:16] yw! [14:16] er pitti ^ do I need to add the livecd-rootfs change too? or does that go through a different process? [14:17] cwayne: it should both be in the same landing ask; upload-wise it's the same process === ondrat is now known as ondra [14:18] pitti, ok, thanks, doing the AP tests now, will let you know :) [14:20] Mirv: do you have an eta for when the 5.2 packages will land in the archive? === dandrader|lunch is now known as dandrader [14:28] ogra_, you ask in your review of my dbus-screen-fix branch: "should the patch be dropped from the session mir?" Do you mean, we should drop the dbus code from unity-mir or something else? [14:28] mterry, no, thats exactly what i meant [14:29] feels like duplication [14:29] ogra_, we should drop it, but only after we turn on nested mode. It's not harmful to have it in there in the mean time [14:29] right [14:29] that was just meant as a reminder ... drop the old cruft :) [14:29] ogra_, OK, thanks for testing on maguro for me! So nested mode is +1 on that device. I'll top approve that branch and wait for libhybris [14:30] yeah, either rsalveti or ricmm_ are now on duty === XDS2010_ is now known as XDS2010 [14:45] hey all [14:53] ogra_: yup, will get that done now [14:53] let me flash my grouper and remove the dust out of it [14:53] * ogra_ hugs rsalveti === alan_g is now known as alan_g|tea [14:53] lol [14:56] ogra_, I have grouper too [14:56] tvoss, there is another pp lifecycle thing i was wondering about btw ... [14:56] *app lifecycle [14:57] ogra_, shoot [14:57] tvoss, i noticed that apps usually immediately stop if they get backgrounded ... i personally often have the case that i start a few webapps in succession ... would be nice if we kept them running for a few secs so they can load in bg [14:58] ogra_, that's something we have to tune then, but our app lifecycle allows for that. My proposal is to get to that later, when we have tuned the memory values and such [14:58] i.e. allow them to completely load even if they are not foregrounded before stopping them [14:58] yeah, surely not important right now [14:59] just something that always bothers me after a reboot [14:59] ogra_, at any rate, the "grace" period will be fixed [14:59] ogra_, let's file a bug against unity-mir then [14:59] (i have a bunch of apps i cionstantly run ... having to wait til app by app is loaded is actualy time consuming and makes it feel un-snappy) [14:59] yep [15:00] I thought it was already waiting 3 or 5 seconds [15:00] ogra_, perhaps we can tag them with "tuning"? [15:00] maybe that's not enough [15:00] (session saving would also rock btw ... but i guess thats a 15.xx task) [15:00] rsalveti, definitely isnt [15:00] at least if you run several webapps [15:00] rsalveti, right, we already grant a grace period, yes, but that would need to be fine tuned [15:01] rsalveti, i think it shuould rather talk to the app "wait for loaded signal or so" than to be a fixed time [15:01] ogra_, what do you think about the "tuning" tag? [15:01] bfiller, is the gallery-app-to-click transition on track for this week? [15:01] ogra_, that would give apps a way to escape the lifecycle trap ... won't happen [15:01] tvoss, sounds good ... if we dont have any other optimization tag yet at least [15:02] ogra_, we do not assume the app to be cooperative or behaving correctly, and thus a fixed grace period [15:02] cwayne: hopefully, waiting on some changes needed in the content-hub to support click [15:03] so with the news that Canonical putting most Nexus devices on hold, does that mean that the N5 attempts are gonna be on hold as well? [15:03] shiggitay, only that some community devs will have to pick it up [15:03] yeah [15:03] that's what I was thinking too [15:03] are any such devs im here? xD [15:03] in* [15:03] bfiller, I think I saw an MR for the content hub already from kenvandine [15:04] hello. could anybody please explain to me, why and what on Ubuntu Touch will be read-only and what are the pro's and con's of making it rw? Can I use apt-get on Ubuntu Touch? [15:04] sergiusens: ack, need to test that today [15:04] what's up with this qtmultimedia-opensourc-src-touch package? === alan_g|tea is now known as alan_g [15:04] bfiller, did you see my email btw? [15:04] I think it being at 5.1 vs the normal one at 5.0.2 is meaning I can't build telephony-service on the device [15:05] shiggitay: I also have a Nexus 5 and I'm waiting for an Ubuntu Touch image :D [15:05] FuLgOrE, the image based updates we provide actually use a binary diff between two readonly images (which makes the updates extremely small and about 10x faster than with apt) ... this requires that the system that gets diffed is readonly so all users have the same diff [15:05] shiggitay, i saw someone in the community working on a port earlier, and once we get it based on 4.4 aosp, it *should* be pretty trivial [15:05] cwayne, yeah I think I know which dev it was [15:06] rsalveti I think [15:06] FuLgOrE, making the image writable means you cant use that mechanism reliably anymore ... you can install debs then, but it will likely break at some point (size limits etc) [15:06] Mirv: there are lots of build failures in that ppa unfortunately, many of which i'm seeing locally too. e.g. i cannot get a good build of address-book-app :( http://tinyurl.com/mtzlknf Any suggestions? [15:06] sergiusens: yes, just haven't had a chance to get back to it [15:07] ogra_: that sounds interesting. How about updates? Would I get updates when the image is rw over apt-get? [15:08] no [15:08] ogra_: sorry for these kind of questions, I'm just a user :) [15:08] you can do apt updates, but only to a certain point [15:08] FuLgOrE, perfectly valid questions, no worries :) [15:09] dpkg uses hardlinks when it unpacks debs ... hardlinks do not work across partitions so you will find packages that are not installable ... [15:09] then there is a size limit due to the fact that we use loop mounted images, you will at some point run out of space for the apt package cache [15:10] how big is the loop image actually? [15:10] the readwrite mode is more something for devs that know they will re-flash at some point [15:10]