=== JanC_ is now known as JanC
[08:56] <htorque> hello everyone! i just had a mutter crash after closing an app after hovering over its menus - any idea against which package i should report it?
[08:56] <htorque> http://paste.ubuntu.com/497552/
[08:58] <didrocks> htorque: hey, there is a bug report about it and i think it's fixed in trunk
[08:59] <didrocks> htorque: look for unity and mutter bugs, you should find it (both package and upstream)
[08:59] <didrocks> you can add your backtrac
[08:59] <didrocks> backtrace*
[09:02] <htorque> didrocks, thanks, i know this bug report but this one doesn't say anything about xerrors
[09:03] <didrocks> htorque: it's more about a race in fact, maybe njpatel who made the fix can know if it's related ^ (apps crashing after hover menus)  http://paste.ubuntu.com/497552/
[09:04] <htorque> oh, that indeed could be, as the system was under load at that time and the menus were a bit laggy
[09:04] <htorque> will try trunk then, thanks
[09:05] <njpatel> htorque, didrocks hey, what's up?
[09:07] <didrocks> htorque: try the trunk and keep us in touch, please :)
[09:24] <htorque> didrocks, njpatel: i found the report in mutter - bug 641561 - but now i'm not sure which package's trunk to try ;-)
[09:24] <ubot5`> Launchpad bug 641561 in mutter (Ubuntu) "mutter crashed with SIGSEGV in g_type_check_instance() (affected: 2, heat: 16)" [Medium,New] https://launchpad.net/bugs/641561
[09:24] <didrocks> htorque: unity
[09:24] <htorque> didrocks, thanks, already compiling
[10:24] <htorque> didrocks, i'm afraid bug 641561 is not fixed in unity trunk
[10:24] <ubot5`> Launchpad bug 641561 in mutter (Ubuntu) "mutter crashed with SIGSEGV in g_type_check_instance() (affected: 2, heat: 16)" [Medium,New] https://launchpad.net/bugs/641561
[10:42] <htorque> <htorque> didrocks, i'm afraid bug 641561 is not fixed in unity trunk
[10:42] <ubot5`> Launchpad bug 641561 in mutter (Ubuntu) "mutter crashed with SIGSEGV in g_type_check_instance() (affected: 2, heat: 16)" [Medium,Confirmed] https://launchpad.net/bugs/641561
[10:44] <didrocks> htorque: ok, njpatel, is it something known or to add to your plate?
[10:45] <njpatel> didrocks, add to plate please
[10:45] <didrocks> njpatel: ok, doing it
[10:52] <Cimi> njpatel: are you in millbank?
[10:53] <njpatel> Cimi, nope
[11:06] <didrocks> htorque: btw, I've set it up for this release's goal. you were asking me against which package opening the bug, I still think that unity + unity upstream is a good choice. We will invalid it if it's not the case
[11:07] <didrocks> htorque: thanks again for your testing and good work :)
=== MacSlow is now known as MacSlow|lunch
[13:32] <doctormo> mpt: ping
[13:40] <klattimer> davidbarth: who do I contact regarding udev/upstart/kernel for bluetooth related issues
=== MacSlow|lunch is now known as MacSlow
[13:43] <fagan> klattimer: try pitti
[13:45] <jcastro> hey klattimer
[13:45] <klattimer> hey jcastro
[13:45] <jcastro> klattimer: chrisccoulson says that he can reproduce the tomboy bug if you're not using the indicator
[13:45] <chrisccoulson> hi :)
[13:45] <jcastro> klattimer: so I guess remove it, log out and back in
[13:45] <jcastro> and it should be broken
[13:45] <klattimer> I've found the source of our bluetooth bug, udev /dev/rfkill broken :/
[13:45] <jcastro> that makes sense now why it's broken in XFCE
[13:46] <klattimer> jcastro: what's that?
[13:46] <chrisccoulson> klattimer, that explains the console messages i see then ;)
[13:46] <klattimer> ok, cool
[13:46] <klattimer> so that's tomboy fixed?
[13:46] <klattimer> or do we just know more about the bug?
[13:47] <chrisccoulson> klattimer, so, consolekit isn't setting the ACL's correctly on /dev/rfkill, it seems
[13:48] <klattimer> yeah
[13:48] <klattimer> I've just filed a udev bug
[13:48] <klattimer> https://bugs.launchpad.net/ubuntu/+source/udev/+bug/644329
[13:48] <ubot5`> Launchpad bug 644329 in udev (Ubuntu) "/dev/rfkill has the wrong permissions (affected: 1, heat: 6)" [Undecided,New]
[13:48] <klattimer> should be an easy fix?
[13:49] <klattimer> jcastro: can you make sure that bug is addressed?
[13:50] <jcastro> looking
[13:50] <chrisccoulson> klattimer, well, it's just adding a new tag "udev-acl" i think. but, i think there's a reason that's only writable by root
[13:50] <chrisccoulson> is the applet trying to use it directly?
[13:51]  * jcastro defers to chrisccoulson 
[13:51] <klattimer> chrisccoulson: the applet opens and reads/writes with it
[13:51] <jcastro> chrisccoulson: I need your help with this one, without seb I am pretty useless
[13:51] <chrisccoulson> hmmm, that seems wrong doesn't it? for network-manager, i think the backend uses /dev/rfkill
[13:52] <chrisccoulson> jcastro - need help with which one?
[13:53] <klattimer> regardless of how network manager does it
[13:53] <klattimer> we need to be able to do it gnome-bluetooth's way right now
[13:54] <chrisccoulson> i've just asked pitti how that's meant to work
[13:54] <jcastro> chrisccoulson: the one you're asking pitti about now. :)
[13:54] <jcastro> klattimer: are you in #ubuntu-desktop?
[13:54] <klattimer> nope
[13:54] <klattimer> amnow
[13:57] <davidbarth> klattimer: hi, udev/upstart i'd say Scott (James Remnant)
[13:58] <klattimer> davidbarth: you're a little late
[13:58] <klattimer> chrisccoulson: is helping out with this one
[13:58] <davidbarth> klattimer: ah awesome ;)
[14:22] <klattimer> kenvandine: I think I've fixed both the bluetooth issues now, the fix for udev is in the works which will do the turn on/off and now I can test again the visible problem should also be fixed when I test and see what broke
[14:22] <klattimer> didrocks: ^^ you might be interested in the above
[14:23] <didrocks> klattimer: oh great! congrats for the hunt :)
[14:23] <didrocks> klattimer: keep us in touch!
[14:24] <kenvandine> klattimer, great
[14:24] <klattimer> kenvandine: just testing now and I'll give you the patch :)
[14:24] <kenvandine> thx
[14:28] <klattimer> kenvandine: can you make sure this gets pushed out https://bugs.launchpad.net/ubuntu/+source/indicator-application/+bug/558841
[14:28] <ubot5`> Launchpad bug 558841 in indicator-application (Ubuntu Lucid) "bluetooth "devices" menu item not working in bluetooth indicator (affected: 21, heat: 127)" [Low,Triaged]
[14:30] <kenvandine> klattimer, ok, how different is that from the last patch i updated?
[14:30] <kenvandine> i'll grab udev from unapproved and build it locally to test
[14:30] <klattimer> not greatly but instead of using gtk_widget_set_sensitive it uses gtk_action which doesn't throw an error
[14:30] <klattimer> also removes some stray prints
[14:31] <didrocks> kenvandine: wait on indicator-application before pushing as we will deal with the API and ABI breakage too
[14:31] <kenvandine> didrocks, ok, good point
[14:31] <kenvandine> didrocks, i'll prepare it though
[14:31] <didrocks> kenvandine: yeah, no change apart from a rebuild, but one is better than 2 ;)
[14:31] <didrocks> thanks kenvandine, klattimer
[14:35] <chrisccoulson> klattimer, jcastro - gnome-bluetooth fix is uploaded now
[14:35] <jcastro> \o/
[14:35] <jcastro> go team!
[14:35] <klattimer> cool, now what about tomboy?
[14:36] <chrisccoulson> heh :-)
[14:36] <chrisccoulson> have you not fixed that one yet? ;)
[14:36] <klattimer> i've looked at it like a dog being shown a magic trick, does that count?
[14:36] <chrisccoulson> lol
[14:39] <klattimer> chrisccoulson: my understanding is, that when tomboy is loaded, and the indicator applet isn't in the panel
[14:39] <klattimer> that's when it stops working right?
[14:39] <chrisccoulson> klattimer, yeah, pretty much. i just did some testing where i did "chmod -x /usr/lib/indicator-application/indicator-application-service"
[14:39] <chrisccoulson> and then killall indicator-application-service
[14:40] <chrisccoulson> so i got the fallbacks
[14:43] <klattimer> so, that implies the menu is being lost either in dbusmenu or in libindicator as libindicator picks the fallback to status menu as the correct thing to do as there's no applet
[14:44] <klattimer> the question is, why would this be specific to tomboy?
[14:44] <klattimer> ah, I've reproduced it
[14:44] <klattimer> :)
[14:45] <chrisccoulson> nice :)
[14:45] <klattimer> we need tedg on this one
[15:16] <klattimer> tedg: can you see any reason that tomboy's menus would show up in the indicator applet but if you remove the indicator applet and tomboy bounces off to the notification area the menus are not visible?
[15:16] <klattimer> the only thing different is that it's coming from mono
[15:17] <klattimer> libdbusmenu mono bindings perhaps, or app indicator mono bindings?
[15:18] <tedg> klattimer, Hmm, no when we move to the notification area we're just using GTK at that point.  No dbusmenu involved.
[15:19] <tedg> klattimer, directhex has a patch for the mono bindings though.
[15:19] <klattimer> really, what does that fix do?
[16:13] <LBo> Is it possible with the python libindicate bindings to start the server in one process and add messages to that server in another process?
[16:15] <Cimi> njpatel: ping
[16:15] <njpatel> Cimi, pong
[16:16] <Cimi> njpatel: we need to get UIF exceptions for compiz, light-themes
[16:16] <njpatel> LBo, i assume you'd need a bridge between the two processes, with only one in charge of actually adding messages to the server, and the other requesting additions over dbus or something
[16:16] <Cimi> njpatel: it's really important
[16:16] <njpatel> Cimi, sure, but not really my thing dude
[16:16] <njpatel> Cimi, dbarth would need to orchastrate
[16:16] <Cimi> I perfectly know
[16:16] <njpatel> orchestrate*
[16:16] <Cimi> but otto forced me to speak with you :P
[16:16] <njpatel> Cimi, do you want him here, I can poke him to log on
[16:17] <njpatel> Cimi, heh
[16:17] <njpatel> chaotic, stop creating more work for me dude!
[16:17] <Cimi> davidbarth: ping
[16:17] <njpatel> :)
[16:17] <Cimi> ahaha
[16:17] <njpatel> ah, of course, he has a different nick here
[16:17] <davidbarth> Cimi: pong
[16:17] <Cimi> njpatel: I'm in pvt dude :P
[16:17] <chaotic> njpatel: sorry man ;)
[16:18] <Cimi> njpatel: In the last two months I have spoken more with otto than with my parents :D
[16:18] <njpatel> chaotic, Oh, that's fine, let my unity releases be finished tomorrow and see how much time I start spending on "otto" bug reporting :)
[16:18] <njpatel> Cimi, heh :)
[16:18] <Cimi> davidbarth: we need to get the UIF exception for the two packages I have sent the mail
[16:18] <chaotic> Cimi: hopefully your parents get back to you a bit sooner ;)
[16:18] <Cimi> chaotic: you should be proud of the preivous sentence :P
[16:18] <Cimi> ahah
[16:18] <LBo> njpatel: No, I want to run the server in one process and add messages to the server in another process
[16:19] <chaotic> :)
[16:19] <njpatel> LBo, sure, but process 1 (in charge of server) can just export a couple of methods on dbus so process 2 can add/remove messages.
[16:19] <chaotic>  
[16:19] <njpatel> LBo, it might be doable with the framework, I'm not 100% sure, tedg would know
[16:19] <LBo> ah, i see
[16:20] <Cimi> davidbarth: it's really important, it also contains a performance boost people were complaining about
[16:20] <LBo> Create my own dbus methods
[16:20] <njpatel> right
[16:20] <davidbarth> Cimi: read https://wiki.ubuntu.com/FreezeExceptionProcess for the moment
[16:22] <LBo> I've been looking at the org.ayatana.indicator.messages bus but I really wouldn't know if it's possible with those methods
[16:22] <Cimi> davidbarth: can I write that mail and then could you send it for me? I'm not subscribed in any of them
[16:24] <LBo> tedg: could you shine some light on this issue?
[16:25] <Cimi> kenvandine: at the same time could you update gtk2-engines-murrine? just after the approval for the exception
[16:26] <kenvandine> Cimi, we can update gtk2-engines-murrine, did you do a release?
[16:27] <kenvandine> we have been looking forward to a release :)
[16:27] <Cimi> damn, true
[16:27] <Cimi> will do once I'lll have the freeze
[16:28] <Cimi> vincent untz was asking that too
[16:38] <Cimi> davidbarth: I subscribe to the mailing list and send the mail, even though I'm not an employee
[16:38] <Cimi> mmm subscription is not required as long they'llapprove the message
[16:42] <davidbarth> Cimi: super, thanks
[17:01] <Cimi> davidbarth: I have sent both emails, you were cc'ed
[17:01] <Cimi> davidbarth: who can I ask to approve my messages to the mailing lists???
[17:03] <davidbarth> Cimi: ping dpm on #ubuntu-desktop for i18n
[17:03] <davidbarth> Cimi: and i don't know who for the other list, robbiew probably
[17:04] <Cimi> the useless list since there's no translation change required :)
[17:04] <davidbarth> well, then it's a no-op, no need to bother them i guess
[17:12] <Cimi> https://lists.ubuntu.com/archives/ubuntu-release/2010-September/000111.html
[17:12] <Cimi> compiz landed
[17:13] <Cimi> https://lists.ubuntu.com/archives/ubuntu-release/2010-September/000112.html
[17:13] <Cimi> both
[17:13] <Cimi> cool :)
[17:17] <Cimi> mpt: hi dude :)
[17:17] <mpt> hi Cimi, I saw you talking smack about Ubuntu Software Center
[17:17] <mpt> We must settle this with a duel
[17:17] <Cimi> yeah
[17:18] <Cimi> if it0s the same issue we have in eclipse
[17:18] <Cimi> the treeview is using text[SELECTED] instead text[ACTIVE]
[17:18] <Cimi> mpt ^^
[17:19] <Cimi> mpt: are you talking about the bug otto has just shown me or my rant in twitter? :)
[17:20] <mpt> Cimi, the latter
[17:20] <mpt> I have no idea what bug Otto has just shown you
[17:20] <Cimi> oh
[17:20] <Cimi> chaotic: show mpt the bug
[17:20] <Cimi> mpt: so you could understand why I was speaking about text :)
[17:21] <chaotic> Cimi: just shown mpt - he says thank you
[17:22] <mpt> Cimi, I've updated bug 635208, thanks
[17:23] <ubot5`> Launchpad bug 635208 in software-center (Ubuntu) "Unfocused selected item in software list is white on light grey (affected: 1, heat: 8)" [Low,Triaged] https://launchpad.net/bugs/635208
[17:24] <Cimi> mpt: for the sidebar, I don't like the fact it's a huge white block by default. maybe having something like nautilus's sidebar proposals could help a bit. but it's my concerns, don't mind ;)
[17:25] <mpt> Cimi, people thought it was even weirder in 1.0 than they do now, but it's gradually filling up.
[17:25] <Cimi> mpt: anyway it's something absolutely not interesting for maverick, let's go back to the bug
[17:25] <Cimi> mpt: yeah definitely, it's much better as it is now
[17:25] <Cimi> mpt: OSS is about continuos evolution
[17:31] <Cimi> mpt: I have subscrivbed myself to that bug, ping me if you need any help
[18:01] <Cimi> mpt: is the color specified by the software-center "theme"?
[18:02] <Cimi> mpt: I've downloaded the source in order to fix it for you
[18:02] <Cimi> mpt: I would like to know which file is responsible of that :)
[18:02] <mpt> Cimi, it's probably in softwarecenter/view/ somewhere
[18:02] <Cimi> ok
[18:03] <Cimi> what's mkit mpt ?
[18:03] <mpt> Cimi, a small collection of widgets written by mmnz
[18:03] <mpt> I think
[18:04]  * mpt -> home
[18:04] <Cimi> ok
[18:04] <Cimi> bye mpt !
[18:04] <mpt> tchau
[19:20] <seif__> bratsche, u there?
[19:20] <seif__> bratsche, how do i detect if the mouse is over the edge of the screen in python
[19:21] <bratsche> seif__: I don't understand what you mean.
[19:21] <seif__> bratsche, lets say i want to do something like docky
[19:21] <seif__> where when i move to the bottom of the screen
[19:21] <seif__> the dock appears
[19:21] <seif__> how do i detect that the mouse is on the edge of the screen
[19:22] <bratsche> I dunno.. I would first try just creating a window that's 1-pixel tall (maybe rgba and fully transparent).
[19:23] <bratsche> That's at least the way I'd try going about it first, it seems most straightforward.
[19:23] <Cimi> seif__: iirc docky simply checks for the cursor position
[19:23] <Cimi> (maybe)
[19:23] <bratsche> That's a bad idea, because you would have the poll the cursor position.
[19:24] <Cimi> so I am wrong
[19:24] <Cimi> :)
[19:24] <seif__> Cimi, i am trying to avoid polling the cursor position
[19:24] <bratsche> I think that's what notify-osd does in order to get the proximity effect working, but in general it's not a good thing to do.
[19:24] <seif__> bratsche, good call I will try that
[19:24] <seif__> bratsche, +1
[19:24] <seif__> so window transpartent and 1 pixel :)
[19:24] <seif__> ok
[19:25] <bratsche> Polling the cursor is a good way to drain your battery.
[19:25] <bratsche> seif__: Cool, good luck!
[19:28] <bratsche> seif__: Or actually, I think you can make the window input-only.
[19:28] <seif__> huh
[19:28] <seif__> bratsche, explain
[19:29] <bratsche> You can make a window input-only, so that it doesn't draw.  Then you don't need to worry about making it rgba and drawing itself transparently.  It would only be used to capture mouse events.
[20:22] <sense> tedg: Could you please take a look at merge review <https://code.launchpad.net/~sense/indicator-application/fix-608219>? (Bug number not related to the fix). It adds the extra API calls of indicator-application to the Python and Mono bindings.
[20:23] <sense> Changes to the packaging are required to make sure that the extra Mono policy file will be installed as well.
[20:24] <tedg> sense, Ah, okay.  I looked this morning... you can't keep making it better so quickly! ;)
[20:25] <sense> tedg: This morning I hadn't added Jo Shields' solution for the assembly dependents to it. :)
[20:31] <sense> Plus: I removed a change to src/app-indicator.c that should not be in there, but slipped into the branch unfortunately.
[21:14] <tedg> sense, You still have a conflict in your merge request.
[21:14] <sense> tedg: Really? What's wrong?
[21:15] <tedg> sense, Policy stuff in Makefile.am
[21:15] <sense> Ah, I see.
[21:15] <sense> I'll look into it!
[21:18] <sense> tedg: Pushing the solution as I'm writing this.
[22:41] <seif__> bratsche, u still there
[22:41] <seif__> how do i make a window input only?
[22:43] <bratsche> seif__: If you're using gtk then you would make a realize method in your class and set the wclass member of your GdkWindowAttr struct to GDK_INPUT_ONLY
[22:43] <seif__> bratsche, awesome
[22:44] <bratsche> Look in gtk and grep for GDK_INPUT_ONLY.. there are several widgets which use it.
[22:44] <bratsche> I don't know how to do it in Python though, so you'll have to translate what I say into that language. :)