[03:10] <bilal> thumper: Hi
[03:10] <bilal> thumper: https://code.launchpad.net/~unity-team/unity/autohide-load-934514/+merge/117367 The answer is yes
[03:10] <bilal> should I re-propose for a ~unity-team review or will you take it up?
[03:22] <thumper> bilal: I've got it
[03:23] <bilal> thanks!
[03:23] <thumper> bilal: I think we need a manual test though
[03:23] <thumper> to make sure it doesn't regress
[03:23] <bilal> alright
[03:24] <bilal> I'll write one
[03:24] <thumper> thanks
[03:30] <bilal> thumper: test added, pushed, diff updated
[03:33] <marcavis> hey folks, we at #frogatto (also at www.frogatto.com, a 2d platformer game) are having an issue where, when we enter the game editor, the program tries to change its window size, which isn't working well on Unity; it keeps flickering between the former and the new size, for several seconds, sometimes crashing at the end. Have you heard of similar problems in other programs?
[03:34] <thumper> marcavis: no... please file a bug :)
[03:34] <thumper> marcavis: are the developers able to use your game editor to test?
[03:36] <marcavis> yes, the editor is built into the game, as well, accessible by pressing CTRL+E in the game
[03:36] <marcavis> (unneeded "as well" above)
[03:37] <thumper> marcavis: what toolkit does the editor use?
[03:37] <duflu> marcavis: I've seen the same bug happen with QEMU/KVM windows. It's probably compiz to blame.
[03:38] <marcavis> hmmm, makes sense... Frogatto just uses SDL/OpenGL, no specific GUI toolkits
[03:38] <duflu> marcavis: Yes, QEMU/KVM uses SDL too
[03:39] <duflu> marcavis: I can't remember if there ever was a bug for it. Please log one with "ubuntu-bug compiz"
[03:39] <marcavis> right... will do so in a bit
[05:04] <marcavis> <duflu> marcavis: I can't remember if there ever was a bug for it. Please log one with "ubuntu-bug compiz"
[05:04] <marcavis> duflu, about that; doesn't gnome 3 use compiz as well?
[05:05] <duflu> marcavis: No, Gnome 3 has a different compositor.
[05:05] <duflu> marcavis: Unless you use "Gnome Classic" which is still compiz :)
[05:06] <marcavis> ahh, okay. though... yeah, I actually use the "Gnome Classic" session most of the time, and I don't get that bug
[05:07] <duflu> marcavis: "Gnome Classic" uses compiz. "Gnome Classic (no effects)" does not
[05:07] <duflu> marcavis: Which do you use?
[05:07] <marcavis> ahh, understood. Yep, it's the latter
[05:07] <duflu> marcavis: OK, please log then bug then
[05:07] <marcavis> In fact, I'll try the former just to be sure it's compiz...
[05:08] <marcavis> well, unless you are quite sure already
[05:13] <duflu> marcavis: Yes, I'm quite sure. But you don't have to have 100% certainty to log a bug. That comes later :)
[05:14] <marcavis> Right, I see.
[05:20] <Mirv> let's try the compiz again today..
[05:20] <marcavis> 'kay, reported
[08:15] <sil2100> Trevinho: hi!
[08:15] <sil2100> Trevinho: are you around?
[10:53] <sil2100> didrocks: hi
[10:53] <sil2100> didrocks: need some advice again
[10:53] <didrocks> hey sil2100
[10:54] <sil2100> didrocks: so, I would prefer to revert the gesture commits made to nux and unity, since they are causing a LOT of regressions
[10:55] <didrocks> sil2100: ensure you revert that in trunk first
[10:55] <sil2100> didrocks: the unity commit regarding gestures can be reverted easily
[10:55] <sil2100> didrocks: but now regarding nux - which is the preferable way? :
[10:55] <sil2100> didrocks: 1) reverting the commit in trunk
[10:56] <sil2100> didrocks: 2) modifying distro by adding --disable-gestures to autoconf?
[10:56] <sil2100> (since nux has the ability just to disable geis during compile)
[10:57] <didrocks> sil2100: no, if it's really buggy, always ask for trunk revert before reverting in the packaging branch
[10:57] <didrocks> sil2100: otherwise, we will have ids conflict next time you merge
[10:57] <didrocks> sil2100: and it means that this code is not mature enough
[10:57] <sil2100> didrocks: ACK, so trunk it is
[10:58] <sil2100> Thanks
[11:00] <didrocks> yw ;)
[11:06] <didrocks> plus que 3 sujets à développer dans le google doc \o/
[11:07] <didrocks> oupss, wrong window :)
=== zyga is now known as zyga-food
=== zyga-food is now known as zyga
[12:55] <ice_flame1> Hello
[12:56] <ice_flame1> Can I ask a question?
[13:01] <dandrader> mhr3, ping
[13:02] <sil2100> dandrader: hi! Since the gestures issue wasn't yet resolved, I'll be reverting the nux and unity changes - it seems there's a bug in geis somewhere
[13:02] <sil2100> dandrader: so not to delay the release any further, I'll just revert the revisions that were using the bug and thus causing severe regressions
[13:03] <dandrader> sil2100, ok. I cannot do much about it since I cannot reproduce the issue in any of my two computers
[13:04] <sil2100> dandrader: we'll help in finding the cause, I'm pretty sure Jay and the others have some leads already
[13:20] <mhr3> dandrader, pong
[13:20] <mhr3> dandrader, i think the geis dbus backend isn't playing nice, why did you move from xcb to dbus?
[13:22] <dandrader> mhr3, that dbus backend is not used anymore.
[13:22] <dandrader> mhr3, gesture recognition is done now all in-process
[13:22] <mhr3> dandrader, eh, my unity thinks differently
[13:23] <dandrader> mhr3,  now that's weird. is it with my "nux gestures" patch on?
[13:23] <mhr3> dandrader, yes
[13:23] <dandrader> that really should not be happening
[13:23] <mhr3> well, is that something special?
[13:24] <mhr3> or just trunk nux
[13:24] <dandrader> mhr3, xcb backend was used back when xserver was doing gesture recognition. this is now long dead
[13:24] <dandrader> mhr3, and the d-bus backend was used when there was a separate daemon doing the recognition. this is also no longer the case
[13:24] <mhr3> dandrader, so what's supposed to be used?
[13:25] <dandrader> mhr3, in geis, the *grail* backend is the one that *must* be used now
[13:25] <mhr3> dandrader, hmm, so why isn't it?
[13:25] <dandrader> meaning that there's a grail instance running locally, doing the gesture recognition locally
[13:27] <dandrader> mhr3, what makes you think geis in unity (behind nux) is using the d-bus backend?
[13:27] <mhr3> dandrader,     geis_warning("back end not specified, defaulting to DBus");
[13:27] <mhr3> that ^^
[13:27]  * dandrader checks code
[13:28] <mhr3> you're not passing any backend to geis_new afaict
[13:28] <dandrader> yep. and it should end up fetching the grail backend
[13:29] <Mirv> seb128: would you have time to upload the compiz SRU today?
[13:29] <seb128> Mirv, trying to
[13:30] <Mirv> ok, let's see :)
[13:30] <dandrader> mhr3, it should fail getting the d-bus one up and running and then fallback to grail
[13:30] <mhr3> dandrader, why should it fail?
[13:32] <mhr3> aaah, ok, yep, it does that
[13:32] <dandrader> mhr3, because there's no gestures daemon working
[13:32] <dandrader> mhr3, you can run compiz/unity with the env variable GEIS_DEBUG=6 to see what happens on the terminal
[13:32] <mhr3> i thought 3 was enough :)
[13:33] <dandrader> mhr3, might be. I always use 6 :)
[13:33] <dandrader> and for grail output you would add GRAIL_DEBUG=-1
[13:33] <dandrader> pretty standardized :P
[13:33] <mhr3> dandrader, any chance for quick patch so it uses grail right away?
[13:34] <mhr3> (maybe the dbus one doesn't get destroyed properly or something
[13:34] <mhr3> )
[13:34] <dandrader> mhr3, sure, let me prepare one for nux and pastebin it
[13:34] <sil2100> mhr3: is this regarding the recent regressions in unity/nux trunk?
[13:35] <mhr3> yes
[13:35] <sil2100> mhr3: is this something that will fix the regressions ;p ?
[13:35] <mhr3> we'll see soon
[13:36] <sil2100> And I spent so much time today, battling CMake and autotools to revert those changes...
[13:36] <sil2100> Will be funny if it ends up not being needed
[13:36] <mhr3> i wouldn't hold by breath :)
[13:37] <mhr3> s/by/my/
[13:37] <dandrader> mhr3, http://paste.ubuntu.com/1136123/
[13:39] <mhr3> thx
[13:39]  * mhr3 builds, tests
[13:40] <mhr3> dandrader, fixed :)
[13:40] <dandrader> mhr3, what!?
[13:41] <mhr3> sil2100, i was wrong, you could have hold your breath :)
[13:42] <sil2100> Oh noes
[13:42] <sil2100> mhr3: so what, no regressions? No launcher bollocks?
[13:42] <mhr3> dandrader, it's not nice that you ship deprecated modules that do weird things to dbus :P
[13:43] <mhr3> sil2100, no lockups of launcher, so i proclaim it works
[13:44] <mhr3> sil2100, so there's your patch ^^
[13:44] <sil2100> mhr3: \o/
[13:44]  * mhr3 goes back to his work
[13:45] <sil2100> mhr3: I'll test it, thanks! You're a life-saver
[13:45] <sil2100> dandrader: thanks to you too
[13:46] <dandrader> mhr3, oh my... you're my hero!
[13:47] <dandrader> cnd, please check the backlog ^^^^
[14:09] <sil2100> JohnLea: hi, are you around?
[14:09] <JohnLea> sil2100; hyia
[14:10] <sil2100> JohnLea: I have a question - since I'm browsing though some distro manual tests right now
[14:10] <JohnLea> sil2100; cool, fire away
[14:11] <sil2100> JohnLea: sent the test-case to priv
[14:19] <cnd> dandrader: great!
[14:19] <cnd> I wonder if the patch from bregma yesterday fixes the same issue
[14:22] <sil2100> https://code.launchpad.net/~sil2100/nux/geis_fix/+merge/118760 <- the patch as a merge request
[14:23] <sil2100> mhr3: tested it on my system, it works like a charm \o/
[14:30] <dandrader> jaytaoko, could you please review it ^
[14:30] <dandrader> or maybe cnd...
[14:30] <bregma> ftr, my patch yesterday would not fix the issue, it only affects the case of no geis daemon on the dbus _and_ no XI2.2 support for MT
[14:32] <bregma> not sure why the dbus query would make Unity go haywire, but the proposed patch will definitely avoid that case
[14:33] <jaytaoko> dandrader: reviewing...
[14:34] <cnd> dandrader: approved :)
[14:35] <sil2100> cnd: thanks for the review!
[14:35] <sil2100> jaytaoko: if it's ok with you, we can merge it in ;)
[14:35] <jaytaoko> dandrader: I am compiling to test it on my system
[14:36] <sil2100> jaytaoko: ACK :)
[14:36] <sil2100> jaytaoko: please approve the merge when you test it positively
[14:37] <jaytaoko> sil2100: dandrader: I can't reproduce the bug from yesterday. yeah!
[14:37] <dandrader> awesome
[14:37] <jaytaoko> sil2100: dandrader: anything you want me to test before I approve?
[14:38] <dandrader> no
[14:38] <sil2100> \o/
[14:38] <jaytaoko> sil2100: dandrader: ok, I am approving
[14:39] <jaytaoko> sil2100: I am merging it now. ok?
[14:40] <jaytaoko> sil2100: do we need the UNBLOCK?
[14:40] <sil2100> jaytaoko: approve it :) The UNBLOCK is needed, since we're in a freeze
[14:40] <sil2100> But I already added it
[14:40] <jaytaoko> sil2100: oh right!. Ok, I am merging it.
[14:41] <jaytaoko> sil2100: done!
[14:41] <sil2100> jaytaoko: thanks! :)
=== mmrazik is now known as mmrazik|on_the_p
=== dandrader is now known as dandrader|afk
=== mmrazik|on_the_p is now known as mmrazik|otp
[15:00] <seb128> sil2100, jaytaoko: you will have "fun", the merger fails because nux fails to build with the quantal version of glew
[15:01] <seb128> sil2100, jaytaoko: somebody needs to fix nux to build with glew 1.8
[15:01] <sil2100> Aw come ooon ;p!
[15:01] <seb128> ;-)
[15:01]  * sil2100 chokes nux
[15:02] <sil2100> jaytaoko: ^
[15:02] <didrocks> sil2100: welcome welcome welcome :)
[15:02] <jaytaoko> seb128: hello!
=== salem_ is now known as _salem
=== _salem is now known as salem_
[15:03] <sil2100> Maybe we can somehow stick with the old glew ? ;)
[15:03] <jaytaoko> seb128: sil2100: ok, i am on it
[15:03] <seb128> sil2100, no, we can't go back in versions in distro
[15:04] <jaytaoko> seb128: by the way, glew 1.9 has been released yesterday with support for opengl 4.3
[15:04] <seb128> sil2100, and there is no reason to downgrade system libs and break other stuff to avoid fixing nux
[15:04] <seb128> jaytaoko, yeah, I saw, I didn't want to jump directly on the just released version, Debian already had 1.8
=== dandrader|afk is now known as dandrader
[15:11] <jaytaoko> seb128: can I just install libglew1.8?
[15:12] <seb128> jaytaoko, yes, just apt-get install libglew-dev
[15:12] <seb128> the current version is 1.8 and will give you libglew1.8 with it
[15:14] <jaytaoko> seb128:ok
[16:03] <jaytaoko> seb128: sil2100: i am still on the glew problem...
[16:03] <seb128> jaytaoko, did you manage to reproduce?
[16:04] <jaytaoko> seb128: yes, I am reproducing the issue
[16:17] <jaytaoko> seb128: ping
[16:17] <seb128> jaytaoko, hey
[16:18] <jaytaoko> seb128: I may have found something: http://sourceforge.net/tracker/?func=detail&aid=3549981&group_id=67586&atid=523274
[16:19] <jaytaoko> seb128: it seems to describe the problem we are having
[16:21] <seb128> jaytaoko, so you think it's an issue in glew?
[16:22] <jaytaoko> seb128: I think so, I did a diff with the previous version of GLEW and I found that there is a bloc of function that is affected
[16:23] <seb128> jaytaoko, do you have a patch?
[16:23] <jaytaoko> seb128: these function are the one you see in the build errors
=== Cantide is now known as CanNOTStudy
[16:23] <jaytaoko> seb128: no, I am first going to test that it works as per the recommended fix
=== CanNOTStudy is now known as Cantide
[16:26] <jaytaoko> seb128: NuxGraphics has compiled
[16:27] <jaytaoko> seb128: so I don't know if this is "the fix" but I tried what was described in the link
[16:27] <jaytaoko> seb128: but that involves changing a file in /usr/include/GL/glxew.h
[16:31] <seb128> jaytaoko, let me finish what I'm doing and have a look
[16:31] <jaytaoko> seb128: ok, I am compiling unity as well to test
[16:41] <seb128> jaytaoko, does that fixes it: http://glew.git.sourceforge.net/git/gitweb.cgi?p=glew/glew;a=blobdiff;f=auto/src/glxew_mid.h;h=e9a3391acefafcc1b2979d2cfad1d43c602521c1;hp=cfcd20d472a790f461e01e6e20a570582452236c;hb=6d14805de58321e8a7b1881323e604bb0ba27217;hpb=38a3d857549e7ac31b7edb2a1cfa1ead52f72220 ?
[16:43] <jaytaoko> seb128: it should
[16:44] <seb128> jaytaoko, I'm backporting that and retrying nux, thanks
[16:45] <jaytaoko> seb128: ok unity has compiled and is running with my local fix.
[16:46] <seb128> jaytaoko, thanks for looking at it
[16:46] <jaytaoko> seb128: no problem...
[16:46] <jaytaoko> seb128: I am going to make the same fix as the link you posted just to be sure...
[16:46] <seb128> jaytaoko, I'm pushing to a ppa for testing
[16:47] <jaytaoko> seb128: ok
[16:48] <sil2100> jaytaoko: so, will you push the nux merge to Approved once this glew issue gets resolved :) ?
[16:49] <seb128> sil2100, I can retry the nux merge requests once that's in
[16:49] <sil2100> seb128: awesome, thanks!
[16:50] <seb128> sil2100, yw!
=== dandrader is now known as dandrader|lunch
[16:50] <jaytaoko> sil2100: has soon as seb128 ppa is in, yes, we can try an merge again the geis fix
[16:51] <sil2100> \o/
[16:51] <sil2100> Excellent
[16:51] <sil2100> See you tomorrow everyone!
[16:54] <jaytaoko> seb128: I did the same fix as in your link and Nux compiled. it is looking good...
[16:58] <seb128> jaytaoko, I pushed it to quantal, it should be available in 30minutes
[16:59] <jaytaoko> seb128: cool! when can we approve the geis merge again?
[17:00] <seb128> jaytaoko, I will set it to approved when things are ok
[17:00] <jaytaoko> seb128: thanks!
[17:01] <seb128> jaytaoko, yw!
[17:33] <seb128> jaytaoko, https://launchpadlibrarian.net/112271202/buildlog_ubuntu-quantal-i386.nux_3.0.0-0ubuntu3~build1_FAILEDTOBUILD.txt.gz
[17:33] <seb128> jaytaoko, that patch is not good enough :-(
[18:07] <jaytaoko> seb128_:: I don't understand...
[18:08] <seb128_> jaytaoko, I will have a look, maybe that doesn't patch the right .h
[18:10] <jaytaoko> seb128_: ok
[18:11] <jaytaoko> seb128_: the file I patched locally is /usr/include/GL/glxew.h
[18:13] <seb128_> jaytaoko, yeah, that's not the one the git diff is patching
=== dandrader|lunch is now known as dandrader
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== marcavis is now known as marcgym
[23:01] <thumper> morning
[23:01] <thumper> where are we at now with the nux/unity release?
[23:02] <bschaefer> thumper, there was a regression in geis, but mhr3 found a fix but then there was a problem with something seb123 pushed causing Nux to not compile
[23:02] <thumper> bschaefer: and now?
[23:02] <bschaefer> thumper, I think, and jaytaoko was looking into getting Nux to compile to make unity merger happy to fix the regression the geis changes
[23:02] <thumper> bschaefer: I saw those results at 4am :)
[23:03] <thumper> really wondering what magic has happened in the intervening 7 hours :)
[23:03] <bschaefer> thumper, oo ok, yeah I think jaytaoko was looking into getting nux compiled (which I thought I saw he had a fix, but that branch isn't merged yet :( )
[23:04] <thumper> just saw the nux fix merge
[23:04]  * thumper goes to do an update
[23:04] <bschaefer> o nice!
[23:04] <bschaefer> so hopefully when that goes, then the geis fix merges then 6.2 is released! (im hoping at lease)
=== mfisch` is now known as mfisch
=== mfisch is now known as Guest6140