[00:15] <lool> so I reinstalled
[00:15] <lool> I got the same bug, but eventually it started
[00:16] <lool> the timing for pressing power button might matter
[00:43] <lool> racarr, kgunn: Pretty good news
[00:44] <lool> racarr, kgunn: It was borderline unstable, but now that I have hud with it, unity8 doens't crash anymore and boot is much more stable
[00:44] <lool> and everything is going in archive, one at a time
[01:17] <kgunn> lool: thanks man!
[01:18] <lool> kgunn: we have an issue with Hud
[01:18] <lool> kgunn: it's likely regressing the desktop
[01:19] <lool> kgunn: who would be able to help this?
[01:19] <lool> kgunn: I can land without it, but the results will be crappy
[01:19] <kgunn> lool: i assume its likely backend ?? ted would be best
[01:19] <kgunn> but doesn't seem on
[01:19] <lool> ted isn't up til 10 hours
[01:19] <lool> at least
[01:19] <kgunn> i know the issues were around the backend....
[01:20] <lool> kgunn: So they added a platform-api backend
[01:20] <lool> kgunn: but on desktop I think we still want bamf
[01:20] <lool> but we dropped the bdep
[01:20] <kgunn> olli_: you on ?? ^
[01:20] <kgunn> lool: thostr_ will be our best bet euro am
[01:21] <lool> ok
[01:21] <lool> I might try just adding the bdep
[01:21] <kgunn> you could get some sleep man and hit it in the morning
[01:21] <lool> yeah that too
[01:22] <kgunn> ricmm_: know anyone who knows about hud backend ?? ^
[01:26] <racarr> back
[01:26] <racarr> seems like we definitely need bamf on desktop
[01:31] <racarr> lool: Good to hear image is working better with hud :D
[01:31] <racarr> is boot faster now too?
[01:32] <racarr> unity mir boot has been really slooow
[01:32] <racarr> and ive kind of suspected it has to do with errors about hud timeouts :p
[01:45] <olli_> kgunn, yep
[04:19] <ricmm_> kgunn: what happened?
[04:20] <ricmm_> lool: I explicitly remember them saying "we both tested on desktop and phone and all works fine"
[04:21] <ricmm_> lool: how did the MR land to trunk if it didnt have the bamf build dep?
[04:22] <ricmm_> oh that was 3 hours ago
[04:22] <ricmm_> crap
[04:22] <ricmm_> his fix looking good
[04:22]  * ricmm_ -> zzz
[04:25] <ricmm_> kdub_: btw if you are still around
[04:26] <ricmm_> kdub_: timings show that unity8 is busy blocking on buffer swap for about ~50ms per frame every other frame or so
[04:26] <ricmm_> when rendering intensively
[04:31] <ricmm_> racarr: kind of suspected? its a known thing since ever!
[05:18] <racarr> ricmm_: I guess I didnt know it was known because the one or two times I mentioned it no one said anything
[05:18] <racarr> and I was just like
[05:18] <racarr> ok move on!
[05:21] <RAOF> Ok. How have I managed to break egl-platform-mir?
[05:26] <duflu> RAOF: If you expect either a useful or amusing answer, I can't comment
[05:32] <duflu> racarr: (1) log off, else (2) Should bug 1233245 have Mir task?
[05:33] <ricmm_> that bug is done afaik
[05:33] <duflu> ricmm_: BTW, the "50ms per frame", what device?
[05:33] <ricmm_> mako
[05:33] <duflu> Oh. Mako should be better than that already
[05:34] <ricmm_> theres a whole bug going on since the fencing was introduced to remove the tearing
[05:34] <ricmm_> of course it *should* be
[05:34] <ricmm_> but it hasnt been for a while
[05:34] <duflu> ricmm_: Yeah I was going to point you at that bug
[05:35] <tvoss> ricmm_, do you know if kdub tried switching to triple buffering while I was sleeping?
[05:35] <ricmm_> tvoss: he didnt because apparently its not trivial to do
[05:38] <duflu> It occurs to me we have a significant bottleneck for touch with only one Android person on mir-team
[05:49] <RAOF> Dear bandwidth: where have you gone? :(
[05:57] <tvoss> didrocks, salut :)
[05:57] <didrocks> hey tvoss!
[06:35] <alf_> lool: Which PPA contains the packages you used to test the fix to the close.qml crash (or have the packages reached the archive now)?
[06:51] <alf_> lool: FWIW, with latest packages from the archive, I can't reproduce the crash anymore
[06:54] <RAOF> Bah! How was mesa mis-built?
[06:56]  * mlankhorst looks at excuse calendar
[06:57] <mlankhorst> high pressure system failure
[07:05] <RAOF> Current theories include: cosmic rays, and clang.
[07:06] <mlankhorst> well a computer generated my excuse, so it's more reliable
[07:06] <duflu> But did cosmic rays affect the computer's output?
[07:08] <mlankhorst> we're not in space
[07:08] <duflu> Yes we are
[07:08]  * duflu goes to close the pod bay doors
[08:02] <lool> alf_: it's all in #90 now
[08:02] <lool> alf_: racarr also gets the crash with latest tip
[08:02] <lool> alf_: I haven't tried again though
[08:02] <lool> alf_: maybe we landed something else from archive in image that we were lacking in testing
[08:06] <alf_> lool: are you tests with mako or maguro
[08:06] <alf_> ?
[08:08] <lool> alf_: haven't retried yet
[08:08] <lool> alf_: but if you're not seeing it with latest image great
[08:08] <lool> alf_: mako
[08:09] <alf_> lool: ok, please give it another try when you can and let me know
[08:09] <lool> yup
[08:09] <lool> breakfast first
[08:49] <duflu> Hey I got my phone back!... How do I tell the image number (like "90")?
[08:50] <alf_> duflu: cat /etc/media-info gives you some information, which you can use to find the image number
[08:50] <duflu> Ta
[08:52] <alf_> duflu: of course, if you upgrade packages then this is not accurate any more
[08:52] <duflu> None seem to need upgrading...
[08:53] <tvoss> duflu, just reflash 90 :)
[08:53] <duflu> Did we kill off /tmp/mir_socket for unity8?
[08:55] <alf_> duflu: look in $XDG_RUNTIME_DIR
[08:57] <alf_> tvoss: a great problem with reflashing is that it deletes your development environment on the phone... it's a big waste of time to set it up again (get all the build-deps and -dbg(sym) packages, tools etc)
[08:58] <alan_g> alf_: +1
[08:58] <alan_g> alf_:  (and every time I think I understand it well enough to write a script something changes)
[09:01] <mlankhorst> hm anyone got something for me to look at? :P
[09:04] <alf_> duflu: since you have a fresh image, do you have a moment to try https://bugs.launchpad.net/qtubuntu/+bug/1237052 ?
[09:04] <duflu> alf_: Just put it away. I'll get back to it soon
[09:05] <tvoss> alan_g, https://code.launchpad.net/~thomas-voss/mir/add-pthread-linker-and-preprocessor-flags/+merge/190316
[09:05] <alf_> duflu: ok, btw you don't need to build anything, all fixes are in the archive now (check my last comment in that bug)
[09:06] <alan_g> tvoss: ack
[09:07] <tvoss> alan_g, waiting for CI to produce a testable package
[09:07] <alf_> mlankhorst: nested Mir EGLImage support is still pending if you are interested ;)
[09:08] <mlankhorst> hm fine :P I'll poke it a bit more
[09:10] <alf_> mlankhorst: I know that RAOF also took another look recently, but I am not sure if there was any progress
[09:10] <alf_> RAOF: ^^
[09:10] <alf_> mlankhorst: (or at least that he wanted to take a look)
[09:20] <alan_g> tvoss: see https://code.launchpad.net/~thomas-voss/mir/add-pthread-linker-and-preprocessor-flags/+merge/190316/comments/436722
[09:23] <tvoss> alan_g, duflu: it's about our own usage of pthread
[09:23] <duflu> tvoss: Can you detail the findings in the MP?
[09:24] <tvoss> duflu, the linked bug points to a very weird issue when a client tries to access the display configuration. Same happens for maliit server, which results in a lot of crashes during test automation
[09:25] <duflu> tvoss: Ah yes, spent time staring at those crashes today
[09:25] <tvoss> duflu, alan_g was able to reproduce the issue with a simple program using a std::unique_lock and not adding -pthred
[09:25] <tvoss> -pthread
[09:25] <alan_g> tvoss: the maliit server definitely pulls in pthreads
[09:25] <tvoss> alan_g, but: our client library is not compiled with that flag
[09:25] <tvoss> alan_g, and that's where the exception is thrown
[09:26] <duflu> tvoss: It's a theory, but I'm not convinced the Mir code is in need of any more "-pthreads", because it would be crashing immediately in the same way (which it doesn't)
[09:27] <alan_g> tvoss: what duflu said
[09:27] <tvoss> duflu, anyway, I'm only sticking to what the pthread manual suggests: add -pthread
[09:27] <tvoss> alan_g, duflu I'm basically waiting for jenkins to produce a testable package, thus the mp
[09:27] <alan_g> duflu: I don't think it hurts to try this
[09:27] <duflu> AFAIK -pthread just defines some macros and adds -lpthread to LDFLAGS
[09:28] <tvoss> duflu, implementation defined
[09:28] <tvoss> duflu, usually REENTRANT is set, but could be more complex for arm for example
[09:28] <duflu> alan_g: It's likely unnecessary bloat to link libraries not all binaries need. Though I suspect all Mir binaries do :/
[09:29] <tvoss> duflu, if you have got a better idea to solve it -> go for it :) as long as the maliit server crashes are down to 0 in http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/90:20131010:20131010/4644/
[09:29] <alan_g> duflu: If it fixes the problem that is a useful data point
[09:29] <tvoss> duflu, library bloat -> micro optimization, let's save that for later
[09:29] <duflu> Not worth arguing...
[09:30] <tvoss> duflu, ack
[09:30] <duflu> tvoss: Worth a try. Linked bug 1233988 too
[09:31] <tvoss> duflu, thx
[09:31] <tvoss> duflu, can you give the package a spin, too, once ci spits it out?
[09:32] <duflu> tvoss: Sure but I think I'll be gone before then.
[09:32] <tvoss> duflu, ack :)
[09:40] <mlankhorst> alf_: huh? this is messed up
[09:40] <mlankhorst> oh nm :P
[09:55] <mlankhorst> alf_: so I assume the problem is in the nested mir somewhere, what is the image supposed to be for empty server, is it cleared?
[09:56] <alf_> mlankhorst: yes, it's glClear()-ed, and then surfaces are composited
[09:58] <alf_> lool: any luck with https://bugs.launchpad.net/qtubuntu/+bug/1237052 ?
[10:01]  * duflu goes to play with vegetables
[10:05] <tvoss> alan_g, https://jenkins.qa.ubuntu.com/job/mir-saucy-amd64-ci/831/console
[10:05] <tvoss> alan_g, is that known?
[10:07] <alan_g> tvoss: it wasn't to me - but https://bugs.launchpad.net/mir/+bug/1236698
[10:09] <tvoss> alan_g, are you on it?
[10:09] <alan_g> tvoss: I'll add it to my list
[10:12] <lool> alf_: sorry didn't have time so far, but I do now
[10:14] <lool> alf_: and it worked!
[10:14] <lool> alf_: So I didn't have all the in distro changes when I tried that yesterday; I definitely had updated qtubuntu, and had an intermediate update of the mir packages, but not anything else
[10:14] <alf_> lool: \o/
[10:14] <lool> alf_: but now with image #90 it passed
[10:15] <lool> alf_: sorry for the delay in confirming
[10:15] <mlankhorst> alf_: huh..
[10:15] <mlankhorst> why is dri2_create_image_khr_pixmap never called? :P
[10:15] <lool> alf_: I'm glad it's fixed after all, I almost didn't take qtubuntu in because of this
[10:16] <lool> alf_: updated bug too
[10:16] <alf_> lool: thanks
[10:17] <mlankhorst> oh nm
[10:18] <alf_> mlankhorst: :)
[10:18] <mlankhorst> alf_: hm if you use the native platform allocator for allocating buffers, what do you use for allocating the main window for nested?
[10:19] <alf_> mlankhorst: the host mir allocates that and sends us the buffer (host mir uses platform_drm)
[10:19] <mlankhorst> yeah where's the code for importing that?
[10:26] <alf_> mlankhorst: in mesa mir_advance_colour_buffer()
[10:27] <alf_> mlankhorst: it uses the prime_fd from the buffer package
[10:27] <alf_> mlankhorst: i.e. the host mir essentially sends the nested mir the prime fd for the "main window" surface, and nested mir passes that to mesa
[10:29] <mlankhorst> alf_: yeah but if the nested mir has no clients, does anything clear the contents of the bo?
[10:33] <alf_> mlankhorst: yes, it is made current, and glClear() is called
[10:33] <alf_> mlankhorst: prime_fd -> EGLSurface -> make_current -> glClear()
[10:34] <alf_> mlankhorst: (at least this is what should be happening)
[11:11] <mlankhorst> can I somehow enable the spam from mir?
[11:11] <alf_> jibel: I am checking the Mir Testing Notes document for bugs to look into... is bug 1237900 still private?
[11:12] <alf_> jibel: or is it a typo?
[11:12] <alf_> jibel: It's the last bug in Image 90:20131010:20131010 list
[11:36] <jibel> alf_, it is public now but invalid
[11:53] <asac> racarr: alf_: any news on the crashers front?
[11:53] <asac> Saviq: ^^ (unity8 crashes in particular i think)
[12:01] <alf_> asac: Most of the crashes caused by the interaction with Mir have been fixed in the latest image
[12:02] <asac> we still see unity8 crashing http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/91:20131010.1:20131010/4658/webbrowser-app-autopilot/
[12:03] <asac> this doesnt happen with SF
[12:03] <asac> just run webbrowser autopilot
[12:04] <alf_> asac: that seems like https://bugs.launchpad.net/ubuntu/+source/platform-api/+bug/1233988, which is in progress from what I can see
[12:04] <ogra_> can someone tell me where Mir gets the VSYNC info from ?
[12:05] <asac> alf_: there is maliit and unity8 crash
[12:05] <asac> alf_: you say that unity8 crash goes away if maliit doesnt crash?
[12:05] <mlankhorst> bleh stupid thing, glClear being ignored;S
[12:05] <asac> alf_: _usr_bin_unity8.32011.crash
[12:05] <alf_> asac: I am not saying anything :)
[12:05] <asac> hehe
[12:05]  * ogra_ is fiddling with bug 1234743 and moving the VSYNC event from a uevent to a sysfs node makes Mir choke while surfaceflinger still starts
[12:05] <asac> well, you said its in progress most likely... but that smells like the maliit fix
[12:05] <asac> not the unity8
[12:05] <asac> alf_: the unity8 goes away on SF as well
[12:06] <asac> i wouls suggest embracing that as a crash that is caused by MIR interactions
[12:07] <mlankhorst> oh you've got to be kidding me
[12:09] <alf_> asac: not how I diplomatically said that *most* of the crashes... have been fixed ;)
[12:09] <alf_> asac: s/not/note/
[12:09] <asac> right
[12:09] <asac> are you on this one?
[12:09] <alf_> asac: I am now
[12:09] <asac> any leads/hopes?
[12:09] <asac> nice :)
[12:19] <alf_> mlankhorst: ?
[12:25] <mlankhorst> nah was hoping for a more logical explanation, meh
[12:26] <mlankhorst> I'll try without radeon, and use intel, at least it has dri2 support. :P
[13:00] <mlankhorst> alf_: but that code was working with android right?
[13:00] <alf_> mlankhorst: yes
[13:46] <mlankhorst> alf_: only thing i found so far is that linuxvirtualterminal should probably not be created in nested, meh
[14:07] <alf_> tvoss: What's the problem in maliit with bug 1233988? I have found a problem in platform-api related to this, too...
[14:07] <alf_> lool: ^^
[14:11] <alan_g> alf_: tvoss is exploring the theory that because we've not linked the Mir client library against pthreads maliit blows up. (I don't know if the theory has been tested yet)
[14:14] <tvoss> alan_g, issue is solved, it wasn't that in the end
[14:14] <tvoss> alan_g, but: -pthread is still a good idea
[14:15] <alan_g> tvoss: then what was it?
[14:16] <tvoss> alan_g, maliit trying to access mir, without mir running :)
[14:16] <tvoss> alan_g, working on a fix to the platform api
[14:16] <tvoss> alan_g, it should handle that situation more graceful
[14:17] <alan_g> tvoss: "mir running" == there's a Mir connection?
[14:18] <alf_> tvoss: lool: alan_g: see my latest comment and MP in https://launchpad.net/bugs/1233988
[14:21] <mlankhorst> alf_: meh I'll try what happens if I always enable gbm, ran out of other ideas :P
[14:21] <alan_g> alf_: tvoss I see. But Mir is also behaving badly - it ought to fail operations, not crash. (One reason for returning an "Error" connection is that it can provide sensible error mode behaviour)
[14:22] <alf_> alan_g: agreed
[14:22] <tvoss> alan_g, true. I won't find time to fix that part, though
[14:31] <mlankhorst> alf_: ah excellent, if I force the gbm path to be always taken it corrupts too, that makes it a lot easier to debug..
[14:32] <mlankhorst> http://paste.debian.net/55230/
[14:33] <mlankhorst> to the best of my knowledge, it should behave identically right?
[14:57] <alf_> mlankhorst: when you have some time please check https://code.launchpad.net/~hikiko/mir/mir.fix-in-session-leader/+merge/190353 (also see my comment there)
[14:58] <asac> alf_: did your crash investigation give reason for hope :)?
[15:01] <alf_> asac: got caught up in https://bugs.launchpad.net/ubuntu/+source/maliit-framework/+bug/1233988, wanted to fix the strange crash to ensure it's not involved somehow with the ap failures/maliit
[15:01] <alf_> asac: so no direct progress there yet
[15:06] <racarr> good mirning
[15:06] <hikiko> alf_, I replied just now
[15:18] <kgunn> racarr: mornin'
[15:29] <lool> alf_: looking
[15:31] <lool> alf_: platform-api change to detect whether connection is truly good seems a good idea
[15:32] <lool> alf_: but I'd rather not confirm the exact semantics of the functions you're calling etc.
[15:32] <lool> alf_: would someone else review this?  then we can add this to landing plan
[15:33] <racarr> trying out new image :)
[15:34] <alf_> racarr: want to review https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-somewhat/+merge/190378 ? :)
[15:34] <tvoss> alf_, did you remove the anon namespace in the header file? :)
[15:35] <racarr> alf_: only somewhat happy :p
[15:37] <racarr> alf_: +1
[15:37] <alf_> racarr: thanks
[15:37] <racarr> image seems really good
[15:37] <racarr> I'd really like to fix the
[15:37] <racarr> screen unblank buffer
[15:37] <racarr> bla
[15:38] <racarr> actually now
[15:38] <alf_> tvoss: no, why?
[15:38] <asac> any luck on unity8 crashers? :)
[15:38] <asac> lol
[15:38] <racarr> asac: Autopilot you mean?
[15:39] <asac> unity8 crashes
[15:39] <asac> during autopilot its easy to reproduce yes
[15:39] <asac> just run webbrowser AP
[15:39] <asac> and it will crash
[15:39] <asac> 5 out of 6 times
[15:39] <racarr> ok I guess I can work on autopilot failures today
[15:40] <tvoss> alf_, an anonymous namespace in a header file is usually a bad idea
[15:40] <asac> racarr: note that its not really autopilot failures... its just the best and easiest to reproduce crashers we have right now :)
[15:40] <asac> we see loads of crashers that are hard to reproduce in QA
[15:40] <asac> so we can start here and hopefully the world will improve :)
[15:41] <racarr> asac: :D
[15:41] <asac> anyway. let me know ifyou need something
[15:41] <asac> those are real crashers ... we dont start unity with special instrumentation flags or anythig
[15:41] <asac> if we run application autopilots
[15:42] <asac> thanks!
[15:42] <alf_> tvoss: sure, "why" == is it related to the 1233988 problem in some way?
[15:43] <tvoss> alf_, nope
[15:43] <alf_> racarr: btw, keep in mind that running the tests one by one seems to work just fine, which give a hint to what the problem is...
[15:43] <alf_> tvoss: ok :)
[15:44] <asac> alf_: you talk about webbrowser?
[15:44] <asac> there are two things:
[15:44] <asac> a) webbrowser tests fail and make unity super slow after they finish
[15:44] <lool> racarr: didn't top approve?
[15:44] <asac> b) webbrowser tests crash unity8 more or less relliably
[15:44] <racarr> asac: I...lost the bug that someone put autopilot instructions in. Is there a summary somewhere?
[15:44] <lool> ah right, two reviews I guess
[15:45] <lool> alf_: so once that's top approved ping me to get it in PPA for testing
[15:45] <racarr> lool: Hmm no someone could top approve I guess
[15:45] <asac> racarr: https://wiki.ubuntu.com/Touch/Testing#Testing_your_Ubuntu_Touch_Code_before_submission
[15:45] <asac> give that a shot
[15:45] <kgunn> racarr: for running AP tests run 'phablet-click-test-setup' to download all the test cases
[15:45] <kgunn> 'phablet-test-run <suite>'...e.g. unity8
[15:45] <lool> to run tests:
[15:45] <alf_> racarr: apt-get install webbrowser-app-autopilot, autopilot run <test>
[15:45] <lool> a) touch /userdata/.writable_image
[15:45] <asac> alf_: dont do that
[15:45] <lool> b) reboot
[15:45] <racarr> tvoss: Want to double sanity check the papi branch and top approve?
[15:45] <lool> c) unlock screen
[15:45] <asac> alf_: use the isntructions above
[15:45] <lool> then run:
[15:45] <lool> ./phablet-test-run -p webbrowser-app-autopilot webbrowser_app
[15:46] <lool> or for unity8:
[15:46] <tvoss> racarr, feel free
[15:46] <lool> ./phablet-test-run -n -p unity8-autopilot unity8
[15:46] <asac> otherwise we will argue until we are blue about not seeing the same things
[15:46] <alf_> asac: why not?
[15:46] <lool> alf_: use the phablet-test-run interface
[15:46] <asac> alf_: doesnt matter... just strictly follow the instructionms
[15:46] <lool> alf_: so that we all do the same thing
[15:46] <asac> alf_: people dont get it right and do stuff to their device
[15:46] <racarr> *parsing* XD thanks all
[15:46] <asac> and then claim the tests succeed and move on
[15:46] <ogra_> make sure to reboot after the unity8 tests ... never run an app test after unity
[15:47] <asac> and i have to argue for 2 days with them until they finally see that they didnt do it the same way
[15:47] <asac> lool: please refer to these isntructions: https://wiki.ubuntu.com/Touch/Testing#Testing_your_Ubuntu_Touch_Code_before_submission
[15:47] <kgunn> racarr: what do you need top approved ?
[15:47] <asac> so we start consolidating it at one place
[15:47] <racarr> kgunn: https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-somewhat/+merge/190378 I did it though
[15:48] <kgunn> lool: can we get a CI run & landing on https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-somewhat/+merge/190378
[15:49] <tvoss> kdub, ping
[15:50] <kdub> hello
[15:50] <kgunn> Saviq: just to make sure we don't have people running round duplicating effort.... racarr is going to look into crashes associated with webbrowser AP tests
[15:50] <kgunn> shout if someones already working
[15:51] <kdub> tvoss, going to try to shift waiting to the compositor side, should make unity wait less
[15:51] <lool> kgunn: autolanding actually -- ci ran
[15:51] <tvoss> kdub, sounds good, had the same idea.
[15:51] <kdub> tvoss,  i'll let you know once i've tested it... just getting my phone all put together
[15:51] <lool> kgunn: was waiting for the top approve  :-)
[15:51] <tvoss> kdub, I will grab a quick bite and be back after that
[15:52] <mlankhorst> argh I don't see why this should give different results..
[15:52] <kgunn> lool: so we are back to normal everywhere ? (no more manual merges)
[15:52] <Saviq> kgunn, tvoss, racarr, maliit loops on unity8 exit with https://bugs.launchpad.net/ubuntu/+source/maliit-framework/+bug/1238107
[15:52] <lool> kgunn: running
[15:52] <Saviq> tvoss, I saw the copy_on_client DisplayConfiguration somewhere before
[15:52] <Saviq> tvoss, today, that is
[15:53] <lool> kgunn: Only on some projects; Francis sent a list; I dont know for yours, but you sometimes have to wait 15mn for a run, so pinging might still be useful when urgent
[15:53] <kgunn> ack
[15:53] <lool> asac: I've updated the AP instructions with my own additions for other testsuites and for Click instructions
[15:53] <tvoss> Saviq, something went out of scope too early
[15:54] <tvoss> Saviq, racarr the DisplayConfiguration is NULL
[15:55] <Saviq> tvoss, I expect unity8 hanging at the same time to be very much related, correct?
[15:55] <alf_> Saviq: copy_on_client problem, essentially means that the connection to the server failed for some reason (no server, connection rejected), and platform-api wasn't handling this well, see https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-somewhat/+merge/190378
[15:55] <Saviq> alf_, yay, so that's fixed
[15:55] <Saviq> alf_, I knew I saw that somewhere
[15:55] <racarr> Does mthis looks like
[15:55] <racarr> ...
[15:55] <racarr> what alf said
[15:55] <Saviq> alf_, racarr yes, it does
[15:55] <racarr> the mutex is null which can only happen if the mirconnection pointer
[15:56] <Saviq> yay, sorted
[15:56] <racarr> is invalid
[15:56] <tvoss> Saviq, not entirely sure, could be
[15:56]  * Saviq pushes unity8's crash on exit
[15:56] <asac> lool: yeah. all this know how should be somewhere in phablet-tools i believe
[15:56] <asac> lool: would be great if phablet-test-run unity8-autopilot would just do the rigth thing
[15:56] <asac> :)
[15:57] <alf_> Saviq: note, that's this only explains crashes for new connection attempts. If you see this for an existing connection then it's something else.
[15:59] <Saviq> alf_, ah, that's on unity8 exit
[15:59] <Saviq> alf_, so unity8 + maliit were connected, but unity8 was shutting down, pushed maliit over the edge into spinning, unity8 stuck
[16:01] <racarr> So what is expected to happen with the webbrowser ap tests?
[16:01] <racarr> I dont see a unity8 crash
[16:02] <racarr> but eventually the tests themselves crash...  File "/usr/lib/python2.7/socket.py", line 303, in flush
[16:02] <racarr>     self._sock.sendall(view[write_offset:write_offset+buffer_size])
[16:02] <racarr> error: [Errno 32] Broken pipe
[16:03] <tvoss> asac, ^
[16:03] <racarr> though it seems like they are still running lol because stuff is still going on on my phone
[16:03] <asac> racarr: what device are you on?
[16:03] <Saviq> tvoss, that looks like a Qt bug https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1238116
[16:03] <racarr> asac: mako
[16:04] <Saviq> tvoss, unity8 crashes shutting down on Mir
[16:04] <tvoss> Saviq, hang on
[16:04] <Saviq> tvoss, hanging
[16:04] <asac> racarr: so not sure. you might be struck by something flaki :)
[16:04] <asac> lol
[16:05] <asac> so sometimes MTP is funny and takes over adb and you disconnect
[16:05] <asac> in those cases, just reboot and try again
[16:05] <asac> it doesnt happen all of the times :) ... wait until you have MTP seen mounted i guess
[16:05] <racarr> mm
[16:06] <racarr> going to try unity8 next...
[16:06] <racarr> I have to run soon though, one more dental filling :( (they couldn't quit finish last time)
[16:06] <racarr> ill be back before too long though
[16:06] <alan_g> alf_: I think your issues with this are addressed? https://code.launchpad.net/~robertcarr/mir/socket-messenger-race/+merge/187647
[16:09] <lool> tvoss: I tested adding a rm to unity8 upstart job; then unity8 crashed and when I used it again, the keyboard would show up when entering an input field, but its window would disappear each type I type letter
[16:09] <lool> tvoss: so I think it was still using the old socket
[16:10] <tvoss> lool, do you have both pre start and post stop?
[16:12] <tvoss> Saviq, looking at it, need to debug
[16:12] <tvoss> Saviq, what did you do?
[16:12] <tvoss> Saviq, gut feeling tells me: qt
[16:13] <lool> tvoss: no
[16:13] <lool> tvoss: also didn't check whether maliit indeed restarted
[16:13] <Saviq> tvoss, that's just unity8 exiting
[16:13] <lool> tvoss: I'm running out of time for today
[16:13] <Saviq> tvoss, 100% reproducible
[16:13] <racarr> got unity8 autopilot running at least. um
[16:13] <tvoss> lool, sure, no problem ... got your current pushed to a branch?
[16:13] <racarr> some tests seem to be running
[16:13] <lool> need to get some sleep tonight, might not be able to test this further today
[16:13] <Saviq> tvoss, let me see if another one will be the same trace
[16:14] <tvoss> Saviq, ack
[16:14] <racarr> its a little confusing XD.
[16:14] <racarr> will dig deepeer on crashes when I get back
[16:15] <Saviq> racarr, they're all running, more or less
[16:16] <Saviq> racarr, but only the first one in a run gets input
[16:16] <ogra_> lool, tvoss https://code.launchpad.net/~mterry/session-manager-touch/socket/+merge/186391
[16:16] <ogra_> not sure if that helps anything
[16:16] <ogra_> (i had it on my MP monitoring list)
[16:19] <Saviq> racarr, maybe you'd have an idea about that? or could help tracking it down?
[16:19] <Saviq> racarr, if you run two or more unity8 tests within one autopilot run, only the first one will get input
[16:24] <lool> ogra_: I commented on the branch
[16:24] <alf_> alan_g: yes, approved
[16:27] <lool> tvoss: did you send the -pthread thing to trunk?
[16:27] <tvoss> lool, nope
[16:27] <lool> tvoss: we have a slot for it FYI
[16:27] <tvoss> lool, ah okay ...
[16:27] <tvoss> there was some discussion on the mp
[16:28] <lool> looking
[16:28] <lool> tvoss: I miss the devel mp?
[16:28] <lool> tvoss: only have the trunk one
[16:29] <lool> tvoss: In any case -lpthread is wrong and should be fixed to -pthread
[16:29] <lool> even if it didn't fix whatever we were seeing
[16:29] <lool> tvoss: this is how I had changed unity8.conf upstart job: http://paste.ubuntu.com/6218716/
[16:30] <tvoss> lool, hang on
[16:31] <tvoss> lool, https://code.launchpad.net/~thomas-voss/mir/add-pthread-linker-and-preprocessor-flags/+merge/190316
[16:31] <lool> thanks
[16:31] <tvoss> alan_g, removed the linked bugs
[16:31] <lool> will add to tracking
[16:31] <lool> tvoss: oh that's against trunk again
[16:31] <lool> isn't it?
[16:32] <lool> tvoss: that's the one I had
[16:32] <tvoss> lool, yup, that's against trunk, want me to resubmit against devel?
[16:32] <lool> tvoss: Just send it against devel branch?
[16:32] <lool> tvoss: I think that's mir process
[16:32] <lool> tvoss: first land in devel, then merge devel in trunk
[16:32] <lool> tvoss: but others here are more knowledgeable on this
[16:33] <alan_g> tvoss: yes
[16:33] <alan_g> lool: "
[16:34] <alan_g> lool: @"In any case -lpthread is wrong and should be fixed to -pthread" - comment against the MP. chat gets lost
[16:34] <tvoss> alan_g, lool resubmitted
[16:39] <alan_g> tvoss: spurious changes: debian/changelog
[16:43] <om26er> kdub, btw if you need any help testing something. I am at service
[16:43] <kdub> thanks om26er
[16:46] <mlankhorst> alf_: but the diff I posted is the smallest way to reproduce the problem, if you apply it it happens with normal mir clients too and not just nested :P
[16:49] <mlankhorst> and I have no explanation as to why
[16:58] <pete-woods> but I'll keep looking
[17:05] <jono> really nice job on Mir on the N4 :-)
[17:05] <jono> working pretty good for me :-)
[17:16] <ogra_> jono, just because your last name isnt -autopilot
[17:16] <ogra_> ther test results are still pretty bad (but we're getting there)
[17:20] <tvoss> lool, alan_g|EOD https://code.launchpad.net/~thomas-voss/mir/add-pthread-linker-and-preprocessor-flags-2/+merge/190432
[17:21] <lool> tvoss: approved but not top approved; leaving that to mir folks
[17:21] <tvoss> lool, ack, sorry, took me a while, my bzr foo was lacking
[17:22] <lool> tvoss: np, added to landing plan too, but will need this to go to trunk too
[17:23] <lool> alf_: You might have expected me to test your branch; I just made sure it went to PPA and someone else will try it in landing plan; might be good to provide some instructions on testing it
[17:23] <lool> alf_: sorry, not staying long tonight, otherwise would have tried it out
[17:23]  * lool  off  &
[17:27] <tvoss> lool.sleep()
[17:27] <tvoss> lool.force_to_sleep();
[17:27] <tvoss> lool, awesome job, dude
[17:32] <jono> ogra_, yeah, seems like a good integration result
[17:33] <jono> and now everyone can focus on bugfixing
[17:33] <ogra_> well, first on getting the tests to work again
[17:33] <ogra_> then on bugfixing
[17:35] <jono> :-)
[18:07] <racarr> Back
[18:10] <ogra_> Front
[18:19] <racarr> :p
[18:34] <davmor2> kgunn: or any one else.  The logs in /home/phablet/.cache/upstart  are they only for the current session?  i.e. if I say pull the battery out to get back to a working system does it start the log afresh?
[18:35] <kgunn> davmor2: good question...i think it can be a mix....for unity i suspect new everytime...for things that maybe dont get autolaunched on boot, i suspect they're old
[18:35] <kgunn> davmor2: i say this because i see diff timestamps when i look
[18:35] <kgunn> just noticed  earlier myself :)
[18:36] <davmor2> kgunn:  that'll possibly be why I can't see anything obvious for this lock up issue that maguro has then
[18:37] <davmor2> kgunn: in order to get back to a working system to pull the logs I need to pull the battery
[18:38] <kgunn> davmor2: weird...so when it locks up, you can't even adb shell in ?
[18:38] <davmor2> kgunn: Nope and macslow confirmed too
[18:39] <davmor2> kgunn: the only thing you can do is pull the battery, even pressing and holding the power button does nothing
[18:39] <davmor2> kgunn: thankfully it doesn't seem to be hitting mako's
[18:41] <davmor2> kgunn: I also tried getting around it by running top in adb shell so the connection was live when it died,  but that just kicks you out of the adb session when it locks up and you can't get back in
[18:43] <davmor2> kgunn: I've been trying to get some reproducible steps, but there don't seem to be any.  You can have lots of apps open, 1 app open, be swiping between scopes, or pulling down the indicator bar
[18:44] <kgunn> davmor2: mmmm....that actually sounds kernel-ish
[18:45] <davmor2> kgunn: only happen on mir, on SF I could run it all day no hangs
[19:00] <tvoss> kdub, which buffers and how many do we hand out to internal clients?
[19:01] <kdub> tvoss, internal and external have the same type of buffers and same count
[19:01] <kdub> so, gpu buffers (not fb's or flagged for hwc usage) and 3
[19:02] <tvoss> kdub, hmmm, why would the shell ever block then?
[19:02] <kdub> tvoss, my branch linked to that slowness bug helps the speed
[19:03] <kdub> i messed up something having to do with snapshotting in that branch though, have to figure out what
[19:03] <tvoss> kdub, mind pinging me the link?
[19:03] <kdub> https://code.launchpad.net/~kdub/mir/android-buffer-syncfence
[19:04] <tvoss> kdub, awesome
[19:07] <kgunn> i swear i think dash decelerates ....
[19:07] <kgunn> render times are pretty quick...then get large when you take your finger off
[19:07] <tvoss> kdub, I like what I see
[19:08] <tvoss> kdub, is the performance improvement tangible?
[19:08] <kgunn> woohoo go kdub
[19:10] <kdub> tvoss, haven't measured
[19:11] <kdub> trying to track down why when you click 'recent apps' you get a white snapshot frame in there in that branch atm
[19:11] <tvoss> kdub, ack
[19:11] <thomi> morning
[19:11] <tvoss> kdub, go ahead
[19:11] <racarr> morning thomi
[19:12] <thomi> o/
[19:12] <tvoss> o/
[19:12] <thomi> hey tvoss, up late?
[19:12] <tvoss> thomi, yup, as usual during this week
[19:13] <thomi> :(
[19:14] <tvoss> thomi, all good :) it's actually quite a lot of fun
[19:14] <thomi> I suppose. I've not been feeling well for the last couple of weeks - mostly I'm always tired. Can hardly keep my eyes open, even after my numerous coffees
[19:15] <tvoss> thomi, oh, sounds like you should go and see a doctor
[19:15] <tvoss> thomi, do you have enough water with your coffee?
[19:15] <thomi> tvoss: I would, but it's not that bad - I'm just tired, no other symptoms
[19:15] <thomi> tvoss: actually, that reminds
[19:15] <thomi> me
[19:15]  * thomi goes to find his water bottle
[19:29] <kgunn> kdub: that's freakin' awesome....
[19:30] <kgunn> just tried your sample "make it go fast"
[19:30] <kdub> thanks :)
[19:30] <kgunn> kdub: you do realize when you do things like this people will just keep expecting miracles
[19:31] <tvoss> kdub, awesome !!!
[19:31] <kgunn> davmor2: you still on ?
[19:32] <davmor2> kgunn: I am
[19:32] <kdub> :D
[19:32] <kgunn> davmor2: wanna try something on maguro ?
[19:32] <davmor2> kgunn: just doing a flash at the minute but I'm happy to try after
[19:32]  * kdub doesnt know if that will fix maguro
[19:32] <tvoss> kdub, no worries, we will try ;)
[19:33] <davmor2> kdub: I'm as happy to break your code as anyone elses I wouldn't want you to fell left out :)
[19:33] <kgunn> kdub: mmm....it should be  indep of hwc1.0 vs 1.1 right ?
[19:34] <tvoss> kgunn, screw it, let's just try
[19:34] <tvoss> :)
[19:34] <kdub> well, i think the omap drivers are using the deprecated native window hooks, which don't do anything with fencing
[19:35] <kgunn> yeah...omap efforts pre-dated the butter activity
[19:42] <kgunn> kdub: so just to confirm...i was taking data just before copying over your fix
[19:42] <kgunn> kdub: and the qml render numbers are back down to where they were weeks ago
[19:42] <tvoss> \o/
[19:43]  * tvoss goes to get alcohol
[19:43] <kgunn> kdub: like...roughly ~27ms todays image....copy your *.so's....i'm getting ~8ms
[19:43] <ricmm> yea
[19:43] <ricmm> renders are back to near-SF numbers
[19:44] <ricmm> swap time went down in half too
[19:44] <ricmm> all we need is screenshots now
[19:44] <kgunn> kdub: a few spikes of 19/20 ms....but not completely abnormal....plus I am certain...unity/qt does something funky to decelerate
[19:44] <kgunn> when you lift a finger or come to a stop
[19:45] <kgunn> kdub: not only that....i'm convinced the quality is actually better than SF...since they had some serious flickering you could easily witness
[19:46] <kgunn> kdub: btw, i do not see the white full screen render...did you already fix that pre-herion sample
[19:47] <ricmm> the white frames are when tapping on a running app
[19:47] <ricmm> the screenshot should slide in from the right
[19:47] <ricmm> however it is an empty frame thats doing it
[19:49] <kgunn> ricmm: btw...i didn't try your powerd deb yet...i was having trouble getting the latest image to exhibit the "can't unblank" upon a unity8 stop/start
[19:49] <kgunn> i wanted to ensure i could easily repro the problem....
[19:50] <kgunn> i did just get one...but had been doing this many times
[19:50] <kgunn> ricmm: do you still want me to try that deb ?
[19:54] <ricmm> what deb?
[19:54] <ricmm> the powerd one?
[19:54] <ricmm> they are already testing it for tests
[19:55] <ricmm> kdub: so I see a difference now with screenshots
[19:55] <kgunn> ricmm: yeah...ok....
[19:55] <ricmm> kdub: less screenshotting issues, before most of the times the surface wouldnt be ready for screenshotting
[19:55] <ricmm> so it would use an old screenshot instead of refreshing
[19:56] <ricmm> kdub: now with this patch the surface is allowing the screenshot
[19:56] <ricmm> which is actually making it lag behind a bit while its mapped to sheet coming in from the right
[19:57] <ricmm> kdub: tvoss kgunn worse comes to worse I prefer this over the choppiness
[19:57] <ricmm> I can live with a couple frames of white
[20:00] <tvoss> ricmm, +1
[20:01] <tvoss> ricmm, kdub http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/92:20131010.2:20131010/4662/
[20:02] <ricmm> not bad
[20:02] <racarr> I am going to work on this...extra characters showing up from real keyboards/autopilot keyboard http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/92:20131010.2:20131010/4662/calendar-app-autopilot/474291/
[20:02] <kdub> yeah, getting better
[20:02] <racarr> should be pretty easy to isolate
[20:02] <racarr> and probably just a problem in qtubuntu or our xkbcommon mapper
[20:03] <ricmm> I've seen it happen in normal apps with OSK
[20:03] <ricmm> as soon as you bring up or focus a text field
[20:03] <ricmm> garbage char will be delivered
[20:03] <ricmm> once I had the filter branch for the hardware keys that didnt happen
[20:04] <racarr> ah I havent seen ti happen with osk I dont believe
[20:11] <racarr> ok. quick lunmch before an afternoon of digging autopilot failures
[20:17] <davmor2> kgunn: it's feels faster initially, however it is also glitchier here. So for example I opened to the camera app and there was lots of flashing that wasn't there before, if you tap on the flash for example.   I'll have a proper go at it after I log off in a bit and I'll double check that I have put files in the right places too
[20:19] <davmor2> I'll let you know tomorrow ;)
[20:19] <davmor2> night all
[20:21] <kgunn> davmor2: cool...
[20:22] <kgunn> davmor2: yeah...mainly curious about the dash app lens full of icons scrolling
[21:02] <racarr> Back
[21:03] <rsalveti> hey, need help with mir specific crash
[21:04] <rsalveti> getting the following after linking to ubuntu_application_api_mirclient
[21:04] <rsalveti> gst-codec-info loads libandroidmedia, which depends on libubuntu_application_api_mirclient, probe for video caps, and then crashes when trying to unload the library
[21:04] <rsalveti> not using any platform-api or mir specific call at this point
[21:04] <rsalveti> http://paste.ubuntu.com/6219717/
[21:04] <rsalveti> the crash
[21:06] <rsalveti> ricmm: racarr: ^
[21:07] <racarr> rsalveti: I am thinking
[21:07] <racarr> rsalveti: So, static deinitialization segfault is almost certainlly
[21:07] <racarr> some sort of linking error
[21:07] <racarr> so the first thought is
[21:08] <racarr> https://code.launchpad.net/~thomas-voss/mir/add-pthread-linker-and-preprocessor-flags-2/+merge/190432
[21:08] <racarr> but I don't know exactly how
[21:08] <racarr> that would produce this
[21:09] <rsalveti> racarr: would that branch help?
[21:09] <rsalveti> tvoss: ^
[21:09] <rsalveti> not sure how would be related
[21:10] <rsalveti> wonder why this wasn't causing any issue before we tried this
[21:10] <tvoss> rsalveti, nope, looks like something different
[21:11] <rsalveti> same code was working fine when linking against ubuntu_application_api
[21:11] <rsalveti> as all it's doing at this point is loading & unloading it
[21:11] <tvoss> rsalveti, my brain is fried tbh :/
[21:11] <rsalveti> seems a common issue around here this week lol
[21:14] <racarr> rsalveti: I dunno...I would ldd things and look for any conflicts but I am not sure...what could show up
[21:19] <rsalveti> racarr: ldd seems sane http://paste.ubuntu.com/6219825/
[21:20] <racarr> rsalveti: Mm
[21:20] <racarr> maybe valgrind or something
[21:20] <racarr> can give hints
[21:20] <racarr> at earlier corruption
[21:21] <racarr> rsalveti: There may be interesting stuff with LD_DEBUG=all (don't know LD_DEBUG well enough to suggest better flags)
[21:21] <racarr> It seems liek its probably either some sort of linking problem or
[21:21] <racarr> some sort of memory corruption
[21:21] <rsalveti> let me check
[21:25] <rsalveti> racarr: not much with valgrind: http://paste.ubuntu.com/6219845/
[21:25] <rsalveti> checking linker
[21:26] <ChickenCutlass> rsalveti: is there any static init going on that might be failing
[21:26] <rsalveti> ChickenCutlass: we're not doing that in this lib directly
[21:26] <rsalveti> at this point we're just linking at it
[21:26] <ChickenCutlass> rsalveti: so linked at compile time with -l
[21:27] <rsalveti> the code that uses platform-api: https://github.com/jhodapp/gst-plugins-bad/blob/master/sys/androidmedia/gstamchybris.c
[21:27] <ricmm> rsalveti: wheres the code that does it
[21:27] <ricmm> ok
[21:27] <rsalveti> and how we're linking to it: https://github.com/jhodapp/gst-plugins-bad/blob/master/sys/androidmedia/Makefile.am
[21:28] <ricmm> and this isnt being used?
[21:28] <ricmm> why do you say its only loading and unloading
[21:28] <rsalveti> ricmm: nops, because gst-codec-info loads the lib, calls a function to get caps and close itself
[21:28] <rsalveti> ricmm: at this point nothing is calling platform-api
[21:29] <rsalveti> ricmm: I know because even when using mir, and calling with the older library, it works just fine
[21:31] <ricmm> do you have a bt ?
[21:31] <rsalveti> http://paste.ubuntu.com/6219870/ the build log
[21:32] <rsalveti> ricmm: bt?
[21:32] <rsalveti> ricmm: http://paste.ubuntu.com/6219717/
[21:35] <ricmm> what the hell
[21:35] <racarr> rsalveti: Can you try the log from running it
[21:35] <racarr> with LD_DEBUG
[21:36] <rsalveti> racarr: uploading, but nothing really useful it seems
[21:36] <rsalveti> 37mb of logs
[21:37] <ChickenCutlass> rsalveti: could this be a missing hybrid hook?
[21:37] <ChickenCutlass> rsalveti: sure looks like it
[21:37] <ChickenCutlass> hybris
[21:37] <ChickenCutlass> but why?
[21:37] <ChickenCutlass> on just loading the lib
[21:38] <racarr> rsalveti: ><
[21:39] <rsalveti> ChickenCutlass: it's not
[21:39] <rsalveti> ChickenCutlass: all gst is doing is calling plugin_init
[21:39] <rsalveti> even if I put a simple return FALSE right after that, it crashes
[21:39] <rsalveti> ChickenCutlass: and works fine with the old platform-api lib
[21:39] <rsalveti> this is a crash at the class destructor it seems
[21:40] <ricmm> yea but at which class
[21:40] <ricmm> if you arent creating anything fro mplatform-api in there
[21:40] <rsalveti> I'm not
[21:40] <ricmm> I dont get why there would be a mention to mir in those logs
[21:42] <ChickenCutlass> ricmm: are there any static init's in there
[21:45] <rsalveti> ricmm: commented out all the platform-api related function calls and it worked now
[21:45] <rsalveti> will get them back one by one
[21:46] <ricmm> thought you said it wasnt being used!
[21:46] <rsalveti> ricmm: it's not
[21:47] <ricmm> then why would commenting them out screw it?
[21:47] <ricmm> err fix it
[21:52] <rsalveti> ricmm: this is what I added back: http://paste.ubuntu.com/6219951/
[21:52] <rsalveti> ricmm: and it's not called!
[21:52] <rsalveti> and it's already enough for the crash
[21:52] <ricmm> ok
[21:54] <ChickenCutlass> rsalveti: so should you not use sizeof (session)
[21:54] <ChickenCutlass> rsalveti: not *session
[21:56] <rsalveti> ChickenCutlass: ricmm: http://paste.ubuntu.com/6219958/
[21:56] <rsalveti> this is already enough for the crash
[21:56] <rsalveti> phablet@ubuntu-phablet:/tmp/test$ gcc test.c -o test -lubuntu_application_api_mirclient
[21:56] <rsalveti> phablet@ubuntu-phablet:/tmp/test$ ./test
[21:56] <rsalveti> Testing
[21:56] <rsalveti> Segmentation fault (core dumped)
[21:56] <ChickenCutlass> rsalveti: ah ok -- so ricmm bug
[21:57] <ricmm> give me some minutes
[21:57] <rsalveti> racarr: ^
[21:58] <sarnold> does argv ever get passed to execve(2)? argv[argc] is expected to be a NULL pointer, and there's no trailing ascii NUL after \n in the first array element
[21:59] <rsalveti> works fine on the desktop
[22:00] <ricmm> that test.c is not crashing for me
[22:00] <ricmm> phablet@ubuntu-phablet:~$ ldd ./test libubuntu_application_api_mirclient.so.1 => /usr/lib/arm-linux-gnueabihf/libubuntu_application_api_mirclient.so.1 (0x401da000)
[22:00] <ricmm> phablet@ubuntu-phablet:~$ ./test
[22:00] <ricmm> Testing
[22:00] <ricmm> phablet@ubuntu-phablet:~$
[22:01] <rsalveti> ricmm: latest image and everything?
[22:01] <ricmm> always
[22:01] <rsalveti> this also crashed with jhodapp|bbiab
[22:01] <ricmm> are you sure your mirclient platform-api and your mir are not somehow out of sync?
[22:02] <rsalveti> ricmm: unless I got a partial update with apt, no
[22:02] <ricmm> im resetting all my versions to saucy for mir and platform-api
[22:02] <ricmm> to make sure we have the same
[22:03] <ricmm> as I'm pretty sure I had trunk mir
[22:04] <rsalveti> ricmm: you did build your own mir, right?
[22:04] <ricmm> yea
[22:04] <ricmm> for the other bug
[22:04] <ricmm> sec still installing
[22:04] <rsalveti> yeah, have latest of everything
[22:04] <rsalveti> just did apt-get update & upgrade
[22:05] <rsalveti> just reproduced with maguro
[22:05] <rsalveti> let me reflash it with latest
[22:05] <rsalveti> might be fixed in trunk then
[22:06] <ricmm> uh yea it breaks
[22:06] <rsalveti> \o/
[22:06] <ricmm> lemme push trunk again
[22:06] <rsalveti> ricmm: trunk of mir or platform-api?
[22:06] <ricmm> mir, I havent rebuilt platform-api
[22:06] <jhodapp> so there's some issue with a version of the mir platform-api then?
[22:07] <rsalveti> jhodapp: mir
[22:07] <jhodapp> ah
[22:07] <rsalveti> jhodapp: http://paste.ubuntu.com/6219958/ is already enough to get the crash
[22:07] <jhodapp> wow
[22:07] <rsalveti> yeah, bad stuff
[22:07] <jhodapp> that's basic
[22:09] <ricmm> yea with my local build it seems to be fine
[22:09] <ricmm> trunk mir
[22:10] <rsalveti> let me build mir from trunk
[22:11] <ricmm> but I dont see anything in trunk that would cause this...
[22:12] <RAOF> mlankhorst: I was poking at nested-gbm yesterday, but mostly finding out that I'd misbuilt mesa in some way and so the egl platform was crashing after _glapi_get_proc_address returned garbage for glFlush
[22:12] <mlankhorst> RAOF: oh did you see my pastebin from earlier?
[22:12] <mlankhorst> I can reproduce the garbage with a normal client if I force a gbm device to be created and use the screen from that
[22:13] <RAOF> mlankhorst: Hm, no.
[22:13] <ricmm> racarr: trunk has nothing special in it, however having built it from my machine with the cross-compile script and deployed to phone makes it not fail
[22:13] <ricmm> racarr: what the hell?
[22:14] <mlankhorst> so just the fact that gbm is used is messing things up
[22:14] <mlankhorst> and i have no idea how
[22:14] <racarr> ricmm: Thiiiinking
[22:14] <mlankhorst> to the best of my knowledge the paths appear to be identical, at least after the gbm proxying :s
[22:16] <RAOF> mlankhorst: Could you repost your pastebin?
[22:16] <mlankhorst> http://paste.debian.net/55230/
[22:17] <rsalveti> ricmm: does it fail if built natively?
[22:17] <rsalveti> well, it's a different toolchain
[22:17] <rsalveti> I'm building mir trunk locally to see
[22:18] <mlankhorst> RAOF: with that patch normal mir clients fail too, that should at least make it easier to debug :P
[22:18] <racarr> Does this just mean we broke client ABI somehow?
[22:18] <racarr> err no that doesn't quite make sense...
[22:18] <racarr> building trunk without rebuilding everything else reportedly fixes it
[22:18] <rsalveti> could be a toolchain/linker issue
[22:18] <racarr> maybe
[22:19] <rsalveti> well, ricmm cross-built it
[22:19] <racarr> something happened in say...
[22:19] <racarr> that introduces ABI breaks
[22:19] <racarr> err...in say hybris
[22:19] <racarr> or something else
[22:19] <racarr> and just mirclient
[22:19] <rsalveti> not a hybris issue
[22:19] <racarr> needed to be rebuilt against it
[22:19] <racarr> but wasn't
[22:19] <racarr> *shrug* it could be, if memory is getting stomped on in static initialization
[22:20] <rsalveti> rebuilding trunk locally ti see
[22:20] <Saviq> hey guys, here's another nice one... https://bugs.launchpad.net/ubuntu/+source/maliit-framework/+bug/1238296
[22:20] <ricmm> Saviq: thanks
[22:21] <Saviq> ricmm, /me got retracing powers now ;D
[22:21] <rsalveti> maybe similar issue?
[22:22] <rsalveti> no, looks different
[22:22] <ricmm> different trace
[22:25] <ricmm> racarr: rebuilt platform-api against my local build and it still works
[22:26] <ricmm> is it possible that something went wrong in the recent archive build?
[22:29] <rsalveti> ricmm: well, if rebuilding the current version fixes it, then it could
[22:29] <rsalveti> still waiting trunk here
[22:36] <racarr> I think if it does work, (rsalvetis build)
[22:36] <racarr> then probably Mir and <SOME PACKAGE> were buitl against different versions of <SOME PACKAGE>
[22:36] <racarr> err
[22:36] <racarr> <SOME OTHER PACKAGE> lol
[22:39] <ricmm> rsalveti: get that system76 already
[22:39] <ricmm> geez
[22:39] <rsalveti> ricmm: dude, building locally
[22:39] <rsalveti> == mako
[22:39] <ricmm> wow
[22:39] <ricmm> see you tomorrow then
[22:40] <racarr> rsalveti: Build from
[22:40] <racarr>  build/src/
[22:40] <racarr> and make install from there
[22:40] <racarr> skip tests
[22:40] <racarr> save lifetimes
[22:40] <rsalveti> ricmm: I need to confirm if this is not a toolchain issue
[22:40] <rsalveti> just build, will test now
[22:41] <rsalveti> ricmm: racarr: crashed still
[22:41] <rsalveti> just built and installed trunk
[22:41] <ricmm> well that sucks
[22:41] <ricmm> can you uh
[22:41] <ricmm> one sec
[22:41] <ricmm> merge lp:~kdub/mir/android-buffer-syncfence
[22:41] <ricmm> I know it makes no sense, but just try
[22:41] <ricmm> thats the only other change in my branch
[22:42] <rsalveti> sure
[22:43] <racarr> hmmm
[22:43] <rsalveti> shit, huge merge
[22:43] <ricmm> its pretty large yea but it shouldnt touch anything related to this
[22:45] <rsalveti> ricmm: replacing libmirclient.so is enough, right?
[22:45] <ricmm> should be as its talking about the connection
[22:45] <ricmm> but you never know with this beast
[22:45] <ricmm> replace it all
[22:45] <ricmm> as im doing so as well
[22:46] <rsalveti> yes sr
[22:46] <ricmm> im building a clean trunk, cross built
[22:47] <ricmm> I'll put the binaries up somewhere for you
[22:47] <ricmm> you put your locally built ones somewhere
[22:48] <rsalveti> ricmm: booom, no
[22:48] <ricmm> still failing?
[22:48] <ricmm> try http://people.canonical.com/~ricmm/mir-fixed/
[22:49] <rsalveti> ricmm: where is the mir socket now?
[22:49] <rsalveti> trying to see if unity8 is still working
[22:49] <ricmm> I'm not sure, alan_g moved it
[22:49] <rsalveti>  /run/user/32011/mir_socket
[22:49] <ricmm> right xdg runtime
[22:50] <rsalveti> ricmm: this shit is fast now
[22:50] <ricmm> super pro
[22:50] <rsalveti> ricmm: so yeah, using the right ones
[22:50] <rsalveti> let me try with yours
[22:53] <rsalveti> people.c is super slow for me today
[22:54] <rsalveti> I believe this issue might be happening with unit8 as well
[22:54] <rsalveti> it's crashing during shutdown
[22:55] <ricmm> sounds terribad
[22:55] <rsalveti> ricmm: no crash with yours
[22:55] <rsalveti> smells like toolchain
[22:55] <ricmm> well thats odd
[22:55] <rsalveti> let me open a bug
[22:59] <rsalveti> ricmm: bug 1238312
[22:59] <rsalveti> ricmm: please add that it works with your lib, when cross-built
[23:01] <racarr> kdub: sync fence is fast :D
[23:01] <ricmm> done
[23:01] <racarr> tested it out
[23:04] <rsalveti> ricmm: how can I cross build mir?
[23:04] <ricmm> rsalveti: thres a script right in trunk
[23:04] <rsalveti> ricmm: want to cross build the same version used by the image
[23:04] <ricmm> ./cross-build-...
[23:04] <ricmm> something like that
[23:04] <rsalveti> great
[23:05] <kdub> racarr, yay
[23:09] <ricmm>  * Authored by: Thomas Guest<EMAIL_ADDRESS>[23:09] <ricmm> tvoss: is that you? lol
[23:10] <racarr> no
[23:10] <rsalveti> ricmm: creating phablet-compatible armhf partial chroot for mir compiles in directory /tmp/mir/mir-0.0.14+13.10.20131010/partial-armhf-chroot
[23:10] <rsalveti> E: No packages found
[23:11] <rsalveti> might be missing something still
[23:11] <ricmm> oh yea
[23:11] <ricmm> racarr: do you have the cross compile instructions list at hand?
[23:11] <ricmm> nvm
[23:11] <ricmm> rsalveti: http://unity.ubuntu.com/mir/building_source_for_android.html
[23:11] <ricmm> you need to add armhf sources to your apt
[23:12] <ricmm> its bad
[23:12] <rsalveti> haha, this is not for android
[23:12] <rsalveti> that's fine
[23:12] <ricmm> yea I dont know why its called that
[23:12] <rsalveti> this if for ubuntu dudes
[23:14] <racarr> at one point
[23:14] <racarr> it literally
[23:14] <racarr> was for android
[23:14] <racarr> in mirs case :p
[23:14] <rsalveti> right
[23:14] <rsalveti> not anymore :P
[23:18] <slangasek> rsalveti: :P
[23:19] <slangasek> rsalveti: can you reproduce this by linking directly to libmirclient?
[23:19] <rsalveti> one more :-)
[23:19] <rsalveti> trying, was just cross-building the same version to confirm
[23:33] <ricmm> rsalveti: soooo
[23:33] <ricmm> racarr:
[23:33] <ricmm> http://paste.ubuntu.com/6220225/
[23:33] <ricmm> thats how it looks when it dies
[23:33] <ricmm> http://paste.ubuntu.com/6220219/
[23:34] <ricmm> thats how it looks when it works
[23:34] <ricmm> the later hits the destructor of the hash table
[23:35] <ricmm> makes me believe that when it fails the hash table has bogus data and it attempts to clear the set
[23:35] <ricmm> which fails, probably guesses a wrong size
[23:36] <rsalveti> ricmm: slangasek: works fine when linking against libmirclient directly
[23:36] <rsalveti> but I know the platform-api one links to a bunch of mir related libs
[23:36] <ricmm> are you actually pointing to a function somewhere?
[23:36] <ricmm> if so, what mirclient func
[23:37] <rsalveti> ricmm: was trying mir_connection_is_valid, but checking if it's really part of that lib
[23:38] <rsalveti> src/client/mir_client_library.cpp:int mir_connection_is_valid(MirConnection * connection)
[23:38] <rsalveti> yup
[23:40] <rsalveti> ricmm: why is it trying to clear the hash table?
[23:40] <rsalveti> at that point, is it valid at all?
[23:40] <ricmm> it shouldnt be
[23:40] <ricmm> the compiler is generating different paths tho
[23:41] <ricmm> one is perhaps initializing it to null while the other is leaving it uninitialized, or something
[23:41] <ricmm> just guesses here
[23:41] <rsalveti> right
[23:43] <rsalveti> ricmm: slangasek: working with the cross-built based libs, same src version
[23:43] <ricmm> yea
[23:43] <ricmm> can you check cxflags?
[23:43] <ricmm> cxx
[23:44] <ricmm> perhaps there are some things different to the default way of building debs
[23:44] <rsalveti> probably
[23:44] <ricmm> optimization or other specific flags
[23:45] <rsalveti> ricmm: not sure because the cmake files are shared
[23:51] <rsalveti> ricmm: wonder why it seems to be fine If I link against it directly
[23:52] <rsalveti> maybe a different lib
[23:52] <rsalveti> linking against mir brings the entire universe


