[00:45] <micahg> chrisccoulson: also, I'll be joining the mozext team in Debian to help with our extensions
[00:45] <chrisccoulson> cool!
[00:45] <micahg> chrisccoulson: I also joined pkg-multimedia to help maintain vlc (bdrung already does a good job with it) and mediatomb
[00:47] <bdrung> micahg: somehow i maintain many multimedia apps (xmms2, audacious, vlc, audacity, ...)
[00:47] <micahg> bdrung: right, but only vlc is a xul rdepend :)
[00:47] <chrisccoulson> micahg, that's cool
[00:48]  * micahg now needs to find the time to actually update mediatomb before it's too late to get it into maverick
[00:48] <bdrung> micahg: yes. you have to be careful. it always starts with one package ;)
[00:48] <chrisccoulson> sometimes i think i should actually do something in debian, but i don't have time to chase people to sponsor packages all the time ;)
[00:48] <micahg> bdrung: I know, it's addictive ;)
[00:48] <micahg> chrisccoulson: that's why teams are great, you have built-in sponsors
[00:49] <bdrung> micahg: the step after getting a bunch of packages is to write tools (mozilla-devscripts, syncpackage, ack-sync, sponsor-patch, wrap-and-sort, ...)
[00:50] <bdrung> chrisccoulson: try it. if it takes too long for you, you still can push to ubuntu and sync it once it's in debian
[00:50] <micahg> bdrung: right now I'm just short on time and being sick doesn't help
[00:52] <micahg> chrisccoulson: BTW, I started working on the gnome-shell wrapper again last night, I think with the patch seb added, it'll actually build now, I just need to get the rules target right
[00:52] <chrisccoulson> micahg - ok, that's good. we still need to fix gjs though don't we?
[00:53] <chrisccoulson> this is all going to be fun when libmozjs has disappeared ;)
[00:53] <micahg> chrisccoulson: yeah, I think we can remove the rpath and relax the xul dependencies
[00:54] <micahg> chrisccoulson: I'm guessing we need to add a note somewhere that a wrapper is needed for any program using the library after that
[00:55] <chrisccoulson> yeah, possibly. i'm not sure where best to add that though
[00:55] <chrisccoulson> and i wouldn't worry too much just yet, as gnome-shell is the only thing using gjs
[00:55] <chrisccoulson> and probably will be the only think for a little while
[00:56] <chrisccoulson> s/think/thing/
[00:56] <micahg> chrisccoulson: right, but stuff in the archive is supposed to be "usable" for people's own stuff as well, no?
[00:57] <chrisccoulson> yeah, it should be. i'm not sure if gjs has any proper documentation or not
[00:57] <chrisccoulson> if so, we could just change that
[00:57] <chrisccoulson> if not, then i really wouldn't worry about it too much ;)
[00:58] <chrisccoulson> if there's no documentation,then people will find it difficult to use anyway
[00:59] <chrisccoulson> i really think we're going to end up maintaining libmozjs as an entirely separate module soon :/
[00:59] <micahg> chrisccoulson: if we can convince upstream to do their part, we can :)
[14:29] <chrisccoulson> b'ah, firefox 4.0 is really broken again :(
[14:30] <chrisccoulson> asac - i'm not sure how we're going to handle the split branding in firefox 4, it's getting more and more difficult to achieve
[14:30] <chrisccoulson> last week it was the single chrome.manifest, and now we have omnijar ;)
[14:35] <asac> ouch
[14:35] <asac> lets talk about taht over weekend chrisccoulson
[14:41] <Dimmuxx> so I guess no beta ppa this week?
[14:48] <chrisccoulson> Dimmuxx, highly unlikely, sorry
[14:48] <chrisccoulson> unless i switch off omnijar temporarily
[14:49] <chrisccoulson> but that would not be an incentive to fix it ;)
[14:49] <Dimmuxx> hehe well it doesn't matter so much since mozilla seem to ignore linux anyway nowadays :/
[14:50] <chrisccoulson> hmmm, that's not really true ;)
[14:51] <Dimmuxx> noone is working on the ui afaik
[15:53] <alexbodn> i've made a script to checkout and debuild bluegriffon, a website editor with xulrunner-2.0-dev from ubuntu ppa. the program builds (apparently correctly) but it doesn't show anything. tell me please how to proceed: upload files etc.
[15:54] <micahg> rsavoye: are you switching away from savannah for bug tracking also?
[15:56] <rsavoye> no, only source control
[15:56] <rsavoye> unfortunately the savannah admin never got bzr setup correctly, and mostly blew off any help the bzr team offered :-(
[15:57] <rsavoye> so a 1 line check was taking 20 minutes or so with bzr with sftp, way too slow...
[15:57] <rsavoye> micahg: btw, the cookie problem with YouTube is fixed in the coming release
[15:58] <rsavoye> it was working a year ago, but somebody accidentally removed all the XPCOM code, so it broke.
[15:58] <rsavoye> now it uses the newer NPAPI, which has much better coookie handling support
[16:01] <chrisccoulson> hey micahg
[16:04] <micahg> rsavoye: hmm, ok, well, maybe we should update launchpad to be able to link gnash bugs to savannah then
[16:04] <micahg> hi chrisccoulson
[16:04] <rsavoye> micahg: that would be nice if possible
[16:04] <rsavoye> on launchpad, it
[16:04] <rsavoye> s been mostly ubuntu specific issues
[16:05] <chrisccoulson> rsavoye, i did start looking at your gnash packages a couple of days ago, then i got sidetracked again ;)
[16:05] <rsavoye> no problem, I've been testing on Maverick since alpha-1 on ARM, x86, and amd64
[16:06] <rsavoye> the release should be out this weekend, just waiting for two translations to get done
[16:07] <chrisccoulson> micahg - do you have any idea why the reporter extension isn't working in our FF builds?
[16:07] <micahg> chrisccoulson: reporter extension?
[16:08] <chrisccoulson> micahg - yeah, there's meant to be an item in the Help menu to report broken websites, provided by extensions/reporter in the source
[16:08] <chrisccoulson> but it never gets built
[16:08] <micahg> chrisccouloreson: I don't know if they use it anym
[16:08] <chrisccoulson> and it's listed in MOZ_EXTENSIONS_DEFAULT
[16:08] <micahg> *I don't know if they use it
[16:08] <chrisccoulson> in browser/confvars.sh
[16:08] <chrisccoulson> MOZ_EXTENSIONS_DEFAULT=" gnomevfs reporter"
[16:09] <micahg> maybe it was never updated to 4.0?
[16:09] <chrisccoulson> the only reason i realised it's not being built is i tried running "make package" in a built tree, and it fails because the extensions/reporter/Makefile is missing, so it expects it to be there :/
[16:09] <chrisccoulson> micahg - it's not working in 3.6 either
[16:10] <micahg> chrisccoulson: hmm, idk
[16:11] <chrisccoulson> ok, no worries. i'll try and figure it out
[16:11] <chrisccoulson> micahg - not sure if you saw the earlier conversation about lp:firefox being broken again
[16:11] <micahg> chrisccoulson: I saw the omnijar thing
[16:12] <micahg> and the patches, but didn't look too closely
[16:12] <chrisccoulson> yeah, it's pretty broken
[16:12] <chrisccoulson> and it doesn't build properly anyway, even without the packaging problems
[16:16] <chrisccoulson> micahg - oh, i see the problem now
[16:16] <chrisccoulson> in debian/rules:
[16:16] <chrisccoulson> --enable-extensions=default,-reporter
[16:16] <chrisccoulson> so, we're deliberately switching it off
[16:17] <chrisccoulson> i suppose it's a bug in the upstream build system that it completely breaks make package
[16:17] <micahg> chrisccoulson: ah, ok, there was talk of removing it anyways
[16:18] <micahg> IIRC
[16:18] <chrisccoulson> it looks like it's still being used at the moment. do you know why we have it disabled?
[16:19] <micahg> chrisccoulson: no, what does bzr blame say for the line?
[16:20] <chrisccoulson> micahg:
[16:20] <chrisccoulson> 213       fta@sof | 	--enable-extensions=default,-reporter \
[16:20] <fta> ?
[16:21] <chrisccoulson> fta - any ideas about that change?
[16:21] <chrisccoulson> (why we disable the reporter extension)
[16:21] <fta> which branch?
[16:21] <chrisccoulson> fta - lp:firefox
[16:21] <fta> let me check
[16:22] <chrisccoulson> thanks
[16:22] <fta> revno: 212
[16:22] <fta>   * Make the reporter extension a link as we already ship it with xulrunner-1.9
[16:23] <fta> revno: 213
[16:23] <fta>   * Don't build the reporter extension at all and revert the firefox-3.0.install changes from the previous commit
[16:23] <chrisccoulson> fta - ah, makes sense
[16:23] <micahg> chrisccoulson: yeah, we forgot to reenable for all in one build :)
[16:23] <chrisccoulson> so, we should revert this change when not building with external xulrunner
[16:23] <chrisccoulson> ok, i'll do that now
[16:23] <chrisccoulson> fta - thanks :)
[16:24] <fta> 2008-03-15, so old..
[16:25] <chrisccoulson> micahg - after talking to bsmedberg on #developers, i'm wondering whether we should stop using "make install" in our builds
[16:25] <chrisccoulson> they don't test that upstream
[16:25] <chrisccoulson> and it's currently broken anyway
[16:25] <micahg> chrisccoulson: k, what's the alternative
[16:26] <chrisccoulson> micahg - "make package" and then manually unpack
[16:26] <fta> ship what's in dist/ :(
[16:26] <chrisccoulson> fta - that won't work either, there's extra things that happen now to package the chrome
[16:26] <chrisccoulson> which is what's currently broken in lp:firefox
[16:26] <fta> if install is not supported, they should remove it, but i will make other dist packagers cry
[16:26] <fta> -i+it
[16:27] <chrisccoulson> yeah, i can imagine ;)
[16:27] <micahg> chrisccoulson: that seems a little unusual, perhaps we should just patch and upstream when there are issues with make install
[16:27] <chrisccoulson> micahg - yeah, we could do. i was just thinking it might be safer for us to use the tested parts of their build system
[16:28] <micahg> chrisccoulson: maybe check with glandium and wolfir and see what they do
[16:29] <chrisccoulson> i'm fairly sure they're just doing make install right now, but some of the recent changes probably aren't going to affect other distro's anyway
[16:29] <micahg> oh...
[16:29] <chrisccoulson> (as they're using system libraries)
[16:29] <chrisccoulson> they're probably not going to benefit from some of these recent changes
[16:29] <micahg> chrisccoulson: I'm just wondering which way is likely to have a lower margin of error overall
[16:30] <chrisccoulson> micahg - <bsmedberg> FF-on-XR probably shouldn't be using omnijar
[16:30] <chrisccoulson> so other distro's may end up shipping close to what they already have
[16:30] <chrisccoulson> whereas we'll be shipping something closer to what upstream have :)
[16:34] <micahg> chrisccoulson: so by trying to match upstream's build, we're getting ourselves into trouble?
[16:34] <chrisccoulson> micahg - i wouldn't say that. we just need to adjust our packaging somewhat to cope with all the changes
[16:35] <chrisccoulson> in the end, ubuntu users will benefit more from that
[16:35] <chrisccoulson> hopefully :)
[16:35] <micahg> chrisccoulson: and no more sparc or ia64 to worry about for maverick
[16:36] <chrisccoulson> yay \o/
[16:36] <micahg> apparently the TB voted by email
[16:36] <chrisccoulson> micahg - https://lists.ubuntu.com/archives/technical-board/2010-August/000441.html
[16:37] <micahg> chrisccoulson: yes, I just read the thread :)
[16:41] <chrisccoulson> micahg - so, for TB3.1, what do we have left? i see you have enigmail for lucid in your PPA
[16:41] <chrisccoulson> and tb-locales for maverick and lucid
[16:41] <chrisccoulson> is there anything else blocking the update?
[16:43] <micahg> chrisccoulson: I'll try ppa-purge later and try upgrading to 3.1 again to see if there are any issues, if not, then just changelog entries and I'm good to go
[16:43] <chrisccoulson> micahg - excellent. we should probably aim for tomorrow, which will give us friday to catch any potential fallout before the weekend
[16:52] <micahg> chrisccoulson: k
[17:11] <micahg> chrisccoulson: now I remember the issue, I'm using -fshort-wchar to build enigmail which  I shouldn't need since it should be included in the build system
[17:12] <micahg> chrisccoulson: for enigmail
[17:24] <jdstrand> chrisccoulson: hey. when is 3.6.9 supposed to come out?
[17:24] <chrisccoulson> jdstrand, sept 7th
[17:24] <chrisccoulson> but we'll likely get the first build next week
[17:27] <jdstrand> chrisccoulson: I'd like to get my apparmor stuff into maverick. what are your thought on a 3.6.8+build1+nobinonly-0ubuntu3?
[17:27] <jdstrand> s/maverick/maverick sooner than that/
[17:27] <chrisccoulson> jdstrand, we already bumped the version in lp:firefox/3.6 to get the daily builds working again (we had to drop a patch)
[17:27] <chrisccoulson> we should get 3.6.9 in to maverick though
[17:28] <jdstrand> chrisccoulson: right, this is wholly separate from 3.6.9
[17:28] <jdstrand> chrisccoulson: I just want to get the apparmor stuff tested is all
[17:28] <chrisccoulson> that's ok, maverick will get the 3.6.9+build1 release next week
[17:28] <jdstrand> (meaning, we still get 3.6.9 into maverick on whatever schedule you want)
[17:28] <jdstrand> ok
[17:29] <jdstrand> that works fine for me
[17:29] <jdstrand> chrisccoulson: thanks
[17:29] <chrisccoulson> how close is sept 7th to final freeze?
[17:29]  * chrisccoulson opens calendar
[17:29] <jdstrand> otoh I don't know
[17:29] <micahg> chrisccoulson: it's right after beta1, we should be fine
[17:29] <jdstrand> going from 3.6.9buil1 to 3.6.9 official is knda a no-brainer though
[17:30]  * jdstrand looks at keyboard funny
[17:30] <chrisccoulson> eek, final freeze is sept 16th
[17:30] <micahg> chrisccoulson: oh, right, we wanted to stage in case we had another delay past Final Freeze
[17:30] <chrisccoulson> that doesn't give us a lot of breathing space :/
[17:30] <micahg> chrisccoulson: maybe branch maverick and release the apparmor fixes
[17:31] <micahg> then we can stage 3.6.9 without worry
[17:31] <chrisccoulson> yeah, i'm starting  to wonder whether we should do that now
[17:31] <chrisccoulson> my concern is that we upload build1 to maverick and the release then gets delayed until after final freeze
[17:31] <micahg> chrisccoulson: right, that's bad
[17:32] <chrisccoulson> perhaps we should be branching for maverick already :/
[17:32] <micahg> we don't want a bad build on the ISOs
[17:32] <chrisccoulson> it seems so early though ;)
[17:32] <micahg> chrisccoulson: we're < 2 months from release
[17:32]  * micahg really needs to rush to get newer versions of things in before beta...
[17:32] <jdstrand> chrisccoulson: you might ask how asac has handled that in the past
[17:33] <jdstrand> chrisccoulson: I can say that hardy had 3.0~b5+nobinonly-0ubuntu3 at release
[17:34] <jdstrand> we almost immediately upgraded to 3.0.1 (or something) iirc
[17:34] <micahg> jdstrand: yes, and asac's said on many occasions he took flac for that
[17:34] <chrisccoulson> jdstrand, we should just update to 4.0~b5 then :)
[17:34] <jdstrand> *shrug*
[17:34] <jdstrand> it is a different time now
[17:34] <micahg> jdstrand: that was also because we couldn't ship FF2 as default for the LTS
[17:34] <chrisccoulson> yeah, we don't have that sort of restriction now
[17:34] <jdstrand> we will be upgrading the 3.6 series almost immediately with a security update regardless
[17:35] <micahg> jdstrand: right, but we don't want to risk having a broken build on the ISOs
[17:35] <micahg> if we can help it that is :)
[17:35] <jdstrand> well, like I said, I don't care, I just want my apparmor stuff in maverick :)
[17:36] <chrisccoulson> final freeze is 3 weeks this cycle :/
[17:36] <chrisccoulson> why do we freeze so early?
[17:36] <jdstrand> 10.10.10 baby
[17:37] <micahg> chrisccoulson: better QA/fixes for final freeze
[17:39] <chrisccoulson> if we don't upload build1 straight to maverick, i'm wondering what's the best process for testing it
[17:39] <micahg> chrisccoulson: why not UMS like the other releases?
[17:39] <chrisccoulson> for 3.6.4, i think we uploaded it to the u-m-s PPA several weeks before the lucid release
[17:39] <micahg> it's in /topic
[17:39] <chrisccoulson> so that's probably ok
[17:39] <micahg> chrisccoulson: right and it wasn't released until 1.5 months later :)
[17:40] <jdstrand> chrisccoulson: if you decide to not push 3.6.9, I am more than happy uploading a 3.6.8...ubuntu3 to maverick
[17:42] <chrisccoulson> yeah, we could do. we should probably wait and see what issues come out of build1 testing next week though
[17:42] <jdstrand> chrisccoulson: k
[18:41] <micahg> chrisccoulson: is it worth adding some simple TB options to the mail indicator this cycle just so it shows up?
[18:41]  * micahg never added it to .head...
[18:41] <micahg> chrisccoulson: BTW, you're quoted in OMGbuntu: http://feedproxy.google.com/~r/d0od/~3/tFZRSH-AYDI/messaging-menu-support-for-thunderbird.html
[18:43] <chrisccoulson> heh, pressure's on :/
[18:43] <micahg> I was thinking to add it to .head after I committed 3.1.2
[18:43] <Dimmuxx> Is there any proper api documentation about the messaging menu somewhere? I have been thinking about using it for stuff
[18:43] <micahg> and request an FFe for it
[18:43] <chrisccoulson> micahg - i think we should wait until we've got proper integration with the menu
[18:43] <micahg> chrisccoulson: k
[18:45] <fta> speaking of app indicator, i wonder why i don't get the "new email" notification from evo
[19:02] <chrisccoulson> fta - i find the new mail notifications from evolution are quite flaky ;)
[19:02] <chrisccoulson> are your mails going through a filter and being moved in to a folder other than your inbox?
[19:03] <chrisccoulson> lack of messaging menu integration is the only thing stopping me from moving to thunderbird ;)
[19:03] <fta> i use procmail to sort my emails, before going to my imaps server
[19:03] <fta> last time i tried, i didn't like tb, felt out of place
[19:05] <chrisccoulson> i quite like tb, but i just don't like the lack of integration
[19:05] <chrisccoulson> which is why i'm really keen to get it in the messaging indicator
[19:07] <micahg> I guess I don't notice since I use xfce
[19:14] <fta> grrr, deco, lost the last 3min
[19:15] <fta> (deco=disconnection)
[21:39] <micahg> chrisccoulson: we might have some issues...security pushed openjdk 6b18-1.8.1 to hardy as well
[21:43] <micahg> chrisccoulson: we might have some issues...security pushed openjdk 6b18-1.8.1 to hardy as well
[21:44] <chrisccoulson> micahg - yeah, that's intentional i think
[21:44] <micahg> yeah, but apparently, it broke tomcat on hardy :-/
[21:44] <micahg> see -motu list
[21:44] <chrisccoulson> micahg - yeah, kees is already looking at that
[21:44] <micahg> chrisccoulson: I was more concerned with our Jaava support
[21:44] <micahg> in FF
[21:45] <chrisccoulson> it should be ok, other than the plugin is already provided by another source package
[21:45] <chrisccoulson> hmmm, i wonder if there's a conflict there too
[21:49] <chrisccoulson> no, that's ok actually, it has the proper Replaces on it ;)
[21:53] <micahg> ah good