Per bug 595054 comment 2, we're way overdue for a Breakpad update for 2.1.x. We should pull the latest (assuming a sanity test of the latest build looks good in our tree) plus the (in-progress) fix for http://breakpad.appspot.com/163001/show aka http://code.google.com/p/google-breakpad/issues/detail?id=397; we'll need that for PUBLIC symbols in several Gecko libs as well as for our OS symbol generation scripts.
7 years ago
Target Milestone: --- → Camino2.1
Since that fix still isn't moving, and we don't want to rock the 2.1 boat, let's push this. We don't have any fixes we're really trying to get, so we should avoid possible late-in-the-game instability.
Flags: camino2.1b1+ → camino2.1b1-
Summary: Update Breakpad pull for Camino 2.1 → Update Breakpad pull
Target Milestone: Camino2.1 → ---
Per discussion, we'll take this if things look good since the PUBLIC symbol bug is fixed.
Assignee: nobody → stuart.morgan+bugzilla
Target Milestone: --- → Camino2.1
Hm, so a year ago Breakpad's nibs were converted to xibs. The sender hasn't changed since then, so I'll try skipping just that change. We'll have to hack conditional build rules out of the projects too though, and maybe change their format. How much do we actually care about the ability to build on 10.4? Are we building our releases on the 10.4 bot, or a 10.5 bot?
Official nightlies for 2.1 come from cb-xserve04 on 10.5, but we continue to produce depend builds and run tests on cb-xserve04 on 10.4 (where running tests produce results that are stable, rather than always linearly increasing like on 10.5/cb-xserve04). I'd rather not drop support for building on 10.4 if we don't have to, but on the other hand, I don't want you to have to invest lots of times in hacks. (Also, once 2.1 ships, we won't have to keep building 2.0, which means cb-xserve01 won't need to remain on 10.4 to keep the same build config across the entire 2.0 series, so cb-x1 could be upgraded or retired. I don't know if it's the box or 10.5 that's responsible for the test skew we see on cb-x4…)
Everything is looking good in my local build (crashes are caught and uploaded, no obviously wrong symbol files), so I'll try to land tomorrow, or maybe Monday, and we'll see if it does in fact build on the 10.4 toolchain with my changes.
Created attachment 564051 [details] [diff] [review] Prep Since our upstream localizations landed, we need to strip them from our build like we do with Sparkle. This moves that script into a separate file, so that it's easier to work with, and makes it more generic so that it will run over both Sparkle and Breakpad. I'm going to land this separately since it's a self-contained change, and doesn't actually depend on the Breakpad update.
Prep landed as http://hg.mozilla.org/camino/rev/ac77aca8591a
Breakpad update to r841 landed as http://hg.mozilla.org/camino/rev/f3c9d5b169f9 Watching tinderboxen; fingers crossed.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
In a surprise twist, the waterfall stayed green. Hopefully the nightly will look good :)
(In reply to Stuart Morgan from comment #9) > In a surprise twist, the waterfall stayed green. Hopefully the nightly will > look good :) Luckily, you're around now when the nightlies are generated :) However, I 1) Looked at the project changes (as I tried to unmangle the results of Xcode usage+VCS merging), and I don't see anything that indicates removal of stuff related to linking like last time ;-) 2) Checked the log from cb-x1 this morning for that checkin and confirmed that it completely recompiled Breakpad successfully on 10.4 3) performed 'make clean' and rebuilt both debug and release successfully locally so I think we should be fine. Note that cb-x1 never clobbers 1.9.2, since only the release tinderbox does nightlies, so we won't see a clobber build on 10.4, but I don't foresee an issue on 10.4 based on existing results (but if you did really want to trigger one, cvs co mozilla/tools/tinderbox-configs/camino/macosx/CLOBBER with -r CAMINO_2_1_M1_9_2_BRANCH and commit it to trigger a clobber ;-) ). Unfortunately, I don't know of any reproducible crashers on 1.9.2 that we can use to trigger test crashes with the actual release nightlies, so for that part we'll just have to monitor incoming crashes on crash-stats. Oh, hmm; I wonder if we can modify Steven's DebugEvents plug-in to crash on load or something, and load his test page in the nightly…? So, fingers crossed, but yay; nice work!
Minor nitpick - the comment in scripts/scrub-framework-languages.pl (attachment 564051 [details] [diff] [review]) says: ># Removes all the Sparkle languages that aren't also part of the app bundle, since those ># languages can't be loaded anyway. It doesn't mention Breakpad. (archeologist of the 30th century will have a headache)
Looks like it is working fine on 10.6.8. Here is one crash (bug 534672): https://crash-stats.mozilla.com/report/index/a0cd483b-7895-4fc9-bf1c-c842d2111003 Version 2.1b3pre (184.108.40.206pre 20111003001604)
You need to log in before you can comment on or make changes to this bug.