Since our Jenkins CI for Breakpad is no longer functioning (and wouldn't work anyway since Breakpad is no longer hosted in SVN), we have a Breakpad snapshot in S3 that we use for building our Socorro stackwalker: https://github.com/mozilla/socorro/blob/master/scripts/bootstrap.sh#L25 I landed some changes in upstream Breakpad that are going to require us to update our Breakpad snapshot: https://groups.google.com/d/msg/google-breakpad-discuss/eybsK91Nbhk/u_Zb39IFAwAJ We're not using the new code client-side in Firefox yet, so as long as we get this fixed before I update the Breakpad snapshot in mozilla-central we're fine.
Mind blown in that I just learned that breakpad ~= stackwalk!  Still baffled by the fact that stackwalkER is something else (an executable build from minidump-stackwalk ). Just so I understand, the bug at hand here is to be ready to download another file from S3 (or keep the same URL and replace on S3) AND to replace the c++ files in minidump-stackwalk)?  https://github.com/mozilla/socorro/blob/master/scripts/bootstrap.sh#L29  https://github.com/mozilla/socorro/tree/master/minidump-stackwalk
Boy, that's confusing, isn't it! "Google Breakpad" is a C++ library as well as a set of programs that use that library. We used to use one of those programs, "minidump_stackwalk" directly from the Socorro processor. Nowadays, we build Breakpad to get the libraries (which we just have a static copy of in S3), and then build the programs in Socorro's "minidump-stackwalk" directory to invoke from the processor. The only program we actually use currently is called "stackwalk" (built from stackwalk.cc), which is functionally similar to Breakpad's "minidump_stackwalk" but it outputs JSON and does a few Mozilla specific things. This bug covers updating the file in S3 to match current Breakpad, and then building a new stackwalk binary to use in the processor (which, last I knew, happened as part of the Socorro build process).
In bug 1230659 I wrote a script to do Breakpad builds in Taskcluster. I was hoping to set up CI using it, but that's kind of a hassle. I think instead I'll just get that landed and then we can use those binaries here.
Here's the output of my Taskcluster build: https://queue.taskcluster.net/v1/task/OBPgU_HqTiuS2EwwIvosUQ/runs/0/artifacts/public%2Fbreakpad.tar.gz Here's a PR (that I don't actually want merged) to get a Travis build using that tar.gz: https://github.com/mozilla/socorro/pull/3281
That PR passed (after a few tries). We need one actual code change to make things build with a newer Breakpad snapshot: https://github.com/mozilla/socorro/pull/3281/commits/036d3598a271f02ae1ceb4b6fa20ee71c12357c7
Submitted that code change as: https://github.com/mozilla/socorro/pull/3282
jp: When that PR lands, we should be able to safely update the breakpad.tar.gz in S3. I'm not sure what the best way to do that is. You could just upload the new one over the old one, or if you would like to keep the old one around you could copy the old one to a new name and then upload the new one in its place. Alternately you could upload the new one with a new name (with an embedded date or something), but then we'd have to change the build script to point to the new location.
peterbe and I talked about this on IRC, and he'd rather see this fixed to be a little more future-proof, so I'm going to fix the Taskcluster task to use a Taskcluster index like I mentioned in bug 1230659 comment 0 so that we can use that as a stable URL in the bootstrap script to always get the latest Breakpad build.
I tweaked the script in bug 1230659, so now we can use the Taskcluster index as a stable URL: https://index.taskcluster.net/v1/task/project.socorro.breakpad.v1.builds.linux64.latest/artifacts/public/breakpad.tar.gz I'll submit a PR to use that URL.