[00:01] <desrt> jcastro: hey?
[00:01] <jcastro> yo
[00:01] <desrt> normally you have some line in your invite about [reply to so-and-so with ACK]
[00:02] <jcastro> it's in there.
[00:02] <jcastro> with a deadline of the 16th
[00:02] <desrt> ah.  marianna.
[00:02] <desrt> gotcha.  thanks :)
[00:02] <desrt> do i also discuss rooming with her?
[00:03] <jcastro> yep
[00:03] <desrt> cheers
[00:03] <desrt> very odd.  the new claire is not named claire.
[00:05] <james_w> rickspencer3: that's a thread I don't want to pull at any further tonight, there's more refactoring than I would like.
[00:05] <rickspencer3> ?
[00:05] <rickspencer3> sure
[00:05] <james_w> using another process to replace glib signals
[00:06] <rickspencer3> right
[00:06] <rickspencer3> we'll have to do *something*
[00:06] <james_w> it works for notifications I think, but not for how he is using it to imitate a dict for some of the settings
[00:06] <rickspencer3> but let's call it  a day
[00:06] <james_w> so I would have to restructure that bit as well
[00:06] <rickspencer3> aargh
[00:06] <rickspencer3> I can't repro getting the CPU to pin with Nafail
[00:06] <rickspencer3> 's code now
[00:07] <rickspencer3> though it seems rather resource intensive at time
[00:07] <rickspencer3> s
[00:08] <Nafai> hrm
[00:10] <james_w> http://osdir.com/ml/svn-commits-list/2010-01/msg03809.html
[00:11] <james_w> wow, that may make my approach pretty much impossible anyway
[00:11] <rickspencer3> Nafai, I'm not getting the pegging issue again
[00:12] <james_w> seems dobey was pretty much there with https://code.edge.launchpad.net/~dobey/gwibber/gwibber-keyring-unthreaded/+merge/22704 but I'm not sure it will have worked
[00:12] <Nafai> ok, I'll work on the changes stuff
[00:12] <james_w> rickspencer3: does starting gwibber-service as "./bin/gwibber-service -d -o" give any hint as to what it is doing?
[00:13] <rickspencer3> good question
[00:13] <rickspencer3> I can for sure try
[00:14] <james_w> if it's beam.smp that's pinning it then it's a different issue, but may just be something like we are accessing it more now
[00:15] <rickspencer3> james_w, well, it only pinned once
[00:15] <rickspencer3> I can't reproduce it now
[00:15] <rickspencer3> but, yeah
[00:16] <james_w> if it keeps happening then I would suggest hitting up chad or something to find if it's possible to get a debug log from couch
[00:16] <james_w> but now I must slee
[00:16] <james_w> p
[00:16] <Nafai> good night james_w
[00:16] <james_w> good night
[00:18] <rickspencer3> night james_w
[00:18] <rickspencer3> Nafai, so I think your approach is going to be preferred
[00:18] <Nafai> ok
[00:18] <rickspencer3> changing from threading to processes seems to involved
[00:18] <Nafai> I think so
[00:18] <james_w> yup
[00:19] <Nafai> once I clean this up a bit, should I propose it for merging and let kenvandine look at it in the morning?
[00:19] <rickspencer3> with Nafai's branch, I think we are closer to something we can ship
[00:19] <james_w> we just need to be very careful what is run in the subprocesses that are currently there
[00:19] <rickspencer3> Nafai, yes
[00:19] <Nafai> awesome
[00:19] <rickspencer3> james_w, any help looking at that would be great
[00:19] <rickspencer3> (tomorrow of course)
[00:19] <rickspencer3> ;)
[00:19] <james_w> sure
[00:19] <james_w> link me up and I'll take a look tomorrow
[00:20] <rickspencer3> wow, gwibber is just a resource hog
[00:20] <Nafai> james_w: What's your email and I'll send a link?
[00:20] <Nafai> s/?//
[00:20] <rickspencer3> I wonder if we can sleep it for longer
[00:20] <james_w> Nafai: request a review from me on the merge proposal, that's the easiest way
[00:20] <Nafai> ah, cool
[00:20] <Nafai> learning more about launchpad
[00:20] <james_w> "Request another review" when you have done it, I'm james-w
[00:20] <Nafai> :)
[00:20] <james_w> otherwise I'm in the directory
[00:20] <Nafai> will do
[00:20] <rickspencer3> Nafai, may I dent a link to your branch?
[00:21] <Nafai> sure :)
[00:22] <rickspencer3> Nafai, are you @nafai?
[00:22] <Nafai> travisbhartwell
[00:22] <Nafai> I decided to go different
[00:24] <rickspencer3> ok, my legions of followers will see your branch
[00:24] <rickspencer3> by legions, like 100
[00:24] <rickspencer3> ;)
[00:25] <rickspencer3> Nafai, good job
[00:25] <Nafai> thanks!
[00:25] <rickspencer3> it's an excellent start, and you got it done in the one day time frame
[00:25] <rickspencer3> except we still need to the mlocking, of course
[00:25] <rickspencer3> Nafai, was pitti going to help with the mlock part?
[00:26] <Nafai> yeah, I'll send an email to him when I'm done pointing him to the branch
[00:29] <rickspencer3> break time for me
[00:39] <chrisccoulson> bzr merge-upstream rocks
[00:52] <rickspencer3> Nafai, fwiw, gwibber still running fine for me
[00:52] <Nafai> yay
[00:52] <rickspencer3> I hope the mlock implementation proves tractable
[00:52] <Nafai> taking a break for dinner and will finish up later tonight
[00:53] <rickspencer3> Google is quite mum on the topic
[00:53] <Nafai> yeah, I hope so too
[00:53] <rickspencer3> bye Nafai
[01:04] <chrisccoulson> is anyone else here using bindwood?
[01:15] <LaserJock> rickspencer3: oh my gosh, is it true?! is Nafai our hero?
[01:15] <rickspencer3> not sure yet
[01:16] <rickspencer3> still have to figure out how to mlock the passwords from Python
[01:16] <rickspencer3> and need to test test test
[01:16] <rickspencer3> I think pitti is going to try his hand at the mlocking tomorrow
[01:16] <TheMuso> Is this all to fix the keyring CPU bug?
[01:17] <rickspencer3> TheMuso well ...
[01:17] <rickspencer3> sort of
[01:17] <TheMuso> heh right.
[01:17] <rickspencer3> it's a "key ring bug" per se
[01:17] <TheMuso> ah.
[01:17] <rickspencer3> so much as using the keyring exposes certain incompatibilities between different APIs
[01:18] <TheMuso> Oh lovely.
[01:19] <LaserJock> perhaps if gnome-keyring was forged in the bowels of Mount Doom.....
[01:29] <rickspencer3> LaserJock, I don't think it has to do with gnome-keyring per se
[01:29] <rickspencer3> I think that a lot of apps were kind of lucky that they worked, and gnome-keyring just kind of caused their flaws to cause bugs
[01:29] <LaserJock> I know I know, just trying to insert some humor
[01:29] <rickspencer3> threading and async programming in genreal is just super buggy
[01:29] <rickspencer3> LaserJock, I know
[01:30] <LaserJock> so do you want people to test the branch now or wait a bit?
[01:30] <rickspencer3> I just didn't want the gnome-keyring guys to think we were calling them out
[01:30] <rickspencer3> LaserJock, might as well test Nafai's branch
[01:34] <LaserJock> bah, stupid gwibber build system
[01:35] <rickspencer3> build?
[01:35] <rickspencer3> LaserJock, I just branched, and ran bin/gwibber-service
[01:35] <rickspencer3> then bin/gwibber
[01:36] <rickspencer3> still no cpu pegging after like an hour or so
[01:36] <LaserJock> it won't start here
[01:37] <LaserJock> the INSTALL files said sudo python setup.py install which *should* put it in /usr/local
[01:37] <LaserJock> but of course even though I told them not to do that they still install to /usr by default
[01:38] <LaserJock> *anyway*, I get some dbus-related error and it won't start up
[01:38] <rickspencer3> LaserJock, don't installit
[01:38] <rickspencer3> just run the code
[01:38] <LaserJock> tried that too
[01:38] <LaserJock> but of course now it's a little hard to figure out what's from the .deb and what's not
[01:39] <LaserJock> do I need any magic commands to set up gwibber-related services?
[01:39] <LaserJock> I get:
[01:39] <LaserJock> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1
[01:40] <rickspencer3> deb?
[01:40] <rickspencer3> laser jock, I just branched the code and ran it from the cl
[01:41] <LaserJock> right
[01:41] <LaserJock> but I have the .debs already installed
[01:41] <LaserJock> when I ran the gwibber installer it overwrote that
[01:41] <LaserJock> sometimes you get weirdnesses when you do things like that
[01:42] <LaserJock> ok, after reinstalling the .debs it seems to start
[01:45]  * rickspencer3 steps away for dinner, family time
[01:46] <LaserJock> rickspencer3: hmm, I seemed to just peg it
[01:46] <LaserJock> *to have just
[01:46] <LaserJock> worked the first few times though
[01:52] <rickspencer3> LaserJock, are you 100% confident you are running Nafai's branch?
[01:53] <LaserJock> not 100% so I'm doing it again
[01:53] <LaserJock> I mean, before it was *every* time I did a refresh
[01:53] <LaserJock> this time I closed the gwibber window, opened it again, and then did the refresh
[01:56] <LaserJock> hmm, now I'm just getting the pegged CPU every time
[01:59] <LaserJock> rickspencer3: yeah, it's not working for me, I get the same behavior as the current gwibber
[02:01] <LaserJock> rickspencer3: this is what I get from CLI http://paste.ubuntu.com/410797/
[02:06] <Nafai> Hi
[02:06]  * Nafai looks at LaserJock's paste
[02:07] <Nafai> LaserJock: Did you run bin/gwibber-service before running gwibber?
[02:08] <LaserJock> no
[02:08] <LaserJock> nobody told me that one :-)
[02:09] <Nafai> yeah, that way it will run the new service
[02:09] <Nafai> :)
[02:10] <LaserJock> well that seems to work a bit better
[02:11] <Nafai> :)
[02:18] <rickspencer3> hehe
[02:18] <rickspencer3> LaserJock, working now?
[02:25] <rickspencer3> every time my fan turns on, I have to check gwibber
[02:27] <TheMuso> heh
[02:34] <LaserJock> rickspencer3: looking good, I even added a new account
[02:34] <rickspencer3> nice
[02:34] <rickspencer3> LaserJock, so it pegged with the old service, and not the new one?
[02:34] <rickspencer3> that's great so far
[02:36] <Nafai> anyone know how to restart a dbus service from another process?
[02:37] <RAOF> If the dbus service provides a .service file in the appropriate place, just try to call one of the methods.
[02:37] <chrisccoulson> Nafai - not sure. i know how to start a service, but i'm not sure if you can restart one
[02:38]  * Nafai nods
[02:38] <chrisccoulson> you actually want to restart an already running service?
[02:38] <Nafai> well, I'm trying to figure out the best way to handle this -- the changes I've made to gwibber-service load the passwords from gnome-keyring when gwibber-service starts up
[02:39] <Nafai> so a solution to handle password changes would be to restart the service
[02:39] <walters> Nafai: call StartServiceByName on org.freedesktop.DBus
[02:39] <chrisccoulson> walters - does that restart an already running service though?
[02:39] <Nafai> walters: so if it is already running, that will do it?
[02:40] <walters> chrisccoulson: no
[02:40] <chrisccoulson> Nafai - you would probably need to add a Restart() method to gwibber-service
[02:40]  * walters should have read from the bottom up rather than top down
[02:40] <chrisccoulson> heh ;)
[02:41]  * Nafai nods
[02:52] <jcastro> hyperair: hi
[02:52] <jcastro> hyperair: the b-c-e app indicator patch is working great!
[02:52] <jcastro> the icon is wrong though, is that just me or a known bug?
[02:56] <LaserJock> rickspencer3, Nafai: yeah, gwibber is running better than it has in weeks for sure
[02:56] <Nafai> sweet
[02:59] <rickspencer3> man, when gwibber is doing it's work, it works *hard*
[03:02] <LaserJock> I tried closing just gwibber (not -service) and restarting and refreshing as that was causing problems
[03:02] <LaserJock> all good now
[03:02] <LaserJock> rickspencer3: gwibber is the biggest CPU user on my machine, and the biggest single RAM user
[03:02] <LaserJock> it's a pretty heavy app
[03:02] <rickspencer3> *sigh*
[03:03] <Nafai> I hope we can optimize it for Maverick
[03:03] <LaserJock> I've become wary that any desktop client of webapps are hopelessly bad performing
[03:04] <LaserJock> getting the data takes a whole lot of effort, along with auth, sync, etc.
[04:00] <rickspencer3> Nafai, hey
[04:00] <Nafai> HI rickspencer3
[04:00] <rickspencer3> so I have both my twitter and my identica passwords in the keyring now
[04:01] <rickspencer3> and I've been running gwibber for like an hour
[04:01] <rickspencer3> and it
[04:01] <rickspencer3> s not pegged yet
[04:01] <Nafai> yay
[04:01] <rickspencer3> though in 10.10, we really have to put it on a diet
[04:01] <rickspencer3> I mean, it's going to kill your netbook battery
[04:01] <Nafai> I haven't figured out the best way to handle changes to passwords, but I think kenvandine will be able to figure out that part easily
[04:01] <Nafai> I'm going to put some ideas in the merge request
[04:02] <rickspencer3> Nafai, just stop and start the service seems like a reasonable back up plan
[04:02] <rickspencer3> this will only happen in the unusual cases when you change or set your password
[04:02] <Nafai> yeah
[04:02] <Nafai> or add an account
[04:03] <rickspencer3> yeah
[04:03] <rickspencer3> hmm
[04:03] <rickspencer3> that code must be in there, I guess
[04:03] <rickspencer3> anyway, I gotsa run
[04:03] <rickspencer3> c'ya tomorrow
[04:04] <Nafai> later
[04:24] <kenvandine> Nafai, got a fix?
[04:25] <Nafai> Think so!
[04:25] <Nafai> just sent a merge request
[04:27] <kenvandine> woot
[04:27] <kenvandine> lp:~nafai/gwibber/gnomekeyring-fix ?
[04:27] <Nafai> yup
[04:28] <Nafai> I listed an explanation and some todos on the merge request comments
[04:29] <kenvandine> cool, thanks man!
[04:29] <Nafai> np
[04:30] <Nafai> Have fun with the tigers?  Lose any kids?  (re: your tweet)
[04:30] <Nafai> :)
[04:32] <Nafai> well, I better get ready for bed.  I'll see y'all in the morning
[04:49] <kenvandine> hehe... no left with all 3 :)
[07:37] <pitti> Good morning
[07:38] <pitti> Nafai: great work, you figured it out?
[08:23] <baptistemm> heya pitti
[08:28] <seb128> hey there
[08:29] <didrocks> good morning seb128
[08:29] <seb128> lut didrocks
[08:29] <didrocks> hey pitti
[08:29] <seb128> ca va ?
[08:29] <didrocks> ça va, bien dormi :) et toi?
[08:29] <seb128> un peu fatigué mais sinon ca va
[08:30] <didrocks> couché tard?
[08:30] <seb128> oui, 3h
[08:30] <mvo> didrocks: hey, good morning! I see there is a compiz -ubuntu14 in bzr, is that uploaded and in the queue? or accidently not set to UNRELEASED?
[08:30] <seb128> didn't get too lucky with evening hacking which frustrated me and I didn't want to go to bed before fixing one of the issues I had on my evening todolist
[08:30] <seb128> which took me a while
[08:31] <seb128> hey mvo, how are you?
[08:31] <pitti> bonjour seb128, didrocks, baptistemm; ca va?
[08:31] <seb128> hey pitti
[08:31] <mvo> hey seb128
[08:31] <seb128> oui, et toi ?
[08:31] <mvo> seb128: good, thanks!
[08:31] <didrocks> mvo: it's in the queue from a week
[08:31] <didrocks> mvo: good morning
[08:31] <mvo> didrocks: heh :) ok
[08:32] <seb128> whoever managed to bring fr back on the i386 iso thanks
[08:32] <didrocks> sweet :)
[08:32] <baptistemm> do you think I should send upstream the patch from bug 529734
[08:32] <baptistemm> I don't know LXDE :)
[08:32] <seb128> baptistemm, yes
[08:33] <seb128> it's a light desktop
[08:33] <seb128> it has been added to fd.o specs etc too I think
[08:33] <baptistemm> it's gonna be a pain to add an entry for every desktop  that exist
[08:34] <didrocks> seb128: I tried on Tuesday evening to fix the preview to show the right button layout order in g-c-c. Didn't managed to get that without copying bunch of code and hackish solution. Furthermore, as there are some discussion upstream about removing most of g-c-c features like theme choice in the appeareance capplet, I told myself we'll see next cycle.
[08:34] <baptistemm> so james_w, if you're have some times to merge my request linked in the bug 529734, I'd appreciate :)
[08:36] <baptistemm> I try to clean all bluetooth related bugs (bluez, bluez-gnome, gnome-bluetooth) but this is really difficult..
[08:36] <seb128> hum
[08:36]  * seb128 does french iso testing
[08:36]  * seb128 looks at pitti now
[08:37] <seb128> "item = gtk.MenuItem('Install Drivers')"
[08:37] <seb128> in gtk/jockey-gtk
[08:37]  * pitti blames ronoc :)
[08:37] <pitti> seb128: fixing in trunk
[08:38] <seb128> pitti, danke
[08:38] <seb128> pitti, bug #542552
[08:38] <seb128> if you need a bug reference
[08:38] <pitti> perfect, thanks
[08:42] <seb128> seems redhat has crash bug reporting now
[08:42] <pitti> seb128: yes, with ABRT
[08:42] <seb128> but not dup detection with it...
[08:42] <seb128> https://bugzilla.redhat.com/buglist.cgi?component=gvfs&query_format=advanced&order=bug_id&query_based_on=
[08:42] <seb128> look at their bug list
[08:42]  * seb128 hugs pitti for apport and retracers
[08:42] <pitti> they rewrote ABRT from scratch instead of using Apport.. :-(
[08:43] <seb128> they pay for it now
[08:44] <seb128> hey MacSlow, njpatel
[08:44] <bryceh> pitti, seb128, oh you're kidding.
[08:44] <bryceh> *sigh*
[08:44] <MacSlow> hey seb128, njpatel, njpatel
[08:44] <pitti> hey bryceh
[08:44] <pitti> guten Morgen MacSlow
[08:44] <MacSlow> bryceh,
[08:44] <MacSlow> hi pitti
[08:44] <pitti> bryceh: what about? ABRT?
[08:46] <njpatel> seb128, MacSlow hey guys
[08:46] <bryceh> pitti, yeah
[08:46] <bryceh> heya MacSlow
[08:46] <njpatel> bryceh, hey
[08:46] <bryceh> hey njpatel
[08:47] <njpatel> bryceh, found a mail from you from a couple of weeks back, it got filtered incorrectly hence no reply, sorry :)
[08:47] <njpatel> bryceh, basic answer to the mail is: I'm still on square one, and nearing defeat ;-)
[08:48]  * MacSlow wonders why the mouse won't move the cursor on the screen
[08:55] <bryceh> pitti, they definitely knew of apport - https://fedorahosted.org/abrt/wiki/AbrtOthers
[08:55] <bryceh> pitti, so why didn't they just contribute the needed improvements/changes to apport?
[08:57] <bryceh> njpatel, aha, yeah I was afraid of that
[08:57] <bryceh> njpatel, yeah seems wayland is a tough nut to crack.  Glad it's not just me having troubles.
[08:58] <bryceh> seb128, http://fedoraproject.org/wiki/Talk:Features/ABRT heh
[08:59] <seb128> bryceh, I think they just don't want to use somebody we did, they would need to admit to do useful things
[09:00] <seb128> somebody -> something
[09:00]  * seb128 not awake yet, coffee!
[09:01] <bryceh> seb128, I think you may be right
[09:01] <seb128> to do -> we do
[09:01] <seb128> I should really start reading what I type
[09:02] <bryceh> seb128, guess we have something to point to now next time they level accusations
[09:02] <seb128> they do what they want but it's a shame for them
[09:03] <seb128> looking through their bugzilla they are the ones who get the troubles
[09:06] <bryceh> seb128, I'm sure Jef will spin it as a pro for fedora to have so many
[09:09] <RAOF> My lord, that's a lot of [abrt] bugs.
[09:14] <seb128> RAOF, it is
[09:14] <seb128> RAOF, hey btw, did you have a good day?
[09:15] <RAOF> Yeah, a fine day.
[09:15] <RAOF> X bugs are less fun than hacking on C# code, though :)
[09:15] <seb128> lol
[09:17] <pitti> bryceh: I heard rumours that it's due to our contributor agreement requirement
[09:17] <bryceh> ahh
[09:31] <tjaalton> does upstart have the same contrib agreement req?
[09:31] <pitti> I guess so
[09:40] <seb128> pitti, bug #551712
[09:40] <pitti> seb128: "ERROR: Broken attachment on bug, ignoring" -> hah, at least that part is working now in the retracers :)
[09:40] <seb128> what do you think would be to blame for it?
[09:40] <seb128> pitti, "The reason was that i had in the BIOS an inexistent floppy drive enabled. After disabling it the load takes about 3 seconds, in contrast to the 15~25secs before. "
[09:41] <seb128> pitti, that's the bug summary
[09:41] <seb128> pitti, oh, nice ;-)
[09:41] <pitti> seb128: udisks or gvfs, I think
[09:42] <pitti> but udisks shoudn't block, at most its udev probers (but they are async)
[09:42] <seb128> do you have any hint on what to ask to figure what is doing that?
[09:43] <pitti> seb128: (will respond in a bit, still busy with other IRC chats)
[09:44] <seb128> pitti, ok
[09:44] <seb128> pitti, no hurry
[09:44] <czajkowski> morning folks
[09:44] <czajkowski> seb128: this morning, latest lot of updates has my software center in the correct location :)
[09:44] <seb128> hey czajkowski
[09:45] <seb128> czajkowski, weird
[09:45] <czajkowski> very
[09:45] <seb128> it's probably some mvo magic there
[09:45] <czajkowski> but nice to see it there :)
[09:46] <pitti> seb128: I'd ask for a bootchart
[09:46] <pitti> seb128: it's the easiest thing where you can see where time is spent on
[09:48] <seb128> pitti, see the bug there is already bootcharts there
[09:48] <pitti> .png.tar.gz?
[09:48] <pitti> oh come on
[09:49] <pitti> why not .png.tar.gz.asc.zip.rar, to make it even more comfortable..
[09:49] <seb128> I can't see anything weird in the charts though
[09:50] <pitti> http://launchpadlibrarian.net/42500603/lance-desktop-lucid-20100330-5.png.tar.gz seems fine to me
[09:50] <pitti> it's a slow VIA CPU, apparently
[09:50] <pitti> but no hang
[09:51] <seb128> well no nautilus, etc either
[09:51] <pitti> hm, right
[09:52] <pitti> seb128: you could compare it with a second login after logigng out, when udisks etc. is already running
[09:52] <seb128> pitti, thanks for the hint
[09:53] <seb128> I've a similar issue on a box I think, I don't have access to this one right now but will check later the bios floppy hint
[09:53] <pitti> seb128: or drop gnome-panel from /etc/init.d/bootchart, so that it goes on for a minute
[09:53] <seb128> if that's the same bug will be easier to debug locally
[09:54] <seb128> hum
[09:54]  * seb128 subscribes pitti to bug #557669
[09:55]  * seb128 stops bothering pitti then, enough IRC ping for a morning there
[09:55] <pitti> heh, NP :)
[09:55] <seb128> I'm wondering if this one is a side effect of you usb eject change
[09:57] <rodrigo_> seb128, do you know if webkit in lucid is getting an upgrade to 1.2.0?
[09:57] <seb128> rodrigo_, I plan to do sync the new one after beta2 yes
[09:58] <seb128> rodrigo_, hey btw ;-)
[09:58] <rodrigo_> seb128, ah, ok
[09:58] <seb128> rodrigo_, do you want the update or you want to make sure we don't update for a reason? ;-)
[09:58] <rodrigo_> seb128, well, there's a crash on the music store that happens in webkit, and I'm just looking at what produces it
[09:59] <seb128> ok
[09:59] <seb128> debian has 1.2 if that can be useful to you
[10:00] <seb128> rodrigo_, http://incoming.debian.org/
[10:00] <seb128> you can find debs there
[10:00] <rodrigo_> oh, ok, will try that
[10:03] <asac> its strange ... have solid color in gnome-terminal but its always transparent :/
[10:04] <seb128> RAOF, bug #557747
[10:04] <seb128> RAOF, could be a gnome-keyring-sharp issue?
[10:05] <seb128> asac, right, known bug, you need to set transparent and the slider on the limit
[10:05] <seb128> asac, solid means = what theme defines right now
[10:06] <asac> ah ok. cool
[10:07] <RAOF> That does look like a gnome-keyring(-sharp) bug.
[10:08] <RAOF> But that looks like the gnome-keyring daemon has died, too, so raising an I/O exception seems to be the right response.
[10:19] <asac> mvo: oh
[10:20] <asac> mvo: apturl doesnt block anymore?
[10:20] <asac> ;)
[10:20] <asac> how can i see if the install succeeded or failed?
[10:20] <didrocks> asac: hey, did you try copying UNE config for -efl? (in other terms, do we need the new package?)
[10:21] <mvo> asac: it should be the same as in karmic, that code has not really changed
[10:21] <mvo> asac: and it works for me(tm)
[10:22] <asac> mvo: i run " apturl apt:mozilla-plugin-gnash?section=universe"
[10:22] <asac> that just returns
[10:22] <asac> and then the dialog pops up
[10:23] <asac> didrocks: UNE config is in which package?
[10:23] <asac> i have to ask someone to test it as i have no install for that here atm
[10:24] <didrocks> asac: as told yesterday, ubuntu-netbook-default-settings, and change all "une" to "une-efl" or whatever you called the .destkop session file
[10:25] <asac> didrocks: you didnt say the package name yesterday ;)
[10:25] <asac> thx
[10:25] <mvo> asac: is universe disabled for you? still no luck reporudcing
[10:25] <asac> mvo: hmm. no its definitly enabled
[10:25] <asac> i have a huge sources.list ;)
[10:26] <asac> maybe something is running that is then used ?
[10:26] <didrocks> 2010-04-08 09:28:51     didrocks        16:56:21> asac: for testing, you can copy every files (but netbook-launcher) containing "une" in the path and replace them with "une-efl" (/etc/xdg-efl mostly and gconf related stuff) from the ubuntu-netbook-default-settings package
[10:26] <asac> like update-manager etc.?
[10:26] <didrocks> it was :)
[10:26] <asac> didrocks: i didnt see what came after "une-efl" ;)
[10:26] <didrocks> argh ;)
[10:33] <mvo> asac: does this patch make a difference? http://paste.ubuntu.com/410939/
[10:34] <asac> checking
[10:35] <asac> mvo: doesnt apply cleanly
[10:35] <asac> also paste.ubuntu.com again needs openid :(
[10:36] <asac> e.g. no wget
[10:51] <cassidy> seb128, https://bugs.launchpad.net/ubuntu/+source/telepathy-mission-control/+bug/557884 could be a cool one to fix in Lucid
[10:54] <seb128> cassidy, ok thanks
[10:55] <mvo> asac: sorry, let debug it after lunch
[11:33] <baptistemm> cassidy, and the frequent telepathy-butterfly crash would be cool to fix :)
[11:33] <baptistemm> I don't know if the fix is available somewhere though
[11:33] <cassidy> I think istaz fixed some
[11:34] <seb128> baptistemm, which one?
[11:34] <baptistemm> hmm, each time I start empathy
[11:34] <seb128> baptistemm, which one?
[11:34] <baptistemm> letme check if I did enter a bug, or I didn't
[11:34] <seb128> baptistemm, can you get a stacktrace?
[11:35] <baptistemm> usually if I see a dup I don't open a bug
[11:35] <seb128> good, what is the bug number?
[11:35] <seb128> and does it crash or is it only apport noise?
[11:36] <baptistemm> hmm, I'll do the check once I'll be at home
[11:36] <seb128> ok
[11:36] <baptistemm> I listed several: when I changed status, and when I start empathy
[11:36] <seb128> we fixed one some days ago
[11:36]  * baptistemm adds that to its todo list
[11:39] <seb128> cassidy, do you think you could roll a new empathy tarball next week?
[11:40] <seb128> cassidy, schedule is tight, I don't think we will get the .1 GNOME tarballs in lucid
[11:41] <cassidy> seb128, sure, just ping me next week
[11:41] <seb128> ok, thanks
[12:04] <asac> mvo: its gone :(
[12:05] <asac> let me check something
[12:17] <hyperair> jcastro: wrong icon?
[12:17] <hyperair> jcastro: screenshot?
[12:17] <hyperair> jcastro: and by the way, it's no patch. it's an official extension upstream =)
[13:02] <seb128> bah, gdmsetup looks ridiculous in french on lucid
[13:02] <seb128> thanks didrocks ;-)
[13:02] <didrocks> seb128: yeah, but I was told "no tooltip", so :)
[13:02] <seb128> who told you that?
[13:03] <seb128> and no 2 lines
[13:03] <seb128> the way the session capplet does?
[13:03] <seb128> one bold with the title
[13:03] <seb128> and one normal under it with the description
[13:03] <seb128> anyway it's late for lucid now
[13:03] <seb128> but it really sucks
[13:04] <didrocks> I agree it sucks…
[13:04]  * seb128 is annoyed, we need to do less changes but take time to do those properly next cycle
[13:05] <seb128> didrocks, I'm still interested to know where the tooltip option was discussed
[13:05] <seb128> I want to talk to whoever said no to it
[13:06] <didrocks> seb128: well, at Portland IIRC, I talked with kwwii about tooltip on combobox
[13:10] <seb128> didrocks, hum, k, I will not make a fuss about it but it's a lame thing to decide in a sprint corridor this way ;-)
[13:10] <seb128> I wonder if we could tweak the french translation in some way for lucid
[13:10] <didrocks> seb128: I agree, we can still find another layout next cycle in any case.
[13:11] <akgraner> Hi anyone know when fonts will be ready?  or what is the better channel to ask in?
[13:11] <seb128> akgraner, what fonts? I've fonts there
[13:11] <seb128> how would you have text displayed otherwise?
[13:11] <akgraner> then new ones
[13:11] <akgraner> that match the new theme
[13:11] <seb128> which new ones?
[13:12] <seb128> I'm not aware of any new font for lucid
[13:12] <akgraner> that match the new light theme
[13:12] <ogra> seb128, i think she means the logo fonts
[13:12] <seb128> k, dunno about that
[13:12] <seb128> check with artwork team I guess
[13:12] <seb128> or kwwii
[13:12] <ogra> akgraner, likely better to ask in some of the artwork channels
[13:12] <akgraner> ahh ok
[13:13] <akgraner> thanks I forget about that channel - sorry :-(
[13:13] <seb128> no worry
[13:13] <seb128> but yeah, artwork guys probably know better about artwork changes
[13:13] <seb128> it seems late in the cycle for a new font now though
[13:14] <ogra> i think there is a ttf for the new logo font but it might not be packaged
[13:28] <lool> Did someone notice odd switches to the console ttys when using alt + Fn keys under xorg?
[13:29] <lool> When I alt + left arrow or alt + F4 for instance I get to a text console; switching back to xorg, the keypress is then processed
[13:35] <seb128> lool, I didn't
[14:19] <seb128> the pkgbinarymangler bug on gnome-games is still there in lucid
[14:19] <seb128> pitti, the bug is assigned to you since karmic, is that still something you want to look at?
[14:19] <seb128> it would spare a fair amount of CD space I guess
[14:20] <pitti> seb128: that somehow fell below the threshold, I'm afraid
[14:21] <seb128> k
[14:21] <seb128> I just notice while looking at current iso and space usage
[14:21] <seb128> noticed
[14:21] <pitti> seb128: do we need more?
[14:21] <seb128> define need
[14:21] <seb128> do we need german translations on the CD? ;-)
[14:22] <seb128> I'm not sure how far we are from getting another language back there
[14:22] <seb128> but I guess it's low importance anyway
[14:22] <seb128> it's just nice to get an extra locale installed if we can
[14:23] <pitti> seb128: "need" -> "we do not have the French language pack yet"
[14:23] <pitti> :)
[14:23] <pitti> seb128: I can look at it for lucid if needs be
[14:24] <seb128> pitti, weeeeell, for a reason I don't want to know we have fr and not de
[14:24] <seb128> which I'm happy with
[14:24] <seb128> I'm just concerned somebody will notice and switch order: p
[14:25] <pitti> seb128: do you know whether bug 536925 is actually an issue for f-spot?
[14:25] <seb128> pitti, hum, that has been fixed no?
[14:26] <pitti> seb128: in g-k-sharp, but the f-spot task is still open
[14:26] <pitti> I'll assign it to RAOF, I guess he'll know best
[14:26] <seb128> I think there is no client side part no, but better to check with RAOF
[14:26] <seb128> ie f-spot should be working now
[14:26] <seb128> since g-k-s has been updated
[14:27] <pitti> ok, asked in the bug
[14:28] <pitti> seb128: yeah, that's what I figured out as well, but I'm not sure
[14:34] <chrisccoulson> Riddell - how is the default search provider defined in konqueror?
[14:35] <Riddell> chrisccoulson: it's set in /usr/share/kubuntu-default-settings/kde4-profile/default/share/config/kuriikwsfilterrc in kubuntu-default-settings
[14:35] <chrisccoulson> Riddell - excellent, thanks
[14:36] <rickspencer3> kenvandine, did you get to try out Nafai's branch?
[14:36] <kenvandine> yup
[14:36] <rickspencer3> and?
[14:36] <kenvandine> talked to him about it last night after you dropped off
[14:36] <kenvandine> i like it
[14:36] <kenvandine> got a couple tweaks already
[14:36] <kenvandine> it's working
[14:36] <rickspencer3> seems pitti has some code to try for mlock'ing
[14:36] <kenvandine> yeah
[14:36] <rickspencer3> I ran it over night, btw
[14:37] <rickspencer3> and worked fine, so far as I could tell
[14:37] <kenvandine> mine too
[14:37] <rickspencer3> so mlock and restarting gwibber-service when someone changes their password, right?
[14:37] <pitti> hey rickspencer3
[14:37] <rickspencer3> hi pitti
[14:37] <kenvandine> rickspencer3, i have another idea there
[14:38] <rickspencer3> kenvandine, sure
[14:38] <kenvandine> Nafai, any special reason you put it in bin/gwibber-service?
[14:38] <kenvandine> couldn't we just put it in the Dispatcher class and add a dbus method to refresh the passwords?
[14:39] <kenvandine> like we could call keyring.get_account_passwords() anytime to refresh our password list, right?
[14:40] <rickspencer3> kenvandine, isn't the key to ensure that get_account_passwords is never called from a thread?
[14:41] <kenvandine> well, not really
[14:41] <kenvandine> it works from a regular thread just fine
[14:41] <kenvandine> the problem was for the pool
[14:42] <kenvandine> my example that just used gobject was fine
[14:42] <kenvandine> even in a thread
[14:42] <rickspencer3> ok
[14:42] <rickspencer3> but still
[14:42] <kenvandine> so i think we can just move that to the dispatcher and add a dbus call to refresh it
[14:42] <kenvandine> so we don't need to restart it
[14:42] <kenvandine> unless someone has a reason not to
[14:42] <kenvandine> note: i haven't tried it yet :)
[14:43] <rickspencer3> just keep it simple
[14:43] <rickspencer3> changing passwords is not something that happens to frequently
[14:44] <kenvandine> agree, i just think this is simpler :)
[14:44] <rickspencer3> fair enough
[14:44] <rickspencer3> "works solidly" is the most important attribute of this part, imo
[14:44] <kenvandine> Nafai, fyi i have pushed a slight change to lp:~ken-vandine/gwibber/keyring_hell_lp_554005
[14:44] <kenvandine> if you are working on stuff, merge that in
[14:44] <rickspencer3> (notice the lack of an "h", because, really, who would I be kidding)
[14:44] <kenvandine> just moved keyring.py to microblog.util
[14:45] <kenvandine> heheh
[14:47] <kenvandine> rickspencer3, actually... i hadn't merged a change into trunk yet before Nafai branched it... Dispatcher doesn't use threading.Thread anymore
[14:47] <kenvandine> it wasn't actually used it
[14:47] <kenvandine> i changed that in the 2.30 branch
[14:47]  * kenvandine merges it
[14:47] <rickspencer3> yes, we noticed that yesterday
[14:47] <rickspencer3> also, MapAsync does not need to be a thread
[14:48] <rickspencer3> all it does is spawn processes anyway
[14:50] <kenvandine> true
[14:50] <kenvandine> i merged that change into lp:~ken-vandine/gwibber/keyring_hell_lp_554005 too
[14:51] <rickspencer3> kewl
[14:51] <rickspencer3> kenvandine, Nafai probably won't be online for another hour
[14:51] <rickspencer3> he starts around 9am his time
[14:51] <kenvandine> oh right... timezone :)
[14:51] <kenvandine> he isn't as nuts as rickspencer3
[14:51] <kenvandine> :-D
[14:51] <rickspencer3> hehe
[15:07] <seb128> slomo, hey
[15:07] <seb128> slomo, do you think you could fix the totem-pl-parser gir binary naming?
[15:10] <slomo> seb128: how should it be called? gir1.0-totem-plparser-1.0?
[15:10] <seb128> gir1.0-totemplparser-1.0
[15:10] <seb128> or I guess yours works too
[15:11] <seb128> the one I gave is the one we use in Ubuntu
[15:11] <seb128> the debian minipolicy about those states it should have the -version though
[15:11] <seb128> which you didn't do on the current one
[15:12] <slomo> ok, changed it
[15:13] <seb128> slomo, thanks!
[15:14] <slomo> looks good to you?
[15:25] <seb128> slomo, I would have prefered using the same naming than ubuntu but I guess it will work
[15:29] <kenvandine> rickspencer3, dropping threading.Thread from Dispatcher and MapAsync reduced the RSS usage by 8M on my x86_64 laptop
[15:29] <rickspencer3> kewl
[15:29] <rickspencer3> kenvandine, that's great
[15:35] <jcastro> hyperair: I get the old icon but in the app indicator area.
[15:36] <jcastro> hyperair: it works great I just think it's using the wrong icon
[16:06] <Nafai> morning
[16:08] <rickspencer3> hi Nafai
[16:08] <rickspencer3> read scroll back, kenvandine proposed a branch of your branch
[16:08]  * Nafai reads
[16:08] <kenvandine> hey Nafai
[16:09] <rickspencer3> kenvandine, your "no threads where not needed" changes are in there?
[16:09] <Nafai> Hey kenvandine
[16:09] <kenvandine> lp:~ken-vandine/gwibber/keyring_hell_lp_554005
[16:09] <kenvandine> merge that back into your branch
[16:10] <kenvandine> and thanks for the awesome work :)
[16:10] <Nafai> ok, just bzr pull from that?
[16:10] <Nafai> np
[16:10] <rickspencer3> kenvandine, Nafai possible to upload this fix today sometime?
[16:10] <kenvandine> rickspencer3, yeah
[16:10] <kenvandine> Nafai, bzr merge lp:~ken-vandine/gwibber/keyring_hell_lp_554005
[16:10] <kenvandine> and bzr ci
[16:10] <Nafai> ah, nice
[16:10] <Nafai> still getting used to the bzr workflow
[16:11] <kenvandine> Nafai, i merged in the changes from the 2.30 branch too, which dropped threading.Thread from Dispatcher
[16:11] <kenvandine> and i dropped it from MapAsync
[16:11] <kenvandine> it reduced RSS usage by 8M on my 64bit box and 3M on my i386 netbook :)
[16:12] <Nafai> nice
[16:22] <kenvandine> rickspencer3, btw i did a little more video editing the other night... pitivi worked perfectly, and easily :)
[16:22] <rickspencer3> nice!
[16:22] <kenvandine> i just wish i didn't have to use dvgrab to capture the video off my camera :/
[16:22] <rickspencer3> pitivi ftw
[16:22] <rickspencer3> kenvandine, well, why not fix that in 10.10?
[16:22] <rickspencer3> ;)
[16:22] <kenvandine> but mini DV seems to be dieing
[16:23] <kenvandine> i went to buy tapes last week at hhgregg, and they don't sell them anymore because they don't sell any DV cameras!
[16:23]  * kenvandine really prefers having original tapes to store long term
[16:24] <LaserJock> shesh
[16:24] <LaserJock> you guys really lowered the RAM usage of gwibber
[16:24] <czajkowski> kenvandine: if you pm me make and modle shop over here still has a selection
[16:24] <kenvandine> LaserJock, yup
[16:24] <kenvandine> best buy still had some, but the price went up a little
[16:24] <czajkowski> kenvandine: and I can pick some up and send them or bring them to UDS for you if you like
[16:24] <kenvandine> it just shows it is dieing off
[16:25] <kenvandine> i don't trust hard drives :)
[16:25] <Nafai> kenvandine: So should I try moving this code to Dispatcher?
[16:25] <kenvandine> our family photos are synced to 3 machines in the house and offsite on a usb drive
[16:25] <kenvandine> Nafai, sure
[16:25] <kenvandine> i was about to do that :)
[16:26] <kenvandine> Nafai, want to do it? or do you have more pressing things?
[16:26] <Nafai> Nope, I can take care of it'
[16:26] <kenvandine> i was going to add a method to Dispatcher for doing it and add Dispatcher.refresh_creds() to bin/gwibber-service
[16:26] <kenvandine> or whatever name you choose
[16:27] <kenvandine> and expose the method via dbus so accounts.py can call it when saving accounts
[16:27] <kenvandine> Nafai, i'll handle making gwibber-accounts call it
[16:27] <jcastro> LaserJock: yeah! It's getting there!
[16:27] <kenvandine> LaserJock, RSS for gwibber-service on my netbook is 8M
[16:28] <Nafai> kenvandine: sounds good
[16:28] <kenvandine> with 3 accounts
[16:28] <LaserJock> kenvandine: how do you measure that?
[16:28] <kenvandine> ps -e -opcpu=,rss=,vsize=,size=,start_time=,cmd= |grep gwibber-service|grep python| grep -v grep
[16:28] <seb128> mvo, didn't software-center use to allow to queue or start several installations?
[16:28] <kenvandine> LaserJock, i have a script that runs that every minute in cron logging the results :)
[16:28] <mvo> seb128: it still does, there is one (fix in bzr, queue) bug that prevents it in the applist interface
[16:29] <mvo> seb128: if you go to the details and queue it there it will work
[16:29] <mvo> seb128: or use the bzr version
[16:29] <seb128> mvo, oh ok, thanks
[16:29] <seb128> mvo, you rock as usual, fixing bugs before I find them ;-)
[16:29]  * seb128 hugs mvo
[16:29] <kenvandine> hehe
[16:30] <kenvandine> preemptive bug fixing :)
[16:30] <mvo> the best kind!
[16:30]  * mvo hugs seb128 back
[16:30] <seb128> s-c is slooooow though
[16:30] <seb128> I got the compiz way to tell you it doesn't respond for like 8 seconds when clicking on the partnair entry
[16:30] <seb128> but there is only acroread listed there
[16:31] <LaserJock> kenvandine: ok, I get 20MB
[16:31] <seb128> it's fast now, I wonder if I didn't select the "ubuntu provided" one by error
[16:31] <seb128> the mini touchapd sucks
[16:32] <kenvandine> LaserJock, on my amd64 laptop it is 29M right now
[16:33] <kenvandine> gwibber-service on i386 has generally been about 40% of what it is on amd64
[16:33] <LaserJock> kenvandine: gwibber itself is still ~ 60MB, but not as bad as it used to be anyway
[16:33] <kenvandine> yeah, it is gonna be much higher
[16:33] <kenvandine> webkit
[16:33] <kenvandine> and UI stuff
[16:34] <LaserJock> I'm not sure what to think
[16:34] <LaserJock> the bling is fun
[16:34] <kenvandine> we'll try to make it smaller next cycle
[16:34] <LaserJock> but with 1GB of RAM in this netbook, I wouldn't mind having a bit lighter version
[16:34] <Amaranth> Once we're all using webkit-gtk it won't hurt so bad
[16:34] <kenvandine> this cycle i have focused on gwibber-service
[16:35] <kenvandine> since that mostly will run all the time
[16:36] <LaserJock> I use them at the same time still
[16:36] <kenvandine> LaserJock, gwibber on my amd64 is 113824 right now
[16:36] <LaserJock> I have to say I'm slightly unnerved by the whole "File->Quit is different than hitting the close button" thing
[16:36]  * kenvandine hates that having a 64 system so you can have more memory means it uses more memory
[16:37] <LaserJock> perhaps some wording or something can be used to help
[16:37] <kenvandine> open for suggestions for next cycle
[16:37] <seb128> pitti, what is doing the "writing on disk..." progress bar on eject in lucid?
[16:37] <seb128> pitti, g-d-u?
[16:38] <pitti> seb128: I _think_ it's gdu-notification-daemon
[16:38] <pitti> it could be gvfs-gdu-volume-monitor as well, let me check
[16:39] <seb128> pitti, ok thanks, the thing decided that the ssd drive in my mini needed flushing before being removed when I unmount the other lucid partition I have there
[16:39] <seb128> pitti, ie it display the bouncing bar when clicking on the eject icon in nautilus sidebar for a partition on the ssd drive
[16:40] <mvo> seb128: the ubuntu provided one is really slow. if I had my will it would only show apps and the system menu would have sub-menus
[16:40] <mvo> seb128: but *shrug*
[16:40] <seb128> mvo, yeah...
[16:41] <seb128> mvo, is that still gtk being slow?
[16:41] <seb128> mvo, the ubuntu mode didn't help there?
[16:42] <LaserJock> kenvandine: so I'm down to ~6 sec. warm starts for gwibber and ~ 30s cold starts
[16:42] <mvo> seb128: gtk is much better now, its not entirely clear currenlty whats causing it now. but I also did not have much time to investigate yet
[16:42] <seb128> mvo, ok, I was just being curious there, thanks
[16:42] <LaserJock> kenvandine: which means it got cut in half from earlier in lucid
[16:42] <kenvandine> LaserJock, i wish i could see why cold starting is so slow for you
[16:42] <rickspencer3> chrisccoulson is totally the unsung hero of the desktop
[16:43] <Nafai> kenvandine: I just pushed the move to Dispatcher to my branch, the DBus method is RefreshCreds
[16:43] <kenvandine> thx
[16:43] <rickspencer3> Nafai did you get the mlock working?
[16:43] <Nafai> I'm going to work on the mlock stuff now
[16:43] <LaserJock> kenvandine: well, gwibber-service does an update before it actually opens gwibber up doesn't it?
[16:43] <rickspencer3> cool
[16:43] <kenvandine> awesome
[16:43] <rickspencer3> let's get this uploaded today!
[16:43] <kenvandine> LaserJock, no it doesn't
[16:44] <rickspencer3> (well after the freeze anyway) ;)
[16:44] <LaserJock> kenvandine: on a cold start?
[16:44] <kenvandine> nope
[16:44] <LaserJock> hmm
[16:44] <kenvandine> it uses the cached messages first
[16:44] <kenvandine> well, gwibber-service does do a refresh after it first starts
[16:44] <LaserJock> I see newer messages right when gwibber starts up
[16:44] <kenvandine> but not until it is completely up
[16:44] <kenvandine> and that doesn't block the UI
[16:44] <LaserJock> weird
[16:45] <LaserJock> I thought maybe it was because it takes so long to refresh
[16:45] <kenvandine> and the UI doesn't trigger any refreshing
[16:45] <chrisccoulson> :-)
[16:45] <Nafai> pitti: on the mlock/munlock stuff, if I'm going to be updating the dictionary that holds the passwords, would the proper thing to do is clear the dictionary, munlock it, re-do it, and then mlock it?
[16:45] <LaserJock> it seems like the refreshing happens before the UI gets there
[16:45] <kenvandine> LaserJock, it likely does if it takes 30s to see the UI
[16:45] <kenvandine> but that isn't by design
[16:45] <LaserJock> ok
[16:45] <kenvandine> it is just because the UI is taking so long to start for you
[16:45] <LaserJock> hmm, there goes that idea :/
[16:46] <pitti> Nafai: you need to munlock first, otherwise you'd lose the reference
[16:46] <pitti> Nafai: do you actually need to update the dict?
[16:46] <Nafai> when accounts have been added/removed or passwords changed, the dictionary contents will change
[16:48] <Nafai> hrm.  how to get the size of the dictionary
[16:48] <Nafai> (memory size)
[16:49] <Nafai> oh sweet. there's a __sizeof__ method :)
[16:49]  * kenvandine found it very interesting how easy it was to use ctypes
[16:49] <pitti> Nafai: you should lock the values only, not the entire dictionary
[16:49]  * kenvandine just assumed it would be hard :)
[16:49] <pitti> Nafai: there's no reason why the dictionary should be in a single memory block (and usually it wouldn't)
[16:49] <Nafai> true
[16:49] <pitti> kenvandine: it's pretty great
[16:50] <kenvandine> i have always avoided it because it was intimidating :)
[16:50] <pitti> Nafai: no need to lock the dictionary hash tables, etc.
[16:50] <pitti> Nafai: so changing the dictionary shouldn't require locking changes of existing values at all
[16:50] <Nafai> so, for key in d: mlock(d[key], len(d[key]), ?
[16:50] <pitti> Nafai: just if you add a key (have string, mlock() it, add it to dict)
[16:51] <pitti> Nafai: I'd add it right after you read the string from g-k
[16:51]  * Nafai nods
[16:51] <Nafai> makes sense
[16:51] <pitti> it's a bit of a confusing terminology here :)
[16:52] <pitti> we have keys which are values of a dictionary, which are addressed as keys :)
[16:52]  * Nafai likes learning new things :)
[16:52] <pitti> well, actually we shold call the first one "password", not "key", I figure
[16:57] <pitti> seb128: hm, do you have an example package for gnome-games? I just checked aisleriot, and it looks alright?
[16:58] <pitti> seb128: language-pack-gnome-de-base has the German help and .omf, and the aisleriot .deb has symlinks to them
[16:58] <seb128> pitti, gnome-sudoku
[16:59] <pitti> seb128: ah, thanks
[16:59] <seb128> pitti, you're welcome!
[17:01]  * kenvandine goes to eat, bbiab
[17:03] <hyperair> jcastro: yes, you're right. i'll patch it
[17:04] <jcastro> hyperair: thanks, great work by the way, I will blog it as soon as I get it!
[17:09] <pitti> seb128: oh, it's crystal clear -- it would only work for the first binary package in debian/control
[17:10] <seb128> pitti, so you picked the only game it's working on? ;-)
[17:10] <pitti> apparently so :)
[17:10] <pitti> seb128: seems I'm lucky today
[17:10] <seb128> hehe
[17:10]  * pitti goes to fill out a lottery ticket
[17:12] <seb128> I didn't find so many issues in beta2 testing so far, good lucid!
[17:12] <pitti> good to hear
[17:12] <rickspencer3> seb128, nice
[17:13] <seb128> it's good to step out of launchpad flow of bugs sometime
[17:13] <seb128> just to see that things are actually mostly working
[17:13] <pitti> works quite well for me, except that the  display gets powered off during boot and I can't see anythign; but *shrug*, minor details :)
[17:13] <seb128> ;-)
[17:13] <seb128> pitti, Sarvatt hinted I should try to update the bios for my issues
[17:14] <seb128> I need to find how to do that still, I didn't look at it yet
[17:14] <pitti> seb128: to me as well
[17:14] <pitti> but it requires windows or a floppy, allegedly
[17:14] <seb128> I didn't update bios-es since the time I used msdos floppies
[17:14] <pitti> I have neither..
[17:14] <seb128> which seems to be an another century
[17:14] <pitti> yeah, I wondered why they don't offer USB stick images
[17:14] <pitti> I wonder if one could actually put the floppy image onto an USB stick :)
[17:15] <Nafai> pitti: How does this look? http://bazaar.launchpad.net/~nafai/gwibber/gnomekeyring-fix/annotate/head:/gwibber/microblog/util/keyring.py
[17:15] <didrocks> well, going out for an hour taking fresh air…
[17:15] <seb128> Sarvatt said he installed freedos on an usb stick
[17:15] <seb128> pitti, there is firmware-addon-dell too
[17:16] <seb128> but I'm not sure how it works
[17:16] <seb128> didrocks, enjoy!
[17:16] <didrocks> seb128: thanks
[17:17] <pitti> Nafai: looks good already!
[17:17] <pitti> Nafai: I'd do two changes:
[17:17] <pitti> (1) move the mlock() right after value =
[17:17] <pitti> since the value is passed around a couple of times, and there are different exit paths
[17:18] <pitti> Nafai: and I'd drop the munlock()
[17:18] <pitti> Nafai: since you never know when the GC runs, so the old value might stay around for ages, unlocked
[17:18] <Nafai> true
[17:19] <pitti> Nafai: I guess free()ing it will unlock it automatically
[17:19]  * Nafai nods
[17:19] <pitti> but even if not, it won't take so much space to even come close to your shm limit
[17:19] <Nafai> ok, this is simpler :)
[17:19] <pitti> Nafai: thanks!
[17:23] <Nafai> kenvandine: Okay, I believe that is all of the requested changes from me
[17:24] <Nafai> Let me know what else I can help with
[17:25] <pitti> Nafai: looks fine to me now
[17:26] <Nafai> thx
[17:41] <hyperair> jcastro: http://paste.debian.net/68037/ <-- could you test this patch please?
[17:43] <jcastro> qense: do you have time to test this patch?
[17:43] <jcastro> hyperair: sorry something came up that needs my immediate attention
[17:53] <hyperair> jcastro: no problem
[18:10] <pitti> seb128: oh, wow -- gnome-sudoku alone shrinks from 2.5 to 0.3 MB
[18:10] <pitti> -rw-r--r--  1 martin martin  7222524 2010-04-08 18:31 gnome-games_2.30.0-0ubuntu3_amd64_translations.tar.gz
[18:10] <pitti> -rw-r--r--  1 martin martin   499250 2010-04-08 18:46 gnome-games_2.30.0-0ubuntu3_static_translations-prev.tar.gz
[18:10] <pitti> oops, ignore the first one
[18:10] <pitti> -rw-r--r--  1 martin martin 18329738 2010-04-08 18:56 gnome-games_2.30.0-0ubuntu3_static_translations.tar.gz
[18:10] <pitti> so, 17.5 MB stripped off all .debs
[18:11] <pitti> (but we only ship a few games by default)
[18:12] <Nafai> rickspencer3: btw, sometime this week I could use some discussion from you or pitti or whoever about blueprints, etc
[18:12] <rickspencer3> Nafai ok
[18:13] <rickspencer3> can we talk this afternoon?
[18:13] <kenvandine> thx Nafai
[18:13] <rickspencer3> like 2pm/3pm for you?
[18:13] <Nafai> Sure, either is fine with me
[18:13] <Nafai> kenvandine: np, glad to help.  Fun to write code that is a critical part of this next release :)
[18:14] <rickspencer3> Nafai, I'll just find you when I get back from my break
[18:14] <Nafai> sounds good
[18:15] <rickspencer3> Nafai, kenvandine am I understanding that Gwibber code changes are all done now?
[18:15] <kenvandine> rickspencer3, almost
[18:15] <rickspencer3> nice
[18:15] <kenvandine> i am doing the accounts side now
[18:15] <rickspencer3> ok
[18:16] <seb128> pitti, excellent
[18:16] <rickspencer3> Nafai, kenvandine, pitti, fyi - I asked kees to take a look at the keyring code for gwibber
[18:16] <pitti> he was just talking to me
[18:16] <seb128> pitti, I noticed it by looking at CD space use sorted by directory
[18:16] <rickspencer3> since all of this was started by trying for better security of passwords
[18:17] <Nafai> seb128: btw, I had a look at bug #553423 and not knowing how the translation stuff works, I'm not sure why that string isn't being translated.  The string in the app indicator using source is identical to the string previously used in the GtkStatusIcon source, and it is using _()
[18:17] <pitti> seb128: I'll upload this on Monday
[18:18] <pitti> seb128: I don't have the guts of letting it into the archive tomorrow evening :) not again..
[18:18] <seb128> Nafai, ok, I will have a look later
[18:18] <seb128> pitti, lol
[18:18] <rickspencer3> :)
[18:18] <seb128> pitti, we are likely to unfreeze one day late again?
[18:18] <pitti> seb128: I don't think so; j/k
[18:19]  * seb128 hugs pitti
[18:19]  * pitti hugs back seb128
[18:19] <pitti> I want lucid to thaw, too
[18:19]  * pitti piled up 16 "Fix committed" tasks again
[18:19] <Nafai> Looks like there are a few tools we can employ for gwibber optimizations during the 10.10 dev process: http://stackoverflow.com/questions/110259/python-memory-profiler
[18:22] <kenvandine> Nafai, cool
[18:23] <LaserJock> kenvandine: does webkit itself use a lot of memory?
[18:23] <LaserJock> I was thinking of possibly using it on an app I'm hacking on
[18:23] <kenvandine> LaserJock, not sure...
[18:23] <LaserJock> but I would like to keep it light
[18:24] <kenvandine> i haven't really profiled the UI stuff
[18:24] <LaserJock> k
[18:25] <LaserJock> kenvandine: presumably lowering the number of messages displayed would lower the RAM usage?
[18:25] <qense> jcastro: will test as soon as I'm done with the dishes!
[18:25] <kenvandine> perhaps
[18:29] <Damascene> hello, every one is pointing me here. I hope I could get the help I want
[18:29] <Damascene> https://bugs.launchpad.net/vte/+bug/263822
[18:30] <Damascene> I want to see if it's possible to replace vte by mtlerm for rtl languages
[18:30] <Damascene> *mlterm
[18:32] <LaserJock> rickspencer3: you clearly have too much fun coding :-)
[18:32] <rickspencer3> heh
[18:32] <LaserJock> I just wish I could get faster with it
[18:33] <digital_> houdy
[18:33] <Nafai> lunch
[18:34] <LaserJock> I really wish we had python-documentation-snippets or something
[18:41] <digital_> anyone had any issues with 10.04 locking up about a minute after gnome loads?
[18:41] <digital_> im trying to track down what is causing it
[18:42] <digital_> i should say locking up with graphical coruption
[18:47] <chrisccoulson> seb128 - the firefox startup notification patch has been applied fo FF3.6/XUL192 upstream now
[18:47] <chrisccoulson> so we will get that when we next update :-)
[18:49] <jcastro> What's the workflow for getting a design person to look at a desktop bug?
[18:49] <jcastro> https://bugs.edge.launchpad.net/indicator-applet/+bug/558581
[18:49] <Amaranth> jcastro: Didn't I just close that?
[18:49] <jcastro> the indicator shortcut conflicts with compiz, but it's not clear which one we care about more
[18:49] <jcastro> Amaranth: did he file one on compiz too?
[18:49] <Amaranth> Super+m in compiz is used for neg
[18:50] <jcastro> right, but someone on design or DX picked that for the indicator applet
[18:50] <Amaranth> jcastro: No, someone else filed a bug saying they want to use super-m for something else
[18:50] <Amaranth> and super-s, super-x, etc
[18:50] <Amaranth> I'll mark it as a dupe
[18:50] <jcastro> thanks
[18:58] <qense> jcastro: why do we want to change the icon name?
[18:59] <qense> jcastro: I thought that was an issue that's resolved now. Or is Debian using different icon names for Banshee?
[19:02] <jcastro> hyperair: ^^
[19:03] <hyperair> qense: what issue are you talking about?
[19:06] <qense> hyperair: the patch you asked jorge to take a look at.
[19:06] <qense> hyperair: it's changing the icon used
[19:06] <hyperair> qense: yes, it is. to banshee-panel. what's wrong with that?
[19:06] <qense> we did have a bug a while ago with the icon name, but the icon name in humanity icons was changed
[19:06] <hyperair> to banshee-panel.
[19:06] <qense> really?
[19:06] <hyperair> we can't have banshee's icon everywhere be monochrome.
[19:07] <qense> I thought vish changed it back to media-player-banshee-panel afterwards because of the bug.
[19:07] <hyperair> banshee-panel is the monochrome icon
[19:07] <hyperair> eh?
[19:07] <hyperair> no, not afaik.
[19:07] <hyperair> qense: could you do a dpkg -S for it? i don't have a lucid installation
[19:07] <hyperair> dpkg -S banshee | grep png
[19:07] <vish> qense: the u-mono icon is banshee-panel, since it is meant for lucid
[19:08] <vish> qense: the humanity icon is with both names
[19:08] <qense> ok
[19:08] <qense> vish: enlighten us: what icon does Banshee use and what icon should it use? Both monochrome and regular.
[19:08] <qense> vish: Wasn't it something like media-player-banshee?
[19:09] <hyperair> qense: media-player-banshee for regular, banshee-panel or media-player-banshee-panel for monochrome, iirc.
[19:09] <vish> qense: it seems to use the banshee-panel icon in Lucid
[19:09] <qense> really?
[19:09] <hyperair> qense: banshee.notificationarea uses banshee-panel for monochrome, but appindicator doesn't.
[19:09] <hyperair> i wrote the patch =\
[19:09] <vish> yeah.. not sure how it worked though o.0
[19:09] <vish> there hyperair is the culprit ;p
[19:09]  * hyperair coughs
[19:10] <hyperair> vish: you were the one who stuffed it in as banshee-panel! i just followed suite!
[19:10] <qense> Maybe it happened because MonoChromeIcon wasn't added to the NotificationArea class when we were first trying the appindicator.
[19:10] <qense> vish: hyperair is probably right here
[19:10] <qense> :)
[19:11] <vish> ;)
[19:11] <hyperair> qense: yaeh, that.
[19:11] <hyperair> qense: the patch landed very recently
[19:12] <hyperair> qense: so can you test the patch?
[19:12] <qense> the monochrome icon was added in 1.5.4 or 1.5.5, wasn't it?
[19:12] <hyperair> 1.6.0
[19:12] <qense> I recall the variable to be there already before 1.6.0
[19:12] <qense> let me look that up
[19:15] <qense> hyperair: never mind, I was confused with one of the other apps I worked on
[19:15] <hyperair> me shrugs
[19:15] <hyperair> er
[19:15]  * hyperair 
[19:15] <hyperair> nevermind
[19:15] <hyperair> sleep deprivation taking its toll
[19:17] <qense> maybe you should take some sleep :)
[19:18] <qense> hyperair: I'll take a look at the patch
[19:18] <hyperair> qense: thanks.
[19:18] <hyperair> and yeah i'll go get some sleep
[19:18] <hyperair> do you have bce commit access?
[19:19] <qense> yes
[19:47] <kenvandine> Nafai, password changing is working fine and not causing any problems
[19:47] <kenvandine> however, in testing that i have discovered another bug... which wasn't there before but certainly unrelated
[19:48] <kenvandine> if you get an auth failure and it raises the error dialog, it causes the cpu to peg
[19:48] <rickspencer3> dang
[19:48] <kenvandine> i have a fix :)
[19:48] <kenvandine> working on it
[19:48] <rickspencer3> kewl
[19:48] <kenvandine> if i don't make it call the error dialog via dbus, it is fine
[19:48] <rickspencer3> I'm taking a break for like an hour
[19:48] <kenvandine> :)
[19:48] <rickspencer3> bbl
[19:48] <kenvandine> ok, good news is the keyring stuff is good to go :)
[19:50] <qense> jcastro: I've committed hyperair's patch to b-c-e:master.
[20:05] <damascene> I want to see if it's possible to replace vte by mtlerm for rtl languages
[20:05] <damascene> https://bugs.launchpad.net/vte/+bug/263822
[20:23] <chrisccoulson> damascene, no, it's not possible
[20:23] <damascene> chrisccoulson, may I ask why?
[20:24] <chrisccoulson> firstly, VTE and mlterm are totally different (VTE is an embeddable terminal widget, used by several applications including gnome-terminal and synaptic)
[20:24] <chrisccoulson> and mlterm is a stand-alone terminal emulator
[20:25] <chrisccoulson> and there is no way we are going to port something like gnome-terminal to something other than VTE (if that other something existed) without upstream wanting to do that
[20:25] <damascene> any thing else?
[20:26] <chrisccoulson> huh??
[20:26] <damascene> I mean are these the only reasons or there is something else?
[20:26] <chrisccoulson> those are the reasons, but they're pretty big reasons IMO
[20:27] <chrisccoulson> vte and mlterm are no interchangeable at all
[20:27] <chrisccoulson> they are completely different
[20:27] <damascene> let me talk about my point of view
[20:27] <chrisccoulson> well, it doesn't matter what your point of view is. what you want is technically impossible
[20:28] <damascene> is it possible to just add mlterm by default?
[20:28] <chrisccoulson> no
[20:28] <damascene> and why is that, please?
[20:28] <chrisccoulson> mlterm is part of the gnome-desktop. we're not going to change a default application because one person asked for that
[20:29] <chrisccoulson> most users use gnome-terminal without any issue
[20:29] <chrisccoulson> mlterm is unmaintained
[20:29] <chrisccoulson> it hasn't had a release since 2007
[20:31] <damascene> well you don't want to accept my opinion what ever it was. and no point of talking to you about it. but because we are in a public channel not private conversation I have to say....
[20:31] <damascene> 1.mlterm works for us with all the terminal apps. vte doesn't
[20:31] <damascene> 2. not only me having this problem. all rtl language users too.
[20:31] <chrisccoulson> well, i've accepted your opinion, but i've just told you why it's not possible ;)
[20:32] <damascene> 3. mlterm 3.0 have been released months ago
[20:32] <chrisccoulson> it would be better to convince the vte maintainers to fix that
[20:33] <damascene> 4.vte maintainer doesn't want to do any thing about it as mentioned on both upstream and launchpad bug
[20:34] <Nafai> back
[20:34] <damascene> 5.if it's possible to make mlterm embedded that will be nice. if not that will fix 90% of the problem
[20:35] <chrisccoulson> well, i suspect that is not possible without a lot of effort, and you'd need to convince the upstream developer to make it embeddable ;)
[20:35] <LaserJock> I suppose you could include mlterm in the default install or something, but I'm guessing it's too big
[20:35] <chrisccoulson> in any case, mlterm hardly has the feature parity of gnome-terminal :-/
[20:35] <chrisccoulson> LaserJock, we don't want 2 applications doing the same thing on the default install
[20:36] <LaserJock> chrisccoulson: we already do don't we?
[20:36] <LaserJock> xterm?
[20:37] <damascene> chrisccoulson, we don't want it on the default install. just when you install Arabic support from the language support in system
[20:37] <chrisccoulson> damascene, but that's completely different to what you were requesting a few seconds ago
[20:38] <chrisccoulson> you were asking to replace gnome-terminal / vte with mlterm...
[20:38] <damascene> you obviously didn't read the bug report :)
[20:39] <damascene> I want to see if it's possible to replace vte by mtlerm for rtl languages
[20:39] <chrisccoulson> like i said, it's not possible, as vte and mlterm are 2 completely different things ;)
[20:39] <damascene> that was my question. sorry wasn't that clear
[20:40] <chrisccoulson> installing another terminal in addition to gnome-terminal would be possible, but mlterm is not a substitute for vte
[20:40] <damascene> ok, another question. could we have mlterm installed when we chose to install rtl language support?
[20:41] <chrisccoulson> damascene, it's possible to install extra applications when installing language support
[20:41] <kklimonda> damascene: is it a technical question or policital one?
[20:41] <damascene> chrisccoulson, what should we do to have that done?
[20:41] <chrisccoulson> but mlterm would need to be in main first (which would mean being reviewed, would have to be actively maintained upstream etc)
[20:41] <damascene> kklimonda, ubuntu politic question
[20:42] <damascene> chrisccoulson, tell me what should I do to make that possible
[20:43] <damascene> ,please.
[20:43] <chrisccoulson> i'm not too sure about that, without first checking how we do it
[20:43] <kklimonda> pitti would be a better person to answer this question probably
[20:45] <damascene> by the way there is someone called yofel want to do the same for the Hebrew calender when Hebrew support installed. and he thinks we could push both mlterm and the calender for the language
[20:46] <damascene> chrisccoulson, kklimonda , I'm glad I've found someone to answer my question finally. I hope you can guide me on this. I've sent e-mail to ubuntu-desktop but no respond
[20:46] <chrisccoulson> that's probably not the best list to send it too
[20:46] <chrisccoulson> ubuntu-devel might be a better list
[20:47] <damascene> ok thanks for the advice. any thing else I've to do?
[20:47] <damascene> is piti around?
[20:49] <chrisccoulson> we do install extra bits for certain languages, but i don't know if that's implemented with dependencies from the launguage packs, or if that is implemented by language-selector itself
[20:51] <damascene> the language selector is the user?
[20:52] <kklimonda> chrisccoulson: I'd say that they are implemented with dependendencies but that sounds like a trick. I see that for example language-support-input-ja depends on ibus-anthy to provide input method or whatever it is..
[20:53] <chrisccoulson> of course
[20:53] <chrisccoulson> :)
[20:54] <chrisccoulson> language-selector lets you choose which meta-packages you want to install for each locale
[20:54] <chrisccoulson> so it would be a dependency on one of the meta-packages
[20:54] <chrisccoulson> not sure which though
[20:55] <damascene> and who is the language selector a person from the locale or form ubuntu?
[20:57] <damascene> sorry for the stupid question. didn't understand your respond well.
[20:57] <kklimonda> right, it doesn't really fall into any category
[20:58] <kklimonda> I'd put it into imput methods if I didn't know that it doesn't fit there ;)
[20:58] <chrisccoulson> language-selector is the tool used to install language support
[20:59] <damascene> I see but it doesn't provide any choice in the current version
[21:00] <kklimonda> chrisccoulson: can we even change the default terminal for existing users?
[21:00] <damascene> you said that you install extra bits for certain languages. can you give me some examples please
[21:01] <kklimonda> damascene: japanese, chinese and similar languages install packages to enable users to input national characters for example
[21:01] <damascene> great
[21:02] <damascene> it's late here. I understand from you that I should contact ubuntu-devs now. any thing else?
[21:02] <damascene> I've to go in a while
[21:02] <baptistemm> is there a way to get a previous version of a package, I would need obexd-client 0.21 to test a regression
[21:02] <kklimonda> damascene: you should send an email to either ubuntu-devel or ubuntu-devel-discuss mailing list
[21:02] <kklimonda> damascene: it's not that urgent as it won't get implemented for 10.04 anyway
[21:03] <kklimonda> damascene: so we have some time to discuss it with people who actually know how it should be done ;)
[21:03] <damascene> ok, np
[21:03] <damascene> thanks all.
[21:03] <kklimonda> baptistemm: hmm.. maybe it's still available on launchpad?
[21:04] <kklimonda> baptistemm: https://edge.launchpad.net/ubuntu/+source/obexd/0.21-0ubuntu1
[21:05] <baptistemm> great.. thanks
[21:16] <jcastro> qense: thanks!
[21:16] <qense> :)
[21:47] <czajkowski> should there be an Ubuntu one syn cloud in the menu panel any more ?
[21:55] <rickspencer3> czajkowski, no
[21:56] <rickspencer3> the U1 UI is in the Me Menu and nuatilus now
[21:57] <kenvandine> seb128, can you please sponsor lp:~ubuntu-desktop/gwibber/ubuntu ?
[21:57] <kenvandine> rickspencer3, just released gwibber 2.29.95 with the keyring fix and a few others :)
[21:57] <rickspencer3> niiiice
[21:57] <Nafai> yay!
[21:57] <seb128> kenvandine, ok
[21:57] <kenvandine> seb128, thx
[21:57] <seb128> do we know when lucid will be unfrozen?
[21:57] <rickspencer3> kenvandine, so what a difference a day can make, huh?
[21:57] <kenvandine> thank you nafa!
[21:57] <czajkowski> rickspencer3: cheers, :)
[21:57] <kenvandine> yup :)
[21:57] <kenvandine> seb128, i haven't heard
[21:58] <seb128> btw does anybody get seahorse using cpu there?
[21:58] <seb128> or gvfs?
[21:58] <kenvandine> seb128, seahorse
[21:58] <kenvandine> if you look at the details of a key
[21:58] <seb128> gnome-keyring upstream replied on the bug asking for details
[21:58] <kenvandine> while that tab is focused, it chews cpu
[21:58] <Nafai> man, evolution is sometimes annoying :(
[21:58] <kenvandine> ROAF noticed that
[21:58] <chrisccoulson> seb128 - i get seahorse using lots of CPU too
[21:58] <rickspencer3> RAOF, empathy in 10 minutes?
[21:59] <seb128> how do you trigger it?
[21:59] <chrisccoulson> but it didn't look like a keyring issue
[21:59] <seb128> ok
[21:59] <chrisccoulson> every time i interrupted it in gdb it was deep inside some gtk function
[21:59] <chrisccoulson> let me try again
[21:59] <seb128> I think people have been mixed all "software uses gnome-keyring and eat cpu" issues
[21:59] <chrisccoulson> yeah, possibly
[21:59] <seb128> ed->ing
[21:59] <didrocks> well, time to go, good evening everyone!
[21:59] <seb128> 'night didrocks
[21:59] <Nafai> didrocks: Later!
[22:00] <kenvandine> seb128, in seahorse, double click on a key
[22:00] <kenvandine> then select the details tab
[22:00] <kenvandine> while that tab is focused seahorse uses a ton of CPU
[22:00] <kenvandine> selecting a different tab fixes it, i think
[22:01] <kenvandine> seb128, i was wrong... not a specific tab just having that dialog open
[22:01] <kenvandine> closing the tab lets the load drop again
[22:02] <kenvandine> it isn't as dramatic as gwibber, only chews on about 60% for me :)
[22:02] <seb128> it doesn't seem the same issue
[22:03] <seb128> as chrisccoulson said it seems rather looping in gtk
[22:03] <chrisccoulson> seb128 - i always get traces that look a bit like this in seahorse: http://paste.ubuntu.com/411242/
[22:03] <seb128> it's not blocked on a keyring call
[22:04] <seb128> it's not important enough to be worth spending time learning the code
[22:04] <seb128> but I will open an upstream bug
[22:04] <chrisccoulson> yeah, it's not that big an issue really. the CPU usage returns to normal once you close the dialog
[22:04] <kenvandine> seb128, agreed
[22:04] <seb128> I think I also figured why gnome-appearance-properties crashes on theme dnd
[22:04] <seb128> the bug open for years which zillion duplicate of crash in pango calls
[22:05] <chrisccoulson> oh ?
[22:05] <chrisccoulson> you figured that out?
[22:05] <seb128> yes
[22:05] <chrisccoulson> excellent :)
[22:05] <seb128> gtk_label_set_text is not thread safe
[22:06] <rickspencer3> chrisccoulson, is there a bug report for that seahorse thing?
[22:06] <seb128> I hate threads officially now
[22:06] <kenvandine> hehe
[22:06] <chrisccoulson> rickspencer3, i think so (seb128 might know though)
[22:06]  * kenvandine heads out for a while, bbl
[22:06] <rickspencer3> seb128, I just finished in ubuntu-app-devel saying *never use threads*
[22:06] <chrisccoulson> lol
[22:06] <seb128> rickspencer3, good advice
[22:06] <chrisccoulson> threads are cool really :)
 rickspencer3: what pragmatic practical reasons (against threads)? (just in curiosity)
 bughugger uses AsynchTaskProgressbox a lot if you want to take a look though
