[00:00] <stgraber> slangasek: ok. I'll also reflash mine tomorrow, currently I apparently managed to mess up my partitions or the system in a way that I end up with a read-only data partition, so can't do a whole lot at the moment
[00:00] <slangasek> ok
[00:00] <slangasek> so at a minimum, I've proved that the N4 bootloader doesn't mind if you resize the system+userdata partitions
[00:01] <slangasek> and with the raring image, booting to the shell worked fine... so this current problem is some new glitch with the container flip
[00:36] <mhall119> just phablet-flashed to 152, and man is it so nice having a terminal there by default!
[01:17] <mhall119> sergiusens: when is powerd 0.12 going to be in the device images?
[01:18] <mhall119> glad I still had a package built in /home/phablet
[01:33] <coder543> Hey everyone. I'm excited about the upcoming Ubuntu Touch project, but I had begun to think about various challenges. First and foremost, is there going to be an API for simple second screen support? On iOS, this is useful for Keynote and MLB.tv, among other things. Having this from the beginning would be necessary if it is ever to be supported by developers.
[01:35] <coder543> The other thing was memory management. It would be unique and rather advantageous if we could use something like "kill -STOP <procid>" whenever a task gets backgrounded and hasn't requested backgrounding, and then when we run low on memory, we could save that app's memory to disk in a swap-like fashion. The user would get a continuous experience regardless of how much memory their device has, even if the app would take a moment 
[01:36] <coder543> Just some thoughts.
[01:36] <coder543> The channel doesn't seem as active right now as it is at other times of day though.
[01:41] <mhall119> yeah, it's way late in Europe, and pretty late in the US
[01:42] <coder543> unfortunately. Should I submit these ideas as bugs, maybe? I don't know.
[01:48] <mhall119> coder543: better to write it up in detail on the wiki first, as a full spec
[01:49] <mhall119> as for memory management, we already suspend app processes when they lose focus
[01:49] <mhall119> and there's work for allowing select forms of background execution
[01:53] <coder543> Ok, I figured that app execution would be being paused by now most likely. The last time I used the developer preview was a few months ago, but saving and restoring from disk in low memory situations is something not done by iOS or Android at this point I'm fairly certain and could be nice, if anyone ever has time to do that. Second screen support (or the lack thereof) is something I see as a rather serious blunder in Android. O
[01:53] <coder543> else ever happens. Android 4.2 finally introduced support for the second screen though, I think... but yeah.
[01:54] <coder543> I'm excited, regardless.
[01:59] <mhall119> the kernel should swap out inactive process memory to disk if it needs more
[02:57] <fginther> mhall119, it looks to be a packaging bug, I think the source format is goofed for an inline package.  I'll update and try again
[03:00] <mhall119> fginther: hmm, I've seen inline packages with that source format
[03:01] <mhall119> fginther: though we can probably just apply the patches to the branch  instead of carrying patch files
[03:01] <fginther> mhall119, that's what I'm attempt and converting to native
[03:02] <fginther> should have a update pushed in a minute or two
[03:02] <mhall119> cool
[03:02] <mhall119> if there's anything you need me for, just let me know
[03:10] <fginther> mhall119, \o/ now it passes
[03:13] <mhall119> yay!
[05:51] <Riussi_> http://summit.devaamo.fi/2013/program/
[06:01] <samuraibsd> Having some trouble flashing the image to my Nexus 4
[06:02] <samuraibsd> I followed all the steps, but the recovery it flashed over my CWM gives an error when I try to use autodeploy.zip
[06:06] <samuraibsd> Are my messages actually visible?
[06:27] <samuraibsd> !ping
[06:30] <dholbach> good morning
[06:30] <samuraibsd> dholbach: Can you see this?
[06:31] <dholbach> samuraibsd, that you just asked me if I could see your message? :)
[06:31] <samuraibsd> Yes.  Thank god, someone alive.
[06:32] <samuraibsd> You wouldn't know anything about the flash process would you?
[06:32] <dholbach> Not much. What are you after?
[06:32] <samuraibsd> Trying to install it on my Nexus 4 and while I got the auto deploy zip onto the internal storage, it gave me an error, and now I can't seem to mount my /sdcard from the recovery
[06:33] <dholbach> What was the error message?
[06:33] <samuraibsd> E: Bad
[06:34] <samuraibsd> And now, when I try to do anything to /sdcard, it gives me E: Unable to mount /usb-otg
[06:34] <samuraibsd> Can't adb push the manual image either, since for some reason it won't mount
[06:35] <samuraibsd> With no OS on the device, I can't do it from inside Android either
[06:35] <samuraibsd> Since booting just immediately turns off the device
[06:36] <samuraibsd> I don't even get a boot animation, just the Google splash and the noff
[06:36] <samuraibsd> then off*
[06:36] <dholbach> I never heard of this issue before.
[06:36] <dholbach> Let me see if I can find anything.
[06:36] <samuraibsd> Neither have I
[06:36] <samuraibsd> And apparently neither has Google, I've been searching for hours
[06:37] <dholbach> I couldn't find any trace of that "error message" in the phablet-flash code
[06:37] <samuraibsd> I don't remember exactly what it said, but I remember E: and bad
[06:38] <samuraibsd> my plan was to play around but then...this
[06:39] <samuraibsd> And now phablet-flash won't work either, so I can't even have it do that
[06:40] <samuraibsd> Tells me I have an unsupported device
[06:40] <dholbach> Sorry, it looks like I'm of no help. Maybe you just wait in the channel a bit more until more of Europe wakes up. You might also want to send a message to ubuntu-phone@lists.launchpad.net
[06:40] <dholbach> Just so you're all covered and somebody can help you out with this.
[06:41] <samuraibsd> Eh, worst case scenario I just stay up for the rest of the night and figure it out on my own...but yeah, I didn't know about the launchpad list, that's good to know.
[06:41] <dholbach> All the best!
[06:47] <samuraibsd> Ah, figured it out...though now it seems Ubuntu won't boot
[06:47] <samuraibsd> Step in the right direction
[06:48] <samuraibsd> Interesting...CM 10.1 boots
[07:27] <batman_> Hi
[07:27] <batman_> can i install ubuntu touch on htc sensation
[08:13] <AskUbuntu> ubuntu on nexus 10 shutdown/suspend | http://askubuntu.com/q/304276
[08:28] <mzanetti> we need fitbit integration with the infographics :D
[08:50] <ogra> slangasek, thanks for the session fixes, there is https://code.launchpad.net/~phablet-team/session-manager-touch/trunk as upstream branch fyi
[08:51] <ogra> slangasek, in the adbd build ADB_HOST is already set in the makefile .... and we will also throw away that patch in favour of lool's proper upstream merge in debian once i finally managed to test it
[09:08] <purwoy> test
[10:05] <folf> Hi: Has anyone gotten the catchpodder podcast agent to work on a phone? (I'm running ubuntu touch on a samsung galaxy nexus).
[10:07] <netcurli> folf: as I am waiting for the download in the background feature, development for catchpodder is currently on halt
[10:07] <netcurli> but if you want to run the current version, I can help you
[10:08] <ogra> Saviq, if you make such changes, can you let me know so i can update the saucy seeds and packages in the archive accordingly ?
[10:09] <Saviq> ogra, you mean the s/qml-phone-shell/unity8/?
[10:09] <ogra> Saviq, right, for saucy we currently build two images ... one via jenkins and the other on cdimage
[10:10] <ogra> they use different seeds and session managers
[10:10] <ogra> once the container flip is done we'll drop the jenkins build
[10:10] <Saviq> ogra, oh, didn't know that
[10:10] <ogra> no worries :)
[10:10] <Saviq> ogra, anyway, would definitely let more people know before merging that
[10:11] <ogra> ok
[10:11] <ogra> include me then :)
[10:11] <Saviq> ogra, will do
[10:11] <ogra> thanks :)
[10:11] <folf> netcurli: I just want to try out the current version :-) so some advice on how to set it up would be nice
[10:13] <netcurli> so at the moment, you will need to grab this plugin code https://code.launchpad.net/~djfun/catchpodder/filedownload
[10:14] <netcurli> and compile and install it on the device
[10:14] <samuraibsd> So just installed this guy on my N4 and got it to boot.  Seems like it'll be pretty legit once it's actually ready for release.  I dig it.
[10:14] <ogra> :)
[10:15] <netcurli> and then you should be able to run the qml app from trunk
[10:21] <folf> netcurli: is starting it from the phone supported? I mean, can it be added to the list of installed apps?
[10:23] <netcurli> I have not added any packaging yet, it is possible, but you need to place the .desktop file in the correct directory (/usr/share/applications ?!) yourself
[10:26] <folf> netcurli: ok thanks :-)
[10:40] <asac> kgunn: do you feel you own the "primary phone unlock experience with SIM-PIN/PUK" or is it jasons team?
[11:12] <davmor2> hey guys I noticed an issue on the nexus 7 last night.   if you set an alarm leave the clock app open, and then let the device sleep every 10 seconds or so there is a burst of light from it  I'm assuming it is a bad thing for that to be happening but I have no idea what is doing it or where or what to file it against any clues?
[11:14] <davmor2> you however won't see it during the day so I'm assuming it isn't that bright in reality but you certainly notice it at night :)
[11:46] <nik90> davmor2: what do you mean by burst of light? The whole screen? Do you have any screenshots for better clarification?
[11:47] <sil2100> didrocks: https://code.launchpad.net/~sil2100/qtvideo-node/fix_ftbfs_with_new_libhybris/+merge/167509
[11:47] <davmor2> nik90: yeap whole screen lights up for a split second and then is dark again
[11:47] <nik90> davmor2: that's wierd
[11:47] <nik90> davmor2: is this only with the clock app?
[11:48] <nik90> davmor2: for bug related to clock app, you can report them at https://bugs.launchpad.net/ubuntu-clock-app/+filebug
[11:49] <davmor2> nik90: no idea it is the first time that the tablet had been useful enough to take to bed and use in place of my Xoom.  It may be the tablet as a whole doing it rather than the clock app I was just highlighting what I did for reproduction :)
[11:49] <nik90> davmor2: :)
[11:58] <mardy> mzanetti: hi! Do you want to resume our OAuth chat?
[11:59] <mzanetti> mardy: hey, sure
[11:59] <mzanetti> mardy: so... yesterday I failed because I realized that qca2 seems to build and link with Qt5 but then crashes in init()
[11:59] <mardy> mzanetti: so, I've been giving it some more though, and probably understood that we have different goals in mind
[11:59] <mardy> mzanetti: qhat is qca2?
[12:00] <mardy> *what
[12:00] <mzanetti> mardy: Qt's openssl implementation
[12:00] <mzanetti> mardy: qoauth is build on top of that for example
[12:00] <mardy> mzanetti: OK
[12:00] <mardy> mzanetti: so, there is nothing preventing apps from dealing with OAuth themselves
[12:01] <mardy> mzanetti: but what UOA (Ubuntu Online Accounts) provides is a bit different
[12:01] <mzanetti> mardy: yeah... for some things I think it really makes sense to integrate into the UOA. But not for everything I think
[12:01] <mardy> mzanetti: we don't handle just OAuth, but all authentication methods
[12:01] <mzanetti> mardy: yeah... I understood that too when looking at the architecture pics of UOA
[12:02] <mzanetti> mardy: but think about this use cases:
[12:02] <mardy> mzanetti: we add support for multiple OAuth accounts for the same provider, which is something very difficult to do for an app handling OAuth itself
[12:03] <mzanetti> mardy: a) I have an app that lets me find car2go's. I can create bookings if I'm oauth authenticated. But that doesn't give me any contacts or anything that would make sense showing up in all accounts. Its just that one app that needs to authenticate itself
[12:03] <mzanetti> b) same goes for a fitbit app wanted to create. However, as I realized that it would be ubercool to have the fitbit stats directly in the infographics, I think that's actually use case for UOA
[12:04] <mardy> mzanetti: yes, for (a) the benefit of using UOA is not much
[12:05] <mardy> mzanetti: that is generally the case with app using a single account, for a well known provider
[12:05] <mzanetti> mardy: yep
[12:05] <mzanetti> mardy: anyways, exactly for this use case I came up with the in-process WebView to do the auth
[12:05] <mardy> mzanetti: UOA is mostly useful for apps like Empathy, Shotwell, Evolution, which support many accounts/services, and of different types
[12:06] <mzanetti> mardy: yep I understood that
[12:07] <mzanetti> mardy: is the UOA team still the right one to talk about a in-app OAuth API or should I rather go to the SDK guys with that?
[12:07] <mardy> mzanetti: but even for simpler apps, I think that now we have a QML API which is infinitely simple (despite the complex architecture it hides): http://bazaar.launchpad.net/~online-accounts/accounts-qml-module/trunk/view/head:/examples/simple-view.qml
[12:08] <mardy> mzanetti: good quesion, I don't know :-)
[12:11] <mardy> mzanetti: however, I wonder if it's worth it
[12:11] <mardy> mzanetti: as you said yourself, it's not difficult for a developer to setup a QtWebKit view and perform the oauth in there
[12:11] <mardy> mzanetti: and that's more portable than using a component we provide
[12:12] <mardy> mzanetti: so, I'm not sure there's much point for someone to use our API
[12:13] <mzanetti> mardy: yeah... ok... the more I think about it, the more it seems a SDK thing (making libqoauth work on the phone etc)
[12:36] <didrocks> sil2100: maybe try with upstream for this fix? they can maybe look at the other ones as well
[12:37] <sil2100> didrocks: which fix?
[12:40] <cri> galaxy tab2 p3100 enable 3g and call phone?
[12:41] <ogra> cri, talk to the person doing the port ... he/she should be noted on the wikipage for the device
[12:43] <cri> ogra, tanks
[12:57] <cking> stgraber, did you get my email with the ext4 comparisons?
[13:03] <mhall119> Ubuntu Touch Clinic Hour starts now
[13:03] <mhall119> Dr. Pope isn't in, so it's just me today
[13:03] <jussi> ooh
[13:03] <mhall119> if you have any questions, go ahead and ask 'em
[13:04] <jussi> so how the heck do I install anything?  the install icons don't work. (main screen at the bottom)
[13:04] <mhall119> yeah, that's not working yet, it's going to be part of Unity 8
[13:04] <mhall119> for now you need to apt-get from the terminal
[13:04] <jussi> oh, right. well that explains it.
[13:05] <mhall119> but, the good new is, there's a terminal installed by default now!
[13:05] <jussi> :)
[13:05] <mhall119> you can search the Apps lens by tapping the "Search" on the top panel while in the Apps lens
[13:07] <blaroche> are there any build docs for indidual apps like phone-app?
[13:07] <blaroche> i wanted to start hacking on it and maybe others... see if i can fix a bug or two .. or more
[13:08] <blaroche> just started looking at it last night, and was hoping to get time this weekend to really dig in
[13:08] <mhall119> blaroche: they should all have something
[13:08] <mhall119> it looks like the gallery-app just uses qmake .pro files
[13:08] <mhall119> and they should all have inline ./debian/ packaging too
[13:08] <blaroche> mhall119: i think i just have to spend time at it.  work out the cmake dependencies
[13:09] <mhall119> if you have the bzr-builddeb package installed, you can just cd into the bzr branch directory and run "bzr builddeb -- -us -uc" to get a binary package
[13:09] <mhall119> build dependencies should all be listed in ./debian/control on the Build-Depends line
[13:10] <blaroche> mhall119: thank you.  i think that will get me going :)
[13:10] <mhall119> blaroche: good luck, you can always come back with more questions anytime
[13:11] <blaroche> mhall119: thanks, i will
[13:19]  * h01ger just thought the weather app was broken, as it showed "sunny" for each day until june 10th in hamburg ;-) i was reliefed to see clouds+rain on the 11th 8-)
[13:20] <mhall119> h01ger: sounds like a bug in hamburg
[13:20] <h01ger> definitly. but tagged "worksforme" too
[13:21] <mhall119> we can be a pessimistic bunch through can't we?  I almost files a bug yesterday because my battery wasn't draining as fast as I expected it to :)
[13:21] <h01ger> :)
[13:33] <m-b-o> h01ger:  I've double checked and looked out the window: sun is actually shining in HH :)
[13:34] <om26er> Hey! How do I check my build number ?
[13:39] <brejoc> hi there, are clinic hours still taking place?
[13:42] <mhall119> om26er: good questions, I've wondered that myself
[13:42] <mhall119> om26er: usually I just check the highest number in ~/Downloads/phablet-flash
[13:42] <mhall119> brejoc: yes
[13:42] <mhall119> for the next 20 minutes
[13:44] <mhall119> popey and I do this every Wednesday
[13:44] <mhall119> of course, you can ask questions any time in here
[13:44] <om26er> mhall119, that's different for me as I have a few  devices connected to the same machine, so I am not sure which one of them is updated and which is not
[13:44] <mhall119> but we've set this hour as a committed time for helping folks
[13:45] <brejoc> nice. i've already asked that on the mailing list ([Ubuntu-phone] push to device messaging). Is there already a push notification system planned or is this something we'd have to initiate?
[13:46] <mhall119> brejoc: there's been a push notification system discussed, but I don't think it's being planned yet
[13:46] <mhall119> aquarius and I discussed how it might be done as part of Ubuntu One
[13:48] <brejoc> mhall119: cool. will there be plans publicly available to participate in the discussion?
[13:49] <mhall119> brejoc: I'm sure there will be
[13:49] <mhall119> possibly at the next UDS
[13:50] <mhall119> which I believe will be around August
[13:50] <brejoc> mhall119: thanks!
[13:50] <mhall119> no problem
[13:54] <stgraber> cking: I did, thanks! I forwarded it to the rest of the people involved in yesterday's discussion.
[13:55] <cking> stgraber, cool, if it needs revisiting with different tests, let me know I will see what we can do, but I'm tight on time nowadays
[13:56] <stgraber> cking: it currently looks like we'll be using loop mounted images for devices where we can't grow/shrink the system and userdata partition to match what we need
[13:56] <stgraber> cking: so hopefully use physical partitions on the devices we support ourselves and use loop-mounted partitions on the others (unless whoever is doing the community port figures out how to resize the partitions safely on their device, then they can do it too)
[13:57] <h01ger> m-b-o, yeah its strange. and whats even more strange: since 5 days basically.
[13:57] <ogra> cking, revisiting with different device would help a lot
[13:57] <brejoc> one more question. i've been porting (no work at all) and testing saltstack, a remote admin tool, to ubuntu touch. salt has to be started via upstart. has anything to be done to make this work with the new container concept - especially in "touch mode"?
[13:57] <cking> stgraber, ok, well, I didn't account for any tweaks on mount options or the vm to ensure we flush data more periodically to ensure data loss is minimised
[13:57] <ogra> cking, the device category we target is like a third of the n4
[13:57] <stgraber> cking: if you have a galaxy nexus, test results on it would be great. Otherwise I think sergiusens said he could do those measurements if you can provide him with instructions
[13:58] <ogra> (read: we target the galaxy nexus class (dual core 1.2GHz/512M ram) by default
[13:58] <cking> ogra, third in sense of what? CPU cycles, memory, etc?
[13:58] <ogra> yeah
[13:58] <ogra> might even be only 900MHz ... i'm not 100% sure
[13:58] <ogra> but definitely a lot lower than the n4
[13:58] <ogra> i guess that will have some impact on the results
[13:58] <cking> stgraber, if he's got a 6.5 digit precision multimeter, then it's repeatable
[13:59] <bobweaver> ping jstill no way to daul boot the n4 ?
[13:59] <bobweaver> woops
[13:59] <ogra> bobweaver, nope, and it will get more and more unlikely
[13:59] <bobweaver> still no way to boot the n4 ?  *
[13:59] <bobweaver> ogra,  why is that ?
[14:00] <ogra> (dual booting that is ... booting alone should work since ages :) )
[14:00] <ogra> bobweaver, because we move away from android more and more
[14:00] <ogra> the flipped images already use an ubuntu initrd and require a certain setup that will likely break with dual boot hacks
[14:01] <ogra> and see above
[14:01] <ogra> there are even plans to re-partition the devices
[14:01] <bobweaver> that is a good idea but for us people irl  we can not afford to loose money with missed text messages and what not
[14:01] <ogra> (though i think we cznt really do that)
[14:01] <ogra> *can't
[14:02] <ogra> you shouldnt lose text messages at all if you use the stable image
[14:02] <cking> ogra, I'll email sergiusens a guide on how to rig up the test
[14:02] <ogra> cking, awesome, thanks !
[14:02] <bobweaver> ogra,  I figured out why "Ubuntu Touch could not stream movies over the net" with qtmultimedia
[14:03] <sergiusens> cking: I can get a hold of electronics... not ASAP, but I can
[14:03] <bobweaver> has nothing to do with gstreamer as I was told in the past
[14:03] <AskUbuntu> Phones that support Ubuntu Touch? | http://askubuntu.com/q/304399
[14:03] <ogra> !devices | AskUbuntu
[14:04] <bobweaver> it is that my movies where not in intervals of 500 so they would not play not that I did that, they play fine and dandy. (qt 5.1beta)
[14:04] <ogra> officially supported are only the nexus devices ...
[14:04] <ogra> bobweaver, cool
[14:04] <sergiusens> ogra: I see Nexus S4 :-P Might be confused with Samsung's S4 (or I am out of sync and these are Nexus indeed)
[14:05] <ogra> heh
[14:05]  * ogra has no clue about non google nexuses 
[14:06] <bobweaver> ogra,  Example of text that I missed http://paste.ubuntu.com/5735859/    I lost about 300 usd because of it
[14:06] <brejoc> #doublepost  -- one more question. i've been porting (no work at all) and testing saltstack, a remote admin tool, to ubuntu touch. salt has to be started via upstart. has anything to be done to make this work with the new container concept - especially in "touch mode"?
[14:07] <ogra> bobweaver, thats what you get using a device clearly marked for development and dogfooding in financially critical production context
[14:07] <ogra> bobweaver, seriously, if you hevily rely on SMS to make money, dont use ubuntu touch yet
[14:08] <ogra> brejoc, does it require anything on the android side ?
[14:09] <ogra> if it can run on i.e. ubuntu-desktop it wont make any difference wether the container is flippped or not
[14:09] <bobweaver> ogra,  yeah lesson learned but I guess that all these people that are saying that everything works great in all there blogs and there posts on g+ made me feel a little saver maybe they are to blame and my stupidity
[14:10] <bobweaver> IDK what dogfooding is
[14:11] <ogra> eating your own dogfood ...  -> using your own unstable software to find its issues
[14:11] <ogra> (emphasis on "unstable" :) )
[14:11] <bobweaver> I see thanks ogra
[14:11] <ogra> it surely works great regarding the expectations ...
[14:11] <ogra> but i wouldnt 100% rely on it
[14:12] <ogra> since bugs are expected
[14:12] <brejoc> ogra: no, just plain ubuntu
[14:12] <bobweaver> yeah I have it on my m7 but not on my n4 any more
[14:12] <ogra> brejoc, then the container flip shouldnt have any influence
[14:12] <bobweaver> n7 *
[14:12] <ogra> yeah, thats what i would od as well
[14:12] <ogra> (if my n7 coould boot the flipped container images :P )
[14:14] <didrocks> sil2100: it seems you missed https://launchpadlibrarian.net/141698927/buildlog_ubuntu-saucy-i386.unity-scope-gdrive_0.9daily13.06.05-0ubuntu1_FAILEDTOBUILD.txt.gz
[14:15] <didrocks> sil2100: and https://launchpadlibrarian.net/141693500/buildlog_ubuntu-saucy-armhf.dee_1.2.5ubuntu1daily13.06.05-0ubuntu1_FAILEDTOBUILD.txt.gz :(
[14:15] <brejoc> ogra: good to know, thanks. one thing i still don't get is the method that has been chosen to determine which daemons are running in touch and desktop mode. is there a document available with more insight?
[14:15] <didrocks> I'm relaunching the second
[14:16] <ogra> brejoc, no, we dont have anything like that yet, i guess thats a matter of convergence which is a 14.04 task
[14:17] <ogra> brejoc, i think upstart offers a way to find whats running though ... i guess we will make use of that
[14:18] <ogra> but thats really up fro discussion still, converged setups are not in focus for 13.10
[14:18] <brejoc> okay. thank you very much!
[14:23] <didrocks> davidcalle: still around?
[14:24] <ubuntero> I will present a lecture on Ubuntu and Ubuntu Touch tonight and would like to show Ubuntu Touch with core-apps. There is a way to put the core-apps in Ubuntu touch menu?
[14:28] <blaroche> ubuntero: i use http://bazaar.launchpad.net/~popey/+junk/phablet-flash-wrapper/view/head:/add_apps.sh
[14:28] <blaroche> line 56
[14:29] <ubuntero> blaroche, thanks
[14:29] <blaroche> thank popey :)
[14:31] <davidcalle> didrocks, sure
[14:32] <didrocks> davidcalle: unity-scope-gdrive failed https://launchpadlibrarian.net/141698927/buildlog_ubuntu-saucy-i386.unity-scope-gdrive_0.9daily13.06.05-0ubuntu1_FAILEDTOBUILD.txt.gz
[14:32] <didrocks> davidcalle: do you mind giving it a look (and poking sil2100__ once he's back)
[14:32] <didrocks> sil2100__: I've fixed the second one by a rebuild
[14:33] <mhall119> ubuntero: line 56 on that is really all you need
[14:34] <mhall119> that will let you expand the Installed Apps section
[14:37] <davidcalle> didrocks, a segfaulting test? For me? Thanks! :p
[14:39] <didrocks> davidcalle: yw! ;)
[14:40]  * bobweaver has just added Ubuntusdk toolkit to qt5.1 android lets see if it works on android 
[14:40] <bobweaver> ahh stupid gio things are getting in the way
[14:40] <didrocks> sil2100__: btw, you didn't remove the shopping lens from the config :/
[14:40]  * bobweaver dont care aout icons 
[14:42] <mhall119> bobweaver: the Ubuntu.Components have been built on MacOSX, so I'm sure they'll work on Android too
[14:43] <bobweaver> jhodapp,  ping
[14:43] <bobweaver> jhodapp,  I was able to get streaming happening on qt5.1 qtmultimedia
[14:43] <bobweaver> jhodapp,  I am uploading a video atm will post when done
[14:44] <jhodapp> bobweaver, hey
[14:45] <jhodapp> bobweaver, does it have its own set of streaming sources?
[14:45] <bobweaver> not sure what you mean by that
[14:45] <bobweaver> it was a bug in android and not qt or anything like that
[14:45] <bobweaver> videos have to be in intervals of 500
[14:46] <jhodapp> bobweaver, well what do you mean by streaming then?
[14:46] <bobweaver> my souce is from my myth tv backend here on my lan
[14:46] <bobweaver> before it would not play  my videos
[14:46] <bobweaver> remember
[14:46] <jhodapp> bobweaver, ok, it's using gstreamer underneath?
[14:47] <bobweaver> IDK Or IDTS
[14:47] <bobweaver> let me look at log
[14:47] <jhodapp> bobweaver, join #ubuntu-media
[14:57] <cking> sergiusens, ogra, benchmarking notes posted
[14:58] <sergiusens> cking: thanks
[14:59] <ogra> cking, yay
[15:05] <AskUbuntu> Asus Vivotab Smart ME400C | http://askubuntu.com/q/304400
[15:09] <h01ger> it seems neither phablet-flash -d grouper -b nor phablet-flash -b seems to work on a nexus7. both get stuck in the bootloader, trying to write to /sdcard/
[15:15]  * h01ger used an outdated version of phablet-flash
[15:16] <MacSlow> Saviq, backend is correctly exported now and working... but something with snap-decisions is broken... looking into it
[15:18] <ogra> cking, oh, you actually tested with only one loop mounted img ... great (the actual implementation would have like 4 loop mounts, i wonder if the impact would be worse)
[15:18] <cking> ogra, i expect so, pressure on vm will be higher I guess
[15:18] <ogra> yeah
[15:19] <cking> ogra, i suspect that there will be far more dirty pages flying around which is always bad.
[15:20] <ogra> yup ...
[15:20]  * ogra thinks we should just keep what we have atm ... probably with some changes and improvements but just use the existing partitions
[15:20] <cking> ogra, I admit my tests were naive, but they give one an idea of the impact at best case
[15:20] <ogra> yeah
[15:21] <ogra> and i expect it to be a lot worse it multiple images on a galaxy nexus
[15:22] <bobweaver> ogra,  do you if there is a way to run x11 on android that is not vnc
[15:22] <bobweaver> like how the n7 images where
[15:22] <ogra> nope, i dont think there is one
[15:23] <ogra> the n7 images didnt use any android
[15:23] <bobweaver> ogra,  I see thanks
[15:23] <bobweaver> ogra,  btw your awesome !!!!
[15:23] <ogra> with the flipped container it might be possible to get xfbdev up though
[15:23] <ogra> but without any GLES support ... i doubt that would help much
[15:23] <ogra> heh, thanks :)
[15:24] <Saviq> MacSlow, cool
[15:24] <rickspencer3> awe_, rsalveti, et al .. have I mentioned how much I enjoy having cellular data now?
[15:25] <ChickenCutlass> rickspencer3, is it working ok for you?
[15:25] <rickspencer3> ChickenCutlass, yeah, I just followed rsalveti's directions in his blog
[15:25] <rickspencer3> worked fine
[15:25] <ChickenCutlass> rickspencer3, excellent.
[15:26] <rickspencer3> looking forward to having the indicator support and all, of course
[15:26] <ChickenCutlass> me too
[15:27] <bobweaver> ogra,  why no gles support ?
[15:27] <bobweaver> E/libEGL  (27730): eglDestroySurface:383 error 300d (EGL_BAD_SURFACE)
[15:27] <ogra> bobweaver, because xfbdev directly attaches to fb0 and thats it
[15:27] <ogra> it might not even work without kernel changes
[15:28] <ogra> (since we dont have any framebuffer console enabled etc)
[15:28] <ogra> we should see Mir on the images soon though, that should make everything better :)
[15:28] <ogra> (and once XMir exists you will even be able to run X apps)
[15:35] <awe_> rickspencer3, thanks!  glad you like it!
[15:36] <rickspencer3> :)
[15:36] <rsalveti> rickspencer3: awesome
[15:37] <rsalveti> first step, more to come
[15:37] <rsalveti> it'll only get better ;-)
[15:37] <rickspencer3> :)
[15:37] <rickspencer3> rsalveti, I understand that copying the network configuration file over and using the terminal to up/down the network connection are hacks for now
[15:38] <rickspencer3> but, the data actually working seems like the foundation
[15:38] <rsalveti> rickspencer3: yeah :-) we're happy we're able to communicate with the modem properly, and setting up the connection
[15:38] <rsalveti> now we just need to hook that up properly with the higher stacks
[15:40] <rickspencer3> rsalveti, will you be able to reuse NM code for writing out the configuration file?
[15:40]  * rickspencer3 presumes that someone will have to write a new GUI
[15:40] <awe_> rickspencer3, that work is underway
[15:41] <rsalveti> rickspencer3: yeah, cyphermox_ is working on getting that more kind of automatic
[15:41] <awe_> the idea is that NM will talk to ofono and get the config information directly
[15:41] <rsalveti> crap, another net split
[15:41] <rsalveti> so in theory all you'll need to do is setting up 'I want data call' :-)
[15:42] <rsalveti> and in case your sim card doesn't offer you the right apn settings, you can then manually create the config
[15:46] <rickspencer3> rsalveti, sounds cool
[15:46] <rickspencer3> meantime, looks like the container flip and move to 100% saucy are both going well too
[15:48] <rsalveti> rickspencer3: yup, lot of progress on both
[15:48] <minhasse> hi
[15:50] <minhasse> hello, i have a problem trying install the unbuntu touch
[15:50] <minhasse> failed to copy 'Descargas/raring-preinstalled-phablet-armhf.zip' to '/sdcard/autodeploy.zip': Permission denied
[15:50] <minhasse> someone can help me¿?
[15:53] <stgraber> slangasek: tried today's build yet? I'm downloading it now so just wondering whether it'll boot or not :)
[15:53] <slangasek> stgraber: I have not
[15:53] <slangasek> stgraber: ubuntu-touch or ubuntu-touch-preview?
[15:55] <stgraber> slangasek: I'm grabbing ubuntu-touch
[15:57] <slangasek> stgraber: yep - I haven't tried it at all yet; certainly, the previous build didn't work so hot for me
[15:57] <slangasek> ogra: which is the last ubuntu-touch image that works for you?
[15:57] <cjwatson> What's the recovery path like if I try ubuntu-touch and it explodes?
[15:57] <stgraber> slangasek: yeah, I suspect we may still have some problems related to video4linux
[15:58] <stgraber> cjwatson: boot to recovery, adb push the touch-preview .zip, reboot to recovery to have it flash
[15:58] <slangasek> ogra: btw, where's the best place to work around bug #1187189?  I think we probably need to apply a divert in some common ubuntu-touch package, since we don't have per-device images
[15:58] <cjwatson> ok, so not too terrible
[15:59] <stgraber> cjwatson: worst case is 2 run through recovery (once for each .zip) and a fastboot flash of the boot partition
[15:59] <stgraber> cjwatson: but yeah, we don't touch the recovery partition, so you can't really brick the device, worst case is really just restoring the boot partition and reset the data partition (which the .zip + recovery do)
[16:07] <AskUbuntu> problem trying install unbuntu touch | http://askubuntu.com/q/304439
[16:11] <ogra> slangasek, funny, i dont see it on maguro
[16:11] <slangasek> ogra: sure, it's hardware-specific
[16:11] <slangasek> or kernel-specific
[16:11] <slangasek> but the rules are in the hardware-independent udev package, which means we need to apply a workaround to the rootfs
[16:11] <ogra> slangasek, i would put is into lxc-android-config ... if you dont have android containers you probably want the device and its full function
[16:12] <slangasek> ok
[16:12] <slangasek> to be honest, I don't think it's related to the Android container, but I don't really care - we just need somewhere to put a dpkg diversion temporarily until the kernel bug can be fixed
[16:12] <ogra> udev should really have a way to just put a rules file in place with lower sequence number that says "ignore" or so
[16:13] <slangasek> hmm, maybe it does
[16:13] <ogra> well, android vs x86 native images
[16:13] <slangasek> stgraber: ^^ can you think of anything?
[16:23] <stgraber> ogra: did you change something wrt how the partitions are mounted? I seem to always end up with a read-only data partition after boot now which prevents the lxc container from starting
[16:23] <stgraber> (that's after manually removing the udev v4l rule file, otherwise the device won't even boot)
[16:25] <seb128> mardy, hey
[16:26] <mfisch> ChickenCutlass: we listen for IncomingMessage to turn the screen on, but what about ImmediateMessage?
[16:26] <mfisch> ChickenCutlass: The docs mention a "Class 0 SMS", not sure what that is though
[16:27] <slangasek> rsalveti: hi, so I see you've marked "investigate ueventd vs. udev" as "Done" - what's the result of that investigation?
[16:29] <rsalveti> slangasek: our investigation was more to know if it'd be possible to have udev and uevent running at the same time
[16:29] <rsalveti> as we were more worried that uevent could be broken because of it
[16:29] <rsalveti> which is not the case
[16:30] <rsalveti> so I marked it as done
[16:30] <slangasek> right
[16:30] <slangasek> ogra still has concerns about double-loading of firmware
[16:30] <slangasek> are you saying that's not an issue?
[16:31] <rsalveti> which firmware specifically?
[16:31] <slangasek> I don't know
[16:31] <rsalveti> the way android loads the firmware is not as standard as we have
[16:31] <rsalveti> it's mostly part of init scripts and such
[16:31] <slangasek> fwiw, my experience was that ueventd was *not* managing to load the firmware for me, because udev was too quick and had the modules loaded before the android container ever started
[16:32] <rsalveti> I'm only concerned with the wifi drivers, but that's broken anyway
[16:32] <slangasek> which is why I suggested udev should read /system/firmware and /vendor/firmware directly (and pitti has already uploaded this change)
[16:32] <rsalveti> right
[16:32] <slangasek> we may have to guarantee that /system and /vendor are mounted before we start udev, to ensure the drivers get their firmware
[16:33] <rsalveti> hm, right
[16:34] <rsalveti> that might complicate things around, but yeah, don't see an easier way
[16:34] <slangasek> rsalveti: I'm merely calling this out as a reminder - I believe *currently* these are mounted from the initramfs before we ever start upstart, so no problem.  We just have to take care to guarantee this in the future if we do change the partitioning
[16:34] <rsalveti> right, ok
[16:35] <rickspencer3> anyone else noticing QtCreator spawning little windows for now discernable reason?
[16:35] <rickspencer3> bzoltan1, ^ ?
[16:35] <bzoltan1> rickspencer3:  It is a known issue for few weeks already... it is a present from upstream
[16:35] <rickspencer3> it's pretty annoying
[16:36] <bzoltan1> rickspencer3:  it is
[16:36] <ogra> slangasek, /system and /vendor are now handled by mountall
[16:36] <ogra> slangasek, should be sufficient for udev
[16:36] <slangasek> ogra: no, handled by mountall is much too late for udev.
[16:36] <bzoltan1> rickspencer3:  it will go away with newer Qt
[16:37] <ogra> slangasek, oh, really ? i thought the rootfs mountall starts later
[16:37] <ogra> err
[16:37] <ogra> s/mountall/udev/
[16:38] <bzoltan1> rickspencer3: the workaround is to delete ~/.config/QtProject and never click on the "Develop" tab.
[16:38] <ogra> oh, yeah
[16:38]  * ogra sees it starts on virtual-filesystems
[16:38] <rickspencer3> bzoltan1, ok, I'll try that
[16:38] <ogra> slangasek, thats bad, we might need to apply an override file that makes it wait until the container is up
[16:38] <slangasek> ogra: the standard ordering is that /mountall/ relies on /udev/ to probe the disks for it and make them available so that mountall can mount them... so if udev in turn needs mountall to mount /system and /vendor for firmware, you've got a race
[16:39] <ogra> so that we are sure android has done its duty
[16:39] <slangasek> ogra: no, there's nothing that should wait for the container; we just need to early-mount /system and /vendor from the initramfs
[16:39] <bzoltan1> rickspencer3:  I hope it helps. This issue came with the Qt 5.0.2 and known to exist in the upstream distributed releases too
[16:39] <ogra> slangasek, then we might end up with double loading the firmware
[16:39] <slangasek> ogra: please discuss that with rsalveti :)
[16:39] <ogra> android will definitely force load it once we bring up the container
[16:40] <ogra> i have no idea if thats bad or not ... but if there are any options handed to the fw we definitely want them to come from android, not from ubuntu
[16:40] <rsalveti> I don't see that waiting android to load as an issue
[16:40] <bzoltan1> rickspencer3: I have checked that either with the 2.8 QtC it is gone as with the Qt 5.1 it is resolved too.  So the problem is solved, we just need to reach with our roadmap the 2.8 QtC or the 5.1 Qt ... July-August
[16:41] <ogra> (i know the broadcom fw needs the right parameters applied when loading it ... i guess there are others as well)
[16:41] <rsalveti> yup, android usually gets a quite custom init script for most of the things
[16:41] <rsalveti> that's why I'd prefer not touching it unless it's really needed
[16:41] <ogra> rsalveti, well, if  the already laoded fw blocks loading it again and udev already loaded it with wrong args, we're screwed
[16:41] <rsalveti> and wait cyphermox_ to understand all the issues with the wifi drivers
[16:42] <rsalveti> yup, that's why for now I'd not make udev to load them
[16:42] <ogra> so i would prefer if we could make sure that android has it in its hands
[16:42] <slangasek> ah
[16:42] <rsalveti> yup, at least for now
[16:42] <rsalveti> until we can understand things a bit better
[16:43] <slangasek> ok, so if we are delegating the firmware loading to android anyway
[16:43] <slangasek> then we can probably revert this udev change (yay)
[16:43] <ogra> and if slangasek/stgraber actually find a way for v4l to suppress udev we might want to use the same thing for all devices we know ship with fw
[16:43] <slangasek> and just make udev start later
[16:43] <ogra> well, we want udev to apply the android rules if the container comes up
[16:43] <slangasek> what do you mean, "the android rules"?
[16:43] <ogra> there are already quite a few links and permission changes i ship in lxc-android-config
[16:44] <slangasek> /lib/udev/rules.d/65-android.rules ?
[16:44] <ogra> and i expect that to grow a lot
[16:44] <ogra> yeah
[16:44] <slangasek> udev will apply those whether the container is running or not
[16:44] <slangasek> and ueventd will of course create them initially with the right perms, not relying on udev for this
[16:45] <ogra> hmm
[16:45] <ogra> k
[16:45] <ogra> then it should be no issue
[16:45] <ogra> the point is that only loading the driver will get you a kernel event for some of them
[16:46] <ogra> so udev actually should be up before the container since thats what loads them
[16:46] <ogra> i guess we're good then
[16:46] <slangasek> how do we know when the container is done "starting"?
[16:46] <ogra> not sure if lxc-init blocks ...
[16:46] <slangasek> "udev actually should be up before the container" - hmm?
[16:47] <ogra> i was kind of assumeing that (if you look at the upstart job)
[16:47] <slangasek> that's exactly the opposite of making sure ueventd loads the firmware
[16:47] <ogra> you want udev to be up to catch the uevents
[16:47] <slangasek> lxc-init has no way to block
[16:47] <ogra> hmm, k
[16:47] <slangasek> why do you want udev to catch the events?  you said you want them handled by ueventd
[16:47] <ogra> then we might have to add a parker in init.rc
[16:47] <ogra> s/parker/marker
[16:48] <ogra> sigh, my typing
[16:48] <ogra> slangasek, i want udev to create the links once devices show up
[16:48] <slangasek> ogra: udev always creates links for *all* devices; see the udevtrigger job
[16:48] <ogra> i'm not sure it catches the uevents if they were processed by ueventd already ... do they stay in the queue ?
[16:49] <ogra> yes, udev isnt my concern, the kernels queue is
[16:49] <ogra> if ueventd processed the event, does it still stay in the queue ?
[16:49] <slangasek> it's not a queue... udevtrigger forces "coldplug" reprocessing of all hardware events
[16:49] <ogra> ah
[16:49] <slangasek> it walks the hardware tree and forces re-emitting of events for everything
[16:49]  * ogra always thought the kernel had an even queue 
[16:49] <ogra> ok
[16:50] <slangasek> it does, but that's not what's used for udevtrigger
[16:50] <ogra> then there are no issues i suppose
[16:50] <slangasek> right, the only issue is properly deferring the udev startup until ueventd is done
[16:50] <slangasek> and I don't know how you represent that
[16:51] <ogra> well, if udevtrigger re-processes everyhting we could just call that
[16:51] <ogra> regardless when udevd is started
[16:51] <ogra> like ... call it from the lxc upstart job
[16:51] <slangasek> how does that help us avoid races between udev and ueventd for loading the firmware?
[16:51] <ogra> it doesnt
[16:51] <slangasek> but that's the problem we need to solve
[16:52] <slangasek> we need to not start udev until ueventd is done with its firmware loading; anything else will be a race
[16:52] <slangasek> well
[16:52] <ogra> the question is if thats true :) we operate on assumptions :)
[16:52] <slangasek> udev won't *see* the firmware, so it won't get double-loaded... but it *will* nack the firmware requests
[16:53] <slangasek> (I've seen this here, that's what led me to symlinking things around for /lib/firmware)
[16:53] <ogra> if a driver doesnt care if it gets loaded the firmware twice it wouldnt be an issue
[16:53] <ogra> we would only need to make sure android is last in the game
[16:53] <ogra> so the right options are applied
[16:53] <slangasek> it's not double-loading that's the problem
[16:53] <slangasek> it's udev giving a nack before ueventd has a chance to ack
[16:53] <ogra> if drivers block that we cant
[16:54] <slangasek> there's no way to make sure android is "last in the game"
[16:54] <ogra> if drivers dont block, we just need to make sure udev is done and then start lxc
[16:54] <slangasek> the ordering is totally non-deterministic
[16:54] <ogra> well, we have a way to know when udevtrigger is done
[16:54] <slangasek> er, again, that's the opposite of what we were talking about above - why are you wanting to run udev *first* before lxc again?  just because we know when udevtrigger ends?
[16:55] <adeola> hello all
[16:55] <ogra> slangasek, i want to be sure that android applies the firmware config
[16:55] <ogra> if the drivers dont care about it being loaded twice udev can do waht it wants as long as we can start android late enough to override it by loading it again
[16:56] <slangasek> ogra: once we revert the udev patch, ueventd will be the only thing that sees the firmware, so there will be *no double-loading*
[16:56] <ogra> except for devices that have something in linux-firmware
[16:56] <slangasek> so the only thing we have to care about is making sure that udev is *not* nacking firmware requests that are supposed to go to ueventd
[16:57] <slangasek> ogra: linux-firmware isn't installed in the image
[16:57] <ogra> doesnt it come with the kertnel package ?
[16:57] <ogra> which i assume we will install at some point
[16:57] <slangasek> the kernel package isn't installed in the image ;)
[16:57] <ogra> even though we dont atm
[16:57] <slangasek> I don't see why we would install it
[16:57] <ogra> well, will it stay that way ?
[16:57] <ogra> ok
[16:57] <slangasek> given that we have separate hardware packs
[16:57] <slangasek> and the kernels have all drivers built in
[16:58] <ogra> right
[16:58] <ogra> well, not all
[16:58] <rsalveti> slangasek: where is the nack code?
[16:58] <rsalveti> and why is that happening? lack of files that udev can't find?
[16:58] <slangasek> if we *do* need modules at some point, we probably still don't want to install full kernel package on the rootfs
[16:58] <ogra> there are some modules listed in init.rc ... they are just not loaded on boot
[16:58] <slangasek> rsalveti: systemd-udev has an internal 'firmware' handler that will send a nack if it can't find the file, yes
[16:59] <ogra> rsalveti, can we make sure /lib/modules from the package ends up on the android side in the right place ?
[16:59] <rsalveti> ogra: we could, but why?
[16:59] <ogra> well, for potential modules that only get loaded on demand
[16:59] <ogra> by init.rc
[17:00] <slangasek> well, it can't be in the device-independent rootfs
[17:00] <ogra> right
[17:00] <slangasek> because we won't have the same kernel package everywhere
[17:00] <ogra> we install the kernel package during android creation
[17:00] <slangasek> so we'll have to be creative there
[17:00] <didrocks> sil2100: any progress on the gdrive scope btw? :)
[17:00] <ogra> so we should be able to copy the modules over
[17:01] <rsalveti> why not bind mounting /lib/modules?
[17:01] <rsalveti> as the kernel is the same anyway
[17:01] <ogra> rsalveti, because we dont have anything in /lib/modules
[17:01] <ogra> we dont actually install the kernel package
[17:02] <slangasek> yes, that comes from the kernel package, the kernel packages are not device-independent, so they're not on the rootfs
[17:02] <ogra> but we do it at android build tome
[17:02] <ogra> *time
[17:02] <ogra> so adding a simple cp -a is what i suggest
[17:02] <rsalveti> right, we're not installing that package
[17:02] <rsalveti> that's the first issue
[17:02] <ogra> thats not an issue if android ships the modules (if there are any)
[17:03] <rsalveti> right, I can make sure that happens
[17:03] <rsalveti> then we need a post inst in the kernel package itself to copy the modules over
[17:03] <rsalveti> but looks dirty
[17:03] <slangasek> cp -a from where to where?
[17:03] <bfiller> sergiusens, ogra : what is the recommended way for a package to install a file in the user's home dir? i.e. maliit wants to drop a conf file in ~/.config/maliit.org/server.conf
[17:04] <slangasek> it's not clear to me what "android creation" is - you mean the container extraction / setup?
[17:04] <rsalveti> slangasek: android image creation
[17:04] <ogra> bfiller, hmm, sounds like a good question for a desktop guy ... seb128 ^^^
[17:04] <bfiller> assuming line 41 in this diff is not the right way: https://code.launchpad.net/~thomas-moenicke/phablet-extras/maliit-plugins_wordribbon/+merge/165590
[17:04] <seb128> ogra, bfiller: we don't
[17:04] <ogra> slangasek, the creation of the content of /system
[17:05] <ogra> seb128, we dont, but we could add a session service that does it
[17:05] <rsalveti> but we might have issues if we don't build /system at the same time we build our boot.imgs
[17:05] <seb128> ogra, bfiller: the user directory might be encrypted, not mounted (on nfs), etc
[17:05] <seb128> ogra, right, that's out of packaging though
[17:05] <mhall119> bfiller: why doesn't maliit create it on-demand when the user needs it?
[17:05] <mhall119> that's usually the right way to do it
[17:06] <seb128> bfiller, ogra: either teach the software to look for a default in /etc before the user dir or teach the software to create the file on first run
[17:06] <mhall119> if it exists use it, otherwise create it with some defaults
[17:06] <bfiller> seb128, mhall119 : makes sense, thanks
[17:06] <slangasek> ogra: ok - so it would be /lib/modules -> /system/lib/modules or such?
[17:06] <rsalveti> yup
[17:06] <slangasek> ok, sounds fine
[17:07] <bfiller> seb128: what about dropping something into /etc/skel? thought those got copied into user's home dir on user creation
[17:07] <rsalveti> ugly but would allow us to have a single rootfs
[17:07] <ogra> like we update the xdg dir names etc in a gnome session
[17:07] <ogra> rsalveti, we dont build boot imgs anymore in the flipped world
[17:07] <ogra> we only build initrds on the android side
[17:07] <rsalveti> ogra: our own bootimgs
[17:07] <seb128> bfiller, they do, but that's hackish and that let users upgrading out
[17:07] <rsalveti> as that's when we choose the kernel to be used
[17:07] <stgraber> bfiller: bad idea as that'd only work for any user created after the package is installed not for any existing user
[17:08] <ogra> (or at least thats all we need to)
[17:08] <ogra> rsalveti, boot.img creation is in live-build in the flipped container setup
[17:08] <seb128> bfiller, what's the issue with making the code look into /etc if there is no user config?
[17:08] <ogra> geez ... freenode stop splitting ...!
[17:08] <seb128> bfiller, that's more robust and cleaner
[17:08] <rsalveti> ogra: so we need to make sure /system gets all the modules from the same kernel we use when we create our own boot.img
[17:08] <bfiller> seb128: no issue, just slightly more work in the code. but sounds like it's the proper way so that's what we'll do
[17:08] <seb128> bfiller, thanks
[17:09] <slangasek> ogra: bearing in mind that if I get my way, the system partition won't be /system anymore ;)
[17:09] <ogra> rsalveti,, hmm
[17:09] <ogra> slangasek, it will always be ... in android ... no matter what you shove underneath it
[17:09] <ogra> and we will always need that dir in ubuntu
[17:10] <mhall119> ogra: rsalveti: I'm going to be filing some bugs about nexus 7 functionality, do we have device-specific tags on Launchpad ?
[17:10] <ogra> under /system ...
[17:10] <rsalveti> mhall119: not yet
[17:10] <ogra> not necessarily a partition indeed
[17:10] <rickspencer3> oh geez
[17:10] <mhall119> rsalveti: would you prefer common name od code name? "nexus7" or "grouper"?
[17:10] <rsalveti> mhall119: grouper
[17:10] <ogra> ++
[17:10] <mhall119> will do, thanks
[17:10]  * rsalveti needs go grab some food
[17:10] <rsalveti> *to
[17:10] <ogra> to go ? :)
[17:11] <rsalveti> :-)
[17:11] <slangasek> ogra: right.  But if we're putting Ubuntu on the system partition already, we may just blat the hardware-specific bits onto the same filesystem in their separate directories, and there wouldn't be any 'cp -a' involved anymore - just a couple of symlinks
[17:11] <ogra> sure
[17:12] <ogra> i'm still not convinced it is a good idea to touch the partitioning though
[17:12] <ogra> buut loop mounting doesnt seem to be the solution either
[17:13] <ogra> (waiting for gnex test results though ... but i expect them to be much worse ... gnex is essentially a panda and i know how badly live images suck on pandas)
[17:13] <ogra> (though that involves a squashfs additionally)
[17:14] <stgraber> yeah, at least in our case it'd be ext4 partition file on ext4 partition which should be pretty different from squashfs partition file on vfat
[17:14] <stgraber> we'd be skipping the compression part of squashfs at the very least
[17:15] <LokiScarlet> Hi. Nexus 4, raring, installed using zips in CWM. Where do I go in the UI for settings and shiz?
[17:15] <ogra> stgraber, right, but i'm still not convinced
[17:16] <stgraber> ogra: well, the thing is, we don't have many choices there. We need separate storage so we can deal with updates and have the system read-only. So we either resize the existing partitions to accomodate that or we need to use loop mounts.
[17:16] <ogra> LokiScarlet, only from the top panel atm ... the settings UI is designed but not done yet
[17:17] <stgraber> both solutions have their own problems, but we'll need to pick one of the two for each piece of hardware we have
[17:17] <LokiScarlet> Thanks.
[17:17] <ogra> stgraber, well, i'm strongly against changing partitions
[17:17] <ogra> users wont be able to revert to android
[17:17] <stgraber> and the sooner we do that the better, because it's going to need a bit of work and it's currently preventing some work from being done (image based upgrades)
[17:18] <ogra> and as long as we dont have a factory device we shouldnt touch it
[17:18] <ogra> stgraber, on devices where we cant touch the part table at all we will have to use loop anyway
[17:18] <stgraber> well, that's not true, they'd be able to restore Android just fine, they'd just end up loosing around 1GB of their userdata partition (or a bit more depending on device)
[17:18] <ogra> no matter what
[17:19] <ogra> so i guess thats the one thing we need to implement now
[17:19] <stgraber> I don't see why Android would refuse to boot if its system partition is twice the usual size
[17:19] <ogra> fastboot will fall over
[17:19] <ogra> when flashing
[17:19] <ogra> has nothing to do with booting
[17:19] <ogra> the img files have the excat partition size inside
[17:20] <ogra> *exact
[17:20] <ogra> so the user would have to change the partitioning back to the original setup ...
[17:20] <stgraber> ah, yeah, that's a bit annoying then. We'd have to provide a binary in Ubuntu to restore the partition table and reboot into fastboot
[17:20] <ogra> which is quite an advanced task
[17:20] <ogra> since it differs by device
[17:20] <stgraber> slangasek: ^
[17:20] <ogra> and even by device model
[17:22] <ogra> i think we should go with the same setup everywhere and not have two
[17:22] <slangasek> hmm, and I suppose fastboot would be the preferred method for restorting android, wouldn't it
[17:22] <ogra> only if we ship factory images we should touch partitioning
[17:22] <ogra> slangasek, depends on the device
[17:22] <stgraber> slangasek: yep, that's what Google provides in their factory images...
[17:22] <stgraber> slangasek: so based on what ogra's saying, trying a restore would essentially brick the phone (or fail if you're lucky)
[17:23] <slangasek> ok.  So, *if* we repartition, we need to have provisions for rolling this back
[17:23] <ogra> right
[17:23] <slangasek> ogra: oh, but wait; you don't fastboot restore the userdata partition
[17:23] <ogra> i would keep the partitoning option for factory only
[17:23] <slangasek> which is the only partition that's becoming smaller
[17:23] <ogra> and not have two ways for the non factory setups
[17:23] <slangasek> so you should be able to fastboot an undersized image onto the expanded system partition with no problems
[17:24] <ogra> yeah, userdata might just be formatted
[17:24] <slangasek> it just wouldn't be resize2fs'ed to use the full partition
[17:24] <slangasek> so I think this is not actually a problem either
[17:24] <slangasek> though I can do some more real-world testing if you like
[17:24] <ogra> so you wouldnt change /system but /data then
[17:25] <stgraber> we're currently growing /system and shrinking /data
[17:25] <stgraber> so as long as fastboot allows flashing to a bigger partition, we're fine
[17:25] <ogra> well, just leave /system alone as is
[17:25] <LokiScarlet> ... That reminds me, I actually tried formatting the user data... Had to reinstall so I went for Raring after that number
[17:25] <stgraber> nope, we can't do that without creating new partitions and we certainly don't want to do that
[17:25] <ogra> let it be what it is ... shrink /data and grab 2-4 G for /
[17:26] <LokiScarlet> I don't like being this lola person ^_^
[17:26] <slangasek> LokiScarlet: "lola person"?
[17:26] <ogra> stgraber, why not ?
[17:26] <ogra> slangasek, lola chang is in the demo contacts :)
[17:27] <slangasek> ogra: ah
[17:27] <LokiScarlet> slangasek: Whoever has these contacts and messages when you install touch
[17:27] <ogra> LokiScarlet, see the release notes wikipage
[17:27] <slangasek> ogra: I don't think leaving the system partition empty and stealing all 2GB from the userdata partition is safer
[17:27] <ogra> it has instructions how to get rid of that
[17:27] <LokiScarlet> Thaaaaaaank youuuuuuuuuuuuu
[17:27] <ogra> slangasek, i didnt say empty
[17:27] <ogra> slangasek, leave it be what it is
[17:27] <ogra> androids /system
[17:28] <ogra> that way fastboot wont have issues for flashing to it
[17:28] <stgraber> ogra: well, we'd waste whatever space is already allocated to system and we'd risk causing bigger changes to the partition table which may cause problems with the bootloaders/android
[17:28] <slangasek> ogra: mmm.  possible.  Still, I think we can make better use of the available space, without exposing users to any risk.
[17:28] <Uto> hi there
[17:28] <slangasek> I think the resize is safe
[17:28] <ogra> what "available space" ?
[17:28] <ogra> my /system on maguro is 600M
[17:28] <slangasek> ogra: the system + userdata partitions
[17:28] <ogra> there is not much wasted space here
[17:28] <Uto> someone can tell me why I stuck at blackscreen please?
[17:28] <slangasek> the "available space" on the disk that is allocated for the OS + data
[17:28] <Uto> http://pastebin.com/qtSgvUs5
[17:29] <kenvandine> popey, can you add plonk to the collections meta package?
[17:29] <stgraber> ogra: right, and around a GB on nexus4, that's not negligible on a 8GB device, so re-using it to make a bigger system partition is definitely worth it
[17:29] <slangasek> right - these aren't huge disks
[17:30] <slangasek> I think we do care about not letting 600M, or 1GB, go to waste
[17:30] <stgraber> ogra: what slangasek is doing is grow /system from 600MB to 2GB and shrink userdata by 1200MB to make this possible. Partition numbers don't change, only the start/end offsets do
[17:30] <ogra> well, but that means 80% of our porters wont be able to use that setup, all users that just try ubuntu will have to be handled special with a rollback mechanism etc
[17:30] <stgraber> which is a far smaller change to the table than shrinking + adding partitions
[17:30] <slangasek> ogra: the need for this special rollback mechanism is unproven
[17:30]  * ogra would prefer if we went with loop for the public images and do the partition dance only on factory
[17:30] <slangasek> as I said, I expect fastboot to have no problems blatting an undersized image onto a partition
[17:31] <stgraber> slangasek: well, it's quite likely that people won't like loosing 1.2GB of usable storage just because they tried Ubuntu
[17:31] <ogra> instead of having to implemet two ways right now
[17:31] <slangasek> ogra: that would mean a completely different and untested boot layout for the factory
[17:31] <ogra> slangasek, we can test it on the n4 i supppose
[17:31] <ogra> i just wouldnt ship two setups
[17:31] <slangasek> stgraber: sure; in that case we can factor in the partition resizing rollback
[17:33] <slangasek> I guess we would want to stash the original partition geometry in the recovery partition or something?
[17:33] <ogra> or in the cache one
[17:34] <stgraber> cache is between system and userdata on the nexus4 so probably not the best place to store that data on (as it's likely to be re-formated in the resizing process)
[17:34]  * ogra still doesnt like that we have to implement two completely different things ...
[17:34] <stgraber> ogra, slangasek: anyway, let me update yesterday's pad with what I think are the next steps so we can hopefully move forward with that stuff
[17:35] <slangasek> ogra: well, I think we can minimize the differences... use loop devices on the generic ports, use raw partitions on the supported devices... that at least gives us alignment on the initramfs
[17:36] <ogra> slangasek, we need to do two different builds ...  will have to handle different bugs etc etc ... and it costs extra time we are getting short of
[17:37] <ogra> once we have a vendor we can dedicate someone to implement the partitioning stuff and extra builds etc ... havving support for both in the initrd already might make sense though
[17:38] <ogra> (i assume factory builds wouldnt come from cdimage anyway)
[17:39] <slangasek> ogra: I am frankly more concerned about the many potential bugs resulting from the current differences between the touch rootfs and the standard ubuntu rootfs.  mountall is still not working right, and I'm not enthusiastic about trying to make all this work right with the current model
[17:39] <ogra> to me it seems like we're splitting effort where we need all hands on deck already
[17:40] <ogra> slangasek, mountalll works as defined in the blueprint (adding an override for fsck in fstab for /dev/root so /lib/init/fstab doesnt kick in) ... plymouthj is our issue
[17:41] <ogra> system. data and vemdor are alll automounted by mountall in the latest flipped image
[17:42] <slangasek> ogra: no, mountall is not working correctly here
[17:42] <ogra> i didnt see any complaints from it in the logs either ...
[17:42] <ogra> slangasek, whats wrong then ?
[17:42] <slangasek> that's because mountall doesn't log anywhere useful by default
[17:43] <ogra> ah, i would have expected something in either dmesg, syslog or the upstart job log
[17:43] <slangasek> by default, mountall logs everything to plymouth ;P
[17:43] <ogra> heh
[17:43] <slangasek> but if you edit /etc/init/mountall.conf to run with --verbose, and disable 'console output', you'll get some interesting stuff in /var/log/upstart/mountall.log
[17:44]  * ogra will try 
[17:44] <ogra> i assume it doesnt like to have / on a bindmount
[17:44] <stgraber> ogra, slangasek: bottom of http://pad.ubuntu.com/ubuntu-touch-fs-structure
[17:44] <ogra> but either of the above discussed stuff will fix that
[17:45] <slangasek> mountall: root filesystem isn't mounted
[17:45] <slangasek> so it's possible that's not hurting anything
[17:45] <slangasek> but it doesn't make me comfortable
[17:45] <slangasek> as for fixing that ... having the system partition be an Ubuntu rootfs would fix it
[17:46] <ogra> yeah, thats surely the bind mount
[17:47] <slangasek> stgraber: hmm, what about the pad?
[17:47] <stgraber> slangasek: yeah, the loop mount should fix that as /dev/loop0 will be the rootfs, so as / will be backed by a block device, mountall should be happy
[17:47] <slangasek> well
[17:48] <stgraber> slangasek: I added a "proposed implementation" section, detailing what I think we should do at the moment to support both setups and what are the changes for all the bits I can think of
[17:48] <slangasek> right
[17:48] <slangasek> so I don't think it makes sense to move to *just* the loop mount configuration, given the performance penalty
[17:49]  * ogra just got some kebab on his lap ... 
[17:49] <ogra> back in a few ...
[17:49] <slangasek> I think this is all worth doing only if we're preferentially implementing/supporting the native partition approach
[17:50] <stgraber> slangasek: sure, we should support both, though I think my updated proposal should limit the performance issue by quite a bit as only the base system will be loop mounted and will be read-only so should cache pretty well
[17:50] <stgraber> everything else is bind-mounts straight from the data partition (that we'll have to mount --move to /data so we don't end up with the same mess we have at the moment)
[17:51] <slangasek> ah, did cking say we're ok for read-only performance?
[17:51] <rsalveti> stgraber: slangasek: ogra: also, remember we can't rely on fastboot necessarily
[17:51] <rsalveti> we're also supporting phones that are not fastboot compatible
[17:51] <rsalveti> and changing partition might break the proprietary method to flash the devices
[17:51] <rsalveti> if they are not creating the partition table and formating the filesystem properly when flashing the device
[17:52] <slangasek> rsalveti: we're only proposing to change partitions on our "supported" devices, and only if we can demonstrate that it works: so mako maguro grouper $otheroneiforgot
[17:52] <rsalveti> so it's quite scary to change partitions
[17:52] <slangasek> rsalveti: and for products I assume we have control over the partition table from the factory
[17:52] <rsalveti> right, but how shold we apply to the rest of the other devices?
[17:52] <rsalveti> people doing ports?
[17:52] <slangasek> rsalveti: that's the loop mount fallback
[17:53] <rsalveti> hm, so we'd need to support both
[17:53] <rsalveti> stgraber: is there any file system that we could put at /data that would reduce the side effect of loop mount files?
[17:53] <slangasek> yes - hopefully with minimized differences between the support requirements for the two...
[17:54] <rsalveti> that sounds painful
[17:54] <stgraber> slangasek: no, he didn't say that, however his biggest concern with the loop mount idea was data corruption which should be reduced by not having writeable loop mounted partitions. The read speed results are rather odd to be honest with mostly good speeds except for a couple of runs that had awful speed.
[17:54] <ogra> rsalveti, ++
[17:54] <rsalveti> and the problem is that we'd only test the option we're using
[17:54] <stgraber> slangasek: also, read speeds of > 500MB/s on a mobile device suggests it was reading from cache (that or we have 6Gbps access to the flash which sounds surprising)
[17:55] <ogra> especially since it's an eMMC
[17:55] <rsalveti> yup
[17:55] <ogra> getting more than 30M/s would be surprising
[17:55] <rsalveti> yeah
[17:56] <slangasek> rsalveti: so to my mind, we're going to end up supporting two options no matter what once there are phones shipping - because I don't see us wanting production devices to have the OS on the userdata partition
[17:56] <slangasek> rsalveti: do you agree?
[17:56] <ogra> and the loop mount is apparently bad at reading ...
[17:56] <ogra> not at writing
[17:56] <ogra> so redonly wont change anything i suppose
[17:56] <stgraber> rsalveti: I personally would expect the overhead to be minimal if we only have the read-only system partition loop mounted from userdata and that it's written in one big continuous file (no fragmentation)
[17:56] <rsalveti> slangasek: right, but who and how we're going to test without the repartitioning option?
[17:57] <stgraber> ogra: well, that's the part I'm not sure of, would have to talk to cking but his measurements are way higher than what we should be getting on flash
[17:57] <ogra> definitely
[17:58] <cking> stgraber, i guess we need to test I/O patterns that are not getting cached with something more exhaustive, like bonnie++
[17:58] <slangasek> rsalveti: well, my point is that if we're going to have two different layouts anyway by the time we get to the product stage, it's better to get our "preferred" layout as close as possible to production now, not wait until later; and to minimize the differences between what we're supporting
[17:58] <stgraber> ogra: they are in MB/s so that kind of speed suggests he was testing the cache, not the actual partition, so therefore those measurements are meaningless. The write ones look reasonable and the few slow read ones look reasonable too. I just think that any > 100MB/s was from cache and so should be discardded.
[17:58] <slangasek> rsalveti: as for who would do the validation of the loopback option, if it exists for community ports, shouldn't that be a community validation?
[17:58] <stgraber> cking: right, that or flush the cache between the tests? (echo 3 > /proc/sys/vm/drop_caches IIRC)
[17:58] <ogra> cking, dd woth cache disabled should do as well
[17:58] <ogra> *with
[17:59] <stgraber> cking: anyway, I was mostly interested in the power and write impact myself, so those measures I believe were correct and look reasonable to me
[17:59] <rsalveti> slangasek: right, but I just want to avoid people having issues with the ports just because we don't test or validate if we're breaking that option
[17:59] <ogra> slangasek, first someone needs to do the implementation ... and create these special images etc
[17:59] <rsalveti> that's why I'd prefer if we could use a common solution at least initially
[18:00] <ogra> and we'd have the community getting totally different bugs
[18:00] <cking> stgraber, yep, I was more concerned with the overhead in terms of power, but we can repeat the tests with larger file I/O and different tests if required, it's not a big deal to re-measure
[18:00] <stgraber> rsalveti: so the only change would be mounting /dev/mmcblk0pX instead of /dev/loopX, if we have any other code difference between the two setups it's because we badly implemented it
[18:00] <rsalveti> stgraber: right
[18:01] <slangasek> ogra, rsalveti: I'm confident we can minimize the bug surface with a proper design.  But I think ogra's last comment is my cue to stop discussing it now, and go off and try to implement something sane ;)
[18:01] <stgraber> oh, unless we want to have mountall mount the data partition instead of the initrd, in which case we'd indeed have a pretty different booth path
[18:01] <ogra> stgraber, as i said above ... we need different images, different install methods and users will have different bugs we cant reproduce easily
[18:01] <rsalveti> slangasek: right, as long we do the implementation and review it properly, I'm fine
[18:02] <rsalveti> and if we would need the loop solution anyway, I'd go and implement that first
[18:02] <ogra> ++
[18:02] <rsalveti> and it seems easier
[18:02] <slangasek> ogra: oh, coming back around to ueventd vs. udev, I'm not sure we converged on a solution yet
[18:02]  * ogra would go with loop only as i said in the beginning
[18:02] <slangasek> I think we still want ueventd to go first
[18:02] <stgraber> well, Steve's is actually easier as long as you aren't scared of using gfdisk on a phone ;)
[18:03] <ogra> so make udev start on started lxc-android-config
[18:03] <stgraber> (which I tend to be with pieces of hardware where I can't pull the disk and fix the partition table by hand)
[18:03] <slangasek> ogra: that doesn't delay it long enough
[18:03] <ogra> slangasek, i know it isnt 100% reliable ...
[18:03] <slangasek> we need it to start after ueventd is *done*
[18:03] <slangasek> it's not even 50% reliable
[18:03] <rsalveti> slangasek: would that solve the nack problem?
[18:03] <rsalveti> or udev would still nack firmware requests?
[18:03] <ogra> we can implement something in init.rc that sets a parker once init.rc is done
[18:03] <rsalveti> later on
[18:03] <ogra> thats the only idea i have
[18:04] <ogra> s/parker/marker/
[18:04] <slangasek> rsalveti: TTBOMK, the firmware requests will not get handled again by udev
[18:04] <ogra> but that will only tell you when androids init is finished
[18:04] <stgraber> slangasek: want me to quickly implement the loop mount setup, then you can use that but dd my system.img to your system partition and look at what needs changing to have it working for you too?
[18:04] <slangasek> stgraber: sure, go for it
[18:05] <stgraber> rsalveti: btw, any hope of patching Android's init not to mount partitions? it's creating quite a bit of a mess on my device with it trying to mount everything. I'd much rather have Ubuntu mount the partitions and LXC bind-mount them before starting the container.
[18:06] <ogra> stgraber, that will be hard to do since we would have to inject device specific fstabs into the ubuntu root
[18:06] <rsalveti> stgraber: do you want to remove all the mount requests?
[18:06] <rsalveti> right
[18:06] <ogra> you could just drop fstab from android
[18:06] <ogra> to prevent it mounting
[18:06] <slangasek> ogra: doesn't the container already fail to mount anything due to permissions?
[18:07] <stgraber> slangasek: nope, we don't have apparmor, so it's unfortunately allowed to do whatever it wants at the moment
[18:07] <ogra> it usually just calls "mount /$mountpoint" in eth init scripts
[18:07] <slangasek> stgraber: ah
[18:07] <ogra> slangasek, it mounts its partitions just fine
[18:07] <ogra> and i sanitized that bit a lot over the last days
[18:07] <rsalveti> stgraber: only partition I see there we could not make android mount is /data
[18:08] <stgraber> ogra: for a definition of "just fine" that currently makes my / become read-only and the kernel complaining quite a bit (data corruption)
[18:08] <rsalveti> stgraber: there are device specifics and also /system, /modem, /cache and such
[18:08] <ogra> stgraber, on todays flipped image from cdimage ?
[18:08] <stgraber> ogra: yep, that image gets me a read-only root and no container running
[18:08] <ogra> on maguro ?
[18:08] <rsalveti> that's weird
[18:08] <ogra> (i have no mako to test)
[18:09] <rsalveti> our fstab should be mounting /data with ro
[18:09] <rsalveti> ops, rw
[18:09] <stgraber> rsalveti: right. So at the very least we want to prevent it from mounting /data, /system and /cache. The rest I don't really care about
[18:09] <stgraber> ogra: mako
[18:09] <ogra> it definitely works for a few people i spoke to today
[18:09] <stgraber> ogra: I don't have maguro here
[18:09] <rsalveti> stgraber: why not mounting /system and /cache?
[18:09] <rsalveti> we're not using such partitions anyway
[18:09] <ogra> stgraber, note that todays image has a bug that requires you to boot twice after the first install
[18:09] <stgraber> rsalveti: we use /cache for our updates, so we need it on the Ubuntu side and /system will be the Ubuntu rootfs or will be unused so we don't want it mounted
[18:10] <rsalveti> rootfs under /system?
[18:10] <ogra> heh
[18:10] <rsalveti> we can't unless we redo the partition
[18:10] <ogra> thats what they plan
[18:10] <rsalveti> right, let's just do the loop mount solution under /data for now
[18:10] <rsalveti> what is the problem with that?
[18:10]  * ogra is laughing his butt off ... seeing rsalveti as shocked as i was in the beginning
[18:11] <ogra> rsalveti, performance
[18:11] <rsalveti> are we increasing the size of /cache as well?
[18:11] <ogra> but i'm fully in the loop camp as well here
[18:11] <ogra> i think repartitioning isnt a good idea
[18:11] <rsalveti> right, +1
[18:12] <rsalveti> we should go with steps, first have the loop based solution working, and then we can try to repartition with some devices
[18:12] <ogra> ++
[18:12] <rsalveti> and have both solutions as supported by our install && upgrade methods
[18:12] <ogra> i was even suggesting to keep the repartitioning only for factory
[18:12] <stgraber> so, my expectation is that the Ubuntu rootfs will contain /var/lib/lxc/android/rootfs which will contain what's currently in the Android initrd AS WELL AS /var/lib/lxc/android/rootfs/system/ which is what we currently have in the Android system partition
[18:12] <stgraber> those won't come from the generic rootfs tarball but from a separate tarball which is stacked on the first
[18:13]  * ogra got that by now ... after two days of discussion
[18:13] <stgraber> so we don't need to mount /system in the container as it's already there
[18:13] <rsalveti> right, but we could
[18:13] <ogra> we need to have full read access to /system from ubuntu
[18:13] <stgraber> we'll mount a tmpfs to /cache as we don't need persistence in there and we actually need the real cache partition for our updates in Ubuntu
[18:13] <ogra> as well as the included /vendor
[18:13] <stgraber> and we'll bind-mount a sub-directory of the real /data as Android's /data
[18:13] <ogra> and links didnt work when i tested here
[18:14] <ogra> they need to be real bind mounts
[18:14] <ogra> 9at least soft links didnt)
[18:14] <stgraber> ogra: that didn't work because Android was mounting the partitions
[18:14] <ogra> no
[18:14] <stgraber> ogra: if we mount the partition in Ubuntu and bind-mount them within the container, it'll work
[18:14] <ogra> we mount the partitions way before android
[18:14] <rsalveti> what is the problem with having android image flashed under /system?
[18:14] <stgraber> ogra: as they'll be visible under /var/lib/lxc/android/rootfs as standard mount points
[18:14] <ogra> mountall does
[18:14] <rsalveti> as that would be way easier for people doing ports
[18:15] <ogra> rsalveti, we might lose a few 100M
[18:15] <stgraber> ogra: then Android mounted it again creating a huge mess, yeah, that's what I'm trying to fix
[18:15] <rsalveti> ogra: why?
[18:15] <ogra> thats the cobncern i heard from slangasek at least
[18:15] <ogra> tsimpson, because /system isnt 100% full ?
[18:15] <ogra> no idea
[18:15] <ogra> err
[18:15] <ogra> sorry tsimpson that was for rsalveti
[18:15] <rsalveti> right, but we don't care about /system
[18:15] <rsalveti> unless we're doing the partitions again
[18:16] <ogra> stgraber, androids mounts shouldnt even be vsible to you
[18:16] <ogra> i dont get that here
[18:16] <ogra> stgraber, are you soure you completekly wiped /data before trying todays image ?
[18:16] <ogra> none of that should happen
[18:17] <stgraber> ogra: the problem is that you're not allowed to mount the same block device twice. The kernel apparently is very confused when that's done in a container and let you do it anyway, which means /dev/mmcblkX is mounted twice in two different namespaces and read-write in both, which means very likely data corruption and similar mess
[18:17] <rsalveti> my solution would be having android flashed under /system (at least for now, and supporting that as an option for later), removing /cache and /userdata from android fstab, and doing the ubuntu rootfs with loop mount files under /data
[18:17] <ogra> stgraber, except /data nothing is mounted rw anywhere
[18:18]  * ogra wonders if stgraber really tested the right image ... i have no complaints at all anywhere 
[18:18] <ogra> i can imagine to see data corruptiion if both would write to the same place in /data, but that cant happen at all
[18:18] <stgraber> ogra: right, and when Android attempts to mount /data in the container that fails, the kernel remounts it read-only and as my / comes from /data, my / becomes readonly
[18:18] <ogra> huh ?
[18:18] <ogra>  /data is definitely mounted fine here in both OSes
[18:19] <rsalveti> stgraber: that we can easily remove
[18:19] <stgraber> ogra: yes, and that's a bug, that shouldn't be possible and is very very bad
[18:19] <rsalveti> but android would need a /data which is rw
[18:19] <ogra> and since android will never write to /data/ubuntu nor will ubuntu write to a toplevel dir in /data we should be totally safe
[18:19] <rsalveti> either a directory, mount loop as well or partition
[18:20] <rsalveti> remember we have blobs writing stuff under /data
[18:20] <stgraber> ogra: ext doesn't support being mounted more than once at any given time, if you do that, you're going to eventually mess with the journal or have both try to write the same block at some point
[18:20] <ogra> from the ubuntu side ?
[18:20] <ogra> stgraber, right, so the loop mount will fix that for /data ... i still dont see an issue for /system
[18:20] <ogra> since thate readonly everywheer
[18:20] <ogra> *thats
[18:22] <ogra> (and i still dont get whats wrong with your image ... )
[18:22] <stgraber> ogra: well, in slangasek's case, the system partition won't quite contain an Android system, so letting Android mount that sounds like a bad idea. It's much simpler to simply have the tree under /var/lib/lxc/android/rootfs/ already contain the system directory. That way, no need to mount it, it's perfectly readable from Ubuntu and everyone is happy
[18:22] <rsalveti> stgraber: so if we remove /system, /data and /cache from the android specific fstab, how should we mount them from the ubuntu side? we'd need to have hw specifics even if we want to boot with the loop mount option (which we don't care about /system)
[18:24] <stgraber> rsalveti: so /system would be part of the Ubuntu rootfs partition, no need to mount that one then. /data is already mounted from the initrd so we'll have the logic there. Only missing one is /cache which we may also mount from the initrd if easier.
[18:24] <stgraber> I have a feeling slangasek will disagree with me there, but I think we should mount all the partitions from the initrd and only have mountall deal with the bind-mounts
[18:24] <rsalveti> stgraber: in the loop mount case /system is not going to be used, right?
[18:24] <slangasek> ogra: I have several concerns here: - inefficient use of available (limited) disk space; - OS on read-write filesystem (even if there's a loop-mounted ro image) increasing risk of corruption, etc; - the filesystem heirarchy is very different from standard Ubuntu, increasing the risk of touch-specific bugs in the foundations layer
[18:25] <stgraber> rsalveti: correct. We won't touch it and won't mount it (so we'll waste it but at least we'll be consistent with the non-loop setup)
[18:25] <rsalveti> stgraber: so the device specific boot.img would need the device specific fstab to be consumed there, and mounted during boot
[18:25] <ogra> slangasek, i agree about /data .... i dont get the /system bit and would expect android to actually have picked the /system size carefullt already
[18:25] <stgraber> rsalveti: right, my though is that we should only be mounting physical partitions from the initrd as the bootimg is already hardware specific, so it doesn't hurt hardcoding them in there
[18:25] <rsalveti> otherwise there's no easy way to know where the partitions are
[18:26] <stgraber> *thought
[18:26] <rsalveti> right
[18:26] <ogra> slangasek, as i suggested way up ... just shrink /data and split it in two ...
[18:26] <rsalveti> the size of /system would only work for android, most of the times
[18:27] <ogra> we wouldnt even need to touch the anroid fstab
[18:27] <ogra> yeah
[18:27] <rsalveti> stgraber: so I'd agree to move fstab from android to our boot.img, and have that mounted during boot
[18:27] <rsalveti> that wouldn't cause us any issue
[18:27] <ogra> touching /system seems really unneeded
[18:27] <slangasek> stgraber: actually, I don't disagree with you; I hadn't made up my mind about whether the initramfs or mountall should be responsible for mounting, but certainly for the loop-mount case, the initramfs is gonna have to have some smarts
[18:28] <ogra> rsalveti, except that we use totally different mount oprions most likely
[18:28] <ogra> *options
[18:28] <rsalveti> ogra: that's true
[18:28] <slangasek> ogra: android has picked the /system size carefully for android, not for Ubuntu, and we aren't installing a full android on it.  And again, I think resizing system is safer than splitting userdata.
[18:28] <stgraber> slangasek: ok. I think we should have the initrd always mount all the partitions we need, in both setups. As we unfortunately don't have a reliable way of figuring out what partition is what on all devices (labels are great but unfortunately they aren't identical on all devices...)
[18:28] <ogra> slangasek, does it ? i think loop mounting is supported ootb
[18:29] <slangasek> ogra: loop-mounting a root filesystem is supported in initramfs-tools?
[18:29] <slangasek> this idea scares me :)
[18:29] <ogra> i think so, yes
[18:29] <rsalveti> stgraber: android ships a device specific fstab per device, as they don't have a rule for label, so there's not much we can do I'd guess
[18:29] <ogra> there is mountall code in the local script for it
[18:29] <ogra> err
[18:29] <stgraber> rsalveti: right
[18:29] <ogra> mountooor
[18:29] <ogra> bah
[18:29] <ogra> mountroot
[18:30] <Uto> please can you have a look on this?
[18:30] <Uto> http://pastebin.com/uQt3v7Gh
[18:30] <ogra> stgraber, even the labels differ
[18:31] <stgraber> ogra: isn't that what I just said? :)
[18:32] <ogra> stgraber, well, i didnt see your sentence above :) ... was correcting my typos
[18:32] <rsalveti> stgraber: so we only need to remove /system, /data and /cache from android's fstab, the rest can still be mounted by android, right?
[18:32] <ogra> you can easily find them by looking at the mountpoints in fstab
[18:32] <ogra> oh, definitely
[18:33] <ogra> each device has device specific mounts you dont want to rip out
[18:33] <stgraber> rsalveti: yep, I expect the rest to be safe as we won't mount them in Ubuntu
[18:33] <ogra> maguro has a habndfulll of things under /mnt
[18:33] <ogra> for example
[18:33] <rsalveti> stgraber: ok
[18:34] <rsalveti> changed the pad to state that
[18:34]  * stgraber is almost done generating his new system.img file
[18:36] <stgraber> ogra: is there a tool I can use to convert saucy-preinstalled-touch-armel+mako.zip into its filesystem representation (equivalent of /system)?
[18:37] <stgraber> ogra: or do I need to parse updater-script myself and apply all the changes by hand (would be a bit annoying)
[18:37] <rsalveti> stgraber: would probably be better to use the system.img file
[18:37] <ogra> unzip it :)
[18:37] <ogra> right, that contains the img
[18:37] <rsalveti> stgraber: that should already have all the modifications done by the updater-script
[18:37] <stgraber> rsalveti: sure, I would if I had it :)
[18:37] <ogra> and that you can just loop moont
[18:37] <rsalveti> stgraber: you can grab from jenkins I guess, let me check
[18:37] <ogra> stgraber, pull it from cdimage
[18:38] <ogra> ubuntu-touch-preview has it
[18:38] <rsalveti> true
[18:38] <stgraber> ogra: ah, ok, will do that then. Wasn't sure it'd be identical to the .zip
[18:38] <ogra> (vs ubuntu-touch which is the flipped img)
[18:38] <rsalveti> guess that's used with phablet-flash -b
[18:38] <ogra> yeah
[18:38] <rsalveti> indeed
[18:38] <rsalveti> stgraber: then just consume from the img
[18:39] <stgraber> yep, doing that now, much much simpler ;)
[18:39] <stgraber> I'll have to talk with ogra about producing shiny .tar.xz for all those bits, but the current .tar.gz and .img are easy enough to convert (unpack + repack)
[18:39] <sergiusens> stgraber: it is... it should be identical
[18:40] <sergiusens> rsalveti: look at my MR! :-)
[18:40] <sergiusens> rsalveti: I want to rebuild saucy ;-)
[18:40] <stgraber> stgraber@castiana:~/Desktop/phablet/fs/tmp$ sudo mount -o loop -t ext4 raring-preinstalled-system-armel+mako.img android/
[18:40] <stgraber> mount: wrong fs type, bad option, bad superblock on /dev/loop1,
[18:40] <stgraber> ogra: ^ you lied! ;)
[18:40] <rsalveti> sergiusens: sure, sorry, long discussion about repartitioning the device and such :-)
[18:41] <stgraber> ogra: is there some kind of padding I need to skip?
[18:41] <rsalveti> hm, I think you need a step before that
[18:41] <ogra> stgraber, hmm, you probably need simg2img from android-tools-fsutils
[18:41] <rsalveti> yeah
[18:41] <rsalveti> exactly
[18:41] <sergiusens> rsalveti: yeah I am following... didn't want to add a 5th nagger
[18:41] <stgraber> much better, thanks
[18:42] <rsalveti> sergiusens: your new mountall.override is the same from the one from the previous mountall package, right?
[18:42] <sergiusens> rsalveti: yeah... pulled it from maguro/raring tbh :-)
[18:42] <rsalveti> sergiusens: don't you need to install the file?
[18:43] <ogra> heh
[18:43] <ogra> details
[18:43] <rsalveti> or are we copying all overrides already?
[18:43] <rsalveti> branching to see
[18:43] <sergiusens> rsalveti: look at the install rule
[18:43] <rsalveti> good
[18:43] <rsalveti> sergiusens: happroved
[18:44] <sergiusens> rsalveti: great, image #2 will have everything but NM... unless we just do a bin copy for now
[18:44] <ogra> might not help
[18:44] <rsalveti> sergiusens: depends on cyphermox_
[18:44] <ogra> saucys NM is newer
[18:44] <rsalveti> we might need to bump the version
[18:44] <rsalveti> yeah
[18:49] <ogra> slangasek, stgraber FYI my mountall log http://paste.ubuntu.com/5736624/
[18:50] <ogra> (and there are no complaints anywhere else in other logs i can find)
[18:50] <ogra> i did actually put quite some effort into reworking and testing that yesterday
[18:50] <slangasek> ogra: really?  so you get no warning about root not being mounted?
[18:50] <ogra> nope
[18:51] <slangasek> ogra: perhaps I need to pull a new version of the image
[18:51] <slangasek> (will do that shortly)
[18:51] <ogra> wipe /data i'm not sure the zip does clear up everything
[18:52] <ogra> and you will be booting to a black screen on first boot (already fixed for the next image, just waiting for unity8 to land for a respin)
[18:52] <ogra> second boot is fine then
[18:52] <slangasek> ok
[18:52] <ogra> thats on maguro though
[18:52] <ogra> not sure if mako will behave differently
[18:52] <ogra> (according to stgraber it does)
[18:52] <sergiusens> ogra: slangasek the zips don't touch /data in a damaging way
[18:53] <slangasek> sergiusens: I'd be more concerned about wrong stale data left behind in /data that needs to be purged
[18:53] <ogra> sergiusens, it doesnt wipe /data/ubuntu ?
[18:53]  * ogra didnt check the code yet 
[18:53] <slangasek> ogra: so as of the last update I applied (yesterdays, I think?) mako is not booting to the UI at all for me
[18:53] <ogra> i thought i saw a "mv ubuntu_tmp_unpack ubuntu"
[18:54] <sergiusens> ogra: slangasek stuff saved in /data/ubuntu is limited to ofono, /home/phablet, /etc/NetworkManager/system-connections
[18:54] <ogra> slangasek, yeah, thats fixed
[18:54] <ogra> slangasek, that was the oom bit
[18:54] <sergiusens> ogra: yeah and if i succeeds it replaces the prev /data/ubuntu
[18:54] <ogra> which teared down ubuntu-session
[18:54] <slangasek> ogra: no, I fixed the oom bit locally
[18:54] <slangasek> qml-phone-shell was segfaulting for me
[18:55] <ogra> ah, you also had udev issues
[18:55] <ogra> these should be fixed too
[18:55] <ogra> so you get the right device permissions for the graphics stuff
[18:55] <stgraber> alright, I'm done with all my changes now, let's see if I can get my phone to boot that stuff
[18:56] <slangasek> ogra: no, the device permissions were correct
[18:56] <slangasek> I had the version of the image that already included those udev fixes
[18:57] <slangasek> and that was the image that *didn't* work for me
[18:57] <stgraber> I basicaylly have one system.img file containing the rootfs, an unpacked copy of the Android initrd in /var/lib/lxc/android/rootfs, an unpacked copy of the Android system partition in /var/lib/lxc/android/rootfs/system, I removed the LXC pre-start script, removed the 60*v4l* udev rule, added an LXC fstab to mount the cache and data partition in Android, disabled those in the Android fstab and updated the initrd to do the loop mount and then
[18:57] <slangasek> the one *before* those changes is the one I was able to get booting to shell after adjusting the dev perms
[18:57] <ogra> hmm
[18:57] <ogra> i would love to have a mako i can play with ... damned
[18:58] <slangasek> ogra: well... since you don't currently, let me boot the latest image and see what I can see
[18:58] <ogra> yeah
[19:00] <slangasek> grr, what is this stupid 'download mode' the n4 keeps putting itself in when I boot it while connected over USB?
[19:01] <stgraber> slangasek: it's annoying, isn't it. You need to press the two buttons right after the phone vibrates. If you do it before, you get that download mode stuff.
[19:01] <stgraber> slangasek: (I just gave up and unplug my nexus4 before rebooting into the bootloader ;))
[19:01]  * ogra thought you always get the DL mode when only pressing vol dn
[19:01] <ogra> at least it is like that on most android devices i have here
[19:02] <sergiusens> ogra: fyi I linked your lp:~phablet-team/session-manager-touch/trunk branch to trunk
[19:02] <ogra> thanks
[19:02] <ogra> i kind of got desparately lost in LPs UI yesterday when trying that
[19:02] <stgraber> ogra: mako seems a bit special in that regard. If you hold all 3 buttons you get into DL mode. So you need to press the on button for 2s, then press up+down to get to the menu
[19:03] <ogra> intresting
[19:03] <stgraber> pushing 2GB over adb is slow... Looking forward to having our own upgrader and being able to push .tar.xz instead ;)
[19:03] <ogra> that wont make the USB connection faster
[19:04] <stgraber> no, but will make the file to push smaller
[19:04] <ogra> heh, yeah
[19:05] <ogra> why didnt you produce a tar.xz ?
[19:05] <ogra> pushing it uncompressed seems like a waste
[19:05] <ogra> (or at least a gz, not sure recovery ships xz support)
[19:06] <stgraber> I could have, but I was lazy and so just created the 2GB large system.img directly on my laptop
[19:06] <stgraber> anyway, finished now, 7MB/s isn't too bad I guess
[19:07] <stgraber> alright, all flash now, let's see what happens
[19:07] <stgraber> stgraber@castiana:~$ adb shell
[19:07] <stgraber> root@ubuntu-phablet:/#
[19:07] <stgraber> first time around!
[19:08] <ogra> is the shell up ?
[19:08] <ogra> does rild work ?
[19:08] <stgraber> hmm, / is read/write, that wasn't expected. I guess mountall tried to be clever there and remounted it
[19:08]  * ogra never doubted that you can get ubuntu to boot ... 
[19:08] <sergiusens> ogra: https://code.launchpad.net/~sergiusens/session-manager-touch/unity8/+merge/167622
[19:09] <stgraber> ogra: well, I'm surprised I managed not to mess up my changes to the initrd ;) that's a loop-mounted boot + a bunch of bind-mounts
[19:09] <sergiusens> I guess it's useless, but it was incorrect :-)
[19:09] <ogra> sergiusens, oh ! thanks
[19:09] <ogra> definitely
[19:09] <ogra> i thought i had grepped ... seems i didnt
[19:10] <ogra> stgraber, well, you only see if the bind mounts worked once you see the shell and rild working
[19:10] <ogra> (admittedly my image only got one of that done yet either)
[19:10] <ogra> getting the design implemented isnt the issue ... making sure android gets along with it is
[19:11] <awe_> ogra, rild *isn't* android, it's a proprietary blob that android uses
[19:11] <awe_> ;D
[19:11] <sergiusens> ogra: unity8 built btw
[19:12] <ogra> sergiusens, \o/
[19:12] <ogra> awe_, nah its a proprietary blob designed to make developers commit suicide as i understood it
[19:13] <slangasek> [    6.839829] kgsl kgsl-3d0: |_load_firmware| request_firmware(a300_pm4.fw) failed: -2
[19:13] <slangasek> ogra: ^^ so that's about what I was expecting to see; kgsl asks for the firmware and udev doesn't have it.
[19:13] <ogra> as it shouldnt
[19:13] <ogra> hmm
[19:13] <slangasek> but before even when I addressed that problem, I was still getting segfaults from qml-phone-shell
[19:14] <ogra> thats from dmesg right ?
[19:14] <slangasek> yes
[19:14] <ogra> so how do you know its udev ?
[19:14] <slangasek> because when I adjusted the system so that udev could see the firmware, the error went away? :)
[19:15] <ogra> heh
[19:15] <slangasek> stgraber: +1 on adb shell -> /bin/bash :-)
[19:15] <ogra> yeah
[19:15] <ogra> +100 for that
[19:15] <stgraber> slangasek: do you know what would trigger a remount of / read/write at boot? My fstab is empty yet it's still happening.
[19:15] <slangasek> ogra: also, there's systemd-udev stuff earlier in the log
[19:16] <ogra> i urgently need to find some time to test lool's adbd package
[19:16] <slangasek> stgraber: mountall may have some internal handling of that
[19:16] <stgraber> slangasek: know of any way to prevent it from doing that?
[19:16] <ogra> stgraber, edit /lib/init/fstab
[19:16] <ogra> add ro to the /dev/root line
[19:17] <ogra> it gets processed if there is no entry in /etc/fstab for the mount
[19:17] <slangasek> or, add an equivalent line to /etc/fstab, which would shadow /lib/init/fstab
[19:17] <ogra> yeah
[19:18] <stgraber> ok, trying that now
[19:19] <stgraber> root@ubuntu-phablet:/# touch /a
[19:19] <stgraber> touch: cannot touch '/a': Read-only file system
[19:19] <stgraber> much better, thanks
[19:20] <Bzero> hi someone speak spanish
[19:22] <stgraber> oh, small LXC bug, if the container config dir is read-only, the container won't start... poked hallyn about that one, should be easy to fix
[19:22] <CPCookieIRC> Hello
[19:23] <CPCookieIRC> Having just a tiny problem compiling Ubuntu Touch, anyone around?
[19:23] <Bzero> someone now install ububtu touch in galaxy s4
[19:24] <Bzero> ???
[19:26] <CPCookieIRC> ./home/cpcookieman/UbuntuPhone/out/host/linux-x86/framework/signapk.jar', needed by `/home/cpcookieman/UbuntuPhone/out/target/product/toro/obj/APPS/BIP_intermediates/BIP.apk'.  Stop.
[19:26] <Bzero> anyone know if you can touch can install ubuntu on galaxy s4???
[19:26] <Rowter> hello
[19:26] <CPCookieIRC> Hello rowter
[19:27] <hallyn> stgraber: where do you want the fix most urgently?
[19:27] <Rowter> anyone here have use kyvi with ubuntu and pqlabs multitouch g6?
[19:27] <Rowter> http://multi-touch-screen.com/product_g4.html sorry. anyone had use this overlay on ubuntu?
[19:28] <stgraber> hallyn: saucy
[19:28] <hallyn> stgraber: ok.
[19:28] <Rowter> I made it work but it  seems like detecting it like a mouse, it does not work well, any ideas?
[19:28] <CPCookieIRC> I obviously need this BIP.apk file, Jean-Baptiste Queru is saying that it's part of the LTE network stack.
[19:29] <folf> Bzero: have a look here https://wiki.ubuntu.com/Touch/Devices
[19:29] <folf> Bzero: it's not listed right now, so probably not.
[19:29] <CPCookieIRC> Bzero: Maybe check xda-developers.com and see if it's unofficially supported.
[19:30] <stgraber> rsalveti: so it looks like that even with fstab.mako updated to have system, cache and data commented, Android still tries to mount them and causes a bit of a mess with the data partition
[19:30] <stgraber> rsalveti: I'm going to try and create fake mount entries in the mount namespace, see if that fixes that
[19:30] <Bzero> ok thanks if it will tell you
[19:31] <rsalveti> stgraber: that's unexpected, as the only way to get the partition id is via fstab
[19:31] <ogra> slangasek, so if you add an override file for udev and ubuntu-session-touch, you should be able to work around the issue by manually starting them
[19:31] <ogra> that should definitely be late enough for the container ueventd to be done
[19:32] <CPCookieIRC> Maybe it's just not commented well enough.
[19:32] <CPCookieIRC> Throw in some more ######## maybe some // // // // /* */

