[01:09] <compuspital> hello everyone
[01:10] <compuspital> I have a few questions about touch, I finally got a tablet with Ubuntu Touch
[01:10] <compuspital> I was wandering how do I go about updating it?
[01:38] <unioah1> what do you want to update? the file system?
[01:39] <unioah1> There isn't a apt-get in it. So I guess you have to download a new one every time.
[01:39] <bensocket> hi
[01:41] <bensocket> could anybody tell wat kind of tablet i can put on ubuntu touch ? not including nexas 10  thanks
[01:43] <unioah1> One you can get kernel and Andriod source.
[01:44] <bensocket> ok
[01:44] <bensocket> ok?
[01:52] <compuspital> I was just curious about updating the software from quantal to raring.
[01:56] <mhall119> compuspital: phablet-flash will get you the raring image
[01:56] <mhall119> but you might loose what's in /home/phablet coming from quantal
[01:56] <mhall119> but once you're on the latest images, phablet-flash preserves /home/phablet/
[01:56] <compuspital> okay even if i'm not running a nexus?
[02:31] <mhall119> no, sorry, phablet-flash only works for nexus devices
[04:52] <compuspital> Hello Guys I just got my first Nexus 7 by exchanging the old device I had Galaxy Tab2 I will run nothing but Ubuntu on my devices
[05:05] <spammer> niggers
[05:33] <Mirv> compuspital: nexus7 is excellent for running Ubuntu :)
[05:36] <zsombi> good morning
[05:36] <compuspital> is it running on mir yet?
[05:41] <compuspital> thank you Mirv for the advice
[05:59] <Mirv> mir usage is still opt-in, not by default yet
[07:05] <dholbach> good morning
[09:07] <oSoMoN> didrocks: hey, when you have a moment, could you please have a second look at https://code.launchpad.net/~osomon/webbrowser-app/i18n-pot-target/+merge/164937 ? I believe I’ve addressed all the comments.
[09:08] <didrocks> oSoMoN: not sure today, deploying otto + everything on saucy, mind if it's only tomorrow maybe?
[09:08] <oSoMoN> didrocks: sure, no urgency
[09:08] <didrocks> oSoMoN: thanks! will have a lookg :)
[09:08] <didrocks> loog*
[09:08] <didrocks> look*
[09:08] <oSoMoN> thanks :)
[09:08] <didrocks> and take coffee…
[09:08] <didrocks> :p
[09:09] <oSoMoN> too much coffee might deteriorate your typing instead of improving it…
[09:16] <didrocks> that's a possibility, indeed :)
[09:36] <user82> popey, have you tested 3g data yet?
[09:38] <asac> sforshee: hey ... todays phablet-flashed image doesnt have a snappy on/off experience anymore?
[09:38] <asac> did it never land?
[09:55] <seb128> rsalveti, still there?
[10:00] <dholbach> user82, as far as I know is popey on holidays
[10:00] <user82> ok thanks dholbach
[10:04] <diplo> Yep, cruising along a canal at the moment I believe. Has been posting pics from there, not sure if it's from ubuntu phone though
[10:05] <diplo> Anyone know of an example of a touch app using oauth ? Wanted to try my first app, was going to try interfacing with goodreads.com
[10:19] <simosays> hi all
[10:19] <simosays> would anyone know details about ubuntu touch builds?
[10:20] <simosays> I am trying to port touch for samsung tab 2, but having some issues when ubuntu should startup
[10:25] <simosays> if i install raring it will start boot cycle, saucy runs without any booting and starts ubuntuappmanager but no any visible screen
[10:26] <dholbach> sergiusens, rsalveti: so the gerrit instance has been talked about quite a bit - and I checked in RT and there seems to be no request for an instance in there (asking because of https://blueprints.launchpad.net/ubuntu/+spec/community-1305-touch-porting)
[10:27] <dholbach> do you remember where this was being discussed in the past?
[10:30] <harisha> Hello All, I have a query on window management in Ubuntu Touch
[10:31] <harisha> Basically I need to switch between 2 QML windows, In Ubuntu Desktop there is utility called "wmctrl", is there equivalent library or commands available on ubuntu touch?
[10:32] <om26er> is there a way to turn on the device screen somehow without pressing the power button ?
[10:32] <om26er> sergiusens, ^
[10:45] <sil2100> oSoMoN: ping!
[10:45] <oSoMoN> sil2100: pong
[10:46] <sil2100> oSoMoN: so, it seems that we have 3 new AP test failures for webbrowser nowadays
[10:46] <sil2100> oSoMoN: could you take a look if these are real failures?
[10:51] <sil2100> oSoMoN: thanks!
[11:02] <penk> mhall119: ping
[11:21] <asac> ogra: is there a unity-desktop image for ARM still? e.g. do we rely on X for anything on ARM?
[11:21] <ogra> asac, sure, the panda desktop image
[11:22] <asac> do we want to keep that working?
[11:22] <asac> or break it?
[11:22] <ogra> we need to QA the apps so they work once convergence happens
[11:22] <asac> ok. is that the only device we have X drivers for>?
[11:22] <ogra> we want to hkeep it until we can test desktop on converged arm
[11:22] <asac> seb128: ^^
[11:22] <ogra> we have drivers for the nexus7
[11:23] <seb128> asac, yes?
[11:23] <asac> ogra: do we have enginereing contacts to get new drivers?
[11:23] <ogra> but that would mean two kernels for the same device
[11:23] <asac> seb128: this is about a potential blocker to remember for the X update
[11:23] <ogra> asac, no upfdate
[11:23] <asac> ogra: never?
[11:23] <ogra> asac, we cant upgrade PVR
[11:23] <seb128> asac, that's already sorted out, we will have an xserver with the video abi break reverted for the panda
[11:23] <ogra> and it was agreed that we wont upgrad X this cycle
[11:23] <asac> sure... i am not very bullish on the future of panda :)
[11:24] <seb128> asac, that package will not get new features and stuff but it's good enough for what we need
[11:24] <asac> seb128: ok. can we include that in testing?
[11:24] <ogra> for armhf that is
[11:24] <seb128> asac, sure
[11:24] <asac> seb128: ok. please add it to a "pre-sign off blueprint" or whatever :)
[11:24] <asac> thanks
[11:24] <seb128> asac, I'm adding it to my list
[11:24] <seb128> yw
[11:24] <asac> seb128: can you remember nexus7 too?
[11:25] <asac> i think thats more worthwhile to look at than panda to be honest
[11:25] <asac> :)
[11:25] <seb128> I though we stopped desktop images for the nexus?
[11:25] <seb128> ogra, ^
[11:25] <ogra> so why the heck can i not write to /proc/self/oom_adj even though my roofs is the first OS and not in a container
[11:25]  * ogra doesnt get that
[11:25] <asac> kernel doesnt have that feature? apparmore doesnt like you?
[11:25] <ogra> asac, i'm not sure Qa has actually tests running, but i know there are automated tests for panda
[11:26] <seb128> asac, I think the problem with the nexus is that the kernel for ubuntu-touch and desktop are incompatible, so if we want a working traditional desktop there we need an extra kernel flavor
[11:26] <ogra> *has actually nexus7 tests running
[11:26] <asac> seb128: we want a convergence target
[11:26] <ogra> asac, right, what seb128 said
[11:26] <asac> panda is a very bad one :)
[11:26] <seb128> asac, right, that's not going to have old xorg stack though, it's going to have Mir+xorg-mir
[11:26] <ogra> a) mgmt *strongly* insisted that we need to make use of the pandas
[11:26] <asac> seems N7 wouldnt work anyway
[11:27] <ogra> b) nexus7 needs an extra kernel flavour with hacks to make input devices work
[11:28] <ogra> and c) it might need extra work to port the QA tests from panda to n7
[11:28] <ogra> keeping panda is the path of least resistance
[11:31] <asac> seb128: do we ahve anything that could be used for mir+xorg?
[11:33] <seb128> asac, we should be able to test on the nexus7, since we have drivers for that, when we get a working Mir+xorg-mir
[11:33] <seb128> asac, but mir-xorg-mir is not there yet
[11:34]  * ogra thinks mir+xorg is rather for 14.04
[11:36] <om26er> How can I change the auto screen turn off timeout ?
[11:37] <ogra> there was a way to inhibit powerd
[11:37] <ogra> ask mfisch
[11:38] <om26er> mfisch, hey! ^
[11:41] <ogra> (probably powerd has a --help option ...)
[11:42] <netcurli> https://lists.launchpad.net/ubuntu-phone/msg02051.html
[11:44] <om26er> netcurli, thanks
[11:49] <ogra> root@android:/ # su - phablet
[11:49] <ogra> phablet@ubuntu-phablet:~$ echo -10 >/proc/self/oom_adj
[11:49] <ogra> -su: echo: write error: Permission denied
[11:50] <ogra> stgraber, ^^^ any idea why i see this outside of the container ?
[11:52] <asac> ogra: remember 14.04 is our convergence release :)
[11:52] <ogra> yes
[11:52]  * asac not convinced that panda is a convergence candidate target
[11:52] <asac> feels we can kill it :)
[11:52] <ogra> it isnt at all
[11:52] <asac> needs more inpt
[11:52] <asac> input
[11:52] <ogra> we need to test the X apps
[11:52] <asac> ogra: ok. well you said we needed it for convergence story
[11:52] <ogra> and we wont have XMir in 13.10
[11:53] <ogra> we need to make sure the *apps* themselves work
[11:53] <ogra> no matter under which display system they run
[11:53] <asac> Feels like that "make sure the apps work" needs to be redone on xmir anyway
[11:53] <ogra> after we have convergence we can kill the native X stuff
[11:53] <asac> so not sure how much we shouild invest to make them work now
[11:53] <ogra> you want to be sure LibO works
[11:53] <asac> let me do more talking :)
[11:53] <ogra> i.e. there are no bugs in it
[11:54] <ogra> and panda is the only setup we can test that with atm
[11:54] <asac> ogra: the majority of stuff is already tested on x86 i think... what is left is the aprt that depends on the stuff that is going to be replaced anyway
[11:54] <asac> thats my current feeling... but well :)
[11:54] <ogra> as soon as we have XMir we can do the testing with that
[11:54] <asac> for one it seem sto be very cost freiendly to keep panda working
[11:54] <asac> as seb128 said :)
[11:54] <asac> so its not a real thing to action on
[11:55] <ogra> we will kill panda with the 14.04 circle, thats definitely planned
[11:56] <ogra> until then we need to make sure there are no arch specific bugs  in appss
[11:56] <ogra> and i.e. LibO is a typical candidate for arch specific breakage ... as firefox  or TB are
[11:57] <ogra> (or chromium ... )
[11:58] <asac> ogra: lib0?
[11:58] <asac> whats that?
[11:58] <ogra> LibreOffice
[11:59]  * ogra sighs 
[11:59] <asac> ogra: dont be sad
[11:59] <ogra> i bet the not starting of apps in the flipped container is somehow realted to not being able to write to /proc
[12:00] <ogra> asac, well, i cant really find the issue with the apps not starting in the flipped images
[12:00] <asac> you have an strace?
[12:01] <ogra> well, i cant strace the android container (since i cant access it)
[12:01] <asac> guess that might reveal something
[12:01] <asac> thought you want to start the apps in the ubuntu container
[12:01] <asac> o rrather on ubuntu system
[12:03] <asac> ogra: any idea if chicken is out today?
[12:03] <ogra> nope
[12:03] <ogra> he didnt say he would be
[12:03] <asac> hmmm
[12:03] <asac> guess i will drag someone else into the management meeting then :)
[12:06] <pmcgowan> asac, its 8am here, folks usually start 8:30 or 9
[12:06] <om26er> Saviq, Hey! How can I force the qml-phone-shell to not restart itself on kill ?
[12:07] <Saviq> om26er, edit /etc/device-services
[12:07] <Kaleo_> ricmm: do you have an API that tells the app that it's about to quit?
[12:18] <pmcgowan> sergiusens, hey
[12:22] <simosays> hi all, would you have any suggestion where to find reason why screen is blank but ubuntuappmanager and surfaceflinger are running?
[12:27] <simosays> logcat does not give any "big" faults, just skipping libc.so and error opening trace file
[12:28] <ogra> slangasek, i saw your discussion in the #distro backlog, i'd be happy for any suggestion how to do the rootfs mounting differently (as long as the result is identical to what we have now)
[12:30] <ogra> slangasek, nothing in the current flipped images is set in stone ...
[12:32] <ogra> asac, http://paste.ubuntu.com/5732441/ thats an strace from running a qml app from cmdline ... i dont really see anything in there (except that it waits forever to get a surface in the end)
[12:40] <asac> ogra: do i have that app also on the current phablet image?
[12:40] <asac> e.g. can i run that in ubuntu_chroot?
[12:41] <asac> hmm
[12:41] <asac> ogra: any idea what the problem is if i get " adb root -> insufficient privileges"?
[12:42] <asac> err "insufficient permissions for device"
[12:42] <ogra> adb kill-server && sudo adb start-server
[12:42] <ogra> try that
[12:42] <asac> still same :/
[12:42] <asac> odd
[12:42] <asac> i cannot even do shell anymore
[12:42] <seb128> asac, adb root
[12:42] <seb128> ups
[12:43] <seb128> sorry I misread ;-)
[12:43] <pmcgowan> asac, try to unplug and replug
[12:43] <pmcgowan> seems adb gets confused sometimes
[12:43] <ogra> if you are not on saucy, make sure to have the latest android-tools-adb package from the ppa
[12:43] <asac> http://paste.ubuntu.com/5732477/
[12:43] <ogra> it ships the proper udev rules
[12:43] <asac> ok let me unplug, kill, plug, start
[12:43] <ogra> asac,
[12:44] <ogra> no, it should have been "sudo adb start-server"
[12:44] <asac> really?
[12:44] <ogra> and stop advertising these illegal downloads :P
[12:44] <asac> i dont think i needed that last time
[12:44] <pmcgowan> you should not need that
[12:44] <asac> ogra: :)
[12:44] <pmcgowan> should not need to restart at all
[12:44] <ogra> you shouldnt if you have the udev rules
[12:44] <pmcgowan> right
[12:45] <asac> ok let me check
[12:45] <ogra> if you use adb from the archive it doesnt have them in pre-saucy
[12:45] <asac> guess didnt do that here
[12:45] <asac> i have saucy
[12:45] <ogra> ah, that should ship the rules
[12:46] <asac> i have rules, maybe it didnt pick it up
[12:47] <ogra> hmm, we should ship override files for all ttyX.conf jobs
[12:49] <ogra> asac, oh, and btw: qmlscene --desktop_file_hint=/usr/share/applications/ubuntu-calculator-app.desktop /usr/share/ubuntu-calculator-app/ubuntu-calculator-app.qml
[12:49] <ogra> thats trhe command i ran
[12:49] <ogra> (prefixed with strace indeed)
[12:50] <asac> ok the device adb was busted
[12:50] <asac> needed to reboot device :/
[12:50] <asac> not sure if you have seen that before
[12:50] <ogra> if i would i wouldnt care :)
[12:50] <ogra> we dont use the android adbd in the flipped container
[12:51] <asac> ogra: so which user do we run stuff under in phablet?
[12:51] <ogra> we have our own ... and that works stable
[12:51] <asac> phablet?
[12:51] <ogra> su - phablet
[12:51] <ogra> and then run the above
[12:51] <ogra> that should start the app "minimized" and you shoould be able to tap it to fullscreen
[12:52] <ogra> here i get a black screen then it starts
[12:52] <RedPandaFox> Anyone had any luck getting touch running on a HTC Sensation?
[12:52] <ogra> RedPandaFox, check trhe devices wikipage
[12:52] <ogra> !devices
[12:53] <stgraber> ogra: if I'm reading the kernel code correctly, you're not allowed to set oom_score_adj (new name for oom_adj) to a value lower than that of your parent (which becomes your minimum value at fork time)
[12:53] <stgraber> ogra: that's unless you're root or have CAP_SYS_RESOURCE
[12:53] <ogra> stgraber, my parent is upstart
[12:54] <ogra> hmm, which is using 0
[12:54] <stgraber> ogra: right, which has the standard score of 0, so you can't go any lower than that
[12:54] <RedPandaFox> ogra, yeah I have seen that. I was just thinking someone may have had some experience. I hoped someone had expanded on a build by LaidbackNikez on XDA
[12:54] <ogra> stgraber, thanks, didnt know that
[12:54] <asac> ogra: so in the trace you gave me the /dev/alog/ ERRORS are probably one symptom
[12:54] <asac> i dont see the same errors here
[12:54] <ogra> so we might grant the phablet user CAP_SYS_RESOURCE
[12:54] <stgraber> yeah, init doesn't need a special score as it'd mean anyone can do rather bad rescoring. The kernel will never attempt to oom kill pid 1 anyway
[12:54] <ogra> *need to
[12:55] <stgraber> ogra: that or have a privileged (setuid) tool that sets the score. You really want to talk with the security team about this.
[12:55] <ogra> asac, /dev/alog is fine here
[12:55] <asac> ogra: your trace shows issues
[12:55] <asac> can you post the URL again?
[12:55] <stgraber> ogra: I have a feeling that CAP_SYS_RESOURCE may be bad enough that you might just as well run the shell as root if you do that...
[12:55] <ogra> asac, http://paste.ubuntu.com/5732441/
[12:56] <asac> open("/dev/alog/main", O_WRONLY)        = -1 EACCES (Permission denied)
[12:56] <asac> open("/dev/alog/main", O_WRONLY|O_LARGEFILE) = -1 EACCES (Permission denied)
[12:56] <asac> open("/dev/alog/radio", O_WRONLY|O_LARGEFILE) = -1 EACCES (Permission denied)
[12:56] <asac> open("/dev/alog/events", O_WRONLY|O_LARGEFILE) = -1 EACCES (Permission denied)
[12:56] <asac> open("/dev/alog/system", O_WRONLY|O_LARGEFILE) = -1 EACCES (Permission denied)
[12:56] <asac> ...
[12:56] <ogra> oh
[12:56] <asac> here i get:
[12:56] <asac> open("/dev/alog/main", O_WRONLY)        = 4
[12:56] <asac> open("/dev/alog/main", O_WRONLY|O_LARGEFILE) = 5
[12:56] <asac> open("/dev/alog/radio", O_WRONLY|O_LARGEFILE) = 6
[12:56] <asac> open("/dev/alog/events", O_WRONLY|O_LARGEFILE) = 7
[12:56] <asac> open("/dev/alog/system", O_WRONLY|O_LARGEFILE) = 8
[12:56] <ogra> let me fix the udev rule ...
[12:57] <asac> also:
[12:57] <asac> open("/sys/kernel/debug/tracing/trace_marker", O_WRONLY|O_LARGEFILE) = -1 EACCES (Permission denied)
[12:57] <ogra>  /dev/alog is a link, i forgot to adjust the permissions of the target
[12:57] <asac> but guess isnt critical
[12:57] <asac> i think thats fine
[12:57] <asac> that file is not found locally here, so no prob
[12:58] <ogra> asac, but as i suspected, no change
[12:58] <asac> post a new one :)
[12:58] <stgraber> ogra: hmm, actually CAP_SYS_RESOURCE isn't as bad as I thought it'd be, though some bits are still a bit scary (man 7 capabilities and look for CAP_SYS_RESOURCE)
[12:58] <ogra> on the ubuntu side i'm pretty sure all is fine
[12:58] <ogra> asac, i'll leave that to the platform-api specialists :) ricmm will take a look today i thinnk
[12:59] <asac> ok
[13:00] <ogra> thanks for the /dev/alog hint though
[13:03] <ogra> sigh, lxc-info could really be clever enough to not have me always type in the name of the only running container
[13:20]  * ogra glares at libhybris ...
[13:21] <ogra> now *that's* a version number
[13:28] <mzanetti> mardy: ping
[13:31] <mardy> mzanetti: pong
[13:33] <tzitzu> hello  boys
[13:33] <tzitzu> after install ubuntu touch  on samsung G nexus ..
[13:34] <tzitzu> all okay exept network conection gsm and sms
[13:34] <tzitzu>  there something more i have to do?
[13:38] <mzanetti> mardy: hey. I've heard you're the oauth guy
[13:39] <mzanetti> mardy: I had a bit of a play with it yesterday and thinking how to enable the callback mechanism for native apps
[13:41] <mardy> mzanetti: any ideas are welcome! At the moment we use a QtWebKit window and check when the URL changes to the one that we need
[13:42] <mzanetti> mardy: yeah... that would have been my approach too. basically creating a OAuthWebView component that disables any browsing capabilities except the login form and block any redirect except the expected one
[13:43] <mzanetti> mardy: could be something like special://authenticated?oauth_token=ab123456&oauth_verifier=876543abc
[13:43] <mzanetti> mardy: do you have something already?
[13:44] <mzanetti> mardy: otherwise I would hack together something tonight for evaluating
[13:45] <mardy> mzanetti: mmm... is there something wrong with the current approach?
[13:45] <mzanetti> mardy: what's the current approach?
[13:46] <mzanetti> mardy: oh... you already have that QtWebkit window in place... I thought so far that's only idea too
[13:46] <mzanetti> mardy: where can I find id?
[13:46] <awe_> mzanetti, did you create a bug for the 3g problem you ran into yesterday?
[13:46] <mzanetti> awe_: yes
[13:47] <mardy> mzanetti: http://bazaar.launchpad.net/~online-accounts/signon-ui/trunk/files/head:/src/browser-process/
[13:48] <mardy> mzanetti: http://bazaar.launchpad.net/~online-accounts/signon-ui/trunk/view/head:/src/browser-process/browser-process.cpp#L117
[13:48] <mzanetti> mardy: oh... thats a separate binary. how does the communication work?
[13:48] <mardy> mzanetti: when the current URL changes to the callback url (modulo the query/fragment), we know that it's finished
[13:49] <mzanetti> mardy: you still need to pass the token back to the app, no?
[13:50] <mardy> mzanetti: D-Bus: http://developer.ubuntu.com/resources/technologies/online-accounts/
[13:52] <mzanetti> mardy: wouldn't it be better if this was in-process?
[13:53] <mzanetti> mardy: you'd get rid of the D-Bus stuff + it would be only one app and the user couln't break the flow by closing one of the windows
[13:54] <mardy> mzanetti: not all apps have UI
[13:54] <mzanetti> mardy: thats true... but in case of a phone-app
[13:55] <mzanetti> which is probably the biggest use case of OAuth anyways
[13:55] <mardy> mzanetti: indeed, but think of the resource consumption
[13:56] <mzanetti> mardy: I think 2 binaries loading up a QQmlEngine consume quite a lot more than one
[13:56] <mardy> mzanetti: here it might be slightly slower because of D-Bus, but once the authentication is done, all the processes exit
[13:56] <mzanetti> mardy: well, the WebView can be deleted too even if its in-process
[13:57] <mardy> mzanetti: right
[13:57] <mardy> mzanetti: I need to leave now, can we continue tomorrow?
[13:57] <mzanetti> mardy: sure
[13:58] <mardy> mzanetti: ping me tomorrow please, or I might forget
[13:58] <mzanetti> mardy: ok... I'll explore the in-process thing tonight.. should be only few lines of code anyways
[13:58] <mzanetti> (for a first test)
[13:59] <mzanetti> awe_: found it or should I dig it out for you?
[14:00] <awe_> got it
[14:00] <awe_> thanks
[14:01] <ogra> sergiusens, so what do we do with ubuntu-session ... i definitely need a good bunch of changes for the flipped container
[14:01] <ogra> while you want to keep the old one for your saucy images
[14:02] <asac> sergiusens: rsalveti: there?
[14:02] <ogra> (it is my last blocker to get the flipped images auto-boot into the session)
[14:02] <ogra> asac, ricardo did his last upload at 13:00 our time
[14:02] <ogra> let him sleep :)
[14:02] <mfisch> ogra: what do you want to inhibit?
[14:03] <ogra> mfisch, i dont, om26er wanted, but i think he got his answer from your ML post
[14:03] <mfisch> great thanks
[14:03] <slangasek> ogra: well, my expectation was that "flipping the container" would lead to the system using a standard Ubuntu initramfs + root filesystem layout
[14:04] <ogra> slangasek, it cant
[14:04] <ogra> well, technically it could ... but that would end up in tears
[14:04] <sergiusens> ogra: I would say rebrand and fork
[14:05] <ogra> slangasek, i initially through about moving / ouot of the subdir, but that would mean that you end up with all the dirs in /data under /
[14:05] <om26er> mfisch, yeah I found a way to inhibit but now it seems the screen won't turn off even I set the timeout back to the old value
[14:05] <ogra> slangasek, so my only option when keeping it in the subdir is to mount /data temporary in the initrd and then bind mount /data/ubuntu to /root before run-init
[14:06] <ogra> slangasek, thats all in the initramfs-tools-ubuntu-touch package if you want to take a look .... thats surely not the final code :)
[14:07] <ogra> slangasek, also we need /data, /system and /vendor  mounted in both OSes at the same time ... the latter two are always mounted ro though
[14:08] <slangasek> ogra: but AIUI the Ubuntu OS is still on the data partition, which is just wrong; it should be on the system partition, and it should really be the *root* of the system partition
[14:08] <ogra> that would break android
[14:08] <om26er> mfisch, and the problem is that device is in the QA lab so I don't have physical access to it, hence the display have been on for more than an hour now
[14:08] <ogra> (and we would have size issues)
[14:08] <slangasek> we're not trying to run Android
[14:09] <ogra> we have to
[14:09] <mfisch> om26er: its been on over 1 hour?
[14:09] <ogra> android uses hardcoded devoice/partition paths everywhere ... if we would put soemthing else than androids /system into that partition it would break
[14:10] <ogra> additionally /system is usually the smallest partition
[14:10] <ogra> yu dont want to use that for a full ubuntu rootfs (especially not with convergence where you grow big)
[14:10] <pmcgowan> om26er, mfisch what device are you talking about?
[14:10] <om26er> mfisch, not an hour without touching since I have been running tests there as well, though it has been on for 15 minutes now. my timout value is 30sec now
[14:11] <om26er> pmcgowan, its a galaxy nexus in the Lab
[14:11] <ogra> slangasek, oh, and did i  mention that the partition table is usually hardcoded in the factory signed bootloader
[14:11] <mfisch> om26er: did you restart the service or phone after switching it back?
[14:11] <pmcgowan> om26er, I thought you might be hitting the powerd bug but thats not on nexus
[14:12] <om26er> mfisch, yes, quite a few times
[14:12] <mfisch> om26er: okay, please file a bug and attach /var/log/upstart/powerd.log, you'll need sudo to read the file
[14:13] <om26er> mfisch, sure, thanks
[14:14] <mfisch> ping me with the bug number and I'll give it a look, although I dont have a gnex or any device right now actually
[14:15] <ricmm> Kaleo_: no, you expect one?
[14:16] <ogra> slangasek, in any case i added the missing remaining udev rules, with the latest lxc-android-config package your devices and permissions should be created fine
[14:16] <sergiusens> sil2100: actually, _salem did a complete rewrite of telepathy-ofono so it would be probably wise to keep calling it with the 2 but change the trunk or put it into a new project
[14:16] <pmcgowan> mfisch, are you aware of the bug with powerd crashing on tablets without sensors
[14:16] <pmcgowan> mfisch, just eaves dropping your conversation
[14:16] <sil2100> hmm
[14:17] <mfisch> pmcgowan: I think a fix was released for it yesterday
[14:18] <om26er> mfisch, bug 1187407, though I don't see many lines in the logs there.
[14:18] <pmcgowan> mfisch, in saucy, just building for raring
[14:18] <pmcgowan> this sounds quite similar
[14:19] <sil2100> didrocks: ^ not sure what to do in this case then, since if we would really want to use the name telepathy-ofono, we could bump the major version and release it as a rewrite
[14:19] <sil2100> didrocks: but sergiusens has a point if that's a complete rewrite
[14:19] <pmcgowan> mfisch, that log is odd, its not finding the new sensors interface
[14:20] <didrocks> sergiusens: is telepathy-ofono will continue to be developped?
[14:20] <didrocks> or is it dead? (the version 1)
[14:20] <pmcgowan> om26er, was that system reflashed or updated?
[14:20] <sil2100> I guess it's dead?
[14:20] <sergiusens> didrocks: we won't use it anymore, it's python based
[14:20] <sil2100> sergiusens, _salem: ^ ?
[14:20] <sil2100> I wonder if anyone else besides us used it
[14:21] <didrocks> sergiusens: but we are not upstream for it? so taking the same name will be seen as a takeover, right?
[14:21] <om26er> pmcgowan, reflashed, I am not sure. I did update powerd from 0.9 to 0.11 when I first gained access to the device
[14:21] <didrocks> (version 1)
[14:21] <pmcgowan> om26er, its missing a new version of the platform stuff, I wonder if the deps are wrong
[14:21] <_salem> sil2100, It's probably dead.
[14:22] <om26er> pmcgowan, there are still updates pending including the platform-api there so we might in the end need to reflash
[14:22] <pmcgowan> om26er, yes its out of sync
[14:22] <sergiusens> sil2100: didrocks https://code.launchpad.net/~sergiusens/dbus-cpp/daily/+merge/167293
[14:22] <_salem> sil2100, well, I am almost sure we are the only ones using it, as we wrote it from scratch.
[14:22] <slangasek> ogra: udev rules> hurrah :)
[14:23] <sil2100> sergiusens: erm
[14:23] <sil2100> sergiusens: https://code.launchpad.net/~sil2100/dbus-cpp/packaging_review/+merge/167286
[14:23] <didrocks> sergiusens: thanks! sil2100 is doing the review I guess for dbus-cpp :)
[14:23] <slangasek> ogra: do you know how big our current Ubuntu image is (unpacked)?
[14:23] <ogra> (and an ugly hack that removes the .override file until ubuntu-session is in saucy)
[14:23] <sil2100> sergiusens: it seems we duplicated work ;)
[14:23] <sergiusens> didrocks: sil2100 ack, had it left over from last night.... forgot to push ;-)
[14:23] <ogra> root@android:/ # du -hcs /data/ubuntu
[14:23] <ogra> 1.3G	/data/ubuntu
[14:24] <ogra> slangasek, ^^^
[14:24] <slangasek> ogra: hmm, yuck
[14:24] <sergiusens> sil2100: didrocks I'll delete the MR
[14:24] <slangasek> ogra: ok, that definitely doesn't fit on my system partition on the N4... .grrr
[14:24] <sil2100> sergiusens: sorry about that! Could have checked first for your branch ;)
[14:24] <slangasek> this is all so inelegant :/
[14:24] <ogra> heh
[14:24] <pmcgowan> sergiusens, did you need to fix the powerd depends?
[14:24] <ogra> well, we have to obey to android
[14:24] <sergiusens> sil2100: it wasn't pushed
[14:24] <slangasek> ogra: yes, but I want to obey it as little as possible ;)
[14:24] <didrocks> sil2100: sergiusens: _salem: if we are the only ones, I would say let's move t-ofono2 -> t-ofono
[14:25] <ogra> so much hardcoded stuff we cant easily change
[14:25] <sergiusens> pmcgowan: I don't follow
[14:25] <ogra> it would be trivial with a separate disk/partition
[14:25] <sergiusens> didrocks: agree... just wanted to make sure he was aware as he pushes to it ;-)
[14:25] <pmcgowan> sergiusens, om26er has a test system with this issue https://launchpadlibrarian.net/141642659/powerd.log
[14:25] <ogra> but we cant easily change the part table
[14:25] <pmcgowan> not sure how thats possible
[14:25] <slangasek> ogra: we could change an awful lot of android, we're only using stripped-down pieces of android that we build ourselves; it's just a question of how much maintenance burden we can/should take on there
[14:26] <slangasek> the partition table, though, we can't reliably change indeed
[14:26] <didrocks> sil2100: you should move the t-ofono first branch, creating a new series and so on :)
[14:26] <sergiusens> pmcgowan: I did not change that... I did add a Recommends for ofono, but that would land in saucy only
[14:26] <ogra> slangasek, the problem is to not make awe cry ... binary vendor daemons like rild like to use the same hardcoding ... if you just differ a bit in the wrong place nothing will work
[14:26] <_salem> didrocks, sergiusens sil2100 +1 on moving tp-ofono2 -> tp-ofono
[14:26] <sil2100> didrocks, sergiusens: if we have a definite decision, I will do that then
[14:26] <pmcgowan> sergiusens, does it have a dep on the platform api?
[14:27] <sergiusens> pmcgowan: yes, or it wouldn't build
[14:27] <pmcgowan> build deps different than deps no, but it seems to
[14:27] <sergiusens> _salem: it's going to daily release though
[14:27] <slangasek> ogra: making the android bits see the "standard" android layout is obviously necessary, but there's lots of ways to do that with bind mounts etc.  I'm less worried about that problem
[14:27] <sergiusens> pmcgowan: shlibs:Depends in deps
[14:28] <pmcgowan> not sure then how he got that
[14:28] <om26er> pmcgowan, i generally download the iso from cdimage and flash it, so for the case of the device in the QA lab, will phablet-flash -b download and install everything without the need to touch the device ?
[14:28] <sergiusens> pmcgowan: might be using an old platform api
[14:28] <stgraber> slangasek: I'm starting to wonder whether we shouldn't use the "data" partition as just a storage space on which to dump ext4 partition files and just loop mount that stuff from initrd. That way, the system partition would be Android, the data partition would be everything else with one partition file for Android-data, one partition file for Ubuntu-rootfs and one partition file for Ubuntu-data
[14:28] <sil2100> _salem: ACK, thanks!
[14:28] <sergiusens> om26er: yes, phablet-flash
[14:28] <pmcgowan> om26er, yes, and generally you dont need the -b
[14:29] <ogra> slangasek, right, the question is how much do we care about porters and how big do we want to make their effort
[14:29] <ogra> we could indeed hack up a lot of stuff (mainly the harcoded init.rc files you can find in /var/lib/lxc/android/rootfs/ but also fstab etc)
[14:30] <slangasek> ogra: well, no, I don't think that's the primary question; we want to enable porting, but the design should not be driven based on community porting requirements :/
[14:31] <ogra> well, it plays a role we cant ignore
[14:31] <ogra> not saying it should be driven by it
[14:31] <ogra> but we need to take it into account
[14:31] <sergiusens> ogra: how does doing that block porters?
[14:32] <slangasek> sergiusens: if the android side has to carry a bunch of Ubuntu patches, that's more work the porters have to merge into their trees
[14:32] <ogra> sergiusens, i didnt say it blocks them but the more changes we add to the android side, the harder doing a port will get
[14:32] <mhall119> penk: very late pong
[14:32] <penk> mhall119: haha, cool
[14:32] <penk> mhall119: I uploaded package to ppa https://launchpad.net/~penk/+archive/touch
[14:33] <mhall119> I saw
[14:33] <penk> but it doesn't build armhf..not sure if it's my problem
[14:33] <mhall119> is the packaging also in your git repo?
[14:33] <slangasek> sergiusens, ogra: however, I don't think our model for porting should be based on the idea of using arbitrary unmodified android trees
[14:33] <sergiusens> slangasek: we already have plenty of pathes on the android side
[14:33] <slangasek> yep
[14:33] <ogra> the current container flip works without and extra changes on the android side (we should drop uchroot though) but that  causes a bunch of warts in the implementation
[14:33] <mhall119> penk: most PPA's won't build armhf, we don't have enough resources to enable it for everyone
[14:33] <penk> mhall119: I have debian/ directory in my git repo, but it's not using Ubuntu.Components
[14:33] <mhall119> but I can upload it to a PPA that does
[14:33] <sergiusens> slangasek: and our android trees are becoming less android as we move on
[14:34] <mhall119> penk: that's okay, as long as it runs on Ubuntu
[14:34] <penk> mhall119: that would be appreciated!
[14:34] <slangasek> stgraber: so I think it's important to have data vs. OS on separate partitions so that we can have the OS read-only (for both the Android and Ubuntu bits)
[14:35] <mhall119> penk: did you write it or just port it?
[14:35] <slangasek> stgraber: I don't see why you would want Android vs. Ubuntu data separate, though?  Or are you using "data" to mean something other than "user mutable data"?
[14:35] <penk> mhall119: I wrote it
[14:36] <mhall119> penk: that's pretty cool
[14:36] <stgraber> slangasek: so currently android expects to have a partition it can mount in /data, I very much doubt it needs to have access to the userdata we have on the Ubuntu side, so unless we can easily patch Android to stop mounting /data, I'd prefer having a very small partition file used for that
[14:36] <mhall119> penk: if you want to collaborate, I'm sure the webbrowser-app developers would welcome it
[14:36] <ogra> slangasek, we cant have /data separate
[14:36] <ogra> it needs to be writable mounted from both OSses
[14:37] <penk> mhall119: that sounds cool, I was trying to see how far pure QML app goes without using other C++ models
[14:37] <stgraber> ogra: do both sides actually need to read and write to /data? What kind of persistent data is Android still writing for us?
[14:38] <sergiusens> stgraber: the android property system writes stuff to /data ... some firmware wants to create sockets on data as well... not sure about the ubuntu side though
[14:38] <ogra> yeah
[14:38] <sergiusens> stgraber: we can easily get rid of the android property system
[14:39] <sergiusens> but the latter not so much
[14:39] <awe_> sergiusens, not if rild uses it
[14:39] <Guest34070> hello, i'm french user of ubuntu. I have a Nexus 7 with Android but I like install Ubuntu touch, is it read just for podcastinf for example ? Sorry for my english...
[14:39] <ogra> not sure about the ubuntu side either ... but given that /data is our biggest partition we definitely want /home to live in it
[14:39] <Guest34070> podcasting*
[14:39] <sergiusens> awe_: oh, but I mean, we can change the location to where it writes... not get rid of the property system itself
[14:39] <awe_> ack
[14:39] <ogra> awe_, rild runs on the android side
[14:39] <penk> mhall119: I'll pack a Chinese handwriting plugin for maliit next, but I'm sure it's not high priority on your list :P
[14:40] <stgraber> sergiusens: right, so we need to have /data writable in Android, that's fine, I didn't say we wouldn't do that. I just said we wouldn't pass it the data partition itself but a very small partition file instead.
[14:40] <ogra> we surely will keep the property system there :)
[14:40] <ogra> no worries :)
[14:40] <awe_> ogra, so does the property system
[14:40] <awe_> ;D
[14:40] <mfisch> pmcgowan & om26er: looks like its dying due to the sensor stuff missing?
[14:40] <mfisch> I dont know where that was fixed or in what rev
[14:40] <sergiusens> stgraber: sounds good to me
[14:40] <pmcgowan> mfisch, which should not be possible, I think om26er just needs to update or flash
[14:41] <mfisch> pmcgowan: ok
[14:41] <mfisch> pmcgowan: also I'm not sure if chicken ever published it for saucy (powerd I mean)
[14:41] <om26er> pmcgowan, mfisch I just updated, i think things should be fine now
[14:41] <sergiusens> mfisch: yes, it's part of daily release now and saucy is the focus
[14:42] <sergiusens> mfisch: sforshee which means no more release commits for powerd and trunk is always released btw
[14:45] <mfisch> sergiusens: what do you mean by release commits?
[14:45] <mfisch> you mean that every commit is a release now?
[14:45] <sergiusens> mfisch: debian/changelog is autogenerated
[14:46] <sergiusens> mfisch: there's a daily build that grabs trunk and publishes that with whatever was commited into trunk durning the day
[14:48] <mfisch> sergiusens: ok, I'll be sure to let seth know
[14:52] <Kaleo_> ricmm: yes
[14:55] <ogra> ricmm, did you see my ping in the backlog ? ... http://paste.ubuntu.com/5732441/ has an strace trying to run the calculator app on a flipped container
[14:55] <ogra> probably the specialist sees something on first sight :)
[14:56] <stgraber> sergiusens, slangasek, ogra: http://pad.ubuntu.com/ubuntu-touch-fs-structure
[14:56] <stgraber> did I forget any storage need on there?
[14:57] <ogra> stgraber, heh, your physical partitions looks a lot different from what i have on the gnex (and my galays S2 looks different again)
[14:58] <stgraber> ogra: yeah, though I believe boot, recovery, system, cache and data are usually a safe bet, no?
[14:58] <ogra> i wonder if we can ever reliably find a common denominator beyong /data /system and /vendor
[14:58] <ogra> yeah, boot and recovery too
[15:00] <stgraber> cache should be safe too as it's what's used for OS updates on Android I believe
[15:01] <Guest34070> doesn't people have an idea ? Ubuntu touch read the podcast ?
[15:01] <Guest34070> please
[15:03] <mhall119> penk: got it compiled and running on my Nexus 7, pretty slick
[15:03] <mhall119> the controls are a bit small though, and hard to hit accurately with my monkey fingers
[15:05] <penk> mhall119: ah, because I haven't tested it on actual devices though, set about 40px for a button :-P
[15:07] <mhall119> penk: using grid units on Ubuntu Touch will help it scale properly
[15:08] <jesterfraud> ugh, I should know this, I feel. Maguro, mako or manta for the Galaxy Nexus?
[15:08] <penk> mhall119: that's on my TODO list, also I brought Ubuntu Components to Mac OSX, hope that helps my testing further… # penkia.blogspot.com/2013/06/bringing-ubuntu-components-to-mac-osx.html
[15:10] <mhall119> well....that seemed simple enough
[15:12] <rsalveti> stgraber: ogra: sergiusens: I believe it's fine to assume we're changing the android side for it not to mount /data
[15:12] <rsalveti> so we can have that as a normal dir inside the android container
[15:13] <ogra> and use /data as a bare rootfs partition ?
[15:13] <rsalveti> yes
[15:13] <ogra> hmm, ok
[15:13] <stgraber> nope, we can't do that
[15:13] <rsalveti> stgraber: why not?
[15:13] <stgraber> we need the rootfs to be read-only
[15:13] <stgraber> so if we use /data directly for the rootfs, then we can't store user data
[15:14] <ogra> which gets us back to ugly slow squashfs loop mounted files ?
[15:14] <rsalveti> right, if we don't have any other partition
[15:15] <rsalveti> slangasek: remember /system can be quite small for some devices as well, so it's not an ideal target for the android based phones
[15:16] <rsalveti> we can change when doing a real product, but for now we should deal with such restrictions differently
[15:16] <stgraber> another reason to use loop-mounted partitions (when we don't have a custom partition table) is that it's the only way to effectively avoid the user killing their system by filling one of the user writable directories
[15:16] <asac> when is pin support for sim landing?
[15:16] <asac> ChickenCutlass: ?
[15:16] <slangasek> rsalveti: well, I'm concerned about the design being constrained by existing devices and leading us to suboptimal layouts that won't translate at all over to products
[15:16] <rsalveti> stgraber: right, seems to be the only sane way
[15:16] <ChickenCutlass> asac, need to schedule that
[15:16] <stgraber> tbh, I really think it'd be much much simpler if we could agree on what number and size of partitoins we would like to have, then fake that using loop-mounted files on the existing devices
[15:16] <asac> ChickenCutlass: what do we need?
[15:17] <stgraber> when we get our own hardware, we can simply move that to physical partitions and be done with it
[15:17] <ChickenCutlass> asac, hold on -- in a standup
[15:17] <rsalveti> stgraber: right
[15:17] <asac> ChickenCutlass: ok... see what we can schedule there
[15:17] <awe_> asac, it's on the list of stuff to do, but 3g was deemed the holy grail
[15:18] <asac> awe_: not complaining, just wonder on our schedule and if there are dependencies on UI etc.
[15:18] <asac> that we need to align
[15:18] <ChickenCutlass> asac, certainly depends on the systems UI.  Which we have  none
[15:18] <awe_> it also requires UI work, which although we have design specs ( which haven't been reviewed )
[15:18] <ChickenCutlass> asac, settings UI
[15:18] <ogra> we have the design afaik
[15:18] <ogra> just no implementation at all yet
[15:18] <asac> awe_: this month have PIN support on our side maybe?
[15:18] <asac> :)
[15:18] <awe_> ogra, we have a design for the greeter, it hasn't been reviewed
[15:19] <awe_> because I've been flat out on 3g
[15:19] <ogra> awe_, well, i would expect the PIN code to live in the settings too
[15:19] <awe_> so...first task is for some of us working on ofono to review the design
[15:19] <stgraber> slangasek, rsalveti, sergiusens, ogra: that's unless one of you knows of a very good reason why we shouldn't do bind-mounted partitions for our current devices, but I've been (ab)using loop devices for years without any significant problems and it's my understanding that Android also uses them heavily already.
[15:19] <awe_> ogra, i believe the design covers settings as well
[15:19] <ogra> ah
[15:20] <stgraber> slangasek, rsalveti, sergiusens, ogra: one concern is potential data corruption, though I can't see how this would be any worse than what we currently have (/data partition mounted read-write and mounted at a few different places)
[15:20] <rsalveti> stgraber: I'm fine with it, seems to be the only way to use /data with separated pieces in ro and rw
[15:20] <ogra> stgraber, well, i would like to know if there is any resource or power impact using loop mounted files
[15:20] <ogra> beyond that i dont see a reason against it
[15:21] <awe_> ogra, maybe not..  anyways, asac we need to do some work on the scheduling now that the dogfood deathrace is over
[15:21] <asac> nice
[15:21] <awe_> ogra, re: settings in the doc
[15:21] <asac> yeah... maybe we can even schedule it with cli
[15:21] <asac> and decouple UI stuff
[15:21] <asac> like we did for other stuff
[15:21] <ogra> awe_, well, i saw mpt posting a design doc for the settings, i assume it has PIN handling
[15:21] <awe_> asac, maybe... it might be a bit harder to de-couple
[15:22] <slangasek> stgraber: do we need to worry about taking a performance hit somewhere for loop mounting?  That seems worth checking with the kernel team before we commit
[15:22] <ogra> probably not covered in the SIM doc
[15:22] <stgraber> ogra: there will be a performance impact that may lead to power consumption impact as a write will go through the VFS layer twice, fragmentation would also usually be a problem, though probably less so on flash devices
[15:23] <ogra> yeah, thats what i thought
[15:23] <ogra> would be intresting how big of a difference it makes
[15:23] <stgraber> an alternative would be to use LVM which would let us avoid that extra layer
[15:23] <ogra> losing 1h battery due to it wouldnt be acceptable ... 10min would i guess
[15:26] <stgraber> cking: ^ (power/performance impact of using a loop mounted ext4 on ext4 partition vs physical partition)
[15:26] <asac> ChickenCutlass: should be scheduled in the telephony section of the cross check slide deck
[15:26] <asac> the current prediction doesnt include it
[15:26] <penk> mhall119: code committed here, btw https://code.launchpad.net/~penk/slatekit-shell/trunk
[15:27] <asac> currently called out items: "Converge network manager and ofono in archive (CO)
[15:27] <asac> First cut of mobile indicator (CO)
[15:27] <asac> Hook networking stack to first pass of indicator
[15:27] <asac> "
[15:27] <asac> probably could be more specific
[15:27] <cking> stgraber, off the top of my head, no idea, I can put that on my list of things to analyse
[15:27] <asac> actually it hsould go into connoectivity i guess
[15:28] <cking> stgraber, the risks of data loss I probably higher when something bad (like power loss) occurs though
[15:36] <sgtkwol> quick question, If I install apps on phone (not desktop), how do I open them? no icons for terminal, file manager, etc
[15:39] <pmcgowan> sgtkwol, use the search to find them on the app lens
[15:43] <stgraber> slangasek: so, another option, do you see any problem in using LVM on the phones?
[15:44] <asac> stgraber: LVM is not very well supported in many kernels that we currently will face on existing phones (too old)
[15:44] <ogra> yeah
[15:45] <asac> i think lvm really just landed in 3.9
[15:45]  * ogra would go with loop  mounted squashfs images if we can prove it doesnt eat to much performance
[15:45] <asac> but we have 3.0 3.4 etc. kernels still breathing everywhere
[15:47] <stgraber> asac: are we talking about the same LVM? LVM2 has been around since at least the early 2.6 kernel and LVM itself for way longer.
[15:47] <sgtkwol> pmcgowan, thanks, got it, woot
[15:48] <asac> stgraber: fully supported on ARM?
[15:48] <xnox> stgraber: but was it ported/enabled in android kernels, is the question...
[15:48] <pmcgowan> sgtkwol, ah good
[15:48] <xnox> asac: it works great on ARM, but have no idea about android kernels though.
[15:48] <asac> stgraber: just repeat what i have in the back of my mind as a reason
[15:48] <asac> xnox: since 2.6?
[15:48] <asac> or now?
[15:48] <asac> :)
[15:48] <xnox> asac: lvm2 is 12 years old.
[15:49] <xnox> asac: so somewhere in 2.6.x yes.
[15:49] <stgraber> xnox: well, it sure works on my nexus4
[15:49] <xnox> stgraber: ack.
[15:49] <stgraber> anyway, I'd prefer loop mounted images personally, was just thinking of other options to lower the overhead
[15:49] <asac> stgraber: whats your usecase? just curious
[15:49] <stgraber> if we can't go with LVM, then there's no need to actually do much performance/power analysis since we don't have a choice anyway
[15:50] <stgraber> asac: we need more partitions than are physicailly available on the phones
[15:50] <stgraber> asac: and as we can't change the partitioning, we're left with two options 1) loop mount partition files or 2) LVM
[15:50] <stgraber> 2) should have a lower overhead than 1), but 1) is easier to debug and certainly confirmed to work on Android kernels as that's what they use for some apps
[15:53] <asac> stgraber: what do you need the partitions for?
[15:53] <cking> stgraber, I'm currently measuring loopback vs non-loopback to see if there is any significant difference
[15:54] <asac> i hope there is :)
[15:54] <asac> otherwise we should just move away from even dealing with partitioning :)
[15:54] <stgraber> asac: the Ubuntu rootfs needs to be read-only, the Android system needs to be read-only, the Android data needs to be read-write, the Ubuntu config needs to be read-write and the Ubuntu userdata needs to be read-write.
[15:55] <stgraber> asac: all that stored on the same physical partiton
[15:55] <stgraber> hmm, actually wrong, Android system is a separate partition (though under used sadly)
[15:55] <stgraber> asac: http://pad.ubuntu.com/ubuntu-touch-fs-structure
[15:55] <asac> chmod :)
[15:55] <asac> lol
[15:55] <asac> oh that pad is good
[15:55] <ogra> and ubuntu userdata and android data need to be the same and accessible from both OSes
[15:55] <asac> have been trying to find it for a bit
[15:56] <stgraber> oh, and we don't want someone to be able to fill one partition and kill the phone ;)
[15:56] <asac> when will that be promoted to a wiki/mail? :)
[15:56] <stgraber> when we all agree on it and implement it? :)
[15:56] <asac> ok ... when is the decision deadline?
[15:56] <ogra> is there one ?
[15:57] <ogra> we need to have a proper setup by rellease
[15:57] <stgraber> I don't think there's one, but as long as we haven't sorted out that mess, I can't really prepare the image based updates which is starting to annoy me a little
[15:57] <asac> slangasek: ChickenCutlass: how much time do you need to get alignment on the partition layout?
[15:58] <asac> stgraber: i dont want that to happen :)
[15:58] <asac> that you cant prepare that
[15:58] <ChickenCutlass> asac, I didn't know there was a partition problem
[15:58] <asac> i dont think there is a problem
[15:58] <asac> just someone needs to say "GO"
[15:58] <asac> :)
[15:58] <asac> and of course take a look if there is something that will shoot ourselves in the foot badly
[15:58] <stgraber> so we should really have that stuff figured out and any change done ASAP, so that ideally the first really usable images with the container flip are based on what we consider our final layout
[15:58] <ogra> asac, ChickenCutlass, there isnt a partition problem, there is a "we dont have any design for the flipped container" problem
[15:59] <stgraber> then we can just tell people to use the saucy images and base their stuff on that
[15:59] <asac> stgraber: are there open points in the proposal for which people had concerns?
[15:59] <ogra> the images we have now are a prototype, far from a proper final implementation
[16:00] <asac> we are talking about nailing the parittionm layout
[16:00] <stgraber> asac: so I think we want to hear back from cking on performance/power impact, not that we really have a choice in the end. Then we need to figure out how many of those "partitions" (file) we need, what they'll contain, where they'll be mounted and how big they'll be
[16:00] <cking> stgraber, let's see what I can turn around in the next hour or so
[16:00] <ChickenCutlass> asac, we are not blocked by this -- also we can not change partition layout on existing phones.
[16:01] <stgraber> cking: cool, thanks for looking into this so quickly!
[16:01] <asac> seems we can by adding .img files :)
[16:01] <asac> ChickenCutlass: well. then someone should write up the truth and then make the call
[16:01] <ogra> ChickenCutlass, we wont, we will use loop mounted files
[16:01] <ogra> or PVm
[16:01] <ogra> err
[16:01] <ogra> LVM
[16:01] <ChickenCutlass> not using LVM on a phone
[16:01] <ogra> dont telll me
[16:01] <asac> still we need to decide what partitions we want and see how we can realize that on legacy phones
[16:01] <ogra> i didnt bring it up :)
[16:01] <ogra> just the messenger
[16:02] <ogra> asac, there is no such thing as choice
[16:02] <asac> i know what choices are doable
[16:02] <ogra> we need /data writable mounted on both OSes ... we need /system readable on both OSes and the same goes for /vendor
[16:02] <asac> there is choice by bringining in .img files etc.
[16:02] <ogra> everything else is optional
[16:02] <asac> thats choice you realize :)
[16:03] <ogra> well, a very limited chouce
[16:03] <asac> ChickenCutlass: slangasek: please make a call stgraber can land image updates this month
[16:03] <ogra> *choice
[16:03] <asac> :)
[16:03] <sil2100> kenvandine: one more once you have a free moment: https://code.launchpad.net/~sil2100/location-service/packaging_review/+merge/167327
[16:07] <sil2100> oSoMoN: ping!
[16:08] <sil2100> oSoMoN: any progress on those AP issues? Got any ideas on those random ones?
[16:10] <ogra> stgraber, hmm, can i somehow get rid of lxcbr0 ?
[16:10] <stgraber> ogra: yep, disable lxc-net or change USE_LXC_BRIDGE in /etc/default/lxc-net
[16:11] <stgraber> ogra: do you actually get lxcbr0 on your hardware? on mako we don't appear to have bridge support in the kernel, so it never shows up
[16:11] <ogra> on maguro with my very latest image (udev working and all) i get it, yes
[16:11] <ogra> i'll ship an override file with the android package
[16:14] <oSoMoN> sil2100: yes, I submitted 2 MRs that I hope will fix the issues, but the CI jenkins refuses to cooperate, the builds timed out, so I re-launched them
[16:22] <sil2100> oSoMoN: thanks! Excellent, too bad jenkins makes problems...
[16:53] <mhall119> Kaleo_: ping
[16:56] <surgemcgee> What is the command to hide the auto generated comments?
[16:56] <slangasek> ChickenCutlass: so, why do you say that we can't change partition layout on existing phones - at least for the 4 devices we support?  Has someone tested and found that this isn't possible?
[16:57] <surgemcgee> Nevermid, is in the options. I swear, that is sometimes not there :0
[16:58] <mhall119> surgemcgee: ?
[16:58] <surgemcgee> Uhhh, it is in the options i guess... Sorry
[17:03] <spazm> hi niggers
[17:04] <spazm> BITCH
[17:06] <spazm> FAGS
[17:09] <Kaleo_> mhall119: pong
[17:09] <mhall119> Kaleo_: hey, I want to start a project for collecting reusable 3rd party components/widgets, but I'm not sure of the best way to go about doing that
[17:10] <mhall119> for example, do I put them all in one big package, or multiple smaller ones?  Do I make a new QML namespace for it, and how do I do that?
[17:10] <Kaleo_> mhall119: it's started already: https://docs.google.com/a/canonical.com/document/d/1xGmQd1qRMFIHIupybpzFmIZHRGUmRhSJanX62ElG5EA/edit
[17:11] <Kaleo_> mhall119: on his note, I need to eat something
[17:11] <mhall119> oh perfect! thanks Kaleo_
[17:11] <Kaleo_> this*
[17:12] <seb128> Kaleo_, hey, enjoy your meal
[17:12] <Kaleo_> thx
[17:13] <seb128> Kaleo_, since I see you around, did you ever have a chance to look at my small "keyboard navigation doesn't skip enabled = false elements in grids"? should I report a bug about that?
[17:13] <Kaleo_> seb128: I did not
[17:13] <Kaleo_> seb128: please do if it's not already in qt bugs
[17:14] <seb128> Kaleo_, ok, my small testcase is there: http://people.canonical.com/~seb128/grid.qml
[17:14] <seb128> Kaleo_, I will check for upstream bugs
[17:14] <seb128> Kaleo_, thanks
[17:42] <xnox> where is the code for qml-phone-shell
[17:43] <didrocks> ricmm: hey, mind a small review: https://code.launchpad.net/~didrocks/platform-api/fix-archs/+merge/167354?
[17:46] <xnox> i think it's a
[17:46] <xnox> lp:unity/phablet.
[17:46] <greyback> xnox: correct
[17:49] <AmEv> Anyone here able to troubleshoot a blank screen?
[17:51] <didrocks> sergiusens: rsalveti: do you mind having a look to ensure that https://code.launchpad.net/~didrocks/platform-api/fix-archs/+merge/167354? is merged before 00 UTC? otherwise, it will block all stacks for tomorrow daily releasing (we can skip it by hand, but that will introduce a daily)
[17:52] <didrocks> I'll log off now, but still looking at the current build status in jenkins
[17:56] <xnox> Are raring phablet touch images build using "trunk" branches or "raring/13.04" branches? For example: lp:hud or lp:hud/13.04
[17:59] <didrocks> xnox: trunk
[17:59] <xnox> didrocks: thanks.
[17:59] <didrocks> apart from those having /phablet
[17:59] <didrocks> (because they aren't compatible with desktop)
[17:59] <AmEv> Hmmm... Looks like the Tegra 2 Transformer and Toshiba Thrive are suffering the exact same black screen problem....
[17:59] <xnox> didrocks: gotcha.
[18:00] <AmEv> Wonder if the blank screen thing is a regression of Tegra 2 devices?
[18:01] <AmEv> The dev had it working at one point, but then people have been reporting black screens since.
[18:03] <ChickenCutlass> slangasek, I beleive the bootloader expects certain partition layouts. I think things get borked if you change them.  rsalveti can probably say more about this.
[18:04] <sergiuse1s> ChickenCutlass: bootloader has partition information written to it... which is consequently why some of the images are breaking with fastboot -w
[18:05] <ChickenCutlass> right
[18:05] <slangasek> sergiusens: and would that have an impact if we were only changing the system+data partitions?
[18:06] <slangasek> sergiusens: also, which bootloader to be exact?  (on which device?)
[18:08] <sergiusens> slangasek: so bfiller has an older bootimage and his partition information differs from mine (the userdata one at least)
[18:08]  * sergiusens looks at the flood
[18:09] <sergiusens> slangasek: I still need to compile the differences since I have a bug open for it, so I'll keep you in the loop... it's right up next after getting saucy in place
[18:12] <slangasek> sergiusens: so, if I change the system/userdata partitions on these devices, am I going to brick them?
[18:12] <sergiusens> slangasek: no, but if you use fastboot you might... although they never get really bricked
[18:34] <cking> stgraber, ext4 on loopback on Nexus4 results: http://kernel.ubuntu.com/~cking/pm-arm/nexus4/ext4-vs-ext4-loop-on-ext4/ext4-vs-ext4-loopback.ods
[18:35] <cking> asac, ^^
[18:37] <cking> so there is noticeable I/O performance hit and some extra current drawn too, random writes are improved on loopback, but that's it really
[18:47] <didrocks> rsalveti: hey!
[18:47] <didrocks> rsalveti: I don't understand your need fixing
[18:47] <rsalveti> didrocks: hey
[18:48] <rsalveti> didrocks: well, build the package :-)
[18:48] <rsalveti> it'll fail as all can't be multi-arch same
[18:48] <rsalveti> for the transitional packages
[18:48] <didrocks> oh, arch: all and multiarch
[18:48] <didrocks> rsalveti: ok, removing them :)
[18:49] <didrocks> I'm removing the pre-depends as well as it's for multiarch
[18:49] <rsalveti> didrocks: ok
[18:52] <rsalveti> didrocks: let me know once done
[18:52] <didrocks> rsalveti: yeah, firing up a pbuilder meanwhile :)
[18:52] <didrocks> typical one line change where nothing wrong can happen :p
[18:54] <pmcgowan_> rsalveti, could our dtmf issue be related to inband vs out of band?
[18:55] <pmcgowan_> rsalveti, but you said you did finally get through
[18:57] <didrocks> rsalveti: ok, pushed. pbuilder gave its green card :)
[19:05] <rsalveti> pmcgowan_: yeah, worked fine when I used the brazilian number
[19:05] <rsalveti> didrocks: thanks
[19:05] <didrocks> thanks to you for the remark :)
[19:08] <pmcgowan__> ChickenCutlass_, ping
[19:08] <ChickenCutlass_> pmcgowan__: Hi
[19:08] <pmcgowan__> ChickenCutlass_, the activity timeout kicks in during calls
[19:08] <ChickenCutlass_> pmcgowan__: Right. It should
[19:09] <pmcgowan__> which is ok to dim the screen but not the welcome screen
[19:09] <pmcgowan__> or is that intended
[19:09] <ChickenCutlass_> pmcgowan__: Intended
[19:09] <pmcgowan__> hmmm
[19:09] <ChickenCutlass_> pmcgowan__: That is what my phone does
[19:10] <stgraber> ogra, sergiusens, slangasek, rsalveti, asac: I forwarded you an e-mail from cking wrt performance and power impact of using loop mounted images
[19:10] <rsalveti> didrocks: happroved
[19:11] <didrocks> rsalveti: thanks ;)
[19:11]  * didrocks continues on the hud, and then, we should be fine
[19:11] <rsalveti> hm, 6% is quite a bit
[19:11] <ogra> stgraber, yup, just read it .... i would have liked to see the same tests on a gnx
[19:11] <ogra> *gnex
[19:11] <stgraber> in short, we're seeing a 6% power increase and at least 10% impact on reads, though there are pretty big variations across tests which make me think there may be something else going on
[19:11] <ogra> i would expect them to be even worse there
[19:12] <stgraber> ogra: apparently a lot more people have nexus4 (company provided or otherwise) than gnex, apparently the gnex isn't as easy to get as th4 nexus4
[19:12] <ogra> and the gnex is the class of device we target
[19:12] <ogra> yeah
[19:12] <ogra> i know :)
[19:13] <rsalveti> we got a few folks with gnex as well
[19:13] <sergiusens> stgraber: if you provide instructions to setup I can run
[19:13]  * rsalveti gone, getting some proper sleep
[19:13] <stgraber> sergiusens: you'd have to ask cking for that, he's run those tests
[19:14] <stgraber> anyway, we were talking with slangasek a bit earlier and were wondering if the following would be possible:
[19:14] <stgraber> Go with two different supported setups:
[19:15] <stgraber> 1) For devices that support it or devices that are prepared at the factory for Ubuntu phone. Have a rather large system partition (2GB) and reduce the size of userdata a little
[19:15] <stgraber> 2) For those devices that can't even deal with a partition resize (even without re-order), have a system.img and data.img files in the userdata partition and loop mount that
[19:16] <stgraber> That'd leave us with the same setup in both cases, only different being real vs virtual partitions. system would contain the Ubuntu rootfs and the Android rootfs (under /var/lib/lxc/android/rootfs) built from the superposition of two .tar.xz
[19:16] <stgraber> data would be a writable partition, containing all user writable folders with bind mounts from there to paths on the filesystem that need to be writable
[19:23] <_salem> bfiller, https://code.launchpad.net/~tiagosh/phone-app/phone-app-delete-confirmation/+merge/167376
[19:24] <bfiller> _salem: nice, I'll try once jenks builds it
[19:24] <_salem> bfiller, ok, cool
[19:25] <_salem> bfiller, ouch, forgot to add i18n to some strings, I will have to update it.
[19:38] <mhall119> ogra: my N7 has been unplugged all day, the screen doesn't stay turned off, and I've been using it off and on at full brightness
[19:38] <mhall119> but it still says my battery is at 100%
[19:39] <mhall119> now, either we've done some magical optimizations, or it's lying to me
[19:39] <mzanetti> mhall119: hey, are you aware of an app that uses qca or even oauth?
[19:39] <mzanetti> mhall119: and your tablet is lying :P
[19:39] <mhall119> what is qca?
[19:40] <mhall119> mzanetti: the Facebook and Friends apps use OnlineAccounts, which uses oauth
[19:40] <mhall119> I don't know of any apps that do oauth themselves
[19:40] <mhall119> they should usually make an OnlineAccounts provider if then need it
[19:40] <mhall119> that way other apps can use it too
[19:41] <mzanetti> mhall119: ah right... that would be enough. I'm curious because the qoauth lib we ship on the device seems to be Qt4 compatible only. same for qca
[19:41] <mhall119> if anybody asked me, I'd tell them to do oauth with a UOA provider
[19:42] <mhall119> in fact, I've had on my to-do-some-day list to write one for Reddit
[19:44] <mzanetti> mhall119: can you point me to some docs or the code please?
[19:45] <mhall119> mzanetti: http://developer.ubuntu.com/resources/technologies/online-accounts/
[19:46] <mhall119> http://developer.ubuntu.com/resources/technologies/online-accounts/for-service-developers/
[19:46] <mhall119> and http://developer.ubuntu.com/api/ubuntu-12.10/python/AccountPlugin-1.0.html for API docs
[19:49] <mzanetti> mhall119: awesome :) thanks a lot. I've actually seen that site before. but the screenshots looked so desktop-ish so I missed the info :D
[19:49] <mhall119> mzanetti: as far as I know the API hasn't changed
[19:56] <mterry> What's the easiest way to get something built for armhf for testing purposes?  I don't want to throw something at the phablet ppa until I test it
[19:58] <mhall119> mterry: do you have a device?
[19:58] <mterry> mhall119, oh I suppose I could build there...
[19:58] <mterry> hm
[20:00] <bfiller> mterry: pbuilder chroot for armhf and then push deb to device
[20:00] <mterry> bfiller, that works fine these days?
[20:00] <bfiller> mterry: yup
[20:00] <mterry> nice
[20:09] <AskUbuntu> How can I create a custom session to use Unity Next and the Core Apps in 13.04? | http://askubuntu.com/q/304092
[20:10] <jackcy75> do i have to install saucy instead of raring to compile a phone zip and use the current saucy daily image zip? I had an already working i9300 kernel zip that meanwhile does not work anymore, even when i compile it again...
[20:25] <slangasek> stgraber: any thoughts on this one? :) http://paste.ubuntu.com/5733851/
[20:26] <slangasek> the kernel has this to say:
[20:26] <slangasek> Jan  1 17:02:59 ubuntu-phablet kernel: [    2.893300] Alternate GPT is invalid,
[20:26] <slangasek> using primary GPT.
[20:26] <slangasek> Jan  1 17:02:59 ubuntu-phablet kernel: [    2.893941]  mmcblk0: p1 p2 p3 p4 p5 p
[20:26] <slangasek> 6 p7 p8 p9 p10 p11 p12 p13 p14 p15 p16 p17 p18 p19 p20 p21 p22 p23 p24 p25
[20:28] <stgraber> slangasek: no idea, I guess that's part of the whole mess that partition tables on mobile devices appears to be
[20:28] <slangasek> well
[20:28] <slangasek> the kernel thinks the GPT is ok, but parted rejects it
[20:30] <slangasek> stgraber: so 'gdisk' is able to work with the partitions; guess it's a parted bug
[20:34] <beidl> screwing with partition tables on mobile devices is a baaad idea. for example, the galaxy nexus has specific partitions for radio, the spl and xloader. i'm not sure if at some point the device expects certain code (like xloader) to be at a certain position on the nand
[20:38] <beidl> older devices that used mtd for accessing the nand could be "repartitioned" at boot time by providing bootargs to the kernel, telling the mtd subsystem at which address/position which partition starts and where it ends. that was the safest bet we had for repartitioning *back in the days*
[20:48] <beidl> actually.... the CM team got MTD running on the galaxy S1 when they released CM9 for it, but I'm not actually sure how they accomplished it. I'm taking a look at their update.zip right now. but the downside is: mtd only allows yaffs2 as a filesystem, no ext4.
[20:51] <beidl> anybody got my info on MTD? my ISP is playing games with me...
[20:53] <jono> anyone know why I am getting this:
[20:53] <jono> jono@forge:~$ adb devices
[20:53] <jono> List of devices attached
[20:53] <jono> ????????????	no permissions
[20:53] <beidl> sudo adb devices
[20:54] <jono> beidl, makes no difference
[20:54] <k1l_> db needs more rights
[20:54] <jono> it normally works
[20:54] <beidl> sudo adb kill-server && adb shell
[20:55] <beidl> jono: maybe that works
[20:55] <mhall119> jono: I had this once before, I had to sudo adb kill-server; sudo adb start-server
[20:55] <netcurli> what device? do you have a udev rule for it?
[20:55] <mhall119> or something like that
[20:55] <k1l_> yep, if sudo doesnt help, kill the adb server and start again
[20:55] <jono> jono@forge:~$ sudo adb kill-server
[20:55] <jono> jono@forge:~$ adb root
[20:55] <jono> * daemon not running. starting it now on port 5037 *
[20:55] <jono> * daemon started successfully *
[20:55] <jono> error: insufficient permissions for device
[20:56] <k1l_> jono: ./adb kill-server ./adb start-server ./adb devices
[20:57] <jono> k1l_, fixed, thanks!
[21:15] <slangasek> beidl: so I realize there may be low-level code that assumes locations of the hardware drivers in particular places, which may thus fail to pay appropriate attention to partition tables and such; but the only partitions I'm manipulating here are the system, cache, and userdata partitions, which the bootloader definitely shouldn't be worrying about
[21:16] <slangasek> stgraber, ogra: fyi, I've adjusted the system, cache, and userdata partitions on the N4 and it still boots to recovery, at least.  Still working on getting the main boot bootable again
[21:17] <mhall119> mzanetti: my battery reads 95% now, so maybe it wasn't lying earlier
[21:18] <beidl> slangasek: yes, of course, but I'm not exactly sure how manipulating non-standard partition tables using standard tools would work. just out of curiosity, how did you repartition your N4 for example?
[21:18] <slangasek> beidl: the hard way <tm>
[21:19] <mhall119> with a magnetized needle and a steady hand?
[21:20] <slangasek> merely as a proof of concept; if we think this is actually what we should do, we'll need to make it much more user-friendly than what I did (port gdisk onto the machine; use it to adjust the partition table; reboot to recovery; port mkfs.ext4 onto the machine and use it to make filesystems; reboot to recovery again; adb push autodeploy.zip)
[21:21] <mzanetti> mhall119: hmm... that'd be quite cool :D
[21:22] <mzanetti> mhall119: which image?
[21:22] <mhall119> mzanetti: 147
[21:22] <mhall119> maybe I just wasn't using it as much as I thought I was
[21:22] <mhall119> or had it plugged into USB more than I thought I did
[21:23]  * mhall119 is thrilled to see the terminal and file manager apps in image 152
[21:23] <mhall119> \o/
[21:26] <rickspencer3> rsalveti, et al
[21:27] <rickspencer3> I just used my cellular data
[21:27] <rickspencer3> worked like a charm
[21:28] <rickspencer3> my only regret is letting Network Manager name the connection id
[21:28] <rickspencer3> I should have named it "a" instead of "T-Mobile connection 1"
[21:30] <pmcgowan__> rickspencer3, I found some problems with string parsing of long connection names, especially those with a & like AT&T
[21:30] <rickspencer3> hehe
[21:31] <rickspencer3> pmcgowan__, mine worked, was just a hassle to type into the terminal app ;)
[21:32] <beidl> rickspencer3: I created aliases in .bashrc for turning 3g on and off, saves some time ;)
[21:32] <rickspencer3> hi beidl, nice idea
[21:34] <mhall119> pmcgowan__: you wouldn't have that problem on Verizon
[21:34] <mhall119> mostly because you'd be stuck with CDMA
[21:35] <AskUbuntu> Ubuntu touch install failure (galaxy nexus) | http://askubuntu.com/q/304129
[21:35] <slangasek> hmmm, nearly there; except the Ubuntu rootfs is mounting by-partlabel and I seem not to have created those properly
[21:37] <beidl> btw, I've got a GNex specific idea: u-boot has been ported to the GNex some time ago. the neat thing about it: it works when you raw-flash it using fastboot to the boot partition. and it reads the actual kernel from the filesystem
[21:40] <pmcgowan__> mhall119, exactly, and why I have two phones still
[21:47] <slangasek> ogra: so I think android-tools-adbd should be fixed to exec /bin/sh, not /system/bin/sh
[21:47] <slangasek> ogra: any objections if I upload this?
[21:49] <stgraber> slangasek: actually, can we have it call /bin/bash? dash is annoying for interactive shells
[21:50] <slangasek> ogra: ah - actually, it seems the adbd source will do this if we define ADB_HOST, but I'm not sure if that's the right thing to do in this context; do you know?
[21:50] <slangasek> stgraber: I agree, but that's why you call 'exec bash' after connecting :-)
[21:50] <slangasek> stgraber: i.e., it's inconvenient but I don't think we should rely on /bin/bash here
[21:51] <stgraber> actually, having it use the shell of the user it's running under would probably make sense (and give us bash)
[21:51] <slangasek> stgraber: I'm not volunteering to write that at the moment, I'm just trying to get an adbd that will let me get into the system given that my /system is failing to mount
[21:54] <stgraber> slangasek: should be a pretty simple change, I can take a quick look at it
[22:03] <stgraber> slangasek: test build worked, doing a test build on armhf so I can test on an actual device
[22:03] <slangasek> ok
[22:03] <slangasek> stgraber: do *you* know whether we should be setting ADB_HOST=1?
[22:05] <stgraber> slangasek: no idea, looks like that'd change adbd's behaviour quite a bit, judging by the number of ifdef
[22:05]  * slangasek nods
[22:06] <stgraber> my change, if it works, basically calls getpwuid(getuid()) and if that returns something reasonable, use ->pw_shell as the shell. If not, fallback to the hardcoded value.
[22:07] <slangasek> hmm, has the current daily image actually been tested to work on the N4?  It seems udev is enabled now
[22:07] <slangasek> but the v4l rules are still in place
[22:07]  * stgraber wishes his pandaboard would have faster I/O, usb2 is slow...
[22:07] <stgraber> slangasek: haven't tested today's, I just apt-get dist-upgrade my nexus4
[22:15] <stgraber> slangasek: looks like my change worked, got a working bash shell even with an empty /system
[22:15] <slangasek> \o/
[22:16] <stgraber> slangasek: want the binary or are you fine to wait for this to hit the archive?
[22:17] <slangasek> stgraber: archive is fine
[22:17] <slangasek> I already hacked something here for myself; but now I'm not even booting all the way to adbd for some reason
[22:20] <stgraber> uploaded
[22:38] <h01ger> another stupid user question: how to quit an app?
[22:41] <greyback_> h01ger: in the Dash, go to Apps lens. Long press on a running application preview, you'll get a close button then.
[22:42] <h01ger> ah. nice. thanks.
[22:42] <h01ger> and how to add my location? i can enter the city but it doesnt take enter or anything..
[22:42] <greyback_> h01ger: that I don't know actually, sorry.
[22:43] <h01ger> np
[22:51] <h01ger> is there a reliable way to get to the dash + the app lens?
[22:57] <slangasek> stgraber: success; now have the N4 booted with a 2GB system partition and the container-flipped setup (though Ubuntu is still on /data/ubuntu because I haven't tried to modify the initramfs yet to do useful things with Ubuntu-on-system)
[23:00] <slangasek> wow, syslog is scary-verbose on here
[23:00] <slangasek> hmmm, because kgsl is failing to find firmware
[23:02] <h01ger> greyback_, add location needs network to work :)
[23:02] <greyback_> h01ger: ah, really? Good to know
[23:03] <h01ger> yup. successfully added two cities now
[23:33] <mhall119> fginther: your packaging for the nemo folderlistmodel works fine for me locally, but jenkins didn't like it
[23:36] <mhall119> fginther: if it's a jenkins error, I'm happy to approve your branch
[23:36] <mhall119> otherwise I'll wait on an update for it
[23:42] <rickspencer3> can anyone suggest a way that I can try to figure out what is making my phone run hot?
[23:43] <slangasek> stgraber: hmm. what version of qml-phone-shell do you have?  when all is said and done here, with 1.74, qml-phone-shell is segfaulting for me on the daily container-flipped image
[23:44] <slangasek> which actually seems to be a much older qml-phone-shell than what's in raring
[23:49] <rickspencer3> hrm ... looking at top, qml-phone-shell is constantly using 30% - 40% of a CPU core right now
[23:50] <slangasek> rickspencer3: seems rather high unless it's actively displaying something... but I can't compare at the moment
[23:50] <rickspencer3> slangasek, just the terminal app
[23:50] <slangasek> hmm
[23:50] <rickspencer3> I wouldn't think it would take that much CPU to ruu top
[23:50] <slangasek> I guess you could adb in and close the terminal, and compare
[23:50] <slangasek> not to run top - but maybe to /display/ top :)
[23:51] <slangasek> (obviously if it is, that's a problem that needs fixing)
[23:51] <rickspencer3> slangasek, yah
[23:51] <rickspencer3> I thought that's what you mean
[23:51] <rickspencer3> t
[23:51] <rickspencer3> ug, phone just became unresponsive
[23:52] <stgraber> slangasek: 1.74
[23:52] <rickspencer3> screw it, I may as well update
[23:52] <slangasek> stgraber: ok; so the problem probably lies somewhere else
[23:52] <rickspencer3> o/ stgraber :)
[23:52] <stgraber> slangasek: is kgsl still complaining?
[23:52] <slangasek> stgraber: I guess an update gives you something different than a fresh install :/
[23:53] <stgraber> hey rickspencer3
[23:53] <slangasek> stgraber: no, once I made /lib/firmware a symlink to /system/etc/firmware, kgsl was happy
[23:54] <stgraber> slangasek: is "test_sf" working?
[23:54] <slangasek> it's dying after sending some ioctls to /dev/binder
[23:54] <slangasek> maybe the lxc container isn't up
[23:54] <slangasek> hmm, no, it is
[23:55] <stgraber> do you see surfaceflinger running?
[23:55] <slangasek> stgraber: yeah, test_sf works
[23:55] <slangasek> so SF is working
[23:55] <stgraber> ok, good
[23:55] <stgraber> try test_egl and test_glesv2 next
[23:55] <slangasek> phablet@ubuntu-phablet:/$ test_egl
[23:55] <slangasek> __pthread_gettid -2
[23:55] <slangasek> stop
[23:55] <slangasek> phablet@ubuntu-phablet:/$ echo $?
[23:55] <slangasek> 1
[23:55] <slangasek> test_glesv2 works though
[23:55] <stgraber> did you test that as root or as the phablet user?
[23:56] <slangasek> phablet
[23:57] <slangasek> I'm not sure if it's worth debugging this then, given that the saucy ppa still has a month-old version of qml-phone-shell :/
[23:57] <slangasek> I'll wait and see what tomorrow's build brings
[23:57] <stgraber> what version do you have (of the shell)?
[23:57] <slangasek> 1.754
[23:57] <slangasek> 1.74