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