[00:00] folks, the firefox-4.0 package from the daily ppa gives me: http://paste.ubuntu.com/463223/ (i386) [00:04] yofel: you use ubuntuzilla? [00:04] er, what's that? [00:06] yofel: ugh seems like a prerm issue [00:06] * micahg needs to learn that graph for when which file is used [00:07] yofel: which version was installed previously? [00:07] sec [00:08] Preparing to replace firefox-4.0 4.0~b2~hg20100712r47317+nobinonly-0ubuntu1~umd2 (using .../firefox-4.0_4.0~b2~hg20100712r47341+nobinonly-0ubuntu1~umd1_i386.deb) ... [00:09] yofel: ugh, that's my fault :( [00:09] yofel: first the profile was 3.7, then 4.0 [00:10] yofel: tonights upgrade should fix it then [00:10] ok, thanks :) [00:11] oh great, trying to look up ubuntuzilla on sf.net results in the sf page crashing aurora and rekonq [00:12] yofel: I guess that's more bugs to file :) [00:12] indeed :D [03:47] yofel: I'm running the same version you were before [03:47] there shouldn't have been a conflict there [09:35] asac: what's the current ppa for TB 3.1? [10:33] BUGabundo_remote: 3.1 is in daily ppa ... but seems to fail ;) [10:33] asac: wasn't micah supposed to give it own PPA? [10:33] long long agio [10:40] hmm [10:40] i think that never happened [10:40] for -stable we have separtae ppas maybe [10:44] maybe [10:44] is there a stable for 3.1? [11:41] about bug 557240: would that be SRUable and if yes before 10.04.1? [11:41] Launchpad bug 557240 in ubufox (Ubuntu Lucid) (and 1 other project) "Disable "Report a Problem" menu item for the stable release (affects: 2) (heat: 47)" [High,Triaged] https://launchpad.net/bugs/557240 [11:41] it seems everyone forgot about that === BUGabundo_remote is now known as BUGabundo_lunch [13:35] yofel, nobody has forgotten about that, it's just that nobody has had time to do anything with it [13:38] chrisccoulson: the patch works fine here, I'm not sure if the branch I attached is correct === BUGabundo_lunch is now known as BUGabundo_remort === BUGabundo_remort is now known as BUGabundo_remote [15:39] chrisccoulson: did you think about instantbird and weave yet? I'm thinking maybe we should keep them [15:40] micahg - i'm not so sure about weave. how certain is it that the functionality will be merged in to FF4.0? [15:41] i was thinking about keeping instantbird as well though, but i want to have a play around with it first [15:41] it looks pretty cool [15:41] and the screenshots on their website are taken on ubuntu ;) [15:42] chrisccoulson: k, I want to file an archive admin bug to add mongodb and instantbird and weave if we keep them [15:42] to the package set I mean [15:42] cool, no problem [15:42] i need to fix instantbird so that it builds, i'll probably do that this afternoon [15:44] chrisccoulson: mongodb is currently unusable in Lucid because of a problem finding mozjs, I haven't had a chance to look at it yet, it slipped under the radar during the cycle [15:48] chrisccoulson: yes, from all the blog posts, it looks like weave/sync will be in 4.0 [15:49] chrisccoulson: but we're not shipping 4.0 with maverick :) [15:50] micahg - right, but maverick probably won't be on 3.6 for too long after release (assuming the release schedule doesn't slip, we'll probably be migrating to 4.0 early next year) [15:50] chrisccoulson: well, I would think, hopefully until Apr 2011 :) [15:51] micahg - i don't mind too much. is it building native components? [15:51] chrisccoulson: If we can hold out until Firefox 4.1 that'll be better, maybe we can only migrate once in the maverick cycle [15:51] chrisccoulson: yes, that why I think it should be kept [15:52] micahg - ok, so we should probably keep it then [15:53] chrisccoulson: I'm trying to remember if there are any other rdepends I forgot about [15:53] mediatomb :) [15:53] k, so I'll file an archive admin bug to add those 4 sources to the mozilla package set [15:54] thanks [15:55] chrisccoulson: I haven't looked at the rdepends in main this cycle yet, willl you be taking care of those? [15:56] where is the firefox-3.7.head branch nowadays? is that 4.0? [15:56] asac: yes [15:56] ah ... me changes checkout location [15:57] micahg: http://brainbird.net/file/BUGabundo-20100713T213810-mfy4wkc.jpeg [15:57] hmm. you guys upgraded the branch to 2.0a? [15:57] asac: that was an accident, I wasn't warned about it [15:58] hmm [15:58] not my call ;) [15:58] asac: fta__: said to go with it and see if there are issues [15:58] but i hate 2.0a [15:58] because hardy users cant branch it ;) [15:58] huge mistake by bzr team imo to make it default before hardy is EOL [15:58] bad for bzr reputation as a relyable thing [15:59] asac: right, I'm going to check the branches before merging now to make sure that doesn't happen to any others [15:59] well. its too late [15:59] the idea was that all mozillateam branches are fine [15:59] now there is not much point ;) [15:59] b'ah, my laptop is completely unusable with maverick on it :/ [16:00] asac: at least they backport in a PPA for hardy users [16:01] asac: I'm confused, is xine-plugin a xul rdepend? it seems to depend on nspr [16:01] yes [16:01] might also use nspr directly (or nss) === fta__ is now known as fta [16:01] ok so after this upgrade and can remove all mozillateam branches :/ [16:01] it busted my repo [16:02] asac, when i hit that, it was already too late [16:03] micahg: i am pushing a good --pack-0.92 branch [16:03] to the old location [16:03] you can kill the 4.0 branch and replay ;) [16:04] hmm. takes a bit longer [16:06] i dont understand why bzr folks dont allow to lock donw the branch format. i dont want any branch to be updated by accident [16:07] * asac goes and deletes 3.7 branch again and hopes that launchpad forgets the format [16:09] BUGabundo_remote: what was the pic? [16:09] hell how can i tell bzr to NOT stack a branch [16:10] chrisccoulson: do you think nspluginwrapper is ok to request as well? [16:10] micahg - yeah, should be [16:10] asac: do you know if nspluginwrapper upstream moved or is it dead? [16:11] dead [16:11] it was never really alive ;) [16:11] just got some defilbration shock treatments back then to make this working for flash 10 :) [16:12] asac: you mentioned before that 1.3 was a devel tree, Debian has been running it for some time already, do you think I should merge it or just try to fix the one known issue with GDK_NATIVE_WINDOWS on amd64? [16:12] i dont care. get feedback on 1.3 in a ppa maybe. [16:12] before upgrading [16:13] 1.3 is a pre-alpha... but if it helps then fine [16:13] asac: k, thanks [16:14] asac: is there a channel for armel porters in Ubuntu? I have a couple failures that I'm not sure what to do with [16:16] grr ... i really hate bzr now [16:17] micahg: pure awesomeness [16:30] micahg: ok i found a way .... delete branch ... run bzr init --pack-0.92 lp:~mozillateam/firefox/firefox-4.0.head [16:31] then you can push a fresh branch of the branch i currently create using the firefox-3.7.head [16:31] is a workaround [16:31] seems that launchpad changed the default to stack branches, which caused the implicit upgrade bacecause it needs format 6 to support stacking [16:31] the remote init (after delete) does the trick) [16:32] ki will let you know when the 3.7 branch is pushed [16:32] asac: k [16:32] though my branch might not be good either anymore because i did a pull initially [16:33] (which failed, but could be its stuck in the middle wrt fromats now) [16:33] asac: you can run bzr check to see [16:33] well. bzr info -v also shows a bunch of nubmers [16:33] i think its all fine ;) [16:33] lets see what happends when i branch after the push [16:34] ah, ok === fta_ is now known as fta [17:27] wow, 10 minutes and counting to create a source package is just crazy [17:35] asac: awesome, it looks like it worked [17:36] fta: asac fixed the ff4.0 branch format, can I move it back into place under firefox-4.0.head? [17:37] micahg, do it, but i assume it will break the dailies [17:37] fta: k [17:42] fta: you might want to resubscribe as well [17:42] fta_: you might want to resubscribe as well === fta_ is now known as fta === gavin__ is now known as gavin [17:56] micahg: you cant move [17:56] you have to do bzr init --pack-0.92 with the new url (e.g. creat an empty branch) [17:56] and then you can push my branch there [17:56] (that should work) [18:05] asac: yes, you can rename the branches [18:06] asac: and I rebranched your branch [18:06] so the old one won't be used anymore [18:06] s/rebranched/branched locally/ [18:07] asac: and my local copy shows branch format 6 now instead of branch format 7 [18:08] yep [18:08] also bzr info with some luck says pack-0.92 [18:08] ok out (communiting) [18:08] asac: on launchpad it does :) [18:09] asac: thanks === fta_ is now known as fta === fta_ is now known as fta [19:44] jdstrand - i pushed the pre-release version of seamonkey to the PPA today, before i realised that we haven't published 2.0.5 yet in lucid [19:44] is it still possible to do that? [19:45] chrisccoulson: possibly [19:45] chrisccoulson: well, actually, no [19:45] chrisccoulson: well, possibly [19:45] :) [19:45] heh [19:45] i wasn't sure if the binaries have disappeared or not ;) [19:45] let's just say it is an operation I've not ever attempted [19:46] no, they haven't [19:46] you could delete the one in the ppa now, then move the other back in place, at which point I could publish to the archive [19:46] that should work [19:47] hmmm, how do i do that? [19:47] I just don't think I can publish your superceded one with our current tools [19:47] chrisccoulson: if you'd like, I can do it [19:47] jdstrand, if you don't mind, that would be great :) [19:53] chrisccoulson: done [19:53] jdstrand, excellent, thanks [19:53] chrisccoulson: how I did it was I used 'Delete packages' followed by 'Copy packages' [19:53] ah, ok. makes sense now :) [19:53] chrisccoulson: it is a little weird copy packages to the same ppa, but that is how you do it [20:06] mdeslaur: did Seamonkey never make it to Lucid? [20:06] micahg, it didn't [20:07] chrisccoulson: k, should we wait a week and push 2.0.6? [20:07] i'd just been discussing that with jdstrand before you reappeared [20:07] chrisccoulson: ah [20:07] * micahg checks logs [20:08] chrisccoulson: k, so 2.0.5 is going [20:08] great [20:08] micahg, yeah, that's the plan [20:09] chrisccoulson: are you planning on SRUing the newsblog fix in 2.0.6? [20:09] chrisccoulson: I also realized I forgot to do the back changelogs for hardy, jaunty, karmic [20:09] micahg - yeah, probably. i need to get a SRU ack for that though [20:10] chrisccoulson: k, I think that fix should deifinitely go in the hardy/jaunty/karmic 2.0.6 builds [20:10] OMG, micahg I love you, thanks for FF4.0B <3 [20:10] bobby: enjoy :) [20:11] No more Java crashing :D [20:11] chrisccoulson: I need to make a ubuntu-mozilla-ppa-bugs project, should the owner be the team? should the team be the bug supervisor? [20:11] ... There isn't a bugs project yet? [20:11] micahg, yeah, that should be fine (making the team the owner) [20:12] chrisccoulson: that means the whole team will get e-mail for the PPA bugs [20:12] bobby: not for PPA bugs [20:12] chrisccoulson: well, not because of owner, but because of bug supervisor [20:12] micahg - ah, maybe that's not such a good idea [20:13] chrisccoulson: so, should I make another bugs team for that PPA? [20:13] Shiretoko? When the heck did FF4 get a codename? [20:14] bobby: not the codename for it [20:14] bobby: that was 3.5 [20:14] bobby: I'll try to fix that tonight :( [20:14] ... So, why am I using the Shiretoko Wbe Browser Firefox 4.0 beta [20:14] Oh, okay, lol [20:14] I was gonna say... [20:15] chrisccoulson: then I'll update the apport hook to report bugs there if they're from a PPA [20:15] Hey, anyone here know when the interface is getting update for 4.0? [20:15] chrisccoulson: do you want to receive the PPA bugmail? [20:16] micahg - yeah, i probably should do [20:16] i'm just trying to work out how it works at the moment [20:16] chrisccoulson: k, so I'll make a team with you, me and ddecator [20:16] assuming he wants it :) [20:17] micahg, we should probably have a team similar to mozilla-bugs (called mozilla-ppa-bugs or something), which we use as the bug contact [20:18] chrisccoulson: with a ML that's subscribed to? [20:19] chrisccoulson: or just for the team membership to get the bugs [20:21] micahg - we probably don't need a mailing list [20:22] we could just create the team and make mozillateam a member, much like how mozilla-bugs works already [20:22] chrisccoulson: k, I'll set it up tonight, probably won't fix the apport hook till the weekend though [20:22] (and i've just realised why i get 2 mails for every bug) [20:22] chrisccoulson: no, mozilla-bugs has an ML, that's why we don't get the bugs [20:24] micahg - ah, i get it now. we should probably do it the same way then [20:25] chrisccoulson: I don't think we need the overhead of the ML [20:25] chrisccoulson: plus these are bugs that are for prereleases, so I don't they need to be archived [20:25] *think [20:27] i'm slightly confused now. is there a team setting to not receive bug mail? i'm just wondering why i don't get mail for mozilla-bugs [20:27] chrisccoulson: because it goes to the Mailing list since that's the team contact address [20:27] ah, now that makes sense [20:35] Hey micahg... JS still isn't working :( [20:35] bobby: what do you mean? [20:36] Well, when I try to open up a site that uses Javascript (Newegg in particular), it just doesn't load [20:36] bobby: that's weird [20:37] The little clock thing is about 80% full, and it says "Loading..." but it never loads... [20:38] Java works fine though from what I've used though. [20:39] bobby: I'll have to look into it later [20:39] m'kay [20:40] bobby: BTW, saw an article that the new JS engine will be in around Sep 1 [20:40] *Twitch* [20:40] How about July 14th? [20:41] bobby: it should still work, I'm talking about Jaegermonkey [20:42] Yeah, I know :P, Oh yeah, why is 4k video on youtube running slow :P? [20:42] bobby: flash or HTML5? [20:42] Flash :P, HTML5 on YouTube runs slow on any browser :P [20:43] bobby: idk, can't do anything about flash being slow [20:43] Is it because it is in the new 4k resolution, would that slow it down? [20:45] bobby: yeah, that might do it :) [20:45] Oh okay. BTW: HTML5 video on YouTube runs slow, but I don't think that it is FF. The player itself is what is lagging, especially the interface [20:45] HTML5 is too experimental ATM. [20:45] bobby: unless you have lots of RAM and a GPU w/RAM as well [20:46] bobby: well, it works pretty well [20:46] Hey! 4GB of DDR2 RAM, and an NVIDIA 9600M GT - 512MB dedicated, overclocked to 575MHz! [20:47] html5/youtube is smooth here [20:47] chromium [20:47] micahg - nice, i got instantbird working now [20:47] chrisccoulson: cool, I fix weave this weekend [20:47] thanks [20:47] chrisccoulson: BTW, 0.2 was released [20:47] instantbird [20:48] micahg - do you think we should be shipping a symlink in /usr/include/xulrunner-1.9.2.7/ pointing to /usr/include/nss, much like we do already with nspr? [20:48] instantbird is looking in there for the nss headers, and i'm just wondering which one is right [20:48] the upstream SDK has a nss folder [20:49] but no headers in it :/ [20:49] oh, actually, the upstream xulrunner SDK does ship the nss headers [20:49] perhaps we should be symlinking those then [20:50] chrisccoulson: yeah, that makes sense, I think we've been patching them to use pkg-config to find teh headers [20:50] ok, i'll add a symlink in our xulrunner packaging [20:52] chrisccoulson: I think we should probably test rebuild all the rdepends against it to see if there are any issues, what do you think? [20:52] micahg - yeah, can do