Closed
Bug 289846
Opened 19 years ago
Closed 19 years ago
make sure tinderboxen work with suite rebranding
Categories
(SeaMonkey :: General, defect)
SeaMonkey
General
Tracking
(Not tracked)
RESOLVED
FIXED
seamonkey1.0alpha
People
(Reporter: kairo, Assigned: chase)
References
Details
I gotta look into tinderbox code to figure out where tinderboxen may break with rebranding (renaming binaries is the key there) and prepare a fix for that, so we can make the transition as smooth as possible.
Reporter | ||
Updated•19 years ago
|
Flags: blocking-seamonkey1.0a+
Target Milestone: --- → Seamonkey1.0alpha
Reporter | ||
Comment 1•19 years ago
|
||
It looks to me as if it would be enough to just change the binary and product names in tinder-config.pl/tinder-defaults.pl and we should be done. I'm not completely sure of that, but that's all I found when searching through mozilla/tools/tinderbox
Reporter | ||
Comment 2•19 years ago
|
||
From a mail from chase (reply to mine):
> From what my research showed, getting tinderboxen to go green again after
> renaming the binaries might be as easy as correcting the variables in the
> tinderbox configurations, see my last comment in bug 289846.
Yes, it should be that easy. In practice we'll see as we make the changes where
things break. :)
[...]
Easiest way is to file bugs on the main issues and assign them to me.
Assignee: kairo → chase
Reporter | ||
Comment 3•19 years ago
|
||
Chase, just as a note: The real rebranding patch is up at bug 285696 and should have reviews soon. This means, it will hopefully be able to land soon (meaning that I'd like it to happen before 1.8b3) in a concerted effort with bug 292268 and bug 288199. This comment is meant as a warning that those infrastructure issues might get hot within a week or so. Stage can probably be prepared before that, tinderboxen have to be fixed after the fact anyways.
Reporter | ||
Comment 4•19 years ago
|
||
OK, we're ready to go code/patch-wise, but Chase is overloaded currently (no time before the july 4 holiday) and can't do the infrastructure stuff atm. We have to coordinate bugs 292268,285696,288199,289846,298901 to make it all happen at once and make the transition as smooth as possible, so we'll push out the whole thing a few days (this is all SeaMonkey-only so we don't have to care about aviary 1.1a2 too much), I hope it'll be ASAP - still need to schedule an impact date/time with Chase though. Additionally, we'll have to wait a few days as well to get MoFo reviews on the announcement which should go public in a tight timeframe around the happening of those changes. Please be warned it's coming up but patient at the same time.
Reporter | ||
Comment 5•19 years ago
|
||
We have a problem with tinderbox config vs. build config on Mac now: a tinderbox ProductName of "Mozilla" looks for Mozilla.app and a profile in /Library/Mozilla/Profiles/, "SeaMonkey" for SeaMonkey.app and /Library/SeaMonkey/Profiles/ - but we have SeaMonkey.app now, but the profiles still in /Library/Mozilla/Profiles/ :-/ The tinderbox code in question is at http://lxr.mozilla.org/mozilla/source/tools/tinderbox/build-seamonkey-util.pl#1080 From looking at that, including the BeOS case that is hardcoded, the app-specific Darwin/MacOSX casing and that VendorName stuff, I'm starting to think that Tinderbox might be better off using a variable for the app-specific part of the profile name. Not sure what's the right fix for now though...
Reporter | ||
Comment 6•19 years ago
|
||
the easiest fix (quite hackish though) probably would be to set a ProductName of "SeaMonkey" for those mac tinderboxes and add the following section before http://lxr.mozilla.org/mozilla/source/tools/tinderbox/build-seamonkey-util.pl#1118 } elsif ($Settings::ProductName eq 'SeaMonkey') { $profile_dir = "$ENV{HOME}/Library/Mozilla/Profiles/$Settings::MozProfileName/";
That's really the way things should work, IMO. There should really only be one configuration variable for the "product" for tinderbox. The scripts should then be able to use that variable to get the right profile name, etc.
Reporter | ||
Comment 8•19 years ago
|
||
OK, Chase fixed that problem with setting a "profile product name" of "Mozilla" when the ProductName is "SeaMonkey". So, now, SeaMonkey-Ports are green, only myotonic is back to its previous orange about regxpcom and MozillaAliveTest failing. Of the main SeaMonkey tinderboxen, the Linux ones are green, as is barcelona. monkey is back to its previous orange (Can't open perl script "TestOutSinks.pl": No such file or directory). The only really still open tinderbox problem is creature, which fails at packaging, probably due to the stub installer package naming thing I pointed out and have a possible fix attached in bug 292268.
Reporter | ||
Comment 9•19 years ago
|
||
Hmm, barcelona is red again, seemingly because ProductName is "Mozilla" instead of "SeaMonkey": /builds/tinderbox/Mozilla-Trunk/Darwin_6.8_Depend/mozilla//dist/Mozilla.app/Contents/MacOS/seamonkey-bin does not exist.
Reporter | ||
Comment 10•19 years ago
|
||
(In reply to comment #9) > Hmm, barcelona is red again, seemingly because ProductName is "Mozilla" instead > of "SeaMonkey": Forget that. I'm dumb. I should not look at old tinderbox pages. :(
Reporter | ||
Comment 11•19 years ago
|
||
OK, there's another small, but real issue still left: lhasa still stages its builds in the wrong directory (mozilla instead of seamonkey)...
Assignee | ||
Comment 12•19 years ago
|
||
(In reply to comment #11) > OK, there's another small, but real issue still left: > > lhasa still stages its builds in the wrong directory (mozilla instead of > seamonkey)... lhasa takes a while to build and it's likely it had already started its 7/2 trunk build when I changed the FTP path in its configuration. Do I see a current GTK2 build in http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2005-07-04-08-trunk/ ? If so, it appears to be working correctly now. Let's give it another day to be certain. If everything is okay I'll remove lhasa's seamonkey files from pub/mozilla/nightly/ and call it a done deal.
Status: NEW → ASSIGNED
Reporter | ||
Comment 13•19 years ago
|
||
(In reply to comment #12) > lhasa takes a while to build and it's likely it had already started its 7/2 > trunk build when I changed the FTP path in its configuration. Do I see a > current GTK2 build in > http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2005-07-04-08-trunk/ ? > If so, it appears to be working correctly now. Yes, looks you're right again. When I filed that comment, those builds weren't there yet, but it's true, it uploaded them correctly. Thanks for your help! It seems the only problems left are monkey (which is a different thing as we know) and creature (which we hope to get cleared).
Reporter | ||
Comment 14•19 years ago
|
||
Thanks Chase, all tinderboxen (not counting monkey and myotonic which have different problems not related to rebranding) are green and working correctly. btek still has increased Tp, which is tracked in bug 299624 This bug is FIXED.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•