=== fta_ is now known as fta
[06:28] <dholbach> good morning
[09:09] <huats> morning everyone
[09:16] <asac> mvo: what about bug 19021 ... is that suitable for hardy-updates?
[09:16] <ubottu> Launchpad bug 19021 in synaptic "Should run dpkg --configure -a automatically" [Medium,Triaged] https://launchpad.net/bugs/19021
[09:17] <asac> or better: do we have a safe fix for it?
[09:33] <mvo> asac: give me a sec
[09:34] <mvo> asac: this is implemented in update-manager now, it will fix some common mistakes
[09:34] <asac> mvo: safe to take for SRU?
[09:35] <mvo> the update-manager bits are part of hardy already
[09:35] <mvo> for synaptic that would be a new feature, I don't think we could get it pass the release team
[09:35] <asac> oh ok, so ill state that and mark wont fix for hardy. thanks
[09:36] <asac> i approved for intrepid
[09:36] <mvo> update-notifier will show a error symbol (not sure if it detect dpkg --configure -a by itself, but it does a lot of broken situations) - when you left click on it, u-m will kick in and do the repair action
[09:36] <mvo> asac: how come you triage those? or is this part of a general milestone cleanup?
[09:37] <asac> mvo: well ... i looked at the hardy bug list and found this.
[09:38] <mvo> cool, thanks
[09:38] <asac> done
[09:40] <asac> any way to tell power manager to set powersave governour instead of ondemand when on battery?
[09:53] <mvo> seb128: I was debugging a update-manager hang the other day and it seems like it hangs here: http://paste.ubuntu.com/10700/ (strace)
[09:54] <mvo> seb128: tihs is in the dist-ugprader, do you have any idea if for svg something else needs to be initialized beside the normal gtk_init() (that is run when importing gtk)
=== asac_ is now known as asac
[10:06] <seb128> mvo: no idea no, are you sure that's the thread hanging and that the hang is due to the svg? did you get a gdb stacktrace?
[10:12] <mvo> seb128: it looks like it, I'm digging into it a bit more
[10:12] <seb128> mvo: do you have steps to trigger the bug easily?
[10:13] <mvo> not easily :/
=== crevette_ is now known as crevette
[10:18] <mvo> seb128: what beside libgdk-pixbuf2-dbgsym and libgtk2.0-0-dbgsym will I need for #6  0xb78d5b26 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 ?
[10:19] <seb128> mvo: the dbgsym seems to be borked, try the dbg maybe
[10:21] <mvo> #4  0xb755ff59 in ?? () from /usr/lib/libgdk_pixbuf-2.0.so.0
[10:21] <mvo> No symbol table info available.
[10:21] <mvo> oh well
[10:22] <seb128> grumpf, need to rebuild gtk I guess
=== MacSlow_ is now known as MacSlow
[10:47] <seb128> mvo: I'm not sure how to debug that, I blame it on pitti that's due to dbgsym thingy I think ;-)
[10:49] <mvo> :)
[10:49] <mvo> that is ok, I think I found a workaorund for now, I need to wait for feedback from my users
[10:49] <seb128> I hate this thing
[10:49] <mvo> what thing?
[10:49] <mvo> bugs in general ?
[10:49] <seb128> neither the gtk dbg nor the dbgsym are working in hardy
[10:50] <seb128> no, debug symbols issues
[10:50] <seb128> it makes almost impossible to debug crashes we receive
[10:50] <seb128> my local builds have working dbg variants
[10:51] <seb128> so I guess it's due to the binary mangler but I don't know why it's breaking things
[10:52] <seb128> and to make things easier dbgsym are not available for hardy updates
[11:19] <mvo> seb128: ok, thanks. I will rebuild it after lunch
[11:23] <seb128> I'm debugging
[11:27] <seb128> bad pkg-create-dbgsym, no cookie for you
[11:27] <seb128> pitti: ok, so pkg-create-dbgsym is buggy and break gtk debugging
[11:27] <seb128> pitti: that's what gtk does
[11:28] <seb128> dh_strip -s --dbg-package=libgtk2.0-0-dbg -Nlibgtk-directfb-2.0-0-udeb
[11:28] <seb128> dh_strip -s -plibgtk-directfb-2.0-0-udeb
[11:28] <seb128> pitti: and pkg-create-dbgsym don't respect the package specified in the second call and stip everything again
[11:28] <seb128> s/stip/strip
[11:28] <seb128> which means the dbg and the dbgsym are b0rked
[11:33] <seb128> pitti: do you think that doing an export NO_PKG_MANGLE=1 between the calls would be a good workaround?
[11:34] <seb128> no need to export, rather NO_PKG_MANGLE=1 dh_strip -s -plibgtk-directfb-2.0-0-udeb
[11:35] <seb128> hum
[11:39] <seb128> "dh_strip -s -plibgtk-directfb-2.0-0-udeb" seems buggy in fact
[11:39] <seb128> dh_strip -plibgtk-directfb-2.0-0-udeb should do the trick
[11:39] <pitti> seb128: give me a second, currently discussing with Matt
[11:39] <seb128> sure
[11:39] <pitti> seb128: do we have a bug# for the broken mass-storage camera handling?
[11:40] <seb128> is it broken?
[11:40] <pitti> seb128: i. e. nautilus mounts them, but doesn't check for a DCIM/ folder, as g-v-m did
[11:40] <seb128> works for me since you enabled g-v-m again
[11:40] <pitti> g-v-m handles libgphoto, calls f-spot
[11:40] <pitti> but mass-storage cams are mounted, not libgphoto'ed
[11:40] <seb128> a right
[11:40] <seb128> again due to the gphoto gvfs backend being disable
[11:41] <seb128> pitti: bug #208467
[11:41] <ubottu> Launchpad bug 208467 in nautilus "Camera Device button "Open F-spot Photo Manager" doesn't work" [High,Confirmed] https://launchpad.net/bugs/208467
[11:41] <pitti> right
[11:41] <pitti> thanks, seb128, you are faster than google :)
[11:41] <seb128> you are welcome ;-)
[11:41] <seb128> it's in my few unread bug mails
[11:42] <seb128> ie, things to reply on
[11:42] <pitti> I mark it for .1, ok?
[11:42] <seb128> sure
[11:42] <seb128> I think we should consider enabling the gvfs gphoto backend
[11:42] <pitti> seb128: I just fail to see what the gphotofs backend has to do with it?
[11:43] <pitti> seb128: it doesn't (shouldn't) handle mass-storage cams
[11:43] <pitti> mdz's problem is that the "open f-spot" button in nautilus doesn't work
[11:43] <seb128> right
[11:43] <seb128> the feature relies on having a DCIM directory available
[11:43] <mdz> is this bug 208467?
[11:43] <pitti> mdz: ^ on your empty camera, do you have that?
[11:43] <mdz> if so, what information can I add to the bug?
[11:43] <ubottu> Launchpad bug 208467 in nautilus "Camera Device button "Open F-spot Photo Manager" doesn't work" [High,Confirmed] https://launchpad.net/bugs/208467
[11:43] <seb128> but that's the gphoto code which does the handling I think
[11:43] <mdz> pitti: yes
[11:44] <seb128> mdz: it is yes, no information is required I think, it just needs somebody working on fixing the issue
[11:44] <pitti> it might be the cleanest way to enable gphoto, fix the fuse-mount (so that it works with non-gvfs apps), and disable it in g-v-m again?
[11:45] <mdz> seb128: ok, the comments seemed to say it was fixed in g-v-m but I see there is a nautilus task still open
[11:45] <seb128> pitti: yes
[11:45] <pitti> right, g-v-m was a kneejerk fix for hardy final
[11:45] <seb128> mdz: right, we disabled the gvfs code and used g-v-m again in hardy
[11:45] <pitti> I guess we can emulate that with an USB stick which has DCIM/ and a few jpgs in it?
[11:45] <seb128> yes
[11:46]  * pitti only has a gphoto camera
[11:49] <seb128> pitti: you can ignore the dbgsym issue description I made before, the second dh_strip call in the package is simply buggy, I'll fix it after lunch
[11:50]  * seb128 lunch now
[11:50] <pitti> seb128: ok, thanks
[11:50] <pitti> lunch, good idea
[14:11] <seb128> pitti: ok, can you accept the gtk sru upload?
[14:11] <seb128> it should fix the dbgsym build
[14:11] <seb128> mvo: bug #227723 for the record
[14:12] <ubottu> Launchpad bug 227723 in gtk+2.0 "non working debug variants in hardy" [Medium,Fix committed] https://launchpad.net/bugs/227723
[14:15] <mvo> thanks seb128
[14:22] <seb128> mvo: did you figure what was the svg issue then?
[14:23] <mvo> not yet, I *think* its something evil with threading a stuff, but I don't know yet
[14:51] <pitti> seb128: thanks for that; I'll have another SRU round in a bit, yes
[17:05] <Amaranth> mvo: do you have the bug number for the animation fixes?
[17:06] <Amaranth> dunno if they made it into -proposed yet, just want to see if i've got a dupe of that
=== vuntz_ is now known as vuntz
[19:25]  * mvo wonders if archive.u.c is slow for everybody just now
[19:28] <mvo> Amaranth: I think the bug in animation was #220631
[19:29] <Amaranth> d'oh, i was looking in compiz :P
[19:29] <Amaranth> mvo: can you reproduce bug 218489 ?
[19:29] <ubottu> Launchpad bug 218489 in openoffice.org "Graphical interface freeze when switching between OpenOffice and another window" [High,Confirmed] https://launchpad.net/bugs/218489
[19:29] <Amaranth> seems to be the same thing
[19:33] <mvo> give me a sec
[19:33] <mvo> I think I have -0ubuntu5 installed already
[19:33] <mvo> I created a ~compiz ppa btw
[19:34] <Amaranth> yeah, i've used it before
[19:34] <Amaranth> wait, maybe that was your ppa
[19:34] <mvo> yeah, I used mine but that is not ideal - the ~compiz is better, then you can upload as well without sponsoring
[19:35] <mvo> I think I can not reproduce it with 0.7.4-0ubuntu5
[19:35] <mvo> let me downgrade
[20:07] <pochu> asac: hey, Liferea's upstream dev added Xul 1.9 support to both 1.4 series and trunk. That wasn't from your patch though, but from a different one which was sitting in the patch tracker and that doesn't break Xul 1.8 support... you may want to have a look at it. http://liferea.svn.sourceforge.net/liferea/?rev=3849&view=rev
[20:09] <asac> pochu: how can i see the complete diff for that commit?
[20:12] <asac> pochu: they have think XPCOM_GLUE == GECKO_1_9 ... which is not really true. but if it works for us. fine
[20:15] <pochu> asac: I haven't tested it yet, but I'll try to do it before the 1.4.16 release
[20:15] <seb128> hey pochu
[20:16] <pochu> hi seb128 :)
[20:17] <seb128> pochu: interested to get the gthumb new version to hardy?
[20:21] <pochu> mvo, Amaranth: do you know Kristian Lyngstøl?
[20:21] <Amaranth> yep
[20:22] <Amaranth> pochu: why?
[20:22] <mvo> pochu: yes
[20:23] <pochu> because he's my room mate for UDS and I did never hear about him ;)
[20:23] <pochu> seb128: there's already a debdiff in the bug, did you see it?
[20:23] <pochu> seb128: I've never used gthumb so I'm not very interested on it tbh...
[20:23] <Amaranth> pochu: well, he is a compiz-fusion guy
[20:23] <seb128> pochu: that's an intreprid update rebased on debian no?
[20:24] <seb128> pochu: ok, that's alright, I will try to find somebody else interested then
[20:24] <Amaranth> pochu: cool guy, bit heavy on the sarcastic humor sometimes though :)
[20:24] <seb128> pochu: I'm too busy to do it but I think we should get the update in hardy, so it's only the matter of finding somebody wanting to do the work there ;-)
[20:24] <pochu> I'm sarcastic too :)
[20:25] <Amaranth> pochu: remember that if it sounds like he says something bad :)
[20:25] <pochu> although I'm sarcastic in Spanish... not sure how I'll do in English ;)
[20:25] <Amaranth> before i met him in real life i actually thought he was a jerk, the humor doesn't come through well on IRC :P
[20:26] <Amaranth> but you should get along fine
[20:26] <pochu> seb128: ah, ok. I could review it if that's what you want but gthumb is in main anyway so you (or some core-dev) will have to re-review it ;)
[20:26] <pochu> heh
[20:27] <seb128> pochu: no, somebody needs to do the update for hardy and look at the launchpad bugs that can be closed, etc
[20:27] <seb128> pochu: I can do the reviewing
[20:27] <pochu> ah, right
[20:27] <pochu> but the update for Hardy wouldn't be more or less similar to the one for Intrepid?
[20:29] <seb128> no, sru are minimal changes, so it's an update using the hardy version and not the debian one
[20:30] <pochu> ah, I thought we wanted to put the new upstream for Hardy too
[20:31] <pochu> although that would make more sense to go to backports, right
[20:31] <pochu> so what needs to be updated for Hardy? backport some patches from the new release?
[20:32] <seb128> pochu: right, I was suggesting doing the version update for hardy, just do it using the hardy version and not the current debian one
[20:32] <seb128> to not include extra packaging changes where it's not required
[20:33] <seb128> s/do/doing
[20:33] <pochu> ok, understood now :)
[20:33] <seb128> well, usually that would be a backport thing
[20:33] <seb128> but hardy is a lts and we will do a 8.04.1 so getting bug fix updates there makes sense
[20:34] <seb128> seems that gthumb has quite some users and the new version fixes several annoying issues
[20:35] <pochu> ok, let me have a look