[00:05] <rickspencer3> hi robert_ancell, hi TheMuso
[00:06] <TheMuso> Hey rickspencer3.
[00:09] <robert_ancell> hey rickspencer3, TheMuso
[00:15] <TheMuso> Hey robert_ancell/.
[00:15] <robert_ancell> TheMuso, hey, pulse was really bad yesterday, i'll see it it still plays up today
[00:18] <TheMuso> robert_ancell: hrm ok
[00:19] <robert_ancell> TheMuso, it locks up after a number of sound effects (e.g. alt-tab, tab in terminal). 100% CPU then kill -9 makes all the sounds be played at once
[00:19] <robert_ancell> TheMuso, note I was using metacity yesterday and I'm using compiz today, it might be something with that
[00:19] <TheMuso> robert_ancell: hrm interesting.
[00:19] <TheMuso> robert_ancell: I wonder whether thats libcanberra.
[00:20] <robert_ancell> And the GUI was locking up while this was occurring, i.e. I couldn't switch to different applications with alt-tab (I had to go to text terminal to kill).  It could be metacity+pulse?
[00:21] <TheMuso> right
[00:25] <TheMuso> robert_ancell: Actually, I am about to upload the final 0.9.16 release of pulseaudio. See if that helps when it comes through.
[00:25] <robert_ancell> cool
[00:33] <rickspencer3> TheMuso, hi, I just got of the phone with Stormy from Gnome foundation
[00:34] <rickspencer3> she wants to set up a little powwow to discuss how gnome, ubuntu, etc... can work more effectively on accessibility
[00:35] <TheMuso> rickspencer3: You have my undevided attention, continue. :)
[00:35] <rickspencer3> TheMuso, the next step is for us all to meet in an irc room and go over the current situation
[00:36] <TheMuso> rickspencer3: Right.
[00:36] <rickspencer3> I think mozilla, gnome, us, etc...
[00:36] <TheMuso> ok
[00:36] <rickspencer3> and then discuss potential ways of working better together
[00:36] <TheMuso> right
[00:36] <rickspencer3> I think there are probably technology issues, and also workflow issues
[00:36] <TheMuso> Yeah I'd agree with that.
[00:37] <rickspencer3> I'm betting that different parts of the echo system have different perspectives about what can be improved, so a meeting of the minds would be useful, imo
[00:37] <TheMuso> Agreed.
[00:37] <rickspencer3> not just the echo system, but the ecosystem too ;)
[00:37] <rickspencer3> TheMuso, ok, I'll let you know when I hear
[00:37] <TheMuso> heh
[00:37] <rickspencer3> eeejay, ^^
[00:38] <rickspencer3> I mentioned both TheMuso and eeejay as people who should be there
[00:38] <TheMuso> Ok cool.
[00:38]  * rickspencer3 reboots after dist-upgrade
[01:42] <robert_ancell> TheMuso, is there a way I can kick the buildservers to try again?  yelp failed to build but I think it was a problem with xulrunner which has been recently updated
[01:43] <TheMuso> robert_ancell: I can retry it for you if you would like.
[01:43] <TheMuso> robert_ancell: Only those with upload rights can retry builds.
[01:43] <robert_ancell> TheMuso, ok, thanks
[01:50] <TheMuso> robert_ancell: Queued for retry on all arches that failed to build.
[01:50] <robert_ancell> TheMuso, thanks
[01:51] <TheMuso> np
[01:58] <TheMuso> hrm lpia failed.
[02:00] <robert_ancell> TheMuso, yeah, this is something broken...
[02:01] <robert_ancell> It's something to do with xulrunner, asac knows about that I think
[02:01] <TheMuso> ok
[02:04] <asac> robert_ancell: the previous version worked?
[02:04] <asac> you dont talk about patches we had. did all patches still apply cleanly?
[02:04] <asac> (in changelog that is)
[02:04] <robert_ancell> asac, it built locally and I guess the previous version worked
[02:05] <robert_ancell> asac, all patches applied as before
[02:05] <asac> how much i dislike huge po diffs ;)
[02:05] <asac> in the debdiffs
[02:06] <asac> this reminds me ... what are the exact issues with the webkit branch ;)?
[02:06] <asac> (of yelp)
[02:07] <asac> is it really something we cannot ship ? ;)
[02:07] <robert_ancell> I don't know.  I expect we can ship now as webkit is on the cd
[02:09] <asac> well. upstream webkit branch was dropped from the gnome release seb told me ;)
[02:09] <asac> just wondered if its really too bad for us too
[02:10] <asac> its odd that it built locally for oyu
[02:10] <TheMuso> robert_ancell: What mirror do you pull from? Its possible it built against an older version that your mirror has.
[02:11] <robert_ancell> TheMuso, I use archive.ubuntu.com
[02:11] <asac> i think that could be really a xulrunner regression
[02:11] <asac> at best file a bug against xulrunner-1.9.1 and yelp saying "yelp fails to build because it cannot find nspr headers" ;)
[02:12] <asac> *sigh* ;)
[02:12] <robert_ancell> asac, ok
[02:12] <asac> assign the bug to me please
[02:13] <asac> link the build log in the bug
[02:13] <asac> thx
[02:15] <robert_ancell> bug 427638
[02:24] <asac> thx
[03:43] <ccheney> gar if you quit firefox after upgrading it does not save tabs
[03:43] <ccheney> you have to kill it to keep the tabs apparently
[03:43]  * ccheney lost probably 50+ tabs he was using :-\
[03:45] <TheMuso> ouch
[03:46] <Amaranth> ccheney: there is a setting for that
[03:47] <Amaranth> it probably asked you at some point and whatever you answered it stuck with so you have to go into the preferences and start the startup option
[03:47] <ccheney> oh.. no it normally works right, it did not because i just upgraded
[03:48] <ccheney> after it restarted and killed all my tabs when i tried to quit again it asked if i wanted to save the tabs
[03:48] <ccheney> but when i quit after upgrading the first time it just killed all my tabs
[03:49] <ccheney> er i mean the first time i quit directly after upgrading is when it killed my tabs
[03:49] <ccheney> so its some bug of when you quit after having upgraded while firefox is still running that it kills your tabs
[03:49] <ccheney> asac: ping ^  are you aware of that issue?
[03:50] <ccheney> when i quit the first time (when it lost the tabs) i noticed it did not ask me if i wanted to save tabs, it just didn't save them and lost them all
[03:50] <asac> ccheney: did firefox offer you to "restart" i the firefox window?
[03:50] <ccheney> i don't recall seeing it ask no, the popup said i needed to restart (i am still running jaunty fwiw)
[03:51] <asac> yes. the popup is not what i mean
[03:51] <asac> ok
[03:51] <ccheney> had problems with my system and with vm on karmic so downgraded back to jaunty
[03:51] <asac> ccheney: ubufox installed? firefox-3.0?
[03:51] <asac> short answer is: yes, upgrading still can cause arbitrary bad things
[03:51] <ccheney> ubufox 0.7-0ubuntu1 and firefox 3.0 yea
[03:51] <asac> with running firefox
[03:51] <asac> ok
[03:51] <asac> yes. thats known bug
[03:52] <ccheney> ok
[03:52] <asac> well. its known that everything can happen.
[03:52] <ccheney> heh
[03:52] <asac> we try to display the restart asap ... and if you get it its likely that it works
[03:52]  * ccheney needs to remember to kill firefox instead that works
[03:52] <asac> but if not you are doomed ;)
[03:52] <asac> yes
[06:11] <robert_ancell> asac, are you doing something on gnome-bluetooth?
[07:12] <didrocks> good morning robert_ancell
[07:13] <robert_ancell> didrocks, hey
[07:33] <rugby471> didrocks: hello
[07:33] <didrocks> hey rugby471
[07:33] <rugby471> didrocks: were you the one who was speaking about using the gnome accessibility layer for the where is it bnutton in software-store
[07:33] <rugby471> bnutton > button
[07:34] <didrocks> rugby471: exactly
[07:34] <rugby471> right
[07:34] <rugby471> was that going to be in karmic+1?
[07:34] <didrocks> yes, because we have first to enable gnome accessibility layer by default
[07:34] <didrocks> and it's too late to do that in karmic
[07:35] <rugby471> as I was thinking of working on a simple 'where is it' function for karmic & those you don't have the gnome accessibility layer on
[07:35] <rugby471> sure
[07:35] <rugby471> ok then I shall continue with it :-)
[07:35] <didrocks> rugby471: I'm working on the workaround too
[07:35] <rugby471> didrocks: oh
[07:35] <didrocks> rugby471: so, let me a week for finishing shaping it, please :)
[07:35] <rugby471> sure
[07:35] <rugby471> I shall stop work on it then as you are probably ahead of me :-)
[07:36] <rugby471> didrocks: what does it involve?
[07:36] <didrocks> rugby471: calling some lib from gnome-menu
[07:36] <rugby471> ah okay
[07:36] <didrocks> rugby471: you were thinking about what?
[07:36] <rugby471> didrocks: will that be in karmic?
[07:37] <rugby471> didrocks: sjust a simple image that goes Applications > Graphics > GIMP etc.
[07:37] <didrocks> rugby471: yes
[07:37] <didrocks> rugby471: well, it's best to calculate it
[07:37] <rugby471> is that what your code does?
[07:37] <didrocks> rugby471: because when you have many items, you have new subcategories
[07:37] <rugby471> yeah
[07:37] <didrocks> yes
[07:37] <rugby471> didrocks: cool well I shall leave you to finish that then :-)
[07:38] <rugby471> didrocks: see ya
[08:21] <robert_ancell> pitti, can you look at sponsoring bug 423450? The DX team want this functionality.
[09:03] <chrisccoulson> hey seb128
[09:03] <seb128> good morning there
[09:03] <seb128> hey chrisccoulson
[09:03] <chrisccoulson> how are you today?
[09:04] <seb128> good!
[09:04] <seb128> you?
[09:04] <didrocks> hey seb128 :)
[09:05] <chrisccoulson> yeah, i'm good too. quite tired though!
[09:05] <seb128> hum, why does apport refuses to report assertions when it doesn't success to get the error in karmic?
[09:05] <seb128> hum, why does apport refuses to report assertions when it doesn't success to get the error in karmic?
[09:05] <seb128> ups
[09:05] <seb128> lut didrocks
[09:05] <seb128> chrisccoulson, same here, went to bed after 2am this night
[09:06] <chrisccoulson> seb128 - you'll be needing to catch up on sleep tomorrow then ;)
[09:06] <seb128> I slept until 8am so that's ok but yes extra sleep on saturday ;-)
[09:07] <chrisccoulson> i slept until nearly 8am too, which is really bad - i'm meant to be in work at 8am;)
[09:07]  * seb128 is sort of disapointed by karmic boot speed
[09:07] <seb128> all the charts sent are somewhat around 35 to 45 seconds to gdm load
[09:07]  * Laney is disappointed that ubuntu-boot broke his boot ;)
[09:08] <seb128> I got an error at first reboot about disk checks
[09:08] <seb128> then next reboot take ages without feedback, I'm wondering if it was fscking
[09:08] <seb128> and now it's working
[09:08] <seb128> weird thing
[09:10] <mvo> hm, I think its time for a compiz update - before the weekend is the perfect time ;)
[09:10] <pitti> Good morning
[09:10]  * mac_v gdm -> desktop 45 secs :( but boot -> gdm 30 secs \o/
[09:10] <pitti> sorry, I'm late today, we were plucking pplums
[09:11] <didrocks> mvo: releasing on Friday is always the rule :)
[09:11] <pitti> didrocks: make quickly depend on devscripts? p-d-e doesn't need devscripts, but if you need it, you ought to depend on it
[09:11] <mvo> pitti: sounds fun - to make jam out of it?
[09:11] <didrocks> pitti: python-mkdebian from p-d-e uses debchange which is in devscripts
[09:11] <pitti> mvo: that, and "einkochen", and just eating some as they are
[09:12] <pitti> didrocks: ah, that, right
[09:12] <didrocks> (and hi too ;))
[09:12] <pitti> didrocks: bonjour :)
[09:12] <didrocks> pitti: so, do you want to make p-d-e recommends devscripts or do I need to change it into quickly?
[09:13] <mvo> mpt: good news, the pathbar code is now in a branch, but its lacking little features like support for click events :) but nzmm is great, the started to work on it already (and I pushed some stub code for the events as well)
[09:15] <pitti> didrocks: sounds like it should be in both; suggests for p-d-e, and depends in quickly
[09:15] <pitti> didrocks: for most projects you don't need devscripts to use p-d-e (as a build system)
[09:15] <didrocks> pitti: even if quickly doesn't use it directly? I need to document that somewhere so :)
[09:16] <seb128> hey pitti
[09:16] <pitti> didrocks: oh, I thought you'd actually use debuild in it
[09:16] <pitti> bonjour seb128
[09:16] <didrocks> pitti: no, I dropped debuild in 0.2 and use directly dpkg-buildpackage
[09:16] <didrocks> so, I have a dep on dpkg-dev
[09:16] <pitti> ah
[09:16] <pitti> so, no lintian love :)
[09:17] <pitti> didrocks: so, I'm happy to change it to say "you need to install the devscripts package for this to work"
[09:17] <didrocks> well, rickspencer3 was afraid by the whole bunch of dep we brought with quickly, and most of them came from devscripts initially :)
[09:17] <pitti> didrocks: but devscripts is a heavy dependency, which I wouldn't like to inflict as a buil-dep of everything which uses p-d-e as a build system
[09:18] <didrocks> pitti: yeah, I understand, but the message can be good. I can do it if you wish (I'm already fixing a bug in python-mkdebian)
[09:18] <pitti> well, but quickly isn't a build-dep or a binary dep of packages
[09:18] <didrocks> yes, I think we will have to bring the whole devscript things back
[09:19] <didrocks> (in quickly)
[09:19] <pitti> didrocks: if you are worried about that, it doesn't matter whether p-d-e or quickly itself pulls it in
[09:19] <seb128> is somebody else having indicator applet crashes when starting and closing evo?
[09:20] <didrocks> pitti: yes of course. It was more on the "logical" way to justify adding devscripts dep on ubuntu-template, even if not directly use (a comment in changelog can precise that and in debian/README)
[09:22] <seb128> what the?
[09:24]  * seb128 looks at asac
[09:25] <seb128> asac, the firefox update in karmic broke greasemonkey
[09:30] <pitti> hm, and makes yelp ftbfs
[09:37] <seb128> pitti, do you know why apport refuses to open bugs about insertions in karmic? it says it can't report bug if the assertion error is not available
[09:38] <pitti> seb128: that's still because back then you said that SIGABRT crashes aren't useful because you are missing the message?
[09:38] <pitti> seb128: so for now I only allowed those which use assert() and have a message
[09:38] <seb128> pitti, where does it look for the error?
[09:39] <pitti> seb128: if you do assert(), our glibc now stores the message in a global variable (__abort_msg), and add_gdb_info() peeks it out from there
[09:39] <pitti> so perhaps g_assert() doesn't use assert() but its own implementation
[09:39] <seb128> pitti, how would I debug that not working there?
[09:40] <pitti> seb128: "there"?
[09:40] <seb128> pitti, the message indicator applet assert every time I close evolution
[09:40] <seb128> but apport keeps refusing to report the bug
[09:40] <seb128> the stacktrace looks useful though, that's frustrating
[09:40] <pitti> seb128: well, I don't mind enabling it again
[09:40] <pitti> I disabled it on your request :)
[09:41] <seb128> well, the point is that it should get the assert error
[09:41] <seb128> I would like to debug why that fails
[09:41] <pitti> ah
[09:41] <pitti> seb128: does it use g_assert*?
[09:41] <seb128> yes
[09:41]  * pitti gets glib source
[09:41] <mpt> mvo, neat
[09:42] <seb128> pitti, http://paste.ubuntu.com/269017/
[09:43] <seb128> pitti, see #3
[09:43]  * pitti looks in ./glib/gtestutils.
[09:43] <pitti> c
[09:43] <pitti> ah, indeed
[09:43] <pitti>   g_printerr ("**\n%s\n", s);
[09:44] <pitti>   abort();
[09:44] <pitti> so this could either say:
[09:44] <pitti> ah, no
[09:44] <pitti> it could just set __abort_msg perhaps
[09:45] <seb128> pitti, should I open a bug and assign it to you? ;-)
[09:45] <pitti> sure
[09:45] <seb128> pitti, or quick way would be to not filter out those without message for now
[09:45] <seb128> and see how it goes
[09:45] <seb128> could we try that for the weekend?
[09:45] <pitti> seb128: if you want to do it locally, search for "Assert" in /usr/share/pyshared/apport/ui.py and rip out the check
[09:46] <pitti> seb128: no problem
[09:46] <seb128> thanks
[09:46] <pitti> seb128: I could also just fix glib :)
[09:46] <seb128> want a bug?
[09:46] <pitti> seb128: I can just do it now
[09:46] <seb128> or do you want to do it now?
[09:46]  * seb128 hugs pitti
[09:46] <seb128> thanks!
[09:46] <pitti> I was about to do some sponsoring, but I can do that later
[09:46] <pitti> ah, I'll do the sponsoring while it builds
[09:47] <seb128> pitti, I'm on indicator-session
[09:47] <pitti> seb128: I still think it's good to suppress that in general; with assertions, a lot of stacktracetop will be identical
[09:47] <seb128> for sponsoring
[09:47] <seb128> just fyi
[09:47] <pitti> and without a message, it's hard to do auto-dupes, and see what's going on
[09:47] <seb128> right
[09:47] <pitti> seb128: I'll sponsor bug 385850
[09:48] <seb128> pitti, didn't you do that yesterday?
[09:48] <pitti> seb128: yes, xscreensaver, but not yet the gnome-screensaver change
[09:48] <pitti> (just a recommends drop)
[09:48] <seb128> ah ok
[09:48] <seb128> thanks
[09:48] <pitti> seb128: I also have bug 423450 on my list
[09:48] <pitti> but that needs some FFE/checking
[09:50]  * pitti does sponsoring one hour every day now, *sigh*
[09:51] <seb128> don't tell me
[09:51] <seb128> I spent most of my evening on sponsoring yesterday
[09:51] <seb128> thanks to the weekly dxteam tarball day ;-)
[09:52] <pitti> seb128: we are this --><-- close to getting package set upload rights
[09:52] <pitti> once we get this, Robert can upload directly
[09:52] <seb128> \o/
[09:52] <pitti> and Ken as well
[09:52] <seb128> and chrisccoulson
[09:52] <seb128> and didrocks
[09:52] <pitti> so for easy updates, they shoudl just do it
[09:52] <pitti> indeed
[09:52] <seb128> that will rock ;-)
[09:53] <pitti> and just use sponsoring bugs if they aren't sure and have complex updates, like the gnome-games split
[09:59] <didrocks> pitti: can you have a look at my proposed merge 11593, please? this is to fix bug #421689
[09:59] <didrocks> (ok, the bot doesn't take merge number: https://code.edge.launchpad.net/~didrocks/python-distutils-extra/handle-submodules/+merge/11593)
[10:12] <chrisccoulson> seb128 - it is a mistake that totem-plugins still depends on python-gdata isn't it?
[10:12] <seb128> chrisccoulson, yes, I will fix that when I do the upload to use libgdata
[10:12] <seb128> chrisccoulson, or do you want to work on the update?
[10:13] <chrisccoulson> seb128 - i can work on that.
[10:13] <seb128> thanks
[10:13] <seb128> hum, hate python
[10:13] <seb128> so totem crashes in python code at closing
[10:14] <seb128> but valgrind lists a zillion errors every time there is python involved
[10:14] <seb128> I can't figure which ones are real issues
[10:14] <chrisccoulson> yeah, i've tried debugging python issues before, but i don't understand it enough ;)
[10:19] <seb128> cassidy, hey
[10:19] <cassidy> seb128: morning
[10:19] <seb128> cassidy, do we want the new telepathy-farsight or telepathy-salut?
[10:19]  * seb128 is doing some syncs
[10:19] <cassidy> we definitely want the latest tp-fs
[10:20] <cassidy> as said yesterday, salut is cool to have but is more risky
[10:20] <seb128> does it bring anything user visible for karmic?
[10:20] <cassidy> oth, if critical bugs are found, they'll be fixed rsn
[10:20] <seb128> what about papyon 0.4.2?
[10:20] <cassidy> debug support in Empathy, tube new API
[10:21] <seb128> debug support?
[10:21] <cassidy> empathy - help - debug
[10:21] <cassidy> very useful to get logs
[10:21] <cassidy> you'll need latest papyon if you want to ship the new butterfly (hopefully released today) supporting audio/video
[10:22] <seb128> does it break anything or can we just sync it?
[10:22] <cassidy> it shouldn't, that's mostly new code not used in current butterfly
[10:23] <cassidy> it also have some nice fixes
[10:23] <cassidy> which would be cool to have
[10:23] <cassidy> see http://lists.freedesktop.org/archives/telepathy/2009-September/003821.html
[10:23] <seb128> ok, it's still 1.5 month before karmic so we have time to fix issues
[10:23] <cassidy> so yeah I'd vote +1 for papyon
[10:23] <seb128> seems you recommend getting new telepathy-salut, papyon, butterfly?
[10:24] <cassidy> butterfly isn't released yet. not sure for this one. Lot of users will be excited to have audio/video support but it hasn't been tested extensively yet
[10:24] <asac> seb128: dont know about greasemonkey.
[10:24] <asac> yelp i have a bug
[10:24] <seb128> asac, what info would be useful in a bug?
[10:24] <seb128> asac, is it working for you?
[10:24] <asac> i dont use greasemonkey ;)
[10:25] <asac> what symptoms? just doesnt work at all?
[10:25] <seb128> cassidy, ok thanks, will try papyon locally
[10:25] <seb128> asac, I use stock replies on launchpad and I don't get those listed today
[10:26] <seb128> asac, the scripts list is empty
[10:26] <seb128> and it was working yesterday
[10:27] <seb128> ie something makes the script I'm using to have been deleted or not listed
[10:27] <asac> hmm
[10:27] <asac> where is that script?
[10:28] <asac> in ~seb128 on rookery?
[10:28] <seb128> asac, http://people.canonical.com/~seb128/bugtriage.user.js
[10:29] <seb128> I don't get the "this is a greasemonkey script do you want to install it" banner either
[10:29] <asac> hmm. works here a bit
[10:29] <asac> [Use Apport] [Needs Backtrace] [Needs Details] [Needs Valg...
[10:29] <asac> those links i have on bugs
[10:29] <asac> seb128: maybe langpacks?
[10:29] <seb128> ok
[10:29] <asac> are you using french?
[10:29] <seb128> I'm using a french locale
[10:29] <seb128> but menus are in english
[10:29] <seb128> so I guess there is no langpacks installed
[10:29] <asac> yeah
[10:29] <asac> hmm
[10:31] <asac> any error on tools -> error console ?
[10:32] <asac> is there a greasemonkey menu entry at all for you? in tools ?
[10:32] <seb128> asac, http://people.canonical.com/~seb128/xul.png
[10:33] <seb128> I've a Tools, Greasemonkey, Gérer les scripts
[10:33] <seb128> so some french translations there!
[10:33] <seb128> the dialog lists no script though
[10:33] <seb128> where is was listing stock reply before the update
[10:34] <seb128> LC_ALL=C firefox -> no difference
[10:34] <seb128> hey njpatel
[10:37] <asac> seb128: can you try with fresh profile (like stop ffox ... move .mozilla dir somewhere else ... start)?
[10:38] <asac> a bit scary error that you see there.
[10:38] <asac> i mean: feels like its the cause.
[10:43] <seb128> asac, it's weird, greasemonkey is not listed in the addon dialog with a guest session
[10:47] <asac> hmm
[10:47] <pitti> argh, I'm a moron
[10:47] <seb128> pitti, ?
[10:48] <pitti> seb128: I bited into my table, wondering why my glib assert fix doesn't work, until I found out that I just forgot to rm the old core file before testing the new version
[10:48] <pitti> seb128: nevermind; I just wasted 20 minutes on something stupid
[10:48] <asac> seb128: i assume you use the greasemonkey package?
[10:49] <seb128> asac, yes
[10:49] <pitti> seb128: collecting the g_assert* message works now
[10:49]  * seb128 hugs pitti
[10:49] <asac> seb128: /usr/share/greasemonkey/install.rdf
[10:49] <seb128> you rock!
[10:49] <asac> can you paste that file?
[10:49] <asac> its odd. the package here is quite outdated
[10:49] <asac> i mean wrt to install.rdf
[10:50] <asac> i had greasemonkey installed through AMO as it seems
[10:51] <seb128> asac, http://paste.ubuntu.com/269048/
[10:51] <seb128> asac, I added the initial # on pastebin
[10:51] <seb128> it refuses it with a "    * PHP and other Web scripts are not allowed" otherwise
[10:51] <asac> wh do you have 3.5.* and i have 3.1b2?
[10:51] <seb128> security thing?
[10:51] <asac> let me reinstall that package
[10:51] <seb128> $ dlocate /usr/share/greasemonkey/install.rdf
[10:51] <seb128> greasemonkey: /usr/share/greasemonkey/install.rdf
[10:52] <seb128> ii  greasemonkey                               0.8.20090123.1-0ubuntu2                          firefox extension that enables customization
[10:52] <seb128>  *** 0.8.20090123.1-0ubuntu2 0
[10:52] <seb128>         500 http://archive.ubuntu.com karmic/universe Packages
[10:52] <seb128>         100 /var/lib/dpkg/status
[10:52] <seb128> asac, you might have told me to change the number when it was broken some weeks ago
[10:53] <seb128> I think it already broke when I installed firefox 3.
[10:53] <seb128> 3.5
[10:53] <seb128> you told me to tweak the numbers
[10:53] <seb128> which worked until today
[10:53] <seb128> asac, ^
[10:54] <asac> ah
[10:54] <asac> ok
[10:54] <asac> and installing the xpi caused issues for you?
[10:54] <seb128> what xpi?
[10:55] <asac> seb128: go to tools -> addons -> get addons
[10:55] <asac> search for greasemonkey
[10:55] <asac> and "add to firefox ..."
[10:55] <asac> you wont see it on first result page if your package is installed
[10:55] <asac> because ffox thinks you already have it
[10:55] <asac> https://addons.mozilla.org/en-US/firefox/downloads/latest/748/addon-748-latest.xpi
[10:55] <asac> just click on that ;)
[10:55] <seb128> "No matching add-ons"
[10:56] <seb128> I guess I've to remove the distro one to use the xpi?
[10:56] <asac> seb128: no. the profile one will win
[10:56] <asac> thats why i didnt see that the distro one was disabled :)
[10:56] <asac> i am testing that now
[10:56] <asac> too
[10:57] <seb128> restart firefox is broken
[10:57] <seb128> I clicked on it twice now
[10:57] <seb128> it does restart firefox
[10:57] <asac> seb128: are you sure you properly upgraded your ffox after the upgrade?
[10:57] <seb128> but I still get the yellow banner "Restart firefox to complete your changes"
[10:57] <seb128> in the addon dialog
[10:57] <asac> oh
[10:58] <seb128> the greasemonkey one is marked "This add-on will be updated when Firefox is restarted"
[10:58] <seb128> should I close and restart the old good way?
[10:58] <seb128> or do you want to debug the "Restart Firefox" not doing its job?
[10:58] <asac> seb128: close firefox ... fix he version number in install.rdf to be 3.1 (so its disabled)
[10:59] <seb128> hum
[10:59] <seb128> don't ctrl-d in xchat ;-)
[11:00] <seb128> asac, the you need to restart doesn't go away
[11:00] <seb128> I did close firefox
[11:00] <seb128> no firefox process in ps
[11:01] <seb128> but the addon is still marked as waiting on restart
[11:01] <asac> yeah
[11:01] <asac> ok remove the distro package
[11:01] <asac> maybe that broke too much
[11:01] <asac> to make the install work
[11:01] <seb128> still broken
[11:02] <seb128> let's cancel this one and try again
[11:02] <asac> cancel?
[11:02] <seb128> the greasemonkey list in the add-ons dialog is waiting on restart
[11:02] <seb128> and it has a cancel button
[11:03] <asac> ok
[11:03] <asac> so in your profile
[11:03] <asac> there is extensions.log
[11:03] <asac> please paste that
[11:03] <seb128> asac, http://people.canonical.com/~seb128/xul.png
[11:03] <seb128> no wait to get out of that
[11:03] <seb128> ok
[11:05] <seb128> asac, http://people.canonical.com/~seb128/extensions.log
[11:05] <asac> looks bad
[11:06] <asac> ok... so package is removed you said?
[11:06] <seb128> yes
[11:08] <asac> backup your profile ... then remove everythign that is extensions* in your profile (
[11:08] <asac> extensions/       extensions.cache  extensions.ini    extensions.rdf  extensions.log
[11:09] <bigon> seb128: could you approuve empathy that is in the new queue?
[11:09] <seb128> bigon, will do
[11:09] <bigon> thx
[11:10] <seb128> asac, that fixes it
[11:11] <asac> ok
[11:11] <seb128> asac, and stock replies are listed again
[11:11] <asac> please keep the old profile so we can look at it later
[11:11] <seb128> ok
[11:11] <seb128> I didn't have to reinstall those
[11:11] <seb128> just to install greasemonkey
[11:11] <asac> i will take care that the greasemonkey package will get updated
[11:11] <asac> which caused your issue to start
[11:12] <seb128> the dialog said that greasemonkey is not compatible with 3.5.3 before restart but it works after restart
[11:12] <asac> though its strange that it just started now
[11:12] <asac> in 3.5.3
[11:12] <asac> hmm
[11:12] <asac> that feels strange
[11:14] <seb128> asac, http://people.canonical.com/~seb128/xul.png
[11:14]  * asac installs again
[11:14] <seb128> I get that before restart
[11:15] <seb128> but as said it works after restart
[11:15] <asac> you are right
[11:15] <asac> oh no ;)
[11:15] <asac> i looked at your screenshow
[11:15] <asac> hehe
[11:18] <seb128> asac, want me to open a bug on launchpad for tracking?
[11:18] <asac> seb128: can you reproduce it? e.g. uninstall greasmonkey ... install the .xpi again?
[11:18] <asac> if so ... definitly
[11:18] <asac> but the version you see there
[11:19] <asac> is the packaged version
[11:19] <asac> so maybe its just left over from the package?
[11:19] <seb128> asac, things are working for me now so I don't really care if you think that's a corner issue
[11:19] <seb128> I don't want to waste your time on small details
[11:19] <seb128> thanks for the help there!
[11:19] <asac> seb128: oh
[11:19]  * seb128 can triage bugs again
[11:19] <asac> now i see it too ;)
[11:19] <seb128> ah ;-)
[11:19] <seb128> yes, I get it every time
[11:19] <asac> i seems if you wait long enough that "not compatible comes up"
[11:20] <asac> ok please file a bug
[11:20] <asac> assign to me
[11:20] <asac> if you have a second, also file a bug that greasemonkey package in the archive needs a bump as its currently not compatible with 3.5
[11:20] <seb128> asac, about what issue? ;-) an where?
[11:20] <asac> seb128: about the "tells me its incompatible after installing the xpi" -> firefox-3.5
[11:21] <asac> about "greasemonkey package has 3.1b2 as maxVersion" -> greasemonkey
[11:22] <asac> and maybe a third bug about the "always wants to restart"
[11:22] <asac> thogh i am not so confident we can reproduce that easily
[11:22] <asac> that definitly was triggerd by sequence of gloomy events for you ;)
[11:25] <pitti> didrocks: looking
[11:27] <seb128> asac, bug #427789
[11:28] <asac> thx
[11:28] <seb128> asac, bug #427790
[11:29] <seb128> asac, I will not open a bug about the other issue, I feel it's too much a corner case to waste debugging on it
[11:29] <seb128> I will open one if I get steps to trigger it though
[11:29] <asac> thanks a bunch
[11:29] <asac> sorry for the inconvenience ,)
[11:29] <seb128> np, thanks for the help debugging the issue ;-)
[11:29] <asac> in the end my fault telling you to bump maxVersion ;)
[11:30] <asac> but its odd that it really breaks in a security update
[11:30] <seb128> hehe
[11:32] <pitti> didrocks: looks fine, I just fixed a few typos
[11:41] <pitti> seb128: you have an easy way of triggering the assertion? want to test my glib .debs, re-trigger it, and see if apport catches it?
[11:42] <pitti> I just used a simple 3-line test.c with g_assert(5<4) and gdb
[11:42] <seb128> pitti, for me it's "start evolution and close it"
[11:42]  * pitti tests
[11:43] <pitti> seb128: works here..
[11:44] <seb128> you probably need email accounts there
[11:44] <seb128> I can test for your there
[11:44] <seb128> just give me the debdiff or a i386 deb
[11:44] <pitti> I just have a local maildir
[11:44] <pitti> seb128: debs almost built, will give you these (will be faster)
[11:45] <seb128> pitti, thanks
[11:45]  * seb128 ready to try ;-)
[11:45] <pitti> seb128: I'd like to see a full end-to-end test before I throw the patch at upstream ;)
[11:46] <seb128> pitti, you can try installing gwibber too and start it from the message indicator and close it
[11:47] <seb128> see if that crashes the applet for you too
[11:47] <pitti> seb128: http://people.canonical.com/~pitti/tmp/glib-assert/
[11:48]  * pitti tries
[11:51] <pitti> seb128: remember to start apport with APPORT_REPORT_THIRDPARTY ubuntu-bug /var/crash/..., to avoid the non-native package check (thus don't start it from update-notifier)
[11:57] <seb128> gnagnagna
[11:57] <seb128> hate apport sometime
[11:57] <seb128> "libpulse-mainloop-glib0, libpulse" outdated
[11:57] <seb128> and APPORT_IGNORE_OBSOLETE_PACKAGES=1 doesn't work
[11:58] <seb128> I have to upgrade before testing
[11:59] <seb128> I will open a bug about APPORT_IGNORE_OBSOLETE_PACKAGES=1 not working after lunch
[11:59] <seb128> pitti, glib update works
[11:59] <pitti> seb128: \o/
[12:00] <seb128> Title: indicator-applet assert failure: ERROR:dbus-gproxy.c:2274:dbus_g_proxy_end_call_internal: assertion failed: (reply != NULL)
[12:00] <pitti> seb128: I'll send the patch to upstream then, and upload
[12:00] <seb128> thanks!
[12:00] <seb128> lunch now
[12:00] <seb128> bbl
[12:00] <pitti> seb128: I spent 5 minutes on the patch, and 30 on getting the autoconfiscation right ..
[12:00] <pitti> seb128: enjoy!
[12:08] <asac> pitti: ffox 3.5 and xul 1.9.1 security updates need to take a detour through -proposed again. can you check (and _binary_ pocket copy from ppa) bug 404827 and 398205
[12:08] <asac> thats for jaunty (universe)
[12:08] <asac> i dropped the details in the bug
[12:09] <asac> idea is again that the binaries get copied so we can copy to -security after the weekend verification is done
[12:25] <pitti> asac: will do after lunch; hm, that was documented on ArchiveAdministration wiki page?
[12:25] <pitti> seb128: ok, sent patch to upstream, and uploaded; let's see how it goes :)
[12:26]  * seb128 back from lunch
[12:26] <seb128> pitti, ok thanks
[12:26] <asac> pitti: we can wait till jdstrand wakes up ... shouldnt be that long
[12:26]  * pitti -> lunch, bbl
[12:26] <asac> enjoy
[12:26] <asac> jdstrand: pitti needs your input on how to copy stuff from ppa to proposed
[12:27] <asac> oops
[12:27] <asac> wrong channel ;)
[12:27] <seb128> asac, he's not there
[12:27] <seb128> ;-)
[12:27] <asac> just noticed
[12:27] <seb128> you don't use tab? ;-)
[12:27] <asac> had a spasm in my hand that made irssi switch to this window directly before sending ;)
[12:28] <asac> no ... irssi ;)
[12:29] <asac> rhythmbox is still our default, right? or should i use banshee?
[12:34] <Amaranth> yeah, still rhythmbox
[12:34] <seb128> asac, rhythmbox
[12:34]  * Amaranth cries a little
[12:34] <seb128> banshee screwed, they didn't roll any tarball in the recent months
[12:34] <seb128> and they have no 1.6 schedule
[12:35] <asac> tarballs are for the weak ;)
[12:35] <seb128> stable versions too? ;-)
[12:35] <Amaranth> I think the lead developer is working on some netbook stuff instead
[12:35] <asac> git snapshots for the world
[12:35] <Amaranth> seb128: sure, just look at compiz :)
[12:35]  * seb128 makes asac responsible for the audio player in karmic
[12:35] <Amaranth> ooh, that reminds me
[12:35] <seb128> asac, feel free to take over that and the bugs which come with it ;-)
[12:35] <asac> you mean in karmic+1?
[12:35] <asac> urgh
[12:35] <Amaranth> seb128: any update on that gnome-panel patch for viewport scrolling?
[12:36] <asac> all bugs are pulse and alsa ;)
[12:36] <seb128> whatever you feel is the right moment to upload git from unstable versions
[12:36] <seb128> Amaranth, blocked on vuntz
[12:36] <seb128> Amaranth, I don't care enough about the feature to upload as a distro change
[12:36] <Amaranth> :(
[12:37] <Amaranth> seb128: the patch has applied cleanly for over a year now, I don't think it'll be much maintenance
[12:37]  * seb128 kicks firefox for crashing when called by apport
[12:37] <seb128> twice that I upload a dump for nothing now
[12:37] <seb128> Amaranth, it's extra delta and potential bugs for no real win
[12:38] <davmor2> is anyone experiencing issues shutting down totem
[12:39] <seb128> yes everybody
[12:39] <davmor2> seb128: Thanks
[12:42] <seb128> "Gdk-ERROR **: The program 'firefox' received an X Window System error."
[12:42] <seb128> oh, come on
[12:50] <mvo> seb128: no robert today?
[12:50] <seb128> mvo, it's friday midnight for him now or something
[12:51] <mvo> seb128: oh, I thought its just evening in .au, but I guess it depends on the exact location :)
[12:51] <seb128> mvo, he tends to be good at stopping work on time, so he might have stopped before you started your day
[12:51] <didrocks> pitti: thanks :)
[12:52] <mvo> seb128: ok, thanks
[12:52] <seb128> mvo, he usually leave between 9am and 10am our time
[12:52] <seb128> mvo, no problem
[12:52] <mvo> seb128: thanks, I finally will do the compiz update today (that I wanted to do *all* week)
[12:52] <seb128> mvo, \o/
[12:53] <Amaranth> mvo: \o/
[12:53] <seb128> mvo, nice work on software-store btw, it's becoming better quickly ;-)
[12:53] <seb128> mvo, I like the grid now it's aligned correctly ;-)
[12:53] <seb128> mvo, and it's nice to have installed softwares listed with a checkbox
[12:56] <Amaranth> it doesn't do any more then it did two weeks ago but it looks awesome doing it now :)
[13:03] <mvo> Amaranth: haha - that is a pretty accurate description :)
[13:21] <seb128> pitti, bug #427819
[13:22] <mvo> seb128: I take the rb, and python-desktop sponsoring from robert
[13:22] <pitti> seb128: nice!
[13:22] <seb128> mvo, thanks!
[13:23] <seb128> pitti, thanks for the quick fixing ;-)
[13:23] <pitti> you're welcome
[13:23] <pitti> seb128: don't thank me too early, you'll just get even more bugs ..
[13:23]  * mvo mubbles about him always mistyping rhythmbox
[13:24] <pitti> mvo: Rharbarber! Rharbarber!
[13:24] <asac> seb128: g_test_run_suite_internal ?
[13:24] <asac> was that a test bug?
[13:24] <asac> i guess so
[13:24] <seb128> asac, bug number?
[13:25] <seb128> oh the one I just sent
[13:25] <seb128> no, not a test bug
[13:25] <pitti> for assertions, the last couple of stack frames will probably always be the same
[13:26] <pitti> but the dupe finder doesn't rely on them, just on the assertion message
[13:26] <asac> seb128: feels odd that evolution enters "g_test_run_suite_..."
[13:26] <asac> or is that just a assertion facility in glib
[13:27] <seb128> that's glib
[13:27] <seb128> evo do g_assert
[13:27] <asac> ok
[13:27] <seb128> which leads to those functions in glib
[13:27] <asac> yes thats what i was asking. thx
[13:29] <seb128> yeah for fusa having correct im status now
[13:31] <asac> seb128: g_test_suite_run is clearly a testing facility
[13:31] <asac> and not an implemetnation of g_assert or something
[13:31] <asac> http://library.gnome.org/devel/glib/stable/glib-Testing.html
[13:32] <asac> are you saying they reuse that somewhat for g_assert implementation?
[13:32] <seb128> pitti, ^ do you know?
[13:32] <pitti> no, sorry
[13:32] <asac> all i am saying that either that crash report is from a make check run
[13:32] <asac> or something is really odd there c;)
[13:32] <pitti> but the macros I saw just use the internal g_assert_message() function
[13:32] <seb128> asac, no, that crash is the indicator-applet crashing when closing evolution
[13:36] <seb128> asac, that's the dump in gdb locally
[13:36] <seb128> #2  0x0028d932 in abort () from /lib/tls/i686/cmov/libc.so.6
[13:36] <seb128> #3  0x001faf2d in g_assertion_message () from /usr/lib/libglib-2.0.so.0
[13:36] <seb128> #4  0x001fb57d in g_assertion_message_cmpnum () from /usr/lib/libglib-2.0.so.0
[13:36] <seb128> #5  0x00c5c45a in dbus_g_proxy_end_call_internal (proxy=<value optimized out>,
[13:36] <seb128>     call_id=<value optimized out>, error=0xbfdccc8c, first_arg_type=161132024,
[13:36] <seb128>     args=0xbfdccc50 "x\314ܿ") at dbus-gproxy.c:2274
[13:36] <seb128> #6  0x00c5c695 in dbus_g_proxy_end_call (proxy=0x99ab958, call=0xf,
[13:36] <seb128>     error=0xbfdccc8c, first_arg_type=161132024) at dbus-gproxy.c:2548
[13:36] <asac> so the retrace is wrong somehow
[13:36] <seb128> well, g_assert path is weird
[13:36] <seb128> but from frame #5 it's correct
[13:37] <asac> that gdb looks ok
[13:37] <asac> i mean the http://launchpadlibrarian.net/31651354/Stacktrace.txt
[13:37] <asac> in the bug
[13:37] <asac> it goes to testsuite ;)
[13:37] <asac> but well. probably optimization or something making fun stuff here
[13:52] <pitti> Riddell: do you think anything will be done for bug 256245 still?
[13:56] <pitti> slomo, seb128: just to keep me up to date, is bug 412927 really "fix committed" still, or is that still pending on figuring out the regressions from that patch?
[13:56] <seb128> pitti, you can change it back to triaged
[13:57] <seb128> pitti, it might not be done for karmic ...
[13:57] <Riddell> pitti: maybe, it's waiting on policykit-qt 1.0 I believe so that kpackagekit can use packagekit 0.5
[13:57] <pitti> (ugh)
[13:57] <seb128> pitti, slomo said it involves quite some refactoring
[13:57] <pitti> Riddell: ah, thanks
[13:57]  * asac lunch
[13:58] <pitti> Riddell: is that just a question of getting an upstream release?
[13:59] <pitti> seb128: that woudl be a shame :-(
[13:59] <Riddell> pitti: upstream completing it and releasing yes
[13:59] <seb128> pitti, don't tell me
[13:59] <pitti> seb128: I guess there's no option to rollback to jaunty's gstreamer?
[13:59] <seb128> pitti, we could rollback to playbin1
[13:59] <seb128> but it would break playing of chained oggs again, etc
[14:00] <seb128> and undo all the testing from this cycle
[14:00] <seb128> and lot of good work, fixes and testing to use something deprecated for playing
[14:00] <seb128> I don't think that's a good deal
[14:00] <pitti> well, "does not play at all" is not good either..
[14:01] <pitti> and for most video formats, "does not play at all" is unfortunately the OOTB experience
[14:01] <seb128> rock - -gstreamer - hard place?
[14:01] <pitti> something like this..
[14:01] <seb128> hey tedg
[14:02]  * mclasen would like a fix for that too...
[14:02] <tedg> Good morning seb128
[14:02] <seb128> tedg, bug #427819
[14:02] <seb128> tedg, I get the applet crashing every time I open or close evo
[14:02] <seb128> tedg, let me know if you need details ;-)
[14:03] <pitti> seb128: would rolling back to playbin1 be a realistic option in terms of packaging, API transitions, etc.?
[14:03] <seb128> mclasen, pitti: slomo said he was working on it but it's not trivial, will likely be after GNOME 2..28
[14:03] <seb128> could be in time for 2.28.1 though
[14:03] <seb128> pitti, playbin1 is still there
[14:03] <seb128> pitti, it would just change elements used by totem and rhythmbox to use it again
[14:04] <pitti> seb128: ah, so we wouldn't actually need to rollback gst, just change totem to use the old API again?
[14:04] <pitti> I see
[14:04] <seb128> but that would mean reintroduce lot of issues and bugs just to workaround initial install not working
[14:04] <seb128> ie "make the install work but then force users to use something buggy for ever"
[14:04] <pitti> seb128: I would just like to get a feeling about how much longer we can postpone that, i. e. until when we have the option of that rollback
[14:04] <seb128> which I don't find a good deal
[14:05] <pitti> well, "forever" -> in karmic
[14:05] <pitti> people have used it in hardy/intrepid/jaunty, too
[14:05] <pitti> and at least they can play their stuff
[14:05] <seb128> so you think initial codec install is more important than user experience with the software after that?
[14:05] <pitti> seb128: TBH yes; user experience with just a "unknown format" dialog is very bad..
[14:05] <slomo> pitti, seb128: if you want to change totem to playbin1 again you could as well use totem 2.26... that's not trivial
[14:05] <seb128> right, and they have been complaining about quite some issues, ie playing chained ogg stopping after each song
[14:06] <slomo> also i'll try to get a patch ready next week ;)
[14:06]  * pitti hugs slomo
[14:06] <seb128> pitti, I'm strongly against limiting experience in use for all user just to ease codec install
[14:07] <seb128> it means all people having the codecs pay a cost for something they don't care
[14:07] <pitti> seb128: ok; well, to me, it's "limited playback" vs "no playback at all", but YMMV
[14:07] <seb128> pitti, "no playback if you don't know how to install a codec"
[14:07] <seb128> ie all users upgrading, etc would pay for no good reason
[14:07] <pitti> realistically, a default install can't play back any contemporary video format; few, if any, come as theora
[14:08] <seb128> pitti, anyway let's try to make that work for karmic we still have time
[14:08] <pitti> *nod*
[14:08] <seb128> pitti, right, but users do figure how to install codec, using the web if they need, and many upgrade and have those
[14:08] <pitti> seb128: thanks for the heads-up; I'm mainly interested to know the alternatives and the pro/con of them
[14:11] <seb128> pitti, np, sorry for the disagreement but I'm pretty confident it will be fixed for karmic
[14:16] <pitti> seb128, asac: do you have an "executive summary" about the status and blockers of bug 401823?
[14:16] <pitti> unassigned karmic blocker, I need to find an assignee for those
[14:16] <seb128> I don't
[14:23] <kenvandine> pitti, did you get my call?
[14:23] <pitti> kenvandine: I did; I accepted it, searched for my usb headset, plugged it in, and when I sat back down, empathy was gone
[14:23] <kenvandine> ok
[14:23] <pitti> kenvandine: I don't have the upnp thing yet
[14:23] <kenvandine> crash :/
[14:24] <kenvandine> pitti, it is building in my ppa
[14:24] <kenvandine> mind if we test that in a bit?
[14:24] <pitti> kenvandine: tried to call you, just crashes, too
[14:24] <pitti> kenvandine: yes, let's test it
[14:24] <kenvandine> ok
[14:24] <kenvandine> not crashing here
[14:25] <kenvandine> so testing with jcastro it disconnects instantly
[14:25] <pitti> kenvandine: that's with your new farsight?
[14:25] <kenvandine> but with others it just crashes their empathy :)
[14:25] <kenvandine> yes
[14:25] <kenvandine> it is building in my ppa now
[14:25] <kenvandine> pitti, i need to take an early lunch here in a few... mind if we try in like 2 hours?
[14:25] <pitti> kenvandine: I'll be in release team meeting then, but we can try afterwards
[14:25]  * kenvandine is convinced it is upnp and jcastro  that is failing :)
[14:25] <kenvandine> ok
[14:25] <pitti> kenvandine: or besides the meeting, after my part is done
[14:26] <kenvandine> just ping me when you are ready
[14:26] <pitti> kenvandine: this morning we got a new telepathy-farsight into karmic; installing that now
[14:26] <kenvandine> i will have bits to test :)
[14:26] <pitti> kenvandine: ~ken-vandine/+archive/ppa ?
[14:26] <pitti> or ubuntu-desktop or sth.?
[14:27] <kenvandine> mine
[14:27] <kenvandine> don't add that to your sources though :)
[14:27] <kenvandine> there is some junk there
[14:27] <kenvandine> just grab the debs
[14:27] <pitti> ok
[14:30] <pitti> asac: do you plan to upload a new NM 0.8 snapshot to karmic at some point? when? (asking about the polkit-1 migration)
[14:31] <pitti> kenvandine: do you have something on your radar which should be mentioned on https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus ?
[14:32] <seb128> tedg, did you read my bug? ;-)
[14:32] <kenvandine> tedg, i have the same bug seb128 has
[14:32] <kenvandine> pitti, nope
[14:32] <tedg> seb128: Yes, even switched it to the right project :)
[14:33] <seb128> tedg, ok, let me know if you need details
[14:33] <tedg> seb128: I haven't looked into it further yet though, catching up on the mail all the Europeans send while I'm sleeping :)
[14:33] <seb128> ok
[14:36] <seb128> pitti, isn't the -proposed tag for -proposed uploads?
[14:36] <seb128> pitti, you set that for the easy codec bug
[14:39] <asac> pitti: i can do that today. or monday (have a few fixes in pipeline that i would like to commit upstream for that). so if you want it today i can just upload
[14:40] <asac> pitti: re XID ... i have to admit that i have no real summary besides from what i mentioned in the bug comment
[14:40] <asac> i will try to get karlt on the line who might know some backgrounds
[14:41] <asac> https://bugs.edge.launchpad.net/ubuntu/+source/firefox-3.5/+bug/401823/comments/4
[14:41] <asac> https://bugs.edge.launchpad.net/ubuntu/+source/firefox-3.5/+bug/401823/comments/5
[14:41] <asac> those comments are the current status
[14:41] <asac> i havent seen a proof of "those troubles ahead"
[14:41] <pitti> asac: ok, thanks
[14:41] <pitti> it didn't sound like OMGbreakseverythign
[14:41] <asac> but its not something i would like to hide
[14:42] <asac> before final
[14:42] <asac> yes
[14:42] <asac> but it could cause follow up crashes (rare?)
[14:42] <asac> from what i understand its becausee gdk overeagerly caches xid's
[14:42] <asac> and then things like flash et al that dont use the same gdk allocate the same XIDs
[14:43] <asac> have to get a fresh git gtk snapshot and will look a bit closer to the gdk code
[14:43] <asac> to refresh my memory on this
[14:45] <asac> mclasen: i guess you might know something too: how bad is: (firefox-3.5:14875): Gdk-WARNING **: XID collision, trouble ahead ?
[14:46] <rickspencer3> asas ccheney ArneGoetje jcastro kenvandine pedro_ Riddell pitti :
[14:46] <rickspencer3> good morning
[14:46] <rickspencer3> anyone hear from bryce?
[14:46] <pitti> hey rickspencer3
[14:46] <pitti> rickspencer3: no, nothing yet
[14:47] <rickspencer3> I did!
[14:47] <rickspencer3> It's a boy!
[14:47] <rickspencer3> he says
[14:47] <rickspencer3> His name is Dutch Alexander, he was born healthy and happy at 9:19pm on
[14:47] <rickspencer3> 9/10.  6lbs 8oz.
[14:47] <rickspencer3> !!!
[14:47] <pitti> yay!
[14:47] <pedro_> \o/! super!
[14:47] <asac> nice
[14:48] <didrocks> sweet :)
[14:50] <kenvandine> woot
[14:50]  * kenvandine runs out for an early lunch break... be back in about an hour
[14:51] <tseliot> rickspencer3: a boy? Wasn't it supposed to be a girl? (BTW the same thing happened when I was born)
[14:51] <rickspencer3> tseliot, I dunno
[14:57] <Riddell> morning rickspencer3
[14:57] <rickspencer3> hi Riddell
[14:57] <Riddell> does this mean we'll have to compete with a screaming bairn to get our X bugs fixed? :)
[15:07] <rickspencer3> Riddell, yes
[15:07] <rickspencer3> a baby has a way of reseeting your priorities in a serious way
[15:13] <pitti> kenvandine: what do I need here (https://launchpad.net/~ken-vandine/+archive/ppa), farsight and libnice?
[15:35] <mvo> did I mention that compiz upstream is rocking currently?
[15:35] <mvo> fixes, fixes, its just great
[15:36] <seb128> mvo, waouh
[15:37] <seb128> mvo, what happened to your upload?
[15:37] <mvo> seb128: postponed because *more* fixes are on the way
[15:37] <mvo> maybe I upload anyway
[15:37] <mvo> and just push them tomorrow
[15:37]  * mvo wants icecream first :)
[15:37] <seb128> if you wait for it to be perfect you will never upload
[15:37] <mvo> good point
[15:37] <seb128> ice cream, hum ;-)
[15:37] <seb128> lucky you!
[15:38] <seb128> enjoy ;-)
[15:38] <mvo> well, I need to go out and get it first, but its so nice outside, that I totally want to do that now :)
[15:39] <asac> have a great weekend everyone!
[15:41] <pitti> see you asac
[15:42] <mvo> you too asac
[15:47] <seb128> asac, hum, now firefox disabled greasemonkey!
[15:48] <pitti> mvo: lucky you, it's quite cold here (18 degrees)
[15:48] <seb128> saying it's not compatible with 3.5.3
[15:53] <kenvandine> pitti, yes
[15:57] <pitti> kenvandine: meeting now; I installed the crack, can I ping you when I have enough spare cycles from teh meeting?
[15:58] <kenvandine> sure
[16:01] <pitti> kenvandine: hm, there goes apport again
[16:01] <pitti> kenvandine: I called you, then you called me
[16:01] <dashua> mvo, Latest compiz uploads r0x.  There are no more artifacts between menubar and the metacity on wobbly :)
[16:01] <dashua> Still testing them out.
[16:01] <kenvandine> hehe
[16:01] <kenvandine> i didn't see the dialog
[16:01] <pitti> kenvandine: it's not even apport, it's just 100% CPU and frozen
[16:02] <kenvandine> pitti, are you back to a functioning state?
[16:02] <pitti> kenvandine: restarted
[16:02] <pitti> kenvandine: it didn't freeze this time
[16:02] <pitti> kenvandine: say something
[16:03] <pitti> kenvandine: I can hear you
[16:03] <kenvandine> mine says "Connecting"
[16:03] <kenvandine> oh
[16:03] <kenvandine> cool
[16:03] <pitti> but through the loudspeakers
[16:03] <kenvandine> hehe
[16:03]  * pitti fiddles headphone
[16:03] <kenvandine> i don't hear you
[16:03] <pitti> kenvandine: I can hear you
[16:03] <kenvandine> that is progress :)
[16:03] <pitti> kenvandine: I switched mike to usb, but still nothing
[16:04] <pitti> kenvandine: let's continue later, meeting time
[16:04] <pitti> kenvandine: heh, hanging up -> frozen again
[16:04] <kenvandine> ok
[16:06] <kenvandine> pitti, when we test again, run empathy with this command
[16:06] <kenvandine> EMPATHY_LOGFILE=/tmp/empathy.log GST_DEBUG=\*fsrtp\*:5 EMPATHY_DEBUG=all empathy
[16:52] <NCommander> pitti, ping, your last patch broke the armel build of glib :-/. Any ideas whats wrong with it?
[16:52]  * NCommander is just looking at it now
[16:53] <pitti> NCommander: we just discussed it in #u-meeting
[16:53] <pitti> NCommander: just fix glibc to build, then we can retry glib
[16:53] <NCommander> oh, sorry, missed that bit
[16:53] <pitti> NCommander: alternatively, we can drop --enable-assert-messages on armel, but then again, glibc really should build either way :)
[16:54] <pitti> NCommander: lool is at fixing glibc ATM
[17:03] <pitti> kenvandine: ok, whatever you did now crashed empathy
[17:03] <kenvandine> pitti, ok... so voice works :)
[17:03] <kenvandine> did you get a X error?
[17:03] <pitti> kenvandiempathy: Fatal IO error 11 (Resource temporarily unavailable) on X server :2.0.
[17:04] <pitti> ^ last line in /tmp/empathy.log
[17:04] <kenvandine> ok
[17:04] <kenvandine> yeah... i think it might be a compiz bug
[17:04] <kenvandine> pitti, but this is good progress :)
[17:05] <lool> pitti: I handed doko the fix; I cant upload since he did some unuploaded changes as a new revision so I think he's testing them and I dont want to wait on a rebuild; also I cant push to the eglibc bzr but that's minor
[17:06] <lool> pitti: You might want to add a versionned libc-dev bdep in glib as time permits though
[17:08] <pitti> lool: does the FTBFS break anything on arm?
[17:08] <pitti> lool: if so, I'll just change it to disable the new feature on armel
[17:09] <kenvandine> pitti, ok... not compiz :)
[17:09] <kenvandine> pitti, progress though :)
[17:10] <lool> pitti: It breaks the image builds
[17:10] <pitti> kenvandine: absolutely
[17:10] <kenvandine> pitti, so i think libnice and farsight2 with gupnp is worth it :)
[17:10] <kenvandine> next to fix the video problem
[17:11] <pitti> kenvandine: gupnp> ++
[17:12] <rugby471> hello
[17:12] <mvo> dashua: great to hear that compiz is fixing these issues - I will do a karmic upload RSN
[17:13] <pitti> kenvandine: mind writing a MIR for gupnp, so that I can approve it?
[17:13] <kenvandine> pitti, i will post the the debdiff
[17:13] <kenvandine> yes
[17:13] <kenvandine> will do
[17:13] <pitti> kenvandine: cool, I'll sponsor; thanks
[17:15] <seb128> pedro_, do you have a bug you use to duplicate all those sudo nautilus crashes?
[17:20] <pedro_> seb128, the memory corruption ones? I've marking those as dup of bug 420841
[17:20] <seb128> ok
[17:20] <seb128> so you think it's not a nautilus issue?
[17:21] <pedro_> seems to be a brasero nautilus extension one
[17:21] <seb128> ok, you are right
[17:22] <pedro_> will send that upstream wonder why i didn't previously
[17:22] <pedro_> probably too much bug mail there
[17:22] <seb128> ok, that keeps coming
[17:29] <rugby471> mpt: https://bugs.launchpad.net/ubuntu/+source/software-store/+bug/427346
[17:29] <rugby471> how do we want to tackle this bug, not display it or just gray it out etc.
[17:29] <rugby471> mvo: ^ are you working on this? otherwise I shall take it up
[17:30] <mpt> rugby471, I think greying it out would be the most understandable way of handling it without adding any new strings
[17:30] <rugby471> mpt: ok, so do we want the item in the department list grayed out?
[17:30] <mpt> rugby471, yes
[17:30] <rugby471> mpt: and no text?
[17:31] <rugby471> mpt: we could have something like: this is not supported by your processor type
[17:31] <mvo> rugby471: no, fixing that would be great
[17:31] <rugby471> ok
[17:31] <mpt> rugby471, as I understand it, we can't add new text, we're past UI freeze
[17:31] <rugby471> oh
[17:31] <rugby471> well there we go :-)
[17:31] <rugby471> mvo: can we not add new strings?
[17:31] <mvo> mpt: I think your idea of using the g-a-i strings is a good one
[17:32] <mvo> rugby471: we should avoid it really hard, but if we can use the ones in g-a-i I think we are ok, its just a bit of work to mnually merge them and the translations
[17:32] <rugby471> ok
[17:32] <mvo> its a pretty anoying bug
[17:32] <mvo> IMO
[17:32] <rugby471> I shall hold off on the strings at the moment then
[17:32] <rugby471> just the graying out :-)
[17:34]  * mvo nods
[17:35] <pitti> seb128: sabayon was removed from Debian, with "ROM; almost completely broken"; should we follow suit?
[17:36] <seb128> pitti, not sure, I think edubuntu uses it and it got updates in karmic
[17:36] <pitti> seb128: ok, thanks
[17:45] <seb128> asac, want to sponsor bug #427665?
[17:57] <tedg> seb128: Can you try lp:~ted/dbusmenu/427819 to see if it fixes that bug?  It removes a small feature, but it shouldn't be one that we need.  I think that dbus-glib is broken here.
[17:58] <seb128> tedg, what do I need to restart?
[17:58] <tedg> seb128: You said the bug was happening at login?
[17:59] <seb128> no, it happens every time I start evo
[17:59] <seb128> or close evo
[17:59] <tedg> seb128: Then killall indicator-applet
[18:00] <seb128> tedg, lp:~ted/dbusmenu/427819 not working
[18:00] <tedg> seb128: Still crashing?  Or something doesn't work?
[18:01] <seb128> bzr complains about lp:~ted/dbusmenu/427819
[18:01] <seb128> ie bzr get lp:~ted/dbusmenu/427819 doesn't work
[18:01] <tedg> seb128: heh, oh.  Maybe LP hasn't saved it yet.
[18:02] <pitti> have a good weenend everyone!
[18:02] <seb128> pitti, thanks, you too!
[18:03] <seb128> tedg, I'm off for dinner will still build try and let you know after dinner
[18:03] <tedg> seb128: Cool, thanks!
[18:04] <didrocks> have a good weekend pitti!
[18:04] <didrocks> and a good dinner for seb128 :)
[18:05] <rugby471> mvo: how does the appdetailsview change colour for the installed and not installed items?
[18:06] <rugby471> mvo: ah don't worry I see :-)
[18:07] <c_korn> tedg: thanks for merging my branch and releasing the new version. does the gconf key need to be documented somewhere ? or are experts expected to find it themselves ? :)
[18:07] <tedg> c_korn: They're defined as experts :)
[18:08] <tedg> c_korn: Seems like a good idea, but I'm not sure where to put it....
[18:10] <kklimonda> pitti: how strict is UI freeze and how hard would it be to get an exception for a new dialog window and a donate button in help menu for transmission?
[18:10] <c_korn> tedg: hm, neither do I. so I think my work is finished so far.
[18:22] <aquarius> is software-store able to run uninstalled? (i.e., out of the source tree?)
[18:23] <aquarius> when I try I get xapian.DatabaseOpeningError: Couldn't detect type of database, which might mean that I need to create a database or something.
[18:25] <rugby471> mvo: I am trying to do the arch thing now
[18:29] <mvo> rugby471: ok, let me know if you have any questions, do you know the details? there should be just a check, if the package is not in the aptcache then it should check if its supposed to be available or not
[18:29] <rugby471> mvo: is the place I need to be check for the arch in appview.py (as you have moved some stuff into seperate widgets)
[18:30] <rugby471> check > checking
[18:30] <aquarius> ah, it tries to make /var/cache/software-store/xapian a xapian database, and that folder doesn't exist. Does that mean that software-store expects to be run once installed, and won't run uninstalled?
[18:31] <mvo> aquarius: it currently runs not great uninstalled, it complains about missing icons too
[18:31] <mvo> aquarius: once the version from the archive is installed it will run just fine out of the bzr tree
[18:32] <mvo> aquarius: its something I would like to fix at some point though
[18:32] <aquarius> mvo, can I just poke softwarestore.enums to point at locally-writeable folders (which I will happily submit a patch for) or is there likely to be loads of stuff which assumes that it is Master Of Everything and can write in /var and so on? :)
[18:33] <rugby471> mvo: I shall try my hand at an easier bug, however i have fixed a medium priority bug in my branch, could you merge?
[18:33] <mvo> aquarius: we could just add --cachedir as a commandline option - I would be happy to merge such a patch
[18:34] <mvo> rugby471: sure
[18:34] <rugby471> mvo:thx
[18:34] <mvo> aquarius: I think its just the cache that is in /var and some icons loading, but that is a matter of "try: except glib.GError: pass ;)
[18:34] <mvo> aquarius: and of course the ugliness that there are no icons then
[18:34] <mvo> :)
[18:34]  * aquarius grins
[18:34] <aquarius> I'll take a look at it :)
[18:35] <mvo> maybe a additional explicit --datadir in the commandline
[18:35] <mvo> (seperate from --cachedir)
[18:36] <mvo> rugby471: is it pushed yet? bzr just said "nothing to do"
[18:36] <mvo> (or maybe LP is a bit on the slow side today ;)
[18:37] <rugby471> mvo: yeah it is slow, the launchpad page still says 'Updating branch...'
[18:37] <rugby471> https://code.launchpad.net/~rugby471/software-store/software-store-andrew
[18:38] <rugby471> aquarius: it should be easy, just add another switch in ./software-store, we are using optparse
[18:38]  * aquarius nods, yep
[18:38] <aquarius> just noticed that myself :)
[18:38] <rugby471> mvo: I no longer experience https://bugs.launchpad.net/ubuntu/+source/software-store/+bug/419740, can I close it?
[18:38] <rugby471> aquarius: hehe
[18:39] <aquarius> I assume you're in favour of explicit "pass a --datadir" rather than semi-magical "am I in the source tree? yes? brilliant, I'll use this different set of data files" code?
[18:39] <rugby471> mvo: what I mean is do you still experience it :-)
[18:39] <mvo> rugby471: yeah, someone will reopen if it happens again
[18:39] <rugby471> mvo: kl
[18:39] <mvo> rugby471: no, haven't had it recently, many think
[18:39] <mvo> thanks
[18:39] <mvo> rugby471: what bug should I close with the merge?
[18:40] <rugby471> https://bugs.launchpad.net/ubuntu/+source/software-store/+bug/425859
[18:40] <rugby471> mvo: ^
[18:40] <mvo> thanks
[18:42] <rugby471> mvo: np, how is the apt.ubuntu.com  progressing?
[18:45] <rugby471> mvo: is https://bugs.launchpad.net/ubuntu/+source/software-store/+bug/427568 fixed?
[18:46] <mvo> loclae-friendly sorting should be fix-commited
[18:46] <rugby471> mvo: kl
[18:47] <mvo> rugby471: your fix works nicely, commited
[18:47] <rugby471> mvo: thanks
[18:48] <mvo> sounds like its time for another upload soon ;)
[18:49] <rugby471> mvo: hehe
[18:52] <rugby471> mvo: wait one min and I might have one more fix
[18:52] <rugby471> mvo: ah nope don't worry
[18:52] <rugby471> mvo: I misunderstood the bug
[18:52] <mvo> sure, I can bit a bit longer
[18:52] <mvo> no problem
[18:52] <rugby471> mvo: go ahead :-)
[18:58] <aquarius> OK, given my no knowledge of xapian -- is the xapian database in /var/cache/software-store/xapian expected to already exist? i.e., it is not created by the software-store program itself?
[18:58] <rugby471> mvo: gotta go now
[18:59] <rugby471> mvo: see ya
[19:03] <mvo> aquarius: its run when the package gets installed, the script is in utils/update-software-store
[19:04] <mvo> aquarius: it would be cool if the app itself checks if it can create the db when a alternative --cachedir is given
[19:04] <aquarius> cool :)
[19:04] <mvo> so that it runs full from a bzr checkout without any need of local install
[19:04] <aquarius> exactly what I'm trying to make it do :)
[19:10] <mvo> cool
[19:37]  * aquarius pushes lp:~sil/software-store/run-uninstalled
[19:37] <aquarius> mvo, how are you software-store guys handling patches? Should I propose for merging into trunk, or do you do things another way?
[19:38] <mvo> aquarius: proposing via the web-ui is fine, or just mentioning it on irc
[19:38] <mvo> its still a small project :)
[19:38]  * aquarius grins
[19:38]  * aquarius mentions it on irc ;)
[19:38] <mvo> what is the branch url?
[19:39] <aquarius> https://code.edge.launchpad.net/~sil/software-store/run-uninstalled
[19:39] <aquarius> I don't know whether it does everything that's required, specifically because I don't really understand xapian, so atm it doesn't actually show any packages inside each department.
[19:39] <aquarius> on the other hand that's better than a traceback :P
[19:40] <mvo> that sounds like its not quite there yet ;)
[19:40] <mvo> better than a traceback for sure
[19:40]  * mvo looks at the branch
[19:41] <aquarius> I agree it's not quite there yet, but I need to be schooled in xapian. :)
[19:45] <mvo> aquarius: hm, the diff looks right, its probably/hopefully something really trivial
[19:45]  * mvo looks a bit sharper
[19:53] <aquarius> I am 82% sure that the problem is that I'm not populating the xapian database right, and therefore it gets no results.
[19:53] <mvo> aquarius: I got it mostly working I think, it needs some love because of apt is a system package and a sub-package in software-store (or either relative imports or rename)
[19:54] <aquarius> python -c "import xapian; d=xapian.Database('data/xapian'); enq=xapian.Enquire(d); print [x for x in enq.get_mset(0, 20)]"
[19:54] <aquarius> []
[19:54] <aquarius> ah, that's weird. When I ran it the first time it complained about apt not having a sub-package Cache, and when I ran it the second time it didn't complain so I thought it was cosmic rays or something :)
[19:54] <mvo> I renamed data=APP_INSTALL_PATH to desktopdir (and the same two lines below)
[19:55] <mvo> haha
[19:55] <mvo> funny, I have not tried running it twice :P
[19:55] <mvo> next thing is to figure out how to flush the WriteableDatabase
[19:55] <mvo> before the other one opens the data again
[19:55] <mvo> flush()
[19:56] <mvo> hm, that is easy
[19:56] <aquarius> I was worried that would be it. I thought to myself: I wonder if I'm allowed to re-open an open db? :)
[19:56] <aquarius> .flush? that's it?
[19:56] <mvo> yeah, that seems to help
[19:59] <mvo> http://paste.ubuntu.com/269348/ is what I did
[19:59] <mvo> I just need to learn a bit more about relative imports, I guess it makes sense to either use them everywhere or nowhere
[20:00] <aquarius> in ubuntu one we had a big argument about it and decided to not use them
[20:00] <aquarius> which is good, because it meant that I didn't have to learn about them ;-)
[20:03] <aquarius> yeah!!!
[20:03] <aquarius> victory.
[20:03] <mvo> haha
[20:03] <mvo> I will just rename apt then
[20:03] <aquarius> well, it's pushed with the relative imports in
[20:04] <aquarius> you violated the Big Important Rule, which is: never name any Python module the same as a system module, or you'll spend a hundred years trying to work out what the problem is :)
[20:05] <aquarius> right, now to do what I actually intended to do, which is disable the install button while something installs. And then go to the pub. :)
[20:06] <mvo> :)
[20:06] <mvo> cool
[20:22]  * aquarius grumbles. You can't pass arbitrary parameters to an AptTransaction's exit_handler
[20:23] <aquarius> if the right way to do this is to allow that, which it is, then I have to patch aptdaemon, which is not happening at 8.30pm on a Friday :)
[20:24] <seb128> tedg, re
[20:25] <seb128> tedg, the update doesn't crash indeed
[20:26] <tedg> seb128: Woot!
[20:26] <tedg> seb128: Does it work? :)
[20:26] <seb128> it seems
[20:26] <seb128> not sure what it could break
[20:26]  * tedg was waiting for a "it doesn't crash, but my cat is dead" :)
[20:27] <seb128> the indicator lists the same things
[20:27] <seb128> and clicking on those work the same way
[20:27] <seb128> no, it seems to work and my cat is good shape too ;-)
[20:27] <tedg> Sounds good.  Odd that you entered that case and I didn't.
[20:27] <seb128> +in
[20:27] <seb128> dunno what triggers it
[20:27] <seb128> I get it on both my desktop and laptop configs
[20:28] <seb128> anyway good to see it fixed
[20:29] <seb128> that's not a major issue, just an applet which reloads fine so it will wait next week
[20:29] <seb128> I'm going back to my friday evening
[20:29] <seb128> have a good weekend everybody
[20:29] <tedg> Cool, I put it into trunk.  So it'll get in the release.
[20:29] <tedg> seb128: Have a good weekend!
[20:29] <seb128> tedg, thanks, you too ;-)
[20:35] <aquarius> wtf? the display of an app is a totally from-scratch webkit view? grr.
[20:39] <aquarius> right, I don't know anything about wkwidget, so it can wait until later this weekend :)
[20:46] <aquarius> mvo, do I need to propose that run-uninstalled branch for merging, or is it now on your list to do anyway?
[20:56] <darkham> how many possibilities i've to finde some of the new themes in karmic daily?
[21:18] <darkham> someone?
[21:22] <seb128> see you later!
[21:40] <mac_v> !topic | darkham