[06:34] <skydrome> hey guy got a segfault with 4.0 and moonlight
[06:34] <skydrome> firefox-4.0
[06:34] <skydrome> Attempting to load the system libmoon
[06:34] <skydrome> Segmentation fault
[06:34] <micahg> skydrome: doesn't everything segfault with moon?
[06:35]  * micahg needs to look into that one of these days
[06:35] <skydrome> tbh i dont even know why its installed
[06:35] <skydrome> think i needed it for something a while ago
[06:35] <micahg> skydrome: if you don't use it, I'd suggest removing it as it seems to cause trouble for people
[06:36] <skydrome> yup removing now
[06:37] <skydrome> look really neat :) cya
[10:23] <ejat> anyone can comment on this : http://imagebin.ca/view/6388it6j.html
[11:25] <BUGabundo_remote> fta: can you reproduce? http://code.google.com/p/chromium/issues/detail?id=48942
[11:35] <fta> BUGabundo_remote, i don't have an account ther
[11:35] <fta> e
[11:37] <fta> "Built on Ubuntu 9.10, running on Debian unstable" grrr
[12:50] <fta> hm.. we need to clean-up those on upgrade.. http://paste.ubuntu.com/462949/
[12:58] <fta> (re) hm.. we need to clean-up those on upgrade.. http://paste.ubuntu.com/462949/
[14:45] <micahg> _Tsk_: hi, I think I figured out my Shredder problem, does the What's New page show Shredder on a version before release like 3.0.6?
[14:46] <_Tsk_> great - yes it does becaue we don't have redirects properly set
[14:46] <_Tsk_> only releases show thunderbird
[14:47] <_Tsk_> and when they don't we need to be notified - it's because our redirect rules are borked
[14:47] <micahg> _Tsk_: so, should I file a bug?
[14:48] <_Tsk_> for 3.0.6 :: no
[14:48] <_Tsk_> it's unreleased yet
[14:48] <_Tsk_> we are just pushing it today to the beta channel
[14:48] <_Tsk_> release date is set to the 20th or so
[14:49] <micahg> _Tsk_: k, great, I'll push it to Maverick then so we get extended testing
[14:49] <_Tsk_> yes please do
[14:51] <micahg> chrisccoulson: Thunderbird 3.0.6 looks ready to go, I'm going to push, ok?
[14:54] <micahg> _Tsk_: was there any discussion of TB 3.0.x EOL at the summit?
[14:54] <_Tsk_> no
[14:55] <_Tsk_> plans are AFAIK :
[14:55] <_Tsk_> 1) make 3.1.1
[14:55] <_Tsk_> 2) push 3.1.1 to 3.X users
[14:55] <_Tsk_> 3) push 3.1.1 to 2.x users
[14:55] <_Tsk_> 4) EOL 2.x
[14:55] <_Tsk_> but no talks on 3.0.x
[14:55] <micahg> :(
[14:56] <micahg> _Tsk_: k, I'll talk to chrisccoulson about it, thanks
[14:57] <_Tsk_> so asac isn't the person to talk about those things anymore
[14:57] <_Tsk_> should we update our contact list and who should we pîng ubuntu wise ?
[14:57] <chrisccoulson> micahg - feel free to upload tb3.0.6
[14:58] <micahg> _Tsk_: he is more advisory at this point, would you say that's correct chrisccoulson?
[14:58] <chrisccoulson> hi _Tsk_, feel free to ping me about anything ubuntu related
[14:58] <chrisccoulson> micahg - yeah, that's pretty much correct
[14:58] <micahg> _Tsk_: you can ping me as well, asac had chrisccoulson and I added to the notices that standard8 sends out
[14:59] <_Tsk_> ho ok that's done then
[15:01] <micahg> chrisccoulson: do you have time to chat about 3.0.x for Thunderbrid?
[15:01] <fta> micahg, http://paste.ubuntu.com/462949/
[15:01] <_Tsk_> micahg:  we also have a discussion on tb-lplanning about eoling 3.0.x
[15:02] <micahg> fta: ugh, what was that after?
[15:02] <fta> micahg, after the upgrade to 4.0. 3.7 left a bunch of stuff behind
[15:03] <chrisccoulson> that's fairly normal unless you do explicit conffile cleanups in the maintainer scripts
[15:03] <chrisccoulson> which we don't ever seem to have done before between major versions
[15:03] <fta> iirc, we already have something to in post/pre to do some clean up
[15:04] <fta> those are not user customized so they must go
[15:04] <fta> same for 3.0
[15:05] <fta> well, no, not 3.0
[15:05] <fta> i just have apturl.js in there
[15:05] <chrisccoulson> yeah, we should clean them up really, but i don't think that's a new problem. i've just logged in to my desktop which has been upgraded through a few releases, and i still have cruft left over in /etc/firefox-3.0 and /etc/firefox-3.5
[15:06] <micahg> fta: there's only something to clean up apparmor profiles
[15:06] <fta> micahg, hmm, i remember i did something like that somewhere
[15:08] <micahg> chrisccoulson: what do you think about SRUing bug 563535 in the next upload to Lucid?
[15:08] <ubot2> Launchpad bug 563535 in thunderbird (Ubuntu) "thunderbird -g fails due to invoking "$LIBDIR/$META_NAME" instead of "$LIBDIR/$META_NAME"-bin (affects: 1) (heat: 44)" [Medium,Triaged] https://launchpad.net/bugs/563535
[15:08] <chrisccoulson> micahg - yeah, i think we already fixed the same issue for firefox
[15:09] <chrisccoulson> i'd like to clean these wrapper scripts up a little this week really
[15:09] <micahg> chrisccoulson: k, so should I just get an sru-ack before you do the security upload?
[15:09] <chrisccoulson> micahg - yeah, can do
[15:11] <fta> that was rm_conffile in debian/xulrunner-1.9.1.postinst a while ago, is it still there?
[15:12] <micahg> fta: I don't see it, but there's a line to remove from ld.so.conf.d :)
[15:13] <fta> micahg, it's in bzr log, not sure why it's gone though
[15:14] <micahg> fta: revision 349
[15:27] <chrisccoulson> wow, i can't believe how slow maverick is on my laptop
[15:31] <mdeslaur> chrisccoulson: you mean widget drawing and stuff?
[15:31] <chrisccoulson> mdeslaur, everything, it runs absolutely terrible on my laptop
[15:32] <chrisccoulson> just switching tabs in nautilus takes around ~10s or so whilst it hammers the disk
[15:32] <chrisccoulson> i've had to purge ubuntuone because it just stops me from being able to do anything for 2 hours after logging in
[15:33] <chrisccoulson> but it still performs pretty bad
[15:33] <mdeslaur> Since upgrading to maverick, it feels like gtk slowed down 10x for me
[15:33] <mdeslaur> I can see stuff draw on the screen
[15:33] <chrisccoulson> yeah, it feels really awful. and nautilus has a huge memory leak too
[15:33] <chrisccoulson> in fact, that might be part of my problem
[15:33] <chrisccoulson> i have to keep killing nautilus every 10 minutes or so
[15:34] <chrisccoulson> and gedit too. perhaps it is a gtk problem ;)
[15:34]  * micahg wonders if it's worth SRUing the gdb bug if we're moving Lucid to 3.1.x anyways
[15:34] <micahg> chrisccoulson: ^^
[15:35] <chrisccoulson> micahg - i suppose it depends on when we plan to do that
[15:35] <chrisccoulson> perhaps we should just wait
[15:35] <micahg> chrisccoulson: wanna chat about it :)
[15:35] <mdeslaur> chrisccoulson: I seem to recall having experienced similar slowdown during the lucid beta cycle when CSD and/or something else was introduced temporarily into gtk
[15:35] <mdeslaur> but, my memory is crappy, so... :)
[15:36] <micahg> chrisccoulson: well, I need to know whether or not I need to make lightning for 3.0.x or just 3.1.x
[15:36] <chrisccoulson> i think we should start getting ready to deploy 3.1.1 on lucid now, but i'd like to get it in maverick first to get some testing coverage
[15:37] <chrisccoulson> i think we should probably make getting 3.1.x in to maverick a priority, so people can test it
[15:37] <micahg> chrisccoulson: k, but how long of a test window?  Once I push lightning 1.0b2 to maverick, we can't get 1.0b1 for 3.0.x in Lucid
[15:38] <chrisccoulson> micahg - i wouldn't worry too much about that, as it's fairly inevitable that lucid will get 3.1.x soon anyway
[15:38] <micahg> chrisccoulson: do we need a special ack for that this early?
[15:38] <chrisccoulson> mdeslaur, i ran the gtk updates from one of our PPA's when i was still running lucid, and that also slowed my machine down in the same way, so i suspect that it has something to do with it
[15:38] <micahg> chrisccoulson: we'll need to update enigmail as well and any other rdepends
[15:40] <chrisccoulson> micahg - that's ok, but we should probably start doing that in maverick ASAP really
[15:40] <micahg> chrisccoulson: ok, I'll try to get 3.1 back in the daily PPA this weekend, then after I get the rest of the rdepends (enigmail and such) updated for maverick, I'll upload (probably last week in July/first week of August), sound ok?
[15:40] <chrisccoulson> hopefully we'll catch all of the surprises early then ;)
[15:40] <chrisccoulson> yeah, that should be ok
[15:42] <micahg> I think I finally had an upload without changelog goofs \o/
[15:43] <micahg> don't worry, they were all minor/cosmetic
[17:57] <chrisccoulson> asac - is there a reason why we build an empty firefox-dev package?
[17:59] <asac> chrisccoulson: transitional?
[18:00] <asac> chrisccoulson: i think at some point we wanted to put the browser specific xpcom headers there
[18:00] <asac> might be that those are non-existing now in recent branches
[18:00] <asac> chrisccoulson: run find browser -name \*.idl
[18:00] <asac> in mozilla/ tree
[18:00] <asac> if that yields anything, it means that in theory we would need a -dev package for firefox
[18:01] <chrisccoulson> asac - it currently only depends on firefox, so if it is a transitional package, it's probably not pulling in the correct package
[18:02] <asac> chrisccoulson: so yeah. then the latter is the reason
[18:02] <asac> run that command to see if we would need a -dev
[18:03] <asac> seems there are a few
[18:03] <asac> http://paste.ubuntu.com/463071/
[18:03] <asac> most likely they dont get installed by make install and stuff like that etc.
[18:03] <asac> sigh
[18:03] <chrisccoulson> so, we should be installing those in firefox-dev really then?
[18:06] <asac> chrisccoulson: we should install those together with the .h files
[18:06] <asac> otoh we dont want anyone to use firefox ;)
[18:06] <asac> so its fine to drop that package i think
[18:06] <asac> until someone complains that they cant build some extension or so
[18:07] <chrisccoulson> cool, i'll drop the package for now then
[18:07] <chrisccoulson> thanks
[18:24] <fta_> grrr
[18:26] <fta> i think it's best if i quit freenode for a while, at least until my dsl link is fixed. no need to spam all the channels i'm usually in
[19:46] <chrisccoulson> micahg - i'm going to push tb3.0.6 to the PPA in a minute unless you've got any other changes you want to get in
[19:46] <micahg> chrisccoulson: no, I think just a straight update is fine since we'll probably push TB3.1 next month
[19:47] <chrisccoulson> cool, ok, doing that now then
[19:47] <micahg> chrisccoulson: thanks, I'm sure you saw I pushed to maverick this morning
[19:47] <chrisccoulson> yes thanks, i'll copy your tarball now ;)
[19:49] <micahg> chrisccoulson: BTW, I think I might add to .head a variable to choose either kmozillahelper or firefox-kde-support depending on version (probably won't get to this till next month though)
[19:49] <chrisccoulson> the firefox-kde-support is from an external source isn't it?
[19:50] <micahg> chrisccoulson: yeah, but that is the new name for the pacakge starting w/maverick
[19:50] <micahg> chrisccoulson: it's a suggests
[19:50] <chrisccoulson> i'm just wondering if it makes sense for us to just build a "firefox-gnome" and "firefox-kde" package which both depend on firefox and pull in the correct platform libraries
[19:51] <chrisccoulson> rather than doing different things for handling the kde/gnome bits
[19:51] <micahg> chrisccoulson: well, firefox-kde-support/firefox-gnome-support already do that I though
[19:51] <micahg> *thought
[19:52] <chrisccoulson> micahg - yeah, but firefox-kde-support comes from an external source package, which seems a bit strange
[19:52] <micahg> chrisccoulson: because it's developed by Novell :)
[19:52] <chrisccoulson> ah, ok
[19:53] <micahg> chrisccoulson: I just want to reference the right package name in the dailies
[19:54] <micahg> chrisccoulson: first, awesome job on all the script fixes this morning for FF.head, but I saw a small typo in r615
[19:54] <micahg> chrisccoulson: just in the changelog
[19:55] <chrisccoulson> micahg - yeah, i just saw that. i'll fix it when i do another push ;)
[19:55] <micahg> chrisccoulson: k, thanks :)
[19:55] <micahg> chrisccoulson: I'll port your fixes to ff4.0.head when I make it all in one
[19:55] <micahg> chrisccoulson: unless you want to do it :)
[19:56] <chrisccoulson> micahg - i'm going to create a firefox-3.6.head.dh7 branch shortly where we can start playing around with doing a dh7 port (just to catch any blockers on doing that)
[19:56] <chrisccoulson> but i want to do some tidying up first really
[19:57] <chrisccoulson> yeah, i'll look at copying some of those changes to ff4.0.head later as well
[19:57] <micahg> chrisccoulson: well, we can't do that until maverick+1 anyways, so I would suggest working on other maverick issues now
[19:58] <chrisccoulson> micahg - yeah, i wasn't planning on spending too much time on it, i just wanted to see if there would be any major issues, or functionality that we would be missing
[19:59] <micahg> chrisccoulson: k, I hope we can do a major cleanup next cycle, but we have to do another round of porting, so I was planning toward the end of release to start porting to xul20 in the transition PPA
[19:59] <chrisccoulson> porting to xul20 is going to be fun ;)
[20:02] <micahg> chrisccoulson: indeed :)
[20:03] <micahg> chrisccoulson: and if squeeze isn't released yet, we'll be 2 xul versions ahead of sid
[20:03] <micahg> chrisccoulson: lfaraone: oh, and the pyjamas guy is ranting on debian-devel now
[20:04] <chrisccoulson> heh, i should tell him that i've started on the pyxpcom packaging now ;)
[20:04] <micahg> chrisccoulson: was just going to ask you about that :)
[20:04] <chrisccoulson> or maybe i should let him whinge for a bit longer....
[20:04] <micahg> chrisccoulson: I was going to chat with upstream about the future of the project, but never had a chance, you might want to do that to see if it'll even be around in 18 months
[20:04] <chrisccoulson> i'm a bit stuck with the versioning for pyxpcom, because the upstream source doesn't have a version number
[20:05] <micahg> chrisccoulson: maybe do it like scott did pybootchartgui
[20:05] <chrisccoulson> micahg - i tried asking in #pyxpcom earlier about versioning and doing a proper release, but i got no answer
[20:05] <micahg> 0+rev
[20:05] <chrisccoulson> micahg - yeah, that's what i've done for the packaging so far, but then i remembered that the python-xpcom binary package has existed in ubuntu before, but with a higher version number
[20:06] <chrisccoulson> so, i'd either need to pick a new binary name (and deviate away from debian), pick another arbitrary version number, or add an epoch
[20:07] <micahg> chrisccoulson: I would just suggest making this replace/conflict the old package
[20:09] <micahg> ah
[20:09]  * micahg forgot about upgrading those old people
[20:09] <micahg> chrisccoulson: you shouldn't worry about upgrading old users I think since the new packages will depend on pyxpcom
[20:10] <chrisccoulson> micahg - i was trying to keep the same binary name as before (python-xpcom), which aligns also with debian
[20:10] <micahg> s/shouldn't/shouldn't need to/
[20:10] <micahg> chrisccoulson: well, is it common to move binaries from one source to another?
[20:11] <chrisccoulson> micahg - i think it's been done before
[20:11] <micahg> chrisccoulson: maybe you should chat with glandium about his plans for it
[20:11] <micahg> it's not in xulrunner-1.9.2 source
[20:11] <micahg> in debian
[20:14] <chrisccoulson> right, dinner time. bbiab