[01:31] RAOF: Is there an important reason why Wily isos are not yet promoted (passing automated testing) that you know of? [01:32] duflu: Not to my knowledge. [01:32] I mean http://cdimages.ubuntu.com/daily-live/current/ [01:33] Possibly some test(s) failing that humans don't care about too much [01:33] (most) [01:36] Oh. I'm *using* wily on this laptop, and haven't noticed breakage. [01:36] If your question is “should I sudo sed -i s/vivid/wily/g /etc/apt/sources.list” [01:38] RAOF: Yeah I have one wily system set up. Just wondering when is the right time to migrate my development machine [01:38] A couple of weeks ago :) [01:39] 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] Yeah, but what tests. [01:41] 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] (often appear to work) === c74d is now known as Guest90315 === c74d3 is now known as c74d === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === marcusto_ is now known as mr_t_ === mr_t_ is now known as marcustomlinson [04:01] Time to put a faster drive in the build machine... [06:36] 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] how would one get the mir pointer state with out this? [06:43] with mir_pointer_event_button_state instead [06:44] 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. === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [08:36] 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? === chihchun is now known as chihchun_afk [09:24] greyback__: getting an dpkg error installing qtmir. missing libgsettings-qt-dev [09:25] greyback__: not in build-dep [09:26] which is kinda weird, since i thought dpkg uses the control file, and so does build-dep? [09:26] dednick: I see it in the debian control file [09:26] yeah, it does [09:26] you're *installing* qtmir, and it relies on this -dev package? [09:26] doesn't sounds right to me [09:27] greyback__: oh, no. using dpkg-buildpackage [09:27] ah compiling [09:27] ya [09:27] hm. i probably have something different in apt sources vs my source === chihchun_afk is now known as chihchun [09:27] might be difference between build-dep in vivid & vivid+overlay [09:28] as I think that gsettings requirement is in overlay only atm [09:28] i may not have updated my source repo since i added overlay. [09:28] nvm [09:28] i think that's it [09:28] would make sense [09:30] greyback__: what can I try to test qtubuntu update? [09:31] alan_g: that the mir surface close event? [09:32] dednick: rebuilt to match Mir-0.13.x API/ABI changes [09:32] alan_g: oh right. nevermind. [09:38] dednick: do you know what it can affect [09:39] alan_g: afraid not. [09:44] 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] dednick: yeah, I'm working on the assumption that any breakage would be very obvious. [09:45] But if there were something specific to look for... === chihchun is now known as chihchun_afk [11:46] 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] greyback__: thanks, I can try that [11:51] Rats! the thing rebooted [12:10] * alan_g decides testing on manta was a bad idea [12:11] mako seems stable === alan_g is now known as alan_g|lunch === mzanetti is now known as mzanetti|run === greyback__ is now known as greyback === mzanetti|run is now known as mzanetti === alan_g|lunch is now known as alan_g [13:19] alf_: glad you didn't disappear in the floods [13:41] alan_g: it seems that I brought the floods back home with me :) [13:42] 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] 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] alan_g: sure === chihchun_afk is now known as chihchun === dandrader is now known as dandrader|lunch [16:50] racarr, hey, so mir_pointer_event_buttons seems to be undefined? Not sure how to get the MirPointerButton from a PointerEvent then :( [16:50] i see it defined in lp:mir but not in /usr/include === alan_g is now known as alan_g|EOD === dandrader|lunch is now known as dandrader === chihchun is now known as chihchun_afk [18:39] bschaefer: still there? [18:40] you have to use mir_pointer_event_button_state instead === dandrader is now known as dandrader|afk [19:29] anpok, thats a strange function, soo i've to manually check each state? [19:30] anpok, thanks! I missed it since i was looking for a function that returned a MirPointerButton :) [19:30] yes you have to for now [19:31] and thats why racarr changed it then [19:31] cool, thanks again! === dandrader|afk is now known as dandrader [19:33] 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] that screenshot is pretty cool [19:34] lol [19:35] are phone applications supposed to be allowed to be transparent... [19:35] that seems like a mistake -.- [19:38] 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] 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] http://uppix.com/f-screenshot20150555676ea2001907fa.png [20:20] fun error im getting now :( [20:20] http://paste.ubuntu.com/11418145/ [20:22] the code thats uses it: http://paste.ubuntu.com/11418169/ [20:24] hmm looks like region im getting from the surface is invalid hmm [20:34] soo surface is getting created correctly (with software usage) [20:34] as this looks like the error i was having when i tried to get a region using a hardware surace [20:34] surface* === mibofra is now known as Guest65273 [22:58] bschaefer: yeah with mesa you won't be able to map it in the client... [22:58] works in android though :) [23:00] AlbertA, hmm but this should still work on the desktop? As demo multi win still works [23:00] which does the same thing :) [23:00] (software rendering) [23:01] 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] though my surface is valid [23:02] bschaefer: yes it should work if you specifically request software buffers [23:02] otherwise it's a bug... [23:02] but with hardware buffers, you'll get the perm issue [23:02] on mesa [23:02] AlbertA, o geeez [23:03] i think i know what i did :) [23:03] i created the surface before setting the buffer :) [23:03] * bschaefer slaps him self [23:03] bschaefer: lol ok [23:03] 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] 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] 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] AlbertA: lol... [23:26] this sort of stuff drives me insane... [23:26] "What does it mean? What does it mean? What does it...AHHHHHHHHHHHHHHHHH" [23:29] racarr: it even has helpful comments along the way :)