[03:58] smspillaz: Ping, re your -intel driver problems. [04:00] !logs [04:00] Official channel logs can be found at http://irclogs.ubuntu.com/ . LoCo channels are now logged there too; for older LoCo channel logs, see http://logs.ubuntu-eu.org/freenode/ [04:06] RAOF: pong [04:07] smspillaz: Just pinging again to check whether (a) your drivers are still broken, and (b) when you'd like to debug this. Pre alpha-1 would be nice for me :) [04:07] RAOF: let me update and check [04:09] Ta. [04:10] completely unrelated but do you know if there was a recent update that broke GIO? [04:11] I'm getting these weird stack smashing bugs when using g_file_new_for_path [04:18] Hm, no I was not aware of that. [04:19] If we're trading bugs, do you know that compiz crashes when you enable or disable plugins? :) [04:19] * RAOF is currently rebuilding unity to grab debugging symbols for the backtrace. [04:20] RAOF: is this with unityshell enabled? [04:20] Yes. [04:21] RAOF: maybe unityshell is doing something stupid in it's destructor [04:21] Why would unityshell's destructor be called to enable an unrelated plugin? [04:21] if a plugin wants to load before another, the entire plugin stack of plugins that need to load after that plugin need to be popped (So that we can handle WRAP/UNWRAP chains without asploding) [04:22] Oh, wow. Fair enough. [04:22] and unityshell has to load last in order to get the paint order stuff right [04:22] Heh. Such as painting over the cursor when ezoom is active! [04:22] yep [04:22] I'm going to fix that at some point really [04:23] well really, the thing is that unityshell just goes ahead and reset the entire opengl context, paints, and then restores it [04:23] so naturally it wants to go on top of everything [04:23] maybe we should make ezoom load after unityshell [04:23] I suspect you could also poke cnd; he's tasked at evaluating whether the input-redirection are worth pushing to Natty & upstream. [04:23] eh, not at this point [04:24] Of course, he's *also* tasked with making X's input stack work, so he might be a bit busy :) [04:24] it's more of a wishlist thing, but the compiz stuff needs to be written properly [04:24] RAOF: IMO if/when we start looking at wayland in about a year (did you know that kwin is already half ported to it?) we'll get input redirection for free there and it will be much less of a hack [04:25] Do we actually get input redirection for free there? I genuinely don't know; I thought wayland's input handling was one of the more WIP places. [04:26] RAOF: compositor and server are the same thing, so we get all the input events before they got to clients [04:26] Ah. Making that a whole lot easier. [04:26] Right. [04:26] RAOF: indeed. the input redirection patches right now involve a lot of roundtrips with a lot of bandwidth [04:26] Yes, that's why IR was hard! [04:27] RAOF: it's like, for every paint, you need to do a round-trip and send XComposite all of your transformation maps [04:27] it well it was either one round trip per event (eg XeVIE which died very quickly) or one round trip per paint [04:27] Urgh. For every paint? Ow. [04:27] I guess you could cache input maps and only send changed ones [04:28] one round trip per event is still more expensive though [04:28] RAOF: I actually had input redirection working on my old install - it wasn't really *that* expensive [04:29] still more expensive than it would ever be with wayland [04:29] then again, we have round trips for all kinds of stupid things [04:30] like ConfigureRequest! (shudder) [04:30] Yeah. X is totally awesome at network transparency :) [04:31] Anyway, how's your graphics now? [04:31] upgrading [04:31] Ah. [04:31] smspillaz: If ezoom loaded after unityshell, would that solve the problem of the launcher and top panel not being included in the magnified image on screen, i.e you can't zoom in on the panel/launcher? [04:31] this netbook is SLOW [04:31] LOL did someone just say X is totally awesome at something and not mean it sarcastically? [04:32] TheMuso: no it wouldn't [04:32] Oh ok. [04:33] TheMuso: the problem is that we reset the entire ogl context, then paint all of our nux widgets and then restore it [04:33] Lovely. [04:35] chains: No, that was sarcasm. X loves roundtrips, which makes network latency fun! [04:38] the envthe nvidia driver love being fantastically awful ? [04:39] *why does the [04:39] * smspillaz growls [04:40] Its nvidia wanting to make less work for themselves by using the one binary blob for all *nix probably... [04:40] TheMuso: actually it's the same code across windows, osx and linux [04:40] yeeehaw another kernel oops [04:40] Oh wow ok. [04:40] ouch [04:40] and another one [04:41] * smspillaz reboots before everything asplode [04:41] * TheMuso is glad he switched to a card with open drivers for this cycle. [04:41] Although that won't help my laptop for the Dallas sprint. [04:45] There's always nouveau :). It might even have power management support by then. [04:46] But that won't help with 3D... [04:46] Or will it? [04:46] I.e without me having to isntalle xtra bits. [04:46] Well, you'll be able to install libgl1-mesa-dri-experimental, and expect it to work. [04:47] * smspillaz has nouveau running on arch, but uses nvidia on his ubuntu install [04:48] RAOF: Hrm ok that will be interesting. [04:49] RAOF: I assume this means that holding my laptop will also not give me third degree burns? [04:49] You can do it on Maverick, too. The main problem is lack of power management. [04:49] smspillaz: Once natty switches to 2.6.38, yeah. As long as the power-management patches make it into 2.6.38, of course. That seems a reasonable bet, though. [04:53] RAOF: :p [04:55] How much testing has sed aptches had so far? [04:58] Lots of testing on the developers' machine. [04:58] Not so much elsewhere, as far as I can tell. [05:00] Mmm, debugging compiz from the same machine. Yay! [05:02] Right. [05:05] RAOF: did you get that bt? [05:06] Yup. [05:07] can I haz it? [05:07] (ugh this glib bug is a stack smash, NOT FUN) [05:07] bug #682550 [05:07] Launchpad bug 682550 in unity (Ubuntu) "Compiz crashes when enabling or disabling a plugin in ccsm (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/682550 [05:10] oh wtf, this happens when the unityshell plugin is reloaded [05:10] eg in the constructor [05:11] RAOF: there's no line numbers in that bt :( could you build from source or add the -dbgsym packages? [05:11] well, no line numbers where I am interested anyways [05:11] Right, in libunityshell. [05:12] I think that's because cmake isn't actually generating debugging information; that was an unstripped build. [05:12] RAOF: did you build in Debug or Release mode? [05:12] * RAOF throws faeces at the wall of cmake [05:12] Why is there a Debug mode?! [05:13] There is Debug and Release mode? [05:13] it's basically just a string you can specify which automatically passes the right options to gcc [05:13] but you can specify them too manually [05:14] hit 't' in ccmake and you can see all the flags [05:14] I mean, why isn't it always built with debugging symbols? [05:14] it should be [05:14] maybe someone changed the cmake file so that it wasn't *shrug* [05:14] also this gio bug is a massive wtf [05:14] g_file_new_for_path ("/home/unity/foo"); == stack smash [05:15] Funky! [05:16] ARGH wth! [05:16] like anywhere I use that function I get a stack smash [05:16] * smspillaz adds this to the incredibly long list of reasons he hates glib [05:18] * smspillaz hurls a brick at gnome [05:24] WHUT [05:24] WHU [05:24] WHUT [05:24] quit [05:24] someone mark this blocker for A1 [05:25] unless I'm using glib completely incorrectly [05:25] int main (void) [05:25] { GFile *file = g_file_new_for_path ("/home/unity/Downloads"); [05:25] return -1; [05:25] }; [05:25] THAT should not segfault [05:28] Don't you need to do the various glib init dances? [05:29] I might need to [05:29] that's what I was thinking of [05:29] * smspillaz shoots the person whoever's idea it was to try and do OO in C [05:29] this is just _bizzare_ since it worked perfectly beforehand [05:29] I'd suspect that might be trying to call a lock function that hasn't yet been initialised by g_thread_init() ? [05:29] Maybe? [05:30] it was doing something weird [05:30] like a jump to non code location [05:30] That could be it. [05:35] yeah that gets me past that crash at least [05:35] argh I still hate this [05:37] Gar. [05:37] Ok. I pointed you at g_thread_init, could you point me at how to get damn debugging symbols out of cmake? [05:38] RAOF: ccmake, press "t" and in CMAKE_CXX_COMPILER_FLAGS (or whatever it is) make sure that "-g" is in every single one [05:38] Hm. What, if anything, calls CMAKE_STRIP? [05:39] maybe there is something in the cmakelists.txt ? [05:39] it shouldn't do that though [05:40] Hm. Grep comes up silent. [05:41] RAOF: did you try adding "-g" to everything? [05:42] Just trying again. [05:44] smspillaz: What's the problem with g_file_new_for_path? [05:44] It works for me. [05:44] bratsche: it was dying on a jump to non code location, but that was due to us somewhere along the line not calling g_type_init () [05:45] Yeah, you need to call g_type_init() [05:45] ;-) [05:46] * bratsche fears that code which is jumping around the init fu [05:46] ugh [05:46] I wonder who had the idea of writing an object system in C [05:46] now we all have to deal with it [05:48] Well, I think we didn't have good C++ compilers back when the idea first came up. :) [05:48] * smspillaz figured [05:48] And C++ kind of blows anyway. Although so does an object system in C. [05:48] Modern C++ is actually quite new. [05:48] Younger than gobject :) [05:56] And gobject isn't really where the C object system started. Before that was the original GtkObject, which wasn't as advanced but was basically still an OO system in C. [05:56] And I'm sure there were things before that. [05:57] And C++ *still* has ABI problems. [05:57] C++ is a horrible language. I'm amazed that any new project would choose it. [05:58] Except for a Qt-based app. It would choose C++ simply because Qt is a good toolkit, and that makes sense. [05:58] I kind of liked C++ for a couple years when I was using it. But I got over it. :) [05:59] There's a lot of fun stuff :) [06:10] Incidentally, why can't you build unity in the source directory? [06:11] Thats a cmake thing afaik... [06:27] morning === kvalo_ is now known as kvalo [06:32] smspillaz: bug #682550 updated. You're looking for /home/chris/Temp/unity-3.2.0/src/unity.cpp:352 [06:32] Launchpad bug 682550 in unity (Ubuntu) "Compiz crashes when enabling or disabling a plugin in ccsm (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/682550 [06:35] smspillaz: you could try using glibmm properly. [06:38] Heh. libunityshell.so probably doesn't need -Wl,-rpath,::::::::::::::: [06:41] smspillaz: did you remember to call g_type_init()? [06:42] http://paste.debian.net/101001/ <-- this works fine, but if you didn't do g_type_init, it segfaults [06:42] Yeah, that got resolved with a quick g_type_init [07:10] RAOF: ok [07:11] Also, I think I've fixed the unity build to actually generate debug symbols! Woot! [07:25] Unity's not maintained in bzr at all? [07:25] RAOF: lp:unity ? [07:26] That's not the packaging though, is it? [07:26] it's the source [07:26] not sure where the packaging happens [07:27] Well, I want to commit or propose a merge for the packaging, so that other people can just apt-get instal unity-dbgsym rather than futz around with cmake and local builds. [07:27] talk to didrocks about it [07:27] didrocks will be here soon, so I can prod him. [07:27] Heh. Yeah. [07:27] yeah I need to poke him too [07:27] re my transition patch which doesn't crash [07:28] Oh, yeah. One of the python transitions things seems to be backtracing. I should file that :) [07:28] I just fixed it now [07:29] Yay! [07:29] that was the whole g_type_init () fail [07:30] I was only doing testing using ccsm (since ccsm uses lcc) except that I forgot that ccsm will call g_type_init () implicitly (eg gtk.main ()); [07:31] Ah, well. I'm talking about a different bug then. [07:32] it's probably the same one [07:32] This looks like a python traceback [07:32] oh right [07:32] that's probably because ccsm uses some deprecated gtk fun somewhere [07:34] I don't think so. [07:35] what it actually crashes? [07:35] http://pastebin.ca/2005504 [07:35] oh that's didrocks fault [07:35] Hah. [07:36] RAOF: also I hate my life because he got to write his transition module in python and due to gconfengine not having working pythong bindings I had to write it in C++ :( [07:36] Oooh, harsh. [07:36] How does gconfengine not have working python bindings? [07:36] yeah, now 1000 lines longer! [07:37] RAOF: I printed the object info in python and it has like one method [07:37] which tracebacks when you call it [07:37] It's just like *facepalm* [07:37] That certainly *sounds* like not working bindings :) [07:40] whatever. it forced me to learn stuff so at least it was a good use of my time [07:41] like I had to learn GIO because someone decided that they hated boost and moved most of it to universe [07:45] Hm. You skillfully diverted me on to unity bugs. What about your intel graphics? :) [07:47] Yo yo didrocks! [07:47] hey RAOF! [07:48] Good weekend? [07:48] yeah, very resting with a lot of snow here :) you? [07:49] Had a board game day and a fine breakfast with my brother. [07:49] And it's been plesantly mild. [07:49] nice :) [08:11] didrocks: hi [08:11] didrocks: I've fixed that crash that some people were having, just going to mail the updated transition stuff to you now [08:12] smspillaz: hey. oh nice! what was the cause? [08:12] smspillaz, didrocks, kvalo: morning [08:12] sometimes g_type_init wasn't called [08:12] did the metadata was enough for you to debug? [08:12] hum, and glib doesn't like that at all :p [08:12] good morning kamstrup! [08:13] kamstrup: completly fine after a week-end? [08:13] didrocks: more or less... we celebrated my daughters 5 year birthday all weekend, so it's nice with a "break" from it :-) [08:13] kamstrup: good monday morning :) [08:13] didrocks: how about you? [08:14] kamstrup: daddy having hangover from all that sugar? ;) [08:14] kamstrup: very nice week-end there, still a lot of snow (and still snowing :)) [08:14] didrocks: nice! [08:14] hey kvalo, how are you? [08:14] didrocks: here too [08:15] didrocks: I'm good, thanks. a bit chilly though, car showed -25 C! [08:15] kvalo: ok, so having -2 C here is like the tropic for you :) [08:15] didrocks: when can I move? ;) [08:16] kvalo: hehe :-) [08:16] didrocks: how are you? [08:17] kvalo: I'm fine thanks, ready for an "alpha week" :) [08:17] busy week then [08:18] didrocks: Thinking of alpha week, can I point you at bug #682574 - it'd be nice to have debugging symbols available :) [08:18] Launchpad bug 682574 in unity (Ubuntu) "Doesn't build with debugging information (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/682574 [08:18] yeah, but now that unity is the default, it should be smoother ;) [08:18] (There's a debdiff attached there) [08:20] RAOF: hum, RelWithDbgSym != Release then? [08:20] * didrocks still hates cmake :) [08:20] Release == no -g flag. [08:20] ok, then, I think that the fix should be in Compiz CMake rather [08:20] -DCOMPIZ_PLUGIN_INSTALL_TYPE=package [08:20] -> should set the flag to RelWithDbgSym [08:21] (as I guess, we have the same issue with compiz plugins) [08:21] didrocks: wouldn't you want package to have no debug syms? [08:21] We do indeed. [08:21] smspillaz: No, we automatically strip the debug syms out into a separate -dbgsym package [08:21] smspillaz: well, in fact, there are stripped when built [08:21] yeah, but building them in the first place makes no sense [08:22] I suppose [08:22] smspillaz: So normal people get unity, and people (or, say, the apport retracer) get to install the -dbgsym package and have debug symbols. [08:22] depends as -DCOMPIZ_PLUGIN_INSTALL_TYPE=package is for packages and not release, I would have thought it complies with packaging requirements :) [08:22] RAOF: yeah, I've already done the dbgsym discussion last Saturday :) [08:22] Heh. [08:23] RAOF: RelWithDebInfo -> -O2 & -g, right? [08:24] didrocks: Yes. [08:24] That's what it defaults to, at least. [08:24] RAOF: ok, at least, I'll have a look at the compiz CMake files to make the package flags doing that [08:24] as I don't want for every compiz package that we need to do it :) [08:24] didrocks: That's a better idea than mine. I see you're more familiar with CMake :) [08:24] RAOF: *hem*hem*, I was ***forced*** to :) [08:25] * RAOF just wanted to get some debug symbols to throw at smspillaz [08:25] :) [08:26] RAOF: hi Chris [08:27] i just wanted to mention that i've had my first call with victorp last week [08:27] to plan for you guys getting access to the unity test results we want to get from their HW lab [08:27] ie, I did not forget, it's just taking some time [08:34] RAOF: confirmed, patching the cmake file is working wonderfully well :) you'll soon be able to spam sam :) [08:34] 8/c [08:34] hey everybody [08:34] hey MacSlow [08:35] salut didrocks :) [08:35] hey jo [08:35] no [08:42] dbarth: Thanks. We'll also get access to the test-suite itself, to run locally, right? [08:45] RAOF: reporting compiz bugs against unity? :) [08:46] dbarth: can you answer on bug https://bugs.launchpad.net/bugs/682499 ? I'm not quite sure what to tell about "non default" plugins + unity [08:46] Launchpad bug 682499 in unity (Ubuntu) "Unity (and Compiz with it) won't start with Desktop Cube enabled (affected: 1, heat: 6)" [Undecided,New] [08:47] RAOF: yes (sorry was interrupted), that's still the plan [08:48] didrocks: on it [08:48] thanks :) [09:00] didrocks: Oh, um... yes. Whoops :) [09:01] RAOF: can you kindly retarget? :p [09:01] in any case, the apport scripts are the same, no worry :) [09:01] But of courset. [09:04] didrocks: so i've asked for a core, because i'm testing the plugin here, and it doesn't crash [09:04] dbarth: oh, you're a cube user? :) [09:04] even if we don't want to be compatible with all of them, we shouldn't crash [09:04] sure [09:05] nah, just tested when jcastro was mentioning the old panel was still there on the cube [09:05] ok :) [09:12] didrocks: could you make a distro patch to remove the glib plugin from core too? [09:12] didrocks: also patches mailed [09:13] smspillaz: right, doing the same in one upload [09:13] smspillaz: thanks :) [09:13] and then, rebuild every plugins to get debug info [09:13] yeah [09:15] hum, can someone on natty (with latest unity) can just try to launch: [09:15] gsettings get com.canonical.Unity.Launcher favorite-migration [09:16] 3.2.0 [09:17] (if unity 3.2.0-0ubuntu3 is the latest one) [09:17] dbarth, i can reproduce the cube crash, how do i get a core dump? [09:19] didrocks: What are you expecting to get? I get '' [09:19] i.e nothing [09:20] TheMuso, hey [09:20] hey smspillaz [09:23] njpatel: Good morning. [09:25] TheMuso: hey Luke [09:25] TheMuso: good point in your email about the loader [09:25] dbarth: Good morning. [09:26] sounds like we already have what it takes to have atk in compiz [09:26] Well, at least when unity is loaded. [09:26] njpatel: hi [09:26] I'll be out for 2 hours (and then back again afterwards) see you all :) [09:26] njpatel: I'm working on metacity now [09:26] i've chatted a bit with smspillaz this morning btw, to clarify why the switcher was already accessible, while there is no atk/a11y code in compiz [09:26] smspillaz, for the decorations right? [09:26] njpatel: yes [09:27] dbarth, yep [09:27] smspillaz explained that it's because the gtk decorator is helping render the switcher, and that's why orca is seeing it [09:27] I'm going to try and get a theme parser for those properties working today and then plug that into the decorator tomorrow ish [09:27] Right, that was my conclusion as well. [09:28] TheMuso: yeah, bu you get something [09:28] thanks htorque and TheMuso [09:28] htorque: hi, er, you should get one already with apport [09:28] not sure why some doesn't have gsettings CLI installed as it's part of -bin [09:28] htorque: ie, it should be in /var/crash something; let me check [09:29] yes. in /var/crash you should find a file that contains the compiz crash [09:30] htorque: you may have to unpack it, ie use apport-unpack [09:31] TheMuso, re: your email, menus opening inside windows: This is what I meant, Orca can't see the panel at all right now [09:32] dbarth, should it be compiz-gnome.0.crash? [09:33] njpatel: To my mind, this seems like 2 separate pieces, since using the F10 key triggers something inside GTK/Compiz's window manager to open menus. So... I suspect we need to grab that and make that happen in the panel instead. [09:34] * TheMuso knows what he is talking about in his head, but is finding it hard to put it into words. [09:34] dbarth, hm, no that's an old one. i don't get anything in /var/crash when i crash compiz/unity [09:35] TheMuso, we could most likely do that [09:36] Either way, I don't see this as something needing atk work. Everything is accessible given focus, we just need to tie it together at the keyboard level. [09:36] Focus as in, once the menu has focus. [09:38] On another note, I have been looking into identifying menus like indicators via the framework. The issue is essentially that the menu is only identified with an image, and no text, so nothing gets presented as a description for that menu. [09:38] bbs, gonna grab some dinner and will be back. [09:42] dbarth, apport isn't yet enabled by default :-) attached CoreDump to the bug report [09:47] didrocks, about gsettings - should libglib2.0-bin installed by default? IIRC i manually installed it... (and when trying to remove it, only dev packages are marked for removal) [09:49] htorque: I think it is, let me check [09:50] htorque, you can enable apport to catch crashes [09:50] dbarth, whew, i missed that CoreDump has 90+ MB, still want it? [09:50] don't add dump manually to bug [09:50] they can't be retraced [09:50] seb128, thanks, already did :-) [09:50] seb128, so what to do? [09:51] htorque: you're right, it's not, I have to add it as a dep of unity :/ [09:52] or rewrite the transition plugin in C… [09:53] htorque, use apport to send the bug? [09:58] * TheMuso is back [09:58] seb128, there's already one. dbarth asked for a coredump. can i attach a backtrace instead of a 90+MB file? :-) [09:59] you can [09:59] you probably want to retrace it locally to get debug infos though [10:00] seb128, thanks, will do :-) [10:03] TheMuso, (for when your back) through the panel, we are able to get a little more info about the indicators ("soundmenu", "datetime" etc, so we could even store some strings in Unity for translation for specific indicators) [10:04] njpatel: The issue is that the menus themselves are GTK, and thereby handled accessibility wise already, but since we only use images to identify the menus, there is no text for say orca to speak when moving to a new menu. I don't yet know enough about how GTK menus work to know whether we can slip in extra text for atk to present, without that text being visible. [10:06] TheMuso, right, but as Unity knows that the user switched to the next/prev menu, could we announce something to orca? [10:06] TheMuso, it could be done from the same gtk program (unity-panel-service) that actually shows the menus, so the same atk connection (or whatever it's called) [10:07] njpatel: I am not sure, and from what I understand so far, I don't think so. [10:07] Or... [10:08] It doesn't really help that I don't understand how much customization is possible with gtk menus + atk. [10:11] The only menus where this will be a problem is the indicators. This problem needs to be addressed for general GNOME/gnome-panel users, so I will do some digging tomorrow to see what I can discover about atk and menus. [10:11] thanks [10:17] htorque: a backtrace is better, yes ;) [10:19] htorque: the thing is that i'd like to see if it's an easy fix or not; ie avoid crashing at least [10:21] knowing that the rotating cube is probably *not* a plugin we will recommend with unity; the interface was not designed to work with it, the user experience is "different" [10:39] gord: http://pastebin.ubuntu.com/537833/ [10:39] njpatel, your tests are breaking my tests again! [10:39] njpatel, ^^ [10:40] dbarth, can't deal with it now, can fix after fixing what I'm working on [10:41] have I said I hate CMake yet? [10:43] What code is actually responsible for creating the indicator menus and making them visible? [10:44] TheMuso, the code in the indicator-* packages, which install .so files into /usr/lib/indicators/4/ [10:44] njpatel: Yes but they go via dbusmenu right, so what actually does the rendering with gtk et al? [10:45] TheMuso, unity-panel-service (unity/services/) is responsible for loading them [10:45] And in gnome-panel's case, indicator-applet, ok thanks. [10:45] TheMuso, no, those files provide GtkMenus to the panel-service, internally they may use dbusmenu to share a menu between the .so and it's service, but we dont' see that [10:45] TheMuso, yep, indicator-applet in the panels' case [10:46] njpatel: Ok so what I am interested in here is the gtk menu setup itself. [10:46] gnome-panels* [10:46] Ok cool, thats enough to go on. [10:46] TheMuso, that will happen in the .so's, so any indicator-* package [10:46] I *think* I may have a solution for labeling the indicators. [10:46] sweet [10:47] Basically involves getting the atk object associated with the menu widget, and shoving some text into the atk object to identify it to the framework. [10:48] nice [10:48] So far as I understand things anyway, hopefully I am right. [11:09] smspillaz: is it wanted that libcompizconfig include CompizPlugin.cmake and not compizconfig-backend-gconf? [11:10] (well, it's the ccp plugin, but that make libcompizconfig supporting COMPIZ_PLUGIN_INSTALL_TYPE=package with build type, but not compizconfig-backend-gconf) [12:03] dbarth, can you try lp:~unity-team/unity/fix-panel-service-finalize please? [12:03] dbarth, if it works, I'll merge-propose === ckpringle_ is now known as ckpringle [12:19] kamstrup: hi. what's the proper way to disgracefully check if gvariant type isn't as expected? [12:22] kvalo: g_variant_get_type_string() [12:22] kvalo: the question is if the type string is interned so you can do == on it, ,or if you need to g_strcmp0 it [12:23] kamstrup: interned? [12:24] kvalo, you can do a pointer match if it's always a static string [12:24] kvalo: sorry, it's my Java background. Interned == "managed in an internal string pool so variants share the type strings" [12:25] the same string* [12:25] njpatel, kamstrup: ah, got it now. thanks :) [12:26]