=== MenZa_ is now known as MenZa [05:35] anyone here? [06:26] good morning [07:34] Good morning [07:39] hello pitti [08:31] hi pitti [08:44] hey pitti - i've pushed a change for bug 446191 to bzr now [08:44] Launchpad bug 446191 in gnome-session "System / Shut Down Suspend does not lock screen" [Medium,In progress] https://launchpad.net/bugs/446191 [08:45] 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] ooh, breakfast time, bbl [08:48] hello there === MacSlow is now known as MacSlow|errand === czajkows1i is now known as czajkowski [09:33] hey seb128 [09:33] hello pitti [09:33] pitti, I'm official not working today (just for information) [09:34] I hand around now but will be out in half an hour for some hours [09:34] nice, enjoy your long weekend then [09:34] it's quiet today, so that's fine [09:34] pitti, do you think we can get the robert_ancell sponsoring items in before karmic still? [09:34] seb128: just a quick question if I may? [09:34] pitti, yes sure, I'm still around for half an hour [09:34] I take friday off because I've vac days to use before december [09:34] seb128: TBH at this point I would just like to see pinpointed patches for RC bugs.. [09:34] but I've nothing special to do some I'm hanging around anyway [09:35] but I'l have a look [09:35] seb128: so, you remember that keyboard bell mode gconf key? [09:35] do you know what it actually _does_? [09:35] I never actually heard anything related to my keyboard [09:35] pitti, thanks, the 2 bug fix updates seem fine and fix some annoying bugs [09:35] it just seems to cause trouble [09:35] 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] pitti, it's what makes your computer beep on delete on empty lines [09:36] TheMuso: hm, but it doesn't even do that for me; presumably because of the pcspkr blacklisting? [09:36] could be [09:36] it's what I was complaining about [09:36] it started doing it again in a guest session there a week ago [09:36] so, would anything break if we just disable the damn key? [09:36] c [09:36] it's very stressing noise happening a lot [09:36] pitti: It deends on whether the sound events for it are turned on. [09:36] pitti: No [09:37] pitti: If people want it, they can re-enable it. [09:37] 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] [ ] Annoy me and scare the neighbour [09:37] what I don't get is why it was fine and came back recently [09:37] it was silent during most of karmic [09:37] and we broke it the week before rc... [09:38] 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] seb128: does that gconf key help? or is it the alsa mixer for you? [09:38] And... the config item for the kernel config_snd_hda_input_beep somehow got enabled again. [09:39] pitti, I've a pc beep entry in alsamixer there [09:39] which we disabled for jaunty. [09:39] it's set to 0 [09:39] * TheMuso sighs [09:39] but people on the bug say that 0 is not enough [09:39] you need to mute it [09:39] TheMuso: ^ so fixing that in alsa doesn't even help, since pulseaudio enables it again? [09:39] pitti, the gconf key make it silent under GNOME [09:39] Yep, jaunty's kernels have the hda beep disabled, and somehow it got re-enabled for karmic [09:40] it's still beeping on vts but that might be wanted [09:40] 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] for jaunty, whereas somehow for karmic, it was re-enabled again. [09:40] SO to really really put a clamp on this, we turn it off, once again, in the kernel. [09:41] did that change in a recent linux upload? [09:41] seb128: I'll just run git annotate on it to see where it came from. [09:41] TheMuso: I see; so bug 77010 should have a linux task? [09:41] Launchpad bug 77010 in libgnome "Overuse of system beep without volume control" [Medium,In progress] https://launchpad.net/bugs/77010 [09:41] pitti: I think so. [09:41] TheMuso: I'll add one and copy your explanation there; thanks! [09:41] pitti: As we have regressed since jaunty, due to that kernel config change. [09:42] no it's not a recent change [09:42] config-2.6.31-11-generic:CONFIG_SND_HDA_INPUT_BEEP=y [09:42] that's the older linux version installed there [09:42] but it was already on [09:42] 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] It was reverted due to some x86/lpia config consolidation. [09:45] TheMuso: can/should we do anything about it in alsa? or should I just close that task? [09:45] 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] So while we disable it for one, its not disabled for another. [09:46] I say we just turn it off in the kernel like we did in Jaunty. [09:46] TheMuso: hah, can I quote that? :-) [09:46] Its a useless option anyway IMO. [09:46] too late for linux changes in karmic now though [09:46] TheMuso: thanks a lot for the explanation [09:46] seb128: Yes, but even in jaunty, it was fixed in an SRU. [09:46] pitti: If you reallyw ant to. [09:47] 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] so finally there's some light on it [09:48] thanks TheMuso [09:48] TheMuso: thanks, and good night! [09:48] seb128: I should use debian/libgnome2-common.gconf-defaults, not patch the .schema.in, right? [09:49] pitti, yes [09:50] pitti, ok, just confirmed in a guest session there [09:50] changing bell_mode to off fixes the issue [09:50] \o/ [09:50] or workaround it but it's good enough for most users [09:50] I'm still wondering why it doesn't happen in my user session [09:50] where it's set to on [09:51] 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] TheMuso, the pc beeper is to 0 in the guest session too [09:55] changing it to mute workaround the issue [09:55] but for my session it's set to 0 and that works [09:56] $ gconftool -u /desktop/gnome/peripherals/keyboard/bell_mode [09:56] I probably have a gnome setting or something on my session [09:56] $ gconftool -g /desktop/gnome/peripherals/keyboard/bell_mode [09:56] false [09:56] ok, that seems to have worked [09:56] pitti, no [09:56] pitti, it's a string type and should be off [09:56] "off" [09:56] oh [09:56] pitti, it's a string type and should be "off" [09:56] booleans are for loosers.. [09:57] pitti, it's a string type and should be "off" [09:57] urg [09:57] focus issues sorry [09:57] ok, rebuilding [09:58] pitti, well there is a "custom" value whatever that does... === MacSlow|errand is now known as MacSlow [10:08] * seb128 is away for some hours, bbl [10:32] 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] in general, only milestoned karmic-targetted RC bug fixes now which have a zero chance of not breaking anything [10:56] everything else -> SRU [10:57] dtchen: the bashisms look fine, but the "more harm than good" at least needs a bug reference [10:58] (the original bug doesn't give details either) [10:58] dtchen: I know that Lennart ranted about it [10:58] pitti: right, that's the bug that Lennart blogged about and is discussing [10:59] pitti: I could file a bug saying that upstream says our applied fix is crackful; do you think that would suffice? [10:59] pitti: it's definitely a bad "fix" and needs to be reverted [11:00] dtchen: well, it's the expansion of "bad" I'm interested in [11:00] i. e. what does it break, why it is worse than the bug that it fixes, etc. [11:00] pitti: ok. firstly, it does the wrong thing with pa_sprintf_malloc(), including using the wrong parameter: address instead of d->address [11:01] ah, so it even causes crashes/corruption? [11:01] 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] pitti: right, potentially it'd do even worse things [11:02] 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] then it looks fine to me [11:03] 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] pitti: yes, I'll update the original bug report [11:03] thank you [11:03] so, please get it uploaded, so that it's in the queue for review [11:07] good morning everyone [11:10] hey chrisccoulson [11:10] hey pitti [11:10] how are you today> [11:10] I'm great; karmic's looking good [11:11] I updated https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus and this didn't make me freak out any more [11:11] it is looking good now:) [11:13] chrisccoulson: I think you pinged me about the screen lock thing, but it got drowned in IRC; is there something to sponsor? [11:15] pitti - i uploaded a fix to ubuntu-desktop bzr [11:15] it also contains a fix for a crasher as well [11:15] chrisccoulson: gnome-session? [11:16] that's right. i was just going to get you a link, but my internet connection is very slow ;) [11:16] (or launchpad is slow) [11:21] 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:21] Launchpad bug 428884 in gnome-screensaver "gnome-screensaver --poke functionality does no longer inhibit screen blanking" [Unknown,Confirmed] https://launchpad.net/bugs/428884 [11:22] it already proxies all the inhibit requests to gnome-session anyway [11:32] hm, [11:32] chrisccoulson: so apps would tell g-session about inhibit, and that would proxy it to g-screensaver? [11:34] 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] 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] (something like that) [11:36] it works similar to g-p-m, but g-p-m still uses the IDLETIME counter too [11:36] whereas gnome-screensaver doesn't [11:39] chrisccoulson: the g-s patch for suspend lock is quite intrusive; how much did you test this? [11:42] pitti - i tested the default settings on my desktop last night, and the screen locked as expected [11:59] pitti - thanks for sponsoring gnome-session :) [12:12] 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] ...considering how many other core desktop components rely on this counter === MacSlow is now known as MacSlow|lunch [14:16] pitti: could you kick gwibber from unapproved? [14:16] and conkeror/galeon if you have one more minute (those are not that urgent though ... just need to happen at some point) [14:18] asac, those gwibber fixes are working great! [14:19] yep [14:19] 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] i also have images back ;) [14:19] yeah :) [14:19] thx for that [14:19] asac, one thing i have noticed with your timeout changes for facebook [14:20] hmm. right [14:20] i wanted to higher them again [14:20] because its clearly not responsible for the dbus blocking [14:20] in my errors stream, i see those every few hours [14:20] yeah [14:20] yeah [14:20] we can do that in a SRU [14:20] i think bumping it would be good [14:20] its not urgent [14:20] ok [14:20] yeah [14:20] the error shows that some data has been downloaded [14:20] kenvandine, https://bugs.edge.launchpad.net/empathy/+bug/408530/comments/44 ... [14:20] yes. i think 60 seconds or something [14:20] Launchpad bug 408530 in empathy "empathy assertion failure: empathy:ERROR:empathy-tp-chat.c:1391:empathy_tp_chat_acknowledge_message: assertion failed: (m != NULL)" [Medium,Triaged] [14:20] cassidy, i was just reading that [14:21] asac, 60s should be good [14:22] cassidy, we did fix everything you had written up in your review [14:22] also we sould get rid of the facebook authentication in show_ui [14:22] thats a mess [14:22] i'll look at this right now [14:22] blocks gwibber lke 10 seconds to start [14:23] but after karmic release ;) [14:23] 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] cassidy, understand... and it is a huge patch [14:24] * Zdra see only one choice now: drop the patch [14:24] Zdra, that isn't possible for us [14:24] we are at ubuntu RC1 already, not time to fix it anymore === MacSlow|lunch is now known as MacSlow [14:25] kenvandine: did we get news on bindwood already? [14:25] will there be a patch today? [14:25] ;) [14:25] or did that fix slip in without me noticing? [14:25] kenvandine, "not possible" is not possible in software [14:25] asac, you have email [14:26] i have too many emails, yes. :) [14:26] Zdra, the indicator is a very important part of our "experience" [14:26] kenvandine, it's always possible [14:26] kenvandine, segfault too ? [14:26] asac, hold off on uploading that yet though [14:26] Zdra, of course we don't want that [14:26] kenvandine, really, that's not a choice, drop that patch ! [14:26] we want to fix these [14:27] see also how you can't get incoming call and subscription [14:27] Zdra, you can... it works fine [14:27] we want to improve that though [14:27] that's not what says users in a bug I saw this morning [14:27] they appear in the indicator as well [14:27] he just responded and said he didn't look in the indicator [14:28] again, we need to improve that [14:28] personally i feel that very real time things like incoming calls should by-pass the indicator [14:28] with some sort of dialog or something [14:28] we will be discussing this at UDS for sure [14:29] coming up with a better way of handling those [14:29] ...and drop the patch until we come with a good proposal... [14:29] it does work though [14:29] it segfault ! [14:30] did you see how many dups that bug has? [14:30] Zdra it is too late to drop the patch, dropping it would mean switching back to pidgin :/ [14:30] yeah [14:30] Zdra, i am going to work on that now [14:30] we have looked at the bugs carefully to see if they were likely caused by the indicator patch [14:31] kenvandine, in upstream we have good developers that knows the code and we always review any single line patch [14:31] you guys do great reviews :) [14:32] kenvandine, the indicate patch was not made by someone knowing well empathy, it was not reviewed, and worst it was REJECTED upstream [14:32] i appreciated the one you did on the early indicate patch [14:32] Zdra, we did fix everything in your comments [14:33] kenvandine, good, but you should have waited for a 2nd round of review before adding that in the package [14:33] I'll try to review the new patch during the 2.29 cycle [14:33] cassidy, thx [14:33] cassidy, useless we are moving to gnome-shell [14:33] and maybe propose a new design based on the new MC5 API [14:33] i was planning to poke you about that [14:33] after karmic [14:34] kenvandine, is there plan about how libindicate will fit in gnome-shell? [14:34] cassidy, not yet [14:34] no reason there couldn't be an indicator in gnome-shell [14:34] kenvandine, FYI https://bugzilla.gnome.org/show_bug.cgi?id=599193 [14:34] Gnome bug 599193 in general "Implement a Telepathy approver for text channel" [Enhancement,Unconfirmed] [14:34] * hyperair still doesn't really see a difference between the indicator and the notification area [14:34] please try to avoid to re-invent it if the upstream one can do the job [14:35] hyperair, that's "ubuntu experience" [14:35] heh [14:37] cassidy, one of the nice things about the indicator is it actually isn't tied to the panel or necessarily an applet [14:37] it is more of a service that empathy uses [14:37] right now the display/interaction for that service is in a panel applet [14:37] with MC5 you should be able to do that as an external app [14:37] but nothing that uses the indicator has to change if that applet gets replaced with anything else [14:37] without changing Empathy [14:38] kenvandine, then you should discuss to integrate libindicate with gnome-shell people [14:38] there has been discussions [14:38] of some sort [14:39] * kenvandine isn't involved with that stuff :) [14:42] asac, kenvandine, Riddell, pitti, hello ... what's the word? [14:42] hey rickspencer3 [14:42] hey [14:42] rickspencer3: unapproved was crammed last night; the remaining polishing fixes [14:43] hmm [14:43] 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] but that's fairly normal :) so it's fine by and large [14:43] pitti, is there some way to identify the "important" ones [14:43] like U1 kills kittens fix, etc...? [14:44] rickspencer3: yes, those should have karmic'ed and milestoned bugs [14:44] but those are all in now [14:44] libgnome making beeps, etc. [14:44] pitti, is it too late to get Quickly into main? [14:44] j/k [14:44] 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] rickspencer3: of course it's not [14:44] * rickspencer3 runs bughugger [14:44] rickspencer3: just not karmic's main :) [14:45] hehe [14:45] Qubuntu [14:57] hey [14:57] pitti, how is desktop land going? [14:57] hey seb128 [14:57] seb128: seems alright [14:58] pitti, what do you think about updating gnome-desktop now? [14:58] not SRUable? [14:58] * rickspencer3 kicks seb128 [14:58] pitti, what do you think about updating gnome-desktop now? that would give us about GNOME = 2.28.1 [14:58] do we have a related RC bug? [14:58] pitti, what do you think about updating gnome-desktop now? that would give us about GNOME = 2.28.1 [14:59] seb128: how much does it change? [14:59] pitti, what do you think about updating gnome-desktop now? that would give us about GNOME = 2.28.1 [14:59] gnagnagna [14:59] * seb128 kicks hands [14:59] see, that's seb128's convincing strategy [14:59] seb128-bot is stuck in a loop, as he is supposed to be on vacation today [14:59] lol [14:59] keep asking until I give up :) [14:59] sorry doing multi tasking and got page up on the wrong dialog [14:59] pitti, I think it's a no change out of translations [14:59] checking [15:00] hey seb128 ! [15:00] hi huats [15:00] ok [15:01] rickspencer3, pitti: only translation change [15:01] pitti, http://git.gnome.org/cgit/gnome-desktop/log [15:01] and a small build change to use ustar for tarball [15:01] which is just how the tarball is rolled [15:02] 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] seb128: ok if it doesn't change any code; please get it uploaded [15:02] pitti, ok [15:03] thanks [15:03] pitti, can I sync libsoup2.4 too? [15:03] it's a no upstream change [15:03] I dropped some debian dir changes while doing the 2.28.1 update [15:04] we were in sync but bzr was uptodate [15:04] it's basically the shlibs not updated [15:04] slangasek accepted the update but asked to fix before karmic if possible [15:04] ah, and Debian has fixed shlibs? [15:04] please go ahead [15:05] pitti, right, in fact I undid the 2.27.91 to 2.28.0 debdiff [15:05] or rather debian dir diff [15:05] since bzr was outdated [15:05] which was a shilibs update an a monitor control version change (updates standards-version I think) [15:06] ok, doing, thanks [15:16] is there anything in Gnome that would set modification times on files explicitly? I have a weird bug 459011 [15:16] Launchpad bug 459011 in ubuntu "something is resetting modification times on my files" [Undecided,New] https://launchpad.net/bugs/459011 [15:16] no awe today? [15:27] pitti, fix in notify-osd for #396736 (#458413) you want that for release or is that rather for SRU? [15:27] MacSlow: SRU [15:28] (which is the default answer now, unless it fixes a release-critical bug) [15:28] pitti, it's unpleasant but not a crasher [15:35] is example-content's desktop shortcut going to grow an icon? [15:36] hey Keybuk [15:36] Laney, dunno, ask dholbach he might know [15:36] davmor2: yeah [15:36] hey [15:36] I mean [15:37] also gparted's menu entry just says "GParted" [15:37] 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] davmor2: I haven't seen any reports of a recovery mode issue yet [15:37] rickspencer3, pitti, kenvandine: https://bugs.edge.launchpad.net/empathy/+bug/408530/comments/44: -( [15:37] Launchpad bug 408530 in empathy "empathy assertion failure: empathy:ERROR:empathy-tp-chat.c:1391:empathy_tp_chat_acknowledge_message: assertion failed: (m != NULL)" [Medium,Triaged] [15:38] the empathy crash which has a zillion duplicate seems to be due to our libindicate change [15:38] unhappy upstream too [15:38] yeah, just fiddling it [15:38] it's not the only bug [15:38] seb128, yeah we discussed it [15:38] we have an another one with a zillion duplicate too [15:39] 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] and unhappy users as well -- this crash drives me nuts [15:39] kenvandine, thoughts? ^ [15:39] i am looking at that one now [15:39] did empathy deny taking a indicate patch? [15:39] Keybuk: I'm assuming he has written a bug on it or knows what bug it is. [15:39] or just because of quality concerns? [15:40] asac, they didn't take one [15:40] asac, they had quality concern, cf bugzilla bug [15:40] i mean did they refuse to take it because they are against the indicate apporach in general? [15:40] ah ok [15:40] asac, and that's why they are unhappy, we didn't address the concerns and shipped anyway [15:40] davmor2: and you get a recovery shell on top? [15:40] yeah [15:40] ie we just sit on our buggy change [15:41] did we ask for help? [15:41] to who? [15:41] i mean ... maybe they would be willing to do that proper for us ;) [15:41] empathy upstream [15:41] they did comment in details on their issues [15:41] they have enough to do they are not interested to write that change [15:41] they did take time to do a detailled review though [15:42] Keybuk: you get this http://launchpadlibrarian.net/34156895/9.10-friendly-recovery-make-freespace.png [15:42] seb128: yeah ok. [15:42] davmor2: thought so [15:42] tbh, we are not against libindicate, but will prefer to see it more "upstreamed" before merging something like that [15:42] seb128: so the 1 hour reply is the first time they give proper hints? [15:42] davmor2: there's another bug with a different description that's the same underlying bug [15:42] asac, no, there is a long upstream bug discussion [15:42] as I said to kenvandine, gnome-shell could be a good opportunity to push libindicate upstream [15:42] asac, open for months [15:43] as we do want to integrate properly with gnome-shell [15:43] Keybuk: is it the menu system at fault or is it mountall? [15:43] see our roadmap http://live.gnome.org/Empathy/Roadmap/Roadmap230 :) [15:43] seb128: thx [15:43] davmor2: mountall isn't exiting when it should [15:44] asac, search in upstream bugs libindicate title [15:44] asac, search in upstream bugs libindicate title [15:44] ups [15:45] I linked it in my LP rant :) [15:45] Keybuk: okay cool so ball in your court with that one then yes? [15:45] davmor2: I think ion has already fixed it for me ;) [15:46] Keybuk: when you upload it give me a shout and I'll try it out across the board [15:46] seb128: so empathy sends messages twice ;) [15:46] j.k. [15:46] * seb128 slaps asac [15:47] cassidy, btw rants are not the most constructive thing there [15:48] it's not as easy as "drop your changes" [15:48] we have design, schedule etc constrains too [15:48] seb128, I know; but I do think my comment was pretty constructive [15:49] 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] Launchpad bug 454093 in software-center "Ubuntu software center reports crash when trying to install 20+ apps at once" [Undecided,New] https://launchpad.net/bugs/454093 [15:49] right, better than some we had on others bugs ;-) [15:49]