[03:25] <lukehasnoname> Evening gents
[08:45] <pitti> bonjour seb128
[08:45] <seb128> hello pitti!
[08:45] <pitti> seb128: FYI, doing the ekiga 3 update ATM
[08:45] <seb128> cool, thanks
[08:47] <seb128> grrr at xulrunner breaking $webbrowser, brb
[09:23] <seb128> lool: hi, do you still need the evince hildon patch? it has been disabled some time ago and nobody complain but there is still a copy in the package I'm wondering if it should stay there
[09:27] <seb128> lool: I think we stopped using it because it was using the hildon fileselector changes and that was not working in intrepid
[10:07] <pitti> seb128: argh, ekiga 3 forgets *all* configuration settings from 2 :(
[10:08] <seb128> pitti: urg, upstream deserves some kicking there
[10:08] <pitti> it starts with the wizard, doesn't know my SIP numbers in evo any more, no call history any more, etc.
[10:08] <pitti> so I'm not sure at all whether I should upload this now
[10:09] <seb128> could you try to figure if that's an upstream choice or a bug?
[10:09] <seb128> we are not likely to do the upstream work there so if that's a choice we can decided to stay on the current version for ever or upload the new one
[10:12] <pitti> seb128: I'll file some bugs upstream, let's see
[10:12] <seb128> ok
[10:14] <pitti> seb128: using @ekiga.net numbers doesn't even work any more
[10:14] <pitti> gah
[10:41] <pitti> seb128: ok, done, and mentioned the upstream bugs in bug 274085
[10:41] <seb128> pitti: thanks
[10:48] <huats> morning everyone
[10:49] <seb128> hello huats
[10:49] <huats> hey seb128
[11:23] <lukehasnoname> What package involves the top menus in Gnome?
[11:23] <seb128> lukehasnoname: what do you mean exactly?
[11:26] <lukehasnoname> well,
[11:27] <lukehasnoname> I don't exactly know where to start, but I very strongly prefer the "fedora" style of the top menus, where the preferences and system menus are broken into smaller groups of similar tasks
[11:28] <lukehasnoname> and just for kicks I was wondering what packages are involved in fixing that, so that I could "patch" the issue I have on my own
[11:30] <seb128> lukehasnoname: gnome-menus has the layouts and the applications .desktop set their own categories then so you might need to change those too
[11:32] <lukehasnoname> thanks, I'll check and see if that is what I want
[11:32] <lukehasnoname> I really should go to bed though
[11:32] <lukehasnoname> it's 5:30am and I have class at 10
[12:36] <kagou> Hi
[12:38] <seb128> hey kagou
[14:27] <lool> seb128: Thanks for the headsup, I think we're using plain evince gtk for now for the reason you described
[14:27] <lool> seb128: ideally, we'd reenable it with an evince-hildon build, just removing the hildon-fm part, but we can do that anytime
[14:28] <seb128> lool: does it make easier if we keep the patch copied in the debian directory somewhere meanwhile?
[14:29] <lool> seb128: I don't understand
[14:29] <lool> seb128: You mean you propose to put the patch somewhere?
[14:29] <lool> seb128: Anywhere is fine
[14:30] <seb128> lool: the current package has the patch copied in the debian directory but not used since it didn't apply and we didn't want to block the update, so we copied it out of the patches directory
[14:30] <lool> seb128: Oh right, just rename it to .patch.disabled if you like
[14:30] <seb128> that's what we did
[14:31] <seb128> the question was whether we should keep it under this name or if we can drop it
[14:31] <seb128> ie, will it be useful when you try to hildonize it again
[14:31] <lool> seb128: It's easiest to find it like this, but if it's a pain, remove it
[14:32] <seb128> no it's not, I was just wondering if you planned to hildonize it again some day
[14:32] <seb128> I'll keep it
[14:32] <seb128> lool: otherwise I've been looking at syncing pygobject and pygtk on debian
[14:32] <seb128> did you try to build the new pygtk?
[14:32] <lool> seb128: Let me check
[14:33] <lool> seb128: BTW I'm not supposed to do distro stuff this week
[14:33] <seb128> the make checks breaks there because it tries to access the su recently-used
[14:33] <lool> seb128: Yeah, I recall that testsuite failure
[14:33] <lool> seb128: I didn't look into it, but I made the testsuite not fail the build
[14:34] <lool> seb128: I didn't merge any of the late pygtk/pygobject work to debian though
[14:34] <lool> Too much in a hurry back then
[14:34] <seb128> lool: ah, I didn't know, there is no hurry those will likely wait next week anyway because debian bumped the python version to 2.5 which will force to rebuild eveything which uses python2.4-gobject
[14:34] <seb128> and there is a CD planned for this week
[14:34] <lool> I see
[14:34] <seb128> anyway enough distro questions for you for now then, thanks for replying ;-)
[14:36] <lool> happy to help :)
[14:36] <lool> (It's ok to answer short questions, just can't start any real distro work)
[14:48] <seb128> pedro_: you closed bug #83326 too quickly, the crash is a gnome-keyring one, they dupped the upstream bug wrongly or reassigned to the wrong component
[14:49] <pedro_> seb128: ok looking at it
[14:50] <pedro_> seb128: i'll re open it and re assign the upstream one
[14:50] <pedro_> seb128: thanks!
[14:50] <seb128> pedro_: thank you ;-)
[14:58] <seb128> fta: are you still interested to look at the cairo update?
[15:31] <asac> seb128: hi ... do you know anyone from upstream we could bribe to take a look at the at-spi patch from gnome bug 558028  (lp 278095)?
[15:33] <seb128> asac: hello, no I don't really know the a11y contributors, you should try asking to themuso rather
[15:33] <asac> seb128: yeah did so i -devel. just thought you might know more ;)
[15:34] <seb128> was worth asking but I don't ;-)
[15:52] <seb128> mvo: bug #297362
[15:53] <seb128> mvo: would it be possible to filter out those errors? or autoduplicate rather
[15:53] <seb128> that's a dpkg bug or something?
[15:53] <james_w> would a bug pattern work?
[15:54] <seb128> james_w: aren't bug pattern specific to a source or binary component?
[15:54] <james_w> not sure, sounds likely though
[15:56] <mvo> seb128: I will add it
[15:57] <seb128> grrrrrr, xulrunner stucked again, how can we ship such crappy softwares
[15:57] <seb128> need to restart
[16:01] <seb128_> re
[16:01] <seb128_> mvo: thanks
[17:06] <asac> seb128: xulrunner? during what use case?
[17:07] <asac> flash? or general epiphany bustage?
[17:07] <seb128> asac: still the same issue I gave you valgrind logs about during the hardy cycle
[17:08] <seb128> asac: it sometimes crash or hang when you close it
[17:08] <asac> ok crash.
[17:08] <seb128> no, crash is alright
[17:08] <seb128> sometime it hangs
[17:08] <seb128> and blocks any other new instance
[17:09] <seb128> the stacktrace looks similar when it hangs
[17:11] <seb128> I think I read on some debian bug that the next xulrunner upload will fix a similar issue
[17:11] <seb128> let's see if it's fixed this cycle ;-)
[17:11] <asac> seb128: fixed upstream or in debian?
[17:11] <asac> let me search for the bug
[17:12] <seb128> the debian maintainer wrote in a bug that the next xulrunner upload to debian should fix the issue
[17:12] <seb128> dunno if the fix is an upstream one or a debian specific change though
[17:17] <asac> hmm buglist of xulrunner in debian is quite short
[17:18] <seb128> the bug is one assigned to epiphany-browser, I would have read the comments otherwise, I just read pkg-gnome bugs there
[17:18] <seb128> but there was no useful detail
[17:19] <asac> seb128: would be grateful for a bug id ;)
[17:19] <asac> no pending bugs in epiphany-browser atm
[17:19] <seb128> asac: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504441
[17:34] <asac> seb128: a bit strange. the crash has a line number upstream doesnt have in nsThreadUtils.cpp
[17:34] <asac> looked at debian diff.gz and it seems they have a tentative fix
[17:34] <asac> that would make the file match that line number again
[17:35] <asac> but that means the fix doesnt work
[17:35] <asac> http://paste.ubuntu.com/73407/
[17:35] <seb128> they didn't do any upload since they added the comment though
[17:35] <asac> a bit strange because the crash is a null deref
[17:35] <seb128> which would suggest the change has not been uploaded yet
[17:36] <asac> yeah. must be
[20:02] <pitti> if I have a gconftool --dump output, how can I feed that back into gconf?
[20:15] <pitti> found it (--load)
[21:08]  * calc thinks he might be getting an ear infection :\
[21:09] <calc> never had one of those before though so not quite sure what it feels like