[01:32] bjsnider: thanks for the merge requests, could you repropose against the branches without .daily in them? [01:52] micahg, done [01:53] is there anything i can do about the issue of adding precise? [01:53] bjsnider: chrisccoulson has to do that [01:53] I think he was waiting for the builds to pass, so since he fixed trunk, I'm guessing he might have enabled it [01:53] bjsnider: and thanks, I"ll look at the branches in a bit [01:54] i ran a stable pbuilder build and it failed after the fix, but for reasons that don't make sense, so i'm thinking it's just my pbuilder environment [01:55] stable branch i mean [01:55] heh, I have to look at stable later anyways since Chromium released and I need to get it working on Lucid-Precise [01:55] or rather Chrome releases [01:55] *released [01:55] what error did you get [01:56] you need to get chrome working? [01:56] no, chromium [01:56] http://pastebin.com/B0a6WUgC [01:56] that's teh build failure [01:56] but there's no upstream Chromium releases, only Chrome [01:58] well, it could mean we're missing a build dep or something [01:58] or just a bug in that file [01:59] http://src.chromium.org/viewvc/chrome/trunk/src/chrome/build_nacl_irt.py?r1=101659&r2=106982 [01:59] that suggests irt.nexe is missing [02:00] but get-orig-source should have pulled that in [02:00] i checked the tarball and it isn't there [02:00] but the builds succeeded even after that commit, so i think this is just a quirk of my system [02:01] i think if the ppa build fails that's the time to worry about it [02:01] I have native client disabled on stable [02:01] it was breaking the build before [02:01] ok [03:41] grrrr, that stupid kde patch again [03:41] i enable it for a single day and it's already broken [03:42] oh well, at least it didn't break the precise builds :) [04:02] chrisccoulson: speaking of precise, can you enable it for chromium when you get a chance? [04:13] bjsnider: in the future, can you branch from the non-daily branches as well? [04:13] * micahg will manually merge the patches this time [04:13] unless you're still around [04:13] sure i can [04:13] bjsnider: ok, you want to fix now or next time? [04:14] next time [04:14] ok [04:14] and please also add the new snapshot commit before the changes as well next time, I'll take care of it this time [04:16] what do you mean? [04:16] ideally, it shows what version the changes are made at [04:17] for build failures, stuff like this: http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-browser.dev/revision/565 [04:17] before you do the changes [04:18] those commits don't exist in the non-.daily branches [04:24] you mean you want me to add something like "* New upstream snapshot: 15.0.861.0~r97996" [04:24] wait, he's changing the changelog and i'm not [04:24] i don't get it [04:25] take a look at this once LP updates it: https://code.launchpad.net/~chromium-team/chromium-browser/chromium-browser.dev [04:27] yes? [04:27] 568 says which revision failed, 569 is one fix, 570 is another [04:28] if we consistently fix after breakage, it makes merging into the next channel easier when the version is bumped [04:28] you just pull all the fixes down [04:28] ok, so you want me to add 568 in other words [04:28] right [04:28] no problem [04:29] thanks [04:29] bjsnider: BTW, it took me almost 5 months to get commit rights to the mozilla team bzr branches, even after that I still was learning more [04:30] not saying it'll necessarily take that long, but there's a learning curve, but once you get what's going on, you can fly :) [04:30] like i told you earlier i'm used to just acting unilaterally [04:31] but i also have access to fta to ask about build failures and packaging issues [04:31] right, Ubuntu doesn't work too well like that in general, there are times to act unilaterally, but usually it's a coordinated effort amongst team members [04:31] he's undoubtedly going to read this irc log at some point, so -- hi fta! [04:33] i should have known not to edit the daily branches because i run one of the bots for another project [04:39] heh, mistakes will be made, that's why we review branches initially [04:39] heck, mistakes will be made afterwards as well, that's why we have peer review [15:03] lol @ https://twitter.com/#!/bhearsum/status/147328159996579840 ;) === m_conley_away is now known as m_conley [16:14] bhearsum, if i download an official build of firefox 8.0.1 and then set app.update.desiredChannel to "beta", is it meant to update to the latest beta? [16:15] or is there another method to switch channels? [16:15] channel switching is not supported [16:15] oh, that's probably why it offers me a 5.0 beta then ;) [16:15] well, actually, it just fails. but the update response is for 5.0 [16:16] you can't adjust the channel in the product [16:16] you can do it by adjusting defaults/pref/channel-prefs.js though - be sure to shut down the browser before changing that [16:16] but no, 8.0.1 _shouldn't_ give you an offer for any beta [16:16] you can change the pref in nightly/defaults/pref channel-prefs.js but it will result in unpredictable results [16:17] our release and beta streams are completely separate now [16:17] ok, thanks [16:17] kbrosnan: not really unpredictible [16:17] maybe non-obvious though [16:18] a bit impercise but mainly was saying that the switching was untested [16:18] and when we did test it. it resulted in some odd states [16:19] what i was trying to figure out is that if someone installs the release, switches to beta and then decides they want to go back to release, does test pilot remain enabled? [16:19] where an aurora folder/icon/label was updateing on beta [16:19] ah, unpredictible in terms of the state of the app afterwards [16:19] chrisccoulson: IIRC yes [16:19] that's dependent on the channel name alone, i think [16:20] just for context, we currently install test pilot in our beta builds in the application directory, which means that it gets removed if someone decides they want to use a release build again [16:21] the reason for this is that we have all users of our development release using the beta [16:22] and didn't want them all to permanently end up with test pilot [16:22] ah [16:22] hmm, i might be confusing Test Pilot with Feedback [16:22] but i'm considering installing test pilot as a distribution addon like in the official builds, so that the addon manager can update it [16:23] but that means that anybody who runs the development version of ubuntu will end up with test pilot installed until they manually remove it [16:23] yeah... [16:23] distribution addon means it ends up in the profile, right? [16:24] yeah [16:24] hm [16:28] http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/extensions/testpilot@labs.mozilla.com/modules/setup.js#189 makes me think that it will be disabled when the channel is switched [16:29] bhearsum, yeah, i just tried that. the feedback button disappears :) [16:29] nice! [16:29] so that might be ok then. i don't think it would be the end of the world if people who are currently running precise end up with test pilot installed in their profile :) [16:30] the button disapears, afik test pilot test may still run if the study allows that version [16:30] and it obviously doesn't matter for people who opted in to the beta on our stable releases either [16:30] kbrosnan, i think that's probably ok. unless you can think of a reason why it shouldn't run :) [16:31] nope, just enumerating possibilities [16:31] thanks [16:32] ok, i'm going to switch it to being a distribution addon in ubuntu then, so that people don't keep reporting bugs about being pestered to install the latest version of test pilot, when they can't :) [16:32] btw damn cool that you have test pilot setup [16:32] we try to offer an experience that closely matches the upstream one, with the exception that it's delivered through our package manager instead :) [16:33] and that's why you guys are so awesome [16:33] heh, thanks ;) [16:55] Is the lack of about:crashes on firefox from https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa intentional? [16:56] alex_mayorga, yes, we don't submit crash symbols for those builds. we do that for release + beta though [16:57] chrisccoulson: what's the rationale? [16:57] alex_mayorga, too much data ;) [16:58] chrisccoulson: so if I hope to help Mozilla I should switch to http://nightly.mozilla.org/ ? [16:58] alex_mayorga, yes, you can do that for nightlies [17:00] chrisccoulson: what's the function of "Ubuntu Mozilla Daily Build" then? [17:00] alex_mayorga, so we don't get any nasty surprises at beta :) [17:01] of course, you can still run it if you wish, but without the crash reporter for the time being :( [17:01] what would it take to have about:crashes? perhaps that can be my 1st patch ever ;-) [17:02] alex_mayorga, well, it's just a matter of turning on the crash reporter. but then the debug symbols have to go to mozilla [17:03] we do that for release and beta already, but the amount of data we'd be submitting would be crazy if we did it for nightly builds too [17:03] (1 build / release, 2 architectures / build for Firefox + Thunderbird, nearly every day) [17:04] I see [17:04] that ends up being around 400MB (compressed) every day [17:05] and those need to be stored somewhere ;) [17:08] have there been talks with mozilla if they want that? [17:09] no, but i'm not sure there are enough users of our nightly builds to justify it :) [17:09] of couse, i could be wrong [17:12] any way to obtain a "guesstimate"? [17:12] i think launchpad has an API for counting downloads [17:13] i'm not sure of a better way though [19:37] micahg, we have an el problemo with the new chromium 18: http://code.google.com/p/chromium/issues/detail?id=107585 [19:38] i think it might be fixed quickly though so we should sit on it [20:55] something is awry with this commit: http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-browser.head/revision/845 [20:55] after that dbg packages stopped being created properly [21:00] I don't see anything getting installed there in debian/rules [21:04] i think i'll revert all of that and run it in pbuilder to see if a proper dbg package is created [21:05] well, we don't want breakpad, the only thing that looks like it might help is the linux symbols stuff === m_conley is now known as m_conley_away