Closed Bug 487274 Opened 15 years ago Closed 15 years ago

need Thunderbird shark builds

Categories

(Mozilla Messaging Graveyard :: Release Engineering, defect)

Product:
Mozilla Messaging Graveyard
Component:
Release Engineering
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: gozer, Assigned: gozer)

References

Details

Let's produce nightly comm-1.9.1 shark/dtrace enabled builds.
From looking at firefox, there will require this mozconfig-foo:

# shark specific options
ac_add_options --enable-libxul
ac_add_options --enable-shark
ac_add_options --enable-dtrace
ac_add_options --enable-debugger-info-modules
ac_add_options --disable-install-strip
export MOZ_PKG_SPECIAL="shark"
TB won't work with --enable-libxul. In theory that shouldn't be needed but you may find that we get link problems at the final step.
<http://hg.mozilla.org/build/buildbot-configs/rev/8d63025aaa0f>

Mac OS X 10.5 comm-central shark

builder should show up on the waterfall shortly. It's a dep/nightly builder for now, just like regular dep/nightly builders, except it shouldn't upload anything for the time being. No builds, No updates, No symbols, nothing.

Once it goes green, I'll reconfigure to get the bits to go somewhere.

I am a little worried about the update channel for this one, not sure how *not* to break this.
The build was continually burning because it needs --enable-static --disable-shared:

http://build.mozillamessaging.com/buildbot/production/builders/MacOSX%2010.5%20comm-central%20shark%20build/builds/7

So I pushed a mozconfig change that should fix this:

http://hg.mozilla.org/build/buildbot-configs/rev/8628c6fe2e82
Oh, this build doesn't appear on clobberer at the moment (wrong directory for the tools?) - so it will want a clobber even if it does go green.

(In reply to comment #3)
> I am a little worried about the update channel for this one, not sure how *not*
> to break this.

I don't think we need an update channel. AFAIK these are intended as builds to check out performance, not builds for general use/testing. Firefox doesn't appear to provide updates (looking at their mozconfig), and I don't think we need to either.
Ok, that time it failed due to missing symbols whilst building the crash reporter stuff. My guess is that it really needs a clobber to sort itself out, unless shark doesn't like static builds - but I doubt that's the case as its only failing in crash reporter.
(In reply to comment #5)
> Oh, this build doesn't appear on clobberer at the moment (wrong directory for
> the tools?) - so it will want a clobber even if it does go green.

Yeah, fixed, but will only show up after the currently running nightly build finishes.

> (In reply to comment #3)
> > I am a little worried about the update channel for this one, not sure how *not*
> > to break this.
> 
> I don't think we need an update channel. AFAIK these are intended as builds to
> check out performance, not builds for general use/testing. Firefox doesn't
> appear to provide updates (looking at their mozconfig), and I don't think we
> need to either.

Agreed, no update channel at all for these then.
(In reply to comment #5)
> I don't think we need an update channel. AFAIK these are intended as builds to
> check out performance, not builds for general use/testing. Firefox doesn't
> appear to provide updates (looking at their mozconfig), and I don't think we
> need to either.

I completely agree that the ability to occasionally checkout performance is the high order bit to worry about.  However, I think there's non-trivial (but also not insanely high) value to having an update feed too: I often see perf issues while using nightly builds, and if there were a nightly feed of this sort, I would use that instead so that I could investigate issues when they happen.  I suspect others might as well.  

So my take is that if an update feed is easy, it's worth doing.
Reading back more closely, I see now that it appears not to be easy.  So, uh, never mind.  :-)
Enabled uploading builds to ftp.m.o, next cycle should show up. Looking good, needs comfirming that these are indeed Shark-enabled and work as expected.
Probably a cut-n-paste error, try and of the builds in here:

<http://ftp.mozilla.org/pub/mozilla.org/thunderbird/tinderbox-builds/comm-1.9.1-macosx-shark/>
Nightly shark builds completed as well.

<http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.1/thunderbird-3.0b3pre.en-US.mac-shark.dmg>
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Is there a reason why those builds are generated only each second day?
I could swear I have checked each folder under http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2009/04/ and haven't seen a shark build for 20090421. Right now I cannot see builds on 2009-04-17 and 2009-04-18. Are they somehow hidden?
Depends on: 490320
I am reopening this bug, because the Leopard builders I created have been build as Leopard Servers, not regular Leopard.

The problematic side-effect of this is that these leopard installs eat CPU cycles like crazy, even when idle (i.e. load > 4.0), since they are running all the OS X Server gizmos.

I will be reinstalling these machines as ordinary Leopard, tracked in bug 490320.
Status: RESOLVED → REOPENED
No longer depends on: 490320
Resolution: FIXED → ---
momo-vm-osx-leopard-01 is back as a shark builder, freshly installed.
And green at that.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.