[19:32] <rsalveti> stgraber: look with grep if you can find any other file pointing out to /data
[19:32] <rsalveti> not data, but the partition name itself
[19:33] <ogra> !devices | Bzero
[19:33] <ogra> Bzero, if it is not on the device wikipage you might need to try to port it yourself
[19:34] <ogra> hmm, where is the bot ?
[19:34] <DarkEra> gone with the net split?
[19:35] <Bzero> yes will try
[19:35] <ogra> its not a netsplit ... its DADAism
[19:35] <ogra> throwing out lines in the wrong order and all :)
[19:36] <CPCookieIRC> Bzero, that's not going to be easy. What carrier is your S4?
[19:39] <slangasek> ogra: actually, what I've done is forced lxc-android-config to run on 'starting udev', and added a 20 second delay to lxc-android-config at the end; but the firmware is still not getting loaded, I think it's because the kernel driver only asks for it on device access
[19:40] <ogra> hmm, yeah,, that might actually be the difference between mako and maguro ... omap4 has a userspace tool that loads it
[19:40] <slangasek> ogra: ah - no, the 'sleep 20' isn't working, udev is starting way too early
[19:40] <ogra> (which gets run in android )
[19:40] <slangasek> [    2.447581] systemd-udevd[159]: starting version 204
[19:40] <ogra> ah
[19:41] <ogra> well, i'd start with manual
[19:41] <ogra> to see if it changes it at all
[19:41] <slangasek> sure, I'll see what that gives me
[19:41] <Bzero> not carrier is stock from lta
[19:41] <ogra> do you get a black screen or does the google logo stay ?
[19:42] <ogra> if you get a black screen that means surfaceflinger came up ... which in turn means the device was actually accessed
[19:42] <slangasek> ogra: google logo
[19:42] <ogra> ah, yeah
[19:43] <slangasek> hmm
[19:43] <slangasek> oh hah
[19:43] <slangasek> ignore my noises
[19:44]  * ogra tries to ... but i'm to curious what it was 
[19:46] <hallyn> stgraber: fix pushed to saucy
[19:50] <slangasek> ogra: well, the container wasn't running; because I had udev 'manual', but the container was still 'start on starting udev'
[19:50] <ogra> haha
[19:50] <ogra> k
[19:50] <slangasek> # cat ~phablet/.ubuntu-touch-session/logs/qml-phone-shell.log
[19:50] <slangasek> Cant find EGLConfig, returning null config
[19:50] <slangasek> that's new
[19:51] <ogra> are /system and /vendor mounted properly ?
[19:51] <slangasek> yes
[19:51] <slangasek> well
[19:51] <slangasek> in the rootfs yes
[19:51] <slangasek> and in the container, I'm not sure - is the container using namespacing?
[19:52] <LokiScarlet> Sooooo apparently if I remove the 'phablet' user on a phone... It breaks the OS
[19:52] <LokiScarlet> Probably using an auto-login
[19:52] <slangasek> LokiScarlet: yes - so don't do that ;)
[19:52] <ogra> slangasek, you can look in /proc ... use "lxc-info -n android" then look in /proc/$pid/root
[19:53] <slangasek> ogra: right; so I'm not sure what "properly" mounted looks like
[19:53] <slangasek> ogra: but I do have, e.g:
[19:53] <slangasek> 69 49 179:21 /vendor /data/ubuntu/vendor ro,relatime shared:18 - ext4 /dev/block/platform/msm_sdcc.1/by-name/system ro,data=ordered
[19:53] <ogra> well, there is no content if there is no partition
[19:54] <LokiScarlet> slangasek: Any better solution to set my own user settings then? :3
[19:54] <ogra> if ls /proc/$pid/root/system and /proc/$pid/root/vendor return ccontent they should be fine
[19:54] <LokiScarlet> inb4 "wait til the final release", that's just no fun~
[19:55] <ogra> why do you care about the user ID ? its not exposed anywhere
[19:55] <slangasek> LokiScarlet: the phablet account is the user that runs the shell UI; this is hardcoded, and I wouldn't advise trying to change this
[19:56] <ogra> if you need an additional cmdline user, just create one (not sure for what you would want that though)
[19:56] <stgraber> hallyn: thanks!
[19:57] <ogra> slangasek, so to get the android logs you can use /system/bin/logcat -d under ubuntu ... have a look if you can see anything obvious there
[19:57] <LokiScarlet> I'm... Trying to blank the user data and then set stuff in the phone UI.
[19:57] <slangasek> /system/bin/lolcat, got it
[19:57] <ogra> hehe
[19:57] <ogra> LokiScarlet, just follow the release notes for clearing the data
[19:57] <LokiScarlet> The obvious "format user data in CWM" idea.... Well, we all know what that does. :3
[19:58] <ogra> (see chsannel topic)
[19:59] <LokiScarlet> MUTTER FI-- I swear this stuff didn't show up before. >.< I must be going insane
[20:00] <LokiScarlet> Wait a minute...
[20:00] <LokiScarlet> >implying going
[20:00]  * LokiScarlet tilts head ninety degrees and smiles stupidly
[20:01] <beidl> LokiScarlet: >no greentext in here
[20:03] <slangasek> ogra: ok - finally got it to manually boot to the shell.  Now let's see if I can do that a second time, and maybe even make it work automatically.
[20:04] <ogra> yay !!!!
[20:04] <ogra> ha, and i found why powerd doesnt autostart
[20:04]  * ogra tries a fix
[20:04] <ogra> i wonder why sutdown takes so long
[20:05] <ogra> yippie
[20:05] <ogra> finally got powerd autostarting
[20:05] <slangasek> ok, somehow udevtrigger is failing to run
[20:06] <ogra> do you call it like that ?
[20:06] <ogra> isnt it udevadm trigger nowadays
[20:06] <slangasek> the udevtrigger job is failing to run.
[20:06] <ogra> ha
[20:06] <ogra> err
[20:06] <ogra> ah
[20:06] <ogra> boah, thats irritating ...
[20:06] <slangasek> so I can do 'udevadm trigger --action=add && service ubuntu-touch-session restart'
[20:07] <ogra> i am kind of used to not have an eternal command history in the shell
[20:07] <slangasek> ok, how do I *configure* the wifi?
[20:07] <ogra> you cant with the in archive NM
[20:07] <slangasek> phooey
[20:08] <ogra> install the NM and the two libnm packages from the phablet PPA
[20:08] <slangasek> shouldn't those already be the ones installed on this image?
[20:08] <jcastro> out of curiosity is there a performance or power saving benefit to switching around from android/chroot to ubuntu/lxc?
[20:08] <ogra> then you can just use phablet-network-setup from the host or use the UI
[20:08] <slangasek> jcastro: not directly AFAICS
[20:08] <ogra> slangasek, the saucy in-archive NM is newer
[20:09] <slangasek> ogra: ah
[20:09] <ogra> cyphermox_, is working on merging the patches from the PPA one in
[20:09] <ogra> then we should have everything in the archive we need
[20:09] <ogra> pulse will also need love
[20:09] <slangasek> well, anyway - I have the sequencing working now with the sleep kludge, but udevtrigger fails to start for $reasons
[20:10] <slangasek> ah, the fact that I have to restart ubuntu-touch-session is also a sequencing bug
[20:10] <ogra> well, the eternal sleep doesnt sound good
[20:10] <slangasek> I wonder what that should be waiting for
[20:10] <slangasek> yeah, we don't want to do it that way
[20:10] <ogra> on started lxc-android-config
[20:10] <ogra> i'd say
[20:10] <ogra> (i thought i actually added that to the job)
[20:10] <slangasek> no, it already has that and that's too early
[20:11] <ogra> hmm
[20:11] <slangasek> I have to *re*start it after udevadm trigger
[20:12] <ogra> bah
[20:12] <ogra> *sniff*
[20:12] <ogra> g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting
[20:12] <ogra> powerd doesnt stay alive
[20:13] <ogra> but starting it manually doesnt die
[20:13]  * ogra doesnt get that 
[20:13] <ogra> mfisch, does powerd only connect after a while to dbus, and not on startup ?
[20:14] <ChickenCutlass> ogra, you do need the system bus to be up
[20:14] <ogra> it seems to run for a while after boot but then dies with the above error
[20:14] <ogra> so why isnt that reflected in the upstart job then ?
[20:14]  * ogra adds a "start on started dbus" to it 
[20:14] <ChickenCutlass> ogra, dbus support was just added.  It's a bug
[20:14] <ogra> ah, k
[20:15] <ogra> i dont understand why it doesnt crash the same way in unflipped raring though
[20:15] <ogra> they shouldnt differ in that regard
[20:15] <mfisch> dbus support has been there for 2-3 weeks now
[20:15] <mfisch> it should work fine
[20:16] <ogra> well, it doesnt in saucy
[20:16] <sergiusens> ogra: it does in my saucy :-)
[20:16] <ogra> i did see the same issue in the unflipped image
[20:16] <sergiusens> :-p
[20:16] <ogra> then it doesnt with archive packages ... no idea
[20:16] <sergiusens> ogra: ah, without dbus you mean... I can check and validate
[20:16] <sergiusens> ogra: but I guess no one fell into the issue of no dbus
[20:17] <ogra> ha !
[20:17] <ogra> so "start on started dbus" definitely fixes it
[20:17] <sergiusens> ogra: I do recall launching powerd when I had the _broken_ mountall
[20:17] <ogra> my screen just tirned off right after boot
[20:17] <mfisch> ogra: so do we need to modify the upstart job?
[20:18] <ogra> mfisch, yeah
[20:18] <ogra> it currently starts on mounted /run
[20:18] <mfisch> start on started dbus?
[20:18] <ogra> thats really really early
[20:18] <ogra> yup
[20:19] <mfisch> okay, I have no device to test on so I will take your word
[20:19] <ogra> ask sergiusens with an unflipped image if it works for him
[20:19] <ogra> that should cover both setups we have atm
[20:20] <mfisch> ogra: here's the mp: https://code.launchpad.net/~mfisch/powerd/startondbus/+merge/167632
[20:20] <mfisch> lets wait on sergiusens
[20:20] <LokiScarlet> beidl: Gonna be hard to do, I've got my shell text set to green
[20:20] <mfisch> sforshee: ping
[20:20]  * LokiScarlet rimshot
[20:21] <sforshee> mfisch, pong
[20:21] <mfisch> sforshee: we need to modify upstart to wait until dbus is up
[20:21] <mfisch> sfeole: MP is above, but dont approve until we hear from sergiusens
[20:21] <beidl> LokiScarlet: well played
[20:21] <sforshee> mfisch, upstart?
[20:21] <ogra> the job, not init :)
[20:22] <mfisch> sfeole: hah yeah
[20:22] <sforshee> that's what I was guessing
[20:22] <sergiusens> ack
[20:22] <ogra> dont tell jodh that you want to make upstart depend on dbus being up *grin*
[20:23] <LokiScarlet> beidl beidl beidl, if nothing's in my way, beidl beidl beidl, with your mind I will play. (Sorry, your name's just that interesting.)
[20:24] <beidl> LokiScarlet: I'm assuming you already guessed what my nick name really means
[20:24] <sforshee> mfisch, give me a minute to test then I'll approve the mp
[20:25] <LokiScarlet> Not a clue.
[20:25] <LokiScarlet> :3
[20:25] <LokiScarlet> Why, does beidl mean something cool?
[20:25] <mfisch> sforshee: we need to wait on sergiusens too
[20:25] <mfisch> he has a "flipped" image
[20:26] <sforshee> mfisch, okay. Is he already testing?
[20:26] <sergiusens> I am unflipped
[20:26] <beidl> LokiScarlet, well, lets put it that way, it's all about the D
[20:26]  * mfisch isnt sure what flipped means but hopefully someone tries it
[20:27] <LokiScarlet> So it means you're a dick? Cause I can prove you wrong and dethroned on that one if you give me some time
[20:28]  * LokiScarlet is teh bakas
[20:30] <ogra> mfisch, booting into ubuntu, running android in lxc .... thats what i have here (and what is our actually planned image setup)
[20:30] <ogra> sergio has the old image model, just on saucy packages
[20:30] <ogra> (flipped the containers)
[20:30] <mfisch> ogra: ah, thanks for explaining
[20:31] <beidl> LokiScarlet, hmm... interesting
[20:31] <sforshee> mfisch, well the change works in the flipped model at least
[20:31] <sforshee> I guess sergiusens can approve when he's done testing
[20:31] <mfisch> sforshee: ok
[20:32] <folf> When flashing  a newer build with phablet-flash, does it always remove the coreapps installed from the ppa's? Or is this supposed to change?
[20:34] <pmcgowan> sergiusens, folf asks a good question
[20:36] <ryukafalz> So I've been wondering... will Ubuntu Touch use the standard web device APIs being worked on at the W3C and such?
[20:36] <ryukafalz> things like media capture and screen rotation, for instance
[20:36] <manoelramon> I need to compile ubuntu touch under x86.. how do I get the source code instead pre-defined images for ARM ?
[20:37] <ogra> pmcgowan, folf, that will start working once we have image based upgrades ... (alternatively the flipped container will allow you to use apt)
[20:37] <sergiusens> pmcgowan: folf I guess always until we have click packages
[20:38] <sergiusens> ogra: well, final solution is click packages installing in user data locations
[20:38] <ogra> yeah
[20:38] <ogra> which will work with image based upgrades :)
[20:38] <folf> ogra, OK. It's not a big issue, but I'd expect a lot of people doing the adb to install openssh, then add ppa's, then install apps :-)
[20:38] <ogra> but the flipped container should enable you to just upgrade through apt like on your desktop
[20:39] <ogra> until the image based upgrades/click package combo is there
[20:39] <ogra> i expect that you wont need to reflash anymore once we have the container flip fully implemented
[20:40] <manoelramon> Sergio, how do I get the souce code ? need to compile for x86 !
[20:40] <ogra> (until image based upgrades do it automatically at least)
[20:40] <sergiusens> ogra: we still need to solve platform-api and hybris... it's the only reason we are not promoting apt-get
[20:40] <sergiusens> manoelramon: hey, got your email... loaded question :-)
[20:40] <ogra> sergiusens, we have the toolchain, its a matter of someone having time to package them :)
[20:40] <sergiusens> manoelramon: everythng is here http://phablet.ubuntu.com/gitweb
[20:41] <ogra> i hope that we have that in place when the flip goes active
[20:41] <sergiusens> manoelramon: just look for the phablet-10.1 branches and cherry pick
[20:41] <sergiusens> ogra: +1
[20:41] <manoelramon> sergio: but there after to fetch the code I have only a project called ubuntu
[20:41] <manoelramon> and on this ubuntu dir I have only assets and xchroot
[20:41] <manoelramon> no code!!!
[20:42] <sergiusens> manoelramon: how are you doing the clone?
[20:42] <ogra> manoelramon, follow the porting wikipage, that should get you all trees
[20:42] <sergiusens> ogra: he's trying x86... it's a different repo ;-)
[20:42] <sergiusens> ogra: as in repo sync manifest
[20:42] <ogra> sergiusens, well, he needs the phablet repo, no ?
[20:43] <ogra> plus an x86 tree he needs to add himself
[20:43] <sergiusens> ogra: yeah... that's why I said loaded question, not sure :-)
[20:43] <asac> rsalveti: lunch doesnt work with our android stuff?
[20:43] <asac> actually ... wonder what java i need :)
[20:43] <ogra> so first step: phablet-dev-bootstrap
[20:43] <asac> https://wiki.ubuntu.com/Touch/Building
[20:43] <asac> java is not mentioned there
[20:43] <ogra> asac, 1.6
[20:43] <rsalveti> we removed the java dependency
[20:43] <ogra> opjdk is fine
[20:43] <asac> java SE? or openjdk is also ok?
[20:43] <asac> ok
[20:43] <ogra> *open
[20:43] <sergiusens> asac: lunch works... openjdk should be fine... still need to get rid of some bits
[20:44]  * asac uninstalls jdk 7 :)
[20:44] <rsalveti> sergiusens: didn't we remove it all?
[20:44] <ogra> iirc you can have them in parallel
[20:44] <rsalveti> yeah, just use openjdk
[20:44] <ogra> (6 and 7)
[20:44] <sergiusens> rsalveti: forgot about bouncycastle
[20:44] <manoelramon_> sergio I used the follwing "repo init -u git://phablet.ubuntu.com/CyanogenMod/android.git -b phablet-10.1"
[20:44] <rsalveti> sergiusens: ok
[20:44] <sergiusens> manoelramon: and repo sync for that didn't work?
[20:44] <asac> sergiusens: so we dont have bouncy?
[20:45] <asac> does it mean i need oracle for now?
[20:45] <sergiusens> asac: it's in, but we might not need it at all
[20:45] <manoelramon_> sergiousens: yes.. worked however I have only a new project called "ubuntu" with two folders inside... but no source code.
[20:45] <asac> i did the bootstrap i think ... i basically gave mea  checkout of the android code
[20:45] <sergiusens> asac: nope, openjdk is fine... the oracle java thing is mostly for apk and android services
[20:45] <asac> kk
[20:46] <rsalveti> manoelramon: repo sync should have copied all your sources files
[20:46] <rsalveti> manoelramon: did it take long to run?
[20:46] <sergiusens> manoelramon: rinse and repeat, just in case you got a broken connection
[20:46] <sergiusens> manoelramon_: which x86 sources are you using btw?
[20:47] <asac> where is the livehelper config for our phablet rootfs?
[20:47] <asac> live-build  :)
[20:47] <AskUbuntu> What are the supported devices for ubunu Phone? | http://askubuntu.com/q/304550
[20:47] <manoelramon_> I should compile for medfield intel x86 based
[20:47] <manoelramon_> let me run the repo sync again
[20:47] <sergiusens> asac: ah, got scared there for a second :-P had no idea what livehelper was :-)
[20:47] <sergiusens> asac: https://code.launchpad.net/~phablet-team/touch-preview-images/ubuntu-build-phablet-saucy
[20:47] <sergiusens> asac: as the name implies, that's for saucy
[20:47] <sergiusens> asac: with no container flip
[20:48] <rsalveti> asac: we also got it upstream
[20:48] <asac> yeah, its the old name ... when i still hacked on it it was named like that
[20:48] <rsalveti> for the image ogra is working on
[20:48] <sergiusens> asac: the other one is in liverootfs branch iirc the name
[20:48] <folf> sergiusens, ogra, pmcgowan BTW I found this: http://bazaar.launchpad.net/~popey/+junk/phablet-flash-wrapper/view/head:/add_apps.sh
[20:48] <folf> Quite useful...
[20:48]  * asac tries to go deep in to his memory to remember how this live-buidl thing worked
[20:49] <pmcgowan> folf, indeed good ole popey
[20:50] <rsalveti> manoelramon_: just saw your email, so try grabbing the sources again, it should work and get you the needed files
[20:50] <rsalveti> you might need to modify them to make it x86 compatible
[20:50] <asac> ok so live-build has certainly evolved a bit :)
[20:50] <rsalveti> manoelramon_: do you have a standard android build tree for x86 that's based on android 4.2?
[20:50] <rsalveti> might be easier to change that instead of trying to build from our sources atm
[20:50] <rsalveti> as I know cyanogenmod doesn't yet support x866
[20:51] <sergiusens> rsalveti: I'm trying to figure out which way the porting is being done
[20:51] <sergiusens> to an x86 tree or from one
[20:51] <rsalveti> might be easier to grab a working android build from intel and reduce it like we did
[20:51] <cyphermox_> rsalveti: sergiusens: I'm pretty much ready to push NM to distro for saucy, but you'd still need to run logind on the touch image, and that breaks the UI currently...
[20:51] <sergiusens> rsalveti: well that was my stance
[20:51] <ogra> asac, for the cdimage side you want livecd-rootfs
[20:52] <rsalveti> cyphermox_: what breaks?
[20:52] <ogra> if you want to roll the flipped image that is
[20:52] <manoelramon_> ok I am fetching the code again.... yes, I do have... I am wondering put the code under my env and compile using our compiler here.... I have all android source code JB including kernel.. that's why I do not wanna port using CM
[20:52] <rsalveti> manoelramon_: right, might be easier
[20:52] <cyphermox_> well you can't actually establish a wifi connection from the UI, you can click it but NM won't be able to authenticate the dbus calls or something
[20:52] <ogra> cyphermox_,
[20:52] <ogra> root@ubuntu-phablet:/# ps ax|grep logind
[20:52] <ogra>   532 ?        Ss     0:00 /lib/systemd/systemd-logind
[20:52] <rsalveti> manoelramon_: http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_build.git;a=shortlog;h=refs/heads/phablet-10.1
[20:52] <ogra> i have no issues here
[20:53] <cyphermox_> ogra: yes, logind is running, that's fine
[20:53] <rsalveti> these are the most important changes we did to reduce the build
[20:53] <ogra> (uding the new world order though)
[20:53] <ogra> *using
[20:53] <cyphermox_> I have logind running here too
[20:53] <manoelramon_> rsalveti: the "ubuntu" project is the folder that should contain all code for touch rgith ?
[20:53] <rsalveti> manoelramon_: basically to remove everything dalvik and app related from android
[20:53] <cyphermox_> but NM relies on that to authenticate the calls, and AIUI it wasn't available in the display server ?
[20:53] <rsalveti> and get a tiny version that is console only (plus a few services, such as surface flinger)
[20:53] <manoelramon_> rsalveti: yes, I saw in the manifest.
[20:54] <sergiusens> manoelramon_: the changes are all over the place
[20:54] <rsalveti> manoelramon_: no, that's just the compat layer which makes it easier to talk with the ubuntu side
[20:54] <sergiusens> manoelramon_: basically if there's a phablet-10.1 branch in the repo in the tree it has changes
[20:54] <rsalveti> you'd also need a ubuntu x86 based image
[20:54] <rsalveti> which we can generate using live-build
[20:54] <rsalveti> but that would be the second step
[20:55] <rsalveti> first step would be getting a minimal image that is able to boot in your device
[20:55] <rsalveti> then trying to get hybris to work, and see if the test cases would work there
[20:55] <manoelramon_> rsalveti: that's the question.. the x86 image in on your webgit also ?
[20:55] <rsalveti> I noticed a few intel folks contributing to hybris, so I'd expect it to work for x86 as well
[20:55] <sergiusens> manoelramon_: no, it's not
[20:55] <rsalveti> that's created from the ubuntu archive
[20:55] <rsalveti> via live-build
[20:56] <manoelramon_> I do not think I will need to port all commits you have done because you fixed bunch of problems I will not have... just wondering how to get the code/image and put over my kernel...
[20:57] <rsalveti> manoelramon_: right, that's why I'd start based on this branch (you can just take the changes, not necessarily all commits), and try to get a minimal image to work first
[20:57] <rsalveti> meanwhile we can produce an ubuntu rootfs via live-build which you can use
[20:58] <rsalveti> sergiusens: we should have everything in the ppa to produce a x86 based image
[20:58] <rsalveti> using raring would probably be a better idea for now
[20:59] <manoelramon_> rsalveti: I already did all changes in the kernel.. I am only need the x86 sources... I could compile to medfield and push back to you.
[20:59] <rsalveti> right, kernel changes should be minimal
[20:59] <rsalveti> the ones under build are the most critical to generate a minimal image
[21:01] <ogra> and you will have to find an x86 tree yourself to add it
[21:02] <ogra> on phablet.ubuntu.com there is none
[21:04] <sergiusens> rsalveti: saucy is solid
[21:04] <rsalveti> sergiusens: lol
[21:05] <rsalveti> sergiusens: can't even have a stable saucy in my desktop
[21:05] <rsalveti> ogra: right, but would be nice if we could support that as well
[21:05] <rsalveti> would just need to check the changes done per repo, which is really painful
[21:05] <rsalveti> and would need a device as well
[21:07] <ogra> rsalveti, well, sure, i would have worked on it but there is always something with high prio on my desk since i joined the same team you work in ... i knew that would happen, i so did !
[21:07] <ogra> :)
[21:07] <manoelramon_> rsalveti
[21:07] <asac> repo sync doesnt work?
[21:07] <manoelramon_> rsalveti: my devices boots :)
[21:07] <asac> fatal: Not a git repository (or any parent up to mount point /home)
[21:07] <asac> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
[21:07] <asac> Traceback (most recent call last):
[21:07]  * ogra votes for renaming phonedations into canonical-workaholics
[21:07] <rsalveti> ogra: right
[21:08] <rsalveti> lol
[21:08]  * rsalveti blames asac 
[21:08] <rsalveti> lol
[21:08] <ogra> "hello, my name is oliver and i am a workaholic ... i am dry since two weeks now .... "
[21:09] <mhall119> 0.01 days without a relapse
[21:09] <ogra> yeah, its definitely all asacs fault
[21:09] <asac> i take that as a compliment :P
[21:09] <ogra> :)
[21:10] <asac> still repo sync doesnt work here :)
[21:10] <asac> but its totally possible that its me
[21:10] <rsalveti> well, as long we don't kill any developer til we release the project we're good lol
[21:10] <rsalveti> asac: hm, let me start fresh to see
[21:11] <asac> wait its here for sure
[21:11] <rsalveti> sergiusens: why are we still building raring based images automatically?
[21:11] <ogra> so that my sync script doesnt feel lonely
[21:11] <rsalveti> repo sync working fine here
[21:12] <mhall119> don't let the machines get lonely, that's when they'll turn on us
[21:12] <rsalveti> manoelramon_: with a minimal image? (aka no dalvik)
[21:13] <manoelramon_> rsalveti: not yet :) ... but if boot today, when you will give me the other sources :) ?
[21:14] <rsalveti> manoelramon_: actually it's just a rootfs, let me try here
[21:15] <manoelramon_> rsalveti: no problem :) but if you give me the code I reply you with compiled for medfield processor ... I swear :)
[21:16] <sergiusens> rsalveti: lol
[21:16] <rsalveti> manoelramon_: would i386 work fine for medfield ?
[21:16] <sergiusens> rsalveti: tough news for you, but I think ofono is only bulding for amrhf
[21:17] <rsalveti> sergiusens: true, have that in my todo
[21:17] <asac> in live-build ... --bootstrap-qemu-arch is used for what?
[21:17] <sergiusens> rsalveti: most apps and components only link to platform-api if it is arh armhf
[21:17] <rsalveti> asac: to build it with qemu
[21:17] <manoelramon_> theoretically yes
[21:17] <rsalveti> sergiusens: that's being fixed as we're pushign things to the archive
[21:19] <rsalveti> manoelramon_: awesome
[21:19] <rsalveti> I'm running live-build to see what happens here, but we might indeed have missing packages
[21:19] <manoelramon_> I hope dude :)
[21:19] <rsalveti> which we're fixing anyway
[21:21] <manoelramon> Thank you so much Ricardo!!!
[21:29] <rsalveti> sergiusens:
[21:29] <rsalveti> E: Unable to locate package libandroid-audiosystem-asound2
[21:29] <rsalveti> E: Unable to locate package powerd
[21:29] <rsalveti> so fixing the android audiosystem unblocks ofono
[21:29] <rsalveti> now powerd is a different issue
[21:29] <rsalveti> shouldn't be armhf specific
[21:32] <stgraber> rsalveti: we'll really need to teach Android not to touch /data, /cache and /system at all...
[21:32] <sergiusens> rsalveti: yup... but libandroid-audiosystem-asound2 always has... not that it's right or wrong
[21:32] <stgraber> I just noticed that it's trying to remount them ro on shutdown or something
[21:32] <stgraber> which means remounting /data read-only but that's our data partition so that's not that great...
[21:32] <rsalveti> stgraber: right, that we can fix
[21:32] <rsalveti> but it can only mount with fstab
[21:33] <stgraber> granted you're not supposed to stop the android container, but still...
[21:33] <rsalveti> after it's mounted it can try to remount, which we can fix from the android side
[21:33] <stgraber> rsalveti: yep, apparently it's respecting the fstab, still failing to start but I'm trying to track that one down now
[21:33] <rsalveti> stgraber: ok
[21:35] <asac> refs/heads/phablet-10.1
[21:35] <asac> what is that based on?
[21:35] <asac> android-4.1.2_r2 ?
[21:36] <rsalveti> yup
[21:37] <rsalveti> actually it's a bit newer than that, but not the latest 4.2.2 tag
[21:37] <asac> refs/tags/android-4.2.2_r1 ? you pull those prebuilts in
[21:37] <asac> ok
[21:37] <asac> i see
[21:37] <asac> so that was misleading then
[21:37] <asac> i will use that
[21:37] <asac> to replace our binoic
[21:37] <asac> so guess would be good to know exactly :)
[21:37] <asac> let me see our gitweb
[21:39] <asac> hard to say
[21:39] <rsalveti> asac: replace our bionic?
[21:39] <rsalveti> why?
[21:39] <asac> seems we didnt push any very recent tags to our phablet
[21:39] <asac> rsalveti: because it has hackery that is a bit annoying atm :)
[21:39] <asac> sincos
[21:39] <rsalveti> nops, we didn't touch that since jan or such
[21:39] <asac> ok i see
[21:39] <rsalveti> asac: we welcome patches
[21:39] <asac> hehe
[21:39] <ogra> ++
[21:40] <asac> rsalveti: so do we know where this is based off?
[21:40] <asac> cm-10.1
[21:40] <rsalveti> CM10.1 M1 I think
[21:40] <rsalveti> let me check
[21:40] <rsalveti> there's a cm tag
[21:40] <asac> but what that is is harrd to figure for me
[21:40] <asac> yeah its cm-10.1
[21:41] <asac> but i what android is that based on?
[21:41] <rsalveti> sure, but there are a bunch of tags
[21:41] <rsalveti> :-)
[21:41] <asac> oh i see a merge
[21:41] <asac> its 4.2.2_r1
[21:41] <asac> http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_bionic.git;a=shortlog;h=refs/heads/cm-10.1
[21:41] <asac> pretty high on top there
[21:41] <rsalveti> right
[21:41] <asac> ok let me try that
[21:41] <rsalveti> and why are you looking into that?
[21:41] <rsalveti> any feature we're missing?
[21:42] <rsalveti> yeah, it's based on CM10.1 M1
[21:42] <asac> hmm. those cm guys didnt push the tag
[21:42] <asac> let me find the commit
[21:43] <rsalveti> manoelramon: where can I find the intel android tree?
[21:43] <rsalveti> or is that already upstream?
[21:43] <stgraber> rsalveti: so, my current problem is that the container kinda starts, /system/bin/mediaserver is spawned, stays there for a few seconds and then the container dies
[21:43] <stgraber> rsalveti: rings a bell?
[21:44] <rsalveti> stgraber: hm, no
[21:44] <rsalveti> stgraber: no logs?
[21:44] <rsalveti> logcat would be useful there
[21:45] <jono> pmcgowan, hey
[21:45] <jono> pmcgowan, any idea who is working on the infographics work?
[21:46] <stgraber> rsalveti: how do I turn /dev/alog/main into something readable?
[21:47] <rsalveti> hm, would need to investigate
[21:47] <rsalveti> let me check
[21:48] <RobbyF> will the email client support exchange?
[21:48] <rsalveti> stgraber: just a simple cat would already be useful
[21:50] <rsalveti> stgraber: try running logcat manually
[21:50] <rsalveti> it should be static linked I'd guess
[21:51] <rsalveti> if not you can probably build it easily
[21:51] <rsalveti> http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_system_core.git;a=tree;f=logcat;h=9cd412866c535d84bd1b106ad4fa32e3a438f1b5;hb=refs/heads/phablet-10.1
[21:52] <ogra> stgraber, /system/bin/logcat
[21:52] <ogra> it is definitely static
[21:52] <rsalveti> yeah, if you have it mounted it'd just work
[21:52] <ogra> :)
[21:52] <asac> rsalveti: you are android-audiosystem guru? what is so armel specific there?
[21:52] <rsalveti> asac: that's what I'm checking now
[21:52] <rsalveti> this is old code from motorola
[21:53] <asac> intersting :)
[21:53] <ogra> well /var/lib/lxc/android/rootfs/system/bin/logcat (can we add some more subdirs) then
[21:53] <asac> is it important for primary user experience?
[21:53] <asac> e.g. booting, showing stuff on screen etc.?
[21:53] <rsalveti> asac: well, just no sound
[21:53] <asac> kk
[21:53] <asac> no crashes?
[21:53] <rsalveti> nops
[21:53] <stgraber> ogra: not static
[21:53] <ogra> oh
[21:53] <stgraber> /var/lib/lxc/android/rootfs/system/bin/logcat: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), stripped
[21:53] <asac> rsalveti: what is it doing? talking to... alsa?
[21:53] <asac> :)
[21:53] <manoelramon> https://01.org/android-ia/documentation/faq
[21:53] <rsalveti> asac: other way around
[21:53] <rsalveti> asac: for pulse to talk to audioflinger
[21:54]  * asac turns upside down
[21:54] <rsalveti> manoelramon: thanks
[21:54] <asac> ok. doesnt sound very armel specific
[21:54] <ogra> stgraber, link system to / then ... LD_PRELOAD should give you all you need
[21:54] <rsalveti> asac: no, just stupid build system
[21:54] <ogra> (it points to /system/lib)
[21:54] <rsalveti> as we got some .S files there
[21:54] <asac> yeah
[21:54] <asac> have you tried sedding everythign :)?
[21:54] <stgraber> ogra: read-only, remember? :)
[21:54] <rsalveti> asac: I'm fixing it
[21:55] <ogra> stgraber, well ... remount rw ... then set the link
[21:55] <rsalveti> stgraber: chroot
[21:55] <asac> good
[21:55] <rsalveti> and then run it from the android container
[21:55] <rsalveti> shouldn't explode :-)
[21:55] <ogra> you dont have /dev
[21:55] <ogra> need to bind mount it
[21:55] <rsalveti> haha
[21:55] <sergiusens> manoelramon: I have may have access to some intel devices from the Cordoba site... I'll get your tree's and see what happens
[21:56] <ogra> hmm, there is still something fishy with powerd
[21:59]  * ogra tries to move it later 
[21:59] <ogra> hmm
[21:59] <ogra> is there any reason why we dont have ubuntu-session start powerd ?
[21:59] <stgraber> rsalveti, ogra: http://paste.ubuntu.com/5737111/
[22:00] <rsalveti> well, powerd is a system service
[22:00] <asac> ogra: my understanding is that powerd is something deeper entrenched in the OS than a session...
[22:00] <ogra> asac, well, it needs bits from the container and dbus
[22:01] <asac> dbus is started in the gnome-session?
[22:01] <ogra> stgraber, same issue slangasek has
[22:01] <asac> otherwise i dont know what ubuntu-session is :)
[22:01] <rsalveti> stgraber:
[22:01] <rsalveti> D/overlay ( 1001): initoverlay:: opening the device:: /dev/graphics/fb2
[22:01] <rsalveti> E/overlay ( 1001): cannot open framebuffer(2)
[22:01] <asac> (and you can ignore me)
[22:01] <ogra> asac, the session bus, not the system bus
[22:01] <rsalveti> then egl fails, which causes surfaceflinger to crash
[22:01] <ogra> asac, https://code.launchpad.net/~phablet-team/session-manager-touch/trunk
[22:01] <rsalveti> but still, it should go on and print more messages
[22:02] <asac> do we use androids busybox?
[22:02] <rsalveti> is that all you get?
[22:02] <asac> err the busybox of CM
[22:02] <asac> (android doesnt have that)
[22:02] <ogra> i dont think so
[22:02] <rsalveti> asac: http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_external_busybox.git;a=summary
[22:02] <ogra> oh, we do ?
[22:02] <asac> so we use that?
[22:02] <asac> hmm
[22:02] <ogra> but with nothing enabled i guess
[22:02] <asac> what is the official android replace called?
[22:03] <ogra> /bin/sh: 0: Can't open /proc/self/fd/9
[22:03] <ogra> ** (process:489): DEBUG: owner id: 1
[22:03] <ogra> ** (process:489): DEBUG: Activity Timeout is 30 seconds
[22:03] <ogra> woah
[22:03] <asac> ah its toolbox
[22:03] <asac> right
[22:03] <asac> thats what its called
[22:03] <ogra> (powerd log)
[22:04] <stgraber> slangasek: apparently I'm hitting the same bug as you had (lxc container not starting), what's the problem?
[22:05] <ogra> stgraber, his container was starting, his  session wasnt ...
[22:05] <ogra> race between udev and the container start
[22:05] <stgraber> ok, my container isn't starting at all and I've got udev in Ubuntu disabled
[22:05] <rsalveti> stgraber: is that all you got from logcat?
[22:05] <stgraber> well, it starts for a minute and dies. The only process I see init spawn is /system/bin/mediaserver
[22:06] <stgraber> rsalveti: yep
[22:06] <rsalveti> stgraber: can you check if you have /dev/graphics/fb2 inside your android container?
[22:07] <rsalveti> hm, that error also happens here
[22:07]  * ogra guesses only while the container is running
[22:07] <ogra> i guess fb2 is HDMI
[22:07] <stgraber> rsalveti: I'll try but as I said the container dies pretty quickly, so I'll have to do some clever tricks to pull the data before it goes away
[22:07] <rsalveti> W/SurfaceFlinger( 1001): no suitable EGLConfig found, trying without EGL_FRAMEBUFFER_TARGET_ANDROID
[22:07] <ogra> or however that special plug adapter thing is called
[22:07] <rsalveti> so surface flinger fails completely here
[22:08] <asac> do we have lots of arm specific stuff in powerd?
[22:08] <rsalveti> which could mean issues with udevd or it couldn't see the vendor stuff
[22:08] <rsalveti> stgraber: are you using our own system.img file?
[22:08] <rsalveti> or did you build it your own?
[22:08] <stgraber> rsalveti: nope, used the one from ubuntu-touch-preview
[22:08] <ogra> unpacked from ours
[22:09] <ogra> did you tar it and forgot --numeric-owner or some such ?
[22:09] <rsalveti> W/Adreno200-EGL( 1001): <eglGetConfigs:400>: EGL_NOT_INITIALIZED
[22:09] <rsalveti> now why would the driver fail
[22:09] <ogra> because /vendor isnt set up
[22:09] <rsalveti> E/Adreno200-GSL( 1001): <ioctl_kgsl_driver_entry:269>: open(/dev/kgsl-3d0) failed: errno 2. No such file or directory
[22:09] <rsalveti> there you go
[22:09] <stgraber> ogra: mix of root and gid 2000, that looks vaguely reasonable
[22:10] <stgraber> rsalveti: well, yeah, as part of my problems I don't even see ueventd starting, so I'd expect /dev to be pretty much empty
[22:10] <ogra> ah, no /dev
[22:10] <stgraber> as I said, I only see a single process being spawned in the container and that's "/system/bin/mediaserver"
[22:11] <stgraber> no ueventd that I can see
[22:11] <rsalveti> the rest might fail
[22:11] <rsalveti> or init fails completely
[22:11] <ogra> yeah, so talk to jhodapp, we cant help :P
[22:11] <rsalveti> due lack of udev
[22:11] <rsalveti> ueventd
[22:11] <ogra> mediaserver is his area
[22:11] <ogra> :P
[22:12] <ogra> did you modify init.rc somehow ?
[22:12] <stgraber> ogra: nope, only changes I did comment cache, system and data in fstab.mako and removed adbd (just in case)
[22:13] <ogra> no need for that
[22:13] <ogra> in fact i would leave it there, that way you can easily switch between ubuntu and container
[22:13] <ogra> (by setting the adbd upstart job to manual)
[22:14] <ogra> adbd wont start if its loopback port is already taken
[22:16] <ogra> stgraber, do you have  nodev.nosuid options set on /data by chance ?
[22:19] <stgraber> ogra: nope
[22:21] <|QuaD|> hello! quick question for you. I am setting up ubuntu touch on my nexus 7 for fun. How are upgrades handled? is it done throuhg normal apt? or do i have to reflash an image everytime
[22:23] <ogra> you currently have to reflash
[22:23] <ogra> since there are bits in the android layer that arent packaged but require updates on package upgrades
[22:24] <ogra> phablet-flash is clever enough to keep your userdata intact though
[22:51] <|QuaD|> ogra: thanks! do we have an eta of when something like nexus 7 will be autoupdateable?
[22:52] <ogra> apt updates will work once the images have the flipped container model in use and the two bits that we use inside android are packaged
[22:52] <|QuaD|> cool
[22:52] <ogra> on the former there is active cross team work going on
[22:52] <ogra> so it should be in place *soon*
[22:53] <ogra> the latter will have to wait until someone has time to actually do the packaging
[22:55] <|QuaD|> and once that build comes out, i just have to run phablet-flash, it will upgrade and then be upgradeable?
[22:55] <asac> remember that apt updates are really just an intermediate state
[22:56] <asac> we are actually shooting for system updates
[22:56] <asac> (for end user experience at least)
[23:30] <rickspencer3> kenvandine, bfiller http://theravingrick.blogspot.com/2013/06/the-social-phone.html
[23:31] <slangasek> stgraber: mmm, the issue I had was because I had changed the lxc-android-container job to start on 'starting udev' and had set the udev job to manual
[23:32] <stgraber> slangasek: yeah, my issue appears unrelated as I already had udev disabled to check that wasn't the problem. Not sure exactly what's going on, but I guess it was to be expected that some bits would fail when moving to a read-only root
[23:38] <mfisch> sergiusens: can you approve the upstart job change for powerd?  https://code.launchpad.net/~mfisch/powerd/startondbus/+merge/167632
[23:40] <slangasek> ogra: is there a master bzr branch for lxc-android-config?  (it's not in debian/control)