Closed Bug 634908 Opened 14 years ago Closed 14 years ago

Resurrect shark builds

Categories

(Release Engineering :: General, defect, P2)

x86
macOS
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bzbarsky, Assigned: nthomas)

References

Details

Attachments

(3 files)

We keep trying to build them every night, but they fail because the mozconfig was never really ported to 64-bit land correctly.
Attachment #513137 - Flags: review?(catlee)
Comment on attachment 513137 [details] [diff] [review] Make shark nightly builds work again. We need MOZ_PKG_SPECIAL so the package names generated don't conflict with the regular builds.
Attachment #513137 - Flags: review?(catlee) → review+
Thanks! Fixed the comment to reflect that and pushed http://hg.mozilla.org/build/buildbot-configs/rev/3fe68a4ae4e8
Boris, have you had a successful build with this mozconfig ? I'm expecting the x86_64 part will barf trying link to a 32bit CHUD. See also bug 600434.
bug 625962 fixed this build config.
Nick, I've been building with --enable-shark locally, yes. We no longer link to CHUD.
Nice. The compile step after the mozconfigs succeeded, but then we failed in make buildsymbols: make buildsymbols in dir /builds/slave/cen-osx64-shark/build/obj-firefox (timeout 3600 secs) make: *** No rule to make target `buildsymbols'. Stop. Probably just need to fix buildbotcustom to run that in the right place now that shark is a universal build.
Blocks: 491464, 571367
Nick, can you do that part? I'm not sure what's involved in it...
This should do the trick based on the output of builder_list.py, but I need to run it through staging. Notes * shark on 1.9.1 and 1.9.2 are i386 only, everything else becomes universal with bz's mozconfig change. Which is the first hunk, since shark isn't a first class platform, more of a hack-it-up-form. * the factory.py hunk corrects what is a logical inconsistency, IMO. We don't want symbols contingent on uploading a dmg, we want it on using that dmg for tests/talos. It only disables buildsymbols for for shark builds, which are --disable-install-strip anyway, so this saves us some CPU time and disk space on ftp (150MB/day). We actually have to shuffle symlinks and update other mozconfigs so that my statement about branches is true.
This makes the mozilla-2.0 and generic branches use the same mozconfig as m-c. All other modern branches symlink to m-c, while 1.9.1 and 1.9.2 use macosx/mozill-central/shark/mozconfig via symlink. (In reply to comment #10) > We actually have to shuffle symlinks and update other mozconfigs so that my > statement about branches is true. This is actually wrong, I was looking at the macosx/ dir instead of macosx64/. There's a lot of unneeded crud in macosx/ that can get the chop at some point.
Comment on attachment 513258 [details] [diff] [review] [buildbotcustom] Tweak shark builds Works in staging. 1.9.1/1.9.2/m-c shark builds all run green, no symbols uploaded. My builder master has other consumers of MercurialBuildFactory (Try, releases) and I see no change in those factories in builder_list.py, so I don't think the second hunk can regress those.
Attachment #513258 - Flags: review?(catlee)
Assignee: nobody → nrthomas
Priority: -- → P2
Comment on attachment 513906 [details] [diff] [review] [buildbot-configs] fix branch mozconfigs Fills in the mozconfig gaps.
Attachment #513906 - Flags: review?(catlee)
Comment on attachment 513258 [details] [diff] [review] [buildbotcustom] Tweak shark builds Do we still need shark on older branches?
Attachment #513258 - Flags: review?(catlee) → review+
Attachment #513906 - Flags: review?(catlee) → review+
(In reply to comment #14) > Do we still need shark on older branches? Seems unlikely we're profiling performance on a stable branches but might still need it to diagnose problems as patches land. I've asked justdave for a grep over the ftp.m.o logs to see how many downloads are occurring.
This got pushed live earlier today. Please reopen if tonight's nightlies are still broken.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
The good news is that we now have shark nightlies. The bad news is that something is broken in the build system. In particular, they're being compiled with -fomit-frame-pointer even though --enable-shark is specified.
I filed bug 636495.
(In reply to comment #17) > http://hg.mozilla.org/build/buildbotcustom/rev/41d7ae2e5b31 I lost the hunk in process.py that disables buildsymbols, so we spend an extra 20 minutes creating the symbols file. Fixed on default with http://hg.mozilla.org/build/buildbotcustom/rev/13acb15b4930
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: