328854 - Talkback disabled on SeaMonkey Mac nightlies

Status: VERIFIED FIXED

(Release Engineering :: General, defect)

Description

[Stewart Gordon]

The Mac nightlies of SeaMonkey have disappeared yet again.  The last one available is datestamped 15 February, but is actually build 2006010510.

Comment 1

[Steve England [:stevee]]

Related to bug 327140?

Comment 2

[Stefan [:stefanh]]

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?

Comment 3

[Stewart Gordon]

Who or what are barcelona and planetoid?

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

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

[Gulliver]

(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

[Robert Kaiser]

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

[Gulliver]

(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!

Comment 8

[Chris Cooper [:coop] (he/him)]

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

[Robert Kaiser]

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

[Chris Cooper [:coop] (he/him)]

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

[Chris Cooper [:coop] (he/him)]

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

[Robert Kaiser]

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

[Chris Cooper [:coop] (he/him)]

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

[Stefan [:stefanh]]

(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

[Gulliver]

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

[Chris Cooper [:coop] (he/him)]

(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

[Gulliver]

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

But it works...

Comment 18

[Mark Mentovai]

> 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

[Robert Kaiser]

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

[Mark Mentovai]

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, [e-mail] is built as an outlying extension, so it (and its install.rdf) lives at Contents/MacOS/extensions/[e-mail].

Comment 21

[Gulliver]

> 
> 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?

Comment 22

[Frank Wein [:mcsmurf]]

*** Bug 337003 has been marked as a duplicate of this bug. ***

Comment 23

[Chris Cooper [:coop] (he/him)]

(In reply to comment #20)
> The offending install.rdf file is coming from
> mozilla/extensions/inspector/install.rdf .  For Firefox, [e-mail]
> is built as an outlying extension, so it (and its install.rdf) lives at
> Contents/MacOS/extensions/[e-mail].

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

Comment 24

[Chris Cooper [:coop] (he/him)]

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

Comment 25

[Gulliver]

(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

[Chris Cooper [:coop] (he/him)]

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

[Chris Cooper [:coop] (he/him)]

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

[Mark Mentovai]

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

[Benjamin Smedberg]

Why would regxpcom or MozillaAlive know or care anything about install.rdf? What are the differences?

Comment 30

[timeless]

*** Bug 341560 has been marked as a duplicate of this bug. ***

Comment 31

[Robert Helmer [:rhelmer]]

More accurate summary.

Comment 32

[David Barr]

The mac nightly build is stuck at 2006061307.

Comment 33

[ChrisX]

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...

Comment 34

[J. Paul Reed [:preed]]

(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

[ChrisX]

Yes, thank you.

Comment 36

[J. Paul Reed [:preed]]

(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.

Comment 37

[David Barr]

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

[Mark Mentovai]

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.

Comment 39

[Mark Mentovai]

Over to Rob, because he was apparently working on this.

Comment 40

[Mark Mentovai]

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!

Comment 41

[Mark Mentovai]

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

Comment 42

[Robert Kaiser]

(In reply to comment #20)
> The offending install.rdf file is coming from
> mozilla/extensions/inspector/install.rdf .  For Firefox, [e-mail]
> is built as an outlying extension, so it (and its install.rdf) lives at
> Contents/MacOS/extensions/[e-mail].

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

Comment 43

[Chris Cooper [:coop] (he/him)]

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

Comment 44

[David Barr]

(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

[Chris Cooper [:coop] (he/him)]

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

[Axel Hecht [:Pike]]

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

[Chris Cooper [:coop] (he/him)]

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

[Chris Cooper [:coop] (he/him)]

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.