=== alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g [08:32] duflu: Hi :) Haha, do you mean me, if you say: "even abusers of CCSM" ? [08:33] MCR: No, but there are plenty of people who break their systems with CCSM. [08:34] duflu: I tried to bring more structure to bug 1030473 and seperated the different warnings/potential errors, but I need advice on how to best act on those... [08:34] Launchpad bug 1030473 in Compiz "Error-reports cppcheck (http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Main_Page)" [Medium,In progress] https://launchpad.net/bugs/1030473 [08:34] duflu: https://code.launchpad.net/~mc-return/compiz/compiz.fix1030473-part4/+merge/118409 [08:35] MCR: I rejected that proposal. Please ignore it. [08:35] MCR: Please submit each type of fix separately [08:37] duflu: It would be nice if you could take a look at the different types and advice me how to/if to fix them. [08:38] MCR: Please submit each as a new bug and we can discuss them formally that way. [08:40] duflu: Maybe you are right and I should have done that in the first place, but at least we have reduced warnings to about 25% already. [08:40] MCR: Yes, it's good. But we have to have some discipline and formality to manage complexity. Otherwise everything becomes a mess. [08:41] duflu: Sure, I agree. [08:41] MCR: As always, one topic per bug please. And only one. [08:41] duflu: That is why I did the fix in parts and not all at once with a huge diff. [08:42] MCR: "per bug" means multiple bugs. Not multiple parts. [08:42] I got tired of being spammed with emails [08:43] duflu: ok, sorry - my intention was not to spam you, but to help with Compiz. [08:43] Although multiple emails is fine if each is a separate clearly defined bug. Otherwise there is no end. [09:19] duflu: Done. All issues separated into new individual bug reports. (Except for the field width specifiers, which we reject to fix if I understood you correctly) [09:25] MCR: Cool. Thanks [09:32] hello, I filed a wish on launchpad Bug #1026764 and was told to name the package. Can someone help me on the package? [09:32] Launchpad bug 1026764 in unity (Ubuntu) "Shortcut "Home|Ubuntu" disappears " [Undecided,Incomplete] https://launchpad.net/bugs/1026764 [09:33] oh sorry it was the wrong package [09:33] *bug [09:34] Bug #1028392 [09:34] Launchpad bug 1028392 in Ubuntu "shutdown shortcut " [Undecided,New] https://launchpad.net/bugs/1028392 [09:34] that's the right one === seb128_ is now known as seb128 [09:41] or is the package just unity? [09:45] noob7: Fixed. I think... ? [09:45] whaaaaat? [09:45] that is awesome [09:47] duflu: np [09:47] thanks [09:47] noob7: Package status corrected. Not bug fixed :) [09:47] yes that's what I was thinking at first ;) [09:47] thanks [09:48] I could be wrong though. [09:48] should be better than nothing [09:48] noob7: You can add such a shortcut easily via CCSM. [09:49] yes I know there are "workarounds" but it would be nice having it there [09:49] just for noobs ;) [09:50] noob7: Try this: http://www.iloveubuntu.net/how-add-shutdown-restart-suspend-hibernate-ubuntu-1204s-dash-ppa-available [09:53] so you would hit metakey, type power, and then click on the power icon?? [09:54] noob7: I use Synapse ;) [09:55] noob7: But you do not even need that - all you need is the CompizConfigSettingsManager. [09:56] noob7: There you have Commands, where you can take any shortcut you like and assign a comand to it, for example: sudo shutdown now -h [09:57] but afaik Ctrl+Alt+Del is used in Gnome to logout, so this is not available without removing this shortcut first [09:58] yes, you would just deactivate it in the shortcut menu and activate the shutdown/restart command [09:58] that's what I was thinking about [09:58] MCR, not in gnome3, its ctrl-alt-L there [09:58] ctrl-alt-del will try to shutdown/reboot [09:59] don't want to have a gnome3<->unity argument ;) [09:59] I'm used to gnome and try to get used to unity [10:00] tha's just my point of view [10:00] noob7: With the power commands I posted above you just get .desktop files for the respective actions, so you have starters for those (with Synapse this means Ctrl+Space, type sh, hit Return to shutdown here.) [10:01] Zhenech: It is a highly customized Unity-2d/Compiz environment here ;) [10:01] ;) [10:02] noob7: I recommend using CCSM for all your needs ;) [10:02] will have a look at this one thanks for the help [10:03] np === _salem is now known as salem_ [12:29] Trevinho: hi [12:30] Trevinho: I tried bisecting that Launcher problem with trunk... [12:31] Trevinho: strange thing though - I'm using quantal bamf right now and unity revision 2500, and the bug is still there ;/ === testuser2 is now known as firasnage === dinojoker is now known as jokerdino [13:00] hello [13:00] anybody there? [13:00] Hi [13:01] this is from ubuntu staff? [13:03] ayesh: what do you mean? [13:09] jaytaoko: hi [13:35] sil2100: hello [13:42] jaytaoko: hello - did you get the e-mail from me about the launcher unity problems? [13:43] jaytaoko: I'm currently trying to bisect my way to finding the problem, but the bug doesn't seem to be in unity or bamf ;/ [13:43] sil2100: not sure I saw that mail. when did you send it? [13:44] Like around an hour ago [13:44] Re: Fwd: unity-team/staging ppa launcher results [13:44] sil2100: ok I have it [13:45] jaytaoko: me and andyrock think it might be nux? But it doesn't make much sense... compiz also was probable [13:45] jaytaoko: or maybe it's the commit that moved geis to nux [13:45] jaytaoko, we tried with an old compiz and the problem is still here [13:46] with an old bamf and the problem is still here [13:46] i'm trying to revert nux to rev 633 now [13:47] building unity without geis commits [13:47] sil2100: so what is the problem exactly? [13:47] sil2100: still reading... [13:48] jaytaoko: the launcher does not correctly show the state of running applications, i.e. after starting a new application, a launcher icon does not appear - to make it appear, I have to switch to another workspace [13:48] jaytaoko: same with pips of running apps and windows, or when closing an application [13:49] That's on unity-team/staging and unity trunk [13:53] sil2100: ok, my first impression this does not seems related to geis. No gesture is involved in reproducing the problem... [13:55] jaytaoko: it seems to be something in nux [13:55] andyrock just tested on an earlier revision [13:55] sounds like a redraw issue [13:57] mhr3, mmm no [13:57] in bamflaunchericon.cpp i don't get the bamf signal [13:58] "active-changed" [14:00] sil2100: I am updating my system to check the issue [14:00] mhh, unity does not find .desktop files in /usr/local/share/applications? [14:01] andyrock: are you receiving a signal that the application has started in bamf? [14:04] i've tried with another signal "active-changed" [14:04] nux rev 639 no problem [14:04] nuv rev 640: i can reproduce the problem [14:05] i'm going to double check [14:06] \o/ [14:06] andyrock: excellent bisecting [14:07] nux is stealing glib events :P [14:08] but I'm not sure this is possible [14:08] :) [14:13] jaytaoko: could you take a look at it? As andyrock says, rev 640 seems to be the problem here [14:14] sil2100: yes [14:15] jaytaoko: thanks! [14:32] andyrock: btw. you think the same was causing the panel issue? [14:32] sil2100, yep and a lot of side effects [14:33] click on spread not working [14:33] etc, [14:33] andyrock: woha, it's a big commit this 640, I could have waited with this one till after 6.2 release [14:33] :( [14:52] sil2100: andyrock: are there other issues related to that branch [14:59] jaytaoko: ouch... well, yes, we noticed problems with the panel as well === morphis|away is now known as morphis [15:07] jaytaoko: ...can you fix it, or should we revert? [15:08] sil2100: I fear if we revert, then we would have to revert other branches in Unity as well... [15:08] jaytaoko: I know :( This is the problem, since unity has removed the gesture stuff too... [15:09] But if there is more than one regression, the regression potential is big [15:13] dandrader: do you think we can have a timely fix for this? ^ [15:15] jaytaoko, no. [15:16] dandrader: how much impact would this have on unity if we were to revert the branch in Nux? [15:16] jaytaoko, you have also to revert the corresponding patch in unity [15:16] I think it's safer just to revert those [15:17] and add a patch to make unity use libgeis instead of libutouch-geis, which should be a one-liner [15:17] sil2100: dandrader: any features that were expected for this release? [15:17] jaytaoko, ? [15:18] jaytaoko: none really, just the introduced fixes - so that quantal can have more-or-less weekly unity [15:18] dandrader: I mean, any bugs or requirement that were relying on geis in this release? [15:18] the "alt-tab with gestures" patch [15:18] that's currently sitting as a merge proposal. it builds on top of those patches [15:21] Well, I would recommend to revert the nux and unity revisions and just add a merge to unity with renaming of utouch to geis [15:35] sil2100: can we have a bit more time to try and fix this? [15:35] dandrader: any candidate for investigation? I am going through WindowThread::Mainloop [15:36] MainLoopGlib.cpp, WindoThread::ProcessEvents... [15:37] couldn't reproduce the problem yet [15:38] didrocks: hi. I verified the fix for bug #1032902 in compiz SRU. that means lp:~timo-jyrinki/compiz/precise_SRU-1 should be ready for pushing to precise-proposed. all other bugs in 1.3 release verification-done. [15:38] Launchpad bug 1032902 in compiz (Ubuntu Precise) "compiz 1:0.9.7.8-0ubuntu1.3 FTBFS in precise-proposed on armel, armhf" [Critical,Triaged] https://launchpad.net/bugs/1032902 [15:38] afk, though, but just in case it'd be ready already [15:40] jaytaoko: hm, since my EOD is nearing, let's maybe do it like this - if you want, you can try fixing this up today [15:40] If it will be not enough time, then I'll just revert the two revisions tomorrow in the morning [15:40] didrocks: Hey, did you manage to check out the library link I sent you a few weeks ago? [15:40] sil2100: understood [15:40] But I would in _overall_ prefer to have a well tested trunk released [15:41] ;) [15:41] jaytaoko: good luck then! :) [15:41] seb128: did you want to sponsor Mirv's compiz as you did upload the previous one? [15:41] doctormon: quite quickly, but yeah, I looked over to it, I like it :) [15:41] didrocks, upload to where? [15:42] didrocks, we already have a version in the queue no? didn't you upload it during GUADEC? [15:42] sil2100: thanks [15:42] didrocks, yeah, we have a version in proposed accepted 3 days ago [15:43] seb128: didrocks means a new version [15:44] seb128: since the previous one had a armel/armhf build problem which was fixed by Mirv [15:44] Mirv: ^ [15:44] didrocks: It seemed to me that gtkme and quickly's python library are very similar in goals. [15:44] sil2100, oh ok, I can have a look tomorrow I guess [15:44] are they a kin worth joining up? [15:44] seb128: excellent, thanks! [15:44] not today, I'm fighting with a zillion things [15:45] trying to do some +1 work, while looking a desktop workitems, some GNOME updates and some other build issues on the side [15:48] seb128: hum, seems that Mirv pointed to a link showing it FTBFS [15:49] doctormon: indeed, it seems to me you are making project similar to Quickly :) [15:49] didrocks, sorry my todolist for the end of day is like 5 hours worth of work still long and keep increasing, I'm not following IRC out of highlights ;-) [15:49] no worry ;) [15:50] will have a look to the log later or tomorrow [15:50] no worry [15:50] * didrocks continues writing [15:52] didrocks: not all the deployment work though and gtkme has been around since 2009, I noticed only at the showdown how similar it was. === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [16:17] andyrock: ping [16:19] jaytaoko, pong [16:19] andyrock: I can reproduce some issues here but I fail to see the relation with the geis branch in nux... so I need to ask a few questions [16:20] i fail to see the relation too, but reverting that commit fixs the issue :/ [16:21] andyrock: so, I don't have totem pinned in my launcher. I open the dash and start Totem. Totem starts but then its icon does not show up in the launcher... how? [16:22] andyrock: I understand the relationship to the geis branch but we need to dig deeper [16:23] andyrock: so I wonder, is the icon being added to the launcher? [16:23] jaytaoko, is the icon being added to the launcher? i think not [16:24] because i think we don't receive the bamf signals [16:24] have you already checked? [16:24] andyrock: I mean if the icon is not being added to the launcher then something is not receiving a signal that the application has started [16:25] jaytaoko, yeah... bamf should emit the signal [16:25] andyrock: ok, so the bamf signal is not received... but still the application starts... can you show me the signal that bamf expects? [16:25] hang on [16:27] jaytaoko, view-opened [16:27] LauncherController.cpp [16:27] andyrock: that is the signal that bamf is waiting for? [16:27] grep for view-opened [16:27] no that's is the signal unity is waiting for [16:28] andyrock, jaytaoko hello, I also just started looking at this...there are also some other signals in BamfLauncherIcon.... [16:29] andyrock, im checking the view opened right now [16:29] bschaefer: hello and welcome to the party! [16:29] I see now that the issue is in good hands: 3 devs working on it, we cannot fail ;) [16:29] :) [16:29] jaytaoko, hello! [16:29] we miss Trevinho :( [16:29] andyrock, no the ViewOpen signal is not getting sent [16:29] the BamfLauncherIcon king [16:29] I keep my fingers crossed that you'll somehow be able to figure this out guys! [16:29] but Active Changed [16:29] is [16:29] See you tomorrow [16:30] sil2100, see ya [16:30] see you sil2100 ! [16:30] bschaefer, can you try to revert rev 640 (nux) [16:30] ' [16:30] ? [16:30] andyrock, yup ill give that a try [16:30] andyrock: bschaefer: you are all on Q right? [16:31] jaytaoko, no on P [16:31] yup! [16:31] I just upgrade last night.... [16:31] andyrock: on P? and you have that issue? [16:32] andyrock, did you compile libgeis your self? [16:32] andyrock: on P, we deactivate geis in Nux because there is no libgeis on P [16:32] jaytaoko, yeah i have unity trunk + nux trunk [16:32] bschaefer, JanC yep [16:32] JanC, sorry [16:32] andyrock, haha I almost did that! [16:32] i built libgeis [16:33] andyrock: ok [16:33] dam autogen [16:33] andyrock: ok, it is still interesting to know that it happens on P with your setting [16:34] i can confirm that i don't get the view-opened signal [16:34] andyrock, with nux rev 640? [16:35] bschaefer, i've nux trunk now so yes i've rev640 too :) [16:35] andyrock, :), well if it fails at 640 ill drop that and drop the geis support in unity and see if thats the problem [16:36] as I haven't updated bamf since the problem started so I don't think it is a problem in Bamf [16:36] doing bzr revert -r 639 [16:36] i cannot reproduce these issues :) [16:36] awesome! [16:36] soo geis is the problem or the changes that came with geis in nux hmm [16:37] andyrock: understood [16:37] bschaefer, but rev640 is huge and it's not so easy to understand the relationship [16:37] jaytaoko, we should try to see if bamf emit that signal [16:37] andyrock: bschaefer: I am tracing back view_opened_signal_... [16:38] andyrock, yeeah, well Ill start trying to split up the changes and slowly add them until it fails [16:39] bschaefer, good luck :P [16:39] * bschaefer hasn't looked at the diff yet... [16:39] bschaefer, make a picture to your face when you see the diff :) [16:40] andyrock, haha...well I already made it when I did a bzr revert from 640 -> 639... [16:41] andyrock: bamf will match view-opened with Impl::OnViewOpened. is that right? [16:41] jaytaoko, yep [16:42] andyrock: who emits "view-opened" signal? [16:42] bamf [16:42] o my.... [16:42] that is a large diff [16:43] jaytaoko, i'm checking if that signal is emitted ;) [16:43] andyrock: ok, i am checking as well... [16:48] andyrock: I opened the dash and clicked on Totem... The OnViewOpened signal is not emitted. I instrumented the code source to check that it prints something if it is emitted... [16:49] andyrock: and so totem does not show up in the launcher [16:50] yep i can confirm [16:52] i can also [16:52] hmm im missing 'libutouch-geis' ... that is annoying [16:52] when Im trying to compile unity before the geis update, must be something on P not on Q [16:53] bschaefer, you need libgeis, not libutouch-geis. [16:53] dandrader, yes, for after the geis update [16:54] dandrader, I was trying to revert back before the libgeis change (which is on Q) [16:54] sounds like real fun issue [16:55] starving of mainloop, or some worker thread? [16:55] which would sound reasonable, cause when i switch workspaces, the bamf events are "replayed" rapidly [16:55] andyrock: ok, we know that the dash is getting the mouse click signal when we click on the totem icon in the dash [16:56] andyrock: I am checking ResultViewGrid::MouseClick [16:56] mhr3, yeah, the Bamf signals for active are still going off, so Bamf is doing something [16:57] mhr3: very interesting observation. I can confirm. [16:58] mhr3: when I switch to another desktop and come back then the icon shows up in the launcher [16:58] andyrock: can you check this ^ [16:58] confirmed [16:58] now to *just* figure out who causes the starvation :) [17:00] mhr3: andyrock: ok that is interesting [17:02] so it'll be either a GSource with high priority or it could also be a worker thread blocked by some mutex that gets unlocked from time to time [17:02] mhr3, are you talking about starvation of an event? I thought they used queues! [17:02] or at lease some way to prevent that of events in a main loop... [17:02] jaytaoko, mhr3, bschaefer if (IsEmbeddedWindow()) [17:02] geis_adapter_->CreateGSource(nullptr); [17:03] i'm sure the geis would know :) [17:03] commented that line seems to fix the issue [17:03] geis people* [17:03] heh, nice andyrock [17:03] andyrock: what line is this? [17:03] MainGlibLoop.cpp [17:03] andyrock, awesome! As soon as I get back from my trash system atm haha [17:03] ill confirm that as well :) [17:04] line 270 [17:04] andyrock: I see it... [17:05] andyrock: ok in this case we IsEmbeddedWindow is true [17:05] andyrock: because we are running Nux inside Compiz [17:05] yeah i know [17:06] andyrock, jaytaoko confirmed that fixed the problem... [17:06] dandrader: can you have a look at WindowThread::RunGlibLoop in Nux/MainLoopGlib.cpp [17:07] bschaefer: thanks! [17:07] andyrock, nice find :) [17:07] eheh but we not found the real problem :) [17:08] dandrader: around line 270... is there something there? [17:08] andyrock, yeah, but that diff... [17:08] is smaller [17:08] LOL === seb128_ is now known as seb128 [17:14] hmm... [17:18] dandrader: any idea why it could affect? [17:21] maybe that gsource prevent the main context to dispatch the events of other sources [17:21] *prevents [17:21] but I'm not a GSource expert :) [17:26] andyrock, hmm can you uncomment the line and re confirm its broken? [17:26] andyrock, i uncommented that back in and now things are working...(unless I broke my unity/nux build haha) [17:27] i have just uncommented that code [17:27] and i can reproduce the issues [17:27] hmm what did I do...haha... [17:27] thanks! [17:28] well, maybe I could make GeisAdapter share the existing gsource (as the TODO comment says) to see if the problem goes away. unfortunately I still cannot reproduce that issue in my test machine. the dash shows nothing when I run the unity I built myself [17:30] dandrader, oo thats because you need to add a link to the lenses to where you built unity [17:30] I did it, still no luck. [17:30] maybe I did it in the wronge dir.... [17:31] o really? hmm it should be /usr/share/unity/lenses/ [17:31] worst case andyrock or I could build and test your changes [17:32] or jaytaoko :) [17:32] dandrader, i'm going to add a mutex [17:32] in the check function [17:33] dandrader, to reproduce the problem [17:33] just un-pin the gedit launcher icon [17:33] open gedit using the terminal [17:33] see if the gedit icon is on the launcher [17:34] the icon is there [17:34] I have an up to date quantal with trunk versions of unity, compiz and nux [17:35] and a non-functioning dash :) [17:35] andyrock, what check function? [17:37] dandrader, like 270 in MainLoopGlib.cpp (Im guessing) [17:38] geis_source_check [17:38] geis_source_prepare etc [17:38] but it doesn't help :) [17:39] i think the prepare function is wrong [17:40] it should return TRUE if the revents contains IO_IN [17:40] basically the same thing the check func does [17:41] (talking about geis_source_prepare) [17:43] mhr3, http://paste.ubuntu.com/1134651/ [17:43] i think we you should return TRUE if there are pending geis events [17:43] or i'm wrong? [17:44] andyrock, that's what it does, right :) [17:45] dandrader: I can test any solution you have since I can reproduce the problem... [17:45] mhr3, you likely pinpointed the problem. when I wrote the prepare function I just followed what written here http://developer.gnome.org/glib/2.30/glib-The-Main-Event-Loop.html#GSourceFuncs === jaytaoko is now known as jaytaoko|lunch [17:46] mhr3: nice catch! [17:47] I hope we can all confirm this is the issue [17:49] dandrader, i just tested http://paste.ubuntu.com/1134656/ it didn't fix it [17:50] :( [17:51] dandrader, do you read all the data from the source? [17:51] if you don't, it'll be just dispatching the same source over and over [17:51] mhr3, in the dispatch function? [17:51] yes [17:52] GeisAdapter::ProcessGeisEvents() is the one doing it [17:52] mhr3, making _check always returning FALSE fix the problem here [17:53] but it's not a fix :) [17:53] it should be doing so [17:53] mhr3 ^ [17:53] http://paste.ubuntu.com/1134651/ [17:53] dandrader, perhaps there's a race where it doesn't? === mfisch` is now known as mfisch === mfisch is now known as Guest16307 === Guest16307 is now known as mfisch === dandrader is now known as dandrader|lunch [18:15] tedg, hi, are there any gtk3 python bindings for libindicate-gtk (the set_property_icon method)? [18:34] dandrader|lunch, from what i see, geis_next_event is always returning EMPTY_EVENT, yet the fd is triggered pretty much all the time [18:34] weird === dandrader|lunch is now known as dandrader [18:45] dandrader, in gboolean geis_source_dispatch(GSource *source, GSourceFunc callback, gpointer user_data) [18:46] you don't call the callback... [18:46] ;/ [18:46] why? === jaytaoko|lunch is now known as jaytaoko [18:48] andyrock, if I'm not mistaken it's because I didn't supply any callback [18:48] but let me check [18:49] andyrock: mhr3: anything you want me to try? [18:51] andyrock, GeisAdapter.cpp:138 - g_source_set_callback(source, 0, this, 0); [18:51] mmm ok [18:53] mhr3, in the very beginning there should be a couple of events [18:53] during initialization [18:54] mhr3, at the very least a GEIS_EVENT_INIT_COMPLETE event should come [18:54] dandrader, ok, it probably did, but why is the fd still being triggered afterwards? [18:55] yeah, it shouldn't [18:55] seems like it's watching an X fd [18:55] that's what's being triggered [18:56] geis itself, internally, has an X display opened and thus listens to some x events [18:57] somehow there's a loopback so to say [18:57] anyway, i had eod like 3 hours ago, /me out [18:59] mhr3, ok, thanks for the help [18:59] dandrader: so the geis fd remains "readable", even though there's no event to read? [19:00] I'm out too... [19:00] bye bye === andyrock is now known as andyrock|out [19:00] bye [19:00] cnd, seems so. I couldn't reproduce the issue myself [19:00] hmm [19:01] I'll take a look at the code to see if anything stands out to me [19:02] before i go, 35 was the x event type ;) [19:03] maybe that helps [19:03] maybe not [19:05] ok, thanks [19:19] dandrader: mhr3: X event 35 is a generic event [19:19] XInput 2.x events are the only generic events so far [19:19] thus, it probably is a touch event [19:20] cnd, maybe a timer event? [19:20] sbte, There should be through the gobject-introspection bindings. [19:21] I wonder if the reason I don't get this bug in my test machine is because it has multitouch devices, thus making geis behave and initialize differently... [19:26] nah, I still cannot reproduce it in my other box [19:26] tedg, any idea what the indicate-gtk module is called then? [19:27] from gi.repository import Indicate doesn't work for the set_property_icon method [19:28] sbte, Should be IndicateGtk3 I think. [19:31] tedg, doesn't seem to work [19:31] [21:30:30 ERROR root] Could not find any typelib for IndicateGtk3 [19:33] Hmm, doesn't seem to be in the dev package. kenvandine, do you know why the GIR file for libindicate GTK3 isn't in the -dev package? [19:34]