[00:06] <iBelieve> I've been running some of the core touch apps on an Ubuntu PC, for example the weather app. I just came across a picture of the weather app on android central (running on a tablet) that has the new design and graphics, but the PPA version doesn't. I tried running it directly from the launchpad branch, but same there. Where can I get the latest version?
[00:28] <amedian> are there anyone to help me ubuntu touch install on htc desire z
[00:30] <amedian> are there any one allive
[00:34] <mhall119> iBelieve: do you have a link to that picture?
[00:34] <mhall119> amedian: most folks arne't active on IRC on the weekend, especially Sunday evenings
[00:35] <amedian> thank you to inform me
[00:36] <amedian> have a good evenings bye
[01:19] <iBelieve> mhall119, here it is: http://cdn.androidcentral.com/sites/androidcentral.com/files/imagecache/w680h550/postimages/9274/ubuntu_touch-3.jpg
[01:45] <mhall119> iBelieve: ah, that was just an image used as a placeholder until the actual weather app was developed
[01:45] <mhall119> but we should be getting the new "Suru" visual designs for the weather app, which is likely to make it look more like that mockup
[01:47] <iBelieve> mhall119, Oh, I see, it looked somewhat like the new designs so I assumed that is what they were. Now I'm realizing that the dates in the article and in the weather app are way before blog posts about the new designs. Sorry for the mistake.
[01:47] <iBelieve> Way looking forward to seeing the new designs! Great work on Ubuntu touch!
[01:50] <mhall119> thanks, I'm looking forward to them too
[01:51] <wilee-nilee> Hows the touch on the saucy img, I have a nexus 7 it has been a bit problematic in the past?
[01:53] <mhall119> wilee-nilee: mostly the same as raring
[01:55] <wilee-nilee> mhall119, Cool thanks.
[05:45] <McKinnon3048> I'm having serious trouble with my ubuntu touch instalation, is this a good place to ask for help
[05:48] <McKinnon3048> is there anybody awake on here?
[05:48] <McKinnon3048> well, I'll ask anyway, and see what happens
[05:49] <RAOF> There'll be people awake here. I believe this would be a good place to ask.
[05:50] <McKinnon3048> I used the terminal instalation for the Ubuntu touch preview, first boot after instalation it takes me to the ubuntu logo'd background recovery screen, but error says the file autoboot isn't found (or something allong that)
[05:50] <McKinnon3048> i tried pushing to SD and sideloading as per the manual instructions, but neither of those work
[05:51] <McKinnon3048> rebooting the tablet takes me to the google unlocked Black screen of death, or to the battery charging screen, the only way back is via power/volume down for recovery, which then boots to that ubuntu background
[05:51] <McKinnon3048> right now i'm bricked and would apriciate ANY help
[06:52] <KriShANsiN> oh boy
[06:53] <KriShANsiN> the nexus 4 is nice. LG phone with saucy?
[06:53] <KriShANsiN> anyone got a nex4 with saucy on it yet?
[06:54] <KriShANsiN> anyone running "mako" ?
[06:54] <didrocks> KriShANsiN: hey, and it's running fine. See as well https://wiki.ubuntu.com/Touch/Devices
[06:56] <KriShANsiN> didrocks: i am going crazy. i cant believe it. we get to flash google foogle firware and run Linux on these LG bad boys? wow! i cant wait to get this.!
[06:58] <KriShANsiN> how are the devs making money? why is all this happening?
[06:58] <KriShANsiN> why is google Andy Rubin so creepy?
[06:58] <KriShANsiN> the Nexus 4 is soooo beautiful but, it creeps me out to hold it because it has google firmware on it.
[06:59] <KriShANsiN> i need to get quantal on this bad korean phone
[07:02] <KriShANsiN> so i guess i just need to pay pal some bucks to the ubuntu touch dev team once i get this up and running
[07:04] <KriShANsiN> so the next question is , when will this be available for iPhones?
[07:04] <KriShANsiN> is that even legal?
[07:05] <Namidairo> when apple unlock the bootloader, someone develops a kernel for it, and ports to cm-10.1
[07:05] <Namidairo> ie. never.
[07:05] <KriShANsiN> so the nexus 4 with mako is the way to go then yeah ?
[07:10] <KriShANsiN> so i flash Jelly Bean and replace it with mako.
[07:10] <KriShANsiN> hell yeah
[07:14] <KriShANsiN> oh man oyu guys are crazy as hell, taking a brand new hard to get Nexus 4 special white edition , running a perfetly fine google firmware that was worked hard on, and replacing it with "mako"? wow!! that is soooo crazy . i have to go lay down for a minute to comprehend what you guys are doing.
[07:15] <Namidairo> wut.
[07:19] <dholbach> good morning
[09:54] <Saviq> ogra_, ping
[10:14] <ogra_> Saviq, hey
[10:14] <Saviq> ogra_, hey, is the full adb suite supposed to be supported in the flipped images?
[10:14] <ogra_> no, not evrything
[10:15] <ogra_> the shell always runs as root, to get logcat you need to do adb shell /system/bin/logcat ... etc
[10:15] <Saviq> ogra_, ok, any plans to support `adb tcpip`?
[10:15] <ogra_> the rebot commands are patched in though
[10:16] <ogra_> effectively we would indeed like to have the full featureset, cant promise it though, this stuff didnt even had a security review yet
[10:17] <Saviq> ogra_, yup, got it, thanks, will deal with USB only for now ;)
[10:17] <ogra_> rsalveti even talks sbout forking adb into "udb" so we can extend it in all directions
[10:17] <ogra_> cant you use ssh ?
[10:18] <Saviq> ogra_, yeah, that's fine, we're going ssh as soon as it's there on the device
[10:18] <Saviq> ogra_, so it's fine, I just used tcpip before, because that made sure the devices don't conflict (with forwards, for example)
[10:19] <ogra_> yeah, understood, open a wishlist bug against android-tools
[10:19] <Saviq> ogra_, but yeah, once the images are flipped by default, we'll be able to simplify our run_on_device script a lot
[10:19] <Saviq> ogra_, thanks
[10:20] <ogra_> well, that should happen today .... just waiting for feedback for the last device
[10:20] <Saviq> ogra_, nice
[10:20] <ogra_> (manta should work too now, but i dont have one so relying on others to test)
[10:28] <AskUbuntu> Development tool and language used for ubuntu mobile app | http://askubuntu.com/q/312064
[10:44] <Saviq> ogra_, what replaced "restart ubuntu-session"?
[10:45] <ogra_> ubuntu-touch-session replaced ubuntu-session
[10:47] <Saviq> ogra_, thanks
[11:14] <nik90> mehow: just sent you and lina an email with questions on the visual designs.
[11:23] <nik90> loicm: ping
[12:04] <om26er> Is there a way to get back to normal images after flashing with --flipped ?(from phablet-flash I mean)
[12:08] <ogra_> om26er, definitely buy using the manual method for flashing, i'm not sure but i would also expect pahblet-flash -b to DTRT
[12:08] <ogra_> (unflipped will vanish this week anyway though)
[12:08] <popey> good!
[12:09] <om26er> ogra_, the problem with manual flash is that the phone is in the lab. :/
[12:09] <ogra_> well, try -b then ... if it is re-boorstrapped from the ground up that should work
[12:11]  * om26er tries
[12:12] <ogra_> Saviq, i was wondering if we could have unity integrated with an  upstart-desktopfile-bridge ...  so that the .desktop files could have hardware related criteria to be shown ...  (i.e. only show the phone app if there is a system ofonod running "show on started ofono" etc etc )
[12:13] <Saviq> ogra_, yeah, that's more of a application-scope integration, but we could think of something
[12:13] <Saviq> ogra_, but then people might get confused why their app doesn't show up
[12:14] <ogra_> well, i wouldnt want to see the phone app on i.e. a tablet without 3g
[12:14] <ogra_> i'm not sure if the HW differences are big enough among devices to justify such a thing at all, its just an idea that struck me :)
[12:34] <ogra_> mdeslaur, jdstrand ... is there antthing we could do to make apparmor not max out the CPU on boot http://people.canonical.com/~ogra/ubuntu-touch/bootchart-maguro.png ?
[12:34] <mdeslaur> ogra_: is that first boot only, or subsequent boots also?
[12:35] <mdeslaur> ogra_: on first boot, it needs to compile policies
[12:35] <ogra_> thats just a notmal boot
[12:35] <ogra_> *normal even
[12:35] <jdstrand> so, to be clear-- 2nd boot does that too?
[12:35] <ogra_> yes
[12:35] <jdstrand> if so, then it sounds like there is a problem with the cache not being generated correctly
[12:35] <jdstrand> (or not used, etc)
[12:35] <ogra_> its the 50th boot or so since the image was installed .... its a bit tricky to get bootchart going on first boot :)
[12:37] <jdstrand> ogra_: do we have boot charts for mako?
[12:37] <jdstrand> (or grouper)
[12:37] <ogra_> note that this is maguro ... (OMAP4) which is not gifted with a big L2 cache ... and only two cores
[12:37] <ogra_> i can make one for grouper later today ... dont have a mako for ubuntu stuff
[12:37] <jdstrand> that should only affect the 1st boot. after that, it should be using the binary cache
[12:37] <ogra_> where does that live on disk ?
[12:38] <jdstrand> /etc/apaprmor.d/cache
[12:38] <ogra_> moght be a filesystem issue
[12:38] <ogra_> root@ubuntu-phablet:/# ls -l /etc/apparmor.d/cache/
[12:38] <ogra_> total 0
[12:38] <ogra_> aha
[12:39] <jdstrand> ogra_: is the filesystem readonly?
[12:39] <ogra_> nope
[12:39] <ogra_> but its a loop of mounts
[12:39] <ogra_> the rootfs lives in a subdir of the partition ...
[12:39] <morphis> rsalveti: ping
[12:40] <ogra_> so we mount the partition, do a bind mount to /root of the subdir, then pivot that to / *and* mount the partition again under /data
[12:40] <ogra_> (very messy and just an interim)
[12:40] <ogra_> the partition is always RW from the bindmount that happens inside the initrd thoguh
[12:41] <jdstrand> ogra_: fyi, here is how it all works: https://lists.ubuntu.com/archives/upstart-devel/2011-December/001771.html
[12:41] <popey> ogra_: is there a way to trigger the creation of the bootchart png? my mako only has a tgz in /var/log/bootchart
[12:42] <ogra_> popey, i adb pull it and then run: pybootchartgui --crop-after=unity8 bootchart.tgz on my PC
[12:42] <jdstrand> ogra_: you don't have to read the whole email. Just read to '== Considerations ==' and you should have enough infor to know the various things that happens with apparmor in early boot
[12:42] <popey> ok, ta
[12:44] <jdstrand> (though you certainly could read the whole email)
[12:44] <popey> jdstrand: http://popey.com/~alan/ubuntu-phablet-saucy-20130624-1.png a mako bootchart
[12:45] <jdstrand> yeah, that is what it should look like
[12:45] <jdstrand> the cache is clearly being used there (teeny sliver for apparmor_parser)
[12:45] <jdstrand> popey: is that for a flipped image?
[12:46] <popey> yes jdstrand, flashed today from yesterdays image
[12:46] <popey> and added some packages, but not much, just not a vanilla flashed device
[12:46] <ogra_> yeah, if you see lxc at the top it is flipped :)
[12:46] <popey> just flashing grouper now, will bootchart that too
[12:47]  * jdstrand flashes his mako and makes sure everything is running correctly there
[12:47] <ogra_> well, seems mako is fine then
[12:47] <ogra_> i wonder if maguro misses a kernel option or so
[12:48] <ogra_> given that all our touch devices have different kernel versions
[12:48] <popey> hmm, still having to run adb root under sudo for my grouper
[12:48] <popey> not a massive issue
[12:48] <ogra_> on the PC you men
[12:49] <ogra_> *mean ?
[12:49] <jdstrand> argh,my mako is 'dead'
[12:49] <ogra_> discharged ...
[12:49] <jdstrand> is there still the issue with it running out of power?
[12:49] <jdstrand> I plug it in and the led is flashing orange
[12:49] <ogra_> put it on the wallplug for 20min or so
[12:50] <jdstrand> ok, cool. I thought I read something about disconnecting the battery
[12:50] <ogra_> android has a function for preventing a boot in the initrd if you are on the charger ... we dont have that yet since we have to wat to actually tell the user we are charging and not moving  on with the boot
[12:50] <ogra_> (no framebuffer access in initrd)
[12:51] <popey> ogra_: yes, on my pc
[12:52] <ogra_> ah, good ... phew :)
[12:52] <popey> heh
[12:54] <ogra_> oh, that reminds me ...
[12:54]  * ogra_ adds a respawn to the adbd upstart job 
[12:54] <ogra_> meant to do that last week already ... kind of forgot about it
[13:10] <ogra_> tedg, .see http://people.canonical.com/~ogra/ubuntu-touch/bootchart-maguro.png and http://popey.com/~alan/ubuntu-phablet-saucy-20130624-1.png ... is there anything we could do to not have the hud-service stall the boot for 10sec ?
[13:11] <ogra_> (i assume everything changes once we run Mir and lightdm but that heavy delay looks still odd)
[13:11] <tedg> ogra_, Migrate to upstart user session for one :-)
[13:12] <ogra_> after the Mir/lightdm switch
[13:12] <tedg> ogra_, But probably we need to get unity8 to not start it right away, and only on use.  It shutsdown when not in use.
[13:12] <tedg> ogra_, That's been on tsdgeos' todo list for a bit, but never gotten out of the "someday" list.
[13:13] <seb128> well, we have an issue if hud uses more cpu than the rest of our desktop combined
[13:13] <ogra_> well, if it takes 10sec to come up on demand too, that wont make it widely used i guess :)
[13:13] <seb128> which seems to be the case
[13:13] <tedg> seb128, It's a Texas sized process ;-)
[13:13] <tedg> seb128, It's initing the voice recognition engine.
[13:13] <seb128> it's likely the pocketsphinx stuff
[13:14] <tedg> We can make that lazier.  Right now it just waits 1 second after the first query is created.
[13:14] <tedg> But, really, the best fix is to switch to upstart and don't create the query on init.
[13:14]  * ogra_ would like to see us getting down to a 20sec boot on maguro and 15 on mako in the end 
[13:15] <ogra_> yeah, i guess we can do that when redesigning the user session
[13:15] <ogra_> but that kind of requires lightdm etc
[13:15] <seb128> tedg, well, upstart will not fix the fact it takes 10 seconds to start
[13:15] <tedg> Yup, I think we have too many transitions planned at this point to do that kind of optimization today.
[13:15] <tedg> seb128, Sure, but it'll make it so that it doesn't block the startup
[13:16] <seb128> right
[13:16] <seb128> it will just take 10s to show on first use
[13:16] <seb128> which is an issue as well...
[13:16] <tedg> Yeah, which is what we're playing with here.
[13:17] <tedg> We might need to (not today) try to init that in a thread or something so we remain responsive.
[13:17] <ogra_> cant we decouple the voice engin a bit ?
[13:17] <ogra_> right ...
[13:20] <tedg> ogra_, When we have upstart user session enabled can we use ureadahead for both the system and user session?
[13:20] <tedg> Looks like we're not really nailing the disk the way I'd expect.
[13:20] <tedg> Or I guess that might be the HUD just blocking everything.
[13:20] <popey> ogra_: http://people.canonical.com/~alan/bootcharts/grouper/ubuntu-phablet-saucy-20130624-1.png  a grouper one fwiw
[13:21] <ogra_> not sure ureadahead works so great on MMC
[13:21] <ogra_> popey, wow, 10sec in initrd ... thats a lot
[13:22] <tedg> ogra_, Oh, why?  What's the different about MMC?
[13:23] <ogra_> jdstrand, so seeing that only maguro exposes the weird apparmor behavior i'll do a fresh install ... if it still exposes that behavior i'll blame the kernel
[13:23] <ogra_> tedg, its an SD card ... not an SSD :)
[13:24] <tedg> ogra_, Heh, sure.  It's like drinking an ocean with a straw.  But that's where I thought it'd be more similar to an HDD.
[13:25] <ogra_> tedg, and we will switch to loop mounted images from this
[13:25] <ogra_> not sure that will work either
[13:26] <ogra_> i currently see ureadahead die on all my boots ... which i blame the bind mounted / for (we dont have a real device here)
[13:27] <tedg> Hmm, interesting.  We should perhaps harass the foundations guys about that.  But, when there's a more stable foundation.  Need to get through all these transitions.
[13:28] <ogra_> yeah, well, we will always support loop mounted images ... thats kind of essential for devices we cant re-partition (90% out there i'd say)
[13:28] <ogra_> not sure ureadahead can handle that at all
[13:31] <ogra_> oha !
[13:31] <ogra_> rtg_, root@ubuntu-phablet:/# ls /sys/kernel/debug/tracing/events/fs/do_sys_open
[13:31] <ogra_> ls: cannot access /sys/kernel/debug/tracing/events/fs/do_sys_open: No such file or directory
[13:31] <ogra_> rtg_, can we have the needed options in maguro to make ureadahead work ?
[13:31] <rtg_> ogra_, do you have debugfs mounted ?
[13:32] <ogra_> yes, the container is sopposed to do that
[13:32] <rtg_> this is mount ? 'none on /sys/kernel/debug type debugfs (rw)'
[13:32] <rtg_> this is*in* mount ?
[13:33] <ogra_> yep
[13:33] <ogra_> and i see content
[13:33] <rtg_> ogra_, ok, start a bug and assign me to it. I've got some other stuff to deal with this morning
[13:34] <ogra_> seems just the fs subdir is missing in tracing/events/
[13:36] <davmor2> yay who ever added all apps to the apps lens I love you :)
[13:36] <rtg_> ogra_, yes, I'm sure its something simple, though I seem to remember a patch for correct functioning of ureadahead.
[13:38] <ogra_> rtg_, bug 1194127
[13:39] <rtg_> ogra_, k, I'll get to it this afternoon.
[13:39] <rtg_> ogdo you think other Nexus platforms are affected ?
[13:39] <ogra_> no hurry ... nobody noticed it until now ... wont hurt if it takes longer :)
[13:39] <rtg_> ogra_, ^
[13:39] <ogra_> not sure
[13:39] <rtg_> ok
[13:39] <ogra_> i only have grouper here
[13:39] <ogra_> i can check that too though
[13:39] <ogra_> one sec
[13:40] <ogra_> root@ubuntu-phablet:/# ls /sys/kernel/debug/tracing/events/fs/do_sys_open
[13:40] <ogra_> enable  filter  format  id
[13:40] <ogra_> rtg_, grouper seems fine
[13:40] <rtg_> ack
[13:40] <ogra_> others have to check on mako and manta
[13:40] <rtg_> I have those
[13:41] <ogra_> k
[13:46] <mhall119> rsalveti: do those latest audio HAL patches get sound working on grouper?
[13:50] <troete> is there a way to disable the pin of the sim from ubuntu touch, without reinstalling android?
[13:51] <ogra_> nope, there is no code to handle the PIN at all yet
[13:52] <troete> thnx :)
[13:56] <diwic> mhall119, no
[13:56] <diwic> mhall119, they are for me to have something to work with
[13:58] <ogra_> diwic, btw, i diverted the ucm profiles from the lxc-android-config package now, if you need them back feel free to remove that
[13:59] <ogra_> it seems to help on maguro ... not on grouper though
[14:00] <diwic> ogra_, actually it lights another problem - what happens if two machines with the same SoC has different audio configurations
[14:00] <diwic> ogra_, how can we ship that on the same image
[14:01] <diwic> ogra_, in this case panda and galaxy nexus
[14:01] <diwic> ogra_, could just as well have been two mobile phones
[14:01] <ogra_> have an alsa-android-ucm package that conflicts/breaks an alsa-ucm package ?
[14:02] <diwic> ogra_, sure, for *this* case. But what if there are two mobile phones both running Ubuntu Touch, but one of them has a more powerful speaker (e g) and therefore the UCM configs need to be different?
[14:03] <ogra_> then we need a specific udev rule to cover that i would say
[14:04] <diwic> ogra_, I wonder if we can steer UCM config file in udev rules...not sure about that
[14:04] <ogra_> i guess we can find a way :)
[14:05] <diwic> I guess so
[14:05] <ogra_> on the touzch images with android container we actually know exactly which device we are on
[14:06] <diwic> maybe the kernels are different anyway so
[14:09] <ogra_> diwic, grep ^ro.product.device= /system/build.prop |sed -e 's/.*=//'
[14:09] <ogra_> diwic, we should have the ability to couple an udev rule to that
[14:09] <diwic> ogra_, sure
[14:10] <diwic> ogra_, just a matter of patching UCM to take the udev rule into account
[14:10] <ogra_> that file is guaranteed to be available and have the android build name (unique device name)
[14:10] <ogra_> well we could just have ucm subdirs per android name
[14:11] <ogra_> that way we shouldnt need specific rules, just make ucm match the name
[14:15] <rsalveti> morphis: pong
[14:17] <rsalveti> mhall119: not yet, that's more to help our future development
[14:20] <ogra_> rsalveti, did you get a chance to test manta yet ?
[14:20] <sergiusens> ogra_: what do you need tested?
[14:21] <ogra_> flipped should boot to the UI (hopefully)
[14:21] <rsalveti> hm, 20130624 about to be published
[14:21] <ogra_> yeah
[14:21] <rsalveti> ogra_: trying to flash, but phablet-tools is trying to get 20130624
[14:21] <rsalveti> guess I need to wait for a few minutes still
[14:21]  * smartboyhw starts writing a new app.
[14:21] <ogra_> well, i see it
[14:23] <pmcgowan> why do I see 0623?
[14:23] <pmcgowan> are you guys getting from the vpn?
[14:24] <ogra_> no, from cdimage directly
[14:24] <ogra_> http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/ has 23 and 24 for me
[14:24] <rsalveti> ogra_: yeah, downloading
[14:26] <ogra_> awe, so with my latest changes to lxc-android-config and your ofono retry logic i dont see any races anymore on maguro :)
[14:27] <ChickenCutlass> ogra_, nice!
[14:28] <rsalveti> diwic: so we already need to do something smarter in udev and such to retrieve the android device name, once that's in place, we could indeed load the android name specific ucm rules
[14:28] <awe> ogra_, hmmm...  I didn't land any retry logic for the socket code
[14:28] <rsalveti> as soc and proc/cpuinfo is not safe in our case
[14:28] <awe> I actually was working on this Fri afternoon and trying to get upstart to handle it...
[14:28] <ogra_> awe, hmm, whats that last changelog entry in ofono then ?
[14:28] <awe> changes to the SIM_STATUS code
[14:28] <rsalveti> ogra_: that's for a sim card race
[14:28] <ogra_> funny, since it seems to fix the race too
[14:29] <ogra_> i see it reconnecting
[14:29] <awe> ogra_, as of Fri, it was still broken....and I was attempting to fix it by exiting when a socket failure occurred
[14:29] <rsalveti> diwic: let me know if you have any issue when using the audio hal, you might need to temporarily disable audioflinger as well
[14:29] <awe> and thus letting upstart handle it
[14:29] <ogra_> oh, ok
[14:29] <awe> but that only seemed to work twice...
[14:29] <rsalveti> that can be done by changing the android init.rc code that lxc loads
[14:29] <awe> so I was actually working on verifying whether or not upstart respawn was working correctly
[14:29] <ogra_> we cant really let upstart respawn the job ... since we want it to exit on devices that have no rild
[14:30] <diwic> rsalveti, right, I've been busy with HWE tasks today for the most part. I'm sure I'll need to disable audioflinger at some point, so how do I do that?
[14:30] <awe> ogra_, on devices with no RILD, the plugin shouldn't power on the modem
[14:30] <ogra_> awe, but ofonod would endlessly respawn and there is no need to have it running at all
[14:31] <awe> ogra_, we shouldn't be using the RILD socket for device configuration
[14:31] <awe> that's brain dead
[14:31] <ogra_> how else would you do it ?
[14:32] <sergiusens> with the properties?
[14:32] <awe> ;)
[14:32] <ogra_> unless someone writes an upstart-container-bridge we will never know if rild is done starting
[14:32] <rsalveti> diwic: check /var/lib/lxc/android, you could change pre-start.sh or just replace the init.rc via the overrides folder
[14:32] <ogra_> properties only tell you it is started
[14:32] <ogra_> i can have the same with a pgrep
[14:32] <awe> two separate problems
[14:33] <rsalveti> copy the original one and remove the media server related line
[14:33] <sergiusens> if it doesn't have one, we could add it
[14:33] <awe> theoretically, we should be able to use an upstart respawn limit
[14:33] <rsalveti> actually, let me see how that is started
[14:33] <rsalveti> yeah, part of the mediaserver
[14:33] <ogra_> sergiusens, the point is that we need to know the app is done starting ... we cant easily do that in the container
[14:33] <awe> so the ofono RILD code exits on any kind of socket error
[14:34] <awe> and if it happens too many times in a short time period, upstart marks the job as failed...and game over
[14:34] <awe> however I couldn't get this to work
[14:34] <ogra_> sergiusens, what i think we should have is the ablve mentioned upstart bridge
[14:34] <awe> upstart seemed to give up after two tries
[14:34] <ogra_> so you can do: start on started container-app APP=rild
[14:35] <diwic> rsalveti, if mediaserver depends on audioflinger, is that a problem we need to solve, or can we just remove mediaserver too once PulseAudio is handling audio?
[14:35] <ogra_> which then only fires ofono if rild is really done with its init
[14:35] <awe> ogra_, did you change the condition that starts ofono?
[14:35] <awe> or is it still started on 'dbus' started?
[14:35] <ogra_> sweonly in the very latest upload about 1h ago, not in the archive yet
[14:36] <rsalveti> diwic: that might indeed need more work to just remove the audioflinger part, need to investigate that more
[14:36] <ogra_> what you have there is still "on dbus started" ... the new one also uses the file bridge to check for /dev/socket existing
[14:36] <rsalveti> but for now you can just disable mediaserver to have full control of the hardware
[14:36] <diwic> rsalveti, okay
[14:36] <ogra_> (in fact the creation of /dev/socket will now trigger ofonod)
[14:36] <awe> ogra_, is there an event fired when the lxc container is started?
[14:37] <ogra_> yes, the "android" event is emitted right after the linkage
[14:37] <ogra_> udev fires based on it
[14:37] <rsalveti> file bridge might work better
[14:37] <rsalveti> would be nice to give that a try
[14:37] <ogra_> rsalveti, thats what ofono now uses
[14:38] <awe> yea rsalveti, quit confusing us!  ;)-
[14:38] <ogra_> for udev it doesnt make sense
[14:38] <ogra_> (there doesnt need to be a /dev/socket to start udev, ofono needs it though, so i made the job fire on /dev/socket creation)
[14:38] <rsalveti> ogra_: oh, right, you already changed that :-)
[14:38] <awe> ogra_, we still need to figure out 3g data on mako
[14:39] <ogra_> rsalveti, in case we decide to go slangasek's route with ueventd to touch a file once it is done we can isneed make udev conditional for this
[14:39] <rsalveti> ogra_: right
[14:40] <ogra_> awe, please try the latest lxc-android-config package for this, the former versions didnt really take subdirs in /dev/socket into account
[14:40] <awe> ogra_, that seems overly complicated to me
[14:40] <awe> ogra_, can I just test today's image, or is it missing pieces?
[14:40] <ogra_> awe, either an upstart bridge into the container or more easily have a stamp file to act on ...
[14:40] <awe> ?
[14:41] <mfisch> ogra_: ping
[14:41] <ogra_> awe, the latest lxc-android/changes didnt make it in the image (4h turnaround time, i didnt want to wait) ... just apt-get install it
[14:41] <ogra_> awe, i thought your "overly complicated" was for the ueventd comment above
[14:41] <awe> ack
[14:41] <ogra_> mfisch, i'm here :)
[14:42] <ogra_> awe, udev cant start if ueventd isnt 100% done ... we need a way to know about this
[14:42] <awe> ogra_, I'll try and re-test data before the stand-up...  if it still fails, we'll need some help from cyphermox
[14:42] <mfisch> hey ogra_ have you run valgrind on arm before? wondering if there's something problematic about arm's ability to rebuild a backtrace
[14:42] <ogra_> awe, well, if it did work with the same NM on unflipped i still would rather blame us/me than NM :)
[14:42] <awe> ogra_, you mean if ueventd is finished processing all the devices... AFAIK, we're not killing ueventd, right?
[14:43] <ogra_> mfisch, not a big valgrind user here, but i know seb128 used it on arm a lot
[14:43] <mfisch> ogra_: okay, I'll ask him
[14:43] <awe> ogra_, yes I still blame the flip, but after my latest analysis, I'm not sure why it's broken... that's why we need cyphermox's help
[14:44] <ogra_> right, well, i think we still might be missing bits and pieces ... the /dev/socket/ subdirs are definitely a bad oversight
[14:45] <ogra_> and while we now have proper per device udev rules i'm not sure all users and groups they would like to use are in the system
[14:46] <mfisch> seb128: you still around?
[14:46] <seb128> mfisch, yes
[14:46] <mfisch> seb128: my stack traces on the phone in valgrind seem to stop really short
[14:46] <mfisch> seb128: short of my code, which would be useful anyway
[14:47] <mfisch> seb128: sforshee said that ARM may not have enough info to recreate a full backtrace by default?
[14:47] <ogra_> we might be missing kernel options ... note that we mostly use the android defconfig with only a few small changes
[14:48] <mfisch> most of my stacks were like 2 lines
[14:48] <mfisch> g_something and then g_malloc above g_somethning should have been my code
[14:48] <seb128> mfisch, valgrind should (mostly) work fine on arm ... do you have debug symbols for your binaries? (like unstripped binaries or -dbg installed)?
[14:48] <sforshee> this is because EABI doesn't include frame pointers
[14:48] <mfisch> I did install unstripped bianries
[14:48] <sforshee> so you have to have unwind tables to produce stack traces
[14:48] <mfisch> usually valgrind will at least just say ???? foo.o
[14:48] <sforshee> which means you need the dwarf data, i.e. debug builds
[14:48] <mfisch> it didnt even give me that
[14:49] <sforshee> there is some gcc option to make it include frame pointers, but all libraries would have to be rebuilt to use this option
[14:51] <mfisch> sforshee: maybe just having it in powerd will be enough
[14:52] <sforshee> mfisch: it won't, because most of the allocations are actually occurring in glib
[14:52] <mfisch> sforshee: but the glib stack portion looked good, or are you saying that's where we lost the frame pointer
[14:54] <sforshee> mfisch: without unwind tables it can generate exactly two frames of a backtrace: the current function and the caller
[14:54] <sforshee> beyond that you need unwind tables
[14:55] <mfisch> sforshee: that explains why I had 2 calls then
[14:55] <sforshee> mfisch: the current function knows how to unwind it's own stack and get back to the caller, otherwise it couldn't return
[14:55] <mfisch> okay so I was at the very top of the stack and stuck there, makes sense
[14:57] <sforshee> yep
[14:57] <didrocks> sergiusens: hey, I'm probably doing it wrong, but phablet-flash --flipped -d mako doesn't restart my device for flashing with latest
[14:57] <didrocks> Restarting device... wait
[14:57] <didrocks> Not enough space in /data, found 1.1G, rebooting
[14:58] <didrocks> (/data actually has only 1.1G used, not free)
[14:58] <didrocks> /dev/mmcblk0p23   13G  1.1G   12G   9% /data
[15:00] <troete> is there a way to run new applications on the device with one click in qt creator?
[15:03] <pmcgowan> didrocks, sergiusens I am seeing something similar
[15:04] <pmcgowan> sergiusens, ogra_ how do I check the version of the installed flip image?
[15:04] <didrocks> pmcgowan: did you install the first version by hand or with phablet-tools?
[15:04] <pmcgowan> didrocks, with tool
[15:04] <sergiusens> pmcgowan: no versioning yet
[15:04] <didrocks> ok, I did it by hand, so not that :)
[15:04] <sergiusens> I'm just used the tools today to flash
[15:05] <pmcgowan> sergiusens, how can I tell if it actually flash even thought flash said not enough space?
[15:05] <ogra_> pmcgowan, i'll dump something in that uses the general ubuntu way
[15:05] <didrocks> pmcgowan: it didn't here, failed after 20s, and didn't reboot the device
[15:05] <sergiusens> pmcgowan: by looking at /cache/recovery/last_log
[15:07] <pmcgowan> sergiusens, where is that file?
[15:07] <didrocks> same, I don't have any /cache, nor /data/cache
[15:07] <didrocks> (and no /var/cache/recovery)
[15:08] <sergiusens> pmcgowan: didrocks oh, yeah, flipped... you nned to go back to recovery
[15:09] <pmcgowan> sergiusens, if I get that message does it mean it did not flash?
[15:09] <sergiusens> pmcgowan: let me double check, but yes, it's most likely not flashed
[15:10] <pmcgowan> sergiusens, and cannot see /sdcard now, is that part of the changes?
[15:10] <popey> pmcgowan: i have no /sdcard on a working flipped phone
[15:11] <sergiusens> pmcgowan: nothing you use to see on android is there
[15:11] <sergiusens> pmcgowan: it's more of an ubuntu like hierierarchy
[15:12] <pmcgowan> sergiusens, where are the tgz files now?
[15:12] <didrocks> sergiusens: works way better in recovery mode, thanks! :)
[15:12] <pmcgowan> didrocks, what does?
[15:12] <sergiusens> pmcgowan: which ones exactly?
[15:12] <pmcgowan> sergiusens, I used to delete them to clear space
[15:13] <pmcgowan> the images
[15:13] <didrocks> pmcgowan: flashing, the OS is rebooting from recovery to recovery, and then, it starts pushing the images
[15:13] <didrocks> (and no more this "1GB: not enough space" which is a side-effect I guess)
[15:13] <sergiusens> pmcgowan: oh, in what used to be /sdcard ?
[15:14] <sergiusens> didrocks: yeah, just to support the same model for flipped and unflipped
[15:14] <didrocks> right :)
[15:14] <popey> sergiusens: the zip file used to be left lying around frequently, so you couldn't flash phone till they're deleted
[15:14] <pmcgowan> sergiusens, yes, to put it another way, what should I do to get the latest installed now?
[15:14] <sergiusens> didrocks: there is no adb push/pull or /sdcard in flipped images
[15:14] <popey> pmcgowan: I use this command to find out what's eating space on the phone so i can delete stuff to make space... du -xB M --max-depth=2 / | sort -rn | head -n 15
[15:15] <sergiusens> pmcgowan: are you moving from flipped to flipped, right?
[15:15] <didrocks> sergiusens: we still push the .zip in /sdcard, right?
[15:15] <pmcgowan> sergiusens, no, I have flipped installed and trying to get an updated version
[15:15] <sergiusens> didrocks: yes we do
[15:15] <didrocks> sergiusens: not sure what the diff with this and adb push/pull then TBH :)
[15:16] <sergiusens> pmcgowan: I'm curious into why you always need to delete stuff, I never fall into that problem
[15:16] <ogra_> adb push/pull works exactly the same on flipped/unflipped
[15:16] <pmcgowan> sergiusens, I have the 8GB model?
[15:16] <pmcgowan> nexus 4
[15:16] <popey> sergiusens: i have it often enough to script removing the zip files before/after flashing (8GB Nexus 4 too)
[15:16] <ogra_> (there are other adb bits that dont, but that one definitely does)
[15:17] <didrocks> ogra_: ah, so I'm not that lost ;)
[15:17] <sergiusens> pmcgowan: oh, ack... I don't have that device, then again my /data is only 2.2G used up
[15:17] <popey> /dev/mmcblk0p23  5.7G  2.2G  3.6G  38% /
[15:17] <ogra_> adb logcat is different in flipped and some other builtin things too ....
[15:18] <pmcgowan> popey, so where are those now?
[15:19] <popey> pmcgowan: i haven't updated it for flipped image yet
[15:19] <popey> at the moment I manually do the rm
[15:19] <popey> pmcgowan: /data/media is where you'll find them
[15:19] <popey> root@ubuntu-phablet:/# du -hs /data/media
[15:19] <popey> 777M	/data/media
[15:24] <sergiusens> ogra_: rsalveti what about rotation not working? is that a flipped issue?
[15:24] <ogra_> i think thats a unity8 issue
[15:25] <ogra_> i heard about it before from people that didnt use flipped
[15:25] <pmcgowan> rotation not working in apps was the issue last week
[15:25] <sergiusens> ogra_: yeah, it worked with the image I took with me while on holidays
[15:25] <pmcgowan> not a unity thing
[15:25] <sergiusens> but today's is broken
[15:25] <pmcgowan> probably platform-api
[15:25] <ogra_> pmcgowan, but was broken unflipped, right ?
[15:25] <pmcgowan> correct
[15:25] <ogra_> good :)
[15:25] <ogra_> well ...
[15:26] <pmcgowan> popey, thanks updated my clean script
[15:26] <ogra_> good for me :P
[15:26] <pmcgowan> its all about ogra_
[15:26] <ogra_> LOL
[15:26] <pmcgowan> popey, with the rename I had double copies as well
[15:28] <popey> oof
[15:28] <FunkyPenguin> is http://paste.opensuse.org/72500799 an expected issue with the latest daily image?
[15:28] <FunkyPenguin> is there a way to resolve the missing icons?
[15:28] <ogra_> it is known at least
[15:28] <popey> yeah, i have it too
[15:29] <ogra_> (by the right people even, so just wait for an update that brings in the fix)
[15:29] <FunkyPenguin> ok, at least i know it isnt down to my incompetence (this time) thanks
[15:29] <popey> thanks to that image I have only just noticed the road names on that map icon
[15:30] <FunkyPenguin> lulz, i never noticed that - nice touch
[15:30] <FunkyPenguin> badoom tish!
[15:43] <rsalveti> FunkyPenguin: missing icons should be fixed later today
[15:44] <FunkyPenguin> rsalveti: muchas grassy arse
[15:45] <jasonhuie> Hi guys, I just tried installing Ubuntu Touch on a Nexus 7 and I'm having some problems with booting.  Is anyone available to help?
[15:47] <awe> ogra_, was your ofono .override part of the ofono package?  If so, then it wasn't in place during my testing as I was always installing a newer version of ofono
[15:47] <ogra_> awe, lxc-android-config contains all container related hacks
[15:48] <awe> ok
[16:04] <morphis> rsalveti: I saw there are a lot of additional changes to the libhybris branch for ubuntu
[16:04] <morphis> is that intended?
[16:05] <rsalveti> morphis: yup, most to unblock some of the work we're doing, but should all be sent upstream later this week
[16:06] <morphis> rsalveti: ok
[16:12] <deus_> is it possible to install native ubuntu 13.10 on a chinese tablet (copy of GoClever 103A)?
[16:12] <mfisch> cking since you and sforshee are here
[16:12] <mfisch> cking: any ideas on the exit events?
[16:13] <cking> cking, what do you mean? I need some context to that question
[16:13] <cking> mfisch, ^
[16:13] <mfisch> cking: ah, my email from Friday about the netlink stuff
[16:15] <cking> mfisch, ah, didn't see that one. let me think a sec, which device are you running it on?
[16:15] <mfisch> cking: nexus4
[16:15] <mfisch> cking: I was getting exec and fork events
[16:16] <mfisch> but as sforshee pointed out, I should try my simpler whodied.c code on the phone too
[16:16] <ogra_> deus_, see the porting guide from the channel topic
[16:16] <ogra_> you would have to port it
[16:17] <deus_> tnx
[16:17] <cking> mfisch, let me try it on the Nexus 4..
[16:18] <cking> mfisch, powerstat works with for/exec/exits on my N4
[16:18] <mfisch> cking: okay, let me try my simplified version
[16:18] <cking> but I'm not using filtering
[16:20] <sforshee> root@ubuntu-phablet:/# ./whodied
[16:20] <sforshee> Socket failed: Protocol not supported
[16:20] <sforshee> mfisch, cking: ^
[16:20] <sforshee> running on my n4
[16:20] <mfisch> sforshee: it worked for me, I even have exit events
[16:20] <cking> run with sudo?
[16:21] <sforshee> mfisch: oh wait, I was running it on the galaxy nexus
[16:21] <sforshee> cking: I was root, that should be good enough, no?
[16:21] <cking> sforshee, should be
[16:21] <mfisch> sforshee: it did work on n4
[16:21] <mfisch> but if it doesn't on other devices thats an issue
[16:22] <sforshee> well it could be differing kernel configurations I suppose
[16:22] <mfisch> for sure
[16:22] <mfisch> cking: okay, so whodied works, but the powerd integrated version does not
[16:22] <mfisch> ah crap
[16:23] <mfisch> cking: NEVERMIND
[16:23] <mfisch> cking: silly mistake here
[16:24] <cking> mfisch, no probs, glad we could factor it out so quickly
[16:24] <mfisch> cking: g_debug vs printf was my issue
[16:24] <mfisch> sforshee: I guess on those devices that don't support it, we'll just live without it?
[16:25] <morphis> awe: ping
[16:25] <sforshee> mfisch: we'll just need to figure out why it isn't working and fix it
[16:25] <mfisch> sforshee: can I send you the kernel config for this device?
[16:25] <mfisch> sfeole: CONFIG_NETFILTER_NETLINK=y and friends need to be on
[16:26] <sforshee> mfisch: assuming you haven't built your own kernel I can easily get the config myself
[16:26] <mfisch> sforshee: no its stock
[16:26] <sforshee> mfisch: my n4 is dead so after it's charged a bit I'll compare my results there
[16:26] <mfisch> ok
[16:26] <mfisch> sforshee: I'll pick this up again wednesday probably when we have our code freeze
[16:26] <awe> morphis, pong
[16:27] <morphis> awe: I have something you might be helpful with
[16:27] <awe> yes?
[16:27] <morphis> awe: https://bazaar.launchpad.net/~morphis/phablet-extras/ofono-lp1089431/revision/42 and look at line 295
[16:28] <morphis> you saw something like this before?
[16:29] <morphis> afaik parcel_init is reseting the parcel so it's data is set to NULL
[16:29] <morphis> so it should be safe to be reused
[16:32] <awe> morphis, just to be clear... you added the "FIXME" comment, and you're asking whether I've seen a similar double-free corruption?
[16:32] <morphis> yes
[16:33] <awe> morphis, I haven't seen this before...
[16:33] <morphis> hm
[16:35] <awe> that said, one thing you missed is that removing "request" from that function breaks the tracing
[16:36] <awe> line 293 still uses request, but you removed it's declaration, and replaced it with a constant in the g_ril_send
[16:37] <morphis> ah yes
[16:46] <mhall119> is saucy-23 using a flipped container?
[16:46] <mhall119> for grouper
[16:46] <mhall119> it says it's pushing the second .zip, but I'm at the ubuntu logo'd recovery console, which usually doesn't happen
[16:47] <popey> mhall119: I use "phablet-flash -d grouper --flipped"
[16:47] <popey> which gives me flipped one
[16:47] <mhall119> I wasn't specifically trying to get the flipped image
[16:47] <mhall119> just wondering why I was dropped into the recovery screen
[16:49] <mhall119> well, it rebooted, here we go
[16:49] <popey> i get that with phablet-flash now, but I only specify flipped
[16:52] <jdstrand> ogra_: fyi, I have files in /etc/apparmor.d/cache on mako (JENKINS_BUILD=saucy-23)
[16:53] <jdstrand> (--flipped)
[16:53] <morphis> awe: hm, ok found a workaround
[16:54] <morphis> awe: somehow it can be faulty to reuse the parcel after you already initialized it
[16:54] <morphis> if I use a different parcecl struct it works fine
[16:54] <awe> hmmm, I'm pretty sure we do this in other places...
[16:55] <morphis> awe: it was done this way before I touch the code too
[16:55] <morphis> but I just added another event registration at gril which is calling the same callback method and then it occured
[16:56] <awe> does your branch have the workaround yet?   If not, let me grab your branch and take a look
[16:56] <awe> was working on another bug...
[16:57] <morphis> awe: I will push it in some minutes
[16:57] <awe> the workaround?
[16:58] <awe> hold off... I'd like to see if I can figure out what's causing the problem with your original change
[16:58] <awe> I'd like to avoid a workaround until we understand the failure
[17:00] <awe> cyphermox, can you please check out https://bugs.launchpad.net/touch-preview-images/+bug/1193161?
[17:00] <morphis> awe: it's simple to reconstruct
[17:00] <morphis> awe: sadly I pushed already
[17:00] <morphis> but I can give you the diff to revert
[17:00] <morphis> I suspect it's something within gril/
[17:00] <awe> morphis, that's easy enough for me to do locally
[17:00] <morphis> ok
[17:01] <morphis> awe: but not if I rewrote the branch history :)
[17:01] <awe> did you?
[17:01] <awe> cyphermox, the above bug is one of our last blockers to moving to flipped images.
[17:02] <morphis> awe: yes
[17:02] <cyphermox> awe: technically I'm off today, it's a national holiday
[17:02] <cyphermox> awe: it indeed looks to me like something funky in udev
[17:03] <awe> cyphermox, OK... it's kinda working now, so if you could look at this first thing tomorrow, be much appreciated
[17:03] <cyphermox> without these devices showing up, NM won't be able to apply the IP config to the device ofono tells it to
[17:03] <cyphermox> do the devices appear in ifconfig?
[17:04] <awe> cyphermox, only rmnet_usb0
[17:05] <awe> cyphermox, this all worked in the standard images, and NM ignored the devices until the 3g connection was activated
[17:05] <cyphermox> ok
[17:05] <cyphermox> yeah
[17:05] <cyphermox> so somehow it's not liking rmnet_usb0
[17:05] <awe> but now it's trying to configure them ahead of time
[17:05] <awe> because it thinks they're ethernet devices
[17:05] <cyphermox> it would have to be missing some kind of info, that would be in the debug logs
[17:06] <cyphermox> awe: I see
[17:06] <morphis> awe: https://code.launchpad.net/~morphis/junk/ofono-sms-fixes-broken
[17:07] <awe> morphis, OK thanks!
[17:08] <awe> morphis, by the way, did you ever manage to reproduce https://bugs.launchpad.net/phone-app/+bug/1089431?
[17:08] <morphis> awe: my "workaround" is more or less moving the code into a new method called ril_ack_delivery
[17:08] <morphis> awe: not really, yet
[17:08] <awe> ok
[17:08] <awe> morphis, I'll look at your original code first...
[17:18] <morphis> awe: but the problem seems to be related to the UI and not to ofono itself
[17:20] <morphis> I manually set the error code to RIL_E_GENEIRC_FAILURE and ofono tries to  resend the message a number of times before it fails: http://paste.ubuntu.com/5796085/
[17:21] <awe> right... so it'd be good then to refute https://bugs.launchpad.net/phone-app/+bug/1089431/comments/3
[17:22] <awe> the original theory was that if a failure occurred in the send to RIL, that an error could be passed back to the UI
[17:22] <awe> it seems like that was an incorrect assumption
[17:22] <morphis> awe: and ofono is sending the correct signals: http://paste.ubuntu.com/5796090/
[17:22] <morphis> so the UI already has everything it needs
[17:23] <awe> ah, OK
[17:23] <awe> well then could you please add your analysis to the bug, and we can then re-assign to the phone-app guys>
[17:23] <awe> s/>//
[17:23] <morphis> will do :)
[17:23] <awe> thanks!
[17:26] <morphis> awe: who is the responsible for the phone-app?
[17:26] <awe> it seems like they also will have some future work to do in order to process delivery reports ( via a history plugin ).
[17:26] <morphis> yes
[17:27] <morphis> awe: I will propose https://code.launchpad.net/~morphis/phablet-extras/ofono-lp1089431 for merging
[17:28] <awe> morphis, boiko_ and tiagosh
[17:28] <awe> ( phone app )
[17:29] <awe> morphis, so it seems an app can't just register to receive sms reports, correct?
[17:29] <awe> it can only be done via a plugin which implements the history_driver?
[17:29] <morphis> I never really looked how the integration of the messagings works within the phon eapp
[17:29] <morphis> awe: but yes
[17:29] <morphis> status reports are only handled through the history plugin
[17:30] <awe> morphis, OK, seems like an odd design
[17:30] <awe> seems like we'd want to be able send a DBus signal for SMS reports too
[17:30] <awe> perhaps this is something we should discuss with upstream
[17:31] <awe> A history plugin still doesn't allow for us to communicate the report to the app..
[17:31] <awe> without inventing a new DBus interface/signal
[17:31] <morphis> yes
[17:36] <morphis> awe: can ask at upstream about this
[17:36] <awe> OK
[17:41] <morphis> awe: https://gitorious.org/meego-cellular/smshistory
[17:43] <awe> morphis, seems like an awful lot of code for something ofono should already be handling
[17:43] <awe> morphis, not sure that's anything we'd want to integrate
[17:43] <awe> but interesting from a historical perspective
[17:44] <morphis> yes
[17:44] <morphis> awe: http://wiki.meego.com/Commhistory
[17:57] <awe> sergiusens, ping
[17:59] <iBelieve> I'd like to get involved with developing the core applications, perhaps the File manager or Email program. Are either of these at a good point in terms of design to start contributing?
[18:00] <iBelieve> I'm mostly interested in implementing the UI, not the internal workings of the apps.
[18:04] <sergiusens> awe: pong
[18:04] <diwic> rsalveti, hmm, I'm testing your test_audio program, and it fails with segmentation fault in audio_hw_device_open on nexus 4
[18:05] <rsalveti> diwic: hm, as a user or as root?
[18:05] <diwic> rsalveti, as a user, let me test root too
[18:05] <rsalveti> wonder if it's conflicting with audioflinger
[18:05] <diwic> rsalveti, fails as root too
[18:05] <rsalveti> let me give it a try with nexus 4
[18:05] <rsalveti> diwic: have the logs?
[18:05] <diwic> rsalveti, where did you try it?
[18:06] <rsalveti> diwic: maguro
[18:06] <rsalveti> galaxy nexus
[18:06] <diwic> rsalveti, paste.canonical.com/93303
[18:06] <awe> sergiusens, having trouble with phablet-flash --flipped reporting not enough space in /data
[18:07] <awe> sergiusens, this is maguro, and it's already running flipped
[18:07] <awe> was trying to flash today's image
[18:07] <diwic> rsalveti, I added the "1" printf between get_hw_module and audio_hw_device_open
[18:07] <rsalveti> diwic: hm, will give it a try, might be missing the config files, as it might be trying to load them from /etc
[18:07] <rsalveti> mind running with strace to see which file it's trying to load?
[18:08] <diwic> rsalveti, ok, will do
[18:08] <rsalveti> meanwhile I'll flash my nexus 4
[18:09] <sergiusens> awe: what's the package version? I just flashed today's with no issue; what is the amount of free space you have?
[18:10] <pmcgowan> awe, I delete the zips from /data/media
[18:10] <bjar> ok so I flashed my galaxy nexus with ubuntu touch and I can't connect to the gsm net (swedish carrier)
[18:10] <dencho-nub> hey everyone!
[18:10] <bjar> am I screwed are there some kind of hack I can do?
[18:10] <diwic> rsalveti, heh, the last file it manages to open is /system/etc/snd_soc_msm/snd_soc_msm_2x_Fusion3, which is in UCM format
[18:10] <awe> sergiusens, 0.14daily13.06.15-0ubuntu1
[18:10] <awe> pmcgowan, ;)-
[18:10] <rsalveti> diwic: hm, interesting
[18:10] <awe> no zips to delete
[18:11] <dencho-nub> hey everyone!?
[18:11] <sergiusens> awe: how aboyt syslog?
[18:11] <awe> sergiusens, good point...
[18:11] <awe> Not enough space in /data, found 1.1G, rebooting
[18:12] <sergiusens> awe: that version seems old.... I'm on 0.14daily13.06.22-0ubuntu1
[18:12] <sergiusens> let me check the tools ppa
[18:13] <diwic> rsalveti, it tries to write some errors into /dev/alog/main, is that a file you know how to decipher?
[18:14] <rsalveti> diwic: yes, just run /system/bin/logcat
[18:14] <rsalveti> that should show you the android log messages
[18:15] <diwic> rsalveti, paste.canonical.com/93305
[18:16] <rsalveti> diwic: yeah, issue with the config file then, not sure why though
[18:16] <diwic> rsalveti, I guess I should try to figure it out
[18:16] <rsalveti> yeah
[18:20] <awe> sergiusens, looks like rsalveti uploaded new versions, however it's not built for raring yet...
[18:21] <rsalveti> awe: the new version has a different fix, not related with yours
[18:21] <rsalveti> but still, you need to clean up your /data
[18:21] <diwic> rsalveti, paste.canonical.com/93307 <- except for some libraries in the beginning, these are the files it fails to open. Worth doing something about?
[18:21] <rsalveti> awe: check your /data/media
[18:22] <rsalveti> hm, permission denied
[18:22] <awe> rsalveti, I did...and nothing obvious to delete
[18:23] <rsalveti> diwic: let me fix the permission errors in our build, can you check if it still fails after manually changing the permission?
[18:23] <diwic> rsalveti, hmm. Running as root and those EACCESS errors go away, but it still segfaults.
[18:23] <rsalveti> right
[18:24] <sergiusens> awe: is this mako?
[18:24] <rsalveti> let me give it a try, rebooting mine
[18:24] <awe> sergiusens, maguro
[18:25] <diwic> rsalveti, also, I'm not sure how much time we should spend on this audio HAL anyway - it would be cool if it worked but there might be easier ways forward perhaps
[18:25] <awe> what about swap?  it's huge
[18:25] <diwic> rsalveti, I mean, if we're going to run PulseAudio for the mixer and PCM streaming finally anyway
[18:25] <awe> sergiusens, I blew away all log files...and no diff
[18:26] <rsalveti> diwic: right, indeed
[18:27] <rsalveti> having support via hal might still be useful later, I can take a look at these hal related issues, while you check the work do be done in pulse itself (to control mixer and pcm)
[18:27] <sergiusens> awe: how about something like: find . -size +10M
[18:28] <awe> swap
[18:28] <diwic> rsalveti, I just need to figure out what mixer settings are needed in what scenarios, but maybe it's easier (at least at this point) to try to read that manually out of the UCM files or something
[18:28] <rsalveti> yeah, probably
[18:28] <sergiusens> awe: so I'm guessing you installed plenty of things post flash, right?
[18:28] <awe> no... not plenty
[18:29] <awe> sergiusens, is our swap file a fixed size, or can it grow?
[18:29] <awe> everything else >10M is std stuff in our image
[18:29] <awe> ( .mp4s, .so, ... )
[18:29] <awe> I maybe installed two or three other packages
[18:30] <awe> the only other tmp files that are kinda big are the pulse shm files
[18:30] <sergiusens> awe: what's you free and total space? (I'm just asking to figure out why I never stumble upon this issue)
[18:33] <awe> sergiusens, /dev/mmcblk0p12   14G  1.1G   13G   8% /data
[18:34] <sergiusens> awe: pmcgowan I know what your problem is
[18:34] <pmcgowan> thats quite a statement
[18:34] <sergiusens> awe: pmcgowan if you flashed before rsalveti fixed adb to reboot and where on a flipped image, it wouldn't reboot at all
[18:34] <awe> sergiusens, is it in the free_data[-1:]?
[18:35] <sergiusens> awe: the dh layout when in recovery is different
[18:35] <pmcgowan> sergiusens, I just deleted my zip files and I am fine
[18:35] <sergiusens> awe: df*
[18:35] <awe> pmcgowan, I have *no* zips
[18:35] <sergiusens> pmcgowan: oh, then I don't know yours, sorry
[18:35] <pmcgowan> but I have like 5.8GB total available
[18:35] <awe> I have 13G
[18:35] <awe> ;D
[18:36] <sergiusens> awe: do this, go into recovery manually and just run phablet-flash --flipped -d maguro whilst in recovery
[18:36] <rsalveti> sergiusens: maybe a custom recovery?
[18:36] <rsalveti> I know you changed the logic to probe the df output
[18:36] <rsalveti> as we're now doing all the logic from the recovery
[18:37] <sergiusens> rsalveti: yeah, I had flipped from last wednesday and ran into the problem of adb reboot doing nothing... with updated flips, it's all ok as adb is fine
[18:37] <rsalveti> sergiusens: right
[18:37] <sergiusens> another option is to apt-get update the ubuntu install and get the new adb
[18:41] <awe> sergiusens, looks like the validate_device is using the wrong column for free_data
[18:41] <awe> it thinks free_data is 1.1GB, which is actually "UseD"
[18:51] <awe> sergiusens, changing the line that calculates the free_data to use [0] [3] instead of [0] [2] solves the space issue, but now it fails trying to push to /sdcard/
[18:53] <sergiusens> awe: yeah, don't change that :-)
[18:53] <sergiusens> awe: df -h whilst in recovery lays out the columns differently
[18:54] <sergiusens> awe: does adb reboot recovery work for you?
[18:54] <awe> so do I need to be in recovery now to flash?
[18:54] <sergiusens> awe: or update adb inside ubuntu (the device, not your workstation)
[18:54] <sergiusens> awe: one time thing, adb (or udb) was broken last week
[18:55] <awe> sure, but I'm pretty sure I was running Friday's image... when did it get fixed?
[18:56] <awe> and no, adb reboot recovery didn't work.  Manually booting into recovery now
[18:56] <sergiusens> awe: rsalveti would know better but that explains your issues
[18:57] <rsalveti> guess it was fixed around friday
[18:58] <rsalveti> so yeah, issue then is that the reboot recovery failed for you
[19:00] <iBelieve> I'd like to get involved with developing the core applications, perhaps the File manager or Email program. Are either of these at a good point in terms of design to start contributing? I'm mostly interested in implementing the UI, not the backends of the apps.
[19:00] <popey> hi iBelieve
[19:00] <popey> iBelieve: the file manager app is mostly done, we haven't done a lot of work on the email client. where do your skills lie?
[19:01] <awe> rsalveti, sergiusens, OK... finally making some progress.  I have to head out an run an error, so bbl ( ~1hr )
[19:04] <iBelieve> popey, I've done some QML work before, having written a weather app with a UI in QML & KDE. I'd prefer to work on coding UIs, since I haven't done much backend-type work in QML, since I've used C++ for my internal backends.
[19:04] <popey> ok, great, just what we need ☻
[19:05] <popey> can you drop a mail to popey@ubuntu.com and mhall119@ubuntu.com and we can discuss further? (I'm just making my dinner ☻  )
[19:05] <iBelieve> popey, Sure, will do.
[19:06] <popey> thanks
[19:07] <mhall119> hey iBelieve
[19:08]  * mhall119 reads the backlog
[19:09] <iBelieve> Hi mhall119
[20:04] <sergiusens> cdesai: hey, all your patches are in
[20:57] <marianne> hi has anyone had any luck installing ubuntu on a samsung Galazy tab 2 (7.0)?
[20:57] <marianne> Galaxy*
[20:59] <sidnei> what is the gesture to pull up system settings? i did it accidentally twice, still trying to figure out how :)
[21:19] <tedg> mhr3, Hey, if you're around could you look at this?  https://code.launchpad.net/~ted/upstart-app-launch/zg-reporting/+merge/171173
[21:27] <sergiusens> rsalveti: https://code.launchpad.net/~sergiusens/phone-app/rebuild/+merge/171174
[21:27] <rsalveti> sergiusens: right, the issue with this package is related with changelog version bump
[21:28] <rsalveti> the usual one we had in the past
[21:28] <rsalveti> I wonder why this is not yet part of CI
[21:28] <rsalveti> boiko: kenvandine: any idea?
[21:28] <boiko> rsalveti: you mean the daily release?
[21:29] <sergiusens> rsalveti: it's because inidicator-messages
[21:29] <rsalveti> yeah
[21:29] <boiko> rsalveti: it was in the past, but then it was building against the wrong indicator-messages
[21:29] <rsalveti> right, wonder when that will be solved
[21:30] <rsalveti> sergiusens: why not temporarily making this a native package then?
[21:30] <sergiusens> rsalveti: not sure... ChickenCutlass who did you get to work on getting indicator-messages issue solved?
[21:30] <sergiusens> rsalveti: native or non -0ubuntu1 ?
[21:31] <sergiusens> rsalveti: I'll remove the -0ubuntuX for now
[21:31] <rsalveti> sergiusens: well, removing 0ubuntuX is making it native :-)
[21:31] <sergiusens> rsalveti: well, debian is weird in that sense to me... the format is 1.0 and not 3.0 (native)
[21:32] <sergiusens> rsalveti: it's being pushed
[21:33] <rsalveti> sergiusens: right, I agree, just that without any -something it usually means native
[21:37] <ChickenCutlass> sergiusens, no one
[21:37] <ChickenCutlass> sergiusens, not sure who that is
[21:44] <Oranger> balloons: Hey ! :) Just want to ask you, is it normal that I the autopilot/ppa just give the 1.2 branch and not the 1.3 ?
[21:44] <Oranger> balloons: Or maybe it's just me who are doing something wrong
[21:44] <balloons> Oranger, no it should give 1.3, what version of ubuntu are you on>
[21:45] <Oranger> balloons: 13.04
[21:46] <balloons> autopilot --version
[21:46] <balloons> Autopilot Source Version: 1.3.1 Autopilot Package Version:
[21:46] <balloons> 1.3.1daily13.06.15bzr247saucy0
[21:47] <balloons> u?
[21:47] <rsalveti> sergiusens: I believe bfiller was taking care of that, iirc
[21:47] <Oranger> autopilot --version
[21:47] <Oranger> usage: autopilot [-h] {run,list,vis,launch} ...
[21:47] <Oranger> autopilot: error: too few arguments
[21:47] <Oranger> Hum..
[21:48] <bfiller> rsalveti: taking care of what?
[21:49] <rsalveti> bfiller: the issue regarding the phablet specific indicator-messages
[21:49] <rsalveti> which is blocking the phone-app to be part of the ci that makes it land in the archive
[21:49] <rsalveti> I remember that someone was working on fixing that (lars?), but not sure how far we are from having a working upstream version that is compatible with both touch and desktop
[21:49] <bfiller> rsalveti: it's larsu and the indicator team
[21:50] <bfiller> rsalveti: don't have an update, don't think they are close to having a working upstream version from last update
[21:50] <rsalveti> right =\
[21:51] <bfiller> I'll inquire tomorrow about it more
[21:51] <rsalveti> great, thanks
[21:51] <rsalveti> sergiusens: happroved
[21:52] <Oranger> balloons: Sorry, I fixed it, always do an apt-get update after added a repo... always ^^'
[21:52] <sergiusens> bfiller: thanks
[21:53] <balloons> Oranger, :-)
[22:24] <ajalkane>  /quit
[22:46] <sag> hiya.. trying to hack ubuntu touch together on my Asus Transformer Prime TF201.. I've gotten it to boot but it just drops me to an shell -- I don't have an keyboard with the tablet.. so I was wondering if anyone had an sneaky idea to get the UI up/
[22:46] <sag> ?*
[22:56] <mhall119> sag: you can try running "unity8" on the shell and see what it spits out
[22:56]  * mhall119 assumes this is an Ubuntu shell, not an Android shell
[22:56] <sag> mhall119: yes it's Ubuntu shell :P thank you! just what I was looking for