[07:05] <pitti> Good morning
[07:06] <pitti> 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
[08:41] <ara> hey all
[08:41] <ara>  has anyone experienced with the latest updates some widgets not correctly rendered?
[08:50] <Ampelbein> ara: which widgets exactly? did not see any such thin
[08:50] <Ampelbein> +g
[08:51] <ara> scale widgets
[08:57] <Ampelbein> ara: bug #347796 perhaps?
[09:01] <Ampelbein> seb128: hi. what do you think of bug #347684 ?
[09:01] <seb128> Ampelbein: hi, just starting my day let me catch up with emails
[09:01] <Ampelbein> ok
[09:11] <seb128> Ampelbein: the patch looks good thanks, maybe you could work on a debdiff with the autoconf update patch too?
[09:11] <Ampelbein> seb128: sure thing.
[09:11] <seb128> thanks
[09:11] <Ampelbein> seb128: i also added a branch, don't know if this can be used?
[09:12] <seb128> don't forget to subscribe the sponsors team too
[09:12] <seb128> it can but seahorse in not in bzr yet
[09:23] <pitti> hey seb128
[09:23] <seb128> hello pitti
[09:25] <didrocks> morning pitti & seb128
[09:25] <seb128> lut didrocks
[09:27] <pitti> hey didrocks
[09:33] <mvo> MacSlow: hi, I have a system where the flickering with the osd-notify bubles happens
[09:34] <mvo> 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] <seb128> hey mvo!
[09:35] <MacSlow> mvo, uff ... no clue what could be causing this if our fixes are in place
[09:35] <seb128> brb
[09:39] <seb128> pitti: the retracer get stucked a lot recently apparently
[09:39] <mvo> hey seb128
[09:39] <seb128> "gpg: Can't check signature: public key not found"
[09:39] <seb128> is what is found in the log when that happens
[09:39] <seb128> did you notice that too?
[09:39] <pitti> seb128: hm, I don't have cron mail today?
[09:39] <seb128> mvo: hello :-)
[09:39] <mvo> MacSlow: might be a problem with the driver, its a r535, we had issues with that in the past
[09:39] <seb128> pitti: it doesn't crash it hangs
[09:39] <pitti> seb128: oh, you mean they are stuck again?
[09:39] <pitti> argh
[09:40] <pitti> seb128: yeah, I noticed as well; yesterday I had to kill them
[09:40] <seb128> pitti: I did restart them yesterday evening on the same issue already
[09:40] <seb128> ok, 3 times in a day
[09:40] <seb128> and I've bugs which are several days old and not retraced
[09:40] <seb128> let's try again
[09:41] <MacSlow> mvo, hm... ATI then ... flgrx or radeon/radeon-hd?
[09:41] <mvo> MacSlow: radon (well, "ati")
[09:43] <MacSlow> mvo, my ATI-based system (iMac) currently doesn't boot under Ubuntu at all :/
[09:45] <MacSlow> 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] <seb128> pitti: urg
[09:54] <pitti> seb128: ?
[09:55] <seb128> pitti: http://paste.ubuntu.com/136598/
[09:55] <seb128> pitti: that the "to retrace" pool for the amd64 retracer
[09:55] <seb128> let's see if it manages to go through this time
[09:55] <pitti> seb128: that'lll keep it busy for a while
[09:56] <seb128> indeed
[10:01]  * pitti toddles off for more test installs
[10:01]  * seb128 can only do vm testing this week
[10:02] <mvo> 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] <MacSlow> mvo, same here ... no clue what else could introduce the flickering
[10:03] <MacSlow> mvo, maybe that user has some "stale" plugin-settings
[10:06] <mvo> MacSlow: it was a fresh install from the current daily
[10:19] <pitti> robert_ancell: good morning; how are you?
[10:20] <robert_ancell> pitti: Doing well.  I'm a little worried about how broken python-opengl seems to be in Jaunty though...
[10:21] <pitti> 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] <pitti> 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] <seb128> pitti: you are in a hurry apparently ;-)
[10:21] <seb128> pitti: I've some tasks on my lists for him today but feel free to add some
[10:22] <pitti> seb128: well, not much, we just got a few desktop-ish bugs from QA, and I wonder whom to give them to
[10:22] <seb128> pitti: we talked about splitting yesterday but didn't actually look into details yet
[10:22] <pitti> seb128: that doesn't mean that you need to *work* on them today
[10:22] <seb128> pitti: what is that about all those bug assignments from other teams, new policy?
[10:22] <seb128> I got compiz bugs assigned, yeah \o/
[10:22] <pitti> seb128: I can assign them to you as well, and you delegate further
[10:22] <pitti> ugh
[10:23] <seb128> I've no clue about compiz and I'm not looking forward working on it
[10:23] <pitti> for example, we have this tracker bug (bug 335911), and nobody owns tracker right now
[10:23] <pitti> it's one of those unmaintained areas
[10:23] <seb128> pitti: right, upstream said that will be fixed in the new version this week
[10:23] <pitti> that particular one is probably trivial, just disable evo email indexing
[10:23] <pitti> but I'd like someone to supervise it
[10:23] <seb128> pitti: we neither install nor run tracker by default ...
[10:23] <pitti> and I'm afraid I can't take more, I'm too much backlogged already :(
[10:23] <seb128> pitti: it's already on my list but point taken
[10:24] <pitti> seb128: right, but upgraders will have it, and it's in main
[10:24] <seb128> pitti: feel free to assign some bugs to robert_ancell I'll watch his list too in the start
[10:24] <seb128> pitti: I will assign somebody to the update when they roll new tarballs
[10:24] <seb128> but I guess you didn't want to focus on this example
[10:24] <pitti> seb128: thus my question whether I should assign to you and you delegate, or just distribute between the two of you
[10:25] <seb128> 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] <pitti> okay, thanks
[10:25] <seb128> as you want
[10:25] <pitti> 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] <seb128> right
[10:27] <seb128> robert_ancell: https://wiki.ubuntu.com/PackagingGuide
[10:28] <pitti> seb128: btw, you know about ct-rev?
[10:29] <seb128> pitti: no
[10:29] <pitti> seb128: so, if you get a bug assigned from QA, that doesn't mean that you are 100% required to fix it
[10:31] <pitti> seb128: but that it should be reviewed by an expert
[10:31] <pitti> 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] <pitti> seb128: QA won't reassign ct-rev'ed bugs back to us
[10:31] <seb128> oh ok
[10:31] <seb128> why don't we get announce about such policy changes ...
[10:31] <pitti> seb128: that's the new experimental workflow for QA to help us focusing on bugs which seem important/regressions
[10:31] <seb128> is that documented somewhere ?
[10:31] <pitti> seb128: let's bring it up in today's meeting
[10:31] <seb128> right
[10:31] <seb128> DOH, meeting -> activity report
[10:32] <pitti> indeed
[10:32]  * pitti writes
[10:43] <didrocks> 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] <seb128> didrocks: gnome-session needs a session bus to talk over
[10:45] <didrocks> seb128: ok, so, if I only call gnome-session, I will talk to the other dbus
[10:45] <didrocks> (the one linked to X:0 gnome-session)
[10:45] <seb128> what do you mean?
[10:45] <seb128> there is no dbus session running for your testuser
[10:46] <didrocks> 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] <vuntz> seb128: gnome-session relaunches itself with dbus-launch, fwiw
[10:48] <vuntz> (when there's no bus)
[10:48] <seb128> didrocks: ok so good it's not needed
[10:49] <seb128> vuntz: cool
[10:49] <didrocks> thanks vuntz & seb128 :)
[10:49] <seb128> it doesn't work here though
[10:49] <seb128> "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] <seb128> "
[10:50] <seb128> I get such errors
[10:50] <didrocks> seb128: strange, I can do a print screen to prove it, if you whish :)
[10:50] <seb128> and in the session a dialog "couldn't connect to the session bus"
[10:50] <seb128> "Could not acquire name on session bus"
[10:51] <seb128> didrocks: how do you start xephyr? maybe you did start dbus before with your test user today?
[10:51] <didrocks> seb128: simply "$ Xephyr :1" in my user session to run Xephyr server
[10:51] <didrocks> and under my testuser:
[10:51] <didrocks> DISPLAY=:1 gnome-session
[10:51] <didrocks> that's it
[10:53] <vuntz> seb128: did you use "su -"?
[10:53] <vuntz> (su - $user, I mean)
[10:54] <vuntz> seb128: you need to have the dbus environment variable unset
[10:54] <seb128> vuntz: no, "su user"
[10:54] <didrocks> (I can confirm, it's unset on my side)
[10:56] <vuntz> seb128: su - user, then
[10:56] <seb128> vuntz: right ;-)
[10:56] <vuntz> seb128: I blame you
[10:56] <vuntz> seb128: it's all your fault
[10:57] <seb128> 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] <vuntz> heh
[10:57] <vuntz> don't change the topic of this discussion! :-)
[10:57] <vuntz> yeah, I'll work on this
[10:57]  * seb128 hugs vuntz
[10:58] <vuntz> I just guess there might be a bad case
[10:58] <didrocks> seb128 knows where to lead the discussion when something is embarrassing ;)
[10:59] <vuntz> need to look at the ConsoleKit API, but if shutting down requires authorization, then it'll be, hrm, fun
[10:59] <vuntz> (kill all clients, then show the dialog asking for the password... what if you don't give the right password?)
[10:59] <seb128> 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] <seb128> vuntz: check if you need authorization before starting closing clients?
[11:00] <didrocks> 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] <vuntz> 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] <dobey> pitti: ok
[11:01] <seb128> vuntz: hum, tricky...
[11:02] <seb128> vuntz: can't you just ask for authorization, then close the client and process to reboot?
[11:02] <james_w> you can gain the auth without triggering the action
[11:03] <vuntz> seb128: I don't think so
[11:04] <seb128> ask for the password twice ;-)
[11:04] <seb128> one just to be sure the user has it
[11:04] <seb128> and one to do the action ;-)
[11:04] <didrocks> seb128: hehe :)
[11:04] <seb128> there is no password caching?
[11:04] <seb128> ie you can't do 2 different actions by asking the password once?
[11:05] <vuntz> seb128: depends of the config
[11:05] <seb128> if password is asked twice for some corner cases now I guess that's okish
[11:05] <vuntz> 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] <vuntz> but it might be possible to handle the other cases in a sane way
[11:08] <seb128> right, as said that's a corner case I would not worry too much about it now
[11:08] <james_w> 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] <james_w> if it returns yes, then just call the action
[11:14] <seb128> mvo: do you think you could take over bug #331918? it seems to be on track with upstream comments there
[11:16] <vuntz> james_w: the problem is that we don't want to do the action immediately
[11:16] <james_w> yeah, it's racy
[11:16] <vuntz> 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] <james_w> because of multiple users?
[11:17] <vuntz> yes
[11:17] <james_w> ah
[11:17] <james_w> it would be possible to reimplement half the logic, but that's even more racy.
[11:18] <vuntz> 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] <james_w> it seems like ConsoleKit will have to grow some sort of callback?
[11:18] <vuntz> james_w: maybe
[11:29] <davmor2> 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] <seb128> yes
[11:32] <davmor2> seb128: Thanks
[11:36] <seb128> I don't find the bug number now
[11:36] <seb128> but I read some complains about that
[11:36] <seb128> I'm pretty sure that's how the code used to work though
[11:47] <davmor2> 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] <james_w> davmor2: what do you have set in Edit->Preferences->Mail Preferences?
[11:53] <james_w> "When new mail arrives in ..."
[11:54] <davmor2> james_w: It was on inbox :)  It isn't any more  thanks  I'll try it :)
[11:54] <pitti> seb128: FYI, current bzr automatically sets the push location if you can write to the branch
[11:54] <pitti> seb128: i. e. "debcheckout -a apport" (or any other bzr-maintained package) will just DTRT now \o/
[11:54] <seb128> pitti: excellent ;-)
[11:54] <james_w> that's bzr, or debcheckout?
[11:55] <pitti> james_w: bzr
[11:55] <pitti> I made a TODO item to fix it in debcheckout, but seems bzr itself beat me to it :)
[11:55] <james_w> I don't think it has changed there
[11:56] <pitti> well, I just tested debcheckout -a apport, and it worked
[11:56] <pitti> testing bzr now
[11:56] <james_w>   if ($repo_type eq 'bzr' and $auth) {
[11:56] <james_w>     if (open B, '>>', "$destdir/.bzr/branch/branch.conf") {
[11:56] <james_w>       print B "\npush_location = $repo_url";
[11:56] <james_w>       close B;
[11:56] <james_w>     } else {
[11:56] <james_w>       print STDERR "failed to open branch.conf to add push_location: $@\n";
[11:56] <james_w>     }
[11:56] <james_w>   }
[11:57] <james_w> so debcheckout :-)
[11:58] <pitti> ah, indeed; bzr get lp:apport doesn't
[11:58] <pitti> it ought to, though
[11:58] <pitti> seb128: anyway, debcheckout! :-)
[11:59] <didrocks> 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] <james_w> didrocks: I don't?
[11:59] <pitti> didrocks: Vcs-Bzr: needs to be kept current
[11:59] <james_w> why would I do that?
[12:00] <didrocks> 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] <james_w> ah
[12:00] <james_w> debcheckout, not me :-)
[12:00] <james_w> it uses Sources.gz
[12:00] <didrocks> oh, ok :-)
[12:01] <james_w> Vcs-Bzr ends up there, so it can look it up from your apt cache
[12:01] <didrocks> so, it's downloading source package as well, in addition to the branch?
[12:01] <didrocks> oh non, Sources.gz
[12:01] <didrocks> no*
[12:01] <didrocks> ok, understood, thanks :)
[12:03] <seb128> pitti: retracers stucked again, I'm restarting it
[12:05] <pitti> bwah
[12:05] <pitti> seb128: next time I'd like to strace it
[12:05] <seb128> pitti: the i386 one seems stucked the same way so feel free
[12:06]  * pitti looks
[12:06] <seb128> mvo: stop ignoring me on reply on other channels ;-)
[12:07] <mvo> seb128: hm?
[12:08] <seb128> mvo: do you think you could take over bug #331918? it seems to be on track with upstream comments there
[12:08] <seb128> mvo: ^ I asked that some time ago ;-)
[12:08] <mvo> seb128: chekcing now
[12:08] <mvo> seb128: if you did, I missed that, sorry
[12:08] <seb128> mvo: that's ok
[12:09] <seb128> mvo: I did almost an hour ago but maybe you were at lunch
[12:09] <mvo> seb128: possible, I disconnected in between (network-manager upgrade :) - maybe then
[12:11] <mvo> seb128: why is it assigned to you ?
[12:11] <mvo> seb128: (not that I mind :)
[12:11] <mvo> just curious
[12:11] <seb128> mvo: cf query ;-p
[12:12] <mvo> ok
[12:16] <seb128> mvo: short story it got assigned to the desktop team and my manager dispatched the task to me next ;-)
[12:24] <seb128> 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] <seb128> mvo: I was just looking at what is using space yesterday and ran into this one
[12:26] <mvo> seb128: let me have a look, I don't know what it is used for
[12:26] <seb128> that's probably not worth bothering too much but I was wondering if a lower quality png would do the same job
[12:30] <mvo> asac: network-manager keeps telling me (every 5 minutes or so) that it can not find a required recource during upgrade
[12:30] <mvo> asac: is that known?
[12:32] <seb128> 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:33] <asac> mvo: that sounds like a dejavu
[12:34] <mvo> seb128: sure, let me have a look
[12:35] <asac> mvo: last time it was about changed image names
[12:35] <seb128> mvo: reload if the current comment doesn't have it yet, it just has been added
[12:35] <mvo> asac: oh, that is quite possible
[12:35] <asac> 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] <seb128> asac, mvo: could be debian bug #520919?
[12:37] <asac> mvo: maybe its human theme ... dxteam changed a bit there
[12:37] <asac> exchanging files for links etc.
[12:37] <asac> looking at debian bug
[12:38] <seb128> hum, probably not
[12:38] <seb128> that would just lead to wrong icons being displayed
[12:38] <asac> seb128: what does icon-naming-utils do?
[12:39] <seb128> asac: it provides a list of alternative names for icons basically
[12:39] <seb128> asac: and is used by gnome-icon-themes for example during the build
[12:40] <seb128> asac: they use those lists to make symlinking to other names from the available icons
[12:41] <asac> seb128: hmm. <icon name="network-wireless">
[12:41] <asac> <link ... nm-device-wireless ...
[12:41] <asac> nm-device-wireless is shipped by nm
[12:42] <seb128> that's fine
[12:42] <seb128> the nm variant is just not used
[12:42] <seb128> it's installed in hicolor
[12:42] <seb128> and the gnome theme has its own icon which takes over hicolor
[12:43] <seb128> and the human theme its own icon too
[12:43] <asac> seb128: ah. so its for gnome theme
[12:43] <seb128> right, what that says is that the real speced name is "network-wireless"
[12:44] <seb128> but that gnome-icon-theme (or any other theme using naming utils) will do nm-device-wireless -> "network-wireless"
[12:44] <asac> yeah. understood
[12:44] <asac> mvo: ok call?
[12:45] <mvo> asac: 5min?
[12:46] <asac> mvo: ok
[12:53] <seb128> pedro_: holla, can you add you "send to GNOME" stock comment on bug #345550?
[12:53] <seb128> pedro_: I think you have instructions on how to do that there ;-)
[12:54] <pedro_> seb128: salut, sure i'll take care of that ;-)
[12:56] <pedro_> seb128: i just link people to https://wiki.ubuntu.com/Bugs/Upstream/GNOME which has the info on how to do it
[12:56] <pedro_> btw already did it
[12:57] <rickspencer3> robert_ancell: hi
[12:57] <pitti> hey rickspencer3
[12:58] <seb128> pedro_: ok thanks
[12:59] <robert_ancell> rickspencer3: hi rick
[12:59] <seb128> hello rickspencer3
[12:59] <seb128> rickspencer3: thanks for assigning me compiz bugs ;-)
[13:00] <rickspencer3> seb128: sorry, I didn't know what else to do with it
[13:00] <rickspencer3> assign it back to me if I should find someone else
[13:00] <asac> rickspencer3: mvo ;)
[13:00] <hggdh> seb128, just FYI -- I have a diff for Evolution 2.26, if and when libpst gets approved. No need to answer.
[13:01] <pitti> I'm off for about two hours, lunch and some errands
[13:01] <seb128> rickspencer3: that's ok, we have friends doing compiz in the foundation team, mvo is looking at it for me now
[13:01] <rickspencer3> asac: well, the Foundations team asked if we could alleviate compiz from mvo
[13:01] <seb128> hggdh: ok thanks
[13:01] <rickspencer3> seb128: I had a feeling that's what would happen :)
[13:01] <asac> rickspencer3: ah. ok then for now its closer to bryce i would think
[13:02] <seb128> rickspencer3: to be honest I don't think we have the ressources to take over this one now
[13:02] <seb128> 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] <seb128> it's going to take some work before knowing the code and upstream as well as mvo do
[13:04] <rickspencer3> seb128: ok
[13:04] <rickspencer3> I'll talk to robbiew and mvo about the rest of Jaunty
[13:04] <seb128> thanks
[13:04] <rickspencer3> we should do a cleaner break for Karmic
[13:05] <seb128> right
[14:12] <asac> calc: can you please include a whitespace before your bullet points of your activity?
[14:13] <asac> bryce: ^^ ;)
[14:13] <seb128> robert_ancell: https://help.launchpad.net/Packaging/PPA if you want to learn about ppa too
[14:14] <crevette> salut seb128
[14:14] <seb128> lut crevette
[14:17] <seb128> mvo: BUGabundo is back on #ubuntu-bugs and looking for you
[14:17] <mvo> seb128 I will be there in a minute or so, my real system is doing a *long* fsck right now
[14:17] <seb128> ok
[14:17] <mvo> maybe more than a minute :)
[14:17] <seb128> ;-)
[14:19] <calc> asac: eh?
[14:19] <asac> calc: look at the wiki
[14:20] <asac> calc: https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-03-24
[14:20] <asac> i think your activity always looks that way ;)
[14:20] <calc> asac: hmm i wonder why :\
[14:20] <calc> asac: i send them in email and they look fine then
[14:20] <calc> i'll fix it though
[14:21] <asac> calc: you need to include a whitespace like you would do it in wiki
[14:21] <calc> whitespace where?
[14:21] <asac> if you do its a pitt/rick bug ;)
[14:21] <calc> after the * there is one after it
[14:21] <asac> calc: in front of the *
[14:22] <asac> calc: just try to use the same form in mail that you need to use in wiki
[14:22] <calc> oh hmm, well there are others without whitespace before the * in the current wiki, so that is a bit odd
[14:22] <calc> eg:
[14:22] <calc> [14:22] <calc> * Discussing ideas on bug sorting/filtering
[14:22] <calc> there is no whitespace on that line either but it displayed correctly
[14:22] <asac> calc: i think it works if you also have a empty line
[14:22] <asac> calc: but its not right; as you can see those are no real HTML bullet points
[14:22] <calc> oh hold on that one is broken a bit too, nm :)
[14:23] <asac> yeah
[14:23] <calc> ok will fix mine up and add extra space from now on (or try to remember to anyway)
[14:23] <seb128> vuntz: hey
[14:23] <seb128> vuntz: you are running GNOME 2.26 right? ;-)
[14:24] <seb128> vuntz: are the action in gnome-keybinding-properties translated for you?
[14:24] <calc> asac: i fixed up bryce as well
[14:24] <asac> calc: cool. seb128 is also broken ;)
[14:25] <calc> seb128: fix yours :)
[14:25]  * seb128 slaps asac
[14:25] <calc> kenvandine_wk's isn't using wiki format but is readable
[14:25] <kenvandine_wk> :)
[14:25]  * asac falls to ground
[14:25] <kenvandine_wk> i guess i should use wiki formatting
[14:26] <seb128> we should stop using wikis
[14:26] <seb128> what's wrong with good old ascii formating?
[14:26]  * kenvandine_wk is just emailing it to rickspencer3... 
[14:26] <asac> seb128: you can include a {{{
[14:26] <asac> }}}
[14:26] <asac> if you want to keep it ascii ;)
[14:26] <kenvandine_wk> seb128: text files ftw
[14:26] <kenvandine_wk> text files and bzr
[14:27] <kenvandine_wk> we can all pull and read in $EDITOR
[14:27] <seb128> asac: we should put those at the limit of the page ;-)
[14:27] <seb128> kenvandine_wk: that's how I plan to handle the desktop team list of who is doing what btw ;-)
[14:27] <kenvandine_wk> seb128: awesome
[14:27] <kenvandine_wk> :)
[14:27] <calc> anyone know how to get the cups queue name from command line?
[14:28] <calc> i was going to ask till but he seems to not be online
[14:28] <calc> he gave me a bug that I need to investigate
[14:28] <kenvandine_wk> lpq?
[14:28] <kenvandine_wk> should list all queues
[14:28] <vuntz> seb128: which actions?
[14:29] <vuntz> seb128: some are not translated here
[14:29] <calc> oh i guess then i have no queues since the printer isn't physically connected to this box
[14:29] <seb128> vuntz: in my case most are not, ie next track, previous track, volume ...
[14:30] <vuntz> seb128: those ones are translated
[14:30] <vuntz> seb128: but the run dialog isn't, eg
[14:30] <seb128> vuntz: ok thanks
[14:30] <vuntz> or "switch to workspace on the left/right/..."
[14:31] <seb128> do you know what component has those strings?
[14:32] <seb128> ah, gnome-settings-daemon
[14:33] <seb128> weird, the .mo has the translation for "Next track"
[14:34] <seb128> I bet that's because gnome-control-center doesn't use the gnome-settings-daemon mo file
[14:35] <seb128> vuntz: does your gnome-control-center mo files has Next track translated?
[14:38] <vuntz> seb128: hrm, how can I find out? With a strings on the mo file?
[14:38] <seb128> vuntz: msgunfmt .mo
[14:38] <vuntz> seb128: it's in gsd
[14:38] <vuntz> not gcc
[14:39] <seb128> vuntz: right, I'm just puzzled on how it gets translated for you
[14:39] <seb128> vuntz: stracing gnome-keybinding-properties shows it doesn't open the gnome-settings-daemon.mo there
[14:39] <seb128> vuntz: I've opened http://bugzilla.gnome.org/show_bug.cgi?id=576570 about that
[14:40] <vuntz> no idea :-)
[14:40] <seb128> 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] <seb128> we might clean those and it could still be in the upstream .mo from a time where the string was a gcc one
[14:41] <seb128> _MMA_: I would expect not though I'm not sure what we should do with it right now
[14:41] <kenvandine_wk> hey _MMA_
[14:42] <_MMA_> seb128: Ok. I was gonna change it in the Studio -menu package but didn't want to do it if you guys had something planned already.
[14:42] <vuntz> seb128: I did what you asked me to do, so... if it doesn't show up there
[14:42] <_MMA_> kenvandine_wk: yo yo . ;)
[14:42] <seb128> vuntz: ok thanks
[14:42] <kenvandine_wk> _MMA_: i am betting message indicator sense into Og atm :)
[14:42] <seb128> vuntz: I'm pretty sure that the issue is due to the fact that the translations are in an another translation domain than the one used
[14:43] <seb128> vuntz: not sure why it works for some strings in your case but that seems an upstream bug in any case ;-)
[14:43] <kenvandine_wk> s/betting/beating/
[14:43] <seb128> _MMA_: any suggestion on where would be the right place for this one?
[14:45] <_MMA_> seb128: For us, it's a little redundant. It just brings up Nautilus so you can throw files on a disk and burn. The Brasero entry is fine for us. I think we were just gonna hide the "System Tools" entry.
[14:46] <seb128> _MMA_: we might just do the same, though the burn location is an handy way to create CDs quickly or an iso
[14:47] <_MMA_> Sure, but only slightly and for us not worth the single menu entry since we want to keep it simple.
[14:50] <_MMA_> seb128: When a blank disk is inserted in Ubuntu, does Brasero come up or CD/DVD Creator? (Studio has auto handling turned off)
[14:51] <seb128> I would have to try but I would expect having the nautilus dialog asking what you want to do
[14:51]  * luisbg waves
[14:51] <seb128> hi luisbg
[14:52] <luisbg> hey seb128
[14:52] <luisbg> :)
[14:53] <_MMA_> luisbg: Looks like seb128 wants to hide it. Just gotta work out the details. Make sure it's the best thing to do. I mentioned for us, it's a bit redundant when there are multiple ways to burn a disk and not worth the single menu entry making the menu even bigger.
[14:54] <luisbg> I agree
[14:54] <luisbg> rebundancy in menus is a big "no-no"
[14:55] <luisbg> basic users dont need more "confusion" in the menu
[14:56] <seb128> well those are different actions
[14:56] <seb128> one is to open the gui the other one the easy nautilus burn location
[14:57] <seb128> but having 2 items in the applications menu is confusing
[14:57] <seb128> we will probably just hide this entry
[14:57] <_MMA_> Especially when the "CD/DVD Creator" looks to be part of Brasero because of the same icon.
[14:58] <seb128> not sure if we should get the places menu entry back though
[14:58] <luisbg> places menu entry is very useful for basic users
[14:58] <luisbg> when they want to go to documents they go there
[14:59] <luisbg> instead of opening "file broswer" then looking for documents folder inside home
[14:59] <luisbg> I use it a lot in my multimedia machine myself :)
[15:06] <Ampelbein> seb128: i accidently subscribed ubuntu-main-sponsors to bug #341440 , can you unsubscribe them. sorry for that.
[15:06] <seb128> done
[15:06] <Ampelbein> thanks
[15:09] <pitti> kenvandine_wk: hm, your ekiga.net account says "user not available"
[15:09] <pitti> kenvandine_wk: but *shrug*, the Canonical voip account works well
[15:10] <kenvandine_wk> :)
[15:10] <pitti> so with that DSL connection, ekiga finally works just great
[15:10] <kenvandine_wk> woot!
[15:10] <pitti> rickspencer3, seb128: ^ FYI :)
[15:10] <kenvandine_wk> rickspencer3: we gotta get you using ekiga now :)
[15:11] <seb128> pitti: good ;-)
[15:11] <rickspencer3> I use ekiga
[15:11] <rickspencer3> that's how I have my meetings with Arne
[15:11] <kenvandine_wk> rickspencer3: great... with your canonical voip?
[15:11] <kenvandine_wk> sweet
[15:11] <rickspencer3> I don't have the canonical sip set up yet, but should o
[15:11] <pitti> @ekiga.net seems really brittle, though
[15:11] <kenvandine_wk> rickspencer3: i would prefer that as well... :)  my land line phone has a crappy battery
[15:11] <pitti> rickspencer3: took me less than a minute
[15:11]  * pitti does a happy DSL dance
[15:11] <kenvandine_wk> :)
[15:11]  * kenvandine_wk is happy for pitti
[15:11] <pitti> ok, back to real work now
[15:13] <pitti> seb128: didn't we use to have some pre-added internet radio stations in rhythmbox?
[15:14] <seb128> pitti: we do
[15:14] <pitti> it's empty for me
[15:15] <asac> any clue why rhythmbox will always start on the same workspace != current workspace?
[15:15] <seb128> pitti: I just booted the current iso in kvm and I've 21 stations listed
[15:15] <asac> (compiz)
[15:16] <pitti> seb128: hm, might be gconf cruft for me then
[15:16] <seb128> pitti: that's not in gconf by in .local/share/rhythmbox
[15:16] <seb128> asac: how do you start it?
[15:21] <asac> seb128: the menu
[15:21] <asac> application -> sound -> ...
[15:22] <asac> let me check something
[15:23] <asac> seb128: so ... moving to different workspace and closing there doesnt change the workspace it starts on
[15:23] <asac> seb128: maybe its something that got saved by session shutdown?
[15:23] <seb128> asac: I've no such issue, maybe you are using a special compiz option or something?
[15:24] <kenvandine_wk> it would be cool if fusa set status for ekiga as well :)
[15:24] <seb128> asac: no, if that was gnome-session that would not impact on menu opening
[15:25] <seb128> asac: and rhythmbox only restore the notification status not the workspace on closing
[15:25] <asac> hmm
[15:25] <asac> odd
[15:29] <vuntz> asac: I'd blame metacity
[15:29] <vuntz> asac: if you saved your session once, it tries to match windows when they are opened against what got saved, iirc
[15:30] <vuntz> (if you're using compiz, it might be the same thing)
[15:32] <bryce> calc, thanks
[15:34] <asac> vuntz: yeah. that was my idea: session manager saved something in the past it doesnt safe anymore - or at least it doesnt get removed if i dont have it running on log out
[15:34] <asac> vuntz: do you know where metacity/compiz stores such things?
[15:37] <vuntz> asac: ~/.config/metacity/
[15:37] <vuntz> don't know anything about compiz
[15:37] <calc> cool a bug thought to be OOo is actually ghostscript :)
[15:37] <calc> less bugs for me :)
[15:41] <Keybuk> bryce: timestamping patch?
[15:42] <bryce> Keybuk: time goes backwards during resume on mdz's machine apparently
[15:42] <Keybuk> really?
[15:43] <Keybuk> at some point during the resume cycle, the kernel resets the system clock
[15:43] <Keybuk> but I had figured that would be before userspace got resumed
[15:43] <Keybuk> since it's part of the general _resume() functions
[15:44] <bryce> https://bugs.edge.launchpad.net/ubuntu/+bug/328035/comments/47
[15:44] <asac> hmmm i can find rhythmbox in /.compiz/session/117f000101000121560779200000066 ... but it has "workspace 0"
[15:47] <crevette> wow, we have very old gupnp packages ...
[15:47] <crevette> is it still possible to sync from debian?
[15:47] <pitti> crevette: yes, it's always technically possible
[15:47] <pitti> subject to usual freezes, of course
[15:48] <crevette> our packages are from august and I have a vrash in nautilus-sendto which is guess is caused by gupnp
[15:49] <crevette> hey pitti
[15:49] <crevette> I'll open a request tonight
[15:51] <crevette> my crash is https://bugs.edge.launchpad.net/bugs/346968
[15:54] <seb128> crevette: you should really use apport to send crashes so they get retraced and everything
[15:56] <crevette> seb128, apprt did not fired up
[15:58] <Laney> did you try with the new gupnp?
[15:59] <crevette> Laney, I'll try tonight with the one shipped by debian unstable
[15:59] <Laney> cool, please do
[16:11] <seb128> robert_ancell: http://people.ubuntu.com/~dholbach/sponsoring/index.html has the sponsoring requests waiting
[16:13] <seb128> robert_ancell: https://wiki.ubuntu.com/DesktopTeam/Bzr
[16:25] <calc> robert_ancell: do you need a sponsor for 339993 yet?
[16:25]  * calc needs that fix to do beta testing in a few days, heh
[16:25] <rickspencer3> team meeting in 5 minutes
[16:27] <bryce> rickspencer3: I may need to nip out a bit early to head to my dr appt if the meeting goes long.  I'd neglected to account for the time change when I set up the appointment.
[16:27] <rickspencer3> bryce: ack
[16:28] <robert_ancell> calc: still working on the patch, thanks
[16:28] <calc> robert_ancell: ok
[16:28] <ArneGoetje> hi all!
[16:29] <asac> hi
[16:29] <pedro_> hello
[16:30] <pitti> hey all
[16:30] <calc> hi
[16:30] <robert_ancell> hi!
[16:30] <rickspencer3> everyone more or less here?
[16:30] <rickspencer3> asac is fighting a fire :)
[16:31] <robert_ancell> seb128 is just walking up
[16:31] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-03-24
[16:31] <seb128> hey there
[16:31] <rickspencer3> I suppose we may as well start
[16:31] <pitti> url 1
[16:31] <pitti> whoops, sorry
[16:31] <rickspencer3> First item Welcome Robert Ancell
[16:31] <rickspencer3> yeah!
[16:32]  * asac feels like a fireball ;)
[16:32] <robert_ancell> I feel very welcomed.  Canonical is a friendly place
[16:32] <rickspencer3> Hi Till
[16:32] <tkamppeter> hi
[16:32] <kenvandine_wk> :)
[16:32] <pitti> welcome again! it's great to see the desktop team grow!
[16:32] <rickspencer3> we just started the meeting, and introduced robert_ancell, our newest team member
[16:32] <kenvandine_wk> robert_ancell: it is :)
[16:32] <rickspencer3> kenvandine_wk: you are now no longer the new guy
[16:32] <seb128> robert_ancell: welcome!
[16:32] <rickspencer3> expectations just increased
[16:32] <pedro_> welcome robert_ancell :-)
[16:32] <kenvandine_wk> woot
[16:32] <rickspencer3> :)
[16:33] <rickspencer3> btw, seb128 and robert_ancell are together at Millbank
[16:33] <rickspencer3> robert_ancell: any introductory comments?
[16:33]  * rickspencer3 puts robert_ancell on the spot
[16:34] <robert_ancell> Sorry, yes:  For those who don't know me I've got a background in embedded engineering (esp Linux) and have been working on gcalctool and gnome-games
[16:34] <robert_ancell> I'm based in Sydney, Australia and previously worked for NASDAQ OMX there
[16:35] <robert_ancell> (but i'm a Kiwi)
[16:35] <robert_ancell> Any questions?
[16:35] <pitti> kiwi? isn't that a bird (and a fruit)?
[16:35] <rickspencer3> lol
[16:37] <robert_ancell> Absolutely
[16:37] <asac> kiwi was the nick name of a debian mentoree i had at some point ;)
[16:37] <robert_ancell> and  also a citizen of NZ
[16:37] <crevette> kiwi is a surname for New Zealand people
[16:37] <crevette> like ossie is for australian people
[16:37] <asac> hmmm i think it was kibi ;)
[16:37] <rickspencer3> ok
[16:37] <rickspencer3> round of applause for robert_ancell
[16:37] <rickspencer3> :)
[16:37]  * kenvandine_wk clapps
[16:37]  * robert_ancell bows
[16:37] <rickspencer3> fwiw, Robert will be focusing on GNOME packaging and such
[16:37] <seb128> yeah!
[16:38] <robert_ancell> seb128: I'm not taking all the crap packages though :P
[16:38] <pitti> compiz is shiny!
[16:38] <pitti> *cough*
[16:38] <didrocks> robert_ancell: no, you can be sure that seb128 will give them to me :p
[16:39] <crevette> seb128 has lots of slaves now
[16:39] <kenvandine_wk> haha
[16:39]  * crevette hides
[16:39] <seb128> robert_ancell: ok, we will keep one of those for somebody else ;-)
[16:39]  * rickspencer3 hands compiz to robert_ancell before he can get away
[16:39] <seb128> don't joke too much he might be taking it
[16:39] <seb128> ;-)
[16:39] <rickspencer3> (I wasn't actually joking :) )
[16:39] <seb128> I tried at lunch and he didn't run away
[16:39] <tkamppeter> robert_ancell, what about evince?
[16:39] <seb128> evince is well maintained
[16:39] <robert_ancell> tkamppeter: I have nothing personally against it...
[16:39] <seb128> upstream is reactive and I do the updates
[16:39] <pitti> well, I think we can leave the splitting of desktop stack maintenance to seb and Robert, off-meeting
[16:39] <rickspencer3> uhoh
[16:39] <crevette> didrocks, where is huats? I didn't see it here for a while
[16:39] <seb128> right
[16:39] <rickspencer3> next is Outstanding actions from last meeting
[16:39] <tkamppeter> robert_ancell: bug 150187
[16:39] <bryce> welcome aboard robert_ancell
[16:39] <pitti> tkamppeter: after meeting, please
[16:39] <rickspencer3> they've all been responded to, so I would ask that you check the wiki to see te status
[16:40] <rickspencer3> next is cv-rev
[16:40]  * rickspencer3 hands mic to pitti
[16:40] <pitti> so, as you guys might have noticed, the QA team recently started to assign bugs to canonical-desktop-team
[16:41] <seb128> yeah, I did notice ;-)
[16:41] <pitti> they are helping us with wading through the incoming stream, identify regressions and high-urgency bugs, etc.
[16:41] <pitti> this might have stirred some confusion
[16:41] <pitti> the intention is that they help us thin the flood into a small stream which we can handle
[16:41]  * rickspencer3 "might" = "did"
[16:41] <pitti> the idea is *not* that by getting such a bug, we are obliged to fix them all
[16:42] <pitti> but that we need to look at them with an expert eye and decide whether it's an actual RC issue we should work on
[16:42] <pitti> (case 1)
[16:42]  * kenvandine_wk being the new guy thought that was just biz as usual :)
[16:42] <pitti> or whether it's not an urgent/worthwhile bug after all (case 2)
[16:42] <pitti> in case (2), the bug should get unassigned again, and tagged "ct-rev"
[16:42] <pitti> like "canonical team reviewed"
[16:43] <pitti> so that it's not tossed back to us again
[16:43] <pitti> in case (1), it needs to get a proper assignee
[16:43] <pitti> with my TL hat, I started to review them, reject a few of them, and assign some of them to some of you
[16:43] <pitti> I try to spread them equally
[16:43] <pitti> two things:
[16:43] <pitti> - Please let me know of if you have too many, by reassigning them to canonical-desktop-team
[16:44] <pitti> - Please let me know if you would like me to continue doing that bug assignment
[16:44] <pitti> or whether you'd rather grab them from the queue yourself
[16:44] <seb128> as long as I don't get compiz bugs assigned to me I'm fine with assignement ;-)
[16:44] <rickspencer3> lol
[16:44] <kenvandine_wk> hehe
[16:44] <pitti> well, sooner or later we need to get someone who maintains compiz
[16:44] <kenvandine_wk> pitti: is there a filter for bugs we can pick from?
[16:44] <kenvandine_wk> as we have time
[16:45] <seb128> I've seen mvo fall into this one, I'm not going to do the same error ;-)
[16:45]  * bryce dittos seb128
[16:45]  * kenvandine_wk nominates seb128
[16:45] <pitti> kenvandine_wk: ~canonical-desktop-team/+assignedbugs ?
[16:45] <pitti> kenvandine_wk: that's my second question actually
[16:45] <crevette> it is new that meeting is hold here ?
[16:45] <pitti> either I take the task of making sure that this queue is always (mostly) empty
[16:45] <seb128> pitti: I suggesting trying to get mvo back to desktop team rather ;-)
[16:45] <pitti> and you work on your assigned bugs
[16:45] <seb128> crevette: no, every weeks for a few months
[16:45] <bryce> crevette: not very new...
[16:45] <crevette> ...
[16:45] <pitti> or it becomes a collective task, but then there will always be some things fall through the cracks
[16:46] <pitti> seb128: good idea
[16:46] <rickspencer3> for my part, I don't like bugs to be assigned to canonical-desktop-team for too long
[16:46] <pitti> ^ ack
[16:46] <rickspencer3> so I review the bugs daily, and assign (to seb mostly)
[16:46] <rickspencer3> ;)
[16:46] <pitti> team assignments are mostly worthless
[16:46] <pitti> they are good as a queue for distributing, but not as a personal TODO list
[16:46] <kenvandine_wk> there needs to be one  wrangler, imho
[16:46] <seb128> right
[16:46] <pitti> so, no objections against me or rickspencer3 doing the queue review?
[16:47] <mvo> lol@seb128
[16:47]  * seb128 hugs mvo
[16:47] <kenvandine_wk> and we can trade amongst ourselves as eneded
[16:47] <pitti> that too
[16:47] <kenvandine_wk> pitti: i am all for it
[16:47] <bryce> pitti: fine by me
[16:47] <pitti> as I said, if you feel that you can't work on something, toss it back to canonical-desktop-team
[16:48] <rickspencer3> In general, I would like the QA team to be quite liberal about putting bugs in our queue, which means that we have to be quite liberal about using ct-rev
[16:48] <pitti> and as a consequence, bugs on your +assignedbugs page are the ones you are really responsible for
[16:48] <seb128> rickspencer3: +1
[16:48] <pitti> rickspencer3: *nod*, up to a certain level, of course
[16:48] <rickspencer3> pitti: is there any reason people couldn't start using ct-rev on their current assigned list?
[16:48] <pitti> rickspencer3: no, should be fine; it's meant for that
[16:49] <pitti> but it's only really necessary for things QA threw at us
[16:49] <seb128> do we have a list of things they raised?
[16:49] <pitti> if it helps you for your own bug management, feel free to use it, of course
[16:49] <pitti> seb128: no, I'm afraid, since we reassing those
[16:49] <pitti> we could fish it out of the activity log, I guess, but that's some effort
[16:49] <seb128> ok, they don't use a tag for those
[16:50] <kenvandine_wk> maybe they should tag them all as qa-gen
[16:50] <pitti> rickspencer3: I'm done with that topic, I think
[16:50] <kenvandine_wk> qa generated
[16:50] <seb128> so basically once unassigned the ct-rev only means "don't bounce that back to ct"
[16:50] <rickspencer3> seb128: right
[16:50] <pitti> seb128: right, so that it doesn't appear in the QA bug distribution queue again
[16:51] <pitti> they have an eye on regression-*, etc.
[16:51] <rickspencer3> to close, on this ... I think this is a good first step to good bug "hygiene" in Karmic ...
[16:51] <rickspencer3> where our bug list is limited to bugs that we intend to (not commit to) fixing in a particular release
[16:51] <rickspencer3> this is something that we should all discuss as a team, though
[16:52] <rickspencer3> thanks pitti!
[16:52] <rickspencer3> next topic is also pitti: ekiga 3.2 after beta?
[16:52] <pitti> right
[16:52] <kenvandine_wk> me thinks so
[16:52] <seb128> doit!
[16:52] <pitti> so, kenvandine_wk packaged the new ekiga, people asked about it
[16:52] <kenvandine_wk> the deps are harmless... nothing else uses it
[16:52] <pitti> kenvandine_wk and I have tested it a bit now, and it looks good
[16:52] <kenvandine_wk> people have been using it out of my ppa
[16:52] <pitti> this time no configuration migration issues, etc.
[16:53] <kenvandine_wk> good reports
[16:53] <bryce> rickspencer3: (btw I'll be heading out in a few minutes; are there any topic items you need my input on before I go?)
[16:53] <rickspencer3> bryce: we can catch you up later
[16:53] <rickspencer3> np
[16:53]  * rickspencer3 waves
[16:53] <bryce> rickspencer3: thx
[16:53] <pitti> bryce: I might bother you again this week about some RC bugs, but nothing too urgent from my side
[16:53] <pitti> bryce: thanks, and good luck at the doctor!
[16:54] <rickspencer3> pitti: so is that decided?
[16:54] <pitti> seems theres' no objection
[16:54] <rickspencer3> moving on
[16:54] <kenvandine_wk> ok, i will finish that up and get it sponsored
[16:54] <pitti> kenvandine_wk: can you please make sure that the relevant bug has an upstream changelog and that ubuntu-release gets subscribed?
[16:54] <pitti> kenvandine_wk: there's certainly an FFE involved
[16:55] <kenvandine_wk> ubuntu-release?
[16:55] <kenvandine_wk> how about ubuntu-main-sponsor?
[16:55] <pitti> yes, release team, for ack'ing FF exceptions
[16:55] <kenvandine_wk> ok
[16:55] <pitti> kenvandine_wk: after it gets ack'ed
[16:55] <pitti> kenvandine_wk: as it happens, I'm a member of the release team :)
[16:55] <pitti> but it should go the official route
[16:56] <rickspencer3> next topic: OEM Swapperoo
[16:56] <rickspencer3> I've talked to pitti and calc about this
[16:56] <rickspencer3> and will now proceed to copy and paste from the wiki :)
[16:56] <rickspencer3> In order to facilitate better team to team communication and cooperation, 3 people from the platform team will be swapping roles with 3 people from OEM team for Karmic cycle.
[16:56] <rickspencer3> Our own calc has been nominated for this. (congrats calc). Goal is for calc to learn their processes and "walk a mile in their shoes", and bring that understanding back to platform team after Karmic. Desktop team will be getting an engineer from OEM team with the symetrical goals. We'll probably slow progress on OOo while calc is gone, distribute maintenance responsibilities for OOo during Karmic so that OEM engineer can have a bit 
[16:57] <rickspencer3> hmm
[16:57] <rickspencer3> I was kinda hoping for line breaks
[16:57] <seb128> urg
[16:57] <rickspencer3> I think it will be cool for calc, and us as well. seb128: concerns?
[16:58] <seb128> I never understood this "let's realloc people who are familiar with something to something new and do the same the other way around with other people too"
[16:58] <pitti> yeah, there was some friction between those two teams indeed
[16:58] <seb128> but I'm not a manager
[16:58] <seb128> let's see how it goes ;-)
[16:58] <seb128> that seems highly inefficient use of ressources to me
[16:59] <pitti> seb128: not necessarily, if it helps both of us to understand the other team better
[16:59] <calc> as i have discussed with Rick we will not be going to the OOo split build for Karmic since it is likely to have issues that someone unfamilar with OOo would have trouble with
[16:59] <pitti> right now, the communication between OEM and platform is far from efficient
[16:59] <seb128> well, I don't think that switching one person will solve that
[16:59] <seb128> but let's see
[16:59] <seb128> I'm happy to be proved wrong
[16:59] <calc> and I will be getting OOo 3.1.0 debs into the ppa for testing, it seems to have worked well for jaunty cycle
[16:59] <seb128> and I've no clue about management ;-)
[16:59] <rickspencer3> there are a total of three people, actually, just one from our team
[16:59] <calc> rickspencer3: can you disclose who the other two are?
[16:59] <pitti> calc: it sounds like an interesting adventure, but of course we'll only send people who volunteer; what's your initial gut feeling about the idea?
[17:00] <rickspencer3> calc: I would if I knew
[17:00] <rickspencer3> they're still discussing
[17:00] <calc> pitti: i think OOo is in decent shape now but does get quite a few bugs... i might need to do some work with the team (but small percentage of time) to make sure things go smoothly
[17:00] <calc> rickspencer3: ok
[17:02] <pitti> calc: I feel that'll apply in the other direction as well; I guess the three OEM guys can't completely let go of their existing customer communications, etc.
[17:02] <rickspencer3> calc: about 20% of your time will be allocated back to the desktop team to help with OOo, so you're not off the hook completely
[17:02] <calc> pitti: we are targeting 3.1.x which should be released mid next month for Karmic, hopefully a 3.1.1 will be out in a few months that is a bugfix release we can use as well
[17:02] <rickspencer3> :)
[17:02] <pitti> but we can learn what the OEM team needs in the long run
[17:02] <calc> rickspencer3: ok, i think 20% should make this doable :)
[17:02] <pitti> and they can learn how to properly get patches into ubuntu and upstream, the freezes, etc.
[17:02] <calc> triaging OOo bugs is a bit annoying but i am sure the desktop team can handle it ;-)
[17:02] <rickspencer3> lol
[17:02] <seb128> the oem guy will handle it
[17:02] <seb128> ;-)
[17:02] <pitti> calc: we'll all give it to the OEM guy :)
[17:02] <pitti> seb128: we are so evil
[17:02] <calc> ie if upstream hears anything about ubuntu without also mentioning you tested on their build they will close the bug immediately without even looking :\
[17:02] <pitti> seb128: no, he'll maintain compiz :-P
[17:02] <rickspencer3> btw, did anyone mention that calc got "New" OOo bugs down to zero at one point last week?
[17:02] <calc> pitti: lmao :)
[17:02] <calc> rickspencer3: still 0 now i think
[17:02] <seb128> pitti: ;-))
[17:02] <kenvandine_wk> wow...
[17:03] <pitti> calc: zero new bugs> wow!
[17:03] <seb128> impressive
[17:03]  * rickspencer3 ^5 calc
[17:03] <kenvandine_wk> zarro bugs
[17:03] <calc> http://people.ubuntu.com/~brian/complete-graphs/openoffice.org/plots/openoffice.org-week-new.png
[17:03] <calc> thanks guys :)
[17:03] <kenvandine_wk> damn bugzilla has scared me for life
[17:03] <calc> all upstream bugs linked as well
[17:03] <rickspencer3> next topic: Release Bugs / Release Status
[17:03] <calc> only 1 confirmed bug currently, i can't test due to the vmware amd64 brasero issue
[17:03] <seb128> calc: come on, you can sudo mv a file away no?
[17:04] <rickspencer3> I'm not sure what there is to discuss here, but we have quite a few bugs still targeted for Jaunty
[17:04] <bryce> calc: launchpadlib ftw?
[17:04] <calc> seb128: ah i will take a look at it later today/tomorrow once i get all my targeted bugs fixed for jaunty (only have 10 left)
[17:05] <calc> bryce: yea launchpadlib helped me make sure i had no more hidden bugs
[17:05] <calc> rickspencer3: bug 339993 is quite evil on vmware at least
[17:05] <bryce> calc: good luck working on the oem team; nice guys, looks like a hell of a job
[17:05] <bryce> calc: cool, yeah I've found it similarly useful :-)
[17:05]  * robert_ancell working on 339993
[17:05] <calc> rickspencer3: but as seb128 mentioned if we can't get it fixed we should tell testers to move the brasero lib out of the way
[17:05] <bryce> ok, bbiab
[17:05] <calc> rickspencer3: er can't get it fixed in time for beta cd i mean
[17:06] <calc> bryce: thanks
[17:06] <rickspencer3> well, since it looks like they already spun the first beta cd, that's kinda taken as read :)
[17:06] <seb128> calc: it's not happening for lot of people, I told you yesterday
[17:07]  * asac reads backlog
[17:07] <calc> seb128: not happening on vmware for a lot of people, i meant to tell testers who use vmware to move it, it seems all the people complaining about this are using vmware
[17:07] <pitti> calc: at this time it's fairly unlikely that we'll respin, especially since it doesn't seem to happen everywhere
[17:07] <seb128> calc: and it's fixed to svn already and robert_ancell was backporting the fix before the meeting
[17:07] <pitti> I did two test isntalls in kvm and two on real iron without any hitch
[17:07] <pitti> so if we fix it immediately after beta, so people can dist-upgrade
[17:07] <seb128> I never ran into this one on 2 real boxes and some kvm installs
[17:07] <calc> yea it seems this bug may only be showing up in cases where people are doing testing via vmware (not sure why...)
[17:08] <pitti> it should be good enough
[17:08]  * calc should setup kvm now that he has hardware that supports it (the virt flag)
[17:09] <rickspencer3> nothing else for release status?
[17:10] <calc> rickspencer3: i have a bug that i think asac was looking into yesterday but i don't know his status, bug 271283
[17:10] <calc> it regressed at the end of intrepid, worked in hardy, so it would be nice to fix if someone knows what to do on the gnome side as mentioned in the bug report
[17:10] <pitti> I did another thorough RC bug review last week
[17:11] <pitti> and although the counter keeps growing, it does that because we get more new bugs
[17:11] <pitti> but we do fix old ones, so it's going well
[17:11] <asac> calc: one question i didnt ask yesterday. does ooo ship their own cairo?
[17:11] <asac> calc: -> -devel
[17:11] <pitti> and the new ones are less and less "OMGkittensdie" level
[17:11] <pitti> https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus
[17:11] <pitti> the first four need more love, though (the "hard" ones)
[17:12] <pitti> I have no bad feelings about the others, they're just "in the pipe"
[17:12] <seb128> pitti: you can get the font one off the list we switched back to 96dpi
[17:12] <pitti> seb128: right, I didn't update it this week yet
[17:12] <pitti> OMGkittensdie: *triage* *splat*
[17:13] <rickspencer3> ok, we currently have 10 targeted bugs
[17:14] <pitti> bug 328035 is dead as well
[17:14] <rickspencer3> but I assume we'll get a bunch of new bugs when the beta goes out
[17:14] <pitti> yes, absolutely
[17:15] <rickspencer3> so with a few exceptions, I suppose everyone should be 110% focused on quality
[17:15] <rickspencer3> for the short time left in this release
[17:15] <rickspencer3> so to close the meeting:
[17:15] <pitti> does anyone feel that their +assignedbugs queue is overloaded for jaunty?
[17:15] <rickspencer3> BETA! BETA!
[17:15] <pitti> the beta images are really kwality IMHO
[17:16]  * kenvandine_wk is going to test some  today
[17:16] <kenvandine_wk> unr and desktop
[17:17]  * komputes is up for jaunty testing tasks if needed
[17:17] <rickspencer3> the qa team asked me to ask everyone on the team and in the community to try out the ISOs when they come out
[17:17] <rickspencer3> to try to install in different configurations and what not
[17:17] <kenvandine_wk> hummm... no UNR image
[17:17] <seb128> pitti: yeah beta is pretty solid for me as well
[17:17] <pitti> the daily{,-live}/current/ ones will most likely be beta
[17:17] <pitti> please go wild on them
[17:18] <pitti> this morning I installed on an USB stick with encrypted home, for kicsk
[17:18] <Riddell> dvds too
[17:18] <pitti> "workstation on my keyring"
[17:18] <kenvandine_wk> nice
[17:18] <rickspencer3> any other business?
[17:18] <pitti> Riddell: I noticed that there are no KDE specific RC bugs on /ReleaseStatus
[17:19]  * seb128 takes the opportunity to be in the office to download isos
[17:19]  * MagicFab waves, from Canonical support
[17:19] <pitti> Riddell: did I just miss them, or is KDE in great shape, by and large?
[17:19] <seb128> hey MagicFab
[17:19] <Riddell> we're in good shape
[17:19] <komputes> pitti: you didn't need to mess with grub after the install on the USB key and there was an internal hd available when you did this?
[17:19] <pitti> komputes, MagicFab: any testing and bug filing appreciated
[17:19] <kenvandine_wk> hey MagicFab
[17:19] <pitti> Riddell: glad to hear
[17:19] <Riddell> 4.2.2 due next week
[17:19] <asac> Riddell: any update on network manaer in kde
[17:20] <asac> ?
[17:20] <pitti> komputes: yes and no; see bug 340498
[17:20] <asac> the applet?
[17:20] <asac> Riddell: will it support more than the really basic features?
[17:20] <pitti> komputes: in short, boot with the usb plugged in, and it should be good
[17:20] <MagicFab> I invited komputes, we're both in support in the Montreal office - just getting our feet wet with this channel. I'll lurk here from now on.
[17:20] <pitti> it smells like a BIOS limitation, not really a grub bug, but I'm not an expert on grub/bios
[17:21] <Riddell> asac: the plasmoid mostly works but some people still report having to use the kde 3 one so we'll keep that on the dvd
[17:21] <pitti> rickspencer3: AOB> seems not :)
[17:21] <Riddell> gran canaria
[17:21] <Riddell> what's our plan?
[17:22] <pitti> Riddell: you mean after fixing all our RC bugs on Friday?
[17:22] <rickspencer3> Riddell: do you mean, what is "Canonical's" plan?
[17:22] <rickspencer3> that would be a good topic for the next meeting
[17:22] <rickspencer3> we should discuss offline first
[17:22] <Riddell> right, call for papers and registration is open for the desktop summit, should we be booking trips and accomodation and submitting talks?
[17:23] <Riddell> ok
[17:23] <rickspencer3> Riddell: yes, absolutely
[17:23] <rickspencer3> meeting adjourned?
[17:24] <Riddell> back to ISO testig
[17:24] <pitti> I'm off IRC for a bit, for CD tesing
[17:24] <kenvandine_wk> where can i find the latest unr image?
[17:24] <rickspencer3> by all
[17:24] <komputes> pitti: just sent you an email with the USB issue I experiened installing onto usb drive when internal hd is present (feel free to read the rest of the doc too)
[17:24] <rickspencer3> thanks!
[17:24] <ArneGoetje> thanks
[17:25] <rickspencer3> and welcome one more time robert_ancell
[17:25] <robert_ancell> thanks
[17:25] <davmor2> pitti: hurry before I complete the lot then :D
[17:25] <rickspencer3> ArneGoetje: perhaps next meeting we might want to look at the translation completion pages
[17:25] <ArneGoetje> rickspencer3: err...
[17:26] <rickspencer3> I think people would find it interesting
[17:27] <ArneGoetje> rickspencer3: if you think so... :)
[17:27] <rickspencer3> next time
[17:27] <rickspencer3> good night!
[17:28] <ArneGoetje> rickspencer3: thanks, good erm... day! ;)
[17:28] <rickspencer3> ArneGoetje: at least it's still today for both of us
[17:29] <ArneGoetje> rickspencer3: nah... it's Wednesday here.
[17:30] <rickspencer3> oh, right
[17:30] <rickspencer3> because it's past midnight
[17:30] <rickspencer3> ?
[17:30] <ArneGoetje> rickspencer3: yep
[17:30] <rickspencer3> still
[17:30] <rickspencer3> if you define a "day" as the time period between episodes of sleeping, it's the same day :)
[17:31] <ArneGoetje> rickspencer3: right
[17:31] <seb128> sleeping? what's that?
[17:31] <rickspencer3> seb128: it's something weak people do
[17:31] <seb128> oh, I see ;-)
[17:32] <ArneGoetje> ok, guys, I'm off for the night.
[17:34] <rickspencer3> g'night ArneGoetje
[17:35] <crevette> is the meeting finished (sorry I was away)
[17:36] <didrocks> crevette: I think so :) for huats, he is very busy those days and so, doesn't show up there
[17:36] <crevette> pitti, do you have an opinion for bluez 4.33 ?
[17:44] <pitti> davmor2: you beat me to them anyway :) but more coverage == good
[17:44] <davmor2> pitti: :)
[17:48] <MagicFab> I am bookmarking usability "challenges" and opportunitues I come across as part of the support team, here: http://delicious.com/MagicFab/du-ubuntu
[18:11] <seb128> pitti: did you have a chance to look at the retracer hang?
[18:11] <seb128> pitti: if not do you mind if I restart it now?
[18:12] <seb128> pitti: I would like to get the backlog going down for a bit some we can do bug forwarding this week while frozen for example
[18:12] <pitti> seb128: ah, sorry; doing now
[18:12] <pitti> seb128: ok, please restart now
[18:12] <pitti> it'll hang again soon enough
[18:12] <pitti> I can track this down on Wed/Thu during deep freeze
[18:15] <seb128> pitti: ok thanks
[18:15] <seb128> pitti: it hangs every few bugs
[18:15] <pitti> meh, that's something new
[18:18] <seb128> right
[18:19] <calc> apparently OOo has 3 bugs that need to be traced but haven't yet, is that due to the hangs?
[18:19] <pitti> calc: yes
[18:19]  * pitti -> back to CD testing
[18:20] <asac> mvo: prod
[18:22] <calc> ok
[18:29] <seb128> pitti: ok retracers restarted, they didn't stand for an hour before hanging today, I'll keep restarting them actively until we catch up on the backlog
[18:33] <mvo> asac: not forgoten
[18:46] <didrocks> seb128: what is this retracer? the LP upstream bug watcher/synchronizer?
[18:47] <seb128> didrocks: no, the thing which goes through crashes sent using apport and retrace those in a debug version
[18:48] <didrocks> seb128: if I understand correctly, it has some kind of playground to replay a crash catched by apport, installing a -dbg package?
[18:48] <seb128> didrocks: man apport-retrace
[18:48] <didrocks> seb128: thanks :)
[18:48] <pitti> seb128: ok, thanks
[18:49] <pitti> seb128: I'll debug them in a quieter moment then
[18:49] <seb128> didrocks: the retrace is basically a bot doing apport-retrace on all the crashes sent
[18:49] <seb128> pitti: thanks
[18:49] <seb128> didrocks: retrace -> retracer
[18:49] <didrocks> seb128: understood, thanks :)
[18:50] <didrocks> (that was what I was infering with "some kind of playground to replay…") :)
[18:53] <asac> calc: for me the xref thing isnt good enough to find the real font code
[18:54] <asac> which tree is it in most likely?
[18:54] <calc> asac: was what Mike mentioned about gnome adding the lcdfilter option to the Xrm database doable? i didn't really understand what he talking about
[18:55] <calc> asac: if you want to see what the code looks like ubuntu builds you would need to start a build and kill it after the patches are applied
[18:55] <calc> asac: its a combination of upstream and patches applied from svn.gnome.org ooo-build/branches/ooo-build-3-0-1
[18:55] <asac> calc: yes. that makes a bit of sense
[18:56] <asac> but the real problem is that ooo seems to do something really wrong
[18:56] <calc> asac: the patch that added cairo support appears to be integrated into upstream directly now, but there may still be patches in ooo-build that are affecting how it works
[18:56] <calc> oh? :\
[18:56] <asac> calc: i refered to the Xrm database thing
[18:56] <calc> ok
[18:56] <asac> for sense
[18:57] <calc> i'm actually doing a build currently if there is anything you would want me to grep for i could check what file things are in
[18:57] <asac> i will check out the vcl subtree for now
[18:57] <calc> ok
[18:57] <asac> calc: hmm ... i want to know all files that use gtk_ cairo_ and pango_ symbols i guess
[18:58] <calc> ok
[18:58] <dobey> oi, freezes can be so annoying sometimes :)
[18:58] <asac> calc: i see a lot of files that start with "sal"
[18:58] <asac> calc: do you know what that stands for?
[18:59] <calc> no, looking to see if i can determine what it is
[19:00] <calc> System Abstraction Layer
[19:00] <calc>  - 22k - Cached - Similar pages -
[19:00] <calc> oops
[19:00] <calc> wiki.services.openoffice.org/wiki/Porting/Modules/SAL
[19:01] <seb128> pitti: there is a
[19:01] <seb128>  4887 ?        S      0:00                                  \_ /usr/lib/apt/methods/http
[19:01] <seb128> which loops on
[19:02] <seb128> read(3, "~\205\t\347\2750r\256\334\334\257\265~h\330\5z\257\26o"..., 12733) = 2896
[19:02] <seb128> read(3, 0x6217d3, 9837)                 = -1 EAGAIN (Resource temporarily unavailable)
[19:02] <seb128> select(5, [0 3], [4], NULL, {120, 0})   = 1 (out [4], left {120, 0})
[19:02] <seb128> etc calls
[19:02] <seb128> in fact that stopped
[19:02] <seb128> bah I will let you debug that
[19:03] <calc> asac: i should have the list for you in a few minutes
[19:03] <seb128> there is also quite some "xulrunner-bin --gre-version" processes around
[19:03] <seb128> I blame xulrunner
[19:03] <seb128> asac: I blame you for breaking the world again ;-)
[19:04] <pitti> seb128: yeah, it seems that's always the same hang
[19:05] <seb128> I'm ready to bet it hangs each time it hits a xulrunner bug
[19:07] <calc> asac: pango_ is only found in a few files, running grep for cairo now
[19:08] <calc> asac: oh yea disregard any files in dirs like "unxlngx6.pro"
[19:11] <bryce> back
[19:12] <asac> calc: http://pastebin.com/f452993d3
[19:12] <asac> run that ... seems the ft backend is the real problem
[19:12] <asac> freetype
[19:13] <asac> seb128: where is that?
[19:13] <asac> pitti: ?
[19:13] <calc> my computer is acting weird :\
[19:13] <asac> so you get regular hangs in xulrunner --gre-version?
[19:14] <asac> where is that observed? on the builders?
[19:14] <seb128> asac: the retracers
[19:15] <asac> seb128: is that reproducible? e.g. running xulrunner --gre-version in the same chroot hangs?
[19:16] <seb128> asac: I will need to try, those retracers are automatic and I've no wait to attach a running instance I think, I will have to start a new one by hand
[19:16] <seb128> asac: but they hang a lot and there seems to be on those "xulrunner-bin --gre-version" calls
[19:16] <seb128> did anybody in this area changed recently?
[19:16] <asac> seb128: thanks for telling me ... finally ;)
[19:17] <asac> not directly
[19:17] <seb128> asac: sorry got several other people pinging me in the same time
[19:17] <asac> seb128: nah. i understood as if you see those hangs for quite a while (e.g. weeks)
[19:17] <asac> and you never told me ;)
[19:17] <seb128> ah
[19:17] <seb128> I'm not sure when that started, we get emails about retracer crashes
[19:17] <seb128> not about hangs
[19:17] <asac> ok
[19:18] <seb128> I would say around a week
[19:18] <seb128> I just noticed yesterday
[19:18] <asac> yeah made it sound like its known for ages ;)
[19:18] <seb128> but the backlog suggests some extra days
[19:18] <seb128> asac: where did I suggest that ;-)
[19:18] <asac> ok ... so no. the last xulrunner upload was quite a while ago
[19:18] <seb128> asac: the "a lot" is just that we can't get those running for some days now
[19:19] <asac> all good ;) ... i understood now
[19:19] <pitti> asac: hello
[19:19] <asac> hi ;)
[19:19] <asac> so how are the chroots getting set up?
[19:20] <asac> do you see this in jaunty chroots or only in some stable release?
[19:20] <calc> gah i can't get a prompt :\
[19:20] <asac> is it the xulrunner-bin from xulrunner-1.9 package or 1.9.1?
[19:20] <seb128> asac: it's basically apport-chroot and apport-retrace
[19:21] <seb128>  1332 ?        S      0:00  |                                               \_ /tmp/tmppQgXs8/usr/lib/xulrunner-1.9.1b3/xulrunner-bin --gre-version
[19:21] <asac> yeah ... ok
[19:21] <seb128> futex(0x805d1e0, 0x80 /* FUTEX_??? */, 2
[19:21] <asac> 1.9.1
[19:21] <asac> jemalloc issue
[19:21] <pitti> asac: the stable releases get much fewer crash reports, so it's hard to tell
[19:21] <asac> at lesat thats my guts feeling
[19:22] <asac> pitti: is it run in fakeroot?
[19:22] <asac> pitti: for now i would think its just 1.9.1 which is new in jaunty
[19:22] <pitti> asac: es, fakeroot and fakechroot
[19:22] <asac> pitti: what does fakechroot do? does it overload libc too?
[19:22] <pitti> asac: I haven't looked at all on this hang yet, so I'm afraid there's not much I can say
[19:22] <pitti> asac: yes, it chroots everything
[19:23] <pitti> asac: if you want, you can log into them
[19:24] <asac> pitti: is there such a chroot where i could chroot into even?
[19:24] <pitti> asac: ssh ronne
[19:24] <asac> ok
[19:24] <asac> i am in there ;)
[19:26] <pitti> dchroot -q -c intrepid
[19:26] <pitti> cd /home/ubuntu-archive/apport-retracer-amd64
[19:26] <pitti> . environ
[19:26] <pitti> apport-chroot login chroots/jaunty.tar.gz
[19:26] <calc> asac: so you want me to run those three commands on a system that shows the problem, or just on my system in general?
[19:27] <pitti> asac: this should work for you ^
[19:28] <asac> pitti: ok. let me try
[19:28] <calc> asac: also are those commands complete, i just see eg pango-view -t "FT2   (not even closed quotes)
[19:28] <asac> pitti: intrepid?
[19:28] <asac> trying
[19:28] <pitti> asac: independently of this, it's a handy method if you need a quick chroot with super-fast archive bandwidth for testing something
[19:28] <asac> oh ... thats great ;)
[19:28] <pitti> asac: yes, it's in the intrepid dchroot; that runs both the intrepid and jaunty fakechroots
[19:29] <asac> pitti: does it create that at a tmp place?
[19:29] <pitti> asac: we have one for i386 as well
[19:29] <asac> or do i need to change in a new dir?
[19:29] <pitti> asac: yes; it's maintained as a tarball, and unpacked into /tmp
[19:29] <asac> ok
[19:29] <pitti> asac: once you exit it, it'll be thrown away
[19:29] <asac> ah ... good to know
[19:29] <asac> so better use a screen if connection is flaky ;)
[19:30] <pitti> asac: if you want to save it, you can unpack it somewhere in your ~ and give that path to apport-chroot
[19:30] <pitti> asac: i. .e apport-chroot accepts a tar.gz or a directory as argument
[19:30] <asac> ok. i think its already more than i can remember ;)
[19:30] <asac> if i need details i will just ask on demand :)
[19:30] <pitti> right
[19:34] <mccann> heya folks
[19:36] <seb128> hi mccann
[19:36] <seb128> asac: I can confirm than running "/usr/bin/xulrunner-1.9.1 --gre-version" there hangs
[19:36] <mccann> does the ux team have a separate channel or is this the place?
[19:38] <bratsche> dx team?
[19:39] <bratsche> #dx if you're looking for Desktop Experience team
[19:41] <calc> asac: ping
[19:42] <seb128> calc: I think he's looking at the retracers issue
[19:42] <calc> seb128: ok
[19:42]  * calc will just follow up to the bug so he can see what i found
[19:47] <asac> pitti: can you somewhat refuse to do retraces where 1.9.1 is involved?
[19:48] <seb128> asac: we can probably hack that yes
[19:48] <seb128> asac: did you figure what is wrong or do you think it will take a while before you can debug it and we should better workaround for now?
[19:50] <asac> seb128: the problem is a deadlock of jemalloc if fakeroot or aoss or other libc wrappers are involved
[19:50] <asac> i know about that issue. its interesting that it pops up now though
[19:50] <asac> especially because xulrunner-1.9.1 installs properly on the builders
[19:50] <asac> for firefox-3.1
[19:51] <asac> hmm ... the builders probably dont run in fake environment
[19:51] <asac> so makes sense
[19:51] <asac> seb128: i would love to debug it in the build roots instead of uploading a hack for it now
[19:51] <asac> depends on how hard disabling xul 1.9.1 would be
[19:52] <asac> if its more than like a few minutes i will fix that tomorrow
[19:52] <asac> by dont using --gre-version
[19:53] <seb128> asac: wait for pitti replies but I except that ignoring xulrunner crashes is a one liner to hack temporarly in the retracers
[19:53] <seb128> asac: the hack will be overwritten in the next apport update though probably so still good to fix when you have time for that
[19:54] <asac> seb128: yes. i will fix it latest tomorrow evening. i just would like to debug tomorrow a bit before uploading new xulrunner
[19:54] <seb128> asac: ok thanks that's fine
[19:54] <asac> if you can even live with hanging retracers for a day thats even simpler i guess
[19:54] <seb128> those are only retracers if they don't run for a day that's no issue
[19:55] <asac> good ;)
[19:55] <seb128> we have enough bugs waiting to be triaged ;-)
[19:55] <asac> lol
[19:55] <asac> i think they should be on when beta gets out
[19:56] <seb128> well, no retracer doesn't mean we don't collect bugs
[19:56] <seb128> the backlog will be retraced
[19:56] <seb128> but right, better to retrace while the versions are still current
[19:56] <seb128> time to go to the pub
[19:56] <seb128> see you later
[20:07] <pitti> asac: oh, so you saw that hang before?
[20:08] <pitti> asac: I'll see to temporarily ignoring them tomorrow morning
[20:08] <pitti> dinner time, and then I'll be off for the evening
[20:08] <pitti> asac: thanks!
[21:04] <dobey> anyone particularly great at understanding dpkg and python?
[21:06] <hyperair> dobey: what's the matter?
[21:07] <dobey> well, for some reaosn, dpkg-whateverfiguresoutpythondeps is adding python2.4 to ${python:Depends}... and i don't even have python2.4 installed
[21:07] <dobey> and i can't figure out why the hell it is doing so
[21:11] <hyperair> i think it's a dh thing
[21:11] <hyperair> dh_somethingpythondeps
[21:11] <hyperair> see man dh_pycentral
[21:12] <hyperair> dobey: ^
[21:12] <dobey> right
[21:15] <dobey> ah-hah!
[21:15] <dobey> thanks
[21:19] <hyperair> dobey: =)