[18:59] <p7f> hi: is there a way to add a trash icon to budgie panel?
[20:01] <fossfreedom_> p7f, not currently - but shouldnt really be hard to create a budgie-applet to-do that.
[20:03] <p7f> fossfreedom_: thanks! and do you know if in future budgie versions print screen key will be functional?
[20:04] <fossfreedom_> p7f, too early to say about budgie v11 - there are workarounds you can apply to get print screen key to work though
[20:06] <fossfreedom> p7f, https://github.com/budgie-desktop/budgie-desktop/issues/305
[20:07] <p7f> fossfreedom: thanks!
[20:19] <p7f> i just deactivated all screenshot key bindings and created new ones with gnome-screenshot commands..


[10:22] <JonathanD> Morning.
[10:28] <lazypower> Morning
[10:29] <JonathanD> hey lazypower
[10:29] <lazypower> Whats  shakin
[10:29] <JonathanD> nothing yet.
[10:30] <lazypower> I wish I could say the same. I've been up most of the night. Finding it hard to sleep. I start my new job today
[10:31] <rmg51> Morning
[10:32] <lazypower> Morning rmg51
[10:32] <rmg51> o/
[10:33] <JonathanD> hi rmg51
[10:33] <rmg51> o/
[10:33] <JonathanD> lazypower: cool on job.
[10:34] <lazypower> Thanks. I'm pretty stoked as you can tell.
[11:53] <pvl1> lazypower what job
[11:53] <lazypower> pvl1, i joined the Canonical Juju team
[11:54] <lazypower> Life Achievement unlocked
[11:54] <pvl1> what is that
[11:54] <pvl1> juju team
[11:54] <lazypower> The most amazing kind of deployment orchestration.
[11:54] <lazypower> jujucharms.com
[11:55] <lazypower> and a solid promo video - http://www.youtube.com/watch?v=1yoIdgdqzLk
[11:55] <pvl1> that's so awesome, congrats dude. you must be excited as a kid in a candy store
[11:55] <pvl1> kinda jealous not gonna lie
[11:55] <lazypower> You know it. I've been fanboy'ing like crazy ever since I got the call
[11:57] <pvl1> they found you or did u apply
[11:57] <lazypower> A bit of both
[11:58] <lazypower> I met Marco Ceppi at a stack overflow meetup in DC 3 years ago, we've been best of friends ever since, he encouraged me to apply
[11:58] <lazypower> so, its been a 2 way street
[11:58] <pvl1> hm, social networking
[11:59] <pvl1> so where is the office
[11:59] <lazypower> I think my big plus is that I have some chef experience and I was working on a competing project in my spare time, so i've got a level of working knowledge they are looking for.
[11:59] <pvl1> and what will you be doing
[11:59] <lazypower> Home base for canonical is in the UK, there's a maryland satellite office for the eastern seaboard.
[12:00] <lazypower> I'll be working on the juju tools, charms, supporting charm authors, providing community support, this is all first hand witness to what the team does now and speculation. I won't know my core duties until today.
[12:00] <pvl1> so u have to drive to maryland
[12:00] <pvl1> or u work from home
[12:02] <lazypower> Working from home
[12:03] <lazypower> I say working on a competing product - sounds like i was writing deployment orchestration. I was looking into chef's orchestration tools that are starting to mature into a beta state is a more accurate description.
[12:03] <lazypower> pvl1, they have open positions
[12:04] <lazypower> http://www.canonical.com/careers/all-vacancies
[12:07] <pvl1> psssht I wish. no official experience. all self taigjt
[12:08] <pvl1> taught
[12:12] <lazypower> Same here. I've been working for a marketing firm the last 3 years
[12:12] <lazypower> not exactly where I thought I wound find myself buried ins ervers up to my neck that required configuration management.
[12:13] <lazypower> But it would be a crime for me not to point out they offer employment based on merit, not based on years experience or title.
[12:15] <pvl1> merrit?
[12:33] <waltman> lazypower: Awesome! When can we put you on the schedule to talk about juju at plug and/or fosscon?
[12:33] <waltman> :)
[12:41] <lazypower> waltman, anytime you like. I've been hacking around on it since the end of November
[12:44] <lazypower> Wait we have a fosscon here in PA?
[12:45] <lazypower> What have I been doing with my life?
[12:51] <pvl1> when is next fosscon
[12:53] <waltman> I don't know that they've announced dates yet, but it's traditionally held on the hottest Saturday in August.
[12:54] <pvl1> oh kool I can make that
[12:57] <JonathanD> pvl1: aug 9
[12:57] <JonathanD> or is it 8
[12:57] <JonathanD> it's not announced yet though.
[12:57] <JonathanD> Soon!
[12:58] <waltman> it will be whichever date is supposed to be hottest in the (very) extended forecast :)
[12:58] <JonathanD> yes.
[12:58] <JonathanD> what waltman said
[12:58] <JonathanD> oh it looks like I have a venue contract
[12:58] <JonathanD> maybe I can announce now.
[12:58] <JonathanD> venue + keynote = announcement
[12:59] <JonathanD> by the way, our keynote is looking for a place to bunk, if anyone would like to offer.
[13:00] <waltman> does he have rules about also bunking his pet parrot?
[13:00] <JonathanD> no
[13:00] <JonathanD> Oh, you don't know the keynote yet :)
[13:01] <waltman> I do not.
[13:01] <JonathanD> John Hall.
[13:01] <JonathanD> to my knowledge, he does not have a parrot.
[13:01] <waltman> Didn't he used to work with Oates?
[13:02] <pvl1> idk who that is. are we supposed to show up witjh our irc nickd or actual names
[13:02] <JonathanD> pvl1: it's not uncommon to put your irc nick along with your name on your nametag
[13:02] <waltman> I confess I don't have the slightest idea who John Hall is.
[13:02] <waltman> oh, Mad Dog?
[13:03] <JonathanD> Drexel grad, also known as yes that.
[13:03] <JonathanD> he's going to give us a past present and future history of open source.
[13:03] <JonathanD> with some philly tie ins, I think.
[13:03] <pvl1> I like
[13:04]  * waltman notes that his first name is "Jon", not "John"
[13:04] <pvl1> I wish I had a linux job
[13:04] <JonathanD> waltman: ah, you'd think I'd get that right.
[13:04] <waltman> indeed
[13:04] <JonathanD> Of all people
[13:04] <JonathanD> I think I don't because everyone is John.
[13:04] <waltman> JonathanD: also juju is going to be talking about juju at plug!
[13:04] <waltman> er, lazypower
[13:05] <waltman> breakfast &
[13:05] <JonathanD> what is juju?
[13:05] <JonathanD> and which plug?
[13:05] <JonathanD> waltman: are you coming tomorrow?
[13:05] <JonathanD> I hear someone scraping ice :(
[13:05] <JonathanD> that means I'll have to as well :(
[13:05] <waltman> I hope to, but I'll be late. I'll be in my boss's class until 6:30.
[13:06] <JonathanD> I should make sure I'm going I suppose.
[13:09] <lazypower> waltman, Who is juju? Do you have a team member speaking about it?
[13:13] <lazypower> JonathanD, Juju is the best thing to land since sliced bread. http://www.youtube.com/watch?v=1yoIdgdqzLk
[13:15] <teddy-dbear> Morning peoples, dogs, turkeys and everything else
[14:47] <JonathanD> I think my graphical issues are related to the dual GPU setup on this machine.
[14:59] <InHisName1> any Pidgin users here ?     Want at least 36 - 48, if I can change it.
[15:03] <lazypower> Since there is no configuration option, its probably hard coded in the plugin.
[15:14] <InHisName1> lazypower:  meaning it's not changeable ?
[15:16] <lazypower> Doesn't appear to be, no
[15:17] <lazypower> This is why i use a bouncer like ZNC with a history plugin. Regardless of my connection statistics I get replays from the rooms i'm in with a lifetime retention. Not an ideal solution for your question but a viable alternative.
[15:18] <ChinnoDog> I tried ZNC for awhile but decided it was too complicated for everyday use.
[15:18] <ChinnoDog> I had it figured out but it was too much work.
[15:18] <lazypower> There's a few alternatives like smuxi, and rygel
[15:19] <lazypower> sorry, not rygel - quassel
[15:20] <lazypower> the big draw to quassel is the baked in bouncer, and an android client.
[15:21] <ChinnoDog> I use weechat. There is also an Android client for it and I don't have to deal with BNC commands.
[15:26] <JonathanD> I'm very close to just reinstalling :/
[15:34] <lazypower> JonathanD, still unable to figure out the gfx issues?
[15:42] <JonathanD> lazypower: yes, I made it much worse :P
[15:43] <lazypower> Oh man, i love that feeling </sarcasm>
[15:44] <JonathanD> Now I boot to a blinking black curosor and cant even ctrl alt F1
[15:45] <lazypower> boot into single user mode
[15:45] <JonathanD> yeah
[15:45] <JonathanD> still not sure how to fix, once I do
[15:45] <lazypower> remove your X11 config and re-run nvidia-xconfig
[15:45] <lazypower> pray it gens a good configuration
[15:48] <pvl1> weechat
[15:49] <pvl1> I'm pretty good with x11 n stuffs
[15:49] <pvl1> what's the issue JonathanD
[16:04] <waltman> pvl1: you should go to plug north tomorrow night and fix JonathanD's config before the main talk.
[16:10] <pvl1> what time
[16:11] <pvl1> and north is in montco right
[16:11] <waltman> 7, but you'll want to get there earlier in case you run into any problems with JonathanD's machine :)
[16:12] <waltman> http://www.phillylinux.org/locations/coredial.html
[16:20] <pvl1> isn't bluebell south west
[16:24] <waltman> It's southwest of Doylestown.
[16:26] <pvl1> I might be able to get a ride
[16:29] <waltman> It's near the Plymouth Meeting mall, if you know where that is.
[16:29] <JonathanD> yay I have a gui!
[16:29] <waltman> pvl1: never mind, he got it working :(
[16:29] <JonathanD> not really
[16:29] <JonathanD> I'm using the intel card instead of the nvidia
[16:29] <waltman> :(
[16:29] <JonathanD> so I can function.
[16:29] <waltman> what kind of computer?
[16:30] <JonathanD> also I learned how to fix it and get into a recoverable state if I break it again.
[16:30] <pvl1> JonathanD I've had to do the same several times
[16:30] <JonathanD> waltman: thinkpad with dual cards, intel and nvidia
[16:30] <pvl1> pretty pissed neither ati nor nvidia want to support waylanf
[16:31] <JonathanD> the dual card thing has never worked well on ubuntu
[16:31] <waltman> JonathanD: I thought you were all about macbooks these days!
[16:31] <JonathanD> waltman: I use my macbook every day.
[16:31] <JonathanD> It shows me pretty graphs while I work on my thinkpad
[16:37] <KyleYankan> a dashing console?
[16:38] <ChinnoDog> KyleYankan: What is the "radar ping" noise I keep hearing?
[16:38] <JonathanD> KyleYankan: lol no
[16:38] <JonathanD> zenoss stuff.
[16:39] <KyleYankan> ChinnoDog: On a repeater? not sure. Most repeaters do a pingy-type of nosie when someone transmits to mark the end of it. Like a roger beep.
[16:39] <ChinnoDog> But that is all I hear. Speaker comes on, there is a ping noise, then it goes off. No voice.
[16:39] <JonathanD> I need a utility to read cad files.
[16:40] <KyleYankan> Might be someone kerchunking.
[16:40] <KyleYankan> Kerchunking is when someone keys up a radio, and doesn't say anything.
[16:40] <ChinnoDog> Now I hear a transmission with lots of pings and some strange noise.
[16:41] <JonathanD> ariens
[16:41] <ChinnoDog> Now there is much garbage on the channel
[16:44] <ChinnoDog> I turned up squelch setting. Seems better now.
[16:48] <MutantTurkey> pvl1: give it time
[16:48] <MutantTurkey> wayland is still too new to have it worth investing in
[16:48] <MutantTurkey> no corporate partners will be using it for years
[16:48] <MutantTurkey> I don't even like wayland. Why couldn't they have just revised the x11 protocol? X12?
[16:49] <KyleYankan> I'm looking forward to the wayland yutani merger.
[16:50] <KyleYankan> Weyland-Yutani: Building a better working world.
[17:09] <ChinnoDog> KyleYankan: jedijf: I am in the FCC database. I am KK4WIZ!
[17:10] <KyleYankan> Nice. Sweet call.
[17:10] <ChinnoDog> It is. I lucked out.
[17:11] <lazypower> waltman: is your guest speaker Marco Ceppi?
[17:11] <waltman> *my*?
[17:12] <lazypower> *the*
[17:12] <waltman> for...?
[17:12] <lazypower> Well this morning it was asked if special lodging for the parrot would be required
[17:12] <waltman> no, I was joking that it might be rms.
[17:13] <lazypower> Oh
[17:13] <lazypower> Yeah... *that* guy...
[17:13]  * lazypower chuckles softly to himself
[17:13] <waltman> maddog seems like he'd be a rather more pleasant house guest.
[17:13] <waltman> in fact, he's friends with rms and has some very funny stories about him :)
[17:15] <waltman> maddog as the persona of a kindly old wizard from the elder times.
[17:15] <waltman> s/as/has/
[17:37] <JonathanD> My communications thus far have been pleasant
[17:39] <KyleYankan> JonathanD: if we house maddog, will I be required to shield the light of anur?
[17:41] <JonathanD> yes.
[17:43] <waltman> Is that what you're calling the bear light these days?
[17:43] <JonathanD> yes.
[17:44] <KyleYankan> .wiki Secret Fire
[17:44] <KyleYankan> Queenbee? :-( i forgot
[17:45] <waltman> the interesting thing about maddog is that he's a geek, but he also was a VP at DEC for a number of years so he has people skills too.
[17:45] <JonathanD> I'm waiting for waltman to offer his living room...
[17:45] <JonathanD> :P
[17:45] <JonathanD> venue secured with all our requirements, I have a contact, we have the deposit, all ahead full
[17:46] <waltman> w00t
[17:46] <JonathanD> *contract
[17:47] <KyleYankan> Oh... We're gonna do fosscon again?  Ok....
[17:47] <KyleYankan> :-P
[17:47] <JonathanD> lemons
[18:05] <KyleYankan> JonathanD: make me a shirt that says "Life"
[18:05] <KyleYankan> and I'll hand out lemons at Fosscon
[18:05] <JonathanD> Ok.
[18:07] <ChinnoDog> haha
[21:13] <JonathanD> So I have dual monitor (on intel) but compiz doesn't work.


[05:13] -queuebot:#ubuntu-release- New binary: ayatana-ido [ppc64el] (bionic-proposed/universe) [0.4.2-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: graphite2 [ppc64el] (bionic-proposed/main) [1.3.10-8] (core)
[05:13] -queuebot:#ubuntu-release- New binary: pikopixel.app [ppc64el] (bionic-proposed/none) [1.0-b8-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: cloudpickle [amd64] (bionic-proposed/universe) [0.5.2-1] (no packageset)
[05:13] -queuebot:#ubuntu-release- New binary: pikopixel.app [amd64] (bionic-proposed/none) [1.0-b8-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: ayatana-ido [amd64] (bionic-proposed/universe) [0.4.2-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: ayatana-ido [s390x] (bionic-proposed/universe) [0.4.2-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: graphite2 [s390x] (bionic-proposed/main) [1.3.10-8] (core)
[05:14] -queuebot:#ubuntu-release- New binary: ayatana-ido [i386] (bionic-proposed/universe) [0.4.2-1] (no packageset)
[05:14] -queuebot:#ubuntu-release- New binary: graphite2 [i386] (bionic-proposed/main) [1.3.10-8] (core)
[05:15] -queuebot:#ubuntu-release- New binary: ayatana-ido [arm64] (bionic-proposed/universe) [0.4.2-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: pikopixel.app [s390x] (bionic-proposed/none) [1.0-b8-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: pikopixel.app [armhf] (bionic-proposed/none) [1.0-b8-1] (no packageset)
[05:16] -queuebot:#ubuntu-release- New binary: pikopixel.app [arm64] (bionic-proposed/none) [1.0-b8-1] (no packageset)
[05:16] -queuebot:#ubuntu-release- New binary: pikopixel.app [i386] (bionic-proposed/none) [1.0-b8-1] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: ayatana-ido [armhf] (bionic-proposed/universe) [0.4.2-1] (no packageset)
[05:18] -queuebot:#ubuntu-release- New binary: graphite2 [arm64] (bionic-proposed/main) [1.3.10-8] (core)
[05:19] -queuebot:#ubuntu-release- New binary: graphite2 [armhf] (bionic-proposed/main) [1.3.10-8] (core)
[05:21] -queuebot:#ubuntu-release- New binary: graphite2 [amd64] (bionic-proposed/main) [1.3.10-8] (core)
[08:04] -queuebot:#ubuntu-release- New: accepted graphite2 [amd64] (bionic-proposed) [1.3.10-8]
[08:04] -queuebot:#ubuntu-release- New: accepted graphite2 [armhf] (bionic-proposed) [1.3.10-8]
[08:04] -queuebot:#ubuntu-release- New: accepted graphite2 [ppc64el] (bionic-proposed) [1.3.10-8]
[08:04] -queuebot:#ubuntu-release- New: accepted graphite2 [arm64] (bionic-proposed) [1.3.10-8]
[08:04] -queuebot:#ubuntu-release- New: accepted graphite2 [s390x] (bionic-proposed) [1.3.10-8]
[08:04] -queuebot:#ubuntu-release- New: accepted graphite2 [i386] (bionic-proposed) [1.3.10-8]
[08:11] -queuebot:#ubuntu-release- New: accepted pikopixel.app [amd64] (bionic-proposed) [1.0-b8-1]
[08:11] -queuebot:#ubuntu-release- New: accepted pikopixel.app [armhf] (bionic-proposed) [1.0-b8-1]
[08:11] -queuebot:#ubuntu-release- New: accepted pikopixel.app [ppc64el] (bionic-proposed) [1.0-b8-1]
[08:11] -queuebot:#ubuntu-release- New: accepted pikopixel.app [arm64] (bionic-proposed) [1.0-b8-1]
[08:11] -queuebot:#ubuntu-release- New: accepted pikopixel.app [s390x] (bionic-proposed) [1.0-b8-1]
[08:11] -queuebot:#ubuntu-release- New: accepted pikopixel.app [i386] (bionic-proposed) [1.0-b8-1]
[08:15] -queuebot:#ubuntu-release- New: accepted ayatana-ido [amd64] (bionic-proposed) [0.4.2-1]
[08:15] -queuebot:#ubuntu-release- New: accepted ayatana-ido [armhf] (bionic-proposed) [0.4.2-1]
[08:15] -queuebot:#ubuntu-release- New: accepted ayatana-ido [ppc64el] (bionic-proposed) [0.4.2-1]
[08:15] -queuebot:#ubuntu-release- New: accepted cloudpickle [amd64] (bionic-proposed) [0.5.2-1]
[08:15] -queuebot:#ubuntu-release- New: accepted range-v3 [amd64] (bionic-proposed) [0.3.0-1]
[08:15] -queuebot:#ubuntu-release- New: accepted ayatana-ido [arm64] (bionic-proposed) [0.4.2-1]
[08:15] -queuebot:#ubuntu-release- New: accepted ayatana-ido [s390x] (bionic-proposed) [0.4.2-1]
[08:15] -queuebot:#ubuntu-release- New: accepted ayatana-ido [i386] (bionic-proposed) [0.4.2-1]
[08:15] -queuebot:#ubuntu-release- New: accepted node-debug [amd64] (bionic-proposed) [3.1.0-1]
[09:11] -queuebot:#ubuntu-release- New sync: icu-le-hb (bionic-proposed/primary) [1.0.3+git161113-4]
[09:12] -queuebot:#ubuntu-release- New: accepted icu-le-hb [sync] (bionic-proposed) [1.0.3+git161113-4]
[09:13] -queuebot:#ubuntu-release- New binary: icu-le-hb [s390x] (bionic-proposed/none) [1.0.3+git161113-4] (no packageset)
[09:14] -queuebot:#ubuntu-release- New binary: icu-le-hb [amd64] (bionic-proposed/none) [1.0.3+git161113-4] (no packageset)
[09:14] -queuebot:#ubuntu-release- New binary: icu-le-hb [ppc64el] (bionic-proposed/none) [1.0.3+git161113-4] (no packageset)
[09:14] -queuebot:#ubuntu-release- New binary: icu-le-hb [i386] (bionic-proposed/none) [1.0.3+git161113-4] (no packageset)
[09:15] -queuebot:#ubuntu-release- New binary: icu-le-hb [arm64] (bionic-proposed/none) [1.0.3+git161113-4] (no packageset)
[09:16] -queuebot:#ubuntu-release- New binary: icu-le-hb [armhf] (bionic-proposed/none) [1.0.3+git161113-4] (no packageset)
[09:17] -queuebot:#ubuntu-release- New: accepted icu-le-hb [amd64] (bionic-proposed) [1.0.3+git161113-4]
[09:17] -queuebot:#ubuntu-release- New: accepted icu-le-hb [armhf] (bionic-proposed) [1.0.3+git161113-4]
[09:17] -queuebot:#ubuntu-release- New: accepted icu-le-hb [ppc64el] (bionic-proposed) [1.0.3+git161113-4]
[09:17] -queuebot:#ubuntu-release- New: accepted icu-le-hb [arm64] (bionic-proposed) [1.0.3+git161113-4]
[09:17] -queuebot:#ubuntu-release- New: accepted icu-le-hb [s390x] (bionic-proposed) [1.0.3+git161113-4]
[09:17] -queuebot:#ubuntu-release- New: accepted icu-le-hb [i386] (bionic-proposed) [1.0.3+git161113-4]
[17:10] -queuebot:#ubuntu-release- New binary: golang-github-mwitkow-go-conntrack [amd64] (bionic-proposed/universe) [0.0~git20161129.cc309e4-1] (no packageset)
[22:46] <doko> Laney, slangasek: looks like the arm64 can't keep up, the backlog isn't cleared during the weekend
[22:47] <doko> s/amr64/arm64 autopkg test machines/
[23:12] -queuebot:#ubuntu-release- New binary: postorius [amd64] (bionic-proposed/none) [1.1.0-1] (no packageset)
[23:13] -queuebot:#ubuntu-release- New: accepted golang-github-mwitkow-go-conntrack [amd64] (bionic-proposed) [0.0~git20161129.cc309e4-1]
[23:14] -queuebot:#ubuntu-release- New: accepted postorius [amd64] (bionic-proposed) [1.1.0-1]
[23:33] -queuebot:#ubuntu-release- New binary: qgis [ppc64el] (bionic-proposed/universe) [2.14.21+dfsg-1] (no packageset)
[23:37] -queuebot:#ubuntu-release- New binary: qgis [s390x] (bionic-proposed/universe) [2.14.21+dfsg-1] (no packageset)
[23:51] -queuebot:#ubuntu-release- New binary: qgis [i386] (bionic-proposed/universe) [2.14.21+dfsg-1] (no packageset)
[23:51] -queuebot:#ubuntu-release- New binary: qgis [amd64] (bionic-proposed/universe) [2.14.21+dfsg-1] (no packageset)


[13:23] <leitao> rtg, Hello. Regarding to #1546159, the patch is having a hard time to get upstreamed.
[13:23] <leitao> Is it possible to keep it until we have a final solution?
[13:24] <apw> bug #1546159
[13:25] <apw> rtg, ^
[13:25] <rtg> leitao, I assume you are comfortable that it has been tested and works well ? I likely need to get kamal to look it over as well.
[15:12] <rtg> jsalisbury, I don't think bug #1576222 is a kernel problem
[15:19] <apw> rtg, right ... that isn't a kernel issue, that is a general distro issue
[15:20] <apw> rtg, move it to the ubuntu project with no package i recon
[15:20] <ogra_> until tzdata becomes a module ... just wait :P
[15:20] <apw> then someone else can figure out where it goes :)
[15:20] <rtg> apw, yeah, Jeff admitted as much - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1576222/comments/4
[17:04] <jsalisbury> rtg, ack.  Still trying to get used to irc notifications in weechat
[17:05] <rtg> jsalisbury, it doesn't seem like you have any notifications :)
[17:05] <jsalisbury> rtg, crap, did  I miss a message from you earlier?
[17:06] <rtg> jsalisbury, just the one about a bug not being a kernel problem.
[17:07] <jsalisbury> rtg, ack, I just saw that.  I'll try to get it figured out.
[17:08] <apw> jsalisbury, the highlight thing is pretty odd looking at first
[17:08] <apw> jsalisbury, the keybinding alt-A takes you to a buffer that is asking for attention
[17:09] <apw> jsalisbury, and alt-P in that buffer will take you to a highlight in your name
[17:09] <jsalisbury> apw, yeah, I'm used to it being a big red backgrounded line.
[17:09] <apw> jsalisbury, does it make your nick yellow ?
[17:09] <apw> mine does that
[17:09] <apw> i mean my nick yellow when i highlight you ... jsalisbury
[17:09] <jsalisbury> No.  It makes your's yellow with a purple background.
[17:09] <apw> ok thats what mine does
[17:10] <jsalisbury> apw, I just started using it today, so getting used to it still.
[17:10] <apw> and do you get the gobbledgook next to the buffer name to tell you which buffers want you ?
[17:10] <apw> alt-A shows the buffers in that order
[17:10] <apw> also you can change the criteria on a per-channel basis
[17:10] <apw> so i ahve like this one and the stable one appear on the active list every time there is any message
[17:11] <jsalisbury> apw, hmm not when I'm on the current buffer that needs my attention.  THe current buffer is highlighted red
[17:12] <apw> right if you are on the buffer its not going to add it to your list
[17:12] <apw> because it is showing
[17:12] <jsalisbury> apw, gotcha.
[17:12] <apw> then you cna hit alt-P to see it
[17:12] <jsalisbury> apw, there are so many cool options to play with :-)
[17:13] <apw> jsalisbury, so like in your weechat buffers (normally /b 1) you can use: /set weechat.notify.irc.freenode.#ubuntu-kernel message
[17:13] <apw> to tell it that a channel is internesting when anything is said, rather than just your name
[17:15] <jsalisbury> apw, ahh, nice
[17:15] <jsalisbury> apw, I really like the split screen options too
[17:15] <apw> yeha they are good, and alt-X spins you round them
[22:10] <DalekSec> apw: Did you happen to see my ping about postinst/preinst scripts?
[22:12] <apw> DalekSec: no, missed it i assume ...
[22:15] <DalekSec> apw: I had noticed Debian updated their scripts a bit, rely more on triggers and seems to be some nice fixes there, fwiw.
[22:16] <apw> ahhh, that is on my list somewhere to investigate
[22:16] <DalekSec> \o/
[22:17] <DalekSec> I had also pinged you about a newer cryptsetup, basically merged it and updated to latest upstream if you wanted to review (better support for newer kernals, iirc) but let it go because too close to FF.
[22:52] <esanchma> I updated a Sony Vaio laptop from willy to xenial and now suspend hangs. resume-trace points to memory48. It seems to be a known regression for 4.4.0-21  (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1574125) so, does the 4.4.0-22 kernel in xenial-proposed solve that?
[22:57] <esanchma> 4.5.2 is known to work and it affects a ton of people.


[03:41] <shank_> Hi all
[03:41] <shank_> Im trying to develop a game with SDL
[03:41] <shank_> on ubuntu
[03:41] <shank_> is SDL the right lib to use for this?
[07:00] <dholbach> good morning
[07:21] <davidcalle> Good morning all
[11:38] <nerochiaro> oSoMoN: quick question: why is there a need to check if actualUrl.toString() when dealing with AddressBar.internal.simplifyUrl ?
[11:47] <oSoMoN> nerochiaro, where exactly? this is done in two places, which one do you refer to?
[11:48] <nerochiaro> AddressBar.qml in onActiveFocusChanged (around line 325 in my branch)
[11:49] <nerochiaro> oSoMoN: ^ the reason I ask is because I need to refactor the code there and I am not sure I understand the intent
[11:50] <nerochiaro> oSoMoN: my current understandind is that we want to simplify the text only when the addressBar has active focus. and if the page is loading we want to use the requestedUrl, if it has loaded we want to use the actualUrl
[11:50] <oSoMoN> nerochiaro, I guess the reason is that there is no point in trying to simplify an empty URL. Try removing the check and run the unit tests. If they pass it should be safe to remove.
[11:53] <nerochiaro> oSoMoN: can you confirm that my understanding of how the simplification logic should work is correct, as written above ?
[12:26] <oSoMoN> nerochiaro, « we want to simplify the text only when the addressBar has active focus » : that’s precisely the opposite
[12:27] <oSoMoN> nerochiaro, if the page is loading, we’re not simplifying
[12:27] <oSoMoN> otherwise we use the actualUrl
[12:28] <nerochiaro> oSoMoN: so when do we use the requestedUrl ?
[12:28] <nerochiaro>     onRequestedUrlChanged: {
[12:28] <nerochiaro>         if (!activeFocus) {
[12:28] <nerochiaro>             text = internal.simplifyUrl(requestedUrl)
[12:28] <nerochiaro>         }
[12:28] <nerochiaro>     }
[12:34] <nerochiaro> oSoMoN: also, unrelated, is there anything special that I need to do when running unit tests with a modified oxide branch ? when running webbrowser-app manually with the modified branch I set the env variables you suggested some time ago to point to the oxide build, and everything works. but if i run ctest from the same shell, a number of QML tests fail. how do you do it ?
[13:19] <oSoMoN> nerochiaro, nothing special should be needed, what errors are you getting?
[13:20] <nerochiaro> oSoMoN: no errors, just tests failing that don't fail when i run them from a shell that does not have any oxide-specific env vars set
[13:21] <oSoMoN> nerochiaro, well if there are failures can you paste them somewhere so I can investigate? run the tests with ctest -V
[13:24] <nerochiaro> oSoMoN: failures are here: http://termbin.com/0pnp and I prepare the shell where I run ctest -V by going to oxide/build and running 'source' on this file: http://termbin.com/huin
[13:25] <nerochiaro> oSoMoN: hold on, something wrong with the failures file i uploaded
[13:27] <nerochiaro> oSoMoN: they seem to fail only when i launch them manually (using tst_QmlTests) but not with ctest -V . I will investigate further and update you. sorry for the noise
[13:42] <balloons> dholbach, so we should talk about https://code.launchpad.net/~nskaggs/help-app/functional-test-template/+merge/260206. I threw that together quickly for someone who wanted to help out with writing some tests.
[13:46] <dholbach> balloons, I think it's great
[13:46] <dholbach> I'm just not sure about adding another ppa :-/
[13:47] <balloons> it's not permanent, but yea, it kind of needs a ppa. If you make it part of the build, that complicates things
[13:48] <balloons> if you leave it as -is until it can be a proper build depends, we can still modify the jenkins job to add the ppa
[13:49] <balloons> the other thing I wanted from you is a list of user stories to automate; aka, what functional tests need to be written specifically. Steps and expectations would help those looking to write the tests
[13:50] <balloons> also, I found a bug and I want to make sure it's not a dupe. Internal linking seems broken. Clicking on the 'scopes' internal link puts you in a browser window with no theming, menu, or controls
[13:54] <kalikiana> t1mp: loicm: zsombi I'll leave it as-is now https://developer.ubuntu.com/en/blog/2015/05/26/keeping-track-evolving-qml-components/ let me know if you like it, and I can publish it later today
[13:54] <dholbach> DS-McGuire, what do you think about https://daniel.holba.ch/blog/2015/05/rfc-help-app-design/#comment-2048027884?
[13:57] <oSoMoN> nerochiaro, the failure is most likely because tst_QmlTests needs an -import parameter to locate oxide, see tests/unittests/qml/CMakeLists.txt for how the test is run
[13:57] <nerochiaro> oSoMoN: makes sense. thanks
[13:58] <kalikiana> zsombi: https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/noDepNoteForComponents/+merge/260302
[13:58] <kalikiana> it's not catching a 100% of the warnings but very very close
[13:58] <dholbach> balloons, for now I think it'd be good to just add the foundations for more functional tests
[13:58] <zsombi> kalikiana: wow, nais!!!!
[13:59] <dholbach> balloons, I'm not quite sure which ones we need
[13:59] <dholbach> balloons, maybe just navigate to a page and back again...
[13:59] <kalikiana> zsombi: crossing one out on the list of things I s/always/NEVER EVER/ wanted to achieve in life. get deep into the qml type system....
[14:05] <balloons> dholbach, I suggested nagivating to every page to start
[14:05] <dholbach> cool, sure - why not?
[14:06] <balloons> I listed a few others I thought of on the bug. But yes, I'd like the mp to go as-is.. no tests, just foundation
[14:06] <loicm> kalikiana: good stuff in there, it's fine for me
[14:10] <loicm> kalikiana: the construction of that sentence could be better IMO "It's designed to be used a way to serialize the public QML API in a way that is human readable as well as easy to process in a pogrammatic fashion."
[14:12] <kalikiana> loicm: how about "It's designed to serialize the public QML API in a way that is human readable as well as easy to process in a pogrammatic fashion."
[14:12] <loicm> kalikiana: much better :)
[14:18] <sturmflut2> sverzegnassi: Great job on the new Document Viewer!
[14:21] <sverzegnassi> sturmflut2, thank you! Hope to add SD card  write support soon... :)
[14:27] <sturmflut2> sverzegnassi: Since when does it render PDFs so fast? I just put a "Linux Voice" issue on the SD card of my bq and it rendered the first page within five seconds. This document is very complex, even my high-powered desktop sleeps for two seconds before anything is displayed.
[14:30] <popey> heh, i use Linux Voice as my tests too
[14:30] <sverzegnassi> sturmflut2, the rendering happens in multiple threads (at the moment the number of threads is hardcoded at 4). Each page is rendered in a single thread, in order to use all the power of the SoC.
[14:31] <sturmflut2> sverzegnassi: Very nice!
[14:33] <popey> it's _really_ hard to get all those cores to wake up
[14:45] <kalikiana> published https://developer.ubuntu.com/en/blog/2015/05/26/keeping-track-evolving-qml-components/
[15:12] <nerochiaro> oSoMoN: i think that https://code.launchpad.net/~uriboni/webbrowser-app/find-in-page/+merge/258225 should be good now
[15:25] <nik90> popey: ping
[15:26] <popey> nik90: hello!
[15:26] <nik90> popey: Hi :)
[15:26] <popey> nik90: am on a hangout, but type at me :)
[15:26] <nik90> popey: sure, it looks like https://code.launchpad.net/~brendan-donegan/ubuntu-clock-app/disable_location_prompt/+merge/242682 is going to be merged at which point clock-app should be free of release blockers. Can you get QA to test it and get out a release when possible?
[15:27] <nik90> popey: as always i have kept the clock-app changelog updated at http://pad.ubuntu.com/clock-app-changelog
[15:27] <popey> nik90: you bet!
[15:27] <nik90> popey: once this release goes through, I am going to migrate clock-app to the new 15.04 framework in preparation for OTA-4
[15:28] <nik90> popey: thnx
[15:34] <nik90> rpadovani: hey would you have time to review https://code.launchpad.net/~nik90/ubuntu-clock-app/fix-empty-state-warnings/+merge/260173 today? It is a harmless MP
[15:35] <rpadovani> nik90, lucky guy, I've just 5 minutes, on it :-)
[15:35] <nik90> rpadovani: ;)
[15:47] <STEiN__> Really silly question, I'm trying to write an app for Ubuntu touch- but I can't seem to find a way to select phone for build (It all says Desktop Desktop) I read the Convergence page online, does that mean I can just install my app to my phone even though it's not written for phone?
[15:48] <nik90> STEiN__: hi there...what kind of project is it (qmlproject, cmake, qmake)?
[15:49] <STEiN__> I just hit new HTML5 project, because I couldn't find a project that said that it was compatible with phones
[15:49] <nik90> STEiN__: either way, click on Projects in the sidebar on the left and then choose the phone kit. That should build it for the phone.
[15:49] <STEiN__> I normally write apps for Android/Mac (Odd combo but eh..)
[15:50] <nik90> STEiN__: I presume, you have run through the initial ubuntu-sdk configuration like creating chroots, kits etc?
[15:50] <STEiN__> Nope, I just followed the Wiki to install the Ubuntu SDK haha
[15:51] <STEiN__> It jumps right from Installing the SDK --> Create an App Project
[15:51] <nik90> STEiN__: I would recommend reading through https://developer.ubuntu.com/en/start/ubuntu-sdk/ to get you acquainted.
[15:51] <nik90> STEiN__: and after the create an app project, it links to running apps from the sdk
[15:51] <nik90> which shows how to run your app on the desktop, phone and any other device for that matter
[15:52] <STEiN__> Cool, thanks :)
[15:52] <nik90> yw
[15:53] <nik90> balloons: hey, I'd like some help with debugging the jenkins issue in https://code.launchpad.net/~nik90/ubuntu-clock-app/fixed-bottomedge-status/+merge/253998
[15:54] <nik90> balloons: manually testing it on the desktop and phone, I can't hit the issue that AP seems to face when run by jenkins
[15:54] <nik90> and code has been approved by zsombi, so its bound to be correct.
[15:56] <balloons> nik90, I like that theory.. bound to be correct
[15:56] <balloons> sure, give me a few mins I'll have a look
[15:57] <nik90> ;)
[15:57] <nik90> well I trust zsombi's judgment when it comes to alarm code
[16:23] <balloons> nik90, the location fixes landed
[16:24] <nik90> balloons: yup..I have requested popey to ask QA to test clock-app and push out a release
[16:25] <balloons> I kicked off a re-run of https://code.launchpad.net/~nik90/ubuntu-clock-app/fixed-bottomedge-status/+merge/253998
[16:25] <nik90> balloons: quick question, which ubuntu version is jenkins running on?
[16:25] <balloons> and I'll have a look in a moment
[16:26] <nik90> balloons: I just proposed https://code.launchpad.net/~nik90/ubuntu-clock-app/migrate-to-15.04-framework/+merge/260336 where I use Ubuntu.Components 1.2 which I know for sure has landed in vivid, but it fails complaining that it cannot be found.
[16:29] <nik90> more specifically the unit tests are failing because QtQuick 2.4 and Ubuntu.Components 1.2 are not found
[16:41] <sverzegnassi> mzanetti: ping
[16:41] <mzanetti> sverzegnassi, hi
[16:44] <sverzegnassi> mzanetti, o/ do you have some spare time for talking about tweakgeek and uttt?
[16:47] <mzanetti> sverzegnassi, sure
[17:15] <balloons> nik90, indeed, it's on utopic
[17:16] <balloons> let's get that fixed
[17:29] <STEiN__> hey nik90, are you still here?
[17:30] <mcphail> How do I force landscape orientation for an app?
[17:34] <kalikiana> t1mp: still around? wanna have a look at a small review? https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/unitTestApiCheck/+merge/260348 nothing added, just a little test case for what we have
[17:40] <mcphail> Is it even possible to force orientation? I thought it was, but can't find a reference in the API. I note cuttherope uses rotation:90 in the WebView, but I don't want to use a webview
[17:41] <ogra_> iirc you can only forst the change of orientation to off ...
[17:41] <ogra_> but if your portrait app gets started while the phone is in landscape it will come up in landscape
[17:41] <mcphail> that's not great news
[17:42] <ogra_> shell rotation support will likely fix that ... if that ever lands
[17:42] <mcphail> For normal apps, fixed rotation is evil. But for games...
[17:43] <ogra_> dont tell me :)
[17:45] <mcphail> yeah
[17:46] <zsombi> kalikiana: one comment on https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/noDepNoteForComponents/+merge/260302
[17:51] <kalikiana> zsombi: hmm that is a good point. but if I hard-code lib that makes it impossible to run out of the builder folder...
[17:51] <zsombi> kalikiana: perhaps just detecting that Ubuntu/Components is in the path would be enough
[17:51]  * mcphail is feeling grumpy. Getting the infrastructure in place for a games platform is rather difficult
[17:52] <kalikiana> mcphail: like bacon2d?
[17:53] <mcphail> kalikiana: bacon2d seems nice enough, but rather limiting. Would be nice to get something like the quake engine running. Being tied to Qt/QML or webviews for all games is not great
[17:57] <kalikiana> mcphail: depends on what you want of course. you can also use quake in js
[17:58] <kalikiana> in that sense 'tied to' is relative
[17:58] <mcphail> kalikiana: being stuck with emscripten is not great. SDL2 _works_, but needs shell support for things like rotation and fullscreen
[18:00] <kalikiana> there are javascript APIs for rotation and fullscreen, if anything you have an advantage because you don't need to implement it from scratch
[18:00] <kalikiana> note I'm not trying to convince you of anything - I was mostly curious about what you were after
[18:02] <mcphail> kalikiana: the platform is 90% capable of running most open-source (hence able to be compiled for armhf) games with little modification. But I really need that other 10%
[18:03] <mcphail> kalikiana: simply having the equivalent of the Android manifest, where you can force landscape mode, would be great
[18:03] <balloons> nik90, in the interim, here's a test run on vivid: http://<IP_ADDRESS>:8080/job/generic-mediumtests-vivid/1121/
[18:04] <nik90> balloons: which MP is this run for?
[18:05] <kalikiana> mcphail: that's already in the works, using the .desktop file
[18:06] <kalikiana> zsombi: updated https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/noDepNoteForComponents/+merge/260302
[18:06] <mcphail> kalikiana: That's great news! Cheers me up, 'cause I'm getting a bit grumpy
[18:07] <zsombi> kalikiana: happroved
[18:08] <zsombi> kalikiana: I still cannot find th ereason why the AP fails on tests...
[18:09] <zsombi> kalikiana: if I run the QML files, and try to invoke the funcs, they seem to show up... no idea why the AP doesn't bring them up...
[18:11] <kalikiana> zsombi: hrm
[18:11] <zsombi> kalikiana: though test_caret_hidden_if_empty seems not to delete the text, and if I run test_textinput.header.qml, and if I delete the text from the header's input, the caret is still visible...
[18:12] <kalikiana> zsombi: that's because you're typing then
[18:13] <kalikiana> er wait
[18:13] <zsombi> kalikiana: wow, if the test tyes to delete the inpu tcontent with the cross button, that doesn't work
[18:13] <kalikiana> hmmmmm
[18:14] <kalikiana> zsombi: which one is that exactly? lemme run it here
[18:14] <zsombi> kalikiana: ubuntuuitoolkit.tests.components.test_textinput.CaretTextInputTestCase.test_caret_hidden_if_empty
[18:26] <zsombi> kalikiana: weird... the test assumes the text input is empty... but the test shows it is not...
[18:26] <kalikiana> zsombi: interesting, fails in the header one for me as well
[18:28] <zsombi> kalikiana: yes, the assert is for the carret not being visible, but it is, as th einput has text... how the heck was this working before?!
[18:29] <zsombi> kalikiana: if I remove the text from the test, it passes....!
[18:30] <kalikiana> zsombi: odd indeed, the others don't have text, and the test would basically make no sense if there was any....
[18:31] <zsombi> kalikiana: yes... so just wonder how th eheck was this working before? it wasn't my MR which got this test, and I didn't change the test either
[18:31] <kalikiana> I'm quite sure it passed at one time, otherwise it wouldn't be in staging
[18:32] <zsombi> kalikiana: but that's wrong anyway, as the caret should be shown if there's text...
[18:32] <kalikiana> zsombi: hm?
[18:33] <kalikiana> this case is about an empty field where there is no text and thus no handler
[18:33] <zsombi> kalikiana: well, the test HAS text :)
[18:33] <zsombi> kalikiana: and noone deletes that text
[18:34] <kalikiana> zsombi: it does. but that would never pass. my only explanation is that a merge went wrong and it changed
[18:34] <zsombi> kalikiana: so if I remove the text from the test file, it passes
[18:34] <kalikiana> yes
[18:35] <zsombi> kalikiana: lemme check staging... but the prob is that my MR doesn't show any change there
[18:39] <zsombi> kalikiana: ok, staging has the same, everything is the same
[18:42] <zsombi> kalikiana: and fails on staging as well!!!!!
[18:42]  * zsombi eod
[21:02] <SvenBo90> Hello, can somebody help me? When I try to create an emulator on qtcreator I go to Devices and click on the +-button. But nothing happens. When I have a look on the console it says QQmlComponent: Component is not ready PopupUtils.open(): Failed to create the popup object.
[21:48] <popey> jdstrand: seen https://myapps.developer.ubuntu.com/dev/click-apps/2744 ?
[22:06] <jdstrand> popey: I haven't, but we can't allow that