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?
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?
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).
(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?
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.
(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!
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
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 :)
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.
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.
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 :)
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.
(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.
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
(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.
> > That's a contributed build, not the one that _should_ be coming from > bm-xserve01. > But it works...
> 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: *** [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?
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)?
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, email@example.com is built as an outlying extension, so it (and its install.rdf) lives at Contents/MacOSfirstname.lastname@example.org.
> > 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. ***
(In reply to comment #20) > The offending install.rdf file is coming from > mozilla/extensions/inspector/install.rdf . For Firefox, email@example.com > is built as an outlying extension, so it (and its install.rdf) lives at > Contents/MacOSfirstname.lastname@example.org. mento: what needs to happen here to make this work? Does it need to be moved/removed/referenced differently?
I've temporarily disabled Talkback so we can at least get some new builds out to people.
(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
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.
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?
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.
Why would regxpcom or MozillaAlive know or care anything about install.rdf? What are the differences?
*** Bug 341560 has been marked as a duplicate of this bug. ***
More accurate summary.
The mac nightly build is stuck at 2006061307.
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?
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.
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.
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.
Over to Rob, because he was apparently working on this.
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!
I stuck a suggestion for solving this bug in bug 347421 comment 7.
(In reply to comment #20) > The offending install.rdf file is coming from > mozilla/extensions/inspector/install.rdf . For Firefox, email@example.com > is built as an outlying extension, so it (and its install.rdf) lives at > Contents/MacOSfirstname.lastname@example.org. If that was really the problem, it may be resolved with SeaMonkey having changed to be a toolkit app now.
I've added a SeaMonkey stanza to the install.rdf file in the Talkback repo, and triggered a respin on all platforms.
(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... ;)
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
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.
The Talkback Makefile just needed to know about SEAMONKEY_VERSION. I've triggered a new set of nightlies to pick up the change.
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.