[22:06] <rickspencer3>  well, first, in python, a thread can't be put on it's own processor
[22:06] <rickspencer3>  but mostly, it just creates lots of bugs
[22:07] <mclasen> seb128: I fixed that bug in control-center a while ago
[22:07] <Nafai> rickspencer3: btw, I'm ready whenever to talk about blueprints :)
[22:07] <seb128> mclasen, it's still happening with 2.30 though
[22:07] <rickspencer3> chrisccoulson, I think async libraries are cool, but writing your own threads bite
[22:07] <chrisccoulson> rickspencer3, when i did the low disk space warning in g-s-d, i implemented the trash emptying in a separate thread
[22:07] <seb128> mclasen, I got valgrind log on stock upstream 2.30 tarballs some days ago
[22:07] <chrisccoulson> but i cheated a bit there
[22:07] <rickspencer3> Nafai, ok 10 minutes
[22:08] <chrisccoulson> (i borrowed it from gnome-applets)
[22:08] <rickspencer3> hehe
[22:08] <Nafai> np
[22:08] <rickspencer3> brb
[22:11] <mclasen> seb128: well, then maybe there's some missing locking, still
[22:11] <seb128> mclasen, https://bugzilla.gnome.org/show_bug.cgi?id=614256
[22:14] <seb128> mclasen, https://bugzilla.gnome.org/show_bug.cgi?id=610003 is your bug?
[22:15] <mclasen> seb128: don't know what 'line 147 in this version' refers to
[22:15] <seb128> mclasen, so file_transfer_dialog_set_prop() might have the same issue
[22:15] <seb128> mclasen, the valgrind log, the error is
[22:15] <seb128> ==27164==    by 0x8065761: file_transfer_dialog_set_prop
[22:15] <seb128> (file-transfer-dialog.c:147)
[22:16] <seb128> mclasen, it's crashing on file-transfer-dialog.c:147
[22:25] <chrisccoulson> right, i'm moving in to the lounge for the rest of the evening
[22:25] <chrisccoulson> bbiab
[22:34] <asac> seb128: when do you plan last gtk+ and gnome flush?
[22:34] <seb128> asac, dunno, ask slangasek when he will say no to uploads
[22:34] <seb128> asac, GNOME 2.30.1 will be late for lucid I think
[22:35] <seb128> ie after lucid rc freeze
[22:35] <seb128> so I'm not if we can get it, but we will get uploads until they are stopped
[22:41] <mclasen> seb128: where is it called from ?
[22:41] <mclasen> job_progress has locking
[22:42] <mclasen> so maybe it is getting called from somewhere else without the necessary locking
[22:44] <seb128> mclasen, http://paste.ubuntu.com/411253/
[22:46] <mclasen> seb128: well, thats only one thread
[22:47] <asac> seb128: kk
[22:47] <seb128> mclasen, http://paste.ubuntu.com/411256/
[22:48] <seb128> mclasen, sorry I got the wrong call before
[22:50] <mclasen> seb128: hmm, yeah, obviously not quite enough locking
[23:29] <RAOF> Good morning.
[23:30] <RAOF> rickspencer3: You wanted me?
[23:30] <rickspencer3> hi RAOF
[23:30] <rickspencer3> did I?
[23:30] <RAOF> 06:59 <rickspencer3> RAOF, empathy in 10 minutes?
[23:30] <rickspencer3> oops
[23:30] <rickspencer3> that was for Nafai
[23:30] <rickspencer3> too many new people ;)
[23:31] <Nafai> :)
[23:31] <RAOF> :)
[23:31] <Nafai> I was curious when you said that earlier...