=== mdeslaur is now known as mdeslaur-afk === DanRabbit_ is now known as DanRabbit [09:48] davidbarth: I'm confused about two memory leak bugs #378193 and #405364 [09:48] Launchpad bug 378193 in Notify OSD "Memory leak in notify-osd (affected: 3, heat: 28)" [High,New] https://launchpad.net/bugs/378193 [09:48] Launchpad bug 405364 in Notify OSD "Memory leak in notify-osd in cairo surface creation - or what is left after fix for 378193 (affected: 4, heat: 22)" [High,Incomplete] https://launchpad.net/bugs/405364 [09:49] I see that the former has a fix committed and merge requested which is pending, however in the second bug I see a merge request approved and am wondering if the approved contains both fixes [09:49] MacSlow: you'll help here too [09:50] klattimer: hi [09:50] :) [09:50] klattimer, looking... [09:50] morning [09:50] uh, i remember MacSlow was hunting down mem leaks [09:51] but then probably one fix was not passing the QA control [09:51] a bit too close to a release and we left it here; MacSlow, remember the details? [09:52] klattimer, davidbarth: the real fix to many (if not all) mem-leak issues of notify-osd is to do the abstract notification-object/class (which is in trunk actually already), but I never had the time to hook it all up [09:53] klattimer, davidbarth: the idea behind it all is to have only two instances of bubbles at any one time (sync and async) and to all the queue-handling etc. on just the abstract notification-class objects [09:54] well, what should be done about these two bugs then? [09:54] I admit that this is more a "feature" than a bug-fix. [09:56] klattimer, I remember that there was a valgrind-hit for GdkPixbuf creation, which I could not track down [09:56] klattimer, but I would have to valgrind it again to refresh my brain on the issue. [09:57] :/ [09:57] people seem to see it most with covers displayed in notifications [09:57] hmm [09:57] well, it seems there's a bit of an issue with this then [09:58] two high priority bugs exist, which are from an older generation, and a proper fix is on the way [09:58] which will in some part include a re-write thus making the current debugging information invalid [09:59] MacSlow: does that sound accurate to you? [10:00] klattimer, the GdkPixbuf related leak is still a leak needed to fix... but switching to the abstract notification-object would considerably lessen the leakage. [10:00] MacSlow: and where is the abstract notification-object on your task list? [10:02] hmm, this is where i would trace the line: no structural changes to n-osd this cycle [10:02] if there are still a leak or two and they require a structural change, let's document that and switch to something else [10:03] klattimer, that class is implemented (wiht unit-tests even)... [10:03] people are not really impacted by those leaks, so it's better to do something that makes their work easier than invest in something that has no user benefit [10:03] klattimer, MacSlow: makes sense? [10:03] i was under the impression that the leaks were serious [10:03] klattimer, but I would valgrind n-osd, with a few track-switches from rhythmbox... [10:03] gb's in some cases [10:03] so is there a leak that can be fixed given the actual code base? [10:04] I believe so [10:04] yeah [10:04] trouble is, which branch [10:04] which branches contain which already patched bits [10:04] klattimer: which bug should i mark whislist/later then? i'll be happy to do so, and just leave open the one where you think progresses can still be made with that code base [10:05] is there a need to merge two branches or not? [10:05] klattimer, nope [10:05] klattimer, use trunk [10:05] davidbarth: I think that I can probably get all the leaks reported here [10:06] MacSlow: then has the branch from https://launchpad.net/bugs/378193 been merged yet? [10:06] Launchpad bug 378193 in Notify OSD "Memory leak in notify-osd (affected: 3, heat: 28)" [High,New] [10:06] klattimer: ok, ping me if you want me to do so bug mgt [10:06] k [10:06] :) [10:07] klattimer, yes [10:07] oh [10:07] k [10:07] trunk it is then [10:19] davidbarth: I think both #378193 and #405364 can be closed and a new bug opened for "test for memory leaks" as a reminder to do a more recent valgrind [10:20] it seems as MacSlow is developing on various other parts right now, tracing memory leaks should wait at least until he's satisfied it's the right time [10:20] MacSlow: does that sound good? [10:21] yup [10:38] MacSlow: have you closed a bunch of high bugs on notify-osd? [10:39] klattimer, not in recent times [10:40] klattimer, only working on unity [10:43] ah no worries i got lost in launchpad [10:51] klattimer: ok === MacSlow is now known as MacSlow|lunch === MacSlow|lunch is now known as MacSlow [13:30] hi klattimer [13:30] hey sup [13:30] jcastro: ? [13:31] keeping busy? [13:31] quite [13:31] seb has some bugs for you. :D [13:31] churning through the notify-osd bugs and sorting them out [13:31] a lot of the work has already been done [13:31] klattimer: since we're guadecing we'd figure we'd err on the side of piling too many on your plate [13:31] oh awesome [13:31] well assign away ;) [13:31] I've been travelling all day so please do a detailed report [13:31] k [13:32] also, can you CC seb128@ubuntu.com on your reports from now on? [13:32] sure [13:32] jawesome [13:32] how you getting on then? [13:32] i got round to adding my pgp key and signing the code of conduct on launchpad too [13:33] rock [13:33] it's going well mostly been trawling through code seeing if patches have been committed yet [13:33] seeing what the fastest wins are so I can concentrate on the ones which need some hard work later [13:34] oh, I did want to ask you, as I can't seem to join the indicator dev team I was wondering what could be done there as ted is away [13:40] klattimer: you'll need to catch dbarth or mirco or njpatel [13:40] imo they should just add you [13:41] k [13:41] indicator-applet-developers? [13:42] klattimer, ^ [13:54] njpatel: yeah [14:01] hi davidbarth [14:33] Cimi: hi, got my message about the thursday upload window? [14:34] yes [14:34] and replied immediatly [15:11] klattimer: ping, i added you to https://launchpad.net/~indicator-applet-developers [15:12] Cimi: ok, so for the menu layout part, can you work with bratsche on getting the other changes ready [15:12] the patch on dbusmenu should be relatively easy, maybe it can be a style property change [15:13] the one with the variable icon size is a bit more tricky, it requires patching libindicator; which bratsche did a while back [15:13] bratsche: did you find the branch on your system btw? [15:17] davidbarth: cool [15:18] davidbarth: I'll take a look for it. [15:20] btw, does anyone here have nvidia with two monitors? [15:20] Could use some help. [15:31] davidbarth: ok [15:32] I was looking at few things for the theme === MacSlow is now known as MacSlow|afk [16:30] klattimer, hey [16:31] klattimer, not sure how is your todolist right now [16:31] klattimer, there is still an issue on bug #558841 [16:31] Launchpad bug 558841 in indicator-application (Ubuntu Lucid) "bluetooth "devices" menu item not working in bluetooth indicator (affected: 19, heat: 140)" [Low,Triaged] https://launchpad.net/bugs/558841 [16:32] klattimer, if you click on desactivate and then active in the applet menu the "visible" item is not listed === MacSlow|afk is now known as MacSlow [19:18] bratsche, interesting response from mozilla about the linux UI for FF4.0 - http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/5a77e3e5e58deb52# [19:18] well, perhaps not interesting [19:18] but i wonder what they're having difficulty with? [19:24] Weird, I clicked over from there to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=572482 [19:24] Mozilla bug 572482 in Theme "[Linux] UI Refresh" [Enhancement,New] [19:24] Scrolled down some and saw a comment that looked like it was by me. [19:24] And I was like, "Uhh.. I don't remember writing that comment." [19:24] But it's not me. :)