Talkback disabled on SeaMonkey Mac nightlies

VERIFIED FIXED

Status

Release Engineering
General
--
blocker
VERIFIED FIXED
12 years ago
4 years ago

People

(Reporter: Stewart Gordon, Unassigned)

Tracking

({regression})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

12 years ago
The Mac nightlies of SeaMonkey have disappeared yet again.  The last one available is datestamped 15 February, but is actually build 2006010510.
Related to bug 327140?

Comment 2

12 years ago
monkey and barcelona had to be upgraded to meet the new build requirements. planetoid have temporarily replaced monkey. barcelona hasn't been replaced, though. It looks like we're waiting for 2 Xserves to replace monkey and barcelona.

Perhaps we can find some kind of temporary solution until everything is settled? Could dbaron (administrator of planetoid) maybe upload the planetoid nightlies? Or maybe it won't take that long time before everything is set up?

Assignee: zach → ccooper
Depends on: 327092
(Reporter)

Comment 3

12 years ago
Who or what are barcelona and planetoid?
They're machine names.

I'm not confident planetoid is configured properly for producing nightlies, nor do I have time to mess with setting up nightly build upload (which is needlessly too complicated, last I checked).

Comment 5

12 years ago
(In reply to comment #4)
> They're machine names.
> 
> I'm not confident planetoid is configured properly for producing nightlies, nor
> do I have time to mess with setting up nightly build upload (which is
> needlessly too complicated, last I checked).
> 

David,

do I understand correctly: the server where the Mac-nightlies are created and reside is broken, a new server might be installed somewhen but nobody wants to comment on the timeframe and neither you nor anybody else is willing to work on a workaround?

Is this the baseline of your message?

Comment 6

12 years ago
If you'd read the bug this depends on, you'd probably know that the new servers have been delayed in shipping and should arrive by Monday, March 6th. It doesn't make much sense to work on getting build machines set up this week when new build machines are planned to get set up starting next week.

Comment 7

12 years ago
(In reply to comment #6)
> If you'd read the bug this depends on, you'd probably know that the new servers
> have been delayed in shipping and should arrive by Monday, March 6th. It
> doesn't make much sense to work on getting build machines set up this week when
> new build machines are planned to get set up starting next week.
> 


Thanks for the information and sorry if you felt my message was insulting!

Updated

12 years ago
Status: NEW → ASSIGNED

Comment 8

12 years ago
barcelona has been resurrected for Mozilla1.7 builds. Once we're out of the woods for respins for the 1.7.13 release, I will get the SeaMonkey build setup there again.

ETA: 2006/04/04

Comment 9

12 years ago
My private "phlox" tinderbox is producing experimental universal binaries from trunk, available at http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/contrib/latest-trunk/seamonkey-1.5a.en-US.mac-uni.dmg for now. Note that I can't include talkback as I'm outside MoFo, but you should be able use those builds for testing anyways :)

Comment 10

12 years ago
I'm going to be adding a SeaMonkey-Trunk build to bm-xserve01 this morning. This may not be the final resting place for the build, and the existing configs that I've moved forward from barcelona may need some updating, but it's a start.

Sorry for the delay on this.

Comment 11

12 years ago
The build is now running:

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1145460060.20982.gz&fulltext=1

Can someone please take a look at the mozconfig file for this build and let me know what needs to change, e.g. for universal binaries, prebinding, etc.?

In the meantime, I'll try to get the release bits in tinder-config.pl configured correctly.

Comment 12

12 years ago
coop: cool!

Universal build is actually quite easy:
set
$MacUniversalBinary = 1;
in tinder-config.pl
and in mozconfig, use the following:
. $topsrcdir/build/macosx/universal/mozconfig
and instead of "ac_add_app_options --enable-prebinding", use that:
ac_add_app_options ppc --enable-prebinding

compare to the mozconfig in http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1145458320.19038.gz&fulltext=1

Contact me or mento on IRC if you need more help with that :)

Comment 13

12 years ago
I've made the config changes necessary to produce UBs and to properly stage releases. Leaving open until we get a bona-fide nightly created and staged.

Comment 14

