[00:00] <seb128> lol
[00:00] <seb128> I didn't notice the pycairo changes had been done
[00:00] <seb128> I would have uploaded the pygtk changes otherwise
[00:00] <pochu> ember: why?
[00:03] <seb128> they can be accepted after beta if those are stable updates
[00:05] <pochu> liferea is, and has a bug fix for 1.0 -> 1.4 cache updates, which is interesting for dapper->hardy upgrades
[00:06] <pochu> I think I'll call to Dell tomorrow to make sure everything's going fine ;)
[01:50] <linoss> anyone of a software application that records a phone conversation utilizing the internal modem on a PC?
[01:50] <linoss> I hope this is the correct channel to post this question
[08:24] <seb128> hey hey mvo
[08:26] <mvo> hwy seb128
[08:27] <mvo> (that was a bavarian hey)
[08:27] <seb128> ;-)
[08:52] <slomo> seb128: http://launchpadlibrarian.net/12662959/buildlog_ubuntu-hardy-i386.gtk%2B2.0_2.12.9-2_FAILEDTOBUILD.txt.gz  <--- something is unhappy... known problem? :)
[08:53] <pitti> kwwii: did human-theme build for you locally? http://launchpadlibrarian.net/12625757/buildlog_ubuntu-hardy-i386.human-theme_0.13_FAILEDTOBUILD.txt.gz
[08:54] <pitti> kwwii: "error: can't copy 'build/share/themes/Human/index.theme': doesn't exist or not a regular file
[09:11] <mvo> Amaranth: can you reproduce bug #99508 ?
[09:11] <ubotu> Launchpad bug 99508 in compiz "Window titlebar displayed not right with compiz enabled" [Medium,Confirmed] https://launchpad.net/bugs/99508
[09:12] <XiXaQ> hmm. I was sure I registered a bug regarding the new clock applets "Adjust date and time" menu item not using the default dialog for doing so in Hardy, but I can't find it..
[09:13] <XiXaQ> is the old clock applet still available in hardy, does anyone know?
[09:13] <dholbach> good morning
[09:14] <mvo> hey dholbach
[09:15] <dholbach> hey mvo
[09:16] <mvo> Amaranth: meh, I can not reproduce #150702 either
[09:46] <seb128> lool, slomo: do you know if public modules using python-support are available during upgrade now?
[09:47] <slomo> seb128: no, i know nothing about the new python policy and everything related to it... i'm trying to not touch packaging of such stuff and if i have to i'm looking at other packages ;)
[09:49] <lool> seb128: I don't know
[09:50] <seb128> I got complain from pygtk upstream than pygtk is broken during upgrades
[09:50] <seb128> and I think the new pycentral fixes this issue and pysupport is still buggy
[09:50] <seb128> I'm pondering if we should switch to pycentral for hardy
[09:50] <lool> seb128: I would think not as I see update-python-modules -c in prerm
[09:50] <seb128> lool: not what?
[09:50] <lool> seb128: But then python-support is a bit special
[09:51] <lool> seb128: I would think it's not available
[09:51] <lool> Would it be available, it would be in postrm
[10:17] <lool> seb128: I see libglib-perl has been uploaded in Debian
[10:18] <seb128> lool: a new version you mean? something we want to use?
[10:20] <lool> I guess so
[10:21] <lool> seb128:  libglib-perl (1:1.180-1) unstable; urgency=low
[10:21] <lool>  .
[10:21] <lool>    * New upstream release
[10:21] <lool> That's all
[10:21] <seb128> ok
[10:21] <seb128> will be for after beta then
[10:21] <lool> Sure
[10:22] <seb128> slomo: btw you might want to use the shared-mime-info change I did yesterday for debian
[10:25] <slomo> seb128: will do, thanks
[11:05] <mvo> asac: the firefox restart required informatio is displayed for me unconditionally even if ff is not running. is that a knwon issue?
[11:07] <asac> mvo: can you see whats wrong?
[11:07] <asac> (no its not known)
[11:07] <mvo> asac: I think the firefox-3.0-restart-required is lacking the "DisplaIf" line AFAICS
[11:08] <asac> strange. i took it from the old package
[11:09] <asac> mvo: how should it read?
[11:09] <mvo> I can have a look after lunch
[11:09] <asac> DisplayIf: $STARTUPWMCLASS ?
[11:09] <asac> i thnk i found it: DisplayIf: ps -C firefox-bin
[11:10] <mvo> asac: yes, thats it
[11:10] <mvo> asac: probably with a ps -C firefox-bin >/dev/null to avoid spittng stuff to ~/.xsession-errors
[11:11] <asac> thanks
[11:11] <mvo> thank you !
[11:12] <asac> mvo: is there a pattern that also takes into account that firefox is running for the current user?
[11:13] <mvo> asac: update-notifier runs with the same uid as the logged in user, so we need to limited the ps to the users processes and we are good
[11:13] <asac> ok
[11:14] <asac> mvo: you have an expression at hand (its friday and i feel botty :))
[11:14] <asac> ok fixed with the above in bzr
[11:14] <mvo> asac: give me a sec (friday for me too ;)
[11:15] <mvo> asac: pgrep firefox-bin -u $USER
[11:16] <asac> that works
[11:16] <mvo> or pgrep firefox-bin -U $(id -u)
[11:16] <asac> :)
[11:16] <asac> ok
[11:17] <asac> yeah the last one looks good
[11:18] <asac> thanks
[11:18] <mvo> cheers
[11:19] <asac> fixed in bzr
[11:30] <asac> mvo: i would like to discuss if its possible to make firefox/xulrunner upgrades safe in intrepid and if we think it might be possible discuss this at UDS.
[11:31] <asac> mvo: you think we can do a pre-call to discuss some ideas i have .... lets say next week?
[11:37] <Hobbsee> asac: "safe"?
[11:42] <slomo> seb128: can sync shared-mime-info from debian now
[11:42] <seb128> slomo: ok, will do after the beta freeze
[11:47] <asac> Hobbsee: yes its not safe atm :)
[11:49] <Hobbsee> asac: i'm trying to figure out what you're defining as "safe", though
[11:57] <asac> no crashes ... no unexpected behaviour and so on
[11:57] <asac> (that do eventually happen - in case you had been lucky and never experienced that :))
[11:59] <Hobbsee> ah right
[11:59] <Hobbsee> yeah, true
[11:59] <asac> not a trivial thing to fix though
[12:40] <dholbach> I wished somebody killed scrollkeeper for good
[12:53] <seb128> dholbach: why?
[12:53] <dholbach> the update runs take ages on my laptop :)
[12:53] <seb128> dholbach: I think rarian compat thing is slower
[12:54] <dholbach> really?
[12:54] <seb128> I did try by then and that's one of the reason why I didn't do the switch
[12:54] <seb128> yes, the compat is not optimized, the goal is to ride of it
[12:54] <seb128> to get rather
[12:55] <dholbach> that'd be the best thing since sliced bread
[12:55] <seb128> ;-)
[12:58] <mvo> asac: sounds great
[12:58] <mvo> asac: (sorry, lunch took longer)
[12:58] <dholbach> hmmmm lunch
[13:01] <seb128> pitti: do you do freeze exception or that's only steve now?
[13:03] <Hobbsee> seb128: afaik, anyone can do them
[13:03] <seb128> Hobbsee: anyone?
[13:03] <Hobbsee> seb128: well, anyone in -release
[13:04] <seb128> Hobbsee: that includes you? ;-)
[13:04] <Hobbsee> seb128: in some mutant sense, yes.
[13:04]  * seb128 hugs Hobbsee
[13:05]  * Hobbsee hugs seb128 bakc, and waves her antlers around
[13:06] <Hobbsee> seb128: it's the kind of mutant-cant-do-much-due-to-no-drescher-access, so....
[13:06]  * Hobbsee may or may not be therefore useful.
[13:08] <seb128> Hobbsee: that's alright, I'm just going to do some bug fix upload and I was wondering if they were likely to be accepted today
[13:08] <Hobbsee> seb128: tbh, i'm not overly comfortable doing high-impact accepts, as i'm aware that a lot of the release decisions get taken in private areas, which i don't have access to.
[13:09] <Hobbsee> seb128: i had proof of that after UDS, and, afaik, it still happens, so
[13:09] <seb128> I don't think that's a true statement
[13:09] <Hobbsee> seb128: it's safer not to work with obsolete info.
[13:17] <seb128> anyway I've no high impact uploads
[13:17] <seb128> I've just uploaded a one liner fix to gvfs which is waiting
[13:17] <seb128> and the patch is from the upstream svn
[13:18] <Hobbsee> seb128: in unapproved?
[13:18] <seb128> seb128: dunno, in wherever things we upload during a freeze land ;-)
[13:19] <Hobbsee> seb128: approved.
[13:19]  * Hobbsee waits to see if this all still works
[13:20] <Hobbsee> grrr
[13:20]  * Hobbsee grumbles at this bug, just as she did last cycle.
[13:21] <seb128> Hobbsee: thanks
[13:21] <Hobbsee> seb128: you're welcome
[13:21] <Hobbsee> and a timeout.
[13:26] <dholbach> the workspace switcher applet thing is still broken in hardy
[13:26] <dholbach> NARF!
[13:27] <dholbach> so no compiz for me on my laptop
[13:41] <seb128> dholbach: how is it broken now?
[13:42] <dholbach> the same as before
[13:42] <dholbach> hang on, I'll post a screenshot
[13:44] <dholbach> http://daniel.holba.ch/temp/compiz-b0rk.png
[13:45] <Hobbsee> dholbach: iz undocumented feature.
[13:45] <Hobbsee> dholbach: it's now up to you what you would like to see in that bottom box :)
[13:45] <dholbach> Hobbsee: ahhhh nice :)
[13:45] <seb128> dholbach: reset your compiz config
[13:45] <dholbach> (MacSlow), mvo, seb128: ^
[13:46] <seb128> dholbach: gconftool --recursive-unset /apps/compiz
[13:46] <dholbach> OK... here we go again
[13:47] <seb128> dholbach: not the first time you do that? ;-)
[13:48] <dholbach> seb128, mvo: http://daniel.holba.ch/temp/compiz-b0rk2.png
[13:48] <dholbach> new variation :)
[13:48] <seb128> dholbach: cat .config/compiz/compizconfig/Default.ini
[13:48] <dholbach> daniel@lovegood:~$  cat .config/compiz/compizconfig/Default.ini
[13:48] <dholbach> cat: .config/compiz/compizconfig/Default.ini: No such file or directory
[13:48] <dholbach> daniel@lovegood:~$
[13:48] <seb128> dholbach: what do you have in .compiz and .config/compiz?
[13:50] <dholbach> daniel@lovegood:~$ find .config/compiz/
[13:50] <dholbach> .config/compiz/
[13:50] <dholbach> .config/compiz/compizconfig
[13:50] <dholbach> .config/compiz/compizconfig/config
[13:50] <dholbach> daniel@lovegood:~$ find .compiz/
[13:50] <dholbach> find: .compiz/: No such file or directory
[13:50] <dholbach> daniel@lovegood:~$
[13:50] <dholbach> daniel@lovegood:~$ cat .config/compiz/compizconfig/config
[13:50] <dholbach> [gnome_session]
[13:50] <dholbach> profile =
[13:50] <dholbach> plugin_list_autosort = true
[13:50] <dholbach> daniel@lovegood:~$
[13:51] <mvo> dholbach: my, bugger, can you please run ccsm
[13:51] <mvo> and go to general options
[13:51] <mvo> desktop size
[13:51] <mvo> and check the "number of desktops" property there?
[13:51] <seb128> mvo: where should that be written?
[13:51] <mvo> in gconf
[13:51] <seb128> mvo: and I though that is was not possible to have a different setting that 1 workspace now?
[13:51] <dholbach> and it deactivated my Ctrl-< key for open terminal
[13:52] <mvo> seb128: yes, I want to make sure that dholbach has it too
[13:52] <seb128> mvo: what key is the corresponding one?
[13:52] <mvo> seb128: it should not be possible anymore, but the screenshot suggests that it is still for some reason :/
[13:52] <seb128> mvo: I suspect something like your issue this week, wrong gconf default to etc or something
[13:52] <dholbach> horizontal 3, vertical 2, number of desktops 6?
[13:52] <dholbach> does that make sense?
[13:53] <dholbach> it was at 2, 1, 1
[13:53] <dholbach> oh, I can't change number of desktops
[13:53] <mvo> dholbach: but it is still 6 even though you can not change it?
[13:53] <dholbach> no, it's 1
[13:53] <seb128> mvo: what is the gconf key involved?
[13:54] <seb128> dholbach: grep compiz /etc/gconf/* -r
[13:54] <dholbach> seb128: nothing
[13:54] <seb128> bah, ok, I'll let mvo debug it
[13:54] <mvo> seb128: it should be "number_of_desktops" in /apps/compiz/general/screen0/options
[13:55] <dholbach> also ccsm gives me GConf backend: There is an unsupported value at path /apps/compiz/plugins/scale/allscreens/options/initiate_edge. Settings from this path won't be read. Try to remove that value so that operation can continue properly.
[13:55] <dholbach> GConf backend: There is an unsupported value at path /apps/compiz/plugins/scale/allscreens/options/initiate_edge. Settings from this path won't be read. Try to remove that value so that operation can continue properly.
[13:55] <mvo> dholbach: thanks! the vnumber_of_desktops 6 is the culprit, it should no longer be possible, but apparently it is, it looks like a bug in compiz to me
[13:55] <mvo> dholbach: you have restarted or loged in loged out?
[13:56] <dholbach> mvo: I'll remove all the settings again, then re-login, then switch to compiz again
[13:56] <dholbach> let's see what happens
[13:57] <mvo> dholbach: I had hoped the limited the number of desktops would fix it. oh well
[13:57] <seb128> mvo: you should remove this if [ $user == "dholbach" ] joke now ;-)
[13:57] <dholbach> haha
[13:57] <dholbach> brb
[14:00] <dholbach> mvo: no dice
[14:01] <dholbach> same as in b0rk2.png
[14:01] <dholbach> anyway... I'm going out for lunch now :)
[14:03] <seb128> dholbach: does it happen with an another user?
[14:03] <seb128> dholbach: enjoy your lunch
[14:42] <kwwii> dholbach: did you ever figure out the problem with the cookie stuff?
[14:53] <Amaranth> bug 150702
[14:53] <ubotu> Launchpad bug 150702 in compiz "alt shift tab stopped navigating windows (gutsy)" [Low,Confirmed] https://launchpad.net/bugs/150702
[14:53] <Amaranth> mvo: i can preproduce the titlebar thing, sometimes
[14:53] <Amaranth> haven't tested recently but a bunch of other people have :P
[14:54] <Amaranth> only happens to maximized windows and only happens with clearlooks-based themes
[14:54] <Amaranth> and i think it doesn't happen to the new clearlooks so only human, unless human has been updated as well
[14:58] <dholbach_> seb128: I'll try later on
[15:04] <_MMA_> seb128: Has the little GDM drum sound vanished for you on Hardy? Has here and On Ubuntu Studio. I'm still looking into it but I figured Id ask if its known or just me.
[15:10] <pochu> good afternoon slomo
[15:13] <Amaranth> pitti: say, does jockey have a list of pciids that fglrx works with?
[15:23] <Amaranth> _MMA_: before you got your CDs made 'officially' how were you making them? UCK?
[15:25] <_MMA_> Amaranth: The old fashion way. You would have to talk to joejaxx for exact details. But is wasnt with any app.
[15:26] <Amaranth> _MMA_: did it involve modifying an existing disc or did you make one from scratch?
[15:26] <_MMA_> An Alt disk from scratch.
[15:26] <Amaranth> ah, alt disc
[15:26] <Amaranth> yeah, those are easy :P
[15:27] <_MMA_> Suuurre. :)
[15:38] <pitti> seb128: I can help out for easier cases
[15:38] <pitti> Amaranth: no, jockey itself does not have such lists; they are shipped by l-r-m
[15:38] <Amaranth> yeah, i found that out
[15:39] <Amaranth> but they don't look like something i can use
[15:39] <Amaranth> if you're using a laptop with a chip supported by fglrx i want to block compiz loading if you're using ati
[15:40] <pitti> Amaranth: I don't quite understand why you would do this?
[15:41] <Amaranth> pitti: because those chips have problems with compiz and the ati driver
[15:41] <pitti> Amaranth: shouldn't you rather test for models where compiz works with the free ati driver? (independent of fglrx)?
[15:41] <Amaranth> random lockups
[15:41] <Amaranth> the only ones that seem to work right are the ones old enough that fglrx no longer supports them
[15:42] <Amaranth> right now i've just got all laptops using the ati driver blocked
[15:42] <pitti> but shouldn't this be a pretty static set?
[15:42] <Amaranth> it's a pretty large set too :P
[15:42] <Amaranth> and i don't know what all of them are
[15:43] <Amaranth> so i need to blacklist a bazillion pciids or whitelist a bazillion pciids
[15:43] <Amaranth> i'd like to have one of those lists autogenerated, if i can
[15:48] <pitti> right; however the autogeneration needs to have a solid criterium as well
[15:48] <Amaranth> what do you mean?
[15:48] <pitti> so at one point you have to input external knowledge
[15:48] <pitti> (like testing results, or feature tests, etc.)
[15:48] <Amaranth> If you're on a laptop and fglrx supports your chip I want to block compiz from starting if you're using ati
[15:49] <Amaranth> until fglrx drops support for more cards this should work fine
[15:49] <Amaranth> I thought about doing a feature check to see what series of chip you had but the xpress 200 is one of the broken ones and it doesn't have shaders
[15:49] <Amaranth> so I ran out of things to chck
[15:50] <Amaranth> check*
[15:50] <pitti> Amaranth: so, for that you could check whether /usr/share/linux-restricted-modules/2.6.24-12-generic/modules.alias.override/fglrx has the graphics card
[15:50] <pitti> but that's a very ubuntu specific hack
[15:50] <pitti> not an upstream solution
[15:50] <Amaranth> Yeah, but so was my last hack :P
[15:51] <Amaranth> the only problem is i don't know how to turn that file into something i can use :P
[15:51] <Amaranth> what do i read to compare to it? our current system is based on pciids as reported by lspci -n
[15:51] <pitti> right
[15:52] <pitti> grep -q 'pci:0000$VID:0000$PID' /usr/share/linux-restricted-modules/2.6.24-12-generic/modules.alias.override/fglrx
[15:52] <pitti> somehting like that
[15:53] <pitti> the better way is of course something like printf("%08X", vid)
[15:53] <Amaranth> oh, duh
[15:53] <pitti> Amaranth: those are modaliases, and for pci they are composed from vendor ID (v), product ID (p), subvendor (sv), subdevice (sd)
[15:53] <pitti> and device class, subclass, and interface
[15:54] <pitti> Amaranth: this entire hack is only necessary because both the fglrx and the nvidia kernel module do not have proper modaliases
[15:54] <Amaranth> yeah
[15:54] <Amaranth> they just always try to load, don't they?
[15:54] <pitti> Amaranth: e. g. if you look at "modinfo b43", it has
[15:55] <pitti> but modinfo nvidia ist just a catch-all
[15:55] <pitti> ooh
[15:55] <pitti> modinfo fglrx -> that actually looks sensible with the latest version
[15:55] <pitti> before it didn't have any
[15:55] <pitti> \o/
[15:55] <Amaranth> hey, that looks like your list :P
[15:55] <pitti> yay, so we can remove the list frim l-r-m
[15:56] <pitti> Amaranth: right, except that the nvidia and fglrx lists from l-r-m are created by some hackish parsing of the shared libraries :)
[15:56] <pitti> Amaranth: modinfo fglrx | grep -q is at least a hack which is not distro dependent
[15:57] <Amaranth> yeah, i remember when you first wrote this it didn't detect my chip and i got a different list when i ran the script than you
[15:57] <pitti> right, that's why we now have per-arch lists
[15:57] <pitti> (in gutsy, too)
[15:57] <Amaranth> pitti: except in can't guarantee fglrx (or l-r-m) will be installed so i'll probably just turn this into something i stuff in the compiz package
[15:58] <pitti> Amaranth: true that
[15:58] <pitti> Amaranth: but at least it's a script which you could run when you wrap a release
[15:58] <Amaranth> just run a bit of regex magic over it to turn it into a regular pciid list so i don't have to write more code :)
[15:58] <pitti> it's just a handwavy heuristics anyway
[15:58] <Amaranth> oh, but i need separate arch versions
[15:58] <Amaranth> hrm
[15:58] <pitti> right, that should be easy
[15:59] <Amaranth> sure, except seb128 thinks we already call too many things in this shell script :)
[16:00] <pitti> modinfo fglrx | perl -ne 'if (/^alias:.*pci:v(\d+)d(\d+)/) { print "$1 $2\n" }'
[16:01] <pitti> erm, not \d
[16:02] <pitti> [0-9A-F] of course
[16:02] <pitti> anyway, you get the idea
[16:02] <pitti> Amaranth: per-arch> well, as you said it's only a handwavy hack, not a precise whitelist anyway
[16:04] <Amaranth> modinfo fglrx | perl -ne 'if (/^alias:.*pci:v0000([0-9A-F]+)d0000([0-9A-F]+)/) { print "$1:$2\n" }'
[16:04] <pitti> Amaranth: anyway: http://paste.ubuntu.com/5687/  <= amd64 list, for your comparison with i386
[16:04] <Amaranth> that should get me a list of pciids in the format lspci returns, right?
[16:04] <pitti> right
[16:04] <pitti> lspci -n | grep -w 0300:
[16:04] <pitti> ^ graphics cards only
[16:06] <Amaranth> ah, they are the same thing
[16:07] <Amaranth> same list on i386 and amd64 for fglrx
[16:37] <ember> isn't gpm to request password after suspend?
[16:56] <Amaranth> ember: no, gnome-screensaver locks the screen on resume
[16:56] <Amaranth> or should
[17:33] <crevette> wtf, gnome-screensaver was not installed anymore
[17:35] <Amaranth> put it out of its misery
[17:48] <seb128> re
[17:49] <seb128> pitti: sorry I was away, you were looking for work to do? ;-) I guess it'll be for next week now
[18:04] <soulc> anyone have an idea of how to fix compiz when it stops working?
[18:19] <Amaranth> 203 bugs in compiz
[18:19] <Amaranth> so close
[18:19] <Amaranth> goal was under 200 by the end of today
[18:20] <cody-somerville> Amaranth, You can do it! :)
[18:21] <Amaranth> I can get one of them into "Fix Committed" state
[18:21] <Amaranth> but I dunno how to get rid of 3 others
[18:24] <seb128> Amaranth: randomly reassign to libwnck as you do usually? ;-)
[18:24] <Amaranth> haha
[18:24] <Amaranth> hey, i _fixed_ all the bugs i assigned to libwnck :P
[18:25] <seb128> Amaranth: btw do you think you could look at bug #118936 before hardy?
[18:25] <ubotu> Launchpad bug 118936 in alacarte "Alacarte does not recover deleted menu items" [High,Triaged] https://launchpad.net/bugs/118936
[18:25] <seb128> Amaranth: right, thanks for that ;-)
[18:25] <Amaranth> seb128: that's a tricky problem
[18:25] <Amaranth> gnome-menus offers no way to get items are are Hidden
[18:25] <Amaranth> and I mark things as Hidden to "delete" them
[18:25] <seb128> isn't the menu reset just a rm .config/something?
[18:26] <seb128> or wouldn't that work rather
[18:26] <Amaranth> well no in this case i've changed the .desktop file
[18:26] <Amaranth> and you might have .desktop files in ~/.local/share/applications that alacarte didn't put there
[18:26] <seb128> right
[18:26] <seb128> nautilus uses that too ;-)
[18:26] <Amaranth> for mime stuff, yes
[18:26] <Amaranth> and WINE uses it
[18:27] <seb128> ok, so not as trivial as I though$
[18:27] <Amaranth> although i think all the files i put there are called "alacarte-madeX.desktop"
[18:27] <seb128> ah
[18:27] <Amaranth> i'll have to look again, i know that was the idea
[18:27] <seb128> in which case that's easy to delete those
[18:27] <Amaranth> to work around a couple bugs
[18:27] <Amaranth> in gnome-menus :P
[18:28] <seb128> I don't think the menu editor is that important
[18:28] <seb128> but I was trying to figure bugs that would be nice to fix for hardy
[18:28] <Amaranth> i could just remove all alacarte-made items
[18:28] <seb128> and that's the only alacarte one which seemed to be annoying
[18:28] <Amaranth> it might not recover everything but it should work 99% of the time
[18:28] <seb128> better than current ;-)
[18:31] <Amaranth> i think the rest of the alacarte bugs are it not responding well to your .menu files being broken
[18:31] <Amaranth> which means you're in trouble anyway
[18:34] <crevette> seb128: can you tell to your big chief to buy laucnhpad.net and all approximative domains around launchpad;
[18:34] <Amaranth> ah, no, that won't work
[18:34] <crevette> my fingers thanks you
[18:34] <Amaranth> to "delete" something I have to have it be named the same as the original
[18:35] <Amaranth> so no easy fix
[18:36] <seb128> crevette: ;-)
[18:37] <seb128> Amaranth: alright
[18:37] <mvo> seb128: are you aware of http://paste.ubuntu.com/5693/ ? (and/or the right person to talk to :) ?
[18:37] <Amaranth> probably requires an ABI breaking patch to gnome-menus
[18:37]  * seb128 teachs crevette how to use bookmarks
[18:38] <Amaranth> down to 202, wonder who closed another bug
[18:38]  * Amaranth guesses pedro_
[18:38] <mvo> just koffice-dev and libgphoto2-2-dev file overwrite problem for most of hardy, that is pretty impressive
[18:38] <Amaranth> mvo: i've got a better fix for ati laptops
[18:38] <Amaranth> well, i have all the stuff i need to code the better fix, just need to do it :)
[18:39] <Amaranth> also, are you going to wait until after beta to update to git?
[18:39] <seb128> mvo: no, I'm not but I'm happy to fix it, pitti does update this package usually
[18:42] <lapo> uhm, it's just me or there are problems with compiz+nvidia and the notification area?
[18:43] <mvo> seb128: I'm happy to do it, but I need to leave now for the evening so I can do it either tonight (late) or monday
[18:43] <Amaranth> lapo: just you?
[18:43] <seb128> mvo: ok, I can do it if you want
[18:43] <Amaranth> please don't file a bug, i'll never get below 200 :P
[18:43] <lapo> eheh, ok, it's a known bug :-)
[18:43] <Amaranth> seb128: also, i know how you feel about libwnck, calc sends me all OOo bugs that he can't reproduce when the reporter is using compiz :P
[18:44] <seb128> Amaranth: ;-)
[18:44] <Amaranth> one of them got upstreamed twice
[18:44] <seb128> I used to do that too with libwnck bugs
[18:44] <seb128> but you kicked all those back :-p
[18:44] <Amaranth> i sent the bug to compiz-fusion and they send it to OOo
[18:45] <Amaranth> OOo is really cool, it requests 200x200 windows for dialogs much larger than 200x200
[18:45] <Amaranth> and requests that they are not resizeable
[18:47] <mvo> seb128: yeah, go ahead if you have time for it, if not, no problem, just let me know
[18:49] <seb128> mvo: ok, I'll go for dinner soon but might look at it after that
[18:50] <mvo> thanks
[18:52] <pedro_> Amaranth: 200 ;-)
[19:03] <Amaranth> pedro_: yay
[19:27] <LaserJock> pedro_: ping
[19:35] <pedro_> Amaranth: just below the 200 now woohoo
[19:35] <pedro_> LaserJock: hello
[19:35] <Amaranth> yep :)
[19:35]  * Amaranth hugs pedro_
[19:35]  * pedro_ hugs Amaranth back
[19:35] <Amaranth> now it can't go back up, don't let anyone file new bugs
[19:35] <LaserJock> pedro_: I just wondered why you marked bug #183060 as Invalid
[19:35] <ubotu> Launchpad bug 183060 in gnumeric "gnumeric crashed with SIGSEGV" [Medium,Invalid] https://launchpad.net/bugs/183060
[19:35] <pedro_> hahaha
[19:35] <pedro_> LaserJock: looking
[19:36] <pedro_> i've doing a lot of clean up lately
[19:36] <LaserJock> pedro_: I would think the LP Janitor would take care of it after 60 days
[19:37] <pedro_> LaserJock: more than a month in a incomplete state without a response from the reporter
[19:37] <LaserJock> and that's enough to get it marked "Invalid"?
[19:37] <pedro_> as i said i was doing some clean up lately, so that's why
[19:37] <pedro_> yes it is
[19:37] <LaserJock> ok then
[19:38] <Amaranth> i'm trying to make compiz bugs look less depressing
[19:38] <Amaranth> so i'm not waiting 60 days for the janitor :P
[19:38] <LaserJock> alright, so we make it look like we dont' have bugs by just closing them?
[19:39] <Amaranth> 30 days without a response for a bug i can't reproduce means no one is ever going to help me figure out how to fix it
[19:39] <Amaranth> with compiz a driver point release or new compiz snapshot can cause and/or fix a million different problems
[19:40] <pochu> does the janitor already close bugs? or is still disabled?
[19:40] <Amaranth> it claims it will
[19:40] <Amaranth> i haven't seen it do so
[19:40] <pedro_> haven't seen the janitor lately either
[19:40] <LaserJock> well, in this case though, somebody just asked for a backtrace
[19:41] <LaserJock> but shouldn't apport be providing those?
[19:41] <Amaranth> ah, sometimes apport does a bad job
[19:41] <Amaranth> or the coredump is bad
[19:41] <LaserJock> right, so we're just gonna ignore it?
[19:42] <Amaranth> if you can't get a good backtrace how can you fix it?
[19:42] <LaserJock> and as far as I can see nobody has *not* confirmed the bug
[19:43] <LaserJock> that's of course what needs to be worked on
[19:43] <LaserJock> but marking it "Invalid" basically is saying "We're not gonna look at it"
[19:45] <Amaranth> Right, it means "we're ignoring this unless you give us more info"
[19:46] <LaserJock> and why should we require the reporter to necessarily do that?
[19:46] <Amaranth> If it just sits there open someone might think they don't have to do anything
[19:46] <Amaranth> Because if they want the bug fixed they need to give the info needed to fix it
[19:46] <LaserJock> but we're not gonna do anything in the mean time?
[19:46] <LaserJock> I don't see anybody trying to confirm or not confirm the bug
[19:47] <LaserJock> it's just "give us a backtrace or we close the bug"
[19:48] <Amaranth> So someone should explicitly say "I cannot reproduce this" before starting the countdown to closing it?
[19:48] <LaserJock> I think so yes
[19:48] <Amaranth> *shrug*
[19:48] <LaserJock> and ask if other people have experience it
[19:48] <Amaranth> I know in compiz I try my best to reproduce the bugs whether I mention that or not
[19:49] <LaserJock> I guess the theory is if it's really a problem we'll get dups
[19:50] <Amaranth> that too