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