[09:59] <thorwil> mat_t: good morning! would you agree to have something similar to an Incoming section in the Ayatana wiki, to then keep all concepts and mockups that go beyond theming out of the Artwork area?
[09:59] <thorwil> this one could be seen as corner case, but i think that's more Ayatana than Artwork: https://wiki.ubuntu.com/Artwork/Incoming/Maverick/daniel_windicators
[10:04] <vish> thorwil: you could move it to > https://wiki.ubuntu.com/Ayatana/Windicator/Concepts and it would get included to https://wiki.ubuntu.com/Ayatana the naivgation at the bottom
[10:05] <vish> thorwil: there is already https://wiki.ubuntu.com/Ayatana/Workspaces and the /Concepts , so kinda makes the main page the place where accepted work is carried out
[10:05] <thorwil> vish: yes, but there should be a long term strategy to where we put pages
[10:06] <vish> thorwil: yup , thats why the Ayatana/Project and the concepts go in Ayatana/Project/Concepts
[10:07] <vish> thorwil: the mailing list already has too many concepts :D  we have to start sorting now else a general /concepts page would be a mess ;p
[10:09] <thorwil> vish: so you're in favor of having topics as first level, with Concepts inside
[10:09] <mat_t> thorwil: hi, sorry, crazy busy atm... makes sense to me, go for it
[10:09] <thorwil> as opposed to Concepts/Topic
[10:10] <vish> thorwil: yup. else the topic[when being worked on] would not be a higher level , or we would endup having to create a new level for those :s
[10:11] <thorwil> vish: ok, bu then we should have some carefully chosen Topics in place. i'll write a proposal and threaten to go ahead with it if nobody stops me :)
[10:15] <vish> thorwil: bah , ayatana no one is gonna listen ;p  you'll eventually get more topics o.0    ..i would just move it to Ayatana/Windicators/Concepts  ..  and people will catch on with the idea :)
[13:15] <ivanka> doctormo: hi
[14:22] <doctormo> hey  ivanka
[14:23] <ivanka> doctormo: all home and safe?
[14:24] <doctormo> yep
[14:24] <ivanka> doctormo: I wanted to follow up on the Free Culture Showcase session and was wondering if we formally attach that project to the deviantart group you have already set up?
[14:24] <doctormo> yourself?
[14:24] <doctormo> Sure what would you like to do?
[14:24] <ivanka> doctormo: home, safe, walked, sore feet, going away for a long weekend - all good!
[14:24] <ivanka> well
[14:25] <ivanka> nothing right this very minute because I need to make sure we have sites for all the different types of data
[14:25] <ivanka> and then I can announce
[14:26] <ivanka> if we are agree in principle that this is ok - I will ping you an email with some suggested text and we can take it from there - that sound ok?
[14:29] <doctormo> ivanka: Sounds like a plan
[14:31] <doctormo> ivanka: At the moment I can make blog entries which are announced to all members, I can't make deviantArt compititions because I believe that requires paying them for the group service. But that shouldn't be required if we have a place to put the artworks and some information to broadcast.
[14:32] <ivanka> doctormo: perfect. I will be in touch next week after my little holiday
[14:32] <doctormo> Have a good time!
[16:05] <seb128> hey kermiac
[16:05] <seb128> tedg, there?
[16:05] <kermiac> hey seb128
[16:05] <tedg> Good morning seb128
[16:05] <seb128> hey tedg
[16:06] <seb128> tedg, kermiac is looking at writting apport hooks
[16:06] <kermiac> hey tedg
[16:06] <seb128> tedg, do you have any useful hint for indicator-applet out of the logs in .cache
[16:06] <seb128> what other infos would be useful to collect?
[16:06] <seb128> having indicator-* versions would be useful too I guess?
[16:07] <tedg> Yeah, I think those are the most useful.
[16:07] <seb128> tedg, do you think it should have a "which indicator has an issue?"
[16:07] <tedg> Are we talking for apport?  If so, I think a wizard to choose which one would be useful.
[16:07] <seb128> and list all the sound, message, etc
[16:07] <seb128> which ones would you list?
[16:07] <tedg> Yeah, also a way to get to the application if that's applicable.
[16:07] <seb128> the system ones, + a choice for an another software?
[16:08] <seb128> I'm not sure we can easily handle the "enter an application name"
[16:08] <tedg> Yup, that's probably the list I'd go for.  Let's see how confused people get :)
[16:08] <seb128> we can bail out and ask to open a bug again the software though
[16:08] <tedg> Well, we can query the list of ones running...
[16:08] <seb128> how?
[16:08] <seb128> kermiac, can you open a bug to track that?
[16:08] <seb128> so we can comment in there
[16:09] <seb128> kermiac, seems we want to collect those .cache logs + have an interactive question "which indicator is having the issue"
[16:09] <seb128> so it would send the bug to the one selected
[16:09] <kermiac> seb128: ok, against indicator-applet, right?
[16:10] <seb128> yes
[16:10] <tedg> seb128, On Dbus if you call "GetApplications" on org.ayatana.indicator.application it will dump them all.
[16:11] <kermiac> seb128: ok, I'll do that first thing tomorrow as it's very late here .I'll ping you with the bug #.
[16:11] <tedg> The first entry is the icon name.  We could probably just show all those.
[16:11] <seb128> thanks
[16:11] <kermiac> np
[16:11] <seb128> tedg, can you drop a comment in the bug when it's opened about this?
[16:11] <tedg> seb128, Yup.
[16:11] <tedg> kermiac, Thanks!
[16:11] <seb128> thanks
[16:11] <seb128> kermiac, thanks
[16:12] <kermiac> ok thanks tedg, I'll ping you with the bug # 
[16:12] <kermiac> np :)
[16:16] <ejat> hi .. just wanna to ask .. will the new ubuntu font release ? 
[16:18] <tedg> ejat, It will release with Maverick -- it's still being developed.
[16:22] <ejat> tedg, owh thanks for the info
[21:56] <desrt> tedg: hey
[21:56] <desrt> tedg: i've seen indicator-applet grow to use ~10GB of ram a few times in the past while
[21:57] <tedg> desrt, Err, that's no good.
[21:57] <desrt> tedg: appears to be related to the sound indicator.  when rhythmbox is running, the applet and sound indicator are each using ~70% CPU and the leaking is happening
[21:57] <desrt> heard anything about this?
[21:57] <tedg> desrt, Just to be curious where did you get 10GB of RAM?
[21:57] <tedg> :)
[21:57] <desrt> from dell
[21:57] <desrt> came with another 2 :)
[21:58] <tedg> No, I've noticed that there seems to be a leak, but nothing like 10GB.  I got to 100MB after a week.
[21:58] <tedg> But, I thought that was fixed with the last dbusmenu change.
[21:59] <desrt> i killed it earlier today when top was saying 10.1g 9.7g for virt/res
[21:59] <tedg> Mines at 20MB and I've been listening to music all day.
[21:59] <desrt> one piece of information that may be important is that i rm /usr/bin/pulseaudio
[22:00] <tedg> Like literally "rm" or "apt-get remove" ?
[22:00] <desrt> well, "mv"
[22:00] <desrt> but rm, effectively
[22:00] <desrt> pulse really really really hates the usb speakers i'm using
[22:00] <tedg> Hmm, I think that indicator sound will try and start it -- but that should be the indicator-sound-service not indicator-applet
[22:01] <tedg> So if that was the issue I don't think that indicator-applet would notice.
[22:01] <desrt> right.  so both of them are using a whole lot of CPU
[22:01] <desrt> and i'm sitting here watching indicator-applet grow
[22:01] <desrt> 446m
[22:01] <desrt> 447
[22:01] <desrt> 449
[22:01] <desrt> (that's virtual size)
[22:01] <desrt> 452
[22:01]  * tedg is looking for a "watching the grass grow" joke but can't find one.
[22:02] <desrt> it's a pretty impressive leak :)
[22:02] <jcastro> it's your day for leaks ted!
[22:02] <desrt> 15574 desrt     20   0  455m  78m  11m R   68  0.7   5:00.52 indicator-apple     3884 desrt     20   0  277m 5380 4204 R   51  0.0 234:38.27 indicator-sound    
[22:02] <tedg> Yeah, I know that ronoc had a patch for Pulse restarting... I'm curious if that's in distro.
[22:04] <desrt> i'm gonna valgrind this sucker
[22:05] <tedg> Hmm, I don't see any unmerged branches hanging out.
[22:06] <desrt> hm.  indicator-applet doesn't like running under valgrind
[22:06] <desrt> but the leak is happening
[22:06]  * desrt waits a bit
[22:07] <tedg> I haven't tried that, but you can run the loader which should be happier.
[22:07] <tedg> apt-get install libindicator-tools
[22:07] <desrt> it's working except that it shows up as a grey block on the panel
[22:07] <desrt> instead of drawing its icons
[22:07] <tedg> $ /usr/lib/libindicator/indicator-loader /usr/lib/indicators/3/libsound.so
[22:08] <desrt> ==16601== LEAK SUMMARY:
[22:08] <desrt> ==16601==    definitely lost: 640 bytes in 7 blocks
[22:08] <desrt> ==16601==    indirectly lost: 368 bytes in 12 blocks
[22:08] <desrt> ==16601==      possibly lost: 128,870,913 bytes in 962,614 blocks
[22:08] <desrt> hmm
[22:08] <desrt> perhaps it is not technically a leak...
[22:08] <tedg> possibly
[22:08] <tedg> :)
[22:08] <desrt> the big leaking happens below dbus_watch_handle
[22:10] <tedg> Hmm, no function by that name...  up one?
[22:10] <desrt> lots of ???
[22:11] <desrt> how am i supposed to be installing the debug version these days?
[22:11] <tedg> Oh, I think you need another repository...  /me looks
[22:11] <desrt> ya. ddebs or something
[22:11] <desrt> i always forget
[22:12] <tedg> https://wiki.ubuntu.com/DebuggingProgramCrash
[22:12] <desrt> there now :)
[22:15] <desrt> hm.  this isn't nearly as annoying as i had remembered
[22:16] <desrt> so the weird thing is that all the symbols on the path of the leak are inside dbus
[22:17] <desrt> hmm
[22:17] <desrt> it looks like lots of DBusMessages are building up
[22:17] <desrt> are you doing any peer-to-peer dbus sockets?
[22:17] <tedg> That seems a little odd.
[22:18] <tedg> None that I know of.  Perhaps in the Pulse side?
[22:18] <desrt> could be
[22:18] <desrt> this is quite obnoxious
[22:18] <desrt> is indicator-applet using pulse directly?
[22:19] <tedg> No, it's not.
[22:19] <desrt> so i guess that's not the case
[22:19] <tedg> Yeah, there's really nothing interesting on the indicator-applet side of things.
[22:19] <desrt> ah
[22:20] <desrt> maybe you're reffing a DBusMessage and not properly unreffing
[22:20] <desrt> for example
[22:20] <desrt> ==19745== 418,304 bytes in 2,752 blocks are possibly lost in loss record 6,314 of 6,328
[22:20] <desrt> ==19745==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
[22:20] <desrt> ==19745==    by 0x96A75FA: dbus_message_new_empty_header (dbus-message.c:966)
[22:20] <desrt> that seriously points to broken refcounting on a DBusMessage somewhere
[22:20] <desrt> oh.  heh
[22:21] <desrt> i just looked at dbus-monitor
[22:21] <desrt> it's going crazy
[22:21] <desrt> signal sender=:1.236 -> dest=(null destination) serial=100160962 path=/org/ayatana/indicator/sound/menu; interface=org.ayatana.dbusmenu; member=ItemPropertyUpdated
[22:21] <tedg> That makes sense, I'm just not sure where'd that be. :-/
[22:21] <desrt> lots of signals flying around
[22:21] <desrt> so there's two bugs i guess
[22:22] <desrt> 1) indicator applet is leaking memory on receiving dbus messages of some kind
[22:22] <desrt> 2) sound indicator is sending messages like crazy
[22:23] <desrt> unfortunately valgrind is not very good about telling you the source of the leak...
[22:23] <desrt> only where the memory in question was allocated
[22:23] <tedg> Yeah, I think that probably the leak would have to be in dbusmenu.  As nothing above there would get dbus messages.
[22:24] <desrt> which one are you using?
[22:24] <desrt> -gtk? -glib?
[22:25] <tedg> -gtk uses -glib.  So if there's a leak of dbus messages it'd probably be in -glib
[22:25] <desrt> is this using dbus-glib?
[22:25] <tedg> Yes
[22:25]  * desrt starts wondering how deep the rabbit hole goes....
[22:26] <desrt> libdbusmenu never directly handles DBusMessage
[22:26] <desrt> wouldn't be surprised if this is a leak in dbus-glib
[22:26] <desrt> anyway.  #2 is definitely your fault
[22:27] <desrt> you should fix that :)
[22:27] <tedg> Heh, for sure.  But, I've got a recreatable test case on a machine that isn't useful to me ;)
[22:27] <desrt> just rename your pulseaudio bin and run rhythmbox :p
[22:27] <desrt> and rename back when done
[22:29] <desrt> i guess you should probably also port dbusmenu to GDBus :)
[22:29] <desrt> all the cool kids are doing it
[22:30] <tedg> Yeah, that's definitely on the TODO list.  No love for dbus-glib here.
[22:30] <desrt> no love anywhere soon, i suspect
[22:32] <tedg> Err, the signal handling is a bit convoluted here... probably can't get an SRU for the GDBus port :)
[22:33] <desrt> i guess glib would need to have an SRU first :p
[22:33] <desrt> seb has mentioned that he intends to semi-officially package new glib for lucid, though
[22:34] <desrt> for gdbus/gsettings reasons
[22:34] <tedg> Yes, that's my understanding.  I'm trying to get him to agree to put gtk+ 3 on the CD.
[22:35] <tedg> He's going to have to agree for N, but it'd be nice for M.
[22:35] <tedg> Otherwise we really need to back port hadess' symbolic icons patch -- which just seems like a waste of energy.