[00:03] <sergiusens> dragonkeeper, http://paste.ubuntu.com/6487169/
[00:04] <TechieElf> sergiusens: You were right, fstab didn't help. Here's the last_kmsg from the boot loop. Can you take a look? http://pastebin.com/8ZQLixZv
[00:05] <sergiusens>   TechieElf that looks the same as the previous one
[00:05] <sergiusens> TechieElf, use abootimg to extract the boot img and hack around init
[00:06] <TechieElf> sergiusens: I'm not familiar with abootimg
[00:08] <TechieElf> I've installed it now. How exactly do I do this?
[00:14] <dragonkeeper> sergiusens, i commented out all galaxys3 settings and renamed device/samsung/msm8960-common/DeviceSettings/Android.mk: becaue it was complaining about package name needed  but now i get http://pastebin.com/uKLRG9kQ
[00:15] <sergiusens> dragonkeeper, well get rid of the nfc stuff
[00:16]  * sergiusens checks out
[00:20] <dragonkeeper> ok
[00:21] <rhosigma> i have an install question
[00:23] <rhosigma>  i have phablet-tools installed.. i have a nexus 7 grouper.. trying to install from the bootloader...l possible??
[00:24] <ahoneybun> rhosigma, from Android
[00:25] <rhosigma> so i cant install from bootloader?
[00:28] <ahoneybun> I did not
[00:28] <ahoneybun> just run the command
[00:29] <ahoneybun> https://wiki.ubuntu.com/Touch/Install#Step_4_-_Downloading_.26_Deploying_Image_to_Device
[00:31] <TechieElf> Can someone help me troubleshoot my boot loop? I have the last_kmsg: http://pastebin.com/8ZQLixZv
[00:37] <rhosigma> better to use channel devel or channel stable
[00:37] <rhosigma> ??
[00:40] <dragonkeeper> woo looks like i9505 jfltexx "samsung galaxy s4" port is building :)
[00:43] <rhosigma> do you think its better to use channel devel or channel stable
[00:44] <TechieElf> rhosigma: stable unless you're a dev
[00:45] <rhosigma> ok thanx
[00:45] <TechieElf> rhosigma: No problem
[01:00] <dragonkeeper> http://pastebin.com/KrvSEaBW   how do i resolve this build error?
[01:22] <dragonkeeper> http://pastebin.com/KrvSEaBW   how do i resolve this build error?
[02:08] <dragonkeeper> given up , time to sleep. only a few more compile errors to fix for i9505
[02:40] <alia> heyy
[06:21] <vendre> hello everyone
[07:47] <dholbach> good morning
[07:54] <nhaines> dholbach: good morning  :)
[07:56] <dholbach> hi nhaines
[07:57] <nhaines> dholbach: I'm just backing up my Galaxy Nexus before I switch back over to Ubuntu again for a week or two.
[07:57] <dholbach> awesome
[07:57] <nhaines> Do you suspect 13.10 or trusty is going to be more exciting?
[08:07] <popey> nhaines: trusty
[08:14] <nhaines> popey: heh, the more testers the better, eh?
[08:14] <popey> well indeed!
[08:15] <popey> also, if you find a bug in saucy, chances are the first thing someone will say is "upgrade to trusty" to be fair
[08:15] <nhaines> Probably after I have a chance to test that package that keeps getting bounced back, I'll jump to trusty.
[08:17] <nhaines> Speaking of, if anyone wants to review my pending click package...  I once again think I've nailed down all the issues.
[08:18] <nhaines> popey: is there any more development ongoing with Ubuntu 13.10 or is everything devoted to trusty now?
[08:24] <popey> nhaines: there was talk of spinning an updated 13.10
[08:25] <popey> nhaines: approved your app
[08:26] <nhaines> popey: thanks!  I'm slightly annoyed (because reasons) and embarrassed (at myself) that it took four passes.  But hopefully I won't make as much work for you guys next time.
[08:27] <popey> are you testing it yourself locally with the click-reviewers-tools ?
[08:29] <nhaines> Not for this webapp, but I'll incorporate that into my workflow when I sit down to build my first real app.
[08:31] <popey> yeah, very wise
[08:35] <nhaines> On the bright side, the phone's booting, so once I push my old backup, disable Mir, and reboot, it'll be screenshot time.
[08:38] <popey> you can take screenshots with mir
[08:38] <popey> https://bazaar.launchpad.net/~popey/+junk/phablet-flash-wrapper/view/head:/mirfbdump that kind of thing
[08:39] <nhaines> Not on maguro.
[08:40] <nhaines> Also if this has changed than I will be happy.
[08:40] <popey> oh, ok
[08:40] <popey> no idea
[08:40] <popey> i dont have a maguro, sorry
[08:41] <nhaines> I guess I'll find out.  Mir used to thrash and die sometimes on maguro when the framebuffer was dumped.
[09:02] <nhaines> Okay, time to figure out how to upgrade to trusty.
[09:03] <nhaines> I'd like to believe that 'adb shell system-image-cli -v --channel trusty -b 0' will do the trick.
[09:07] <nhaines> popey: fyi, I get pure black images when using mirfbdump on maguro on 13.10.
[09:21] <popey> nhaines: that command should work
[09:23] <nhaines> popey: it doesn't appear to have done so.  :(  Well, guess I'll just figure out how to phablet-flash it.
[09:24] <popey> nhaines: phablet-flash ubuntu-system --channel=trusty
[09:24] <nhaines> popey: extremely helpful.  Thank you very much.
[09:25] <popey> np
[10:04] <motz> hi, on which tablets is it possibile to install ubuntu?
[10:18] <sil2100> mardy: ping
[10:18] <pitti> ogra_, lool: would you mind top-approving https://code.launchpad.net/~elopio/dialer-app/fix1250270-pep8/+merge/194775 ? It's trivial and approved by the phone devs, but I don't want this blocked for 4 days until the US folks stopped eating turkey :)
[10:18] <pitti> and elopio has another MP on top of that
[10:19] <nhaines> pitti: for your information, we also eat stuffing and mashed potatoes!
[10:19] <elopio> pitti: I need to update the other one.
[10:19] <pitti> elopio: I think it'll merge cleanly to trunk once the pep8 one lands
[10:19] <pitti> nhaines: what, no alcohol?
[10:20] <elopio> that would be nice. I'll keep an eye on it.
[10:20] <nhaines> pitti: well, obviously we need to have something to wash it down with after.  :)
[10:21] <pitti> ogra_, lool: it got held up way too long by the e-d-s transition already :)
[10:21] <pitti> nhaines: *phew* :)
[10:21] <ogra_> pitti, done
[10:21] <pitti> ogra_: danke
[10:21] <lool> pitti: I was about to ask whether I need to run test this given it's pep8 fixes
[10:22] <pitti> lool: well, better that than adding a "[X] trivial fix" which then gets abused :)
[10:22] <pitti> and these can introduce hard to see errors as well
[10:23] <pitti> like forgetting a trailing comma or whatnot
[10:24] <lool> pitti: FYI:
[10:24] <lool> tests/autopilot/dialer_app/tests/__init__.py:16: 'GreaterThan' imported but unused
[10:24] <lool> tests/autopilot/dialer_app/tests/__init__.py:22: 'sleep' imported but unused
[10:24] <pitti> lool: https://code.launchpad.net/~elopio/dialer-app/fix1250275-pyflakes/+merge/194776 :)
[10:24] <pitti> lool: that's the branch that goes on top of the PEP8 one
[10:25] <lool> :-)
[10:25] <pitti> lool: so once that's merged, I'll ask ogra or you to top-approve that one
[10:25] <pitti> that'll re-run the tests which should succeed now
[10:25] <pitti> (again, e-d-s uninstallability had made it fail for three weeks or so)
[11:11] <mardy> sil2100: pong (saw your bug report)
[11:11] <davmor2> Morning all
[11:12] <davmor2> ogra_: r35 installing
[11:13] <popey> davmor2: do you have mako or maguro?
[11:13] <popey> davmor2: also, do you have a list of tests you're doing manuall
[11:13] <popey> +y
[11:14] <davmor2> popey: I only have maguro
[11:14] <popey> (morning btw)
[11:28] <TechieElf> Morning all
[11:32] <davmor2> popey: oh although I have a grouper too thinking about it :)
[11:34] <TechieElf> Can someone help me troubleshoot my bootloop? Here's the last_kmsg: http://pastebin.com/8ZQLixZv
[11:41] <sil2100> mardy: any idea what's up with that problem of mine?
[11:45] <TechieElf> I need help with a boot loop. Here's the bootimg.cfg: http://pastebin.com/iSnntn0n it looks wrong. Can someone help me?
[11:53] <lool> pitti: I checked https://code.launchpad.net/~elopio/dialer-app/fix1250275-pyflakes/+merge/194776 and approved it but didn't top approve it yet
[11:53] <lool> pitti: surprized by the From -> from fix, did this fail the tests before the change then?
[11:53] <pitti> lool: yeah, the pep8 fix is a bit slow to land; although I think the CI machinery should be clever enough to see that the pyflakes branch goes on top of the pep8 one
[11:54] <pitti> lool: no, I was quite surprised that this worked
[11:54] <pitti> I thought "From" wasn't valid python
[11:54] <lool> weird
[11:54] <lool> yeah
[11:54] <lool> maybe it's super old Python and cheap to keep supporting
[11:54] <pitti> lool: it was already reviewer-approved, only needs top-approval now
[11:54] <pitti> this will also re-trigger the tests
[11:58] <lool> pitti: Yeah, I just wanted to do a preliminary review for myself, to top approve immediately once ready
[12:08] <mardy> sil2100: not yet, I'll check it a bit later
[12:43] <TechieElf> Good morning everyone.
[12:47] <Rhonda> Hey there.
[12:47] <ogra_> hey !
[12:47] <Rhonda> I still have my nexus 4 and I guess I'm at the point where I want to give touch a try. :)
[12:47] <Rhonda> I started to follow the wiki, up to the point of "adb backup -apk -shared -all"
[12:48] <Rhonda> The resulting backup.ab file is 2 gig in size, which somehow gives me the impression, that adb has troubles with LFS?
[12:48] <sergiusens> it was mentioned by someone that adb may have a size limit it can pull
[12:49] <Rhonda> That's highly disappointing for me, because I want to make sure that I don't lose any data.  What are your suggestions here?
[12:49] <Rhonda> contacts and calendar are synced to my own davical instance, and I checked the postgres database, so that's not the issue.
[12:50] <Rhonda> And my photos are synced to dropbox anyway.  But I still have this gut feeling that something bad might happen.
[12:50] <Rhonda> Should the "sudo fastboot oem unlock" influence the current installation somehow?
[12:51] <ogra_> i think it wipes all userdata
[12:51] <ogra_> i.e. a factory reset
[12:51] <Hourd> it does yes
[12:52] <Hourd> but you can then restore from your backup file and it should be the same as before you unlocked it
[12:52] <Rhonda> Well, given that the backup file is only 2g, I highly doubt that. :)
[12:54] <popey> I have seen issues with files over 2GB too
[12:54] <popey> so i wouldn't trust that backup
[12:54] <popey> and would expect to lose everything on the phone
[12:55] <popey> Those are my expectations anyway ☻
[12:55] <sergiusens> I would use something that doesn't rely on adb
[12:55] <sergiusens> some network push of the backup
[12:55] <ogra_> mtp should work too, no ?
[12:56] <sergiusens> not everything is exposed over mtp
[12:56] <ogra_> indeed you would have to tar it up via adb in an accessible folder or so
[12:56] <sergiusens> ogra_, that would work
[12:59] <sergiusens> if you have clockworkmod recovery already, try http://wiki.cyanogenmod.org/w/ClockWorkMod_Instructions#Making_a_backup
[13:05] <pitti> lool: mind top-approving https://code.launchpad.net/~elopio/dialer-app/fix1250275-pyflakes/+merge/194776 now? the pep8 one just got merged
[13:09] <lool> pitti: yup, done
[13:09] <pitti> lool: merci
[13:21] <lops> 'morning
[13:32] <t1mp> am I typing something wrong here?
[13:32] <t1mp> tim@ideapad:~$ phablet-flash ubuntu-system --channel trusty-devel
[13:32] <t1mp> INFO:phablet-flash:Device detected as manta
[13:32] <t1mp> INFO:urllib3.connectionpool:Starting new HTTPS connection (1): system-image.ubuntu.com
[13:32] <t1mp> ERROR:phablet-flash:https://system-image.ubuntu.com/trusty-devel/manta/index.json cannot be retrieved
[13:34] <ogra_> what is trusty-devel ?
[13:34] <ogra_> :)
[13:35] <ogra_> (you want trusty-proposed or devel-proposed (they are the same))
[13:43] <pitti> ogra_: oh, trusty and devel are the same now, finally?
[13:43] <ogra_> yep
[13:43] <ogra_> saucy is stable
[13:44] <ogra_> lool, oh, btw, there is a saucy-proposed image containing your SRU now
[13:44] <lool> ogra_: cool
[13:44] <lool> ogra_: I dont have to retest it though, I guess it's just generic image testing at this point?
[13:44] <lool> cause I reupgraded to trusty already
[13:44] <ogra_> yeah, i guess so
[13:45] <pitti> ogra_: great, that was rather confusing a few weeks ago
[13:45] <ogra_> yeah ... took a bit until we got there ... i hipe we can be faster next release
[13:45] <ogra_> *hope
[13:54]  * ogra_ grumbles about blueprints .... how do i add a WI thats owned by more than one person :/
[13:55] <Saviq> ogra_, help, we're getting mind-twisted here...
[13:55] <ogra_> haha
[13:55] <Saviq> ogra_, we're executing some commands over ssh
[13:55] <Saviq> ogra_, to build/run unity8 on the device
[13:56] <Saviq> ogra_, so, starting with "ssh phablet@mako"
[13:56] <Saviq> ogra_, that doesn't get us the env from upstart
[13:58] <Saviq> ogra_, case in point
[13:58] <mardy> jdstrand: hi! Do you have an ETA for https://bugs.launchpad.net/ubuntu/+source/apparmor-easyprof-ubuntu/+bug/1245903 ?
[13:58] <Saviq> ssh phablet@mako 'echo ${QML2_IMPORT_PATH}'
[13:58] <Saviq> vs.
[13:58] <ogra_> did you check your quoting ?
[13:58] <Saviq> ssh phablet@mako 'bash -ic 'echo ${QML2_IMPORT_PATH}''
[13:58] <mzanetti> ogra_: the whole day long :D
[13:58] <Saviq> ogra_, yeah, many times ;)
[13:58] <Saviq> ogra_, the first one prints, the second one doesn't
[13:59] <mzanetti> actually, the quoted example does work... its the one where quotes shouldn't be needed that doesn't
[13:59] <ogra_> Saviq, why would you use the second one with ssh ?
[13:59] <Saviq> ogra_, to get the upstart env? like dbus?
[14:00] <Saviq> ogra_, our complete thing is:
[14:00] <ogra_> that should be achieved by the first one already ... starting bash only fires up an additional subshell ...
[14:00] <pitti> Mirv, sil2100: it seems you've done some work on  QtSensors/qtubuntu-sensors?
[14:01] <Saviq> ogra_, look at the difference between 'ssh phablet@mako env' and 'ssh phablet@mako sudo -u phablet -i env'
[14:01] <ogra_> (which would be good when using adb but should not be necessary with ssh, where pam is processed at login already)
[14:01] <TechieElf> Can someone please help me troubleshoot this annoying boot loop? I have the last_kmsg
[14:01] <Saviq> ogra_, the one without sudo doesn't include UPSTART session etc.
[14:01] <Saviq> ogra_, I think the problem is that bash is called without -i
[14:01] <ogra_> hmm
[14:01] <Saviq> ogra_, when... it's not -i
[14:01] <sil2100> pitti: hi! In my case it was mostly packaging-related though - what's up?
[14:01] <Saviq> ogra_, and that's when it doesn't include the env
[14:01] <ogra_> let me set up an ssh env here ...
[14:02] <Saviq> ogra_, so our whole thing is:
[14:02] <pitti> sil2100: I'm tasked with investigating how to create integration tests for sensors
[14:02] <pitti> sil2100: so I've looked at libhybris, qtsensors-opensource-src, and qtubuntu-sensors
[14:03] <Saviq> ssh phablet@mako sudo -u phablet -i bash -ic \"$@\"
[14:03] <pitti> sil2100: libhybris is rather clear, but the latter two are mostly just C++ skeleton; I have some trouble finding the actual meat
[14:03] <Saviq> ogra_, I know that's tragic, but that's the only thing that worked for us
[14:03] <pitti> sil2100: the only meat I've found is in src/plugins/sensors/ in qtsensors-opensource-src
[14:03] <Saviq> ogra_, and now we noticed that as soon as we ./ another script from that - the env is lost again
[14:04] <pitti> sil2100: so, qtubuntu-sensors claims it provides a libhybris backend, but I don't see anything there which uses libhybris or talks to Androis
[14:04] <pitti> d
[14:04] <pitti> sil2100: so I guess I'm missing something; what connects the dots between QtSensors and libhybris?
[14:04] <pitti> sil2100: or are we using qtsensors-opensource-src's android backend?
[14:05] <sil2100> pitti: hm, sadly I don't know the code as well even, Mirv might know something, I would most probably poke kalikiana_ about this
[14:05] <sil2100> kalikiana_: ^
[14:05] <pitti> sil2100: ah, thanks
[14:06] <pitti> kalikiana_: hey Christian, how are you?
[14:06] <sil2100> kalikiana_: could you backtrack a bit up and try clearing up the situation?
[14:06] <pitti> kalikiana_: so iahmad gave be some briefing this morning, but apparently he was missing something
[14:07] <kalikiana_> pitti: hey
[14:07] <kalikiana_> you want to know something about sensors?
[14:07] <pitti> kalikiana_: yes; jfunk asked me to team up with some sensors dev to discuss how to create some initial integration tests
[14:08] <pitti> kalikiana_: so as a first step I'm trying to understand the architecture of the various layers
[14:08] <kalikiana_> our backends come from https://code.launchpad.net/qtubuntu-sensors/ when you speak of "existing open source backends" it's worth noting these are largely not open and hardware specific
[14:08] <kalikiana_> so for instance the vibration backends for QtFeedback can't be re-used
[14:08] <pitti> kalikiana_: so, I read the sensor bits from libhybris; I guesss that's the low-level API that we use?
[14:08] <kalikiana_> the stuff ie MeeGo uses is not open
[14:09] <Mirv> pitti: yep regarding usage kalikiana is knowledgeable
[14:09] <kalikiana_> pitti: it depends on what you mean by 'sensor' there's a cuple Qt APis that require backends
[14:09] <pitti> kalikiana_: so, QtSensors is mostly C++ typing/signalling/adapter classes around possible backends like android, simulator, or the qtubuntu-sensors backend, right?
[14:10] <ogra_> Saviq, did that change recently ?
[14:10] <Saviq> ogra_, I don't think it did
[14:10] <pitti> kalikiana_: well, qtubuntu-sensors' description says "libhybris" backend, but there's nothing hybris-y in that
[14:10] <Saviq> ogra_, we had this sudo/bash thing that work around it
[14:10] <ogra_> (there was more cgroup stuff added in trusty afaik)
[14:11] <Saviq> ogra_, but we started using a script in one of the calls
[14:11] <pitti> kalikiana_: so my questions are (1) are we actually talking to libhybris on the phone as the low-level API or do we use somethign else, and (2) what connects the qtubuntu-sensors to libhybris
[14:11] <kalikiana_> pitti: yes basically it's interfaces that map to C++ and QML API, and they do whatever the installed backends do or don't
[14:11] <Saviq> ogra_, and that script does not inherit the env
[14:11] <Saviq> ogra_, it wasn't critical for us so no one complained much
[14:11] <ogra_> right, you would have to wrap it into another subshell call
[14:12] <Saviq> ogra_, meaning bash -ic? tried that - it actually didn't work..
[14:12] <ogra_> no, a fully wrapped sudo i fear
[14:12] <kalikiana_> pitti: hybris is used for camera. it's not "the" api because there's different things there
[14:12] <Saviq> ogra_, whoah
[14:13] <Saviq> ogra_, that would get us back to $HOME?
[14:13] <pitti> kalikiana_: ah, so we are not using libhybris for the sensors; how do we get them from Android then?
[14:13] <kalikiana_> pitti: for instance QtFeedback is based on writing to /sys/something and will soon use usensord which is a service
[14:13] <ogra_> Saviq, it should., yeah
[14:13] <Saviq> ogra_, we need to be in $HOME/shell for that...
[14:13] <Saviq> ogra_, or well, fix the script, FWIW
[14:13] <ogra_> got a pastebin with the script or some such ?
[14:14] <Saviq> ogra_, just 'echo $QML2_IMPORT_PATH'
[14:14] <kalikiana_> pitti: it would help to be more specific than "them"… there's lots of different plugins :-)
[14:14] <Saviq> ogra_, well, the script is http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/run
[14:14] <Saviq> ogra_, ran on device by http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/run_on_device
[14:15] <Saviq> ogra_, run_on_device:109 calls ./run via ssh
[14:15] <pitti> kalikiana_: sure; so, to put it this way: starting from "I turn my mobile phone", how does the information flow from the hw sensor/android drivers all the way up to an app?
[14:15] <pitti> kalikiana_: where hw sensor == orientation sensor, in this case
[14:16] <sil2100> mardy: any luck with the bug? Am I doing something wrong when running the tests?
[14:16] <pitti> kalikiana_: (it looks like we implement orientation and accel ATM? )
[14:16] <mardy> sil2100: sorry, I'm still investigating another bug
[14:17] <mardy> sil2100: just out of curiosity, what happens if you run "online-accounts-ui --desktop_file_hint=/usr/share/applications/online-accounts-ui.desktop" from the terminal?
[14:17] <kalikiana_> pitti: accelerometer and location come from libplatform-api-headers
[14:17] <kalikiana_> those are used to implement the qt backends
[14:17] <sil2100> mardy: let me try, one moment
[14:19] <TechieElf> i seriously would appreciate some assistance with my boot loop problem.. can someone help? I have the last_kmsg..
[14:19] <pitti> kalikiana_: ah, so platform-api provides the actual sensor reading, and qtubuntu-sensors is just glue code?
[14:20] <ogra_> mzanetti, Saviq, how about using #!/bin/bash in http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/run  :)
[14:20] <mzanetti> tried that
[14:20] <kalikiana_> pitti: yes
[14:20] <Saviq> ogra_, not enough
[14:20] <mzanetti> ogra_: Saviq: no difference
[14:20] <ogra_> hmmm
[14:20] <Saviq> ogra_, again, does not do --interactive
[14:20] <ogra_> tried adding -i to the shebang ?
[14:20] <Saviq> ogra_, AFAICT, bash only loads the upstart env when ran with --interactive
[14:20] <sil2100> mardy: ok, strange things happen
[14:20] <Saviq> ogra_, did, no go
[14:21] <Saviq> ogra_, at that point the env is borked somehow already
[14:21] <mardy> sil2100: such as? :-)
[14:21]  * Saviq tries again
[14:21] <ogra_> Saviq, mzanetti thne source /pet/profile at the top of your script
[14:21] <ogra_> /etc/profile
[14:21] <ogra_> heh, funny typo
[14:21] <sil2100> mardy: when I run it from ssh, the online-accounts-ui starts up in the background (I see it appearing in the list of active applications), but it doesn't come up - and after pressing on the app in the list, a black screen appears and then unity8 dies
[14:22] <sil2100> mardy: dies and gets restarted in a clean state
[14:22] <Saviq> ogra_, sure, that would help us, but hardly feels like the right solution...
[14:22] <mardy> greyback: ^ that might be the same crash that you were investigating, or maybe not :-)
[14:22] <ogra_> well, i dont see a better one
[14:23] <pitti> kalikiana_: ah, so I found the functions that qtubuntu-sensors uses in src/ubuntu/hybris/ubuntu_application_sensors_hybris.cpp -- these are magic macros to implement these in terms of libhybris?
[14:23] <greyback> sil2100: mardy: yes I suspect the same. I'm working on it, it's annoying :)
[14:23] <Saviq> ogra_, is it expected / by design that this happens?
[14:23] <ogra_> Saviq, i guess thats the shell handling of ssh if you dont actually log in
[14:24] <ogra_> else you wouldnt need all that sudo nonsense
[14:24] <mardy> greyback: in the above case, we have a process (online-accounts-ui) which opens a connection to QtUbuntu but doesn't create a window until some clients connect to it
[14:24] <sil2100> greyback, mardy: do you guys think the AP failures are also because of that? Since I ran other app AP tests fine with this image
[14:24] <Saviq> ogra_, :'(
[14:24] <mardy> sil2100: I'll investigate tomorrow (I hope); they might be related, yes
[14:24] <greyback> mardy: which should be fine.
[14:24] <mardy> greyback: still, a window appears in unity
[14:25] <pitti> kalikiana_: ah no, this also just seems to be more glue which calls a function like uas_accelerometer_event_get_acceleration_x from a dynamically loaded shlib /system/lib/libubuntu_platform_hardware_api.so
[14:25] <mardy> greyback: while the process didn't create any
[14:25] <ogra_> Saviq, the /bin/sh definitely wont process /etc/profile ... not sure how else we could set the vars we need ...
[14:25] <greyback> mardy: yes that's a bug/me being lazy
[14:25] <Saviq> ogra_, well, shouldn't they be inherited from the "wrapping" environment?
[14:25] <mzanetti> ogra_: but isn't it weird that it drops the env? I mean, when calling the script it's there
[14:26] <kalikiana_> pitti: I don't know the exact implementation at that level, I'm more on the consuming side. tvoss_ might be better to ask there
[14:26] <pitti> kalikiana_: ok, thanks
[14:26] <greyback> mardy: can you report a separate bug for that and assign to me please? Fix should be reasonably easy for me
[14:26] <Saviq> ogra_, i.e. 'echo $FOO' works, but when you put that in a script and execute it with './foo', it's gone?
[14:26] <tvoss_> pitti, hey, how can I help?
[14:26] <pitti> kalikiana_: iahmad showed me https://docs.google.com/a/canonical.com/drawings/d/1sXQ3Xl8A0mvMi5Q0y7E5ipKfJbRfA6AokWdwm2gw0Bg this morning, but after our discussion and my initial code reading this looks rather wrong/incomplete
[14:26] <mardy> greyback: OK
[14:26] <pitti> tvoss_: hey, how are you?
[14:27] <pitti> tvoss_: I'm trying to understand the sensors API architecture
[14:27] <tvoss_> pitti, pretty good, thank you :) enjoying the US having public  holidays a.k.a. the silence :)
[14:27] <greyback> mardy:  online-accounts-ui will have to show up as separate app, until we've the window child/parent relationship stuff going
[14:27] <mardy> greyback: unity-mir or unity8?
[14:27] <mardy> greyback: yes, that's fine
[14:27] <pitti> tvoss_: so far I found lots and lots of glue code in qtsensors-opensource-src, qtubuntu-sensors, the platform API, but I still don't know how a hw sensor event actually flows to an application
[14:27] <greyback> mardy: mark as affecting both. It's unity-mir primarily though
[14:28] <pitti> tvoss_: do we happen to have an architecture description/diagram somewhere, or who would be a good person to explain it to me?
[14:28] <tvoss_> pitti, yup, let me find one
[14:28] <pitti> tvoss_: (background: I got tasked to discuss the creation of sensor integration tests with $appropriate_developer)
[14:28] <pitti> and of course provide some initial tests
[14:28] <Saviq> ogra_, sourcing /etc/profile, ~/.bashrc, nothing works :/
[14:29] <ogra_> thats cant be
[14:29] <ogra_> adding ". /etc/profile" should definitely process the profile and profile.d
[14:29] <tvoss_> pitti, yup, let me see
[14:29] <mzanetti> ogra_: Saviq: the one we need is in /etc/environement
[14:29] <mzanetti> not sure how that gets sourced normally
[14:29] <Saviq> mzanetti, right, that's an important point
[14:30] <ogra_> ugh, that needs to be moved out there
[14:30] <tvoss_> pitti, so I have got https://docs.google.com/a/canonical.com/document/d/1Auu7Vjk8THFOjCnbWiTw0y7TqI2Njpd8UHY73_nqjOw/edit#heading=h.3wm9daqnlz9x
[14:30] <Saviq> mzanetti, ogra_ right, so sourcing that helps...
[14:30] <ogra_> great
[14:31] <ogra_> well, do you know how it gets in there ?
[14:31]  * mzanetti doesn't
[14:31] <Saviq> ogra_, me neither
[14:31] <ogra_> it should move to become a profile.d snippet installed by a package
[14:31] <Saviq> ogra_, qtubuntu then
[14:31] <ogra_> so we can safely upgrade it if it changes
[14:31] <Saviq> ricmm, do you know where the /etc/environment QML2_IMPORT_PATH comes from?
[14:31] <tvoss_> pitti, which is how we planned it out. Today, sensor events are aggregated and fusioned together by the android sensor service (running in the container), and individual clients start sessions with the service
[14:32] <ogra_> Saviq, i suspect from the build scripts actually
[14:32] <Saviq> ogra_, yeah, something like that
[14:32] <ogra_> Saviq, the question is what the impact of moving it is ...
[14:33] <pitti> tvoss_: ah; what is at the boundary between the Android container and our Ubuntu platform API? do we use libhybris for that, or reading binder, or whatever else to communicate with the android sensor service?
[14:33] <Saviq> ogra_, it's only there for unity8's consumption
[14:33] <ogra_> preferably we should have an /etc/environment that doesnt differ from a desktop install
[14:33] <mzanetti> Saviq: you sure about that?
[14:33] <Saviq> ogra_, so we can definitely improve that
[14:33] <mzanetti> Saviq: I could think of things inside Qt relying on it too
[14:33] <Saviq> mzanetti, nothing else should be using the Applications module
[14:33] <Saviq> mzanetti, it's not about the QPA
[14:33] <ogra_> and have such bits live in profile.d sippets
[14:33] <Saviq> mzanetti, it's the qml import path
[14:33] <Saviq> mzanetti, standup, btw
[14:33] <tvoss_> pitti, today, the actual events are passed over to the client via binder, handed over the libc boundary via hybris
[14:34] <tvoss_> pitti, then dispatched via platform api to higher-level runtimes (like qt)
[14:35] <pitti> tvoss_: so libhybris connects to binder (in the client process) and translates that to the hybris/include/android/hardware/sensors.h API?
[14:35] <tvoss_> pitti, hang on
[14:35] <pitti> tvoss_: right, I think I understand what's going on between platform-api, qtubuntu-sensors, qtsensors-opensource-src, and the app now
[14:36] <tvoss_> pitti, cool
[14:36] <pitti> tvoss_: I'm still missing the connection between platform-api and the android sensor service
[14:36] <pitti> tvoss_: e. g. src/ubuntu/hybris/ubuntu_application_sensors_hybris.cpp defines the functions
[14:36] <pitti>   for qtubuntu-sensors (like uas_accelerometer_event_get_acceleration_x)
[14:36] <pitti> tvoss_: but they aren't actually implemented there, but just called from a dynloaded /system/lib/libubuntu_platform_hardware_api.so
[14:37] <tvoss_> pitti, yup, the dynloaded so lives in the container
[14:37] <tvoss_> so on the android side
[14:37] <tvoss_> pitti, http://bazaar.launchpad.net/~phablet-team/platform-api/trunk/view/head:/android/hybris/ubuntu_application_sensors_for_hybris.cpp shows you the implementation
[14:37] <pitti> tvoss_: what package builds that?
[14:38] <tvoss_> pitti, we used to build it as part of the android source tree. ogra_ can you give some more detail here?
[14:38] <pitti> tvoss_: ah, got the file (it's actually in platform-api)
[14:38] <tvoss_> pitti, yup, in the android parts of it
[14:39] <tvoss_> pitti, iirc, that file does the translation of events
[14:39] <pitti> so libubuntu-platform-hardware-api1 ships /usr/lib/x86_64-linux-gnu/libubuntu_platform_hardware_api.so.1
[14:39] <pitti> so I guess we symlink/copy that into /system/ during image build time?
[14:39] <pitti> tvoss_, ogra_ ^
[14:40] <pitti> tvoss_: indeed, that file looks promising; the last link in the chain between HAL/hybris and the app :)
[14:40] <ogra_> i think thats a qeustion for ricmm or rsalveti
[14:41] <ogra_> the bits of the android tree are indeed built at package build time of the android package
[14:41] <tvoss_> pitti, yup
[14:41] <ogra_> and iirc the ubuntu bits are pulled in during build
[14:42] <pitti> ogra_, tvoss_: ok; I don't need to know how that happens in detail, just that platform-api's android/hybris/ubuntu_application_sensors_for_hybris.cpp is essentially what runs in Android and directly talks to Android's sensor service
[14:42] <ogra_> (either from bzr or with lp-pull )
[14:43] <tvoss_> pitti, yup
[14:43] <pitti> tvoss_: so I think iahmad, you, and I should have a meeting in the next days to discuss how/where we can provide some mock sensors and how to get some initial integration tests
[14:44] <pitti> tvoss_: do you think anyone else should participate in that, kalikiana_ or some other developer who works on that regularly?
[14:44] <tvoss_> pitti, +1 for kalikiana_, but that should be it
[14:44] <pitti> tvoss_: ack
[14:46] <pitti> tvoss_: so conveniently kalikiana_, you, and I are all in the same TZ; could we meet tomorrow or Monday morning, so that iahmad and perhaps jibel can join?
[14:47] <tvoss_> pitti, sure, tomorrow woul dbe best for me. I'm in London Monday to Wednesday next week
[14:47] <pitti> kalikiana_: does that work for you, too? some time around 9 or 10?
[14:47] <jibel> pitti, tomorrow morning works for me.
[14:48] <ricmm> I'd say invite me, considering I wrote a lot of the latest one
[14:48] <ricmm> but tomorrow I'm flying
[14:49] <pitti> ricmm: hm, so no overlap between you and tvoss_ then; could we have it tomorrow, and I talk to you next week and confirm the plan with you?
[14:50] <dragonkeeper> anyone know how to fix this http://pastebin.com/ziG7Y2dR  , trying to compile port and it keeps throwing out errors
[14:51] <ricmm> sure
[15:00] <pitti> tvoss_, ricmm: I'd appreciate a quick review of my notes about the architecture: is that more or less correct? http://pad.ubuntu.com/sensors-testing
[15:00] <kalikiana_> pitti: preferrably 11 so I'm mentally more focussed, though I can make it earlier if that's better for you
[15:01] <pitti> kalikiana_: 11 WFM, if it's fine for tvoss_
[15:05] <rsalveti> morning
[15:08] <pitti> kalikiana_, tvoss_: sent you an invite
[15:10] <rsalveti> pitti: the android image consumes both libhybris and platform-api during build-time
[15:10] <rsalveti> pitti: to provide /system/lib/libubuntu_platform_hardware_api.so, for example
[15:10] <kalikiana_> pitti: ok, got it
[15:10] <rsalveti> but that's not part of any debian package, but provided by the same source package, which is consumed when we build the android image
[15:11] <pitti> rsalveti: ah, so somehow libubuntu_platform_hardware_api.so gets copied out of the libubuntu-platform-hardware-api1 package (i. e. from /usr/lib) to /system/
[15:11] <rsalveti> so that's why we need to maintain both the android and the ubuntu images in sync
[15:11] <rsalveti> pitti: not even copied, it downloads the source package and feeds that into the android build system
[15:12] <rsalveti> if you check the source package, you'll fined a few Android.mk files
[15:12] <rsalveti> they are the ones consumed by the android build-system
[15:12] <pitti> rsalveti: ah, thanks (the details are not that relevant for creating integration testing, but good to know anyway)
[15:12] <pitti> I mostly wanted to make sure that I'm looking at the right files
[15:13] <rsalveti> pitti: yeah, just so you don't have possible issues in the future in case you want to change something in the platform-api package, for example
[15:13] <pitti> as e. g. the qtsensors-opensource-src package has its own android backend; so we are not using that
[15:14] <pitti> rsalveti: we still build platform-api also on the buildds, right? so if we want to put some new integration tests into "make test", they could run there, and also have access to e. g. umockdev or some other ubuntu bits?
[15:14] <didrocks> oSoMoN: hey, around? there is a yummi keyboard issue :)
[15:15] <oSoMoN> didrocks, yeah, I’m not busy eating/digesting turkey
[15:15] <rsalveti> pitti: yes, as long you abstract the android side of it, you should be fine
[15:15] <oSoMoN> didrocks, what’s the issue?
[15:15] <didrocks> oSoMoN: bug #1255999
[15:15] <pitti> rsalveti: I added some initial possible points of injection/mocking to http://pad.ubuntu.com/sensors-testing
[15:15] <didrocks> eat that one then ;)
[15:15] <didrocks> oSoMoN: I think you will agree on the sane language part ;)
[15:16] <pitti> rsalveti: to be discussed tomorrow with tvoss_ and kalikiana_ for which of those are feasible/practical/useful, and perhaps add some more
[15:16] <oSoMoN> hehe, love the "sane language" thing :)
[15:16] <rsalveti> let me check
[15:16] <didrocks> ;)
[15:17] <oSoMoN> tmoenicke, hey, are you aware of bug #1255999
[15:18] <tmoenicke> oSoMoN: nope, thanks
[15:20] <Ursinha> ogra_, about bug 1255999, do you have it consistently or only every now and then?
[15:21] <ogra_> Ursinha, no kbd at all since upgrading to r32
[15:21] <didrocks> Ursinha: consistenly if we don't use english
[15:21] <Ursinha> ogra_, didrocks, right, because I have an intermittent issue that the keyboard doesn't come up when focusing on a textarea, mostly on browser
[15:22] <Ursinha> I have to close it and open again when it happens, but it seems to be another issue
[15:22] <didrocks> Ursinha: yeah, I was thinking first that it's that one that ogra_ was discussing about
[15:22] <didrocks> Ursinha: I even have it in the saucy touch
[15:22] <Ursinha> didrocks, do you know if there's a bug for that? I saw that happen since r10
[15:22] <Ursinha> ah, so it's old
[15:23] <didrocks> Ursinha: yeah, I don't know if there is a bug, it was always there, I hoped that keyboard crash fixes would fix it, but not…
[15:23] <Ursinha> didrocks, I can file one
[15:23] <rsalveti> ricmm: tvoss_: the sensors api is still provided by /system/lib/libubuntu_application_api.so, right?
[15:23] <tvoss_> rsalveti, yup
[15:24] <didrocks> Ursinha: yeah, would be good if we can get a start of knowing how to get it
[15:24] <rsalveti> just because I saw a libubuntu_hardware... in a header file
[15:24] <rsalveti> which we don't have
[15:25] <Ursinha> didrocks, okay, I'll see if I can find a bug and file one if I don't..
[15:25] <didrocks> thanks!
[15:29] <t1mp> hmm
[15:29] <t1mp> my galaxy nexus stays off (or it looks like that. screen is black, and I cannot connect to it via usb cable)
[15:29] <t1mp> I think the battery was empty, but since then I had it connected to power for a few hours.. still nothing
[15:29] <t1mp> I removed the battery and put it back, still nothing. I cannot switch it on with the power button.
[15:30] <t1mp> any ideas what I can try?
[15:31] <ogra_> t1mp, bug 1255045 probably
[15:32] <didrocks> depends if t1mp can't even see the google logo at boot
[15:33] <rsalveti> tvoss_: pitti: so it's basically qtsensors <-> qtubuntu-sensors <-> libubuntu-application-api1 <- using hybris -> /system/lib/libubuntu_application_api.so <- binder -> android sensor service
[15:33] <pitti> rsalveti: ack, thanks; that coincides with my understanding now
[15:34] <pitti> rsalveti: and everything up to and including libubuntu_application_api.so is in-process; it's binder which makes the "jump" between the app and the sensor service, right?
[15:34] <t1mp> ogra_, didrocks I think it had image 32 on it. and touching the screen doesn't help. I don't even see the google boot logo.
[15:34] <rsalveti> that's why it's hard to mock binder because what uses binder is android itself
[15:34] <rsalveti> pitti: yes
[15:34] <rsalveti> actually, you're right
[15:34] <rsalveti> it's all in-process
[15:35] <pitti> rsalveti: why? it's not a very hard protocol
[15:35] <ogra_> t1mp, oh, sorry, yeah, thats definitey not it then
[15:35] <t1mp> ogra_, didrocks it seems dead. I'll keep it connected to power for a few more hours and then try again.
[15:35] <pitti> rsalveti: I added it to the pad as it's the lowest possible point in the stack which we can still control, without going into Android itself
[15:35] <rsalveti> pitti: sorry, would be a bit harder if not all not part of the same process
[15:35] <ogra_> t1mp, if you have, try another USB cable too
[15:35] <pitti> rsalveti: and it's generally easier to mock stuff between processes than in-process
[15:36] <rsalveti> right, you'd just need a mock /system/lib/libubuntu_application_api.so
[15:36] <pitti> rsalveti: but yeah, we'll discuss the pros and cons in tomorrow's meeting
[15:36] <rsalveti> cool
[15:36] <pitti> rsalveti: right, that's another option; skip binder and hybris completely and instead provide pre-defined dummy results from the platform API functions
[15:36] <t1mp> ogra_: yeah. I'll try a different charger also to be sure
[15:36] <pitti> rsalveti: conveniently this gets dlopened, so we can tap into that, too
[15:37] <pitti> rsalveti: (slightly tricky as it's a hardcoded absolute path, but we could provide some mechanism for that in platform-api)
[15:37] <tvoss_> rsalveti, yup, as noted down in the pad iiuc
[15:37] <rsalveti> yeah
[15:37] <pitti> rsalveti: like a $UBUNTU_PLATFORM_API_PATH or whatever
[15:38]  * pitti adds that to the list of option
[15:38] <rsalveti> I just fixed the pad as it was saying /usr/lib/x86_64-linux-gnu/libubuntu_platform_hardware_api.so.1 was copied over to /system
[15:38] <pitti> s
[15:39] <Saviq> ogra_, q: does truncating the ssh.override file for you result in ssh starting automagically on boot?
[15:39] <ogra_> no
[15:39] <ogra_> it is a link
[15:39] <ogra_> you cant remove or truncate it, system-image will set it up again
[15:39] <pitti> rsalveti: thanks
[15:40] <Saviq> ogra_, well, it remains empty on boot
[15:40] <ogra_> right
[15:40] <Saviq> ogra_, and that's one of the reasons why it's bind-mounted
[15:40] <ogra_> which wont make ssh start
[15:41] <Saviq> ogra_, so that you can clear it and that should make ssh start
[15:41] <ogra_> that was my initial plan, yes
[15:41] <Saviq> ogra_, right :)
[15:42] <ogra_> but that doesnt work, since upstart uses inotify iirc ...
[15:42] <ogra_> which doesnt work with bind mounts
[15:43] <ogra_> my plan for this release is to have a property and update the override job to start conditionally based on that property
[15:43] <seb128> sil2100, pete-woods: libunityvoice1-dev should Depends on qtbase5-dev since its .pc has Requires Qt5Core
[15:43] <ogra_> but thats still a bit away
[15:43] <ogra_> as i need the time for this
[15:48] <seb128> sil2100, pete-woods: -DENABLE_TESTS=NO ... why not?
[15:51] <ricmm> pitti: rsalveti what pad is this you guys talk about?
[15:51] <ricmm> and why is this a topic separate from general platform API testing
[15:51] <pitti> ricmm: http://pad.ubuntu.com/sensors-testing
[15:52] <pitti> ricmm: it's not really separate, it's just one part that I got told we'd be starting with
[15:52] <pitti> ricmm: that pad just contains my notes from today, it's not anythign official
[15:52] <rsalveti> ricmm: guess more about understanding the stack to see how it should be tested
[15:52] <pitti> ricmm: as a basis for tomorrow's meeting, and understanding the stack well enough to see how/where we can inject test data
[15:55] <shashi> hii
[15:55] <ricmm> pitti: AFAIK the sensors service was meant to transition to ubuntu, that will mean a different IPC interface and API
[15:55] <shashi> i want to port this on my galaxy tablet
[15:55] <shashi> galaxy note 8
[15:55] <shashi> n5100
[15:55] <shashi> is it possible ?
[15:56] <shashi> plz help
[15:56] <pitti> ricmm: ah, so it'll soon stop using binder and libhybris?
[15:57] <pitti> ricmm: that's important information indeed; if that's planned, there's little sense in investing mocking at the binder level
[15:57] <ricmm> rsalveti: isnt this the plan?
[15:57] <ricmm> given, we dont really have any assigned to it... but the plan was for sensors (the main binder offender) to go to ubuntu
[15:57] <ricmm> anyone*
[15:58] <pitti> ricmm: so the long-term plan is to do it all from drivers in the ubuntu/linux kernel through sysfs?
[15:58] <ricmm> the long term goal is to write an ubuntu-side sensorservice
[15:59] <ricmm> probably in Go, with a DBus interface
[15:59] <ricmm> which we can easily mediate access to with jamie et al
[15:59] <tvoss_> pitti, ricmm I think the ubuntu-side service still has to use the android HAL, though
[15:59] <ricmm> certainly
[15:59] <ricmm> but we are not talking about the hal at all, pitti is talking about injection at the process boundary
[16:00] <rsalveti> ricmm: well, I believe our first step would be just to migrate the same service, iirc
[16:00] <ricmm> for which the service API needsto be defined
[16:00] <rsalveti> and then move away from binder
[16:00] <rsalveti> if we want to create another sensor service from scratch, then fine :-)
[16:00] <ricmm> well thats a decision that needs to happen *before* we mock the comm
[16:01] <ricmm> just saying it to be kept in mind
[16:01] <ricmm> as it wont be android sensorservice on android over binder forever, and technically the 14.04 plan is that it wouldnt be
[16:01] <pitti> ricmm, rsalveti: so as a first step it might be indeed better to create a libubuntu_application_api.so which returns mock results?
[16:02] <ricmm> pitti: in the general p-api testing plan the idea is to first make the platform API smart enough to dynamically load backend plugins
[16:02] <ricmm> instead of the separate SOs we currently ship
[16:03] <ricmm> then the first step is to provide a dummy one for the components, then make that dummy smarter to be a more dynamic mock backend
[16:03] <ricmm> does that make sense?
[16:03] <rsalveti> ricmm: standup :P
[16:03] <ricmm> rsalveti: sec
[16:03] <pitti> ricmm: yes, it does; making it possible to mock binder would enable us to do more kinds of testing, but if we are moving away from it that is a dead end
[16:04] <pete-woods> seb128, sil2100: unfortunately the tests need working pulseaudio to run, hence why there are also autopilot tests for it
[16:04] <rsalveti> indeed
[16:04] <ricmm> well exactly the first point would be just being able to plug any SO dynamically
[16:04] <seb128> pete-woods, ok
[16:04] <pitti> ricmm: so providing an alternative libubuntu_hw.so is better if *that* interface will stay around
[16:04] <ricmm> it could either be a dummy-return or a more robust mocked IPC
[16:04] <ricmm> the hardware API will stay as-is I believe, that one is direct hw access
[16:04] <ricmm> as-in it uses the HAL directly
[16:04] <pete-woods> seb128: I will add the missing dependency
[16:04] <ricmm> in process
[16:04] <pitti> ricmm: that of course would not test the platform-api backend itself (that would still need mockgin stuff at the binder level), but at least everything on top of it
[16:04] <seb128> pete-woods, thanks
[16:05] <ricmm> pitti: yes of course
[16:05] <pitti> ricmm: great, thanks for your input there
[16:05] <ricmm> pitti: at what time will the call be?
[16:05] <pitti> ricmm: 1000 UTC now
[16:05] <ricmm> 10:00 UTC ? geez thats early
[16:06] <pitti> ricmm: but as I said, I'm happy to do a followup call with you next week
[16:06] <pitti> ricmm: as we can't fit all relevant people into one time anyway
[16:07] <ricmm> I will be waiting to board at around 1300 UTC
[16:07] <mzanetti> cjwatson: hello, did you have a chance to think about this one yet? https://bugs.launchpad.net/ubuntu/+source/click/+bug/1251635
[16:08] <pitti> ricmm: updated the pad wiht this information
[16:11] <pete-woods> seb128: https://code.launchpad.net/~pete-woods/unity-voice/missing-dep/+merge/197096 if you're interested
[16:17] <seb128> pete-woods, thanks, approved
[16:20] <pete-woods> :)
[16:22] <lops> you guys coding for UP? where do you usually save your data? i'm kind of lost in the api docs
[16:23] <lops> save data in runtime, that is.
[16:26] <labsin> lops, You can save in ~/.local/share/<full-package-name>
[16:26] <labsin> that's the only folder you get access to by default (with the restrictions)
[16:26] <jdstrand> mardy: (I'm not really here but...) re eta> I figure next week. I want to write some test cases for apparmor-easyprof-ubuntu beyond the unit tests that can be run in image tests
[16:27] <labsin> lops, but it is best not to hardcode this directory
[16:29] <lops> thanks. what about in runtime? i don't yet understand how I'm supposed to use any vars that are in other source files.
[16:29] <labsin> lops, If you for instance need a Database, you can use U1Db and this will automatically save in that directory
[16:29] <labsin> lops, otherwise you can write a simple Qt cpp plugin for that.
[16:30] <lops> thanks labsin ;)
[16:31] <lops> i wish the docs were a bit more complete. they are pretty much useless now. :/ at least for qt newbies i guess
[16:33] <labsin> lops, If you plan on writing a plugin, just use the template and change as little as possible
[16:34] <lops> there's a template? where is that
[16:34] <labsin> lops, when you do new->project
[16:35] <labsin> the qml extention library + tabbed T... can be a good start
[16:35] <labsin> it's file-> new project
[16:36] <labsin> The best info on qt can be found when you but qt-project.org in the chrome address bar, then press tab and then type what you need from qt
[16:37] <labsin> lops, about the data storing, below is a question from the ubuntu-touch maillist. The follow-up mails can be interesting for you: https://lists.launchpad.net/ubuntu-phone/msg04835.html
[16:46] <lops> thanks labsin. those mails are useful indeed. however i still have doubts about data that has been read for a file and is on memory.
[16:47] <lops> i have javascript inside my QML page that is drawwing some plots. where should I keep the data for that plot? say, after reading in from the file.
[16:51] <pa> hi
[16:51] <pa> forgive me, but is ubuntu for nexus 10 officially available?
[16:51] <pa> and if not, is there a planned release date?
[16:52] <lops> the oficial sites talks about a Pre-release version for nexus 10
[16:53] <pa> so no official dates?
[16:54] <pa> 14.04 perhaps?
[16:54] <lops> sorry pa, not really aware of anything
[16:54] <ogra_> pa, 14.04 has a clear focus on tablets ...
[16:55] <ogra_> pa, (while 13.10 was focusing on getting the basic phone image proper)
[16:55] <ogra_> so with 14.04 N10 should work just fine
[16:55] <pa> ogra_, so there will be an official release, right?
[16:55] <ogra_> yes
[16:55] <pa> great, thanks
[16:56] <pa> after all, ubuntu touch could be the real successor of maemo/meego..
[16:57] <pa> as mer seems a bit.. how to say.. weird
[16:57] <lops> i don't understand why call this version 1.0
[16:57] <lops> when it's not finished...
[16:58] <labsin> lops, you could keep it in the cache folder: @{HOME}/.cache/@{APP_PKGNAME} or in a database
[16:58] <dragonkeeper> is there a ubuntu-touch .zip that can be flashed to put all the ubuntu stuff on the device . ?
[17:00] <lops> labsin, i should save to disk things like lists of values?
[17:01] <labsin> lops, what kind of data do you have and how do you need to use them afterwards? Maybe a Database suits better?
[17:03] <lops> labsin, i have a list of numbers and I want to draw a chart. i'll explore databases
[17:04] <labsin> lops, or just keep it as a list in javascript or in a custom cpp extention then it stays in memory (if it's not THAT big)
[17:05] <lops> labsin, i might try an external javascript file. right now i only have javascript inside "onPaint" inside my Canvas in qml
[17:06]  * ogra_ hugs davmor2 ... thanks for the mail :)
[17:07] <davmor2> ogra_: it took me a while to get to it :D  I was still playing catch up from my week off :)
[17:19] <Droidrider> Il y a t-il des Français ici ?
[17:53] <cjwatson> mzanetti: I haven't looked at it at all yet.  I'm spending a couple of weeks working on GRUB.
[17:53] <dragonkeeper> whats different about the ubuntu boot.img ?
[17:54] <ogra_> different in regard to ?
[17:54] <dragonkeeper> the stock android boot.img
[17:57] <ogra_> well, an android boot.img carries the android rootfs inside
[17:58] <ogra_> the ubuntu boot.img has a normal ubuntu  initramfs in it (not much different from what you have on your desktop) to mount the readonly ubuntu rootfs image
[17:59] <dragonkeeper> ok so in theory if i only had the boot.img  for ubuntu and flashed that then flashed a normal cm10.1 and then flashed saucy-preinstalled-phablet-armhf.zip  ubuntu would boot
[18:00] <ogra_> if your kernel is properly configured to run ubuntu it would most likely boot you ointo an ubuntu rootfs without UI ... you should be able t access it with adb
[18:01] <ogra_> to get a UI you will need an android system.img with the modifications explained on the porting wikipage from the channel topic to run it inside the lxc container
[18:02] <dragonkeeper> hmm alright . and just out of interest how many bytes is the ubuntu boot.img ?   or does it change depending on device
[18:02] <ogra_> (graphice, modem and sensor drivers are handled inside the lxc container
[18:02] <ogra_> )
[18:03] <ogra_> it should be below 8M
[18:03] <ogra_> or around that size
[18:03] <dragonkeeper> cool i have 7.3
[18:03] <ogra_> the size is really only limited by the partitioning your device has
[18:04] <dragonkeeper> thats all ive managed to get so far, which is why i asked . i cant seem to get the rest to compile
[18:04] <ogra_> https://wiki.ubuntu.com/Touch/ContainerArchitecture
[18:05] <ogra_> that has some more detailed info about the boot process
[18:07] <dragonkeeper> ogra_ Thanks , would you be able to help me solve compile errors ?
[18:07] <ogra_> dunno, got a log with them ?
[18:07] <dragonkeeper> i can pastebin all my output
[18:07] <ogra_> rule of thumb: you never want to compile anything with APP in its path ... rip out all these bits from the makefiles
[18:08] <ogra_> they are usually requiring dalvik which we dont have
[18:09] <dragonkeeper> http://paste.ubuntu.com/6490637/  ogra_
[18:13] <dragonkeeper> ogra_, if i run it again i get this one as well http://paste.ubuntu.com/6490662/
[18:13] <ogra_> i dont think we use stagefright, you should be able to safely drop it
[18:14] <ogra_> there is no error in the second one
[18:14] <dragonkeeper> its in the folder ubuntu tools made  frameworks/av/media/libstagefright
[18:16] <dragonkeeper> how would i pull it out without causing more errors
[18:17] <ogra_> sergiusens, rsalveti, any hint for dragonkeeper
[18:19] <sergiusens> I don't think we are using the software decoders from stagefright so you can just disable that
[18:19] <dragonkeeper> sergiusens, how ?
[18:19] <sergiusens> remove it from the makefiles?
[18:20] <sergiusens> and if it's too intertwined edit the code
[18:20] <sergiusens> is this based on a later version than cm10.1?
[18:20] <dragonkeeper> no its cm10.1
[18:20] <sergiusens> you can also backport the code changes if there were any
[18:20] <sergiusens> ogra_, we use stagefright for the hw decoding
[18:22] <ogra_> sergiusens, oh, i thought it was completely gone, my bad then
[18:22] <sergiusens> ogra_, nah, I might be mistaken
[18:23] <ogra_> heh, we need the salveti ....
[18:23] <sergiusens> anyways, removing it completely will only break video playback, so it's a start for a first build
[18:23] <dragonkeeper> either way its stopping me from compiling lol
[18:23] <ogra_> yeah
[18:27] <studebakerch> i cant find the correct command code for Terminal to flash factory image of nexus 7 back
[18:27] <dragonkeeper> ok took it out of build/core/main.mk   just gotta see what happens now
[18:28] <daker> studebakerch: https://wiki.ubuntu.com/Touch/Install#Restoring_Android
[18:28] <studebakerch> i used the command "run ./flash-all.sh " but it said it wasnt the correct command
[18:29] <dragonkeeper> cant u use fastboot ?
[18:29] <daker> studebakerch: without "run" just ./flash-all.sh
[18:34] <dragonkeeper> ogra_ looks like its hardwired . its in alot of files
[18:35] <dragonkeeper> grep -r -H "/libstagefright" * > ../removestuff
[18:35] <dragonkeeper>  is listing all files and lines containing libstagefright .  anyway i can use the output and automate it so all lines get changed to a space ?
[18:36] <AndrewSPX> hi there..
[18:36] <AndrewSPX> anyone ?
[18:36] <dragonkeeper> shhh he wont see us
[18:36] <AndrewSPX> :)
[18:37] <AndrewSPX> i just wonder if i can install ubuntu touch on my HTC One S
[18:37] <dragonkeeper> yes
[18:37] <AndrewSPX> can you help me with some download links ?
[18:37] <AndrewSPX> with the corect package
[18:38] <dragonkeeper> currently supported https://wiki.ubuntu.com/Touch/Devices
[18:38] <AndrewSPX> i saw that
[18:38] <AndrewSPX> but is not mentioned my phone there
[18:38] <dragonkeeper> ok if your device isnt there ull have to do what im doing
[18:38] <AndrewSPX> is just HTC One X
[18:38] <dragonkeeper> https://wiki.ubuntu.com/Touch/Porting
[18:39] <AndrewSPX> what shoud i do there?
[18:39] <dragonkeeper> go through it and it will tell u how to port ubuntu-touch to your device
[18:40] <AndrewSPX> sounds complicated
[18:40] <AndrewSPX> i'm not programmer
[18:40] <AndrewSPX> or something
[18:40] <AndrewSPX> just regular user
[18:40] <dragonkeeper> doesnt get done by its self sadly  if u want it badly enough thats what ull need to do, or wait for someone else to do it
[18:41] <AndrewSPX> well.. i think is better to wait
[18:41] <AndrewSPX> and another thing...
[18:41] <AndrewSPX> why you guys don't join undernet ?
[18:41] <AndrewSPX> is hard for me to come here
[18:42] <dragonkeeper> theres no ops/owners here
[18:42] <AndrewSPX> uhm?!
[18:42] <AndrewSPX> here are no ircops ?
[18:42] <AndrewSPX> or ops ?
[18:42] <AndrewSPX> X ? Q ?
[18:42] <AndrewSPX> something ?!
[18:43] <dragonkeeper> the owner of this channel isnt here  or ops so i assume no offical ubuntu team members monitor this chat , as its offical channel  i doubt it will be moved by commenting in here
[18:43] <AndrewSPX> ok..
[18:44] <AndrewSPX> let it go..
[18:44] <AndrewSPX> i got a problem with ubuntu on pc
[18:44] <dragonkeeper> o.O
[18:44] <AndrewSPX> is about that bar
[18:44] <dragonkeeper> thats #ubuntu
[18:44] <AndrewSPX> aa ok
[18:44] <AndrewSPX> thx anyway :)
[18:44] <daker> dragonkeeper: it's an official channel
[18:45] <dragonkeeper> daker yes i know it is :S
[18:54] <nhaines> dragonkeeper: there are loads of Canonical employees and Ubuntu members (hi!) here.
[18:55] <nhaines> dragonkeeper: no one's op because no one needs to be op.  Anyone with channel access can issue commands through chanserv.
[18:56] <dragonkeeper> awesome
[18:59] <nhaines> dragonkeeper: The reason this (and all Ubuntu-related channels) are on Freenode is because Freenode is specifically built to host Free Software development.
[18:59] <nhaines> So there's a big chance that upstream and related projects are also on Freenode.
[19:01] <dragonkeeper> nhaines, yes probs are . tbh though it doesnt really bother me what server people host on
[19:01]  * dragonkeeper has his head in source code
[19:08] <labsin> Anyone want to try my new published app? It's in the click store right now and is called Falling Blocks
[19:50] <nhaines> dragonkeeper: I am telling you this so that the next time someone asks and you want to answer them, you have accurate information to give them.
[19:55] <rsalveti> ogra_: sergiusens: dragonkeeper: you can disable the software decoders as it's not currently used, but libstagefright is needed if you want accelerated video decode to work
[19:55] <rsalveti> but we'll be supporting the software decoders as well, soon :-)
[19:56] <rsalveti> wonder why this is failing though, were you able to build CM first for your target?
[20:00] <Ursinha> ogra_, my screen frozen when I was unlocking it, how can I check what's going on? there's no crash in /var/crash
[20:19] <rsalveti> Ursinha: is the device still up?
[20:20] <Ursinha> rsalveti, it was, I was able to adb shell and everything looked okay, but screen was frozen
[20:20] <Ursinha> I had to reboot
[20:20] <Ursinha> not even power button did it
[20:20] <Ursinha> reboot as in adb shell; reboot
[20:20] <rsalveti> Ursinha: right, maybe an issue with mir
[20:20] <Ursinha> rsalveti, there was no new crash on crash folder
[20:20] <rsalveti> Ursinha: checking /system/bin/logcat might also be useful when it happens
[20:21] <Ursinha> okay, will do that next time, thanks
[20:21] <rsalveti> and trying to strace the process id as well
[20:21] <rsalveti> see if the process is completely stopped or just not rendering at the display
[20:23] <Ursinha> rsalveti, the process being mir? or what?
[20:24] <rsalveti> Ursinha: unity8 in this case (mir and unity8 are both the same process)
[20:25] <Ursinha> right
[20:36] <sergiusens> Ursinha, rsalveti also check ~/.cache/upstart/unity8.log
[20:37] <Ursinha> sergiusens, is that reset every reboot?
[20:37] <sergiusens> not really, just rotated
[20:42] <rsalveti> sergiusens: are we rotating .cache as well?
[20:43] <seb128> rsalveti, why would you rotate cache? by definition that's datas that are not useful to store
[20:43] <rsalveti> seb128: just concerned about the amount of disk space that the logs might end up using over time
[20:43] <seb128> rsalveti, clean those, don't rotate them
[20:44] <rsalveti> seb128: right, but are we doing any atm?
[20:44] <seb128> rsalveti, g-s-d on the desktop is e.g cleaning thumbnail that didn't get accessed for some time
[20:44] <sergiusens> rsalveti, seb128 the why's I don't know, but I have a [1-9].gz of every job
[20:44] <rsalveti> interesting, might be an upstart specific thing then
[20:44] <seb128> we should have some housekeeping service
[20:45] <seb128> g-s-d is doing that on the desktop, we don't have anything on touch though
[20:45] <rsalveti> right
[22:27] <Guest34670> Any idea how i can connect to WLAN
[22:30] <Guest34670> No one?
[22:35] <johnnyD> Hi
[22:35] <johnnyD> Anyone here?
[22:36] <johnnyD> I have fresh installed ubuntu on nexus 4 but have no wifi connection any ideas how to get it working?
[22:37] <johnnyD> Wifi hardware seems to be enabled
[22:40] <johnnyD> Nmcli returns no wifi device
[22:41] <johnnyD> No one here?
[22:41] <johnnyD> Or no clue
[22:57]  * xnox this channel is now going into a soft sleep mode. if you have answered questions please try sending email to the ubuntu-phone mailing list.