[00:00] <thomi> racarr: ok, log incoming
[00:01] <thomi> racarr: http://paste.ubuntu.com/6181800/
[00:01] <thomi> racarr: I don't see any mention of the uinput device
[00:02] <thomi> racarr: which is called 'autopilot-finger' BTW
[00:02] <thomi> racarr: in that log, the input events are me unlocking unity8 with my finger
[00:02] <thomi> no autopilot
[00:03] <thomi> I wonder about these two lines:
[00:03] <thomi> [EE, android-input] [EventHub]could not open /dev/input/event6, Permission denied
[00:03] <thomi> [EE, android-input] [EventHub]could not open /dev/input/event7, Permission denied
[00:05] <thomi> yeah, so when we create the autopilot touch driver, even6 and event7 appear on the /dev/input folder
[00:05] <racarr> thomi: i would say thats almost certainly it
[00:05] <thomi> not sure why we get 'Permission denied' though, the permissions on those device nodes are identical to all the others
[00:06] <racarr> I guess unity8 isnt run with root, but something sets the permissions on the /dev/input nodes it needs to something it can use
[00:06] <racarr> group?
[00:06] <racarr> apparmor?
[00:06] <racarr> secret-security-framework-number-9
[00:06] <thomi> group is all the same, android_input
[00:06] <thomi> who would I talk to about apparmor?
[00:06] <racarr> I dunno
[00:06] <thomi> Jamie maybe, if he's still awake
[00:06] <racarr> I bet ricmm would know more than me
[00:06] <racarr> ricmm_: ^ ?
[00:07] <racarr> maybe its a race with setting the permissions
[00:07] <racarr> and opening hte device
[00:07] <racarr> I dont know
[00:07] <racarr> where the permissions
[00:07] <racarr> comes from
[00:12] <kgunn> thomi: good grief...
[00:12] <kgunn> i mean how did that work prior to mir....shoulda been the same right
[00:14] <thomi> kgunn: racarr, OK, I've eliminated apparmor as a culprit
[00:14] <thomi> racarr: are you able to see what would cause that permission denied error in mir?
[00:17] <racarr> its the same error you get if you urn it on the desktop without
[00:17] <racarr> permissions to open the /dev/input devices
[00:17] <racarr> looking
[00:17] <thomi> I see it's in EventHub.cpp:961
[00:17] <racarr> Mm
[00:18] <racarr> errno doesnt lie
[00:18] <racarr> permission is denied
[00:18] <racarr> (kind of catchy when you say it outloud)
[00:18] <thomi> but...
[00:19] <thomi> http://pastebin.ubuntu.com/6181858/
[00:20] <thomi> what. thefuck. is. goingon!?
[00:20] <thomi> robert_ancell: does mir drop priviledges after starting up?
[00:20] <thomi> oops, I meant racarr ^
[00:21] <thomi> like, maybe when it loads initially, it's running as root, but then it drops to being run as a user that isn't root or in the android_input group?
[00:30] <racarr> not that I know of
[00:33] <robert_ancell> thomi, it does not
[00:33] <thomi> bums
[00:34] <racarr> is it possible the devices are being probed after mir opens , mir tries to open them fails, gives up, then they get given
[00:34] <racarr> the appropriate permissions?
[00:34] <thomi> I'll try creating the devices first, then starting mir
[00:50] <sarnold> are there devices that refuse O_RDWR but work fine for O_RDONLY ?
[01:17] <kgunn> thomi: any luck
[01:18] <thomi> kgunn: long answer: check out #ubuntu-touch scrollback. short answer, no luck at all. Have managed to stump several people much smarter than I am :-/
[02:17] <kgunn> thomi: i see you are basically left to contemplate the infinite in #touch...can you summarize where you are, maybe duflu in his inifinite linux device wisdom might have some tricks
[02:17]  * duflu thinks you have the wrong name there
[02:20] <thomi> kgunn: sure
[02:21] <thomi> actually, I should probably file a bug so my progress is not lost to the grey mist I'm happy to call my memory
[02:33] <kgunn> thomi: so this same thing works in SF ?
[02:33] <thomi> yup
[02:34] <thomi> just writing up a bug report. Will be done in a few minutes
[02:34] <kgunn> thomi: hmmm....by removing sf, could something not be setting wider permissions that should?
[02:34] <duflu> Thank you for not continuing the tradition of bugs that only exist in IRC
[02:34] <thomi> we looked pretty exhaustively at permissions
[02:34] <thomi> duflu: :)
[02:34] <thomi> this is a big one
[02:35] <kgunn> ditto to the documenting it in a bug
[02:42] <duflu> robert_ancell: Please stop removing distro tasks. They are absolutely required where bugs are reported against distro, and fixed in distro
[02:42] <robert_ancell> duflu, none of the other bugs have distro tasks and all mir bugs affect distro. There's no need to duplicate entries
[02:43] <duflu> robert_ancell: They're not duplicate. They clearly delineate where a fix is upstream or in distro
[02:43] <duflu> Launchpad is designed that way
[02:43] <robert_ancell> duflu, in the case of mir upstream == distro
[02:44] <duflu> robert_ancell: Not true. Our upstream fixes are usually days (or weeks) ahead of distro. And after we branch properly, months
[02:44] <duflu> Hence you need separate tasks
[02:44] <robert_ancell> duflu, when it's marked fixed released it's in distro
[02:45] <duflu> robert_ancell: No, that means fix released upstream (usually as a tarball). Hence Fix Released upstream often happens after distro in reality
[02:45] <robert_ancell> duflu, in reality our releases are done automatically and straight into distro. There's no tarballs
[02:46] <duflu> robert_ancell: You can't make up your own rules different to the rest of Ubuntu. People need and expect ubuntu tasks to know what's going on
[02:48] <robert_ancell> duflu, you can, we have, there's no point making ensuring ever bug has both an upstream and ubuntu task open on it. All Mir bugs are Ubuntu bugs, we've decided to track them all in the upstream tracker
[02:49] <thomi> duflu: kgunn, anyone else who cares: this is what I've been bashing my head against all day: https://bugs.launchpad.net/mir/+bug/1233944
[02:50] <duflu> robert_ancell: Anyone who uses Ubuntu and Launchpad knows that fixed in "Mir" does not mean fixed in "Ubuntu". We need to communicate more clearly and there's a simple protocol in place. Why not just make the bugs *accurate* ?!
[02:50] <kgunn> robert_ancell: racarr (if you're on) kdub ^
[02:50] <thomi> I will purchase many drinks for the person who solves this for me
[02:51] <duflu> robert_ancell: If you want, I will do it. I do so anyway. I just can't stand working in an environment where even the information describing what we're doing is wrong
[02:51] <robert_ancell> duflu, I'd say most people who use Launchpad don't know or care about the distinction between upstream and downstream tasks. The bugs are accurate.
[02:52] <robert_ancell> duflu, no, it's a huge amount of pointless paperwork
[02:52] <duflu> It's not huge, and it has a very clear purpose. Launchpad's bugs a multidimensional for good reason
[02:53] <robert_ancell> duflu, they were done like that because there was a large number of components that have different upstreams and downstreams. In this case that has not occurred. The software center team used this practise because it made things much easier and it matches my experience too
[02:54] <thomi> I gotta go walk in the pouring rain to clear my head for a bit. When I get back, I expect to see a bugfix waiting for me ;)
[02:54] <thomi> brb
[03:03] <robert_ancell> thomi, I'm looking at this bug but you probably know more about the input layer than me
[03:05] <robert_ancell> thomi, I'm a little unsure of what you mean in the report - does Mir never get input from these devices or only if they are created before Mir starts?
[03:05] <thomi> robert_ancell: mir is only able to open the devices if they exist before mir starts
[03:06] <robert_ancell> thomi, and you get the input events from them?
[03:06] <thomi> robert_ancell: well, I never got that far, but the open() call doesn't fail, which is what's happening in the error case
[03:06] <robert_ancell> thomi, so the bug essentially seems to be "mir fails to hotplug input devices"?
[03:07] <thomi> I guess so
[03:07] <kgunn> thomi: robert_ancell ...ok thinking aloud (and yes i'm a manager i'll try not to hurt myself)
[03:08] <thomi> robert_ancell: feel free to change the bug title :)
[03:08] <kgunn> but...it bothers me this is "3rd party code"..so i dig around in cynagenmod
[03:08] <robert_ancell> thomi, can you show me the code that creates the devices?
[03:08] <thomi> robert_ancell: sure... one second
[03:08] <kgunn> it seems that eventhub.cpp is built into either libui or libinput
[03:08] <robert_ancell> thomi, wondering if they're created with wrong permissions and then they're updated (just a guess)
[03:08] <kgunn> depending on when the change happened
[03:09] <thomi> robert_ancell: well, we use uinput, and the uinput system creates the actual event* devices
[03:09] <kgunn> so could one of these libs that is actually in the device be causing this? with some primordial android input setup code
[03:10] <thomi> robert_ancell: http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/input/_uinput.py#L192
[03:10] <kgunn> e.g. just like surfaceflinger would fight with mir over the display....maybe one of these is fighting mir for the input dev
[03:10] <thomi> basically, work out the device capabilities, and hand it all off to the kernel
[03:14] <robert_ancell> thomi, can you reproduce on the desktop or just the phone?
[03:15] <thomi> robert_ancell: I haven't tried on the desktop. Should I just run mir_demo_server, or something more complicated?
[03:15] <robert_ancell> thomi, that should be fine, you're just looking for the error message when they're created
[03:16] <thomi> ok, need to install some things first...
[03:18] <kgunn> thomi: reading your instructions...cd ~/autopilot, is that on the device ?
[03:18] <thomi> kgunn: yes
[03:18] <kgunn> ah i see it...forget to run setup after i reflashed
[03:19] <thomi> kgunn: that directory gets created when you run phablet-click-test-setup
[03:19] <thomi> yeah
[03:22] <thomi> robert_ancell: so I'm having problems testing mir on the desktop since I don't currently have a second machien to SSH into the first one, so I can't create the uinput devices after mir starts
[03:22] <robert_ancell> thomi, ah - what do I need to install to test it here?
[03:23] <thomi> robert_ancell: python-autopilot
[03:24] <robert_ancell> thomi, the archive one or a branch?
[03:24] <thomi> robert_ancell: archive is fine
[03:24] <thomi> make sure you export those mir env vars :)
[03:25] <robert_ancell> thomi, I can just run the contents of create_touch_device() to test this right?
[03:25] <thomi> robert_ancell: probably, yes
[03:25] <robert_ancell> (trying to break this down to the simplest repeatable case)
[03:26] <thomi> I usually just start the python interpreter, and write:
[03:26] <thomi> from autopilot.input import Touch; t = Touch.create()
[03:26] <thomi> simple enough for me :)
[03:26] <robert_ancell> ta
[03:26] <robert_ancell> brb
[03:35] <robert_ancell> thomi, seems to run fine on desktop
[03:35] <robert_ancell> thomi, but u-s-c is being run as root, the shell on the phone is being run as a user account right?
[03:38] <kgunn> thomi: as part of the instructions in the bug...do you assume they've loaded your python-ubuntu-platform-api deb ?
[03:40] <thomi> kgunn: ahhhh yes!
[03:40] <thomi> kgunn: thanks for that
[03:40] <thomi> robert_ancell: yesh, that's correct
[03:40] <thomi> kgunn: will update the bug now :)
[03:40]  * kgunn wonders if yesh is a michael scott/office reference
[03:42] <thomi> kgunn: bug updated
[03:42] <robert_ancell> heading out for 20 mins...
[03:51] <kgunn> thomi: should that same example AP test (ubuntu ui tookit) run on SF even with the new deb installed ?
[03:52] <thomi> kgunn: yes
[03:52] <thomi> kgunn: are you saying that it doesn't?
[03:52] <kgunn> thomi: verifying that now...
[03:53] <ricmm_> thomi: can you try with apparmor=0 passed to the kernel?
[03:54] <ricmm_> you can probably looking into our flash-kernel script to see how it constructs a blob with command line to flash
[03:54] <ricmm_> if that fails, make sure you put everything in the bug
[03:54] <ricmm_> and ill pick it up in the AM EST
[03:54] <thomi> ricmm_: we ruled out apparmor
[03:55] <thomi> I'm about to EOD, but the bug is pretty well documented
[03:55] <ricmm_> DENIED in syslog is not enough to rule it out
[03:55] <thomi> oh?
[03:55] <ricmm_> ruling it out is apparmor=0 in the kernel command line
[03:55] <ricmm_> some things are silent, or at least im told so :)
[03:56] <thomi> huh.. that's not what the apparmor guys said earlier. OK, so how do I chaneg the kernel parameter on the phone?
[03:56] <ricmm_> look into the flash-kernel script
[03:56] <ricmm_> but if you are about to EOD, go EOD
[03:56] <ricmm_> ill look into it tomorrow
[03:56] <ricmm_> midnight here
[03:56] <thomi> ricmm_: 'flash-touch-kernel'?
[03:58] <ricmm_> indeed
[03:58] <ricmm> anyways you've put enough in the bug, update with the apparmor result or just go and ill try it tomorrow
[03:59] <thomi> ok
[03:59] <thomi> I'll try and figure this script out, or eat dinner, whichever happens first :)
[04:02] <kgunn> thomi: i get https://pastebin.canonical.com/98327
[04:04] <thomi> kgunn: you need to be the phablet user: sudo -i -u phablet
[04:04] <thomi> kgunn: adding that bit of infomration to the bug as well :)
[04:04] <kgunn> gah
[04:06] <kgunn> thomi: op now i get the awesome testibilty arg prob
[04:08] <thomi> kgunn: the fact that you get a warning is not necessarily a sign that something broke. post your output somewhere?
[04:12] <kgunn> https://pastebin.canonical.com/98328 thomi
[04:13] <kgunn> again this is still just running with surface flinger
[04:13] <kgunn> stepping away to get a drink to stay awake
[04:14] <thomi> kgunn: you need to download https://raw.github.com/akkana/scripts/master/termsize and run it - get your terminal back :)
[04:14] <thomi> I mean that as an aside, it won't fix your problem
[04:14] <thomi> but it will make you less suicidal while developing on the phone :)
[04:15] <thomi> kgunn: hte unknown option is a red herring. Your actual problem is this: MismatchError: After 10.0 seconds test on Standard.selected failed: True != dbus.Boolean(False, variant_level=1)
[04:16] <thomi> kgunn: I'm *sure* this worked for me earlier today... let me reboot & double check
[04:26] <thomi> kgunn: ahhh, you need to unlock the shell before you run the test
[04:27] <thomi> kgunn: yeah, that'll be it
[04:28] <thomi> OK, I gotta go help with dinner
[04:28]  * thomi -> BBL
[05:06] <kgunn> thomi: so how to unlock the shell ?
[05:09] <kgunn> thomi: nvmd i see you updated
[05:10] <kgunn> thomi: ok...totally works
[05:11] <thomi> kgunn: :)
[05:21] <kgunn> thomi: did you have any trouble with the mir logging...i'm running ok (expected failure on mir) but don't get the input log after the env setting
[05:21] <kgunn> ...and yes i was sudo -u phablet -i when i set the env variables
[05:51] <thomi> kgunn: nope, it just worked for me
[05:51] <thomi> kgunn: note that if you're running unity8/mir under upstart you need to use initctl set-env,  otherwise, if you're running it directly use export
[05:56] <robert_ancell> thomi, duflu, RAOF, racarr, kdub, kgunn, alf_, hikiko, meeting in 4 mins..
[05:59] <robert_ancell> hikiko, meeting!
[06:04] <hikiko> robert_ancell, i am having a problem connecting i ll be there in 2 minutes
[06:04] <robert_ancell> hikiko, np
[06:17] <duflu> Was I the only one thinking of Brady Bunch music when the second alf appeared?
[06:17] <robert_ancell> racarr, so you wanted to talk to kdub and I wanted to talk to RAOF or alan :)
[06:19] <racarr> In my case, I should have just talked to kdub during the day XD
[06:19] <racarr> I am so useless by the time we have these meetings ><
[06:20]  * alf_ upgraded hangouts, let's see if it's going to be better next time
[06:21] <duflu> It's a story of a man named Frantzis, who was bringing up some very lovely clones...
[06:21]  * duflu goes back to real work
[06:21] <robert_ancell> bye all
[06:21] <duflu> Bye robert_ancell
[06:22] <racarr> bye
[06:55] <geomyidae> can we have a small hint about the gpu drivers? pleeeease
[07:31] <duflu> racarr: Still around?
[07:33] <mlankhorst> morning
[08:04] <duflu> mlankhorst: Morning. Did any of that nouveau vsync timing work land, anywhere?
[08:08] <mlankhorst> nah but maintainer is looking at it :/
[10:58] <dandrader> alan_g, so, about that FakeEventHub MP review, ARBITRARY_TIME should be simply arbitrary_time (so one can't infer if it's const, local, global or member variable)?
[10:58] <hikiko> hi, did anyone get the stop lightdm crash recently?
[10:59] <hikiko> because I got it today and I couldnt switch VTs from ssh anymore
[11:00] <alan_g> dandrader: Yes. But one can infer it isn't a macro.
[11:00] <dandrader> ok
[11:03] <dandrader> although one would handle a macro pretty much the same way it would a const variable.
[12:17] <dandrader> ricmm, ping
[12:23] <davmor2> guys you possibly know this already but there are crashers for maliit and hud when you start mir
[12:35] <jibel> bug 1233988
[12:35] <jibel> davmor2, is it the one you're seeing ^
[12:35] <jibel> and I couldn't retrace hud
[12:36] <davmor2> jibel: possibly,  I had a few that I couldn't retrace so far
[12:38] <davmor2> jibel: I'm trying a few things currentl'y when I get back from Lunch I'll add some debug symbols and see if I can get some info from it
[12:53] <greyback_> folks, I've an issue with Mir and clients which are SIGSTOP-ed. It appears that sometimes Mir considers that client dead and disconnects it.
[12:53] <greyback_> is there any way to prevent that?
[12:57] <kgunn> davmor2: i don't have an issue with assigning the maliit crash to mir if its the cause...but please do some testing on SF to compare....at least, i've seen OSK be fairly unstable in the SF config as well
[12:57] <kgunn> davmor2: hud for sure is a unity-mir/mir issue
[12:58] <kgunn> https://bugs.launchpad.net/unity-mir/+bug/1231713
[12:59] <greyback_> kgunn: I need some Mir team help with the above query, please push it to near the top of the stack. It's causing big app-management problems
[13:08] <davmor2> kgunn: I cleared out /var/crash before starting mir so I think it is possibly just an issue with maliit but on a fresh sf boot I don't see any crashes but that isn't to say that the reboot didn't cause the maliit crash if that makes sense.
[13:10] <davmor2> kgunn: my phone is completely locked up now.  I'm about to dig into it and see what is  what.
[13:13] <davmor2> kgunn: ouch adb isn't connecting
[13:13] <kgunn> greyback_: ack.... alan_g this sounds related to how the server handles crashing shell (altho more to the second phase of restoring apps)
[13:14]  * kgunn waits for alan_g to tell me there's code sitting on dev branch i should have merged to trunk (braces)
[13:14] <alan_g> kgunn: if you know it, why should I tell you?
[13:14] <greyback_> kgunn: the server handling crashing shell is probably unity-mir/my fault. I've idea on possible fix
[13:15] <alan_g> greyback_: how quickly does this happen? After half an hour? Or in seconds?
[13:15] <jibel> kgunn, I don't get this maaliit crash with SF, but it is there on every boot with MIR enabled
[13:16] <kgunn> jibel: ack...can you log a specific bug to that effect (maliit crash on every mir boot)...thank you
[13:17] <kgunn> greyback_:  https://code.launchpad.net/~alan-griffiths/mir/client-dies-without-server/+merge/187797
[13:17] <kgunn> which i s on our dev branch....
[13:17] <greyback_> alan_g: minutes
[13:17] <kgunn> dev branch most definitely breaks api
[13:18] <kgunn> so...gotta do all the paperwork first
[13:18] <greyback_> kgunn: oh interesting
[13:18] <kgunn> https://code.launchpad.net/~mir-team/mir/development-branch
[13:18] <kgunn> ...which i'll just go ahead and start right now....
[13:19] <alan_g> kgunn: it would be good to land https://code.launchpad.net/~alan-griffiths/mir/fix-1201436/+merge/188535 too - that's got more RPC cleanup
[13:19] <jibel> kgunn, bug 1233988
[13:20] <kgunn> alan_g: shall i top approve? (i take it "fix nits" addresses duflu's "needs fixing")
[13:20] <kgunn> jibel: thank you1
[13:20] <kgunn> or thank you! even
[13:22] <jibel> is there a know issue for unity8 using 100% CPU when the phone is idle with screen blank?
[13:22] <alan_g> kgunn: yes
[13:24] <kgunn> jibel: yes...there are actually 2 disctint bugs for that
[13:24] <jibel> I found 1233870 but not the other, do you have it handy?
[13:30]  * kgunn wonders if i just lied to jibel...one moment
[13:31] <alan_g> greyback_: can you get a server log from msg-processor-report? That ought tell why the server decides to disconnect
[13:32] <greyback_> alan_g: ok
[13:32] <kgunn> jibel: i knew it was a unity8 bug....but it seems there are a few more :) https://bugs.launchpad.net/unity8?field.searchtext=cpu&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&fiel
[13:32] <kgunn> d.has_no_package=
[13:32] <alan_g> I suspect that something happens on the socket - but...
[13:33] <jibel> kgunn, no worries, I'll continue searching
[13:33] <kgunn> jibel: i think i was thinking of this one https://bugs.launchpad.net/unity8/+bug/1217099
[13:33] <davmor2> kgunn: had to take the battery out of my phone, now digging into if there were any crash reports
[13:35] <davmor2> kgunn: the only addition to the crash count seems to be _usr_lib_arm-linux-gnueabihf_upstart-app-launch_zg-report-app.32011.crash  I'll try that script that does seem to work ish and get some info on it
[13:36] <kgunn> davmor2: cool
[13:47] <davmor2> kgunn: http://paste.ubuntu.com/6183885/  hope that is useful I think it stopped saying there were missing symbols
[13:52] <davmor2> kgunn: would there be a dbg package for this from /usr/lib/arm-linux-gnueabihf/qt5/plugins/platforms/libqubuntumirclient.so
[13:53] <kgunn> davmor2: there must be somewhere
[13:54] <davmor2> kgunn: apt-cache search libqubuntumirclient returns nothing
[13:54] <kgunn> greyback_: ^ best way to get debug pkg for libqubuntumirclient.so ?
[13:55] <kgunn> davmor2: so...what was happening when you got this? http://paste.ubuntu.com/6183885/
[13:55] <kgunn> davmor2: looks like glib got upset somehow...
[13:56] <davmor2> kgunn: pass that was the only additional crash I found after removing the battery so I could get the device back up after it completely locked up on me
[13:56] <kgunn> tedg: mind looking at this real quick http://paste.ubuntu.com/6183885/  just thot you might have an idea
[13:57] <tedg> kgunn, You don't have zeitgeist installed
[13:58] <kgunn> davmor2: ^
[13:58] <kgunn> packaging mistake ?
[13:58] <greyback_> davmor2: the qtubuntu-android-dbgsym package, from ddebs.ubuntu.com repo
[13:58] <davmor2> tedg: this is image 75
[13:58] <om26er> davmor2, what's the package name for bugs against Mir ?
[13:58] <greyback_> davmor2: see https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages for info
[13:59] <davmor2> greyback_: thanks
[14:02] <davmor2> greyback_: I think it was more my apt-cache search foo letting me down :)
[14:03] <greyback_> davmor2: :)
[14:03] <om26er> wow unity8 takes 100% cpu probably that's the reason for slowness I see on mako
[14:03] <davmor2> om26er: https://launchpad.net/mir
[14:03] <om26er> davmor2, I wanted the package name, but I'll find it from that link. Thanks
[14:07] <davmor2> kgunn, jibel: that's about as good a stack as I can get for the maliit issue http://paste.ubuntu.com/6183984/ jibel does that match yours?
[14:08] <Saviq> guys, you're hogging our testing vms again! ;P
[14:09] <davmor2> Saviq: I'm on a my own hardware so I doubt that :P
[14:09] <Saviq> davmor2, it was a general remark to the Mir guys ;)
[14:09] <jibel> davmor2, yes, it seems to match
[14:10] <jibel> davmor2, why don't you submit the crash with apport and let the retracer do the work
[14:10] <jibel> ?
[14:10] <jibel> pitti fixed them few days ago to produce usable stack traces
[14:10] <davmor2> jibel: cause it's fun :)
[14:10] <jibel> davmor2, you have too much spare time ;)
[14:11] <davmor2> jibel: I have no spare time I have a script and installing a few dbg packages :)
[14:13] <davmor2> jibel: how are you doing that?  apport-collect/cli/bug?
[14:13] <jibel> davmor2, apport-cli /path/to/crash on the device
[14:14] <kgunn> jibel: really...that simple huh ?
[14:14] <tedg> kgunn, So it seems the answer to your question is: people just putting data into Zeitgeist doesn't make it important enough to have.
[14:14] <jibel> davmor2, then send and when it asks to open the browser, copy the link to the browser on your desktop
[14:14] <tedg> Stupid shortsightedness
[14:14] <kgunn> tedg: :)
[14:14] <om26er> kgunn, do we have a bug for 100% cpu usage of unity8 on mako or should I report one ?
[14:15] <jibel> om26er, read backlog
[14:15] <kgunn> om26er: we have it
[14:15] <jibel> *scroll
[14:15] <kgunn> om26er: we have a handful actually :)
[14:15] <kgunn> davmor2: that last one is interesting http://paste.ubuntu.com/6183984/ seems you need libmirclient dbg symbols
[14:16] <ricmm> kdub: ping
[14:16] <om26er> ok
[14:16] <davmor2> kgunn: apparently I don't have some up-to-date packages so I'm updating the image and trying again, shuggin fashin packages
[14:18] <kgunn> davmor2: ack
[14:18] <kgunn> dandrader: before i forget
[14:19] <kgunn> dandrader: if you mp, please target this branch https://code.launchpad.net/~mir-team/mir/development-branch
[14:19] <dandrader> kgunn, sure
[14:19] <kgunn> dandrader: we're using that as a staging area to prevent un-shepherded server api breaks
[14:24] <kgunn> ricmm: he's west coast
[14:24] <kgunn> ricmm: can anyone else help ?
[14:24] <kgunn> altho he's prompt at ...he'll be in in 30min
[14:37] <ricmm> kgunn: just wanted to see where he was at with the branch to remove the vsync signal
[14:37] <ricmm> for the cpu usage bug
[14:37] <kgunn> ricmm: yep :) me too...feel free to join our standup
[14:38] <ricmm> ill join it for the first few mins
[14:38] <ricmm> thx
[14:41]  * ricmm tea aswell
[14:49] <dandrader> kgunn, the sleep&retry hack works, but a lot of cycles seems to be needed (i.e. a big delay between the device file showing up and udev rules getting applied to it), which is a bit unnerving
[14:49] <kgunn> didrocks: what's that incantation to bump the deb changelog ?
[14:49] <kgunn> dandrader: have you tested a few times...is it consistent?
[14:49] <didrocks> kgunn: dch -i
[14:50] <kgunn> didrocks: dang it...thot so...sorry for the ignorant interupt
[14:50] <didrocks> kgunn: seems obvious isn't it? ;) (j/k)
[14:50] <didrocks> no worry, if you don't practice it regularly, yeah, it's normal that you don't remember ;)
[14:50] <kgunn> dandrader: i know you were going to try-wait in a loop...guessing it tries multiple times ?
[14:51] <kgunn> dandrader: wonder if your attempts slow it down ?
[14:52] <kgunn> dandrader: curious, are you able to run through autpilot test ? e.g. ubuntuuitoolkit per the bug
[14:52] <dandrader> kgunn, anyway, the quick hack is not so quick in the end. aiming at the proper fix now
[14:52] <kgunn> dandrader: so, not MP worthy ?
[14:53] <dandrader> kgunn, if I have to spend time debugging a quick hack it's because it's not quick anymore :)
[14:53] <kgunn> dandrader: sure
[14:53] <dandrader> kgunn, and a second problem is hit:
[14:53] <dandrader> "[InputReader]  Touch device 'autopilot-finger' did not report support for X or Y axis!  The device will be inoperable."
[14:54] <dandrader> kgunn, so that might be a second hurdle waiting after the current one
[14:54]  * kgunn goes for another cup of coffee...and considers running into the street to be hit by oncoming traffic
[14:55] <dandrader> lol
[14:56] <alan_g>  /me wonders how he has lived this long
[14:59] <ricmm> kgunn: give it two more weeks
[14:59] <ricmm> then we can all just get on a bus and do the same
[14:59] <kgunn> :)
[15:00] <ricmm> kgunn: ill skip the standup, I just saw emails from kevin that I had missed
[15:00] <ricmm> its up for review, the changes requested are trivial
[15:01] <ricmm> im sure kevin will have it ready within 1-2 hours
[15:01] <ricmm> im testing it locally now and will do my review
[15:05] <kgunn> ricmm: cool...appreciate the testing
[15:17] <hikiko> good evening!
[15:19] <mhall119> kgunn: is it possible to run a Wayland session compositor on top of the Mir system compositor?
[15:20] <kgunn> mhall119: i would assume you mean in theory ?
[15:20] <mhall119> yeah
[15:20] <mhall119> and if there's been any discussion and/or plans
[15:21] <kgunn> mhall119: sure...you'd have to write a wayland-mir back end
[15:21] <kgunn> mhall119: its been discussed...like over beer...but nothing more than that
[15:21] <mhall119> ok
[15:24] <alan_g> kgunn, mhall119: FWIW we've had similar discussions about implementing Wayland using the Mir library. (IT would be "fun", but isn't currently planned or worked on.)
[15:28] <mhall119> alan_g: would that work to run an upstream Gnome-Shell-as-Wayland-compositor on top of a Mir system compositor?  I thought implementing the Wayland protocol would only let us run Wayland clients
[15:32] <davmor2> kgunn: right completely fresh install on the default SF all I have crash wise is for _sbin_ureadahead.0.crash so I will delete that now and then reboot into mir and see what appears then
[15:33] <alan_g> mhall119: Maybe. In that case the "Weston" session compositor would need to talk the protocol that the Mir system compositor uses (and currently that's the internal Mir one). For that you'd need to implement a session compositor as a Mir client.
[15:33] <alan_g> But if the system compositor talked Wayland...
[15:34] <alan_g> * s/Weston/Wayland/
[15:36] <kdub> right, you'd have to implement a fb backend based on mir in weston
[16:11] <pete-woods> hi all, according to (http://unity.ubuntu.com/mir/installing_prebuilt_on_android.html) I should be able to run mir on nexus 7 with a special  libhybris
[16:11] <pete-woods> questions 1) is this true? 2) if so, where do I get it?
[16:11] <kdub> pete-woods, i think that support landed, so no special one needed anymore
[16:11] <kdub> haven't tried in a while
[16:12] <pete-woods> kdbub: I just tried running it, and basically ran into this bug (https://bugs.launchpad.net/mir/+bug/1231917)
[16:12] <pete-woods> and figured that it must be that libhybris thing mentioned in the wiki
[16:13] <kdub> might be that hwc isnt working for nexus 7
[16:14] <pete-woods> I don't know what hwc is (hardware compositor?), but I'm guessing I can't fix it myself
[16:15] <kdub> pete-woods, posted a suggestion on the bug
[16:19] <pete-woods> kdub: thanks for the suggestion, /system seems to be mounted ro, is there a safe way to change this?
[16:19] <kdub> mount -o remount,rw /system
[16:20] <pete-woods> okay
[16:20] <pete-woods> kdub: I just wanted to check I wasn't going to explode stuff if I did that
[16:20] <pete-woods> :)
[16:21] <kdub> if it explodes, move it back
[16:21] <pete-woods> :)
[16:25] <kdub> alan_g, on that deactivate-notifications-when-display-off branch, changed the name to mode(MirPowerMode)
[16:25] <kdub> reads much cleaner, no new enums or confusing bools
[16:25]  * alan_g goes to look...
[16:26] <pete-woods> sadly that removing the hwcomposer shared lib doesn't seem to help, but thanks for the suggestion
[16:27] <kdub> pete-woods, thanks for giving it a try
[16:28] <pete-woods> np
[16:28] <pete-woods> I am obviously the one with most to gain from a fixed display server
[16:28] <kdub> i'm wandering around hwc code for the next bit, so there's hope i can get it working... no time promises though
[16:29] <alan_g> kdub: approved
[16:29] <kdub> alan_g, thanks
[16:29] <pete-woods> kdub: well I have my fingers and toes crossed :)
[16:47] <kgunn> alan_g: kdub alf|xmir_devel .....any takers https://code.launchpad.net/~kgunn72/mir/bump-libmirserver5/+merge/188877
[16:47] <kgunn> its an easy one
[16:51] <kgunn> kdub: you want mp 188751 top approved ? or should we wait for duflu ?
[16:52] <kgunn> going for a run bbiab
[16:52] <kdub> kgunn, let me fix that nit, should be done by the time you get back
[18:13]  * kdub wishes mocking ioctls was easier
[18:16] <kgunn> kdub good to go ?
[18:17] <kdub> oh sure
[18:18] <kgunn> racarr: you around ?
[18:19] <kgunn> racarr: don't hate me...but it'd be really really useful if you could a) review  https://code.launchpad.net/~dandrader/mir/hack_lp1233944/+merge/188889
[18:20] <kgunn> and b) test it out on a phone against an AP run per https://bugs.launchpad.net/mir/+bug/1233944
[18:21] <kgunn> bschaefer: you got a phone?
[18:21] <bschaefer> kgunn, sadly no, i've a nexus 7 that refuses to be recognized by my laptop :(
[18:21] <kgunn> :-/
[18:22] <kgunn> greyback: ^ in case you're feeling benevolent
[18:22] <kgunn> i'll try...but i go at manager speed :-|
[18:25] <racarr> kgunn: THATS IT THATS THE LAST
[18:25] <racarr> FUCKING STRAW I HAVE HAD
[18:25] <racarr> :p
[18:25] <racarr> Don't worry, you're too nice to hate.
[18:26] <racarr> um, ok let me figure out what is going on
[18:26] <greyback> kgunn: I'm in middle of other debugging session at the moment, can take it on after. In case the bi-polar racarr scares you :)
[18:26] <kgunn> racarr: and i have an interesting relationship...he rages a lot :)
[18:27] <racarr> aha, no I don't mind doing this at all, I was just playing a long
[18:27] <racarr> phone is at dead battery though. so it will be a bit
[18:28] <racarr> branch itself looks fine
[18:28] <racarr> err
[18:28] <racarr> hmm
[18:29] <racarr> worried about opening a device multiple times now
[18:32] <racarr> ok I think it will open devices multiple times potentially
[18:32] <racarr> and its not clear what will happen
[18:32] <racarr> going to propose a thing
[18:32] <kgunn> ok
[18:33] <kgunn> altho...shouldn't that be a well defined device interface thing (e.g. multiple open calls from a client result in 1 device handle)
[18:33] <kgunn> or some such
[18:34] <racarr> its just a file
[18:34] <racarr> so you keep on getting file descriptors to it I guess
[18:34] <racarr> if you keep on opening it by path
[18:35] <davmor2> kgunn: you have a nexus 4 right?
[18:35] <kgunn> yes sir
[18:36] <davmor2> kgunn: can you install solitare and try moving the cards around for me on mir they are really jumpy on maguro
[18:37] <davmor2> kgunn: I'm just after finding out if it is a maguro thing (which I'm expecting it is) or if it is an animation that mir isn't happy with in general
[18:39] <kgunn> davmor2: give me a few
[18:40] <davmor2> kgunn: no worries
[18:51] <racarr> kgunn: I proposed a merge in to dandraders branch
[18:51] <racarr> but it seems like he isn't around? and this probably needs to go quick?
[18:54] <kgunn> racarr: yeah...he eod'd
[18:55] <kgunn> davmor2: hey...so...when i try to download solitare it keeps telling me err, please go sign into ubuntu1 via system settings
[18:55] <kgunn> davmor2: i can;t find that in sys setting....but used the ubuntu1 app
[18:55] <kgunn> i signed in, but still gives me the same error
[18:56] <davmor2> kgunn: open the setting app,  in setting click on accounts, login to u1
[18:56] <thomi> morning all
[18:56] <kgunn> thomi!
[18:57] <thomi> hey kgunn, pitti tells me he found the bug
[18:57] <thomi> pitty is like... super engineer. I bet it took him 2 minutes
[18:58] <kgunn> thomi: maybe 10 :)
[18:58] <racarr> kgunn: Ok I am going to repropose it sourced from my branch then someone else can review
[18:58] <kgunn> racarr: totally makes sense
[18:59] <kgunn> then poor kdub will need to review
[19:00] <racarr> ok done
[19:00] <racarr> https://code.launchpad.net/~robertcarr/mir/1233944-addendum/+merge/188900
[19:00] <kgunn> thomi: if you want to rebuild mir use that ^ and see if that solves it
[19:00] <kdub> daniel will be the only one who can pull that in
[19:01] <thomi> OK. grabbing now
[19:01] <racarr> I still cant get my nexus to physically turn on...
[19:02] <kgunn> kdub: no, i think racarr retargeted it to dev branch instead of daniels ....so i guess that means we'd simply need to take both if we want them
[19:02] <kgunn> or do i have it wrong?
[19:04] <racarr> no mine contains daniels so just merge the second one
[19:04] <kdub> yeah, didn't refresh my page
[19:05] <racarr> I actually resbmitted daniels proposal sourced from my branch
[19:05] <racarr> but im not sure what that means different than retargeting
[19:05] <racarr> my proposal
[19:05] <kgunn> racar right so if we pull yours in daniel's comes with it i think
[19:06] <racarr> yeah
[19:06] <kgunn> davmor2: ok...instructions were good, logged into u1 ok...but now, i hit the install button on solitaire and it just sits here
[19:07] <kgunn> wonder if getting an error prior to logging in properly is an issue
[19:07] <kgunn> or logging into the u1 app and the settings app
[19:07] <kgunn> is an issue
[19:07] <davmor2> kgunn: :( have you thought about joining qa?
[19:08] <kgunn> davmor2: because i find so many weird things wrong ? :)
[19:08] <davmor2> kgunn: because you break stuff as easily as I do :)
[19:09] <davmor2> kgunn: apparently there is a link being added that takes you to the settings page which will land soon :)
[19:10] <davmor2> kgunn: you may need to reboot I'm afraid (Yes the proverbial turn it off and turn it on again fix) :D
[19:11] <thomi> hey mir folk - can someone point me to the pbuilder/sbuild cross compile info again? I seem to have wiped my setup
[19:12] <kgunn> thomi: you mean this http://unity.ubuntu.com/mir/building_source_for_android.html
[19:12] <thomi> kgunn: I want to build packages, not raw binaries :-/
[19:14] <kdub> we should eliminate those instructions...
[19:14] <kdub> tricky part is getting everyone bootstrapped with their cross build setups
[19:14] <thomi> kgunn: racarr: are there plans to use ueventlib instead of inotify? I trust pitti when he says that it's the correct solution
[19:15] <kgunn> thomi: yes...but even pitti points to a quick hack soln
[19:15] <thomi> sure
[19:15] <kgunn> uevent a longer term thing
[19:15] <thomi> just wanted to make sure this was going to get patched, and not forgotten about :)
[19:15] <thomi> I didn't mean today :)
[19:16] <kgunn> thomi: you know me by now...we'll at least have a bug indicating we're a bunch of scally wags
[19:17] <kgunn> kdub: so what are the instructions ? (i've just built per the wiki....realized i've never cross compiled mir and then installed on a device)
[19:17] <thomi> heh, ok
[19:17] <thomi> you can do it with pdebuild/pbuilder, but I can never remember how
[19:17] <kdub> the instructions are 'make an armhf with the needed dependencies, then use a certain cmake command'
[19:18] <thomi> also, sbuild will do it I believe
[19:18] <thomi> kdub: oh, there's an easier way than that :)
[19:18]  * thomi continues searching
[19:18] <kgunn> ls
[19:18] <kgunn> oops
[19:18] <kdub> thomi, but with cross compiling?
[19:18] <kdub> not emulated compiling
[19:18] <thomi> yeah
[19:18] <thomi> oh, well, does it make a difference?
[19:19] <kdub> not in what's produced, but in time
[19:19] <kdub> emulated compiling is slow for a development workcycle
[19:19] <kdub> its slow for a packaging one, but more tolerable
[19:20] <kdub> and i know how to make a chroot :) its just the scripting of making the chroot that i haven't been able to do
[19:21] <thomi> I see. maybe I have a blinging laptop.. I never noticed it being significantly slower that native compiles
[19:21] <kdub> well, i'd say that native and emulated compiles are roughly on par
[19:22] <kdub> but cross compiles are faster than both
[19:26] <kdub> thomi, right now, we just run the top level script 'cross-compile-chroot.sh'... but its a bit of a hack
[19:29] <thomi> yeah... but I'm pretty paranoid about copying binaries over to system locations. If I get a package at least I can revert those changes safely
[19:29] <thomi> it turns out, the CI system produces such packages, so I'll grab them
[19:31] <kgunn> kdub: sorry if i'm being dense...so, after running  cross-compile-chroot.sh...do i just copy all the libmir*.so's over to the device in the directory /usr/lib/arm-linux-gnueabihf/
[19:32] <kdub> kgunn, that's what i usualy do... like thomi noted though doing that can cause headaches though if you're not careful
[19:32] <kgunn> kdub: :) define "careful"
[19:33] <kdub> make sure the linkage is what you expect
[19:34] <kgunn> kdub: oh...like version numbers and the fact that android input is a static lib and all the so's probably link to it
[19:34] <kdub> well, its a static lib, but it goes out in... libmirserver.so?
[19:35] <kgunn> kdub:  i was just gonna push everything to be certain
[19:37] <kgunn> hey...so doing this...and kind of double checking stuff....i noticed something
[19:37] <kgunn> in the ubuntu-system image....there's no libmirclientlttng.so
[19:38] <kgunn> remember last night i said logging didn't work for me...
[19:38] <kgunn> thomi: did you install seperately ?
[19:38] <thomi> kgunn: not yet
[19:38] <thomi> waiting for CI to do it's thing
[19:39] <kgunn> thomi: no i meant last night...when you were using mir logging....had you installed the libmirclientlttng.so seperately ?
[19:39] <thomi> kgunn: nope
[19:39] <thomi> kgunn: but I wasn't using lttng
[19:54] <thomi> gah
[19:54] <thomi> jenkins is down, and I can't find those instructions anywhere
[19:54] <thomi> I really don't want to have to build the package on the phone, that sounds like a bad idea
[19:56] <racarr> kgunn: Should I still try and test this autopilot stuff?
[19:56] <racarr> Just finished up input-injecter
[19:57] <thomi> kgunn: found them - was looking in the wrong wiki: https://wiki.canonical.com/PES/Engineering/DevelopingWithPbuilder?highlight=%28compile%29%7C%28armhf%29
[19:57] <thomi> racarr: that would certainly help me out
[19:58] <racarr> yay the red light is back on my phone
[19:58] <racarr> should be operable soon
[19:59] <racarr> thomi: Ok ill get on it
[19:59] <thomi> thanks
[19:59] <racarr> it wll be 20 minutes to upgrade, 20 minutes to build the new mir branch, etc...
[20:00] <racarr> should I just start from cdimage-touch or is there
[20:00] <racarr> a specific image
[20:00] <thomi> racarr: I'd grab the ubuntu-system image from the devel-proposed channel
[20:00] <racarr> thomi: Can phablet flash do that?
[20:00] <thomi> sure
[20:00] <thomi> one second
[20:01] <racarr> I think maybe I have seen this incanation before
[20:01] <kgunn> https://wiki.ubuntu.com/Touch/Install
[20:01] <racarr> but I keep on downloading the images and using clockwork mod XD
[20:01] <kgunn> racarr: ^ see section 4
[20:01] <thomi> yeah, what he said :)
[20:01] <racarr> phablet-flash --help has gotten worse and worse
[20:01] <racarr> and phablet-flash has gotten
[20:01] <racarr> better and better lol
[20:01] <racarr> ok thanks :D
[20:02] <kgunn> its like phablet-flash ubuntu-system --channel devel-proposed --no-backup -d mako
[20:02] <kgunn> no backup is like --wipe
[20:02] <kgunn> and like i always saw...its always good to wipe
[20:02] <racarr> oi
[20:02] <kgunn> in life and on phone flashing
[20:03] <racarr> kgunn: That could either be a very zen metaphor or a very juvenile one :p
[20:04] <kgunn> racarr: do you know who you're talking to ? :)
[20:04] <racarr> I guess that makes it double zen.
[20:04] <racarr> oi :p
[20:04] <kgunn> the product of living with a 15 yr old boy
[20:05] <kgunn> racarr: rest of the instructions here... https://bugs.launchpad.net/mir/+bug/1233944 for running AP tests
[20:05] <racarr> thanks
[20:06] <racarr> im cross compiling mir in parallel with the flash so it shouldn't really take that long
[20:06] <kgunn> racarr: also...missing from that bug...you have to install on the device...python-gi & unity8-fake-env
[20:06] <kgunn> to get AP to run
[20:06] <bschaefer> racarr, hey, if you get a chance, could you comment on this MP: https://code.launchpad.net/~brandontschaefer/mir/lp.1233089-fix-v-h-scroll/+merge/188666
[20:07] <racarr> kgunn: ok
[20:07] <kgunn> thomi: i flashed hours ago...those packages still not there^
[20:07] <racarr> bschaefer: Ill do that now while my phone flashes!
[20:07] <bschaefer> racarr, sweet :)
[20:07] <thomi> kgunn: the littng .so? You don't need it
[20:07] <bschaefer> racarr, i know we talked about waiting on it, which we might have to, but duflu has made a comment as well :)
[20:07] <kgunn> thomi: no...the AP dependent modules
[20:07] <kgunn> thomi: python-gi & unity8-fake-env
[20:08] <thomi> kgunn: oh yeah, that's why you need to apt-get install the -autopilot packae
[20:08] <thomi> *package
[20:08] <kgunn> thomi: oh my bad...
[20:08] <thomi> that's not going to get fixed until we kick sergio's ass  a bit more :)
[20:09] <racarr> bschaefer: touch_major/minor
[20:09] <racarr> is used by qtubuntu
[20:09] <bschaefer> oo, soo can't use that :)
[20:09] <racarr> it uses some sort of mathematics to compute the touch "area"
[20:09] <racarr> tbh I think its all used
[20:09] <bschaefer> racarr, orientation/pressure might not be bad to remove?
[20:09] <bschaefer> dam
[20:10] <racarr> orientation
[20:10] <racarr> is unused
[20:10] <racarr> pressure is used
[20:10] <bschaefer> racarr, well, now I wish I hadnt reverted this a bit ago...
[20:10] <bschaefer> racarr, alright, what about raw_x/raw_y?
[20:10] <racarr> sorrry
[20:10] <racarr> raw_x and raw_y are used :(
[20:10] <racarr> maybe x and y aren't used
[20:10] <bschaefer> dang, id?
[20:10] <racarr> or maybe if we keep x and y and offset
[20:10] <racarr> we can remove raw_x and raw_y or something
[20:11] <racarr> ID is probably only used forlogging and hashing
[20:11] <bschaefer> yeah...which is a useful one hmm I can look at trying to compress the raw_x/raw_y into an offset
[20:11] <bschaefer> but it has to be a sizeof(float)
[20:12]  * bschaefer doesn't know the android input stack super well :)
[20:13] <bschaefer> racarr, to bad vscroll and hscroll isn't an XOR...otherwise I could just do a union and drop 1 float
[20:13] <racarr> mm
[20:14] <racarr> trying to put two floats in one floats sounds pretty bad though, there will be no precision
[20:15] <bschaefer> racarr, well I was thinking (yesterday at lease) that you can only have a vscroll XOR hscroll if so then you can just union those 2
[20:15] <bschaefer> cause it'll only ever be one, though it'll be hard to tell which direction it really is...
[20:15] <bschaefer> racarr, yes you are right though, no precision :)
[20:15] <robert_ancell> thomi, any change on the input issue?
[20:16] <bschaefer> racarr, whats size used for in the struct?
[20:16] <racarr> oh you could lose one precision bit and
[20:16] <racarr> best to avoid bit hacks though
[20:16] <racarr> bschaefer: hm?
[20:17] <bschaefer> iagree
[20:17] <bschaefer> racarr, http://paste.ubuntu.com/6185447/
[20:17] <bschaefer> line 6 in the paste...im not sure what size would be used for
[20:17] <bschaefer> size of the blob?
[20:19] <bschaefer> well that explains it: http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_SIZE
[20:20]  * bschaefer digs through qtubuntu
[20:20] <racarr> size of the touchpoint is my guess
[20:20] <racarr> qtubuntu doesnt really use it
[20:20] <racarr> from grep
[20:20] <kgunn> think i just ran into the careful you were talking about kdub
[20:20] <racarr> maybe you could get away with size and orientation
[20:20] <kgunn> its up..unity8 running...but nothing on screen
[20:20] <racarr> this is kind of worrying me though
[20:20] <bschaefer> racarr, well i want to make sure if i remove something, it wont be needed in the future...
[20:20]  * bschaefer as well
[20:20] <racarr> I think there is nothing to remove then
[20:20] <racarr> just stuff we dont use now
[20:20] <bschaefer> racarr, as v/h scroll is somewhat needed as well...
[20:20] <greyback> kgunn: just a note, thanks to ricmm, the problem I was having with disappearing apps is solved
[20:21] <bschaefer> racarr, and we can't change the size of that strcut, as it'll break things... <sadface>
[20:21] <racarr> Well in the future we can break ABI
[20:21] <racarr> I guess we just can't right now.
[20:22] <bschaefer> racarr, sounds good, i can make a comment on that MP
[20:22] <bschaefer> racarr, thanks for the info!
[20:22] <kgunn> greyback: thats a great note!
[20:22] <racarr> grr phone died int he middle of flashing
[20:22] <kgunn> f!...reflashing
[20:23] <kdub> you should always leave ubuntu touch plugged in at all times ;-)
[20:23] <racarr> I know but I only have so at the end of day when my computer becomes a nexus of audio cables it always ends up unplugged
[20:23] <racarr> should find my wall charger
[20:23] <racarr> only have so many usb*
[20:23] <kdub> racarr, the change 12233944 looks okay enough... just don't know enough to say that it won't break anything
[20:24] <kdub> not too familiar with the code, or the problem
[20:24] <racarr> me either so we will wait on testing it to land
[20:24] <racarr> well, I have some idea that it's ok :p but not 100% confident
[20:26] <kdub> racarr, yeah :/
[20:27] <kdub> android system code (like sf or the input stack) always seems like a big else-if chain based around flags to me
[20:29] <racarr> lol yes
[20:29] <racarr> most of the android input classes have some big methods that basically is like
[20:29] <racarr> changeState(new state)
[20:29] <racarr> with a massive case statement
[20:29] <racarr> lol
[20:29] <kdub> maybe vtables are just too slow for them :) better to have every object have an int, with flags set
[20:30] <racarr> I think, a lot of it is symptomatic of this sort of OO pattern of avoiding too much abstraction
[20:30] <kdub> and the code switches function calls around the int flags
[20:30] <kdub> :P
[20:30] <racarr> i.e. all the objects in the input stack kind of
[20:30] <racarr> correspond
[20:30] <racarr> to some, object that you could kind of imagine
[20:30] <racarr> as a physical object or like an actor
[20:30] <racarr> but I think trying to stick to that ideal
[20:30] <racarr> normally just leads to object explosion
[20:30] <racarr> and the input stack would be a lot cleaner, if InputDispatcher were several more abstract components
[20:30] <racarr> etc
[20:37] <racarr> Ok lunch while my phone chargers so we dont have a repeat
[20:37] <racarr> bbiab
[20:38] <kgunn> thomi: can i cheat assuming you're ahead of me...what's in your pcreate proj file ?
[20:39] <kgunn> deb & deb-src urls
[20:39] <thomi> kgunn: you men ~/.pbuilderrc ?
[20:40] <kgunn> thomi: the one where you create the proj
[20:40] <thomi> kgunn: ummm, I'm not sure what you mean - I'm following this: https://wiki.canonical.com/PES/Engineering/DevelopingWithPbuilder?highlight=%28compile%29%7C%28armhf%29
[20:40] <thomi> essentially you run pcreate ... and then pbuild
[20:40] <olli> thomi, are you still building?
[20:41] <thomi> olli: yup :-/
[20:41]  * olli is curious to hear if the fix helped
[20:41] <olli> did dandrader test it locally?
[20:41] <kgunn> thomi: right, but pcreate prompts you with a text editor to enter proj location info
[20:41] <thomi> it's a race to see if pbuild or the CI process finished first
[20:41] <kgunn> see the wiki "Create Project:pcreate" then #2
[20:42] <thomi> kgunn: gotchya, just leave it blank
[20:42] <kgunn> ?
[20:42] <kgunn> cool
[20:42] <thomi> kgunn: in the past you needed additional sources.list lines, but not anymore
[20:42] <thomi> everything is in the archive these days
[20:42] <kgunn> thomi: ....and my wife says i don't follow instructions...ha
[20:44] <thomi> following instructions is for the weak willed anyway
[21:03] <robert_ancell> racarr, was https://code.launchpad.net/~robertcarr/mir/1233944-addendum/+merge/188900 meant to superceed Daniel's MP or be merged into it?
[21:03] <robert_ancell> Anyway, it looks sane to me as a workaround, are you abstaining since it looks like you've proposed it or you're not sure about it
[21:05] <racarr> robert_ancell: Abstaining because I reproposed it
[21:05] <racarr> it was originally going to go in to daniels mp
[21:05] <racarr> but then daniel is EOD
[21:05] <racarr> so I resubmitted my branch with daniels to dev branch
[21:05] <racarr> which is the one that should land
[21:06] <racarr> it still needs testing though
[21:06] <racarr> so dont top approve
[21:08] <robert_ancell> racarr, ack
[21:13] <racarr> wait did my flash fail again? errrrrgggg
[21:13] <racarr> it seemed to be doing so well and was ont he on device install and now lonnng black screen
[21:15] <racarr> ok I need to let my phone charge for > 30 minutes apparently
[21:59] <thomi> kgunn: racarr, anyone else - packages for racarr's branch are now available from here: https://jenkins.qa.ubuntu.com/view/All/job/mir-saucy-armhf-ci/77/
[21:59] <thomi> download them to phone with wget, and install with dpkg. job done.
[22:11] <kgunn> thomi: does it actually work ?
[22:12] <kgunn> drumroll
[22:12] <thomi> just installing now
[22:15] <olli> drumroll
[22:15] <thomi> still installing...
[22:16] <thomi> you all understimate the crappieness of NZ "broadband"
[22:16] <olli> you install via broadband?
[22:16] <olli> did you build a whole new image?
[22:17] <thomi> nah, just downloading the new mir packages
[22:17] <thomi> and their dependencies
[22:17] <thomi> 3 minutes left...
[22:20] <olli> I see, no local build
[22:20] <olli> I thought you might have done a local build and as such using "broadband" didn't compile
[22:21] <thomi> 30 seconds....
[22:21] <thomi> olli: I tried, but it was faster to let the CI machinery do the build for me
[22:22] <kgunn> olli: ^ and that's a cf
[22:22] <olli> cf?
[22:22] <olli> as in cluster f?
[22:22] <kgunn> c=cluster
[22:22] <olli> I hear you
[22:23] <kgunn> olli:  and i built local using the meta chroot...which built fine, but when i installed the so's manually it didn't work
[22:23] <kgunn> so...the whole pbuilder thing is the _right_ way
[22:24] <olli> yep
[22:24] <thomi> hmmmm
[22:24] <racarr> ok did some chores while my phone recovered...back on board now :)
[22:25] <olli> that doesn't sound like the cheering I was hoping for
[22:25] <thomi> so I don't see the logging output anymore
[22:25] <thomi> it works!
[22:25] <thomi> but I don't see the log messages I was looking for
[22:25] <thomi> but hey
[22:25] <thomi> it freaking works :)
[22:25] <kgunn> hells yeah
[22:26]  * thomi runs some AP test suites
[22:26] <kgunn> justice leaque right there
[22:26] <olli> thomi, ok, getting closer to the cheers
[22:26] <olli> so
[22:26] <olli> thomi, how is the phone performance
[22:26] <olli> any noticeable lag
[22:27] <thomi> olli: tests seem to be running quickly
[22:27]  * kgunn almost thinks olli wants there to be lag
[22:27] <thomi> I'll run the complete test suite set and see what happens
[22:27] <thomi> but the input problem seems to be solved
[22:28] <kgunn> thomi: so ubuntuuitoolkit worked basically...any others
[22:28] <racarr> there is definitely still lag on n4
[22:28] <kgunn> racarr: i think olli meant, with this fix in did it get worse
[22:29] <racarr> nah
[22:31] <olli> just checking
[22:33] <thomi> uh oh
[22:34] <kgunn> :-| ?
[22:34] <thomi> a bunch of AP tests locked up, and now the phone doesn't respond to my touches
[22:34] <thomi> as in, my actual finger
[22:34] <thomi> but unity8 is still running
[22:35] <kgunn> thomi: do you have an error like "[InputReader]  Touch device 'autopilot-finger' did not report support for X or Y axis!  The device will be inoperable."
[22:36] <thomi> kgunn: nope
[22:36] <thomi> but then, for some reason, I get no mir logging at all
[22:36] <kgunn> what does /userdata/.cache/upstart/unity8.log say
[22:36] <ricmm> I think Mir just fried my screen
[22:36] <ricmm> I have this white-ish cloud on top of everything
[22:37] <ricmm> super sad
[22:37] <kgunn> ricmm: GN or N4 ?
[22:37] <ricmm> N4
[22:37] <kgunn> ricmm: was this testing kdub 's unblank fix ?
[22:37] <thomi> kgunn: http://paste.ubuntu.com/6185918/
[22:37] <ricmm> not really just normal usage
[22:38] <ricmm> tracking some issue that required me restart mir a bunch of times
[22:38] <racarr> we all overheat our phones a lot :/
[22:38] <ricmm> this happened before and disappeared rather fast
[22:38] <ricmm> seems like its fading away slowly
[22:38] <ricmm> maybe it is indeed overheated
[22:38]  * ricmm puts it in the freezer
[22:38] <kdub> yeah, probably overheated
[22:38] <racarr> lol
[22:39] <thomi> racarr: am I going crazy? Why don't I get mir log messages anymore? I set those mir log env vars
[22:39] <racarr> kdub: Maybe the code to hack the users brain through electrical impulses out of the touch screen went bad.
[22:39] <kdub> i run mir on the phone off the usb port in my freezer
[22:39] <kdub> don't know how all of you run it...
[22:39] <kdub> :P
[22:39] <kgunn> thomi: anything in /var/crash
[22:39] <racarr> thomi: Some of the android stuff goes to stderr I believe is
[22:39] <racarr> a possibility
[22:40] <thomi> kgunn: yeah, but not from today
[22:40] <kdub> ricmm, usually temperature warnings will appear in logcat
[22:40] <ricmm> maybe this means I need to stop for the day
[22:40] <thomi> racarr: this worked yesterday
[22:40] <ricmm> as its my personal phone
[22:40] <kdub> but really, i've never overheated my phone to the point it stops working
[22:40] <kgunn> thomi: mmm, this was what i saw too...no logging
[22:40] <ricmm> it wasnt really hot
[22:40] <ricmm> its something else
[22:40] <ricmm> it was workin fine, I restart mir and the cloud was there
[22:40] <ricmm> rebooted and it was still there on the Google logo
[22:41] <ricmm> slowly fading away
[22:41] <ricmm> left some burned dash items there as well, which are almost completely gone by now
[22:41] <kdub> very strange
[22:41] <ricmm> witchcraft
[22:41] <ricmm> kgunn: what kind of "team" are you running?
[22:41]  * ricmm calls a priest
[22:41] <kgunn> :)
[22:42] <kgunn> racarr: kdub we need to help thomi on the logging situation....or at least, i guess racarr should be runnable in a moment
[22:43] <kdub> logging situation?
[22:43] <thomi> kgunn: racarr: something in that branch seems to have killed logging, as strange as that sounds
[22:43] <racarr> im setting up the autopilot stuff now
[22:43] <kgunn> thomi: double check, did you echo your env variables
[22:43] <racarr> I think that's
[22:43] <racarr> almost definitely not what happened :p
[22:43] <thomi> I've now tried with both upstart and without
[22:44] <thomi> kgunn: yeah, with 'initctl list-env' I can see that they're set correctly
[22:45] <thomi> even without upstart, and exporting those variables directly I don't see any logs
[22:46] <thomi> racarr: this is still correct, yes?
[22:46] <thomi> initctl set-env MIR_SERVER_INPUT_REPORT=log
[22:46] <thomi> initctl set-env MIR_SERVER_LEGACY_INPUT_REPORT=log
[22:46] <racarr> setting up autopilot now
[22:46] <racarr> I believe so, I don't know what initctl does though, but the env variables are still right
[22:48] <racarr> err how am I supposed to install the packages from CI
[22:49] <racarr> I am getting hundreds of apt errors about overwriting some file about /tmp/var/ci blabla
[22:50] <racarr> *patiently waits on apt*
[22:53] <thomi> racarr: huh?
[22:54] <thomi> racarr: dpkg -i package_name.dev
[22:54] <thomi> err, sudo ...
[22:54] <thomi> racarr: initctl is upstart
[22:54] <racarr> dpkg -i * led to disaster
[22:54] <racarr> :(
[22:54] <racarr> running an apt-get update an apt-get -f and
[22:54] <racarr> all that such
[22:54] <thomi> racarr: right, because you installed the -dev packages, didn't you:)
[22:56] <racarr> thomi: I guess, grabbed all the packages and dpkg -i them XD
[22:56] <racarr> didnt have the dev packages before
[22:56] <thomi> yeah
[22:56] <thomi> but that's ok, apt-get install -f will sort it out
[22:57] <racarr> no apt wotn work because
[22:57] <racarr> it cant find the archive file for libmirserver4
[22:57] <racarr> which it claims needs to be reinstalled ><
[22:58] <thomi> racarr: you shouldn't have done an apt-get update
[22:58] <thomi> now it's trying to install newer versions :-/
[22:58] <racarr> it was the same before...
[22:58] <thomi> racarr: rm your -dev packages
[22:58] <racarr> no it can't install anything apt just immediately bails
[22:58] <thomi> and do dpkg -i *.deb
[22:58] <racarr> mm I removed the dev packages
[22:58] <racarr> and dpkg -r them
[22:58] <thomi> cool
[23:00] <racarr> g libmirprotobuf0_0.0.12+13.10.20131001.1bzr1101pkg0saucy77_armhf.deb (--install): unable to install (supposed) new info file `/var/lib/dpkg/tmp.ci/postinst': File exists
[23:00] <racarr> Preparing to replace libmirserver4:armhf 0.0.12+13.10.20131001.1bzr1101pkg0saucy77 (using libmirserver4_0.0.12+13.10.20131001.1bzr1101pkg0saucy77_armhf.deb) ...
[23:00] <racarr> err, pkg: error processing:
[23:01] <thomi> dude
[23:01] <racarr> then dependency problems
[23:01] <thomi> WTF did you do!?
[23:01] <thomi> that's totally borked
[23:01] <thomi> re-flash?
[23:01] <thomi> in the mean time... why don't I get any log messages?
[23:05] <racarr> all the way down
[23:05] <racarr> I dunno I downloaded all the packages and dpkg -i * them :(
[23:05] <racarr> lol
[23:05] <racarr> apparently not very well
[23:05] <racarr> I think it might fix itself if I coudl resolve the dependencies but I cant use apt
[23:05] <racarr> apt-get download maybe
[23:05] <racarr> grr resolved the dependnecies but this
[23:05] <racarr>  /tmp.ci/postint thing
[23:05] <racarr> keeps it from working
[23:05] <racarr> but there is not even such a folder /var/lib/dpkg/tmp.ci/postint
[23:08] <racarr> even dpkg --forrce-all doesn't work
[23:08] <racarr> I don't know
[23:08] <racarr> I am reflashing
[23:08] <racarr> as for log messages
[23:08] <racarr> I think almost certainly they aren't being captured to a file
[23:08] <racarr> or the environment isn't really set
[23:09] <racarr> start exploring, i.e. do mir demos produce logs
[23:09] <racarr> is the environment really set (attach with GDB to the running process and verify)
[23:09] <kgunn> i've never been able to get a log
[23:09] <racarr> do the other mir logs work?
[23:13] <thomi> racarr: this was working yesterday
[23:13] <thomi> with upstart, I'm totally confident that the variables are set as we expect them to be
[23:13] <kgunn> robert_ancell: hey...i need a pointer...probably just a bzr command i lack knowledge of
[23:13] <thomi> anyway, time for lunch for me
[23:13] <kgunn> https://code.launchpad.net/~kgunn72/mir/bump-libmirserver5/+merge/188877
[23:14] <kgunn> robert_ancell: if you look at that ^
[23:14] <kgunn> you'll see i attempted to replace debian/libmirserver4.install with 5
[23:14] <kgunn> so on my local i did mv libmirserver4.install libmirserver5.install
[23:15] <kgunn> but when i pushed...it didn't seem to include the libmirserver5
[23:15] <kgunn> wondering if there was a step in the bzr commit i missed
[23:19] <kgunn> grabbing food brb...thomi / racarr ...i know its not perfect, but its progress lend me your thots no merging
[23:20] <kgunn> thomi: would it be worth it to reflash, enable mir, enable logging ??
[23:20] <kgunn> then stepwise ensure logging continues working
[23:21] <thomi> kgunn: I'm running more tests now, I'll keep running tests on mir over today.
[23:21] <thomi> kgunn: TBH, I'm getting pretty fed up with all the various quirks/issues I'm running into
[23:22] <thomi> so I'll run the rest of the tests, and see what happens
[23:26] <racarr> yay no apt suicide this time
[23:33] <racarr> no unity8 though once I touched .display-mir
[23:33] <racarr> these packages must be ABI incompatible?
[23:33] <racarr> thomi: Which unity-mir, etc are you using with these packages
[23:34] <thomi> racarr: hmmm, says "none"
[23:34] <thomi> oh FFS
[23:34] <thomi> guess what?
[23:34] <thomi> I'm not running freaking mir
[23:35] <racarr> libunity-mir1
[23:35] <thomi> 0.1+13.10.20131001-0ubuntu1
[23:35] <thomi> rebooting now
[23:36] <racarr> it seems unlikely the unity-mir is going to work with these packages
[23:36] <racarr> kgunn: which ppa has the most recent builds of
[23:36] <racarr> unity-mir against development-branch?
[23:36] <thomi> adb shell
[23:37] <thomi> oops
[23:37] <racarr> thomi: adb hell is the what the pros use
[23:37] <thomi> is this channel logged?
[23:37] <racarr> I dunno probably one way or another
[23:38]  * thomi restrains himself
[23:38] <racarr> no adb hell is a real command
[23:38] <racarr> try it
[23:38] <racarr> :p
[23:38] <thomi> racarr: I know
[23:38] <racarr> aha
[23:38] <racarr> sorry
[23:38] <racarr> ok so to test this we need an updated unity-mir and platform-api mirserver too
[23:38] <thomi> racarr: I'm referring to the burning rage I'm feeling right now, and my desire to express it verbally here, in this channel
[23:39] <thomi> racarr: surely your change doesn't break ABI?
[23:39] <racarr> no but this package doesn't contain only that change vs the
[23:39] <racarr> packae ina rchive almost certainly
[23:40] <racarr> well I dunno, actually even after I removed .display-mir im still not getting anything so I think it was
[23:40] <racarr> phablet-click-test-setup
[23:40] <racarr> that broke things.
[23:40] <racarr> I shouldn't have installed the packages and run that at the same time
[23:40] <thomi> kgunn: ^^
[23:41] <racarr> oh hey I tried to reflash again and there are new images
[23:41] <racarr> going to take things STEP by step this time :)
[23:42] <thomi> kgunn: this is totally fubar. I've run out of patience. I say merge it, it can't be worse than what we already have. merge it and spin up a new image
[23:43] <thomi> right now this feels like a waste of my time, at least until we get something that boots all the way
[23:47] <racarr> theres nothing fubar about it we have just been skipping steps
[23:48] <racarr> on the image, unity works, then mir works, then the new mir packages are installed and mir doesn't work
[23:48] <racarr> but that's expected if there are any ABI changes between development-branch and what is in archive