[01:31] <duflu> RAOF: Is there an important reason why Wily isos are not yet promoted (passing automated testing) that you know of?
[01:32] <RAOF> duflu: Not to my knowledge.
[01:32] <duflu> I mean http://cdimages.ubuntu.com/daily-live/current/
[01:33] <duflu> Possibly some test(s) failing that humans don't care about too much
[01:33] <duflu> (most)
[01:36] <RAOF> Oh. I'm *using* wily on this laptop, and haven't noticed breakage.
[01:36] <RAOF> If your question is “should I sudo sed -i s/vivid/wily/g /etc/apt/sources.list”
[01:38] <duflu> RAOF: Yeah I have one wily system set up. Just wondering when is the right time to migrate my development machine
[01:38] <RAOF> A couple of weeks ago :)
[01:39] <duflu> RAOF: I would have thought when distro declares it "passing" :)
[01:39]  * duflu always installs fresh
[01:39]  * RAOF doesn't actually know what gates iso promotion.
[01:40]  * duflu assumes it's test automation
[01:40] <RAOF> Yeah, but what tests.
[01:41] <duflu> Dunno. I would say I don't care but similarly if Mir was failing tests it would appear to work but still not be recommended for use
[01:41] <duflu> (often appear to work)
[04:01] <duflu> Time to put a faster drive in the build machine...
[06:36] <bschaefer> racarr, hey, w/e you see this tomorrow ... mir_pointer_event_buttons isn't defined in the new library? (but its in trunk?)
[06:36] <bschaefer> how would one get the mir pointer state with out this?
[06:43] <anpok_> with mir_pointer_event_button_state instead
[06:44] <anpok_> bschaefer: sometime after the 0.13 branch racarr reworked the button state enum another time and added the '_buttons' accessor, before that you could only query for buttons individually.
[08:36] <dednick> cimi: have you had any time to look at https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/lp1396058-multi-line-messages/+merge/257050 yet?
[09:24] <dednick> greyback__: getting an dpkg error installing qtmir. missing libgsettings-qt-dev
[09:25] <dednick> greyback__: not in build-dep
[09:26] <dednick> which is kinda weird, since i thought dpkg uses the control file, and so does build-dep?
[09:26] <greyback__> dednick: I see it in the debian control file
[09:26] <greyback__> yeah, it does
[09:26] <greyback__> you're *installing* qtmir, and it relies on this -dev package?
[09:26] <greyback__> doesn't sounds right to me
[09:27] <dednick> greyback__: oh, no. using dpkg-buildpackage
[09:27] <greyback__> ah compiling
[09:27] <dednick> ya
[09:27] <dednick> hm. i probably have something different in apt sources vs my source
[09:27] <greyback__> might be difference between build-dep in vivid & vivid+overlay
[09:28] <greyback__> as I think that gsettings requirement is in overlay only atm
[09:28] <dednick> i may not have updated my source repo since i added overlay.
[09:28] <dednick> nvm
[09:28] <dednick> i think that's it
[09:28] <greyback__> would make sense
[09:30] <alan_g> greyback__: what can I try to test qtubuntu update?
[09:31] <dednick> alan_g: that the mir surface close event?
[09:32] <alan_g> dednick: rebuilt to match Mir-0.13.x API/ABI changes
[09:32] <dednick> alan_g: oh right. nevermind.
[09:38] <alan_g> dednick: do you know what it can affect
[09:39] <dednick> alan_g: afraid not.
[09:44] <dednick> alan_g: i presume you're talking about your ~mir-team/qtubuntu/track-mir-deprecations branch. Which just looks confirming the touch and keyboard input still work. But as to it introducing specific problems i have no idea.
[09:45] <alan_g> dednick: yeah, I'm working on the assumption that any breakage would be very obvious.
[09:45] <alan_g> But if there were something specific to look for...
[11:46] <greyback__> alan_g: sorry, was afk. As input code was changed, I'd make sure to test multi-touch things, so 2 finger zoom gestures in camera & gallery would be a start. I'd do some finger mashing to make sure qt doesn't crash for any reason. And would test unity8 on desktop to ensure keyboard presses work
[11:47]  * alan_g can't remember the last time he had U8 working on desktop
[11:48] <alan_g> greyback__: thanks, I can try that
[11:51] <alan_g> Rats! the thing rebooted
[12:10]  * alan_g decides testing on manta was a bad idea
[12:11] <alan_g> mako seems stable
[13:19] <alan_g> alf_: glad you didn't disappear in the floods
[13:41] <alf_> alan_g: it seems that I brought the floods back home with me :)
[13:42] <alan_g> I like it "The fundamental theorem of agile software development: if you think you can’t split a development task, you probably didn’t try hard enough." @PeterHilton
[13:45] <alan_g> alf_: could you check the test I had to hack (rationale should be clear from MP comments) https://code.launchpad.net/~alan-griffiths/unity-system-compositor/spinner-rework/+merge/260148
[13:45] <alf_> alan_g: sure
[16:50] <bschaefer> racarr, hey, so  mir_pointer_event_buttons seems to be undefined? Not sure how to get the MirPointerButton from a PointerEvent then :(
[16:50] <bschaefer> i see it defined in lp:mir but not in /usr/include
[18:39] <anpok> bschaefer: still there?
[18:40] <anpok> you have to use mir_pointer_event_button_state instead
[19:29] <bschaefer> anpok, thats a strange function, soo i've to manually check each state?
[19:30] <bschaefer> anpok, thanks! I missed it since i was looking for a function that returned a MirPointerButton :)
[19:30] <anpok> yes you have to for now
[19:31] <anpok> and thats why racarr changed it then
[19:31] <bschaefer> cool, thanks again!
[19:33] <taiebot> Hi guys just a heads up on the sdl games that have landed on the store https://uappexplorer.com/app/neverball.lb https://uappexplorer.com/app/neverputt.lb? while they work correctly on vivid on willy mako its not the same  http://uppix.com/f-screenshot20150555676d30001907f7.png taiebot (a tester)
[19:34] <racarr> that screenshot is pretty cool
[19:34] <racarr> lol
[19:35] <racarr> are phone applications supposed to be allowed to be transparent...
[19:35] <racarr> that seems like a mistake -.-
[19:38] <taiebot> racarr:looks like a mir bug the app is a quarter of the screen with the top side having two time the app displayed
[19:39] <taiebot> while the input  are located in the right places if you manage to imagine where the input would be if the app was correctly displayed
[19:39] <taiebot> http://uppix.com/f-screenshot20150555676ea2001907fa.png
[20:20] <bschaefer> fun error im getting now :(
[20:20] <bschaefer> http://paste.ubuntu.com/11418145/
[20:22] <bschaefer> the code thats uses it: http://paste.ubuntu.com/11418169/
[20:24] <bschaefer>  hmm looks like region im getting from the surface is invalid hmm
[20:34] <bschaefer> soo surface is getting created correctly (with software usage)
[20:34] <bschaefer> as this looks like the error i was having when i tried to get a region using a hardware surace
[20:34] <bschaefer> surface*
[22:58] <AlbertA> bschaefer: yeah with mesa you won't be able to map it in the client...
[22:58] <AlbertA> works in android though :)
[23:00] <bschaefer> AlbertA, hmm but this should still work on the desktop? As demo multi win still works
[23:00] <bschaefer> which does the same thing :)
[23:00] <bschaefer> (software rendering)
[23:01] <bschaefer> I just find it strange that the region returned from the stream buffer is undefined ie. invalid pixel format and garage width/height
[23:01] <bschaefer> though my surface is valid
[23:02] <AlbertA> bschaefer: yes it should work if you specifically request software buffers
[23:02] <AlbertA> otherwise it's a bug...
[23:02] <AlbertA> but with hardware buffers, you'll get the perm issue
[23:02] <AlbertA> on mesa
[23:02] <bschaefer> AlbertA, o geeez
[23:03] <bschaefer> i think i know what i did :)
[23:03] <bschaefer> i created the surface before setting the buffer :)
[23:03]  * bschaefer slaps him self
[23:03] <AlbertA> bschaefer: lol ok
[23:03] <bschaefer> i had the software buffer being set but yeah just after the surface was created using the spec sooo it was using hardware
[23:06] <AlbertA> I'm curious to see what this would spit out with the mir code base: http://karpathy.github.io/2015/05/21/rnn-effectiveness/
[23:07] <AlbertA> this is what it spits out when trained with the linux kernel code base: http://cs.stanford.edu/people/karpathy/char-rnn/linux.txt
[23:26] <racarr> AlbertA: lol...
[23:26] <racarr> this sort of stuff drives me insane...
[23:26] <racarr> "What does it mean? What does it mean? What does it...AHHHHHHHHHHHHHHHHH"
[23:29] <AlbertA> racarr: it even has helpful comments along the way :)