[00:15] <TheMuso> RAOF: Nice as well.
[00:15] <TheMuso> rickspencer3: hey there.
[00:16] <rickspencer3> hey TheMuso
[00:16] <fagan> RAOF: nice job with F-spot
[00:16] <rickspencer3> I'm about to step out, but will be online a bit later I think
[00:16] <RAOF> We managed to make it down to Clifton Gardens on Sunday and walk around neatly in between downpours. :)
[00:16]  * fagan used it over the weekend and loved it
[00:16] <TheMuso> heh nice
[00:16] <RAOF> fagan: Excellent!
[00:17] <fagan> the viewer mode is really handy
[00:17] <TheMuso> As much as many people might disagree with me, I was hoping that it would rain more.
[00:17] <fagan> TheMuso: come to ireland then
[00:17] <fagan> :)
[00:17] <fagan> We rain a lot
[00:18] <TheMuso> heh
[00:30] <Sarvatt> is 05_locking_for_compiz.patch supposed to still be in our gnome-screensaver patch series? it was fixed years ago apparently, i think it might have just been brought along accidentally because its relevant on hardy
[00:31] <Sarvatt> https://bugzilla.gnome.org/show_bug.cgi?id=488264 -- thats the bug for it
[00:56] <nigelb> TheMuso, morning :)
[00:58] <TheMuso> Hey nigelb.
[00:58] <nigelb> TheMuso, I tried the patch in bug 534190, but it didn't really work for me :( thoughts?
[00:59] <TheMuso> nigelb: right, I will look at that bug a bit later. I am busy going through mail from the weekend.
[00:59] <nigelb> sure :)
[00:59] <nigelb> since you're on there.  I just wanted to let you know :)
[01:00] <TheMuso> yep ok
[01:15] <Amaranth> Sarvatt: That was fixed in xorg ages ago
[05:15] <rickspencer3> TheMuso, hey
[05:15] <rickspencer3> what's up with bug #477226 ?
[05:17] <TheMuso> rickspencer3: the built in microphoen is still not working for people .I need to go back into the code and see whats up. Haven't got to it yet, and it slipped off my radar. WIll take a look at trying to solve it.
[05:18] <rickspencer3> TheMuso, np
[05:18] <rickspencer3> is it still High importance do you think?
[05:19] <TheMuso> rickspencer3: Possibly, because the internal microphone is still likely to be used by people.
[05:19] <rickspencer3> ok
[05:19] <rickspencer3> thanks TheMuso
[05:19] <rickspencer3> ttyt
[05:19] <TheMuso> np
[05:39] <crimsun> TheMuso: 0x1a needs to be VREF'd appropriately depending on the presence of 0x1b; you could probably do that in cxt5066_ideapad_automic() based on a switch/case if you don't feel like adding a separate function for the u350
[05:40] <crimsun> I'm doing something similar for the new Sony VAIOs in the Realtek case
[05:40] <crimsun> anyhoo, ->work
[05:51] <TheMuso> crimsun: ah ok thanks.
[06:16] <TheMuso> crimsun: hrm how would I identify the U350 from the U150 the patch was written for initially? or would the 150 also need the same change?
[06:51] <pitti> Good morning
[06:51] <pitti> Good morning
[06:53] <TheMuso> Morning pitti.
[06:56] <Damascene> what ever,
[06:56] <Damascene> I've been trying to send to the mail list for the past four days no luck
[06:57] <Damascene> I got a message some cerimanl killing it with score 3.7
[06:58] <Damascene> !help
[06:58] <Damascene> !op
[07:53] <Damascene> I've been trying to send to the mail list for the past four days no luck
[07:54] <Damascene> I got a message some cerimanl killing it with score 3.7
[08:08] <didrocks> good morning
[08:14] <RAOF> didrocks: Aloha!
[08:15] <didrocks> hey RAOF, how are you?
[08:16] <RAOF> Pretty good.
[08:16] <RAOF> Although it's getting dark here now.  Daylight savings has ended.  I'm slipping out of the future!
[08:16] <pitti> bonjour didrocks, hey RAOF
[08:17] <didrocks> guten morgen pitti
[08:17] <pitti> found some nice easter eggs? :-)
[08:18] <RAOF> Not so much.  Just a couple.  And they got eaten perhaps a couple of days early :)
[08:20] <didrocks> pitti: not really, help my browser moving all those 3 days. Travelled more than 22 hours by train and truck. And, as he was at the 5th floor, I can hardly walk: my legs are totally broken :(
[08:20] <didrocks> pitti: and you? found some? ;)
[08:20] <pitti> your _browser_?
[08:21] <didrocks> brother :)
[08:21] <pitti> didrocks: urgh, that sounds stressful
[08:21] <pitti> didrocks: was nice for me, lots of hiking, family, bowling, and eating :)
[08:21] <didrocks> not stressful, tiring rather ;)
[08:21] <didrocks> good
[08:21] <didrocks> not to much chocolate over the week-end?
[08:32] <didrocks> pitti: desrt needed zeromq sync from debian to have some easier work on dconf from lucid. It's a new package which could be synced from lucid. What do you think about it? (bug #553858)
[08:33] <pitti> didrocks: can you please reopen it with that rationale?
[08:35] <didrocks> pitti: sure, done  :)
[08:36] <Damascene> I've been trying to send to the mail list for the past four days no luck
[08:36] <Damascene> I got a message some cerimanl killing it with score 3.7
[08:43] <pitti> Damascene: please, first this isn't a place to discuss email problems, and second you didn't even say which mailing list you were sending to
[08:53] <Damascene> pitti, ubuntu-desktop
[08:53] <Sarvatt> darn, managed to get a fix for the clutter apps segfaulting xserver when they are closed that doesn't involve completely dropping the glx 1.4 backports but it's breaking quadrapassel (which was already pretty broken). it's up here if anyone wants to give it a shot - https://edge.launchpad.net/~sarvatt/+archive/bugfixes/+sourcepub/1036476/+listing-archive-extra
[10:06] <chrisccoulson> hello everyone
[10:07] <seb128> hey chris
[10:07] <seb128> hey chrisccoulson
[10:07] <didrocks> hey chrisccoulson, salut seb128
[10:08] <chrisccoulson> hey seb128, how are you? did you have a good weekend?
[10:08] <chrisccoulson> hey didrocks
[10:08] <seb128> lut didrocks
[10:08] <seb128> chrisccoulson, I'm good thank you, had an excellent weekend
[10:08] <seb128> I'm fighting the 800+ bug emails in my inbox for 2 hours now
[10:09] <chrisccoulson> heh, i've not looked in my inbox just yet
[10:09] <didrocks> same here (just 500, but it's enough already :)) :)
[10:09] <seb128> chrisccoulson, didrocks: did you guys have a good weekend too?
[10:10] <chrisccoulson> seb128 - yeah, it was quite relaxing. we had some family round on sunday, but i didn't do very much really
[10:10] <chrisccoulson> i did change the tracker packaging quite a bit yesterday afternoon though
[10:10] <didrocks> seb128: well, tiring one. Help me brother moving. More than 22 hours in train/truck during the 3 days and he was on the 5th floor. Consequently, no more leg, can hardly walk :)
[10:11] <didrocks> s/me/my
[10:12] <seb128> didrocks, so happy to be back to the computer? ;-)
[10:12] <didrocks> seb128: oh, more than happy indeed :-)
[10:12] <chrisccoulson> didrocks - no elevator to the 5th floor?
[10:12] <didrocks> chrisccoulson: no :(
[10:13] <didrocks> 3500 kgs of stuff for 4 people is quite a lot at the end of the week-end :-)
[10:13]  * didrocks looks forward to next week-end to do *nothing* TBH
[10:35] <pitti> hey seb128, good morning chrisccoulson
[10:35] <seb128> hey pitti
[10:36] <seb128> had a good week end too?
[10:36] <pitti> seb128: yes, very relaxing; we went for a nice hike, some bowling, and meeting some friends
[10:36] <pitti> and my cold is much better
[10:38] <milanbv> pitti: why does Apport refuse to report crashes from abort()?
[10:39] <chrisccoulson> kklimonda|G1, i'm going to upload an updated gnome-screensaver package to my PPA shortly. i would appreciate you testing it when you get the chance to see if it solves bug 555870 for you
[10:39] <milanbv> sometimes some daemon is crashing, and it says it doesn't want to file the bug, which is a little disappoiting ;-)
[10:39] <pitti> milanbv: usually they come from assertion violations
[10:39] <pitti> milanbv: for standard C assert macro and glib's g_assert_* stuff it is able to capture the actual assertion message, and sends a report
[10:40] <kklimonda|G1> chrisccoulson: will do it tonight, thanks for looking at it.
[10:40] <pitti> milanbv: but for programs which implement assertions for themselves, we can't grab the assertion message, thus the crash report would be useless
[10:41] <kklimonda|G1> pitti: for PP upload rights do i need endorsements from people who has worked on this package with me or from any developers who has worked with me?
[10:41] <milanbv> pitti: here I have forced reporting a desktopcouch-service abortion, and the stacktrace contains:
[10:41] <milanbv> assertion failed: ((int) res != INCOMPLETE)")
[10:41] <milanbv> which I think can be enough, isn't it?
[10:41] <milanbv> at least, if people report this, it's better than opening an empty report...
[10:51] <seb128> ok, down to 17 unread bug emails
[11:05] <chrisccoulson> pitti - would you be able to spare some time this week to remove some mozilla extensions from the archive for me? :)
[11:19] <pitti> chrisccoulson: yes, that's on my list; in fact, I was going to do it right now :)
[11:20] <chrisccoulson> pitti - excellent, thanks :)
[11:20] <chrisccoulson> so, the removal list is here: https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/extension-list
[11:20] <chrisccoulson> the extensions that need removing have "Remove" in the action column
[11:20] <mvo> chrisccoulson: this stuff needs to go from app-install-data as well then, could you mail me the names of the removal or ask someone in the mozilla team to update the app-install-data branch?
[11:21] <chrisccoulson> mvo - that someone in the mozillateam will probably be me ;)
[11:21] <chrisccoulson> yeah, i will do that too, thanks for pointing that out (i would have overlooked that otherwise)
[11:23] <mvo> chrisccoulson: cool, thanks
[11:24] <pitti> chrisccoulson: I wondered why you kept livehttpheaders ?
[11:24] <pitti> chrisccoulson: or mozilla-noscript?
[11:26] <Damascene> any one can contact the owner of the mail list?
[11:26] <chrisccoulson> pitti - i think asac requested mozilla-noscript
[11:27] <chrisccoulson> pitti - and livehttpheaders falls in to the "popular with users according to popcon" category, but i'm quite indifferent about that one tbh
[11:27] <chrisccoulson> i'm ok with removing that
[11:28] <kklimonda|G1> chrisccoulson: are yo rtemoving those extensions only for lifeless TheMuso s?
[11:28] <kklimonda|G1> o.o
[11:29] <chrisccoulson> kklimonda|G1, i'm not sure i understand the question
[11:29] <kklimonda|G1> chrisccoulson: are you removing those extensions only for LTS?
[11:30] <chrisccoulson> kklimonda|G1, we're removing them permanently, starting with the LTS
[11:30] <kklimonda|G1> damn - i really like the ability to install all my extensions using apt-get
[11:31] <chrisccoulson> kklimonda|G1, it's quite easy to install them from a.m.o though (and we're only removing ones that are easy to install)
[11:31] <james_w> kenvandine: hey, did you see https://code.edge.launchpad.net/~sune-keller/empathy/fix-533857/+merge/22762 ? (Not urgent, just not sure if LP will have mailed you)
[11:31] <chrisccoulson> kklimonda|G1, the issue with the extensions is that they are going to become a maintenance burden in the future when we start tracking major firefox versions in stable releases
[11:32] <pitti> chrisccoulson: ok, removed, blacklisted, https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/extension-list updated
[11:32] <chrisccoulson> so we want to keep the number to an absolute minimum
[11:32] <pitti> much more green now :)
[11:32] <chrisccoulson> pitti - excellent, thanks :)
[11:32] <pitti> chrisccoulson: please feel free to reiterate and remove more :)
[11:33] <chrisccoulson> pitti - no worries. i'm sure the list will be under constant review, as debian package more extensions
[11:33] <pitti> chrisccoulson: (e. g. our enigmail is currently totally broken, and stumbleupon/livehttpheaders/etc. might go as well)
[11:33] <pitti> and webdeveloper
[11:33] <pitti> the addons management in firefox is quite good, after all
[11:34] <chrisccoulson> pitti - yeah, i was planning to update stumbleupon. i don't want to remove that, as that's quite a popular and well maintained extensions
[11:34] <chrisccoulson> and the webdeveloper addon is broken due to a debian change
[11:34] <chrisccoulson> they change the maximum version number to 3.5.x :-/
[11:36] <james_w> kenvandine: ah, just seen you assigned the bug to yourself yesterday, sorry for the noise
[12:12] <dpm> hi mvo, when you've got some time, do you think you could look at bug 430926? It's about making the friendly-recovery package using the translations, and kelemengabor submitted a branch for the fix already
[13:16] <mvo> dpm: thanks, looking
[13:17] <Keybuk> gnargh!
[13:17] <Keybuk> I'm so filing a bug
[13:17] <Keybuk> someone moved the buttons around on the windows
[13:17] <Keybuk> I keep maximising instead of closing!
[13:19] <didrocks> Keybuk: you mean, the close button on the extreme right?
[13:19] <Keybuk> extreme left
[13:21] <didrocks> Keybuk: yeah, extreme left, sorry. Yeah, that's either in the bug report or in mark's blog post. That's an sabdfl's decision in any case.
[13:22] <dpm> thanks mvo!
[13:25] <didrocks> dpm: hey, I've repushed a new version in my quickly translation import branch. Can you ping the LP guys to know why autoimport doesn't work?
[13:28] <dpm> didrocks, done pinging, let me come back to you when they give us an answer
[13:28] <didrocks> dpm: awesome, thanks!
[13:45] <kenvandine> james_w, no worries, i hadn't gotten an email but did get an irc ping
[13:45] <Sarvatt> \o/ clutter app close xserver segfaults fully fixed here on 4 machines, the quadrapassel artifacts I was seeing were just with xorg-edgers packages
[13:46] <james_w> kenvandine: cool
[13:47] <seb128> Sarvatt, waouh!
[13:47] <seb128> njpatel, ^
[13:51] <dpm> didrocks, the template seems to have been imported now. Not sure what happened but the repush might have done the trick -> https://translations.edge.launchpad.net/quickly/0.x/+imports
[13:53] <didrocks> dpm: sweet! Let's hope than autoexport will work the same. I'll keep you in touch!
[13:53] <didrocks> hey james_w
[13:53] <dpm> didrocks, :)
[13:54] <james_w> salut didrocks
[13:58] <Sarvatt> btw are you guys targetting UNE to intel netbooks? you may want to consider exporting CLUTTER_VBLANK=none globally because apparently its using glXGetVideoSyncSGI which is insanely slow on intel and GLX_SGI_swap_control isn't being advertised for some reason.. it makes my system on the order of 10x slower having mutter or netbook-launcher open with wait_video_sync blanking
[13:58] <zyga> re, empathy is crashy lately :-(
[13:59] <Sarvatt> trying to look into getting GLX_SGI_swap_control advertised again
[13:59] <didrocks> njpatel: you have more knowledge than I on that… ^
[14:01] <zyga> mvo: do you have any hints on how to reproduce #540790
[14:01] <zyga> mvo: mmm, maybe I could remove all the keys...
[14:01] <zyga> mvo: but that wouldn't make it possible to test the actual fix (inconsistent repo -> update -> consistent repo)
[14:02] <mvo> zyga: rm /var/lib/apt/lists/*.gpg
[14:02] <mvo> zyga: that will make all packages unauthenticated
[14:02] <zyga> mvo: thanks, I'll check it out
[14:10] <dpm> didrocks, I also noticed that on http://bazaar.launchpad.net/~quickly/quickly/trunk/files/head%3A/data/templates/ubuntu-pygame/help/po/ the tutorial might not be imported because it lacks the .pot extension. (or at least that's why I believe it hasn't been imported)
[14:12] <didrocks> dpm: oh right, I have to bzr add after releasing (as the .pot is generated from the xml built at build-time). Thanks! :)
[14:12] <baptistemm> hello
[14:13] <didrocks> salut baptistemm
[14:19] <zyga> mvo: AptdaemonBackend.reload() would be enough to do 'apt-get update' in background/
[14:20] <mvo> zyga: yes, that should work
[14:29] <Sarvatt> no chance of getting GLX_SGI_swap_control exposed with our xserver-xorg-video-intel and xserver versions in lucid, darn
[14:41] <njpatel> Sarvatt, sorry, didn't see didrocks ping
[14:41] <njpatel> Sarvatt, didrocks: running CLUTTER_VBLANK=none with netbook launcher shouldn't cause any issues
[14:42] <njpatel> However having it global will effect Mutter-based stuff (well, shell :) when viewing videos etc, though I don't know how bad it'll be
[14:42] <didrocks> njpatel: I saw you told that with < karmic. Is it still true with karmic and lucid version? Shall we use that in the session file?
[14:42] <njpatel> didrocks, having it local to netbook-launcher would be the way to go, yeah
[14:42] <didrocks> njpatel: ok, so only for netbook-launcher would make sense
[14:42] <didrocks> njpatel: will do that if you think it won't hurt too badly the netbook-launcher visual effects
[14:43] <didrocks> (as it deactivates some, right?)
[14:43] <njpatel> didrocks, it won't, I don't think we do anything intense enough for it to cause any artefacts
[14:44] <didrocks> njpatel: sweet! will do so :)
[14:46] <rickspencer3> good morning all
[14:47] <seb128> hey rickspencer3
[14:47] <seb128> how are you?
[14:47] <rickspencer3> okay
[14:47] <rickspencer3> je suis fatigue
[14:47] <seb128> oh ?
[14:48] <Damascene> I've been trying to send to the mail list for the past four days no luck
[14:48] <Damascene> I got a message some cerimanl killing it with score 3.7
[14:48] <seb128> rickspencer3, ah oui, les états-unis avait pas de weekend ralongé
[14:49] <rickspencer3> mmmm
[14:49] <rickspencer3> non
[14:49] <rickspencer3> les etats-unis avait pas de weekend normal
[14:50] <seb128> "avait un weekend"?
[14:50] <seb128> ie you had a normal 2 days weekend?
[14:50] <rickspencer3> oui
[14:50]  * seb128 hugs you
[14:51] <rickspencer3> j'ai travaille juni
[14:51]  * seb128 hugs rickspencer3
[14:51] <seb128> rather
[14:51] <seb128> "lundi"
[14:51] <rickspencer3> nice break seb128?
[14:51] <seb128> was great to have a long weekend
[14:51] <seb128> yes!
[14:51] <rickspencer3> good
[14:51] <seb128> I needed it after the previous crazy weeks
[14:51] <seb128> I'm pretty good today ;-)
[14:51] <rickspencer3> good to hear
[14:52] <seb128> I almost finish dealing with the weekend backlog and tuesday paperwork
[14:52] <rickspencer3> I have no crazy things to add to your liest
[14:52] <rickspencer3> list, even
[14:52] <seb128> good ;-)
[15:02] <pitti> hey rickspencer3, how are you?
[15:02] <rickspencer3> hi pitti
[15:02] <rickspencer3> I am quite well
[15:02] <rickspencer3> how are you?
[15:02] <rickspencer3> was the break good?
[15:02] <pitti> rickspencer3: I'm great; cold is much better, and 4 days break was very relaxing; we went hiking with the family, some bowling, meeting some old friends, etc.
[15:03] <rickspencer3> and some bug triaging, pitti? ;)
[15:03] <pitti> rickspencer3: just a little :)
[15:03] <rickspencer3> well, whatever relaxes you, I suppose ;)
[15:03] <pitti> I caught up on some Debian stuff, and wanted to cut a first dent into my mailbox yesterday
[15:03] <rickspencer3> oh, that's great
[15:06] <rickspencer3> ccheney, good morning
[15:07] <rickspencer3> ccheney, I see you have bug #450569 with some open bug tasks
[15:07] <rickspencer3> are you planning more work there?
[15:31] <ccheney> rickspencer3: its only open under docvert and doesn't really need to be fixed afaik
[15:32] <ccheney> rickspencer3: the part assigned to me was already fixed for lucid anyway
[15:32] <rickspencer3> ccheney, well, are the other tasks going to get fixed?
[15:32] <rickspencer3> if not, can we "won't fix" them?
[15:32] <rickspencer3> basically, I'm tired of this bug showing up in our Release Critical bug list :)
[15:32] <ccheney> rickspencer3: people keep playing with the status of them
[15:33] <ccheney> rickspencer3: i'm trying to look to see if it was considered fixed before, looking through the lists of status changes
[15:33] <ccheney> rickspencer3: the only open tasks aren't listed as release critical
[15:33] <ccheney> but mitch fixed the part of the status for OOo that someone was messing with
[15:34] <ccheney> the only way we can fix this long term is if someone on the launchpad team makes it so that random lp users can't change the status of bugs after they are marked fixed
[15:34] <mvo> ccheney: speaking of OOo, could you please check #556348 ? it contains a fix as well
[15:34] <ccheney> i often get people going by and changing status of bugs (not usually for RC bugs) without even commenting on them
[15:34] <ccheney> mvo: looking
[15:38] <ccheney> mvo: ok will add that back, i think it must have gotten dropped during a merge and/or when looking at the deps for the other pre-dep rc bug, not really sure
[15:39] <mvo> ccheney: ok, thanks for adding it back
[15:58] <Nafai> Good morning
[15:59] <didrocks> hey Nafai
[15:59] <Nafai> Hey didrocks
[16:02] <seb128> hey Nafai
[16:02] <chrisccoulson> hey Nafai
[16:03] <Nafai> Hi everyone :)
[16:17] <rickspencer3> hi Nafai
[16:20] <pitti> kenvandine, rickspencer3: any troubles in the release team meeting? and thanks for covering
[16:21] <kenvandine> pitti, nope
[16:30] <rickspencer3> kenvandine, how's the giwbber refactoring going?
[16:35] <kenvandine> rickspencer3, pretty frustrating, let me comment more at the meeting
[16:35] <rickspencer3> kenvandine, ack
[16:35] <rickspencer3> kenvandine, would another person working on it help you?
[16:36] <kenvandine> doubt it...
[16:36] <kenvandine> unless it was someone with a magical answer :)
[16:37]  * Nafai gets out his crystal ball
[17:06] <seb128_> pitti, how did you fix the vino color issue?
[17:07] <pitti> seb128_: removed the "gtk-tooltip" style from that status bar
[17:07] <pitti> now it uses the same colors as the rest of the fialog
[17:07] <pitti> dialog
[17:07] <seb128_> pitti, hum, k, I was not sure if it was there for a reason and reluctant to drop it
[17:07] <pitti> which is much less prone to damage from themes, at least
[17:07] <seb128_> let's see how it goes
[17:07] <pitti> well, it should really be a GtkStatusBar, but that'd be new code
[17:08] <seb128_> right
[17:08] <seb128_> did you forget to push your change btw?
[17:08] <pitti> seb128_: I didn't push it at all -- no Vcs-Bzr:
[17:08] <pitti> is there a branch for it?
[17:09] <seb128_> standard lp:~ubuntu-desktop/vino/ubuntu
[17:09] <pitti> Vcs-Svn: svn://svn.debian.org/svn/pkg-gnome/desktop/unstable/vino
[17:09] <pitti> hmm
[17:09] <pitti> seb128_: ok, I'll reject the upload, and reupload with fixed vcs-*
[17:09] <seb128_> pitti, thanks
[17:13] <pitti> seb128_: done
[17:14] <seb128_> pitti, thanks
[17:14] <seb128_> hum
[17:17] <ccheney> wow my annoying desktop loses several minutes a week it seems
[17:19]  * ccheney runs ntp hoping it works better
[17:19] <ccheney> too bad ntpdate doesn't run except on startup, i never reboot
[17:21] <seb128_> james_w, I'm not sure I like bzr reviews on launchpad :p
[17:21] <james_w> seb128_: why's that?
[17:21] <seb128_> james_w, I just noticed that you were discussing this g-s-d change there but the bug side gets no update about that
[17:22] <seb128_> those comments are interesting and should be in the bug
[17:22] <james_w> yeah, it's frustrating the other way too
[17:23] <seb128_> I'm wondering if also I should be getting emails about this review
[17:23] <seb128_> since I'm subscribed the ubuntu package on launchpad
[17:23] <james_w> hmm
[17:23] <seb128_> I get the bugs and comments about those but not the review comments
[17:24] <james_w> you are subscribed to the bugs for the package
[17:24] <seb128_> which means I'm somewhat tracking what's happening there but not quite
[17:24] <james_w> but there's a separate subscription for the code review
[17:24] <seb128_> hum
[17:24] <seb128_> k
[17:24] <james_w> and LP currently has no concept of subscribing to the package as a whole
[17:24] <seb128_> I need to think about what how I would like it to be working
[17:24] <james_w> we can get you subscribed to all the code review
[17:24] <seb128_> I don't like how it works now ;-)
[17:24] <james_w> yeah
[17:25] <seb128_> no thanks
[17:25] <james_w> we can certainly get you more emaill :-)
[17:25] <seb128_> lol
[17:25] <seb128_> I think I will be fine without that thank you
[17:25] <seb128_> I think I would suggest that review comments should be available on the bug concerned too
[17:26] <seb128_> though I'm not sure that would be right either
[17:27] <seb128_> james_w, thanks for reviewing that change btw ;-)
[17:27] <james_w> np
[17:28] <james_w> I'll be sure to speak to you about GNOME changes that come in as code reviews
[17:28] <seb128_> that's ok, I don't want to create extra work for you
[17:28] <seb128_> and now that I know comments might be going in the review I will watch for those ;-)
[17:30] <rickspencer3> team meeting time?
[17:31] <seb128> rickspencer3, yes
[17:31]  * tseliot nods
[17:31]  * ArneGoetje waves
[17:31] <didrocks> o/
[17:31] <ccheney> here
[17:32] <rickspencer3> ArneGoetje, bryce_, ccheney, chrisccoulson, didrocks, kenvandine, Nafai, pitti, Riddell, seb128, tkamppeter, tseliot
[17:32] <rickspencer3> hi
[17:32] <rickspencer3> who am I missing?
[17:32] <tkamppeter> hi
[17:32] <Nafai> o/
[17:32] <pitti> o/
[17:32] <james_w> seb128: bug 556656
[17:32] <rickspencer3> two things before start
[17:32] <Riddell> hi
[17:32] <bryce_> hi
[17:32] <seb128> james_w, thanks
[17:32] <chrisccoulson> hi
[17:32] <rickspencer3> 1. Hi Nafai - welcome to your first team meeting!
[17:33]  * tseliot waves
[17:33] <Nafai> Yay!  Thanks.
[17:33] <rickspencer3> all Nafai started last Thursday
[17:33] <rickspencer3> he'll be working with didrocks on UNE in 10.10, and also I am hoping on some application developer focused areas
[17:33] <rickspencer3> (and if something else interests him as well)
[17:33] <rickspencer3> Nafai, what's you real name, and why "Nafai"?
[17:34] <Nafai> Travis Hartwell; back when I started with IRC in the 90's the network I was on 'travis' was taken, so I chose a name from some books I was reading at the time.  The Homecoming series by Orson Scott Card
[17:34] <Nafai> It's kind of stuck
[17:34] <rickspencer3> kewl
[17:35] <rickspencer3> Nafai, based in Utah, USA, correct?
[17:35] <Nafai> Yes
[17:35] <rickspencer3> excellent
[17:35] <rickspencer3> Nafai, pitti is your tech lead for the rest of 10.04
[17:35] <rickspencer3> seb128, will be fore 10.10, we'll have a call soon
[17:35] <Nafai> ok
[17:35] <rickspencer3> but anyone here will be glad to help you with anything, i am sure
[17:36]  * pitti puts on the "No, I won't fix your computer!" T-shirt
[17:36]  * tseliot nods
[17:36] <rickspencer3> hehe
[17:36] <didrocks> welcome Nafai ;)
[17:36] <rickspencer3> okay, except for pitti anyone will help with anything
[17:36] <rickspencer3> ;)
[17:36] <seb128> ;-)
[17:37] <rickspencer3> also before we start, I think kenvandine won't be able to join us this morning, so we'll skip his parts and pick them up in the Eastern Edition if he is available then
[17:37] <rickspencer3> let's rock
[17:37] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-04-06
[17:37] <rickspencer3> Riddell, kubuntu update?
[17:37] <Riddell>  * beta 2 in good shape but some issues with installer in current images means rebuild needed
[17:37] <Riddell>  * http://tinyurl.com/yjybcx9 15 milestoned bugs.  three have fixes committed.  if current fix rate continues we should be all fixed up before release
[17:37] <Riddell> that's it, very quick this week :)
[17:38] <rickspencer3> thanks Riddell
[17:38] <rickspencer3> next is 10.10 blueprints
[17:38] <rickspencer3> yeah!
[17:38] <rickspencer3> time to start seriously thinking about 10.10 and what you want to accomplish there
[17:39] <rickspencer3> for the first step, I would like everyone to generate a list of blueprints they want to bring to UDS
[17:39] <rickspencer3> note that the requirement is just for a *list*
[17:39] <rickspencer3> writing the blueprints will be the next phase
[17:39] <rickspencer3> I'd like everyone to have a list by the next team meeting
[17:39] <Riddell> isn't writing done at UDS?
[17:39] <pitti> s/at/after/
[17:40] <rickspencer3> Riddell, well, yes and no
[17:40] <pitti> but the stubs and summary should be there before
[17:40] <pitti> we need that for scheduling/planning
[17:40] <rickspencer3> I expect there to be good thought put into them before they are accepted and such
[17:40] <pitti> the actual meat (wiki page/work items) are after UDS
[17:40] <rickspencer3> Riddell, but I get your  point
[17:40] <rickspencer3> I guess rather than "written" I should have said "registered"
[17:41] <rickspencer3> now, I am betting some of the newer folks are thinking "wtf?"
[17:41] <rickspencer3> no worries
[17:41] <Nafai> :)
[17:41] <chrisccoulson> heh
[17:41] <rickspencer3> if you don't know what blueprints to write, or how to register them and such ... please ping me out of band
[17:41] <rickspencer3> we'll get together with pitti and seb128 and step you through it
[17:41] <rickspencer3> but I would like to see everyone with a list by next Tuesday
[17:42] <rickspencer3> any questions?
[17:42] <seb128> where do we put the lists?
[17:42] <rickspencer3> seb128, good question
[17:42] <rickspencer3> shall we add them to the blueprint list wiki page I started?
[17:42] <pitti> how about just registering stubs?
[17:43] <pitti> desktop-maverick-frobnicate
[17:43] <ccheney> don't they need to be registered to be scheduled anyway?
[17:43] <seb128> I don't like much doing registration for random first thinking round
[17:43] <rickspencer3> pitti, that's good too
[17:43] <seb128> it creates quite some noise
[17:43] <ccheney> seb128: ah i see your point
[17:43] <pitti> seb128: for those, just put them into your weekly report, and keep a local list?
[17:43] <seb128> wiki or in the activity reports?
[17:43] <rickspencer3> pitti, since seb128 is tech lead for 10.10, I will delegate the decision to him, sound ok?
[17:43] <pitti> ack
[17:44] <seb128> there we go ;-)
[17:44] <rickspencer3> seb128, be careful what you ask for ;)
[17:44]  * rickspencer3 watches pitti wash hands
[17:44] <rickspencer3> :)
[17:44] <pitti> so, everyone snailmail them to seb128, in proper French language!
[17:44] <seb128> lol
[17:44] <didrocks> pitti: no pb ;)
[17:44] <rickspencer3> hehe
[17:44] <seb128> soooooo
[17:45] <rickspencer3> (https://wiki.ubuntu.com/DesktopTeam/10.10/BlueprintList)
[17:45] <seb128> register those you are sure about on launchpad using desktop-maverick-* + add those you want to discuss in your activty report?
[17:45] <pitti> rickspencer3: will take me a bit to stop taking decisions and jumping on every question :)
[17:45] <rickspencer3> pitti == Ubuntu Desktop :)
[17:45] <seb128> rickspencer3, would that work for you?
[17:46] <rickspencer3> seb128, sure
[17:46] <seb128> or do you prefer using the wiki, easier maybe to list in one spot and do changes
[17:46] <rickspencer3> seb128, well, you'll be organizing them, so it's what's easier for you
[17:46] <rickspencer3> ;)
[17:46] <rickspencer3> though I would like to take a look at everything next week, so folks can ask each other questions
[17:46] <seb128> ok, so register + activity report
[17:46] <pitti> seb128: NB that the desktop meeting page will have all activity reports in one wiki page anyway :)
[17:46]  * rickspencer3 hears pitti chuckly
[17:46] <seb128> we can discuss those in the activity report page in next meeting
[17:47] <seb128> and review the list in launchpad too
[17:47] <rickspencer3> ok
[17:47] <rickspencer3> seb128, I'll put you down for that agenda item
[17:47]  * kenvandine waves
[17:47] <seb128> ok
[17:47] <seb128> hey kenvandine
[17:47] <rickspencer3> hi kenvandine, are you back?
[17:47] <kenvandine> yeah
[17:47] <pitti> ... and kenvandine will fix everything then, as decided
[17:47] <pitti> oh, hi kenvandine!
[17:47] <kenvandine> hehe
[17:47] <kenvandine> :)
[17:48] <rickspencer3> kenvandine, can you touch on partner status and gwibber briefly?
[17:48] <kenvandine> yup
[17:49] <kenvandine> sorry i didn't update the wiki with the partner update, been beating on gwibber
[17:49] <kenvandine> OLS has a bug fix coming today, fixing the contact picker for file sharing
[17:49] <kenvandine> of course it'll just get queued, nothing that needs to break release
[17:50] <kenvandine> they are also working hard on desktopcouch
[17:50] <kenvandine> chad has a branch in review that works around the keyring problem
[17:50] <kenvandine> but it is a pretty big refactor
[17:51] <rickspencer3> so no more desktopcouch-se == 100% CPU?
[17:51] <kenvandine> the good news for them is he has narrowed the bug down to specific versions of libgnome-keyring0
[17:51] <kenvandine> i haven't been successful doing that in gwibber
[17:51] <kenvandine> rickspencer3, right
[17:51] <seb128> did he narrow down the issue to a changeset?
[17:52] <kenvandine> he thought he did, but i patched that out and still got the issue
[17:52] <kenvandine> he was trying to do that yesterday afternoon, last i heard he hadn't found the specific commit
[17:52] <seb128> ok
[17:52] <seb128> it would be useful if he could find the commit
[17:52] <kenvandine> yeah, i think that is what he worked on all day yesterday
[17:53] <seb128> k
[17:53] <kenvandine> in gwibber i think it is the combination of multiprocessing and threads
[17:53] <kenvandine> perhaps we are spamming the keyring via dbus
[17:53] <kenvandine> or something
[17:53] <kenvandine> more about that after the meeting
[17:53] <pitti> libdbus and threads is always an "interesting" combination
[17:53] <kenvandine> nothing urgent in the pipe for DX as far as i know
[17:53] <kenvandine> pitti, indeed
[17:53] <pitti> it keeps failing on me for anything but the main thread
[17:54] <kenvandine> pitti, it is the recipe for drinking heavily :)
[17:54] <kenvandine> doing that in gwibber would be a pretty significant code change :/
[17:54] <rickspencer3> ok, so a technical discussion for gwibber + keyring + threads right after the meeting?
[17:54] <kenvandine> yeah
[17:54] <rickspencer3> in that case, let's finish up ;)
[17:54] <kenvandine> i have a proposal
[17:54] <rickspencer3> pitti, release status?
[17:54] <seb128> speaking of dx, if you have dx issue which you think should be considered for lucid, let me or dbarth know
[17:55] <seb128> they are rocking their bugs list so might take over some extra issues for lucid ;-)
[17:55] <pitti> all beta-2 work items done since last week, good job
[17:55] <kenvandine> :)
[17:55] <seb128> pitti, \o/
[17:55] <pitti> http://people.canonical.com/~pitti/workitems/canonical-desktop-team-ubuntu-10.04.html is looking fine
[17:55] <pitti> no actual work items for us except to disable "file a bug" menu
[17:56] <pitti> which we don't expect any problems with
[17:56] <pitti> I'm a bit more concerned about the large number of open bugs still
[17:56] <seb128> it's in the ubuntu-desktop ppa now
[17:56] <seb128> if you want to test
[17:56] <seb128> the lpi change
[17:56] <pitti> remember that we basically have just one week left for the final push, then we'll go into final freeze
[17:57] <pitti> https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus is pretty up to date, FYI
[17:57] <ccheney> what is the 'file a bug' issue is it something i need to change in OOo also, as it doesn't use lpi lib directly?
[17:57] <pitti> ccheney: good point; we want to drop the menu item for final
[17:57] <ccheney> pitti: is there a url about the issue?
[17:58] <pitti> ccheney: well, it isn't a "must do", but it might help thinning the firehose of really bad bug reports that we get
[17:58] <pitti> ccheney: https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-bug-management
[17:58] <rickspencer3> pitti, I see that tseliot has a certain number of bugs still open, tseliot are you on track, or do you want some help prioritizing?
[17:58] <ccheney> pitti: ok
[17:59] <ccheney> pitti: i'll talk to you more about it offline
[17:59] <pitti> chrisccoulson: on that note, bug 447431 is still alive in current lucid :(
[17:59] <chrisccoulson> pitti - yeah, slangasek said
[17:59] <pitti> but at this point, nothing more from me; any questions?
[17:59] <chrisccoulson> i'm surprised about that though, as upstream ignore the error that caused the original crash now :-/
[17:59] <tseliot> rickspencer3: I know but I can deal with them. I plan on fixing a fair amount in the next few days
[17:59] <pitti> ccheney: does 3.2.1 have any chance to land still?
[18:00] <ccheney> pitti: no, its still not released yet and i doubt it will be by next week
[18:00] <pitti> ccheney: is 3.2.0 "good enough"?
[18:00] <pitti> we might provide 3.2.1 in 10.04.1
[18:00] <ccheney> pitti: we could stick it in a SRU if someone wants it, but 3.2.0 is probably good enough
[18:00] <ccheney> pitti: of course i keep getting rc bugs at the last minute so 3.2.1 might be helpful as an sru in a month or two
[18:01] <pitti> ccheney: that sounds fine. .1 is three months from now
[18:01] <ccheney> pitti: ok yea that sounds fine
[18:01] <pitti> rickspencer3: back to you
[18:01] <Nafai> Remind me what SRU is?
[18:01] <ccheney> stable release update
[18:01] <rickspencer3> thanks pitti
[18:01] <Nafai> thanks
[18:01] <ccheney> Nafai: normally updates are only for security issues
[18:02] <rickspencer3> Nafai, so it's like when users get an update in update manager
[18:02]  * Nafai nods
[18:02] <rickspencer3> they are either fixes for grave problems or trivial fixes (very low rist)
[18:02] <rickspencer3> risk, even
[18:02] <chrisccoulson> Nafai, see https://wiki.ubuntu.com/StableReleaseUpdates
[18:02] <rickspencer3> but with an LST we plan a couple of point releases
[18:02] <rickspencer3> ok
[18:02] <rickspencer3> Any other business?
[18:03] <rickspencer3> ok
[18:04] <rickspencer3> let's call that a wrap, and move on to discussing gwibber
[18:04]  * rickspencer3 taps gavel
[18:04] <kenvandine> sigh... :)
[18:04] <didrocks> thanks, good luck kenvandine :)
[18:04] <seb128> thanks
[18:04] <kenvandine> http://pastebin.ubuntu.com/410129/
[18:04] <kenvandine> a test case that works fine calling the keyring
[18:05] <kenvandine> gwibber does something like that, but mixes in data from desktopcouch and the actual processing happens via map_async in mulitprocessing.Pool
[18:06] <kenvandine> if i remove the gobject.threads_init() it mostly works... no CPU load issues at all
[18:06] <kenvandine> but then the async callbacks never get called
[18:06] <kenvandine> and everything that depends on that breaks
[18:06] <kenvandine> but the keyring calls are fine
[18:07] <kenvandine> as a test i made the method that is called by map_async call a dbus method and it got a ton of errors from dbus, duplicate, already called with the same signature
[18:07] <kenvandine> something like that
[18:08] <kenvandine> it looked like it just made 10 dbus calls to the same method at the same time and dbus didn't like that, so a hunch is now that the keyring is using dbus perhaps that is a problem
[18:08] <kenvandine> but i can't confirm that
[18:09] <kenvandine> anyone have ideas?
[18:09] <seb128> I don't
[18:10] <seb128> chrisccoulson, james_w and pitti have been discussing dbus issues in the past they might have an idea on the issue
[18:10] <seb128> or Keybuk
[18:10] <kenvandine> at this point i think the most prudent thing to do is back out the keyring change... or at least disable it
[18:10] <kenvandine> without the keyring call, it seems fine
[18:10] <Keybuk> that sounds more like dbus-glib than dbus
[18:11] <kenvandine> perhaps
[18:11] <kenvandine> i am not getting any errors though
[18:11] <james_w> kenvandine: what's a likely secret id I can substitute to run this?
[18:12] <kenvandine> chad's work around for desktopcouch is move all the keyring calls out to the main thread
[18:12] <kenvandine> look in couch
[18:12] <kenvandine> or better
[18:12] <kenvandine> in your keyring
[18:12] <kenvandine> in fact
[18:12] <kenvandine> just find any id in your login keyring
[18:12] <kenvandine> and use that
[18:12] <kenvandine> look in seahorse
[18:15] <kenvandine> james_w, thing is, i can't reproduce the problem with a simple script like that
[18:15] <kenvandine> let me add mulitprocessing stuff to it
[18:15] <james_w> right, but a working example is a good place to start
[18:15] <james_w> what's the id I should take from seahorse? "Name"?
[18:16]  * Nafai heads off to lunch
[18:16] <Nafai> bbl
[18:16] <kenvandine> james_w, in the details tab
[18:16] <james_w> "desktopcouch: oauth"
[18:17]  * mvo has read "autsch"
[18:17] <didrocks> Nafai: enjoy!
[18:21] <james_w> kenvandine: ?
[18:21] <kenvandine> yeah?
[18:21] <kenvandine> {"desktopcouch": str("oauth")})[0].secret
[18:22] <james_w> ok, thanks
[18:23] <james_w> I thought everything had an id
[18:23] <james_w> and I had to work out the id of one that I have
[18:23] <kenvandine> sorry, no... it is arbitrary i think
[18:35] <kenvandine> http://pastebin.ubuntu.com/410145/
[18:35] <kenvandine> james_w, that test pegs the CPU
[18:38] <kenvandine> or anyone else that wants to look at it
[18:40] <rickspencer3> Nafai, you worked on twisted, right?
[18:41] <kenvandine> twisted... shiver
[18:42] <rickspencer3> kenvandine, well, that's all async and crazy, right?
[18:42] <kenvandine> yrah
[18:42] <rickspencer3> so maybe Nafai has some insight into this
[18:42] <kenvandine> yeah
[18:42] <kenvandine> that would rock :)
[18:42] <rickspencer3> but he's having lunch
[18:42] <rickspencer3> he succumed to his physical needs
[18:42] <rickspencer3> this is why have transfered my ghost into the net
[18:43] <kenvandine> i am about to eat myself :)
[18:43] <rickspencer3> ^lame gits reference
[18:46] <chrisccoulson> kenvandine - i just ran your example python code there in GDB
[18:46] <chrisccoulson> it's messed up. the same GMainContext is being run in 2 different threads
[18:47] <chrisccoulson> and the glib documentation makes it quite clear that you can't do that
[18:47] <kenvandine> but any idea what is causing that?
[18:47] <chrisccoulson> "To allow multiple independent sets of sources to be handled in different threads, each source is associated with a GMainContext. A GMainContext can only be running in a single thread, but sources can be added to it and removed from it from other threads."
[18:47] <james_w> ok, now we're cooking
[18:48] <chrisccoulson> kenvandine, yeah, i suspect that the keyring call goes in to the mainloop for a bit whilst it waits for the return values from dbus
[18:48] <kenvandine> chrisccoulson, so if you comment out gobject.threads_init() all is peachy
[18:48] <kenvandine> but of course then you don't get the callbacks
[18:48] <chrisccoulson> kenvandine, i didn't try that yet, but i suspect it will be
[18:48] <kenvandine> which in the case of gwibber tons of things rely on
[18:48] <chrisccoulson> one second
[18:49] <kenvandine> i tried moving to gtk.gdk.threads_init and using threads_enter and threads_leave
[18:49] <kenvandine> but had the same issue
[18:49] <kenvandine> same thing for using gtk.gdk.lock
[18:49] <kenvandine> seems having those parallel processes causes havoc if threads are enabled
[18:50] <rickspencer3> kenvandine, sorry if this is stupid, but could you signals instead of call backs for the between thread communication?
[18:50] <rickspencer3> (and I mean __gsignal__ stuff)
[18:51] <kenvandine> not sure how that works with multiprocessing
[18:51] <kenvandine> they are separate processes
[18:51] <kenvandine> but there must be a way, not sure if it would help
[18:51] <kenvandine> or you mean drop multiprocessing?
[18:51] <chrisccoulson> kenvandine, i've missed most of what you've been discussing, but why does the gnome keyring call need to run in it's own thread?
[18:51] <rickspencer3> no
[18:52] <kenvandine> chrisccoulson, it is running in a thread that is used to process an operation, like for example download a feed from twitter
[18:52] <kenvandine> etc
[18:52] <kenvandine> post to identica, blah blah blah
[18:53]  * rickspencer3 steps away
[18:53] <chrisccoulson> kenvandine, so, even if you moved the gnome-keyring call to the main thread, you'd still end up with multiple threads all running the same GMainContext?
[18:53] <kenvandine> chrisccoulson, it could of course be refactored to not do the multiprocessing stuff... but that is quite a bit of refactoring for this close to release
[18:53] <kenvandine> yeah
[18:53] <chrisccoulson> ouch
[18:53] <chrisccoulson> that is really quite broken :(
[18:53] <kenvandine> well, but none of the other calls matter there
[18:53] <kenvandine> but indeed, there must be a way to handle that
[18:54] <chrisccoulson> kenvandine, so, essentially, you can't guarantee which threads certain events run in?
[18:54] <kenvandine> surely gwibber isn't the only app using both gobject and multiprocessing
[18:54] <chrisccoulson> if my understanding is correct
[18:55] <chrisccoulson> event sources are associated with a GMainContext, so if you run the same one in multiple threads, that's going to create quite a mess isn't it?
[18:56] <james_w> kenvandine: I dropped trying to use multiprocessing for something I was doing as it was sharing too much state with the child processes and breaking DBus interaction
[18:59] <chrisccoulson> when i ran the test script here, gdb showed both threads blocking on poll() with the same context, so if gwibber really does that then there is no way you can guarantee what thread each callback will run in (as each thread is going to race when an event source is ready)
[18:59] <chrisccoulson> or am i missing something here?
[18:59] <chrisccoulson> or being completely stupid?
[19:00] <kenvandine> humm
[19:01] <crimsun> TheMuso: you may need to switch (codec->subsystem_id):case 0x17aa4001:, but because I don't have the codec SSID for the u150 that's currently in HEAD, that's problematic. If you intend to support this in ubuntu-lucid.git, you'll need to backport the ideapad cxt5066 model & quirk from upstream.
[19:01] <kenvandine> chrisccoulson, but that is harmless right? it isn't blocking each other
[19:02] <kenvandine> chrisccoulson, and each thread is processing a different operation
[19:02] <kenvandine> i think the problem is calling the keyring call with that same context
[19:02] <chrisccoulson> kenvandine, no, that's definately not harmless. you'll end up with all sorts of locking issues in glib and in your code
[19:02] <kenvandine> and potentially other calls could do the same, but other than that i think it is pretty isolated
[19:03] <kenvandine> so your saying python multiprocessing can't be mixes with gobject?
[19:03] <kenvandine> s/mixes/mixed/
[19:03] <kenvandine>  python multiprocessing is specifically designed to share information between processes
[19:07] <crimsun> TheMuso: I've asked for alsa-info.sh dumps in the bug so that we can check the codec dump. One thing to test before jumping down the rabbit hole of modifying cxt5066_ideapad_automic() is whether the VREF needs to be set differently, since that would potentially be a much less intrusive change.
[19:11] <kenvandine> james_w, so you think we just need to drop multiprocessing?
[19:12] <james_w> kenvandine: I don't know
[19:12] <james_w> chrisccoulson's findings would suggest that you are suffering a similar issue
[19:12] <kenvandine> i don't see any specific problem solved by using multiprocessing here... but that is quite a bit of refactoring
[19:12] <kenvandine> yeah
[19:12] <kenvandine> which has been my suspicion
[19:13] <kenvandine> without the gobject threads, it is fine
[19:13] <kenvandine> and without multiprocessing it is fine... but mixing them is yucky
[19:14] <kenvandine> in fact... ryan dropped keyring integration back in the 1.x days because they were getting races with the keyring... perhaps it was related
[19:14] <kenvandine> this specific code in gwibber is very old...
[19:14] <james_w> there may be something we can do in limiting the amount of context that the parent passes to the child
[19:15] <james_w> my suspicion is that it is globals that are causing this, as they are copied, rather than getting different objects in the child
[19:15] <james_w> but I don't really understand why they look the same across address spaces
[19:16] <chrisccoulson> right
[19:17] <chrisccoulson> it seems that libgnome-keyring is not thread-safe anyway
[19:18] <chrisccoulson> in connect_to_service() in gkr-operation, it calls egg_dbus_connect_with_mainloop(conn, NULL), which causes it to use the default GMainContext (which is the one created in your parent thread)
[19:19] <chrisccoulson> so
[19:19] <chrisccoulson> you would need to do all the keyring stuff from your main thread
[19:20] <Guest279> Hello
[19:21] <Guest279> Anyone know about Restoring Partitions?
[19:21] <chrisccoulson> Guest279, #ubuntu is for support
[19:22] <Guest279> oh thanks
[19:23] <YokoZar> What package does someone mean when they say "the pthread library"
[19:23] <YokoZar> oops wrong channel
[19:25] <chrisccoulson> kenvandine, does that make more sense now? sorry, i don't know how far you got with debugging this before, so i might have repeated what other people already discovered
[19:25] <kenvandine> yes, that is helpful
[19:26] <kenvandine> doesn't make it clear what the right fix is :)
[19:36] <baptistemm> good evening
[19:37] <kenvandine> hey baptistemm
[19:37] <baptistemm> hello kenvandine
[19:44] <fta> kenvandine, chrisccoulson: why does transmission properly show & hide from the indicator applet while rhythmbox can't??
[19:45] <kenvandine> fta, you mean it toggles?
[19:45] <kenvandine> i think the spec says it should raise the window
[19:46] <fta> kenvandine, it clearly doesn't
[19:46] <kenvandine> you mean transmission doesn't?
[19:46] <Sarvatt> pitti: video=LVDS-1:d is your friend :)
[19:46] <fta> for transmission, it's mostly ok, with a few more steps, it's possible to raise / hide it
[19:46] <pitti> Sarvatt: ah, thanks for the hint
[19:47] <fta> for rhythmbox, it's totally broken
[19:47] <pitti> Sarvatt: still a bit sad to see the live CD not boot at all :(
[19:47] <fta> kenvandine, ^^
[19:47] <pitti> Sarvatt: "d" means "disable"?
[19:47] <fta> kenvandine, (i'm using metacity)
[19:47] <Sarvatt> yeah, :e for enable
[19:48] <fta> kenvandine, strangely, it was fine on my old desktop (lucid). it's broken on my fresh install (new system disk)
[19:49] <seb128> fta, how broken?
[19:49] <fta> can't hide it
[19:49] <kenvandine> fta, i don't think it is supposed to
[19:49] <kenvandine> i know with the old status icon it did toggle
[19:50] <fta> and i can only raise it if it was iconified/minified
[19:50] <kenvandine> ok, that seems like a bug... i just saw the same thing too
[19:50] <kenvandine> if it is open, but in the background
[19:50] <fta> not if it's visible in another workspace
[19:50] <kenvandine> it doesn't get raised
[19:50] <Guest279> Is this the place to ask a question?
[19:50] <kenvandine> seb128, wasn't that working before?
[19:50] <kenvandine> Guest279, no, #ubuntu for support
[19:50] <seb128> fta, I can hide it by closing the dialog using the x wm button
[19:50] <Guest279> oh
[19:50] <seb128> and show it using the indicator
[19:51] <kenvandine> seb128, don't close it but raise another window
[19:51] <kenvandine> then try showing it
[19:51] <seb128> but that might be because I changed the gconf key
[19:51] <seb128> it's claiming for attention
[19:51] <seb128> that's a known wm "bug" for years
[19:51] <kenvandine> yeah... but with the timestamps i thought it worked now?
[19:51] <kenvandine> it does raise when i close it or minimize it
[19:52] <seb128> it's not clear if the show call should show you the dialog where you are
[19:52] <seb128> or move you where the dialog is...
[19:52] <fta> seb128, well, i'm used to the old style tray where the "show" was a toggle, like transmission
[19:52] <kenvandine> i see
[19:52] <seb128> or claim for attention
[19:52] <kenvandine> fta, yeah... there has been much debate about that :)
[19:52] <seb128> fta, the indicators are menus, not toggles
[19:52] <seb128> ctrl-w not working is a known bug
[19:52] <fta> transmission clearly has a checkbox there
[19:52] <seb128> we should fix that
[19:53] <seb128> right, rhythmbox doesn't
[19:53] <seb128> we should check with mpt or design team what the behaviour should be
[19:53] <fta> it's confusing
[19:53] <seb128> it's inconsistant now
[19:53] <seb128> either we should have checkbox
[19:53] <kenvandine> seb128, i did back when we did the patch, they said should always raise not toggle
[19:53] <seb128> or close the dialog to hide it and a show item
[19:53] <seb128> right
[19:53] <seb128> that was my understanding too
[19:54] <seb128> close to close and use the menu to show
[19:54] <kenvandine> we did the same for empathy and pidgin
[19:54] <fta> you should gray/disable the show then
[19:54] <seb128> why?
[19:54] <seb128> it's showing
[19:54] <kenvandine> i guess whoever did the transmission work didn't follow the same guidelines
[19:54] <kenvandine> fta, you mean when it is already focused right?
[19:54] <seb128> the entry is still valid
[19:54] <fta> (if it's already visible)
[19:55] <seb128> well you can stil show it
[19:55] <seb128> it makes no graphical difference
[19:55] <seb128> but it's not buggy either
[19:55] <kenvandine> everything just needs to be consistent
[19:57] <fta> hm, even transmission has issues, xchat is on top, i call for transmission, it appears behind xchat
[19:58] <kenvandine> fta, that is the window manager issue seb128 mentioned
[19:58] <kenvandine> long standing problem :/
[20:08]  * kenvandine eats... bbs
[20:41] <kenvandine> Nafai, ping
[20:42] <Nafai> pong
[20:43] <kenvandine> hey, i hear you have some twisted experience? and might be helpful with nasty threading issues :)
[20:43] <Nafai> Yes, I used to be a Twisted core developer
[20:43] <kenvandine> the gwibber problem seems to stem from mixing gobject threads and python multiprocessing
[20:43] <kenvandine> so when the processes get the same GMainContext
[20:44] <kenvandine> which is likely the basis for all the issues we get calling the keyring from inside that thread
[20:44] <kenvandine> http://pastebin.ubuntu.com/410145/
[20:44] <kenvandine> Nafai, a test case that will make your CPU peg :)
[20:44] <Nafai> sweet
[20:44]  * Nafai looks
[20:45] <kenvandine> of course we could refactor everything to not use multiprocessing, but that is a significant change... i am hoping there is some way to we can make them play nicely
[20:46]  * Nafai nods
[20:48] <Nafai> let me poke around for a bit :)
[20:51] <kenvandine> thx Nafai
[21:14] <baptistemm> hmm, I have a question, who should I ping to get bug 544150 included?
[21:28] <pitti> good night everyone
[21:28] <didrocks> good night pitti
[21:28]  * didrocks will follow pitti
[21:28] <Nafai> night guys
[21:29] <didrocks> once again, I said that I will take an early evening
[21:29] <didrocks> and it's a fail :)
[21:30] <didrocks> have a good afternoon Nafai!
[21:30] <seb128> didrocks, it's not late!
[21:31] <seb128> baptistemm, subscribe ubuntu-sponsors?
[21:44] <rickspencer3> Nafai ... $quickly debug ftw
[21:44] <rickspencer3> can't wait to try it
[21:44] <Nafai> :)
[21:44] <Nafai> very handy
[21:44] <rickspencer3> Nafai, any luck with gwibber?
[21:44] <Nafai> not yet :(
[21:45] <Nafai> going to try profiling it next
[22:05] <Nafai> kenvandine: asynchronous stuff with Twisted is easier to debug :)  I'm not sure what's going on
[22:05] <kenvandine> Nafai, if you figure something out... ping me and i will read it later on tonigh
[22:05] <kenvandine> hehe
[22:05] <Nafai> I ran the profiler on it and got this output: http://paste.ubuntu.com/410243/
[22:08] <kenvandine> i gotta go for now though, if you figure anything out just tell me and i will read the scrollback later :)
[22:08] <Nafai> ok
[22:08] <kenvandine> i have a flower bed and 92F sunny yard begging me to go do some digging :/
[22:16] <rickspencer3> kenvandine, dig it!
[22:18] <rickspencer3> I can see we are getting close the beta
[22:18] <rickspencer3> only 38 Megs to download
[22:18] <rickspencer3> seb128, pitti how hard would it be to turn off auto-syncing for lucid in the beta, until we can get this 100% thing licked?
[22:19] <rickspencer3> kenvandine ^ you too, but I assume you are afk
[22:20] <seb128> rickspencer3, hum, what do you mean by auto syncing there?
[22:20] <rickspencer3> seb128, I mean "auto-running" I guess
[22:20] <rickspencer3> auto-starting?
[22:20] <seb128> oh
[22:20] <rickspencer3> like, when you log on, don't start gwibber automatically
[22:20] <rickspencer3> is it too late for the beta to do that?
[22:20] <seb128> I guess it would be trivial
[22:21] <rickspencer3> (I am fine if it's too late)
[22:21] <seb128> but I doubt they would roll new isos for that
[22:21] <rickspencer3> right
[22:21] <rickspencer3> so "too late"
[22:21] <seb128> that's still a beta
[22:21] <rickspencer3> yeah, it's fine
[22:21] <rickspencer3> we just don't exactly need more bug reports on the issue
[22:21] <rickspencer3> ;)
[22:21] <seb128> we get that many bugs?
[22:22] <rickspencer3> seb128, well, we get many "me toos" on the bug report
[22:22] <rickspencer3> so, I assume we'll get lots of bug reports after the beta
[22:23] <rickspencer3> like I say, though, it's not something worth causing extra work around the beta for (imho)
[22:23] <seb128> let's aim at getting it fixed by unfreeze time
[22:23] <rickspencer3> well, let's get it fixed asap!
[22:23] <seb128> right
[22:23] <rickspencer3> Nafai, do you have any other tasks aside from looking at the Gwibber bug?
[22:24] <rickspencer3> I'm hoping another pair of eyes can help
[22:24] <Nafai> yeah, I have an indicator application related bug I'm looking at, but if there is something higher priority I can jump on it
[22:25] <rickspencer3> mmm
[22:25] <rickspencer3> no, we need you on the indicators
[22:25] <rickspencer3> so after that, Gwibber until the break of day
[22:25] <rickspencer3> ;)
[22:25] <Nafai> ok, can do that
[22:42] <seb128> Nafai, could you look at bug #553423 too when you have some time for the issue?
[22:42] <Nafai> Sure
[22:43] <seb128> thanks
[22:43] <Nafai> np
[22:53] <Nafai> stepping away for a moment, bbiab
[23:02] <TheMuso> Good morning.
[23:09] <rickspencer3> Hi TheMuso
[23:09] <rickspencer3> TheMuso, Eastern Edition in 50 minutes, right?
[23:09] <TheMuso> rickspencer3: yep sounds good.
[23:10] <rickspencer3> things have been sliding all over my calendar
[23:10] <rickspencer3> all the dst
[23:10] <rickspencer3> s everywhere taking hold, I guess
[23:11] <TheMuso> yep
[23:21]  * desrt has the bvta blues
[23:21] <desrt> *beta