[05:35] <Guest4326> anyone here?
[06:26] <kklimonda> good morning
[07:34] <pitti> Good morning
[07:39] <baptistemm> hello pitti
[08:31] <didrocks> hi pitti
[08:44] <chrisccoulson> hey pitti - i've pushed a change for bug 446191 to bzr now
[08:45] <chrisccoulson> i'm not sure if it's too late to make the release now, or whether you want me to work on a SRU justification?
[08:46] <chrisccoulson> ooh, breakfast time, bbl
[08:48] <seb128> hello there
[09:33] <pitti> hey seb128
[09:33] <seb128> hello pitti
[09:33] <seb128> pitti, I'm official not working today (just for information)
[09:34] <seb128> I hand around now but will be out in half an hour for some hours
[09:34] <pitti> nice, enjoy your long weekend then
[09:34] <pitti> it's quiet today, so that's fine
[09:34] <seb128> pitti, do you think we can get the robert_ancell sponsoring items in before karmic still?
[09:34] <pitti> seb128: just a quick question if I may?
[09:34] <seb128> pitti, yes sure, I'm still around for half an hour
[09:34] <seb128> I take friday off because I've vac days to use before december
[09:34] <pitti> seb128: TBH at this point I would just like to see pinpointed patches for RC bugs..
[09:34] <seb128> but I've nothing special to do some I'm hanging around anyway
[09:35] <pitti> but I'l have a look
[09:35] <pitti> seb128: so, you remember that keyboard bell mode gconf key?
[09:35] <pitti> do you know what it actually _does_?
[09:35] <pitti> I never actually heard anything related to my keyboard
[09:35] <seb128> pitti, thanks, the 2 bug fix updates seem fine and fix some annoying bugs
[09:35] <pitti> it just seems to cause trouble
[09:35] <TheMuso> Enables/disables the bell event for pressing backspace in GTK text boxes, or the terminal, or a program like irssi triggering a bell event. I.e allows you to turn it on/off to hear it etc.
[09:36] <seb128> pitti, it's what makes your computer beep on delete on empty lines
[09:36] <pitti> TheMuso: hm, but it doesn't even do that for me; presumably because of the pcspkr blacklisting?
[09:36] <seb128> could be
[09:36] <seb128> it's what I was complaining about
[09:36] <seb128> it started doing it again in a guest session there a week ago
[09:36] <pitti> so, would anything break if we just disable the damn key?
[09:36] <TheMuso> c
[09:36] <seb128> it's very stressing noise happening a lot
[09:36] <TheMuso> pitti: It deends on whether the sound events for it are turned on.
[09:36] <TheMuso> pitti: No
[09:37] <TheMuso> pitti: If people want it, they can re-enable it.
[09:37] <TheMuso> However in future cycles, I think we ned to ensure any noisy beeps similar to whats being reported are muted, and the sound events mechanism handles the bell event sound.
[09:37] <pitti> [ ] Annoy me and scare the neighbour
[09:37] <seb128> what I don't get is why it was fine and came back recently
[09:37] <seb128> it was silent during most of karmic
[09:37] <seb128> and we broke it the week before rc...
[09:38] <TheMuso> seb128: I think its got to do with pulseaudio futsing with mixer settings. Unfortunately I can't reproduce it here, so I don't know exactly what mixer element to pinpoint.
[09:38] <pitti> seb128: does that gconf key help? or is it the alsa mixer for you?
[09:38] <TheMuso> And... the config item for the kernel config_snd_hda_input_beep somehow got enabled again.
[09:39] <seb128> pitti, I've a pc beep entry in alsamixer there
[09:39] <TheMuso> which we disabled for jaunty.
[09:39] <seb128> it's set to 0
[09:39]  * TheMuso sighs
[09:39] <seb128> but people on the bug say that 0 is not enough
[09:39] <seb128> you need to mute it
[09:39] <pitti> TheMuso: ^ so fixing that in alsa doesn't even help, since pulseaudio enables it again?
[09:39] <seb128> pitti, the gconf key make it silent under GNOME
[09:39] <TheMuso> Yep, jaunty's kernels have the hda beep disabled, and somehow it got re-enabled for karmic
[09:40] <seb128> it's still beeping on vts but that might be wanted
[09:40] <TheMuso> pitti: We put a clamp on at least one known mixer element in alsa, but theres a possibility pulse is doing something. However as I am just saying, we actually turned this option off completely in the kernel for the hda codec, which is what the cause is.
[09:40] <TheMuso> for jaunty, whereas somehow for karmic, it was re-enabled again.
[09:40] <TheMuso> SO to really really put a clamp on this, we turn it off, once again, in the kernel.
[09:41] <seb128> did that change in a recent linux upload?
[09:41] <TheMuso> seb128: I'll just run git annotate on it to see where it came from.
[09:41] <pitti> TheMuso: I see; so bug 77010 should have a linux task?
[09:41] <TheMuso> pitti: I think so.
[09:41] <pitti> TheMuso: I'll add one and copy your explanation there; thanks!
[09:41] <TheMuso> pitti: As we have regressed since jaunty, due to that kernel config change.
[09:42] <seb128> no it's not a recent change
[09:42] <seb128> config-2.6.31-11-generic:CONFIG_SND_HDA_INPUT_BEEP=y
[09:42] <seb128> that's the older linux version installed there
[09:42] <seb128> but it was already on
[09:42] <TheMuso> Ok, it was accidentally reverted back in July, but since it didn't bother anyone, we didn't think to check it, but now its causing problems again, we can fix it.
[09:43] <TheMuso> It was reverted due to some x86/lpia config consolidation.
[09:45] <pitti> TheMuso: can/should we do anything about it in alsa? or should I just close that task?
[09:45] <TheMuso> pitti: We'd be running around like headless chickens if we did it in alsa, since different codecs/revisions of codecs all label it different things.
[09:46] <TheMuso> So while we disable it for one, its not disabled for another.
[09:46] <TheMuso> I say we just turn it off in the kernel like we did in Jaunty.
[09:46] <pitti> TheMuso: hah, can I quote that? :-)
[09:46] <TheMuso> Its a useless option anyway IMO.
[09:46] <seb128> too late for linux changes in karmic now though
[09:46] <pitti> TheMuso: thanks a lot for the explanation
[09:46] <TheMuso> seb128: Yes, but even in jaunty, it was fixed in an SRU.
[09:46] <TheMuso> pitti: If you reallyw ant to.
[09:47] <TheMuso> pitti, seb128, I'll put a patch together for the kernel guys as an SRU, and fix up the bug on Monday. I'm about to head off for my evening.
[09:48] <pitti> so finally there's some light on it
[09:48] <seb128> thanks TheMuso
[09:48] <pitti> TheMuso: thanks, and good night!
[09:48] <pitti> seb128: I should use debian/libgnome2-common.gconf-defaults, not patch the .schema.in, right?
[09:49] <seb128> pitti, yes
[09:50] <seb128> pitti, ok, just confirmed in a guest session there
[09:50] <seb128> changing bell_mode to off fixes the issue
[09:50] <pitti> \o/
[09:50] <seb128> or workaround it but it's good enough for most users
[09:50] <seb128> I'm still wondering why it doesn't happen in my user session
[09:50] <seb128> where it's set to on
[09:51] <TheMuso> seb128: A good way to work out why is to open alsamixer in both sessions, and check for an element similar to "pc speaker" and see what they are both set to. My guess is pulse has a setting for it stored in your session, but not for the new session.
[09:54] <seb128> TheMuso, the pc beeper is to 0 in the guest session too
[09:55] <seb128> changing it to mute workaround the issue
[09:55] <seb128> but for my session it's set to 0 and that works
[09:56] <pitti> $ gconftool -u /desktop/gnome/peripherals/keyboard/bell_mode
[09:56] <seb128> I probably have a gnome setting or something on my session
[09:56] <pitti> $ gconftool -g /desktop/gnome/peripherals/keyboard/bell_mode
[09:56] <pitti> false
[09:56] <pitti> ok, that seems to have worked
[09:56] <seb128> pitti, no
[09:56] <seb128> pitti, it's a string type and should be off
[09:56] <seb128> "off"
[09:56] <pitti> oh
[09:56] <seb128> pitti, it's a string type and should be "off"
[09:56] <pitti> booleans are for loosers..
[09:57] <seb128> pitti, it's a string type and should be "off"
[09:57] <seb128> urg
[09:57] <seb128> focus issues sorry
[09:57] <pitti> ok, rebuilding
[09:58] <seb128> pitti, well there is a "custom" value whatever that does...
[10:08]  * seb128 is away for some hours, bbl
[10:32] <dtchen> TheMuso: I've pushed a Karmic PA branch. It's probably a good idea to run this proposal past the release team: http://bazaar.launchpad.net/~crimsun/pulseaudio/karmic/revision/213?compare_revid=209
[10:56] <pitti> in general, only milestoned karmic-targetted RC bug fixes now which have a zero chance of not breaking anything
[10:56] <pitti> everything else -> SRU
[10:57] <pitti> dtchen: the bashisms look fine, but the "more harm than good" at least needs a bug reference
[10:58] <pitti> (the original bug doesn't give details either)
[10:58] <pitti> dtchen: I know that Lennart ranted about it
[10:58] <dtchen> pitti: right, that's the bug that Lennart blogged about and is discussing
[10:59] <dtchen> pitti: I could file a bug saying that upstream says our applied fix is crackful; do you think that would suffice?
[10:59] <dtchen> pitti: it's definitely a bad "fix" and needs to be reverted
[11:00] <pitti> dtchen: well, it's the expansion of "bad" I'm interested in
[11:00] <pitti> i. e. what does it break, why it is worse than the bug that it fixes, etc.
[11:00] <dtchen> pitti: ok. firstly, it does the wrong thing with pa_sprintf_malloc(), including using the wrong parameter: address instead of d->address
[11:01] <pitti> ah, so it even causes crashes/corruption?
[11:01] <dtchen> pitti: secondly, in the case that d->address is bad (in this case it is; see the original report), even if we had _malloc()ed d->address, it'd still do the wrong thing
[11:02] <dtchen> pitti: right, potentially it'd do even worse things
[11:02] <pitti> dtchen: would you mind posting that to the original bug report, or adding a new one? to have a papertrail of the change?
[11:02] <pitti> then it looks fine to me
[11:03] <dtchen> pitti: so Lennart and I are discussing how to verify that the BT audio device is fully set up; it probably won't land for Karmic but hopefully for -updates
[11:03] <dtchen> pitti: yes, I'll update the original bug report
[11:03] <pitti> thank you
[11:03] <pitti> so, please get it uploaded, so that it's in the queue for review
[11:07] <chrisccoulson> good morning everyone
[11:10] <pitti> hey chrisccoulson
[11:10] <chrisccoulson> hey pitti
[11:10] <chrisccoulson> how are you today>
[11:10] <pitti> I'm great; karmic's looking good
[11:11] <pitti> I updated https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus and this didn't make me freak out any more
[11:11] <chrisccoulson> it is looking good now:)
[11:13] <pitti> chrisccoulson: I think you pinged me about the screen lock thing, but it got drowned in IRC; is there something to sponsor?
[11:15] <chrisccoulson> pitti - i uploaded a fix to ubuntu-desktop bzr
[11:15] <chrisccoulson> it also contains a fix for a crasher as well
[11:15] <pitti> chrisccoulson: gnome-session?
[11:16] <chrisccoulson> that's right. i was just going to get you a link, but my internet connection is very slow ;)
[11:16] <chrisccoulson> (or launchpad is slow)
[11:21] <chrisccoulson> pitti - just looking at bug 428884 - i've got a feeling that in the longer term, all the existing inhibit API and functionality in gnome-screensaver will probably just disappear like in gnome-power-manager
[11:22] <chrisccoulson> it already proxies all the inhibit requests to gnome-session anyway
[11:32] <pitti> hm,
[11:32] <pitti> chrisccoulson: so apps would tell g-session about inhibit, and that would proxy it to g-screensaver?
[11:34] <chrisccoulson> pitti - AFAIUI now, gnome-session does all the idle detection (and presents it via it's presence API)  and keeps track of all inhibitors. gnome-screensaver uses the presence API and gnome-session inhibitors to work out when to activate the screensaver
[11:35] <chrisccoulson> so gnome-session will set the session idle after a certain period of time, and this triggers a countdown in gnome-screensaver which eventually times out if the session remains idle. the screensaver is then activated if there are no inhibitors registered with gnome-session
[11:35] <chrisccoulson> (something like that)
[11:36] <chrisccoulson> it works similar to g-p-m, but g-p-m still uses the IDLETIME counter too
[11:36] <chrisccoulson> whereas gnome-screensaver doesn't
[11:39] <pitti> chrisccoulson: the g-s patch for suspend lock is quite intrusive; how much did you test this?
[11:42] <chrisccoulson> pitti - i tested the default settings on my desktop last night, and the screen locked as expected
[11:59] <chrisccoulson> pitti - thanks for sponsoring gnome-session :)
[12:12] <chrisccoulson> pitti - about the gnome-screensaver/VLC issue - i can probably come up with a change which makes gnome-screensaver reset the IDLETIME counter, but I'm not sure that would be appropriate for a SRU
[12:12] <chrisccoulson> ...considering how many other core desktop components rely on this counter
[14:16] <asac> pitti: could you kick gwibber from unapproved?
[14:16] <asac> and conkeror/galeon if you have one more minute (those are not that urgent though ... just need to happen at some point)
[14:18] <kenvandine> asac, those gwibber fixes are working great!
[14:19] <asac> yep
[14:19] <asac> mine is still running ... for about 18 hours already ;)
[14:19]  * kenvandine still can't believe nobody has noticed the window handling with the status icon was completely busted
[14:19] <asac> i also have images back ;)
[14:19] <kenvandine> yeah :)
[14:19] <kenvandine> thx for that
[14:19] <kenvandine> asac, one thing i have noticed with your timeout changes for facebook
[14:20] <asac> hmm. right
[14:20] <asac> i wanted to higher them again
[14:20] <asac> because its clearly not responsible for the dbus blocking
[14:20] <kenvandine> in my errors stream, i see those every few hours
[14:20] <kenvandine> yeah
[14:20] <asac> yeah
[14:20] <asac> we can do that in a SRU
[14:20] <kenvandine> i think bumping it would be good
[14:20] <asac> its not urgent
[14:20] <kenvandine> ok
[14:20] <kenvandine> yeah
[14:20] <kenvandine> the error shows that some data has been downloaded
[14:20] <cassidy> kenvandine, https://bugs.edge.launchpad.net/empathy/+bug/408530/comments/44 ...
[14:20] <asac> yes. i think 60 seconds or something
[14:20] <kenvandine> cassidy, i was just reading that
[14:21] <kenvandine> asac, 60s should be good
[14:22] <kenvandine> cassidy, we did fix everything you had written up in your review
[14:22] <asac> also we sould get rid of the facebook authentication in show_ui
[14:22] <asac> thats a mess
[14:22] <kenvandine> i'll look at this right now
[14:22] <asac> blocks gwibber lke 10 seconds to start
[14:23] <asac> but after karmic release ;)
[14:23] <cassidy> kenvandine, as I said I didn't check. I'm just upset because Zdra and I complained a lot about this patch and it still introduce regressions in our software...
[14:24] <kenvandine> cassidy, understand... and it is a huge patch
[14:24]  * Zdra see only one choice now: drop the patch
[14:24] <kenvandine> Zdra, that isn't possible for us
[14:24] <Zdra> we are at ubuntu RC1 already, not time to fix it anymore
[14:25] <asac> kenvandine: did we get news on bindwood already?
[14:25] <asac> will there be a patch today?
[14:25] <asac> ;)
[14:25] <asac> or did that fix slip in without me noticing?
[14:25] <Zdra> kenvandine, "not possible" is not possible in software
[14:25] <kenvandine> asac, you have email
[14:26] <asac> i have too many emails, yes. :)
[14:26] <kenvandine> Zdra, the indicator is a very important part of our "experience"
[14:26] <Zdra> kenvandine, it's always possible
[14:26] <Zdra> kenvandine, segfault too ?
[14:26] <kenvandine> asac, hold off on uploading that yet though
[14:26] <kenvandine> Zdra, of course we don't want that
[14:26] <Zdra> kenvandine, really, that's not a choice, drop that patch !
[14:26] <kenvandine> we want to fix these
[14:27] <Zdra> see also how you can't get incoming call and subscription
[14:27] <kenvandine> Zdra, you can... it works fine
[14:27] <kenvandine> we want to improve that though
[14:27] <Zdra> that's not what says users in a bug I saw this morning
[14:27] <kenvandine> they appear in the indicator as well
[14:27] <kenvandine> he just responded and said he didn't look in the indicator
[14:28] <kenvandine> again, we need to improve that
[14:28] <kenvandine> personally i feel that very real time things like incoming calls should by-pass the indicator
[14:28] <kenvandine> with some sort of dialog or something
[14:28] <kenvandine> we will be discussing this at UDS for sure
[14:29] <kenvandine> coming up with a better way of handling those
[14:29] <Zdra> ...and drop the patch until we come with a good proposal...
[14:29] <kenvandine> it does work though
[14:29] <Zdra> it segfault !
[14:30] <Zdra> did you see how many dups that bug has?
[14:30] <kenvandine> Zdra it is too late to drop the patch, dropping it would mean switching back to pidgin :/
[14:30] <kenvandine> yeah
[14:30] <kenvandine> Zdra, i am going to work on that now
[14:30] <kenvandine> we have looked at the bugs carefully to see if they were likely caused by the indicator patch
[14:31] <Zdra> kenvandine, in upstream we have good developers that knows the code and we always review any single line patch
[14:31] <kenvandine> you guys do great reviews :)
[14:32] <Zdra> kenvandine, the indicate patch was not made by someone knowing well empathy, it was not reviewed, and worst it was REJECTED upstream
[14:32] <kenvandine> i appreciated the one you did on the early indicate patch
[14:32] <kenvandine> Zdra, we did fix everything in your comments
[14:33] <Zdra> kenvandine, good, but you should have waited for a 2nd round of review before adding that in the package
[14:33] <cassidy> I'll try to review the new patch during the 2.29 cycle
[14:33] <kenvandine> cassidy, thx
[14:33] <Zdra> cassidy, useless we are moving to gnome-shell
[14:33] <cassidy> and maybe propose a new design based on the new MC5 API
[14:33] <kenvandine> i was planning to poke you about that
[14:33] <kenvandine> after karmic
[14:34] <cassidy> kenvandine, is there plan about how libindicate will fit in gnome-shell?
[14:34] <kenvandine> cassidy, not yet
[14:34] <kenvandine> no reason there couldn't be an indicator in gnome-shell
[14:34] <cassidy> kenvandine, FYI https://bugzilla.gnome.org/show_bug.cgi?id=599193
[14:34]  * hyperair still doesn't really see a difference between the indicator and the notification area
[14:34] <cassidy> please try to avoid to re-invent it if the upstream one can do the job
[14:35] <Zdra> hyperair, that's "ubuntu experience"
[14:35] <hyperair> heh
[14:37] <kenvandine> cassidy, one of the nice things about the indicator is it actually isn't tied to the panel or necessarily an applet
[14:37] <kenvandine> it is more of a service that empathy uses
[14:37] <kenvandine> right now the display/interaction for that service is in a panel applet
[14:37] <cassidy> with MC5 you should be able to do that as an external app
[14:37] <kenvandine> but nothing that uses the indicator has to change if that applet gets replaced with anything else
[14:37] <cassidy> without changing Empathy
[14:38] <cassidy> kenvandine, then you should discuss to integrate libindicate with gnome-shell people
[14:38] <kenvandine> there has been discussions
[14:38] <kenvandine> of some sort
[14:39]  * kenvandine isn't involved with that stuff :)
[14:42] <rickspencer3> asac, kenvandine, Riddell, pitti, hello ... what's the word?
[14:42] <pitti> hey rickspencer3
[14:42] <kenvandine> hey
[14:42] <pitti> rickspencer3: unapproved was crammed last night; the remaining polishing fixes
[14:43] <rickspencer3> hmm
[14:43] <pitti> which also means increased stress levels between people trying to rush in large patches and release team having to wade through them and/or say no
[14:43]  * rickspencer3 is doing a dist-upgrade, will see
[14:43] <pitti> but that's fairly normal :) so it's fine by and large
[14:43] <rickspencer3> pitti, is there some way to identify the "important" ones
[14:43] <rickspencer3> like U1 kills kittens fix, etc...?
[14:44] <pitti> rickspencer3: yes, those should have karmic'ed and milestoned bugs
[14:44] <pitti> but those are all in now
[14:44] <pitti> libgnome making beeps, etc.
[14:44] <rickspencer3> pitti, is it too late to get Quickly into main?
[14:44] <rickspencer3> j/k
[14:44] <Riddell> rickspencer3: some odds to be sorted out, agateau has done some fixes for knetworkmanager, kubuntu-docs needs translations, a pykde issue that I need to look into, nothing killer
[14:44] <pitti> rickspencer3: of course it's not
[14:44]  * rickspencer3 runs bughugger
[14:44] <pitti> rickspencer3: just not karmic's main :)
[14:45] <rickspencer3> hehe
[14:45] <rickspencer3> Qubuntu
[14:57] <seb128> hey
[14:57] <seb128> pitti, how is desktop land going?
[14:57] <pitti> hey seb128
[14:57] <pitti> seb128: seems alright
[14:58] <seb128> pitti, what do you think about updating gnome-desktop now?
[14:58] <pitti> not SRUable?
[14:58]  * rickspencer3 kicks seb128
[14:58] <seb128> pitti, what do you think about updating gnome-desktop now? that would give us about GNOME = 2.28.1
[14:58] <pitti> do we have a related RC bug?
[14:58] <seb128> pitti, what do you think about updating gnome-desktop now? that would give us about GNOME = 2.28.1
[14:59] <pitti> seb128: how much does it change?
[14:59] <seb128> pitti, what do you think about updating gnome-desktop now? that would give us about GNOME = 2.28.1
[14:59] <seb128> gnagnagna
[14:59]  * seb128 kicks hands
[14:59] <pitti> see, that's seb128's convincing strategy
[14:59] <rickspencer3> seb128-bot is stuck in a loop, as he is supposed to be on vacation today
[14:59] <seb128> lol
[14:59] <pitti> keep asking until I give up :)
[14:59] <seb128> sorry doing multi tasking and got page up on the wrong dialog
[14:59] <seb128> pitti, I think it's a no change out of translations
[14:59] <seb128> checking
[15:00] <huats> hey seb128 !
[15:00] <seb128> hi huats
[15:00] <seb128> ok
[15:01] <seb128> rickspencer3, pitti: only translation change
[15:01] <seb128> pitti, http://git.gnome.org/cgit/gnome-desktop/log
[15:01] <seb128> and a small build change to use ustar for tarball
[15:01] <seb128> which is just how the tarball is rolled
[15:02] <seb128> it's not really important but it would be nice to have about GNOME saying 2.28.1 since that's what we have
[15:02] <pitti> seb128: ok if it doesn't change any code; please get it uploaded
[15:02] <seb128> pitti, ok
[15:03] <seb128> thanks
[15:03] <seb128> pitti, can I sync libsoup2.4 too?
[15:03] <seb128> it's a no upstream change
[15:03] <seb128> I dropped some debian dir changes while doing the 2.28.1 update
[15:04] <seb128> we were in sync but bzr was uptodate
[15:04] <seb128> it's basically the shlibs not updated
[15:04] <seb128> slangasek accepted the update but asked to fix before karmic if possible
[15:04] <pitti> ah, and Debian has fixed shlibs?
[15:04] <pitti> please go ahead
[15:05] <seb128> pitti, right, in fact I undid the 2.27.91 to 2.28.0 debdiff
[15:05] <seb128> or rather debian dir diff
[15:05] <seb128> since bzr was outdated
[15:05] <seb128> which was a shilibs update an a monitor control version change (updates standards-version I think)
[15:06] <seb128> ok, doing, thanks
[15:16] <tormod> is there anything in Gnome that would set modification times on files explicitly? I have a weird bug 459011
[15:16] <Riddell> no awe today?
[15:27] <MacSlow> pitti, fix in notify-osd for #396736 (#458413) you want that for release or is that rather for SRU?
[15:27] <pitti> MacSlow: SRU
[15:28] <pitti> (which is the default answer now, unless it fixes a release-critical bug)
[15:28] <MacSlow> pitti, it's unpleasant but not a crasher
[15:35] <Laney> is example-content's desktop shortcut going to grow an icon?
[15:36] <davmor2> hey Keybuk
[15:36] <seb128> Laney, dunno, ask dholbach he might know
[15:36] <Keybuk> davmor2: yeah
[15:36] <Keybuk> hey
[15:36] <Keybuk> I mean
[15:37] <Laney> also gparted's menu entry just says "GParted"
[15:37] <davmor2> Keybuk: have you seen the issue with recovery mode?  mountall seems to drop you out of the options
[15:37]  * Laney is installing a karmic system ;)
[15:37] <Keybuk> davmor2: I haven't seen any reports of a recovery mode issue yet
[15:37] <seb128> rickspencer3, pitti, kenvandine: https://bugs.edge.launchpad.net/empathy/+bug/408530/comments/44: -(
[15:38] <seb128> the empathy crash which has a zillion duplicate seems to be due to our libindicate change
[15:38] <seb128> unhappy upstream too
[15:38] <pitti> yeah, just fiddling it
[15:38] <seb128> it's not the only bug
[15:38] <kenvandine> seb128, yeah we discussed it
[15:38] <seb128> we have an another one with a zillion duplicate too
[15:39] <davmor2> Keybuk: go into recovery mode on the installed system press the down arrow 3-4 times bdmurray pointed it out to me late-ish last night
[15:39] <pitti> and unhappy users as well -- this crash drives me nuts
[15:39] <rickspencer3> kenvandine, thoughts? ^
[15:39] <kenvandine> i am looking at that one now
[15:39] <asac> did empathy deny taking a indicate patch?
[15:39] <davmor2> Keybuk: I'm assuming he has written a bug on it or knows what bug it is.
[15:39] <asac> or just because of quality concerns?
[15:40] <seb128> asac, they didn't take one
[15:40] <seb128> asac, they had quality concern, cf bugzilla bug
[15:40] <asac> i mean did they refuse to take it because they are against the indicate apporach in general?
[15:40] <asac> ah ok
[15:40] <seb128> asac, and that's why they are unhappy, we didn't address the concerns and shipped anyway
[15:40] <Keybuk> davmor2: and you get a recovery shell on top?
[15:40] <asac> yeah
[15:40] <seb128> ie we just sit on our buggy change
[15:41] <asac> did we ask for help?
[15:41] <seb128> to who?
[15:41] <asac> i mean ... maybe they would be willing to do that proper for us ;)
[15:41] <asac> empathy upstream
[15:41] <seb128> they did comment in details on their issues
[15:41] <seb128> they have enough to do they are not interested to write that change
[15:41] <seb128> they did take time to do a detailled review though
[15:42] <davmor2> Keybuk: you get this http://launchpadlibrarian.net/34156895/9.10-friendly-recovery-make-freespace.png
[15:42] <asac> seb128: yeah ok.
[15:42] <Keybuk> davmor2: thought so
[15:42] <cassidy> tbh, we are not against libindicate, but will prefer to see it more "upstreamed" before merging something like that
[15:42] <asac> seb128: so the 1 hour reply is the first time they give proper hints?
[15:42] <Keybuk> davmor2: there's another bug with a different description that's the same underlying bug
[15:42] <seb128> asac, no, there is a long upstream bug discussion
[15:42] <cassidy> as I said to kenvandine, gnome-shell could be a good opportunity to push libindicate upstream
[15:42] <seb128> asac, open for months
[15:43] <cassidy> as we do want to integrate properly with gnome-shell
[15:43] <davmor2> Keybuk: is it the menu system at fault or is it mountall?
[15:43] <cassidy> see our roadmap http://live.gnome.org/Empathy/Roadmap/Roadmap230 :)
[15:43] <asac> seb128: thx
[15:43] <Keybuk> davmor2: mountall isn't exiting when it should
[15:44] <seb128> asac, search in upstream bugs libindicate title
[15:44] <seb128> asac, search in upstream bugs libindicate title
[15:44] <seb128> ups
[15:45] <cassidy> I linked it in my LP rant :)
[15:45] <davmor2> Keybuk: okay cool so ball in your court with that one then yes?
[15:45] <Keybuk> davmor2: I think ion has already fixed it for me ;)
[15:46] <davmor2> Keybuk: when you upload it give me a shout and I'll try it out across the board
[15:46] <asac> seb128: so empathy sends messages twice ;)
[15:46] <asac> j.k.
[15:46]  * seb128 slaps asac
[15:47] <seb128> cassidy, btw rants are not the most constructive thing there
[15:48] <seb128> it's not as easy as "drop your changes"
[15:48] <seb128> we have design, schedule etc constrains too
[15:48] <cassidy> seb128, I know; but I do think my comment was pretty constructive
[15:49] <mvo> Keybuk: can you think of a reason against increasing the max_match_rules_per_connection limit for the dbus system bus? Its currently 512 and that limits aptdaemon (that uses signals and each creates a match rule). something like ~5000 (background is bug #454093)
[15:49] <seb128> right, better than some we had on others bugs ;-)
[15:49] <cassidy> and I found your bug :p
[15:49] <seb128> much appreciate
[15:50] <pitti> anyway, I guess this has a pretty trivial patch, and it's a karmic-tasked bug milestoned to karmic-updates
[15:50] <MacSlow> How do I get rhythmbox to show me the cover-art-display?
[15:51] <pitti> if we get a patch by Monday which is trivial, we can squeeze it into final, otherwise we'll SRU it
[15:51] <MacSlow> Should that not be visible by default (no matter if there's actually a cover available for the played song or not)?
[15:51] <kenvandine> cassidy, yes it was pretty constructive and thanks so much for finding the bug
[15:51] <kenvandine> cassidy, it will be easy to handle the A scenario you mentioned
[15:52] <cassidy> I hope that's actually the bug now :p
[15:52] <kenvandine> cassidy, but no idea how to deal with the B scenario
[15:52] <kenvandine> cassidy, hehe... so much build up :)
[15:52] <Keybuk> mvo: no reason, should be no problem to increase it
[15:52] <Keybuk> davmor2: wilco
[15:52] <kenvandine> so if reading this right, you can trigger it by having 2 chat windows opening and switching between them?
[15:52] <davmor2> Keybuk: you coming over tomorrow?
[15:53] <cassidy> kenvandine, you could use g_signal_connect_data and ensure that the signal is disconnected when needed
[15:53] <Keybuk> davmor2: "coming over" ?
[15:53] <davmor2> Keybuk: Last LRL
[15:53] <Keybuk> no, the website said there weren't any tickets left
[15:54] <dobey> hrmm
[15:54] <asac> kenvandine: es. use connect_data ... make a destroy for cb_data
[15:54] <asac> yes
[15:54] <asac> ;)
[15:54] <asac> to unref
[15:55] <kenvandine> i am following the exact steps he outlined to reproduce it, and it isn't crashing :/
[15:56] <mvo> Keybuk: thanks
[15:56] <Keybuk> mvo: the original D-Bus authors liked arbitrary limits for everything
[15:57] <kenvandine> pitti, when you got that crash, do you recall if you had two chat windows open?
[15:59]  * mvo nods
[16:01] <pitti> kenvandine: most often I don't
[16:02] <pitti> I only have that very seldomly
[16:02] <kenvandine> humm
[16:02] <walters> mvo: 5000?  wow.  what bindings?
[16:03] <walters> mvo: you can create a match rule for say "type='signal',interface='org.aptdaemon.Package'" instead of one per interface/object path
[16:03] <mvo> walters: python bindings
[16:04] <mvo> walters: oh, cool. I will experiment with that
[16:04] <walters> i don't quite understand how 20 apps would lead to 5000 rules though
[16:05] <mvo> right now its 20 apps hit the 512 limit
[16:05] <mvo> and I want to increase it as a stop-gap measure so that its harder to hit the limit
[16:05] <mvo> 200 apps in the queue ought to be enough for everybody
[16:09] <walters> mvo: yeah...though if you expect thousands of objects it might make more sense to redesign the API so that there's only one master object that emits signals like PackageStatusChanged(string packagename) etc
[16:10] <walters> match rules aren't quite free, though there's a patch oustanding to make them more efficient, which i need to finish reviewing..
[16:13] <mvo> walters: thanks, I think longer term the api needs tweaks, but for karmic I will go with increasing the limit if there is no real downside/risk in it
[16:14] <dobey> pitti: hey. it's somewhat unclear to me what level of membership i should apply for. just universe-contributor for now and then MOTU later? or just straight to MOTU?
[16:14] <walters> there's not really a downside/risk, the intent of the limit was to mitigate DoS obviously, but it's sort of a lost cause
[16:16]  * mvo nods
[16:17] <pitti> dobey: I think you should apply as an Ubuntu member first, and then for ~ubuntu-desktop; in a few days, ~ubuntu-desktop members will be able to upload desktop related packages
[16:18] <pitti> dobey: unless of course you want to become a packaging generalist and actually apply for MOTU/core-dev (but that'd require some more packaging practice then)
[16:19] <dobey> pitti: ok. the description of universe-contributor just seems somewhat of a default, since i've contributed multiple packages, which are in main already :)
[16:20] <dobey> pitti: but i'll do that and ~desktop first. thanks for clarifying :)
[16:21] <cassidy> seb128, https://bugs.edge.launchpad.net/ubuntu/+source/telepathy-glib/+bug/459157
[16:21] <cassidy> seb128, you'll probably be interested in the fix for https://bugzilla.gnome.org/show_bug.cgi?id=599386 as well
[16:21] <seb128> cassidy, right but those will have to be srus now I guess
[16:22] <seb128> pitti, ^ what do you think?
[16:22] <kenvandine> cassidy, if your theory is correct, this bug should be easy to reproduce with any protocol?
[16:22] <pitti> seb128: I'm in release meeting, later
[16:23] <cassidy> kenvandine, I guess..
[16:23] <seb128> pitti, ok
[16:23] <kenvandine> i can't seem to trigger it :/
[16:23]  * kenvandine tries a different path to getting the chat windows 
[16:41] <seb128> re
[16:41] <seb128> pitti, gnome-desktop uploaded btw
[16:41] <seb128> if you have time to review it after meeting
[16:41] <pitti> thanks
[17:13] <jcastro> kenvandine: can someone address this m-i empathy patch problem?
[17:13] <jcastro> bug 408530
[17:14] <Zdra> jcastro, segfault is part of the "ubuntu experience"
[17:14] <jcastro> I suspect tedg, it's always a good start
[17:15] <seb128> re
[17:15] <seb128> back on a stable internet now
[17:15] <seb128> sorry for the flacky one before and the serie of disconnects
[17:15] <chrisccoulson> hello seb128
[17:16] <pitti> seb128: you changed ISP in the meantime? :-)
[17:18] <seb128> pitti, no it was rather a laptop to access point issue
[17:18] <seb128> hey chrisccoulson
[17:18] <seb128> pitti, thanks for accepting gnome-desktop
[17:24] <chrisccoulson> pitti - do you think we should fix bug 457104 now, or is it not so important?
[17:24] <chrisccoulson> (it's just cruft left after upgrading)
[17:29] <pitti_> chrisccoulson: does it hurt to have more?
[17:29] <pitti_> rickspencer3: FYI, my server just went AWOL; and of course precisely 15 minutes after my ISP shuts down business for the week; so I'm without email now
[17:30] <seb128> emails are overrated
[17:30] <pitti_> rickspencer3: would you mind mailing the desktop team and slangasek that they need to IRC or phone me?
[17:30] <pitti_> it'll be a quiet weekend anyway :)
[17:31] <chrisccoulson> pitti - it doesn't really have any effect having 2 desktop files in /etc/xdg/autostart, other than a warning in ~/.xsession-errors and 2 at-spi-registryd entries in gnome-session-properties
[17:31] <pitti_> chrisccoulson: let's fix it for lucid
[17:31] <chrisccoulson> ok, no problem:)
[17:46] <kenvandine> jcastro, i am working on it... just haven't been able to reproduce it yet
[17:46] <seb128> pitti_, did you look at the brasero update?
[17:47] <pitti_> seb128: see /query
[17:48] <seb128> pitti_, ok
[17:49] <pitti_> oh, my server just came back \o/
[17:49] <pitti_> rickspencer3: ^ unwarn then
[17:49] <rickspencer3> thanks pitti_
[17:56] <asac> ArneGoetje: do you know this scim-bridge topcrash?
[17:56] <asac> ArneGoetje: quite some dupes ... wonder if its our qt patch
[17:57] <asac> bug 243344
[17:57] <asac> lots of dupes and still happening recently in karmic
[17:59] <asac> and the other scim-bridge top crash (in unload) is the second most duped in ubuntu ;)
[17:59] <asac> bug 199592
[17:59] <asac> but i think unload isnt that intrusive for user experience
[18:00] <asac> but the other isnt bad either ... like rank 20 in whole ubuntu or so ;)
[18:00] <asac> and i think that happens while using
[18:00] <asac> anyway. lets check that on monday
[18:14] <seb128> pitti_, ok, gnome-desktop 2.28.1 didn't update the about gnome version, that's stupid
[18:14] <seb128> pitti_, I've a 1 liner configure change 0 -> 1
[18:14] <pitti_> hmm
[18:14] <seb128> pitti_, can I upload?
[18:14] <pitti_> sure
[18:14] <seb128> thanks
[18:15] <kenvandine> asac, that bindwood bug is fixed, urbanape should be contacting you
[18:15]  * kenvandine goes back to empathy debugging
[18:24] <seb128> pitti_, gnome-desktop uploaded btw
[18:26] <pitti_> thanks
[18:30] <seb128> mvo, ubuntu-translators says you broke string freeze
[18:30] <mvo> seb128: what?
[18:31] <mvo> seb128: which one?
[18:31] <seb128> mvo, there is any email on the list
[18:31] <seb128> about 2 new strings
[18:31] <mvo> for what package?
[18:31] <mvo> update-manager? that is a utf-8 fix and I unfuzzied all translations
[18:31] <mvo> i.e. the string was not displayed localized anywhere
[18:32] <mvo> hm, I'm not subscribed, let me check the archive
[18:32] <seb128> mvo, seems it's not there yet
[18:32] <mvo> ok
[18:32] <seb128> mvo,
[18:32] <seb128> "
[18:32] <seb128> "No init available"
[18:32] <seb128> "Your system appears to be a virtualised environment without an init
[18:32] <seb128> daemon, e.g. Linux-VServer. Ubuntu 9.10 cannot function within this type
[18:32] <seb128> of environment, requiring an update to your virtual machine
[18:33] <seb128> configuration first.
[18:33] <seb128> Are you sure you want to continue?""
[18:33] <mvo> oh, right
[18:33] <seb128> mvo, that's the ones in the email
[18:33] <seb128> "2 new strings in update-manager" is the email
[18:33] <seb128> +title
[18:33] <mvo> yeah, sorry. this one is hard to avoid, its either break upgrades in a verser totally or display a string
[18:33] <mvo> sorry, I forgot about that
[18:33] <seb128> I'm just forwarding the message
[18:33] <mvo> yeah
[18:33] <seb128> since I'm subscribed to the list
[18:33] <mvo> thanks for that :)
[18:34] <mvo> when its in the archive I will reply
[18:34] <seb128> I guess you might want to drop an email there
[18:34] <seb128> want me to bounce the email to you?
[18:34] <mvo> seb128: that would be nice
[18:34] <seb128> mvo, done
[18:35] <mvo> thanks
[18:35] <seb128> mvo, let me know if you worked I don't trust evo for bouncing
[18:36] <mvo> not here yet
[18:36]  * mvo wait
[18:37] <asac> kenvandine: which bug? was there a new fix?
[18:37] <asac> or did we find a regressions during testing?
[18:37] <asac> (i had the impression there already was a branch ready)
[18:37] <seb128> mvo, I think I screwed look again
[18:37] <mvo> now!
[18:37] <mvo> seb128: thanks, its there now
[18:37] <seb128> cool
[18:38] <mvo> seb128: it lacks the mail adress of the author, could you /msg me that please?
[18:39] <seb128> mvo, cf query
[18:41] <mvo> thanks!
[18:41] <mvo> and thanks for letting me know about it, much appreciated
[18:41] <seb128> you're welcome!
[18:41]  * seb128 hugs mvo
[18:46] <pitti_> yay, my real me again
[19:01] <pitti> good night everyone!
[19:01] <dobey> night pitti
[21:11] <dobey> anyone around using wicd or something else instead of networkmanager?
[23:12] <asac> dont use wicd