[00:25] :( [00:28] I uninstalled unity and ubuntu desktop and reinstalled and the problem persists. but [00:28] was able to get it to work in recovery mode with low graphics. but every program was crashing. [00:29] kde's window manager works fine though [01:04] DBO you around? [01:04] yeah but a bit grumpy [01:04] whats up? [01:04] hey glad to finally get a hold of you [01:05] I need a way to send information from inside of unity to the user for debug purposes what would be my best bet [01:10] DBO ^^ [01:10] rbnswartz, to the user? [01:10] to me on the outside of unity so I know if a value is set or a function is called. [01:11] I can't really use cout [01:13] rbnswartz, we normally just use printf [01:13] Im not sure what else you really want [01:13] will that output on the screen though [01:13] if so how do I get to the output [01:15] I almost said printf’s a polymorphic function that either returns a string or an IO action that prints stuff based on context, but the i noticed this is not #haskell after all. :-P [01:16] See printf(3). It mentions sprintf which might be what you want. [01:18] okay thanks also one more thing when I compile and install unity is that version the one that is used on boot or do I have to disable and re-enable the plugin from compiz manager [01:22] DBO^^ [01:23] rbnswartz, you should restart compiz after installing a new version [01:24] DBO I restart compiz and then go to the compiz settings and disable then reenable the plugin. Then everything crashes [01:24] yeah you dont have to disable/reenable [01:24] just restarting compiz is enough [01:25] Okay thanks that is what I needed. Thank you for your time and it was great talking to you again. === _LibertyZero is now known as LibertyZero === LibertyZero is now known as _LibertyZero === API is now known as Guest16442 [07:46] good morning [07:56] morning MacSlow [07:56] hey smspillaz [07:56] greetings folks! [08:06] good morning === API is now known as Guest29614 [09:23] kamstrup: hi. i was told to ask you if i had issues with libunity. i'm trying to build it on natty and on configure i get this: "error: failed. Please install the package 'gobject-introspection' in order to compile libunity" -- but i have that package already installed. any ideas ? [09:30] nerochiaro: sorry for the obvious question, but are you 110% sure you have gobject-introspection installed? [09:31] kamstrup: just triple checked now. it is installed [09:31] kamstrup: i can try reinstall it if you want [09:32] nerochiaro: have you tried 'sudo apt-get build-dep libunity'? [09:32] kamstrup: great idea. let me try that [09:33] nerochiaro: if it installs something you're missing please let me know what it was so I can add checks for it [09:33] kamstrup: The following NEW packages will be installed: [09:33] gir1.2-dbusmenu-glib-0.4 [09:33] The following packages will be upgraded: [09:34] kamstrup: but i still get the same failure when i configure [09:34] nerochiaro: is it libunity trunk or a release? [09:34] kamstrup: lp:libunity [09:35] kamstrup: branched it yesterday [09:38] nerochiaro: ok, so when you say "configure" you mean "autogen.sh"? [09:40] kamstrup: i ran it once, then ran only configure after that. and in fact, running autogen.sh again now worked [09:40] kamstrup: sorry for being an idiot ;) [09:40] nerochiaro: no worries :-) [09:40] kamstrup: one more question [09:41] kamstrup: the docs mention a dbus filter that would route all messages from the LauncherEntrys to unity [09:41] kamstrup: how is that setup ? [09:41] dbus rule, sorry [09:41] nerochiaro: not sure what you refer to? [09:43] kamstrup: https://wiki.ubuntu.com/Unity/LauncherAPI << it says at some point Unity will pick up the Update signal by having a DBus match rule catching all signals from com.canonical.Unity.LauncherEntry disregarding its origin. [09:43] i'm not sure what's that about honestly [09:43] nerochiaro: oh, sorry, that's outdated [09:43] nerochiaro: it's already there [09:43] nerochiaro: i'll just update the wiki [09:44] nerochiaro: oh, no, wait [09:44] kamstrup: right, but i'm asking this for unity2d since we likely have to do the same thing, so I needed to understand what's that about a bit more precisely [09:44] nerochiaro: sorry for the confusion [09:44] kamstrup: no problem [09:44] nerochiaro: right, it didn't occur to me that you where looking at this from the unity side, not the client side [09:45] kamstrup: should've said that at the start :) === ubot5` is now known as ubot5 [09:45] nerochiaro: so what we do in unity to pick up the Update signals are just: [09:46] nerochiaro: g_dbus_connection_signal_subscribe (conn, [09:46] + NULL, // sender [09:46] + "com.canonical.Unity.LauncherEntry", [09:46] + NULL, // member [09:46] + NULL, // path [09:46] + NULL, // arg0 [09:47] + G_DBUS_SIGNAL_FLAGS_NONE, [09:47] + on_launcher_entry_signal_received, [09:47] + this, [09:47] + NULL); [09:47] in src/LauncherEntryRemoteController.cpp [09:47] kamstrup: ah, makes sense. i think i can do the same from Qt. thanks [09:48] that will set up a dbus match rule ala: "interface='com.canonical.Unity.LauncherEntry',type='signal'" [09:48] the point is to listen for the signal disregarding the sender [09:49] I also listen for any signal on that interface so we can print some good debugging info if people sends unknown signals on that interface [09:49] and then work by looking at the app_uri in the signal [09:49] if it's Update [09:49] yep [10:30] kamstrup: do you have a debian packaging info for libunity yet ? [10:41] kamstrup: also, i'm trying to build the example from the wiki page, and i get this: [10:41] $ valac --pkg unity --pkg dee-1.0 --pkg gee-1.0 --pkg Dbusmenu-Glib-0.4 testlibunity.vala [10:41] error: Package `Dbusmenu-Glib-0.4' not found in specified Vala API directories or GObject-Introspection GIR directories [10:42] kamstrup: if i comment out the menu parts in the example and remove that failing pkg it works [11:13] nerochiaro: what do you mean by "debian packaging info"? [11:13] didrocks: the debian/ dir [11:13] if the question is "is there a package", the answer is yet [11:13] yes* [11:14] didrocks: ok, where can i find it ? [11:14] nerochiaro: in natty, it's just libunity [11:15] didrocks: ok, maybe i'm missing something, but if i bzr branch lp:libunity and want to build the .deb on my own, how do i do that ? [11:15] is there a packaging branch ? [11:16] nerochiaro: oh, you want to build it on your own? (why btw? the release version is weekly and you should either build locally or using the package, but well…) [11:16] lp:~ubuntu-desktop/libunity/ubuntu [11:17] didrocks: right. because i just build from source and i wanted to install it via the package [11:17] but it's ok, i just did make install [11:17] nerochiaro: do you need something particular in trunk? [11:17] nerochiaro: the thing is that if you build your own package, you won't be able to report bugs via apport (even unrelated one) [11:17] didrocks: i just wanted to run on the latest, since I was told you were changing things quickly this week [11:18] didrocks: working on unity2d [11:18] nerochiaro: yeah, the daily build in the ppa should be what you want [11:19] didrocks: ok, i'll move to that [11:19] nerochiaro: FYI, in libunity, trunk and latest natty package is the same [11:19] ok, so i'm fine even with trunk. just simpler with the package i guess [11:20] didrocks: and also, maybe you know this: in the LauncherEntry part of libunity, why there's a check if unity is actually running before sending the updates ? [11:21] nerochiaro: that's a dee issue AFAIK, but I don't have a deep look on that part yet. I'll get to it next week :) [11:21] didrocks: ok. i guess njpatel knows [11:22] or kamstrup perhaps === MacSlow is now known as MacSlow|lunch [11:37] nerochiaro: because the check is free, and there is no need to spam the bus during startup or other heavy pressure ops [11:41] kamstrup: ok. also did you see the issue i reported about about building the example app from the wiki page ? [11:42] nerochiaro: yeah, the build instructions on the wiki has been updated [11:42] nerochiaro: after didrocks cleaned up the deps for libunity you only need to pass --pkg unity to valac [11:42] kgreat [11:42] kamstrup: great [11:43] should work with the packaged version in natty in fact [12:13] njpatel: considering https://bugs.launchpad.net/libunity/+bug/719780 do you know if quicklists are supported in unity yet? === API is now known as Guest26240 [12:18] kamstrup: it's not [12:18] hmm, where does the package 'unity-misc' live? [12:19] it's needed to compile latest unity trunk [12:19] rodrigo_: I would say ~ubuntu-desktop/libunity-misc/ubuntu [12:19] * didrocks checks [12:19] ah, a new lib [12:19] rodrigo_: no, it's just not migrated yet [12:20] rodrigo_: I'll migrate it today with the new release [12:20] migrate to? [12:20] rodrigo_: https://code.launchpad.net/~unity-team/libunity-misc/packaging [12:20] I'll move it with today's release in ~ubuntu-desktop [12:20] I moved them once after another when we are doing release :) [12:21] ah ok [12:21] which didn't happen for a while in libunity-misc [12:21] ok, the libunity-misc-dev package does it [12:24] no, it doesn't: /opt/extra/src/canonical/unity/atk-component-for-panel/src/PanelTray.h:31:32: fatal error: unity-misc/na-tray.h: No such file or directory [12:24] didrocks, so yeah, it needs an update? [12:24] rodrigo_: yeah, will come with today's release [12:25] ok [12:28] kamstrup, I was certain they were, but as this is the first thing to really use them, maybe not [12:28] kamstrup, internally everything is quicklist, so I thought your and jason's work hooked that up too, maybe it's a few lines of code that are missing there [12:29] libunity-misc trunk says "configure: error: cannot find sources (unity-misc/unity-misc.h) in . or .." [12:30] an older commit suggests this file was removed [12:30] didrocks, ^^ [12:31] om26er: that's because njpatel is evil :) let me check [12:31] om26er, didrocks let me push a fix, sorry :) [12:32] om26er, didrocks done [12:32] njpatel: excellent, thanks :) [12:32] njpatel, aaala === MacSlow|lunch is now known as MacSlow === chaotic_ is now known as chaotic [13:30] om26er: looking GNOME bugs as well? ;) [13:33] didrocks, just subscribed ;) [13:41] Hi all, thanks for the great work you are doing. I wanted to ask a question regarding progressbars on launcher icons... who should I ask? [13:42] "I see that libunity has support to show and hide, and update the progress on the progressbar on the launcher icons. Will it also support enabling/disabling the 'pulse' on the progressbar?" [13:43] alecu: not sure, ask DBO when he's there :) [13:43] didrocks, thanks. [13:53] alecu, I don't think we'll be adding a pulse this release, but I'm not sure. What was your use-case? [13:54] njpatel, disabling the pulse was meant to signal that the connection to the Ubuntu One servers was lost, but that there was still pending files to upload. [13:54] (or download) [13:55] alecu, I thought you were doing that through an emblem [13:55] alecu, we decided against pulse as it would needlessly cause animation [13:55] njpatel, yup, we may do that as an emblem too. [13:55] njpatel, sounds reasonable. [13:55] thanks! [13:55] np :) === chaotic_ is now known as chaotic [14:19] DBO, where are you? === m_conley_away is now known as m_conley [14:39] iainfarrell: what new circle of friends should I use ? [14:52] tedg, got a moment? [14:55] kamstrup: hi. energy for review? https://code.launchpad.net/~kvalo/indicator-network/settings-passphrase-fix/+merge/50161 [14:58] kvalo: is it less than 6k lines? [14:58] ;-) [14:58] kamstrup: it is, this time ;) [14:59] kamstrup: actually I think all pieces are done and from now on it's more about small steps [14:59] cando_, What's up? [15:00] tedg, forget me...i've solved my doubt..:) [15:00] thanks [15:01] kvalo: approved [15:02] kamstrup: thanks [15:33] DBO: bamf compilation fails [15:33] onox, bamf hasn't changed in quite some time [15:33] I suspect the issue is on your end [15:33] yes, njpatel told me I need to patch glib [15:33] http://dpaste.com/426280/ [15:33] you got a patch? [15:36] onox, are you not on ubuntu? [15:36] onox, the patch is only needed to build the GIO module [15:36] you can skip building the GIO module if you want [15:37] bamf will still work with a degraded accuracy [15:37] DBO: I'm on gentoo ^_^ [15:37] how do I disable the gio module? [15:39] tedg, about? [15:39] aruiz, Yup [15:40] tedg, the dbusmenu server should emit the DBUSMENU_SERVER_SIGNAL_ITEM_ACTIVATION signal once an item is clicked right? [15:41] aruiz, No, the menuitem should emit it's signal. That's for signaling back to the client. [15:41] tedg, so, how do I listen for items being called on the client side? [15:42] aruiz, We might be mixing up client and server here :) dbusmenu-server is in LO. [15:42] yeah, understood [15:42] tedg, and the global menubar is client, right? [15:42] Okay, so the server gets the event from dbus and passes it to the menuitem to handle. [15:43] Correct, the unity-panel-service is the client. [15:43] DBO: btw, why are you not twittering anymore? :( [15:43] so I should connect a callback for every menuitem? [15:43] onox, not really no [15:43] aruiz, Yes, so each menu item has an activate signal. [15:43] tedg, gotcha [15:43] onox, I guess you could disable the gio module in the Makefile.am [15:44] I'll rip module \ out of SUBDIRS [15:44] tedg, the "gint id" mislead me to think that you can just connect to the root item or the server [15:46] aruiz, Yeah, it's perhaps a bit over OO'd, but it's nice for things like the GTK parser we have that doesn't know anything about the server really. [15:46] yup [15:46] tedg, okay, let's see if I can get some actions triggered around here [15:49] tedg, it works :-) [15:50] Woot! [15:52] tedg, the callback, not the actual action, sorry for the downer now :P [15:53] I'm not too far from that though [15:54] * tedg cries a little [15:54] ;) [15:54] :) [16:04] rodrigo_, please update your bugs https://launchpad.net/unity/+milestone/3.4.4 [16:05] njpatel, update how? === JanC_ is now known as JanC [16:24] rodrigo_, the statuses [16:24] fix committed/in progress etc [16:24] just so I know what to move to the next milestone, what needs to be done etc etc [16:25] njpatel, ok, so all that is committed is now in today's release, right? [16:25] rodrigo_, yep, it will be, there is still time to merge any branches that haven't landed, though [16:26] ok [17:01] njpatel: word [17:01] desrt, hey hey [17:01] smspillaz, didrocks we have our desrt [17:01] :) [17:01] erm. [17:01] njpatel: excellent \o/ [17:01] hey desrt :) [17:01] could you guys please give him a run-down of the current status on the gdbus bug :) [17:02] your $DBUS_SESSION_BUS_ADDRESS variable isn't set [17:02] or at least that's my guess [17:02] seb128, [17:02] could you guys please give him a run-down of the current status on the gdbus bug :) [17:02] your $DBUS_SESSION_BUS_ADDRESS variable isn't set [17:02] or at least that's my guess [17:03] desrt: yeah, it's not set [17:03] it isn't [17:03] smspillaz was looking at why [17:03] still it shouldn't hang? [17:03] it's trying to spawn a private bus for itself [17:03] right, it shouldnt :) [17:03] which i think is just stupid, frankly [17:03] david only added the functionality for compatibility with libdbus-1 [17:03] why does that dbus-launch call hangs though? [17:04] there are two possible reasons [17:04] 1) dbus-launch isn't daemonising properly [17:04] 2) it is, and sending sigchld but the sigchld is missed by gdbus [17:04] i'd wager 2 if i was forced to guess.. [17:05] you can see for yourself based on if you have a zombie dbus-launch hanging around, i guess [17:05] smspillaz, ^ [17:06] so something is unsetting that envvar in compiz/unity? [17:06] i'll take a quick peek at the code in gdbus to investigate my suspicions about #2 [17:06] guess that makes it a compiz issue really, glib shouldn't hang this way but compiz should hit that code to start [17:06] ya. exactly [17:06] it's our bug to fix [17:06] but the real problem is yours to fix [17:06] shouldn't [17:06] desrt, thanks [17:06] njpatel, right [17:06] desrt: where exactly are we re-setting the session bug id ? [17:06] *bus id [17:06] there isn't any code in compiz that touches dbus [17:07] i have no idea :) [17:07] desrt, thanks [17:07] smspillaz, unity [17:07] touches dbus quite a bit [17:07] oh :/ [17:07] so ... how is this a compiz bug then ? [17:07] njpatel: good touch or bad touch? [17:07] smspillaz, well, gnome-session has this environement set and it starts compiz [17:07] so it really ought to be set [17:07] smspillaz, no one tells me if it happens without the unity plugin, been waiting for that info for weeks as I can't reproduce [17:07] right, I can look into that again [17:07] desrt, always bad, that's just how we roll [17:07] njpatel: the crash happens before the unity plugin is *loaded* though, thats the thing [17:08] naughty DX [17:08] smspillaz, oh, so it is your fault [17:08] but we don't touch dbus [17:08] smspillaz, find the code that calls unset and we're done [17:08] ;) [17:08] we don't touch the env either [17:08] smspillaz, did you do the thing about printing out the env before and after every plugin that you load? [17:09] this is definitely not a gdbus bug... [17:09] we need to narrow this down to a part of compiz or one of the plugins [17:09] njpatel: seb128: desrt: last time I looked into this, I printed the env on main () and DBUS_SESSION_BUS_ADDRESS [17:09] was not there [17:09] but it's in /proc/$(pidof compiz)/environ [17:09] smspillaz, you need to add more places where it prints, as I said, before and after ever plugin that is loaded [17:09] njpatel: I guess I can try that, but the hang happens *before* any plugins other than ccp are loaded (which initailizes gconf) [17:09] smspillaz, then you need a lot of printfs ;) [17:09] hrm [17:10] something's not adding up here that's all [17:10] smspillaz, it's really weird, as said the proc environ say it's set [17:10] I agree [17:10] smspillaz, if nothing else, I want to isolate it either in or away from compiz [17:10] compiz is also started by gnome-session which is has it set and is using dbus for sure [17:10] i think i figured it out [17:10] hm? [17:10] g_spawn_sync() doesn't wait for SIGCHLD to finish up [17:11] instead it waits until its reading from stdout and stderr both hit EOF [17:11] which is a good indication that the child process is dead (because both have been closed from the other end) [17:11] dbus-launch is probably leaking at least stderr to the daemon [17:11] so it never closes, so we never hit EOF [17:11] --> run forever [17:12] it's really a case of differing expectations and non-documentation than a bug that you can point at and say "it's your bug" [17:12] i'll open a bug in glib anyway [17:12] desrt, thanks [17:12] since one way or another g_spawn_sync() should work a particular way or we should not be depending on it working that way from gdbus [17:13] smspillaz, well that's for tha hang part, still compiz should connect to the existent bus so there is an issue in compiz [17:13] seb128: we don't touch dbus at all, thats the thing [17:13] seb128: we only touch dbus implicitly because gconf uses it [17:13] smspillaz, gconf does [17:13] smspillaz, gconf [17:13] sorry [17:14] seb128, got there before me :) [17:14] heh [17:14] my expectation is that if you load gconf and use it, it should just work or error out if it can't connect () rather than just hanging due to some obscure env thing which isn't even made clear in the gconf docs [17:15] smspillaz, why it hangs is a bug that desrt just explained [17:15] yeah, I saw that [17:15] smspillaz, so we've figured out that why it isn't doing that, but it doesn't take anything away from the fact that, even though the env is set, something is screwing it up [17:15] smspillaz, still at the time you start dbus is set and the environment variable as well [17:16] and that something is in or around compiz [17:16] and hence, we need to fix it [17:16] njpatel: but there's no good indication of what that thing might beg [17:16] *be [17:16] njpatel: seriously, what we do is this [17:16] that's what youneed to figure [17:17] start -> load plugins -> init screen -> init plugin screens -> ccp screen -> init backend -> load gconf -> hang! [17:17] smspillaz, at each of those steps print the env and, hopefully, you'll see between each one where it's screwed up [17:17] lamlex: So I'm looking at bug 711916 and it has 14 unmarked likely duplicates and I'm curious about what's next. [17:17] Launchpad bug 711916 in compiz (Ubuntu) "compiz crashed with SIGSEGV in std::_List_node_base::_M_hook()" [Medium,Confirmed] https://launchpad.net/bugs/711916 [17:17] njpatel: you could just set a watchpoing on environ :) [17:18] *point [17:18] smspillaz, whatever, but you get the point :) [17:18] *shrug* I guess we can do that [17:18] *waits for compiz to rebuild* [17:19] but I think I'm going to get some sleep now [17:19] night all === smspillaz is now known as smspillaz|sleepi [17:19] 'night smspillaz|sleepi [17:19] sure, night [17:19] bdmurray: I guess looking at the dupes and decided in they're dupes is next? === smspillaz|sleepi is now known as smspillaz|sleep [17:19] right? [17:19] riiiiight? [17:19] lamlex: sure. more specifically should I open an upstream compiz task or an upstream unity one? [17:20] hm, njpatel how are we doing compiz bugs? [17:21] I would think upstream compiz task is the way but I know that sam has a workflow established [17:21] lamlex, I'm not sure, it's a didrocks/sam thing [17:21] didrocks: ^ [17:22] lamlex: there is no compiz upstream bug because their bug tracker was broken until recently [17:22] they should move to launchpad ;-) [17:22] lamlex: so, on unity related issue, open a compiz packaging page and an unity upstream one [17:22] bdmurray: yeah, already proposed :-) [17:41] tedg, you know how much i love days like today... [17:42] to test libindicator, i can just do rebuilds of the existing indicators right? [17:44] kenvandine, Yup, should work :) [17:44] * kenvandine grumbles about having to do rebuilds of everything to just test one package [17:44] :) [17:44] tedg, which indicators will get releases today? [17:45] kenvandine, Don't have a complete list yet, but several. [17:45] kenvandine, I wouldn't rebuild them in archive yet. [17:45] right [18:18] tedg: ping [18:18] m_conley, Hey [18:19] tedg: hey - I was wondering, do you have a mock version of libindicate to write tests against? [18:19] tedg: I'm trying to find a nice way to unit test my TB indicator extension. [18:19] m_conley, The best is to use the listen-and-print tool. It'll put things on the command line. [18:19] m_conley, It's in the libindicate source [18:20] tedg: awesome - thank you! [18:41] didrocks: really fascinating bug! [18:43] desrt: I gave me joy and cry at 3AM the day before my holidays :) [18:43] for the record, i have no idea what the hell is wrong [18:43] unless there's some bizarre way that dbus is leaking pipes [18:48] http://ostatic.com/blog/fedora-opensuse-give-up-on-unity :/ [18:56] desrt: the thing is that it's pretty reliable [18:56] desrt: if I don't add any delay at start [18:56] so what's the symptom? compiz totally fails to start, or what? [18:57] just had a thought -- is there any way that something like apport could be holding some process open? [18:58] desrt: yeah, compiz totally fail to start and hangs [18:58] hum, I didn't try without apport enabled IIRC [18:59] not apport expert though, I was just thinking it was waiting on some kernel signals [19:00] so when i login i get a normally-functioning compiz... [19:01] i think the problem is that an fd is leaking somehow... [19:09] didrocks: some clear information on how to reproduce this would go a long way... [19:09] root access to a system that's currently in the deadlocked state would also help [19:09] but please install libc debug symbols first :) [19:18] Why doesn't synaptic integrate with globalmenu? [19:20] desrt: well, quite easy, install ubuntu, I can provide you the compiz version without the workaround and log in :) [19:20] ah. i didn't know that a workaround was being used. [19:20] non-workaround version, plz :) [19:21] desrt: yeah, I've reordered the compiz starting order :) [19:21] desrt: sure, not right now because in unity reease and ETOOMANYTHINGS-before-rebase [19:21] okay [19:21] desrt: I think sam should look at #1 why the variable isn't there [19:21] i'll shelf working on the bug until then :p [19:21] desrt: heh :-) [19:22]