=== hggdh is now known as hggdh|away === Mez_ is now known as Mez [07:05] Good morning [07:06] dobey: no, I didn't write build_icons; most of the basic stuff was written by glatzor, I mostly worked on po file handling and proper cleanup === bluesmoke_ is now known as Amaranth [08:41] hey all [08:41] has anyone experienced with the latest updates some widgets not correctly rendered? [08:50] ara: which widgets exactly? did not see any such thin [08:50] +g [08:51] scale widgets [08:57] ara: bug #347796 perhaps? [08:57] Launchpad bug 347796 in plasma-widget-network-manager "network manager widget not fully visible" [Undecided,New] https://launchpad.net/bugs/347796 [09:01] seb128: hi. what do you think of bug #347684 ? [09:01] Launchpad bug 347684 in seahorse "provide launchpad-integration" [Wishlist,New] https://launchpad.net/bugs/347684 [09:01] Ampelbein: hi, just starting my day let me catch up with emails [09:01] ok [09:11] Ampelbein: the patch looks good thanks, maybe you could work on a debdiff with the autoconf update patch too? [09:11] seb128: sure thing. [09:11] thanks [09:11] seb128: i also added a branch, don't know if this can be used? [09:12] don't forget to subscribe the sponsors team too [09:12] it can but seahorse in not in bzr yet [09:23] hey seb128 [09:23] hello pitti [09:25] morning pitti & seb128 [09:25] lut didrocks [09:27] hey didrocks [09:33] MacSlow: hi, I have a system where the flickering with the osd-notify bubles happens [09:34] MacSlow: compiz looks correct, the matching rules for fade and animation are both in place - this is with a test install of today [09:34] hey mvo! [09:35] mvo, uff ... no clue what could be causing this if our fixes are in place [09:35] brb [09:39] pitti: the retracer get stucked a lot recently apparently [09:39] hey seb128 [09:39] "gpg: Can't check signature: public key not found" [09:39] is what is found in the log when that happens [09:39] did you notice that too? [09:39] seb128: hm, I don't have cron mail today? [09:39] mvo: hello :-) [09:39] MacSlow: might be a problem with the driver, its a r535, we had issues with that in the past [09:39] pitti: it doesn't crash it hangs [09:39] seb128: oh, you mean they are stuck again? [09:39] argh [09:40] seb128: yeah, I noticed as well; yesterday I had to kill them [09:40] pitti: I did restart them yesterday evening on the same issue already [09:40] ok, 3 times in a day [09:40] and I've bugs which are several days old and not retraced [09:40] let's try again [09:41] mvo, hm... ATI then ... flgrx or radeon/radeon-hd? [09:41] MacSlow: radon (well, "ati") [09:43] mvo, my ATI-based system (iMac) currently doesn't boot under Ubuntu at all :/ [09:45] mvo, so it's impossible to test... only thing I can think of atm would be to grab a current live-cd and try that [09:54] pitti: urg [09:54] seb128: ? [09:55] pitti: http://paste.ubuntu.com/136598/ [09:55] pitti: that the "to retrace" pool for the amd64 retracer [09:55] let's see if it manages to go through this time [09:55] seb128: that'lll keep it busy for a while [09:56] indeed [10:01] * pitti toddles off for more test installs [10:01] * seb128 can only do vm testing this week [10:02] MacSlow: so much joy! I just tunred animation and fade off, no flickering, turned both on again, no flickering anymore, reset the compiz settings, no flickering. so now I can not reproduce it anymore [10:02] mvo, same here ... no clue what else could introduce the flickering [10:03] mvo, maybe that user has some "stale" plugin-settings [10:06] MacSlow: it was a fresh install from the current daily [10:19] robert_ancell: good morning; how are you? [10:20] pitti: Doing well. I'm a little worried about how broken python-opengl seems to be in Jaunty though... [10:21] robert_ancell, seb128: do you think it is okay to assign some easy bugs to robert_ancell's queue? or is that too early yet? [10:21] also, I don't know how the two of you want to divide packages/maintenance/bugs between you, did you already happen to talk about this? [10:21] pitti: you are in a hurry apparently ;-) [10:21] pitti: I've some tasks on my lists for him today but feel free to add some [10:22] seb128: well, not much, we just got a few desktop-ish bugs from QA, and I wonder whom to give them to [10:22] pitti: we talked about splitting yesterday but didn't actually look into details yet [10:22] seb128: that doesn't mean that you need to *work* on them today [10:22] pitti: what is that about all those bug assignments from other teams, new policy? [10:22] I got compiz bugs assigned, yeah \o/ [10:22] seb128: I can assign them to you as well, and you delegate further [10:22] ugh [10:23] I've no clue about compiz and I'm not looking forward working on it [10:23] for example, we have this tracker bug (bug 335911), and nobody owns tracker right now [10:23] Launchpad bug 335911 in tracker "Tracker's Evolution mail indexation hangs Evolution" [High,Confirmed] https://launchpad.net/bugs/335911 [10:23] it's one of those unmaintained areas [10:23] pitti: right, upstream said that will be fixed in the new version this week [10:23] that particular one is probably trivial, just disable evo email indexing [10:23] but I'd like someone to supervise it [10:23] pitti: we neither install nor run tracker by default ... [10:23] and I'm afraid I can't take more, I'm too much backlogged already :( [10:23] pitti: it's already on my list but point taken [10:24] seb128: right, but upgraders will have it, and it's in main [10:24] pitti: feel free to assign some bugs to robert_ancell I'll watch his list too in the start [10:24] pitti: I will assign somebody to the update when they roll new tarballs [10:24] but I guess you didn't want to focus on this example [10:24] seb128: thus my question whether I should assign to you and you delegate, or just distribute between the two of you [10:25] just assign some bugs to robert_ancell that's fine, I will make sure that's something he can manage and do adjustements if required [10:25] okay, thanks [10:25] as you want [10:25] as I said, no need to hurry working on them, from my POV I just want to balance the bug assignment workload evenly [10:27] right [10:27] robert_ancell: https://wiki.ubuntu.com/PackagingGuide [10:28] seb128: btw, you know about ct-rev? [10:29] pitti: no [10:29] seb128: so, if you get a bug assigned from QA, that doesn't mean that you are 100% required to fix it [10:31] seb128: but that it should be reviewed by an expert [10:31] seb128: and if you think that the bug is not important enough for us to work on, or it's too hard, or is waiting for upstream, etc., then unassign yourself and tag it "ct-rev" [10:31] seb128: QA won't reassign ct-rev'ed bugs back to us [10:31] oh ok [10:31] why don't we get announce about such policy changes ... [10:31] seb128: that's the new experimental workflow for QA to help us focusing on bugs which seem important/regressions [10:31] is that documented somewhere ? [10:31] seb128: let's bring it up in today's meeting [10:31] right [10:31] DOH, meeting -> activity report [10:32] indeed [10:32] * pitti writes [10:43] seb128: why do we have to use dbus-launch gnome-session and not only "gnome-session"? -> I assume that a new dbus should be associated with the new session, but gnome-session does not launch dbus by default, right? [10:44] didrocks: gnome-session needs a session bus to talk over [10:45] seb128: ok, so, if I only call gnome-session, I will talk to the other dbus [10:45] (the one linked to X:0 gnome-session) [10:45] what do you mean? [10:45] there is no dbus session running for your testuser [10:46] seb128: I can simply call, with my testuser "DISPLAY=:1 gnome-session" and it works, so, if gnome-session needs absolutely a dbus to talk with, which one does it take? [10:48] seb128: gnome-session relaunches itself with dbus-launch, fwiw [10:48] (when there's no bus) [10:48] didrocks: ok so good it's not needed [10:49] vuntz: cool [10:49] thanks vuntz & seb128 :) [10:49] it doesn't work here though [10:49] "gnome-session[14927]: WARNING: Could not make bus activated clients aware of DISPLAY=:1.0 environment variable: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. [10:49] " [10:50] I get such errors [10:50] seb128: strange, I can do a print screen to prove it, if you whish :) [10:50] and in the session a dialog "couldn't connect to the session bus" [10:50] "Could not acquire name on session bus" [10:51] didrocks: how do you start xephyr? maybe you did start dbus before with your test user today? [10:51] seb128: simply "$ Xephyr :1" in my user session to run Xephyr server [10:51] and under my testuser: [10:51] DISPLAY=:1 gnome-session [10:51] that's it [10:53] seb128: did you use "su -"? [10:53] (su - $user, I mean) [10:54] seb128: you need to have the dbus environment variable unset [10:54] vuntz: no, "su user" [10:54] (I can confirm, it's unset on my side) [10:56] seb128: su - user, then [10:56] vuntz: right ;-) [10:56] seb128: I blame you [10:56] seb128: it's all your fault [10:57] vuntz: I take the blame for this one ... how about session saving for non-logout actions, are you still planning to work on it? [10:57] heh [10:57] don't change the topic of this discussion! :-) [10:57] yeah, I'll work on this [10:57] * seb128 hugs vuntz [10:58] I just guess there might be a bad case [10:58] seb128 knows where to lead the discussion when something is embarrassing ;) [10:59] need to look at the ConsoleKit API, but if shutting down requires authorization, then it'll be, hrm, fun [10:59] (kill all clients, then show the dialog asking for the password... what if you don't give the right password?) [10:59] didrocks: it's not embarassing we just didn't use the same way to switch users, if you use "su user" you need dbus-launch ;-) [11:00] vuntz: check if you need authorization before starting closing clients? [11:00] seb128: right :), but seing at my company how the UNIX user environnement are tuned and not properly cleaned, I always user - to get a fresh environment :) [11:01] seb128: right, but if you need authorization, what should you do? Ask for it? It will shut down immediately, without waiting for the clients to stop [11:01] pitti: ok [11:01] vuntz: hum, tricky... [11:02] vuntz: can't you just ask for authorization, then close the client and process to reboot? [11:02] you can gain the auth without triggering the action [11:03] seb128: I don't think so [11:04] ask for the password twice ;-) [11:04] one just to be sure the user has it [11:04] and one to do the action ;-) [11:04] seb128: hehe :) [11:04] there is no password caching? [11:04] ie you can't do 2 different actions by asking the password once? [11:05] seb128: depends of the config [11:05] if password is asked twice for some corner cases now I guess that's okish [11:05] seb128: if the PolicyKit config for this action is auth_self_one_shot or auth_admin_one_shot, it can ask it twice [11:06] but it might be possible to handle the other cases in a sane way [11:08] right, as said that's a corner case I would not worry too much about it now [11:08] can't you call polkit_context_can_session_do_action or similar, and if it returns auth_*, do the authentication, then call the action? [11:09] if it returns yes, then just call the action [11:14] mvo: do you think you could take over bug #331918? it seems to be on track with upstream comments there [11:14] Launchpad bug 331918 in compiz "Clipped area for multiple X screens with different dimensions" [Medium,Confirmed] https://launchpad.net/bugs/331918 [11:16] james_w: the problem is that we don't want to do the action immediately [11:16] yeah, it's racy [11:16] james_w: and we don't know exactly which action we'll have to do (since we call Restart() and multiple actions can be returned) [11:17] because of multiple users? [11:17] yes [11:17] ah [11:17] it would be possible to reimplement half the logic, but that's even more racy. [11:18] but, well, if we manually detect there are multiple users and use the right action, we would just stop working when ConsoleKit logic will change [11:18] it seems like ConsoleKit will have to grow some sort of callback? [11:18] james_w: maybe [11:29] Guys is it know that evolutions notify-osd plugin only tells you about mail in the inbox and not every mail box this is a regression over the old notify system where you just unchecked the box for only inbox [11:31] yes [11:32] seb128: Thanks [11:36] I don't find the bug number now [11:36] but I read some complains about that [11:36] I'm pretty sure that's how the code used to work though [11:47] seb128: it is how it used to work unless you unchecked the box in plugins then it would tell you what box had mail see screenshot at http://www.davmor2.co.uk/evo-notify.png [11:52] davmor2: what do you have set in Edit->Preferences->Mail Preferences? [11:53] "When new mail arrives in ..." [11:54] james_w: It was on inbox :) It isn't any more thanks I'll try it :) [11:54] seb128: FYI, current bzr automatically sets the push location if you can write to the branch [11:54] seb128: i. e. "debcheckout -a apport" (or any other bzr-maintained package) will just DTRT now \o/ [11:54] pitti: excellent ;-) [11:54] that's bzr, or debcheckout? [11:55] james_w: bzr [11:55] I made a TODO item to fix it in debcheckout, but seems bzr itself beat me to it :) [11:55] I don't think it has changed there [11:56] well, I just tested debcheckout -a apport, and it worked [11:56] testing bzr now [11:56] if ($repo_type eq 'bzr' and $auth) { [11:56] if (open B, '>>', "$destdir/.bzr/branch/branch.conf") { [11:56] print B "\npush_location = $repo_url"; [11:56] close B; [11:56] } else { [11:56] print STDERR "failed to open branch.conf to add push_location: $@\n"; [11:56] } [11:56] } [11:57] so debcheckout :-) [11:58] ah, indeed; bzr get lp:apport doesn't [11:58] it ought to, though [11:58] seb128: anyway, debcheckout! :-) [11:59] james_w: how do you determine if a package is in ~core-dev or ~ubuntu-desktop for instance. A hard list, based on Vcs-Bzr: regularly refreshed? [11:59] didrocks: I don't? [11:59] didrocks: Vcs-Bzr: needs to be kept current [11:59] why would I do that? [12:00] james_w: for debcheckout, some package are in ~core-dev, other in ~ubuntu-desktop, etc., or do you just pull all of them in ~core-dev? [12:00] ah [12:00] debcheckout, not me :-) [12:00] it uses Sources.gz [12:00] oh, ok :-) [12:01] Vcs-Bzr ends up there, so it can look it up from your apt cache [12:01] so, it's downloading source package as well, in addition to the branch? [12:01] oh non, Sources.gz [12:01] no* [12:01] ok, understood, thanks :) [12:03] pitti: retracers stucked again, I'm restarting it [12:05] bwah [12:05] seb128: next time I'd like to strace it [12:05] pitti: the i386 one seems stucked the same way so feel free [12:06] * pitti looks [12:06] mvo: stop ignoring me on reply on other channels ;-) [12:07] seb128: hm? [12:08] mvo: do you think you could take over bug #331918? it seems to be on track with upstream comments there [12:08] Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/331918/+text) [12:08] mvo: ^ I asked that some time ago ;-) [12:08] seb128: chekcing now [12:08] seb128: if you did, I missed that, sorry [12:08] mvo: that's ok [12:09] mvo: I did almost an hour ago but maybe you were at lunch [12:09] seb128: possible, I disconnected in between (network-manager upgrade :) - maybe then [12:11] seb128: why is it assigned to you ? [12:11] seb128: (not that I mind :) [12:11] just curious [12:11] mvo: cf query ;-p [12:12] ok [12:16] mvo: short story it got assigned to the desktop team and my manager dispatched the task to me next ;-) [12:24] mvo: btw compiz has a reflection.png which is over a megabyte, do you think it could be shrinked by some way for CD benefits? ;-) [12:24] mvo: I was just looking at what is using space yesterday and ran into this one [12:26] seb128: let me have a look, I don't know what it is used for [12:26] that's probably not worth bothering too much but I was wondering if a lower quality png would do the same job [12:30] asac: network-manager keeps telling me (every 5 minutes or so) that it can not find a required recource during upgrade [12:30] asac: is that known? [12:32] mvo: bug #279820 you might want to look at it, #ubuntu-bugs guys did a good job at getting a debug stacktrace and it has lot of duplicates [12:32] Launchpad bug 279820 in compiz "compiz.real crashed with SIGSEGV" [Medium,Incomplete] https://launchpad.net/bugs/279820 [12:33] mvo: that sounds like a dejavu [12:34] seb128: sure, let me have a look [12:35] mvo: last time it was about changed image names [12:35] mvo: reload if the current comment doesn't have it yet, it just has been added [12:35] asac: oh, that is quite possible [12:35] mvo: but odd. from 0.6 to 0.7 there were images renamed ... i didnt see that for 0.7 to 0.7.1 [12:36] asac, mvo: could be debian bug #520919? [12:36] Debian bug 520919 in icon-naming-utils "icon-naming-utils: wrong icons for NetworkManager" [Unknown,Closed] http://bugs.debian.org/520919 [12:37] mvo: maybe its human theme ... dxteam changed a bit there [12:37] exchanging files for links etc. [12:37] looking at debian bug [12:38] hum, probably not [12:38] that would just lead to wrong icons being displayed [12:38] seb128: what does icon-naming-utils do? [12:39] asac: it provides a list of alternative names for icons basically [12:39] asac: and is used by gnome-icon-themes for example during the build [12:40] asac: they use those lists to make symlinking to other names from the available icons [12:41] seb128: hmm. [12:41] nm-device-wireless is shipped by nm [12:42] that's fine [12:42] the nm variant is just not used [12:42] it's installed in hicolor [12:42] and the gnome theme has its own icon which takes over hicolor [12:43] and the human theme its own icon too [12:43] seb128: ah. so its for gnome theme [12:43] right, what that says is that the real speced name is "network-wireless" [12:44] but that gnome-icon-theme (or any other theme using naming utils) will do nm-device-wireless -> "network-wireless" [12:44] yeah. understood [12:44] mvo: ok call? [12:45] asac: 5min? [12:46] mvo: ok [12:53] pedro_: holla, can you add you "send to GNOME" stock comment on bug #345550? [12:53] Launchpad bug 345550 in gstreamer0.10 "gnome-sound-properties freez" [Low,Confirmed] https://launchpad.net/bugs/345550 [12:53] pedro_: I think you have instructions on how to do that there ;-) [12:54] seb128: salut, sure i'll take care of that ;-) [12:56] seb128: i just link people to https://wiki.ubuntu.com/Bugs/Upstream/GNOME which has the info on how to do it [12:56] btw already did it [12:57] robert_ancell: hi [12:57] hey rickspencer3 [12:58] pedro_: ok thanks [12:59] rickspencer3: hi rick [12:59] hello rickspencer3 [12:59] rickspencer3: thanks for assigning me compiz bugs ;-) === hggdh|away is now known as hggdh [13:00] seb128: sorry, I didn't know what else to do with it [13:00] assign it back to me if I should find someone else [13:00] rickspencer3: mvo ;) [13:00] seb128, just FYI -- I have a diff for Evolution 2.26, if and when libpst gets approved. No need to answer. [13:01] I'm off for about two hours, lunch and some errands [13:01] rickspencer3: that's ok, we have friends doing compiz in the foundation team, mvo is looking at it for me now [13:01] asac: well, the Foundations team asked if we could alleviate compiz from mvo [13:01] hggdh: ok thanks [13:01] seb128: I had a feeling that's what would happen :) [13:01] rickspencer3: ah. ok then for now its closer to bryce i would think [13:02] rickspencer3: to be honest I don't think we have the ressources to take over this one now [13:02] I understand that mvo is busy but compiz is quite some work and I don't think we have anybody in the team who worked on it yet [13:03] it's going to take some work before knowing the code and upstream as well as mvo do [13:04] seb128: ok [13:04] I'll talk to robbiew and mvo about the rest of Jaunty [13:04] thanks [13:04] we should do a cleaner break for Karmic [13:05] right [14:12] calc: can you please include a whitespace before your bullet points of your activity? [14:13] bryce: ^^ ;) [14:13] robert_ancell: https://help.launchpad.net/Packaging/PPA if you want to learn about ppa too [14:14] salut seb128 [14:14] lut crevette [14:17] mvo: BUGabundo is back on #ubuntu-bugs and looking for you [14:17] seb128 I will be there in a minute or so, my real system is doing a *long* fsck right now [14:17] ok [14:17] maybe more than a minute :) [14:17] ;-) [14:19] asac: eh? [14:19] calc: look at the wiki [14:20] calc: https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-03-24 [14:20] i think your activity always looks that way ;) [14:20] asac: hmm i wonder why :\ [14:20] asac: i send them in email and they look fine then [14:20] i'll fix it though [14:21] calc: you need to include a whitespace like you would do it in wiki [14:21] whitespace where? [14:21] if you do its a pitt/rick bug ;) [14:21] after the * there is one after it [14:21] calc: in front of the * [14:22] calc: just try to use the same form in mail that you need to use in wiki [14:22] oh hmm, well there are others without whitespace before the * in the current wiki, so that is a bit odd [14:22] eg: [14:22] === Misc === [14:22] * Discussing ideas on bug sorting/filtering [14:22] there is no whitespace on that line either but it displayed correctly [14:22] calc: i think it works if you also have a empty line [14:22] calc: but its not right; as you can see those are no real HTML bullet points [14:22] oh hold on that one is broken a bit too, nm :) [14:23] yeah [14:23] ok will fix mine up and add extra space from now on (or try to remember to anyway) [14:23] vuntz: hey [14:23] vuntz: you are running GNOME 2.26 right? ;-) [14:24] vuntz: are the action in gnome-keybinding-properties translated for you? [14:24] asac: i fixed up bryce as well [14:24] calc: cool. seb128 is also broken ;) [14:25] seb128: fix yours :) [14:25] * seb128 slaps asac [14:25] kenvandine_wk's isn't using wiki format but is readable [14:25] :) [14:25] * asac falls to ground [14:25] i guess i should use wiki formatting [14:26] we should stop using wikis [14:26] what's wrong with good old ascii formating? [14:26] * kenvandine_wk is just emailing it to rickspencer3... [14:26] seb128: you can include a {{{ [14:26] }}} [14:26] if you want to keep it ascii ;) [14:26] seb128: text files ftw [14:26] text files and bzr [14:27] we can all pull and read in $EDITOR [14:27] asac: we should put those at the limit of the page ;-) [14:27] kenvandine_wk: that's how I plan to handle the desktop team list of who is doing what btw ;-) [14:27] seb128: awesome [14:27] :) [14:27] anyone know how to get the cups queue name from command line? [14:28] i was going to ask till but he seems to not be online [14:28] he gave me a bug that I need to investigate [14:28] lpq? [14:28] should list all queues [14:28] seb128: which actions? [14:29] seb128: some are not translated here [14:29] oh i guess then i have no queues since the printer isn't physically connected to this box [14:29] vuntz: in my case most are not, ie next track, previous track, volume ... [14:30] seb128: those ones are translated [14:30] seb128: but the run dialog isn't, eg [14:30] vuntz: ok thanks [14:30] or "switch to workspace on the left/right/..." [14:31] do you know what component has those strings? [14:32] ah, gnome-settings-daemon [14:33] weird, the .mo has the translation for "Next track" [14:34] I bet that's because gnome-control-center doesn't use the gnome-settings-daemon mo file [14:35] vuntz: does your gnome-control-center mo files has Next track translated? [14:38] seb128: hrm, how can I find out? With a strings on the mo file? [14:38] vuntz: msgunfmt .mo [14:38] seb128: it's in gsd [14:38] not gcc [14:39] vuntz: right, I'm just puzzled on how it gets translated for you [14:39] vuntz: stracing gnome-keybinding-properties shows it doesn't open the gnome-settings-daemon.mo there [14:39] vuntz: I've opened http://bugzilla.gnome.org/show_bug.cgi?id=576570 about that [14:40] Gnome bug 576570 in Keybinding "gnome-settings-daemon actions are not translated" [Normal,New] [14:40] no idea :-) [14:40] vuntz: are you sure you don't have the string left over in the g-c-c .mo installed? [14:41] <_MMA_> Will the "CD/DVD Creator" entry be staying visible in "System Tools"? for release? [14:41]