=== charles__ is now known as Guest11727
=== Guest11727 is now known as charles
[07:06] <sil2100> didrocks: hello! Tests for touch are done \o/
[07:07] <sil2100> didrocks: Unity SRU-2 all green regarding touch \o/
[07:07] <sil2100> didrocks: can I publish the tarball?
[07:07] <didrocks> sil2100: yes, you can :)
[07:07] <didrocks> sil2100: also, send me the unity-2d branch please
[07:12] <sil2100> didrocks: will send you all links to branches on e-mail in a moment
[07:18] <didrocks> thanks
[07:28] <sil2100> didrocks: all green still? ;)
[07:30] <sil2100> didrocks: too late, tarball published!
[07:31] <sil2100> ;)
[07:31] <didrocks> sil2100: you didn't add the right nux build-dep for unity and unity-2d as well, I'll do them
[07:32] <didrocks> https://bugs.launchpad.net/unity-2d/+bug/1046392 should foolow the SRU policy
[07:32] <ubot5> Ubuntu bug 1046392 in unity-2d "Update dependency on the renamed libgeis" [Undecided,Fix committed]
[07:32] <sil2100> Ah, this bug, ok!
[07:32] <sil2100> This bug was missed, doing it now
[07:33] <didrocks> needs a SRU bug (the same I think) for nux and unity for the renaming
[07:33] <sil2100> didrocks: thank youu!
[07:33] <didrocks> sil2100: see ^
[07:33] <didrocks> sil2100: all the other bugs follow the SRU policy (for unity)
[07:33] <didrocks> ?
[07:33] <sil2100> didrocks: yes, for unity - I updated the descriptions to follow SRU, the only thing left is nominating some of them to Precise, but besides that it's all SRUable
[07:34] <sil2100> didrocks: maybe I could add nux and unity to the bug above and make that SRUable?
[07:34] <didrocks> sil2100: looks the easiest way to me
[07:34] <sil2100> didrocks: would that be ok?
[07:34] <sil2100> ACK
[07:34] <didrocks> sil2100: change the description to tell that the test has to be done with unity *and* unity-2d
[07:35] <didrocks> and ping me with the bugs I need to approve the nomination for :)
[07:35] <sil2100> didrocks: will do! :)
[07:35] <didrocks> sil2100: I'm adding the bug # to the changelog meanwhile
[07:37] <sil2100> didrocks: ok, thanks! I'll open up the Unity milestone then and add it there
[07:38] <didrocks> perfect
[07:40] <sil2100> didrocks: actually...
[07:41] <sil2100> didrocks: for unity and nux there is already a Bug
[07:41] <sil2100> https://bugs.launchpad.net/nux/+bug/1047385
[07:41] <ubot5> Ubuntu bug 1047385 in unity (Ubuntu) "Update dependency on renamed geis" [High,Triaged]
[07:41] <didrocks> sil2100: hum, you did built that on a precise machine?
[07:41] <sil2100> didrocks: unity? Yes, I was building it on my precise chroot
[07:41] <didrocks> ok, I'll add those then :)
[07:42] <didrocks> hum
[07:42] <didrocks> I'm getting a dep issue
[07:42] <didrocks>  libgrail5 : Depends: libframe6 (>= 2.2.4) but it is not installable
[07:42] <didrocks> E: Package 'libframe6' has no installation candidate
[07:42] <sil2100> Do you have proposed enabled?
[07:42] <didrocks> yep, proposed main
[07:43] <sil2100> Strange, all packages are build in our unity-team/sru ppa as well
[07:43]  * didrocks runs rmadison
[07:43] <didrocks> ah, it's in precise-updates already
[07:43] <didrocks> so, I need to add it as well to my chroot
[07:44] <sil2100> Oh!
[07:44] <sil2100> :)
[07:44] <didrocks> I would have thought that pbuilder have them enabled by default (not proposed, but updates :))
[08:46] <didrocks> sil2100: ok, everything building and ready, just waiting on the bug SRU status to be sorted out :)
[08:49] <sil2100> didrocks: https://bugs.launchpad.net/ubuntu/+source/unity-2d/+bug/1046392 nominated!
[08:49] <ubot5> Ubuntu bug 1046392 in unity-2d (Ubuntu) "Update dependency on the renamed libgeis" [Undecided,Fix committed]
[08:49] <sil2100> Rest in the works, in a moment ;)
[08:49] <didrocks> great :)
[09:13] <duflu> MCR1: I assume the benchmark offset gives you better results now?
[09:15] <MCR1> duflu: Better results should in this case be much lower results because of the non-damage triggering ?
[09:15] <duflu> MCR1: Yes, lower idle and higher when a window is busy
[09:16] <MCR1> duflu: It still does not fall below ~15fps.
[09:16] <duflu> Hmm, sounds wrong
[09:16] <MCR1> when idling
[09:16] <duflu> But that might be unity's fault
[09:16] <duflu> I will have to test it later
[09:17] <MCR1> duflu: I remember the benchmark in Compiz 0.8 versions showing thousands of frames per second...
[09:17] <MCR1> now it will never show more than the screen refresh rate, which is also not correct
[09:19] <MCR1> so currently the benchmark tool is not doing things right, because comparing stuff with these results is problematic
[09:19] <MCR1> duflu: valgrind compiz does not work, because Compiz already runs
[09:20] <MCR1> duflu: and valgrind compiz --replace did not succeed once here
[09:21] <duflu> MCR1: OK, some crashes do that
[09:21] <MCR1> duflu: But for the massive unityshell slowdown no benchmark tool is even needed, because the change in framerate is so high...
[09:22] <duflu> MCR1: It should be limited to the refresh rate, as configured in CCSM > Composite and CCSM > OpenGL
=== mmrazik is now known as mmrazik|lunch
[09:23] <MCR1> duflu: But the options of the benchmark tool say something else (gotta reboot to tell you exactly as composite is currently disabled)
[09:24] <sil2100> didrocks: can I give you a list of bugs to ACK nominations ;)?
[09:24] <sil2100> On priv?
[09:26] <MCR1> duflu: If the FPS Limiter Mode says "Limiter disabled" it should run without any limit, no ?
[09:27] <duflu> MCR1: I don't think the "limiter" makes sense any more. The options you want are sync to vblank (OpenGL) and the refresh rate (Composite)
[09:41] <MCR1> To All: Seems I found a workaround for slow framerates under Unity -> disable "Framebuffer object" in the CCSM OpenGL plug-in 8-)
[09:42] <MCR1> Could someone plagued by low framerates try that one and confirm ? ^^
[09:43] <MCR1> smspillaz: Ping ^^ :)
[09:45] <MCR1> Here on ATI with gallium driver this brings an awesome increase in speed, so probably we should turn it off by default (current default == on) if it speeds up other gfx configs as well...
[09:46] <MCR1> Anyone running current trunk on Quantal capable of testing this ?
[09:47] <smspillaz> MCR1: yes, that's known. I'm working on a solution for it now
[09:47] <MCR1> oh okay, I did not know it :)
[09:47] <smspillaz> MCR1: we can't turn it off by default because that will introduce tearing
[09:48] <MCR1> no tearing visible here
[09:48] <smspillaz> MCR1: that is unless radeon respects the swap interval with glXCopySubBufferMESA
[09:49] <smspillaz> MCR1: you will still get tearing under heavy load
[09:50] <MCR1> smspillaz: Okay, thanks a lot for the info. I hope you find a nice solution :)
[09:51] <smspillaz> MCR1: incidentally the thing I am writing won't work for you because radeon does not implement glBlitFramebuffer properly. But we can dream
[09:51] <MCR1> :)
[09:52] <smspillaz> MCR1: actually, all the compositors will benefit immensely once the DRI2 proto stuff is figured out for partial buffer copying on the swap interval
[09:52] <smspillaz> until then ...
[09:53] <MCR1> Does Compiz check which hardware/driver the user is running ?
[09:53] <MCR1> We could and should use this information to automatically adjust the settings in CCSM depending on the hardware...
[09:54] <smspillaz> MCR1: no, and it shouldn't. OpenGL is supposed to be platform agnostic
[09:54] <MCR1> If the defaults are not good for every config, we should make one default for every config...
[09:54] <MCR1> and stop dreaming, no ? ;)
[09:55] <smspillaz> I will generally only add workarounds for broken proprietary drivers where they have not fixed their driver after I have asked them to multiple times
[09:55] <smspillaz> MCR1: or, we could just fix the drivers
[09:55] <MCR1> hehe
[09:56] <smspillaz> MCR1: unfortunately there's not a lot of motivation to fix this aspect right now. Wayland uses a guarunteed backbuffer through gbm so they don't need to be concerned about the backbuffer being undefined
[09:56] <smspillaz> as such, there's no future reason for us to implement post_sub_buffer and copy_sub_buffer
[09:58] <MCR1> The average Compiz user should not be forced to change settings or even open the workarounds plug-in, we should adjust that automagically for him...
[09:58] <MCR1> until the drivers are fixed...
[09:58] <MCR1> after all we know which setting needs to be triggered for which combination of gfx/driver
[09:59] <MCR1> on the desktop/laptop platform we do not have that many...
[10:00] <MCR1> Intel only has free drivers, so that is 1, ATI- gallium or fglrx +2, Nvidia noveau + proprietary +2 - makes 5 combinations
[10:00] <smspillaz> MCR1: plus 4 different ARM drivers
[10:00] <smspillaz> tegra2, tegra3, pvr, mali
[10:01] <smspillaz> llvmpipe
[10:01] <MCR1> yeah, unfortunately I do know nothing about those, but still...
[10:01] <MCR1> defaults should be sane
[10:01] <smspillaz> MCR1: the problem with adding workarounds is that it hides the problem
[10:01] <smspillaz> the bugs continue to lie undetected in the driver
[10:01] <smspillaz> until someone hits the one day
[10:01] <smspillaz> *them
[10:01] <MCR1> Sure, workarounds are never the right fix - but our only solution for 12.10, no ?
[10:02] <MCR1> I mean here for example the difference is night and day without framebuffers
[10:02] <smspillaz> MCR1: example: the intel mesa driver does not advertise GL_BIND_MIPMAP_TO_TEXTURE in the fbconfigs because every compositor never checked for it properly
[10:02] <smspillaz> MCR1: give us a while to try and come up with a solution
[10:02] <MCR1> ok, sure - you are the boss ;)
=== doko_ is now known as doko
=== mmrazik|lunch is now known as mmrazik
=== MacSlow is now known as MacSlow|lunch
[11:53] <tsdgeos> smspillaz: still around?
[12:11] <smspillaz> tsdgeos: yes
[12:11] <smspillaz> tsdgeos: whats up ?
=== MacSlow|lunch is now known as MacSlow
[12:18] <Mirv> didrocks: do you think we can still drop the gconf support in compiz now that the decorator was ported, or is it too risky? it seems to build and run (now finally) fine on 0.9.8.2 with -DUSE_GCONF=OFF
[12:18] <Mirv> ie. build also without libgconf2-dev
[12:19] <didrocks> Mirv: I'm fine with that, just ensure that the gconf -> gsettings transitional package add a dep then on the convert tool
[12:20] <Mirv> didrocks: ok, thanks
[12:21] <didrocks> yw
=== _salem is now known as salem_
[13:06] <tsdgeos> smspillaz: oh sorry, about https://code.launchpad.net/~aacid/compiz/do_not_change_viewport_on_resize/+merge/123564 when you say " I think it might make sense to add a check here to check if the window is on the currently active viewport, and if so, to always maximize it on that viewport." it is what the removal of  the viewportForGeometry call actually does
[13:16] <smspillaz> tsdgeos: still around ?
[13:17] <tsdgeos> smspillaz: yes
[13:18] <smspillaz> tsdgeos: ah okay, you are right about that code being confusing. The situation I'm thinking its designed to handle is one where a window maximized on a viewport that is /not/ the current viewport - eg, if some other window maximizes itself you don't want it to maximize on the current viewport
[13:18] <smspillaz> so I think the appropriate check as to whether or not to apply a viewport offset would be like window->defaultViewport () == screen->vp ()
[13:18] <smspillaz> and then if its not, apply the offset
[13:19] <tsdgeos> ok, i see
[13:19] <tsdgeos> smspillaz: any hint on how to do the testing?
[13:20] <smspillaz> tsdgeos: that function will be tricky, let me check the whole thing
[13:21] <tsdgeos> because i checked and doesn't seem to be any test that checks "that deep"
[13:22] <smspillaz> tsdgeos: oh wow that function really is a monster
[13:22] <tsdgeos> it is :'(
[13:23] <smspillaz> 400 lines
[13:23] <smspillaz> tsdgeos: what I would suggest is to try breaking it up into smaller utility functions
[13:23] <smspillaz> then it will become clearer how to get those functions under test
[13:24] <smspillaz> tsdgeos: if you don't have time, I can probably take it on next week ish
[13:24] <tsdgeos> well
[13:24] <tsdgeos> it's not that i don't have the time (which not sure i have) it's more than i'm not sure i can name the new functions sensibly :D
[13:24] <tsdgeos> i'll give it a try
[13:24] <tsdgeos> and if not report back
[13:25] <smspillaz> tsdgeos: sure :) generally speaking what I do is look at what the function is doing and put it in a short sentence
[13:25] <smspillaz> if there's an "and" in it, its the wrong abstraction :p
[13:25] <tsdgeos> :D
=== cjohnston_ is now known as cjohnston
[13:42] <Mirv> didrocks: lp:~timo-jyrinki/compiz/ubuntu.dropgconf being proposed to lp:ubuntu/compiz
[13:47] <didrocks> Mirv: looking good, thanks! pushed
[14:34] <sil2100> didrocks: I'm getting a strange error while trying to upload my unity-2d package for oneiric for testing to a PPA
[14:34] <sil2100> didrocks: it keeps rejecting it saying that there is already a unity-2d_4.12.0.orig.tar.gz in the archives and that it has different contents
[14:34] <sil2100> didrocks: while I even downloaded it directly
[14:35] <sil2100> didrocks: I was doing a bzr bd -S, then I even took it with apt-get source on my oneiric chroot to get the .orig and then re-run bzr bd -S - it's all the same
[14:36] <sil2100> So hm, how come there is a tarball mismatch when I'm using the one from the archives?
[14:37] <didrocks> sil2100: did you download the orig.tar.gz from the distro?
[14:37] <didrocks> sil2100: maybe bzr bd repacks it differently today
[14:38] <didrocks> I mean, after you apt-get source
[14:38] <didrocks> you rm -rf build-area ?
[14:57] <sil2100> didrocks: ah, right
[14:58] <didrocks> "right" == you did it or not ?:)
[14:58] <sil2100> didrocks: I didn't remove build-area ;)
[14:58] <sil2100> didrocks: anyway, hm, sorry for the noobish question, but does this mean I need to do those unity-2d oneiric changes as a quilt patch..?
[14:59] <didrocks> sil2100: I don't think so, why?
[14:59] <didrocks> you can bzr merge
[15:01] <sil2100> didrocks: that's what I'm doing, but with the original tarball from the archives, when I do bzr bd -S it says that there are uncommited changes and that with format 3.0 I need to do a quilt patch
[15:04] <didrocks> sil2100: oh right, they forced format 3.0 at this time
[15:04] <didrocks> sil2100: so yeah, you have to do quilt patches, I'm afraid
=== dandrader is now known as dandrader|Afk
=== ken__ is now known as kenvandine
=== dandrader|Afk is now known as dandrader
[16:06] <sil2100> didrocks: you would like me to send you the unity-2d branch with the quilt patch made, or is unity-2d trunk (with native changes) enough for you?
[16:07] <sil2100> didrocks: since I use the quilt one for testing, but not sure if you want to do some mojo of your own ;) ?
[16:08] <didrocks> sil2100: I would prefer the unity62d branch with the quilt patch made, something ready to be sponsored. I don't have the time for experimenting :)
[16:10] <sil2100> didrocks: ok ;)
=== Canti is now known as Cantide
=== dandrader is now known as dandrader|lunch
[18:30] <quequotion> hello!
[18:31] <quequotion> I came to ask if there's any news or progress on bug 1025535
[18:31] <ubot5> Launchpad bug 1025535 in Compiz "Unity with transparent desktop cube visible over full-screen applications" [Low,New] https://launchpad.net/bugs/1025535
[18:38] <quequotion> also, though off topic, how many "affects me" does a bug need before the auto-confirm kicks in?
=== dandrader|lunch is now known as dandrader
[19:45] <c10ud> Cimi, you there?
[19:45] <Cimi> c10ud, y
[19:45] <c10ud> Cimi, hello, mind taking a look at this? https://bugs.launchpad.net/ubuntu/+source/pygobject/+bug/1002792
[19:45] <ubot5> Ubuntu bug 1002792 in pygobject (Ubuntu) "emesene crashes with assertion failed in gtkstylecontext.c" [Undecided,Confirmed]
[19:46] <c10ud> I believe my description of the bug is wrong, the issue is theme-related. Not sure if you're still the theme-engine guy ;)
[19:47] <Cimi> c10ud, I don't think is theme related
[19:47] <Cimi> c10ud, either gtk or emesene are not disposing elements correctly
[19:47] <c10ud> Cimi, in my box i updated the theme engine with quantals' and i cannot reproduce the crash anymore (!)
[19:47] <Cimi> the timeout is running and operates over destroyed elements
[19:47] <Cimi> thus the segfault
[19:48] <Cimi> c10ud, you updated gtk too I think
[19:48] <Cimi> might be a bug in gtk then
[19:48] <c10ud> nope, i just installed some random deb i read in omg or some place like that
[19:49] <Cimi> it's not a ug in the theme though
[19:49] <Cimi> *bug
[19:51] <c10ud> i am checking the package list and i don't see any gtk -- i believe it's the gtk3-engines-unico that's causing issues
[19:51] <c10ud> if you can backport a fix or do something i can triple-check
[19:51] <c10ud> (and want me absolutely sure)
[19:53] <Cimi> c10ud, I don't have that function in unico :-)
[19:53] <Cimi> so it's not unico
[19:55] <c10ud> you don't have a Precise box around, i guess..?
[19:55] <Cimi> what is different is the animation
[19:55] <Cimi> I have some animations in precise
[19:55] <Cimi> no longer in 12.10
[19:55] <Cimi> so, this could be a bug in gtk
[19:55] <c10ud> ah
[19:55] <c10ud> ok then
[19:56] <c10ud> sorry for the noise, i'll see who's in charge for the gtk package then
[19:56] <Cimi> c10ud, in the precise theme
[19:56] <Cimi> c10ud, search for "transition"
[19:56] <c10ud> where?
[19:56] <Cimi> in gtk-widgets.css
[19:57] <Cimi> remove the lines and test
[19:58] <c10ud> Cimi, thanks, i'll update the bug report with this new info, make some tests and ping the right people then
[19:58] <Cimi> ok
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== salem_ is now known as _salem