12 years ago
(In reply to comment #13)
> I've made the config changes necessary to produce UBs and to properly stage
> releases. Leaving open until we get a bona-fide nightly created and staged.
> 

Hmm, atm it looks like they're not getting packaged correctly:

"seamonkey-1.5a.en-US.mac.dmg                       21-Apr-2006 17:33  8.7K"

The .dmg doesn't contain any binary.

Comment 15

12 years ago
I used the 2006041913 built for a couple of days now and it is quite stable:
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/contrib/latest-trunk/seamonkey-1.5a.en-US.mac-uni.dmg

Comment 16

12 years ago
(In reply to comment #15)
> I used the 2006041913 built for a couple of days now and it is quite stable:
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/contrib/latest-trunk/seamonkey-1.5a.en-US.mac-uni.dmg
> 

That's a contributed build, not the one that _should_ be coming from bm-xserve01.

Comment 17

12 years ago
> 
> That's a contributed build, not the one that _should_ be coming from
> bm-xserve01.
> 

But it works...

Comment 18

12 years ago
> But it works...

That's not the point.

From the bm-xserve01 trunk build log:

/builds/tinderbox/SeaMonkey-Trunk/Darwin_8.5.0_Depend/mozilla/build/macosx/universal/unify: copyIfIdentical: files differ:
  ../build/ppc/dist/seamonkey/SeaMonkey.app/Contents/MacOS/install.rdf,
  ../build/i386/dist/seamonkey/SeaMonkey.app/Contents/MacOS/install.rdf
make[1]: *** [postflight_all] Error 1
make: *** [postflight_all] Error 2

This is because tests (regxpcom and MozillaAlive) were run in place on the ppc version, changing the install.rdf file that would be part of the package.  Because it no longer matches the install.rdf file in the i386 package, there's no way for unify to know what to put into the combined universal binary.

This should be an error that turns the tinderbox red:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/tools/tinderbox/post-mozilla-rel.pl&rev=1.95&mark=215-218#215

kairo, how do you want to handle this?

Comment 19

12 years ago
Mark:
Umm, I wonder why there's an install.rdf at all...
Interestingly, the box has staged a tinderbox-build that looks complete (at least the files size), but nightlies have a problem.
Could this be talkback-related in some form (that is built for release builds but not for other cycles)?

Comment 20

12 years ago
Yes.

Ordinarily, unify is run immediately after the ppc and i386 builds complete, as part of client.mk's build or alldep target.  In the failing SeaMonkey builds, that initial unify is completing successfully.

When building Talkback, unify must be run a second time.  This is because Talkback installs itself in ppc/dist, and they need to be copied into the universal staging area.  Since different apps put Talkback in different locations, the only sure-fire way to handle this is to run unify a second time.

Talkback is built after tests are run on the app.  This is probably by design: there's no sense in buliding Talkback for a build that failed tests and won't be uploaded.  Even so, I think it would make sense to run tests on a COPY of the app, to avoid the possible indeterminacy inherent in letting the app modify itself between build time and packaging time.

Anyway...

The offending install.rdf file is coming from mozilla/extensions/inspector/install.rdf .  For Firefox, inspector@mozilla.org is built as an outlying extension, so it (and its install.rdf) lives at Contents/MacOS/extensions/inspector@mozilla.org.

Comment 21

12 years ago
> 
> Hmm, atm it looks like they're not getting packaged correctly:
> 
> "seamonkey-1.5a.en-US.mac.dmg                       21-Apr-2006 17:33  8.7K"
> 
> The .dmg doesn't contain any binary.
> 

Any news on that one?
*** Bug 337003 has been marked as a duplicate of this bug. ***

Comment 23

12 years ago
(In reply to comment #20)
> The offending install.rdf file is coming from
> mozilla/extensions/inspector/install.rdf .  For Firefox, inspector@mozilla.org
> is built as an outlying extension, so it (and its install.rdf) lives at
> Contents/MacOS/extensions/inspector@mozilla.org.

mento: what needs to happen here to make this work? Does it need to be moved/removed/referenced differently?

Comment 24

12 years ago
I've temporarily disabled Talkback so we can at least get some new builds out to people.

Comment 25

12 years ago
(In reply to comment #24)
> I've temporarily disabled Talkback so we can at least get some new builds out
> to people.
> 

Chris,

where are these new builts available? Don't show up in http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/ nor in http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/contrib/latest-trunk/.

Thanks

Comment 26

12 years ago
The turn-around time for builds on bm-xserve01 is over 4 hours, so I imagine the nightly for today just hasn't finished building yet.

Comment 27

12 years ago
The SeaMonkey nightly is here:

http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2006-05-16-11-trunk/

...and it should be showing up in the latest-trunk dir as well.

Talkback has been disabled for this build. 

Has there been any progress with the install.rdf Talkback problem?

Comment 28

12 years ago
I don't know about "progress" - I don't think it's really a bug that install.rdf files get overwritten, although it's certainly undesirable in cases like this.

Comment 29

12 years ago
Why would regxpcom or MozillaAlive know or care anything about install.rdf? What are the differences?
Component: FTP: Staging → Build & Release
QA Contact: myk → preed

Comment 30

12 years ago
*** Bug 341560 has been marked as a duplicate of this bug. ***
Summary: No SeaMonkey Mac nightlies since 5 January 2006 → SeaMonkey Mac nightlies since 5 January 2006
More accurate summary.
Summary: SeaMonkey Mac nightlies since 5 January 2006 → Talkback disabled on SeaMonkey Mac nightlies

Updated

12 years ago
Assignee: ccooper → build
Status: ASSIGNED → NEW

Comment 32

12 years ago
The mac nightly build is stuck at 2006061307.

Comment 33

12 years ago
Right now the latest Mac build is 29-Jun-2006, whereas all others are July 7. I'd really like to test the new JEP 0.9.5+f...
(In reply to comment #33)
> Right now the latest Mac build is 29-Jun-2006, whereas all others are July 7.
> I'd really like to test the new JEP 0.9.5+f...

Looks like there's a current mac build in:

ftp://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/

rhelmer fixed a problem with the OS X Seamonkey Trunk tbox (bm-xserve02).

Does this address your issue?

Comment 35

12 years ago
Yes, thank you.
(In reply to comment #35)
> Yes, thank you.

I'm going to resolve this then.

If there's still a problem with talkback in the UB builds, someone will probably have to take a look at that to make sure unify gets properly run or what-have-you; if so, re-open, but also re-assign to someone who is going to look at it.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 37

12 years ago
Wait, I'm confused.

Comment #32 and Comment #33 are about the nightly builds choking in general, again. The fix is noted in Comment #34, verified in Comment #35, and the bug is marked resolved in Comment #36.

However, this bug is now tracking the fact that Talkback isn't getting built into the Mac nightly builds right now, right? A quick look at 

http://kb.mozillazine.org/Talkback,

followed by a quick look at

/Applications/Mozilla/SeaMonkey.app/Contents/MacOS/components

(allowing for personal variation), showed me that, as of 2006072004, Talkback is still not getting built in.

So, was this bug tracking the overall fact that nightly builds for OSX were failing, or the fact that Talkback wasn't getting built in? If the former, then we're good here, but need to open another bug for the Talkback thing. If the latter, then we need to re-open.

Comment 38

12 years ago
Reopening.  Nightly build log of SeaMonkey (bm-xserve02-trunk) shows no evidence of attempting to build Talkback.  Is $shiptalkback on?  I'd check, but the tinder-configs aren't in a public repository, and I can't check on the box because I've got no idea where bm-xserve02 is.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 39

12 years ago
Over to Rob, because he was apparently working on this.
Assignee: build → rhelmer
Status: REOPENED → NEW

Comment 40

12 years ago
Oh, reading the context here*, $shiptalkback seems to be off for a reason - this probably doesn't belong to a build person.  Rob, sorry, I'm yanking this one from you.  :)

* Actually, I supplied the context in comment 18 and comment 20, but I forgot that's what THIS bug was.  Too many bugs!
Assignee: rhelmer → build

Comment 41

12 years ago
I stuck a suggestion for solving this bug in bug 347421 comment 7.

Updated

11 years ago
Depends on: 373373

Updated

11 years ago
Depends on: 383125

Comment 42

11 years ago
(In reply to comment #20)
> The offending install.rdf file is coming from
> mozilla/extensions/inspector/install.rdf .  For Firefox, inspector@mozilla.org
> is built as an outlying extension, so it (and its install.rdf) lives at
> Contents/MacOS/extensions/inspector@mozilla.org.

If that was really the problem, it may be resolved with SeaMonkey having changed to be a toolkit app now.

Comment 43

11 years ago
I've added a SeaMonkey stanza to the install.rdf file in the Talkback repo, and triggered a respin on all platforms. 

Comment 44

11 years ago
(In reply to comment #43)
> I've added a SeaMonkey stanza to the install.rdf file in the Talkback repo, and
> triggered a respin on all platforms. 

Since I've been (kind of) bugging people about this, drop a note when the respins are done, and I'll download the nightly and start hammering... ;)

Comment 45

11 years ago
I've enabled Talkback again in the Mac tinder-config.pl.

Windows and Linux Talkback builds are failing now (as KaiRo reported in IRC):

__main__.Error: ('/builds/tinderbox/SeaMonkey-Trunk/Linux_2.6.9-42.ELsmp_Depend/mozilla/fullsoft/rdf/install.rdf', 42, 'UNDEFINED_VAR', 'SEAMONKEY_VERSION')

Full log:
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1181252160.4009.gz&fulltext=1#err4

This var seems to be passed in correctly to Preprocessor.py, where "correctly" means "in a similar manner to Firefox" in this case. 

cc-ing Pike for his insight on Preprocessor.py

Comment 46

11 years ago
I'm on dialup right now and can't really load full clobber logs. There is a slight difference between quoting when passing the arguments between preprocessor.pl and Preprocessor.py, you want to check the patch in bug 361583. Preprocessor.py doesn't allow for quoted values, not sure if that's an issue.

Comment 47

11 years ago
The Talkback Makefile just needed to know about SEAMONKEY_VERSION. I've triggered a new set of nightlies to pick up the change.

Comment 48

11 years ago
In the test builds I've been doing for bug 373373, the ppc version of the Talkback extension gets built (there is no Intel version), and then repackaging fails to get that into the right place.

If I read bug 347421 comment 7 correctly, if I bundle that ppc-only version of the Talkback extension and drop that into the right place for UB (which is what the repackaging code is meant to do anyway), it should just work. Is that an accurate interpretation? This would be ideal, because this is what we'll be doing for bug 373373 anyway.

Updated

11 years ago
Status: NEW → RESOLVED
Last Resolved: 12 years ago11 years ago
Resolution: --- → FIXED

Updated

11 years ago
Status: RESOLVED → VERIFIED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.