[00:03] dragonkeeper, http://paste.ubuntu.com/6487169/ [00:04] 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] TechieElf that looks the same as the previous one [00:05] TechieElf, use abootimg to extract the boot img and hack around init [00:06] sergiusens: I'm not familiar with abootimg [00:08] I've installed it now. How exactly do I do this? [00:14] 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] dragonkeeper, well get rid of the nfc stuff [00:16] * sergiusens checks out [00:20] ok [00:21] i have an install question [00:23] i have phablet-tools installed.. i have a nexus 7 grouper.. trying to install from the bootloader...l possible?? [00:24] rhosigma, from Android [00:25] so i cant install from bootloader? [00:28] I did not [00:28] just run the command [00:29] https://wiki.ubuntu.com/Touch/Install#Step_4_-_Downloading_.26_Deploying_Image_to_Device [00:31] Can someone help me troubleshoot my boot loop? I have the last_kmsg: http://pastebin.com/8ZQLixZv [00:37] better to use channel devel or channel stable [00:37] ?? [00:40] woo looks like i9505 jfltexx "samsung galaxy s4" port is building :) [00:43] do you think its better to use channel devel or channel stable [00:44] rhosigma: stable unless you're a dev [00:45] ok thanx [00:45] rhosigma: No problem [01:00] http://pastebin.com/KrvSEaBW how do i resolve this build error? [01:22] http://pastebin.com/KrvSEaBW how do i resolve this build error? === kdub is now known as kdub^holiday === Namidairo`bnc is now known as Namidairo === duflu_ is now known as duflu [02:08] given up , time to sleep. only a few more compile errors to fix for i9505 === Namidairo is now known as Namidairo`bnc === Namidairo`bnc is now known as Namidairo [02:40] heyy === vying is now known as Guest42268 === anders3408 is now known as anders3408|away === chihchun_afk is now known as chihchun [06:21] hello everyone === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:47] good morning [07:54] dholbach: good morning :) [07:56] hi nhaines [07:57] dholbach: I'm just backing up my Galaxy Nexus before I switch back over to Ubuntu again for a week or two. [07:57] awesome [07:57] Do you suspect 13.10 or trusty is going to be more exciting? [08:07] nhaines: trusty === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [08:14] popey: heh, the more testers the better, eh? [08:14] well indeed! [08:15] 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] Probably after I have a chance to test that package that keeps getting bounced back, I'll jump to trusty. [08:17] Speaking of, if anyone wants to review my pending click package... I once again think I've nailed down all the issues. [08:18] popey: is there any more development ongoing with Ubuntu 13.10 or is everything devoted to trusty now? [08:24] nhaines: there was talk of spinning an updated 13.10 [08:25] nhaines: approved your app [08:26] 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] are you testing it yourself locally with the click-reviewers-tools ? [08:29] Not for this webapp, but I'll incorporate that into my workflow when I sit down to build my first real app. [08:31] yeah, very wise [08:35] 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] you can take screenshots with mir [08:38] https://bazaar.launchpad.net/~popey/+junk/phablet-flash-wrapper/view/head:/mirfbdump that kind of thing [08:39] Not on maguro. [08:40] Also if this has changed than I will be happy. [08:40] oh, ok [08:40] no idea [08:40] i dont have a maguro, sorry [08:41] I guess I'll find out. Mir used to thrash and die sometimes on maguro when the framebuffer was dumped. === chriadam is now known as chriadam|away [09:02] Okay, time to figure out how to upgrade to trusty. [09:03] I'd like to believe that 'adb shell system-image-cli -v --channel trusty -b 0' will do the trick. [09:07] popey: fyi, I get pure black images when using mirfbdump on maguro on 13.10. [09:21] nhaines: that command should work [09:23] popey: it doesn't appear to have done so. :( Well, guess I'll just figure out how to phablet-flash it. [09:24] nhaines: phablet-flash ubuntu-system --channel=trusty [09:24] popey: extremely helpful. Thank you very much. [09:25] np === jcollado is now known as jcollado_afk [10:04] hi, on which tablets is it possibile to install ubuntu? [10:18] mardy: ping [10:18] 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] and elopio has another MP on top of that [10:19] pitti: for your information, we also eat stuffing and mashed potatoes! [10:19] pitti: I need to update the other one. [10:19] elopio: I think it'll merge cleanly to trunk once the pep8 one lands [10:19] nhaines: what, no alcohol? [10:20] that would be nice. I'll keep an eye on it. [10:20] pitti: well, obviously we need to have something to wash it down with after. :) [10:21] ogra_, lool: it got held up way too long by the e-d-s transition already :) [10:21] nhaines: *phew* :) [10:21] pitti, done [10:21] ogra_: danke [10:21] pitti: I was about to ask whether I need to run test this given it's pep8 fixes [10:22] lool: well, better that than adding a "[X] trivial fix" which then gets abused :) [10:22] and these can introduce hard to see errors as well [10:23] like forgetting a trailing comma or whatnot [10:24] pitti: FYI: [10:24] tests/autopilot/dialer_app/tests/__init__.py:16: 'GreaterThan' imported but unused [10:24] tests/autopilot/dialer_app/tests/__init__.py:22: 'sleep' imported but unused [10:24] lool: https://code.launchpad.net/~elopio/dialer-app/fix1250275-pyflakes/+merge/194776 :) [10:24] lool: that's the branch that goes on top of the PEP8 one [10:25] :-) [10:25] lool: so once that's merged, I'll ask ogra or you to top-approve that one [10:25] that'll re-run the tests which should succeed now [10:25] (again, e-d-s uninstallability had made it fail for three weeks or so) [11:11] sil2100: pong (saw your bug report) [11:11] Morning all [11:12] ogra_: r35 installing [11:13] davmor2: do you have mako or maguro? [11:13] davmor2: also, do you have a list of tests you're doing manuall [11:13] +y [11:14] popey: I only have maguro [11:14] (morning btw) === MacSlow is now known as MacSlow|lunch [11:28] Morning all [11:32] popey: oh although I have a grouper too thinking about it :) [11:34] Can someone help me troubleshoot my bootloop? Here's the last_kmsg: http://pastebin.com/8ZQLixZv === chihchun is now known as chihchun_afk === _salem is now known as salem_ [11:41] mardy: any idea what's up with that problem of mine? [11:45] 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] 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] pitti: surprized by the From -> from fix, did this fail the tests before the change then? [11:53] 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] lool: no, I was quite surprised that this worked [11:54] I thought "From" wasn't valid python [11:54] weird [11:54] yeah [11:54] maybe it's super old Python and cheap to keep supporting [11:54] lool: it was already reviewer-approved, only needs top-approval now [11:54] this will also re-trigger the tests [11:58] pitti: Yeah, I just wanted to do a preliminary review for myself, to top approve immediately once ready [12:08] sil2100: not yet, I'll check it a bit later === chihchun_afk is now known as chihchun [12:43] Good morning everyone. === MacSlow|lunch is now known as MacSlow [12:47] Hey there. [12:47] hey ! === jalcine- is now known as jalcine [12:47] I still have my nexus 4 and I guess I'm at the point where I want to give touch a try. :) [12:47] I started to follow the wiki, up to the point of "adb backup -apk -shared -all" [12:48] The resulting backup.ab file is 2 gig in size, which somehow gives me the impression, that adb has troubles with LFS? [12:48] it was mentioned by someone that adb may have a size limit it can pull [12:49] 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] contacts and calendar are synced to my own davical instance, and I checked the postgres database, so that's not the issue. === dandrader is now known as dandrader|afk [12:50] And my photos are synced to dropbox anyway. But I still have this gut feeling that something bad might happen. [12:50] Should the "sudo fastboot oem unlock" influence the current installation somehow? === gustavold1 is now known as gustavold [12:51] i think it wipes all userdata [12:51] i.e. a factory reset [12:51] it does yes [12:52] but you can then restore from your backup file and it should be the same as before you unlocked it [12:52] Well, given that the backup file is only 2g, I highly doubt that. :) [12:54] I have seen issues with files over 2GB too [12:54] so i wouldn't trust that backup [12:54] and would expect to lose everything on the phone [12:55] Those are my expectations anyway ☻ [12:55] I would use something that doesn't rely on adb [12:55] some network push of the backup [12:55] mtp should work too, no ? [12:56] not everything is exposed over mtp [12:56] indeed you would have to tar it up via adb in an accessible folder or so [12:56] ogra_, that would work === chihchun is now known as chihchun_afk [12:59] if you have clockworkmod recovery already, try http://wiki.cyanogenmod.org/w/ClockWorkMod_Instructions#Making_a_backup === dandrader|afk is now known as dandrader [13:05] lool: mind top-approving https://code.launchpad.net/~elopio/dialer-app/fix1250275-pyflakes/+merge/194776 now? the pep8 one just got merged [13:09] pitti: yup, done [13:09] lool: merci === alan_g is now known as alan_g|lunch [13:21] 'morning [13:32] am I typing something wrong here? [13:32] tim@ideapad:~$ phablet-flash ubuntu-system --channel trusty-devel [13:32] INFO:phablet-flash:Device detected as manta [13:32] INFO:urllib3.connectionpool:Starting new HTTPS connection (1): system-image.ubuntu.com [13:32] ERROR:phablet-flash:https://system-image.ubuntu.com/trusty-devel/manta/index.json cannot be retrieved [13:34] what is trusty-devel ? [13:34] :) [13:35] (you want trusty-proposed or devel-proposed (they are the same)) === Namidairo is now known as Namidairo`bnc === ondra is now known as ondra|lunch [13:43] ogra_: oh, trusty and devel are the same now, finally? [13:43] yep [13:43] saucy is stable [13:44] lool, oh, btw, there is a saucy-proposed image containing your SRU now [13:44] ogra_: cool [13:44] ogra_: I dont have to retest it though, I guess it's just generic image testing at this point? [13:44] cause I reupgraded to trusty already [13:44] yeah, i guess so [13:45] ogra_: great, that was rather confusing a few weeks ago === Namidairo`bnc is now known as Namidairo [13:45] yeah ... took a bit until we got there ... i hipe we can be faster next release [13:45] *hope === Ursinha-afk is now known as Ursinha [13:54] * ogra_ grumbles about blueprints .... how do i add a WI thats owned by more than one person :/ [13:55] ogra_, help, we're getting mind-twisted here... [13:55] haha [13:55] ogra_, we're executing some commands over ssh [13:55] ogra_, to build/run unity8 on the device === psivaa is now known as psivaa-lunch [13:56] ogra_, so, starting with "ssh phablet@mako" [13:56] ogra_, that doesn't get us the env from upstart [13:58] ogra_, case in point [13:58] jdstrand: hi! Do you have an ETA for https://bugs.launchpad.net/ubuntu/+source/apparmor-easyprof-ubuntu/+bug/1245903 ? [13:58] Ubuntu bug 1245903 in apparmor-easyprof-ubuntu (Ubuntu) "Online Accounts applications need a couple of more D-Bus interfaces" [Undecided,In progress] [13:58] ssh phablet@mako 'echo ${QML2_IMPORT_PATH}' [13:58] vs. [13:58] did you check your quoting ? [13:58] ssh phablet@mako 'bash -ic 'echo ${QML2_IMPORT_PATH}'' [13:58] ogra_: the whole day long :D [13:58] ogra_, yeah, many times ;) [13:58] ogra_, the first one prints, the second one doesn't [13:59] actually, the quoted example does work... its the one where quotes shouldn't be needed that doesn't [13:59] Saviq, why would you use the second one with ssh ? [13:59] ogra_, to get the upstart env? like dbus? [14:00] ogra_, our complete thing is: [14:00] that should be achieved by the first one already ... starting bash only fires up an additional subshell ... [14:00] Mirv, sil2100: it seems you've done some work on QtSensors/qtubuntu-sensors? [14:01] ogra_, look at the difference between 'ssh phablet@mako env' and 'ssh phablet@mako sudo -u phablet -i env' [14:01] (which would be good when using adb but should not be necessary with ssh, where pam is processed at login already) [14:01] Can someone please help me troubleshoot this annoying boot loop? I have the last_kmsg [14:01] ogra_, the one without sudo doesn't include UPSTART session etc. [14:01] ogra_, I think the problem is that bash is called without -i [14:01] hmm [14:01] ogra_, when... it's not -i [14:01] pitti: hi! In my case it was mostly packaging-related though - what's up? [14:01] ogra_, and that's when it doesn't include the env [14:01] let me set up an ssh env here ... [14:02] ogra_, so our whole thing is: [14:02] sil2100: I'm tasked with investigating how to create integration tests for sensors [14:02] sil2100: so I've looked at libhybris, qtsensors-opensource-src, and qtubuntu-sensors [14:03] ssh phablet@mako sudo -u phablet -i bash -ic \"$@\" [14:03] sil2100: libhybris is rather clear, but the latter two are mostly just C++ skeleton; I have some trouble finding the actual meat [14:03] ogra_, I know that's tragic, but that's the only thing that worked for us [14:03] sil2100: the only meat I've found is in src/plugins/sensors/ in qtsensors-opensource-src [14:03] ogra_, and now we noticed that as soon as we ./ another script from that - the env is lost again [14:04] 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] d [14:04] sil2100: so I guess I'm missing something; what connects the dots between QtSensors and libhybris? [14:04] sil2100: or are we using qtsensors-opensource-src's android backend? [14:05] 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] kalikiana_: ^ [14:05] sil2100: ah, thanks [14:06] kalikiana_: hey Christian, how are you? [14:06] kalikiana_: could you backtrack a bit up and try clearing up the situation? [14:06] kalikiana_: so iahmad gave be some briefing this morning, but apparently he was missing something [14:07] pitti: hey [14:07] you want to know something about sensors? [14:07] kalikiana_: yes; jfunk asked me to team up with some sensors dev to discuss how to create some initial integration tests [14:08] kalikiana_: so as a first step I'm trying to understand the architecture of the various layers [14:08] 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] so for instance the vibration backends for QtFeedback can't be re-used [14:08] kalikiana_: so, I read the sensor bits from libhybris; I guesss that's the low-level API that we use? [14:08] the stuff ie MeeGo uses is not open [14:09] pitti: yep regarding usage kalikiana is knowledgeable [14:09] pitti: it depends on what you mean by 'sensor' there's a cuple Qt APis that require backends [14:09] kalikiana_: so, QtSensors is mostly C++ typing/signalling/adapter classes around possible backends like android, simulator, or the qtubuntu-sensors backend, right? [14:10] Saviq, did that change recently ? [14:10] ogra_, I don't think it did [14:10] kalikiana_: well, qtubuntu-sensors' description says "libhybris" backend, but there's nothing hybris-y in that [14:10] ogra_, we had this sudo/bash thing that work around it [14:10] (there was more cgroup stuff added in trusty afaik) [14:11] ogra_, but we started using a script in one of the calls [14:11] 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] 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] ogra_, and that script does not inherit the env [14:11] ogra_, it wasn't critical for us so no one complained much [14:11] right, you would have to wrap it into another subshell call [14:12] ogra_, meaning bash -ic? tried that - it actually didn't work.. [14:12] no, a fully wrapped sudo i fear [14:12] pitti: hybris is used for camera. it's not "the" api because there's different things there [14:12] ogra_, whoah [14:13] ogra_, that would get us back to $HOME? [14:13] kalikiana_: ah, so we are not using libhybris for the sensors; how do we get them from Android then? [14:13] pitti: for instance QtFeedback is based on writing to /sys/something and will soon use usensord which is a service [14:13] Saviq, it should., yeah [14:13] ogra_, we need to be in $HOME/shell for that... [14:13] ogra_, or well, fix the script, FWIW [14:13] got a pastebin with the script or some such ? [14:14] ogra_, just 'echo $QML2_IMPORT_PATH' [14:14] pitti: it would help to be more specific than "them"… there's lots of different plugins :-) [14:14] ogra_, well, the script is http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/run [14:14] ogra_, ran on device by http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/run_on_device [14:15] ogra_, run_on_device:109 calls ./run via ssh [14:15] 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] kalikiana_: where hw sensor == orientation sensor, in this case [14:16] mardy: any luck with the bug? Am I doing something wrong when running the tests? [14:16] kalikiana_: (it looks like we implement orientation and accel ATM? ) [14:16] sil2100: sorry, I'm still investigating another bug [14:17] 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] pitti: accelerometer and location come from libplatform-api-headers [14:17] those are used to implement the qt backends [14:17] mardy: let me try, one moment [14:19] i seriously would appreciate some assistance with my boot loop problem.. can someone help? I have the last_kmsg.. [14:19] kalikiana_: ah, so platform-api provides the actual sensor reading, and qtubuntu-sensors is just glue code? [14:20] mzanetti, Saviq, how about using #!/bin/bash in http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/run :) [14:20] tried that [14:20] pitti: yes [14:20] ogra_, not enough [14:20] ogra_: Saviq: no difference [14:20] hmmm [14:20] ogra_, again, does not do --interactive [14:20] tried adding -i to the shebang ? [14:20] ogra_, AFAICT, bash only loads the upstart env when ran with --interactive [14:20] mardy: ok, strange things happen [14:20] ogra_, did, no go [14:21] ogra_, at that point the env is borked somehow already [14:21] sil2100: such as? :-) [14:21] * Saviq tries again [14:21] Saviq, mzanetti thne source /pet/profile at the top of your script [14:21] /etc/profile [14:21] heh, funny typo [14:21] 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] mardy: dies and gets restarted in a clean state [14:22] ogra_, sure, that would help us, but hardly feels like the right solution... [14:22] greyback: ^ that might be the same crash that you were investigating, or maybe not :-) [14:22] well, i dont see a better one [14:23] 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] sil2100: mardy: yes I suspect the same. I'm working on it, it's annoying :) [14:23] ogra_, is it expected / by design that this happens? [14:23] Saviq, i guess thats the shell handling of ssh if you dont actually log in [14:24] else you wouldnt need all that sudo nonsense [14:24] 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] 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] ogra_, :'( [14:24] sil2100: I'll investigate tomorrow (I hope); they might be related, yes [14:24] mardy: which should be fine. [14:24] greyback: still, a window appears in unity [14:25] 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] greyback: while the process didn't create any [14:25] Saviq, the /bin/sh definitely wont process /etc/profile ... not sure how else we could set the vars we need ... [14:25] mardy: yes that's a bug/me being lazy [14:25] ogra_, well, shouldn't they be inherited from the "wrapping" environment? [14:25] ogra_: but isn't it weird that it drops the env? I mean, when calling the script it's there [14:26] 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] kalikiana_: ok, thanks [14:26] mardy: can you report a separate bug for that and assign to me please? Fix should be reasonably easy for me [14:26] ogra_, i.e. 'echo $FOO' works, but when you put that in a script and execute it with './foo', it's gone? [14:26] pitti, hey, how can I help? [14:26] 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] greyback: OK [14:26] tvoss_: hey, how are you? [14:27] tvoss_: I'm trying to understand the sensors API architecture [14:27] pitti, pretty good, thank you :) enjoying the US having public holidays a.k.a. the silence :) [14:27] mardy: online-accounts-ui will have to show up as separate app, until we've the window child/parent relationship stuff going [14:27] greyback: unity-mir or unity8? [14:27] greyback: yes, that's fine [14:27] 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] mardy: mark as affecting both. It's unity-mir primarily though [14:28] 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] pitti, yup, let me find one [14:28] tvoss_: (background: I got tasked to discuss the creation of sensor integration tests with $appropriate_developer) [14:28] and of course provide some initial tests [14:28] ogra_, sourcing /etc/profile, ~/.bashrc, nothing works :/ [14:29] thats cant be [14:29] adding ". /etc/profile" should definitely process the profile and profile.d [14:29] pitti, yup, let me see [14:29] ogra_: Saviq: the one we need is in /etc/environement [14:29] not sure how that gets sourced normally [14:29] mzanetti, right, that's an important point [14:30] ugh, that needs to be moved out there [14:30] pitti, so I have got https://docs.google.com/a/canonical.com/document/d/1Auu7Vjk8THFOjCnbWiTw0y7TqI2Njpd8UHY73_nqjOw/edit#heading=h.3wm9daqnlz9x [14:30] mzanetti, ogra_ right, so sourcing that helps... [14:30] great [14:31] well, do you know how it gets in there ? [14:31] * mzanetti doesn't [14:31] ogra_, me neither [14:31] it should move to become a profile.d snippet installed by a package [14:31] ogra_, qtubuntu then [14:31] so we can safely upgrade it if it changes [14:31] ricmm, do you know where the /etc/environment QML2_IMPORT_PATH comes from? [14:31] 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] Saviq, i suspect from the build scripts actually [14:32] ogra_, yeah, something like that [14:32] Saviq, the question is what the impact of moving it is ... [14:33] 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] ogra_, it's only there for unity8's consumption [14:33] preferably we should have an /etc/environment that doesnt differ from a desktop install [14:33] Saviq: you sure about that? [14:33] ogra_, so we can definitely improve that [14:33] Saviq: I could think of things inside Qt relying on it too [14:33] mzanetti, nothing else should be using the Applications module [14:33] mzanetti, it's not about the QPA [14:33] and have such bits live in profile.d sippets [14:33] mzanetti, it's the qml import path [14:33] mzanetti, standup, btw [14:33] pitti, today, the actual events are passed over to the client via binder, handed over the libc boundary via hybris [14:34] pitti, then dispatched via platform api to higher-level runtimes (like qt) [14:35] tvoss_: so libhybris connects to binder (in the client process) and translates that to the hybris/include/android/hardware/sensors.h API? === dholbach_ is now known as dholbach [14:35] pitti, hang on [14:35] tvoss_: right, I think I understand what's going on between platform-api, qtubuntu-sensors, qtsensors-opensource-src, and the app now [14:36] pitti, cool [14:36] tvoss_: I'm still missing the connection between platform-api and the android sensor service [14:36] tvoss_: e. g. src/ubuntu/hybris/ubuntu_application_sensors_hybris.cpp defines the functions [14:36] for qtubuntu-sensors (like uas_accelerometer_event_get_acceleration_x) [14:36] tvoss_: but they aren't actually implemented there, but just called from a dynloaded /system/lib/libubuntu_platform_hardware_api.so [14:37] pitti, yup, the dynloaded so lives in the container [14:37] so on the android side [14:37] 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] tvoss_: what package builds that? [14:38] pitti, we used to build it as part of the android source tree. ogra_ can you give some more detail here? [14:38] tvoss_: ah, got the file (it's actually in platform-api) [14:38] pitti, yup, in the android parts of it [14:39] pitti, iirc, that file does the translation of events [14:39] so libubuntu-platform-hardware-api1 ships /usr/lib/x86_64-linux-gnu/libubuntu_platform_hardware_api.so.1 === alan_g|lunch is now known as alan_g [14:39] so I guess we symlink/copy that into /system/ during image build time? [14:39] tvoss_, ogra_ ^ [14:40] tvoss_: indeed, that file looks promising; the last link in the chain between HAL/hybris and the app :) [14:40] i think thats a qeustion for ricmm or rsalveti [14:41] the bits of the android tree are indeed built at package build time of the android package [14:41] pitti, yup [14:41] and iirc the ubuntu bits are pulled in during build === psivaa-lunch is now known as psivaa [14:42] 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] (either from bzr or with lp-pull ) [14:43] pitti, yup [14:43] 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] tvoss_: do you think anyone else should participate in that, kalikiana_ or some other developer who works on that regularly? [14:44] pitti, +1 for kalikiana_, but that should be it [14:44] tvoss_: ack [14:46] 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? === dandrader is now known as dandrader|lunch [14:47] pitti, sure, tomorrow woul dbe best for me. I'm in London Monday to Wednesday next week [14:47] kalikiana_: does that work for you, too? some time around 9 or 10? [14:47] pitti, tomorrow morning works for me. [14:48] I'd say invite me, considering I wrote a lot of the latest one [14:48] but tomorrow I'm flying [14:49] 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] anyone know how to fix this http://pastebin.com/ziG7Y2dR , trying to compile port and it keeps throwing out errors [14:51] sure [15:00] 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] pitti: preferrably 11 so I'm mentally more focussed, though I can make it earlier if that's better for you [15:01] kalikiana_: 11 WFM, if it's fine for tvoss_ [15:05]